Hyper-V Amigos Showcast Episode 14: RemoteFX & DDA

Posted on February 13, 2017 by workinghardinit

Carsten and I dove into our labs and played around with RemoteFX and Discrete Device Assignment in Windows Server 2016 Hyper-V and RDS. This resulted in the Hyper-V Amigos Showcast Episode 14: RemoteFX & DDA.

Some background on RemoteFX & DDA

I’ve discussed the new capabilities in previous blog posts such as https://blog.workinghardinit.work/?s=DDA&submit=Search and RemoteFX and vGPU Improvements in Windows Server 2016 Hyper-V. But here the Hyper-V Amigos talk about it for your benefit and enjoyment. I for one know we had a ton of fun. Microsoft only VDI solutions are really taking off both on-premises and in Azure in cost conscious environments that still need good performance. I think we’ll see an uptake of such deployments as Microsoft has made some decisions and added some features to make this more feasible.

Hyper-V Amigos Showcast Episode 14: RemoteFX & DDA.

Click this link or the image below to watch Hyper-V Amigos Showcast Episode 14: RemoteFX & DDA

There’s a bit of a learning curve associated with using DDA in Windows Server 2016. You’ll have to get acquainted with how to do it and put it to the test in labs and POCs. Do this before you even start thinking about designing production ready solutions. Having a good understanding on how it works and behaves is paramount to success.

Enjoy!

vNIC Speed in guests on Windows Server 2016 Hyper-V

Posted on January 3, 2017 by workinghardinit

Prior to Windows Server 2016 Hyper-V the speed a vNIC reported was an arbitrary fixed value. In Windows 2012 R2 Hyper-V that was 10Gbps.

This is a screen shot of a Windows Server 2012 R2 VM attached to a vSwitch on an LBFO of 2*1Gbps running on Windows Server 2012 R2 Hyper-V.

This is a screen shot of a Windows Server 2016 VM attached to a vSwitch on an LBFO of 2*10Gbp running on Windows Server 2012 R2 Hyper-V.

As you can see the fixed speed of 10Gbps meant that even when the switch was attached to a LBFO with 2 1Gbps NIC it would show 10Gbps etc. Obviously that would not happen unless the 2 VMs are on the same host and the limitations of the NIC don’t come into play as these are bypassed.Do note that the version of Windows in the guest doesn’t matter here as demonstrated above.

The reported speed behavior has changed in Windows Server 2016 Hyper-V. You’ll get a more realistic view of the network capabilities of the VM in some scenarios and configurations.

Here’s a screenshot of a VM attached to a vSwitch on a 1Gbps NIC.

As you can see it reports the speed the vSwitch can achieve, 1Gbps. Now let’s look at a VM who’s vNIC is attached to a LFBO of two 10Gbps NICs.

This NIC reports 20Gbps inside of the VM, so that’s 2 * 10Gbps.

You get the idea. the vNIC reports the aggregated maximum bandwidth of the NICs used for the vSwitch. If we had four 10Gbps NICs in the LBFO used for the vSwitch we could see 40Gbps.

You do have to realize some things:

Whether a VM has access to the the entire aggregated bandwidth depends on the model of the aggregation. Just consider Switch independent teaming versus LACP teaming modes.
The reported bandwidth has no knowledge of any type of QoS. Not hardware based, or virtual via Hyper-V itself.
The bandwidth also depends on the capabilities of the other components involved (CPU, PCIe, VMQ, uplink speed, potentially disk speed etc.)
Traffic within a host bypasses the physical NIC and as such isn’t constraint by the NIC capabilities it self.
As before the BIOS power configuration has an impact on the speed of your 10Gbps or higher NICs.

The exceptional value of a great technical community

Posted on December 12, 2016 by workinghardinit

There is a tremendous value in being an active community member. You learn form other people experiences. Both their successes and their mistakes. They learn from you. All this at the cost of the time and effort you put in. This, by itself, is of great value.

There are moments that this value reaches a peak. It becomes so huge it cannot be dismissed by even the biggest cynic of a penny pinching excuse for a manager.You see, one day bad things happen to even the nicest, most experienced and extremely competent people. That day, in the middle of the night you reach out to your community. The message is basically “HELP!”.

Guess what, the community, spread out across the globe over all time zones answers that call. You get access to support and skills form your peers when you most need it. Even if you have to pay an hourly fee that would still be a magnitude cheaper than many “premium” support schemes that, while very much needed for that vertical support, cannot match the depth and breath of the community.

For sure, you don’t have a piece of paper, and SLA, an escalation manager. That might upset some people. But what you do get are hard core skills, extra eyes and hands when you need it the most. That, ladies and gentlemen, is the exceptional value of a great technical community at work. Your backup when the system fails. Who ever has committed community experts as employees or partners or owners of a business indirectly has access to a global network of knowledge, talent, skills and experience. If you truly think people are the biggest capital you have, than these are the gems.

