This may happen…..or may not and work perfectly.
The new service pack consists of two executable files which run in sequence: WSSv3 SP1 and then MOSS SP1.
If the Service Pack doesn’t work, the upgrade will claim that it was complete, however, the upgrade may have actually crashed halfway through the WSSv3 SP1 portion of the operation, leaving half of the databases updated and the other half (the content and SSP databases) not updated. The result is the content databases are locked, and the SharePoint services were hung up in a loop. In short – If this occurs, you have a problem. Feel free to email me for details.
Resolution: To fix everything, run a series of stsadm commands to force the upgrade, because the GUI-based commands will not respond and the service pack will claim that it was already installed. Then get all of the timer jobs to start running again. This should do it.
Not that this is a SharePoint bug blog. However I think I’d mention this and add this as a category on my blog
If you change the names or delete them in AD, they are still shown in SharePoint.
One small portion of the site, which is ambiguously considered a web part by some sources, is called “Select Users and Groups” or the “People Picker”. This web part/service is available throughout different portions of a site collection for the purpose of doing a lookup query for users or groups. It is also implemented differently in different portions of the site, because the same lookup query will bring back different result sets depending in which portion of the site collection you initiate it from. For the implementation of the “People Picker” that we are concerned with, when the lookup is performed, the web part looks at the Shared Services Provider database (where it scans imported profiles and groups) and also directly at Active Directory. Regarding the Active Directory query, there is no issue.
However, regarding the database where imported user profiles are stored, while the user profiles that it retrieves are up to date, it is also bringing back security groups that have been deleted or renamed in its result set. According to multiple sources including Microsoft, security groups are imported along with user profiles. This seems to hold true considering that a recently created security group is not visible to certain portions in SharePoint (audiences for example) until a full profile import is done through the SSP. However, according to different documentation regarding SharePoint Server 2007, the literature claims that security groups are not imported via the SSP profile import service; they are only directly queried from Active Directory. Nonetheless, these groups do exist inside the Shared Services Provider database, as I have managed to drill down to the actual table in which these values seemingly reside: dbo.MemberGroup.
Of course Microsoft may or may get back to you on this, and I can’t promise that in the end this will indeed resolve the issue in the next issue.