Sumatra web site again up and running

Thanks to the good and capable folks at TMDHosting (whom we recommend) Sumatra's web site and email are once again running.

We recommend TMD.  They came up aces for us when we needed 'em.

Sumatra migrating main site to a new hosting company

Folks,  we gave up on the company that rendered our previous hosting company into bacon grease.  Working with a new vendor to get up and running again.  Those of you currently working on a calendar migration / calendar project with us know how to get in touch with us.

Problems on our web site as our hosting company is acquired

Folks,

Our web hosting company is being acquired by Site5, who has thus far proven to be REALLY MISERABLE. 

So if you get annoying messages from trying to access our web site or FTP please give it a 24 to 48 hours as the new DNS records replicate through the net.  (Am I angry that these Site5 guys just bought out a bunch of customers and their first act of customer service is to shut us down and not even bother to warn us ahead of time?  Yes.  Yes I am!)

If things are not up at a decent pace we'll let you know here.

Twenty minutes into my turn in the support queue:

For April Fool's Day: Soul-Crushing Meetings

We in Sumatra migrate meeting data.
We cannot however make your meetings any less soul-crushing.

I'd love to give credit to the originator of this if they tell us who they are (came to me by way of my cousin who got it from his feed who posted it from some other feed and yadda yadda yadda).

DAVical and Open Source Calendar Migration to Exchange / Office 365

We got an inquiry a while back about migrating DAVical to Exchange.

They vanished as happens in the way of people with more ambition than budget, but it did get us thinking about how to do Open Source calendar server migration to Exchange or Office 365.

This is made easier because we already have a full-state migration method out of Zimbra into Exchange and Office 365.

Works like this:

Short answer is I'm pretty sure we can do it using the REST implementation we already implemented for Zimbra.

In Zimbra the format to download an ICS to our migration is:

http://SERVER/home/username/calendar?fmt=ics

