John Howard - Senior Program Manager in the Hyper-V team at Microsoft : Desktop Operating Systems

Hyper-V: Why does Hyper-V Manager not always work over VPN connection? Access Denied or RPC server unavailable errors.

jhoward — Fri, 08 Aug 2008 07:55:51 GMT

This post examines a problem several people have reported when running Hyper-V Remote Management tools over a VPN connection - specifically hitting an error “Access denied. Unable to establish communication between ‘SERVER’ and ‘CLIENT’”. In some variations, I’ve seen RPC errors such as “RPC server unavailable. Unable to establish communication between ‘SERVER’ and ‘CLIENT’.”

And an example of an RPC error case:

To be explicit up front, I am talking about this only occurring over a VPN/RAS connection – when connected using a wired or wireless connection without VPN, everything works normally. If things are not working on wired/wireless, follow my series of remote management posts to configure everything first.

Diagnosing the issue took a bit of sleuthing. So let’s dive in. A big clue is in the first message – it implies there is some form of communication between the Hyper-V enabled server and the Remote Management client. Indeed, that is correct – there is a DCOM callback. So let’s start by looking at the IP configuration on the laptop machine I’m using for this walkthrough after the VPN connection has been established.

Note that the DHCP assigned address for the VPN connection is 192.168.200.6, and the DHCP assigned address for the Internet connection is 192.168.1.119.

Let’s run a network trace network trace on the Hyper-V enabled server to see what’s going on. I’m running the network trace while starting Hyper-V Manager on the laptop:

The two highlighted lines show that the Hyper-V enabled server is making an attempt to connect to my local wireless IP address on my broadband connection, 192.168.1.119, rather than the DHCP assigned IP address for my machine on the internal network, 192.168.200.6.

What’s also interesting in the trace are ARP packets from the Hyper-V enabled server at 192.168.200.218 to “HPCRAPTOP”:

Notice that the server is asking where 192.168.200.14 is, and netmon is resolving 192.168.200.14 to the IP address of the laptop. So that indicates all is not well with DNS since we know above that the DHCP assigned address on the VPN connection is 192.168.200.6. Let’s do an nslookup to examine the DNS entry for the laptop.

Indeed, the laptop from a DNS perspective is incorrect and explains why netmon is resolving 192.168.200.14 to my laptop. (Although I didn’t mention it, I happen to know that this DNS entry, 192.168.200.14, was the IP address assigned to the laptop when it was last connected directly to the internal network.)

So as an experiment and first workaround, let’s edit \windows\system32\drivers\etc on the Hyper-V enabled server to add an entry for my laptop as 192.168.200.6, the current IPv4 address for VPN and see what happens.

Yes, that works. But it’s hardly what I could describe as a desirable or every-day-workable solution. If you’re walking through with me, remember to remove that entry hosts to see if there are any other workarounds.

Well there is one interesting workaround which I mentioned in my remote management configuration series. However, I absolutely do NOT recommend this one unless you really need to as you are lowering the security of your machine. Changing this setting is NOT necessary for remote management in a domain environment, but it is in a workgroup environment (my home environment I’m using for this is domain based). Here are the settings to change in dcomcnfg on the management client:

Why this works is related to WMI/DCOM fallback, but I’m far from claiming to be an expert here and will walk swiftly away from any further explanation. However, I re-iterate, I absolutely do not recommend you change this setting unless you need to.
So let’s step back a bit now and try and understand a bit more about the DNS issue. The obvious thing to think may be to run “ipconfig /registerdns” from an elevated command prompt on the remote management machine to correct the DNS registration. Let’s see what happens, while at the same time running a network trace on the ISA server with a filter for just the DNS protocol.

If you’re ahead of the game, you may notice this is a very interesting capture! Maybe not if you’re aware of my home setup, so let me explain why. 192.168.15.2 is the external internet address of my ISA server (in turn connected to a VOIP router). The destination being resolved to a host with name starting ‘ns’ is my ISP’s DNS server. Looking at the frame details, you can see the packet is a DNS update request for the laptop. Unsurprisingly, if you look at the response from the ISP in packet 3949, the response is “NotAuth”. Afterall, they’re not authoritative for DNS of my domain. I am!

This routing to the external network through ISA is normal expected behaviour. So I’m still yet to find a good solution. But all is not lost (of course). Let’s take a different tactic and look a little closer at the Vista SP1 inbox VPN client configuration (as in one which hasn’t been created by what-ever the equivalent of CMAK, or Connection Manager Administration Kit, for Vista – and no, I’ve no idea what the replacement technology is. But it does remind me to do some research for another day....).

I’m assuming you’re already familiar with configuring a PPTP or L2TP VPN connection in Vista – that’s a little outside of the scope of this post. But here’s the IPv4/Properties/Advanced/DNS dialog tab of the VPN connection I’ve created to connect back to my home network. Look at the bottom three items relating to DNS registration:

Hmmmm. These look extremely promising . Logically, it sounds like I want all three: I want to specify a DNS suffix for this connection which is that of my internal domain; Yes, I want to register the connection’s address in DNS; and I’d like to use the DNS suffix in the DNS registration. So I changed it to look like this:

After saving the changes, let’s run that DNS-filtered network trace on the ISA server again while re-establishing the VPN connection:

Looks good as a DNS update was sent to the internal DNS servers, not to the external ISP. It shows the update for the IPv4 address of the remote management client as 192.168.200.4 with a success response in the following packet. And ipconfig on the client?

This confirms the trace above – the remote management client has IP address 192.168.200.4. What about an nslookup of the laptop?

Excellent. Everything is looking rosey – the DHCP assigned IP address of the laptop acquired from the VPN connection is in DNS on the internal servers. Therefore, the Hyper-V enabled server should be able to locate the laptop when making it’s DCOM callback, so let’s fire up Hyper-V manager and see what happens:

Voila! Hope you found that useful.

Cheers,
John.

Part 5. Domain client to Workgroup Server: Hyper-V Remote Management: You do not have the required permission to complete this task. Contact the administrator of the authorization policy for the computer ‘COMPUTERNAME’

jhoward — Sat, 05 Apr 2008 05:26:00 GMT

Update 14th Nov 2008. I've just released a script which does all this configuration in one or two command lines: HVRemote

So far, I’ve covered the following Hyper-V Remote Management scenarios:

Workgroup: Vista client to remote server, server configuration, full install (Part one)
Workgroup: Vista client to remote server, client configuration (Part two)
Workgroup: Vista client to remote server, server configuration, core install (Part three)
Domain: Vista client to remote server (Part four)

But the questions keep coming. Part number five covers the case of a domain joined Vista client connecting to a remote server in a workgroup.

And the reason for all these posts? To configure both machines to overcome the error: “Hyper-V Remote Management: You do not have the requested permission to complete this task. Contact the administrator of the authorization policy for the computer ‘COMPUTERNAME’” message when you start Hyper-V Manager remotely.

IMPORTANT: Before anything else, I am going to assume you already have DNS setup correctly. If you can’t resolve the remote server machine using nslookup on the Vista machine, fix that now. Nothing will work unless that is right.

One shortcut I do take in the walkthrough is to make the server with the Hyper-V role enabled a full install. See part three for how that affects you if your server is a core installation. I’m not going to provide great detail about exactly what to click in each step – it’s all been covered in the previous posts, so please refer back.

Let’s make this walkthrough a little more interesting, by making it more representative of a real-world deployment by locking down the access permissions to a specific user/group (rather than 'administrator'). I’m going to have a domain user, “domain1\john” with password “johnhoward” connecting to a workgroup remote server with the Hyper-V role enabled where a local user “john” with password “john” exists. (And no, these are no reflection on my real passwords. It’s purely for demonstration only and to show you that password matching isn’t needed to make this work).

Step 1. Create the user accounts (Domain Controller & Hyper-V enabled Server)

On my domain controller, I’ve created an account "domain1\john" using Active Directory Users and Computers. Note that I am not making this account an administrator anywhere. Just a regular Joe User.

On the Hyper-V enabled server, I’ve created the account workgroup\john using the net user command. I’ve also created a group called “Remote Hyper-V Admins”, and added the local workgroup “john” account to that group.

Step 2. Enable Firewall WMI Rules (on Hyper-V enabled server)

Run the following command as an administrative user on the server: 'netsh advfirewall firewall set rule group=”Windows Management Instrumentation (WMI)” new enable=yes'

Step 3. Allow authenticated remote DCOM access (on Hyper-V enabled server)

Here I’ve added the “john” account to the “Distributed COM Users” group. Unfortunately, in a workgroup environment, you can’t nest groups, but the “Remote Hyper-V Admins” group will come in useful later.

Step 4. Allow authenticate users to remote WMI namespaces (on server)

See step 4 in part one for more information. Here is where I’m using the “Remote Hyper-V Admins” group I created previously. As before, make sure you do this TWICE, once for Root/CIMv2 and again for Root/Virtualization.

Step 5. Configure AZMan (on server)

Here I’ve granted “Remote Hyper-V Admins” authorization rights to be Hyper-V administrators. See step 5 in part one for full details.

REBOOT SERVER.

Step 6. Create a firewall exception for MMC (on client)

To save repeating myself, this is identical to Part two, step 6.

Step 7. Allow anonymous callbacks (on client)

To save repeating myself, this is identical to Part two, step 7.

Step 8. Set credentials for the remote server (on client)

This is the gem of information you need. I’m logging onto the client machine as “john”, a standard domain user. The client has LUA enabled, as it should. From a non-elevated command prompt (that’s important), use cmdkey to store credentials for accessing the remote machine using the following syntax: “cmdkey /add remoteserver /user:remoteserver\username /pass”

Of utmost importance, is the option passed to the /user parameter: - you must specify it as remoteserver\username, not just username. So in my walkthrough, I entered “cmdkey /add jhoward-hp2 /user:jhoward-hp2\john /pass” as the remote machine is called jhoward-hp2.

Step 9. Run Hyper-V Manager (on client)

Start Hyper-V Manager from Control Panel/Administrative Tools (or \program files\Hyper-V\virtmgmt.msc). If you are using a pre-release version of Hyper-V and have not previously accepted the EULA, accept it now.

You will notice that once you create a virtual machine and open Virtual Machine Connection, you will be prompted for credentials. At this point, use the credentials on the remote machine (john, password john in my example).

And “Voila”

So I’m very nearly there. I just need to write up the scenario of the Client being in a workgroup and the Server being domain joined. Part six to follow soon….

Cheers,
John.

Update 14th Nov 2008. I've just released a script which does all this configuration in one or two command lines: HVRemote

Part 4. Domain joined environment: Hyper-V Remote Management: You do not have the required permission to complete this task. Contact the administrator of the authorization policy for the computer ‘COMPUTERNAME’

jhoward — Wed, 02 Apr 2008 02:59:00 GMT

Update 14th Nov 2008. I've just released a script which does all this configuration in one or two command lines: HVRemote

Quick links to the all parts in the series: 1, 2, 3, 4 and 5

So after even more feedback and questions, part 4 of this series provides the walkthrough steps necessary to perform Hyper-V remote administration in a domain joined environment.

For reference:

