Migrate WSUS3.0SP2 to new server

I've searched using shift, move, migrate, new server - and not found what
I'm looking for so apologies if this is in this NG under my nose somewhere.

I have WSUS 3.0 SP2 on a Win2003SP2 and it does so little work there with
only 50 users that I am thinking of migrating WSUS onto the same server as a
Search Server 2008 Express - to free up a server license.

Any problems so far? Bad idea to start with? Problems with WSUS and on the
same hardware?

Now I did find this, and it's pretty much how I've migrated WSUS before,
only without copying the approvals which I've reset manually when 'needed':
http://exchangeserverpro.com/how-to-...o-a-new-server

The tartet machine with Search Server Express is also a Windows 2003 SP2
x64, while the initial server is 32 bit. The only issue I can see is if the
wsusmigrationimport.exe tool does not work on 64 bit.

Or is there a better / easier way to do it that copies everything over?

TIA
--
Dave Harry

"Dave Harry" <> wrote in
message news:...
> I've searched using shift, move, migrate, new server - and not found what
> I'm looking for so apologies if this is in this NG under my nose
> somewhere.
>
> I have WSUS 3.0 SP2 on a Win2003SP2 and it does so little work there with
> only 50 users that I am thinking of migrating WSUS onto the same server as
> a Search Server 2008 Express - to free up a server license.
>
> Any problems so far?

Not that I can see. The system load of 50 clients on a WSUS server is hardly
even measurable. You'll just want to be sure to coordinate the indexing
activities of the Search Server with the synchronization events of the WSUS
server so they don't bump heads for disk access.


> Problems with WSUS and on the same hardware?

> Now I did find this, and it's pretty much how I've migrated WSUS before,
> only without copying the approvals which I've reset manually when
> 'needed':
> http://exchangeserverpro.com/how-to-...o-a-new-server

Generally I'd recommend avoiding this article as a source, although the
concept is valid.

Mr. Cunningham shoots his credibility in the foot, IMHO, when he opens up
the article talking about migrating WSUS to a server running SQL Server
Express Edition. Anybody who's considered any of the ramifications of WSUS
and SQL Server Express would know that SQL Server Express is a wholly
inappropriate database solution for a WSUS server, as the Windows Internal
Database is a *better* database engine.

It's also somewhat redundant to migrate the approvals and groups, since the
*replica* process will already do this automatically. What isn't replicated
is the group *memberships* if you're using server-side targeting -- but
there's a solution for this also.

