Migrating from Microsoft Proxy Server 2.0 | The Best Damn Firewall Book Period

If you work in an organization that already has a Proxy Server 2.0 installation in place, you probably don't want to redo all the configuration settings that you have so carefully applied to your three-year-old deployment. The good news is that just about every rule you created in Proxy Server 2.0 will be successfully migrated, depending on the type of migration you perform.

What Gets Migrated and What Doesn't

When you migrate your Proxy Server 2.0 configuration to Windows 2000, virtually all components of your configuration will be ferried over to ISA Server. These include:

Proxy Server Domain Filters (ISA Server Rules)
Proxy Server Network Settings (ISA Protocol Rules)
Proxy Server Monitoring configuration (ISA Server Performance Monitor)
Proxy Server Cache Configuration (ISA Cache Configuration)

All these elements will be brought over, depending on how you perform the migration in relation to your enterprise array configuration. The ways in which rules and other configuration elements are migrated depends on the user who performs the migration and the Enterprise Policy settings, if any, for that particular server or array.

Table 23.2 shows what happens during the migration from Proxy Server 2.0 to ISA Server when the enterprise array setting is set to Use Array Policy Only.

Table 23.2: The "Use Array Policy Only" Effect on Migration from Proxy Server 2.0
Enterprise Policy Setting	Enterprise Administrator Performing Upgrade	What Gets Migrated
Use Array Policy Only	Doesn't matter	All proxy server rules are migrated to the array policy

Note that when the enterprise policy is set to use the array policy only, it doesn't matter whether you are a domain admin or an enterprise admin. All the proxy server rules will be migrated to the array because, when only the local array policy is used, there are no interactions with the enterprise policy, so there's no impact on the permissions related to the enterprise policy and how it applies to a particular array.

Let's look at an example when the enterprise policy setting is configured to the Use Enterprise Policy Only setting (Table 23.3).

Table 23.3: The "Use Enterprise Policy Only" Effect on Migration from Proxy Server 2.0
Enterprise Policy Setting	Enterprise Administrator Performing Upgrade	What Gets Migrated
Use Enterprise Policy Only	Yes	All proxy server rules are migrated, and enterprise policy is set to Use Array Policy Only
Use Enterprise Policy Only	No	None of the Proxy Server rules are imported, andthe new array uses the enterprise policy only

Note that when the user running the upgrade is an enterprise administrator, all the proxy server rules are migrated and the upgrade routine changes the enterprise policy to Use Array Policy Only to allow for the migration of the configuration settings from Proxy Server 2.0. It must do this in order to bring over the allow rules you have configured in Proxy Server 2.0.

This is not the case when the person performing the upgrade is not an enterprise administrator. Since the non-enterprise admin is not able to influence enterprise policy, none of the Proxy Server 2.0 rules will be imported. That's because the policy setting in this scenario is configured to use the enterprise policy only, and therefore the Setup program will not allow the domain admin or local admin security account to change the enterprise policy to Use Array Policy Only, if only temporarily for the upgrade process.

In the next scenario (see Table 23.4), we see what happens when the enterprise policy setting is configured to Use Enterprise and Array Policy.

Table 23.4: The "Use Enterprise and Array Policy" Effect on Migration from Proxy Server 2.0
Enterprise Policy Setting	Enterprise Administrator Permission	What Gets Migrated
Use Enterprise and Array Policy	Yes	All proxy server rules are migrated, and the enterprise policy configuration is set to Use Array Policy Only
Use Enterprise and Array Policy	No	Only deny rules are migrated to the array policy; allow rules are dropped

In this case, when the user performing the upgrade is an enterprise admin, the enterprise policy is changed to Use Array Policy Only so that the Proxy Server 2.0 rules can be migrated to the ISA array policy. You can then change the enterprise policy back to Use Enterprise and Array Policy after the migration is completed. Be sure to back up the migrated array policy after the upgrade and before the change policies settings to enterprise and array policy, because you won't be able to change back.

If the user performing the upgrade is not an enterprise admin, only deny rules are migrated. This puts you at a disadvantage in not migrating all your old settings and does not afford you the opportunity to use them in an array, should you decide not to use an enterprise policy.

Functional Differences between Proxy Server 2.0 and ISA Server

Proxy Server 2.0 and ISA Server have a good deal in common, but some of the things that you're used to doing in Proxy Server 2.0 are done a little differently with ISA Server. Some of the differences between the two include:

IPX/SPX is not supported.
The Web Proxy Service listens on Port 8080 and Web proxy client implications.
The Winsock client is not required on published servers.
The Web cache is stored as a single file.
There is no SOCKS service.
The firewall client doesn't support 16-bit operating systems.
There are incompatibilities between ISA and IIS on same machine.

ISA Server Does Not Support IPX/SPX

Proxy Server 2.0 included the ability to access the Internet while network clients ran IPX/SPX as their transport protocol. This capability has not been extended to ISA Server. When Proxy Server 2.0 was released, Novell NetWare networks were not considered legacy. In order to successfully integrate into a mixed Windows NT/NetWare network, support for an IPX gateway was important. The versions of NetWare in use at that time required IPX/SPX.

However, NetWare's market share has profoundly diminished as Windows NT and now Windows 2000 have grown in popularity. Additionally, current versions of NetWare (5.0 and up) can run on pure IP. With the ascendance of TCP/IP as the networking protocol, Microsoft decided to drop IPX/SPX support in ISA Server.

If you are running Proxy Server 2.0 on an IPX network, you need to upgrade the networking infrastructure to support TCP/IP prior to installing ISA Server.

Web Proxy Service Users Port 8080

The Web Proxy Service in Proxy Server 2.0 listened for Web protocol requests on the server's internal interface port 80. It did so because the Web Proxy Service in Proxy Server 2.0 was actually an ISAPI plug-in to the WWW Service included with Internet Information Server, and the WWW service listened on port 80. This made the Web Proxy Service dependent on the WWW service configuration. The Web Proxy Service included with ISA Server is not dependent on IIS or WWW Service configuration parameters.

ISA Server Web proxy clients need to send their requests to TCP port 8080 on the internal interface of the ISA server (by default). This does have some advantages, because the Autodiscovery mechanism uses TCP port 80 on the internal interface of the ISA server. It is important to note that you should not host a Web site on the external interface of the ISA server on TCP port 80, because the Web Proxy Service's Listener, which is used to listen for requests made for servers on the internal network that have been published, uses this port number. However, you do have the option of publishing a Web site hosted on any other available port on the internal interface if you need to run a Web site on the ISA server.

Warning

You cannot run Web sites off port 80 on the internal interface of the ISA server. Autodiscovery allows firewall and Web proxy clients to obtain valuable configuration information automatically. ISA Server allows firewall and Web proxy clients to obtain this information via port 80 on the internal interface.

However, our advice is to run no Web services on the ISA server and instead take advantage of publishing internal servers or providing Web services via a perimeter network. If you must use the ISA server to provide Web services, bind to the Web site an alternative port number that is not being used by any other services.

Because of this change in the Web Proxy Services internal listening port, you have to change either the default internal Web proxy listener port number or the configuration of the Web proxy clients to send requests to port 8080 on the ISA server.

You can manually change this information on all the Web proxy clients, but that could be a time-consuming and administratively expensive proposition. A better approach is to configure your DNS and/or DHCP server to provide the address of the ISA server, and then allow the ISA server to provide configuration information automatically to the network clients.

Published Servers Do Not Require the Winsock Client

One of the sweetest features of ISA Server is that you do not need to configure servers that you want to publish to the Internet as Winsock proxy clients. In Proxy Server 2.0, you often had to monkey around with the wspclnt.ini settings on your published servers. Sometimes the configuration settings worked, but more often they didn't, at least not until after you spent an enormous amount of time trying to figure out what was wrong with your settings. When you publish a DNS server, a mail server, or a database server with ISA, you do not need to configure tiresome text files and cross your fingers. The only requirement to make server publishing work correctly with ISA Server is that you configure the published servers to be secure NAT clients. Since setting up a secure NAT client is a no-brainer, you'll find the task of publishing internal servers to Internet clients easier than you ever imagined.

The Web Cache Is a Single File

Proxy Server 2.0 saved the Web cache to the file system. That meant you could easily collect tens of thousands of discrete files that needed to be managed by the NTFS file system.

Even though the NTFS file system is quite efficient, the large number of files did cause a perceptible performance hit for Web cache access times. The excessive number of files became even more problematic when you performed routine maintenance duties such as a nightly virus check, disk defragmentation, or searches of the hard disk for particular files.

ISA Server has solved this problem by saving the Web cache to a single file. The file is saved with the .CDAT file extension stored in a folder named urlcache. One .CDAT file is created on each drive you configured to store the Web cache. More than one .CDAT file can be created on a drive if your cache size is larger than 10GB, since one .CDAT file is created for each 10GB of cache file size. For example, if you created a cache file of 15GB on drive D:, there would be one 10GB .CDAT file and one 5GB .CDAT file on that drive.

No More SOCKS Proxy Service

If you ran the SOCKS Proxy Service and configured access rules for SOCKS proxy clients on your Proxy Server 2.0, you won't be able to configure selective rules for those clients in ISA Server. This is because ISA Server does not have a SOCKS Proxy Service.

