Installing & using the Windows Server Migration Tools To Migrate Local Users & Groups

Introduction

I was working on a little project for a company that was running TS Gateway on 32bit Windows 2008. The reason they did not go for x64 at the time was that they used Virtual Server as their virtualization platform for some years and not Hyper-V. One of the drawbacks was that they could not use x64 guest VMs. Since then they have move to Hyper-V and now also run Window Server 2012. So after more than 5 years of service and to make sure they did not keep relying on aging technology it is time to move to Windows Server 2012 RD Gateway and reap the benefits of the latest OS.

All in all the Microsoft documentation is not too bad, all be it that the information is a bit distributed as you need to use various tools to complete the process. Basically, depending on the original setup of the source server you’ll need to use the TS/RD Gateway Export & Import functionality, Web Deploy (we’re at version 3.0 at the time of writing) and the Windows Server Migration Tools that were introduced with Windows 2008 R2 and are also available in Windows Server 2012.

In a number of posts I’ll be discussing some of the steps we took. You are reading the second post.

1. x86 Windows Server 2008 TS Gateway Migration To x64 Windows Server 2012 RD Gateway
2. Installing & using the Windows Server Migration Tools To Migrate Local Users & Groups
3. TS/RD Gateway Export & Import (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”)

As discussed in the first part we need to migrate some local users & groups on the TS Gateway (source) server as they are also being used for some special cases of remote access, next to Active Directory users & groups for the Remote Access Policies (RAPs) & Connection Authorization Policies (CAPs). The tool the use is the Windows Server Migration Tools. These were introduced with Windows 2008 R2 and are also available in Windows Server 2012.

Some people seem to get confused a bit about the installation of the Server Migration Tools but it’s not that hard. I have used these tools several times before in the past and they work very well. You just need to read up a bit on the the deployment part and once you have it figured out they work very well.

Installing the Windows Server Migration Tools on the DESTINATION Server

First we have to install the on the DESTINATION host (W2K12 in our case, the server to which you are migrating)). For this we launch Server Manager and on the dashboard select Manage and choose Add Roles & Feature.

Navigate through the wizard until you get to Features. Find and select Windows Server Migration Tools. Click Next.

Click Install to kick of the installation.

After a while your patience will be rewarded.

Installing the Windows Server Migration Tools on the SOURCE Server

To install the Windows Server Migration Tools on the SOURCE server, you need to run the appropriate PowerShell command on the DESTINATION server. This is what trips people up a lot of the time. You deploy the correct version of the tools from the destination server to the source server, where you will than register them for use. Do this with an admin account that has admin privileges on both the DESTINATION & SOURCE Computer.

Start up the Windows Server Migration Tools from Server Manager, Tools.

This launches the Windows Server Migration Tools PowerShell window.

Our SOURCE server here is the32 bit (X86)  Windows 2008 TS Gateway Server. The documentation tells us the correct values to use for the parameters /architecture and /OS to use.

SmigDeploy.exe /package /architecture X86 /os WS08 /path \\SourcerServer\c$\sysadmin

Now before you run this command be sure to go to the ServerMigrationTools folder as the UI fails to do that for you.

Also this is PowerShell so use .\ in front of the command otherwise you’ll get the error below.

While you want this:

Now you have also deployed the correct tools to the SOURCE server, our old legacy TS Gateway Server. Next we need to register these tools on the SOURCE Server to be able to use them. You might have gotten the message already you need PowerShell deployed on the SOURCE Server as documented.

If you have PowerShell, launch the console with elevated permissions (Runs As Administrator) and run the following command: .\SmigDeploy.exe

Congratulations you are now ready to use the Windows Server Migration Tools! That wasn’t so hard was it?

Using the Windows Server Migration Tools To Migrate Local Users & Groups

To export the local users and groups from the source TS/RD Gateway server you start up the Windows Server Migration Tools on the SOURCE server (see the documentation for all ways to achieve this) and run the following PowerShell command:
Export-SmigServerSetting -User All  -Group –Path C:\SysAdmin\ExportMigUsersGroups –Verbose

As you can see I elected to migrate all user accounts not just the enabled or disabled ones. We’ll sort those out later. Also note the command will create the folder for you.

To import the local users and groups to the target RD Gateway server you start up the Windows Server Migration Tools on the Destination server (see the documentation) , i.e. our new Windows Server 2012 RD Gateway VM.

and run the following PowerShell command:

