Storing WSUS Content On A Remote Drive (HOWTO)

Show Menu

Introduction

WSUS will only allow the content to be hosted on a local NTFS partition, and prevents administrators from hosting the content files (which can be very large) on a network share, or mapped network drive. In situations where disk space on the WSUS server is limited, but there is a large fileserver available on the network, it may be desirable to store the content files on the fileserver.

This guide shows how to store the WSUS content files on a partition hosted on a seperate fileserver running linux, using the iSCSI protocol. This creates what appears to be a local disk under windows explorer, but is actually a network connected storage location (NAS). This is treated like a local disk, and the WSUS content is permitted to be stored on it.

This guide assumes that you have a currently functional WSUS installation and wish to migrate the content to a new location with room for expansion. Other requirements include a linux based server with adequate free (unallocated) disk space or an iSCSI NAS. If you are using an iSCSI NAS, jump to step 2.

Warning

By storing content on a network attached drive, network traffic will be doubled (since the data must be transfered from the iSCSI target host to the WSUS host, before being distributed to the client). This may degrade network performance, so consider your situation. Additional resource demands on the fileserver must also be considered, as the iSCSI commands must be interpreted at both ends, in addition to the data transfer.

This is a completely unsupported configuration, and you will probably not recieve any assistance from Microsoft if you configure your server in this manner.

How To...

1. Set up the iSCSI target on the Linux fileserver

The first step is to create the iSCSI target for us to work with. The target is the physical (or virtual) drive on which the data will reside. You will need to have a partition ready to use which is at least large enough to hold the existing content, and you will most probably want more space available for expansion. This example uses /dev/evms/wsus as the target partition.

a) Install the iSCSI Target software

This is a different process for each linux distribution, so you're on your own. The software chosen was iSCSItarget, which is available from http://iscsitarget.sourceforge.net/ . This requires kernel 2.6.14 or later, and may require some kernel reconfiguration/recompilation. More detail on how to install can be found here: http://iscsitarget.sourceforge.net/wiki/index.php/HowToInstall . Alternative iSCSI target software may be used, but you're also on your own there.

b) Configure the Target

Edit the configuration file for IETD, which is typically /etc/ietd.conf, and configure as appropriate (see: man ietd.conf). Make sure you set the path correctly. (eg: Lun 0 Path=/dev/evms/wsus,Type=fileio )

c) Start the target daemon

run: /etc/init.d/ietd start

This should insert the kernel module for you, and then start the daemon. Check dmesg, you should see some lines similar to:

iSCSI Enterprise Target Software - version 0.4.13
iotype_init(90) register fileio
iotype_init(90) register nullio
sess_param(173) 0 1 1 8192 8192 262144 65536 2 20 1 1 1 0 1 1

You will want to set up the appropriate rc scripts so that the daemon starts whenever the system is booted.

2. Install the Microsoft iSCSI Initiator software

Download and install the MS iSCSI Initiator from http://www.microsoft.com/windowsserver2003/technologies/storage/iscsi/msfiSCSI.mspx

The default installation options worked for me.

3. Connect the iSCSI drive

Start the MS iSCSI initiator program and configure the node name and CHAP password (if you set one).

Go to the "Discovery" tab and then click the "Add" button in the Target Portals section. Enter the IP address or dns name of the linux server, then click on the Advanced buttons and check the settings and parameters there. If you set a password, you will need to enable "CHAP logon information" option, and configure that section appropriately.

Then move to the "Targets" tab and click Refresh. Select the target we created and click "log on". Tick the box for "Automatically restore this connection when the system boots" and then click OK.

Move to the "Persistent Targets" tab and ensure that our iSCSI device is set as a persistent connection. We will need the initiator program again in the next step, so leave it open for now.

4. Initialise and format the disk

Open the Disk Management Console (start -> run "diskmgmt.msc"). The Initialise disk wizard will probably open automatically, but we want to double check that we are initialising the appropriate disk, so cancel out of the wizard. Right click on the new disk and select Properties. Ensure that this disk is labeled "IET VIRTUAL-DISK", and not some other physical disk in your server. If everything is correct, right click on the disk and then choose initialise and go through the wizard. Once the disk is initialised, format the disk with NTFS, and assign it a drive letter (i chose W:). A quick format is probably all that is needed, and a full format could take quite some time).

Next, we go back to the MS iSCSI initiator and go to the "Bound Volumes/Devices" tab. Here, we want to set it up so that our partition is always mounted before the WSUS service needs it. Clicking "Bind All" should fill the box in with the drive we used (W:), ensuring its availability on boot. We are now finished with the initator, so you can close it.

5. Migrate the WSUS Content

The next stage is to move over the WSUS content, and then redirect the WSUS service to look in the new location. Fortunately, there is already a tool written which does just that for us.

Open a command prompt and navigate to the WSUS tools directory (by default: C:\Program Files\Update Services\Tools). From here run:

wsusutil movecontent W:\wsus C:\wsusmove.log

Where W:\wsus is the target directory (which must exist already. A subfolder is created inside this target directory called "WsusContent", in which the content files are stored), and C:\wsusmove.log is the log file for the operation. This may take a while, depending on the amount of content to be copied.

6. Verify correct operation

When the WSUS service restarts after the content migration operation, it will re-set the state of file downloads and needs to re-process all of the content files to ensure that they are all present. The "Updates needing files" counter on the WSUS administration page should decrease fairly rapidly as the already downloaded files are scanned and verified.

The simplest way to verify that the content store has infact been moved to the new location is to approve a new (not-already downloaded) update, and see where the content file is placed. If it goes to the new iSCSI drive, then all is good.

Additionally, it would be appropriate to test to see if updates are delivered to clients properly. A simple way to do this (if there aren't any clients requiring patching) is to open up the %windir%\windowsupdate.log logfile on a client computer and find a previous BITS download job which will look like:

2006-06-14 14:18:17 1404 90 DnldMgr * BITS job initialized, JobId = {F2B53332-456E-4FFD-A3F6-FDEA91AA0097}
2006-06-14 14:18:17 1404 90 DnldMgr * Downloading from http://wsusserver:8530/Content/E3/B88D8576A3A533A62EE3BC2CF86909D7D0DFB0E3.exe to C:\WINDOWS\SoftwareDistribution\Download\S-1-5-18\a4ff98ebdfdcbfc1752bf9ecddec7ee7\b88d8576a3a533a62ee3bc2cf86909d7d0dfb0e3 (full file).

By inserting the URL into a web browser or download manager, you can check to see if the updates are downloadable by clients (the download should start successfully without any errors).

7. Remove the original WSUS Content Store

Once correct operation of the new content location has been verified, it should be safe to remove the original content store from the disk. Simply navigate to the original location (by default: C:\WSUS\ )and delete the "WsusContent" folder. Be careful not to remove any other directories which may be present, such as the MSSQL instance which holds the database.

Last Modified 6/28/06 3:53 AM