Part one is the server configuration for a full server installation in a workgroup environment
Part two is the client configuration for parts one and three
Part three is the server configuration for a server core installation in a workgroup environment
Part four, this post, contains the relevant bits from parts two and three as applicable to deploying remote management of Hyper-V in a domain environment
Setting up and the pre-requisites for Hyper-V on server core are in this post.
More information on server core commands is here

Follow the same steps for setting up the server core box itself as before, but remember to join the machine to the domain by using netdom join <computername> /domain:<domainname> /userd:<domain user> /passwordd:*. Don't forget to enable remote administration.

Let’s first logon as domain administrator on the Vista machine and connect to the remote machine using Hyper-V Manager. As you can see, that works fine.

Obviously running as domain administrator isn’t a practical option in anything but a contrived lab environment. So I’ve created a standard user account in the domain called “domainuser” who is not an administrator either in the domain, the server core box with the Hyper-V role enabled, or on the Vista machine. Let’s see what happens when I start Hyper-V Manager on the Vista machine targeting the remote server core box. As you can in the screenshot below, it indicates that I am unauthorized. This is expected at this stage.

Step 1 Authorization Manager configuration

I need to authorize the domain user account for operations on the Hyper-V server, the same as I did in the workgroup environment. This is easier if I use an administrative account on the remote server core machine. For simplicity, I’m going to log back on to the Vista machine as domain administrator and run configure the Hyper-V authorization policy. (Note in the real world, you don't need domain administrator - this is for simplicity in the walkthrough only).

Logon to the Vista machine as Domain Admin and click start/run AZMan.msc.

Now open InitialStore.xml from the %systemdrive%\programdata\microsoft\windows\Hyper-V directory on the remote server machine. Right click on Open Authorization Manager and select Open Authorization Store…

Select XML and enter the path to InitialStore.xml (or browse to it, noting that the programdata directory is hidden).

Expand the tree through Hyper-V services\Role Assignments\Administrator and select “Administrator”. Note that I’m making this walkthrough as simple as possible by making the domain user an administrator in the context of being able to perform all operations on the machine running the Hyper-V role. This does not however mean that the domain user becomes, or needs to be a local administrator on the Hyper-V machine (or on the Vista machine).

In the right-hand side of the window, right click and select Assign Users and Groups then From Windows and Active Directory….

Select the domain user account and click OK.

You can now close Authorization Manager

Step 2 DCOM Configuration

Again, this is similar to the configuration steps necessary in the workgroup environment. You need to grant the appropriate users access rights to remote DCOM on the server. Use the same steps as in the workgroup configuration and add those users to the Distributed COM Users group.

On the Vista machine logged on with an account with administrative rights on the server core machine, click start/control panel/administrative tools/computer management.

Remember in the server core configuration steps, I allowed remote management to enable this to work. If you get an error - go back to the server core configuration steps (links at top of this post). Right Click on the top of the tree on the “Computer Management (Local Computer)” node and click Connect to another computer…

Enter the name of the remote server (jhoward-hp2 in my walkthrough)

Expand the tree down through Computer Management/System Tools/Local Users and Groups/Groups and select Distributed COM Users on the right hand side.

Double click on "Distributed COM Users", click Add… and select the appropriate users (domainuser in my walkthrough), and click OK.

Step 3. Remote WMI

This step is the same as the configuration steps necessary in the workgroup environment. You need to allow the domain user account access to the Root\CIMV2 and Root\virtualization namespaces. While Computer Management is still open from Step 2, expand out Services and Applications and select WMI Control.

Right click on WMI Control and select properties. Then switch to the "Security" tab. Expand the tree and select the "Root\CIMV2" namespace node.

IMPORTANT: You need to set the security twice. Once for the Root\CIMV2 namespace, and then again for the Root\virtualization namespace.

Click the "Security" button. If the appropriate user or group does not already appear, use “Add…” as you did in Step 2 above to add them.

Now select the user and click the Advanced button below the “Permissions for <user>” area.

Again, make sure the user/group is selected and click Edit.

You need to make three changes here:

In the “Apply to:” drop-down, select “This namespace and subnamespaces”
In the Allow column, select Remote Enable
Check “Apply these permissions to objects and/or containers within this container only”

The screen should look like below. If so, click OK through the open dialogs.

Repeat for the Root\virtualization namespace

Click OK as appropriate to confirm all open dialogs and close Computer Management.

After completing this step, reboot your server for the changes you made in step 2 to take effect.

Step 4. Test it out

I logged back onto the Vista machine using the test domain user account. I started Hyper-V Manager and targeted jhoward-hp2, the remote server core machine. I then created a new virtual machine with all default settings, except selecting to add a virtual hard disk later. I started the virtual machine and connected to it. And as you can see in the screenshot below, the virtual machine is up and running (the boot failure message is expected as there’s no bootable media in the virtual machine).

Cool!

Cheers,
John.

Update 14th Nov 2008. I've just released a script which does all this configuration in one or two command lines: HVRemote

Part 3 - Hyper-V Remote Management: You do not have the required permission to complete this task. Contact the administrator of the authorization policy for the computer ‘COMPUTERNAME’

jhoward — Mon, 31 Mar 2008 03:56:00 GMT

Update 14th Nov 2008. I've just released a script which does all this configuration in one or two command lines: HVRemote

Quick links to the all parts in the series: 1, 2, 3, 4 and 5

Although I thought I’d finished at part two, after even more emails and comments on part one and two, it quickly became obvious to me that I need to round off the series by answering “But what if my server is a server core installation”. In server core, you have none of the “niceties” of most of the user interface.

This blog post is an alternate to part one, covering the case where the server is server core. Before going any further, make sure you have followed the steps in my previous post to enable the Hyper-V role on server core and enable remote management. Remote management is important for this walkthrough - you'll need it to complete the steps.

Step 10 (On Client and Server)

This mirrors step 1 in part one. Make sure you are using a username and password which matches between the client and the server. For this walkthrough, I created an account with the username “john” with the same password on both machines. The “john” account is not an administrator on the server machine, but is an administrator on the client machine (for convenience). Enter the following command.

net user john * /add

Step 11 (On Server)

This step mirrors step 2 in part one. Enable the firewall rules on the server for WMI (Windows Management Instrumentation). Enter the following command:

netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes

Make sure the command it successful and responds with Updated 4 rules(s). Ok.

Note: What you enter in quotes is just a name must match the group name defined in the Windows firewall itself. So if you are running a non-English language server, you will need to verify what group name this is.

Step 12 (On Server)

This step mirrors step 3 in part one. It grants appropriate DCOM (Distributed COM) permissions to the user(s) who are remotely connecting. In a full install of Windows Server 2008, this is (relatively) easy using dcomcnfg. Unfortunately, this is not available on server core. However, there is a built-in user group you can use which does the job just as well (in fact, although I haven’t tested it, this should work equally well on a full installation of Windows Server 2008).

You need to add the user account(s) or groups to the “Distributed COM Users” group. In my example, the server is named jhoward-hp2 and the local user account is john.

net localgroup “Distributed COM Users” /add jhoward-hp2\john

Step 12B (On the remote management console/client)

[Edited 16th May 2008. This was step 15, but moved to before step 13]
Follow steps 5, 6 and 7 in part two. These are identical and must be done on the client machine.

Step 13 (On Remote Management Machine)

This step mirrors 4 in part one and grants appropriate WMI permissions to the user(s) who are remotely connecting. You need grant access to two namespaces, and, as in step 3, you can add individual users, group(s) or the “Authenticated Users” group.

This is a little more challenging on server core as there is no computer management MMC. However, as I’ve already enabled remote management, I can do this from my remote management (Vista SP1) workstation. On that machine, I’m logged on with administrator credentials matching an account on the server machine.

Open Computer Management under Start/Administrative Tools. Right-click on the top most node, “Computer Management (Local Computer)”, and click “Connect to another computer …”

In the select computer dialog, enter the name of the remote server core machine and click OK. In my case, this is jhoward-hp2 (jhoward-hpu was the full installation). Then expand the tree down through Services and Applications\WMI Control and select WMI Control

Right-click on WMI Control and select properties. Then switch to the Security tab. Select the Root\CIMV2 namespace node.

IMPORTANT: You need to set the security twice. Once for the Root\CIMV2 namespace, and then again for the Root\virtualization namespace.

Click the Security button. If the appropriate user or group does not already appear, use “Add…” to add them. Note that when doing this remotely, you will be prompted for credentials. Make sure you entere the username as server\username as the default domain will be that of the client management machine

Now select the user and click the Advanced button below the “Permissions for <user>” area.

Make sure the user/group is selected and click Edit

You need to make three changes here.

In the “Apply to:” drop-down, select “This namespace and subnamespaces”
In the Allow column, select Remote Enable
Check “Apply these permissions to objects and/or containers within this container only”

The screen should look like this. If so, click OK through the open dialogs.

Repeat for the Root\virtualization namespace

Click OK as appropriate to confirm all open dialogs and close Computer Management.

Step 14 (On Remote Management Machine)

This step mirrors step 5 in part one and configures the Authorization Manager (AZMan) policy for the server running the Hyper-V role. I am assuming in this walkthrough, you are using the in-box default policy and have not re-configured anything at this stage.

To make life a little easier, I’m first going to map a network drive on the remote management machine to the system drive on the machine running server core. In my case, the system drive is G. At an elevated command prompt on the client, type the following (replacing G and jhoward-hp2 as appropriate)

net use * \\jhoward-hp2\g$

Open Authorization Manager by typing “azman.msc” in the box on the start menu.

Right-click on the Authorization Manager and choose Open Authorization Store from the context menu.

Make sure the “XML file” radio button is selected, and browse to the \ProgramData\Microsoft\Windows\Hyper-V directory on the mapped drive, select InitialStore.xml, then click OK.

I’m going to keep this walkthrough as simple (!) as possible, and making my “john” account an Administrator in the context of Hyper-V authorization policy. Expand the tree down through InitialStore.xml\Hyper-V services\Role Assignments\Administrator, and select Administrator.

In the area on the right, right-click and select “Assign Users and Groups” then “From Windows and Active Directory…”.

Note that you are prompted for appropriate administrative credentials. Make sure you enter the username as server\administrativeaccount again, to ensure the domain name is that of the server.

At this point, I would say to add the appropriate users or groups like I did in the full installation option. However, I hit a snag. For some reason, AZMan running remotely did not seem able to find the “john” account (or any other user account I created on the core installation) even though it was definitely there as you can see using Computer Management on the remote machine targeting the server.

The answer (I thought) was to create a new user group and add the “john” account to that group. However, that also failed. All was not lost. First thing to do was to report a bug. Next, was to come up with a backup plan. Now at this point, I apologise in advance - it's a really horrible workaround, and involves hand-editing InitialStore.xml

Let’s take a look at InitialStore.xml on the full installation I made in part one, particularly the section with “Name=Administrator”. In the first screenshot taken using Internet Explorer to open the XML file, you can see that the “john” account has been added, the second screenshot being without “john” being an administrator.

So it just is a question of finding and adding the appropriate user/group sid as member. How hard can that be? (OK, don't answer that quite yet!) Thanks to the scripting guy, it didn’t take long to get the answer. I created the script below, test.vbs, and ran it on the remote management machine using "cscript test.vbs". (Replace jhoward-hp2 in both places with your server name, and john with the appropriate user name. Also make sure there is no space between 'john', and Domain= in the penultimate line.)

strComputer = "."
Set objWMIService = _
GetObject("winmgmts:\\jhoward-hp2\root\cimv2")
Set objAccount = objWMIService.Get _
("Win32_UserAccount.Name='john',Domain='jhoward-hp2'")
Wscript.Echo objAccount.SID

So now I had the account SID for the "john" account, I could use notepad to edit InitialStore.xml appropriately. I still had my network drive mapped. IMPORTANT: Take a backup copy of InitialStore.xml now!

Unfortunately, notepad is not the most easy to use editor for XML files. There are plenty of freeware XML editor out there, but I stuck with notepad, if for no more reason than to prove that this whole walkthrough can be done using inbox components. Here you can see I’ve added a new member tag on the bottom line – everything from <Member>S-1-5-21-602….. to the following </Member>

Just to make sure I hadn’t made a huge editing error, I used IE again to confirm

And yes, you can now close the Authorization Manager MMC if it is still open on the remote management machine!

Important. You must reboot your server for the above changes to take effect.

Step 15 (On the remote management console/client)
[Edited 16th May 2008. Moved this step to earlier as step 12B. Ignore step 15 if you did it earlier]

~~Follow steps 5, 6 and 7 in part two. These are identical and must be done on the client machine.~~

Step 16 (Away from the keyboard)

This mirrors step 8 in part two. Take a very deep breath and congratulate yourself. Open beer, have a party, whatever takes your fancy. To have got this far, you deserve it. Make sure you have followed all the steps to the letter, especially the bit about restarting the server.

Step 17 (On the client)

Logon as the account you have given permissions to (“john” in my walkthrough) on the client.

Start Hyper-V Manager from Administrative Tools on the Control Panel. Enter appropriate administrative credentials if UAC is enabled and the account is not an administrator on the client.

Click Connect to Server and enter the name of the remote machine, accepting the EULA if this is a pre-release version of Hyper-V.

Watch in even more awe than you did in part 2 as you get a screen like below ;) Here I’m managing jhoward-hpu which is the full installation, and jhoward-hp2 which is the server core installation. Wow! I need some time off!

Cheers,
John.

Update 14th Nov 2008. I've just released a script which does all this configuration in one or two command lines: HVRemote

Part 2 - Hyper-V Remote Management: You do not have the required permission to complete this task. Contact the administrator of the authorization policy for the computer ‘COMPUTERNAME’

jhoward — Sat, 29 Mar 2008 05:47:00 GMT

Update 14th Nov 2008. I've just released a script which does all this configuration in one or two command lines: HVRemote

Quick links to the all parts in the series: 1, 2, 3, 4 and 5

The second part of the extra-long blog post contains the steps necessary on the client machine. Part one concentrated on the server side configuration.

Step 5 (On the client)

Step 5 mirrors step 2 in the first part of this blog post, but on the client. Note also (again for convenience more than anything else), my Vista SP1 machine is actually itself a virtual machine running on the same physical machine as the server. You’ve got to love it when you can have a somewhat recursive technology ;)