Import-SmigServerSetting  -User Enabled  -Group -Path C:\SysAdmin\ExportMigUsersGroups -Verbose

Do note that the migrated user accounts will be disabled and have their properties set to "Next Logon". This means you will have to deal with this accordingly depending on the scenarios and communicate new passwords & action to take to the users.

Do note that the local groups have had the local or domain groups/users added by the import command. Pretty neat.

You’re now ready for the next step. But that’s for another blog post.

x86 Windows Server 2008 TS Gateway Migration To x64 Windows Server 2012 RD Gateway

Introduction

I was working on a little project for a company that was (still) running TS Gateway on a 32 bit  x86) version Windows 2008. The reason they did not go for x64 at the time of deployment was that they then used Microsoft Virtual Server as their virtualization platform and had been for some years.

In a number of posts I’ll be discussing some of the steps we took. You are reading the first one.

1. x86 Windows Server 2008 TS Gateway Migration To x64 Windows Server 2012 RD Gateway
2. Installing & using the Windows Server Migration Tools To Migrate Local Users & Groups
3. TS/RD Gateway Export & Import (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”)

In those early days of W2K8 they had not yet switched to Hyper-V. As an early adopter I was able to show the the reliability of Hyper-V, so later they did.

One of the drawbacks of using Microsoft Virtual Server was that they could not use x64 guest VMs and that’s how they ended up with x86, which was still available for a server OS for W2K8. Since then they have move to Hyper-V and now also run Window Server 2012. Happy customers! So after more than 5 years of service and to make sure they did not keep relying on aging technology it is time to move to Windows Server 2012 RD Gateway and reap the benefits of the latest OS.

The Migration

Their is no in place upgrade from a x86 to an x64 OS. So this has to be a migration. No worries this is supported. With some insight, creativity and experience you can make this happen. The process reasonably well documented on TechNet, but not perfectly, and your starting point is right here RD Gateway Migration: Migrating the RD Gateway Role Service. These docs are for Windows Server 2008 R2 but still work for Windows Server 2012. Another challenge was we needed to also migrate their custom website used for the employees to check whether their PC is still on and if not wake it up or start it up remotely.

There are some things to take care of and I’ll address these I some later blog posts but I want you to take to heart this message. While an in place upgrade of an 32 bit X86 operating system to X64 version of that OS is not possible that doesn’t mean you’re in  a pickle and will have to start over from scratch. For many scenario’s there are migration paths and this is just one example of them, or better two combined,TS Gateway and a Website.

If You Can, You Should Attend TechEd 2013 Europe

It’s that time of the year again, when TechEd is coming closer. I’m attending the European Edition in Madrid, Spain. But I can guarantee you I will be on line a lot during the USA edition as well. At be attending the USA edition this year if I could but work, time and budget wise I can’t make that happen. This isn’t because the European edition is less, absolutely not. The reason is that at MMS2013 in Las Vegas last month we got the heads up that Microsoft will start talking publicly about the new version of Windows and I’m game for that. Windows Server 2012 is the best Windows version ever but I know what I’d like to see in there to make it even better. I’m kind of curious if anyone at MSFT follows my thinking on this subject. I hope so!

So yes I’m a TechEd advocate, you bet! If you want to know why, read my blog post here on http://workinghardinit.wordpress.com/2010/06/05/why-i-find-value-in-a-conference/.

Come and learn amongst your peers, network with them and industry experts. To become competent and gain expertise you are going to have to get out there and expose your ideas, insights and thinking to your peers around the globe. That’s how it works. To those who dismiss quality conferences like this I can only say that you are wrong. To those who claim it’s a paid holiday I can only say that to a liar all other men are liars and to a thief all other men are thieves.  Enough said. Invest in knowledge and competence development, it will pay of better than some extra thousands of € in the bank!

So if you can please join me and attend TechEd. It’s a blast and a tremendous learning experience. I never ever miss attending TechEd, not even at times it wasn’t easy for me to do so. You can register here. I hope to see you there!

SMB Direct RoCE Does Not Work Without DCB/PFC

Introduction

SMB Direct RoCE Does Not Work Without DCB/PFC. “Yes”, you say, “we know, this is well documented. Thank you.” but before you sign of hear me out.

Recently I plugged to RoCE cards into some test servers and linked them to a couple of 10Gbps switches. I did some quick large file copy testing and to my big surprise RDMA kicked in with stellar performance even before I had installed the DCB feature, let alone configure it. So what’s the deal here. Does it work without DCB? Does the card fail back to iWarp? Highly unlikely. I was expecting it to fall back to plain vanilla 10Gbps and not being used at all but it was. A short shout out to Jose Barreto to discuss this helped clarify this.

DCB/PFC is a requirement RoCE

The more busy the network gets the faster the performance will drop. Now in our test scenario we had two servers  for a total of 4 RoCE ports on the network consisting of a beefy 48 port 10Gbps switches. So we didn’t see the negative results of this here.

DCB (Data Center Bridging) and Priority Flow Control are considered a requirement for any kind of RoCE deployment. RDMA with RoCE operates at the Ethernet layer. That means there is no overhead from TCP/IP, which is great for performance. This is the reason you want to use RDMA actually. It also means it’s left on it’s own to deal with Ethernet-level collisions and errors. For that it needs DCB/PFC other wise you’ll run into performance issues due to a ton of retries at the higher network layers.

The reason that iWarp doesn’t require DCB/PCF is that it works at the TCP/IP level also offloaded by using a TCP/IP stack on the NIC instead of the OS. So errors are handled by TCP/IP at a cost: iWarp results in the same benefits as RoCE but it doesn’t scale that well. Not that iWarp performance is lousy, far form! Mind you, for bandwidth management reasons,you’d be better of using DCB or some form of QoS as well.

Conclusion

So no, not configuring  DCB on your servers and the switches isn’t an option, but apparently it isn’t blocked either so beware of this. It might appear to be working fine but it’s a bad idea. Also don’t think it defaults back to iWarp mode, it doesn’t, as one card does one thing not both. There is no shortcut. RoCE RDMA does not work error free out of the box so you do have the install the DCB feature and configure it together with the switches.

MVP Carsten Rachfahl Visits & Interviews Me On Networking & Storage in Windows Server 2012

Last month Carsten (MVP – Virtual Machine) & Kerstin Rachfahl (MVP – Office 365) visited me in my home town. Apart from a short visit to the historic center & a sushi diner amongst friends we also did an interview where we discussed our ongoing Windows Server 2012 Hyper-V activities. We’re trying to leverage as much of the product we can to get the best TCO & ROI and as early adopters we’ve been reaping the benefits form the day the RTM bits were available to us. So far that has been delivering great results. Funny to hear me mention the Fast Track designs as a week later we saw version 3 of those at MMS2013. The most interesting to me about those was the fact that the small & medium sizes focus on Cluster in a Box and Storage Spaces!

While we were having fun talking about the above we also enjoyed some of the most beautiful landmarks of the City of Ghent as a back drop for the interview. It was filmed in a meeting room at AGIV, to whom I provide Infrastructure services with a great team of colleagues. Just click the picture to view the video.

You can also enjoy the video on Carsten’s blog http://www.hyper-v-server.de/videos/interview-mit-didier-van-hoye-ber-seinen-storage-netwerk-und-mehr/ All I need to do now is to arrange for Carsten to physically touch the Compellent storage I think.

SMB 3.0 Multichannel Auto Configuration In Action With RDMA / SMB Direct

Most of you might remember this slide by Jose Barreto on SMB Multichannel  Auto Configuration in one of his many presentations:

• Auto configuration looks at NIC type/speed => Same NICs are used for RDMA/Multichannel (doesn’t mix 10Gbps/1Gbps, RDMA/non-RDMA)
• Let the algorithms work before you decide to intervene
• Choose adapters wisely for their function

You can fine tune things if and when needed (only do this when this is really the case) but let’s look at this feature in action.

So let’s look at this in real life. For this test we have 2 * X520 DA 10Gbps ports using 10.10.180.8X/24 IP addresses and 2 * Mellanox  10Gbps RDMA adaptors with 10.10.180.9X/24 IP addresses. No teaming involved just multiple NIC ports. Do not that these IP addresses are on different subnet than the LAN of the servers. Basically only the servers can communicate over them, they don’t have a gateway, no DNS servers and are as such not registered in DNS either (live is easy for simple file sharing).

Let’s try and copy a 50Gbps fixed VHDX file from server1 to server2 using the DNS name of the target host (pixelated), meaning it will resolve to that host via DNS and use the LAN IP address 10.10.100.92/16 (the host name is greyed out). In the below screenshot you see that the two RDMA capable cards are put into action. The servers are not using  the 1Gbps LAN connection. Multichannel looked at the options:

• A 1Gbps RSS capable Link
• Two 10Gbps RSS capable Links
• Two 10Gbps RDMA capable links

