Azure Classic to Resource Manager Migration – Validation failed

I am starting to investigate the migration of resources from Azures Classic deployment mode into the shiny Azure Resource Manager mode.

The first step for me was to attempt to validate the VNET which I wanted to migrate to see if it was compatible. I ran the command listed on the following website (

    Move-AzureVirtualNetwork -Validate -VirtualNetworkName $vnetName

As I expected (nothing is ever simple is it?!) I received an error as shown below. The problem was that the validationmessages shown was limited and didn’t really show me any detail. In my case all it showed me was the name of my VNET.

Validation failed.  Please see ValidationMessages for details

In order to get some more detailed information out of the cmdlet, I ended up saving the validation command to a variable and then calling the variable, as shown below:

$validate = Move-AzureVirtualNetwork -Validate -VirtualNetworkName $vnetName -Verbose


This gave me lots of detail and I discovered that I had typed the VNET name incorrectly. D’oh! I forgot that when you create a Classic VNET in the new portal, the actual name of the VNET is not what you see in the new portal. You need to have a look in the old portal to see the actual name.

Hopefully this helps some folk out there!


Public Folder Migration Fail #2

Another day, another Public Folder migration failure. This time, on testing your Public Folder migration to Office 365, they appear to be unavailable and are not visible in the Outlook client.

I always follow the wonderful guide provided by Microsoft on how to migrate your Public Folders from Exchange > Office 365 (I’m not being sarcastic, it is actually a good guide) available here:

The last two times I have run through this process, I have attempted to test the PF Migration on a single user prior to going live for all users. Microsoft suggest the following command for doing this:

Set-Mailbox -Identity <Test User> -DefaultPublicFolderMailbox <Public Folder Mailbox Identity>

However since the Exchange 2016 wave of Office 365 has gone live, this command no longer appears to have the desired effect. What seems to happen is that because the -IsExcludedFromServingHierarchy parameter is set to $true, the command does not fully enable the Public Folders for that user.

In both situations, I have taken the plunge and enabled Office 365 Public Folders for all users by running:

Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false

The end result (after a little patience) is that Public Folders become available for all users. I’m not sure if this is a general bug or a result of the Exchange 2016 backend of Office 365, but I’d be interested to hear your experiences!


Public Folder Migration Fail

The above title isn’t a surprise for anybody working in IT, but unusually for Public Folders, this one has a fairly simple fix!

The situation is thus; when attempting to complete a Public Folder migration to Office 365, you come across the following error:

Before finalizing the migration, it is necessary to lock down public folders on the legacy Exchange server (downtime required). Make sure public folder access is locked on the legacy Exchange server and then try to complete the batch again.

Public Folder migration error

The problem with this error is that you have already locked down Public Folders on the legacy Exchange Server by running:

Set-OrganizationConfig -PublicFoldersLockedForMigration:$true

So what’s an admin to do when they’ve already run the command they are being told needs to be run?! Some googling may lead you to the idea of rebooting the server, or restarting the Information Store. Both of these will work, but a much simpler solution is simply to dismount the Public Folder database/s, and then mount them. The PFs are already locked so are unavailable to the users so there is no negative impact of doing this.

TL;DR – turn it off, and turn it on again.


Exchange Online Public Folder Migration Fail

Today I have been migrating Public Folders (yuk!) from Exchange 2010 to Exchange Online, and have come across a slightly odd issue.

I had followed the lovely guide to Public Folder migrations provided by Microsoft here, however I could not complete my migration as the migration batch had completed with errors. The error I was receiving was as follows:

Error: MigrationMRSPermanentException: Error: There are 2 mail public folder‎(s)‎ in Active Directory that were not linked to any public folder during migration.

The Public Folders referenced in the error message were both Exchange system folders, so I wasn’t sure why it was bothering to try and synchronise them. Luckily the error message does give us a clue as to what to do;

You may also run "Set-MailPublicFolder -IgnoreMissingFolderLink:$true" for each AD object that is a legacy system folder and resume the migration

Being the silly person I am, I assumed that this command needed to be run against the legacy Public Folders On Premise, but apparently -IgnoreMissingFolderLink is not a parameter in Exchange 2010. What I actually needed to do, which is not obvious from the error message,  was to run this command in Exchange Online. I ended up using a catch all command, which looked like this:

Get-MailPublicFolder | Set-MailPublicFolder -IgnoreMissingFolderLink:$true

Once this was done, I stopped the migration batch, and then started it again. It then performed it’s initial sync and I was able to continue the migration!


Office 365 Hybrid Mailbox Move stuck in ‘Removing’ state

This is an issue I’ve come across more than once now. An attempted mailbox move from Exchange 2010/2013 to Office 365 has failed and you want to remove the migration batch and try again. You try to remove the batch, but it just gets stuck in the ‘Removing’ state for an extended period of time. We need to give this request the finger and start from scratch, but how?

First things first, lets check the status of the move using Powershell, as Powershell will never lie! Login to Exchange Online Powershell, and run:

get-migrationbatch -identity <nameofbatch> | fl

If the status does read as ‘Removing’ and it’s been a long time since you started the removal, then you likely have a corrupted batch. Let’s forcefully remove it. To remove the batch, run:

Remove-migrationbatch -identity <nameofbatch> -force

If you now run the get-migrationbatch command above, you should get an error which states that the batch does not exist. Good news! We now just need to clear out the migration user requests which will still be lingering. To see which user requests exist, run:


If the only users in here are the users which were associated with your migration batch, then you can run:

Get-MigrationUser | Remove-MigrationUser -Force

to remove all of the migration user requests. However if there are other user requests in here which you do not want to remove, then remove the users individually by running:

Remove-MigrationUser <Identity> -Force

Now if you run the Get-MigrationUser command, you should see that the users who were in the corrupted batch are no longer listed. You can start a new batch once you’ve resolved whatever issue caused the mailbox move to fail and all should be tickety-boo 🙂

In our case we were running mailbox export commands at the same time as mailbox migrations, and we had some timeout issues with the Mailbox Replication Service. The error we received in the migration report was “Relinquishing job because of large delays due to unfavorable server health or budget limitations”. Simple fix, just remove the migration batch once the exports were complete, and start again. What we didn’t bank on would be that the migration batch would become corrupted. To resolve this, we allowed our mailbox exports to complete, and then restarted the Microsoft Exchange Replication Service. We then cleared the corrupted batch using the commands shown above, and started in again. It completed successfully this time.

Move-DatabasePath error ‘WMI exception occurred on server’

Today I discovered a problem affecting the migration of a database path to a new location in Exchange 2010. After running the Move-DatabasePath cmdlet and specifying the -LogFilePath and -EdbFilePath parameters, I was faced with an error which read:

Failed to connect to target server “DDExch”. Error: WMI exception occurred on server ‘DDExch.DDAD.local’:
Call cancelled
+ CategoryInfo          : InvalidOperation: (DDDB02 Live:DatabaseIdParameter) [Move-DatabasePath], InvalidOperatio
+ FullyQualifiedErrorId : 6C2ED31B,Microsoft.Exchange.Management.SystemConfigurationTasks.MoveDatabasePath

It turns out that this error is related to having a large quantity of log files in Exchange 2010. The version I am running is SP3 but I am unsure as to whether this makes any difference. I also tried running this in EMC and had the same result.

To resolve this problem, either perform log truncation using your preferred Exchange backup tool, or enable circular logging to truncate the logs. Remember, after enabling circular logging, you will need to dismount and mount the database for it to take effect. I would recommend that you disable circular logging after this and dismount/mount the DB again.

Hope this helps some folk struggling with a database migration.