• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 548
  • Last Modified:

WSUS environment change - what will happen to existing computer objects?

Hi there,

I will be shortly be making some changes to an existing WSUS environment.  Currently we have a single upstream server (obviously) and a number of downstream servers across different sites.

Current setup:

Site A = 1 upstream, 1 replicated downstream
Site B = 2 replicated downstream
Site C = 1 replicated downstream

Proposed setup:

Site A = 1 replicated downstream (existing upstream to be decommed)
Site B = 1 replicated downstream (other downstream to be decommed)
Site C = 1 upstream (existing downstream to be converted to this upstream)

So end result will be one server in each site.  Sites A and B will each be losing an existing server.

Important point to note is that the Site C downstream will be converted into the upstream though the GUI.  No databases will be backed up and moved around.

As WSUS does not replicate computer objects between different up and downstreams, I am worried about the existing machines (be they servers or desktops) in Sites A and B as these sites will lose their existing primary WSUS servers.  Although they will be replaced with a simpler setup replicated through standard WSUS replication, can anybody tell me if objects local to these servers will automatically pickup with their new local WSUS servers or will I have to force them (hundreds or server objects) in any way?

GP will push computer objects todards "wsus" which will obviously be amended in DNS for the new primary local servers.

Further clarification available if I am not making myself clear.

I suppose another way of putting this would be to say "if I physically relocate a server from one site to another, will it automatically find and communicate with it's new local WSUS server?".  That should be a similar situation.
0
agtechnicalservices
Asked:
agtechnicalservices
  • 5
  • 5
1 Solution
 
arnoldCommented:
The computer/server objects if configured on the downstream servers can replicate/report back up to the upstream.


There is no need to move databases around since each WSUS instance configured as an upstream or a downstream server has its own database.  One thing to make sure prior to switching from downstream to upstream, is to synchronize the downstream server with the current upstream server if you've made changes.  There is no issue, other than you may need to approve installs of packages again.

I do not believe that WSUS would work as a DC i.e. each site will query the local DC.
In WSUS you would either have to adjust the GPO that applies to the site to point to the new intranet site or maintain and update dns such that
site A has a siteawsus.domain
site B has a sitebwsus.domain
site C has a sitebwsus.domain

this way when you add/replace WSUS server, you would modify the DNS record for the WSUS name holders to point to the new wsus IP.
0
 
agtechnicalservicesAuthor Commented:
I was planning on manually syncing, yes.

However since posting this I have "heard" that is it not possible to move an upstream server to another by simply converting from an existing downstream.  Apparently the databases are very different.  Unfortunately I have no way to test this which is a shame but I can see that the option to point an existing downstream to Windows Update Services does seem to exist...

I am not worried about reconfiguring DNS, but approving installs of packages again does worry me.  I may have to think again based on this.
0
 
arnoldCommented:
Yes, through the options, you change the site C from being a downstream to being independent.
then you change site A and siteB to be a downstream of site C and I believe that is all that is required.
The change will be to approve updates, you would only be able to use site C versus your current Site A.

I think updates that were previously approved, will remain approved, but I have not gone through this process to say for sure.

try the following:
convert site C to being an upstream.  If you have a test system or a virtual environment in which you can install an OS for which updates have been previously approved and see what your WSUS server does.
The issue is if you ran cleanup wizard on the WSUS downstream/upstream and deleted packages that are no longer needed, you may need to reapprove updates that were deleted at the time.
i.e. all your XP systems already had SP3 and the cleanup wizard deleted all the pre SP3 updates.  If you install a new SP2 windows XP and it checks in with your new upstream server at site C, it may indicate that there are pre sp3 updates needed by the new system.
0
Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

 
arnoldCommented:
The important part, you would not need to approve any updates unless you have a system that needs them such that I would not worry to much.
I think your worry stems from you approving the updates from memory i.e. which updates I previously approved on the upstream site A?
0
 
agtechnicalservicesAuthor Commented:
We're on the same page here that's for sure.

I'm going to carry on regardless (ignoring what other topics elsewhere may suggest) as the logic seems solid to me.  I'm aware that updates will have to be approved from Site C rather than Site A post change, yes.  Your "try the following:" suggestion is exactly what I had in mind so apologies if I explained that in a rather convoluted fashion in my first post.

I understand regarding the use of the cleanup wizard - not too worried about that.

Now my only issue is that the 3 new servers (pending as downstreams from the existing and to be decommed upstream) have a slightly different number of total updates (less) than the original upstream.  Fairly confident this is due to language changes on the original upstream.  i.e. originally setup with 2 languages and then quickly reconfigured with 1.  Maybe.

Still, if I can't pinpoint this as the issue I will ignore it and just unlick the GP object from the clients just in case it starts deploying any unwelcome surprises.  Gradually add to a few machines as a test and then re-link if it's safe after that.

Will let you know what happens...
0
 
arnoldCommented:
The discrepancy might deal with versions of updates that exist on the upstream server, but there is no reason those versions would be downloaded to the downstream.  The old version could very well be declined, but were not deleted if cleanup wizard was not run.

 But it does not matter, once the downstream connects and synchronizes to its up stream it will get the current state.  The product catalog is controlled by the upstream server, so if there is a discrepancy in product selection on the old upstream and the new upstream, those discrepancies will be fixed on the first sync.

I.e. the new one includes a newer release of MS products that the old one does not.
Or other options were selected on the new one dealing with the type of updates to retrieve using WSUS.
0
 
agtechnicalservicesAuthor Commented:
Update: this solution worked as expected.  Simple redirection of upstreaming.
0
 
arnoldCommented:
Why are you assigning zero points to the solution that worked?
0
 
agtechnicalservicesAuthor Commented:
Apologies - I had no intention of assigning 0 points.  In fact I tried to spread the 125 accross the comments from arnold and submitted the close request.  I object closing this now until the points can be re-assigned.
0
 
agtechnicalservicesAuthor Commented:
Thank you.  Confirmed solved.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now