Enable the firewall rules on the client for WMI (Windows Management Instrumentation). From an elevated command prompt, enter the following:

netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes

Make sure the command it successful and responds: Updated 8 rules(s). Ok.

If you now open “Windows Firewall with Advanced Security” from Control Panel/Administrative Tools on the start menu, you will notice eight rules, six inbound and two outbound have been enabled. (It helps to sort by Group)

Step 6 (On the client)

This step creates a firewall exception for the Microsoft Management Console application (mmc.exe). From an elevated command prompt, enter the following:

Netsh firewall add allowedprogram program=%windir%\system32\mmc.exe name="Microsoft Management Console"

Make sure the command is successful and responds “Ok.”

You can verify that you succeeded in the above step by looking in the “other” Windows Firewall application. (No, I have no idea why there are two either….). Open "Network and Sharing Center" on the control panel, and click Windows firewall in the bottom left corner, then click "Allow a program through Windows Firewall" where you’ll see a new entry with the name “Microsoft Management Console”

Step 7 (On the client)

IMPORTANT!!!! You need to do this step in the following scenarios:

Client and server are both in a workgroup
Client is a workgroup and server is in a domain
Client is in a domain and server is in a workgroup
Both client and server are in domains, but there is NO TRUST between them.

You DO NOT NEED TO DO THIS STEP if the client and server are in either the same or trusted domains. Go to step 8.

WMI makes calls back from the server to the client. This is entirely expected (and is not Hyper-V specific). When a server is in a workgroup, the DCOM connection from the server back to the client is "anonymous". This step therefore grants the appropriate permission.

On the start menu box (yes, well spotted, I need to apply updates), type dcomcnfg and hit enter to open Component Services. If UAC is enabled, click allow when prompted or enter appropriate administrative credentials.

Expand the tree down through Component Services\Computers\My Computer, select My Computer, right-click, choose properties and select the COM Security tab.

Click Edit Limits in the Access Permissions area (do not confuse with Edit Limits in the Launch and Activation Permissions area). Select “ANONYMOUS LOGON” from the list of users, and make sure Remote Access/Allow is checked in the permissions area. Your screen should look like below.

Click OK and OK again, and close Component Services.

Step 8 (Away from the keyboard)

Take a deep breath and pat yourself on the back. Now do that again. A third time if you like. Then double-check to make sure you followed the above steps and those in part one to the letter. You did remember the step about restarting the server, didn't you?

Step 9 (On the client)

Logon as the account you have granted permissions to (“john” in my walkthrough) on the client.

Start Hyper-V Manager from Administrative Tools on the Control Panel. Enter appropriate administrative credentials if UAC is enabled and the account is not an administrator on the client.

