WSUS setup for servers vs end-user pc's. RRS feed

  • Question

  • Our Server group just finished building a WSUS for their servers to get updates. I told them that I would like our everyday end-user computers (mobile, laptop and desktop units) to also hit that WSUS during MDT. This would mean that the end-user computers would get different updates than their servers would, talking to the same WSUS.

    They're informing me that this would require a separate WSUS server for us than their servers. I'm guessing "I" am going to be tasked with providing "them" with instructions on how to set up their server to do this. Is there a simple way to configure this? I'm reading that they can incorporate our AD GPO's, already in place, for our client pc's to use as the rules to follow for what updates we get. I see in MDT that I can specify the WSUS server AND the target group in the CS.INI file.

    If I can provide, at least, some official MS documentation that they can read, follow and implement, I'd jump on that. Since I won't be having to build or maintain this, I'm not wanting to invest all of my time in research.
    Any info on multiple-group targets getting different updates would be awesome. Basically we'd need two groups: Client end group and server group.

    Friday, March 9, 2018 9:53 PM

All replies

  • For my purposes, in MDT, I would modify the CS.INI as:


    TargetGroup=name of client pc's group

    I'm guessing this would tell our client-end computers to use the specified WSUS.
    However, I'm not sure of the best way to have all of our computers, other then servers, get the correct updates applied to them. Thus the reason for my post.
    Somehow they can use AD GPO already in place to define what pc's belong to this target group.

    Friday, March 9, 2018 9:53 PM
  • You don't have to have different WSUS servers, you can different computer groups. That how our University runs their one WSUS server for all the different schools. We have our own group for the School of Law and then just ask them to approve things like 1709 when we were ready to let it start rolling out to our clients.

    Managing WSUS Client computers and WSUS computer Groups

    Daniel Vega

    Friday, March 9, 2018 10:06 PM
  • Great! So is my CS.INI correct above? Just reference the WSUS and also the Target Group in the INI?
    I'm hoping that is all I need to do on my end, in MDT.
    Saturday, March 10, 2018 2:12 AM
  • Well that's not a built-in variable (unless they added it recently), so looks like you also need to modify ZTIWindowsUpdate.wsf

    Add WSUS Target Group option to MDT deployments

    Be sure to document your changes, because when a new MDT version comes out and that file is replaced, your custom change will be broken and you might forget why.

    Daniel Vega

    Monday, March 12, 2018 1:23 PM
  • According to the link, you do add "Properties=TargetGroup" to the CS.INI

    I see that in addition, the ZTI file must be updated as well. Must I reference the "name" of the target group in the ZTI, or only in the TS?

    Monday, March 12, 2018 2:09 PM
  • Use customsettings if you want all your task sequences to put machines in the same target group.

    Do not use customsettings but rather add the variable to each TS if you want to specify different target groups based on which task sequence you run.

    Daniel Vega

    Monday, March 12, 2018 2:13 PM
  • Maybe I'm looking at this from the opposite end...
    I was understanding that our AD group would have our client computers in a specific group. I would add in my CS file, the name of that group, so that ALL computers we clone will get updates for that group. That is the goal. Every computer we clone in our IT dept will get the same updates, different from what their servers get.
    I thought the client computers we clone would be in one group already, and I would just be able to reference that target group name in my INI, and they'd get the appropriate updates. You're suggesting I have to 'move' the pc's in AD using the ZTI?
    Monday, March 12, 2018 2:18 PM
  • This is what I understand so far...

    Every computer we image will get the same updates. So in my CS file, I can reference Properties=Target Group

    Then, I can name the group, TargetGroup=whatever
    The 'whatever' is the name of the group of ALL computers we image.

    At that point, does the AD group need to create a group, with that name, and move our computers into it on the WSUS? I believe I know what I have to do in MDT....give Properties=TargetGroup that link and name the group:
    TargetGroup=whatever.....what has to happen on the WSUS side? I will not be working on the WSUS, our Server Group will. All they say is that we need a separate server for our Clients (everything but their servers).
    I recommended making a 'group' which contains all Client computers so that I can reference that in the pc's in that group get the designated updates.
    Does this sound correct? If so, what do they need to configure in WSUS to create the Client group of pc's we will be cloning?

    Monday, March 12, 2018 2:29 PM
  • If all the client computers were already in a target group then there would be no need to tell MDT where to put them.

    What MDT does, with the change referenced in the link, is tell the newly imaged machine to be a part of that WSUS target group so that it only gets the updates approved for that target group. Nothing more.

    Daniel Vega

    Monday, March 12, 2018 2:31 PM
  • Ok. So all the Server Group needs to do is create a group of updates in WSUS that are specific for one group. In my CS, I name that group (TargetGroup=xxxx) and the pc will get updates from just that group.

    The Server guys don't need to do anything with AD computer names specifically then? Just put the updates in a group, I point to that group merely by adding it in my CS? That would be very easy to do.

    Monday, March 12, 2018 2:35 PM
  • If you are referring to the OU that a client computer joins, that is different from the WSUS target group. 

    Essentially the target group needs to exist ahead of time in WSUS. Then as machines are imaged, they will be added to the target group. You will still need to specify an OU if you were doing that before and the OU does not need to share the same name as the target group.

    Daniel Vega

    Monday, March 12, 2018 2:51 PM
  • I'm lost in the specifics...which just gets me riled up since we have a Server Group in place already.

    On the WSUS, a 'group' needs to be created. In MDT, I reference that group in my CS. Does that alone get the updates for that group? Or does WSUS have to have every single computer on our domain in that group? What exactly tells one computer to get updates from one specific target group? I sound and feel stupid since this all is brand new to me. I was hoping to just set up MDT for this but I have to "tell" my Server Group how to do their end of this...step by step.
    Does the target group define computers hitting the WSUS or does it define the group of updates? I may just throw all the web links at them and tell them to research it all.

    Monday, March 12, 2018 3:04 PM
  • Is there a good link you are aware of that I can send to our Server Group so they can READ and find out how to set up the WSUS on their end? Once they create the target group, I can set up MDT on my end for the TS to get updates accordingly.

    Its as if I'm trying to learn Latin online in a few hours and it's frustrating for you and me.


    Monday, March 12, 2018 3:37 PM
  • To be fair, if a particular team is responsible for maintaining WSUS then they should be the ones to learn how to do this assuming where you work is big enough to begin to need target groups. They will be responsible for approving what updates WSUS allows computers to get. 

    What you do with MDT is just tell the computer to become part of a specific WSUS group so that it only gets updates approved for that group. 

    This should explain it well: Deploy Windows 10 updates using Windows Server Update Services (WSUS)

    Being in a WSUS group tells the computer to get updates approved for that group, which can include inherited approvals as well as the updates approved specifically for that group.

    Daniel Vega

    Monday, March 12, 2018 3:46 PM
  • Thanks. The environment I work in is, well, for example:

    If I need a GPO for something, I first have to research it, find out what it is, where it goes in AD, ask AD group to add it to a test group, put my test computer in it, test it out, then ask them to move it to production.
    When it came to the Start Menu, they  wouldn't research how to "do" it, I had to look it all up for them. Then the most they could do was push that policy out daily, which only wiped out your changes you made each day. So, I wasted lots of time getting that set up in MDT. Which works, by the way. Now, WSUS. I've been reading what I need to do so the computers get the right updates, but what happens on the WSUS side....even with them creating the server for their "servers", I have to tell them what to do for our cloning computers to get other updates...and those updates I also have to tell them what they are and how to add them.

    Monday, March 12, 2018 3:51 PM
  • I want their job...make someone else do all the research and work of figuring it out 0_o

    Oh the joys of working for the state.

    Daniel Vega

    Monday, March 12, 2018 3:56 PM
  • I may just tell them that the only solution is to create a separate WSUS for our client computers, name it something and MDT will point to it and get every update there. They can at least set up the restrictions (such as feature updates, drivers, etc) and thus my job will be completely effortless. Of course, we as IT must tell them which updates we want/don't want, etc...but this eliminates my time spent on looking all that up. Thanks for your info, however.
    • Proposed as answer by Dan_Vega Tuesday, March 27, 2018 9:08 PM
    Monday, March 12, 2018 4:02 PM