Back Up a Certificate Authority in Windows Server 2008

Here are 2 manual methods to easily back up a Certificate Authority in Windows server 2008. The first method uses the ‘certutil’ utility from the command line. Simply open ‘cmd’ and type the following, where C:\CA_BACKUP is the path which you want to save the backup to:

certutil -backup C:\CA_BACKUP

You will see something like the output shown here:

Using the certutil -backup command

Notice that you are required to enter a password for the backup file in order to keep your CA data secure. Your backup files will now be found in the location you specified.

The second method uses the ‘Certificate Authority’ console. Using this method open the ‘Certificate Authority’ console and then right click on your CA and choose ‘All Tasks’ and then ‘Backup CA’ as shown:

Choosing 'Back up CA'

The first page of the Certificate Authority Backup Wizard is displayed, click ‘Next’:

The CA Backup Wizard

Choose which items you wish to back up, and then choose a location for your backup, then click ‘Next’:

Choose a backup location

Provide a password for the backup, and click ‘Next’:

Provide a password for your backup

Click ‘Finish’ complete the wizard and make your backup:

Complete the CA backup Wizard

As mentioned earlier these are manual methods for backing just the Certificate Authority data on a CA machine. You can always use schedule full system state backups using wbadmin, or your chosen third party backup tool, which will also backup this information.

Advertisements

Set deadline for windows update installation in WSUS

In certain circumstances, when using WSUS (Windows Server Update Services) in your environment, you may wish to deploy a critical Windows update sooner than your scheduled installation window. Personally, I would excercise extreme caution using this setting due to the gotchas outlined at the end of this post.  However, this can easily be achieved by setting a deadline for installation when you approve the update or updates. In the WSUS console simply select the update or updates, and then right click them and choose ‘Approve …’ as shown.

Approving an update in the WSUS console

Once the ‘Approve Updates’ screen opens, choose which group of computers you want to approve the update for. In this case I have chosen ‘All Computers’, and then  ‘Approved for Install’. Next right click the ‘All Computers’ group again and choose ‘Deadline’ and then ‘Custom’ as shown:

Set a custom deadline for installation of an update in the WSUS console

The ‘Choose Deadline’ screen opens. Choose the date and time that you want the update or updates to be installed at, as shown:

Choose the date and time for your deadline

Thats it, your update will now be installed at the time that you have set. There are a couple gotchas using this setting that it is worth being aware of. Firstly if the update with the deadline requires a restart, the computer will reboot after installation regardless of what the user is doing at the time. It is therefore probably best to avoid deadline times in the middle of the working day when users may suddenly find their computers reboot with little or no warning causing them to lose work. Secondly, a deadline will override the ‘No auto-restart with logged on users for scheduled automatic updates installations’ Group Policy setting, so again be careful if you have this GPO setting enabled, as you may not expect your computers to reboot, but they will in this case.

References:

http://technet.microsoft.com/en-us/library/dd939923(WS.10).aspx

Force KCC (Knowledge Consistency Checker) to run on a domain controller

Sometimes after demoting domain controllers you may be left with inconsistent NTDS connection objects in Active directory. In my case there was an NTDS connection object listed under one of the domain controllers at our central site which referenced a recently demoted domain controller at a remote site. I needed an NTDS connection object pointing pointing to the newly installed DC at the remote site instead. To fix this i simply deleted the incorrect NTDS connection object in the ‘Sites and Services’ console, from the central site domain controller, and then forced KCC to run on the same domain controller by running:

repadmin /kcc

This forces the domain controller that you run the command on to check its inbound replication topology immediately and generate any missing connections. After running this command a new NTDS connection object was generated from the new DC at the remote site. This can either be verified by checking under the Domain Controllers NTDS Settings, in the ‘Sites and Services’ Console or by running:

repadmin /showrepl

tftp timeout on PXE boot when using WDS

I came across a peculiar problem today when trying to PXE boot a client computer on a newly commissioned Windows 2008 WDS server. This server had been commissioned in exactly the same way as all of our other WDS servers, but the client refused to boot the wim image that we had published in the WDS server. We recieved the message ‘tftp timeout’. We could tell that the client machine was picking up an IP address ok from the DHCP server, it seemed though, that it was unable to download the wim image file from the WDS server. We turned on WDS client logging and increased the logging level using the following 2 commands:

WDSUTIL /Set-Server /WDSClientLogging /Enabled:Yes

WDSUTIL /Set-Server /WDSClientLogging /LoggingLevel:info

Further information on enabling logging for Windows Deployment Services can be found here. After doing so we could see event: 4101 Source: Deployment-Services-Diagnostics stating ‘The following client failed tftp download’ as shown below:

Event ID: 4101 Source: Deployment-Services-Diagnostics

In this particular scenario we had WDS, DHCP and DNS installed on the same server. After a bit of digging we found the following Microsoft KB article (KB977512). It turns out when you have DNS and WDS installed on the same server there is the potential for DNS to grab the entire port range that WDS uses for tftp, preventing clients from connecting. The workaround is to increase the size of the port range on the WDS server so that it is larger that the range that is used for DNS. To do this you need to open the Windows Deployment Services console and right click on the affected server and choose properties. Once in the properties screen amend the UDP port range in the ‘Network Settings’ tab to 50000 to 65000 as shown below:

Amend the UDP port range in WDS Network settings

Click OK and you’re done. It also turns out that this problem has been fixed in Windows Server 2008 R2, which is why we hadn’t experienced this on our other WDS servers.

Move a file share to a new server using Robocopy

Robocopy is a command line tool that has been around for years, but is still really useful today. It is part of the Windows Server Resource Kit Tools. You will need to install these in order to use the robocopy command. Essentially it is a tool for copying files from one location to another, but with some significant extra advantages over the standard xcopy command. The main advantages that I can see are these:

  • The ability to copy NTFS permissions, if you want to
  • The ability to skip files that have been copied previously, provided that they have not changed

For the reasons above it is still ideal for using when you want to quickly migrate the contents of a file share to a new server. To do this first set up the new file share on the new destination server, making sure the share and NTFS permissions match those that are configured on the old share on the old server.

Next enter the following command in a new batch file, where OLDSERVER is the old file server name, and OLDSHARE is the old share name, and NEWSERVER is the new server name and NEWSHARE is the new share name:

robocopy “\\OLDSERVER\OLDSHARE\” “\\NEWSERVER\NEWSHARE” /S /E /COPY:DATS

The command basically tells robocopy to copy the contents from the UNC path of the old share, to the UNC path of the new share. The /S and /E tell robocopy to copy any subdirectories, and empty directories. In this example the /COPY:DATS tells robocopy to copy the Data, Attributes, Timestamps and Security information. There are a couple of other elements that you can also copy if you want. To copy everything use /COPY:DATSOU or alternatively /COPYALL. Here is a list of all the flags you can use with the /COPY: part of the command:

D – Data

A – Attributes

T – Timestamps

S – Security i.e. NTFS permissions

O – Owner information

U – Auditing information

The beauty of this solution is that you can run this script during the day, when users are on the system to do the initial copy which depending on how much data is in the share could take a while (that said, this is obviously not a good idea if you are copying the contents to a remote server over a slow WAN link). Then out of hours you can run the script again, but this time it will only copy any files which have changed since the last copy making the copy process a lot quicker. Then all you need to do is change the path for any drive mappings you have in your login script, or group policy preferences, to point to the new file share on the new server. When your users come in the following day, they will will be blissfully unaware that the data has been relocated.

Robocopy has other uses too, and various other options check the help information for more details using:

robocopy /?  

Event ID 5153 Source WAS after IIS install on a Windows Server 2008 DC

I ran into this issue today while installing WSUS components on a new branch office Windows Server 2008 Domain Controller. After installing the WSUS role I spotted a warning in the event log as follows:

Event 5153 Source WAS

This error occurs when you promote a Windows 2008 Server to become a domain controller in a domain that is lower than 2008 functional level, and the server is also running IIS. Fortunately, this is documented in Microsoft KB 946139 and the fix is simple.

Copy and past the text for the script given in the KB article into notepad and save the file as samupgrade.js. Then from the command line run:

cscript samupgrade.js

The output is shown below:

Sam Upgrade Task Output

Reboot the server and you’re done