Nuove CU per SharePoint 2007 e 2010

La scorsa settimana Microsoft ha rilasciato nuovi cumulative updates (October 2010 CU) per SharePoint 2007 (WSS e MOSS) e SharePoint 2010 (SPF, SharePoint Server e Project Server). Di seguito trovate i link alle pagine di descrizione delle kb relative a questi aggiornamenti.

  • KB 2412268 – WSS 3.0
  • KB 2412267 – MOSS 2007
  • KB 2394323 – SharePoint Foundation 2010
  • KB 2394320 – SharePoint Server 2010
  • KB 2394322 – SharePoint Server 2010 con Project Server

Ed ecco anche i link per scaricare i pacchetti completi delle CU di ottobre 2010:

Oltre a ricordare la consueta dose di prudenza e cautela nell’installazione di questi update, che ricordo essere relativi alla correzione di problemi specifici descritti nelle rispettive kb, ricordo anche che per SharePoint Server 2010 è sufficiente installare i soli pacchetti di SharePoint Server in quanto sono già comprensivi degli update per SharePoint Foundation.

Consiglio anche di aggiungere ai preferiti il link al centro aggiornamenti relativo alla famiglia di prodotti Office e Office Server.

Happy patching :)

– Riccardo

Mind the underscore

L’intenzione del titolo di questo post è di rifarsi alla vocina della metropolitana londinese che ti ricorda in continuazione “mind the gap, mind the gap, mind the gap…”. Cosa c’entra con SharePoint? Niente, ma oggi per l’ennesima volta sono incappato in un problema stupidissimo legato al carattere “underscore”, per gli amici “_”.

Sebbene questo “fetuso” (termine tecnico diffuso tra Sondrio e Morbegno) sia un carattere ritenuto valido nell’assegnazione dell’url di una web application (ricordo che i caratteri segnalati come non validi sono # % & * { } : < > ? / + ) il suo utilizzo in un sito SharePoint (certo, perchè un dominio web con l’underscore non lo registri manco alle isole Tuvalu) può causare nausea e forti dolori intestinali.

Nello specifico io ho riscontrato due problemi che mi hanno fatto perdere anche troppo tempo. Uno relativo ai workflow ed uno ad InfoPath Form Services. Nel primo caso cercando di creare un flusso di lavoro partendo da uno dei template OOTB ottenevo la tristemente famosa pagina “Unknown error”, nel secondo caso, tentando di aprire un modulo InfoPath via web, Form Services mi avvertiva che non poteva aprire il form perchè il mio browser non aveva abilitati i cookies. Un fatto curioso è che utilizzando FireFox il modulo veniva aperto correttamente (ma visualizzato da schifo :)).

Prima di ricordarmi dell’ultimo mal di pancia ho provato di tutto, scomodando anche colleghi ed amici, stavo per ricorrere alla configurazione “cookieless” agendo a livello di web.config. Per fortuna mi è tornata in testa quella vocina insistente, mind the underscore, mind the underscore, mind the underscore…

Per la cronaca la risoluzione del problema è banale, modificare l’indirizzo lato Central Administration negli Alternate Access Mappings, in IIS e nel DNS.

– Riccardo

Controlli di validazione in custom list form

Cari site builder in ascolto, vi è mai capitato di ricevere richieste di poter inserire controlli per la validazione dei dati inseriti in una lista SharePoint? Forse la domanda giusta sarebbe stata “quante volte”…

Inserire controlli di validazione è molto più semplice di quanto possiate immaginare, anche se bisogna tenere in considerazione un paio di aspetti. Ma andiamo per ordine, nelle prossime righe andremo a creare una custom list form nella quale verificheremo la correttezza (formale) di un indirizzo e-mail inserito dall’utente. Tralascio le azioni preliminari di creazione e configurazione della lista, che chiamerò ValidationControls, sapete come si fa vero? :)

Da SharePoint Designer apro il file NewItem.aspx relativo alla mia lista (in un progetto reale difficilmente aprirei e apporterei modifiche direttamente a questo file, chiudete un occhio se potete). Una volta nascosta la form originale (selezionando “Hidden” dalle proprietà della web part), inserisco una nuova custom list form selezionando la lista, il content type e il tipo di azione da supportare (in questo esempio non mi preoccuperò della magagna Attachment, chiudete l’altro occhio, ok?). Dal menù “Task Panes” di SPD seleziono “Toolbox” che mi farà apparire la lista di tutti i controlli disponibili per il mio sito, tra cui anche i controlli di validazione. Tra quelli disponibili aggiungerò alla mia custom list form un controllo di tipo “RegularExpressionValidator” che mi permetterà di sfruttare la grande flessibilità delle regular expressions.

 

A questo punto possiamo fare una prima prova (che fallirà tanto quanto la traversata del Titanic), inserire un controllo di validazione e legarlo manualmente ad un form field esistente. Nel tag <asp:regularexpressionvalidator … /> aggiungo manualmente la proprietà ControlToValidate ed inserisco come valore l’id del form field relativo alla colonna CustomerEmail. Riusltato: un errore che a seconda della configurazione del vostro web.config potrebbe apparire circa così:

Per fare in modo che il controllo di validazione non causi danni dovrò modificare il tipo di campo di input a cui lo voglio legare, trasformando il form field in Text Field. Per fare questo espando il menù “Common FormField Actions” e seleziono da “Format as” > “Text Box”.

A questo punto riconfiguro il controllo di validazione in modo che sia legato al nuovo campo di testo. Alcuni dei parametri più importanti sono ControlToValidate (permette di specificare quale campo di input debba essere validato), ErrorMessage (permette di specificare il messaggio di errore) e a mio parere anche Display (permette di specificare l’ingombro del controllo quando non visualizzato). Abbiamo inoltre la possibilità di impostare svariati parametri legati all’aspetto del messaggio che al momento tralascio.

Faccio un discorso a parte per il parametro “ValidationExpression”. Questa impostazione servirà per specificare il tipo di controllo da effettuare e nello specifico la regual expression che deve essere verificata. SPD ci viene incontro fornendoci un limitato numero di controlli preconfigurati, tra i quali (ma guarda un po’) anche il controllo sul formato dell’indirizzo e-mail.

Una volta salvata la pagina, provando ad inserire un dato diverso da un indirizzo e-mail otterremo il messaggio di errore configurato.

In questo esempio ho utilizzato un controllo di tipo RegularExpressionValidator in quanto abbiamo già a disposizione un pattern di verifica accettabile. Nel caso di controlli personalizzati (ad esempio lunghezza minima e massima di una stringa) all’interno di una custom list form non potremo usare una RegEx, a causa di caratteri “speciali” riservati ad XSL come ad esempio le parentesi graffe. Un modo per aggirare l’ostacolo può essere quello di utilizzare il controllo CustomValidator che ci permette di specificare una funzione JS che si occupi per noi di tutte le verifiche necessarie e, in questo caso, il solo limite è la fantasia di chi ci commissiona i progetti :D

– Riccardo

Politiche di supporto per farm WSS pre SP2 e CU Dicembre 2009

Oggi mi è capitato sotto mano un post molto interessante di Stefan Goβner che parla delle politiche di supporto per farm WSS v3 pre SP2. Vi rimando al suo post per leggere anche le risposte ai commenti che sono stati inseriti, anche queste molto interessanti.

Riassumendo: al rilascio di WSS sp1 è stato annunciato (http://support.microsoft.com/lifecycle/#ServicePackSupport) che il prodotto sarebbe uscito dal supporto un’anno dopo il rilascio del prossimo service pack. L’SP2 è stato rilasciato ad Aprile 2009, quindi siamo quasi alla fatidica data.

Cosa dite? Ci sarà un “decreto mille proroghe” anche per il supporto a SharePoint sp1? :)

Intanto che si parla di updates, da pochi giorni sono disponibili i pacchetti Cumulative Updates di Dicembre 2009. Trovate maggiori informazioni a questi indirizzi:

WSS
http://support.microsoft.com/default.aspx?scid=kb;EN-US;977027

MOSS
http://support.microsoft.com/default.aspx?scid=kb;EN-US;977026

Mi raccomando, prudenza ;)

– Riccardo