ISA does support SOCKS version 4 clients via the SOCKS application filter. Machines that ran as SOCKS proxy clients in Proxy Server 2.0 must be configured as secure NAT clients when connecting to ISA Server. The SOCKS Application Filter intercepts the SOCKS requests on port 1080 and forwards the requests to the Internet. You can control access for these clients as you would with any other secure NAT client.

Incompatibilities between ISA and IIS on the Same Machine

Proxy Server 2.0 was highly integrated into IIS, so you did not have to worry about any potential incompatibilities between the two. However, you have to make some changes to your IIS configuration prior to upgrading a Proxy Server 2.0 installation to ISA Server.

When you upgrade from Proxy Server 2.0, you must take into consideration the IIS configuration. As discussed earlier, the best course of action is to not run Web services on your ISA server and to uninstall IIS completely. However, you might not have this option.

If you must run a Web server from the same machine running ISA, make sure that no Web sites listen on port 80 of either the internal or external interface. As we said earlier, port 80 on the external interface is used by the Web Proxy Service Listener, and port 80 on the internal interface is used by the ISA Autoconfiguration publishing system.

Other IIS services could find themselves at issue with ISA Server if you plan on publishing internal servers to the Internet. If you want to publish internal mail servers, you cannot run the IIS SMTP Service on port 25 of the ISA server, because the publishing rule will use the external interface port 25 for publishing the internal SMTP server. In the same fashion, you cannot run the IIS NNTP Service on the external interface of the ISA server if you want to publish an internal NNTP site, because the published server needs to use the default port number for the service on the external interface, which is 119.

Note

When publishing internal servers to the Internet, you cannot configure ISA Server to remap ports. If a published server is configured to listen on a particular port number, the request will be forwarded to the same port number on the internal server. This setup prevents you from publishing internal servers by having them listen on alternate port numbers on the external interface.

An alternative is to change the listening ports on the IIS Services to an alternative number so that the published services can use the default port numbers. The changes to the listening ports can be made in the Internet Services Manager console.

Learn the ISA Server Vocabulary

If you are upgrading from Proxy Server 2.0 to ISA Server, you are probably already comfortable with the vocabulary of Proxy Server 2.0. It will be easier for you to make the transition if you learn the "new language" of ISA Server.

Table 23.5 includes some terms that mean the same thing in Proxy Server 2.0 and ISA Server.

Table 23.5: Translating Proxy Server 2.0 to ISA Server
Proxy Server Term	ISA Server Term
Web Proxy Service routing rules	Routing rules
Packet filters	Allow or block packet filters
Winsock permissions	Protocol rules
Publishing properties	Web publishing rules
Domain filters	Site and content rules

Upgrading Proxy 2.0 on the Windows 2000 Platform

Performing the actual migration from Proxy Server 2.0 to ISA Server is relatively easy. However, if you are going to install Proxy Server 2.0 directly onto a Windows 2000 machine, you must to use a special installation file called msp2wizi.exe that can be downloaded from the Microsoft Proxy Web site at www.microsoft.com/proxy.

However, there are a couple of things that you should do prior to beginning the migration:

Back up your Proxy Server 2.0 settings.
Stop all Proxy Server 2.0 services.

You should back up your Proxy Server 2.0 settings in case the ISA installation fails and you need to return to Proxy Server for some reason. You can back up the Proxy Server 2.0 configuration files from the Properties sheet of any of the Proxy Server 2.0 services. Perform the following actions to back up Proxy Server 2.0:

Start the Internet Services Manager.
Right-click one of the services, and click the Properties command. In the services' Properties dialog box, click the Server Backup button, as shown in Figure 23.32.

Figure 23.32: The Services Dialog Box
Type the complete path to the file that contains the backup information, as shown in Figure 23.33. Do not include the filename. The file will be saved with the name MSP*.mpc, where the wildcard will be replaced with the data. Click OK, and the text-based backup file will be saved to that location.

Figure 23.33: The Backup Dialog Box

After the configuration, it's a good idea to copy the files to another location for safekeeping. You do not need to keep the backup on the same machine, because no utility will allow you to roll back from ISA Server to Proxy Server once the migration is completed. You would have to uninstall ISA Server, reinstall Proxy Server 2.0, and then restore your settings from the backup.

You also need to stop all Proxy Server-related services prior to the migration. Type the following commands to stop the services:

net stop wspsrv net stop mspadmin net stop mailalrt net stop w3svc

If everything works the way it's supposed to, you should see something like the screen shown in Figure 23.34.

click to expand
Figure 23.34: Stopping Proxy Server 2.0-Related Services

After stopping these services, you can begin the ISA Server installation process as we did earlier. Everything about the installation is the same, except for two dialog boxes related to the upgrade process itself. The first upgrade-related dialog box is shown in Figure 23.35.

click to expand
Figure 23.35: Information Box Regarding Upgrading Proxy Server

