WSUS Problem

I am using client side targeting with Group Policy but noticed that all the servers quite rightly showing up in my Servers group that i made but i need to move one server into my Test Group. How can i do this when the Change Membership is greyed out because i am using Group Policy?

Also even though i am using Group Policy i am noticing a lot of clients are in the Unassigned group and i cannot move these either.

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

sprkymrk

This is one of those times where the saying "You can't have your cake and eat it too" comes to mind.

If you are controlling WSUS through Group Policy, that is where you need to make your changes. It's done that way by design. Consider a Domain Admin that wants to make sure that WSUS settings are applied according to his design, but then a server admin decides he wants to do it different, what would be the point of having a nice GPO in place if the server admin could change it?

You need to create a new GPO/OU or modify the current one to make it do what you want. Or don't use Group Policy and do it from the WSUS server.

billybob01 wrote:

Also even though i am using Group Policy i am noticing a lot of clients are in the Unassigned group and i cannot move these either.

Have you tried gpupdate /force on the clients? Or is it possible the WSUS SID of the clients are messed up due to the cloning procedure used?

billybob01

We use sysprep when cloning so the WSUS SID should not be an issue. Do i need to make another OU with the one server i need to go into my test group and then apply client side targeting to that OU stating test group?

blargoe

I don't think the WSUS sid is cleared by sysprep... could be wrong... I think there used to be a utility to clear the WSUS sid?

blargoe

Regarding the group policy, the only thing you can do is to assign your "test" server a different group policy (perhaps put it in a different OU and assign the the group setting via GPO to that OU).

You have to create the groups in WSUS first before WSUS puts the clients in the group specified in the GPO. Also, if you have replica servers, the "enable client side targeting" has to be set for EVERY server that has clients reporting to it, not just the master server.

When you click on the name of the server in the WSUS console, do you have any messages on in the pane on the right side regarding clients requesting groups that do not exist?

billybob01

It`s ok now, they have all reported in. I have placed a server in it`s own OU and applied Gp to it stating Test Group within client-side targeting and just waiting for it to appear, even though i ran gpupdate /force, it takes ages!!

jasonboche

blargoe wrote:

I think there used to be a utility to clear the WSUS sid?

You may be talking about this:

Resetauthorization Option
WSUS uses a cookie on client computers to store various types of information, including computer group membership when client-side targeting is used. By default this cookie expires an hour after WSUS creates it. If you are using client-side targeting and change group membership, use this option in combination with detectnow to expire the cookie, initiate detection, and have WSUS update computer group membership.
Note that when combining parameters, you can use them only in the order specified as follows:
wuauclt.exe /resetauthorization /detectnow
===========
Stop WSUS Client-Side service (net stop wuauserv)
Go to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate and delete:
PingID (if listed)
AccountDomainSid
SusClientId
And then restart the WSUS client-side service (net start wuauserv). Then, run wuauclt.exe /resetauthorization /detectnow to force WSUS to get its act together and start over. It'll recreate the keys you deleted with a unique ID, solving the problem.
===========

sprkymrk

jasonboche wrote:

blargoe wrote:

I think there used to be a utility to clear the WSUS sid?

You may be talking about this:

Resetauthorization Option
WSUS uses a cookie on client computers to store various types of information, including computer group membership when client-side targeting is used. By default this cookie expires an hour after WSUS creates it. If you are using client-side targeting and change group membership, use this option in combination with detectnow to expire the cookie, initiate detection, and have WSUS update computer group membership.
Note that when combining parameters, you can use them only in the order specified as follows:
wuauclt.exe /resetauthorization /detectnow
===========
Stop WSUS Client-Side service (net stop wuauserv)
Go to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate and delete:
PingID (if listed)
AccountDomainSid
SusClientId
And then restart the WSUS client-side service (net start wuauserv). Then, run wuauclt.exe /resetauthorization /detectnow to force WSUS to get its act together and start over. It'll recreate the keys you deleted with a unique ID, solving the problem.
===========

That wil work. I created a batch script like this:

REM Stop the Automatic Updates service
net stop wuauserv

REM Stop the Windows Management Instrumentation service
net stop winmgmt

del /f /q %systemroot%\softwaredistribution\*.*

REM Delete SusClientID and AccountDomainSid keys from
REM  HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate
SET WU_KEY=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate
reg delete %WU_KEY% /v SusClientID
reg delete %WU_KEY% /v AccountDomainSid
SET WU_KEY=

REM Start the Automatic Updates service
net start wuauserv

REM Start the Windows Management Instrumentation service
net start winmgmt

REM Force a group policy update
gpupdate

REM Roll the WU Client...
wuauclt /resetauthorization /detectnow

billybob01

I still have clients in the unassigned group!! even though i am using group policy. Will these eventually appear in there respective groups??

blargoe

They may have to go through an update and reboot cycle depending on whether or not they had other updates pending before the new client was rolled out. I'm not really sure about that but it seems like I had a few stragglers that stayed that way until they rebooted.

Check out their hklm\software\policies\microsoft\windows\windows update\ and see what their target group is set to. If there isn't a value there then check your group policy application. If there is a value there, make sure the update server they report to has that group name defined.

sprkymrk

Yeah, they might just need a reboot, or else try a gpupdate on them.