fxsupport
asked on
How do I properly set up GPOs for WSUS 3.0?
Quick rundown of the network:
Two Windows 2003 (Standard) domains with a two-way trust (no forest)
Users are in OUs per department.
Computers are in OUs per type (Laptop / PC / Server)
On Domain A, I just set up a new server with WSUS 3.0.
I've been reading up on WSUS via the Guide to Getting Started with WSUS 3.0 and Best Practices with WSUS 3.0 @ Microsoft, as well as reading up on other sites. We're somewhat unclear where to place the GPOs for users / computers. The answers to the following questions will hopefully help clear this up for us.
WSUS GPO -> Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update -> Specify intranet Microsoft update service location
As recommended, this is enabled with the URL to the WSUS server (http://<WSUS server name>)
Questions are primarily about:
WSUS GPO -> ... -> Windows Update -> Enable client-side targeting
Quote:Originally Posted by Microsoft Documentation
This policy enables client computers to add themselves to target computer groups on the WSUS server, when Automatic Updates is redirected to a WSUS server.
In the WSUS console -> Update Services -> <server name> -> Computers, we've set up 4 computer groups (Domain A - Computers (same for laptops and PCs), Domain A - Servers, and the same for Domain B). Domain B computers are in there because an early test showed that they get pulled in, but more about that later.
QUESTIONS:
1. So, when the afforementioned policy wants computer groups, it wants one (or more) of the computer groups set up in WSUS, correct?
2. Would the best practice for the afforementioned configuration mean setting up a GPO for each OU that we want in the same WSUS computer group? e.g. WSUS GPO 1 for the Laptop and Computer OUs, and WSUS GPO 2 for the Server OU. Thought process behind this is that it's best to install updates / reboot on the servers with less automation (don't want to reboot in the middle of something important).
3. Also, does a GPO have to be placed on a user OU at all? I don't think so, but not 100% sure.
Now, as a curveball, we have some programmer users here (already in their own OU of course). Our plan for them is a policy that has them grab updates from the local WSUS server, but they can choose what to install and reboot by their own discretion.
4. Would it be necessary to create a new OU for the programmers' computers?
5. Has anyone ever used a WSUS server on one domain for administering updates for a second domain via a trust between the two? As mentioned earlier, an earlier test showed that Domain B's computers started to show up in the WSUS server on Domain A. My guess is that we'd have to set up GPOs on Domain B that point to http://<WSUS server name>, and that SHOULD work???
6. Any comments / suggestions on the set up so far?
As a side note, this server will also host our internal ticket / inventory system (Spiceworks baby!)
Two Windows 2003 (Standard) domains with a two-way trust (no forest)
Users are in OUs per department.
Computers are in OUs per type (Laptop / PC / Server)
On Domain A, I just set up a new server with WSUS 3.0.
I've been reading up on WSUS via the Guide to Getting Started with WSUS 3.0 and Best Practices with WSUS 3.0 @ Microsoft, as well as reading up on other sites. We're somewhat unclear where to place the GPOs for users / computers. The answers to the following questions will hopefully help clear this up for us.
WSUS GPO -> Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update -> Specify intranet Microsoft update service location
As recommended, this is enabled with the URL to the WSUS server (http://<WSUS server name>)
Questions are primarily about:
WSUS GPO -> ... -> Windows Update -> Enable client-side targeting
Quote:Originally Posted by Microsoft Documentation
This policy enables client computers to add themselves to target computer groups on the WSUS server, when Automatic Updates is redirected to a WSUS server.
In the WSUS console -> Update Services -> <server name> -> Computers, we've set up 4 computer groups (Domain A - Computers (same for laptops and PCs), Domain A - Servers, and the same for Domain B). Domain B computers are in there because an early test showed that they get pulled in, but more about that later.
QUESTIONS:
1. So, when the afforementioned policy wants computer groups, it wants one (or more) of the computer groups set up in WSUS, correct?
2. Would the best practice for the afforementioned configuration mean setting up a GPO for each OU that we want in the same WSUS computer group? e.g. WSUS GPO 1 for the Laptop and Computer OUs, and WSUS GPO 2 for the Server OU. Thought process behind this is that it's best to install updates / reboot on the servers with less automation (don't want to reboot in the middle of something important).
3. Also, does a GPO have to be placed on a user OU at all? I don't think so, but not 100% sure.
Now, as a curveball, we have some programmer users here (already in their own OU of course). Our plan for them is a policy that has them grab updates from the local WSUS server, but they can choose what to install and reboot by their own discretion.
4. Would it be necessary to create a new OU for the programmers' computers?
5. Has anyone ever used a WSUS server on one domain for administering updates for a second domain via a trust between the two? As mentioned earlier, an earlier test showed that Domain B's computers started to show up in the WSUS server on Domain A. My guess is that we'd have to set up GPOs on Domain B that point to http://<WSUS server name>, and that SHOULD work???
6. Any comments / suggestions on the set up so far?
As a side note, this server will also host our internal ticket / inventory system (Spiceworks baby!)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Ok, so we were on the right track then, good to know. Now we've just gotta compare the old disabled WSUS GPO (from before my time here) and the one I've set up, and that should do it. I'll post an update when it's completely done so that future readers can be fully informed.