Some Notes on the Machines

Older hosted Exchange mailboxes, are starting to fail Autodiscover in newer Outlook installs. Below is a registry fix which gets them working. Apply the change and then reboot, then try it again.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeHttpsRootDomain"=dword:00000001
"PreferLocalXML"=dword:00000000
"ExcludeHttpRedirect"=dword:00000000
"ExcludeHttpsAutodiscoverDomain"=dword:00000001
"ExcludeScpLookup"=dword:00000001
"ExcludeSrvRecord"=dword:00000001
"ExcludeExplicitO365Endpoint"=dword:00000001

First we connect to Exchange Online via Powershell. First we install or update the MSOnline module.

#Install
Set-Executionpolicy RemoteSigned -Scope Process
Install-Module -Name ExchangeOnlineManagement
Import-Module ExchangeOnlineManagement

#Update
Set-Executionpolicy RemoteSigned -Scope Process
Update-Module -Name ExchangeOnlineManagement
Import-Module ExchangeOnlineManagement

Then we connect:

Connect-MsolService

Now get a list of deleted users:

Get-MsolUser -ReturnDeletedUsers

And here’s how we permanently purge all of them. Do this ONLY if you are certain. There is no going back after this.

Get-MsolUser -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin -Force

There are different methods for 365/Azure. But to get directly to Exchange Online from Powershell running on Windows, a current update of longstanding methods is as follows.

To install the module:

Set-Executionpolicy RemoteSigned -Scope Process
Install-Module -Name ExchangeOnlineManagement
Import-Module ExchangeOnlineManagement

To update the module:

Set-Executionpolicy RemoteSigned -Scope Process
Update-Module -Name ExchangeOnlineManagement
Import-Module ExchangeOnlineManagement

To connect:

Connect-ExchangeOnline -UserPrincipalName admin@domain.com

Current reference, including methods for MacOS and Linux as well:

learn.microsoft.com/en-us/powershell/exchange/exchange-online-powershell-v2

These steps change quite often, fair warning!

Steps below are as of 2021-01-04. Please note this has to be done in Internet Explorer or Edge.

First, set permissions.

1. Browse to protection.office.com/homepage , log in as tenant administrator
2. Click eDiscovery Manager.
3. Open eDiscovery Administrator, and add your current admin user.

It takes one hour (as of Microsoft support 2021-01-04) for the permissions to take effect. Used to be up to 24. Afterwards, perform the export.

4. Browse to protection.office.com/homepage , log in as tenant administrator
5. In left pane, click Search, then click Content Search
6. Click New Search
7. At bottom, item Specific locations, click Modify
8. At top left, Exchange email, click “Choose users, groups, or teams”
9. Click “Choose users, groups, or teams” in the new window
10. Enter mailbox email address, wait until the search results come
11. Check the mailbox, and click Choose, then Done
12. Click Save
13. Click Save & run
14. Name the query (and PST), click Save. The query will run. Don’t continue until it’s done. It will say “Status: completed” at the lower left.
15. Click on the word “More” at the top, just to the left of the word “Sort”.
16. Click on “Export results”. Choose options appropriately. Click Export.
17. Click on “Exports” above that area, to the right of “Searches”. If the export does not appear, click on Refresh.
18. Click on the export item.
19. Click on “Download results”. A download applet will start, requiring an export key which can be copied from the browser. Paste it in, choose your download destination, and go! It can take a very long time to start, there is a long preparation phase.

In administrative Powershell:

1. Install-Module AzureAD
2. Install-Module MSOnline
3. Connect-AzureAD
4. Connect-MsolService

In Active Directory Users and Computers, remove the user object from OU being AD-synched. Then complete an Azure/AD sync cycle. Then:

5. Restore-MsolUser -UserPrincipalName users_login_probably_email
6. Set-MsolUser -UserPrincipalName users_login_probably_email -ImmutableId "$null"

Do the last step before the next automatic AD sync!

A couple of links:

https://itpro-tips.com/2019/this-users-on-premises-mailbox-hasnt-been-migrated-to-exchange-online/

