Many updates to support new hardware and to address some minor security concerns never even make it into Windows NT, as Microsoft is focusing on the newer server operating systems like Windows 2000 and Windows .NET, which is just around the corner. All the while, your Windows NT servers hum merrily along in the back of your server room, oblivious to their antiquity.
The time is approaching when you’ll need to retire your Windows NT servers. And since your Windows NT servers contain all of your company’s vital data, you don’t want to risk losing everything due to a poorly planned upgrade. There are several issues you’ll face when retiring a server that has been online for quite some time, such as replacing the actual server, naming issues, and size requirements.
Upgrading vs. replacing
The first thing that you must decide when phasing out an old server is whether to upgrade your old server, replace it, or do away with it completely. Unfortunately, there are no hard rules on when it’s appropriate to upgrade vs. when it’s appropriate to replace or dispose of an old server.
When trying to decide whether to upgrade or replace, you must consider whether the hardware is adequate to run a newer operating system, such as Windows 2000 or Windows .NET. Generally speaking, if your old server meets all of the recommended requirements—not the minimum requirements—for running Windows 2000 Server or Windows .NET Server, it may seem easy to upgrade the operating system rather than replace the entire server. But there are other factors to consider.
If you’re still using Windows NT 4.0, then it’s probably safe to say that you’re not the type to upgrade very often, whether for budgetary or philosophical reasons. This means that you could be using your new operating system for the next three to five years. Just because your server’s hardware is adequate to handle the new operating system today, doesn’t mean it will be adequate to handle the operating system five years from now.
Remember that, over time, operating systems tend to become bloated. As you install service packs, the core operating system tends to take up more disk space and RAM. Likewise, the day-to-day usage tends to result in a large collection of unused files, such as temporary files and DLL files.
When deciding whether to upgrade or replace, you need to keep your future needs in mind. If your server is adequate for today but may not be adequate two years down the road, you don’t necessarily have to toss a perfectly good server. You could always just wait a couple of years to replace the server. You could also upgrade individual components in the server as the server’s components become outdated.
If your server doesn’t quite have what it takes to run the new operating system, you might have thought about upgrading the hardware to the point that it can run the new software. But upgrades are only effective to a point.
A good example of this was the rush back in 1999 to make all systems year 2000 compliant. The company that I worked for at the time had hundreds of computers all over the country that were out of date. Many of the old computers were 486 machines that were running Windows 3.1. Rather than requiring all of the old computers to be replaced, management decided to upgrade the computers to run Windows 98.
After the upgrade, the computers were year 2000 compliant, but in the end, the company spent thousands of dollars for a performance downgrade. Because the machines were so slow, they were replaced as soon as all of the company’s other year 2000 problems had been addressed. So the company wound up spending about $600 per machine for an upgrade and then about another $1,000 per machine to replace the computers that they had just upgraded.
Logistical problems with replacing servers
One tip I can give you about upgrading the server operating system is to make sure you’ve installed the latest Windows NT service pack prior to the upgrade. On more than one occasion, I’ve run into server upgrade problems that could have been easily prevented by simply taking the time to install a service pack.
If you’ve decided to replace the server, there are much bigger issues to contend with, the most obvious of which is moving all your data to the new server. If the server you’re replacing is a file and print server, moving the data is as simple as running a backup and then restoring the backup tape to the new server. But if the server is a database or an application server, a simple backup/restore operation isn’t going to get the job done. In addition to backing up and restoring the data, you’ll probably have to run some sort of utility such as the SQL Enterprise Manager to make sure that the database is consistent before users can use it.
As you consider your options with replacing your old server, keep in mind that replacing the server isn’t always an absolute requirement. If your server is still running Windows NT, the server may also have a relatively small hard disk, and you may be able to migrate the data from the server onto an existing server.
Another option is, if you have several Windows NT servers that you’re phasing out, you might be able to buy one really large server and roll the data from all of the old servers onto the one new server. If you decide to use this method, I recommend using a separate partition for each server’s data.
Dealing with the server name issue
Another problem that you should consider is the fact that no server is an island. Sure, in extremely small companies, there may be only one server in the entire company, but the vast majority of companies have multiple servers, each of which is connected to another.
If each server functioned completely separately, you could bring a new server online using the same name as the old server. You could then re-create the partition scheme and the share points and then restore the data files, and the users would be able to access their data as if it had been there all the time. Unfortunately, in an interconnected environment, things aren’t that simple.
A computer name tends to be used more by humans than by computers. Each computer name has an associated globally unique identifier (GUID). So if you bring a new computer online and assign it the same name as the old server, the GUID will be different. Because the GUID is different, your other servers will realize that it isn’t the server that it claims to be. Depending on your network configuration, Windows may not even allow you to use the old server’s name, which would present even more problems from a client access standpoint. Having a common GUID and server name is especially important if the server is a domain controller, because if the names are different, you could end up with authentication errors and potential SAM or AD corruption.
There are several different techniques for dealing with this problem. One technique is to just bring the new server online using a different name than the original server. By doing so, however, you must make sure that the users can access the data in its new location. Remember that universal naming conventions (UNCs) are server specific. So even if the share point name and the server’s IP address remain the same, users will not be able to locate their data via UNCs if the server name has changed. This means you must update login scripts, static drive mappings, and any batch files you might use that address the old server by name.
You may also need to update some icons on users’ desktops to point to new locations. As you can tell, it’s really tough to locate every place where a UNC was used. You should keep in mind that if you use the option of combining multiple servers into a single server, there will be no getting around having to manually update UNCs.
Unless you’re combining multiple servers into a single server, I recommend using the same name for the new server as the old server used. As I explained, this can be a little tricky because of issues with the server’s GUID. But it’s to your advantage that, while things like the SAM are GUID based, UNCs aren’t. They are truly based on the server name rather than the GUID represented by the name.
So how do you get around the whole GUID problem? Begin by taking the old server offline, unplugging it, and setting it aside. Wait about an hour so all other machines in the domain are aware that the server is really offline. Then, use the Windows NT Server Manager tool or Windows 2000’s Active Directory Users And Computers console to remove the server from the domain. This should be a fairly straightforward process as long as domain controllers remain in the domain.
If the server that you’re removing happens to be the only domain controller in the domain, you can save yourself a lot of trouble by installing Windows 2000 Server or Windows NT Server on an old PC and temporarily making the PC a domain controller. Once you’ve done this, promote the spare machine to a PDC prior to removing your other computer from the domain. While you’re switching PCs, the temporary PDC will maintain the SAM. When the operation is finished, you can make the new machine a domain controller by using the DCPROMO command. You may then remove the temporary domain controller from the domain.
Domain controller complications aside, you must next bring the new server online and assign it the same computer name and IP address as the old server. This should go smoothly because all information about the old server has been removed from the SAM. When the installation process completes, re-create the old server’s partition scheme and share points on the new server. By doing so, you’ll insure that any UNCs that reference the server will continue to work.
What if something goes wrong?
Any time you phase out an old server, there’s the chance that something could go wrong. For example, you could find that an application will run under Windows NT but not Windows 2000, or you could discover that not all data was migrated successfully. Whatever the reason, you’ve merely taken your old server offline, and it’s completely unmodified. You can always bring this server back online if necessary, but there are a few things to remember before you do.
First, any data that has been added to the new server will be lost unless you migrate it to the old server. Second, to bring your old server back to life, you’ll once again have to deal with the naming issue. This means using Windows 2000’s Active Directory Users And Computers console to remove the new computer from the domain, and then bringing the server back online. You may have to manually rejoin the domain before the server will be able to function as a part of the domain. The easiest way to do this is to have the server join another domain, and then join the original domain. Switching domains a couple of times will usually do the trick.
Make the move
Windows NT may be a stable and reliable operating system, but you can’t rely on it forever. When you decide to upgrade to Windows 2000 Server or Windows .NET Server, you need to have a replacement strategy in mind. You can upgrade your existing server or replace it with a brand new one. Once you know the implications of both strategies, you can make a decision and send Windows NT off to the retirement home.