The first post I created on this blog was Windows Server Update Services. I had an interesting time upgrading WSUS from v2 to v3 that included migrating to a new server. Well, I am having another interesting experience with WSUS.
About a year ago, a deployed a VMware Essentials environment and began virtualizing some of my servers. Some are conversions from physical to virtual and others are migrating or upgrading services onto new virtual machines. (Maybe I should create some posts on my vm enivronment. -Justin)
My current, soon to be old, WSUS server is an old Dell PE1650 with Windows Server 2003. It has held up pretty well. The new server is a VM running Windows Server 2008 R2 Enterprise. Why Enterprise? Because I have a license for it.
I decided to reduce the amount of effort in migration by attaching the new server to the old database. I tried every way I could think of and search for. I kept getting the same error about not being able to connect to the remote database. I spent more time trying to migrate the existing data than I would have spent just recreating all the settings. The configuration is just not that complex. Fortunately, it being a VM and me doing a snapshot before the install process failures, I was able to roll back to a clean slate and do a clean install.
This time around, I would try a different option. Instead of connecting to the existing database, I had it do a new Windows Internal Database. I also decided to try and configure it as a Replica Server of the other server. After it finishes synchronizing, I deselect the Replica option and see if it can run on it’s own. Oh, look at that. It worked! Much easier.
After reviewing the approved updates to make sure that they are all there and some finishing touches on the configuration, I create a new Group Policy that points to the new WSUS server and assign it to a couple of computers for testing.
Everything is looking good. Moving on to the next thing that I’m behind on.
Discussion
Comments are closed.