Meer dan eens lopen klanten van ons tegen problemen aan met profielinformatie die niet up to date is binnen de farm of delen van de farm. Ook zitten beheerders met hun handen in het haar omdat ze maar niet begrijpen waar alle events gerelateerd aan profile synchronisatie vandaan komen, wat soms tot knalrode eventlogs leidt. Eerlijk gezegd snapte ik tot zojuist ook niet helemaal hoe de vork in de steel zat, vandaar ook deze post. Hierin ga ik redelijk indepth uit de doeken doen hoe profile synchronisatie precies werkt en hoe veel voorkomende problemen op te lossen en te voorkomen.
Huh.. Hoe? Wat?
Om te beginnen wat is profile synchronisatie precies?
In het kort: Profile synchronisatie zorgt voor het 'in sync' houden van MOSS profiel informatie op de afzonderlijke WSS profielen binnen een contentdatabase, en het 'in sync' houden van site membership informatie in de MOSS profielen.
Zoals velen van jullie weten, hebben we in Sharepoint profielen. Wat velen alleen niet weten is dat we twee afzonderlijke profielen hebben. We hebben namelijk profielen in Windows Sharepoint Services, maar ook in Sharepoint Server 2007 en dat zijn verschillende features. Om een consistente weergave te hebben van deze beiden profielen, moeten we dus synchroniseren.
WSS profielen
WSS profielen kan je vinden onder Welcome User > My Settings. De informatie hieruit wordt bijvoorbeeld gebruikt in People and Groups.
Een WSS profiel vind je op elke afzonderlijke site collectie. Elke site collectie heeft dus een ander WSS profiel voor een specifieke gebruiker. Onderstaand voorbeeld laat vergelijking zien tussen een site zien binnen een site collectie, waar ik net als gebruiker ben toegevoegd, en een site, waar ik al een tijdje lid van ben, en waar profile synchronisatie extra informatie heeft toegevoegd:
Ondanks dat deze site collecties in dezelfde content database zitten, gebruiken ze toch andere informatie. Elke site in de site collectie deelt een verborgen list, de User Information List, waarin profiel gegevens zijn opgeslagen. Je kunt deze informatie vinden als je browset naar http://urlwebapp/managedpath/sitecollectieroot/_catalogs/users, en wanneer je in de AllUserData table van een content database zoekt op tp_ContentType = 'Person':
AllUserData bevat alle informatie over items in alle lists binnen de alle sites in de content database. Zo zie je maar dat profiel informatie gewoon een item is in de verborgen User Information List.
MOSS Profielen en site memberships
MOSS profielen zijn de profielen die geïmporteerd worden vanuit een profielenbron. Dit is in de meeste gevallen Active Directory, maar dat kan ook een andere LDAP database zijn of zelfs een willekeurig systeem ontsloten via Business Data Catalog. De informatie die opgehaald wordt, wordt vervolgens weggeschreven in de profilestore, een verzameling tables in de SSP database (dbo.UserProfileFull en dbo.UserProfileValue bevatten het gros van de profielinformatie). Deze informatie wordt getoond, wanneer je een MySite bezoekt of wanneer je browset naar Shared Services Administration > User Profile and Properties > View User Profiles.
Een MOSS profiel bevat een publiek deel en een persoonlijk deel.
Als beheerder kan je aangeven welke properties getoond worden in het Details overzicht op het publieke deel van een MOSS Profile. Je kan als eindgebruiker bepaalde properties wijzigen. Welke dat zijn, is op te geven door de beheerder. Hierbij dient alleen rekening gehouden te worden dat, wanneer een property gemapped is aan een property in de profielenbron, deze overschreven worden bij de volgende import. Terugschrijven naar de profielenbron is in deze versie van Sharepoint nog niet mogelijk.
Een belangrijk onderdeel van een MOSS profiel zijn de site memberships. Deze zijn alleen zichtbaar voor jezelf en alle farm admins. Site memberships bevat een overzicht met sites waar je lid bent van een de Members sharepoint group. Andere groups zoals Visitors, Owners enz. komen niet voor in dit overzicht. Deze informatie wordt vervolgens gebruikt in het MOSS profiel om een overzicht te tonen, maar ook om het mogelijk te maken alle bestanden die je als gebruiker hebt geupload naar 1 van deze sites centraal terug te vinden. Erg handig dus!
Een andere handige functionaliteit is dat, waar je je ook bevindt in de structuur van je portal, je altijd snel naar 1 van je sites kan browsen door My Links > My Sharepoint Sites in de topbar.
Deze membershipinformatie is niet beschikbaar bij de initiële import van het profiel. Sterker nog, je kan natuurlijk allang member zijn van een site, zonder ook maar een MOSS profiel te hebben. Deze informatie moet dus ook gesynchroniseerd worden vanuit de afzonderlijke site collecties naar de profilestore. Membership informatie uit deze store, en ook informatie over My Colleagues en eigen toevoegingen op My Links, is terug te vinden met de volgende SQL query (Je weet dat het unsupported is om SQL queries te draaien tegen productiesystemen heh? J )
declare @RecordId int select @RecordId = RecordId
from dbo.UserProfile_Full
where NTName = 'HOME\Mark'
exec dbo.QuickLinksRetrieveAllItems @RecordId,@ViewerItemSecurity=31,@RequestedItemSecurity=16
Deze stored procedure haalt informatie uit de dbo.UserMemberships, dbo.UserLinks en dbo.UserColleagues tabellen op. Het mag zich raden welke informatie waar staat.
Onder water.
Goed… Genoeg over de basics. Laten we het nu over het echte werk gaan hebben. Hoe zorgen we nu dat we een synchronisatieslag kunnen maken tussen wat er in de profilestore staat en wat er in de contentdatabase staat?
Profile synchronisatie in Sharepoint is een samenspel van een 3tal componenten, te weten:
- Een tweetal timerjobs.
- Een set stored procedures op de Content database.
- Een set stored procedures op de SSP database.
Zoals nagenoeg elke periodieke administratieve afhandeling binnen Sharepoint gaat profile synchronisatie via timerjobs, te weten de Profile Synchronization en Quick Profile Synchronization. Standaard draaien deze om respectievelijk het uur en de minuut. De normale job zorgt voor een volledige synchronisatie van informatie en verzorgd dat alle wijzigingen, toevoegingen en verwijderingen sinds de laatste job worden afgehandeld. De Quick job zorgt voor het synchroniseren van alleen nieuwe toevoegingen. Dus als ik mezelf lid maak van een site, wordt bij een Quick job mijn WSS profiel geupdate, maar dat van anderen op dat moment niet.
Bij het aanmaken van een web applicatie of SSP, wordt er een job definitie aangemaakt voor beide jobs:
Wanneer het tijd is om de job af te vuren, zal de Timer Service van een willekeurige server in de farm de jobs uitvoeren. De timerservice gebruikt vervolgens een set verschillende stored procedures op de content databases en SSP database om de synchronisatie te doorlopen. Op de content databases zijn er geen specifieke profiel synchronisatie stored procedures, omdat profiel synchronisatie een MOSS feature is en de content database een object is dat ook bestaat in de WSS wereld. De stored procedures waaraan ik refereer zijn bedoeld om informatie over de WSS profielen uit te kunnen lezen en te kunnen updaten. Op de SSP database zijn wel een set speciaal geschreven stored procedures aanwezig. Deze worden gebruikt om informatie over de synchronisaties bij te houden om ervoor te zorgen dat alleen wijzigingen doorgevoerd worden. Verder zorgen deze ervoor dat profiel informatie (membership info) bijgewerkt wordt.
Een volledig overzicht over de internals van deze stored procedures is terug te vinden in de Protocol specificaties op MSDN:
[MS-WSSDLIM]: Windows SharePoint Services: Content Database Document and List Item Management Communications Protocol Specification
http://msdn.microsoft.com/en-us/library/cc313081.aspx
[MS-UPSSYNC]: User Profile Synchronization Stored Procedures Protocol Specification
http://msdn.microsoft.com/en-us/library/cc313167.aspx
High level ziet een synchronisatie (niet Quick) er als volgt uit:
Gedurende profile synchronisatie hebben we 3 stadia waarin de sync plaats vindt, namelijk:
- Content DB Synchronisatie
- Profile Synchronisatie
- Membership Synchronisatie
Deze stadia overgangen zijn voor het synchronisatie mechanisme om voortgang bij te houden. Gedurende elk stadia wordt er op verschillende plekken voortgang bijgehouden in tijdelijke in-memory tables (Staging data), maar ook in tabellen in SQL (bijv. dbo.ContentDBSync en dbo.SiteSync, waar we later nog op terug komen J). Ook worden er hier en daar extra checks gedaan om consistentie te bewaren. Om het overzichtelijk te houden heb ik het iets abstracter gemaakt en dergelijke checks en status updates weggelaten. Onthoud dat elk stadia dus een eigen werkgebied heeft in het geheugen of database. Terugkomend op mijn visualisatie, gebeurt er in grote lijnen het volgende:
- Bij aanvang van de synchronisatie vraagt de timerservice de contentdb sync informatie op bij de SSP. Deze gegevens bevatten informatie over de laatste synchronisatieslag voor deze specifieke content database.
- De SSP geeft de informatie terug indien aanwezig. Het belangrijkste daarbij is het Database Changetoken, wat een timestamp is van de laatste succesvolle synchronisatieslag. Wanneer de content database geen sync informatie heeft in de SSP database, wordt dat op dat moment aangemaakt in de dbo.ContentDBSync tabel. Deze sync informatie bevat naast het changetoken ook gegevens over de status van de content database gerelateerd aan profile synchronisatie.
- De timerservice zal vervolgens op basis van de Database Changetoken de changelogs van de content database afspeuren naar nieuwe sites.
- De gegevens bevatten GUIDS van de afzonderlijke sites, de site collectie waartoe ze behoren en de contentdatabase waarin ze te vinden zijn.
- De nieuwe sites worden geregistreerd bij de SSP in de dbo.SiteSync tabel. Deze sync informatie bevat net als bij de content database sync informatie, gegevens over de status van de site met betrekking tot profile synchronisatie, waar een Site Changetoken een deel van is.
- De timerservice zal vervolgens een overzicht van sites, die in de synchronisatie meegenomen moeten worden, ophalen bij de SSP. Dit is een overzicht van alle sites in de content database met bijhorende Site Changetokens. Dit is een gedeeltelijke resultset. Stap 6 t/m 12 worden iteratief uitgevoerd totdat alle sites zijn verwerkt.
- Vervolgens zal de timerservice een overzicht van alle gewijzigde profielen op basis van de Database Changetoken opvragen. Dit is eveneens een gedeeltelijke resultset. Stap 7 t/m 12 worden iteratief uitgevoerd totdat alle profielen zijn verwerkt. Dit maakt het ook mogelijk nieuwe profielen te registreren op basis van nieuw gevonden ACLs (dus ook nieuwe WSS profielen).
- De gewijzigde profielen bevatten dus de MOSS profiel informatie uit de SSP profilestore (dbo.UserProfileFull en dbo.UserProfileValue voornamelijk). Alleen gegevens over MOSS profielen die een WSS profiel wederhelft hebben worden teruggegeven. Een profiel moet eerst geregistreerd zijn voor synchronisatie.
- De informatie wordt vervolgens gebruikt om de WSS profielen in de User Information Lists bij te werken via de List stored procedures. De informatie is opgeslagen in de dbo.AllUserData tabel in de content database, waar alle items voor elke list in elke site binnen de content database te vinden is.
- Gedurende het bijwerken van de User Information Lists worden meteen alle nieuwe ACLs voor de sites opgevraagd op basis van de Site Changetoken.
- De ACLs bevatten informatie over de site, site collectie, content database, group Ids en gebruikers Ids (SIDS), welke in de SSP geregistreerd worden.
- Op basis van deze ACLs worden voor alle gebruikers die lid zijn geworden van een Site Members groep, of waar lidmaatschappen zijn verwijderd, het profiel bijgewerkt met Site Membership informatie (dbo.UserMemberships).
- Op basis van de ACLs wordt er ook bepaald of er nieuwe profielen zijn waarvoor synchronisatie moet worden gestart. Deze worden geregistreerd.
Als nu alle sites en profielen zijn verwerkt stopt het Synchronisatie proces.
Nu het proces klaar is, bevatten alle WSS profielen up to date informatie op basis van de MOSS profielen en zijn site memberships op de MOSS profielen bijgewerkt. Tenminste als alles goed gaat J. Er kan namelijk wel eens wat mis gaan.
Crap… iets is er niet in de haak!
Profile Synchronisatie is een proces waar redelijk wat verkeerd kan gaan. Er zijn in principe twee veel voorkomende probleem scenario's:
- Profile synchronisatie voor sites / content databases is gestopt zonder dat daarvan melding gemaakt wordt.
- Errors betreffende het niet kunnen synchroniseren van sites in eventlog en tracelog.
Wanneer profile synchronisatie is gestopt voor sites/content databases zonder aanduidbare reden, dan is de kans groot dat iemand content databases of sites uit de synchronisatie heeft gehaald door de preparetomove stsadm operatie te draaien. Preparetomove werd voor de Infrastructure Update gebruikt om ervoor te zorgen dat, wanneer een content database detached werd van de farm en later weer werd attached, Sharepoint op de hoogte was van dit feit omdat voor IU de database GUIDS wijzigden bij het attachen. Hetzelfde gold voor het verplaatsen van sites binnen de farm. In de dbo.SiteSync table van de SSP database werd bij het gebruik van preparetomove een MOVING flag gezet, waarna profile synchronisatie stopt voor die content database of site, totdat deze opnieuw werden aangetroffen met een andere GUID.
Na Infrastructure Update wijzigen de GUIDS niet meer, waardoor site collecties die de MOVING = 'True' flag hebben, nooit meer meegenomen worden in de profile synchronisatie. Profile Synchronisatie wacht namelijk totdat de site collecties worden gevonden met een nieuwe GUID. Om deze reden moet dit commando niet meer gebruikt worden (http://blogs.msdn.com/toddca/archive/2009/01/30/preparetomove-away-from-running-this-command.aspx).
Gelukkig kan je nog altijd terug, wanneer je het commando gedraaid hebt. Het is kwestie van het commando draaien met de –undo parameter (http://technet.microsoft.com/en-us/library/cc262122.aspx).
Voorbeeld:
- Gebruik de volgende SQL query om erachter te komen welke site collecties de MOVING status hebben:
USE SSP1_DB
SELECT ss.LastSynch, ss.ChangeToken, ss.SchemaVersion, ss.LastChangeSynchSuccess,
ss.Moving, ss.MovingDeleted, ss.Registered, so.Name AS db, so2.Name AS webapp,sm.Path FROM dbo.SiteSynch ss
JOIN SharePoint_Config.dbo.SiteMap sm ON ss.SiteID = sm.ID
JOIN SharePoint_Config.dbo.Objects so ON sm.ApplicationId = so.Id
JOIN SharePoint_Config.dbo.Objects so2 ON sm.DatabaseId = so2.Id
- Gebruik respectievelijk stsadm –o preparetomove –site <siteurl> -undo en stsadm –o preparetomove –contentdb <dbserver:dbnaam> -undo om voor een site collectie dan wel contentdatabase de MOVING status te verwijderen.
- Trigger de profile synchronisatie door de timerjob te resetten naar een rotatie van 1 minuut, gebruik makend van stsadm –o sync –synctiming M:1. Wacht vervolgens een minuut en reset de timing weer naar een rotatie van 1 uur door stsadm –o sync –synctiming H:1.
- De synchronisatie zou weer moeten starten voor die specifieke site collectie of database.
Wanneer tijdens profiel synchronisatie op een gegeven moment allerlei EVENT IDs in application log en ULS logs verschijnen (IDs 5555, 5553, en 7888) betreffende het niet kunnen synchroniseren van bepaalde objecten, dan heeft dit in de meeste gevallen als oorzaak dat site collecties of content databases zijn verplaatst (bijvoorbeeld na het gebruik van stsadm –o mergecontentdbs) . In de meeste gevallen is dit probleem vervolgens te verhelpen door de synchronisatie informatie voor de content databases die deze 'probleemsites' bevatten te resetten. Dit gaat als volgt:
- Gebruik het commando stsadm –o sync –listolddatabases x om een overzicht te genereren van alle databases die synchronisatie informatie bevatten die minimaal x dagen verouderd is. X moet bepaald worden aan de hand van de events in de eventlog. Het aantal dagen sinds het eerste event moet als waarde genomen worden.
- Vergelijk de output van het commando met de events in de application log en ULS logs. De output bevat database GUIDS, welke je kunt matchen met database GUIDS uit de events. Wanneer deze informatie overeen komt, plan dan buiten kantoortijden een paar uur maintenance in.
- Tijdens maintenance draai je vervolgens het commando stsadm –o sync –deleteolddatabases X om de profiel informatie te verwijderen.
- Trigger de profile synchronisatie door de timerjob te resetten naar een rotatie van 1 minuut, gebruik makend van stsadm –o sync –synctiming M:1. Wacht vervolgens een minuut en reset de timing weer naar een rotatie van 1 uur door stsadm –o sync –synctiming H:1.
- De synchronisatie zou weer moeten starten voor die database, en de events zouden verdwenen moet zijn uit de logs.
Wanneer er nog steeds errors voorkomen, dan kun je proberens stsadm -o sync -deleteolddatabases 0 te draaien. Dit verwijdert alle profiel informatie, waardoor ook site memberships niet meer beschikbaar zijn. Vandaar dus ook dat je deze commando's buiten kantoortijden moet draaien.
Er is 1 scenario waar het resetten van de sync informatie niet gaat werken, en dat is wanneer er twee site collecties zijn met WEBs (subsites) met dezelfde GUIDS. In deze gevallen blijf je 5553 errors houden:
Event Type: Error
Event Source: Office SharePoint Server
Event Category: User Profiles
Event ID: 5553
Date: 7/14/2009
Time: 5:01:08 AM
User: N/A
Computer: COMPUTERNAME
Description:
failure trying to synch site bd030447-46db-4bf4-9bc9-865b6b7fb293 for ContentDB 79eab52a-526c-4c7f-9adf-6c15a0b64a3b WebApp 1abfa921-6f2c-4d30-8e2e-1d807e5d060c. Exception message was Cannot insert duplicate key row in object 'dbo.UserMemberships' with unique index 'CX_UserMemberships_RecordId_MemberGroupId_SID'.
The statement has been terminated.
Duplicate GUIDS komen voor, wanneer je stsadm –o backup / -o restore gebruikt om een site collectie te restoren, terwijl de orginele site eveneens actief blijft. Bij de restore wijzigt weliswaar de site collectie GUID, maar niet alle GUIDS van objecten binnen de site collectie. Hier kan profile synchronisatie niet mee overweg. Nu zijn er verschillende artikelen die dan vervolgens als oplossing bieden om stsadm –o preparetomove –site <url> -oldcontentdb <GUID> te draaien. Dit biedt welliswaar een oplossing voor de events, maar hiermee introduceer je een nieuw probleem. Het enige wat je dan vervolgens doet is 1 van de twee actieve site collecties uit de profile synchronisatie houden. Nieuwe profielinformatie komt zo niet meer door naar die site collectie. Wanneer je dan vervolgens in de toekomst stadm –o deleteolddatabases 0 gebruikt, krijg je ook meteen de events weer terug. Oplossing voor dat specifieke probleem is dus om 1 van de 2 sites te verwijderen, dan wel de content de migreren naar een nieuwe site collectie.
Ik hoop dat profile synchronisatie nu iets duidelijker geworden is. Dit is eveneens een van mijn laatste 2007 blog posts. Vanaf vandaag zal ik mij voornamelijk gaan richten op 2010. Hou deze blog in de gaten!