Securing Wireless Networks with Windows Server 2008 and NPS

In this post I’m going to go through the process of securing your wireless network using Windows Server 2008 and the NPS (Network Policy Services) role from start to finish.

Previously, I was using Windows Server 2003 with IAS (Internet Authentication Services) to secure my wireless network, until I recently upgraded all of my servers to Windows Server 2008 – By the way, NPS is the new version and name for IAS.

Here is the TechNet guide which I followed – http://technet.microsoft.com/en-us/library/cc771455.aspx – I will be applying these guidelines to the following environment…

  • A Windows Server 2008 machine running AD DS (Active Directory Domain Services)
  • A Windows Server 2008 machine running NPS (Network Protection Services) and AD CS (Active Directory Certificate Services)
  • A Linksys WAP54G (an entry level wireless access point – you can use any wireless access point that supports RADIUS)

You can run NPS, AD DS and AD CS on the same machine if you want to, but I wouldn’t recommend it (personally, I prefer to keep my domain controllers running only AD DS).

I’m not going to go through the process of installing AD DS as it’s a little out of scope for this post, so we’ll start from having an established domain, and a clean install of Windows Server 2008 on which we will install AD CS and NPS.

The first step is installing AD CS and NPS on your clean Windows Server 2008 install…

  1. First, you’ll need to join the server to your existing domain and then restart;
  2. After the server restarts, open Server Manager;
  3. Click on the Roles node;
  4. Click on the Add Roles;
  5. On the Server Roles screen, select Active Directory Certificate Services and Network Policy and Access Services;
  6. Follow the wizard, selecting Network Policy Server when configuring the Network Policy and Access Services role and leaving the default Certification Authority role service selected for AD CS;
  7. Select Enterprise for the setup type for AD CS;
  8. Choose Root CA for the CA Type (remember we’re assuming that this is the first Certification Authority in your environment, so if it’s not you either don’t need to install this role, or if you choose you can configure this server as a Subordinate CA instead);
  9. Run through the rest of the wizard, making any changes you may wish to, otherwise just leave the defaults as they are appropriate (I changed the CA Common Name to the name of the server, as I think it’s cleaner) – Note that there is a warning at the end of the wizard, stating that the name of this server cannot be changed after installing the AD CS role.

Now that you have a Root CA and an NPS server on your domain, we can start configuring it…

  1. Open an MMC console, and go to File -> Add/Remove Snap-in…
  2. Add the Certificates snap-in, selecting Computer account for the local computer;
  3. Expand Certificates (Local Computers) -> Personal, right click on Certificates and choose Request new certificate;
  4. Follow the wizard, choosing Computer for the certificate type and then click the Enroll button, then close MMC;
  5. Open the Network Policy Server administrative console from Administrative Tools;
  6. Right click on the parent node, NPS (Local) and click Register server in Active Directory – Click OK on the two informational popups;
  7. With the NPS (Local) node still selected, choose RADIUS server for 802.1X Wireless or Wired Connections and then click on the Configure 802.1X button;
  8. Under Type of 802.1X connections, select Secure Wireless Connections and provide an appropriate name for the policies which will be created as part of this wizard;
  9. In the next step, you’ll need to configure a RADIUS client (by the way, RADIUS stands for Remote Authentication Dial In User Service), so click on the Add button;
  10. The RADIUS client will be your wireless access point, so for the friendly name type in something to identify the access point (for example, AP01), then provide the IP address or DNS entry for the access point;
  11. Click on the Generate radio button, and then click on the Generate button to generate a shared secret – Copy the shared secret to a notepad document, and click OK – Note that on my particular access point, a character limit of 22 characters exists for shared secrets so I had to cut the string down to the acceptable limit, so I would suggest checking for this limitation on your own hardware;
  12. Click Next, and then choose Microsoft: Protected EAP (PEAP) and then click on the Configure button (if you get an error message, you probably didn’t follow steps 1 -> 4 correctly);
  13. Ensure that the Certificate issued drop down box has the certificate you enrolled in step 4;
  14. Click Next, and then click on the Add button to use an Active Directory group to secure your wireless (you should add both the machine accounts and user accounts to this group to allow the machine to authenticate on the wireless before the user logs in);
  15. On the next step of the wizard, you can configure VLAN information, otherwise just accept defaults to complete;
  16. Restart the Network Policy Server service.

If you expand the Policies node now, you’ll see that the wizard has created a Connection Request Policy and a Network Policy containing the appropriate settings to authenticate your wireless connection – These individual policies can obviously be created manually, but the wizard is an easier method.

You can also remove the less secure authentication method options, and increase the encryption methods in the network policy if you wish (I have configured mine this way)…

  1. Under the Network Policies node, bring up the properties of the newly created policy;
  2. On the Constraints tab, uncheck all of the checkboxes under Less secure authentication methods;
  3. On the Settings tab, click on Encryption and uncheck all boxes except Strongest encryption (MPPE 128-bit);
  4. Save the policy and then restart the Network Policy Server service.

With the NPS server configured to accept requests from your wireless access point, you’ll now need to configure the access point to communicate with the NPS servers – These instructions are for my Linksys WAP54G, but will be similar to most access points which support RADIUS…

  1. In the web interface for the access point, click on the Wireless tab and assign an appropriate SSID;
  2. Click on the Security sub-tab, and set the Security Mode to WPA-Enterprise (if your access point supports WPA2-Enterprise, use this instead);
  3. Set the Encryption to AES, and then provide the NPS server IP as the RADIUS Server and the Shared Secret that you saved in step 11 above;
  4. Save your settings and restart the access point.

Now your access point should be configured to talk to your NPS server, so all that is left is to configure your clients to connect – The recommended way of doing this, would be to use Group Policy, but the instructions below are for configuring a Windows Vista client – You can easily replicate these actions in a Group Policy under the Security node.

To configure a Windows Vista client which is joined to the domain…

  1. Open up the Network and Sharing Center;
  2. Click on Connect to a network;
  3. Locate the network you have just secured (it should say Security-enabled network next to it) and click the Connect button;
  4. It will take a short while to set up the profile and then connect successfully.

You can also configure a few extra settings to speed up the time it takes to connect (it won’t improve the overall speed, only the time it takes to initially connect to the wireless network)…

  1. In the Network and Sharing Center, click on Manage wireless networks and then double click the network you set up above;
  2. Click the Security tab, and then the Settings button below;
  3. The Validate server certificate checkbox should already be selected by default, but you should also select the CA that you set up earlier under the Trusted Root Certification Authorities to speed up the certificate verification process;
  4. You can also check the box Do not prompt user to authorize new servers or trusted certification authorities in order to improve the user’s experience.

Some suggestions recommendations…

  • Use a security group with the appropriate machine and user accounts as members to secure your network;
  • Group Policy is by far the best way to deploy the client side settings, but will obviously require an established domain connection in order to push these settings down to the clients;
  • While disabling the SSID of your access point sounds like an increased security measure, it can be a security risk if you are configuring your workstations to actively look for the SSID name – Potential session hijackers could intercept this traffic and set up an SSID for the requested name, unknowingly to the user which would then connect to a potentially malicious network;
  • You can vary the encryption type from AES to TKIP if your devices don’t all support AES, although AES is the preferred encryption algorithm;
  • If you’re having trouble with your connection, there are a few places you can look to troubleshoot, namely – Local client event logs, the NPS log file which lives in C:WindowsSystem32logfiles and most importantly the Security event logs of the NPS server which contains detailed information about access successes and failures.

Error Installing Printers on Windows Server Core 2008

If you’ve ever tried installing a printer on Server Core 2008, chances are you’ve probably come across an error when using Print Management (printmanagement.msc) to remotely manage your Server Core install and add your printer. It looks like it’s going to work fine, but then just before it finishes, you get this…

Unable to install <printer name>, Type 3 – User Mode, <architecture> driver. Operation could not be completed (error 0x800f0247).

And then you might also get this…

Failed to add driver. Operation could not be completed (error 0x00000578).

When you try installing this same printer and driver on a GUI machine, it installs without any problems, so you can safely say it’s a Server Core issue.

As you’d expect, the first step would be to lookup the error code… So we have errors 0x800f0247 and 0x00000578.

Converting these codes from hexidecimal to decimal gives us errors 2148467271 and 1400 respectively. The first one is bogus, as it’s out of range, however error code 1400 translates as ERROR_INVALID_WINDOW_HANDLE.

The issue is the fact that Server Core isn’t handling the unsigned drivers by giving the Print Management console information to prompt the user to confirm the installation of the driver, hence the driver fails to install.

To get around this issue, we can pre-install the required drivers from the command line of the Server Core machine, by passing a call to the PrintUI.dll (which luckily is still used for the Server Core printing engine) – You could also theoretically use the prndrvr.vbs file which can be found in %SYSTEMROOT%\System32\Printing_Admin_Scripts\en-us however it seems that it also cannot handle the prompting of the unsigned driver installation either, and because it only passes calls through to PrintUI.dll anyway, we may as well use it directly.

So create a directory called C:\Temp and copy your printer driver folder to this location on your Server Core machine.

Then, from the command prompt of your Server Core machine, use the following syntax…

start /w rundll32 PrintUI.dll,PrintUIEntry /ia /K /m “<driver name>” /h “<architecture>” /v 3 /f “<driver inf file>”

Here is a breakdown of the above command…

  • The start /w command will hold the command prompt until the command has finished;
  • rundll32 is the process we use to invoke PrintUI.dll;
  • ,PrintUIEntry tells rundll32 that we want to use this entry point in PrintUI.dll;
  • /ia tells the PrintUI.dll that we want to install a printer driver using an inf file;
  • /K (must be capital!) allows us to specificy a numerical value for /v;
  • /m is where you provide the name of the driver (in my case “Samsung CLX-3160 Series”) – You can get this by looking inside the inf file for your driver;
  • /h is where you provide the architecture for the driver, as “Windows NT x86” for 32-bit architecture, “x64” for 64-bit architecture and “IA64” for Itanium architecture;
  • /v specifies that the driver is used for Windows XP or later
  • /f is the location to the driver .inf file (which you should have copied to C:\Temp)

