Udostępnij za pośrednictwem

ConfigMgr Software Updates on an Isolated Network

  • Artykuł

The Windows Server Update Services (WSUS) 3 Deployment Guide documents a process by which update metadata and update content can be transferred from one server to another isolated server.  Since Configuration Manager 2007 relies upon WSUS for the software update plumbing, a similar process can be used to transfer updates to an isolated network for ConfigMgr.

First, some definitions:

  • Isolated network: no Internet connectivity.  There is a physical or logical "air gap" between the isolated network and a network that has access to the Internet.  This is common in high-security or test lab environments.
  • Update metadata: the details of the updates (KB, Severity, Supercedence, etc.) that is stored in a SQL database.
  • Update content: the bits (.exe, .cab, .msu) that clients run to install the update.  These are stored by WSUS in a folder called WsusContent.  The files are named by their SHA1 hash and then stored in subfolders corresponding to the last two characters of the hash.  E.g., KB935840 (MS07-31) Security Update for Windows Server 2003/Windows XP x64 is a 901 KB executable file from 1 June 2007 that is saved on the WSUS server at D:\WSUS\WsusContent\00\8D0F195FC2024DAC3EF2A19289F3932789C2FF00.exe.

The following is a brief overview of the entire process:

  • DEV-WSUS-01 is an Internet-connected server running WSUS 3 that synchronizes the update metadata and downloads the update content from Microsoft Updates.
  • The update metadata is exported and the recently downloaded update content is copied to a staging area, where it can then be copied to removeable media for transfer across the air gap.
  • PROD-WSUS-01 is an isolated server running WSUS 3 and specified as the ConfigMgr active Software Update Point (SUP).
  • The update content is copied from the removeable media to PROD-WSUS-01 and the update metadata is imported into the WSUS database.
  • PROD-SCCM-01 is an isolated server running ConfigMgr 2007.  The update metadata is synchronized from the WSUS database to the ConfigMgr Update Repository.
  • ConfigMgr clients scan against the available software update metadata and report any required updates.
  • An update list is created of any required updates.
  • An update package is created from the update list, pulling update content from \\PROD-WSUS-01\WsusContent.
  • An update management is created from the update list to deploy the updates in the update package to the specified collection.
  • The rest of the process is then the same for any typical ConfigMgr software update deployment.

Now let's look at the details of this process.

I've provided a script, InstallWsus.cmd, that handles the prerequisites (IIS, .NET 2, Report Viewer 2005) for Windows Server 2003 x86 platform, and then, given the name of the SQL server and instance, silently installs WSUS.  Using this script ensures that WSUS is installed the same on the two servers (Internet-connected and isolated networks).  It does assume SQL is installed already (local or remote).

When configuring the Internet-connected server, the following settings are important:

  • Synchronize from Microsoft Update: ConfigMgr must get its updates from Microsoft Updates, not via an upstream server.
  • Products/Classifications: after the first synchronization (which will update the list of those currently available), customize these as required by the isolated environment.
  • Store update files locally on this server: we want to use WSUS to download the bits.  Ensure the option Download update files to this server only when updates are approved is checked (enabled).  Also ensure the option Download express installation files is unchecked (disabled) as this feature is incompatible with ConfigMgr Software Update Management.
  • Languages: configure the languages are required by the isolated environment.  This setting must be identical between the Internet-connected and isolated WSUS servers.
  • Default Automatic Approval Rule: enable and alter the default rule to approve updates for all computers when an update is in any classification.  This will cause the WSUS server to automatically download the update content after synchronization.

I hope it's obvious but I'll mention that DEV-WSUS-01 needs enough disk space to store the update content for the selected products, classifications and languages.  This can quickly grow to hundreds of gigabytes depending upon the how many options are selected.

It's also important to note that this WSUS server is not intended to support any clients, its sole purpose in life is to suck down content for transfer to the isolated network.  I don't recommend the automatic approval setting on a WSUS server supporting production systems, it's used here to automate the download of update content.  Also keep in mind the timing of the synchronizations, as it will start downloading content right away, which will affect your Internet bandwidth.

