Planning an ISA Server Deployment (Part 2)

Welcome back to the continuing series on ISA Server 2004! In this article, part two of “Planning an ISA Server 2004 Deployment”, we are going to cover server requirements necessary to actually install ISA 2004. We’ll talk about hardware requirements as well as some of the unique requirements we need to plan on when installing the software on both Windows 2000 and Windows Server 2003 platforms.

As we talked about in our last article, planning is of vital importance in an ISA Server 2004 deployment, in order to prevent having to go back and correct what may become serious problems later down the road after the install is declared a “success”. Before the CD is even inserted into the box which will become an ISA server, some considerations that must be taken into account are hardware and operating system platforms. We’ll talk about both of those issues in this article.

First, let’s look at hardware. ISA Server 2004 has a minimum set of hardware requirements, of course, as all Microsoft products do, but the minimum requirements are only established to set the low-end boundary of what a computer must have just to get ISA server installed, not necessarily to run it well. We’ll list the minimum requirements, but understand that you should always, especially in a large production environment, go with considerably more hardware than just the minimum if you want it to run right.

Microsoft says that the minimum hardware requirements for an ISA Server 2004 are: a Pentium III or compatible CPU running at least at 550 MHz, 256 MB of RAM, and an NTFS –formatted hard disk drive with at least 150MB of space available on it. Of course, if you are going to use the ISA server for content caching, you will need additional hard disk space. It should go without saying, of course, that a CD-ROM, keyboard, mouse, and VGA-compatible video adapter are also necessary to install the server.

Planning an ISA Server Deployment (Part 1)

In this two- part article in our continuing series on ISA Server 2004, we will look at a very critical part of the process, the planning phase. Planning is one of the most important parts of an ISA Server deployment, but is also the part that very few people put a lot of time and energy into. Unfortunately, failing to plan the deployment properly can lead to problems later that will cost you more in terms of time and work to go back and correct these issues. That’s why this phase is so important.

The first part of planning, which this particular article covers, is planning out the network infrastructure that your ISA Server will be a part of, and knowing exactly how it will fit into the architecture. This is critical because there are several considerations to look at before you actually bring the server online. There are several aspects of your infrastructure you will need to examine, including: network infrastructure, organizational security policies, client requirements, branch office connections, VPN structure, server publishing, partner access, fault tolerance, and the actual roll-out itself. We’ll briefly look at each one of these now:

Network Infrastructure: This involves having a comprehensive network diagram and configuration documentation that exactly lays out the way the network is built. Critical parts of the infrastructure that may affect and be affected by the ISA server rollout will be DHCP services, DNS, email services, Active Directory structure, perimeter network configuration, web servers, and any other network services that must be reconfigured to coexist with an ISA Server. You should know what protocols your company network uses, and how they should be secured as they enter and leave the network. You may have to move some services inside the DMZ, if you have one, or look at creating a DMZ if you don’t currently have one. You will need to decide how DNS is handled, and whether the ISA server will handle DNS resolution. You will also need to look at any web services that are accessed from outside your network and how they will be protected against unauthorized use. These are but a few of the considerations you will have to contend with on the network, but it depends on how your network is built and what your requirements are as to how you plan for them.

Deploying ISA Server 2004

Welcome back to the series on ISA Server 2004. So far we’ve talked about what ISA server is and does, and its functions and editions. This article will take it one step further by discussing the many different ways you can use ISA server in your network, no matter how large or small.

ISA Server 2004 can be deployed in a number of different configurations to suite your organization’s needs. Since ISA server is well suited for small, medium, and large businesses, a wide variety of deployment scenarios are possible. There are three basic deployment configurations we will discuss, and then talk about some variations on these.

The first scenario is as an internet edge firewall, probably the most common scenario. The ISA Server protects an internal network from an external one, such as the Internet. One network interface is attached to the Internet, or other untrusted network, and the internal network is attached to the second interface. There may or may not be a perimeter network between the Internet-facing ISA server and the internal network, depending upon the size of the network and the needs of the organization. The ISA server may allow internal servers to be published, such as a web server, and it may even operate as a VPN server. In any case, the ISA server serves as the only entry and exit point into the internal network from the outside world, and controls all inbound and outbound network traffic.
A second method is to deploy the ISA Server as a back-end firewall. In this case, the ISA server is one of two firewalls deployed in a demilitarized zone (DMZ) or perimeter network configuration. The front-end or Internet-facing firewall serves as initial entry point into the network. This machine may or may not be an ISA server. This firewall offers some protection for the internal network and serves as the primary protection for servers deployed inside the DMZ. The ISA server acting as the back-end firewall, on the other hand, primarily protects internal assets and allows publishing of resources outside the internal network. For example, a web server in the DMZ may require data from an SQL server that resides on the internal network. The back-end server would allow access to the SQL server from the web server inside the DMZ only, and not from any other external host. Then the web server would provide requested data to an Internet host through the front-end firewall.
Yet a third scenario would be to use an ISA server as a branch office firewall and/or VPN server. In this case, the ISA server would serve as a single entry point into a smaller, geographically separated branch office network, usually connected to the Internet with a WAN connection, and connect to another ISA server at the main office, in a site-to-site VPN configuration.

Keep in mind that when factoring in additional roles for your firewall, such as proxy or caching server, VPN server, or a remote access server, this can add variations to the complexity of the basic scenarios mentioned above. You may choose to have separate ISA servers host these roles, or combine them onto one server. Additionally, having arrays configured in each of these scenarios can both add to your deployment options and the overall complexity of the deployment, as an ISA server may also function solely as a configuration storage server for an array. The bottom line to remember here is that ISA Server 2004 is quite versatile; it can be deployed to fit the unique needs of any size organization.

With that, we’ll close out this installment. In our next article, we’ll discuss an often-overlooked, but extremely critical part of getting ISA Server 2004 up and running – the planning step. See you then!

Microsoft ISA Server Editions

Welcome back to our series on Microsoft’s ISA Server 2004. In our previous article, we talked about some of the features of ISA 2004. This time, we’ll talk about the two editions of the product and how they differ from each other and their predecessor, ISA Server 2000. We’ll also talk about the various upgrade paths from ISA 2000 to 2004.

ISA Server 2004 comes in two flavors: the Standard Edition and the Enterprise Edition. Although both offer similar features, such as the firewall, caching server, and proxy server capabilities, they differ in how they are implemented, the size of the infrastructure they are targeted for, and some advanced features. We’ll discuss the features of each and the differences between the two in this article.

ISA Server 2004 Standard Edition is the basic ISA Server package. It’s suitable for almost all networks, and is used mainly in a stand-alone environment. It can be used in small- or branch-office type of scenarios, or when you only need one ISA server installed to fulfill a specific role (such as a web proxy). It can be deployed in all of the roles previously discussed, including proxy server, caching server, and firewall configurations, or a combination of all three.

ISA Server Standard Edition differs from the Enterprise Edition in that it stores its configuration data in the local registry, instead of in a central location, such as Active Directory. This means that if you make any configuration changes that need to be applied to all of your ISA servers, you’ll have to go to each one and make the change individually. Additionally, Standard Edition does not support a centralized caching database configuration, as Enterprise Edition does when configured in an array. Each Standard Edition server has its own separate content cache.