John Howard - Senior Program Manager in the Hyper-V team at Microsoft : Network Infrastructure Systems

Connection Manager Administration Kit for Vista

jhoward — Sat, 09 Aug 2008 20:34:48 GMT

Curiosity got the better of me. When I was analyzing why Hyper-V Remote Management didn't always work over a VPN connection due to DNS the other day, I mentioned that I wasn't familiar with the replacement technology for CMAK in Windows Server 2003.

Well, I found it (but it was surprisingly well hidden) - the replacement is.... CMAK, in Windows Server 2008. The details of it are squirreled away in the depths of the Technet Library under Windows\Windows Server\Windows Server 2008\Networking.

It turns out, CMAK is a feature built into Windows Server 2008 - dead easy to install using Server Manager, and it can create profiles for Windows Vista and older operating systems.

But I had to give it a try to see if it was possible to set the DNS suffix for a connection and ensure it was registered on the internal DNS servers when a VPN connection was established, thus ensuring Hyper-V Remote Management works correctly when on a VPN.

Sure enough, then you get to the "Create or Modify a VPN Entry", there is an advanced tab where the three fields needed are present.

Never having used CMAK before, I found it very easy to use, at least for a basic VPN configuration - no custom actions and so forth - those would have been a bit of overkill for a home setup. And did it work? Yup, perfectly :)

Cheers,
John.

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.

Hyper-V: Why is networking reset in my VM when I copy a VHD?

jhoward — Wed, 23 Jul 2008 01:36:53 GMT

This is a question I’ve seen come up a few times so figured it was time to examine why in a little more detail. In Virtual Server, you were able to copy VHDs and the associated VMC (Virtual Machine Configuration) file from one host to another, add the VMC to the other host and everything would work. In Hyper-V however, this is not the case due to improvements in our security model.

The supported way of copying a virtual machine from one Hyper-V enabled server to another is to use the export and import functionality in Hyper-V Manager. However, there are few situations I’ve seen where some creative workarounds have been necessary.

Consider the case where you store a VHD on a different physical drive than the VM configuration, and the physical drive holding the configuration gets corrupted or re-imaged for some reason and the original configuration is “lost”. Let’s suppose further that the virtual machine contains some very specific IP configuration settings on one or more network adapters – maybe it’s a router of some kind, for example.

In this scenario, the obvious thing to do is to create a new virtual machine with a similar configuration, add the VHD(s) and start it up. When you log on to the VM, you’ll see that the originally configured IP settings are no longer present. The reason for this is that the “GUID” of the original network adapter was stored in the “lost” configuration. So when a new configuration is created, when a synthetic NIC is added, a new GUID is generated. When the virtual machine starts, plug-and-play see this new NIC, as a completely different NIC, just like as you would in a physical machine.

Of course, you can, in most circumstances (I’m not aware of any Microsoft applications which you can’t do this on) reset the IP configuration, change the application(s) to bind to the new network adapter and all is good. Apart, that is, from that reminder from Windows that another adapter already has that IP address, as shown below.

There's a KB article outlining how to remove those hidden network adapters. (Although targeted for XP, this appears to also work on Windows Server 2008).

So that explains what’s going on. The rest of this article really just digs a tad deeper for a little more insight into how Hyper-V operates under the covers, and see if there’s another way to approach this.

Let’s go back and go through what we’ve done so far:

Created a (Windows Server 2008) virtual machine with a single “synthetic” NIC
Assigned a static IPv4 address of 192.168.200.248.
Deleted the virtual machine using Hyper-V manager (this doesn’t delete the VHD).
Created a new virtual machine using the same VHD and a single “synthetic” NIC.
In Network Connections (ncpa.cpl), you see Local Area Connection n where n does not match what would have been seen in the original VM
For that same “Local Area Connection n” network connection, you’ll see the device name is “Microsoft Virtual Machine Bus Network Adapter #m” where m does not match what you would have seen in the original VM (or may have been missing entirely).

Now perform the steps in the KB article so that we can see the “old” NIC in device manager. From an elevated command prompt:

set devmgr_show_nonpresent_devices=1
start devmgmt.msc
On the menu bar: View/Show hidden devices
Expand the Network adapters node

