Forum Discussion
EXO: All delegate-approval-requiring meeting requests are deemed "Out-of-Policy"
I have noticed something, only because some users raised it as an issue, but it seems to be widespread in Exchange Online. With Set-CalendarProcessing we have -AllRequestInPolicy, -AllRequestOutofPo...
FYI, MS Support has confirmed that this is a known issue in EXO and the "PG" are aware of it. It's on a list of things to be fixed, with no ETA or info regarding the priority of this compared to other things that are broken.
I was initially told that this behavior is the design of the product, but I refuted that and supplied all the information I could about the true design of the product, which is:
There are many settings the dictate ‘in or out of policy’. In addition, there are 3 pairs of settings that involve who is allowed to make in-policy or out-of-policy requests. These and their definitions can be found online and confirm what I’m saying (Set-CalendarProcessing😞
- BookInPolicy: A list of named meeting requestors whose requests will be automatically approved/accepted.
- AllBookInPolicy: A true/false setting to make all users’ requests automatically approved/accepted.
- RequestInPolicy: A list of named meeting requestors whose requests will be eligible for delegate approval as long as their requests are in-policy.
- AllRequestInPolicy: A true/false setting to make all users’ requests eligible for delegate approval, as long as their requests are in-policy.
- RequestOutOfPolicy: A list of named meeting requestors whose requests will be eligible for delegate approval, even when their requests are out-of-policy.
- AllRequestOutOfPolicy: A true/false setting to make all users’ requests eligible for delegate approval, even when their requests are out-of-policy.
Of the 3 All***Policy true/false settings, only one is supposed to be set to True, and the other two set to False. By default AllBookInPolicy is true while AllRequestInPolicy and AllRequestOutOfPolicy are False.
Whether a meeting request is in or out of policy is determined by things like the following:
- Meeting is not too short, not too long (vs MinimumMeetingDuration/MaximumMeetingDuration).
- Meeting is not too far out in the future (vs BookingWindowInDays).
- There aren’t more attendees than the resource’s capacity.
- The meeting is a conflict / the series has conflicting occurrences (per AllowConflicts, MaximimumConflictInstances).
- Etc.
A meeting is not deemed out-of-policy simply because the requestor isn’t named in the ***InPolicy settings and/or the All***InPolicy settings are not set to True. The privilege to book or request to book are completely decoupled from the in-or-out-of-policy decision.
In Exchange Online, while this issue is still unresolved, all forwarded meeting requests (going to the resource delegates for approval) erroneously have the text in the message body stating the request is "out-of-policy", no matter if the request is truly in or out of policy.
Note that I can see this behavior that I'm describing, described in this ultra-old webpage: https://mskb.pkisolutions.com/kb/949782. You can only see the page in Google's cache, and only the text-only version seems to work: http://webcache.googleusercontent.com/search?q=cache:hv6-EyhHv4YJ:https://mskb.pkisolutions.com/kb/949782&hl=en&gl=ca&strip=0&vwsrc=1
The problem is exactly what I've described, but was for Exchange 2007, and addressed officially with Update Rollup 4 for Exchange 2007 SP1. Seems like the issue is back. It's again, low priority, but clearly a broken product piece, in that every actually-in-policy request that is (properly) forwarded to delegates for request, is said in the forwarded request to be "out-of-policy". For detail-oriented delegates, they see this and wonder "what setting about this meeting is breaking the policy?", and the answer is "nothing". At least that is how it seems to me right now.
The problem is exactly what I've described, but was for Exchange 2007, and addressed officially with Update Rollup 4 for Exchange 2007 SP1. Seems like the issue is back. It's again, low priority, but clearly a broken product piece, in that every actually-in-policy request that is (properly) forwarded to delegates for request, is said in the forwarded request to be "out-of-policy". For detail-oriented delegates, they see this and wonder "what setting about this meeting is breaking the policy?", and the answer is "nothing". At least that is how it seems to me right now.
FYI, MS Support has confirmed that this is a known issue in EXO and the "PG" are aware of it. It's on a list of things to be fixed, with no ETA or info regarding the priority of this compared to other things that are broken.
I was initially told that this behavior is the design of the product, but I refuted that and supplied all the information I could about the true design of the product, which is:
There are many settings the dictate ‘in or out of policy’. In addition, there are 3 pairs of settings that involve who is allowed to make in-policy or out-of-policy requests. These and their definitions can be found online and confirm what I’m saying (Set-CalendarProcessing😞
- BookInPolicy: A list of named meeting requestors whose requests will be automatically approved/accepted.
- AllBookInPolicy: A true/false setting to make all users’ requests automatically approved/accepted.
- RequestInPolicy: A list of named meeting requestors whose requests will be eligible for delegate approval as long as their requests are in-policy.
- AllRequestInPolicy: A true/false setting to make all users’ requests eligible for delegate approval, as long as their requests are in-policy.
- RequestOutOfPolicy: A list of named meeting requestors whose requests will be eligible for delegate approval, even when their requests are out-of-policy.
- AllRequestOutOfPolicy: A true/false setting to make all users’ requests eligible for delegate approval, even when their requests are out-of-policy.
Of the 3 All***Policy true/false settings, only one is supposed to be set to True, and the other two set to False. By default AllBookInPolicy is true while AllRequestInPolicy and AllRequestOutOfPolicy are False.
Whether a meeting request is in or out of policy is determined by things like the following:
- Meeting is not too short, not too long (vs MinimumMeetingDuration/MaximumMeetingDuration).
- Meeting is not too far out in the future (vs BookingWindowInDays).
- There aren’t more attendees than the resource’s capacity.
- The meeting is a conflict / the series has conflicting occurrences (per AllowConflicts, MaximimumConflictInstances).
- Etc.
A meeting is not deemed out-of-policy simply because the requestor isn’t named in the ***InPolicy settings and/or the All***InPolicy settings are not set to True. The privilege to book or request to book are completely decoupled from the in-or-out-of-policy decision.
In Exchange Online, while this issue is still unresolved, all forwarded meeting requests (going to the resource delegates for approval) erroneously have the text in the message body stating the request is "out-of-policy", no matter if the request is truly in or out of policy.
- FYI - I was delighted to find out this morning that this issue has now been addressed. I've since tested and confirmed it myself. Thank you very much! My OCD will benefit from this.
JeremyTBradshaw Looks like the issue is back
again. We are facing the exact same issue. If delegate books the conference room who is in RequestOutOfpolicy, all delegates get an approval email. Though there is no way to approve it, the meeting itself is appearing as Tentative on the Conference room. What was the fix for you?
- Hi, to be honest it sounds like a slightly different setup and issue, but I might be able to help with a strategy change. I like putting the Resource Delegates in the BookInPolicy setting so that their requests are just auto accepted. Also, just to mention it, marking people as ResourceDelegates gives them Editor on the calendar and Send on Behalf rights - totally unrelated but I also rely on this for room delegates. That means we can do a consistent move for delegates, which is add them to both ResourceDelegates and BookInPolicy, and they're essentially all set.
The in/out of policy stuff is not 100% clear and it does sound like you've uncovered an unfinished or broken part of the product.
For this reason I suggest living in the in policy lane entirely. Let me know if this helps.
- Thanks for the thread and persistance, Jeremy, at least one fellow OCD person is delighted too.
