SolutionBase: Understanding how Windows Server 2003 can help with change management

Change is good, right? Well, managing change can be difficult. Here's how Windows Server 2003's built-in features can help with change management.

One of my pet peeves has always been consultants who throw around trendy buzz words without knowing or caring what those words really mean. I recently tuned into a Web cast in which just such a person was rambling on and on about just such a buzz word; change management. Don't get me wrong though. I think that change management definitely has its place in IT. It's just that a lot of people tend to make the idea of change management way more complicated than it needs to be.

The million-dollar question is therefore, how can Windows Server 2003 help with change management? To put it more simply, how can Windows Server 2003 relieve the administrative staff of the burden of day-to-day operations? Well, I doubt that you will ever be able to get completely away from day-to-day administration, but Windows Server 2003 offers many tools that can be used to greatly simplify administration. In the sections below, I will discuss how Windows Server 2003 can be used to make various administrative tasks easier.

What's change management?

The idea behind change management is very simple. In fact, I can summarize change management in just two words; Version Control. An example of change management from an IT prospective is making sure that all of the users have the same version of Microsoft Office. Unfortunately, effectively performing change management is a lot more complicated than defining it. An example of performing change management effectively would be deploying the next version of Microsoft Office to all of your users with little, if any, administrative effort or end user down time.

Right now, you might be wondering what the big deal is. After all, a new version of Microsoft Office only comes out every two or three years, so what does it really matter if deployment is a headache? The thing is though that I was just using Microsoft Office as an example. Change management is something that occurs in one form or another on almost a daily basis. Some examples of change management include: deploying a new application, deploying a security patch, setting up a new PC, moving a user to a different PC. These are all changes that occur on almost a daily basis in most organizations.

In a small organization, it is possible to manage such changes (perform these tasks) manually, but doing so typically places a heavy burden on the IT staff. After all, how many IT people have you seen that have no time for special projects because they are too busy putting out fires and dealing with the day-to-day stuff? In a small organization, effective change management can greatly boost productivity. In a large organization, effective change management is critical to even being able to manage the network.

Setting up a new PC

One of the primary change management tasks that Windows Server 2003 allows you to automate is setting up a new PC. Setting up new computers manually has always been a very time consuming task because you have to manually install an operating system, anti virus software, applications, service packs, and anything else that might be required. It's easy to waste an entire afternoon setting up a single PC.

Back in the days of Windows 9x and Windows ME, it was possible to set up a new PC and then create a ghost image of the machine's hard drive. From that point on, you could set up additional machines by restoring the ghosted image to them as long as the new machine's hardware was identical to the machine that the ghosted image was made off of.

Ghosting does not work for machines running Windows NT, 2000, or XP though because of the way that those operating systems make use of SIDs. You can however set up new computers by using the Remote Installation Services (RIS). As you may know, RIS was also included with Windows 2000 Server, but did not support Windows XP installations. The version of RIS included with Windows Server 2003 will allow you to deploy Windows XP.

RIS gives you several different options for setting up new machines. The option that saves the most time works a lot like ghosting. This method involves manually setting up a new machine with the desired operating system, applications, etc. You then create a RIS image based on that machine. This image is then used to deploy Windows and the various applications onto new machines.

The main advantage that RIS has over ghosting is that there are no complications with SIDs or with differences in hardware. The Windows deployment process automatically detects differences in hardware and loads the necessary drivers. The Setup process also guarantees that the new machine receives unique SIDs.

The process of setting up a new machine is very simple. The new machine performs a PXE boot off of the boot prom on the machine's NIC. If the machine does not support PXE, you can create a RIS boot disk that acts as a PXE emulator. Once the machine attaches to the RIS Server, it runs a miniature version of Windows Setup. This setup program just asks for machine specific information such as the computer name. You can however completely automate the process by supplying Setup with an answer file containing the answers to all of its questions. Once the mini setup completes, the remaining files are copied from the RIS server to the new machine. When all is said and done, the new machine will contain Windows and the applications that were included in the image file.

