Windows 7 / Getting Started

---

Build Application Servers

The Application server role is a multifunctional role because it is required to support commercial server software as well as corporate or in-house applications. Whether it is for software or applications, this server role, like all others, is based on the core server kernel installation for VSOs. Stage this server in the same way you stage all the other member servers in your VSO network. There are, however, some particularities, depending on the type of software or application the server will host. In addition, software products and/or custom applications often require a detailed architecture of their own before implementation.

For example, you could not install Microsoft Exchange Server without first determining its impact on your Active Directory Domain Services (ADDS) structure, on domain controllers, on the replication topology, and on other elements of the infrastructure you already have in place. Because of this, the Application server role is often one of the last server roles you implement.

Share Commercial and Corporate Applications

Most organizations will already have a vast number of software products and custom applications already in place. This is, after all, the basis of the client/server model. Organizations that are already using Windows networks will also know that both software products and applications hosted on these operating systems must conform to a specific set of guidelines in order to operate. This is outlined as the "Designed for Windows" set of specifications. Ideally, every application and software product you run will be upgraded to versions that are completely compatible with Windows Server 2008, but this is an improbable scenario.

NOTE: The specifications for Windows applications can be found at www.microsoft.com/winlogo.

Few organizations will be able to afford the upgrade of all of their software products or the redesign of all of their custom applications during the migration to WS08. The best you can hope for is to upgrade a few core or critical software products and redesign a few core applications. For example, on the software side, if you're using anything previous to Microsoft Exchange 2003, it makes a lot of sense to upgrade to Exchange 2007 because it relies on features that are a core part of WS08. It also makes sense to upgrade other core software, such as the products found in the Microsoft Windows Server System, if you can. Finally, you should try to upgrade your mission-critical custom applications, if you can, because they will gain from the new capabilities of WS08.

TIP: Support lifecycles are also a good reason to upgrade your applications. Microsoft, for example, provides complete information on their application lifecycles at http://support.microsoft.com/gp/ lifeselectindex. If your product is losing support, then it may be a good time to upgrade it. Sometimes, the cost of supporting an older product outweighs the cost of upgrading it.

If you can't upgrade everything or redesign your applications, don't despair. Like Windows Vista, Windows Server 2008 now boasts a Compatibility Mode that can emulate almost any previous version of Windows, from 95 to XP Service Pack 1. In addition, WS08 includes a Program Compatibility Assistant that walks you through the assignment of compatibility parameters for legacy software or older applications. And finally, you can use the Application Compatibility Toolkit from Microsoft to create shims, or code snippets that will make your older applications work in WS08.

TIP: Application compatibility in Windows Server 2008 is the same as in Windows Vista because both use the same code base. For a comprehensive look at application compatibility and potential application issues in these versions of Windows. The Definitive Guide to Vista Migration, at www.realtime-nexus.com/dgvm.htm. You can also rely on the Microsoft Application Compatibility Toolkit, which is available at http://technet.microsoft.com/en-us/windowsvista/aa905072.aspx.

One of the important aspects of application compatibility is security. Microsoft changed the security model for applications between Windows NT and Windows 2000, and continues to make it evolve in WS08. In NT, applications were allowed to write in critical areas of the system disk, such as the %SYSTEMROOT% and Program Files folders. This had the effect of potentially destabilizing the system. Now, neither users nor applications have the right to change or modify information in these critical folders. Therefore, if you have a legacy application that must run on Windows Server 2008, you must either modify security settings to allow users to modify specific files in critical folders or run the Program Compatibility Wizard to redirect program data to the user's profile area. You shouldn't, however, reset your server's security level from the defaults; that is, of course, if you want to keep it running. Rather, it is best to use the Program Compatibility Assistant to apply special settings to each program that requires it.