There are two NICs. Let’s take a closer look at the dimmed adapter (the one highlighted) by selecting properties, switching to the details tab and selecting Hardware Ids from the dropdown. In particular, notice the first line highlighted which is a GUID, in this example, starting f61bbefc-.

This is the VMBus “Channel Offer GUID” for the “old” NIC. Let’s do the same with the currently configured NIC.

Notice that the highlighted GUIDs are different – the new one, in my case, starts 944fafdc. (Another way to retrieve this GUID is to extract it from the registry – a little harder, but absolutely possible.) Now a bit of background information – let’s take a look at the XML configuration file for the current virtual machine. By default, the XML configuration files are stored under \programdata\microsoft\windows\hyper-v\virtual machines. BUT – it’s totally unsupported to edit these files manually, and we entirely reserve the right to change the format at any point in time. There’s no harm though taking a peek at a section of it. Notice the highlighted line (ChannelInstanceGuid) matches 944fafdc….

So you’ve probably now worked it out. We know the old “ChannelInstanceGuid” from the device manager screenshot above, and need to create a VM configuration with that same ChannelInstanceGuid. As I mentioned above, it’s totally unsupported to hand-edit the configuration file, so we have to use an alternate mechanism. We expose this property in our WMI model (http://msdn.microsoft.com/en-us/library/cc136992(VS.85).aspx). Specifically, it’s the first element of the array Msvm_SyntheticEthernetPortSettingData.VirtualSystemIdentifiers[] which needs updating. I’ll leave the actual scripting sample up to someone else – there’s various examples out there on the Internet of how to use the Hyper-V WMI model.

Hope that was of interest.
Cheers,
John.

Hyper-V: MAC Address allocation and apparent network issues MAC collisions can cause

jhoward — Wed, 16 Jul 2008 06:02:00 GMT

In a physical only world, you don’t usually have to worry about MAC addresses that much as each NIC vendor carves off a MAC address from their ranges which have been allocated to them. However, in a virtual environment, you have to be a little more careful, particularly if you are using dynamic MAC address assignment. This post looks at how Hyper-V allocates dynamic MAC addresses and some potential problems you can face. So often it can be the last thing people think to check, but can be the root cause of otherwise unexplained network oddities.

Here’s a screenshot of a typical MAC collision problem – pings sometimes work, sometimes fail – and this is all on a local isolated network.

To start the walkthrough, I have a base install of Windows Server 2008 on a server with a single physical NIC – against best practice, but it serves fine for demonstration. I have already installed the RTM update (KB950050) to the server, but have not yet added the Hyper-V role. Let’s look at an output of “ipconfig /all”. You can see that the MAC address of the physical NIC is 00-13-20-F5-F8-7D and I’m obtaining an IP address from a DHCP server on the private test network I’m using.

Now let’s use Server Manager to enable the Hyper-V role. Note that Server Manager allows you to create an external virtual network switch during role enabling, but I am choosing not to do this. Let’s see what has happened in the registry after the Hyper-V role is enabled. Specifically, I’m looking at two keys which have been created under HKLM\Software\Microsoft\Windows\NT\CurrentVersion\Virtualization, as-yet unpopulated: MinimumMacAddress and MaximumMacAddress, plus another key in the worker node, CurrentMacAddress – again as-yet unpopulated. (The astute walking through this in front of a machine will notice that CurrentMacAddress also appears in the Virtualization node. That key is not used though.)

Next, I’m going to create my first virtual machine. As I haven’t created any virtual network switches yet, I’ll leave the network disconnected. I don’t need a hard disk. Also, I’m deliberately choosing not to start it. Let’s see what’s happened in the registry. MinimumMacAddress and MaximumMacAddress have been populated with 00-15-5d-c8-6a-00 and 00-15-5d-c8-6a-ff respectively – a range of 256 possible MAC addresses.

So where did this range come from? The first three bytes are the Microsoft IEEE Organizationally Unique Identifier, 00-15-5D which we use in Hyper-V. The next two bytes, C8-6A are derived from the lowest two octects of an IPv4 address on the server (the first IP address as NICs are enumerated). If you look at the second screenshot in this post, the IPv4 address on the only NIC on this server was 192.168.200.106. In Hex, this is “C0.A8.C8.6A”. The last two octets or bytes are C8 and 6A. The last byte of the address range is automatically generated with a minimum 00 and maximum FF.

You can probably now realize, that while this algorithm will work for many people, it may not necessarily be perfect and cause MAC address range clashes. To cope with multiple Hyper-V enabled servers, you would need to ensure address ranges are managed at a higher level across those servers, such as the use of SCVMM.

Let’s go back to the virtual machine I created. By default, when a virtual machine is created, it is allocated a dynamic MAC address. This can of course be changed in the settings for the virtual machine. Here’s the setting for the blank virtual machine. Notice that it’s set to Dynamic and the MAC address in the “Static” boxes show 00-00-00-00-00-00

Now I’m going to start the Virtual Machine and open the settings. Although some settings cannot be changed while a virtual machine is running (including changing static/dynamic MAC, or the static MAC itself), notice that the boxes under the static MAC address radio button are now populated with the first MAC address in the range defined in the registry: 00-15-5D-C8-6A-00.

Now for a bit of fun (and to make the walkthrough a bit simpler), let’s change the registry so that the maximum MAC address is 00-15-5D-C8-6A-02. (I’ll also do a reboot just to make sure the change takes effect) This change means that we are limited to three possible dynamically assigned MAC addresses, the last octet being 00 (in use by the “Blank” VM), 01 or 02.

Now, I’m going to create another virtual machine named 6A-01 and power it on, then create a third virtual machine named 6A-02 and power that on too. Let’s look at the settings for each of these while all three virtual machines are running. As expected 6A-01 has a MAC address ending 6A-01 and 6A-02 has a MAC address ending 6A-02. That’s why we have the “CurrentMacAddress” registry key to track what MAC address to assign to VMs in turn.

Can you guess though at this point what would happen though if I create another virtual machine and power it on? I don’t have any MAC addresses left in my available range and all MAC addresses are currently in use.

Did you guess correctly? Let’s now power off the very first virtual machine (“Blank”) I created with MAC address 6A-00, and then try to run through the New Virtual Machine Wizard again with my “No MAC Addresses Available In Range” virtual machine. Try to guess what will happen at the end.

The virtual machine starts successfully and now has a duplicate MAC address to the first virtual machine I created, ‘Blank’:

Last quiz question: What would happen then if I tried to start “Blank” – will it start or not? After all, it has already been allocated a MAC address ending 6A-00.

Actually, we will detect this as you can see above and stop the virtual machine from powering on. So in some ways, on a single Hyper-V enabled server, we’re relatively immune to duplicate MAC addresses across virtual machines running on a single server. However, due to the algorithm for choosing the ranges of MAC addresses, while relatively safe, there is no guarantee of being unique across an entire network. And of course, chances are that you will want packets from or to virtual machines on a Hyper-V server to “hit” the physical network.

So hopefully that gives you a better idea why it is important to manage MAC addresses across multiple servers in a virtual machine environment. While the walkthrough above was specific to Hyper-V, the same types of issues could arise in Virtual Server.

Cheers,
John.

Hyper-V: What are the uses for different types of virtual networks?

jhoward — Wed, 18 Jun 2008 02:57:00 GMT

If you followed yesterdays post explaining the basics of networking in Hyper-V, you may be wondering what the different types of virtual networks are, when you should use them, and how they look in terms of traffic flow.

When you open Virtual Network Manager from Hyper-V Manager, there are three types of virtual network which can be created: External, Internal and Private. There is also a fourth type which can only be created through WMI and doesn’t have an official name, but I’ll call it a “Dedicated” virtual network (thanks Jake who came up with the suggestion!). Let’s look at each type, and when it is appropriate to use them.

External

External virtual networks are used where you want to allow communications between

Virtual machine to virtual machine on the same physical server
Virtual machine to parent partition (and visa-versa)
Virtual machine to externally located servers (and visa-versa)
(Optional) Parent partition to externally located servers (and visa-versa)

Internal

Internal virtual networks are used where you want to allow communications between

Virtual machine to virtual machine on the same physical server
Virtual machine to parent partition (and visa-versa)

In a block diagram, an internal network is an external network without the binding to a physical NIC. An internal network would commonly be used to build a test environment where you need network connectivity into the virtual machines from the parent partition itself.

Private

Private virtual networks are used where you want to allow communications between

Virtual machine to virtual machine on the same physical server

In a block diagram, a private network is an internal network without a virtual NIC in the parent partition. A private network would commonly be used where you need complete isolation of virtual machines from external and parent partition traffic. DMZ workloads running on a leg of a tri-homed firewall, or an isolated test domain are examples where this type of network may be useful.

Dedicated

Dedicated networks are in some ways one of the most useful type of virtual network where you dedicate a physical NIC for use just by virtual machines. They allow communication between:

Virtual machine to virtual machine on the same physical server
Virtual machine to externally located servers (and visa-versa)

Note that the parent partition is unable to use a dedicated virtual network for its own communication. You would normally have a second physical NIC for use by the parent partition, as was discussed yesterday. In a block diagram, a dedicated network is an external network without a virtual NIC in the parent partition.

Note that you can achieve something functionally identical to a dedicated network by creating an external virtual network, and unbinding the protocols from the newly created virtual NIC in the parent partition. However, I would personally recommend you deploy a dedicated virtual network “correctly” to avoid accidental changing of bindings on the virtual NIC, or to avoid confusion as to what is present in the network adapters control panel applet. (And before you ask, I don’t have a sample script to create a dedicated virtual network yet. A post for another day).

Cheers,
John.

How to remove a failed server from DFS in Windows Server 2003 R2

jhoward — Sat, 20 May 2006 18:12:00 GMT

This week has been a little strained, hence quiet on the blogging front. Apart from a hectic week at work (more to follow on that shortly), the reason was a "disaster" which happened late last Sunday evening - everything was working at home one moment, and dead the next.

Since the move over from the UK, I'm still in temporary accomodation. To save space, although my servers were couriered over, I didn't bring a monitor as all the monitors I owned only ran on 240v. The servers arrived a little shaken, but not too stirred - a few cards were loose, but no failed disks. Just a little prodding into place and they came back perfectly. Humming away for 6 weeks or so without fault.

If you've ever tried to figure out why a machine won't boot without a monitor attached, I know where you're coming from. Short answer is, it's next to impossible. It also happened that this machine was not just any machine, but a Domain Controller. And not just any domain controller, the domain controller holding all the FSMO roles for my home domain. Of course, it will probably come as no surprise to you it's also running a further 5 virtual machines including my website hosting, ISA and Exchange. So yes, it was somewhat of a disaster.

On Monday morning, I took the machine into the office and with a monitor attached, it was obvious it was continually rebooting (off both plexes in the boot mirror) before the GUI portion of the boot came up. Safe mode, last known good gave same symptoms. Similarly, boot logging didn't help as the boot log doesn't get written to disk until the GUI part of the boot comes up.

I borrowed another disk from Ben, plugged it in and installed XP SP2 (only 32 bit OS immediately to hand). However, during the first boot, it blue-screened. Sure enough, there was a problem with the hardware - either motherboard or memory.

Running a memory tester showed something wrong with one or more of the (expensive!) ECC memory slots. I saw a big bill coming :(. It was a tedious process of elimination by swapping DIMMs around until the failed chip or chips was identified. That at least got to the point of XP booting. Attempting to boot back with the failed DIMM removed (actually a pair as the system needs matched pairs), same symptoms as before. At this point, going back to XP, I discovered XP didn't have drivers for the RAID SCSI Controller for the system boot disk and worse, none were available. Onto plan B for recovery.

I re-installed a Windows Server 2003 on the loan disk with the recovery console enabled to attempt to see what was going on. Chkdsk showed the SCSI disks being corrupt and the mirror needing repair. Fixing those still wasn't getting past the text mode part of the boot.

Not being one to give up, I took the machine home on Monday night. During the day, my wife had bought a second hand 17" monitor for $20.00 - given it's in next to perfect condition, I thought that was pretty good value.

From the recovery console of Windows Server installed on the loan disk, I spent two very long and tedious evenings going through disabling drivers one-by-one in the hope I'd find the driver failing to load - every time the same 0x0000007b with 0xc000007b in the parameter list - inaccessible_boot_disk.

Well, two days later I did give up. In some ways I'm glad I did - when I took the decision to blow away the machine for real, I discovered the disks were also corrupt in some way - both of them. Blue screens on reinstall. Possibly the RAID controller? Nope, tried a spare one too :( Anyway, I've more disks on order and more memory on order - at least they're much cheaper in the US than in the UK.

In the meantime, with reduced RAM, on the loan disk I at least got the ISA server and the Exchange server back running. Cleaning up AD to seize the FSMO roles which were held by the previous installation is easy enough (http://support.microsoft.com/?id=255504). They're now safely on a Virtual domain controller running on another server.

However, there was one interesting side effect relating to DFS in Windows Server 2003 R2. Yes, the machine also was a file server replicating to another server using RDC using domain based DFS. Some of the DFS roots had the now decommissioned server as the preferred target. What this unfortunately means is that when you go into the DFS console from another machine (either another server or from an XP machine with the console installed), when examining the DFS Root, you get the error below: \\domain.com\share: The namespace cannot be queried. The RPC server is unavailable.

This only happens on roots which were configured to have the failed server as the preferred target. Clients were still OK accessing the still working server as they failed over automatically

So, from the File Server Management Console, you're stuck - you can't remove the failed server. However, you can use the command line utility, dfsutil to forceably remove it.

First, run dfsutil /root:\\domain.com\share /export:share.txt

Share.txt will look something like

<?xml version="1.0"?>
<Root Name="\\DOMAIN\Share" State="1" Timeout="300" >
<Target Server="FAILEDSERVER" Folder="Share" State="2"/>
<Target Server="GOODSERVER" Folder="Share" State="2"/>
</Root>

To delete the failedserver, and remember this is a last ditch thing, run (on one line)

dfsutil /unmapftroot /root:\\domain\share
/server:failedserver /share:share

You're now close. To make this work, you must have access to the share on a good server. You must also bounce (at least I had to) the DFS Replication service on the good server AND restart the File Server Management Console. However, once done, everything will be good again. Just need to re-introduce the new server once the new disks arrive.

So now you know one reason why it's been a quiet week of blogging!
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.

DHCP Client service required for Dynamic DNS Registration

jhoward — Thu, 27 Apr 2006 18:43:00 GMT

One of those oddities I discovered a couple of days ago after trying to tune down my IIS box which is configured with a static IP address. I stopped the DHCP Client service as I figured (incorrectly) that it wouldn't be needed due to not using DHCP for that server. I didn't notice a problem until I tried accessing the website externally the next day. Once you stop the DHCP Client service, there isn't an immediate problem as the DNS server still had the unexpired registration - however, as soon as that expired, the IIS server effectively fell off the network as it's name could not be resolved internally.

The error I was seeing was when accessing a web-site hosted on that IIS server externally. The network looks a bit like this:

Client -> Internet -> ISA Server -> IIS

When accessing the website, the ISA server returns an error to the client along the lines that it could not locate the upstream server. The ISA Server's web-publishing rule says that to forward requests from www.myexternaldomain.com to iis.myinternaldomain.com (names substituted obviously).

When trying to diagnose why the problem was happening, it's worth mentioning I have three DNS servers internally, all replicating among them. Unfortunately, what I didn't realise (bad Admin, slap wrists again) that one of them wasn't replicating fully. Hence, from the ISA firewall, an nslookup to find iis.myinternaldomain.com worked. I didn't point nslookup at the other two servers, or run a netdiag as it appeared to be OK. I could also ping the machine from the firewall so it involved a bit of headscratching.

What was even stranger from a diagnosis point of view was that from a client, I could point Internet Explorer at iis.myinternaldomain.com and the site appeared. It was only when I went to the IIS box itself which happened to be pointing at a different DNS server, I realised on an nslookup that there was a DNS problem - the record wasn't present on that DNS Server. Now why the firewall default DNS server thought the record was present, yet when accessing it through the ISA Server, it failed to find it, I've no idea.

Anyway, the moral of this story is, don't stop the DHCP client on a server if you want to be able to find your server through DNS at a later time. There's a related KB article I found here.

Hope this helps someone.
Cheers,
John.

Backing up Windows Sharepoint Services

jhoward — Fri, 23 Dec 2005 16:55:00 GMT

Although I have a fair few ideas as to mini-projects to complete over the Christmas & New Year holiday, it will probably come as no surprise to many of you that there is always the possibility that family will get in the way ;) On the assumption that I can find enough excuses, one thing I've prepped over the past few days is a base VM of Windows Server 2003 R2. One instance is, as of this morning, running Windows Sharepoint Services. WSS isn't a product I've really looked at a great deal before, and before I start putting anything important on it, the first consideration is how can I back it up if disaster strikes. Fortunately, I found a good answer here which I'll try out.

Funny that WSS stands for so many things now: First it was the Web Storage System as implemented in Exchange 2000 and just after, in the original Sharepoint Portal Server. Then it was (and is still) Windows Server System. And now a third. I think there must be a world-shortage of TLA's...

And here's just some of the other projects on my to-do list this Christmas:

Complete my SQL 2000 -> SQL 2005 migration
Implement IPSec
Complete the VPN quarantine project which fell by the wayside a little
Try out Exchange 12 Beta
Implement SMS
Read new WMI Scripting book

And on Santa's wish list:

XBox 360
Another 4GB of RAM and a second Xeon processor :)
Bunch of SATAII drives with RAID card. 10x250GB should last a few months :)