Multichannel concluded the RDMA card is the best one available and as we have two of those it use both. In other words it works just like described.

Even if we try to bypass DNS and we copy the files explicitly via the IP address (10.10.180.84)  assigned to the Intel X520 DA cards Multichannel intelligence detects that it has two better cards  that provide RDMA available and as you can see it uses the same NICs  as in the demo before.  Nifty isn’t it

 

If you want to see the other NICs in action we can disable the Mellanox card and than Multichannel will choose the two X520 DA cards. That’s fine for testing but in real life you need a better solution when you need to manually define what NICs can be used. This is done using PowerShell (take a look at Jose Barrto’s blog The basics of SMB PowerShell, a feature of Windows Server 2012 and SMB 3.0  for more info).

New-SmbMultichannelConstraint –ServerName SERVER2 –InterfaceAlias “SLOT 6 Port 1”, “SLOT 6 Port 2”

This tells a server it can only use these two NICs which in this example are the two Intel X520 DA 10Gbps cards to access Server2. So basically you configure/tell the client what to use for SMB 3.0 traffic to a certain server. Note the difference in send/receive traffic between RDMA/Native 10Gbps.

On Server1, the client you see this:

On Server2, the server you see this:

Which is indeed the constraint set up as we can verify with:

Get-SmbMultichannelConstraint

We’re done playing so let’s clean up all the constraints:

Get-SmbMultichannelConstraint | Remove-SmbMultichannelConstraint

Seeing this technology it’s now up to the storage industry to provide the needed  capacity and IOPS I a lot more affordable way. Storage Spaces have knocked on your door, that was the wake up call . In an environment where we throw lots of data around we just love SMB 3.0

Design Considerations For Converged Networking On A Budget With Switch Independent Teaming In Windows Server 2012 Hyper-V

Last Friday I was working on some Windows Server 2012 Hyper-V networking designs and investigating the benefits & drawbacks of each. Some other fellow MVPs were also working on designs in that area and some interesting questions & answers came up (thank you Hans Vredevoort for starting the discussion!)

You might have read that for low cost, high value 10Gbps networks solutions I find the switch independent scenarios very interesting as they keep complexity and costs low while optimizing value & flexibility in many scenarios. Talk about great ROI!

So now let’s apply this scenario to one of my (current) favorite converged networking designs for Windows Server 2012 Hyper-V. Two dual NIC LBFO teams. One to be used for virtual machine traffic and one for other network traffic such as Cluster/CSV/Management/Backup traffic, you could even add storage traffic to that. But for this particular argument that was provided by Fiber Channel HBAs. Also with teaming we forego RDMA/SR-IOV.

For the VM traffic the decision is rather easy. We go for Switch Independent with Hyper-V Port mode. Look at Windows Server 2012 NIC Teaming (LBFO) Deployment and Management to read why. The exceptions mentioned there do not come into play here and we are getting great virtual machine density this way. With lesser density 2-4 teamed 1Gbps ports will also do.

But what about the team we use for the other network traffic. Do we use Address hash or Hyper-V port mode. Or better put, do we use native teaming with tNICs as shown below where we can use DCB or Windows QoS?

Well one drawback here with Address Hash is that only one member will be used for incoming traffic with a switch independent setup. Qos with DCB and policies isn’t that easy for a system admin and the hardware is more expensive.

So could we use a virtual switch here as well with QoS defined on the Hyper-V switch?

Well as it turns out in this scenario we might be better off using a Hyper-V Switch with Hyper-V Port mode on this Switch independent team as well. This reaps some real nice benefits compared to using a native NIC team with address hash mode:

• You have a nice load distribution of the different vNIC’s send/receive traffic over a single member of the NIC team per VM. This way we don’t get into a scenario where we only use one NIC of the team for incoming traffic. The result is a better balance between incoming and outgoing traffic as long an none of those exceeds the capability of one of the team members.
• Easy to define QoS via the Hyper-V Switch even when you don’t have network gear that supports QoS via DCB etc.
• Simplicity of switch configuration (complexity can be an enemy of high availability & your budget).
• Compared to a single Team of dual 10Gbps ports you can get a lot higher number of VM density even they have rather intensive network traffic and the non VM traffic gets a lots of bandwidth as well.
• Works with the cheaper line of 10Gbps switches
• Great TCO & ROI