When the ISA Server installation routine detects that Proxy Server 2.0 was installed on the same machine, it will tell you that an older version of ISA Server is on the machine. Well, this isn't exactly right, but you know what it's trying to say. When you are performing the upgrade, you want to install the files into the same folder.

Note

If you install the files into a different folder, you will be able to keep the original Proxy Server 2.0 files on your machine, although they won't be of much use to you because you can't run both Proxy Server 2.0 and ISA Server at the same time and you can't switch back and forth between the two.

The second upgrade-related dialog box is a little more accurate, as you see in Figure 23.36.

click to expand
Figure 23.36: Proxy 2.0 Migration Dialog Box

Since you want to migrate your Proxy Server 2.0 settings to the ISA Server, click Yes in this dialog box. If you want to install ISA Server without migrating your Proxy Server 2.0 settings, you can click No and the installation routine will ignore all settings from your old configuration. Keep in mind our earlier discussion regarding how the migration is affected by the group membership of the logged-on user and the enterprise policy settings.

Upgrading a Proxy 2.0 Installation on Windows NT 4.0

If you are planning to upgrade your Windows NT 4.0 Server that has Proxy Server 2.0 installed and then migrate your Proxy Server 2.0 settings to ISA Server, you'll need to know how to handle the upgrade to Windows 2000 while preserving your Proxy Server 2.0 settings.

If you are upgrading your Windows NT 4.0 Server with Proxy Server 2.0 installed, you are likely to run into one of two scenarios:

You have planned the upgrade with the Proxy Server installation in mind.
You forgot about Proxy Server and have already upgraded the Windows NT 4.0 machine to Windows 2000 without thinking about Proxy Server.

The following procedures will guide you in how to proceed in either situation.

A Planned Upgrade from Windows NT 4.0 Server to Windows 2000

The best way to approach an upgrade from Windows NT 4.0 to Windows 2000 is to plan the upgrade with Proxy Server 2.0 in mind. The following procedure will allow the upgrade from Windows NT 4.0 to Windows 2000 to go smoothly:

Use the Proxy Server configuration interface to back up your Proxy Server 2.0 settings as we did earlier in the chapter. To back up the Proxy Server 2.0 configuration, click the Server Backup button and select a location to store the proxy configuration files.
After backing up the Proxy Server 2.0 configuration, you need to uninstall the proxy server. Go to the Start | Programs | Microsoft Proxy Server, and click the Uninstall command. During the uninstall process, be sure to leave the proxy server log files, Web cache, and backup configuration files in place. The Uninstall program will ask if you want to save these components.
Perform the upgrade of the Windows NT 4.0 Server to Windows 2000 Server or Advanced Server.
After the machine has been upgraded, confirm that the upgrade was successful by letting the machine run for a short shakedown period. If the installation is stable, install Microsoft Proxy Server 2.0.
Once Proxy Server is installed, use the Server Restore button in the Proxy Server Properties dialog box to restore your previous configuration. You must remember the location where you stored the configuration files!

The key to this approach is that you've backed up the Proxy Server 2.0 configuration, uninstalled Proxy Server 2.0, reinstalled Proxy Server 2.0 after the upgrade to Windows 2000, and then restored the old Proxy Server 2.0 configuration from the backup you made before the upgrade.

What If You Forgot about Proxy Server?

It is possible that when you upgraded your Windows 2000 Server, you forgot about Proxy Server or realized during the upgrade that Proxy Server was installed, but you thought that you'd get around to dealing with it after the Windows 2000 upgrade was completed. If you find yourself in this position, perform the following procedure:

Run the Update Wizard (msp2wizi.exe) that you downloaded from the Microsoft Web site. Be sure that the Internet Information Server 5.0 Management console is closed before you start the update.
During the installation process, you won't be given the option to update the existing Proxy Server installation. You need to perform a fresh installation. Be sure to choose the same installation locations that you did when you first installed Proxy Server 2.0 on the Windows NT 4.0 Server. If you place the files in the same location, your previous configuration should remain intact.

Once the Microsoft Proxy Server 2.0 is installed on your Windows 2000 computer, you can access it via the Administrative Tools menu by clicking the Internet Services Manager command. You will see the Internet Information Services console as it appears in Figure 23.37.

Figure 23.37: The Internet Information Services Console

After you have installed Proxy Server 2.0, there will be three new nodes in the left pane of the Internet Information Services console: the Socks Proxy, the Web Proxy, and the WinSock Proxy. To access the configuration of any of these proxy services, just right-click any one of them and click the Properties command.

Realize that all upgrades place you in a delicate position. Even though everything should work correctly, experience tells us that whatever can go wrong with an upgrade will go wrong. Even when an upgrade appears to be successful, rarely will the program work like a fresh installation.