So for example, my command looked like this…

start /w rundll32 PrintUI.dll,PrintUIEntry /ia /K /m “Samsung CLX-3160 Series” /h “Windows NT x86” /v 3 /f “C:\Temp\Samsung CLX-3160 Series\driver\sugi1.inf”

After running this command, you get a red unsigned driver warning screen, which you can now accept to install the driver.

When you refresh the Drivers node in Print Management on your GUI machine, you’ll see your new driver listed. You can now go ahead and deploy your printer, however note that if you are running x64 of Server Core 2008 you’ll need to install the x64 driver before you can add the printer (otherwise you won’t be able to select your installed driver during the printer add process).

You can also delete the folders you copied in to C:\Temp now, because the drivers have been copied to their permanent location.

Tapeless Data Protection Manager 2007 Strategy

(If you’re wanting some info on deploying DPM 2007, I suggest reading this first…)

Microsoft’s System Center Data Protection Manager 2007 (DPM 2007) ideally should be installed on it’s own server, and connected to a tape drive or library for long term backups.

Without a tape library, if your DPM server dies, you can’t restore the data it’s been protecting because the configuration and database has the catalog information.

If long term backups isn’t part of your backup strategy, there is an alternative – dpmbackup.exe

The dpmbackup.exe tool is a command line option packaged with DPM 2007 that allows you to backup up the configuration and database out to a file which can be restored from the command line also. I’ve set up a scheduled task to run this command and to robocopy the data off to an external disk at a regular interval.

As my protection is between every 15 minutes (for Exchange) and every 1 hour (for other servers and data), I have very short term restore options available to me, from between 15 minutes and 5 days (my retention period), but I back up my DPM config every 8 hours. This means that if I was unlucky enough to lose my Exchange server and DPM server entirely in one go, theoretically 8 hours would be the oldest backup I’d need to restore from.

Here’s my very basic script…

dpmbackup -db
robocopy “C:\Program Files\Microsoft DPM\DPM\Volumes\ShadowCopy\Database Backups” “E:\DPM\DB” /E /COPYALL
robocopy “C:\Program Files\Microsoft DPM\DPM\Config” “E:\DPM\Config” /E /COPYALL

“The update could not be found” – Error When Trying to Re-install WSUS on Server 2008

I came across an unusual error when re-installing WSUS on one of my Server 2008 boxes.

Basically, I completely screwed an install of WSUS and it was just easier to rip it out and re-install it, because it was a downstream server anyway.

The uninstall went fine, but when I tried to re-install it, I got this error…

The update could not be found. Either the update is not applicable to this computer or the update no longer exists. Either the update is not applicable to this computer or the update no longer exists. Verify that the update still exists and applicable to this computer form your WSUS server or Windows Update. Verify that the update still exists and applicable to this computer form your WSUS server or Windows Update.

Turns out that because this server was using itself as it’s update server, it can’t re-install WSUS because it can’t check with the WSUS server for updates… Awesome.

It’s a relatively quick fix though – Just delete “HKLMSoftwarePoliciesMicrosoftWindowsWindowsUpdate”, restart the Windows Update service (wuauserv) and then you should be good to go.

EDIT: I’ve come across another (probably more common) scenario where this error occurs…

When installing the WSUS role for the first time, you need to either approve update KB940518 on an existing WSUS server in your environment, or just install it from Windows Update if you don’t already have a WSUS server – This makes the role available for installation on Windows Server 2008 machines.

KB940518 only adds the role to the available roles list in Server 2008, and does not contain the actual install files for WSUS. Therefore, if you have an existing WSUS in your organisation that your new potential WSUS server reports to, you need to ensure that you have selected Windows Server 2008 Server Manager – Windows Server Updates Services (WSUS) Dynamic Installer) (and ideally Windows Server 2008 Server Manager Dynamic Installer) under Products and Classifications, otherwise you’ll get the error above.

You could also delete the registry key I’ve mentioned above and then check for updates, but this will obviously go out to the internet to download the WSUS installation package, rather than from your existing WSUS server.

HINT: The C:\Windows\WindowsUpdate.log file contains logs for Server Manager when it attempts to search for updates for roles. These lines commonly include the string “[ClientId = Server Manager]”

Deploying Microsoft Data Protection Manager 2007

Microsoft Data Protection Manager 2007 (referred to as DPM) is part of the System Center collection of products from Microsoft.

DPM is agent based, and monitors changes on servers and keeps a copy of those changes available for a restore in the case of a disaster or deleted data.

It utilises Volume Shadow Services (VSS) and you have the option of storing the snapshots to disk (on the DPM server) or to a tape library.

I’m going to be talking specifically about the disk-based backups in this article, rather than tape backups. It is important to note that a seperate dynamic disk is required for DPM, which I’ll talk more about a bit later on.

Firstly you’ll need to get a server up and running for installing DPM on – I’ve installed mine on a Windows Server 2008, but Windows Server 2003 is obviously support also.

There are a few prerequisites for installing DPM, which the installer will let you know of if your system doesn’t comply. You can read up on these prerequisites here, if you’d prefer to before starting the installation.