And on Santa's actual list (probably)

Socks, Aftershave :(

Have a great Christmas & New Years celebration everyone. I'm back online on 3rd Jan next year.
Cheers,
John.

Part 25: Infrastructure essentials Blogcast - RPC/HTTP for Outlook & Exchange - Integrated Auth

jhoward — Fri, 16 Dec 2005 11:45:00 GMT

Continuing the blogcast series on infrastructure essentials.

The final part to the RPC/HTTPS series shows you how to alter the configuration we have such that Outlook 2003 can move seamlessly between external and internal connectivity through the use of integrated authentication. To do this, we need to change both the ISA server and the Exchange server. The overall end user experience, as you will see, is far better.

So over the Christmas break, I'll get round to recording a few more parts to the series, including VPN connectivity.
Click here to view.

Series Index:

0. Network configuration and series background.
1. Getting started
2. ISA Server configuration to allow basic web browsing capability
3. ISA Firewall Client basic configuration
4. ISA Firewall Client auto-detection through WPAD configuration
5. Configuring an Exchange mailbox and Outlook profile
6. Fixing 0x8004010F on Outlook send/receive
7. Installing our first Certificate Authority
8. Publishing OWA through ISA using Forms Based Authentication
9. OWA /exchange redirection
10. OWA nearly goes SSL - we have a certificate
11. OWA is available over SSL/HTTPS
12. Sending external email - Configuring outbound SMTP
13. Mail retrieval through POP3 polling
14. Preparations for Email retrieval through SMTP Transfer
15. Completing Email retrieval through SMTP Transfer
16. RPC/HTTP: Overview and installing RPC Proxy component
17. RPC/HTTP: IIS Config and a bit on certificates
18. RPC/HTTP: Exchange IIS Config completion
19. RPC/HTTP: Working from internal network
20. RPC/HTTP: Revisiting our ISA rules
21. RPC/HTTP: Outlook working externally. OWA still requires more work
22. RPC/HTTP: Bounce OWA through localhost
23. RPC/HTTP: OWA Back to HTTPS
24. RPC/HTTP: RPC Publication

DFS Namespace Active Directory blob size in Server 2003 R2

jhoward — Fri, 09 Dec 2005 10:12:00 GMT

Another question asked on Wednesday evening's Intro to R2 event was about the blob size limitation in Domain Based (ie Active Directory integrated) DFS-Namespaces. Has it changed since Windows Server 2003 SP1? The answer is no, the same limits apply. The recommendation is for around 5,000 links and the wizard in the DFS Namespace wizard reminds you of this approximate limit. However, that isn't a strict value. The real limitation is around 5MB of storage being used.

But, what is really great in Windows Server 2003 R2 is that you can get a view of the blob size very easily, and work out if you can add more links. In the DFS Namespace Management UI, examine the properties of a domain based namespace. If you have 5,000 links but the blob is around 2.5MB, you're good to keep adding links until the blob gets close to that 5MB.

Thanks to Drew from the product group who gave me the answer :)

