2

Can anyone suggest a tool/method to simulate various scenarios when using WSUS? Or am I asking the impossible? I'm curious to know if I deploy X number of patches over slow links is there any way of determining when all of the machines on the other end of the wire will be updated?

3 Answers 3

2

Virtual machines in a test environment that allows you to implement rate-limiting (to simulate various link speeds) is the best solution. But, as Andrew noted, there are considerable costs associated with this.

Another approach might be to simply break out your pencil and perform some back-of-the-napkin calculations. What's the link speed, how large is the set of patches, can they be multicast, how many machines on the remote end, and so on. Once you've considered these variables you might decide that it's simpler to deliver a single set of patches to a second WSUS server on the far end and move on with life.

Not knowing anything about how your network is engineered makes this a difficult question to answer concisely.

5
  • 1
    Thank you, I suspect a "napkin" design plan will be where I go. The number of clients out on the other end are few enough (90, 40, and 60 at three remote sites) for me not to have too much concern. I'm just looking to validate what I know from experience in similar environments.
    – Mitch
    Jun 13, 2009 at 18:43
  • You should add that info to your original post. Deploying a WSUS server at each site with 30 or more systems should be a standard policy. Anytime your site becomes large enough that the SA staff cannot patch all systems in a day, you should be using a patch management server. Jun 13, 2009 at 19:14
  • "Deploying a WSUS server at each site with 30 or more systems should be a standard policy" based on what? Is there a "suggested/recommended" clients per WSUS?
    – Mitch
    Jun 13, 2009 at 19:24
  • That's my own thought. I don't remember seeing a standard number of clients per WSUS ... his main concern is bandwidth, and the time needed to transfer patches over slow links ... Jun 13, 2009 at 19:40
  • A more concise way of putting what I was thinking :)
    – user1804
    Jun 14, 2009 at 14:31
0

If you're concerned about bandwidth and remote WSUS servers isn't an option, then you can also tune your BITS settings in a GPO for those sites; the clients may get the patches slower but better than not at all.

-2

Why have Virtual Machines become the knee-jerk reaction to administration problems?

VMs are not magic pixie dust to sprinkle over your problems.

You should figure out how long it takes to download a certain sized file over the link. Nice round numbers are convenient, let's make it 1GB.

  1. Time how long the upload/download takes (N)
  2. Time how long 2 upload/downloads take (N+1)

Make a guess.

In this case your deployment of WSUS is interesting, usually WSUS is deployed on the local end of a slow link. There are really only two reasons to deploy WSUS: management and bandwidth. Putting WSUS on the distant end of a link is really no different (bandwidth wise) from downloading all your patches from Microsoft. Every client has to access the same slow link.

Have you considered deploying another WSUS server at the local end of your link?

If this is a branch office, and you do not want/cannot deploy a WSUS server. Consider doing patches starting Friday evening and letting them roll throughout the weekend.

7
  • The "plan" calls for WSUS servers at each of six locations. I think that's overkill for the number clients supported. My thought is one WSUS for the lot, I'm certain the local sites will update with no issue. I just don't see that deploying a WSUS server for the small number of users, the satellite sites, is efficient.
    – Mitch
    Jun 13, 2009 at 19:22
  • 2
    I only read three sites in his comment. Is it too much to ask that each office has a domain controller and a WSUS? You can centralize email and some file servers, but logins and patch management should always be available. Have you had good results with a single WSUS, over slow links? Jun 13, 2009 at 19:45
  • Because virtual machines are great simulation tools, they are cheap (no need to get ESX crazy to run a simulation there are plenty of free VMs to do the job), and easy to use. so usually when somebody talk about simulating something Virtual Machines come in at the top of the list.
    – GNUix
    Jun 13, 2009 at 23:57
  • Well, it's hard to find a 'free VM' with XP or Vista installed. Every installation is an activation. I just assume, in all my answers, OP doesn't have VLKs. Jun 14, 2009 at 0:30
  • "VMs are not magic pixie dust to sprinkle over your problems." Nice invective. I didn't answer the question naively, this seemed like an appropriate response to this problem. The OP mentioned "simulate", now unless we get into some truly interesting programming to simlulate some windows machines and patchy networks, why not use the standard solution, a virtual one?
    – user1804
    Jun 14, 2009 at 14:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .