Modifica e test del server SMTP con Powershell

Chissà perchè nel passaggio 2007 > 2010 Microsoft non abbia ritenuto di mettere a disposizione una cmdlet per la configurazione del server di posta in uscita (SMTP), corrispondente al vecchio comando stsadm -o email. Technet riporta infatti ancora lo stesso comando (http://technet.microsoft.com/en-us/library/cc263462.aspx) e anche nella pagina relativa ai mapping stsadm / Powershell (http://technet.microsoft.com/en-us/library/ff621084.aspx) non si trova corrispondenza.

Questo non signifca però che non si possa fare, bastano poche righe :)

Prima di tutto memorizzo i dati da configurare all’interno di quattro variabili.

$smtpServer = ‘mail.sharepoint.corp’
$smtpFrom = ‘admin@sharepoint.corp’
$smtpReplyTo = ‘admin@sharepoint.corp’
$smtpCharset = 65001

In una nuova variabile memorizzo l’oggetto “Web Application” corrispondente alla Central Administration*.

$caWebApp = Get-SPWebApplication -IncludeCentralAdministration | ?{ $_.IsAdministrationWebApplication }

e utilizzo infine il metodo UpdateMailSettings di questo oggetto per configurare il server di posta in uscita.

$caWebApp.UpdateMailSettings($smtpServer, $smtpFrom, $smtpReplyTo, $smtpCharset)

* Dato che la configurazione del server SMTP può essere personalizzata per Web Application basterà selezionare la web application desiderata al posto della Central Administration per modificarne la configurazione.

Una volta apportata la modifica al server di posta è consigliabile effettuare un test per verificare che tutto funzioni a dovere. Anche per questo possiamo usare poche righe di Powershell. Tramite il metodo SendMail dell’oggetto SPUtility (http://msdn.microsoft.com/en-us/library/ms477270.aspx) invieremo un email sfruttando la configurazione SMTP di un sito SharePoint. Più facile a farsi che a dirsi.

$web = Get-SPWeb “http://intranet
$sent = [Microsoft.Sharepoint.Utilities.SpUtility]::SendEmail($web,$false,$false,”riccardo@sharepoint.corp”,”Oggetto del messaggio”,”Corpo del messaggio”)

La variabile $sent assumerà il valore di True o False a seconda che l’invio del messaggio riesca o meno. Semplice no?

– Riccardo

Community Contributor Award 2012

Ok, il resto del mondo sarà forse più interessato a sapere se la Pro Patria sabato abbia vinto, perso o pareggiato, ma ci tengo comunque a segnalare che sabato ho ricevuto un e-mail da Microsoft di congratulazioni per aver ricevuto il riconoscimento Community Contributor Award 2012.

Microsoft Community Contributor Award 2012

Di cosa si tratta? Ecco qui la definizione di Microsoft:

These awardees have volunteered their time and energy to ensure the success of their online technical communities. They have been recognized for their contributions ranging from moderation activities to providing helpful solutions to questions within the community.

La notizia è stata tempestivamente battuta da tutte le maggiori agenzie di stampa: http://www.greenteam.it/notizie/Pages/Nuovo-premio-Microsoft-Community-Award-2012.aspx :)

– Riccardo

ps. Per dovere di cronaca, la Pro Patria ha giocato domenica a Rimini e ha vinto per 3 a 2.

SharePoint Web Services e DataForm

In molte occasioni, in mancanza di altri mezzi, mi è capitato di utilizzare i web services di SharePoint per la visualizzione di dati cross site collection o cross farm. Se a qualcuno dovesse suonare nuovo quello che ho scritto si tratta di utilizzare i vari servizi che si trovano nella virtual directory _vti_bin di ciascun sito SharePoint e sfruttare uno dei metodi messi a disposizione come data source (XML Web Services) di una Data Form Web Part. Uno di questi servizi è lists.asmx, uno dei suoi metodi GetListItems (es. http://www.ilmiosito.it/_vti_bin/lists.asmx?op=GetListItems).

L’utilizzo di questo tipo di origine dati nasconde però molte insidie (che qualcuno chiama “configurazioni” :)). Vediamo alcuni dei parametri che devono essere compilati e come:

  1. listName [Obbligatorio]: il nome è parlante, si tratta del nome (nome visualizzato) della lista da cui si vogliono leggere i dati;
  2. viewName [Opzionale]: in questo caso il nome trae in inganno, non si tratta del nome della vista, ma del suo GUID. Ci interessa? Eccome! Tramite l’impostazione di questo valore possiamo scegliere quali dati saranno visibili nella dataform, con quali filtri e in che ordine. In pratica ci permette di spostare la logica di selezione ed ordinamento dei dati sulla visualizzazione e non sulla query, dall’interfaccia grafica e non da SharePoint Designer. In teoria ci sarebbe un parametro specifico per ciascuna di queste funzionalità, ma in pratica non sono mai riuscito ad utilizzarli (mancanza mia? bug? Più probabile la prima, ma è da molto che regolarmente faccio dei tentativi, tutti vani…). Se non impostato viene considerato come valore di default la visualizzazione predefinita;
  3. rowLimit [Opzionale]: Permette di specificare il limite di elementi da selezionare. Mooolto importante dal mio punto di vista in quanto sovrascrive il limite impostato nella visualizzazione specificata in precedenza. Ad esempio, se la vostra visualizzazione ha un limite di 100 elementi visualizzati potrete impostare quì un valore molto più alto, per essere certi che vengano mostrati tutti i dati. Da quello che ho potuto constatare, per quanto riguarda il limite di elementi nella visualizzazione, non si tratta di un valore assoluto, ma anche del valore di elementi per pagina. Di conseguenza, per evitare di correre il rischio di avere visualizzazioni con un numero eccessivo di elementi trovo importantissimo valorizzare questo parametro.Questa caratteristica non è un bug, ma è dovuto al fatto che il metodo GetListItems supporta la pagina lato server. Oggi ho scoperto (mio malgrado) un’altra caratteristica che deriva da questo parametro, cioè che anche per i campi di lookup pare valga la stessa logica. Mi spiego: tra i dati che visualizzo è presente una colonna di tipo lookup. La lista di riferimento di questo metadata ha più di 100 elementi e nella visualizzazione di default è impostato proprio questo limite di elementi per pagina. Bene (‘nsomma), nella mia dataform venivano visualizzati solo i dati di lookup presenti nella prima paginazione. In questo caso ho dovuto scegliere la strada più veloce, modificare cioè le impostazioni sulla vista, ma sicuramente in un momento di maggiore calma provvederò a correggere i parametri della dataform;
  4. WebId [Opzionale]: Se valorizzato permette di ridefinire lo scope di azione del servizio, agendo cioè su siti differenti da quello utilizzato per la connessione;

Ho omesso da questo elenco quei parametri che mi hanno sempre causato errori (query, viewFields, QueryOptions). Nel caso dovessi riuscire nei prossimi giorni sarò più che lieto di farvelo sapere :)

-Riccardo