(2008-12-07) ILM “2” Web Portal Shows ‘An Unexpected Error Has Occurred’

After having installed and setup ILM "2" I used the ILM "2" Portal with the default domain administrator account. Everything worked like a charm. Then I wanted to test the request and approval of joining a distribution list. For that I created a few users in AD and also in the ILM "2" portal. In both cases I used the default domain administrator account as you can see below.

After trying to logon to the ILM "2" portal as one of those user accounts, I suddenly got the following error as you can see below.

Isn’t that weird? I was able to logon to the ILM "2" web portal with the default administrator account but not with any other account in AD. Looking at the error above, it is not helpful. It is even far from helpful unfortunately. The event log does not mention anything also. To get more information out of this you need to enable logging and stack tracing. This is done in the ‘WEB.CONFIG’ file for the particular Sharepoint Site. For the ILM "2" web portal that file can be found in the following directory: "C:\inetpub\wwwroot\wss\VirtualDirectories\80". In that file make the following adjustments:

* In the ‘system.web’ section: <customErrors mode="On" /> – change to – <customErrors mode="Off" />

* In the ‘SharePoint’ section: CallStack="false" – change to – CallStack="true"

Both are shown below:

Because the ‘WEB.CONFIG’ file is changed, Sharepoint itself restarts the Web Application automatically.

After these changes if you logon again you will see the following stack trace which is definitely more information than before.

Although it mentions ‘Access Denied’, it is still not helpful enough to determine the exact cause of the error.

Looking in the Application Event Log you might find an event ID similar to the one below.

Now you have more specific information about what the ‘Access Denied’ means. It is not the ‘NETWORK SERVICE’ that does not have enough permissions, because I was able to log on with the default domain administrator account. So, it must be the user itself that lacks some permission assignments. When investigating the specified paths, nothing turns out to be wrong, which makes it even more weird than it already is.

To keep this as short as possible, the error specified in the event ID is misleading. There is nothing wrong with the permissions on the specified paths. It is related to the specified user (ADCORP\AEINSTEIN) though!

The real issue here is that the user in Sharepoint lacked the specification of it sAMAccountName. See below. How did this happen? Well, I just forgot to specify it!

Sharepoint needs to have the sAMAccountName and the domain name specified to match the authenticating user from AD (ADCORP\AEINSTEIN) to the user in Sharepoint. Without either one you will get the error as shown at the beginning of this post. This was told to me by Brad Turner in the newsgroups. Brad also experienced this himself and there are other people that have experienced this or are experiencing it right now (based on the post on the newsgroups)

Hope this helps you, if you experience it, and thanks to Brad for giving me a hint to the solution.

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————