System Update Point Synchronization

This blog will explain how Software Update Point synchronization work, the difference of manual and scheduled sync and why use active and non-active Software Update Points.


Manual Sync & Scheduled Sync

There’re two ways in Configuration Manager 2007 to start synchronization.

  • From Site Management->Site->Site Settings->Component Configuration, launch Software Update Point Component Properties->Sync Schedule Page, you can set the synchronization to start at a scheduled time.
  • From Computer Management->Software Updates->Update Repository, click “Run Synchronization” at the Actions bar. (I refer this as Manual sync here).

For manual sync, it will do “delta sync” from the WSUS Server. It will not sync expired/superseded/declined/interactive updates and it will only sync updates changed since last synchronization time. The last synchronization time is store in the site control file. If the time is empty (e.g., you just enabled a Software Update Point), it will do a “full sync” as described below.

For scheduled sync, it will do a “full sync” from the WSUS Server. It will sync all updates without filter.

For bundle updates, we’ll try to sync all its child updates first. If its child update also has updates, it will sync the child updates first (depth first)

You can tell from the wsyncmgr.log, whether it does “delta sync” or a “full sync”:

  • “Delta sync” Syncing updates arrived after 3/29/2011 7:44:37 PM
  • “Full sync” Syncing all updates


How Synchronization works in a hierarchy

When you enable Software Update Point in a hierarchy, you can only set the SUP of the Central Site to sync from live Microsoft Update. The SUPs of the child sites can only sync from its upstream update server. And you will not have the option to configure scheduled sync or start a manual sync from the child sites’ SUPs. Child sites’ SUPs will signaled by Central site’s SUP to start a sync. The process is like below:

  1. User starts a manual sync or a scheduled sync on Central Site’s SUP.
  2. Central Site’s SUP will configure the WSUS Server to sync from live Microsoft Update.
  3. Central Site’s SUP will sync the data from WSUS Server to Configuration Manager Database.
  4. Central Site’s SUP will send sync notification to its child sites.
  5. Child Site’s SUP will wake up by the notification and configure its WSUS Server to sync from its upstream WSUS Server. (only metadata, no content will be synced)

Child Site’s SUP WILL NOT sync the data from its WSUS Server to its Database. The updates and deployment objects are synced to Child sites through objects replication. Clients of Child sites will do scan against the Child sites’ WSUS server but get content from the Distribution Point.

All of the above process can be monitored in wsyncmgr.log.

On Central Site’s SUP:

Performing sync on local request SMS_WSUS_SYNC_MANAGER 3/29/2011 9:49:52 PM 6060 (0x17AC)

Synchronizing SMS database with WSUS server SCCMVM00592 SMS_WSUS_SYNC_MANAGER 3/29/2011 9:49:53 PM 6060 (0x17AC)

sync: Starting SMS database synchronization SMS_WSUS_SYNC_MANAGER 3/29/2011 9:49:53 PM 4832 (0x12E0)

Syncing updates arrived after 3/29/2011 7:44:37 PM SMS_WSUS_SYNC_MANAGER 3/29/2011 9:49:53 PM 4832 (0x12E0)

Done synchronizing SMS with WSUS Server SMS_WSUS_SYNC_MANAGER 3/29/2011 9:50:14 PM 4832 (0x12E0)

Sending sync notification to child site(s): 90U SMS_WSUS_SYNC_MANAGER 3/29/2011 9:50:15 PM 6060 (0x17AC)

On Child Site’s SUP:

Found parent sync notification file WEB.SYN. SMS_WSUS_SYNC_MANAGER 3/29/2011 7:50:08 PM 4780 (0x12AC)

Performing sync on parent request SMS_WSUS_SYNC_MANAGER 3/29/2011 7:50:08 PM 4780 (0x12AC)

Synchronizing WSUS server SCCMVM00444 SMS_WSUS_SYNC_MANAGER 3/29/2011 7:50:09 PM 4780 (0x12AC)

sync: Starting WSUS synchronization SMS_WSUS_SYNC_MANAGER 3/29/2011 7:50:09 PM 7164 (0x1BFC)

Successfully synced site with parent WEB, version 2 SMS_WSUS_SYNC_MANAGER 3/29/2011 9:51:17 PM 4780 (0x12AC)


Active Software Update Point vs non-Active Software Update Points

One site can have several Software Update Point, but it can only have one Active Software Update Point.

Clients will only use Active Software Update Point to retrieve the update catalog and EULA info; non-Active Software Update Points are just there for NLB.

Some references/guidelines on when to have NLB: shows the scalability of WSUS Server: A WSUS server that is using the recommended hardware can support a maximum number of 15K clients by using a default detection cycle of 22 hours. with the release of System Center Configuration Manager 2007 R3, the scalability is now up to 300K clients per hierarchy.