Tag Archives: Slow WAN

by

Experience with Software Update Point and WSUS server over slow WAN


Hi guys, its been sometime since I posted something new 🙂

I received a question on whether to use System Center Update Point (SUP) or WSUS over the slow WAN network. Let’s say 1 Mbps.

From experience, I have encountered three different ways to deploy Windows Updates

  1. Deploy Windows Updates from one WSUS server location regardless of how many remote locations you have
  2. Deploy Windows Updates from one WSUS upstream server to multiple downstream servers in remote locations
  3. Deploy Windows Updates from System Center Configuration Manager 2012 R2.

We all know WSUS servers can be built on existing Windows Servers at no cost.
For System Center Configuration Manager 2012 R2, servers and clients will require licenses for management.
How do they fare differently?

  1. Deploy Windows Updates from one WSUS server location regardless of how many remote locations you have

    Reliability: 4 out of 5 (I never had issues with this, except all right, I admit, people complaining about the network being slow at times but I do send them emails to notify them ^__^;;)

    Pros:
    a. Single point of deployment
    b. Do not need to configure additional WSUS servers

    Cons:
    a. Do this and your network administrators will not be happy.
    Imagine deploying a 2GB worth of Windows Update files during working hours over 1Mbps. Even though the updates are distributed       to the computers via BITS so that network impact will not be significant. It takes a longer time to monitor the deployment to ensure         the Windows Updates are installed

    If you have 10 computers at the remote office with a network bandwidth of 1Mbps, you are going to have a hard time.
    You will be sending 2GB to each of the 10 computers. If you schedule to install at night, not all computers will download
    the Windows Updates as they may not be on or being hibernated.

  2. Deploy Windows Updates from one WSUS upstream server to multiple downstream servers in remote locations
    Reliability: 1 out of 5 (It synchronizes fine the first time, subsequent times I get synchronization failures and also download failures. Have to fix the WID a few times to get rid of the issue)

    Pros:
    a. Downstream servers will get a copy of the Windows Updates from the Upstream server. So computers can get their Windows Updates     from their respective downstream server.

    Cons:
    a. Connecting to upstream network and replicating the upstream server to the downstream server over slow WAN is a bad idea. I experienced Windows Update failed to download and also synchronize fully. I spent a few nights fixing this.

    Be sure to uncheck the This Server Is A Replica Of The Upstream Server  checkbox. This allows the downstream server to receive approvals but download from the Internet on the remote office’s end.

    b. Multiple server management. That means more group policies.

  3. Deploy Windows Updates from System Center Configuration Manager 2012 R2.
    Reliability: 4 out of 5 (You can choose to download, package, omit Windows Updates from deployment list after your Window Update test in test environment , something that WSUS doesn’t have. The cool feature is that you see only the updates you deployed , instead of having to go through the entire WSUS Windows Updates list. )

    Pros
    a. No need to install or configure additional WSUS servers on Secondary Sites (unless you are adding an additional SUP role to the distribute site server, the SUP will configure the WSUS server)

    b. Create collections with query and place computers in. In WSUS server, you will need to create computer groups manually and add     them in.

    c. System Center Configuration Manager 2012 has comprehensive reporting features. You can tell at a glance how many computers are required, installed and not installed per deployment. On WSUS you can only see a graph of how many computers requires this update.

    d. You can set a computer not to prompt a user to restart.