Pages

Tuesday, September 15, 2015

Moving O365 (Office 365) archive mailbox to on-prem Exchange server

I’ve recently been involved with an Office 365 archiving pilot project to demonstrate the user experience and performance for a client to see if it met their requirements and noticed that while it was quite easy to move the archive mailbox from the on-prem Exchange database to O365, there did not seem to be a way to move the mailbox back to the on-prem Exchange. After failing to find instructions through search, I ended up calling Microsoft O365 support for assistance and what ended up being the solution was to use PowerShell. As I’m sure there will be others who find themselves in the same situation as I did, I thought it would be good to write this blog post to demonstrate the steps.

To move the mailbox from O365 to your on-prem Exchange, execute the following New-MoveRequest cmdlet replacing the unique parameters:

$cred = get-credential // Enter your On Premise Admin credential

New-MoverRquest -identity user@domain.com -remotehostname mail.domain.com -archiveonly -archivedomain “domain.com” -Outbound -remotearchivetargetdatabase “db1” -remotecredential $cred

Note the following parameters that need to be changed for your environment:

user@domain.com – replace with the user’s email address
mail.domain.com – your migration endpoint configured in Office 365
domain.com – your SMTP domain
db1 – the name of the on-prem archive database that this user’s archive will be moved to

image

Note that the above immediately begins the move and as with all move requests done on an on-prem Exchange, this move would fail if it encounters any corrupted items. Skipping corrupted items is the same as a regular on-prem Exchange move and to specify a threshold for corrupted items, use the parameter -BadItemLimit # where # is the amount of corrupted item threshold you would like to set.

Get-MoveRequest on its own or with the | FL parameter can be used to review the status of the mailbox move:

image

The Exchange Management Console and navigating to Office 365 > Recipient Configuration > Move Request can also be used for reviewing the status of the archive mailbox migration as such:

image

image

Continue to wait until the move is completed and you should be able to see that the on-prem Exchange archive database is specified as the user’s Archive database:

image

image

The on-prem Exchange Management Shell can also be used to confirm that the user’s archive mailbox database is now on-prem by executing:

Get-Mailbox -identity user@domain.com –archive | FL

image

Note that the ArchiveDatabase is listed as blank when the user’s archive mailbox is still on O365:

image

After the move, you should see that the field is now populated with the on-prem Exchange archive database:

image

Hope this will help anyone looking for off boarding an Office 365 Online Archive mailbox back onto their on-prem Exchange.

------------------------------------------------------------------------------------------------------------------------------------------------------------------

An additional note I’d like to make is if you would like to list all the archive mailboxes active on Office 365, execute the following cmdlet:

Get-MailUser | Where-Object {$_.ArchiveStatus -match "Active"} | fl DisplayName,*archive*

image

Friday, September 11, 2015

AD FS and DirSync services fail to start after server restart

Problem

You’ve successfully installed AD FS and DirSync on their respective Windows Server 2012 R2 servers and have confirmed that both are working as expected. However, you also realize that the services on the AD FS and DirSync servers no fail to start as soon as you restart the server:

DirSync

Service Name: FIMSynchronizationService
Display Name: Forefront Identity Manager Synchronization Service
Service Account: .\AAD_d5b89680b957

Service Name: MSOnlineSyncScheduler
Display Name: Windows Azure Active Directory Sync Service
Service Account: .\AAD_d5b89680b957

image

AD FS

Service Name: Adfssrv
Display Name: Active Directory Federation Services
Service Account: <nonGeneric>

image

Windows could not start the Active Directory Federation Services service on the Local Computer.

Error 1069: The service did not start due to a logon failure.

image

Solution

While there could be various reasons why this issue may occur, one of them is if you have a GPO configured in your domain that specifies what accounts are allowed to have Log on as service rights.  In the environment I worked in, there was such a policy so when I launched the Local Computer Policy editor with gpedit.msc:

image

… I can see that the options to edit the Log on as a service configuration greyed out:

image

The reason why the AD FS and DirSync worked initially is because the install manually granted these service accounts the rights but a restart of the server removed them.

Troubleshooting this issue didn’t actually take me too much time but I can see that it could have if I missed this so I hope this will safe some time for anyone who may encounter the same issue.