Installing the DPM Server software is pretty straight forward – If there are any issues, they’re usually pretty clear on what needs to be done to finish the install successfully (such as missing prerequisites, etc.), although there are two things you’ll want to do after the installation…

  • If you’ve installed DPM on Windows Server 2008, you’ll probably have issues viewing the reporting tab, because of an “IIS connectivity issue” – I did a little bit of research and found that there is a bug with x64 (as far as I can tell, it doesn’t affect x86, but this could just be a lack of information out there) where the Reporting Services virtual directory in IIS doesn’t have script permissions, so you’ll need to set that (you can see the blog where I found this, here);
  • After DPM has been installed, you should install the DPM 2007 rollup update KB949779 which contains the latest features, and updated agent versions with greater feature support

Once you have the server software installed, you’ll need to add your disk, and you’ll need to deploy your agents to the machines you want to protect.

  1. To add your disk, click on the Management button across the top ribbon, and then click on the Disks tab;
  2. In the action menu on the right hand side, click on Add…
  3. The available disks are on the right hand side – If there are no disks in this list, then you don’t have a disk which is supported (if you’re looking to trial DPM in a non-production environment, I have a workaround you might like to try which I discuss at the end of this article);
  4. Add the disk you’d like and click OK – You’ll likely get a prompt that the disk needs to be converted to a dynamic disk in order for it to be utilised by DPM (unless it was already dynamic);
  5. When your settings are saved, you should see that the disk is available.

Now you need to deploy the agents out to the machines you want to protect.

  1. Click on the Agents tab (still under the Management button);
  2. In the action menu on the right hand side, click on Install…
  3. Select the machines and volumes you’d like to protect and follow the deployment wizard – Note: You should only select ONE domain controller the first time you deploy a DPM agent, as it will create DPM groups in Active Directory (in the absense of local groups). If you add more than one domain controller, you’ll likely get duplicate groups created and all sorts of issues;
  4. When you deploy agents, a few prerequisites are checked to make sure that the agent can be installed successfully. If any hotfixes or components are missing, they generally have to be installed manually before you can go back and try to deploy the agent again;
  5. Once the agents are deployed, they’ll need a reboot. You can do this as part of the deployment, or you can do it manually, but they will not appear as “OK” until this happens;
  6. You will also need to install Microsoft Hotfix KB940349 for DPM to be able to use VSS in the way required on each of the protect machines (not required for Windows Vista or Windows Server 2008);
  7. For Windows Server 2008 server, you need to install the Windows Server Backup feature to be able to back up the system state and you’ll need to install KB949779 on the DPM servers – You can install Windows Server Backup from the command line easily by running start /w ocsetup WindowsServerBackup (it’s case sensitive!);
  8. When all of the machines are rebooted, they should appear in DPM as “OK” under Agent Status and you should then be able to add them to a Protection Group.

If you’re deploying to Domain Controllers, you may run in to some issues with deploying them remotely. The issue I had was that it reported I didn’t have access to the ADMIN$ share on the Domain Controller I tried to deploy to, which I did. This can be caused if the time is not synchronised, but I ruled that out almost immediately. Some other issues you may have is with the replication of the groups, as some groups are created by DPM for managing access to the remote servers, and if these are created on more than one DC simultaneously, the objects will conflict on next replication cycle and you’ll have a whole bunch of duplicated groups.

The steps I followed were…

  1. In Active Directory, open the “Distributed COM Users” group under the “Builtin” container;
  2. Add the DPM server’s computer account to this group;
  3. Under the “Users” container, create two domain local security groups called “DPMRADCOMTrustedMachines” and “DPMRADmTrustedMachines”;
  4. Again, add the DPM server’s computer account to these groups;
  5. Run repadmin /syncall from the DC where you created the above groups (repadmin.exe is part of the Windows 2003 Support Tools) to force AD replication between it’s partners;
  6. On the DC, map a drive to the DPM server (such as X:);
  7. Open up the command prompt, and navigate to X:\Program Files\Microsoft DPM\DPM\Agents\RA\<version>\<arch> (where version is the agent version (just do a dir to see what’s available) and where “arch” is the architecture your system is running, such as x86, x64 etc.);
  8. Run DPMAgentServer.exe <DPMServer.Domain>;
  9. This will manually install the DPM agent on the DC;
  10. Back on the DPM server, try deploying the agent to the DC where you just manually installed the agent – It should see that an agent is already installed, and configure it correctly to bring it in to your managed agents. If you get an error, try restarting the DC before trying again;
  11. If you are successful, you’ll see the DC added as an agent, and it will say that a reboot is required;
  12. Reboot the DC and then refresh the agent info when it comes back.

You only have to perform these steps on the first DC you deploy the agent to – The remaining DCs you should be able to deploy to from the DPM console, but if you have trouble with a particular DC, you can try running through steps 6 – 12 on that particular DC.

When you have your agents deployed to the servers you want to protect, you can create a “Protection Group” which is available under the Protection button in the DPM console.

When you click on this button, you can select “Create protection group” from the right hand action menu and then just follow the wizard to create your protection group. The wizard is pretty self explanatory. I’m not going in to the details of protection groups in this article, so you’re out of luck if this is why you were reading, sorry.

