SOLVED

EXO: All delegate-approval-requiring meeting requests are deemed "Out-of-Policy"

Steel Contributor

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, -AllRequestOutofPolicy, and -AllBookInPolicy.  Each of these is a boolean and only one should be set to $true.  Each of these has a corresponding multi-valued property - RequestInPolicy, RequestOutofPolicy, and BookInPolicy.  The entries in these multi-valued properties are recipients whose meeting requests will be deemed In or Out of policy, or automatically accepted.

When AllRequestInPolicy is set to $true, and the other two All***Policy settings are set to false, it is expected that all requests are "In-Policy".  However in Exchange Online, no matter what, the forwarded approval request that goes to delegates always says "

This out-of-policy resource request was forwarded to you for your approval.

This request was forwarded to you for approval because the organizer doesn't have permission to book this resource."

 

In Exchange (on-premises) server, these forwarded requests would say "This in-policy resource request was forwarded to you for approval." and it shows the same reason (organizer doesn't have permission to book).

 

I'm just wondering - has anyone else observed this issue?  If so, any insights or additional info to share, maybe from Microsoft Support?

4 Replies
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/9...

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.
best response confirmed by Jeremy Bradshaw (Steel Contributor)
Solution

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.
Thanks for the thread and persistance, Jeremy, at least one fellow OCD person is delighted too.
1 best response

Accepted Solutions
best response confirmed by Jeremy Bradshaw (Steel Contributor)
Solution

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.

 

View solution in original post