If you're using server-side targeting, the computers will re-register with
the new server in the Unassigned Computers group. However, EminentWare was
kind enough to whip up a command-line utility that solves this little
inconvenience. Grab the ComputerMigrator from
[https://www.eminentware.com/cs2008/media/p/430.aspx] and you can
prepopulate the computers into their correct groups before assigning the new
server as the active server for the clients.

This replication server process is also documented in the Essential Business
Server Deployment Guide
[http://technet.microsoft.com/en-us/l...0(WS.10).aspx], which is
designed to help migrate a standalone WSUS v3 server into the EBS
"Management Server" environment.

Ironically, when I tried to encourage the WSUS product group to endorse this
process, and write their own documentation to be authoritative on the
process (even before I knew EBS had already documented it), they declined to
do so. (I guess next week I'll go look in SQL Server Books Online to find
out how to configure my Exchange Server, since cross-group documentation
seems to be the new norm in Redmond.)


> The tartet machine with Search Server Express is also a Windows 2003 SP2
> x64, while the initial server is 32 bit. The only issue I can see is if
> the wsusmigrationimport.exe tool does not work on 64 bit.

Using replication to build the new server means you do not need to worry
about migrating approvals. I'm not even sure why Cunningham mentions that
tool -- but then, as noted, he is migrating this to SQL Express. :-/


--
Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2010)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

"Lawrence Garvin [MVP]" <> wrote in message
news:2FE29B4F-2141-467D-8BB2-...

>> Any problems so far?
>
> Not that I can see. The system load of 50 clients on a WSUS server is
> hardly even measurable.

It barely even counts as grass on its virtual machine manager's CPU graph.
Old man grass - mown very short.


> It's also somewhat redundant to migrate the approvals and groups, since
> the *replica* process will already do this automatically.

Oh yeah... Good point.

>What isn't replicated is the group *memberships* if you're using
>server-side targeting -- but there's a solution for this also.
>
> If you're using server-side targeting, the computers will re-register with
> the new server in the Unassigned Computers group. However, EminentWare was
> kind enough to whip up a command-line utility that solves this little
> inconvenience. Grab the ComputerMigrator from
> [https://www.eminentware.com/cs2008/media/p/430.aspx] and you can
> prepopulate the computers into their correct groups before assigning the
> new server as the active server for the clients.

Handy, thanks. I think I will try that before I instead rename my servers
(there's a handful outside GP control).
Not that 50 computers is really a backbreaking task.


> (I guess next week I'll go look in SQL Server Books Online to find out how
> to configure my Exchange Server, since cross-group documentation seems to
> be the new norm in Redmond.)

<grin>


Thank you again Lawrence for another extremely helpful response.
Regards,

--
Dave Harry

I'd like to report my successes and failures for anyone else wanting to do
this.
Generally speaking, the process worked apart from one gotcha.
Lawrence, I notice you have a wsus wiki. Perhaps you might like to note
this.


I installed Search Server 2008 Express (SSE) and configured it.
Then I installed WSUS. It now defaulted to 8530 of course and I configured
it to replicate from the original. This worked ok and after serveral federal
government administations, sync finished.

But SSE was broken. Couldn't fix it. So I uninstalled SSE, rebooted and
reinstalled SSE.
Seemed to work ok and WSUS still seems alright. Yay.
Perhaps installing WSUS before SSE would be preferable. But be sure to
deliberately install WSUS on TCP/8530 instead of the default 80.

The WSUS -> XML migration tool Lawrence mentioned is great.

But the one thing that migration of server will NOT do is take all your
workstation's settings (update view configurations) across. Here is how I
got around it. Rather than change policy for workstations to point to a new
server, I moved the DNS for "wsus.localdomain" to the new machine.

After replication sync and computer ID import, redirect the new WSUS back to
Windows Update. Rename the old server WSUS-OLD and reboot or shutdown.
Rename the new server wsus.localdomain and reboot. Or, set a CNAME alias in
DNS which is what I did.

At my workstation, I did a IPCONFIG /FLUSHDNS, just to be sure, and started
my WSUS console. All original update views remained.

Hopefully this is useful to someone.

--
Dave Harry

"Lawrence Garvin [MVP]" <> wrote in message
news:2FE29B4F-2141-467D-8BB2-...
> "Dave Harry" <> wrote in
> message news:...
>> I've searched using shift, move, migrate, new server - and not found what
>> I'm looking for so apologies if this is in this NG under my nose
>> somewhere.
>>
>> I have WSUS 3.0 SP2 on a Win2003SP2 and it does so little work there with
>> only 50 users that I am thinking of migrating WSUS onto the same server
>> as a Search Server 2008 Express - to free up a server license.
>>
>> Any problems so far?
>
> Not that I can see. The system load of 50 clients on a WSUS server is
> hardly even measurable. You'll just want to be sure to coordinate the
> indexing activities of the Search Server with the synchronization events
> of the WSUS server so they don't bump heads for disk access.
>
>
>> Problems with WSUS and on the same hardware?
>
>> Now I did find this, and it's pretty much how I've migrated WSUS before,
>> only without copying the approvals which I've reset manually when
>> 'needed':
>> http://exchangeserverpro.com/how-to-...o-a-new-server
>
> Generally I'd recommend avoiding this article as a source, although the
> concept is valid.
>
> Mr. Cunningham shoots his credibility in the foot, IMHO, when he opens up
> the article talking about migrating WSUS to a server running SQL Server
> Express Edition. Anybody who's considered any of the ramifications of WSUS
> and SQL Server Express would know that SQL Server Express is a wholly
> inappropriate database solution for a WSUS server, as the Windows Internal
> Database is a *better* database engine.
>
> It's also somewhat redundant to migrate the approvals and groups, since
> the *replica* process will already do this automatically. What isn't
> replicated is the group *memberships* if you're using server-side
> targeting -- but there's a solution for this also.
>
> If you're using server-side targeting, the computers will re-register with
> the new server in the Unassigned Computers group. However, EminentWare was
> kind enough to whip up a command-line utility that solves this little
> inconvenience. Grab the ComputerMigrator from
> [https://www.eminentware.com/cs2008/media/p/430.aspx] and you can
> prepopulate the computers into their correct groups before assigning the
> new server as the active server for the clients.
>
> This replication server process is also documented in the Essential
> Business Server Deployment Guide
> [http://technet.microsoft.com/en-us/l...0(WS.10).aspx], which
> is designed to help migrate a standalone WSUS v3 server into the EBS
> "Management Server" environment.
>
> Ironically, when I tried to encourage the WSUS product group to endorse
> this process, and write their own documentation to be authoritative on the
> process (even before I knew EBS had already documented it), they declined
> to do so. (I guess next week I'll go look in SQL Server Books Online to
> find out how to configure my Exchange Server, since cross-group
> documentation seems to be the new norm in Redmond.)
>
>
>> The tartet machine with Search Server Express is also a Windows 2003 SP2
>> x64, while the initial server is 32 bit. The only issue I can see is if
>> the wsusmigrationimport.exe tool does not work on 64 bit.
>
> Using replication to build the new server means you do not need to worry
> about migrating approvals. I'm not even sure why Cunningham mentions that
> tool -- but then, as noted, he is migrating this to SQL Express. :-/
>
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2010)
>
> My Blog: http://onsitechsolutions.spaces.live.com
> Microsoft WSUS Website: http://www.microsoft.com/wsus
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>

"Dave Harry" <> wrote in
message news:...

> Lawrence, I notice you have a wsus wiki. Perhaps you might like to note
> this.

Uh... no.. I don't have a wiki.. <g> ... but I do have a blog.


> But the one thing that migration of server will NOT do is take all your
> workstation's settings (update view configurations) across.

Correct. The migration process will not modify the registry on the managed
clients, nor update the Group Policies used to configure those clients;
however, the procedure that is documented in the EBS documentation (and
elsewhere), does, I'm fairly certain of, contain a step indicating that
policy should be updated following the completion of the conversion of the
new server from replica mode back to upstream mode.


> Here is how I got around it.

This is not really a "get around it" scenario. :-)
These are the appropriate steps ( more or less ) that should be performed in
every case.


> Rather than change policy for workstations to point to a new server, I
> moved the DNS for "wsus.localdomain" to the new machine.

> After replication sync and computer ID import, redirect the new WSUS back
> to Windows Update. Rename the old server WSUS-OLD and reboot or shutdown.
> Rename the new server wsus.localdomain and reboot. Or, set a CNAME alias
> in DNS which is what I did.

The only exception here is that changing policy is the *preferred*
solution,but luckily WSUS is the type of application that responds perfectly
well to CNAME aliases, so adding a CNAME entry for the URL pointing to the
new machine will easily avoid the necessity of updating the Group Policy.

However, I would not recommend renaming the new server post-installation.
Please refer to the Release Notes for reasons why renaming the new server
has not, historically speaking, been an appropriate action after
installation of WSUS.
You'll also want to review the registry key HKLM\Software\Microsoft\Update
Services\Server\Setup to verify that the old hostname has been updated to
the new hostname in the applicable registry keys.

If one truly has a need to retain the same machinename on the new server, I
would recommend uninstalling WSUS after the replica synchronization is
complete (keeping the database, logs, and content) (and IIS6 on a Windows
Server 2003 system), renaming the system, and then reinstalling IIS (if
necesary) and WSUS back to the existing database, logs and content using the
new servername.


--
Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2010)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin