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"