With a dual 10Gbps team you’re ready to roll. All software defined. Making the switches just easy to use providers of connectivity. For smaller environments this is all that’s needed. More complex configurations in the larger networks might be needed high up the stack but for the Hyper-V / cloud admin things can stay very easy and under their control. The network guys need only deal with their realm of responsibility and not deal with the demands for virtualization administration directly.

I’m not saying DCB, LACP, Switch Dependent is bad, far from. But the cost and complexity scares some people while they might not even need. With the concept above they could benefit tremendously from moving to 10Gbps in a really cheap and easy fashion. That’s hard (and silly) to ignore. Don’t over engineer it, don’t IBM it and don’t go for a server rack phD in complex configurations. Don’t think you need to use DCB, SR-IOV, etc. in every environment just because you can or because you want to look awesome. Unless you have a real need for the benefits those offer you can get simplicity, performance, redundancy and QoS in a very cost effective way. What’s not to like. If you worry about LACP etc. consider this, Switch independent mode allows for nearly no service down time firmware upgrades compared to stacking. It’s been working very well for us and avoids the expense & complexity of vPC, VLT and the likes of that. Life is good.

My Impressions on Windows Server 2012 Hyper-V Cookbook

Having read Windows Server 2012 Hyper-V Cookbook I can safely say that if you need get up to speed with Hyper-V in Windows Server 2012 this is a great book for this purpose.

Having met Leandro Carvalho that’s not a surprise. What is pretty impressive is how he managed to get all you need to know to get going inside of one book that you can still lift with one hand. Now this is not going to make you a veteran Hyper-V enterprise architect over the weekend but it will help you get a well set up and functional Hyper-V environment running, monitored and protected. If you are already familiar with Hyper-V form previous Windows versions this book will also get you up to speed on a lot of the most important new features and improvements.

Now a mere 305 pages are not enough to go into depth on every subject but this book will make a fine learning tool to set up a lab and take your first Windows Server 2012 Hyper-V servers / clusters into production. It also tackles some of the more intimidating stuff to some people like in place upgrades of Hyper-V clusters and disaster recovery. Details like CSV cache, Port ACL and their significance in the new Hyper-V version are not forgotten. I like that attention to detail. Knowing the vastness of what’s new in Windows Server 2012 Hyper-V I’m impressed at how well organized and effective the information is presented. So if you need to get started with Hyper-V, do it here with this book. It will make for a fine foundation to build on and move on to investigate the numerous network configurations, the VHDX format, SMB 3.0 goodness etc.

Exploring Hyper-V Virtual Switch Port Mirroring

Windows Server 2012 brings us many new capabilities and one of those is port mirroring. You can now configure a virtual machine NIC (vNIC) who’s traffic you want to monitor as the source in the Advanced Features of the Network Adapter settings. The vNIC of the virtual machine where you’ll run a network sniffer, like Network Monitor or WireShark, against is set to “Destination”. It’s pretty much that simple to set up. Easy enough.

On the vNIC you want to monitor the traffic to and from the VM, under Settings, Network Adapter (choose the correct one), under Advanced Features you select “Source” as Mirroring mode. In this example we’re going to monitor data traffic to and from the guest Columbia.

On the destination VM we have a dedicated vNIC set up called “Sniffie”

On the guest VM Pegasus, where we’ll capture the network traffic via a dedicated vNIC (“Sniffie”), we set that vNIC (virtual port) to “Destination” as Mirroring node:

So now let’s start pinging a host (ping –t crusader)  on our Source VM  Columbia

And take a look on the Destination vNIC on virtual machine Pegasus where we’re capturing the traffic. The “Sniffie” NIC there is set to destination as Mirror Mode. Look at the ICMP echo reply from form 192.168.2.32 (Crusader host). Columbia is at 192.168.2.122 sending out the ICMP echo request.

Pretty cool!

Some Technicalities

So deep down under the hood, it’s the switch extension capabilities  of the Hyper-V virtual switch that are being leveraged to achieve port sniffing. This is just one of the many functionalities that the Hyper-V extensible switch enables. The Hyper-V extensible switch itself uses port ACLs to set a rule that forwards traffic from one  virtual port to another virtual port. For practical reasons translate virtual port to vNIC in a VM and this translates into what we shown above. While it’s good to know that port ACLs are what is used by the extensible switch to do enable all kinds of advances features like port mirroring but you don’t need to worry about the details to use it.

Things to note

Initially many of us made the assumption that we’d be able to sniff the traffic form a virtual port to a port on their physical switch. This is not the case. Basically, in box, it’s a source VM that mirrors it’s network traffic form one or more virtual ports (vNICs) to a destination VM’s one or more virtual ports (vNIC).

