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 -remotehostname -archiveonly -archivedomain “” -Outbound -remotearchivetargetdatabase “db1” -remotecredential $cred

Note the following parameters that need to be changed for your environment: – replace with the user’s email address – your migration endpoint configured in Office 365 – your SMTP domain
db1 – the name of the on-prem archive database that this user’s archive will be moved to


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:


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:



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:



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 –archive | FL


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


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


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*


Friday, September 11, 2015

AD FS and DirSync services fail to start after server restart


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:


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



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


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.



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:


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


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.