In DAVical (https://www.davical.org/clients.php) it's

http://SERVER/caldav.php/username/calendar/

The ICS is close enough that it presents no problems, and there is admin access to all accounts.

So we have a decent chance of getting this to work.

Also Zyg's tried it out in the lab and got it to function, but undoubtedly there's a bug or two in there that real-world hardening will discover and squash.

So sites with several hundred users and a willingness to spend part of their test phase in careful mode can feel free to contact us.

DAVical is built on top of PostgreSQL which we read in order to migrate Apple's iCalendar server, but there's no indication that's a superior migration path.  And it represents a little more work so -- nope.

Security best practices for Office 365

I went to a local Microsoft presentation that was supposed to be a "Deep Dive into Office 365 Security."

Word of warning: Very rarely is any Microsoft presentation a deep dive.

This one was no exception as the presenter spent way too long talking about weak passwords and putting up vague slides that were really good at telling you what your problems can be but way too vague on how to specifically, actually solve them.

Still this Microsoft shill was up-front that the slide contents came from this posting:

Security best practices for Office 365 

Not a bad summary of issues you need to face as you move to Office 365.

The links include how to activate specific security safeguards in your Office 365 environment.

Now: It seems to me that since this environment is completely in the hands of Microsoft, which as a company should be really concerned about client security, perhaps a decent subset of these should be turned ON by default with instructions on how to turn them off, instead of OFF by default with instructions about how to make your Office 365 experience more secure.

But that's just me wondering WTF?!?

New in Office 365: PowerShell and Delegate Permissions

If you've seen our earlier post Migrating Delegate Permissions: The 80/18/2 Rule, you know that in on-premises Exchange at least you can use the Add-MailboxFolderPermission cmdlet in PowerShell to set Delegate Access.

Now Microsoft is allowing you to use this capability on Office 365.

Sidebar: Is anyone else getting tired of discovering which cmdlets work in on-prem Exchange but not in Office 365 by Microsoft's tried-and-true method of "well, walk into the minefield and if you do not explode you'll be fine?"

Log into your Admin account and you should be able to see this update:

This lets you use effective scripting and server-side methods to handle Delegates.

As we always counsel: Be really careful how you set up Delegates in Exchange / Office 365.  See our article:  Two Ways to Grant Access to a Resource in MSFT Exchange. and use the "Booking" Delegation approach.

Sometimes Low-Tech is the Best Tech -- even in calendaring

The New York Times recently did an article "In an Era of 'Smart' Things, Sometimes Dumb Stuff is Better."

You may be surprised that for some people who spend almost all their professional time in Microsoft Exchange and Outlook and breaking legacy calendaring systems (not that there are really any left for us to break), Zyg and Russ are calendar Luddites.

If you've seen us come into a customer site you may have been astounded that the calendaring guys pulled out paper organizers.

Zyg is big on his medium-form filofax and Russ still uses the Time/system book he was trained on at Lotus.

WHY? you are probably asking.

Really simple:  every server, client, and data set at Sumatra is fair game to become an immediate test system by any employee should the need arise.  And yes, it's happened to each of us and we're kind of happy when it does because it means we're shagging down issues making our latest generation of calendar migration tech better.

Now we still have our laptops with Outlook clients.  Truth be told I've tried every organizer / email client since Lotus Agenda.  I do not love Outlook (there is a lot to be unhappy about) but find Outlook just keeps evolving and no other client-based organizer can lay claim to that.

We also both have analog wristwatches.

Migrating Delegate Permissions: The 80/18/2 Rule

From the Oracle Communication User Documentation,

https://docs.oracle.com/cd/E56607_01/doc.301/e73472/olh_calendar001.htm#CONOH202

calendars have the following delegate options:

Exchange has the following delegate options.

You should now see the problem about how you move from legacy to target and keep everyone happy.

Basically, you cannot possibly keep everyone happy if you try to migrate delegate permissions from Oracle to Exchange.  The only sane solution is to let users set delegates themselves post-migration.

While it is possible to set Delegates via PowerShell in Exchange via Add-MailboxFolderPermission, Sumatra does not recommend migrating legacy delegate lists.

1. The access model between legacy and target system are different enough that any mapping is a “best guess.”  While this is fine for many users, it will lead to dissatisfaction among an undetermined subset.  And long experience with migrations has shown us that user communities are happier with a migration with clear rules and expectations universally applied.
2. Migrating delegates automatically propagates a situation of “maximum access.”  Now is a perfect time for end users to review who has access to their calendars and re-think it.
3. Use it as a primary incentive to get users training on the new system.

Exception to the rule:  Zimbra to Microsoft Exchange.

Since Zimbra consciously decided to rip-off emulate as much Microsoft functionality as explicitly and exactly as it could, you have a higher chance of success here.  But please see comment #2 above about propagating a culture of "maximum access."

Using PowerShell to SET permissions in Exchange is straight-forward.

BEWARE:
Migrating Zimbra permissions to Exchange does not automatically set up menus for user access via Outlook or OWA!

You will likely perpetuate security issues for users who have changed roles and should no longer have access to some accounts! Your migration is the best time to review all of these!

To extract Zimbra delegate permissions:

Zmmailbox will give permissions for any mailbox or calendar you want as follows

./zmmailbox -z -m jimi@sumatra.local gfg /Inbox
./zmmailbox -z -m jimi@sumatra.local gfg /Calendar

This also works for tasks and contacts.

To save to a text file append '> permissions.txt'

See: https://wiki.zimbra.com/wiki/Ajcody-User-Management-Topics

Permissions exist as per the following table:
 r = read
 w = write
 i = insert
 d = delete
 x = accept/decline invitations
 a = administer

To insert Zimbra permissions into Exchange:

Use:

Add-MailboxPermission in PowerShell

Add-MailboxFolderPermission -Identity jimi@sumatra.local -User zyg@sumatra.local -AccessRights Editor


This will give Zyg editor delegate access to Jimi's mailbox.

And of course, you will need to manipulate or edit the text file you originally extracted from Zimbra.  But this is not beyond high school programming or scripting, people.

You can also delegate other folders like jimi@sumatra.local:\Calendar and so forth.

See also: How to use Powershell to set delegate for user mailbox in Exchange 2010 and Office 365

Again, just because you can migrate permissions does not mean you should.

Seriously talk this over.

Migration: Email Distribution Groups and the 80/18/2 Rule

Distribution groups are not as much a pain in some cases as you might imagine!

Keep in mind these are an email migration issue as opposed to a calendar migration issue -- but we're interested in writing about stuff to solve problems, not pass blame.

For MDaemon to Exchange public distribution lists we needed to write our own specific application.   Our specific application did the mapping from legacy domain to target domain and also used our own mapping files for user/resource IDs, so .... it really kicks butt.

Nobody else we know does this.

And in general for legacy systems it may not be possible to even generate the information you need in order to make this work.  As usual we're talking server-side solutions for the entire enterprise as opposed to lame client-side solutions for one freaking user at a time.

But we'll tell you how to do this if you have the chance.

Again we begin with the end business goal of migrating into Exchange or its cloud sibling clearly in mind.

Refer to: Distribution groups and EWS in Exchange   and use New-DistributionGroup.

From Zimbra it's not too bad.

In Zimbra getting this information for public groups is actually very straightforward.  See Zimbra.List all existing distribution list and the respective members

This command:

zmprov gadl -v > dist_list.txt

will list all distribution lists with their members and output it to a text file.

The same command with some variations:

for i in `zmprov gadl` ; 
   do zmprov gdl $i zimbraMailAlias zimbraMailForwardingAddress ; 
   done > /tmp/dist_list.txt

accomplishes the same thing

Now -- keep in mind, if in going into Exchange you are changing any user IDs or your domain you're going to need to do some work on the export file before you start using EWS to re-create the lists.

To export single distribution lists in Zimbra (see: https://forums.zimbra.org/viewtopic.php?t=48514)

zmprov gdl dist_list@domain.com > dist_list.txt

To create a distribution list (what Exchange refers to as a distribution group) in on-premises Exchange 2013 use

New-DistributionGroup -Name (+Additional parameters as necessary)

See: https://technet.microsoft.com/en-us/library/aa998856(v=exchg.150).aspx

To create a distribution list in Office 365 / Exchange 2016

New-DistributionGroup -Name "RockIcons" -Members jimi@sumatra.com,janis@sumatra.com,jerry@sumatra.com,puffy.amiumi@sumatra.com

See: https://technet.microsoft.com/en-us/library/aa998856(v=exchg.160).aspx#Syntax

Dynamic Distribution Groups

And for some business purposes you want to consider Dynamic Distribution groups.  You may also know these by their former name of Query-Based Groups.

These come to the fore when you have a (wait for it....) very dynamic membership in the sense of people changing roles or having a high turnover.  Example:   A project group or a support desk.

Check over Dynamic Office 365 Groups might come with a big cost for a good analysis of the pros and cons.

Windows update consumed all of my hard drive

I blogged about "Surviving a botched windows update" two weeks ago after the December 12, 2017 Windows Update.  I thought my problems were behind me. I was so wrong.  It took almost two weeks to find and fix the problem. What a waste of time.

Here are the four symptoms:

1. Ran out of hard drive free space (200+ gb of free space suddenly disappeared)
2. Windows update stuck on 99%
3. "C:\Windows\Logs\CBS\CBS.LOG" grew to 200GB.  The file had 200,000 of these entries:  Current tick count lower than last tick count. [HRESULT = 0x8007000d - ERROR_INVALID_DATA] 
4. The Event Logs shows: "Installation Failure: Windows failed to install the following update with error 0x800706BE: 2017-12 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4054517)."

The solution:

I read the December 12, 2017—KB4054517 (OS Build 16299.125).  "When, what to my wondering eyes should appear, But a Knows Issues (1)."  The symptom reported in that KB:

Update installation may stop at 99% and may show elevated CPU or disk utilization if a device was reset using the Reset this PC functionality after installing KB4054022.

No kidding.

Here is an abbreviated version of the steps I took (from the KB article.) 

1. Download the appropriate version of KB4054022 for your device architecture from the Microsoft Update Catalog to c:\temp. Then run the commands in the steps below from the administrative command prompt.
2. Create a temp directory, expand the .msu file that you downloaded in step 1.
• mkdir c:\temp
• expand -f:* windows10.0-kb4054022-x64_da67baa74c09ad949d90823b25531731c3211184.msu c:\temp
3. End the existing Trusted Installer processes and install KB4054022 using the Deployment Image Servicing and Management tool.
• taskkill /f /im tiworker.exe
• taskkill /f /im trustedinstaller.exe
• dism /online /add-package /packagepath:c:\temp\Windows10.0-KB4054022-x64.cab
4. Delete the CBS logs from the Windows Logs directory.
• del /f %windir%\logs\cbs\*.log

Three days later things seem to be back to "normal."
-----------------------------------------------------------------------------
(1) Adapted from the poem "Twas the Night Before Christmas"

Surviving a botched Windows update: recover your Outlook profiles

I returned from a client meeting and saw a required reboot after a Windows 10 or Office 2016 Update (I'm not sure which).  After the reboot, the Windows startup said the boot drive was inaccessible.  After spending a half day trying to recover, I gave up and "recovered Windows 10."  Of course that meant I lost every installed application on my hard drive.  Recover kept my user files.  Fortunately most are stored on a different drive and on Sumatra's SAN and cloud drives.

The hardest part was recovering my Outlook Profile -- i was not looking forward to re-entering all of the credentials for my various email accounts.  Windows moved the old windows to a new folder "Windows.Old"  found my old registry hive, and was able to extract the Outlook Profile.

Here's the steps.   Thanks to JRich from Mass General for blog post that pointed me in the right direction!!

In Powershell, run as the administrator:
1. Use the REG command to load the "old hive" into your registry under the HK Local Machine

reg load 'HKLM\_OldOutlook' "C:\Windows.old\Users\riuliano\NTUSER.DAT"

2. Open RegEdit navigate to Outlook, i.e.
HKEY_Local_Machine\_OldOutlook\Software\Microsoft\Office\16.0\Outlook\

3. In Regedit, right-click on "Profiles" and Export the file

4. Edit the exported profile file, and replace "Hkey_Local_Machine\_OldOutlook" with "HKey_Current_User\".  Save the file

5. Back in RegEdit, Import the "reg" file you just edited.

6. Back in Powershell, remove the registry key and garbage collect.
reg unload hklm\OldOutlook

[gc]::collect()

That's IT!



BTW, if you want to see what the director looks like in powershell, you can create a virtual directory of the old hive:
New-PSDrive -Name OldOutlook -PSProvider Registry -Root "HKLM\_OldOutlook"

then you can "cd OldOutlook:"
and get-item and value.  I'm sure i could have looped through and copied each profile key from the old hive to the new hive.  Export seemed much simpler, though.

Remember to remove the PSDrive:
Remove-PSDrive OldOutlook

Access Runtime in a click-to-run world

A quick FYI:

Some Sumatra products require MS Access Runtime.   Microsoft offers two versions:

Microsoft Access 2016 Runtime Download  and
Microsoft Access 2013 Runtime Download

Both version of the Access Runtime products are installed via an "MSI" or Windows installer.

Here's the rub: C2R and MSI of the same major version cannot be installed side by side. 

If you have Office 365, you are likely to have the Office "click-to-run" (C2R) version.  Since there is no C2R for either Access Runtime, you'll have to install the Access 2013 Runtime.  Microsoft says the two versions are functionally equivalent, and this installation should work smoothly.

If you wonder what will happen if you install the Access 2016 Runtime and Office C2R, this is what you'll see:

Migrating calendar user settings into Exchange / Office 365

Today's topic on migrating into Exchange or Office 365 from a legacy system is USER SETTINGS.

Spoiler alert: I'm going to make the case that this is something you should put in the hands of your end users post-migration.  At best it's a necessary evil for a subset of high value individuals in your organization and at worst an example of sticking your finger in an already hopelessly broken dike hoping to keep it all together before the deluge overwhelms you and you needlessly drown.

In our 80/18/2 rubric, we're in the 2% in terms of user satisfaction, and that's also about as much of this as you can successfully automate server-side.

Let's begin with the end in mind and look at how the settings get put into Exchange.  Then we'll work back from there.

Set-MailboxCalendarConfiguration is your major asset in this endeavor.

Read it.  Study it.  Grok it. 

You can now take server-side control of SETTING user preferences in your organization. 
Notice I did not write MIGRATING user preferences, keep an eye on this.

Let's take DefaultReminderTime as a simple starter example.

Set-MailboxCalendarConfiguration ^
    -Identity "Jimi Hendrix" ^ 
    -DefaltReminderTime 00:30:00

Sets the default reminder time for Jimi Hendrix at 30 minutes.

We could also on the Exchange side set:  WorkDays, 
WorkingHoursStartTime, WorkingHoursEndTime, WeekStartDay, all really useful in calendar management.  You can set this via Group Policy “Microsoft Outlook”, “Outlook Options”, ”Preferences”, ”Calendar Options”.  We find it’s much more convenient to set the hours via “Set-MailboxCalendarConfiguration” than Group Policy since it allows the users to change their work hours. The down side of the cmdlet: you’ll have to run this for every new mailbox-enabled account you create.

Let's look at an Oracle Calendar Server legacy system

Now, working backwards, we need to get that default reminder time information out of our legacy system.  

In Oracle Calendar Server you can use uniuser to get your user lists and you can use it to provision users.  But you cannot use uniuser or any other server-side tools  to get individual user preferences.

Let me repeat: you cannot get the info you want on an individual basis from the server.

You CAN get the default user profile in $ORACLE_HOME/ocal/misc/user.ini 

Looking at that:

Notice that the TimeBeforeReminder is FAR MORE CONSTRAINED than Exchange/Office 365/Outlook allow.

Remember in an earlier post when I wrote about disconnects between your legacy and Exchange?  Welcome to the disconnects.

And just because this is more popular lately let's consider Oracle Communications Calendar Server which we access server-side via WCAP.  The user settings are not in general available by any of the options.  get_accountprops.wcap is the most obvious, but is highly limited.  We can get ACLs, but see our earlier comments on delegate migration.

So your users have more discretion than they had before and setting their preferences in the client user interface takes a few minutes as opposed to a few hours.

You COULD use the PowerShell cmdlet to set the same default for all users.  You could probably also apply a Group Policy to accomplish the same business goal.  But re-creating individual user preferences server-to-server is a no-go from the start.

Our conclusion: Don't bother.  But tell them in advance.

We've only looked at Oracle calendars so far.

Let's look at one more legacy system -- Zimbra calendaring.

From the administration console we can see the preferences information for a given user:

Yes, the data is there, but again there is no server-side means of exporting it.  You can get at all the users on the system but their specific calendar preferences require client-side methods (which are SLOOOOOOOWWWWWW and inefficient).  We've actually looked at the mySQL database where all this info is stored and while it is possible to extract, we also found significant reticence among migration sites when we used tools like putty and HeidiSQL to extract data.  And that was mainstream calendar data!  We've since refined our calendar migration methods to avoid those requirements.

Email and calendar migration get you accolades and you can accomplish them successfully.  Leave the user preferences in a new system where they belong -- in the hands of the users.

We recommend you communicate this to your users in advance.  95% of them won’t know or care, and you will force the remaining 5% to find something else to whine about.

Calendar Migrations: The 80/18/2 rule

Enterprise migrations are as much a social engineering issue as a data conversion issue.

Keep in mind, we're talking organizations here as opposed to single-users, and we're focused on server-to-server solutions as opposed to client-to client solutions.

Let's get into that social engineering by way of the perceived utility among your user base, shall we?

If you're acquainted with the 80/20 rule, we're going to give you, based on our experience of doing this kind of stuff since 2001, our own 80/18/2 rule when it comes to migrating into Exchange or Office 365.

To wit:

• 80% of what you need to migrate is email.
• 18% is calendars (full-state or flat, doesn't matter), contacts, tasks 
• 2% is user preferences, settings, delegates 

Getting 80% done should cost you NOTHING

Email is manageable with imapsync and your cost is  €100 EUR for product and support no matter your enterprise size.  Why on earth would you pay anybody for email migration when this is available (unless you have a backroom deal with a consultant)?  We've even done a couple of guides one of which you can download here.

We've done several posts on how to use imapsync to migrate into Exchange / Office 365.

If all you (need to) care about is email you're done here.

Your likely result in this 80%:  
Your end-user efforts: Minimal
Your Admin efforts: Moderate to high
Your End User Satisfaction: Moderate (if you stop here)

Your next 18%

Contacts and tasks are not other-user-connected information and (worst case) you can move them via CSV/TXT file methods.

Calendars are a more complex discussion.  In fact this entire blog is dedicated to migrating calendars and keeping as much of the useful connections between users intact.

Anybody who's promising you "no data loss" in a migration and takes calendars without re-creating the guest list has been dealing in alternate facts.

If you do not care about attendees, attendee responses, and resource bookings, there are a variety of solutions.  If your enterprise wants "no data loss" when it moves to a new collaboration platform, i.e.,  to keep its meetings as meetings, please search this blog for the legacy system and read the appropriate articles.

We do charge for that capability.

Your likely result in this 18% with Sumatra methods: 
Your end-user efforts: Minimal
Your Admin efforts: Moderate to high (depends on experience level)
Your end-user satisfaction: HIGH

Your likely result in this 18% without Sumatra methods:  
Your end-user efforts: HIGH (Need to re-create meetings, resource bookings)
Your Admin efforts: Low.  (We have seen sites choose based on Admin efforts -- their call)
Your end-user satisfaction: Low to moderate

The final 2% (the last mile to the finish line)

Let's talk about that last part since it's portrayed out of proportion to its time value: 

• User preferences, 
• Delegates
• Junk Mail filtering rules
• Client-side Outlook re-configuration

User Preferences
Many of these are scriptable.
One of us has in fact has been itching to write about how to script user preference migration so keep an eye on this blog.
The important things to keep in mind here are:

1. From almost any legacy system there is going to be a disconnect between user preferences offered and Exchange / Office 365.
2. Even if there is not a disconnect in a specific functionality, the question is can you get at the legacy data via server-side utilities?
3. Setting user preferences is a great opportunity (a "teachable moment") to enforce encourage your users getting training and actually taking steps in Exchange before or after a migration.

Delegates
You would LIKE to think Delegates are a simple matter.

This is exactly incorrect.

First off, because the model for delegates is usually very different between your legacy system and Microsoft Exchange.  Example: In Oracle Calendars delegate access (called Designate access in OCS) is OBJECT-BASED and in Exchange it's FOLDER-BASED.  

Second because over time the number of delegates in legacy systems has usually out-grown the organization's needs and some re-thinking is most definitely in order.  During a migration is the perfect time to reset those access permissions. Or, worst case, you migrate all legacy delegates (and we mean it’s the worst case.) 

Third because after you set those delegate permissions in Exchange you discover that users can edit conference room bookings, and can see other’s calendar information. What’s the worst case: there is no good way to reverse the permissions.  Exchange has some native peculiarities that you're not going to really understand until you're in the thick of actually production deploying it and then it's either too late to change or a pain in the neck to re-do.  See: Two ways to grant access to a Resource in #MSFTExchange.

While it is possible to devise very clever technical solutions (and we have!) experience in this shows that (in stark contrast to a full-state calendar migration) it always leaves a subset of users grumbling that it did not do what they wanted.  

And grumbling is the enemy of a successful enterprise migration.  We prefer a few whining grumbling users to the entire organization ready to “run you out of town.”

Our conclusions from doing these: The effort is better spent as a training opportunity to get users active in setting up their delegates post-migration. 

Junk Mail / filtering Rules

This is potentially a real pain.  Thunderbird HAD a tool for email filtering migration but it's atrophied.

While Microsoft makes it possible to export rules from Outlook and import them to other Outlook clients, in general the methods for taking rules from legacy systems and migrating them simply to Outlook are lacking. And we've never seen it done server-side.


Best strategy we've seen for those who need to deal with it is to identify the high need individuals and get them or their admins training to help re-create essential rule sets. 

Client-side Outlook re-configuration
If users were using Outlook as a client in your legacy system you need to point them all to your Exchange domain now.

Not too difficult.  See Deploy Outlook mail profile settings via GPO or script

The process as described in that link is solid, but we have found problems with the VB script in it. If you are a Sumatra client please feel free to ask us for our VB script:  deployprf.vbs

Your likely result in this 2%:  Experience tells us user response is almost a complete crap-shoot if you try to automate it.  Best you can hope for is a low complaint level.  No one is ever really grateful for it.
Your end-user efforts: Low to Moderate
Your Admin efforts: Moderate to high
Your end-user satisfaction: it’s dependent upon end-user communication and expectation management

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!