I mentioned earlier that DPM requires a seperate dynamic disk for storing the snapshot data on. This is because it creates multiple logical volumes to organise the data. If you don’t have a supported disk, there is a low performance way around it, which is really only suitable for evaluation rather than a production solution.

The steps are…

  1. Create a blank VHD (Virtual Hard Disk) file using a Microsoft virtual product such as Hyper-V, Virtual Server, Virtual PC or a third party tool;
  2. Copy this VHD to a location on the disk you want to use with DPM;
  3. If you are using Windows Server 2003, you can use the VHDMount tool to mount the VHD file, and it will appear as a physical disk in Computer Management, which you can format and convert to a dynamic disk. If you are using Windows Server 2008, you can use a script which you can find here.

You can even do this on a USB or Firewire disk if you wanted to, which you normally wouldn’t be able to convert to a dynamic disk. You should also be aware that on restart, the VHD will be unmounted.

EDIT: As per Bill Ives’ comments on this topic (below), it appears that at least in some circumstances when running Windows Server 2003 and using the VHDMount utility, the disk will try to initialise every time it is unmounted, and then re-mounted, causing data loss. You should ensure that you test this in your environment to determine the behaviour of your VHD, before relying on it for restore. I’ll also re-iterate that using a VHD file should not be a method that you use in a production environment.

Migrating from Virtual Server 2005 to Windows Server 2008 with Hyper-V

I’ve recently migrated all of my Virtual Server 2005 machines to Windows Server 2008 with Hyper-V. The migration isn’t as smooth as it could be, but it’s not too difficult either.

Here are the steps that I took, keeping in mind that all of my guest operating systems are running Windows Server 2003 R2. I was going to take screenshots, but it’s been a long day.

  1. Firstly, you need to record the TCP/IP information from each of your VM’s to migrate, as you’ll need to reconfigure the NIC from scratch a bit later;
  2. When you’ve record the TCP/IP information, you should uninstall the Virtual Machine Additions from the guest operating systems – This is a fairly important step, as I’ll explain further on;
  3. Now you should shut down your guests to prepare for the migration;
  4. Using the Hyper-V Manager on your Windows Server 2008 machine, you should first configure the Hyper-V settings – You can do this by right clicking on the server in the Hyper-V Manager console, and clicking on Hyper-V Settings;
  5. I configured the Virtual Machines location to point to D:\Virtual Server, as the default is in an unusual location (like Virtual Server 2005);
  6. With your new path specified, you can create your first machine – On the right hand pane, click New -> Virtual Machine;
  7. Go through the options, naming your machine, allocating the appropriate RAM and assigning the NIC;
  8. When you get to the step to add a hard disk, select Attach a virtual hard disk later and then Finish;
  9. You should now have your machine visible in the Virtual Machines section;
  10. Use Explorer to open the location that you specified in step 5, and notice that Hyper-V has created a folder named “Virtual Machines” which contains a subfolder and an XML file with the same GUID (hexidecimal string) name;
  11. The XML file is the equivalent of the .vmc file from Virtual Server 2005 (where the machine configuration is stored), and the folder will be empty for now, but will be where the virtual machine’s running state (.vsv) will be stored;
  12. I recommend you create a folder underneath the D:\Virtual Server directory called Virtual Hard Disks and then create a subfolder for each of your machines under here – I copied the GUID name of the machine, to keep consistency;
  13. Locate your legacy Virtual Hard Disk (.vhd) file and copy it in to the appropriate Virtual Hard Disk subfolder;
  14. In the Hyper-V Manager console, right click on your machine and click Settings;
  15. Click on IDE Controller 0 and then click on Add on the right hand side, ensuring that Hard Drive is selected from the combo box above;
  16. Click on Browse and then locate your copied .vhd file;
  17. If you have additional disks, you can either add them on a virtual IDE controller, or a virtual SCSI controller (you need to add the SCSI controller via the Add Hardware option in the machine settings) – Note that Hyper-V does NOT support SCSI boot devices (I’m not sure why);
  18. Now you can start your VM by right clicking on it and selecting Start – Connect to the console by right clicking on it and selecting Connect;
  19. When it boots up and you log in, you’ll probably notice a few things – Firstly, if you are logged in via RDP you won’t be able to use the mouse to control the guest. This makes life pretty difficult, because of course your shortcut keys generally target to your local machine, or to your RDP window, depending on how you’ve configured your RDP client. This is why I recommend uninstall Virtual Machine Additions before moving your .vhd because navigating through Add/Remove is a bit tricky without a mouse and shortcut keys like ALT+TAB, etc… You should be able to follow the next steps without a mouse (note that if you need a mouse, you can either log on to the Hyper-V server locally, or you can install the Hyper-V Manager on a Vista machine, and if needed delegate access to remotely manage the machine – Third party remote server administration tools that don’t utilise the RDP protocol would likely work as well).
    The second thing you’ll probably notice, is that your machine is detecting new hardware – Escape out of these dialogues.
  20. Press CTRL+ALT+Left Arrow to lose focus to your virtual machine, and then click on Action -> Insert Integration Services Setup Disk (you can also just press CTRL+I);
  21. The setup disk will auto-run, and will ask you if you want to install the Integration Services – It will also prompt you to update the HAL;
  22. After you’ve confirmed the prompts and the tools are installed, your machine should reboot – When it comes back from a reboot, log in again and it should continue to install some more drivers – Note that you may also receive another “hardware detected” dialogue box which you’ll need to close before the drivers can finish installing (it seems to wait indefinitely otherwise);
  23. Your VM should reboot again, and at last you should have control of the mouse (I can’t remember if you get control in the last step, but you’ll definitely have it now);
  24. When you log in this time, you’ll probably notice that there’s a network error icon in the system tray complaining of limited connectivity – We need to remove the legacy NIC from Virtual Server 2005 before we configure the new NIC (well, we don’t need to, but Windows will complain that you’ve already allocated the IP if you use the same one);
  25. To remove this old NIC, run the following commands from the Command Prompt

    set devmgr_show_nonpresent_devices=1
    devmgmt.msc
  26. This will set a flag to allow devices that are not present to be displayed when hidden devices are unhidden in the Device Manager, and it will open Device Manager;
  27. In Device Manager, click on View -> Show hidden devices, and then expand Network Adapters;
  28. You should see your old NIC(s) which should be either a DEC 21140 or an Intel 21140 – Right click the NIC(s) and uninstall;
  29. Close Device Manager, and then run the following command to reset the non-present device flagset devmgr_show_nonpresent_devices=0
  30. Using the information recorded in step 1, reconfigure your TCP/IP configuration as normal.

