Working With Terminal Services Remote Applications (Part 3)

Introduction

In the previous part of this article series, I walked you through the process of hosting the Windows Calculator as a remote application. While that was a neat trick, I did things the quick and dirty way, in an effort to quickly show you what was possible with Terminal Service RemoteApp. In this article, I want to take a step back and show you some of the settings that I did not really get to discuss in the previous article.

The RemoteApp Wizard

Now that I have demonstrated the Terminal Service RemoteApp feature, I want to work through the RemoteApp Wizard one more time, and take more time to explain things as I go. You can launch the RemoteApp Wizard by opening the TS RemoteApp Manager, and clicking on the Add RemoteApp Programs link found in the Actions pane.

When the RemoteApp Wizard opens, click Next to bypass the wizard’s Welcome screen. At this point, you should see a list of the applications that are available for remote hosting, as shown in Figure A. You can select the check box next to any application that you want to host, or you can use the Browse button to locate the executable file for any application that is not on the list.

Figure A: Select the applications that you want to host remotely

One thing that I want to mention quickly is that by default, this list will only show you applications that have been installed for use with the Terminal Services. You can host any application on the server, but unless an application has been installed specifically for use with the Terminal Services, there is no guarantee that the application will run correctly.

If you look at the figure above, you will notice that this particular dialog box contains a Properties button. If you select an application and click this button, you will see a dialog box that tells you the application’s name and its local path. That way, you can verify that you are hosting the correct application. You can see what this dialog box looks like in Figure B.

Figure B: The application’s properties sheet provides you with detailed information about the application that you have selected

What is more important though, is that sometimes an application will be configured to use various command line switches. Clicking the Properties button gives you the chance to verify that no switches are being used in conjunction with the application when it is run locally. If any switches are being used, and you need to keep using the switch when you run the application locally on the server, then you can use the Properties dialog box to prevent command line switches from being used by those who are running the application remotely. Conversely, you can also require command line switches to be used when remote users execute the application.

After you have selected the applications that you want to host, and you have verified any existing command line arguments, click Next. When you do, Windows will show you a summary of the applications that you are about to remotely host. Click Finish, and the application will be added to the list of RemoteApp programs.

Exporting RemoteApp Settings

At this point, we could generate an RDP file for the application if we wanted to, but I wanted to take a moment and show you the export and import features for remote applications. Hosting remote applications does not tend to be quite as resource intensive for a terminal server as hosting a full blown Windows desktop, but applications still consume server resources. This is especially true if you have multiple users who are all using multiple remotely hosted applications.

Depending on the workload that the users place on the terminal server, one terminal server may not able to handle the user’s demand on its own. You may end up having to deploy multiple terminal servers in the name of scalability and fault tolerance.

If you do end up having to deploy multiple terminal servers, then you will be happy to know that you do not have to configure your remote applications separately on each server. You do have to install the remote applications on each individual server; there is no getting around that requirement. However, you do not have to manually specify which applications are being remotely hosted.

Once you have one RemoteApp server configured, you can click the Export RemoteApp Settings link that is located in the TS RemoteApp Manager’s Actions pane. When you do, Windows will display the dialog box that is shown in Figure C.

Figure C: The TS RemoteApp Manager allows you to export remote application settings to other servers

As you can see in the figure, you have the option of either specifying the name of a terminal server that you want to export the settings to, or you can export the settings to a file. If you choose to export the settings directly to another terminal server, then any RemoteApp settings that are presently configured on that server will be overwritten.

If you decide to export the RemoteApp settings to a file, then you can use the Import RemoteApp Settings link, found in the TS RemoteApp Manager’s Actions pane to import the settings into the new terminal server. Like the direct export method though, importing a settings file will cause any existing remote application settings to be overwritten.

Creating an RDP File

I showed you how to create an RDP file for a remote application in my previous article. However, I wanted to wrap things up by revisiting some of the settings that I didn’t get to talk about in the previous article.

You can create an RDP file by selecting an application from the RemoteApp Program list, and clicking the Create RDP File link, found in the System Configuration section. This will cause Windows to launch the RemoteApp Wizard.

Click next to bypass the wizard’s Welcome screen, and you will be taken to the screen that is shown in Figure D. If you look at the figure, you can see that the first option that this dialog box gives you is the location to which you want to save the RDP files that you generate. By default, RDP files are placed in the C:\Program Files\Packaged Programs folder, but the location is customizable.

Figure D: There are a lot of options that you can configure when generating an RDP file

The next section lists the terminal server that is hosting the remote application, the port number that should be used by the RDP session, and whether or not the server requires authentication. The default settings will typically work fine, but you do have the option of clicking the Change button to change these settings.

One particular situation that would require you to make a change would be if the remote applications were being hosted by a terminal server farm instead of by an individual server. In such a case, you would need to provide the farm’s fully qualified domain name.

The next section down is the Terminal Service Gateway Settings section. You would not normally have to do anything here, because gateway settings are detected automatically. Microsoft does provide you with a Change button that you can use in case the gateway settings are detected incorrectly though.

The last section is the Certificate Settings section. You would use this section if you normally use a certificate to sign the applications that you publish.

Once you have entered the desired settings, click Next, followed by Finish, and the RDP file will be generated.

Conclusion

If you have followed along and performed the steps that I have outlined in this article series, then you might have noticed that the TS RemoteApp Manager contains options for using remote applications with Terminal Service Web Access. I will show you how this works in the next part of this article series.

Working With Terminal Services Remote Applications (Part 2)

Introduction

In the first part of this article series, I talked about some of the benefits associated with using Terminal Services RemoteApp. In this article, I want to continue my discussion by guiding you through the deployment process.

Before We Begin

Before I get started, I need to point out that the Terminal Service RemoteApp feature is different from a normal Terminal Service session. Because of the inherent differences, not all Windows clients will be able to work with remotely hosted applications. Terminal Service RemoteApp only works with clients that are running Windows Vista, Windows Server 2008, Windows XP with SP2 or higher installed, and Windows Server 2003 with SP1 or higher and the new Remote Desktop Client installed.

Installing the Terminal Services

Let’s get started with the installation process. For the purposes of this article series, I am going to assume that you have already installed Windows Server 2008, and that you have joined the server to the appropriate domain.

Begin the installation process by opening the Server Manager, and selecting the Roles container. Next, click the Add Roles link, located in the Actions pane. This will cause Windows to launch the Add Roles wizard.

Click Next to bypass the wizard’s Welcome screen, and you will be taken to a screen that lists the various roles that are available on the server. Select the Terminal Services role, and click Next. Windows should now display a screen that serves as an introduction to the Terminal Services. Go ahead and click Next, and you will be taken to a screen that allows you to select the role services that you want to install. For right now, go ahead and choose the Terminal Server role and the TS Licensing Role.

For the sake of this article series, I am assuming that you do not have an existing Windows 2008 terminal service deployment in place. We are selecting the TS Licensing role, because Microsoft requires all terminal servers to be connected to a licensing server, although there is a grace period before you actually have to license your servers.

Go ahead and click Next, and you will see a warning message that tells you that any applications that were installed prior to the installation of the terminal services may not work with the Terminal Services. Go ahead and click Next to ignore this warning.

Windows will now display a screen that asks you if you want to perform network level authentication. Network level authentication is a new mechanism that allows Windows to perform user authentication before a full blown Terminal Service session is established. Network level authentication is generally considered to be a good thing, because it simplifies the authentication process and conserves server resources. Even so, only clients running Windows Vista and Windows Server 2008 support network level authentication. Therefore, you will want to carefully consider whether or not network level authentication should be enabled. For the purposes of this article series, I will be enabling network level authentication.

The next screen that you will be taken to asks you if you want to use per user or per device licensing. You can choose either one, but the option that you choose must correspond to the type of Terminal Server licenses that you have actually purchased.

Click Next, and Windows will ask you which users and groups should be allowed to connect to the terminal server. For now, just click Next to accept the defaults.

You will now see a screen asking you to make a decision about the discovery scope. What this means is that you have to decide whether your licensing server should only service terminal servers that are members of the same domain as the licensing server, or if you want the licensing server to service the entire forest. Once again, you are going to have to select the option that is the most appropriate for your own organization, and then click Next.

At this point, the wizard should display a summary of the installation options that you have chosen. I recommend that you take a moment or two to read over the installation summary just to make sure that the correct options have been selected. After doing so, click the Install button. Windows will now install the requested services. When the installation process completes, click the Close button. You will now be prompted to restart your server. Go ahead and click Yes to reboot the server.

RemoteApp

Now that we have got a basic Terminal Service deployment established, I want to give you a quick preview of what RemoteApp can do. In the next part of the series, I will go back and do some fine tuning and show you some other options for application hosting.

In the interest of simplicity, let us start out by hosting the Windows Calculator. To do so, click the Start button and choose the Administrative Tools Terminal Services TS RemoteApp Manager options from the Start menu.

When the RemoteApp Manager starts, select the Add RemoteApp Programs link from the Actions menu. When you do, Windows will launch the RemoteApp Wizard. Click Next to bypass the wizard’s Welcome screen, and you will be taken to a list of the applications that are installed on your terminal server. Select the check box corresponding to Calculator, and click Next, followed by Finish. You should now see the Windows Calculator added to the list of RemoteApp Programs, as shown in Figure A.

Figure A: The Windows Calculator has been added to the list of RemoteApp Programs

When you select the listing for the Calculator, a number of additional options become available on the Actions pane. Click the Create .RDP File option. This will cause Windows to launch the RemoteApp Wizard.

Once again, click Next to bypass the wizard’s Welcome screen. You should now see a screen that asks you to enter a bunch of different options related to the remote application. Our goal for right now is to simply try out a remote application, so change the Location to Save the Package field to point to a network share that is accessible from a client machine. Do not worry about any of the other settings for now. I will address them later in this series.

Click Next, followed by Finish, and Windows will create a custom RDP file and place it into the location that you have specified. An RDP file is a Remote Desktop file. RDP files are normally used to establish Terminal Service sessions with remote machines, but in this case, the RDP file is application specific. If we open the RDP file from a client machine, the client will launch the Calculator (keep in mind that right now the Administrator is the only user who has access to the Calculator). If you look at Figure B, you can see that the Calculator appears to be running locally. The only indication that it is a hosted application is the word Remote in the bar at the bottom of the screen.

Figure B: This is what a RemoteApp looks like when it is running

Conclusion

In this article, I have shown you the basics for hosting an application. In the next part of this article series, I want to take a step back, and show you how to fine tune the application hosting experience.

Working With Terminal Services Remote Applications (Part 1)

Introduction

Back in the fall of 2006, I wrote an article for this site regarding a new Windows Server 2008 feature called Terminal Services Remote Programs. At the time that I wrote that article, Windows Server 2008 was still in beta testing. Since that time, Microsoft has renamed Windows Terminal Services Remote Programs to Terminal Service RemoteApp. There have also been some other changes in regard to how this feature works. That being the case, I wanted to revisit the topic and discuss Windows Server 2008’s Terminal Service RemoteApp feature.

What is Terminal Service RemoteApp?

Over the past couple of years, a lot of software publishers have been experimenting with offering hosted services. The basic idea behind a hosted services architecture is that an organization does not have to purchase licenses for software applications or have the hassles of installing or maintaining those applications. Instead, an ISP or a software vendor leases the applications to the organization. The application actually runs on the service provider’s servers, and users interact with the application over the Internet.

I have to tell you that I am not exactly a big fan of hosted services. Leasing applications is almost always more expensive in the long run, because the sum total of all those monthly payments eventually exceeds what it would have cost to simply purchase the software licenses.

There are some other drawbacks as well. For starters, hosted services takes an application’s configuration out of an organization’s direct control, and I have also known of several situations in which network administrators were put out of a job because the companies that they work for decided to outsource all of their applications to a hosting provider.

Even if job security and total cost of ownership are not issues for you though, there is one major compelling argument against the use of hosted services. If your Internet connection goes down, then nobody can access to the hosted applications. Of course Internet service is more reliable in some areas than others, but my ISP drops my connection all the time. I can’t imagine making access to my mission critical applications dependent on my ISP’s ability to maintain my Internet connection.

Even though I am not particularly fond of hosted services, the truth is that nobody would use hosted services if there were not some kind of benefit to it. The primary benefit is that the service provider takes care of all of the application maintenance for you.

So what does all of this have to do with Terminal Service RemoteApp? Well, Terminal Service RemoteApp is similar to the software that the hosting providers use to provide hosted services to their clients. Since it comes with Windows Server 2008, Terminal Service RemoteApp essentially allows you to bring the application hosting in house rather than outsourcing it to a service provider.

The Benefits of Using Terminal Service RemoteApp

At first, the thought of hosting your applications in house using a similar method to what the hosting providers use probably sounds a little bit counterproductive. After all, taking this approach to distributing your applications is usually quite a bit more complex and expensive than just installing applications directly onto each user’s workstation. Even so, there are quite a few benefits to using Terminal Service RemoteApp. Many of these benefits are things that you just don’t get if you install the applications locally on each individual workstation or if you outsource your applications to a hosting provider. In my opinion, using Terminal Service RemoteApp gives you the best of both worlds. In the sections below, I will explain some of these benefits.

Seamless Access

Probably the coolest thing about Terminal Service RemoteApp is that application access is completely seamless to the end users. Users do not need to open a Terminal Service session in order to access remotely hosted applications. Instead, Terminal Services RemoteApp provides the illusion to users that the applications are installed locally. Hosted applications can reside alongside applications that are installed locally, and a user would be hard pressed to tell the difference between them.

What this means for you is that you won’t have to spend time training users on how to access hosted applications, because users typically won’t even realize that the applications are hosted. The fact that hosted applications can run alongside locally installed applications means that you can make the transition to application hosting gradually. You don’t have to move all of your applications over to a hosted environment overnight (or at all for that matter).

Centralized Application Management

Just as the primary benefit to using a hosted services provider is ease of management, easier application management is also the main benefit to using Terminal Service RemoteApp.

There was a time when application management was not such a big deal. Applications were installed, and were never touched again until it was time to upgrade to the next version. Today though, almost every application publisher releases application patches on a regular basis. Testing all of these patches and pushing them out to all of your workstations can be a huge task.

Using Terminal Service RemoteApp does not free you from having to keep your applications up to date, but it does make the job a lot easier. Hosted applications are centrally located, so you only have to worry about maintaining a single copy of each application, rather than keeping every single workstation up to date.

Ease of Management for Branch Offices

Terminal Service RemoteApp is ideally suited to organizations that have branch offices, but who do not have a dedicated IT staff in those branches. Using Terminal Services RemoteApp allows administrators to maintain all of the applications from the corporate headquarters, so that the IT staff does not have to make a trip to the branch offices to perform routine application maintenance tasks.

Better Use of Server Resources

Normally, a Windows Terminal Server provides users with a full blown Windows environment. Of course providing each user with a separate instance of an entire operating system consumes a lot of server resources. Hosting applications on a terminal server still requires a considerable amount of server resources, but not as much as if the server were also hosting the Windows operating system.

Coexistence of Otherwise Incompatible Applications

One often overlooked benefit to using Terminal Service RemoteApp is that it allows for the coexistence of otherwise incompatible applications. For example, Microsoft Office is designed so that only one version of Office can be installed at a time. Even so, I know of some corporations that have a business need for running multiple versions of Office. Since hosted applications are not actually installed on workstations, it becomes possible for users to run multiple versions of Microsoft Office, or to run otherwise incompatible applications.

Anywhere Access

My personal favorite benefit to using Terminal Service RemoteApp is that it allows users to access hosted applications from anywhere. With the right components in place, users could conceivably access hosted applications from their laptops while traveling, from their home computers, or even from a Windows Mobile device.

I am in the process of writing a book on telecommuting that will be available sometime in the early summer of 2009, and using Terminal Service RemoteApp to provide access to applications while on the go will be one of the topics that the book covers in depth.

Conclusion

These are just some of the benefits associated with using Terminal Service RemoteApp. In the next article in this series, I will begin showing you how to install and configure this new feature.

High Availability and Disaster Recovery for Exchange Servers - A Comparative Analysis

Email is becoming ubiquitous and has become the standard tool for communication in many enterprises, big and small. Microsoft is the dominant player in the messaging platform market through its Exchange Server. Enterprises are clearly choosing the reliability, scalability, and performance of Exchange, combined with the feature-rich Microsoft Outlook and Outlook Web Access clients and built-in collaboration services for workflow and other applications.

Email has become a mission-critical application for most businesses today and it has long been a challenge to backup and restore email information. If a crash occurs and if the data is not restored, it can have devastating consequences for a business. So it is imperative for companies to effectively backup and recover data and protect them from huge losses in productivity and downtime.

High Availability Solutions for Exchange Servers



Failover Clustering

Microsoft Clustering enables users to prevent hardware failures by stringing redundant hardware, called nodes, together through a central cluster manager that coordinates load balancing and data activity. Typically, nodes share common storage space and have the capability of picking up load off of a node that goes down due to hardware or software malfunction. There are two types of cluster environments—active/active and active/passive. In the former, every node in the environment is live and capable of processing requests. When one active node goes down, the others simply process more requests as the load is evenly dispersed across the remaining nodes. In the latter, there is a single active node that processes all incoming requests. Upon hardware or software failure in the active node, the passive node is immediately and automatically brought up by the cluster manager to take over the normal function of processing data requests. In this way, hardware exposure is mitigated through physical hardware redundancy.

Microsoft Exchange Server supports both active-active and active-passive cluster environments. Exchange Server Clustering provides high availability by protecting against a node failure. However, it does not prevent against storage failures. Given the size of typical cluster environments, multiple hard disks are used to build large storage arrays. In Network and System Administration, when large numbers of any one device are used, failure is expected. When a hard disk fails, application disruption is unavoidable, as all the nodes in the cluster could be using that one particular disk as shared storage which contains all files, including Exchange Server database files. As protection against this particular failure, RAID configurations are common. However, from a performance standpoint, this significantly slows down I/O in the subsystems due to writing the data to multiple disks at the same time. Administrators have to balance such performance degradation and understand that this particular implementation has limitations. Again, the RAID option is to protect against any hard disk failure but it cannot prevent site disasters.

In direct contrast to this storage dependency, using other replication approaches prevent against hardware, software and storage failures. Failover servers are normally installed on unique, usually geographically independent, Exchange Servers which serve as a barrier to failures of any type.

Exchange Server Clustering environments are more cost-intensive compared to the Standby option. The primary reason for this is the high hardware and software requirements. Clustering requires Windows NT Enterprise Edition, Windows 2000 Advanced Server or Windows 2003 Enterprise Edition and Exchange Server Enterprise Edition. Additionally, it only supports hardware listed on the Microsoft Hardware Compatibility list. On the other hand, a Standby or Failover server does not have any special hardware requirements and is simply a software solution to meet disaster recovery needs. As an additional cost, LAN connectivity is required between the Exchange Server cluster nodes to send and receive what is called a heartbeat signal, among other communications. This signal is used by each node to determine if other nodes are still available. In case any node is not available the remaining nodes take over. With Standby, LAN or WAN network connectivity will work to replicate Exchange Server mailboxes. The speed of this process is directly related to the size of the mailboxes and network bandwidth.

File or Block Level Replication

Different kinds of replication techniques can be used to replicate data between two servers both locally and remotely. In block level, replication is performed by the storage controllers or by mirroring the software. In file-system level (replication of file system changes), the host software performs the replication. In both block and file level replication, it does not matter what type of applications are getting replicated. They are basically application agnostic, but some vendors do offer solutions with some kind of application specificity. But some of the disadvantages are:

Typically, identical hardware/software in both production and replicated servers are needed.

Possibility of virus/corruption getting propagated from production server to replicated server.



Exchange 2007 Built-in High Availability Features

Exchange Server 2007 includes four features that provide high availability for Mailbox servers: Local Continuous Replication (LCR), Cluster Continuous Replication (CCR), Single Copy Clusters (SCC) and Standby Continuous Replication (SCR).

- Local Continuous Replication (LCR): LCR is a single-server solution that uses built-in asynchronous log shipping technology to create and maintain a copy, or replica, of a storage group on a second set of disks that are connected to the same server as the production storage group. LCR provides log shipping, log replay, and a quick manual switch to a secondary copy of the data.

- Cluster Continuous Replication (CCR): CCR is a clustered solution that uses built-in asynchronous log shipping technology to create and maintain a storage group replica on a second server. CCR is designed to be either a one or two datacenter solution, providing both high availability and site resilience.

- Single Copy Clusters (SCC): SCC is a clustered solution that uses a single copy of a storage group on storage that is shared between the nodes in the cluster. SCC is very similar to clustering in previous versions of Exchange Server, with some significant changes and improvements.

- Standby Continuous Replication (SCR): SCR is designed for scenarios that use or enable the use of standby recovery servers. SCR enables a separation of high availability and site resilience. SCR can be combined with CCR to replicate storage groups locally (using CCR for high availability) and remotely in a secondary site (using SCR for site resilience).

These high availability features provide good functionality but one has to be an experienced user of Exchange server to implement them. Also, here are some of the constraints one will face when implementing the built-in high availability of features of Exchange 2007.

- Exchange Server 2007 runs on a 64-bit machine and hence costs more.

- For best performance, it is recommended that Active Directory Domain Controllers also run on a 64-bit machine, but it is not mandatory.

- No support for Exchange 2000 and Exchange 2003.

- The replicated server is in a passive mode and cannot be accessed for reporting, monitoring and archival purposes.

- It cannot create replication for all storage groups at one time.

- It is a must to have only one mailbox store in a Storage Group, otherwise Exchange 2007 Replication will not work.

Mailbox Replication Approach

In this approach, the replication is done at a mailbox level and it is very application specific. One can pick and choose the mailboxes that need to be replicated. One can set up a granular plan for key executives, sales and IT people, in which the replication occurs more frequently to achieve the required Recovery Point Objective (RPO) and Recovery Time Objective (RTO). For everyone else in the company, another plan can be set up where the replication intervals are not that frequent.

Another advantage of this approach is that the replicated or failover server is in an Active mode. The failover server can be accessed for reporting and monitoring purposes. With other replication approaches, the failover server is in a Passive mode and cannot be used for maintenance, monitoring or reporting purposes.

Backup and Replication

Some solutions offer both backup and replication as part of a single solution. In this case, the backup is integrated with replication and the users get a two-in-one solution. Considered two-tier architecture, these solutions consist of an application and agent environment. The application server also hosts the network share that stores all the backup files. The files are stored on this network share and not on any particular target server so as to prevent loss of backup files. If the target server goes down, users would like to continue to access their backup files in order to rebuild the target server with as little downtime as possible.

Figure 1

The mailboxes will be backed to the backup server and then replicated to the remote failover server. The full backup and restore is done first and then only the changes will be applied through incremental. For restoring emails and mailboxes, the local backup data can be used and for disaster recovery purposes, the remote failover server can be utilized.

Failover/Failback

When a disaster strikes the primary site, then all the users will be failed over to the remote site. Once the primary is rebuilt, one has to go through the failback process. The only way to make sure that your disaster recovery solution works is to test it periodically. Unfortunately, to do that one has to failover the entire Exchange server. Exchange Administrators will be leery about doing this for fear of crashing the production Exchange server. With the mailbox replication approach, one can create a test mailbox and use it for failover/failback testing periodically.

Conclusion

Companies are impacted adversely with significant loss of productivity and revenue when an Exchange server goes down. With increasing dependence of business on Exchange server, customers are demanding instant failover to a local or remote server. This concept may mean survival of business in case of a major destruction. High availability and disaster recovery of Exchange servers should be taken seriously and companies should implement the proper solution to protect them. One has to choose the appropriate solution based on their needs to protect the Exchange servers.

A look at some more AX4/iSCSI availability diagrams

Your comments on AX4 & iSCSI high availability were very informative and provided a number of idea for improving on the described availability scenario. In this post, Scott Lowe continues the availability discussion.

You guys gave me some great thoughts in my last posting in which I discussed my AX4/iSCSI highly available architecture. In this posting, I will continue the thread and give you a look at what the Westminster College architecture will look like in a few weeks. Some of this information is based on ideas provided in your comments. Although I’ve had the basic architectural diagram in mind for quite some time, your comments have helped to refine it.

Let’s start with a look at how VMware ESX will fit into our architecture.

This diagram is very similar to the one from the previous posting with one change. At the bottom of the diagram, I show an ESX cluster, fully VMotion-enabled. Each ESX server has multiple connections to the iSCSI storage network as well as to the primary network the users use to connect to the ESX servers. Under this scenario, we will achieve a high level of service availability for all of the servers running on the individual ESX servers. We’ll get to a highly available architecture with our SQL servers — and well as some other non-ESX services — through clustering, which will also entail a setup like the one above.

The next scenario expands on the scenario shown in the previous discussion.

I mentioned in that posting that, for simplicity’s sake, I wouldn’t show the connections to our core switch — an HP Procurve 5412zl. One of the comments on the previous posting recommended that we use the HP 5412zl for our primary iSCSI VLAN rather than our Dell blade-based M6220 switch. Under this scenario, we would bond together the four uplink ports on the M6220 to the 5412zl. The only downside to this scenario is that all iSCSI traffic from our blade chassis will have to traverse both the M6220 and the 5412zl. An alternative would be to use one uplink port on each of the M6220’s to connect to the AX4 and connect the other pair of iSCSI ports on the AX4 to the 5412zl. Doing this, we would have only two ports available to bond together from the M6220s to the 5412zl. We will test both scenarios, but I suspect that we will go with the alternative scenario I just described as it provides a higher level of redundancy.

I look very forward to your comments and suggestions.

iSCSI is the future of storage

iSCSI is here to stay and will eventually supplant a significant portion of the installed base of Fibre Channel SANs out there. Further, as organizations make their initial forays into block-level shared storage, iSCSI will beat Fibre Channel more often than not.

This week, HP announced their $360 million acquisition of LeftHand networks. Last year, Dell surprised the tech industry with a $1.4 billion purchase of the formerly independent EqualLogic. With these iSCSI snap-ups by true tech titans, iSCSI has officially arrived, is here to stay, and, I believe, will become the technology of choice for most organizations in the future.

This is not to say that iSCSI has been sitting in the background up to this point. On the contrary, the technology has taken the industry by storm. Both of these companies based their entire business hopes on the possibility that organizations would see the intrinsic value to be found in iSCSI’s simplistic installation and management. To say that both companies have been successful would be an understatement.

I’m a big fan of both EqualLogic and LeftHand Networks offerings, having purchased an EqualLogic unit in a former life. At that time, I narrowed my selection down to two options - LeftHand and EqualLogic. Both solutions had their pros and cons, but both were more than viable.

It’s not all about EqualLogic and LeftHand, though. The big guns in storage have finally jumped feet first into the iSCSI fray with extremely compelling products of their own. Previously, these players, including EMC and NetApp, simply bolted iSCSI onto existing products. Lately, even the biggest Fibre Channel vendors are releasing native iSCSI arrays aimed at the mid-tier of the market. EMC’s AX4, for example, is available in both native iSCSI and native Fibre Channel versions and is priced in such a way that any organization considering EqualLogic or LeftHand should make sure to give the EMC AX4 a look. To be fair, the iSCSI-only AX4:

-Does not support SAN copy for SAN to SAN replication
-Is not as easy to install or manage as one of the aforementioned devices, but isn’t bad either
-The bandwidth to the array does not increase as additional space is added
-It does not include thin provisioning, although this was rumored to be rectified in a future software release
-The AX4 supports up to 64 attached hosts

But, the price per TB is simply incredible and a solution based on a different vendor would not have been attainable. This year, I purchased just shy of 14 TB of raw space on a pair of AX4 arrays-4.8 TB SAS and 9 TB SATA-for under $40K. For the foreseeable future, I don’t need SAN copy and space can be managed in ways other than through thin provisioning. Over time, we’ll run about two dozen virtual machines on the AX4 along with our administrative databases and Exchange 2007 databases. By the time I need additional features, the AX4 will be due for replacement anyway.

iSCSI started out at the low end of the market, helping smaller organizations begin to move toward shared storage and away from direct attached solutions. As time goes on, iSCSI is moving up the food chain and, in many cases, is supplanting small and mid-sized Fibre Channel arrays, particularly in organizations that have never had a SAN before. As iSCSI continues to take advantage of high-speed SAS disks and begins to use 10Gb Ethernet for a transport mechanism, I see iSCSI continuing to move higher into the market. Of course, faster, more reliable disks and faster networking capabilities will begin to close the savings gap between iSCSI and Fibre Channel, but iSCSI’s reliance on Ethernet for an underlying transport mechanism brings major simplicity to the storage equation and I doubt that iSCSI’s costs will ever surpass Fibre Channel anyway, mainly due to the expensive networking hardware needed for significant Fibre Channel implementations.

Even though iSCSI will continue to make inroads further into many organizations, I don’t think that iSCSI will ever completely push Fibre Channel out of the way. Many organizations rely on the raw performance afforded by Fibre Channel and the folks behind Fibre Channel’s specifications aren’t sitting still. Every year brings advances to Fibre Channel, including faster disks and improved connection speeds.

In short, I see the iSCSI market continuing to grow very rapidly and, over time, supplanting what would have been Fibre Channel installations. Further, as organizations continue to expand their storage infrastructures, iSCSI will be a very strong contender, particularly as the solution is updated to take advantage of improvements to the networking speed and disk performance.

Protecting Microsoft Exchange in Physical & Virtual Environments

Introduction

For many companies, email has become a more important communication tool than the telephone. Internal employee communication, vendor and partner communication, email integration with business applications, collaboration using shared documents and schedules, and the ability to capture and archive key business interactions all contribute to the increasing reliance on email.

Businesses of all sizes, from multinational enterprises to small and midsize businesses, are using the messaging and collaboration features of Microsoft Exchange to run business functions that if lost, for even a short amount of time, can result in severe business disruption. No wonder Exchange has become a critical application for so many businesses. When these businesses look at high availability solutions to protect key business applications, Exchange is often the first application targeted for protection.

Improving the availability of Exchange involves reducing or eliminating the many potential causes of downtime. Planned downtime is less disruptive since it can be scheduled for nights or weekends - when user activity is much lower. Unplanned downtime, on the other hand, tends to occur at the worst possible times and can impact the business severely. Unplanned downtime can have many causes including hardware failures, software failures, operator errors, data loss or corruption, and site outages. To successfully protect Exchange you need to ensure that no single point of failure can render Exchange servers, storage or network unavailable. This article explains how to identify your failure risk points and highlights industry best practices to reduce or eliminate them, depending on your organization’s Exchange availability needs, resources and budget.

Exchange Availability Options

Most availability products for Exchange fall into one of three categories: traditional failover clusters, virtualization clusters and data replication. Some solutions combine elements of both clustering and data replication; however, there is no single solution that can address all possible causes of downtime. Traditional and virtualization clusters both rely on shared storage and the ability to run applications on an alternate server if the primary server fails or requires maintenance. Data replication software maintain a second copy of the application data, at either a local or remote site, and support either manual or automated failover to handle planned or unplanned server failures.

All of these products rely on redundant servers to provide availability. Applications can be moved to an alternate server if a primary server fails or requires maintenance. It is also possible to add redundant components within a server to reduce the chances of server failure.

Get Rid Of Failover – Get Rid Of Downtime