You can send many sources to one destination. That’s fine. You could also define more destinations on the same host but that’s not really wise and practical as far as I can see. All in all, you set it up on  when needed on the source VM and you keep a destination VM with a sniffer around for the sniffing.

Also keep in mind that all this works within the boundaries of the same host. Which means that if you want to monitor a VMs network traffic when it moves across nodes in a cluster you’ll have to have "destination” virtual machine on each host. This means that when a source VM is live migrated it will mirror the traffic to that local destination VM. That works.

You could try and live migrate source & destination VMs to the same host but this is not feasible in real life. For one the capture doesn’t survive after a life migration as your sniffer loses connectivity to virtual Port / vNIC.

Don’t be too disappointed about this. Port mirroring is not meant to be a permanent situation that you need to keep highly available anyway, bar some special environments/needs.

Whilst is it true that out of the box you can’t do stuff like sending the mirrored traffic form a guests vNIC/virtual port to a physical switch port where you attach your network sniffer laptop or so. If you throw on the CISCO Nexus 1000V it replaces the Microsoft in box “Forwarding Extensions” and than it’s up to CISCO’s implementation to determine what you can or can’t do. As this stuff is right up their sleeve they allow the Cisco Nexus 1000V mirrors traffic sent between virtual machines by sending ERSPAN to an external Cisco Catalyst switch. I have not had the pleasure of playing working with this.

Anyway, I hope this help to explain things a little. Happy sniffing and don’t get yourself into trouble, follow the rules.

Remote File Browsing Issue In Windows Server 2012 Hyper-V Leaves Results Pane Empty Workaround

In Windows Server 2012 the Remote File Browsing functionality for Hyper-V acts ups on some nodes indicating a problem.

You can read what “Remote File Browsing” is on TechNet here. You use it to browse the file system on a remote Hyper-V server when creating a  new VM there for example.

Remote File Browsing is a shell namespace extension implemented by Hyper-V, it provides a way to browse the folders/files on remove Hyper-V server without requiring server to open extra shell over the network.

The path "::{0907616E-F5E6-48D8-9D61-A91C3D28106D}\HYPER-V-TEST" is to tell shell (explorer or common file dialog) that it is hosting/pointing to the RemoteFileBrowsing shell namespace extension on the HYPER-V-TEST. The guid is Hyper-V remotefilebrowsing shell namespace extension GUID. However, due to the limitation on common file browser, it is not able to translated into "Hyper-V Remote File Browsing".

Now in Windows Server 2012 we sometimes see the following when we use it:

It seems to work but the result pane remains empty. The cluster is healthy, the nodes are healthy, all nodes are identically configured. Some nodes have it, other don’t. We also can’t find any errors logged anywhere.

If you try to work around it using the UNC path that will fail due to security issues later so don’t even go there

Basically we were a bit baffled (we could not reproduce it in the lab either) until we saw some posts on then forums, indicating we’re not the only one seeing this.

http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/608d0c3b-0a7b-4ad9-9843-5e5051dcd526

http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/7a34f5e1-76bc-493a-8a7a-e9f420bf6a79#d7dd4db7-d7bd-419d-aa72-b12e43cd7a5d

If you know your cluster is perfectly healthy forget all the security settings stuff and go straight to testing this “fix” or rather workaround: Toggle Audit Object Access on and off.

In our case I can confirm that these nodes had been under a group policy that audited registry entries during a period that we were trouble shooting network card settings change behavior. We had removed that policy by first reverting the settings to not configured and after some days by removing the GPO. But that didn’t work. Even with no audit policy configured we had to go to all nodes showing this behavior, opening the local Group Policy, toggling our Audit Object Access on for success,applying this and reverting this to No auditing again.

So fire up an MMC, add a snap-in

Select Group Policy Object

Accept the defaults

When don navigate to Computer Configuration -> Windows Settings -> Security Settings -> Local Policy -> Audit Policy -> Audit Object Access

Now try to use Remote Browser again (close & reopen all wizard windows and start over a new) to see the results:

Success! All is well again.

Notes:

• We only see this on systems remotely connecting to Windows Server 2012 Hyper-V nodes that are running Windows Server 2012 or Windows 8 themselves not on Windows 2008 R2 or Windows 7 with the RSAT for W2K12 installed.
• This is not related to Windows core alone due to missing GUI components or something.