That should be it – You should now have a machine happily living in your new Hyper-V environment.

(Nearly) All You Need to Know About Proxy Autoconfiguration, WPAD and PAC files

The principle behind the automatic configuration of proxy settings is obvious – To enable users to automatically obtain their proxy settings, without the requirement of having the manually configure their browser (or internet application) settings. There are other benefits, such as the ability to quickly update proxy information, as well as the ability to specify fail-over proxies, in the event that a primary proxy is not available, and I’ll go through those as well, but first…

PAC stands for Proxy Automic Configuration, and PAC files are the files that WPAD uses to pull down the proxy information. PAC files can be published via the WPAD protocol, or alternatively they can be manually configured in the browser by providing a path or URL to their location.

WPAD stands for Web Proxy Automatic Discovery, and is a method published by either DHCP, DNS or both in order to enable browsers to automatically detect the proxy settings required for the network that they are on.

PAC Files

I’ll begin with talking about PAC files, as that is where the proxy information is actually stored, and everything else is just the distribution method of your PAC files.

PAC files are written in the Javascript language. They primarily contain the following information…

  • The proxy server(s) to use
  • The port of the proxy server(s)
  • A list of sites or hosts that the proxy bypasses (the requests go directly out to the internet, without bypassing the proxy)

An example of a pretty basic PAC file, is this (don’t worry, I’ll break it down further)…

function FindProxyForURL(url, host)

