After moving a few Windows Server Hyper-V hosts recently from one Virtual Machine Manager server to another, a couple of virtual machines started exhibiting some strange behaviour in regards to networking. So I break out trusty “ping” and it doesn’t report any problems. At that point the remote desktop session is working again so I lost interest assuming it to be “one of those things…”.
After a couple of days this started happening more and more. It wasn’t till I needed to do something one of the servers using remote desktop that I noticed the machine I was expecting to connect to wasn’t the machine I got. At this point it started making a little bit of sense and on inspecting the mac address to look-up the DHCP lease that I realised what it was.
Unlike physical machines, virtual machines do not have hardware generated mac addresses for the network adapters, instead they are taken from a pool of possible mac addresses which can be modified in Hyper-V. Normally Virtual Machine Manager will take care of this for you however as the virtual machines existed before the host was linked to the new Virtual Machine Manager, the issue wasn’t resolved automatically… or highlighted for that matter in the management console (anyone know if you can write your own jobs?).
The fix in my case was to shutdown the virtual machine and remove the network adapter assigned to it and add another. Now you could just change the mac address yourself if you wanted but the adapter in question was legacy so for me it was easier to replace with a synthetic adapter. If you do change the adapted and you were previously using a legacy network adapter also check if you have the option to upgrade the client additions before starting the virtual machine again, as the drive may not be present for the new adapter.
The sysprep automation within Virtual Machine Manger 2008 is a really nice feature which can help you deploy machines quickly and in a “set and forget” manner.
If however you are unfortunate enough to not run your servers in the US locale you may have noticed that even if you change all the regional settings on your template target, after the sysprep has completed and produced a template any machine generated from it will be in the US locale. Luckily there is a solution, however its fairly difficult to find so I thought I would post it for reference:
<?xml version="1.0" encoding="utf-8"?>
<component name="Microsoft-Windows-International-Core-WinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
The above example of an unattend.xml file (answer file) is targeted at x64/amd64 architecture and english/UK. If you are using 32 bit architecture you need to replace “amd64” with “x86”.
Similarly if you need a different locale a list of the locales and codes can be found on the following msdn link
Once you have generated your unattended.xml file add it manually to your library server, once it has been added you can browse to the file as part of the answer file setting in the Guest OS Profile.
Message Queues are a great tool for interprocess communication if you need to ensure that a message is processed, regardless of the target process’s connectivity or runtime state. If you are developing with Microsoft’s .Net Framework you can take advantage of Windows Communication Foundations built-in support for Microsoft Message Queues.
I have been using WCF with Microsoft Message Queues on a recent project, which as part of a back-end processor, the queues are automatically created in the event that they do not exist. The queues can be programmatically created using the following code (C#):
When you deploy this application to a Windows Server 2008 machine, the queue will be created as expected and as default allow messages to be inserted into the queue. However Windows Server 2008 R2 behaves a little differently, as default the queue will not allow anyone other than the owner to insert messages into the queue.