Exchange Server

Restoring an accidentally migrated mail user to On-Prem Exchange

We recently migrated most of our users to Office 365, and due to a miscommunication, three users that should have stayed on premises were migrated, converted to the RecipientTypeDetails RemoteUserMailbox, and had their local mailboxes disconnected.

Reconnecting their mailboxes failed as they were of the wrong user type:

Connect-Mailbox -Identity "Name Surname" -Database "DB10" -User "Name Surname"
This task does not support recipients of this type. The specified recipient Name Surname is of type User. Please make sure that this recipient matches the required recipient type for this task.
    + CategoryInfo          : InvalidArgument: (Name Surname:UserIdParameter) [Connect-Mailbox], RecipientTaskException
    + FullyQualifiedErrorId : E9DDBACA,Microsoft.Exchange.Management.MapiTasks.ConnectMailbox

The solution was to remove the Exchange properties from the user object:

Get-Recipient -Identity "Name Surname" | Disable-RemoteMailbox

After confirming this is what we want to do, the mailbox could be safely reconnected.

However: After reconnecting the mailboxes, the users still couldn’t start Outlook: The program failed to start with an error message “The set of folders cannot be opened”.

The issue here is that DSAccess caches an erroneous query, and the solution is to update the status of disconnected or soft-deleted mailboxes:

Clean-MailboxDatabase -Identity "DB10"

After this, the users could continue working as usual.

Fixing “No DKIM keys saved for this domain” in EOP and Office365

Sometimes a newly added domain in Microsoft EOP will not let you enable DKIM from the web user interface. The only workaround I know of is to prepare the domain using PowerShell.

To connect a PS session to O365, I use the following script, ripped straight from Microsoft’s documentation:

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session -DisableNameChecking

After waiting for an eternity for the necessary stuff to load, run the following command – and wait another eternity for it to finish:

New-DkimSigningConfig -DomainName "mydomain.tld" -Enabled $true

Note: Unless you’ve already added the necessary _domainkey CNAME records to your DNS zonefile, this command will succeed in generating the DKIM keys, but will fail to enable DKIM signing for the domain. Without looking into it I suspect that the Set-DkimSigningConfig cmdlet could be used to enable signing.

Finally disconnect from your O365 PS session:

Remove-PSSession $Session

Your domain now signs mail sent through O365 or via Exchange Online Protection.

Bonus knowledge: With a recent version of PowerShell Core installed, you can manage situations like this from a regular Mac or Linux box.

Exchange – another lesson learned

This is why we test things before going live:
After migrating a test box from the old Exchange environment, it could receive mail just fine, and sending mail out of the organization worked flawlessly too. Unfortunately any mail sent from this account to recipients within the old Exchange environment got stuck in the mail queue.

Logically as usual, the fix was to complement the default receive connectors on the old servers with the explicit addresses of the new Exchange servers, even though they naturally were well within the 0.0.0.0-255.255.255.255 range. Way to go, Microsoft!