L’incident auquel j’ai été confronté aujourd’hui m’a permis de remettre les mains sur SharePoint, un outil sur lequel j’ai pas mal travaillé les premières années de ma – encore courte – carrière. Les Office WebApp étaient hors service ce matin sur la ferme SharePoint, que ce soit Excel, Word ou l’ouverture d’un PDF, nouveau fichier ou ancien, rien n’était accessible.
 |
| Pour Word, le message d’erreur était plutôt clair : il y a une erreur de configuration empêchant d’ouvrir le document |
 |
| Pour Excel, un fond indiquant une erreur serveur et un chargement infini avec les points défilant sous « Excel Web App » |
Pour expliquer grossièrement comme cela fonctionne, les WebApp sous SharePoint fonctionnent grâce à un serveur sur lequel on installe ces WebApp en question. Puis sur le serveur applicatif de SharePoint, on interroge le serveur sur lequel sont installés les WebApp ; le serveur SP fait ensuite le lien et sait qu’il doit exécuter les WebApp depuis le serveur lorsqu’un utilisateur demande à ouvrir un fichier Word, un PDF, ou tout autre fichier pris en charge. Chez Microsoft, ce serveur WebApp est nommé WAC.
Sur le WAC, j’ai pu analyser les logs, qui se trouvent dans C:\ProgramData\Microsoft\OfficeWebApps\Data\Logs\ULS ; j’avais pas mal d’erreurs qui ont bien brouillé les pistes et m’ont donné du fil à retordre. Mais tout d’abord, vérifier le bon fonctionnement du WAC, en interrogeant cette URL :
https://<SERVEURWAC.domain>/hosting/discovery
Ce qui nous renvoie quelque chose comme ceci :
Le serveur WAC est donc opérationnel. En creusant un peu les logs grâce à l’outil Microsoft ULSViewer qui permet de les lire plus facilement – et surtout, en temps réel – je tombe sur cette erreur :
Le UPA ou User Profile Application est un service qui gère les utilisateurs, les groupes et les droits qui en découlent. Pour le gérer, il faut se rendre sur l’administration centrale de SharePoint. Pas de chance, je n’ai rien pu configurer ou visualiser :
J’ai donc redémarré les deux frontaux SP, ce qui a corrigé cette erreur, mais toujours pas rendu l’accès à mes WebApp. Retour aux logs, et je tombe sur ceci :
Il semblerait donc que le fichier soit introuvable. Pourtant, le WAC fonctionne bien, et les fichiers existent, de plus les tests ont également porté sur des fichiers nouvellement ajoutés au site SP. Les relances de service « Office Web Apps » n’ayant rien donné, je décide donc de regarder le lien entre le backend SP et le WAC. En utilisant le SharePoint Management Shell qui utilise PowerShell sur le serveur backend SP :
Get-SPWOPIBinding
Cela renvoie les liens entre la ferme SP et le WAC. On obtient plusieurs infos : le type de fichier, le type d’ouverture demandé (consultation, écriture…), les conditions (HTTP ou HTTPS, interne/externe)… En apparence tout semble bien lié, cependant en détruisant le lien et en le recréant, tout s’est remis à fonctionner :
Remove-SPWOPIBinding -All $:true
On confirme la suppression du lien, les WebApps qui étaient plantées ne fonctionnent plus du tout car le SP n’en a plus connaissance. Puis on recrée ce lien :
New-SPWOPIBinding -ServerName <SERVEURWAC.domain> -AllowHTTP
En sortie d’instruction, tous les liens vont défiler, en réalité l’instruction se base sur le retour XML que l’on a vu plus haut. Les WebApp refonctionnent désormais.
Si jamais en lançant le SharePoint Management Shell il apparaît un message « The Local Farm is not accessible », cela signifie que le compte utilisé pour lancer la console n’est pas le compte d’administration de la ferme SharePoint, il faut donc l’utiliser autant que possible, en ouverture de session ou en runas.