Take the pain out of deploying Systems Management Server 2.0

Plan, plan, plan - the most successful customers I've worked with have invested more in the planning and testing phases than in the actual deployments. If your architecture is sound for your needs, and your testing hits all the complexities of your enterprise, you'll see a much greater success.

It's important to understand how you expect to use SMS 2.0. Many IT professionals begin the upgrade process with the technical focus of doing the install, as opposed to really capacity planning your SMS 2.0 enterprise and designing the right architecture. With the new features that SMS 2.0 brings, many customers may be delivering more software, taking inventory more frequently, or utilizing software metering. All of these components will have an impact on your architecture and design. Here are some key metrics to understand:

1. Number/size/frequency of software packages to deliver?
   
2. Frequency of hardware/software inventory refreshes?
   
3. If using metering, how many machines/apps would you be monitoring?
   

These questions, and several more, are things to really understand to make sure your SMS 2.0 architecture that's on your war room wall, is the right architecture for your enterprise. (You can get more information about planning for SMS upgrades in "SMS Site Design Best Practices.")

You have to prepare users for some of the changes they'll see. They may have some more command prompt scripts kicking off for uninstall/reinstall, or they will see new interfaces for packages to be installed from, etc. In all my 1.2 - 2.0 migrations, it's been evident that users can create rollout problems where technical issues don't exist, and well-prepared users are better able to absorb any technical issues that may arise.

Again, look at all the "SMS Site Design Best Practice" documents, the SMS section in the BackOffice Resource Kit, as well as the Administrators Guide that ships with SMS 2.0 for all deployment planning best practices.

When doing an install where you don't migrate all the package and inventory history of your SMS 1.2 hierarchy, you install a new SMS 2.0 site, de-install the 1.2 clients, and then install the 2.0 clients. For many customers, this allows them to have a clean install of the server, and eliminate any database issues that may have existed with SMS 1.2. However, I've seen customers perform both options with a high degree of success.

This is always a big concern, since help desks and administrators are so reliant on remote control to save time and money in support costs. The best thing is to prioritize the features your corporation needs to have access to, test EXTENSIVELY to ensure you can deploy these features quickly and successfully, and then just move each site quickly - one at a time - so there is as little gap as possible from when the users migrate from the 1.2 client pieces to the 2.0 elements.