Provare SharePoint 2013

Mi fa impressione pensare al fatto che sia già passata una settimana dalla fine dell’edizione 2013 della SharePoint & Office Conference. Sarà perché dopo un periodo così inteso sono tornato al lavoro “ordinario” con una strana sensazione di stordimento del tipo “E adesso cosa succede?”.

Cooomunque… La mia impressione sulla conferenza è stata molto positiva, sono davvero molto soddisfatto sia come speaker che come partecipante. In questi tre giorni infatti, oltre che parlare di Powershell 3 e SharePoint 2013, New SharePoint 2013 Search Features e (ahimè) Workflow con SharePoint Designer 2013, ho avuto modo di seguire qualche sessione, purtroppo non tutte quelle che avrei voluto. Ho trovato notevoli quelle di Carmelo Ferrara (SharePoint: Capacity Planning and Performance Improvements), Spencer Harbar (Rational Guide to SharePoint Server 2013 User Profile Synchronization), Brian Alderman (Optimizing SQL Server for SharePoint) e Luca Bandinelli (SharePoint 2013 new Search Architecture).

Ma veniamo al punto. Durante i coffee break più di un partecipante alla conferenza mi ha chiesto se fosse possibile “provare” SharePoint senza doverlo installare “in casa”. Di seguito riporto un elenco, sicuramente non esaustivo, di alcuni servizi che offrono questa possibilità.

  • Office365 penso non abbia bisogno di presentazioni. E’ possibile registrarsi per provare il “prodotto” gratuitamente per 30 giorni (Office365 Enterprise E3 Trial). L’ambiente  è configurato e funzionante in pochi minuti;
  • CloudShare è un servizio online che mette a disposizione una, o più, macchine virtuali SharePoint (2007, 2010 e 2013) già configurate. A questo indirizzo trovate l’elenco di tutte le VM che potrete scegliere (non solo SharePoint): http://www.cloudshare.com/products/proplus/availablemachines. Anche in questo caso c’è una trial gratuita di 14 giorni. Non ho mai provato questo servizio, al contrario di Office365 :);
  • SharePointPower.com è un servizio che mette a disposizione un tenant SharePoint 2013 (site collection “illimitate”, massimo 1 GB di storage e 10 utenti, enterprise feature, 20 lingue disponibili) per studiare le funzionalità del prodotto. Sicuramente è una soluzione molto interessante, anche per il fatto che sembra essere totalmente gratuito. A questo indirizzo trovate qualche informazione aggiuntiva: http://thuansoldier.net/?p=2915. Come per il caso precedente non l’ho ancora provato personalmente;
  • 2010 Information Worker Demonstration and Evaluation Virtual Machine (SP1). Già da qualche anno Microsoft permette di scaricare una virtual machine (Hyper-V) di valutazione del prodotto. L’ambiente SharePoint, 2010 in questo caso, è già configurato, compreso Office Web Applications e FAST Search for SharePoint 2010. E’ inoltre possibile scaricare dalla stessa pagina una serie di pacchetti contenenti dati di esempio per tutte le funzionalità da testare. In molte occasioni queste VMs mi sono tornate molto comode. Purtroppo non ho trovato e non sono a conoscenza dell’esistenza delle stesse macchine virtuali con SharePoint 2013. A differenza di tutti gli altri servizi queste VM richiedono dell’hardware su cui girare.

Enjoy your test 🙂
– Riccardo

Annunci

Report dimensioni site collection con Powershell

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

SharePoint & Office Conference 2013


Vintage Weekend: Elencare tutti i documenti di un sito con Powershell su SharePoint 2007

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:\Logs\ilmiosito-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


Nuovo articolo SharePointCommunity.it

Dopo qualche mese di “assenza” sono finalmente tornato a scrivere per SharePointCommunity.it. Sabato è stato pubblicato il mio ultimo articolo, Creare custom property extractors per FAST Search for SharePoint 2010.

Come? Vi state chiedendo cosa sia un custom property extractor? Anticipo solo che si tratta di una feature di FAST Search for SharePoint 2010 che permette di riconoscere automaticamente una serie di termini all’interno dei contenuti indicizzati (attenzione, leggete bene le note finali dell’articolo) e di utilizzarli nel sito di ricerca (o forse sarebbe meglio dire nel servizio di ricerca).

Per il resto vi invito a leggere l’articolo e, se vi va, farmi sapere cosa ne pensate :).

Happy SPC.it
– Riccardo


Refinement Panel: errore nel link Show more

Poche settimane fa sono incappato in un problema a dir poco “curioso”. Cliccando sul link “show more” nel refinement panel di una pagina dei risultati di ricerca personalizzata, al posto di mostrare un numero più ampio di scelte, non succedeva proprio niente.

Refinement Panel

Controllando con la developer toolbar ho notato l’errore di script seguente (The value of the property “SearchEnsureSOD” is null or undefined, not a Function object).

L’errore mi è sembrato molto strano, perchè XSLT e CSS a parte avevo solo rimosso la web part relativa al box di ricerca.

Dopo una breve ricerca ho scoperto che il punto è proprio questo. Senza la Search Box Web Part (o analgo controllo in master page) viene sollevata questa eccezione.

A questo punto mi sono incuriosito e ho cercato nel mio piccolo di approfondire un pò l’argomento. La prima cosa che ho notato analizzando le chiamate http della pagina con Fiddler è stata che con la web part in pagina vengono caricati due file javascript in più, il search.js e ajaxtoolkit.js.

Fiddler Results

Controllando l’output della pagina ho inoltre notato che, oltre a non effettuare la chiamata al file search.js, nella versione della pagina senza box di ricerca (web part o controllo non fa differenza) mancano una serie di funzioni javascript.

HTML

A pensarci bene avrei potuto fare un’altro paio di verifiche, ad esempio richiamare “a mano” il file search.js dal page layout, peccato non mi sia venuto in mente prima, maybe next time 🙂

SearchEnsureSOD(-Riccardo)


Aggiornare campi publishing images con Powershell

Di recente ho avuto l’esigenza di aggiornare tutti i valori di un campo di tipo “publishing images“. Anche se non si trattava di un numero esagerato di immagini ho provato a cercare un alternativa, trovo che l’update di questi campi da UI sia infatti molto “noioso”. L’alternativa è ovviamente Powershell :).

Ho scoperto che bastano verametne poche righe per completare l’operazione e, soprattutto, lo stesso script contiene tanti spunti utili in molti altri scenari.

Ma veniamo al dunque. Cominciamo a memorizzare nelle “solite” variabili gli oggetti site collection e web.

$spSite = Get-SPSite http://sharepoint
$spWeb = $spSite.RootWeb

Tocca ora all’elenco che contiene le immagini da aggiornare.

$spList = $spWeb.Lists[“Links”]

A questo punto, facendo un ciclo su tutti gli elementi dell’elenco, memorizziamo nella variabile $image il campo PublishingPageImage. Trattandosi di un tipo di dato “complesso” la nostra variabile avrà diverse proprietà. Una di queste è ImageUrl che contiene le informazioni relative al path dell’immagine.

Nel mio caso l’aggiornamento prevedeva il campio di origine dell’immagine mentre il nome del file doveva rimanere invariato. Di conseguenza ho aggiornato la proprietà ImageUrl sostituendo il vecchio path con quello corretto. Per questa operazione ho utilizzato l’operatore replace.

In un primo momento pensavo che questo, seguito solo dal comando $listitem.Update(), bastasse per aggiornare le mie immagini, ma mi sbagliavo. A questo punto abbiamo aggiornato solo una proprietà dell’oggetto ed è quindi necessario reimpostare correttamente il valore del nostro campo. Il codice di esempio della pagina su MSDN mi è stata molto utile per capire questo passaggio.

foreach($listitem in $spList.Items){
$image = $listitem[“PublishingPageImage”]
$image.ImageUrl = $image.ImageUrl -replace “/SiteAssets/”, “/SiteCollectionImages/”
$listitem[“PublishingPageImage”] = $image;
$listitem.Update()
}

Alla fine dello script rilasciamo l’oggetto “web” e abbiamo finito.

$spWeb.Dispose()

Potete scaricare lo script qui.

Happy Posh
– Riccardo