Transitioning from an Exchange 2003 to an Exchange 2007 environment

There is no shortage of information out there on transitioning from Exchange 2000 or Exchange 2003 to an Exchange 2007 environment, although when performing the transition myself I found myself relying upon multiple resources to get the job done. Specifically, one of the things that was a problem for me was the fact that there is no real process to “upgrade” to Exchange 2007 retaining your old server name (a problem for third party issues SSL certificates).

I’ve run through the transition in a lab environment three times to capture all of the required steps (and hopefully the most common transitioning problems) in order to create a guide on performing this in your own environment.

There are a few assumptions with this guide (you can factor in any differences pretty easily):

  • This is an Exchange 2003 on Windows Server 2003 to Exchange 2007 on Windows Server 2008 transition process
  • This is a single server exchange environment transitioning to another single server environment
  • The environment uses RPC/HTTPS (now called Outlook Anywhere) for all client access

This guide will also include a transition from your legacy Exchange 2003 environment, to a temporary Exchange  2007 server, and then a migration from that temporary server to a new Exchange 2007 server of the same name as your legacy Exchange 2003 server. A quick summary:

  • Existing Exchange 2003 server (I will refer to this as the legacy server) migrating to…
  • Temporary Exchange 2007 server (I will refer to this as the temporary server) migrating to…
  • New Exchange 2007 server (I will refer to this as the new server) and that’s the end of the line

So let’s get started…

  • Export your SSL certificate (if you have a trusted third party issued certificate) from the legacy server to a .pfx file and copy this .pfx file to a file share to be accessible at the end of the transition
  • Ensure that the account to perform the transition is a Domain Administrator and a Schema Admin
  • Ensure that the legacy server has at least Exchange 2003 SP2 applied
  • Ensure that the schema master domain controller, and any global catalog servers in the same site as the Exchange server have at least Windows 2003 SP1 applied
  • Ensure that the domain functional level is Windows Server 2000 native or higher
  • Add the following registry key to the legacy server

HKLM\SYSTEM\CurrentControlSet\Services\RESvc\Parameters\SuppressStateChanges = 1 (DWORD)

  • Provision the temporary server using Windows Server 2008 and join to the domain
  • Install Windows Powershell, Remote Server Administration Tools (RSAT) and issue the following commands to install IIS dependencies dependencies:

ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-Dyn-Compression
ServerManagerCmd -i Web-Stat-Compression
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Windows-Auth
ServerManagerCmd -i Web-Digest-Auth

  • Install the Exchange Best Practices Analyzer (ExBPA) on any server that has an internet connection and access to the domain controllers, and run an Exchange 2007 readiness check to determine if there are any warnings or recommendations
  • Run setup.com /PrepareAD from the Exchange 2007 install media (make sure to “Run as Administrator” if UAC is turned on)
  • Install Exchange 2007 on the temporary server as a “Typical Exchange Server Installation” and select the legacy Exchange server when prompted for mail flow settings (make sure to “Run as Administrator” if UAC is turned on)
  • Using the Exchange Management Console (EMC) on the temporary server, migrate all mailboxes using the “Recipient Configuration | Mailbox” menu
  • Remove all mailbox databases from the legacy server
  • Ensure that the new mailbox databases are configured to use the new public folder database as their default
  • Migrate all public folder replicas by running moveallreplicas.ps1 –server <legacyserver> -newserver <temporaryserver> from the temporary server
  • Wait for all of the records under the “Public Folder Instances” node in the public folder database in ESM to disappear on the legacy server (this can take a while, sometimes days to complete depending on the amount of data)
  • Using Exchange Server Manager (ESM) on the legacy server, create a new “Public Folder Container” directly under the new Exchange 2007 administrative group
  • Drag the existing “Public Folders” tree under the “Folders” tree in the new administrative group
  • Remove the public folder store from the legacy server, selecting the temporary server’s public folder database when prompted for a new store
  • Remove all storage groups from the legacy server
  • Remove the routing group connectors that were created during the Exchange 2007 install, using ESM on the legacy server, under both the legacy and the new administrative groups
  • Delete the domain and enterprise Recipient Update Services (RUS) object using adsiedit.msc
  • Uninstall Exchange 2003 from the legacy server
  • Using adsiedit.msc on the temporary server, delete the legacy administrative group
  • Delete the legacy Exchange Domain Servers and Exchange Enterprise Servers groups (if they aren’t being used for other custom purposes in your environment)
  • If the legacy server is being entirely decommissioned, remove it from the domain and shut it down
  • Provision the new server using Windows Server 2008 and join to the domain
  • Install Windows Powershell and the IIS dependencies as per the temporary server build
  • Install Exchange 2007 on the new server as a “Typical Exchange Server Installation”
  • Install the latest Exchange 2007 updates, including service packs and update rollups (this is important) and then restart the server
  • Rename the storage group and mailbox databases as desired
  • Configure the location for the storage group and mailbox database as desired
  • Create a new public folder database with the desired name and location
  • Migrate all mailboxes from the temporary server to the new server using the “Recipient Configuration | Mailbox” menu
  • Remove the mailbox database(s) from the temporary server
  • Change the default public folder database on the mailbox database(s) on the new server to be the new public folder database (it’s under the “Client Settings” tab of the mailbox database properties)
  • Move all offline address book by running Move-OfflineAddressBook -identity “\<oabname>” -server <newserver> -confirm:$false
  • From the temporary server, move all public folder replicas to the new server by running moveallreplicas.ps1 –server <temporaryserver> -newserver <newserver>
  • Monitor the status of the replica move by running Get-PublicFolderStatistics -server <temporaryserver> until no items are returned, or you can append | Measure-Object -Line to count the number of lines returned to monitor the public folders moving (this can take hours, days or weeks depending on the amount of data)
  • Remove the public folder database from the temporary server
  • Remove Exchange 2007 from the temporary server, remove the server from the domain and shut down
  • Create a new wildcard (*) send connector using the “Organization Configuration | Hub Transport” menu
  • Configure the “Default <servername>” receive connector to allow “Anonymous users” to connect using the “Server Configuration | Hub Transport” menu
  • Copy the exported .pfx file from earlier and use the “Server Certificates” option on the parent node in IIS7 to import the certificate
  • Change the certificate used by OWA by selecting the Default Web Site, clicking the “Bindings” menu on the right hand side, and editing “https”
  • Select the imported certificate from the drop-down box and save settings
  • Install the “RPC over HTTP Proxy” feature
  • Enable Outlook Anywhere using the “Server Configuration | Client Access” menu in EMC on the new server, right clicking on the server and selecting “Enable Outlook Anywhere”
  • Allow 15 minutes before testing (check the event logs for event ID 3006 which indicates that Outlook Anywhere is configured)
  • Edit the hosts file to comment out the IPv6 localhost line (::1) and add the following lines