Blogcast: Virtual Server 2005 R2 Host Clustering How To - Part 5 of 5

jhoward — Fri, 02 Dec 2005 22:08:00 GMT

If you watched the demonstration blogcast of Virtual Server 2005 R2 I posted up at the weekend, yesterday, I ripped the environment apart to build it again from scratch so you can see how I built it.

The last part of this mini series is where we setup the networking on the Virtual Machine guest we are making highly available through host clustering. In my scenario, I deviate from the whitepaper on host clustering as the network cards between my two hosts are different. In the whitepaper, you place the .vnc file for the network on the shared drive. I also show you once more what happens during unplanned downtime by power-cycling one of the nodes in the cluster.

So that's all you need to know about host based clustering using Virtual Server 2005 R2 in conjunction with Windows Server 2003 Clustering Services. Have fun, and please let me know if you found this useful!

Click here to view part 5.

Previous parts:

Part 1
Part 2
Part 3
Part 4

Blogcast: Virtual Server 2005 R2 Host Clustering How To - Part 4 of 5

jhoward — Thu, 01 Dec 2005 19:14:00 GMT

If you watched the demonstration blogcast of Virtual Server 2005 R2 I posted up at the weekend, yesterday, I ripped the environment apart to build it again from scratch so you can see how I built it.