Easily migrating non-AD integrated DNS servers while preserving server names and IP addresses

Posted on November 28, 2016 by workinghardinit

Introduction

I’ll show you the quickest way to move an existing public advertising DNS deployment on Windows Server 2012R2, generation 1 virtual machines (1 primary DNS server and 1 or more secondary DNS Servers) to Windows 2016 RTM generation 2 VMs. On top of this we will preserve the sever names and the IP addresses. This makes the migration easier and it doesn’t burden anyone with updating IP addresses or FQDN of services pointing to the existing public advertising DNS service. Basically the result is the best possible for everyone involved.

Step by Step

We start by preparing a sysprepped VHDX of Windows 2016 with all the updates installed and any tools that are sysprep compatible and that you want or need on your VMs. This will allow us to make the move fast. As we want our new DNS VMs to be generation 2 VMS, make sure you use a generation 2 VM to create the syprepped OS VHDX.

The process we describe below is the same for each of the involved DNS servers. You start with the secondary VMs and end with the primary VM. This is just a form risk reduction, it’s smart to start with the secondary as it’s less critical than the primary where you make the changes.

Log on to the old, source VM and do the following

Create a Folder to store the migration data and Info, i.e. C:\DNSMigrateServer01
Open an elevated command prompt
Run Ipconfig /all > C:\DNSMigrateServer01\Server01TCPIPinfo.txt this gives you the IP info you need for future reference.
Run reg export HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters C:\DNSMigrateServer01\Dns-Service.REG
Run reg export HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server” C:\DNSMigrateServer01\Dns-Software.REG
In some cases, rarely for most deployments, you’ll need to also copy all files under each custom database directory on the old DNS server by manually reading from the registry at the following path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\DatabaseDirectory If you have these also copy the directory to C:\DNSMigrateServer01. Normally when you have custom DNS database locations this is not by accident and should be well documented.
Run xcopy %windir%\system32\dns C:\DNSMigrateServer01 /s This copies the content of your DNS folder (normally C:\Windows\System32\dns) to your migration folder. Note that you don’t need to copy the samples sub folder. Even the backup folder is not really needed. Just create a new backup when needed on the news DNS servers.
Copy the C:\DNSMigrateServer01 from your old DNS Server to your desktop or some file share for safe keeping. You’ll need to copy this into the new DNS Server later. Note it contains your IP information, your registry exports and your DNS files.

You now have everything you need form the old DNS Server. So now we’ll decommission it, but before we do so we’ll make sure we have the options to recover it if needed.

Make sure you have a backup or have made on recently (you do trust your ability to restore, right?)
Shut down the VM and for good measure and fast recovery you might want to export the VM for quick import.
Remove the VM from Failover Clustering if it’s clustered.
Now remove the VM from Hyper-V Manager. Note this doesn’t delete the virtual disk files.
Remove the old VHDX (you have an export and a backup) and replace it with your sysprepped W2K16RTM VHDX that has all the updates already. Rename that VHDX to something sensible like server01disk01.vhdx.
Create a new generation 2 VM with the same name as the old one, select the required memory settings, choose to use an existing VHDX and point it to your sysprepped VHDX.
Start the VM
Go through the mini wizard and log in to it.
Configure the NIC with the same setting as your old DNS Server
Rename the VM to the old DNS VM name and join the domain.
Restart the VM
Login to the new DNS VM
Install DNS
Copy the C:\DNSMigrateServer01 you saved from your old DNS Server into the new one
Open an elevated command prompt and run
- Stop the DNS Server service by running net stop “DNS Server”
- Double click the Dns-Service.REG and merge them into the registry

Double click the Dns-Software.REG files and merge them into the registry.

Copy all the files under C:\DNSMigrateServer01 to %windir%\System32\DNS
Start the DNS Server service by running net start “DNS Server”

Congratulations, you now have a new generation 2 VM running DNS on Windows Server 2016 with the same name and IP configuration as the old one. You now want to validate it’s working. To do so on the primary DNS server update the serial number in the start of authority (SOA) tab of the zone properties. I normally use YearMonthDayXX.

This will allow you to check whether the zone transfers to your migrated DNS server work. Normally all is just fine. In case things went horribly wrong you can import the VMs you exported or restore the backups. If your VMs are domain members and as you have reused the VM name, you’ll need to reestablish its domain member ship but that’s easily done.

Now repeat the above process for all the reaming secondary DNS Server and finally for the primary DNS server. Until you’ve done them all.

Conclusion

You do this process for every DNS Server and finally for your primary DNS server. That’s it. You’re in business and you have achieved 2 goals. You’re DNS VMs have been move to generation 2 and are running on a clean install of Windows Server 2016. All this without having to reconfigure DNS zone and transfers and while maintaining your DNS server names and IP addresses. Life is good.

Working Hard In IT

My view on IT from the trenches

Category Archives: Hyper-V