We're currently in the middle of the first phase (Analyze) of our "Baseline Update" project. We want to migrate our 1500+ clients from WinXP SP1 to SP2.
I need some hints from you guys who already did that change...

- Since we have more than 400 applications, we need a lot of time to test the applications to ensure, they're SP2 compatible. How did you manage this? Have you had a Freeze time to be able to manage it yourself or did you do it with external staff?

- How did you test the applications?

- How long was the period of the migration itself (from the first SP2 client until they were all migrated successfully)?

- How did you distribute the Service Pack? With SUS/WSUS, your software distribution tool or any other method? Was it the right choice? What are the advantages/disatvantages of that specific method?

- Did you enable all the new security features like the Pop-Up Blocker, Security Center, Windows Firewall and so on?

- Do you use GroupPolicies as the main tool to distribute settings or simple registry keys or Packages?

Thanks for any help

0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


Hey Roland,

We are currently migrating about 40K + systems to SP2 and as you stated it is a long process.

The first thing to do is find out what new security features in SP2 you want to use, Firewall etc, and find the policies for enabling\disabling them. You can do this through a GPO or through startup\shutdown scripts and registry mods. If a particular group needs certain apps enabled through the Firewall then you may need to be able to implement those things on the fly so it's good to be familiar with it. I would recommend not using it altogether but the Popup blocker works pretty well.

The second thing we do is create a baseline installation for everyone to use that will be deployed through SMS. We make sure the package installs completely silently and works with our current image and has the option to reboot\or not upon completion. We then give that to the different areas for testing and usually keep a document centralized for the reporting of issues. (usually through a mock deployment so that it looks just like it would in production). Be sure to set a reasonable timeline for everyone to be signed off by so that the same installation can be used across all systems. Each area should have a method for testing changes on the systems so they "should" be able to run through their specific application testing pretty quickly.

Once the install has been given the thumbs up by everyone we then schedule the installation so that in a worst case scenario (everything fails and machines are in the ditch) our help desk does not get flooded with calls. We reduce the risk of failure by sending out one job that simply starts a copy of the SP2 package down to the local computer. We have a script that copies only at certain times of the day to avoid network congestion. Once the copy is complete we then advertise another job to kick off the install. We then mark the systems that need to be "cleaned up" because they were not successful, hand that off to someone else, and then start the next batch.

As far as SMS vs SUS goes, SMS works well for for big SP deployments. However, we use the SMS SUS feature pack for deploying most other patches.

It's a long process but it works for us. Hope it helps.
Answered 05/01/2006 by: yarborg
Blue Belt

Please log in to comment
Thanks yarborg for your valuable feedback!

Anyone else?
Answered 05/04/2006 by: rpfenninger
Second Degree Green Belt

Please log in to comment
Because of the lack of compatibility information the project that I am participating in we are basically going down a similar route that Yarborg is. The exception is that the business is willing to let us deploy a whole new desktop image with SP2 rather than rolling it out as an upgrade. This is probably a more expensive way to go since every machine will be imaged but we are given the chance to make very significant changes to the base computing platform. The key issue will be to ensure that the business units and thier application experts perform testing on every application destined to the new platform otherwise we will get caught with some high priority break fix requests.
Answered 05/04/2006 by: kkaminsk
Ninth Degree Black Belt

Please log in to comment
What about packaging apps during migration phase.
Did you still package on SP1 machines until the end of the migration phase or did you updgrade the packaging computers as soon as the first productive clients had SP2?
What are the advantages and disadvantages? Risks?
Answered 05/08/2006 by: rpfenninger
Second Degree Green Belt

Please log in to comment
It is being handled like a typical OS upgrade. We will be testing apps out on the new desktop build over the summer and fixing defects as they are reported. New apps that come in while the certification process is going on will have to be certified on two platforms but since it is summer we should not have too much in terms of new applications. Some additional packaging resources are also present to help the full time staff focus on the project and help ensure that the legacy environment is properly maintained until it is decommissioned. The real fun will come down to the migration because the two platforms are significantly different (new platform has Oracle 10, new java etc..).

Users will not be able to roam between platforms but this shouldn't be a big deal. I guess that is where your impact can be seen is that you have to know what portions of your end user population are transient and make sure that the rollout does not significantly impact their access to computing resources. The reason we will have issues with our roaming users is that application deployment is done via ZenWorks and the two platforms are too different to allow for the applications to follow the user between computing environments. Now if you were doing machine based software deployment this would be a non issue but I have not seen many shops these days that manage their software on a per machine basis. Even if you were in a per machine distribution model roaming profiles could cause some issues depending on the application and what it likes to do with the user profile.
Answered 05/08/2006 by: kkaminsk
Ninth Degree Black Belt

Please log in to comment