The following is a rough summary of the process that can be used each month (or on whatever desired interval) to synchronize the update metadata, download the update content and export both for transfer.

  • Synchronize the WSUS server with Microsoft Updates.  With the above settings it will then automatically download the update content.
  • Manually approve all updates that do not automatically approve due to EULA requirements.  In the Update Services console, you can display all Unapproved updates, select all and then Approve them.
  • Monitor the update content download in the Update Services console (the server home page shows the status).
  • I've provided a PowerShell script, SpanWsusContent.ps1, that scans the WsusContent folder for files with the archive bit set, copies them in 4 GB chunks to a given path, and then clears the archive bit.  The outcome is a series of "Disk#" folders that are about 4GB in size which can be easily burned to DVD for transfer.  By using the archive bit on the files, the next time update content is downloaded from Microsoft Updates, this script will only copy the new content, which will result in a significantly smaller quantity of data to transfer.  The first transfer will be the full content, but each subsequent transfer will only be the deltas.
  • I've provided a simple batch script, WsusMetadataExport.cmd, to run the WsusUtil tool to export the update metadata from the WSUS database.  I use the script for consistency, especially with export file names (to avoid confusion each month).  (NOTE: There's probably a better way to script this, especially with the kludgy datetime stamp, but I'll save that for another rainy day.)
  • Copy the exported update metadata CAB file in with the update content so that it can be easily copied to removeable media (I shoot for the last Disk# folder which typically has available space).
  • I then recommend copying this content to a staging area, but some might see this as an extra, unnecessary step.
  • Now the exported update metadata and delta update content is ready to be transferred across the air gap using whatever process you have defined.

I also recommend a quick spot check by noting the Size (in bytes) and number of Files in the entire WsusContent directory.  This can be used as a quick check that the content is the same between WSUS servers.

The isolated WSUS server should be installed using the same InstallWsus.cmd script (or similar) for consistency. The rough summary of the process on the isolated WSUS server is as follows:

  • I also recommend using a staging area on the isolated network, but again it may be unnecessary in your environment.
  • Copy the update metadata CAB file to PROD-WSUS-01 for import into the WSUS database.
  • Copy the update content to the WSUS server (merging with the existing content).  I use the following command for this task:
    robocopy \\PROD-SERVER-02\WsusStaging\<YYYYMMDD>\Disk#\WSUS\WsusContent \\PROD-WSUS-01\WsusContent /e
  • Now is a good time to verify the Size and number of Files in the WsusContent against what is on the Internet-connected server.
  • I have a similar batch script, WsusMetadataImport.cmd, to run WsusUtil to import the update metadata CAB file.
  • Wait; it can take several hours for the server to import the metadata and (more importantly) validate the new content.

The WSUS server should be configured in ConfigMgr as the active Software Update Point (SUP) role.  ConfigMgr takes control of the WSUS service; configuration via the Update Services console is unnecessary.  The following settings on the SUP need to be configured:

  • Select the option Do not synchronize... which supports the import method in use.
  • By selecting this option you will be unable to configure Classifications and Products.  This is expected and ok.
  • Configure the Languages identically as on the Internet-connected WSUS server.
  • No additional settings are necessary, and no configuration is required in the Update Services console; let ConfigMgr configure the SUP (WSUS) server.

The following is the rough process to use the updates in ConfigMgr:

  • Right-click the Update Repository and Run Synchronization to synchronize the update metadata from the WSUS database to the ConfigMgr database.  Open D:\Program Files\Microsoft Configuration Manager\Logs\wsyncmgr.log in Trace32 to monitor the progress.
  • Once all systems have scanned against the new update metadata and reported status, create an Update List based upon the Required updates.  When creating the update list, do not check Download the files associated with the selected software updates.
  • Right-click the Update List and select Download Software Updates to create the Update Package.  A few screens into the wizard, select Download software update from a location on the local network and enter \\PROD-WSUS-01\WsusContent as the path.  If you've done everything correctly, ConfigMgr will automagically find the imported content and provision it into your Update Package at the package source you provided earlier in the wizard.
    • This is a crucial step where the rubber meets the road.  If you get errors it could be for a variety of reasons: the content was transferred incorrectly or improperly, the update content is invalid or corrupt, etc.  Also check out KB938759 for an update to Windows Server 2003 for handling large, signed files (e.g., service pack updates).
  • Finally, right-click the Update List and select Deploy Software Updates and proceed through the DSUW.  Assuming your update package is ok, the rest of the process is per normal.  If you're prompted to download update content, that means that your Update Package doesn't have the content for all of the updates included in the Update List that you're trying to deploy.

I included a PDF diagram that depicts the data flows for both the update metadata and the update content as a way to visual the above process.

The attached archive includes all of the scripts and diagrams referenced in this post.

I'm always looking for ways to streamline and improve this so please let me know if you have any suggestions, comments or additions.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use .

ConfigMgr Software Updates on an Isolated Network.zip

Comments

  • Anonymous
    March 21, 2013
    The comment has been removed
  • Anonymous
    September 25, 2014
    Hi. In a situation like this do you recommend EVER using the WSUS Cleanup Wizard to clean expired updates and the like on the disconnected side? My own testing has caused all of the updates to be deleted from the WSUSContent folder as they are not "approved". Of course they aren't meant to be as they are merely there to be downloadable from SCCM.
  • Anonymous
    September 28, 2014
    How to install windows updates in isolated environments? (WSUS or Configuration Manager)
    All required