https://answers.microsoft.com/en-us/msoffice/forum/all/this-users-on-premise-mailbox-hasnt-been-migrated/5735f499-7079-42a4-a5e9-8da275404d09

If you let the eDiscovery Export Tool time out, it will eventually give you a link:

https://docs.microsoft.com/en-us/office365/securitycompliance/increase-download-speeds-when-exporting-ediscovery-results

which has the registry edit below. No explanation is given, but it does say that adjustment of the number (in some direction?) can help.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Client\eDiscovery\ExportTool]
"DownloadConcurrency"="2"

To count the total number of folders in use within a mailbox, first connect Powershell to Exchange Online, then:

$MailboxToCountFoldersWithin = Get-Mailbox username
$MailboxToCountFoldersWithin | Get-MailboxFolderStatistics | Measure-Object | Select-Object -ExpandProperty Count

The total number of folders, will be output as a number.

This is is caused by bad permissions in a receive connector. The fix:

1. Open ADSIEdit
2. Browse to Configuration, Services, Microsoft Exchange, , Administrative Groups, Exchange Administrative Group, Servers, , Protocols, SMTP Receive Connectors
3. Open the properties for the receive connector(s) involved in the transmissions you are debugging
4. Open the Security Tab. Under “Authenticated Users”, make sure “Accept any Sender” and “Accept Authoritative Domain Sender” are checked.
5. Wait five or ten seconds, and try again.
6. If still not, or if it works for a little while and then does the error again, you probably have severe issues in your Exchange. For a stopgap, you can set permissions for Everyone, but an Exchange rebuild is probably warranted.

From the extraordinary Mike Hunsinger.

The method below has worked perfectly on several servers and has not caused a recovery situation. That said, assure there’s good backups and perform these procedures word-for-word as these Exchange updates have been known to bootloop and bluescreen servers, particularly SBS servers when the original (and these days, ancient) install was not very cleanly done.

The key is to determine the current Exchange SP level, then based on the current version, plan your updates like this: First, install the highest-level rollup for the current SP. Then install the next SP by version. Followed by that SP’s highest-level rollup, then the next SP.

Here’s an example:

Your 2010 Exchange Server is using SP1 RU 3 (Roll-Up3). You intend to upgrade this system to SP3 RU14 (Latest version of Exchange).

Here’s the order in which you should install the updates based on this exchanges current version:

1. Update Rollup 8 for Exchange Server 2010 SP1 (Highest version of SP1)
2. Exchange Server 2010 SP2
3. Update Rollup 8 for Exchange Server 2010 SP2 (Highest version of SP2)
4. Exchange Server 2010 SP3
5. Update Rollup 14 for Exchange Server 2010 SP3 (Highest version of SP3)

Notes found to be important:

• Assure the server’s OS itself is running the latest service pack for Windows Server.

• Exchange SP’s must be downloaded from the web and installed using an exe. Roll-Ups must only be installed via Windows Update.

• Using this pattern of installs and installing Roll-Ups using only Windows Update, will prevent having to perform the lengthy staging process where the mailbox databases are manually converted between versions using CMD.

• Completely review the prerequisites for each Rollup and SP before installing it. There are corroborative softwares such as .net and sql client or certain hotfixes that may need to be installed prior to a given service pack or roll-up.

• During the Service Pack updates, you will see a long checklist the server is moving down while performing the upgrades. If the server errors on one of the checklist items and asks if you wish to continue or roll-back. ROLL IT BACK. Resolve the issue noted and try the update again. You want all 10 lights green when it hits the bottom of the checklist. Errors here are usually the result of insufficient permissions someplace in the server. The errors are usually easy to trace down online.

• Between every update listed. Launch the ECM. Assure the mailboxes are all listed. Then run the builtin Exchange testing. If Exchange says it’s passed, move onto the next update. If Exchange fails any factors, they must be eliminated before continuing.

• Allow up to 1 hour for the server to reboot following an Exchange SP Upgrade. It’s advisable that ILO be activated prior to installing the upgrades described in this document, so you can keep an eye on the server while it reboots.

• I usually allow 1.5h for each service pack and it’s associated rollup.

• It never goes exactly smoothly, so there’s usually some challenges to overcome during each of the updates.