Click Connect to Server and enter the name of the remote machine.

Watch in awe as you get a screen like below. You can also see, it took me 2 hours, 24 minutes and 19 seconds to do this walk-through documenting it step-by-step. It should take you much less time!

Cheers,
John.

Update 14th Nov 2008. I've just released a script which does all this configuration in one or two command lines: HVRemote

Part 1 - Hyper-V Remote Management: You do not have the required permission to complete this task. Contact the administrator of the authorization policy for the computer ‘COMPUTERNAME’

jhoward — Sat, 29 Mar 2008 05:00:00 GMT

Update 14th Nov 2008. I've just released a script which does all this configuration in one or two command lines: HVRemote

Quick links to the all parts in the series: 1, 2, 3, 4 and 5

After the many emails I’ve had about this, it seemed only appropriate to write up a detailed post (or two actually) about how to resolve this.

You will hit this problem when using the Hyper-V Vista management tools connecting to a remote Windows Server 2008 machine with the Hyper-V role enabled, and where both machines are in a workgroup (or in a domain environment where you genuinely don’t have access - but that's another blog entry).

There are several additional configuration steps you need to complete to make remote management work in a workgroup environment.

Step 1 (On Client and Server)

Make sure you are using a username and password which matches between the client and the server. For this walkthrough, I created an account with the username “john” with the same password on both machines. The “john” account is not an administrator on the server machine, but is an administrator on the client machine (for convenience).

Step 2A (On Server core installations)

See part 3 of this series

Step 2B (On Server full installations)

Enable the firewall rules on the server for WMI (Windows Management Instrumentation). From an elevated command prompt, enter the following:

netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=yes

Make sure the command is successful and responds Updated 4 rules(s). Ok.

Note: The string in quotes must match the group name defined in the Windows firewall itself. So if you are running a non-English language server, you will need to verify what group name this is.

If you now open “Windows Firewall with Advanced Security” from Administrative Tools on the start menu, you will notice four rules, three inbound and one outbound have been enabled. (It helps to sort by Group)

Step 3 (On Server)

This step grants appropriate DCOM (Distributed COM) permissions to the user(s) who are remotely connecting. Depending on your circumstances, you can add the individual users (they must obviously have an account already on the server), a group, or you can allow all users by select the “Authenticated Users” group.

Open Component Services by typing “dcomcnfg” in the box on the start menu, and expand the menu so that “My Computer” is selected under Component Services\Computers.

Right-Click on My Computer, select Properties and select the “COM Security” tab.

In the above dialog, click Edit Limits in the “Launch and Activation Permissions” area (not to be confused with the Edit Limits in the “Access Permissions” area).

Click “Add…” and enter the users (or groups including “Authenticated Users” as appropriate)

Click OK, then select the added user or group

In the Allow column, select Remote Launch and Remote Activation, then click OK.

Close Component Services

Step 4 (On Server)

This step grants appropriate WMI permissions to the user(s) who are remotely connecting. You need grant access to two namespaces, and, as in step 3, you can add individual users, group(s) or the “Authenticated Users” group.

Open Computer Management under Start/Administrative Tools, expanding the tree down through Services and Applications\WMI Control. Select WMI Control

Right-click on WMI Control and select properties. Then switch to the Security tab. Select the Root\CIMV2 namespace node.

IMPORTANT: You need to set the security twice. Once for the Root\CIMV2 namespace, and then again for the Root\virtualization namespace.

Click the Security button. If the appropriate user or group does not already appear, use “Add…” as you did in Step 3 above to add them.

Now select the user and click the Advanced button below the “Permissions for <user>” area.

Again, make sure the user/group is selected and click Edit

You need to make three changes here:

In the “Apply to:” drop-down, select “This namespace and subnamespaces”
In the Allow column, select Remote Enable
Check “Apply these permissions to objects and/or containers within this container only”

The screen should look like below. If so, click OK through the open dialogs.

Repeat for the Root\virtualization namespace

Click OK as appropriate to confirm all open dialogs and close Computer Management.

Step 5 (On Server)

This step configures the Authorization Manager (AZMan) policy for the server running the Hyper-V role. I am assuming in this walkthrough, you are using the in-box default policy and have not re-configured anything at this stage.

Open Authorization Manager by typing “azman.msc” in the box on the start menu.

Right-click on the Authorization Manager and choose Open Authorization Store from the context menu.

Make sure the “XML file” radio button is selected, and browse to the \ProgramData\Microsoft\Windows\Hyper-V directory on the system drive and select InitialStore.xml, then click OK.

I’m going to keep this walkthrough as simple (!) as possible, and making my “john” account an Administrator in the context of Hyper-V authorization policy. Expand the tree down through InitialStore.xml\Hyper-V services\Role Assignments\Administrator, and select Administrator.

In the area on the right, right-click and select “Assign Users and Groups” then “From Windows and Active Directory…”.

Add the appropriate users or groups (here you can see the “john” account)

Close the Authorization Manager MMC.

IMPORTANT. You must now reboot your server for the above changes to take effect.

In part 2, I'll walk through the client configuration steps.

Update 14th Nov 2008. I've just released a script which does all this configuration in one or two command lines: HVRemote

Cheers,
John.

Windows Desktop Search - Index network shares for faster searching

jhoward — Wed, 21 Feb 2007 19:51:00 GMT

Can't wait to get home tonight..... just saw a pointer to this download on microsoft.com which is an addin for Windows Desktop Search, supported on Windows Vista which provides indexing capability for network shares. Given I've got hundreds of GB of data sitting on network shares which I'm regularly searching (slowly), this will make life far easier for me. Hopefully for you too.

http://www.microsoft.com/downloads/details.aspx?FamilyID=f7e981d9-5a3b-4872-a07e-220761e27283&displayLang=en

Cheers,
John.

Enable Remote Desktop Connection through Windows Firewall Remotely

jhoward — Thu, 11 May 2006 06:29:00 GMT

Yesterday evening, I was at home and attempting to remotely connect to my XP desktop machine in the office to access an application which was installed there, but not installed on my laptop. This was over VPN. Now I’ve only had both machines for a few weeks since moving over here and was positive that one of the first things I did on my work machine was to allow remote desktop. However, once on VPN, I was unable to connect to that machine remotely.

My first thought was that I’d forgotten to tick that checkbox as shown above (it wasn’t, but I didn’t know better then). So my thought process was simple – it’s no problem – there’s a way round changing that setting as I had already gone through the simple checks – ping worked, net use to c$ worked. Even better, I had remote access to the registry and the event viewer to there was a relatively easy solution.

That checkbox at the end of the day is just a registry setting. So how do you find out what the registry setting is? One way would be to change the setting locally while running sysinternals RegMon utility, see what was changed and update it remotely. Not the simplest way (maybe), but it would work. As it happened, being at home with my domain in place, I’d previously created a Group Policy to ensure that all clients at home were remotely accessible.

From GPMC, the details tab will give you a GUID for that policy.

You can then go to \windows\sysvol\sysvol\<domain>\policies\GUID\Machine and type out the registry.pol file to see the setting it’s applying. You could also take a look at the associated ADM file – both work easily as well

As you can see, the registry setting is under HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services and the setting is fDenyTSConnections. What isn’t clear from a binary dump here is what the value of that setting is being set to, or what the type is. However, a quick regedit on a client tells you that information – it’s a DWORD with value 0.

If you then use regedit, connect to the machine remotely, it’s trivial to change that setting. However, remote connections were still failing. Hmmm. What about a remote reboot – easy enough using the shutdown command. Still no connection. Anyway, I’m up to the challenge here.

What about forcing a refresh of policy remotely. That’s fairly straightforward using psexec from sysinternals. Start a remote command prompt and run gpupdate /force. Unfortunately, still not able to get a connection. Next thing to look at turns towards the Windows Firewall. Fortunately, through running netstat –an –P TCP via psexec, you can see what ports are listening.

So at this point, I’m pretty sure (assuming the policy had been applied correctly), it’s the Windows Firewall blocking port 3389 (RDP). Next thing to do is to use psexec again to get a dump of the Windows Firewall domain policy (this was a domain joined machine). netsh has an option “dump” which you would think would be the right option to select, but that’s not it. What you actually need to run is show config as in netsh firewall show config. This confirmed there is no port opening for Remote Desktop in the configuration

Again, you can use netsh remotely through psexec to allow that exception. The command is netsh firewall set portopening protocol=TCP port=3389 name=<arbitrary> mode=ENABLE profile=DOMAIN

And that was it. Remote connectivity enabled.
Hope this helps someone!
Cheers,
John.

Internet Explorer Tip - Open new window

jhoward — Tue, 09 May 2006 16:18:00 GMT

Here's a tip I learnt a couple of months ago and meant to post up before - totally forgot. Maybe it's force of habit, but rather than opening a new instance Internet Explorer, going to the address bar and typing in a web page, it's quicker to do start/run (ie Windows+R) www.microsoft.com instead. No, that's not the tip (but useful if you're doing it the long way now!).

The problem with the start/run way is probably due to my messy desktop - I already have the start bar expanded to allow for two rows of window icons and can't get used to the grouping of icons on the start bar - it's not uncommon to have 18 windows simultaneously (I just counted). Several of them are usually IE instances (and most of those with multiple tabs). Start/run will "hijack" the first started IE instance and lose your current page (which I usually want). Worse, the instance it hijacked may be a "pop-up" style window, either not re-sizeable or without toolbars. Not the end of the world as you can still click Alt-Left and go back, but it then means you have to do things the long way again.

The answer is to rather than start/run www.microsoft.com you do start/run explorer http://www.microsoft.com. OK, so the astute may be thinking here this isn't much of a shortcut - thats 16 extra keystrokes ("explorer http://") - yes, you must include the http:// prefix :(. However, you can get that down to 2 extra characters by creating e.cmd somewhere in your path (eg \windows\system32) containing 2 lines:

explorer http://%1
exit

Then you can do just start/run e www.microsoft.com. Of course, you can take this much further by parsing %1 parameter in the batch file (or using a VBScript). How about looking to see if theres a www prefix missing and adding it - similarly, the .com. Now there's a thought - start/run e microsoft. Only just crossed my mind as I'm typing this. Hmmmm! Definitely on my list of things to do.

Now, if I can only find a way of doing this in a way which finds a suitable IE Windows (ie resizeable with toolbars and address bar), adds a tab to it and navigates that tab to the URL, I'll be even happier...

Hope that helps someone.
Cheers,
John.

Hands-on Windows OS Internals and Advanced Troubleshooting

jhoward — Fri, 21 Apr 2006 18:26:00 GMT

I received an email from David Solomon - author of Windows Internals this morning. By amazing coincidence, I happened to have a copy of it open and reading it just as the email came in. David & his colleage, Mark Russinovich regularly give courses to folks in the Windows Core OS Division here in Redmond as part of a standard "getting up to speed" induction.

David just let me know that on 26th-30th June there will be a course running in London. Registration for that can be found here. From the people on campus I've spoken to who've been on this course, they highly recommend it.

Here's the full details:

Hands-on Windows OS Internals & Advanced Troubleshooting w/Russinovich and Solomon

If you like Sysinternals or the book Windows Internals, then you'll want to attend a hands-on (bring your own laptop) Windows internals & advanced troubleshooting class, taught by Mark Russinovich and David Solomon. Topics include: crash dump analysis, advanced process and thread troubleshooting, memory management internals, security internals, boot process and troubleshooting, I/O system. Now updated to cover (Windows) Vista!

Cheers
John.

Windows Vista Webcasts Next Week

jhoward — Fri, 07 Apr 2006 16:29:00 GMT

Just seen the list of webcasts for next week - there's a couple on the list worth mentioning. All times are PST (add 8 hours for UK time)

Top 10 Things You Need to Know About Windows Vista for the Enterprise (Level 200)
Wednesday, April 12, 2006 - 9:30 AM - 10:30 AM Pacific Time
Glenn Fincher, Senior Consultant, Xtreme Consulting Group
For those of you who haven’t had a chance to get a preview of Microsoft Windows Vista, this webcast introduces some of the new features and capabilities. This discussion focuses on features designed with the enterprise in mind.

http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032292988&Culture=en-US

Top 10 Things You Need to Know About Windows Vista for Small and Medium-Sized Businesses (Level 200)
Wednesday, April 12, 2006 - 11:30 AM - 12:30 PM Pacific Time
Tony Richardson, Principal Consultant, Xtreme Consulting Group, Inc

For those of you who haven’t had a chance to get a preview of Microsoft Windows Vista, this webcast introduces some of the new features and capabilities. This webcast focuses on features designed with small and medium-sized businesses in mind.
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032292994&Culture=en-US

TechNet and Languages in Internet Explorer

jhoward — Tue, 28 Feb 2006 06:13:00 GMT

I'm sure this isn't going to teach a lot of people anything new, but given I just noticed it myself, I think it's worth mentioning just in case. Due to my recent change of laptop, and the fact that my new laptop doesn't run Windows Server 2003 (actually it does, just not very well - the power settings are a nightmare), I'm back to a default install of XP still at the defaults for many settings. One such setting shows itself up in Internet Explorer. There's been a few sites over the past few days I've visited and noticed that I was getting US English settings (dates for example) rather than UK English, even though I set the language and keyboard input settings to UK English at XP install time. Fine - I could just wait a month and it wouldn't make a lot of difference. However, I double checked the Internet Explorer settings and found that even with the selected install options, for some reason the language was still set to "en-us" (US English). You can see this in action on numerous sites, for example http://support.microsoft.com which shows up as Microsoft US Support. More obviously an example is the newly designed TechNet site at http://www.microsoft.com/technet which, if you're set for UK English will redirect to http://technet.microsoft.com/en-gb/default.aspx. <shameless plug>Well worth a look.</shameless plug>

To check or change your language settings in IE6, select Tools/Options. On the general tab, click Languages near the bottom and add/remove the appropriate languages.

Shadow Copy Client Download

jhoward — Mon, 20 Feb 2006 11:11:00 GMT

I was on the train a few days ago and ended up chatting to some guy (apologies, I'm terrible with names) about stuff which inevitably deviated into technology - of course we got to the bit when I mentioned I worked for Microsoft. His relatively small company continues to run Windows Professional 2000 on the client side, with Windows Server 2003 for servers. However, one thing he did want was the ability to be able to use shadow-copies on those clients. As it ships, Windows 2000 Professional did not have the client side capabilities to be able view those previous versions generated through shadow copies. I said to him I'd dig out the link and here it is: If you have Windows 2000 SP3 or later, this download will add the capability, but there are other downloads on that page for earlier versions of Windows too.

Good talking to you!
Cheers,

John.

Clear Read-Only Attributes in bulk

jhoward — Mon, 13 Feb 2006 15:49:00 GMT

There's often those situations where you need to clear read-only attributes from a directory tree in bulk. In the past, having been a command line junkie and developer, I've used the attrib command with the /S parameter to include sub-directories as I've invariably had three or four command prompts open simultaneously. Those days have moved on, and the therapy has made me cut down to a maximum of two prompts at a time :) (It's obviously working as there's only one open at the moment!)

While command prompts work for many people, I came across a utility a few years ago which extends the context menu for the Explorer shell which does the same thing. It shows how my mindset has changed - the machine I needed to change the attributes from didn't have the utility installed. It didn't even cross my mind until posting this about opening a command prompt - a quick Internet search to find the utility was my immediate thought and solution I used. Useful also as it works right across the board - from Windows 95 to Windows Server 2003.

Here's the download link: http://davidcrowell.com/Croa.aspx

Applying Least Privilege to User Accounts in Windows XP

jhoward — Tue, 07 Feb 2006 19:51:00 GMT

You've already probably heard by now the many efforts and changes which will be coming into place with the release of Windows Vista later this year regarding how "least privilege" (I use quotes as the actual term has changed a few times and I'm not sure that the latest TLA is) will be strongly enforced through all interactions between user and computer.

However, applying least privilege to user accounts in Windows XP isn't always the most pain-free time to be had - users can be frustrated, support calls 24x7. You know the story, I'm sure. However, yesterday the MSSC (Microsoft Solutions for Security & Compliance) team released "Applying the Principle of Least Privilige to User Accounts in Windows XP". Interesting reading.

It's available on TechNet here or for download here.