Some Notes on the Machines

There is an alternative activation logon screen.

https://answers.microsoft.com/en-us/msoffice/forum/msoffice_account-mso_win10/unable-to-sign-in-to-office-2016-desktop-apps-sign/b32738c8-1b17-43d1-839b-cb97c8ae3c29

From the indefatigable Mike Crayton:

https://www.thecloudjournal.net/2016/08/reset-microsoft-office-product-activation-status/

https://gallery.technet.microsoft.com/office/How-To-Reset-Office-01cf9c07

This can help a lot when Office will not activate.

New version, as of 2018-10-29:

www.microsoft.com/en-us/download/details.aspx?id=47594

When this happens, do the following in Azure AD Connect:

1. In “Customize synchronization options”, disable (uncheck) the password hash sync option.
2. Wait for sync to complete, watching in the Operations tab of the Synchronization Service Manager.
3. In “Customize synchronization options”, enable (check) the password hash sync option.
4. Wait for sync to complete, watching in the Operations tab of the Synchronization Service Manager.
5. Check the Office 365 admin readout.

When recent versions of Outlook and other Office applications run certain plugins, sometimes the result will come up in a separate window called “AdxTaskPane”. To prevent this:

1. File > Options > General > User Interface options
2. Choose “Optimize for compatibility (application restart required)”
3. Restart the application

When you do an Office 365 / EOL migration with Azure AD Sync in place, mailboxes may freeze up, where in the O365 console under “Mail Settings” for one or more mailboxes, it says “This user’s on-premises mailbox has not been migrated to Exchange Online. The Exchange Online mailbox will be available once migration is completed.” One may spend a whole lot of time, even with Microsoft on the line, not fixing this problem.

There may be more than one cause. But a very important cause and fix is outlined here:

https://mikeparker365.wordpress.com/2016/01/07/how-to-filter-out-msexchmailboxguid-from-aad-connect-sync/

The gist of it is, one of the user attributes synched up from the on-prem server is “msExchMailboxGuid”, and this is trouble, because if this is synched up, EOL thinks it is trying to make a duplicate of an existing mailbox, rather than a new one, and it will not make a duplicate, it is in fact waiting for this attribute to be deleted before proceeding.

So what we do, is we go to Synchronization Service, right-click on “Active Directory Domain Services”, make sure “Connector Designer” is selected, and then scroll down to msExchMailboxGuid , and uncheck it. Then click OK.

The next step is to kick off a sync. The easiest way is in Powershell on the server which has AD Sync installed:

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Initial

You can watch the progress in “Synchronization Service” if you like; after the two final exports are complete it is done. But we’re not done yet.

The next step, is to remove the licenses from all of the O365 accounts which are marked as not yet migrated.

Then run another sync.

Then add the licenses back.

And run another sync.

That did it this morning!

These two will do it in the current version as of this writing:

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Initial 

The above is a full sync, necessary in a minority of circumstances. A delta sync is as follows:

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta

From the profound Mike Crayton. We do this:

1. Create an admin role group named “Manage Distribution Groups”, with the admin role of “Distribution Groups”, setting as members the user(s) to be given this ability
2. Give them this URL for getting to the management console:
   https://outlook.office.com/ecp/

These are not very documented, and at least at this writing, the informatives in the console were incomplete. Here’s the steps I have working at this writing, postulating the domain at hand being “emaildomain.com”:

1. First, in the O365 Exchange administrative console, go to the Protection area, and the rightmost tab is “dkim”, click on that. Then try to Enable any which are disabled. You will see an error message which says you need to create two CNAMEs. The two strings given, are the alias targets, the alias names are not given. Use these in the next step.

2. Set CNAMEs in Internet DNS. The alias names are the same every time; the targets are taken from the error message in step 1. They are not always entirely predictable, sometimes you will see “0i” buried within and there may be other variations. But the result will not be very distant from this:

selector1._domainkey.emaildomain.com
CNAME to
selector1-emaildomain-com._domainkey.emaildomain.onmicrosoft.com.
TTL 3600

selector2._domainkey.emaildomain.com
CNAME to
selector2-emaildomain-com._domainkey.emaildomain.onmicrosoft.com.
TTL 3600

3. Once your DNS changes have propagated thoroughly, go back to step #1 and try to enable DKIM again for the domain whose records you have just changed. If you have done your CNAMEs correctly, O365 will turn DKIM on. You may need to wait for DNS propagation.

After migrating all email accounts from an on-premises Exchange 2008 or later server to Exchange Online, there remains the problem of what to do about new Outlook profile creation. Outlook will still look for the old server name, and especially if you want to keep the old server alive for a while, you will have significant problems getting Outlook 2013 to do anything with Exchange Online. Here is what the extraordinary Matt Quick and I did recently with beautiful results.

For the sake of this discussion, “localdomain.local” is the LAN-local AD-enabled domain, and “publicdomain.pub” is the Internet domain. The on-prem Exchange originally had local DNS name “exchange.localdomain.local” and Internet DNS name “exchange.publicdomain.pub”.

1. Migrated all mailboxes from on-premises Exchange 2010 to Exchange Online. Dirsync was used for initial account setup, then turned off for the actual copyover process which was done with MessageOps.
2. In Exchange Management Shell, ran Get-ClientAccessServer to get the canonical name of on-prem Exchange (we’ll say it was EXCHANGENAME), and then Set-ClientAccessServer -Identity EXCHANGENAME -AutoDiscoverServiceInternalUri $NULL (replacing EXCHANGENAME with the actual name) to nullify as many defaults as possible.
3. Set autodiscover.localdomain.local as a CNAME to autodiscover.outlook.com.
4. Set autodiscover.publicdomain.pub as a CNAME to autodiscover.outlook.com in Internet DNS. This LAN has a local copy of publicdomain.pub in its domain controllers, so copied this record to the local server as well.
5. Unregistered the NIC for the on-premises Exchange server in DNS. The checkboxes are in the DNS tabs of both TCP/IPv4 and TCP/IPv6, within the Advanced area of the NIC. This is done so that DNS changes which are next, will not be undone automatically.
6. Removed DNS A records exchange.localdomain.local and exchange.publicdomain.pub from local and Internet DNS respectively.
7. Added DNS CNAME records exchange.localdomain.local and exchange.publicdomain.pub, both pointing to outlook.office365.com, to local and Internet DNS as appropriate.
8. Set up oldexchange.localdomain.local and oldexchange.publicdomain.pub as A records pointing to the IP being used by the on-premises Exchange, to local and Internet DNS as appropriate, for archival uses and until we are ready to decommission the on-prem Exchange altogether.