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.org\username’ 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 somedomain.org (or .com, .info, .local, etc). So everywhere an account that is needed for SharePoint is entered, it must simply be somedomain\username (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 somedomain.org domain is within SQL and your login accounts within SQL. These should also be in the form of somedomain\username (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.
Finally!! Last night I downloaded my copy of PerformancePoint from MSDN. I’ve been working with a client all day and have work with them all day tomorrow implamenting SharePont, so unfortunately, I haven’t had a chance to install it yet. I also have other client engagements the beginning of next week, so hopefully this weekend or middle of the week next week I can get it installed and start playing.
The PerformancePoint RTM Evaluation version is available! Both the 32-bit version, download here, and the 64-bit version, download here, are available as a free download. In addition Microsoft has released some sample data as well as a hotfix for PerforancePoint to interact with ProClarity Analytics Server. I am still waiting for PerformacePoint to be released on MSDN as well as if the evaluation can be upgraded to a licensed version once it becomes available. I’ll continue to post as information becomes available. The latest I have seen is that it will be available on MSDN in “very early October”.
The other day I ran into a problem with email enabled lists in SharePoint. I set up SharePoint to allow incoming email. The company wanted the email in SharePoint to have the same domain as the rest of the email address for the company. We used SharePoint Directory Management Service and created a new OU to store all the email contacts. We set up the SMTP server name to be the SharePoint SMTP server and set the display address to be the companies email. However, when the user is created, the primary email address’s domain is the name of the SMTP server. This causes a problem in that AD won’t assign the company email domain to the contact using the recipient policies because it is the primary email in the recipient policy, which wouldn’t assign two primary email addresses to the contact. To solve the problem I wrote a simple PowerShell script to look at all the users and assign the email address to all the contacts in the OU that didn’t already have an email address of the set domain. The beginning of the script will allow you to set the domain, OU and domain of the email. You can either run the script manually whenever you want, or set it to run as a scheduled task.You also don’t need to run the script on your Exchange Server, or even have PowerShell running on your Exchange server, you can run it from whatever computer you wish as long as it has PowerShell installed and has access to write to the users in the OU on the Exchange Server. I ran it from my 64 bit Vista Machine without and problems.You can download the script here.
I ran into a goofy problem today that I’ve never seen before. I was installing ProClarity Analytics Server 6.3 and go the point where I had to enter the sa password to connect to SQL Server 2005. I had password that was a combination of symbols (% and $ to be exact), upper and lowercase letters and numbers. However, when ProClarity actually started the install process, it failed to create the database every single time, I tried different users, different security configurations, everything I could think of that would cause ProClarity to fail to create the database. The only thing I wasn’t changing was the password. Finally, I decide..maybe ProClarity is having problems with a character in my password. I changed the password to a dictionary word (I know…bad practice, but I was getting frustrated). What do you know?! It worked, so the lesson from today is that apparently ProClarity has problem interpreting either the % or the $ in the password for the sa account (or any account) when running the install. I know it can handle numbers and upper case letters as I have used those before in passwords. If I have some time I’ll do some more testing to figure out exactly which character it is and if the position of the character in the password has anything to do with it.
Well, I got CTP4 installed today. Overall it went fairly smoothly. The only difficulty I ran into was uninstalling CTP3 monitoring. It wouldn’t uninstall through add remove programs, so I ended up having to use Windows Installer Cleanup. This didn’t fully remove it, so once that was finished I deleted the monitoring entry out of the windows registry as well as delete the left over monitoring folder from the Program Files directory. The last thing I had to do was to delete the PPSMonitoring database (simple so I could use the same name again). Once this was done, CTP4 Monitoring Server installed without any problem. The biggest visual difference was in the Dashboard Designer. I’ll post some screen shots of the new Designer tomorrow sometime.
As of tonight PerformancePoint CTP4 is officially available on Microsoft Connect. I’m in the process of downloading it right now and hope to have the bits installed on a test server tomorrow morning.
Today I ran into a problem working on a demo for PerformancePoint, I wanted to extend my original web application in SharePoint (one web application for internal access and one web application for external access). However, it doesn’t appear that this plays very well with PerformancePoint pages published up to SharePoint. I think I may be able to solve it using ISA Server or another reverse proxy, however I don’t currently have one in place to play with. I’m heading to Chicago on Tuesday for a two day PerformancePoint training on Analysis and Monitoring at Microsoft so maybe I can get some answers then. If anyone has any input or advice I would love to hear it and I will continue to update my blog as I work through this issue.
Categories: Uncategorized Tags: