Blocage dans O365 de l’envoi et de la réception de mails en dehors des heures de travail, soit le soir et le weekend (Mis à jour le 10/02/2017)


Introduction

Ce type de demande peut faire suite à des accords signés entre les partenaires sociaux et la direction avec comme référence l’article relatif au Droit à la Déconnexion de la loi El Khomri entrée en vigueur au 1er Janvier 2017.

https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000032983213&fastPos=1&fastReqId=319181516&categorieLien=id&oldAction=rechTexte – LOI n° 2016-1088 du 8 août 2016 relative au travail, à la modernisation du dialogue social et à la sécurisation des parcours professionnels

https://www.legifrance.gouv.fr/affichTexteArticle.do;jsessionid=FFF451BC1BFC344F068FF87F8136ADE6.tpdila08v_1?idArticle=JORFARTI000032984268&cidTexte=JORFTEXT000032983213&dateTexte=29990101&categorieLien=id – droit à la déconnexion

De plus chaque accord d’entreprise contient des spécificités (par exemple : envoi possible mais pas de réception avant le lendemain matin ou le lundi matin, pas d’accès aux mails du tout, alertes à émettre,  gérer des exceptions pour certaines catégories de personnel, etc…). Il n’est donc pas possible de répondre de manière unique à toutes les demandes.

Comment alors mettre en œuvre ce type de demande dans un environnement mutualisé comme O365 ?

Le Groupe Produit n’a rien prévu de tel dans O365 pour le moment et n’est pas enclin actuellement à implémenter quoi que ce soit. Cela se comprend dans le sens où même si une fonctionnalité existait, chaque client aura ses demandes spécifiques selon ses besoins et pas question de spécificité dans un univers mutualisé.

Voici des suggestions et non des solutions avec leurs avantages et inconvénients afin de vous donner quelques idées sur le sujet. Attention les commandes et comportements évoqués peuvent évoluer dans O365 et nous vous conseillons toujours de les tester. Mais plus important encore, il est primordial de vous faire accompagner par Microsoft avant de mettre en œuvre une quelconque solution pour valider qu’elle soit bien recommandée et supportée par le Groupe Produit.

 

1 – Mise en attente des messages soumis

Cette proposition s’appuie sur la mise en quarantaine des messages sur des critères choisis. Puis de libérer ensuite ces messages.

 

Exemple de commande Powershell qui crée une règle Transport avec comme nom AccordSyndical avec les critères suivants :

– s’applique à tous les messages envoyés par le domaine philphan.onmicrosoft.com (interne)

– est activée tous les jours entre 11h20 et 11h25 (prendre en compte le temps UTC)

– met en quarantaine ces messages

New-TransportRule -name AccordSyndical -SenderDomainIs philphan.onmicrosoft.com -quarantine:$true -ActivationDate ’09:20:00′ -ExpiryDate ’09:25:00′

Les messages dont les expéditeurs ne font pas partie du domaine philphan.onmicrosoft.com sont bien remis dans les BAL.

Les messages envoyés tous les jours entre 11h20 et 11h25 ont été mis en quarantaine que ce soit pour des destinataires internes ou externes au domaine philphan.onmocrosoft.com.

Pour lister les messages mis en quarantaine :

Get-QuarantineMessage

On voit qu’il y a une date d’expiration qui est de 7 jours par défaut.

Maintenant pour relâcher tous les messages du domaine philphan.onmocrosoft.com actuellement en quarantaine :

Get-QuarantineMessage -domain philphan.onmicrosoft.com | Release-QuarantineMessage –ReleaseToAll -verbose:$true -confirm:$false

 

Et les messages sont alors délivrés aux destinataires aussi bien internes qu’externes.

 

Points techniques à prendre en compte (mise à jour du 31 Mars 2016):

  1. Quelles limites peut-on rencontrer (pour la file d’attente, boîtes aux lettres, la taille, la durée de conservation en jours) ?
    Il n’y a aucune restriction sur le nombre et la taille des messages qui peuvent être envoyés en quarantaine.
  2. Est-ce que les messages seront délivrés dans une boîte aux lettres de quarantaine que nous devons créer ? Ou s’agit-il d’une boîte aux lettres système ?
    La quarantaine n’est pas une boîte aux lettres – c’est un fichier hébergé dans Exchange Online Protection.
  3. Combien de temps les mails sont-ils conservés dans la file d’attente ?
    Les messages qui sont mis en quarantaine par le biais d’une règle de transport ont une durée de vie de 7 jours – et ce paramètre n’est pas configurable.
    La quarantaine n’est pas conçue ni destinée pour une libération massive de messages. Le but premier de la quarantaine est que la plupart des mails envoyés en quarantaine ne seront jamais libérés. Considérant qu’il faut quelques secondes pour libérer un seul message, cette fonction n’est pas adaptée si le but d’un tenant Office 365 est de mettre en quarantaine puis de libérer des dizaines de milliers de messages par jour. En effet dans ce cas il y aura un probable retard conséquent dans la remise de tous les messages dû entre autre au throttling lors du relâchement de ce grand nombre de messages. De plus il y aurait trop de limites non supportées par le Groupe Produit concernant le blocage des queues.

 

2 – Génération d’un NDR (avis de non-remise), avec commentaire explicite lors de l’envoi d’un message

Le message envoyé est bien dans le dossier Eléments envoyés de l’expéditeur mais n’est jamais remis, un NDR est généré.

Au bout d’un certain nombre de NDR (avis de non-remise), on peut imaginer que l’expéditeur devrait comprendre qu’il est inutile d’envoyer des mails le WE.

Cette proposition est simple à mettre en œuvre  mais oblige les expéditeurs (surtout externes si le paramètre SenderDomainIs n’est pas spécifié) à renvoyer le message ou à adapter ses usages.

 

Exemple de commande Powershell qui crée une règle Transport avec comme nom AccordSyndical avec les critères suivants :

– s’applique à tous les messages envoyés par le domaine philphan.onmicrosoft.com (interne)

– est activée tous les jours entre 15h45 et 15h50 (prendre en compte le temps UTC)

– rejette ces messages avec génération d’un NDR avec un code statut 7.1.100 et un commentaire personnalisé

New-TransportRule -name AccordSyndical -SenderDomainIs philphan.onmicrosoft.com –ActivationDate ’13:45:00′ -ExpiryDate ’13:50:00′ -RejectMessageEnhancedStatusCode 5.7.100 -RejectMessageReasonText “Les accords syndicaux en vigueur empêchent l’envoi de mails en dehors des heures légales de travail.”

L’expéditeur reçoit alors le NDR avec le commentaire personnalisé.

 

3 – Désactivation des protocoles d’accès à sa boîte aux lettres

Cette proposition consiste à ne plus permettre aucun accès à la BAL quel que soit le client utilisé (Outlook, OWA, terminal mobile, application) : Il suffit de désactiver tous les protocoles d’accès à la boîte aux lettres.

Ceci est illustré en mettant à False tous les « protocolesEnabled » surlignés en jaune ci-dessous.

Exemple de commande Powershell qui désactive le protocole OWA pour l’utilisateur user3 :

Set-CASMailbox -identity user3 -OWAEnabled:$false

Cette proposition permet de ne pas toucher au traitement des messages dans O365, les messages continuent d’être traités et délivrés normalement. Cependant on ne peut éviter les effets des caches implémentés un peu partout car il n’y a pas de possibilité pour les administrateurs de redémarrer IIS ni de recycler les pools adéquats. Nous ne savons pas quand sera effective la prise en compte de la désactivation/réactivation des protocoles, en quelques minutes ou bien plus.

Quelques liens sur le sujet:

La seule manière de bloquer immédiatement l’accès est de retirer la licence – toutes les connexions sont abandonnées automatiquement en quelques secondes, les messages envoyés aux comptes désactivés retournent un NDR et les messages envoyés depuis Outlook/OWA/EAS restent dans les dossiers Brouillons/Boîte d’Envoi.

 

4 – Blocage de l’accès en amont lors du login

Cette proposition « radicale » consiste à ne plus permettre aucun accès lors du login des utilisateurs concernés.

Les étapes suivantes doivent empêcher les usagers de se connecter à leur BAL O365 depuis l’extérieur. Ces usagers peuvent être mis dans un groupe sur lequel une politique sera appliquée.

  1. Ajuster le délai de la connexion à leur compte Active Directory To set logon hours
  2. Restreindre l’accès au service Office 365 basé sur le LAN d’entreprise Limiting Access to Office 365 Services Based on the Location of the Client
  3. Créer les OOF sur les BAL des usagers afin d’avertir les expéditeurs des messages http://superuser.com/questions/623199/how-do-i-set-up-outlook-2010-to-send-auto-reply-based-on-the-time-and-day-of-the

Cette proposition permet de ne pas toucher au traitement des messages dans O365, les messages continuent d’être traités et délivrés normalement. Et la maitrise de l’accès aux comptes reste du côté des administrateurs. Cependant cette proposition n’est pas adaptée si le login est commun à d’autres services que la messagerie par exemple.

 

5 – Addin Outlook

Cette proposition consiste à déporter une solution côté client de messagerie via un développement spécifique. Le grand avantage est qu’on ne touche pas au fonctionnement de O365 et permet de personnaliser ses besoins. Mais cela implique aussi qu’il faille trouver une solution pour les clients/applications autre qu’Outlook afin que les usagers ne puissent pas se connecter à leur BAL via un terminal mobile ou un client Web ou autre.

 

6 – Déplacement des messages dans un dossier caché

Cette proposition consiste à créer un dossier et une règle spécifiques dans la boîte aux lettres de l’utilisateur qui a souscrit à la demande afin d’y déplacer les messages en dehors des heures ouvrées. Et pour pousser la proposition :

  • Cacher ou mettre des permissions sur le dossier et la règle pour éviter que l’utilisateur ne les contourne.
  • Ajouter un envoi de notification pour informer l’expéditeur interne ou externe que le destinataire ne recevra son message que pendant les heures ouvrées.

L’avantage de cette proposition est que les messages sont déjà remis dans les BALs, ce qui évite toute rétention et autre, et que le traitement ne s’effectue qu’après au niveau de la BAL.

Pour les messages entrants:

https://technet.microsoft.com/en-us/library/dd335113(v=exchg.160).aspx – New-MailboxFolder

Utiliser la commande New-MailboxFolder pour créer des dossiers des dossiers dans la BAL des utilisateurs ayant souscrit à l’offre.

Mais attention:

“Use the New-MailboxFolder cmdlet to create folders in your own mailbox. Administrators can’t use this cmdlet to create folders in other mailboxes (the cmdlet is available only from the MyBaseOptions user role).”

Mais cela est possible via EWS

https://msdn.microsoft.com/en-us/library/office/dn535504(v=exchg.150).aspx : How to: Work with folders by using EWS in Exchange

https://blog.lokilabs.net/2014/08/12/creating-folders-in-office365-mailboxes/

Et on peut cacher ce dossier spécifique via EWS

https://msdn.microsoft.com/en-us/library/office/dn659505(v=exchg.150).aspx

On peut d’ailleurs se demander dans quelle mesure on ne pourrait pas cacher tous les dossiers durant HNO pour ces utilisateurs.

Puis créer la règle https://technet.microsoft.com/en-us/library/dd335170(v=exchg.160).aspx.

Supposons que le dossier créé dans l’étape précédente s’intitule HNO et que la BAL est test.philphan, par exemple.

* add-MailboxPermission -Identity test.philphan -User admin -AccessRights fullaccess

* new-inboxrule -name MoveToHNO -mailbox test.philphan -MoveToFolder “:\HNO” -priority 1 -StopProcessingRules $true

Mettre -priority 1 pour que la règle soit exécutée en premier.

* Activer la règle durant les heures non-ouvrées – https://technet.microsoft.com/en-us/library/dd351213(v=exchg.160).aspx

Enable-InboxRule -Identity xxxx -mailbox test.philphan

* Désactiver la règle pendant les heures ouvrées – https://technet.microsoft.com/en-us/library/dd298120(v=exchg.160).aspx

Disable-InboxRule -Identity xxxx -mailbox test.philphan

* remove-MailboxPermission -Identity test.philphan -User admin -AccessRights fullaccess

On peut aussi programmer cette partie via EWS :

https://msdn.microsoft.com/en-us/library/office/dn600291(v=exchg.150).aspx : How to: Move and copy email messages by using EWS in Exchange

Pour déplacer les messages du dossier HNO vers Inbox via EWS :

https://msdn.microsoft.com/en-us/library/office/dn481313(v=exchg.150).aspx : How to: Manage Inbox rules by using EWS in Exchange

 

Pour les messages sortants:

1) Ajouter les utilisateurs ayant souscrit à l’offre HNO dans une DL spécifique, disons HNO-DL

2) Créer une règle Transport pour rejeter les messages soumis par les membres de cette DL durant HNO New-TransportRule https://technet.microsoft.com/en-us/library/bb125138(v=exchg.160).aspx avec les paramètres/conditions suivantes par exemple:

New-TransportRule -name No-Msg-Sent-HNO -FromMemberOf HNO-DL -ActivationDate ’18:00:00′ -ExpiryDate ’06:00:00′ -GenerateNotification %%xx%% -RejectMessageReasonText  etc…

 

7- Message d’information

Cette proposition permet d’ajouter un message informatif à tous les messages envoyés par les collaborateurs via une signature personnalisée.
Finalement cette proposition simple est basée sur la compréhension et la responsabilité des utilisateurs qui souscrivent à ce service. Aucune contrainte technique.

 

8- Message d’information via règle de transport

Cette proposition permet d’ajouter un message informatif à tous les messages envoyés par les collaborateurs via une règle de transport.
Il faut vérifier si la règle de transport appliquée à des milliers d’utilisateurs est possible.

 

9- Ce qui n’est actuellement pas possible

  • Le blocage des mails côté EOP n’est pas envisageable dû à des problèmes de sécurité et dû au fait que EOP ne peut que rejeter des messages et pas les garder dans une quelconque queue.
  • L’utilisation de la boîte aux lettres de modération par défaut avec approbation par un groupe spécifique de personnes. Cette BAL est limitée à 10 GB et 48 heures de rétention quelque soit la taille du tenant. De plus nous tombons dans la même problématique de throttling lors du relâchement des messages que pour la mise en rétention des messages.
  • L’archivage EXO ne peut être utilisé pour un stockage temporaire https://technet.microsoft.com/en-us/library/archive-features-in-exchange-online-archiving.aspx
    .         Using journaling, transport rules, or auto-forwarding rules to copy messages to Exchange Online Archiving for the purposes of archiving is not permitted.
    ·         A user’s archive mailbox is intended for just that user. Microsoft reserves the right to deny unlimited archiving in instances where a user’s archive mailbox is used to store archive data for other users.
  • La liste n’est pas exhaustive.

 

Informations concernant le déclenchement aux heures dites

  1. Il n’y a pas moyen de spécifier une périodicité par jour dans les règles Transport, tous les lundis par exemple.
  2. Le nombre maximal de règles Transport est de 100 actuellement.

Donc pour s’assurer que les commandes soient exécutées aux heures dites :

  1. Soit on planifie une tâche depuis un serveur on-premise ou une station de travail qui se connecte en EXO PowerShell et active les règles puis les désactive aux moments souhaités (périodes récurrentes).
  2. Soit on crée autant de règles Transport que nécessaire dans la limite de 100, une pour les jours de la semaine et une par weekend.

 

Conclusion

Dans l’état de l’art, le mieux est un développement spécifique pour chaque demande en évitant la complexité.
Et surtout ne pas oublier d’impliquer Microsoft avant toute mise en œuvre afin de vérifier la viabilité de la solution.

 

 

 

English version

Blocking email sending and receiving in O365 outside business hours (night and weekend)

 

This kind of request comes from agreements signed between social partners and management especially in France and Germany for instance.

How to set it up in a mutual environment like Office365?

Please find below 3 solutions tested in Office365 :

 

1 Put on hold emails submitted outside legal business hours

This solution leans on emails quarantine based on specific criteria. Then to release these emails.

 

Example of Powershell cmdlet to create a Transport rule with “AccordSyndical” as name and following criteria:

– It applies to all emails sent by philphan.onmicrosoft.com domain (internal)

– It is daily enabled between 11:20 AM and 11:25 AM (take UTC time into account)

– It puts these emails in quarantine

New-TransportRule -name AccordSyndical -SenderDomainIs philphan.onmicrosoft.com -quarantine:$true -ActivationDate ’09:20:00′ -ExpiryDate ’09:25:00′

Emails whose senders don’t belong to philphan.onmicrosoft.com domain are delivered in mailboxes as expected.

Emails sent between 11:20 AM and 11:25 AM were quarantined whatever the recipients are, internal or external to philphan.onmocrosoft.com domain.

To list emails put in quarantine:

Get-QuarantineMessage

Note the expiration date is 7 days by default.

Now to release all these emails:

Get-QuarantineMessage -domain philphan.onmicrosoft.com | Release-QuarantineMessage ReleaseToAll -verbose:$true -confirm:$false

And emails are then delivered to all recipients.

 

Technical points to watch for (update from March 31st 2016):

Be careful as these points can evolve in O365 and you need to perform tests.

  1. What limits can we meet (queue, mailbox, size, retention period in days)? There is no size restriction on the count/size of messages that can be sent to quarantine.
  2. Does mail go inside a quarantine mailbox that we have to create? Or a system mailbox? Quarantine is not a mailbox – it is a file store hosted in Exchange Online Protection.
  3. Does mail stay in queue? Messages that are quarantined via a transport rule have a lifetime of 7 days – this is not configurable. Quarantine is also not designed for or intended for mass-release of messages. The expectation for quarantine is that most things sent to quarantine will never be released. Considering that it takes a couple of seconds to release a sinlge message, this feature would not scale if the tenant is expecting to quarantine and then release tens of thousands of messages daily.

 

 

2 NDR (Non-Delivery Report) generation with explicit comment when email is sent outside legal business hours

Email is indeed in the Sent Items folder of the sender mailbox but it is not delivered. NDR is created.

If users were not previously informed, it should understand after receiving number of NDRs with the same explicit comment.

Example of Powershell cmdlet to create a Transport rule with “AccordSyndical” as name and following criteria:

– It applies to all emails sent by philphan.onmicrosoft.com domain (internal)

– It is daily enabled between 3:45 PM and 3:50 PM (take UTC time into account)

– It rejects these emails, generates NDR with status 7.1.100 and adds a personalized comment

New-TransportRule -name AccordSyndical -SenderDomainIs philphan.onmicrosoft.com ActivationDate ’13:45:00′ -ExpiryDate ’13:50:00′ -RejectMessageEnhancedStatusCode 5.7.100 -RejectMessageReasonText “Current social agreements prevent emails sending outside legal business hours.”

Sender receives this specific NDR.

 

 

3 No possibility to access a mailbox outside legal business hours

A “radical” solution consists of preventing any access to the mailbox whatever the client is (Outlook, OWA, mobile device, application): just disable all mailbox access protocols.

Set to False all « protocolesEnabled » highlighted in yellow like below.

Example of Powershell cmdlet to disable OWA protocol for user3:

Set-CASMailbox -identity user3 -OWAEnabled:$false

 

2 technical points to watch for:

  1. There is no way to specify a day period in Transport rules like every Monday.
  2. Currently the maximum number of Transport rules is 100.

 

So to make sure commands are launched at right time:

  1. Schedule a task from an on premise server or from a workstation which connects in EXO PowerShell and enables/disables rules when you want (recurrent periods).
  2. Create all necessary Transport rules with limit of 100, one per weekday and one per weekend.

 

To summarize these proposals:

  • They are easy to setup.
  • They can be shown quicky.
  • It is possible to get some agility in rules with options/exceptions depending on specific requests from our customers.

 

Other proposals were discussed and/or tested but they were impracticable or need a specific Development.


Comments (0)

Skip to main content