The only thing that you have to watch out for when setting up a RIS server, is that RIS only supports a limited number of network cards. Even if your NIC does support PXE boot, there are no guarantees that it will work with RIS. This tends to especially be a problem with machines that have Intel network cards. It is possible to add a driver for an unsupported network card to RIS, but the procedure is tricky and requires a patch that you can only get from Microsoft's Product Support Services.

Deploying new applications

As you've seen, you can use a RIS server to deploy Windows and the applications that your company uses. However, applications have a finite lifecycle. Sooner or later applications are bound to be upgraded to a newer version or phased out completely. A part of effective change management is being able to deploy new applications in as efficient manner as possible.

Windows Server 2003 doesn't offer great application deployment tools. You are usually better off getting a third party utility for managing applications. Windows Server 2003 does allow you to publish or assign applications through the group policy though.

You can publish or assign any application that includes a Windows installer file (an .MSI file). Publishing an application basically means that you are making the application available to users. Publishing an application doesn't actually install the application, but it does make it available for installation through the Add / Remove Programs applet in the Control Panel.

You can assign applications to either the user or to the computer. If you assign an application to a computer, then the application is installed upon the next logon. If you assign an application to a user, shortcuts to the application are placed on the desktop or the Start menu, but the application doesn't actually get installed until the user attempts to use it.

As I said earlier, I recommend using a third party application management program, because such programs tend to offer more flexibility. There is at least one advantage to deploying applications through the group policy though. If you assign an application to a user or a computer and the application gets damaged or uninstalled, Windows is usually smart enough to detect the problem and automatically fix it.

Applications are published or assigned through the group policy. You can assign an application to a computer at Computer Configuration | Software Settings | Software Installation. You can publish or assign applications to users at User Configuration | Software Settings | Software Installation.

Deploying software patches

So far I have talked about deploying new machines and maintaining applications on those systems. However, it is also necessary to maintain patches to Windows and your applications. Windows Server 2003 does not natively offer a patch management solution. However, you can download the Software Update Services (SUS) from the Microsoft Web site.

SUS works similarly to Windows Update with one big exception. Rather than having every PC in your organization downloading updates separately, only one server downloads updates. The Administrator can then either approve or disapprove of updates. Workstations and other servers then download the approved updates from the SUS Server.

SUS does a relatively good job, but it does have some shortcomings. The biggest shortcoming is that SUS only updates Windows. Microsoft is currently beta testing a replacement called the Windows Update Service (WUS) that will handle patch management for other products such as Microsoft Office and Exchange Server. You can get a beta copy of WUS from Microsoft.

Even WUS has its limitations though. WUS will not update non-Microsoft products. For that, you will have to use something like Microsoft's SMS Server or GFI's LANguard Network Security Scanner.

Switching PCs

Of all of the change management features built into Windows, my favorite is the way that Windows can be configured to automatically move a user's files and settings with them when they get a new PC. The reason why I like this feature so much is because at one of the places where I used to work, the game of "musical PCs" reached epidemic proportions. The company had very heavily fluctuating staffing requirements. As departments grew or shrunk, they were moved to the part of the building that would best accommodate a department of that particular size.

The other reason why switching PCs became such an epidemic was because of a game of one-upmanship. Any time that a new employee was hired, a PC was ordered for that employee. The company had a policy of buying the fastest PCs available, so the most recently ordered PCs were almost always faster than those ordered a few months ago. What would happen though is that the managers of the various departments would always take the newest PC for themselves. The manager's "old" PC would then go to the assistant manager. The assistant manager's machine would go to the supervisor, and so on. Basically, this meant that any time a new computer arrived, twenty or thirty people would end up switching computers.

At that time, all of the users saved their files on their local hard drive. Therefore, every time someone switched PCs, all of their files, settings, and applications had to be manually transferred to the new PC. The IT staff also had to take care to remove each user's files off of their old PC in order to protect privacy. The company eventually had to hire three techies whose only job was to move PCs each day.

