Real World Case Study

Parker HealthNet, A Regional Healthcare Network

Parker HealthNet has decided to use Windows 2003 Terminal Services to provide applications for 5000 users at nine hospitals and thirty remote healthcare facilities. Many of their users will need to access applications from multiple client devices. For example, doctors often travel between hospitals and remote medical offices, and nurses will use terminals spread throughout many locations in hospital complexes.

A project team was assembled to create a design for the Terminal Server environment. Their design was based on the current environment as outlined in Figure 6.13.

Figure 6.13: Parker HealthNet's WAN Architecture

The project team first outlined their objectives. For the Parker HealthNet environment, several objectives were identified, including:

• Security A secure environment was needed, since most of their applications are integral to patient care and must be HIPAA compliant.

• Availability If applications were not available, patient care would suffer.

• Mobility . Many users would need to simultaneously access applications running on multiple Terminal Servers in multiple locations.

Based on their current environment and future needs, the project team was able to make several design decisions. First, they decided to place Terminal Servers locally at each of the nine hospitals. Each hospital would be configured with its own Terminal Server cluster. They decided that users would primarily access applications running on Terminal Servers installed locally in each of their own hospitals, but that there would also be some central medical applications for all users running on a Terminal Server cluster in the central datacenter. Figure 6.14 shows a typical hospital and how its users would access applications.

Figure 6.14: Typical Hospital with Terminal Server application access

Parker HealthNet migrated to Windows 2000 Active Directory two years ago, and they'll be running a Windows 2003-based Active Directory by the time the Terminal Servers are deployed. They have one Active Directory domain with separate Active Directory Sites configured for each hospital.

Once these basic design decisions were made, the project team deliberated at length on more complex questions. They were able to consolidate all of their questions into two core issues:

• Should they use mandatory profiles, flex profiles, or group policies to lock down the desktops?

• Considering that many users travel between locations, where should the master roaming profiles be located? What about the home folders?

Let's take a look at how the Parker HealthNet project team dealt with these design issues.

Issue 1. Desktop Lockdown

The major discussion around desktop lockdown was not "if" they should lock them down, but "how." Should they use mandatory profiles, flex profiles, or group policies? Initially the project team thought that they had to use group policies, but some members pointed out that mandatory and flex profiles contain the same registry data as policies. By using mandatory roaming or flex profiles, they could create locked-down template users and use those to manually create the mandatory roaming profiles.

After reviewing the options, the project team quickly threw out the pure mandatory profile option. They figured that since the flex profile was basically built on top of a mandatory profile, they could implement it across the board with very little risk. For users who don't need to customize their own environments, the flex profile works just like a mandatory profile. However, for the users who would need to customize any parts of their environments, the flex profile would allow them to do that without the "bloat" associated with standard roaming profiles.

To bolster the security offered by the mandatory components of the flex profiles, Parker HealthNet also chose to create policies and apply them to the OUs containing the Terminal Servers to further limit the capabilities of their users.

Issue 2. User Profile and Home Folder Locations

After determining which types of profiles and policies would be used, the project team needed to decide where on the network to store users' roaming profiles and home folders. The easiest way to determine this was to look at how users would access the Terminal Servers. From there, it would be easy to determine where to store user data.

The project team planned for all users across the health system to run the "standard" applications from Terminal Servers at their respective local hospitals. Additionally, many users would need to access medical records applications that would reside on Terminal Servers in the central datacenter in Hospital A. Those users would therefore need access to two Terminal Servers—one at their local site and one in the central datacenter. Generally, users would not need access to multiple Terminal Servers at different local sites.

Now that the project team knew where the Terminal Servers would be located and how they would be accessed, they needed to decide where on the network to store roaming profiles and user data. They knew that they should try to keep the data as close as possible to the Terminal Servers. They decided to create several storage locations throughout the health system, with one storage location at each of the nine hospitals. The exact data location for a specific user would depend on where that user was based. The project team appreciated the fact that just having data stored in multiple locations on the network does not mean each that user's data would be located in multiple locations. It just means users' home folders and roaming profiles would be sprinkled throughout the WAN.

For users in the remote medical offices, roaming profiles and home folders would be stored at the nearest hospital. (See Figure 6.15.) This arrangement is due to the fact that there would not be any Terminal Servers at the remote office facilities, and remote office users would access Terminal Servers located at the nearest hospital.

Figure 6.15: Roaming profile and home folder Locations

Because some users need simultaneously to access applications from Terminal Servers in the central hospital and their local hospitals, the project team needed to decide where those roaming profiles and home folders would be located. Right away they discarded any notions of using data replication to copy user profiles or home folders to multiple locations throughout the WAN. They knew that by introducing data replication, they would needlessly complicate their environment and waste money on additional storage devices and replication software.

Ultimately, the project team decided to keep the user data at the local hospital site since the medical applications that ran on the central Terminal Servers didn't require access to the users' home folders. They could enable home folder overrides for those servers. As for the profiles, it wasn't a major issue for users with sessions on those servers to load their profiles from their local hospital servers since using the flex profiles allowed the project team to limit the size of the profiles.

Once that was settled, all the project team had left to do was to decide how to deal with users that travel between hospitals. Should those users access applications from local Terminal Servers in the hospital they are visiting, or should they access Terminal Servers from their home sites?

After a brief discussion, the project team decided that traveling users would run applications off of Terminal Servers at their home sites, not the sites to which they traveled. This decision was made for several reasons:

• Easier to manage, as there would be no need for any script logic to determine from where the user was connecting.

• Easier to size the servers, as the user base for each site would be constant.

• Master copies of profiles and home folders would be stored at the same local site as the Terminal Server.

• Users could easily reconnect to disconnected sessions from any location, as the sessions would always be running in the "proper" location.

• The RDP protocol is efficient and is the preferred protocol for WAN communication. (If local Terminal Servers were used, then the RDP protocol would only be used on the local LAN, and inefficient file transfer traffic would traverse the WAN. See Chapter 3 for details.)

Parker HealthNet Implementation Summary

Ultimately, Parker HealthNet was able to successfully implement the Terminal Server environment as outlined. Though it has been only six months since they completed the implementation, patient care has been positively affected. In fact, Parker HealthNet is planning on acquiring two or three hospitals in the next 12 to 18 months, and view their Terminal Server environment as one of the key components that will allow them to quickly integrate the new hospitals into their existing business environment.