Import of RD Gateway configuration file with policies referencing local resources wipes all policies clean!

Introduction

When you have Windows Server 2016 RD Gateway server and you expect to be able to import a configuration XML file you’ll might find yourself in a pickle when you are also using local resources. Because the import of RD Gateway configuration file with policies referencing local resources wipes all policies clean! With local resources I mean local user accounts and groups. These are leveraged more than I imagined at first.

When does it happen?

In the past I have blogged about migrating RD Gateway servers that contain policies referencing local resources here: Fixing Event ID 2002 “The policy and configuration settings could not be imported to the RD Gateway server “%1” because they are associated with local computer groups on another RD Gateway server”.

We used to be able to use the trick of making sure the local resources exist on the new server (either by recreating them there via the server migration wizard or manually) and changing the server name in the exported configuration XML file  to successfully import the configuration. That no longer works. You get an error.Import of RD Gateway configuration file with policies referencing local resources wipes all policies clean!

As far as migrations go from older versions, they work fins as long as you don’t have policies with local resources. Otherwise you’d better do an in place upgrade or recreate the resources & policies on the new servers. The method described in my blog is not working any more. That’s to bad. But it gets worse.

Import of RD Gateway configuration file with policies referencing local resources wipes all policies clean!

As said,it doesn’t end there. The issue is there even when you try to import the configuration on to the same server you exported it from.That’s really bad as it a quick way to protect against any mistakes you might make, and allows to get back to the original configuration.

What’s even worse, when the import fails it wipes ALL the policies in the RD Gateway Server => dangerous! So yes, the import of RD Gateway configuration file with policies referencing local resources wipes all policies clean!

Precautions

Only a backup or a checkpoint can save your then (or recreate the all manually)! Again this is only when the exported configuration file references local resources! The fasted way to clean out an RD Gateway configuration on Windows Server 2016 is actually importing a configuration export which contains a policy referring to local resource. Ouch! I’m not aware of a fix up to this date.

For now you only protection is a checkpoint or a backup. Depending on where and how you source your virtual machines you might not have access to a checkpoint.

You have been warned, be careful.

The exceptional value of a great technical community

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.

Disk2VHD on a Generation 2 VM results in an unbootable VHDX

Most people who have been in IT for a while will know the Windows  Sysinternals tools and most certainly the small but brilliant Disk2VHD tool we can use for Physical To Virtual (P2V) and Virtual to Virtual (V2V) conversions. It’s free, it’s good and it’s trustworthy as it’s made available by Microsoft.

For legacy systems, whether they are physical  with IDE/SATA/SAS controllers or virtual with an IDE generation 1 VMS thing normally go smooth.

image

But sometimes you have hiccups. One of those is when you do a V2V of a generation 2 virtual machine using Disk2VHD. It’s a small issue, when you create a new generation 2 VM and point it to the OS vhdx it just won’t boot. That’s pretty annoying.

image

Why do a V2V in such a case you might ask. Well, sometimes is the only or fasted way to get out of pickle with a ton of phantom, non-removable checkpoints you’ve gotten yourself into.

But back to the real subject, how to fix this. What we need to do is repair the boot partition. Well recreate it actually as when you look at it after the conversion you’ll notice is RAW. That’s no good. So let’s walk through how to fix a vdhx that your created from a source generation 2 Hyper-V vm via Disk2VHD.

First of all create a new generation 2 VM that we’ll use with our new VHDX we created using Disk2VHD. Don’t create a new vdhx but select to use an existing one and point it to the one we just created with Disk2VHD. Rename it if needed to something more suitable.

Don’t boot the VM but add a DVD and attach the Windows Server ISO of the version your vhdx contains to the DVD.

image

Move the DVD to the top of the boot order I firmware.

image

The VM will boot to the DVD when you hit a key.

Select your language and keyboard layoout when asked and the don’t install or upgrade the OS but boot

image

image

 

image

 

 

image

 

image

Type diskpart and  list the disks. Select the disk we need (the OS disk, the only one here) and list the volumes. You can see that volume 3 off 99MB is RAW. That’s not supposed to be that way. So let’s fix this by creating boot loader directory structure, repair the boot record by creating the boot sector & copy the needed boot files into it.

Type:

select volume 3

assign drive letter L:

FORMAT FS=FAT32 LABEL=”BOOT”

That’s it we can now us that 99MB volume to make our disk bootable to windows again.  Type Exit to leave diskpart.

image

So now we have a formatted boot partition we can create the need folder structure and fix the boot record and configure our UEFI bootloader

Switch to the L: volume

create efi\microsoft\boot folder structure for the bootloader as show below with the md command(make directory)

Type: bootrec /fixboot to create the bootrecord

Type: bcdboot C:\Windows  /l en-us /s l: /f ALL

This creates the BCD store & copies the boot files from the windows system directory

 image

Just click Continue to exit and continue to Windows Server 2012R2

image

.. and voila, your new VM has now booted.

image

Now it’s a matter of cleaning up the remnants of the original VMs hardware such as the NIC and maybe some other devices. The NIC is very important as it will have any static TCP/IP configuration you might want to assign tied to it which mean you can’t reuse it for your new VM. So, the 1st thing to do is uninstall the old network adapters from device managers, you’ll see them when you select “show hidden devices” in the view menu.

Good luck!

July 2016 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2

Microsoft recently released another update rollup (aka cumulative update). The

July 2016 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2.

This rollup includes improvements and fixes but more importantly it also contains ‘improvements’ from June 2016 update rollup KB3161606 and May 2016 update rollup KB3156418. When it comes to the June rollup KB3161606 it’s fixes the bugs that cause concerns with Hyper-V Integration Components (IC) to even serious down time to Scale Out File Server (SOFS) users. My fellow MVP Aidan Finn discuses this in this blog post. Let’s say it caused a wrinkle in the community.

In short with KB3161606 the Integration Components needed an upgrade (to 6.3.9600.18339) but due to a mix up with the manifest files this failed. You could leave them in pace but It’s messy. To make matters worse this cumulative update also messed up SOFS deployments which could only be dealt with by removing it.

Bring in update rollup 3172614. This will install on hosts and guest whether they have  already installed or not and it fixes these issues. I have now deployed it on our infrastructure and the IC’s updated successfully to 6.3.9600.18398. The issues with SOFS are also resolved with this update. We have not seen any issues so far.

image

In short, CU should be gone from Windows Update and WSUS. It it was already installed you don’t need to remove it. CU will install on those servers (hosts and guests) and this time is does things right.

I hope this leads to better QA in Redmond as it really is causing a lot of people grief at the moment. It also feed conspiracy nuts theories that MSFT is sabotaging on-premises to promote Azure usage even more. Let’s not feed the trolls shall we?