In part 3, the new cluster group for the virtual machine was created. In the penultimate part of this mini-series, we place the VHD and VMC for a virtual machine on our shared drive and examine the configuration after adding it to the Virtual Server 2005 R2 admin interface on Node 1 of the cluster. For now, we don't configure the network (that's for part 5). We fail the virtual machine cluster group across to Node 2 and repeat adding the machine through the Virtual Server admin interface. We perform a critical step from the command line to set a private variable for the cluster script to work correctly. This absolutely must be done before the script is brought online in cluster administrator. The command takes the following format:

cluster res "<HA scriptname>" /priv VirtualMachineName=<Name of VM>

With that done, we are ready to bring the script online in the cluster group and watch the Virtual Machine starts up. Once booted, we log on and start working. In cluster administrator, we then proceed to move the cluster group across to the other node, verifying we are able to continue working on the guest now running on the other cluster node. This is an example of "Planned" downtime.

The final part of thi series is where we setup the network for failover, but in an atypical configuration to that described in the whitepaper - in the environment I have, the network cards used by the guest are different between the two hosts. However, it's good to know that this is possible. Stay tuned tomorrow to find out how :)

Click here to view part 4.

Previous parts:

Part 1
Part 2
Part 3

Blogcast: Virtual Server 2005 R2 Host Clustering How To - Part 3 of 5

jhoward — Wed, 30 Nov 2005 12:58:00 GMT

If you watched the demonstration blogcast of Virtual Server 2005 R2 I posted up at the weekend, yesterday, I ripped the environment apart to build it again from scratch so you can see how I built it.

Part 3 of 5 gets into the "nitty-gritty" of the configuration. We create a new group in the cluster for the guest virtual machine and create the script necessary for the high-availability failover of Virtual Machines in a cluster. We add this script as a generic resource to the cluster.

Click here to view part 3.

Previous parts:

Part 1
Part 2

Part 24: Infrastructure essentials Blogcast - RPC/HTTP for Outlook & Exchange - RPC Publishing

jhoward — Tue, 29 Nov 2005 13:48:00 GMT

Continuing the blogcast series on infrastructure essentials.

In the last part, forms based authentication for Outlook Web Access was back running again, bouncing through the localhost listener. In this part, we put RPC/HTTP back into place. We create a publishing rule for the Exchange Virtual Directory being published (/rpc). We also create a publishing rule for the RPC server. However, since recording this blogcast a couple of months ago now, this step is actually not necessary - I recommend you do not do this part of the configuration.

Click here to view.