L'histoire des salles de conférence surbookées

Cet article a été publié pour la première fois chez pr itk publié et y a été consulté environ 10 000 fois.

Temps de lecture : 18 minutes

Dernière mise à jour il y a 7 mois par Patrick Ruppelt

Cet article se réfère essentiellement à la constellation dans laquelle les utilisateurs accèdent à un serveur Exchange 2007 (ou en partie à d'autres versions d'Exchange) avec ton client Outlook (Outlook 2010, Outlook 2007, Outlook 2003).

Exchange offre la possibilité de définir des ressources. Toute une série de ressources sont déjà disponibles, tout comme les ressources de salle, c'est-à-dire les salles. C'est super si l'utilisateur inscrit simplement un nouveau rendez-vous dans son agenda, invite les participants et sélectionne une salle correspondante comme ressource. Si la salle est occupée, l'utilisateur le voit déjà dans la chronologie qu'apporte un Office Outlook actuel. Exactement comme tu en as l'habitude avec les autres utilisateurs.

Or, il est censé arriver qu'au même moment deux équipes se trouvent devant la même salle de réunion et affirment tous deux que chez eux, le rendez-vous est pourtant inscrit et confirmé dans le calendrier. Tu ne peux pas ? L'un des deux ment ? Non ! C'est possible. Exchange peut vraiment donner l'impression à deux équipes qu'elles ont toutes les deux réservé une salle et que celle-ci est réellement inscrite dans leur calendrier respectif comme étant réservée. Passionnant, n'est-ce pas ?

Pour trouver la cause, il faut aller un peu plus loin. Ce n'est pas aussi simple qu'il n'y paraît au début. La gestion des ressources suit une logique assez stricte, si je peux m'exprimer ainsi en tant que non-technicien. D'une part, la nature technique dans la mesure où les différents paramètres sont de nature booléenne. D'autre part, l'intention de l'administrateur lors du paramétrage suit également des règles booléennes.

Mon raisonnement est un peu confus, je l'illustre avec quelques extraits d'un - oui, presque un pamphlet - de Murat Gunyar. Sur le blog de l'équipe Exchange, il a rédigé un excellent article. Article Je pense qu'il est très instructif, informatif et parfois absurde. Même si l'absurdité vient plutôt du fait que la technologie est au maximum aussi bonne qu'elle a été développée. Je cite :

Note : Lorsque le cmdlet Set-MailboxCalendarSettings est relancé pour modifier n'importe quel paramètre, les permissions du délégué d'origine sont supprimées. Le délégué est toujours affiché lors de l'exécution de la cmdlet 'Get-MailboxCalendarSettings'. Cependant, si tu regardes les permissions sur le calendrier de la ressource, les permissions du délégué ont été supprimées.

Cela signifie quelque chose comme ceci : Tu définis de nouveaux paramètres dans Powershell, par exemple parce que tu veux changer un petit quelque chose. Mais cela ne fonctionne pas si facilement, car Set-MailboxCalendarSetting remplace simplement tous les paramètres précédents par le nouveau. Il n'y a donc pas d'"ajout" mais un "remplacement". C'est peut-être l'une des subtilités que tous les administrateurs Exchange connaissent. Bon, si tu n'es pas admin, tu n'as pas besoin de le savoir, mais je trouve que c'est intéressant pour tous ceux qui lisent cet article simplement par intérêt ou curiosité. Revenons-en au sujet. Il y a donc un "remplacement". C'est bien. Et ensuite ? La commande est exécutée telle qu'elle a été conçue, les anciennes autorisations, par exemple, n'existent alors plus.

Quel est le rapport avec un calendrier surbooké ? Eh bien, il y a la commande Get-MailboxCalendarSettingsqui affiche - wonder why - les paramètres. Malheureusement, cette commande affiche à nouveau pas afficher les paramètres modifiés. Pour les voir, il faut regarder les autorisations dans le calendrier de la ressource. Et maintenant, en toute honnêteté : quel admin le fait... ?

O. k., il est vrai que cela n'a pas encore beaucoup de rapport avec les calendriers surbookés, mais nous nous rapprochons de la solution. Car maintenant, nous avons atteint un point assez central dans Exchange Server et nous pouvons commencer à chercher les causes possibles.

New-Mailbox -database "Storage Group 1Mailbox Database 1" -Name ConfRoom1 -OrganizationalUnit "Conference Rooms" -DisplayName "ConfRoom1" -UserPrincipalName ConfRoom1@contoso.com -Room

Ce serait un exemple simple directement tiré de Microsoft TechNet sur le thème "comment créer une boîte aux lettres de salle". Mais quand est-ce que je me retrouve chez un client, avec le phénomène de surréservation et que je peux m'asseoir tranquillement et recréer les boîtes aux lettres moi-même. J'aurais pu le faire hier chez mon client - où ce problème s'est produit - avec plus de 3000 utilisateurs et je ne sais pas combien de salles de conférence. Amuse-toi bien.

Essayons donc de voir comment sont aménagées les pièces. Cela permet de savoir quelles sont les salles concernées. Mais l'utilisateur qui a signalé l'erreur ne peut généralement pas te le dire. Il ne le sait pas lui-même, car il s'occupe de tant d'autres choses chaque jour, pourquoi se préoccupe-t-il de l'informatique ? Solution : exécuter grep sur toutes les ressources avec tous les indicateurs pertinents, tout mettre dans un fichier Excel et l'évaluer. Évaluer ? Comment, c'est la question.

Phase 1 : quelles sont les boîtes aux lettres qui sont des salles en fait. Les salles ne s'appellent pas toujours ainsi. La liste doit d'abord être complète pour que la recherche ait un sens. Tout ce qui est un -room n'est pas si mal que ça. Il y a beaucoup de chemins qui mènent à Rome. Il y a aussi des boîtes aux lettres d'équipement - et une confédération peut en principe être considérée comme telle. On peut aussi réaliser des espaces via des boîtes aux lettres partagées, ou créer des utilisateurs propres pour cela et les utiliser à leur tour comme boîte aux lettres de groupe avec calendrier. Mais le plus important, c'est que le géant de Redmond a déjà pensé à quelque chose en proposant des assistants et des fonctions spéciales qui font exactement ce que tu veux.

Phase 2 : Nous avons donc maintenant des espaces. Leur comportement dépend des paramètres définis. Microsoft a une liste assez complète dans le TechNet Mais cela va un peu trop loin pour un blog qui s'appelle social techblog from an economic point of view. C'est pourquoi je résume ici le principe de base qui explique comment et pourquoi les espaces se comportent de manière autonome. Le chien doit être enterré quelque part.

Paramètre important numéro 1 : AutomateProcessing

Ce paramètre détermine comment

• None : La réservation de ressources et le Calendar Attendant, qui ajoute automatiquement les nouvelles réunions au calendrier, sont tous deux désactivés sur cette ressource. En d'autres termes, ils ne font rien, toutes les demandes restent dans la boîte aux lettres de la ressource jusqu'à la fin des temps.
• AutoUpdate : la valeur par défaut accepte toutes les demandes sous réserve et attend ensuite que le rendez-vous soit confirmé par le délégué. L'organisateur de la réunion reçoit l'info du delegate.
• AutoAccept : Et c'est là que ça devient vraiment intéressant. La réservation de la ressource se fait au niveau de la boîte aux lettres spatiale. Les demandes entrantes sont traitées en fonction des politiques (directives). Dans ce mode - et seulement dans ce mode - l'organisateur de la réunion reçoit effectivement la confirmation de la salle elle-même.

Jusqu'ici, cela semble évident et logique, du moins une fois que l'on a réfléchi à la meilleure façon de mettre en œuvre une telle chose. Mais comment un AutoAccept peut-il fonctionner pour donner des résultats acceptables dans la pratique ? Il y a un autre paramètre qui n'est pas innocent dans le fait que tu peux surréserver des salles.

Numéro 2 : Politiques de réservation de ressources

Ici aussi, je ne fais qu'un résumé très succinct, que l'on ne me reproche pas de ne pas fournir des informations techniques 100% correctes. Les politiques définissent un statut "InPolicy", c'est-à-dire conforme, et un statut "OutOfPolicy", c'est-à-dire non autorisé. Autorisé ou non peut se définir par des plages horaires (réunions uniquement pendant les heures de travail), surréservation (oui/non et oui, oha, on peut aussi tout à fait définir qu'une surréservation est autorisée. Mais cela serait vraiment trivial comme cause de surréservation), durée (c'est-à-dire combien de temps dure la réunion - par exemple, toutes les réunions de plus de 2 heures nécessitent l'autorisation du supérieur), etc.

Et pour rendre l'histoire vraiment confuse - non, en fait, juste pour que ce soit pratique - on fait une autre distinction à ce moment-là :

• BookInPolicy : cette liste d'utilisateurs (groupes, AD, ...) peut inscrire des réunions InPolicy et celles-ci sont aussi automatiquement acceptées.
• RequestInPolicy : Semblable à BookInPolicy, mais une approbation par le délégué est nécessaire pour que la réservation soit confirmée.
• RequestOutOfPolicy : Ici, le schéma est un peu différent, ces utilisateurs peuvent demander n'importe quelle chose et si le délégué l'approuve, alors c'est bon. Je suppose que Microsoft a introduit cette option pour les comités d'entreprise, le conseil d'administration et la direction. Ou pour les bourreaux de travail qui, par nature, restent assis dans la salle de réunion même le dimanche.

Maintenant, nous sommes allés si loin qu'il est logique de réfléchir encore une fois à la manière dont une surréservation peut se produire. Murat a rédigé une conclusion dans son billet de blog sous la forme d'un tableau sur les possibilités utiles. Je te recommande de lire cet article là aussi, car il est vraiment bon.

Le fait est - qu'est-ce qui est logique ?

• Réservation automatique : AutoAccept > AllBookIn True > AllRequestIn False. Délégué : aucun
• Manual Approval : AutoAccept > AllBookIn False > AllRequestIn True. Delegate : devrait être défini
• Manual Approval : AutoUpdate > AllBookIn True > AllRequestIn False. Délégué : aucun

Ce n'est pas si facile à résumer, car même sur TechNet, la question a été souvent posée. C'est là que la technique s'arrête et que la logique entre en jeu !

Si tu évalues maintenant tes centaines de salles de conférence, tu en trouveras toujours qui ne proviennent peut-être pas du serveur Exchange actuel mais d'un 2003. Là aussi, les ressources étaient différentes. Ou même d'un Exchange encore plus ancien ? Ou bien quelqu'un d'autre a créé les comptes, ou bien ils ont été paramétrés différemment.

Un exemple montre ce qui se passe lorsque l'on ne tient pas compte de la logique - et qui peut finalement donner lieu à des choses intéressantes comme une double réservation par un système technique. Ce qui est intéressant, c'est qu'il suffit d'examiner la situation de ce point de vue et de se demander ce qui est "le plus susceptible d'arriver". Il existe toute une série de constellations qui conduisent à ce que quelque chose se passe mal. doit.

Prenons le cas 1 : AutoAccept > AllBookIn True > AllRequestIn False. Délégué : aucun

Définissons AllBookIn comme False. Que se passe-t-il ? Quelqu'un veut planifier un rendez-vous. Quelle que soit la liste BookIn dans laquelle il se trouve, il n'y a pas de délégué qui puisse approuver quoi que ce soit. Il ne peut pas non plus s'inscrire de manière régulière, et encore moins en tant que RequestIn. Que se passe-t-il dans la pratique : Le meilleur cas d'erreur de réservation : un message d'erreur qui dit que les droits ne sont pas suffisants pour réserver ce rendez-vous.

Cas 2 : Par contre, prenons un cas vraiment mauvais - Approbation manuelle : AutoAccept > AllBookIn False > AllRequestIn True. Delegate : devrait être défini, mais ne l'est pas.

Et voici le cas qui combine tellement de coïncidences qu'il est à la fois passionnant de voir le résultat et extrêmement difficile d'en déterminer directement la cause dans la pratique. Voici ce qui se passe :

• L'employé 1 inscrit un rendez-vous. AllBookIn false ne provoque donc qu'une acceptation provisoire grâce à AutoAccept. L'organisateur reçoit un e-mail dans sa boîte aux lettres indiquant que le rendez-vous a été provisoirement confirmé. Le rendez-vous est enregistré dans le calendrier de l'employé. Dans les détails du rendez-vous, tu peux voir ton propre temps ainsi que celui des participants comme étant réservé. Dans la ligne de temps, tu peux aussi voir la salle de réunion. La duplicité : L'affichage d'Outlook à cet endroit semble être incohérent, ou alors il est lié à tes propres paramètres d'affichage. Le fait est que l'utilisateur ne voit pas que la salle elle-même est encore "sous réserve".
• L'employé 2 inscrit un rendez-vous. Je pourrais maintenant copier le texte de l'employé 2. Le fait est que tout semble parfait, mais ce n'est pas le cas. En fait, je dois avouer que mon titre est peut-être un peu trompeur, car Exchange n'a pas enregistré deux rendez-vous en même temps. Mais pour les utilisateurs, tout semble vraiment correct - pour les deux équipes. Nous l'avons testé pendant plusieurs heures et avons pu le reproduire dans toutes les constellations possibles.

Que se passe-t-il maintenant ? Car le chemin des dubianités est loin d'être terminé. Les deux employés retournent à leur travail sans penser à mal.

Tous les trop Les collaborateurs invités aux deux dates De toute façon, je pense que la date conviendra, parce qu'il y a une date limite. un organisateurJe suis sûr qu'il va s'en occuper.

Dans tous les calendriers, la date est réservée. Pour voir que quelque chose ne va pas - si on le cherchait explicitement - il faudrait déjà comme organisateur regarder les détails du rendez-vous et étirer la ligne de temps sur un écran d'au moins 22″ jusqu'à ce que l'on puisse voir de toutes petites hachures sur la salle que celle-ci n'a pas encore accepté. Les employés voient en effet - Dubiosité numéro X - la salle comme étant réservée. Et comme réservée. Je suppose que les participants voient ce statut comme ça (et supposent donc que tout se passe bien) parce qu'ils ne voient pas leur propre statut de salle, mais seulement le fait que la salle a été réservée en principe. Mais par l'équipe qui était là en premier. En d'autres termes : les participants invités à la réunion 2 n'ont définitivement pas reçu d'annulation, ils voient la date, les participants et la salle dans tous leurs calendriers. Les participants invités à la réunion 1 voient exactement la même chose, sauf qu'ils voient probablement le statut réservé de la salle d'eux-mêmes.

Jusqu'ici, tout va bien. C'est un peu étrange, mais si les paramètres étaient correctement définis, cette situation ne durerait pas longtemps. En fait, c'est là qu'intervient le délégué. Il reçoit le conflit dans sa boîte aux lettres, car en tant que délégué, il travaille comme représentant de la salle et doit prendre une décision.

Ah oui - une parenthèse intéressante : même si c'est le cas et qu'il envoie une annulation, l'organisateur du rendez-vous doit quand même agir. Cela ne change rien aux entrées du calendrier de toutes les personnes concernées. En d'autres termes, il s'agit encore d'une prétendue double réservation. Dubios.

Retour au sujet principal. Le délégué n'est pas inscrit, le mail de décision est bloqué dans la file d'attente de la salle et aucune escalade n'est prévue. Il ne se passe donc rien.

Qu'est-ce qui est prévu dans un tel cas ? Rien du tout. Car il s'agit d'une mauvaise conception du système de règles mis en œuvre par l'administrateur d'un point de vue logique. Un tel processus ne devrait jamais se produire. Et cela signifie en clair : les deux organisateurs ont reçu une promesse provisoire. Il n'y a jamais eu de refus. Et dans tous les calendriers, tout semble correct. Ergo : les deux équipes seront au même endroit au même moment et les deux ont également raison. Dubios.

Et nous ne sommes pas encore au bout de nos peines - j'ai encore une curiosité en réserve. La plupart des clients n'utilisent pas Exchange depuis hier, mais ont déjà utilisé les versions précédentes. Il était courant que les départements aient un ou plusieurs employés qui s'occupaient des calendriers des salles de conférence. La plupart du temps, ceux-ci étaient simplement ouverts en tant que boîte aux lettres supplémentaire, et même dans ce cas, il n'y aurait plus ce surbooking. Seulement, ce n'est pas prévu ainsi. Bien sûr, cela fonctionne, mais seulement tant que le calendrier est ouvert quelque part - comme "propriétaire". Si l'employé quitte la maison, c'est fini. Ce cas n'est jamais documenté, en tout cas je ne l'ai jamais vu en 15 ans... Et ensuite ? Ensuite, tu as une salle de conférence orpheline qui a apparemment fonctionné pendant des années (bien que mal configurée), et puis tu as un problème. "tout à coup" ne fait plus son travail et permet des surréservations.

Pas douteux : Comme toujours, l'erreur est humaine.