Most availability products rely on a recovery process called “failover” that begins after a failure occurs. A failover moves application processing to an alternate host after an unplanned failure occurs or by operator command to accommodate planned maintenance activity. Failovers are effective in bringing applications back online reasonably quickly but they do result in application downtime, loss of in-process transactions and in-memory application data, and expose the possibility of data corruption. Even a routine failover will result in minutes or tens of minutes of downtime including the time required for application restart and data recovery resulting from an unplanned failure. In the worst case, software bugs or errors in scripts or operational procedures can result in failovers that do not work properly; with the result that downtime can extend to hours or even days. Reducing the number of failovers, shortening the duration of failovers, and ensuring that the failover process is completely reliable, all contribute to reducing Exchange downtime.

Local server redundancy and basic failover address the most common failures that cause unplanned Exchange downtime. However, data loss or corruption, and site disruptions, although less common, can cause much longer outages and require additional solution elements to properly address.

Evaluate Unplanned Downtime Causes

Unplanned downtime can be caused by a number of different events:

-Catastrophic server failures caused by memory, processor or motherboard failures
-Server component failures including power supplies, fans, internal disks, disk controllers, host bus adapters and network adapters
-Software failures of the operating system, middleware or application
-Site problems such as power failures, network disruptions, fire, flooding or natural disasters

Each category of unplanned downtime is addressed in more detail below.

How to Avoid Server Hardware Failures

Server core components include power supplies, fans, memory, CPUs and main logic boards. Purchasing robust, name brand servers, performing recommended preventative maintenance, and monitoring server errors for signs of future problems can all help reduce the chances of failover due to catastrophic server failure.

Failovers caused by server component failures can be significantly reduced by adding redundancy at the component level. Robust servers are available with redundant power and cooling. ECC memory, with the ability to correct single-bit memory errors, has been a standard feature of most servers for several years. Newer memory technologies including advanced ECC, online spare memory, and mirrored memory provide additional protection but are only available on higher-cost servers. Online spare and mirrored memory can increase memory costs significantly and may not be cost effective for many Exchange environments.

Internal disks, disk controllers, host bus adapters and network adapters can all be duplicated. However, adding component redundancy to every server can be both expensive and complex.

Reduce Storage Hardware Failures

Storage protection relies on device redundancy combined with RAID storage to protect data access and data integrity from hardware failures. There are distinct issues for both local disk storage and for shared network storage.

Critical Moves To Protect Your Local Storage

Local storage is only used for static and temporary system data in a clustering solution. Data replication solutions maintain a copy of all local data on a second server. However, failure of unprotected local storage will result in an unplanned server failure, introducing the downtime and risks involved in a failover to an alternate server. For local storage, it is quite easy to add extra disks configured with RAID 1 protection. It is critical that a second disk controller is also used and that disks within each RAID 1 set are connected to separate controllers. Using other RAID levels, such as RAID 5, is not recommended for local disk storage the write cache is lost.

Secure Your Shared Storage

Shared storage depends on redundancy within the storage array itself. Fortunately, storage arrays from many storage vendors are available with full redundancy that includes disks, storage controllers, caches, network controllers, power and cooling. Redundant, synchronized write caches available in many storage arrays allow the use of performance-boosting write caching without the data corruption risks associated with single write caches. It is critical, however, that only fully-redundant storage arrays are used; lower-cost, non-redundant storage array options should be avoided.

Access to shared storage relies on either a fibre channel or Ethernet storage network. To assure uninterrupted access to shared storage, these networks must be designed to eliminate all single points of failure. This requires redundancy of network paths, network switches and network connections to each storage array. Multiple host bus adapters (HBAs) within each server can protect servers from HBA or path failures. Multipath IO software, required for supporting redundant HBAs, is available in many standard operating systems (including MPIO for Windows) and is also provided by many storage vendors; examples include EMC PowerPath, HP Secure Path and Hitachi Dynamic Link Manager. But these competing solutions are not universally supported by all storage network and storage array vendors, often making it difficult to choose the correct multipath software for a particular environment. This problem becomes worse if the storage environment includes network elements and storage arrays from more than a single vendor. Multipath IO software can be difficult to configure and may not be compatible with all storage network or array elements.

Say Goodbye to Networking Failures

The network infrastructure itself must be fault-tolerant, consisting of redundant network paths, switches, routers and other network elements. Server connections can also be duplicated to eliminate failovers caused by the failure of a single server component. Take care to ensure that the physical network hardware does not share common components. For example, dual-ported network cards share common hardware logic and a single card failure can disable both ports. Full redundancy requires either two separate adapters or the combination of a built-in network port along with a separate network adapter.

Software to control failover and load sharing across multiple adapters falls into the category or NIC teaming and includes many different options. Options include fault tolerance (active/passive operation with failover), load balancing (multiple transmit with single receive) and link aggregation (simultaneous transmit and receive across multiple adapters). Load balancing and link aggregation also include failover.

Choosing among these configuration options can be difficult and must be considered along with the overall network capabilities and design goals. For example, link aggregation requires support in the network switches and includes several different protocol options including Gigabit EtherChannel and IEEE 802.3ad. Link aggregation also requires that all connections be made to the same switch, opening a vulnerability to a switch failure.

Minimize Software Failures

Software failures can occur at the operating system level or at the Exchange application level. In virtualization environments, the hypervisor itself or virtual machines can fail. In addition to hard failures, performance problems or functional problems can seriously impact Exchange users, even while all of the software components continue to operate. Beyond proper software installation and configuration along with the timely installation of hot fixes, the best way to improve software reliability is the use of effective monitoring tools. Fortunately, there is a wide choice of monitoring and management tools for Exchange available from Microsoft as well as from third parties.

Reduce Operator Errors

Operator errors are a major cause of downtime. Proven, well-documented procedures and properly skilled and trained IT staff will greatly reduce the chance for operator errors. But some availability solutions can actually increase the chance of operator errors by requiring specialized staff skills and training, by introducing the need for complex failover script development and maintenance, or by requiring the precise coordination of configuration changes across multiple servers.

Secure Yourself from Site-Wide Outages

Site failures can range from an air conditioning failure or leaking roof that affect a single building, a power failure that affects a limited local area, or a major hurricane that affects a large geographic area. Site disruptions can last anywhere from a few hours to days or even weeks. While site failures are less common than hardware or software failures, they can be far more disruptive.

A disaster recovery solution based on data replication is a common to protect Exchange from a site failure while minimizing downtime associated with recovery. A data replication solution that moves data changes in real time and optimizes wide area network bandwidth will result in a low risk of data loss in the event of a site failure. Solutions based on virtualization can reduce hardware requirements at the backup site and simplify ongoing configuration management and testing.

For sites located close enough to each other to support a high-speed, low-latency network connection, solutions offering better availability with no data loss are another option.

Failover Reliability

Investments in redundant hardware and availability software are wasted if the failover process is unreliable. It is obviously important to select a robust availability solution that handles failovers reliably and to ensure that your IT staff is properly skilled and trained. Solutions need to be properly installed, configured, maintained and tested.

Some solution features that contribute to failover reliability include the following:

-Simple to install, configure and maintain, placing a smaller burden on IT staff time and specialized knowledge while reducing the chance of errors
-Avoidance of scripting or failover policy choices that can introduce failover errors
-Detection of actual hardware and software errors rather than timeout-based error detection
-Guaranteed resource reservation versus best-effort algorithms that risk resource over commitment

Protect Against Data Loss and Corruption

There are problems of data loss and corruption that require solutions beyond hardware redundancy and failover. Errors in application logic or mistakes by users or IT staff can result in accidentally deleted files or records, incorrect data changes and other data loss or integrity problems. Certain types of hardware or software failures can lead to data corruption. Site problems or natural disasters can result in loss of access to data or the complete loss of data. Beyond the need to protect current data, both business and regulatory requirements add the need to archive and retrieve historical data, often spanning several years and multiple types of data. Full protection against data loss and corruption requires a comprehensive backup and recovery strategy along with a disaster recovery plan.

In the past, backup and recovery strategies have been based on writing data to tape media that can be stored off-site. However, this approach has several drawbacks:

-Backup operations require storage and processing resources that can interfere with production operation and may require some applications to be stopped during the backup window
-Backup intervals typically range from a few hours to a full day, with the risk of losing several hours of data updates that occur between backups
-Using tape backup for disaster recovery results in recovery times measured in days, an unacceptable level of downtime for many organizations

Data replication is a better solution for both data protection and disaster recovery. Data replication solutions capture data changes from the primary production system and send them, in real time, to a backup system at a remote disaster site, at the local site, or both. There is still the chance that a system failure can occur before data changes have been replicated, but the exposure is in seconds or minutes rather than hours or days. Data replication can be combined with error detection and failover tools to help get a disaster recovery site up and running in minutes or hours, rather than days. Local data copies can be used to reduce tape backup requirements and to separate archival tape backup from production system operation to eliminate resource contention and remove backup window restrictions.

Consider Issues That Cause Planned Downtime

Hardware and software reconfiguration, hardware upgrades, software hot fixes and service packs, and new software releases can all require planned downtime. Planned downtime can be scheduled for nights and weekends, when system activity is lower, but there are still issues to consider. IT staff morale can suffer if off-hour activity is too frequent. Companies may need to pay overtime costs for this work. And application downtime, even on nights and weekends, can still be a problem for many companies that use their systems on a 24/7 basis.

Using redundant servers in an availability solution can allow reconfiguration and upgrades to be applied to one server while Exchange continues to run on a different server. After the reconfiguration or upgrade is completed, Exchange can be moved to the upgraded server with minimal downtime. Most of the work can be done during normal hours. Solutions based on virtualization, which can move applications from one server to another with no downtime, can reduce planned downtime even further. Be aware that changes to application data structures and formats can preclude this type of upgrade.

Added Benefits of Virtualization

The latest server virtualization technologies, while not required for protecting Exchange, do offer some unique benefits that can make Exchange protection both easier and more effective.

Virtualization makes it very easy to set up evaluation, test and development environments without the need for additional, dedicated hardware. Many companies cannot afford the additional hardware required for testing Exchange in a traditional, physical environment but effective testing is one of the keys to avoiding problems when making configuration changes, installing hot fixes, or moving to a new update release.

Virtualization allows resources to be adjusted dynamically to accommodate growth or peak loads. The alternative is to buy enough extra capacity upfront to handle expected growth, but this can result in expensive excess capacity. On the other hand, if the configuration was sized only for the short-term load requirements, growth can lead to poor performance and ultimately to the disruption associated with upgrading or replacing production hardware.