I was having trouble renaming my single Ethernet adapter because I had added and removed the NIC a few times during VM testing. The name of the NIC in Network and Sharing Center was “Ethernet 2” and I wanted it to be named “Ethernet”. I like things neat.
When I tried to rename the adapter I got an error stating that there was already an adapter with that name. I knew I only had one virtual NIC attached to this VM so I knew it had to be a leftover somewhere.
I tried to use PowerShell to rename the adapter but had no luck – it also indicated that “Ethernet” was already in use.
I did a search on the registry for “Ethernet” and after some digging found what I was looking for:
A while back I encountered this error when trying to Live Migrate a VM from my Hyper-V 2012 Cluster to the new Hyper-V 2012 R2 Cluster.
You might be asking why I was running Hyper-V 2012 in the first place…
I just happened to start upgrading our Hyper-V 2008 R2 Cluster after Windows Server 2012 was released, and then Windows Server 2012 R2 was released with some very much improved features. So I had a few VMs on the 2012 Cluster that needed to be moved to 2012 R2. It was a great time-saver to be able to Live Migrate from 2012 –> 2012 R2 (well, if I could get it working).
The error message when trying to LM a VM:
"The virtual machine cannot be moved to the destination computer. The hardware on the destination computer is not compatible with the hardware requirements of this virtual machine. Virtual machine migration failed at migration source."
I found this one fairly easily but it took a little bit of time.
When comparing my 2012 node to my 2012 R2 node I noticed that the Virtual Switches were named differently. Apparently for Live Migration this will cause an issue, at least in 2012 –> 2012 R2.
After renaming the Virtual Switches to match, the Live Migration completed successfully:
I found a thread on TechNet about the issue and the OP (original poster) replied saying that it was a bug all along and it had been patched.
Well as I wrote on the TechNet thread, I am still having this issue on a fully patched 2012 R2 Standard server. I was able to work around it by using the local Administrator account to assign permissions, rather than using an account in “Domain Admins”.
This bug does not seem effect permissions when using the folders, as I am able to create/modify/etc.; it is only an issue when setting the permissions on the folder.
Here was my folder when logged on as user1, a member of Domain Admins:
As you can see, Domain Admins have “Full control” of this folder and should be able to set any permissions needed. But I kept getting the error in the screenshot at the beginning of this post.
After reading the thread I found on TechNet, I logged on as the local Administrator, went to the folder in question, and added the group I wanted to have access. I then made those permissions propagate to all subfolders and it went quickly and without error. So it works as local Administrator but not as a Domain Admin.
From what I can tell the issue is that Windows Server 2012 R2 cannot recognize that user1 has “Full control” of the folder because user1 is not listed explicitly in the ACL. Even though user1 is a member of “Domain Admins” who are in the ACL, it does not matter.
This seems like a bug to me, but at least there is a fairly easy workaround.
If you closed the window you can always access it via command line by typing:
Helpful tip for Core mode: If you closed the command prompt and have nothing on the screen, press CTRL + ALT + END
Even after enabling Remote Management, I was not able to connect to my server via RDP. I enabled ping in the sconfig Network Settings to ensure that I could see the server from my desktop, and while ping was successful I still could not open a RDP session to manage my Core installation.
I figured it was the firewall, so I disabled it completely:
netsh advfirewall set currentprofile state off
After turning the firewall off in its current profile I was able to successfully remote in to my Hyper-V Server 2012 R2 installation and finish up my settings.
Since this is a home lab setup, I am fine with the firewall being off. In a domain environment, you might turn the firewall off as well (depending on your security protocols).
At first I did not want to disable the firewall completely so I went down the path of figuring out why I could not RDP to my server. This turned out to be somewhat of a challenge.
I started by checking out the Remote Desktop rules. This command will return the name of the Remote Desktop rule and whether it is enabled:
If we had run this command prior to using sconfig to enable Remote Desktop, we would only see the first three rules. The second three rules are added and enabled when we use sconfig to enable Remote Desktop. The first three rules are not enabled, but the GUID rules are enabled. Why did sconfig create three new rules to enable Remote Desktop?
You can see here that the GUID rule (the first in the image, after I renamed it from the GUID to match the DisplayName) matches the second rule shown: “RemoteDesktop-UserMode-In-TCP” (no spaces), except for the Profile attribute, which for the GUID rule (top) is Domain, Private and for the built-in rule (bottom) is Public.
Remote Desktop rules are all now enabled and I was able to successfully RDP to my server!
These steps would be the same for the full version of Windows Server 2012 R2 Core Edition Standard or Datacenter.
I ended up figuring all of this out after a re-install of Hyper-V Server 2012 R2. What happened was that sconfig added the firewall rules for RDP (the GUID rules), but it added them for the Domain and Private firewall profiles. My server was set on the Public profile. Therefore, the rules that were added via sconfig were not applicable. Why does this happen out of the box? I suppose that is a question for Microsoft.
In the end I simply added the Domain and Private Profiles to the built-in rules, then enabled the group as above. I did NOT enable Remote Desktop with sconfig because I did not want it to add those three “extra” GUID rules. I suppose if you were going to have multiple connections using different firewall profiles then you would want separate rules, but this is for a lab setup and I like to make things less confusing!
In order to add the Domain and Private profiles to the built-in firewall rules, I used the following command. I included the Public profile just to be complete, even though it is already part of that rule: