Augmentation de la taille des mails sur Office 365

Posted on 20/04/2015 by nicolas

Bonjour,

L’équipe Office 365 a annoncé l’augmentation de la taille maximum des mails de 25 Mo à 150 Mo.
Si cela peut paraître intéressant à première vue, l’usage devrait cependant resté anecdotique.

En effet, l’intérêt d’une solution collaborative comme Office 365 réside dans le fait que l’on peut très facilement déposer un fichier dans SharePoint Online et le partager avec ses collaborateurs en envoyant un lien vers ce document par mail.

Plusieurs avantages à cela. Tout d’abord, chacun est sûr de toujours visualiser la dernière version du document. Ensuite, on m’encombre pas sa messagerie avec de multiples copies du même document dans autant de boîtes mails que de destinataires.

Cependant, dans certains scénarios, cela peut s’avérer utile. Par exemple un client qui souhaite m’envoyer un gros document, que je pourrai pas la suite stocker dans Office 365 et partager avec lui en utilisant la fonction de partage avec des utilisateurs externes.

http://blogs.office.com/2015/04/15/office-365-now-supports-larger-email-messages-up-to-150-mb/

SharePoint et Windows Update (Suite)

Posted on 06/03/2015 by nicolas

Bonjour,

Dans mon billet SharePoint et Windows Update, j’annonçais que les mises à jour de SharePoint (CU) descendait par Windows Update (et WSUS). Cela était problématique pour plusieurs raisons : cela peut nécessiter l’application d’un PSCONFIG sur tous les serveurs de la ferme SharePoint (occasionne une interruption de service), désynchroniser les niveaux de CU des différentes fermes SharePoint s’ils ne sont pas descendus en même temps sur toutes les fermes, et occasionner des dysfonctionnements s’ils contiennent un problème qui aurait dû être détecté lors d’une application par staging dév / intégration / recette / production.

Microsoft a décidé de revenir en arrière sur ce fonctionnement, et de ne plus publier les CU automatiquement par Windows Update à partir de Mars 2015. Les patchs de sécurité continuent toutefois d’être publiés.

Merci à Stephan Goßner pour l’information : http://bit.ly/18WkEKx

Optimisation JQuery et DOM

Posted on 01/03/2015 by nicolas

Bonjour,

Ce billet pour parler d’un problème rencontré trop souvent dans un code JavaScript lors du développement d’une application web avec JQuery.

Le problème

Mon client me dit que le temps de chargement d’un page est trop long, et me demande si je peux le diminuer.

L’analyse

Je regarde la page en question, et découvre du code JavaScript dont j’ai extrait les lignes suivantes :

for (var i = 1 ; i <= 1000 ; i++)
        $('#test').Append('<h1>Test' + i + '</h1>');

Je note un 1^er problème :

A chaque passage dans la boucle, je parcours le DOM avec le code #(‘test’)

Nous pouvons optimiser ce code de la manière suivante :

var test = $('#test');
for (var i = 1 ; i <= 1000 ; i++)
        test.Append('<h1>Test' + i + '</h1>') ;

Ce code est plus optimisé puisque j’évite de parcourir le DOM en sauvegardant le résultat de la requête JQuery dans une variable que je réutilise. De cette manière, je ne parcours le DOM qu’une seule fois.

Je note toutefois un 2^ème problème dans ce code :

A chaque passage dans la boucle, j’ajoute une chaine dans le DOM. Je pourrais concaténer les chaines HTML en amont, ce qui donnerait :

var chaine = '';
for (var i = 1 ; i <= 3 ; i++)
        chaine += '<h1>Test ' + i + '</h1>';
var test = $('#test');
test.Append(chaine);

Ce code est plus optimisé puisque j’évite de manipuler le DOM plus que nécessaire.

Conclusion

Lors du développement d’une application JavaScript, une app SharePoint par exemple, 2 points d’attention doivent retenir votre attention :

Minimiser le parcours du DOM
Eviter la manipulation excessive du DOM

Il y a d’autres points importants pour l’optimisation de son code, points sur lesquels je reviendrai dans de futurs posts, mais nous avons ici une 1^ère base.

SharePoint et Windows Update

Posted on 27/02/2015 by nicolas

Bonjour,

Un post pour parler d’un problème rencontré lors de la restauration d’une sauvegarde SharePoint sur l’une de mes fermes.

L’histoire
Mon client me demande de lui mettre à disposition un site de production sur une plate-forme de recette pour faire des tests. Je lui propose de faire cela rapidement mais, oh surprise, cela ne fonctionne pas.

L’analyse
Après analyse, je me rends compte que :
– Les fermes SharePoint ne sont pas dans la même version
– Un PSCONFIG est nécessaire sur la ferme source pour finaliser l’installation d’une KB
– Une KB est descendue par Windows Update.

Hors la restauration d’une sauvegarde effectuée avec la commande Backup-SPSite nécessite que la ferme d’origine soit dans une version de SharePoint inférieure ou égale à la version de la ferme destination. Si tel n’est pas le cas, la restauration de la sauvegarde par la commande Restore-SPSite ne fonctionnera pas.

En regardant la description de la KB, aucune information concernant la nécessité d’appliquer un PSCONFIG après l’application de la KB.

Conclusion
Microsoft publie depuis peu des mises à jour de SharePoint au travers de Windows Update (et donc de WSUS), et cela peut nécessiter l’application d’un PSCONFIG sur tous les serveurs de la ferme. Il faut donc prendre en compte ce nouveau flux dans les processus de mise à jour des fermes afin de contrôler le niveau de CU de chacune de ses fermes et d’éviter les surprises.

Kurt Mackie a fait un très bon résumé de la problématique dans cet article: http://redmondmag.com/articles/2015/02/13/pushing-sharepoint-server-updates.aspx

[edit] Microsoft ne publie plus les CU par Windows Update, voir ce billet : http://bit.ly/18WkEKx