The pilot plan
William wants to build a very simple infrastructure to test the product with some users and later add more features (and servers) to the deployment.
Hence, he creates a basic task list to deploy the XenApp design validation farm:
- Design Active Directory integration.
- Build a small test farm in the lab with three servers to test XenApp and applications and get some experience with the product.
- Create a list of applications to publish in the XenApp farm.
- Test the list of applications and decide the best method to deliver them.
If we are satisfied with the results, the next step will be to create a XenApp pilot farm or extend our XenApp design validation farm, and provide some users access to the farm. This will be discussed in more detail in the next chapter. However, a few tasks are described as follows:
- Estimate the amount of XenApp applications Servers: In this step we need to calculate the number of XenApp application servers required. We can obtain an estimate based on the amount of memory and CPU required per user when they are executing the applications. Then we can add extra servers based on how critical these applications are and the future growth of the company. The pilot phase will confirm if these estimations are realistic or not.
- Are we going to enable Instant App Access (also known as Session Pre-Launch) on our XenApp farm? Introduced in XenApp 6.5, the new feature improves launch time, BUT also requires more hardware resources because to improve launch times, XenApp creates pre-launch on advance and keeps closed sessions open. This session will require some testing to figure out the appropriate settings for our environment.
- Determine the number of XenApp infrastructure servers we need for our farm. Based on the size of the farm (and our budget) we need to estimate how many XenApp infrastructure servers we need. One Web Interface server is enough or do we need at least two? Are we going to use one (or more) dedicated Data Collectors?
- Define the installation processes: In this step we need to decide the method to build the XenApp servers. Are we going to use Microsoft WDS (Windows Deployment Services), unattended scripts, or a manual process to install the operating system in physical servers? Or are we going to use virtual machines and just clone the template?
- Build and test XenApp applications servers: In this step we are going to choose how to build the application servers. Are we going to use virtual machines and deploy a template with all applications? Clone and deploy images to physical servers with all applications installed? Use Active Directory GPOs or script to install applications? Are we going to set all our XenApp servers as session-only to improve performance or set some of them as controller mode to use as backup just in case our main controller gets down?
- Design, build, and test XenApp infrastructure servers: Here we need to decide the appropriate way to build infrastructure servers. Are we going to build these servers as virtual machines or use physical servers? Can some infrastructure servers run small or old servers? Can we reuse any existing servers?
- Create and test a preproduction pilot farm based on our farm design. In this phase, after we have our servers ready, a small amount of users, usually from the IT department test applications on XenApp servers.
- Select and make a list of pilot users from different business groups. In this step, managers from every area of the company will select a few users from each department to test the farm and applications.
- Provide access to pilot users to the pilot farm. In this phase, we need to create Active Directory groups and assign the pilot users selected in the previous phase to these groups. After that, we will assign these groups to published applications and users can start the pilot phase.
- Release the server to production. In this final phase, after we successfully test the farm for several weeks or months, and all errors and issues are resolved, we can provide access to all users in the organization to the new farm.
Designing Active Directory integration
The Active Directory design is very important for a successful XenApp implementation and now in XenApp 6.5 (and 6.0) more than ever because XenApp policies and farm and servers settings have been added to Active Directory group policies.
Following is a check list of the basic recommendations:
- Put all XenApp servers in their own AD OUs (Organizational Units), this will help us easily manage servers using Worker Groups.
- If we use dedicated servers for some applications (silos), we need to create an OU for each of them, and keep servers organized in their own OUs.
- All XenApp servers must reside in the same domain.
- The server farm needs to be in a single Active Directory forest. If our XenApp farm has servers in more than one forest, users cannot log on using UPNs (user principal names). UPN logons use the format username@UPN.
XenApp supports Active Directory Federated Services (ADFS) when used with the Citrix Web Interface. If we provide access to published applications to a business partner, ADFS will provide a great alternative to creating multiple new user accounts on our AD domain.
Building a small test farm
Installing a small test farm is the first step to gain some experience with the product.
We have two options:
- Build a single server test farm. If we want to learn about XenApp 6.5 or deploying a very small internal farm for a few users, we can install all these components in a single server. The following is a list of steps required to build a single server small test farm:
- Install Windows Server 2008 R2 SP1 on the server. Requirements are already mentioned in Chapter 1, Getting Started with XenApp 6.5.
- Join the server to the Active Directory domain. Although we can run XenApp on a workgroup, I don't recommend it.
- Follow the instructions in Chapter 3, Installing XenApp 6.5, to configure Windows components such as Windows Firewall and IE ESC (Enhanced Security Configuration).
- Using instructions in Chapter 3, Installing XenApp 6.5, to install and configure these components on the server: Web Interface, License Server, and XenApp.
- When XenApp setup asks about the database, we need to choose New Database. This option will install SQL Server 2008 Express Edition on the same server.
- After the setup is completed and server rebooted, we need to download and install a XenApp Evaluation licenses from www.citrix.com. Instructions are provided in Chapter 3, Installing XenApp 6.5.
- Optionally we can set up Remote Desktop license. This step is not required if we are going to use this test environment for less than 120 days.
- Build a multiple server test farm. If we are planning a pilot farm for a medium or large company, we would probably want to build a few XenApp servers, usually a separate Web Interface server (or two if we want some redundancy), and install the License server on one of the Web Interface Server. Also, we probably want to use a separate SQL Server. This scenario is covered in detail in Chapter 3, Installing XenApp 6.5.
William wants to test basic features of XenApp 6.5. Later, he can add more infrastructure servers for other roles or increase redundancy.
The following diagram shows a graphic of the components of a small XenApp farm:
There are three roles he will use in the test farm: Citrix XenApp, Citrix Web Interface, and Citrix License Server.
William will reuse two existing servers with two CPUs (Quad Core) and 16 GB RAM, and at least two hard drives with RAID 1 (more about disk configuration is discussed in the next chapter) for XenApp testing servers.
Here he is facing two options:
- Build test servers on physical servers
- Use these two servers to deploy hypervisors and create virtual machines
William chooses to deploy XenApp using my favorite option for test environments: download a free hypervisor like Citrix XenServer, VMware ESXi, or Microsoft Hyper-V Server and create virtual machines. Using virtual machines to build a lab provides a lot of benefits, including the ability to take snapshots and roll back changes, very useful to the learning process, faster server delivery, and more. We are going to talk about running XenApp on virtual machines in Chapter 14, Virtualizing XenApp Farms.
As Brick Unit Construction had one existing SQL Server 2008 dedicated server, William will create the Citrix data store on it.
This is the new proposed architecture of infrastructure servers at Brick Unit Construction:
Creating a list of applications to publish in our XenApp farm
The first step to deploy applications on a multi-user environment is to decide which applications we want to run on XenApp.
XenApp is especially useful when we have applications that are old and infrequently used, difficult to manage, or frequently updated.
The following are some parameters we can use to select applications we want to move to our XenApp 6.5 farm:
- Citrix XenApp lets us efficiently deploy and maintain software in an enterprise environment. We can easily deploy applications from a central location (our datacenter). As we install the programs on the XenApp server and not on the client computer, programs are easier to upgrade and to maintain.
- Testing new versions of a new application is easy and we can run multiple versions of the same application at the same time, using multiple servers or streaming the application to the client. For example, we can run Office 2007 and Office 2010 or both 32-bit and 64-bit versions of Microsoft Office 2010 at the same time.
- Are we going to provide remote access to applications published on XenApp in the near future? Remote users can access programs that are running on XenApp farm from devices such as home computers, kiosks, mobile devices, and operating systems other than Windows, such as MAC and Linux.
- Applications accessing remote databases or data stores can improve its performance and reduce network utilization, moving the application from branch offices or remote sites to our datacentre.
- Reducing license expenses is the other advantage that we will have when we move applications to a XenApp farm. We can limit the amount of sessions of a specific application.
William decided to move all Microsoft Office suite applications in use in the company (Microsoft Word, Microsoft Excel, Microsoft Outlook, Microsoft PowerPoint, Microsoft Project, and Microsoft Visio) to the XenApp farm. This decision will reduce the time the IT department spends updating Office in remote machines and simplify the license management of Microsoft Project and Microsoft Visio.
Brick Unit Constructions doesn't have enough licenses of Microsoft Project and Microsoft Visio for all employees, and usually the change of roles of several users makes license management complicated and deployment of these applications slow. The creation of the Active Directory group for all project managers will simplify the Microsoft Project and Microsoft Visio management and provide instant access for users of these applications.
Moving the Microsoft Office suite to XenApp will simplify printing and file storage and management, too.
The next application William picks to move to XenApp is the financial application used in each construction site. This is an in-house application known internally as BrickFin. This application is very difficult to deploy because it requires the company to install a client in every computer and then manually set up multiple connections to access financial information for the site.
Brick Unit Constructions uses another in-house application for architects and engineers. This is an offline application used in the construction site in laptops, to take notes and photos and document the project. This application is called BrickDocProject.
Finally, the company has two more applications; one for time tracking called BrickTime and another used for expenses tracking called BrickExpenses used for all users. These applications are web applications, so publishing them in the farm is pretty easy.
Testing the list of applications
The next step is to test the list of applications and decide the best method to deliver them.
Most Windows 32-bit programs will work on the 64-bit version of Windows like Windows Server 2008 R2. One of the exceptions is antivirus programs. They use 32-bit kernel-mode device drivers and 32-bit drivers don't run on 64-bit operating systems.
The same applies to any device driver. Printers will require 64-bit print drivers. We will talk later about printing on a XenApp 6.5 environment in Chapter 9, Printing in XenApp Environments.
The WOW64 (known as Windows 32-bit on Windows 64-bit) subsystem allows 32-bit Windows-based applications to run flawlessly on 64-bit Windows operating systems.
Some 32-bit programs may run slower on Windows Server 2008 R2 than they would on 32-bit versions of Windows Server 2003/2008.
The WOW64 subsystem isolates 32-bit binaries from 64-bit binaries by redirecting registry and file system calls. The WOW64 subsystem isolates the binaries to prevent a 32-bit binary from accidentally accessing data from a 64-bit binary. For example, a 32-bit binary that runs a .DLL file from the %systemroot%\System32 folder might accidentally try to access a 64-bit .DLL file that is not compatible with the 32-bit binary. To prevent this, the WOW64 subsystem redirects the access from the %systemroot%\System32 folder to the %systemroot%\SysWOW64 folder. This redirection prevents compatibility errors because it requires the .DLL file to be specifically designed to work with 32-bit programs.
Running 32-bit applications on a 64-bit operating system can cause overload because WOW64 creates a 32-bit environment for any application to load 32-bit DLLs and isolate it from 64-bit applications.
One of the best practices for installing applications is to install related applications or applications that have dependencies on other local applications on the same XenApp servers.
If the application has compatibility issues or excessive use of resources that might affect other programs on the same server, deploy it on silo servers using Worker Groups.
Before installing any application on a Remote Desktop Server (Terminal Server) or XenApp server, is a good idea to check the vendor website to ensure the application can run on multi-user environment. If the application has issues, vendors usually provide compatibility scripts or fixes. If the application is not supported on multi-user environment, we must try to stream the application to the client.
Websites that use old ActiveX controls in Microsoft Internet Explorer must run on the 32-bit version of Microsoft Internet Explorer.
After testing, if any of these solutions do not work, we might need to try finding and fixing the root cause of the issue.
To identify root application issues, we need to consider using free tools such as the Microsoft Application Compatibility Toolkit (ACT) or Microsoft Sysinternals tools such as Process Monitor. Also we can buy Citrix AppDNA.
Sysinternals tools are available at http://technet.microsoft.com/sysinternals
Examples of common issues include the following:
- Custom or in-house applications developed with hardcoded paths in the registry.
- Applications that use the computer name or the IP address as credential or for identification purposes.
.INIfiles that contain hardcoded file path names, database connection settings, and read/write file.- 32-bit applications that use 16-bit DLLs.
The Microsoft Office suite is one of the most popular products delivered in XenApp environments. Here we have some advice to deliver them successfully:
- If we have an application that requires Microsoft Excel to export results, install them on the same server.
- Install all Microsoft Office applications (Microsoft Office, Microsoft Project, Microsoft Visio, and so on) on the same server. Microsoft Office shares a lot of components between different products. Avoid mixing different versions of Microsoft Office products on the same server (for example Office 2003 and Visio 2007 on the same server).
- If you need to deliver multiple versions of Office products (Office 2003, Office 2007, and Office 2010) at the same time and you can't use a dedicated server for each one, use application stream.
- Office 2010 is the first edition of the suite released on both native 32-bit and 64-bit versions. Curiously, Microsoft recommends installing the 32-bit version instead of the 64-bit version. Installing 32-bit Office 2010 applications that run on 64-bit operating systems allow for better compatibility with Active X controls, COM add-ins, and VBA code.
- Some Microsoft Office 2010 compatibility issues on the native 64-bit version:
- Microsoft Access MDE/ADE/ACCDE files created on the 32-bit version cannot run on 64-bit editions of Office 2010 and vice versa.
- ActiveX controls and COM DLLs add-ins that were written for 32-bit Office will not work in a 64-bit version. The workaround for resolving this issue is to obtain 64-bit compatible controls and add-ins or to install Office 2010 32-bit (WOW).
- Inserting an object into an Office 2010 application document might fail, if we try to insert a 32-bit object in a 64-bit Office 2010 application document.
- Visual Basic for Applications (VBA) code that uses the Declare statement to access the Windows Application Programming Interface (API) or other DLL entry points will see differences between 32-bit and 64-bit versions.
Windows Server 2008 R2 comes with both 32-bit and 64-bit Internet Explorer browsers. 32-bit IE comes as a default. There are different versions of Java software available for download depending on whether you are using 32-bit or 64-bit IE browsers.
If we are using:
- 32-bit Internet Explorer (IE), we need to download and install 32-bit Java.
- 64-bit IE, we need to download and install 64-bit Java.
- Both 32-bit and 64-bit IE, we need to download and install both 32-bit and 64-bit Java versions.
William and his team installed and tested all selected applications, and took the following decision to deliver them:
- Microsoft Office suite: They will deploy Office 2010 64-bit. Brick Unit Construction talked with several users and reviewed documents and they found users don't have any VBA code or 32-bit add-ins and nobody uses Microsoft Access. Using the native 64-bit version will reduce the amount of resources used on XenApp servers.
- BrickFin: Installing the application in a XenApp server and creating multiple icons (one for each site) will simplify access to this application. This application requires Excel to export financial results to Excel, so IT will deploy it on the same XenApp server as Microsoft Office.
- BrickDocProject: IT decided to stream it to client computer because it requires offline access.
- Web applications: William and his team tested these two web applications and found one of them used to manage expenses using an old 32-bit ActiveX so they need to run it on Internet Explorer 32-bit version. This web application uses lots of resources on the XenApp server because users sometimes left it open and updated the time several times a day. That might affect other programs on the same XenApp server, so they think they will deploy it on silo servers.