WSUS recommeded set up

I don't really understand the "splitt up". WSUS has the base functionality to offer updates, than you can confirm them to install and assign them to groups of clients.

As several systems have several needs, it is a good idea to build up some groups and to assign your machine to groups. This way you can confirm updates not only to differnt groups of computers, you can even control the behaviour, how they react.

A WIn7 Update you can assign to a WIn7 group, so that only such systems get the update and second you control when the update is assigned.

With some GPOs on the other side, you control the assignement und update process. For server a manual reboot is usually recommended while clients can take the updates and directly install them.

So, a separation happens on two levels, one separation of the machines in WSUS and a second one to devide the machines via GPOs to control the behaviour.

When you assing an update in WSUS, the next step is to control via GPO, when and how the update is instlaled and also if the computer is allowed to reboot automatically of only by hand.

Servers should usually not reboot automatically while clients usuall can. Any unexpected reboot may break funcrionality, at least for some time and should be controlled. Also GPOs allows to control, if the user can delay a reboot or if it is forced.

In WSUS you control via approval, which updates should be installed and also when they should be applied. As it is sometimes a good idea to wait some days, especially for servers, keep them speperate and apply only updates, you are sure they work as expected.

Also seperating groups of serves or clients reduce the need of checking ever update for every machine. Even if an update is limited to an OS or a service, if generally applied the client has to check, if it should be installed what produces overhead. Means an update for SQL server ou apply only to a comuter groups ehich contails computers with SQL installed.

Thanks, do you use scripts for the reboots?

NO, I just make sure via GPO's that servers never boot from alone. They just inform, that there are updates and I choose to install and then possibly reboot, when I can do it.

OK, this is some handwork to control it, but I prefer to controll myself when to reboot servers. Especially in virtualized environments (like mine), an uncontrolled reboot especially of the host systems can produce some strange effects. Even if too much machines installs and reboots in a short timeframes, the load on the system can extremely heavy.

For the clients, I setup via GPOs that the client can choose, if the machine should reboot. The user can deny, so it will happen with the regular shutdown.

Thanks I have 350 servers so not so good for manual. If possible can you send me the settings for your GPO. I really appreciate your help

Hi Bembi, this is the set up that my predecessor had set up with the tiers. I dont know why this had been set up like this. Is this something common to a typical WSUS set up?
Capture.PNG

Typical is the right word, the questions is more "senseful"

There are two parts as I said, the GPO, which determines usually the path to the WSUS, the reboot options (automatic / manual) and possibly the install time (+- the variance of intaller service).

The other part is the WSUS, while the WSUS can be similar organized like the GPOs.

You have a "test group" folder, possibly with some machines, to which the updates are applied first to isolate possible issues. The the servers are devided into several tiers, maybe there are also devided in the GPO structure to different times. Another options is devide them into critical and non critical machines, or even devided following a network infrastructure or host systems or other criterias.

I.e. if you have several servers, which are using a kind of failover configuration, it make sense to update them in two sequences, first the one, than the other.
Other reasons may be just load, to avoid that too many machines are updating / rebooting in a small timeframe on the same virtualisation host, on the same network or whatever.

To understand, why this seperation is made, you have to understand the GPOs behind it. To reduce handwork (to assign an update to several tiers at different times) GPOs can be used for every tier with a different install time, so you can apply the updates at once, but the installations happen at different times.

So, to say if it is senseful of not depends on all factors, your infrastructure, the WSUS with the machines in the different folders and the GPOs behind it. If you combine them together, you should be able to find out, what was the original idea behind the structure you have taken over.

But in general, if you have 350 servers, it makes absolutely sense to seperate them to avoid heavy load in a short time frame.
Maybe a map helps, indentify the servers and clients, the subnets they belong to, the virtual hosts they are running on and the GPO structure with the settings, the machines take.

Thanks for your detailed reply. I've checked the AD and i cant make sense of the WSUS Tiers as they are in a separate OU from the servers. Correct me if im wrong but if i had a Tier OU and applied the GP to that, i wold need to move the server into that OU. That means any that any policy that was on the server OU would be lost. What am i missing

thanks
ad.PNG

If you want to apply different GPOs to different server sets, you usually seperate them by different OUs and apply each policy to the according OU, so that the servers in one OU gets a differnt OU than servers in another OU. Tre other option is to use WMI filters to limit the GPO to servers which fits to the WMI filter (setup in the policy settings). But WMI filters are not the fastest and seperation via OU is better to keep the overview.

THe separation into several folders in WSUS make only sense if there is a kind of separation. Maybe you can check some of the servers just by policy resultset on the machines to find out, what policies they get.

Even you can check some of the install dates on the local machines, just pick out an older update and check, if the install date is the same or different.

If no GPOs are in effect, the seperation in WSUS can even make sense, but just a bit more handwork. YOu cann apply an update the first day to tier1, the sencond day to tier2 and so on, but handwork.

Maybe your predeccessor just had an idea for separation, but never finished it?
Or it is just struggled over the time as new servers came along and old ones were removed? Just a bit left over mess from the past?

If you can not get along what was the sense of the separation, you may define a new one and replace it. You can create new OUs with policies, new folders in WSUS and move the server from one OU to the other as well as from one WSUS forlder to the new one.
After moving, you can delete all the old stuff, at least this way you get it under your own control. Just be carefully as GPO structures can even be complicate, so use first some test machines an check the GPO results before you move production machines, just to make sure, you do not break something.  

O often have seen such ADs, where several changes are made over the time and all the old structures are left over and nobody took the time to clean it up.

That makes sense the work was carried out over 12 months ago and left as currently is. One last thing do you auto approve for clients. If so how do you treat the internet explorer updates, as some users need to stay on older IE version. Thanks again, very helpful

Sorry for my late reply. Thanks for your help much appreciate i will i could assign more points