multiple forest patching controlled by a single WSUS server?

[Special Access]

In our lab environment, we have several distinct forests and we need
to keep them patched (obviously) but someone has asked if a single
WSUS server can patch across the forests. We know it will patch
across parent and child domains in a single fores, even for those
computers that are not in the domain. The concern seems to be if the
computers will be visible in the console when there is no trust
between the forests and if patching can actually happen between them.

Advice? Ideas? WSUS 3.0 SP2 is what the single WSUS server is,
currently installed in the largest forest (computer-wise) and can ping
all the other computers in the other forests.

Thanks for the info, pointers, advice etc.

Mike

[Dave Harry]

Post by Special Access
The concern seems to be if the
computers will be visible in the console when there is no trust
between the forests and if patching can actually happen between them.

As I understand it, the WU client has trust in Microsoft's signed packages
on the WSUS server.
Domain trust is not required.

One WSUS server can supply as many computers as the machine can physically
handle, across any forest and non-domain computer.

[Special Access]

On Wed, 31 Mar 2010 11:51:41 +1100, "Dave Harry"

Post by Dave Harry

Post by Special Access
The concern seems to be if the
computers will be visible in the console when there is no trust
between the forests and if patching can actually happen between them.

As I understand it, the WU client has trust in Microsoft's signed packages
on the WSUS server.
Domain trust is not required.
One WSUS server can supply as many computers as the machine can physically
handle, across any forest and non-domain computer.

That is what I thought as well, but couldn't find it in writing
anywhere. Some of the computers in the other forest(s) are
disappearing from the console for the test group of workstations we
are using. We have tried the /a /detectnow and /report now functions,
and they reappear for a time.. then disappear. We have validated the
AU settings on the computers and everything looks OK. They won't let
me proceed until they are "certain it will work" and all my testing so
far says it's still a 50/50 shot (sigh)
The WSUS was setup with the WID since there are less than 700
computers in the labs... and I haven't seen anything anywhere in my
searching that says why the computers keep disappearing and almost
everyone says the /a /detectnow in conjunction with the /reportnow
should bring it back. and to their credit, it does.. they just don't
stay around very long (10-40 mins, almost sounds like a policy refresh
thing which is why I was asking)

Dave, thanks for the inputs. I'll keep on trying to see what the root
of the problem is.

Mike

[Lawrence Garvin [MVP]]

Post by Special Access
Some of the computers in the other forest(s) are
disappearing from the console for the test group of workstations we
are using.
and they reappear for a time.. then disappear.

This is symptomatic of duplicate SusClientIDs. You should ensure that the
systems have been updated to the v7.4 WUAgent, and refer to KB903262 for
further remediation if the issue still exists after updating the WUAgent.

Post by Special Access
We have tried the /a /detectnow and /report now functions,
and almost
everyone says the /a /detectnow in conjunction with the /reportnow
should bring it back.

Truly, the "almost everyone" you're consulting with, you should fire,
IMNSHO.

For one /a is not a valid parameter.
For two, the /reportnow parameter is only functional *IF* a reporting event
is pending, and all it does expedite what would happen normally. The fact
that clients are being swapped out is prima facie evidence that the
reporting functionality of the WUAgent is working perfectly -- except for
the fact that your client systems have duplicated IDs which are masking one
another.

[Special Access]

On Tue, 30 Mar 2010 21:29:21 -0500, "Lawrence Garvin [MVP]"

Post by Lawrence Garvin [MVP]
For one /a is not a valid parameter.
For two, the /reportnow parameter is only functional *IF* a reporting event
is pending, and all it does expedite what would happen normally. The fact
that clients are being swapped out is prima facie evidence that the
reporting functionality of the WUAgent is working perfectly -- except for
the fact that your client systems have duplicated IDs which are masking one
another.

interesting, as technet article
http://technet.microsoft.com/en-us/library/cc720477(WS.10).aspx
states the /a is shorthand for the /resetauthorization switch.

We have started stopping BITS, WUAUSERV, removing the SUSid and the
AccountID from the registry, deleting the 'softwareupdate' folder,
restarting WUAUSERV and BITS, and finally running wuauclt /a
/detectnow. So far, so good. 4 computers that were in and out seem
to like it enough to stay in all day today.

Thank you, Lawrence, for your replies. I am slowly learning more than
I ever wanted to about WSUS heheh

Mike

[Lawrence Garvin [MVP]]

Post by Special Access

Post by Lawrence Garvin [MVP]
For one /a is not a valid parameter.

interesting, as technet article
http://technet.microsoft.com/en-us/library/cc720477(WS.10).aspx
states the /a is shorthand for the /resetauthorization switch.

Yeah.. it does ... it also has an incorrect description for the
/resetauthorization switch.

So either the description is for the /a switch, which has nothing at all do
to with /resetauthorization,
or if /a and /resetauthorization are the same (which I don't believe they
are) then the page entirely misrepresents the functionality of the
/resetauthorization switch.

In fact, to execute "an asynchronous background search for applicable
updates", you would use the /detectnow switch, not /resetauthorization.
Furthermore, /resetauthorization won't even work by itself, it must be
combined with /detectnow, and the only thing that /resetauthorization does
is delete the cached targeting cookie.

I also note, sadly, that the /detectnow switch is not even documented in
this article.

Short answer: this Appendix is one of the more notable blights on the
otherwise good documentation provided for WSUS.

Post by Special Access
We have started stopping BITS, WUAUSERV, removing the SUSid and the
AccountID from the registry, deleting the 'softwareupdate' folder,
restarting WUAUSERV and BITS, and finally running wuauclt /a
/detectnow. So far, so good. 4 computers that were in and out seem
to like it enough to stay in all day today.

So.. would you like to know which *two* steps of the above procedure is
producing all of your positive results, and which of the other SIX steps you
could completely ignore?

1. Stopping services -- totally unnecessary.
2. Removing SusClientID -- one of two constructive steps.
3. Removing AccountID -- not the correct key name and deprecated in the WUA
v7 product anyway -- if it still exists, it's left over from the WSUS v2
installations you used to have.
4. Deleting the 'softwareupdate' folder -- an excessively destructive step
which destroys the client-side datastore containing the machine's complete
update history, as well as the ReportingEvents.log file which is the *only*
true and complete history of all activity of the WUAgent for the lifetime
of that machine.
5. Restarting services -- only necessary if Step #1 was performed.
6. Running the indicated command -- wuauclt /resetauthorization /detectnow

Ergo....

These are the only required steps to resolve your duplicate SusClientID
issues:

1. Delete the SusClientID and SusClientValidationID (as documented in
KB903262).
2. Run wuauclt /resetauthorization /detectnow

Post by Special Access
Thank you, Lawrence, for your replies. I am slowly learning more than
I ever wanted to about WSUS heheh

:-)

[Lawrence Garvin [MVP]]

Post by Special Access
In our lab environment, we have several distinct forests and we need
to keep them patched (obviously) but someone has asked if a single
WSUS server can patch across the forests. We know it will patch
across parent and child domains in a single fores, even for those
computers that are not in the domain.

Just to state the fundamental point here -- WSUS is domain agnostic. It
knows nothing, and cares nothing, about the domain membership or forest
membership of a client system, and cares nothing about any existing domain
trusts, forest trusts, or the lack thereof. The only time domain membership
is relevant is to establish an authenticated connection between a front-end
WSUS server and the back-end database server, and to establish an
authenticated connection between a remote console and the WSUS server.

[Special Access]

On Tue, 30 Mar 2010 21:25:19 -0500, "Lawrence Garvin [MVP]"

Post by Lawrence Garvin [MVP]

Post by Special Access
In our lab environment, we have several distinct forests and we need
to keep them patched (obviously) but someone has asked if a single
WSUS server can patch across the forests. We know it will patch
across parent and child domains in a single fores, even for those
computers that are not in the domain.

Just to state the fundamental point here -- WSUS is domain agnostic. It
knows nothing, and cares nothing, about the domain membership or forest
membership of a client system, and cares nothing about any existing domain
trusts, forest trusts, or the lack thereof. The only time domain membership
is relevant is to establish an authenticated connection between a front-end
WSUS server and the back-end database server, and to establish an
authenticated connection between a remote console and the WSUS server.

Got it. In a twisted sort of way, that makes sense. If it would do a
computer not in the domain, then why would it care if it's in the same
forest.

Mike

[Lawrence Garvin [MVP]]

Post by Special Access
Got it. In a twisted sort of way, that makes sense. If it would do a
computer not in the domain, then why would it care if it's in the same
forest.

You got it! :-)