Prevent Double-Bookings in Office 365 Calendar

We keep getting Office 365 sites coming the blog with search terms something like "prevent double bookings in 365 calendar."  

Invariably they find our post Double-Booked Meeting Rooms in Office 365 (and how to avoid them)

Let's keep in mind this is usually a problem for conference rooms.  People are double-booked all the time and it's expected.

Lots of technical info there, but as with anything in calendaring you need to also put it into a social context.

The only ways to prevent double-bookings entirely in advance and at meeting creation time are:

1. Disallow recurring bookings for resources
2. Set the allowable conflict rate to 0%
3. Make the resources go through a human gatekeeper

Now the social aspect of this:  Your users are probably going to balk at any of these.  And with good reason: 

1. Recurring meetings are just so darned useful. 
2. An allowable conflict rate of 0% is highly unrealistic
3. Having someone in charge of each resource defeats the purpose of calendaring

This is also a big issue because there is no easy mechanism for individuals to scan ahead and see if there is a possible conflict on the horizon with their meetings.  One of my daughters actually has this problem with a recurring meeting at her organization.

This is what makes double-booking a thorny problem. 

Our solution based on what we've seen is to create a PowerShell cmdlet that searches for up-coming resource conflicts and informs users or alternately takes action.

It's configurable and customize-able for a variety of situations.  Since it's a cmdlet it seems to be making more headway with on-prem Exchange sites, but it there's demand for something entirely cloud-based we're happy to discuss the issue.

October 2022: We just updated our cmdlet for Modern Authentication.

SuPump when used on disabled accounts

We had an issue crop up in one of our favorite sites using the Sumatra Pump.

Calendar item insertion jobs were hanging and the error logs were showing things like this:

GetUserFromAD-ERROR: Failed while reading AD: (employeeId=F112ZHW); err: Object reference not set to an instance of an object.
GetUserFromAD-ERROR: Failed while reading AD: (employeeId=F112ZHY); err: Object reference not set to an instance of an object.
'ERROR: Failed while reading AD.(employeeId=F112ZHT)
ERROR: Failed while reading AD.(employeeId=33460A)

Simple to diagnose: The accounts causing the problem were DISABLED accounts.

To deal with it exclude the disabled accounts.
      Patient: "Doctor, it hurts when I do this."  
      Doctor: "Don't do that!"

WHAT (NOT) TO DO

An easy fix: add this criteria to exclude disabled accounts to the LDAP string in the _config.xml file:

(!userAccountControl:1.2.840.113556.1.4.803:=2)

Thus,  your LDAP4USER setting should look something like this  

LDAP://DC=YOUR_DC,DC=COMPANY,DC=COM;(&(mailNickName=*)(employeeID=*)(!userAccountControl:1.2.840.113556.1.4.803:=2))

What the heck do those strange numbers mean????

It’s a bitwise AND filter for the UAC.  

For more info on the UAC please see:

How to use the UserAccountControl flags to manipulate user account properties

OWA :-( Something went wrong (owa/auth/errorFE.aspx?httpCode=500)

We were testing the Attachments in Oracle Calendar.  It works without problem in Office 365 as it seems to do on our Exchange 2016 On-Prem servers.  BUT, we can't confirm it, because OWA (o.k, Outlook on the web) puts up a ":-( Something went wrong " page (the URL is owa/auth/errorFE.aspx?httpCode=500) with no helpful information.

This walks through the testing and debugging I went through.  If you want to skip this and move directly to the answer, it was to recreate the certificates (see the bottom of the blog). Note, Google search results offered solutions that caused me to spin my wheels.  Before you try my solution, I urge you to ensure that your problem is the same as my problem.

What I tried:
Set TimeZone and Language. We provisioned a few test user mailboxes and started the insertion without first logging into those mailboxes.  A quick Google search suggested the problem is due to incompletely configured mailboxes, i.e., no time zone and language. The typical workflow: the user should be redirected to languageselection.aspx, choose the correct setting and then return. But not for us.  The Exchange Shell command, Set-MailboxRegionalConfiguration, without success.  

Get-Mailbox myuser | Set-MailboxRegionalConfiguration -Language 1033 

-TimeZone "Eastern Standard Time"

Cogmotive's blog conveniently provides the enumerated language and timezone values.

"Test-OWAConnectivity" -- It's removed in Exchange 2016!

Check  the event log.  
a) Looking at errors.  Came across. Can't find the  URL officeclient.microsoft.com?  A MSExchangeApplicationLogic Error 3018. It can't get out to the internet? 
Set proxy, -- no change: 
Set-ExchangeServer Server01 -InternetWebProxy http://10.3.3.3:80

b) Many Event 1309 Warnings
I was looking for errors -- but broadened the filter to include warnings.  I found many problems with Asp.Net.4.0.30319.0

This warning pointed me to a MS Support article: Event ID 1309 and you can't access OWA and ECP after you install Exchange Server 2016 or Exchange Server 2013.  It suggests "SharedWebConfig.config" is missing from the FrontEnd and ClientAccess.  The files are present. Recreating them one-at-a-time and restarting IIS made no difference. 

OK, that didn't work. onto the next one

c) Many 2004 Warnings -- Unable to find Certificate with thumbprint....

Checking Get-ExchangeCertificate, and Get-AuthConfig, I see the authCOnfig has the certificate, but not the Exchange Certificate.  This is getting closer!

What finally worked -- Create a new "Microsoft Exchange Server Auth Certificate": 

New-ExchangeCertificate  ...
* Don't replace the SMTP certificate 
* Note the thumbprint of the new certificate
* Put in place
$a=get-date
Set-AuthConfig -NewCertificateThumbprint EZxxxxx –NewCertificateEffectiveDate $a
Set-AuthConfig –PublishCertificate
* Remove reference to the old certificate
Set-AuthConfig -ClearPreviousCertificate.
iisreset

Bingo!