SharePoint 2010 - Configurare User Profile Service Application
Il file PDF dell'articolo è disponibile UPA Sharepoint 2010.pdf
Pare che la configurazione della User Profile Service Application sia uno dei problemi più frequenti che chi installa SharePoint 2010 Server trovi sulla sua strada, soprattutto nella sua funzionalità principale, la User Profile Synchronization. Lo scopo di questo articolo è quindi quello di chiarire le modalità di configurazione e dare anche una descrizione dell’architettura che sta dietro a questa Service Application.
Come ben sapete (o dovreste almeno aver sentito in giro) SharePoint 2010 ha rivoluzionato l’architettura dei servizi applicativi precedente (quella basata sugli Shared Service Provider SSP) reinventandola quasi da zero. In pratica ogni Service Application è un oggetto indipendente, multi istanza (ovvero si possono avere più istanze in esecuzione nella stessa farm) e che mette a disposizione i propri servizi indipendentemente dalla farm SharePoint in cui è fisicamente installata. Nel caso di User Profile Service Application (UPA in seguito) essa quindi è completamente autonoma rispetto al servizio di Search/Indicizzazione ma nel contempo dipende dal nuovo servizio di gestione delle identità di Microsoft, ForeFront Identity Manager per le operazioni di sincronizzazione con Active Directory. Non va trascurato anche il fatto che ogni istanza di UPA configurata nella ns. farm ha sempre TRE database SQLServer.
Veniamo ora a queli che sarebbero i passi essenziali per avere una istanza UPA completamente funzionante.
1. Effettuare il provisioning di una UPA attraverso il Wizard di configurazione della Farm oppure tramite la funzione di Gestione dei servizi della Central Administration di SharePoint.
2. Avviare “User Profile Synchronization Service” nell’istanza di UPA attivata nel passo precedente.
3. Nella pagina di gestione dei profili della Service Application creare una nuova connessione (Sync Connection)
4. Avviare una sincronizzazione completa.
Sono proprio i passi 3 e 4 che spesso non è possibile portare a termine con successo. I motivi possono essere molti, quasi tutti riconducibili ad una carente attività di pianificazione dell’installazione di SharePoint stesso e di una non accurata lettura della (quasi inesistente J ) documentazioni specifica.
Procediamo quindi alla demistificazione della cattiva fama che UPA si è guadagnata in questi mesi.
La prima cosa da tenere in mente è che la creazione di una connessione di sincronizzazione e l’esecuzione della stessa richiedono autorizzazioni specifiche: in fin dei conti si sta accedendo a sistemi che potrebbero essere fuori dal dominio di gestione dell’account con cui amministrate la farm SharePoint.
Importante prima di iniziare: User Profile Synchronization non funziona in una installazione a server singolo non a dominio con il database SQLServer built-in. Anche perché non avrebbe senso.
Forefront Identity Manage (FIM), conosciuto anche come Microsoft Identity Integration Server (MIIS) è usato per facilitare la sincronizzazione fra servizi che agiscono sugli oggetti che identificano utenti e gruppi. Nel nostro caso specifico FIM è il tramite per il quale UPA ed Active Directory le informazioni relative ai profili utente vengono scambiate e sincronizzate. E' pacifico che senza un FIM funzionante UPA non potrà mai accedere ad Active Directory. I componenti di FIM vengono installati dal setup di SharePoint 2010 qualora essi non siano già presenti. Attenzione, vengono installati ma non vengono benchè minimamente configurati. Sarete voi a doverli configurare.
Si è accennato al fatto che ogni istanza di UPA utilizzata tre databases SQLServer. Uno di questi è il Sync database. FIM utilizza il Sync Database per memorizzare i suoi dati. In definitiva FIM è composto dai seguenti elementi:
1. Due Windows Services
- Forefront Identity Manager Service
- Forefront Identity Manager Synchronization Service
2. Sync database (SQL)
3. Il MIIS Client.exe usato per monitorare lo stato delle operazioni di sincronizzazione
4. I files di FIM incluso il MIIS Client tool si trovano di default in questo percorso
C:\program Files\Microsoft Office Servers\14.0\Synchronization Service
Nota: NON PROVATE MAI AD AVVIARE I DUE SERVIZI MANUALMENTE.
Un UPA (User Profile Service Application) possiede diversi componenti fra i quali i seguenti che rivestono un ruolo fondamentale:
· 3 databases SQL (Social, Profile, Sync)
· Una Admin Page (ManageUserProfileServiceApplication.aspx)
· Un "User Profile Service Application" Proxy
· 2 SharePoint Services (User Profile Service e User Profile Synchronization Service)
Nota: questi servizi si trovano in Central Admin\System Settings\Manage Services della Central Admin della farm.
Siamo in uno dei punti fondamentali che spesso non vengono considerati e che portano inevitabilmente al fallimento della configurazione a meno che non utilizziate, contravvenendo a tutte le best practices possibili immaginabili l'account del primo amministratore di Dominio.
Per fare le cose a modo occorrerebbe in primo luogo definire DUE account ognuno con il suo specifico insieme di permessi :
1. User Profile Sync account
2. Directory Sync account
Questo account è responsabilie della creazione e dell'esecuzione del servizio . Con questo account vengono eseguiti anche i due servizi FIM. Questo account richiede i seguenti permessi per le operazioni di provisioning:
- Farm Administrator Account (timer service account)
- Local Admin del server su cui gira UPA
- Avere un profilo utente dell'account sul server in cui effettuate il provisioning. Meglio ancora fare l'operazione di provisioning con questo account.
- Membro del gruppo Pre-Windows 2k compatibility group
Il Directory Sync Account (dirsync) è responsabile delle operazioni di autenticazione\enumerazione verso i server Active Directory (AD) al fine di effettuare le operazioni di sincronizzazione. Anche questo account richiede dei permessi specifici verso i servers AD per leggere dalla struttura AD e qualche volta scriverci anche. Nell'esemplificazione che segue considereremo la sincronizzazione verso AD perchè è quella più comune, in realtà UPA/FIM possono interagire con molti altri sistemi di directory, ma per ora non complichiamoci troppo la vita e rimaniamo con i problemi noti. Una premessa prima di tutto: la vostra infrastruttura AD deve funzionare, il che non è cosi frequente come dovrebbe essere.
L'account DirSync viene indicato nella pagina di crezione della connessione di sincronizzazione ed i permessi richiesti variano a seconda di quale naming convention abbiamo usato per denominare la nostra AD e dalle direzioni di sincronizzazione che intendiamo usare. Possiamo sintetizzarli in questo modo:
a. AD Domain netbios name uguale al nome FQDN dell'AD domain
b. AD Domain netbios name differente dal nome FQDN dell'AD domain
c. Sync da AD verso SharePoint - Sync da SharePoint verso AD
In primo luogo definiamo cosa si intende per differente: si intentede differente quando il nome netbios del dominio è differente dalla prima porzione partendo da sinistra del none FQDN del dominio AD. Esempio nome netbios è contosouno e nome FQDN dominiouno.contoso.local sono nomi di domini AD differenti per UPA, mentre contoso e contoso.local sono uguali.
Permission requirements: AD Domain netbios name uguale al nome FQDN dell'AD domain
Questo è lo scenario più semplice ed in teoria nulla dovrebbe esser fatto oltre al garantire all'account il permesso di "replicate directory changes". In una struttura con dominio root e dei child domain occorrerà garantire all'account DirSync il permesso "replicate directory changes" anche nei child domain. Se gli account da sincronizzare esistono solo nei child domain il DirSync account non necessita di permessi nel root domain.
Ricapitolando quindi in questo caso il permesso da fornire al DirSync account è:
- Replicate directory changes in ogni dominio AD coinvolto il lettura
Per maggiori info
How to grant the "Replicating Directory Changes" permission for the Microsoft Metadirectory Services ADMA service account
Permission requirements: AD Domain netbios name diverso dal nome FQDN dell'AD domain
E' probabilmente il più diffuso in domini migrati da NT 4.0 ed anche il più propenso a fallire. Quando ci si trova in questo contesto di Naming Context (NC) occorre compiere i seguenti passi
1. Abilitare la property NetBiosDomainNamesEnabled a true (vero) per l'istanza di UPA
2. Garantire il permesso Replicate Directory Changes all'account usato da UPA in ogni import Domain NC
3. Garantire il permesso Replicate Directory Changes all'account usato da UPA nel Config Domain NC
Ovviamente se il vs. dominio è uno solo Import Domain e Config Domain sono la stessa cosa. Il Config Domain è quello dove è attestata la Vs. UPA.
NetBiosDomainNamesEnabled è una proprietà che è impostata in ogni istanza di UPA. Per default il suo valore è impostato a "false" quindi questo significa che deve essere cambiato in "true" nello scenario corrente. PowerShell può essere usato per modificarne il valore: vediamo come.
1.) Get-SPServiceApplication
a. Questo comando mostra in output tutte i service application riportandone l'ID univoco (GUID). Identifichiamo quello della UPA che ci interessa
2.) $var = Get-SPServiceApplication –Identity
3.) $var.NetBiosDomainNamesEnabled = “True”
4.) $var.update()
4.) $var.NetBiosDomainNamesEnabled
Nota: l'ultimo comando serve a visualizzare il valore della proprietà per verificare che sia stato impostato correttamente
7.) Per utilizzare il nome Netbios del dominio occorre obbligatoriamente creare una nuova connessione: NON PENSATE di usare una connessione esistente perchè NON FUNZIONERA'. Per creare una nuova connessione tramite la UI della Central Admin seguite questo percorso:
Central Admin\Application Management\Manage Service Applications\User Profile Service Application\Configure Synchronization Connections
Per il Domain NC: usate la stessa proceduta descritta in "Permission requirements: AD Domain netbios name uguale al nome FQDN dell'AD domain"
Per il Dominio Config NC:
1. Avviate ADSI Edit
2. Right click ADSI Edit e clicckate "connect to"
3. Quindi in "Connection Point" scegliete “Select a well known Naming Context”, quindi "Configuration" and poi OK:
4. Espandete Configuration object e click con tasto destro - proprietà nel configuration container che dovrebbe essere nel formato DN simile al seguente:
CN=Configuration, DC=Contoso,DC=com
5. Selezionate la Security Tab e quindi aggiungete l'account usato da UPA per il DirSync e assegnate ad esso il permesso di Replicate Directory Changes (This object only)
Per esempio Bill è il dir sync account:
6. Click OK
Note: OVVIAMENTE l'account usato per accedere al Config NC via ADSI Edit DEVE membro del gruppo Enterprise Administrators.
Siccome nel mondo reale e soprattutto nelle organizzazioni medio-grandi chi gestisce SharePoint spesso NON è chi gestisce l'infrastruttura AD e dato che spesso in queste realtà chi gestisce l'infrastruttura AD non sa realmente come funziona AD alcune risposte a domande o situazioni comuni.
D. Il nome netbios del mio dominio AD è diverso da quello FQDN. Il mio AD Admin si rifiuta di garantire il permesso di replicating directory changes senza una spiegazione.
R.Avete due strade: se è stato lui a fare il pastrocchio dei nomi diversi senza che il dominio AD venga da una migrazione NT 4.0 potete ricattarlo e soggiogarlo al vostro volere minacciando di rivelare l'identita dell'autore del pastrocchio. Seriamente parlando spiegategli che si tratta di un permesso che abilita la sola lettura e giammai abilita la scrittura del Configuration NC, spiegandogli che la cosa occorre proprio per questo "disallineamento" fra nome Netbios ed FQND del Dominio AD (e che quindi è colpa sua :-)....)
D. Il nome netbios del mio dominio AD è diverso da quello FQDN. Il mio AD Admin si rifiuta di garantire il permesso di replicating directory changes nel Config NC nonostante gli abbia spiegato cosa faccia. L'account usato per il DirSync ha solo il permesso sul Dominio NC. Sembra che tutto funzioni, potrò vedere tutti i profili dei miei utenti in SharePoint dopo un full sync?
R. La mancanza dei permessi richiesti nel Config NC non significa che non funzionerà niente. Il problema è che ci sarà come risultato indesiderato il fatto che il SAM account name mostrerà solo la prima parte del nome del dominio FQDN in luogo del nome netbios del dominio. Questo può avere delle implicazioni che non possono essere previste, è questo il motivo per cui ufficialmente Microsoft non supporta questa configurazione.
D. Il nome netbios del mio dominio AD è diverso da quello FQDN. Come posso verificare che il permessi siano stati impostati in maniera corretta nel Config NC per l'account usato dal DirSync dopo una sincronizzazione completa?
A. Questa domanda implica che chi la fa non ha accesso ad AD/ADSI edit per validare che il DirSync account abbia i giusti permessi. Questo accade tipicamente quando voi non siete Enterprise Admin o avete la delega per farlo. Non disperate potete usare due metodi per verificare che i permessi siano corretti:
1. Andate nella Central Admin\Application Management\Manage Service Applications\User Profile Service Application Management page\Manage User Profiles e cercate il nome netbios del dominio e verificate che tutti i profili utente appaiano.
2. Con SQLServer Management Studio aprite il database SQLServer "User Profile...." usato dall'istanza di UPA (usate magari l'account dell'application pool con cui gira la Central Admin...) e nella tabella "UserProfile_Full" e verificate che ci siano delle righe in cui la colonna "NT" mostri il nome del Dominio NC.
Questo è uno dei maggiori cambiamenti in SharePoint 2010 relativamente alla sincronizzazione utenti: ora potete sincronizzare i dati nei due versi. Non solo potete sincronizzare i profili utente in SharePoint da quelli in AD ma anche il contrario. E questo già fa immaginare i Sysadmin AD che affilano le accette e lucidano le mazze ferrate... Per la sincronizzazione da AD verso SharePoint sono sufficienti i permessi che abbiamo visto sinora, per fare il contrario (SharePoint verso AD) occorre che l'account di DirSync usato da UPA possa SCRIVERE in AD. In primo luogo tranquillizzo i SysAdmin AD: non dovete far diventare quell'account Enterprise Admin ne dargli i diritti di scrittura nel Config NC (se p diverso dal/i Domain NC). I permessi aggiunti che occorre assegnare al ns. account affinchè possa scrivere nel Domain NC sono questi:
· Create all child objects (This object and all descendants) in ognuno degli export Domain NC
· Write (This object and all descendants) in ognuno degli export Domain NC
Per verificare che i permessi di sincronizzazione siano corretti possiamo SOLO e SOLO ORA fare il provisioning del servizio UPA, cosa che invece molti presi dalla frenesia di installazione di SharePoint fanno come prima cosa appena finita l'installazione della prima macchina della farm....
Quindi con calma e dopo aver riverificato TUTTI i punti precedenti possiamo iniziare la sequenza di provisionig:
1.) Provisioning di una istanza di UPA sia il "Farm Configuration Wizard" (comodo ma con i nomi dei DB SQL farciti di scomodi GUID) oppure tramite la pagina "Manage Service Application" nella Central Admin.
2.) Avviare il servizio "User Profile Synchronization Service" in "Central Administrator\System Settings\Manage services on server"
2.a) Pregare :-)
Nota: Questo configura i due famigerati servizi FIM
3.) Nella pagina "Manage Profile" create una nuova Sync Connection
4.) Fate partire un full sync
Non illudetevi, un altro milione di cose potrebbe andare storto. Vediamo come capire se tutto ha funzionato prestando attenzione soprattutto ai passi 2 e 3 nella prossima sezione.
Dopo che UPA è stato configurato e (forse) avviato, lo stato del servizio "User Profile Sync Service" deve risultare avviato affinche UPA possa effettuare le operazioni di sincronizzazione. Come detto precedentemente è la configurazione e l'avvio dei due Windows services FIM che determina il corretto funzionamento del tutto. Solo se questi due servizi risultano avviati (started) si può dire che (forse) la configurazione di UPA è corretta e funzionante.
1.) I due servizi debbono essere in stato started nella Central Admin
2.) I due windows Services FIM service e FIM Sync service risultino avviati (Management Console Services)
3.) Soprattutto la pagina Timerjob status page sempre nella Central Admin di SharePoint deve mostare "success"
In parecchi casi, la maggior parte delle volte per mancaza dei permessi giusti, lo User Profile Synchronization Service si blocca nello stato Starting in maniera perpetua. Dovete con pazienza iniziare una sessione di monitoraggio dei log usando l'ULS Log Viewer (http://code.msdn.microsoft.com/ULSViewer).
Usando l'USL Viewer potete filtrare usando come categoria "User Profile"
Un modo di stabile che una Sync Connection sia valida, oltre a quello che ci dice la Central Admin è quello di usare il MIIS tool e verificare che sia presente un terzo agent di gestione (MA) sia presente.
Spero che queste poche righe vi siano state utili per configurare con successo le istanze di UPA usate nelle vostre farm SharePoint 2010. Qualora continuiate a non riuscire nell'operazione vi consiglio di consultare queste preziose fonti
Spence Harbar Blog:
http://www.harbar.net/articles/sp2010ups.aspx
RussMax Blog:
http://blogs.msdn.com/b/russmax/
Microsoft Technet
http://technet.microsoft.com/en-us/library/ff182925(office.14).aspx
http://technet.microsoft.com/en-us/library/ee721049(office.14).aspx
Gabriele Del Giovine