The other day I was working with a client and had a new error come up that I hadn’t seen before when creating a new Shared Service. The error was Error Event 7888 and next to my Shared Service Provider in SharePoint is said, “Provisioning Failed: Windows NT user or group ‘somedomain.orgusername’ not found. Check the name again”. After digging around and reading several other posts on the issue, I found what my problem was. Apparently, SharePoint doesn’t play well with the FQDN (or .com, .info, .local, etc). So everywhere an account that is needed for SharePoint is entered, it must simply be somedomainusername (without the .org).The areas that I found needed to be changed were the following:

The overall admin account (application pool for Central Admin). This can be changed using the command stsadm.exe –o updatefarmcredentials

The next place it needs to be changed is the application pool identity for any of the web applications you have created. This MUST be done through central admin…changing them in the IIS settings will not work. They can be changed in Central Admin in the Operations Tab under the Security Configuration heading and then click Service Accounts. From here you can change the credentials for any of the Application Pool users that need to be changed.

One other place in SharePoint the username may need to be changed is under the Search setting. The location of this varies between WSSv3 and MOSS.

Finally, the last location to check for any usernames with the domain is within SQL and your login accounts within SQL. These should also be in the form of somedomainusername (without the .org).

Once all of this was done, my SSP properly provisioned, however, I was still getting Error Events 7888 in the event viewer. To eliminate these errors from occurring every minute, I had to delete the SSP and recreate it and everything worked fine. The only other “hitch” was deleting the SSP since it was my only one. It is possible to delete it using stsadm.exe –o deletessp. After you run it you will get an error, simply run the exact same command a second time and your SSP will be deleted. You should be all set to create a new SSP without any errors.

If I’ve forgotten any places where the users need to be changed or anything else relating to this error, feel free to let me know or post a comment.