{

if (isPlainHostName(host)) { return “DIRECT”; }

if (isInNet(host, “192.168.0.0”, “255.255.255.0”)) { return “DIRECT”; }

if (shExpMatch(host, “www.host.com”)) { return “DIRECT”; }

if (shExpMatch(url, “http://www.url.com*”)) { return “DIRECT”; }

return “PROXY proxy1:8080; PROXY proxy2:8080; DIRECT”;

}

This is a standard PAC file, that retrieves the URL or host that the user’s browser has accessed, and compares it to a list of exceptions to determine whether it will allow direct access to the internet, or whether it will pass the connection through a proxy server.

If the URL or host doesn’t match anything in the exclusion list, it will then pass the connection through the first proxy.

If the first proxy (proxy1) doesn’t respond on port 8080, it will try to pass the connection through the second proxy (proxy2) on port 8080, and if that also fails, it will then allow the connection to pass out through the internet directly, as it’s least preferred option. You do not need to allow the connection to pass through to the internet directly if the proxy servers don’t respond – In fact, if you do not specifically include it as a fallback option, the connection will instead time out and the user will not be able to establish their connection until a proxy server responds.

In case you’re having difficulty identifying what does what in my PAC file example, I’ll break it down a bit further…

function FindProxyForURL(url, host)

This line obtains the URL and host information from the browser, so that it has information to compare against it’s exception list – For example, if the user was trying to access Google, then http://www.google.com/ would be the URL and www.google.com would be the host.

if (isPlainHostName(host)) { return “DIRECT”; }

This essentially checks if this is a “single label” host, which means there are no full stops (periods). If a single label host can be resolved, it’s pretty much going to be internal (such as http://intranet for the URL or just intranet for the host. If the host fits these conditions, then the connection is not passed through the proxy – This is what the return “DIRECT” part of the line means.

if (isInNet(host, “192.168.0.0”, “255.255.255.0”)) { return “DIRECT”; }

This checks if the IP address of the host is on the internal network (assuming 192.168.0.0 – 192.168.0.255 is your internal network) and therefore also bypasses the proxy for this connection.

if shExpMatch(host, “www.host.com”)) { return “DIRECT”; }

This is a direct string comparison, and grabs the host variable specified earlier, and compares it against www.host.com – If it matches, then the connection bypasses the proxy.

if shExpMatch(url, “http://www.url.com*”)) [ return “DIRECT”; }

This is another direct string comparison, but ends in a wildcard (*) which means that if the URL begins with http://www.url.com then it bypasses the proxy.

return “PROXY proxy1:8080; PROXY proxy2:8080; DIRECT”;

This is where your preferred proxy servers are listed. The connection will try proxy1 on port 8080 first, proxy2 on port 8080 second, and then go out directly to the internet if the first two proxies gave no response.

PAC files can be called anything you want to call them, except if you are using the DNS WPAD implementation, in which case it MUST be called wpad.dat in lower case.

Publishing Your PAC File

There are essentially two ways to publish your PAC file – On a file system (network share, or local machine) or via HTTP (on a web server).

The file system method is pretty simple. Just copy the PAC file to the desired location. This could be the user’s local machine, or a file server.

If you are using the user’s local machine, then I would assume this would either be a temporary measure, or that you are deploying PAC files to each of the machines for a specific requirement. The more common file system method, would be to copy the PAC file up to a file server, and reference it via a network share.

In either of the file system based scenarios, you need to reference the PAC file by appending file://// to the beginning of the location, so a file stored in the user’s C: would become file:////C:/proxy.pac – Notice the use of forward slashes, rather than backslashes in the path. This isn’t specifically required, but makes sense.

The same is true for the PAC file hosted on a file server, in that the reference would be file:////SERVER/SHARE/proxy.pac

I have seen some cases where an extra fifth slash is required after file: particular in Firefox. You’ll need to find the right balance here, depending on what your application prefers.

If you’re using the HTTP method, you need a MIME type of application/x-ns-proxy-autoconfig for the file extension, which should either be .dat or .pac and then reference the file using the full URL, for example http://server/proxy.pac

Manually Configuring PAC Files In Your Browser

This method assumes a few things about your environment…

  • Your only have a few machines to manage, and manually configuring each one is no big deal; or
  • You have a method of managing the browser configuration, such as Group Policy AND your are confident there are no internet capable application outside of your management (or they don’t matter) AND your environment does not cater for external users roaming on your network (or it’s no big deal to configure these machines as they come on to your environment, and to de-configure them before they leave)

If you aren’t happy with these conditions, then the WPAD method (in the Deploying Automatic Configuration Using WPAD section) might be the way to go for you.

For the purpose of this article, I’m only going to go through Internet Explorer 7 (which is the same for Internet Explorer 6) and Firefox. Any other compatible applications will have a very similar configuration method.

Let’s start with Internet Explorer. Fire up IE, click on Tools -> Internet Options, go to the Connections tab and click on the LAN Settings button.

You should clear any previous proxy configuration from here, and then tick Use automatic configuration script and provide the path or URL to your PAC file in here (see the section above Publishing Your PAC File if you haven’t already). You should also ensure no other tick boxes are checked, such as the Automatically detect settings box, as this will slow things down (it will be looking for the WPAD implementation, and when it can’t find it, it will load your proxy script – There is a noticeable delay).

This is similar in Firefox. Click on Tools -> Options, click on the Advanced icon up the top, click the Network tab and then click the Settings button.

Clear any previous proxy information here, select the Automatic proxy configuration URL radio button and provide the path or URL to your PAC file in here (see the section above Publishing Your PAC File if you haven’t already).

As I mentioned before, you can manage these settings using Group Policy. For Internet Explorer, there are built-in configuration options in Group Policy, but in Firefox you need to rely on the use of third party tools, or alternatively an in-house developed option. There is a fantastic Firefox setting management add-on for Group Policy called FirefoxADM which can be downloaded from SourceForge at http://sourceforge.net/project/showfiles.php?group_id=129699

Deploying Automatic Configuration Using WPAD

As mentioned at the beginning of this article, you can publish your wpad.dat file using DNS and/or DHCP, although DHCP is probably the more preferred method because it is more flexible and is more easily distributed to your client machines than DNS is.

The DNS method requires the HTTP distribution of the wpad.dat file, and also requires that a CNAME alias record called wpad is created in the root domain in DNS and points to the web server that hosts your wpad.dat file. I’ll go in to specifics shortly.

The DHCP method is much more flexible, as it supports both the file system and HTTP based methods of wpad.dat distribution, and requires that you add an extra scope option to your DHCP server.

DNS

You need to have uploaded your wpad.dat (remember, lower casing for compatibility reasons) to an HTTP server and added the MIME type of application/x-ns-proxy-autoconfig for .dat file extensions. Also, it’s important that the file can be downloaded via the IP address, rather than the hostname (which means you CAN’T use host headers) because some applications actually resolve the host themselves, the then use the IP address to obtain the wpad.dat file from the server. Basically, if you can’t download http://<ipaddress>/wpad.dat, then you’re probably going to run in to issues.

If you can get to your wpad.dat this way, then you’re nearly there… The second requirement is that you need to manage your own DNS services internally, and you need to add a CNAME alias record called wpad which points to the hostname of your HTTP server where your wpad.dat file is stored. This CNAME record needs to exist in the domain that you have recorded in your client’s DNS suffix configuration on their NIC settings. If this doesn’t exist, you need to populate that information on the NIC settings to avoid problems. If you are on a Windows domain, this should already be configured.

From the clients, ensure you can ping browse to http://wpad/wpad.dat and download the file. If you can, then skip over the next DHCP section down to the part about browser configuration for WPAD.

DHCP

This is my preferred method, because…

  • It supports both file system and HTTP based hosting of the PAC file;
  • It supports custom ports;
  • It doesn’t require internally managed DNS;
  • It doesn’t require NIC settings modification to allow remote or misconfigured machines to resolve the WPAD DNS entry

To deploy your PAC file via DHCP, you need to add an extra scope option 252 to your DHCP scope. If you are using Windows 2003 DHCP, then you can following this article – http://www.microsoft.com/technet/isa/2004/help/SRSP1_H_Create252.mspx

If you’re running a different DHCP server, you need to ensure that it supports the addition of custom scope options. If it does, create the 252 option, and then add it to your scope populating the information with the location to your PAC file, but it’s important to add a trailing space to the location of your file, as there are some cases where the last character is truncated and therefore the PAC file is not loaded correctly.

You’ll need to renew the DHCP lease on the clients in order for them to obtain this information. Unfortunately, the only way to verify that your clients are receiving this information, is to use network capturing software, such as Microsoft’s NetMon, to monitor the DHCP lease negotiation.

Configuring the browser

The last step with the WPAD implementation, is just to ensure that the Automatically detect settings box is checked in the browser (called Auto-detect proxy settings for this network in Firefox).

You can do this by Group Policy, if that’s an option, or make the change for/advise your users.

Expanding System Disks in Virtual Server 2005 R2

If anyone’s ever under estimated the anticipated size of your system disk in Virtual Server (or any environment, really) you’ll know that it’s a little painful to resize the disk AND partition neatly.

In this blog, I’ve focussed specifically on Virtual Server 2005 R2, however the same principal applies to any environment that you may have. It covers the resizing of the physical (virtual) disk itself, and then the resizing of the system partition to occupy the extra available space that you have created.

For non-system disks, you can do this quite easily from within the Windows OS, however you obviously can’t do this from your system disk when you’re using it, in which case you can follow these steps…

  1. Download VHD Resizer from http://vmtoolkit.com/files/folders/converters/entry87.aspx and install it on your Virtual Server
  2. Download BartPE Builder from http://www.nu2.nu/pebuilder/ and install it on any machine
  3. Insert the original operating system install CD, or mount the ISO (in my case, it’s Windows 2003)
  4. Open the PE Builder, and say “No” to scanning for Windows source files (because we already know where they are)
  5. Point the source path to the root of the CD drive, set the output path to the location where you’d like the files to be copied (this directory can be removed once the ISO has been created) and set the media output to ISO and select where to save it.
  6. Hit the “Build” button, and continue through any warnings/license agreements
  7. You get quite a verbose output while the files are being copied, and the ISO is being created – You should want to make sure that there are no errors or warnings, otherwise your PE ISO may not boot
  8. Close and exit the PE Builder, and copy the created ISO up to a directory on your virtual server that has been configured as a search path (you can configure Search Paths from within the Virtual Server console, under “Server Properties” -> “Search paths”
  9. You can also delete the output directory, which in my case was C:\Program Files\PE Builder\Win2k3-PE
  10. Now it’s time to shut down the VM that has the system drive you need to resize
  11. With the VM shut down, make a copy of the VHD file you want to expand, which will be the file we will work with
  12. Open VHD Resizer, and point it to the copy of your system drive VHD
  13. Provide the desired location and name of your new VHD, select the new size and choose whether to create a dynamic or fixed disk – I called my new VHD “SYSTEM-new.vhd” because we want to leave the original “SYSTEM.vhd” as our backup
  14. Click on “resize” and wait for it to complete – It took about an hour and a bit to convert a fixed 8GB disk to a dynamic 20GB disk
  15. When it’s done, rename the original VHD file to put “-backup.vhd” at the end, such as “SYSTEM-backup.vhd” and then rename the newly resized VHD to the name of the original file – You can also delete the copy of the original VHD now (in my case “Copy of SYSTEM.vhd”)
  16. Now that the disk is been resized, we also need to expand the partition so that you can use the extra space, so configure the VM to mount the BartPE ISO, and then power the VM on (make sure your VM is configured to boot from CD before HDD)
  17. As we’re just going to resize the partition, there’s no need to boot with network support, so say “No” to any messages about network support
  18. Click GO -> System -> Storage -> DiskPart, to fire up DiskPart
  19. Perform the following commands…
    • Type “list volume” to get a list of the available volumes
    • Identify the volume you wish to extend and then type “select volume <volumenumber>”
    • Type “extend”
  20. Type “list volumes” again, to make sure it reports the new size
  21. Click GO -> Shutdown -> Shutdown
  22. Unmount the BartPE ISO
  23. Power your VM back up, and then view the disk details from within Disk Management to verify that your settings are correct – You may also be prompted to reboot as a system change may have been detected.