127.0.0.1 <hostname>
127.0.0.1 <hostname.domain>

  • Restart the new server and test the connection

I have a fairly complicated environment regarding permissions, address lists and the like, so I found that I had to go through and make sure that my showInAddressBook attributes were set correctly on all of my mailboxes (the address lists were fine, but the global address lists were not). This may not be an issue in your environment, but feel free to drop me a line if you’re having issues.

COM Surrogate errors in Windows 7 x64 after installing Adobe CS4

I’m running the latest official beta of Windows 7 (build 7000) x64 and have been getting a whole bunch of these errors…

Runtime Error!
Program C:\Windows\SysWOW64\DLLHost.exe

This application has requested the Runtime to terminate it in an unusual way.

Generally, it happens when opening the Control Panel, but it can happen when doing other things that are obviously enumerating items from the Control Panel, such as Mobile Device Center or opening the Network and Sharing Center.

Turns out that it’s due to Adobe CS4 (not sure about CS3) being installed, as the VersionCue .cpl file doesn’t play nicely with Windows 7 x64.

I was able to work around this issue by renaming the VersionCueCS4.cpl file to VersionCueCS4.old in the C:\Program Files (x86)\Common Files\Adobe\Adobe Version Cue CS4\Server\bin\ directory.

No more COM Surrogate errors!

Error When Trying to Demote a Windows Server 2008 Domain Controller via the Command Line

If you’ve deployed a Windows Server 2008 core install running AD DS, you’ll be familiar with the promotion process. If you’ve ever demoted a Domain Controller from the command line, you may have come across an issue which makes your heart skip a beat (the last thing you want is for a Domain Controller promotion or demotion operation to fail, because you never know what you’re going to be left with). It’s actually a pretty easy “fix” which is handy to know before you try going crazy in adsiedit or anything like that.

The error can occur while the demotion process is attempting to stop the NETLOGON service, however the stop request times out, you get a message indicating that the operation has completed, but then an error on the next immediate line and your demotion stops.

Stopping service NETLOGON

……………………………………..
The attempted domain controller operation has completed
Failed to configure the service NETLOGON as requested

When I first did this, I figured that the dcpromo process would be aware of the last failure, and retry, which is sort of the case except you get the following error

The wizard cannot access the list of domains in the forest. The error is: the interface is unknown.

Another error which sounds particularly ominous, but it’s not. During the first demotion attempt, the demotion failed because either the NETLOGON service didn’t stop in time, or didn’t return the success code to the stop request, however by the time you run the second demotion the service has stopped. The demotion isn’t going to work with the NETLOGON service stopped.

The solution is as simple as just starting the NETLOGON service again by typing “net start netlogon” from the command, and then retrying your demotion. The dcpromo will pick up from where it was before, and nearly always complete successfully this time around.

Unrealistically Fast (or Negative) Ping Responses in Server 2003 Hyper-V Guests

I came across an interesting problem the other day while I was doing some unrelated troubleshooting on one of my Hyper-V guests.

The symptoms were that my Windows Server 2003 machine would return very strange results when pinging hosts, both internally and externally, such as returning all four responses within about half a second, yet measuring them at over 3000ms (which means they should have timed out, rather than given me a reading in milliseconds) as well as occasionally providing negative values for response times.

Obviously the results were completely inaccurate, but I couldn’t work out why the issue was only happening on a handful (not all) Hyper-V guests running Windows Server 2003 and none on Server 2008.

Turns out that this is an issue if all of the following are true:

  • You are running an operating system prior to Windows Vista or Windows Server 2008
  • You are running the current implementation of Microsoft Hyper-V (i.e. at the time of writing)
  • You have presented multiple processors to the Hyper-V guest

The issue occurs because the multiprocessor HAL in Hyper-V causes the guest’s operating system Time Stamp Counter (TSC) to skew. According to this blog the problem wouldn’t ordinarily occur if you were running Windows Server 2003 with SP2 unless the BIOS check fails to determine if the TSC should be used. More specifically, if I understand correctly the issue occurs because the processors (or cores, if we’re talking about a single multicore processor) are not in sync with each other, which produces sporadic out-of-time results where time sensitive operations (such as ping responses) are in use.

The resolution is to force the guest to use the PM timer instead of the TSC, by adding /USEPMTIMER in the boot.ini file and then restart. You can easily test this by running a ping -t to a host and checking for drastically abnormal results.

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.