Obviously, the situation that I described above is excessive and is a great example of poor upper management. However, even in a normal company people do sometimes switch computers. An employee might get a new system to replace an obsolete one, or an employee might transfer to a different department. Even if you don't have to move PCs every single day, it can still be a really big job to move all of a user's files and settings off of one PC and onto another.

Although moving a user from one computer to another can be a huge job, it doesn't have to be. Windows Server 2003 allows you to configure user accounts so that a user's files and settings follow the user from one machine to another.

Part of the process is related to the way that Windows makes use of user profiles. As you probably know, any time that a user logs into a machine that's running Windows XP, Windows creates a profile directory for the user at C:\Documents and Settings. A user's profile folder stores things like the user's desktop, documents, Internet Explorer favorites, and anything else that's user specific. Normally, a user's profile folder is specific to each individual computer. For example, if a user logged onto a computer and placed an object on the Desktop, that object would only appear on that one PC's desktop.

You can however make a user's desktop, files, and settings follow a user from machine to machine through the use of roaming profiles. As you might already know, roaming profiles have been around since the days of Windows NT. The idea behind roaming profiles is that a user's desktop, files, and settings are stored on a server. That way, when a user logs in, their desktop, files, and settings follow them, regardless of where they log in at.

Roaming profiles work relatively well, but they do have some shortcomings. To understand these shortcomings, you have to know a little bit about how roaming profiles work. When a user logs in to a workstation, a local profile folder is created on that workstation (assuming that it doesn't already exist). The contents of the user's roaming profile are then copied from a network share to the local profile folder. The user then works off of the local copy of the profile until they log off. At log off, anything in the local profile folder is copied to the network copy of the profile (assuming that the networked profile isn't marked as being a mandatory profile).

There are two main problems with the way that roaming profiles work, but Windows Server 2003 provides solutions to both problems. The first problem is that log on and log off times can be excessively long. Remember that every time that a user logs on or off, the contents of the profile are copied to or from the network. If the user happens to have a few large files in their profile folder, it can cause the process to take a long time. I have personally witnessed logins that have taken almost an hour to complete.

Windows Server 2003 does a couple of things to get around this problem. First, it doesn't copy the contents of the user's Internet Explorer cache as a part of the profile. This alone saves a lot of time. The other thing that Windows Server 2003 offers is a folder redirection option in the Group Policy. The idea is that you can tell Windows that certain portions of a user's profile should remain on the network at all times rather than being copied to the local machine at login and then back to the network at log off. You can redirect the user's application data, desktop, My Documents folder, and Start menu. Redirecting these particular items can save a great deal of time during login and log off. If you are interested in experimenting with folder redirection, you can find the settings in the group policy at User Configuration | Windows Settings | Folder Redirection.

The other major problem with roaming profiles is that if the server containing the profiles were to fail, then no one would be able to access their files until the server was brought back up. Furthermore, since the server would also contain the user's start menu, desktop, application settings, and things like that, the users may not be able to access certain applications until the server is brought back online.

The solution to this problem is to take advantage of the Distributed File System (DFS). The idea behind doing this is that you can create a DFS root that contains all of the user's profiles. You can then create replicas of the root on other servers. This accomplishes a few different things. First, it gives you a degree of fault tolerance. If the server containing the primary DFS root were to fail, the users would be unaware of the failure because they would be automatically redirected to a replica server. This prevents users from experiencing down time during a server failure. Another thing that using a DFS accomplishes is that it allows you to take one of the DFS servers offline for maintenance during the day without disturbing anyone. Finally, having multiple DFS replicas boosts performance because the workload is automatically balanced between servers rather than the entire workload being placed on a single server.

Change can be good

As you can see, change management is nothing more that keeping your network's operating systems and applications current with as little administrative effort as possible. Windows Server 2003 contains several tools that will help you to perform effective change management. Once you understand what these tools are, you can use them to allow Windows Server 2003 be an agent of change in your organization.