Systems Management

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.

Thanks yarborg for your valuable feedback!

Anyone else?

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.

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?

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.