E' passato un po' di tempo dall'ultimo post e mi accingo ad "inaugurare" il nuovo anno esattamente da dove l'avevo lasciato, cioè da Windows PowerShell. Ne approfitto già che ci sono per ricordarvi che alla prossima SharePoint & Office Conference io e Claudio terremo una sessione su PowerShell 3 e SharePoint 2013, se siete da quelle parti fatevi riconoscere :). Ma torniamo a noi. Di recente un cliente mi ha chiesto un report giornaliero sulle dimensioni di una serie di site collection (SharePoint 2010). Un possibilità era quella di suggerire al cliente di aprire la site collection con SharePoint Designer tutte le volte che ne aveva voglia e controllare da se. Ottima idea per interrompere subito i rapporti con la maggior parte dei clienti :). Affidarsi alle dimensioni del content database non fornisce sufficienti informazioni sul reale livello di utilizzo del sito in quanto lo stesso database può contenere più site collection. Inoltre penso sia applicabile la stessa considerazione fatta in precedenza. La strada che ho intrapreso è stata, inutile ribadirlo, quella di utilizzare uno script PowerShell. Concettualmente è molto semplice. Faccio un ciclo su tutte le site collection, memorizzo sia lo spazio utilizzato dalla site collection che dal content database ed invio i risultati via email ad uno o più destinatari . Lo script è pensato per essere eseguito tramite Task Scheduler. Ecco lo script:

if ((Get-PSSnapin Microsoft.SharePoint.Powershell -ErrorAction SilentlyContinue) -eq $null){ Add-PSSnapin Microsoft.SharePoint.Powershell -ErrorAction SilentlyContinue } <## Nelle righe seguenti vado a ricavare l'indirizzo del server SMTP configurato nella Central Administration e imposto qualche variabile di servizio ##> $nl = [environment]::NewLine $message = "" $storage = 0 $ca = Get-SPWebApplication -IncludeCentralAdministration | ?{$_.IsAdministrationWebApplication -eq "True"} $smtpServer = $ca.OutboundMailServiceInstance.Server.Address <## A questo punto ciclo su web application e site collection, ordinando i risultati per spazio occupato. Nel ciclo formatto i valori in modo che siano numeri leggibili e creo il messaggio da inviare ##> Get-SPWebApplication | Get-SPSIte -Limit All | Sort-Object -Descending -Property $_.usage.storage | %{ $db = Get-SPContentDatabase $_.ContentDatabase ; $dbsize = "{0:N2}" -f ($db.DiskSizeRequired/1GB) ; $size = "{0:N2}" -f ($_.usage.storage/1GB); $message += $nl + $nl + $_.Url + "; " + $size + " GB; " + ($_.ContentDatabase -replace "SPContentDatabase Name=","") + "; " + $dbsize + " GB;" $storage += $_.usage.storage } <## Aggiungo al messaggio la somma dello spazio occupato da tutte le site collection. Alle righe successive imposto il messaggio di posta e lo invio. ##> $message += $nl + $nl + "Totale storage {0:N2}" -f ($storage/1GB) + "  GB" $date = Get-Date $msg = new-object Net.Mail.MailMessage $smtp = new-object Net.Mail.SmtpClient($smtpServer) $msg.From = "me@mioserver.it" $msg.ReplyTo = "me@mioserver.it" $msg.To.Add("te@tuoserver.com") $msg.subject = "Report storage site collections " + $date.ToShortDateString() $msg.body = $message $smtp.Send($msg)

Puoi scaricare lo script dal mio SkyDrive, a tuo rischio e pericolo, si intende :) Se invece questo tipo di informazioni servono una tantum e nel più breve tempo possibile devo convenire con Igor che il comando stsadm -o enumsites -url http://miosito è probabilmente la soluzione più veloce. Anche se io continuo a preferire the Powershell way :) Happy PoSH - Riccardo

Live dal mio nuovissimo Lenovo W530 faccio solo una rapida escursione nel mondo esterno per segnalare che nei giorni scorsi è stato pubblicato su SharePointCommunity.it il video della sessione che ho tenuto durante l'evento SharePoint Governance, tenutosi Martedì 30 Ottobre a Milano. In realtà a causa di problemi "tecnici" la sessione è stata registrata in un secondo momento, ma sono sicuro che fa lo stesso :) Da pochi minuti inoltre è stato pubblicato un nuovo articolo su come rinominare una web application in SharePoint. Approfitto per ringraziare Achille della disponibilità :)

• SharePoint Governance con Nintex Workflow http://www.sharepointcommunity.it/media/Lists/Screencasts/DispForm.aspx?ID=20
• Rinominare una Web Application via PowerShell http://www.sharepointcommunity.it/articles/Lists/Articles/DispForm.aspx?ID=52

