|Read more about this book|
(For more resources related to this subject, see here.)
Farm terminology and concepts
Now is the moment to define the terminology we are going to use. If you are new in the Citrix world, please pay attention to this section.
- Multi-user environment is when applications are published on servers running remote desktop services and/or XenApp accessed by multiple users simultaneously.
- XenApp server is the main software component of the Citrix application delivery infrastructure. The objective of XenApp servers is to deliver applications to user devices.
- XenApp application servers are the farm servers that host published applications.
- XenApp infrastructure servers are the farm servers that host services such as a license server or web interface. Usually, they do not host published applications.
- Remote desktop services (RDS), formerly known as Terminal Services, is one of the components of Microsoft Windows that allows a user to access applications and data on a remote computer over a network. We need to install this component (and appropriate licenses) to setup and run XenApp servers. XenApp extends the functionality of Microsoft Remote Desktop Services, adding flexibility, manageability, security, and performance to RDS.
Applications can be made available by installing in the server or streaming to the client. XenApp 6 supports only Windows 32-bit or Windows 64-bit applications. Running 16-bit applications is NOT supported.
XenApp offers three methods for delivering applications to user devices, servers, and virtual desktops:
- Server-side application virtualization: Applications run on the XenApp servers. XenApp shows the application interface on the user device or client, and transmits user actions from the device, such as keystrokes and mouse actions, back to the application.
- Client-side application virtualization: XenApp streams applications on demand to the user device from the XenApp farm and runs the application on the user device.
- VM hosted application virtualization: Challenging applications or those requiring specific operating systems run inside a desktop on the XenApp server. XenApp shows the application interface on the user device or client, and transmits user actions from the device, such as keystrokes and mouse actions, back to the application.
XenApp server farm is a logical collection or group of XenApp servers that can be managed as a single entity. Usually, Citrix define three types of farms:
- Design validation farm: Design validation farm is set up in a laboratory, typically as the design or blueprint for the production farm. Usually, the preferred method to build a design validation farm today is using virtual machines.
- Pilot farm: Pilot farm is a preproduction farm used to test a farm design and applications before deploying the farm across the company. The pilot must include users from the entire organization and role. These users should access the farm for their everyday needs.
- Production farm: Production farm is in regular use and accessed by all users in the organization.
Farm Architecture defines the plan for the design of the server farm and zones based on current requirements and future expansion plans. Farm architecture requires a strong understanding of the network topology, scalability, failover, and geographic location of the sites and users in the company.
- Zones: Zones are used to control the aggregation and replication of data in the farm. A farm should be divided into zones based upon the network topology, where major geographic regions are assigned to separate zones. Each zone elects a data collector, which aggregates dynamic data from the servers in its zone and replicates the data to the data collectors in the other zones.
- Worker group: A worker group is a new feature introduced on XenApp 6. It is a collection of XenApp servers in the same farm. Worker groups allow a set of similar servers to be grouped together and managed as one. Worker groups are closely related to the concept of application silos (silos usually are servers dedicated to run critical or resource-intensive applications). All servers in the worker group share the same list of published applications and identical XenApp server settings.
- Data collector: A collector stores information about servers and published applications inside a group and acts as a gateway between data collectors in other groups. In large XenApp server farm environments, it is a good idea to have a dedicated server and restrict it from delivering applications. A dedicated data collector improves load balancing decisions and reduces session logon time.
User device is where the client software is installed to access data anywhere:
- Citrix Receiver: Citrix Receiver is the first universal client for IT service delivery. Users can use any device—it runs on smartphones, laptops, desktops, and netbooks (PC or Mac). With Citrix Receiver installed on a device, IT can deliver applications and desktops as an on-demand service with no need to manage, own, or care about the physical device or its location. Citrix Receiver is a lightweight software client with an extensible browser-like "plugin" architecture that communicates with head-end infrastructure in the Citrix Delivery Center product family including XenApp and XenDesktop. Citrix Receiver was formerly known as Citrix ICA Client.
- Citrix Dazzle and the self-service storefront: Citrix Dazzle, the self-service enterprise application storefront, offers a personal and easy-to-use interface for subscribing to applications. Administrators can distribute the Dazzle plug-in using Citrix Receiver, and users can choose their published application subscriptions. Dazzle also downloads and pre-caches streamed applications. The self-service storefront is available for both Windows and Mac users.
- Merchandising Server provides easy management, setup, and distribution of Citrix Receiver and related plugins and updates. Users simply point any browser to the setup site included with Merchandising Server, and within two clicks, the setup process starts. Merchandising Server software is delivered as a virtual appliance for Citrix XenServer or VMware.
Infrastructure servers are farm servers that host services such as license server or web interface. Usually, they do not host published applications.
XenApp farms have two types of infrastructure servers:
- Virtualization infrastructure consists of the XenApp servers that deliver virtualized applications and VM hosted applications and roles that support sessions and administration, such as the data store, data collector, Citrix XML broker, Citrix License Server, configuration logging database (optional), load testing services database (optional), service monitoring agents, and so on.
- Access Infrastructure consists of roles such as the web interface, secure gateway (optional), and access gateway (optional) that provide access to users.
In small deployments, we can group one or more roles together. In large deployments, we provide services on one or multiple dedicated servers.
Virtualization infrastructure represents a series of servers that control and monitor application environments.
Now, we will see different types of infrastructure servers:
- Citrix licensing: A Citrix License Server is required for all XenApp deployments. Install the license server on either a shared or standalone server, depending on your farm's size. After we install the license server, we need to download the appropriate license files from the MyCitrix.com website and install them in the license server. We can share a license server with multiple Citrix products.
- Data store database: Data store database is a repository of persistent farm information, including server's information, published applications, administrators, printers, and so on. We can host the data store database on a SQL Server Express database running on one of our XenApp servers in a small farm, use a dedicated SQL Server, or an Oracle database server in medium to large farms.
- Citrix XML Broker acts as an intermediary between the web interface and other servers in the farm. When a user logs in to the web interface, the XML Broker receives the user's credentials from the web interface and queries the server farm for a list of published applications that the user has permission to access. The XML Broker obtains this application set from the IMA (Independent Management Architecture) system and returns it to the web interface.
- Citrix XML Service: The XML Broker is a component of the Citrix XML Service. By default, the XML Service is installed on every server during XenApp setup. However, only the XML Service on the server specified in the web interface acts as the broker. In a small farm, the XML Broker runs on a server with multiple infrastructure functions. In a large farm, the XML Broker might be configured on one or more dedicated servers. Configuring a dedicated XML server is a simple task, we need to set up a dedicated XenApp server without any published applications.
- Single sign-on (optional): Single sign-on provides password management for published applications. Single sign-on can use Active Directory or a NTFS share to store password information. Single sign-on was formerly known as password manager and requires a Platinum license. Installation and configuration of single sign-on is out the scope of this article.
- Service monitoring (optional) is based on CitrixEdgesight and enables the administrator to collect, monitor, and report server resource metrics to estimate servers required to deploy a XenApp farm or to analyze the load of production servers. This feature requires a Platinum license. Installation and configuration of Edgesight is out the scope of this article.
- Provisioning Services (optional) assist administrators to manage the entire XenApp farm of application hosting servers, both physical and virtual, using one or multiple standardized server image. PVS can rollback to a previous working image in the time it takes to reboot. This feature requires a Platinum license. Installation and configuration of Provisioning Services is out the scope of this article.
- SmartAuditor (optional) allows an administrator to record the onscreen activity of any user's session, over any type of connection, from any server running XenApp. SmartAuditor uses policies to record, catalog, and archive sessions for retrieval and playback. This feature requires a Platinum license. Installation and configuration of SmartAuditor is out the scope of this article.
- Power and Capacity Management (optional) enables administrators to reduce power consumption and manage server capacity by dynamically scaling the number of online servers or powering on/off servers based on specific times. This feature requires a Platinum license. Installation and configuration of Power and Capacity Management is out the scope of this article.
Access Infrastructure represents a series of servers deployed within the local network or the DMZ to provide access to different types of users (local or remote) to resources published on XenApp servers.
XenApp farms have three types of access infrastructure servers:
- Web interface provides users with access to resources published on one or multiple XenApp farms through a standard web browser or through the Citrix Online Plug-in.
- Access Gateway (optional) is a universal SSL VPN appliance that can be used to secure client connections to XenApp farms and provide secure access to other internal network resources. XenApp Platinum Edition licenses include a universal Access Gateway license, which can be used with any Access Gateway edition. The Access Gateway appliance, also known as Netscaler, must be purchased separately.
- Secure Gateway (optional) assists administrators to secure access to enterprise network computers running XenApp and provides a secure Internet gateway between XenApp farms and client devices. The Secure Gateway transparently encrypts and authenticates all user connections to help protect against data tampering and theft. All data traversing the Internet between a remote workstation and the Secure Gateway is encrypted using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol. The Secure Gateway is an application that runs as a service on a server that is deployed in the demilitarized zone (DMZ).
Designing a basic XenApp architecture
Let's take a look at the Brick Unit Constructions, a small construction company near Washington DC established in 1973 by John Charles Empire. The HQ of the company is located near Frederick in Maryland. The company had around 120 users working there. Currently, they have 17 sites under construction around the state located in a 150 miles radius from HQ. Each of these sites has 10 to 25 computers, accessing applications installed on the site server or in each user computer. So we have around 400 users between HQ and construction sites. Almost 20 percent of all these users utilize laptops, work on a few projects at the same time, and travel between sites. All these sites are connected in a MPLS network between HQ and sites using T1 links.
Managing the software installed on computers and other devices in the field is a nightmare for the small IT department of the company and their manager, William Empire, son of John Charles.
Usually, the projects are short-term, between 6 months to 2 years. When the project is completed, IT needs to take a full backup of every machine and the server and reassign them to a new project. None of these sites has its own IT personnel, so the management of these servers and computers (backups, installing new applications, printers, and so on) is centralized from HQ, making the administration very complicated.
Users with laptops are having issues with printers and access to files located on different servers. William wants to resolve this issue by moving all data in remote file servers to a centralized file server on a NAS (Network Attached Storage) device, and migrate all printer queues located on remote sites to a new printer server on HQ. The migration of printers will help him to clean up print server drivers and check the compatibility of the current printers with Citrix.
The other issue these users are having is related to an in-house developed financial application installed on construction sites servers. Users must have these applications installed multiple times (one per site).
The following diagram is the Brick Unit Construction's current infrastructure:
William is concerned about the following:
- Deciding whether he would want to run XenApp on virtual machines or physical servers
- Budget: The cost of all Terminal Server and Citrix licenses will require a large expenditure
- Virtual machines will provide a lot of benefits, but will require a large investment in a SAN (Storage Area Network), the increase of memory RAM of existing servers, and the cost of the virtualization server software
William's idea is to move all applications installed on a client's machine or servers in remote sites to a XenApp farm, migrate all data in these sites to the HQ file, print servers, remove servers from field, and reuse them (these servers are pretty new) to build more XenApp servers or virtualization hosts to run XenApp on virtual machines.
Moving all applications to XenApp will help IT to reduce the license cost of applications and simplify the deployment of new versions.
Centralizing all data in a NAS file server will help to reduce backup costs (hardware and software) and simplify administration. Also, it will reduce the time to restore information.
Currently, the most popular option to implement XenApp 6 is using virtual machines and William decided to use it for the deployment of Brick Unit's farm.
|Read more about this book|
(For more resources related to this subject, see here.)
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.
He, hence, creates a basic task list to deploy the XenAppDesign 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 Citrix 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. A few tasks are described as follows:
- Estimate the amount of XenApp application 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.
- 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 Citrix Infrastructure Servers we need. Is one web interface server 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 application servers: In this step, we are going to choose how we are going 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?
- 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 on small or old servers? Can we re-use 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 Citrix implementation and now in XenApp 6 more than ever because XenApp policies and farm and server 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) 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 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 than 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 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 on the server.
- Join the server to the Active Directory domain. Although we can run XenApp on a workgroup, I don't recommend it.
- Configure Windows components such as Windows Firewall and IE ESC (Enhanced Security Configuration).
- 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 the server is rebooted, we need to download and install a XenApp Evaluation license from www.citrix.com.
- Optionally, we can setup Remote Desktop licenses. 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 servers. Also, we probably want to use a separate SQL Server.
William wants to test basic features of XenApp 6. 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 Citrix farm:
There are three roles he will use in the test farm: Citrix XenApp, Citrix Web Interface, and Citrix License Server.
William will use two servers with two CPUs (Quad Core) with 8 GB RAM and at least two hard drives with RAID 1 for XenApp testing servers.
Both Citrix License Service and Citrix Web Interface Server are not intensive services so he decides to put both together in the same server. He will use a single processor server with 2 GB of RAM.
Because 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 Citrix farm
The first step to deploy applications on a multi-user environment is to decide which applications we want to run on Citrix.
Citrix is especially useful when we have applications that are old and infrequently used, difficult to manage, or frequently updated.
Following are some parameters we can use to select applications we want to move to our XenApp 6 farm:
- Citrix XenApp lets us to efficiently deploy and maintain software in an enterprise environment. You can easily deploy applications from a central location (our datacenter). Because you install the programs on the XenApp 6 server and not on the client machine, applications 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 Citrix 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, like MAC and Linux.
- Applications accessing remote databases or data stores can improve its performance and reduce network utilization by moving the application from branch offices or remote sites to our datacenter.
- Reduce license expenses is the other advantage 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 Citrix 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 don't have enough licenses of Microsoft Project and Microsoft Visio for all employees, and usually the change of roles of several users make license management complicated and deployment of these applications slow. The creation of the AD 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 Citrix 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 us to install a client in every computer and then setup manually multiple connections to access all financial information for the site.
Brick Unit Constructions use 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.
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.
For more information about this topic, see the Running 32-bit Applications in the 64-Bit Windows section of the Microsoft Platform SDK documentation.
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 Citrix 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 Remote Desktop (formerly known as Terminal Server) or XenApp server, it is a good idea to check the vendor website to ensure the application can run on multi-user environment. If the application has issues, usually vendors 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 machine.
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, consider using tools such as the Microsoft Application Compatibility Toolkit (ACT) or Microsoft Sysinternals tools like Process Monitor.
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
- .INI files that contain hardcoded file path names, database connection settings, and read/write file.
Microsoft Office applications
The Microsoft Office suite is one of the most popular products delivered in Citrix 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 we need to deliver multiple versions of Office products (Office 2003, Office 2007, and Office 2010) at the same time and we can't use a dedicated server for each one, we need to 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 ActiveX controls, COM add-ins, and VBA code.
- Some Microsoft Office 2010 compatibility issues on the native 64-bit version are as follows:
- 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 that users don't have any VBA code or 32-bit add-ins and nobody uses Microsoft Access. Using the native 64-bit version will increase 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 server as Microsoft Office.
- BrickDocProject: IT decided to stream it to a 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, uses an old 32-bit ActiveX. So they need to run it on Internet Explorer 32-bit version. This web application used 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 server, so they think they will deploy it on silos servers.
In this article, we learned how to design a Citrix XenApp 6 farm and discovered Brick Unit Construction. Specifically:
- Common farm terminology and concepts used in the Citrix world and some new names used on XenApp 6
- Designing a Basic XenApp Architecture
- Writing a simple pilot plan
- Designing Active Directory integration
- Building a small test farm, used as a design validation farm
- Creating a list of applications to publish on the new farm
- Testing the list of applications and deciding the best method to deliver them
- Managing Citrix Policies [article]
- Microsoft Forefront UAG Building Blocks [article]
- FAQ on Virtualization and Microsoft App-V [article]