This isn't my first rodeo when it comes to WSUS, but I am finding that it is almost easier to just lump all computers in one group then to try to sort through the updates for specific groups. What do you think?

For example, I have several groups (winsvr2k8x64, winsvr2k8x86, win7x64, etc.) however some updates will say for x86 based computers, and some will say 32bit computers, and the filtering criteria does not allow for a "and name contains" + "and name does not contain". It only allows for and, or.

31 Replies

You do not have to group computers that way. It knows what needs to go where.

Groups are for applyign update policies to so you can control the release.

As a basic example 3 groups: Test, Workstations, Servers.

Workstations we set the policy to auto download and shedule for 3pm so the users are forced to turn off or reboot before they leave.

Servers are left at download and ask.

Test is where we test updates before applying them to the others.

I hesitated for a while because I could not get manual grouping to actually apply any kind of policy and I had not researched the effect of OUs (which we use to apply the policies). Now that I realice you can have machine OUs independant of the user OUs and we are small enough that we don't need machine based OUs for any other purpose it is fairly easy to set up the policy using the GPO editor. The help on doing so is easy to find but I, and probably many others would be happy to elaborate.

1st Post

Been using WSUS for several years. I just have a single group for all our machines (W2k8, W2k3, W7, W-Vista, WinXP, W2k, 64bit, 32bit), and use Group Policy to push the updates. Works fine. Only ever had a couple of minor issues which I posted on MS's WSUS forum and which were immediately resolved.

Im the same as Mark, I do have issues with it though most of them are that I just dont have time to even look at it. When I came to my network all the machines had been poorly imaged with no sysprep etc. So WSUS sees an entire room as one machine. At some point Ill sit down and sort it out, buts it definitely a you get out what you put kinda thing.

The trick with that is to make your sysprep and have the unnatend.xml give it a name you would not use on the domain and set it up for a workgroup,. Then, when you image to a new machine you name it as you add it to the domain. It's a tiny extra step but it does save a swathe of possible WSUS and DHCP issues.

If you already have machines with the issue then it would take some time bet peobably the best thign would be to come up with a new naming convention with no overlap. Take each machine off the domain via its local computer properties. Remove it from active directory and then re-add it using the new convention. It's a pain bit a one off. There may be a way to automate it from a list of IP addresses.

I was a bit more anal and separated out Workstations into location and OS type, (ie. Bldg 2 - Win 7 x64) and the same with servers. As noted above that's not necessary, but I like the granularity and organization it gives me.

Who knows - SOME day, I might actually want to only roll out a particular update to half of my old XP machines and leave the others without it. I figure this way I've at least got the option.

Bodestone theres a reg key that needs changing, Ive got a .bat file with it somewere ill try and dig it out. But it deletes the key that holds the registration with wsus, the rest of the scipt the forces it to reconnect to wsus. Its much quicker than renaming all your machines. Lol still havent found the time to run it on all the effected though.

I too use GP to control update times / functions. I really wanted some better control over my machines in terms of WSUS, so I created the extra groups. Additionally, it gave me quick easy reporting on my machines, however now I am using System Center Essentials, and the reporting is different anyhow.

I think before next week I might just do the Workstations, Servers, & test.

We basically use 2 groups - desktops and servers. Group policy setting on those OUs tell the computers what to do with the update. Desktops are set to download and install the update (and reboot if necessary), servers are set to download only.

I was a bit more anal and separated out Workstations into location and OS type, (ie. Bldg 2 - Win 7 x64) and the same with servers. As noted above that's not necessary, but I like the granularity and organization it gives me.

Who knows - SOME day, I might actually want to only roll out a particular update to half of my old XP machines and leave the others without it. I figure this way I've at least got the option.

Sounds like your are creating your own pain. Creating more groups because you might need them some way wastes time now instead of someday when you actually need to.

I generally recommend three basic computer groups above the default of unassigned: Servers, Workstations, and a sub group of workstations update test. Additional groups should be created if there are sensitive groups, like accounting, or geographic areas where large approval groups could cause bandwidth issues.

Several software groups can be beneficial aswell.

Long story short, as soon as you have more than 5 PCs and having unapproved updates is not palatable WSUS is the way to go.

You do not have to group computers that way. It knows what needs to go where.

Groups are for applyign update policies to so you can control the release.

As a basic example 3 groups: Test, Workstations, Servers.

Workstations we set the policy to auto download and shedule for 3pm so the users are forced to turn off or reboot before they leave.

Servers are left at download and ask.

Test is where we test updates before applying them to the others.

I hesitated for a while because I could not get manual grouping to actually apply any kind of policy and I had not researched the effect of OUs (which we use to apply the policies). Now that I realice you can have machine OUs independant of the user OUs and we are small enough that we don't need machine based OUs for any other purpose it is fairly easy to set up the policy using the GPO editor. The help on doing so is easy to find but I, and probably many others would be happy to elaborate.

So completely agree with Bodestone here.. Especially the download at 3pm and forcing the users via GPO to default to 'install and shut down' and force them to do so when they go home for the day. WSUS itself, without a GPO I think could be a pain, but as soon as you set up a few policies you'll never have to walk around the buildings again manually installing updates! Its one of the few good programs M$ put out.

WSUS is easy as everyone has said. Create your WSUS groups using GP and then these will then populate in WSUS and away you go. We have severe and critical updates apply automatically to both servers and workstations and if that update then needs a restart set the install and restart scheduling in GP so that the servers go down on the weekend and workstations reboot around lunch time when people are generally not using them.

Doing this we would have only ever had a handful of troublesome updates and those were mainly in virtual machines when the host went down before the update finished (was using vmware server at the time but we now user Hyper-V with fail over and haven't had that problem since)

If you use Microsoft Forefront then you can have WSUS download and update all your clients with the latest virus definition files automatically as well. Additionally you can also use Local Update Publisher which hooks into WSUS and allows you to deploy third part programmes and updates like flash, reader and java using your WSUS setup.

I have been working with WSUS since the first release and have found it to be one of the easiest and most stable Microsoft products i have ever used. At a minimum I would create 3 groups - Test, Servers, and Workstations. With GPO's you can then control every aspect of the patching process.

@WarezWolf I'm curious as well. I've NEVER had to reinstall WSUS. Now are you having to reinstall the OS b/c the trial version of the server software has expired. Sorry I couldn't resist the play on your name. :)

I find it completely unreliable and budget a once every month or two to reinstall it.

..puts finger down throat....

Absolutely agree with Andrew and Scadd I really wanna know why it's giving you such an issue!! Post your problems we'll get it fixed for you. I had ONE issue once with WSUS when I was trying to deploy a custom MSI and the probelm was my MSI package not WSUS.... It's NEVER been anything but a godsend! Let us give you a hand.. (Sorry didn't mean to speak for Andrew and Scadd :))

1st Post

Been using WSUS for about 1 1/2 yrs. with no problems. Basically just have a production and a test group. We don't use it for servers. Oh and we don't use it for OS service packs. Used SUS before also with very few issues.