Microsoft SharePoint 2010: Configurazione di servizi tra farm
È possibile configurare SharePoint per la comunicazione oltre i confini delle farm, per condividere e usufruire di servizi di altre server farm.
Shannon Bray
Microsoft ha apportato diversi miglioramenti in merito alla distribuzione e all'utilizzo di servizi SharePoint. In SharePoint 2007 i servizi venivano resi disponibili tramite il cosiddetto Provider di servizi condivisi (SSP). Sebbene SSP abbia rappresentato un notevole passo avanti rispetto a quanto disponibile in SharePoint 2003, poneva molte difficoltà.
Il problema principale con l'architettura di SharePoint 2007 consisteva nel fatto che rappresentava un tipo di configurazione "senza compromessi". Le applicazioni Web erano associate a un SSP specifico e non erano in grado di utilizzare i servizi in modo selettivo. Se ad esempio in SSP erano configurate le funzionalità di ricerca ed Excel Services, qualsiasi applicazione Web SharePoint che utilizzava il servizio di ricerca avanzato doveva comunque accedere a Excel Services.
Inoltre, l'architettura non era estendibile. Non era possibile creare servizi personalizzati utilizzando la stessa infrastruttura SSP. Infine, cosa più importante, era difficile configurare servizi tra farm in SharePoint 2007. La nuova architettura di servizi in SharePoint 2010 risolve tutti questi problemi.
Descrizione dell'architettura delle applicazioni di servizi
Prima di analizzare in dettaglio le procedure per consentire la comunicazione dei servizi tra le farm di SharePoint, è importante comprendere i componenti e i servizi che rendono possibile questa operazione. Ecco alcune caratteristiche principali dell'architettura delle applicazioni di servizi:
- È possibile utilizzare servizi in modo selettivo
- L'architettura dei servizi è estendibile
- I servizi sono supportati in SharePoint Foundation
- È possibile eseguire la scalabilità orizzontale dei servizi
- I servizi possono essere resilienti e ridondanti
- ·È possibile attuare la federazione dei servizi
A differenza dei servizi in SharePoint 2007, è ora possibile scegliere quali applicazioni Web SharePoint utilizzeranno i servizi. Non sarà più necessario associarle all'SSP specifico: è possibile scegliere le architetture appropriate.
L'architettura è ora estendibile, ovvero consente di creare servizi personalizzati. In questo modo sarà possibile risparmiare una grande quantità di tempo, denaro e risorse, poiché è possibile distribuire soluzioni personalizzate che possono operare in raccolte di siti o addirittura applicazioni Web SharePoint.
SharePoint 2010 non include alcun servizio integrato con SharePoint Foundation, ma l'infrastruttura è in grado di fornire il livello di supporto appropriato. È possibile creare servizi personalizzati e utilizzarli in SharePoint Foundation. La nuova architettura consente di espandere il carico tra più server per permettere alle progettazioni di gestire il carico appropriato.
Uno dei servizi più rinnovati è costituito dal servizio di ricerca avanzato. In SharePoint 2007 il server indice rappresentava un singolo punto di errore. In SharePoint 2010 i servizi di ricerca per indicizzazione possono essere utilizzati in vari server. Se si verifica un problema in un server, grazie alla ridondanza il sistema continuerà a funzionare nel modo previsto.
È inoltre possibile condividere servizi oltre i confini delle farm. In questo modo è possibile consolidare i servizi che si desidera condividere in un'unica farm, continuando comunque a distribuire servizi a un numero di consumatori.
Descrizione dei concetti principali
Il termine "applicazione di servizio" è piuttosto abusato, rendendo difficile per le persone capire dove si trovano i componenti e come funzionano. Per avere un'idea chiara di cosa accade dietro le quinte, è importante conoscere questi termini:
Servizio: file binari dell'applicazione distribuiti nei server all'interno della farm.
Istanza del computer di servizio: istanza effettiva del servizio in esecuzione nel server.
Applicazione di servizio: componente logico contenente la configurazione e la gestione del servizio, come le informazioni sull'applicazione e la stringa di connessione del database.
Proxy dell'applicazione di servizio: interfaccia utilizzata dai consumer di servizi per comunicare con il servizio e il bilanciamento del carico, in modo che sappiano quale server contattare e in che modo utilizzare il servizio effettivo. È importante notare che il proxy dell'applicazione di servizio non è un proxy di servizi Web o di Windows Communication Foundation (WCF).
Consumer di servizio: qualsiasi applicazione o servizio che utilizza il servizio.
Gruppi di proxy del servizio: gruppi di applicazioni di servizio associati a specifiche applicazioni Web.
È possibile distribuire servizi in vari modi, ad esempio tramite Configurazione guidata, Amministrazione centrale o Windows PowerShell. Con la Configurazione guidata vengono considerati molti servizi con i valori predefiniti. È sconsigliabile utilizzarla per gli ambienti di produzione. Per garantire un esito positivo è opportuno configurare manualmente molti servizi.
In Amministrazione centrale è possibile configurare diversi servizi popolando i campi a essi associati. Nelle situazioni in cui si dispone di un livello di controllo inferiore rispetto alla Configurazione guidata farm, la maggior parte dei professionisti di SharePoint opterà per Windows PowerShell.
Windows PowerShell offre un elevato livello di controllo sull'ambiente, ma può risultare insidioso configurare molte delle applicazioni di servizio. Per informazioni dettagliate su come eseguire il provisioning dei vari servizi SharePoint con Windows PowerShell, fare riferimento a "Automating SharePoint 2010 with Windows PowerShell 2.0" (Wiley, 2011) di Shannon Bray e Gary Lapointe.
In fase di configurazione delle farm di SharePoint, vengono creati automaticamente due servizi. Si tratta dei componenti chiave per il funzionamento dei servizi, tra cui:
- Servizio di individuazione applicazioni e bilanciamento del carico
- Applicazione del servizio token di sicurezza
Le applicazioni di servizio devono esporre un endpoint Web, poiché tutte le comunicazioni avvengono tramite HTTPS. È inoltre importante sapere che le applicazioni di servizio comunicano attraverso le porte TCP 32843 e 32844. Le applicazioni personalizzate utilizzano in genere la porta 32845.
Descrizione del funzionamento della federazione dei servizi
Dopo aver esaminato il modo in cui viene attuata la federazione dei servizi, passiamo ad analizzare quelli che supportano la federazione:
- Cerca
- Profili utente
- Metadati gestiti
- Servizi di integrazione applicativa (BCS)
- Archiviazione sicura
- Web Analytics
In una WAN sono supportati molti altri servizi, tra cui Ricerca, Metadati gestiti, Integrazione applicativa dei dati, Profilo utente e Archiviazione sicura. Nonostante siano tutti supportati, è consigliabile utilizzare solo Ricerca e Metadati gestiti.
In un ambiente WAN il servizio Ricerca registrerà un aumento di latenza in fase di indicizzazione. Nel caso di BCS si verificheranno alcuni rallentamenti iniziali prima della memorizzazione dei dati nella cache. Il servizio Profilo utente dispone di un motore di replica per i profili e pertanto è sconsigliabile utilizzarlo in un ambiente WAN. Se le applicazioni utilizzano l'archiviazione sicura, introducono latenza.
Farm di esempio
In questo esempio creeremo due farm. Una ospiterà i servizi aziendali, l'altra le applicazioni Web di gestione del contenuto. Creeremo entrambe dall'inizio e delineeremo ogni fase per illustrare in che modo attuare la federazione dei servizi in qualsiasi ambiente.
Entrambe le farm si troveranno nello stesso dominio, ma possono essere agevolmente create anche in vari domini. Poiché utilizzeremo lo stesso dominio per questi esempio, è possibile sviluppare la demo con quattro server: TechED-AD, TechED-SQL, TechEd-Services e TechEd-SP.
Iniziare creando gli account appropriati in Active Directory. Gli account sono descritti di seguito: spFarm, spServices, spContent, spCrawl, spUPS e spC2WTS. Per accelerare il processo, è possibile aggiungere account mediante Windows PowerShell da una delle quattro farm di SharePoint (per maggiori dettagli, vedere la Figura 1). È importante sottolineare che creeremo questi account nell'unità organizzativa degli account del servizio gestito. Se pertanto Windows Server 2008 R2 non è il sistema in uso, sarà necessario cambiare la posizione di CN negli script nella Figura 1.
Figura 1 Aggiunta di account SharePoint in Active Directory.
$domainName = $env:USERDOMAIN $LDAP = "LDAP://CN=Managed Service Accounts,DC=$domainName, DC=local" $objCN = [ADSI]$LDAP $objUser = $objCN.Create("user","CN=SharePoint Services") $objUser.Put("sAMAccountName","spServices") $objUser.Setinfo() $objUser.psbase.invokeset("AccountDisabled", "False") $objUser.SetPassword("pass@word1") $objUser.setinfo() $domainName = $env:USERDOMAIN $LDAP = "LDAP://CN=Managed Service Accounts,DC=$domainName, DC=local" $objCN = [ADSI]$LDAP $objUser = $objCN.Create("user","CN=SharePoint Content") $objUser.Put("sAMAccountName","spContent") $objUser.Setinfo() $objUser.psbase.invokeset("AccountDisabled", "False") $objUser.SetPassword("pass@word1") $objUser.setinfo() $domainName = $env:USERDOMAIN $LDAP = "LDAP://CN=Managed Service Accounts,DC=$domainName, DC=local" $objCN = [ADSI]$LDAP $objUser = $objCN.Create("user","CN=SharePoint Search Crawl") $objUser.Put("sAMAccountName","spCrawl") $objUser.Setinfo() $objUser.psbase.invokeset("AccountDisabled", "False") $objUser.SetPassword("pass@word1") $objUser.setinfo() $domainName = $env:USERDOMAIN $LDAP = "LDAP://CN=Managed Service Accounts,DC=$domainName, DC=local" $objCN = [ADSI]$LDAP $objUser = $objCN.Create("user","CN=SharePoint User Profile Services Sync") $objUser.Put("sAMAccountName","spUPS") $objUser.Setinfo() $objUser.psbase.invokeset("AccountDisabled", "False") $objUser.SetPassword("pass@word1") $objUser.setinfo() $domainName = $env:USERDOMAIN $LDAP = "LDAP://CN=Managed Service Accounts,DC=$domainName, DC=local" $objCN = [ADSI]$LDAP $objUser = $objCN.Create("user","CN=SharePoint C2WTS") $objUser.Put("sAMAccountName","spC2WTS") $objUser.Setinfo() $objUser.psbase.invokeset("AccountDisabled", "False") $objUser.SetPassword("pass@word1") $objUser.setinfo() $domainName = $env:USERDOMAIN $LDAP = "LDAP://CN=Managed Service Accounts,DC=$domainName, DC=local" $objCN = [ADSI]$LDAP $objUser = $objCN.Create("user","CN=SharePoint Farm") $objUser.Put("sAMAccountName","spFarm") $objUser.Setinfo() $objUser.psbase.invokeset("AccountDisabled", "False") $objUser.SetPassword("pass@word1") $objUser.setinfo()
Dopo aver configurato gli account, concentriamoci sull'ambiente Enterprise Services. Ai fini di questo esempio configureremo la nostra farm affinché vengano inclusi solo i servizi che supportano la federazione e di cui è possibile eseguire rapidamente il provisioning (Metadati gestiti, BCS e Archiviazione sicura). Per creare l'ambiente Enterprise Services, rilegheremo a Windows PowerShell gli oneri più gravosi. Questa opzione è importante, in quanto garantisce coerenza e lascia la situazione in uno stato noto. Nella Figura 2 è illustrata la creazione della farm. Il provisioning dei servizi verrà eseguito a breve.
Lo script per la configurazione della farm di consumer sarà analogo a quello illustrato nella Figura 3.
Figura 2 Creazione della farm aziendale.
Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0 # Settings $databaseServer = "TECHED-SQL" $configDatabase = "Enterprise_Farm_Config" $adminContentDB = "Enterprise_Farm_Content_Admin" $passphrase = "pass@word1" $farmAccountName = "TECHED\spfarm" $farmAccount = Get-Credential $farmAccountName $passphrase = (ConvertTo-SecureString $passphrase -AsPlainText -force) #will error, but fix the regkey... psconfig.exe -cmd upgrade Write-Host "Creating Configuration Database and Central Admin Content Database..." New-SPConfigurationDatabase -DatabaseServer $databaseServer -DatabaseName $configDatabase ` -AdministrationContentDatabaseName $adminContentDB ` -Passphrase $passphrase -FarmCredentials $farmAccount $spfarm = Get-SPFarm -ErrorAction SilentlyContinue -ErrorVariable err if ($spfarm -eq $null -or $err) { throw "Unable to verify farm creation." } Write-Host "ACLing SharePoint Resources..." Initialize-SPResourceSecurity Write-Host "Installing Services ..." Install-SPService Write-Host "Installing Features..." Install-SPFeature -AllExistingFeatures Write-Host "Creating Central Administration..." New-SPCentralAdministration -Port 2010 -WindowsAuthProvider NTLM Write-Host "Installing Help..." Install-SPHelpCollection -All Write-Host "Installing Application Content..." Install-SPApplicationContent Write-Host "Enterprise Farm Creation Complete!"
Figura3 Creazione della farm consumer.
Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0 # Settings $databaseServer = "TECHED-SQL" $configDatabase = "Consumer_Farm_Config" $adminContentDB = "Consumer_Farm_Content_Admin" $passphrase = "pass@word1" $farmAccountName = "TECHED\spfarm" $farmAccount = Get-Credential $farmAccountName $passphrase = (ConvertTo-SecureString $passphrase -AsPlainText -force) #will error, but fix the regkey... psconfig.exe -cmd upgrade Write-Host "Creating Configuration Database and Central Admin Content Database..." New-SPConfigurationDatabase -DatabaseServer $databaseServer -DatabaseName $configDatabase ` -AdministrationContentDatabaseName $adminContentDB ` -Passphrase $passphrase -FarmCredentials $farmAccount $spfarm = Get-SPFarm -ErrorAction SilentlyContinue -ErrorVariable err if ($spfarm -eq $null -or $err) { throw "Unable to verify farm creation." } Write-Host "ACLing SharePoint Resources..." Initialize-SPResourceSecurity Write-Host "Installing Services ..." Install-SPService Write-Host "Installing Features..." Install-SPFeature -AllExistingFeatures Write-Host "Creating Central Administration..." New-SPCentralAdministration -Port 2010 -WindowsAuthProvider NTLM Write-Host "Installing Help..." Install-SPHelpCollection -All Write-Host "Installing Application Content..." Install-SPApplicationContent Write-Host "Consumer Farm Creation Complete!"
Provisioning di un ambiente Enterprise Services
È ora possibile creare vari servizi che si desidera condividere con un'altra farm. Come già indicato, è possibile attuare la federazione di sei servizi. Crearne un paio, come illustrato nella Figura 4.
Figura 4 Provisioning di Enterprise Services.
Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0 # App Pools $saAppPoolName = "SharePoint Web Services Default" $saAppPoolUserName = "TECHED\spservices" # Service Application and DB names $stateName = "Enterprise Farm State Service" $stateDBName = "Enterprise_Farm_StateService" $usageName = "Enterprise Farm Usage and Health Data Collection Service" $usageDBName = "Enterprise_Farm_Usage" # Create Managed Accounts and Application Pools # Service Apps Write-Host "Please supply the password for the $saAppPoolUserName Account..." $appPoolCred = Get-Credential $saAppPoolUserName $saAppPoolAccount = New-SPManagedAccount -Credential $appPoolCred $saAppPool = New-SPServiceApplicationPool -Name $saAppPoolName -Account $saAppPoolAccount # Create State Service Application and Proxy, and add to default proxy group Write-Host "Creating $stateName Application and Proxy..." $stateDB = New-SPStateServiceDatabase -Name $stateDBName $state = New-SPStateServiceApplication -Name $stateName -Database $stateDB New-SPStateServiceApplicationProxy -Name "$stateName Proxy" -ServiceApplication $state -DefaultProxyGroup # Setup the Usage Service App Write-Host "Creating $usageName Application and Proxy..." $serviceInstance = Get-SPUsageService New-SPUsageApplication -Name $usageName -DatabaseName $usageDBName -UsageService $serviceInstance # app pool $saAppPoolName = "SharePoint Web Services Default" $appPoolUserName = "TECHED\spServices" # Gets app pool or quits Write-Host "Getting Application Pool..." $saAppPool = Get-SPServiceApplicationPool -Identity $saAppPoolName -EA 0 if($saAppPool -eq $null) { Write-Host "Cannot find the Application Pool $appPoolName, please ensure it exists before continuing." Exit -1 } # MMS specifics $mmsInstanceName = "MetadataWebServiceInstance" $mmsName = "Enterprise Farm Managed Metadata Service" $mmsDBName = "Enterprise_Farm_Managed_Metadata" # Sets up Managed Metadata service instance & service app and proxy Write-Host "Creating $mmsName Application & proxy..." $mms = New-SPMetadataServiceApplication -Name $mmsName -ApplicationPool $saAppPoolName -DatabaseName $mmsDBName $proxy = New-SPMetadataServiceApplicationProxy -Name "$mmsName Proxy" -ServiceApplication $mms -DefaultProxyGroup Write-Host "Starting the $mmsInstanceName..." Get-SPServiceInstance | where{$_.GetType().Name -eq $mmsInstanceName} | Start-SPServiceInstance Write-Host "Enterprise MMS Complete!" # BDC specifics $bdcInstanceName = "Business Data Connectivity Service" $bdcName = "Enterprise Farm Business Data Connectivity Service" $bdcDBName = "Enterprise_Farm_BDC" # Sets up Business Data Connectivity Service Application and Proxy and Service Instance Write-Host "Creating $bdcInstanceName Application and Proxy..." $bdc = New-SPBusinessDataCatalogServiceApplication -Name $bdcName -ApplicationPool $saAppPoolName -DatabaseName $bdcDBName Write-Host "Starting the $bdcInstanceName Instance..." Get-SPServiceInstance | where-object {$_.TypeName -eq $bdcInstanceName} | Start-SPServiceInstance Write-Host "Enterprise BDC Complete!" # SSS Specifics $sssInstanceName = "Secure Store Service" $serverName = "TechED-Services" $sssName = "Enterprise Farm Secure Store Service" $sssDBName = "Enterprise_Farm_SecureStore" # Sets up Secure Store Service Application & Proxy and Service Instance Write-Host "Creating $sssName Application & Proxy..." $sss = New-SPSecureStoreServiceApplication -Name $sssName -ApplicationPool $saAppPoolName -DatabaseName $sssDBName -auditingEnabled:$true -auditlogmaxsize 30 -Sharing:$false $proxy = New-SPSecureStoreServiceApplicationProxy -Name "$sssName Proxy" -ServiceApplication $sss -DefaultProxyGroup Write-Host "Starting the $sssInstanceName Instance..." $sssInstance = Get-SPServiceInstance | where-object{$_.TypeName -eq "Secure Store Service" -and $_.Server.Address -eq $serverName} | Start-SPServiceInstance Write-Host "Enterprise SSS Complete!"
Provisioning di un ambiente di consumo
Il grosso della farm consumer è stato completato. Passiamo ora alla farm che utilizzerà Enterprise Services. Qui è possibile creare qualsiasi servizio. È essenziale capire che è possibile utilizzare i servizi di un'altra farm e affidarsi alla farm in questione per la distribuzione delle risorse.
Nella farm consumer verrà inoltre eseguito il provisioning di un'applicazione Web di gestione del contenuto SharePoint che è possibile utilizzare per illustrare Enterprise Services, come mostrato nella Figura 5.
Figura 5 Provisioning di contenuti SharePoint.
# App Pools $saAppPoolName = "SharePoint Web Services Default" $saAppPoolUserName = "TECHED\spservices" $waAppPoolName = "SharePoint Content" $waAppPoolUserName = "TECHED\spcontent" # Web App details $mainURL = "http://teched-sp" $webAppName = "TechED Consumer" $contentDBName = "Consumer_Farm_Content_Web_Application" # Root Site Collection details $ownerEmail = "administrator@teched.com" $ownerAlias = "TECHED\administrator" # Web app Write-Host "Please supply the password for the $waAppPoolUserName Account..." $appPoolCred = Get-Credential $waAppPoolUserName $waAppPoolAccount = New-SPManagedAccount -Credential $appPoolCred <# Create a new Web App using Claims (Windows (NTLM)) #> $authProvider = New-SPAuthenticationProvider $webApp = New-SPWebApplication -ApplicationPool $waAppPoolName -ApplicationPoolAccount $waAppPoolAccount -Name $webAppName -Port 80 -AuthenticationProvider $authProvider -DatabaseName $contentDBName # Set sensible content db limits Set-SPContentDatabase $contentDBName -MaxSiteCount 50 -WarningSiteCount 30 <# Create Site Collection at root #> New-SPSite -Url $mainURL -owneralias $ownerAlias -ownerEmail $ownerEmail Write-Host "WebApp Complete!"
Configurazione di certificati
Ora che abbiamo completato le farm, passiamo alla pubblicazione dei servizi Enterprise Services che desideriamo condividere con il consumer. A tale scopo possiamo utilizzare diversi passaggi:
- Creare certificati nella farm aziendale
- Creare certificati nella farm consumer
- Scambiare i certificati
- Importare i certificati nella farm aziendale
- Importare i certificati nella farm consumer
- Creare certificati nella farm aziendale
Per prima cosa, è necessario esportare il certificato radice dalla farm aziendale. A tale scopo, creare un percorso per esportare il certificato (vedere la Figura 6). Dopo aver confermato il percorso, utilizzare il cmdlet Get-SPCertificateAuthority per esportare il certificato per la farm.
Figura 6 Creazione di un percorso per un certificato.
# Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0 $path = "C:\Certs" # Test and Create Path If ((test-path $path) -eq $false) { [IO.Directory]::CreateDirectory("$path") } # Export Cert $rootCert = (Get-SPCertificateAuthority).RootCertificate $rootCert.Export("Cert") | Set-Content "C:\Certs\EnterpriseServicesRootCert.cer" -Encoding byte
Creazione di un certificato nella farm consumer
Nella farm consumer è necessario esportare il certificato radice, ma anche un certificato STS (vedere la Figura 7). Quest'ultima viene esportata mediante il cmdlet Get-SPSecurityTokenServiceConfig.
Per semplificare il processo verrà inoltre fornito l'ID per la farm consumer e verrà creato un file di testo. Aggiungere l'ID della farm alle autorizzazioni di pubblicazione nella farm aziendale per poter accedere ai servizi.
Figura 7 Esportazione del certificato STS.
# Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0 $publisher = "TECHED-Services" $consumer = "TECHED-SP" $path = "C:\Certs" # Test and Create Path If ((test-path $path) -eq $false) { [IO.Directory]::CreateDirectory("$path") } # Run the following to export the necessary certificates on the consumer farm to c:\temp on the server: $rootCert = (Get-SPCertificateAuthority).RootCertificate $rootCert.Export("Cert") | Set-Content "C:\Certs\IntranetRootCert.cer" -Encoding byte $stsCert = (Get-SPSecurityTokenServiceConfig).LocalLoginProvider.SigningCertificate $stsCert.Export("Cert") | Set-Content "C:\Certs\IntranetSTSCert.cer" -Encoding byte #On the consumer farm, run the following command to get the id of the consumer farm: $farmID = (Get-SPFarm).Id New-Item C:\Certs\IntranetConsumerFarmID.txt -type file -force -value "$farmID" #On the consumer farm, run the following command to copy the IntranetConsumerFarmID.txt to the publisher farm Copy-Item \\$consumer\c$\Certs\IntranetConsumerFarmID.txt \\$publisher\c$\Certs
Scambio dei certificati
Una volta ottenuti i certificati necessari da entrambe le farm, utilizzare il cmdlet Copy-Item per copiare EnterpriseServicesRootCert.cer nella farm consumer, quindi copiare i certificati IntranetRootCert e IntranetSTSCert nella farm aziendale, come illustrato qui:
$publisher = "TECHED-Services" $cconsumer = "TECHED-SP" # Copy to Consumer Copy-Item \\$publisher\c$\Certs\EnterpriseServicesRootCert.cer \\$cconsumer\c$\Certs Copy-Item \\$cconsumer\c$\Certs\IntranetRootCert.cer \\$publisher\c$\Certs Copy-Item \\$cconsumer\c$\Certs\IntranetSTSCert.cer \\$publisher\c$\Certs
Importazione del certificato dell'editore
Passiamo ora all'importazione di due certificati Intranet nella farm aziendale e stabiliamo un rapporto di attendibilità. Per configurare le autorizzazioni, è necessario utilizzare l'ID della farm. Utilizzare il file di testo creato per agevolare il processo ed eseguire i comandi illustrati nella Figura 8 nella farm dell'editore per stabilire il rapporto di attendibilità con la farm consumer.
Figura 8 Creazione di un rapporto di attendibilità con la farm consumer.
$trustCert = Get-PfxCertificate "C:\certs\IntranetRootCert.cer" New-SPTrustedRootAuthority Intranet -Certificate $trustCert $stsCert = Get-PfxCertificate "c:\certs\IntranetSTSCert.cer" New-SPTrustedServiceTokenIssuer Intranet -Certificate $stsCert $farmID = Get-Content C:\Certs\IntranetConsumerFarmID.txt $security = Get-SPTopologyServiceApplication | Get-SPServiceApplicationSecurity $claimProvider = (Get-SPClaimProvider System).ClaimProvider $principal = New-SPClaimsPrincipal -ClaimType "https://schemas.microsoft.com/sharepoint/2009/08/claims/farmid" -ClaimProvider $claimProvider -ClaimValue $farmID Grant-SPObjectSecurity -Identity $security -Principal $principal -Rights "Full Control" Get-SPTopologyServiceApplication | Set-SPServiceApplicationSecurity -ObjectSecurity $security
Importazione del certificato consumer
Rimane ancora un passaggio inerente ai certificati: nella farm consumer è necessario eseguire lo script indicato di seguito per importare EnterpriseServicesRootCert ed eseguire questi comandi nella farm consumer per stabilire il rapporto di attendibilità con la farm dell'editore:
$trustCert = Get-PfxCertificate "C:\Certs\EnterpriseServicesRootCert.cer" New-SPTrustedRootAuthority EnterpriseServices -Certificate $trustCert
Pubblicazione dei servizi
Dopo aver creato le due farm, importato il certificato radice dalla farm aziendale nella farm consumer, importato i certificati radice e STS dalla farm consumer nella farm aziendale e utilizzato l'ID della farm consumer per stabilire un rapporto di attendibilità tra le due farm, passiamo all'esplorazione di Amministrazione centrale e alla pubblicazione dei servizi.
Il passaggio successivo prevede l'analisi delle applicazioni di servizio. Individuare uno dei sei servizi che si desidera condividere, evidenziarlo e quindi fare clic sul pulsante Pubblica nella barra multifunzione. Verrà visualizzata una finestra di dialogo che consente di selezionare la modalità di distribuzione del servizio. Modificare il tipo di connessione in HTTPS e selezionare Pubblica applicazione di servizio in altre farm. Prendere nota dell'URL editore, che è possibile utilizzare in vari modi.
Utilizzo dei servizi
SharePoint fornisce alcuni percorsi ai servizi consumer. Per prima cosa, evidenziare il pulsante Connetti nella barra multifunzione. Fare clic sul pulsante Connetti nella barra per visualizzare la finestra di dialogo Connetti a un'applicazione di servizio remota. Copiare l'URL completo della sezione precedente e incollarlo nella casella di testo. Fare clic su OK per visualizzare un servizio specifico. Ciò è dovuto al servizio identificato nello specifico. Per visualizzare tutti i servizi pubblicati, è sufficiente utilizzare l'indirizzo HTTPS.
In questo modo verrà confermata la configurazione corretta dei certificati. Specificare infine il tipo di connessione che si desidera stabilire. Si tratta di un'opzione utile se l'editore condivide varie applicazioni di servizio dello stesso tipo. È importante sottolineare che verrà utilizzato solo il percorso HTTPS. Il risultato finale è costituito dal fatto che verranno visualizzate solo le applicazioni di servizio del tipo specificato in origine.
Risoluzione dei problemi relativi alla soluzione di servizi federati
Vari fattori possono incidere sui servizi federati, tra cui reti, firewall e impedimenti dell'infrastruttura. Se le server farm sono situate in domini diversi, l'applicazione di servizio Profilo utente prevede che entrambi i domini siano reciprocamente attendibili.
Affinché le funzionalità di amministrazione delle applicazioni di servizio Integrazione applicativa dei dati e Archiviazione sicura siano operative dalla farm consumer, il dominio della farm dell'editore deve stabilire un rapporto di attendibilità con il dominio della farm consumer. Altre applicazioni di servizi tra farm non prevedono un rapporto di attendibilità tra i domini. Oltre a controllare le attendibilità dei domini, è necessario verificare quanto segue:
- Garantire l'attendibilità dei domini
- Verificare che il consumer disponga delle autorizzazioni necessarie per il servizio di topologia
- Controllare l'ACL
- FQDN
- Certificati
Un altro esempio: provare ad accedere a uno dei servizi dalla farm consumer. Notare l'errore "Il sito Web ha rifiutato di visualizzare la pagina Web". È possibile correggere l'errore visitando la farm aziendale e consentendo alla farm consumer di utilizzare il servizio specifico.
Per configurare le autorizzazioni della farm consumer, evidenziare l'applicazione del servizio che si desidera configurare e fare clic su Autorizzazioni. Verrà ricavato l'ID della farm consumer. Come già illustrato, è stato creato un file di testo con l'ID della farm consumer ed è stato trasferito nella farm dell'editore. Il file è disponibile al percorso c:\certs. Incollare l'ID della farm nella casella di testo e fare clic su Aggiungi. Verificare le autorizzazioni appropriate. A questo punto è possibile procedere con il test del servizio.
Test della soluzione di servizi federati
Dalla farm consumer dovrebbe essere possibile interagire con i servizi. Per questo ambiente lab verranno utilizzate quattro immagini Hyper-V. Due immagini saranno destinate all'ambiente host, le altre due all'ambiente consumer. È possibile espandere agevolmente il numero dei server, ma a causa delle limitazioni hardware negli ambienti demo, è più semplice utilizzare un server per Active Directory e condividere i ruoli SQL Server e SharePoint 2010 nell'altro.
Sebbene non sia fondamentale seguire alla lettera ogni passaggio, è consigliabile attenersi alla procedura per ottenere un risultato coerente. La configurazione di rete non rientra nell'ambito di questo documento. Ulteriori informazioni sono disponibili sul mio blog.
Ogni server è stato configurato con le impostazioni seguenti:
Nome server: TechED-AD Indirizzo IP 192.168.110.1
Dominio: TechED.local Livello di funzionalità foresta Windows Server 2008 R2
Password amministrazione: pass@word1
Nome server: TechED-SQL Indirizzo IP 192.168.110.2
Dominio: TechED.local Livello di funzionalità foresta Windows Server 2008 R2
Password amministrazione: pass@word1
Nome server: TechED-Serives Indirizzo IP 192.168.110.11
Dominio: TechED.local Livello di funzionalità foresta Windows Server 2008 R2
Password amministrazione: pass@word1
Nome server: TechED-SP Indirizzo IP 192.168.110.12
Dominio: TechED.local Livello di funzionalità foresta Windows Server 2008 R2
Password amministrazione: pass@word1
Una volta create le quattro macchine, creare una nuova foresta di domini nel controller di dominio. Il dominio per questo esempio è TechED.local. Per promuover i server al controller di dominio, utilizzare l'utilità DCPromo. Con le impostazioni precedentemente utilizzate, assegnare gli indirizzi IP appropriati alle schede di rete e rinominare i computer in base alle esigenze.
Una volta creati i controller di dominio e configurati i rispettivi indirizzi IP, sarà possibile eseguire il join dei server che ospiteranno SQL Server e SharePoint 2010. Abilitare la funzionalità Windows PowerShell Integrated Scripting Environment (ISE) in ogni server che ospita SQL Server e SharePoint per agevolare sensibilmente la gestione di Windows PowerShell.
Installare ora SQL Server 2008 R2 nel server TechED-SQL (vedere la Figura 9). Nella macchina host dovrebbe essere presente il file ISO appropriato. Associarlo alla macchina virtuale (Supporti | Unità DVD | Inserisci disco).
Figura 9 Installazione di SQL Server.
# Set Exec Policy Set-ExecutionPolicy -executionPolicy Unrestricted # Add SQL Service Account to AD $domainName = $env:USERDOMAIN $LDAP = "LDAP://CN=Managed Service Accounts,DC=$domainName, DC=local" $objCN = [ADSI]$LDAP $objUser = $objCN.Create("user","CN=SQL Service") $objUser.Put("sAMAccountName","sqlService") $objUser.Setinfo() $objUser.psbase.invokeset("AccountDisabled", "False") $objUser.SetPassword("pass@word1") $objUser.setinfo() # Install SQL Server with the following settings # Disable Firewall # # SQL Server Feature Installation # Check … # Database Engine Services, SQL Server Replication, Full-Text Search # Business Intelligence Development Studio # Management Tools - Complete # Microsoft Sync Framework # ----------------------------- # Default Instance # Use account above for all services # Select Windows Authentication Mode and click Add Current User # Complete Wizard
Una volta installato TechED-SQL, installare solo i prerequisiti e i file binari di SharePoint. Non eseguire la procedura guidata. Prima di qualunque altra cosa, acquisire uno snapshot di tutte e quattro le macchine: meglio andare sul sicuro!
.jpg)
Shannon Bray è un Evangelist di SharePoint e Microsoft Certified Trainer. Attualmente lavora presso Planet Technologies come Technical Architect e si occupa esclusivamente di Microsoft SharePoint. Bray è specializzato in progettazione di architetture e sviluppo di soluzioni con tecnologie Microsoft. È presidente del Colorado SharePoint User Group e ha presentato argomenti SharePoint in Microsoft TechReady e Tech-Ed. Bray è autore di diverse serie di video di formazione su SharePoint e ha da poco pubblicato il volume "Automating Microsoft SharePoint 2010 Administration with Windows PowerShell 2.0." (Wiley, 2011)