Server 2012 Hyper-V Live migration poor GUI error message

My colleague recently set up the networking on a backup machine that would be used to accept Server 2012 live migrations. The network was teamed using LACP and we always use the naming convention VMLAG for the VM Ethernet switch.

When I tested live migration from the GUI there was a problem - the error message was the virtual machine was not compatible. The target server was significantly older than the source and had never run a VM before so we started investigating hardware.

We looked through the specifications of the (significantly different Dell models) servers in question and they both met all the requirements of live migration. We rebooted and checked the BIOS and everything was switched on for virtualisation / live migration.

After some head scratching I decided to run the same command in Powershell and lo and behold the real error was displayed:
The original GUI message was still there:
The virtual machine 'XNMTEST' is not compatible with physical computer 'BACKUPSERVER'
But Powershell gave some crucial extra information relating to the error:
Could not find Ethernet Switch VMLAG

I immediately looked more closely at the target server. My colleague had put a space in the VM networking name!

Instead of VMLAG he had typed VM<space>LAG. I renamed the switch to match the source server and it worked perfectly.

2 morals to this story:
Double check the obvious first -  looking at processor specifications and BIOS settings was not required.

Use Powershell to get better error messages - the GUI message whilst technically accurate was somewhat misleading! The GUI should be modified to give the same error messages as Powershell instead of (presumably) just the highest level error.

Ola Hallengren SQL Server Backup Script adds support for MS Shipped objects - eg merge replication metadata tables

SQL Server Merge replication makes very heavy use of metadata tables, and these are likely to become fragmented quickly. My own totally unscientific findings are that regular maintenance of these tables can give a 10% reduction in sync times.
If you want to know more about the subject read this article from BOL:
http://msdn.microsoft.com/en-us/library/ms151789(v=sql.105).aspx

You should be aware that most maintenance systems including the excellent and very popular Ola Hallengren solution http://ola.hallengren.com and the built in SQL Server Maintenance Plan system did not include the merge replication metadata tables.

Whilst investigating Ola's solution I noted that it did not include merge metadata tables which are marked as MS_Shipped objects, so I contacted Ola and he listened carefully, asked some very good questions and decided to add as a feature. The feature is now available in his build and you need to look at the parameter MSShipped objects.

It is commonplace to say the SQL Server built in Maintenance Plan is poor, as it rebuilds all indexes without regard to levels of fragmentation or size of tables etc. This is true but if you are not running 24 x 7 and the extra log generation is not going to create many problems (remember you will be creating/backing up a very large log file with the the built in maintenance plan in full recovery) and you have some disk IO to burn it is a good start and certainly much better than nothing. Take the option for compression if you have a supported version (SQL Server 2008R2 Standard and higher).

Whatever you are using check fragmentation of merge metadata tables.
You can read more here:
http://www.brentozar.com/blitz/merge-replication-with-infinite-history/