Qualcuno mi ha segnalato che ha problemi con la riproduzione del video, se così fosse fatecelo sapere che provvederemo a rimediare tempestivamente. - Riccardo

Seconda parte della serie Vintage Weekend. Se vi siete persi la prima parte si tratta di esempi di script Powershell pensati per essere utilizzati con SharePoint 2007. In questo caso il pretesto mi è stato dato da un cliente che aveva bisogno di conoscere tutti gli utenti e gruppi di una site collection. Come nell'esempio precedente trattandosi si SharePoint 2007 è necessario referenziare le librerie che interrogheremo prima di procedere. Successivamente, una volta memorizzato l'oggetto "site collection" effettueremo un ciclo su tutti i gruppi del sito e per ognuno di questi stamperemo a video tutti i nomi utente.

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") $site = New-Object Microsoft.SharePoint.SPSite("http://yourservername/sites/yoursitecollection ") $groups = $site.RootWeb.sitegroups foreach ($grp in $groups) { "Group: " + $grp.name; foreach ($user in $grp.users) { "  User: " + $user.name } } $site.Dispose()

Happy PoSH - Riccardo

Chiamatelo Vintage, chiamatelo Legacy, chiamatelo un po' come vi pare ma SharePoint 2007 è ancora là fuori e gode di discreta salute. Proprio qualche giorno fa mi è stata chiesta un indicazione di massima sul numero totale di elementi presenti in una web application. In un primo momento ho pensato che la pagina "storage manager" potesse aiutarmi, ma così non è stato in quanto questa pagina mostra al massimo i primi 100 "contenitori" più utilizzati. Ho trovato la risposta, come in molti altri casi in Windows Powershell. Non mi stancherò mai di ripetere infatti che, anche se solo in SharePoint 2010 sono state create delle cmdlet apposite, già dalla versione 2007 è possibile accedere al modello oggetti di SharePoint da script. Il concetto è molto semplice, selezionare una web application ed effettuare un ciclo su tutte le site collection, tutti i siti, tutti gli elenchi e scrivere URL, titolo e tipologia della lista in un file di testo. Infine ho anche aggiunto il conteggio degli elementi presenti in ciascuna lista.

[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") $farm = [Microsoft.SharePoint.Administration.SPFarm]::Local foreach ($spService in $farm.Services) { if (!($spService -is [Microsoft.SharePoint.Administration.SPWebService])) {   continue;  } $webApp = [Microsoft.SharePoint.Administration.SPWebApplication]::Lookup("http://2007.sharepoint.corp") foreach ($site in $webApp.Sites) { foreach ($web in $site.AllWebs) { foreach ($list in $web.Lists) { $values = $web.Url + "," + $list.Title + "," + $list.BaseType + "," + ($list.items).count add-content -path "D:Logsilmiosito-items.csv" -value $values } $web.Dispose(); } $site.Dispose() } }

Una volta eseguito lo script potrete aprire il file CSV in Excel ed utilizzarlo per fare tutte le statistiche che vi servono. Happy Vintage PoSH - Riccardo

Qualche settimana fa, preparando una demo su FAST Search for SharePoint 2010, ad un certo punto alcune delle web part della pagina dei risultati della ricerca (search refiner e core result web part) hanno cominciato ad andare saltuariamente in errore. L'errore era il "classico" Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator. L'errore, comune quando si commette un errore nella personalizzazione dell'XSLT di una Data Form Web Part, mi è parso molto strano a causa del fatto che non avevo affatto modificato i template XSLT di quelle Web Part. Verificato il Correlation ID con le informazioni presenti nel ULS log ho trovato questo messaggio:

Error while executing web part: System.StackOverflowException: Operation caused a stack overflow. at Microsoft.Xslt.NativeMethod.CheckForSufficientStack() at <xsl:template match="Result">(XmlQueryRuntime , XPathNavigator ) at <xsl:apply-templates>(XmlQueryRuntime , XPathNavigator ) at <xsl:template name="dvt_1.body">(XmlQueryRuntime , XPathNavigator ) at Root(XmlQueryRuntime )  ... (continua)

La causa di questo errore era nota da qualche tempo a Microsoft, di fatto se la trasformazione dei template XSLT impiega più di 1 secondo viene sollevata questa eccezione. Nel mio caso, date le risorse della VM, questo era assolutamente possibile, ma in vista della demo con il cliente dovevo assolutamente risolvere l'errore. A partire dalla Cumulative Update di Febbraio 2012 è stato aggiunto un nuovo metodo grazie al quale, tramite Powershell, è possibile aumentare il timeout. E' sufficiente uno script di tre righe, eccolo:

$farm = Get-SPFarm $farm.XsltTransformTimeOut = 5 $farm.Update()

Data la soluzione, vale la pena comunque soffermarsi sulle motivazioni che portano a questo errore, cioè verificare attentamente le performance della farm e  revisionare i propri template XSLT.

- Riccardo