Even with the most meticulous design, the day will come when your farm’s capacity is not sufficient any more. User numbers increase, applications become more resource-hungry and the amount of data to be handled increases steadily. So what do you do? Simply more of the same, i.e. buy more servers and add them to the farm? That is one way of increasing capacity, but it is not the only one and therefore may not be the best.

• Deciding How Many Farms To Deployall About Citrix Service
• Deciding How Many Farms To Deployall About Citrix Technology
• Deciding How Many Farms To Deployall About Citrix Using

A farm in the Citrix Virtual Apps (formerly Citrix XenApp) architecture is a network entity that contains multiple Citrix Virtual Apps (formerly Citrix XenApp) servers grouped as a single logical entity. It also combines multiple data storage devices to form a single datastore database. Es, along with the top eight best practices in deploying Citrix XenApp/XenDesktop 7.7. Citrix XenApp and XenDesktop 7.7 Architecture Moving from IMA to FMA For many years and versions, Citrix XenApp has been based on the Independent Management Architecture (IMA) which provided a framework for communication between XenApp servers in a server farm.

• Read Part 2: Is Citrix Director Sufficient for End-to-End Monitoring? Understanding the Monitoring Capabilities of Director and How to Use It. Citrix Director is a web-based monitoring console for Citrix XenApp and XenDesktop virtualization platforms that allows administrators to control and monitor virtual applications and desktops. Starting with version 7, Citrix Director is the default.
• With Citrix MetaFrame Presentation Server, the option of replicating print drivers across all servers in the farm with one simple mouse click is now possible. In the event that there is a print server on the network, it can also import all its installed printers instead of having to reinstall and configure all these printers all over again.

In this article I am assuming that your farm actually is near 100% capacity (with a safety margin, of course). Only then does the following discussion make sense. It may very well be that a farm appears to be fully loaded, but in reality the terminal servers are having a good time idling around. In such cases some other component slows things down. The list of potential sources of trouble is long and includes the network, infrastructure servers (Citrix data store, domain controllers, file servers, application servers, etc.) and even misconfiguration of the virus scanners. Before going out and spending money on new hardware or software, it might be a good idea to have an external consultant review your farm design to make sure you are spending your company’s money on the right things.

Identify the Capacity Bottleneck

Once you are sure that you actually have a capacity bottleneck, the obvious first step is to identify it. Just knowing “I cannot get more than x users on each of my servers” is not going to be enough.

A XenApp farm is a very complex thing. Finding a bottleneck may at first sound like looking for a needle in a haystack. So let’s simplify. Every terminal server consists of the following main components:

• Memory
• CPUs
• Hard disks
• Network interfaces

Today’s (dual) 1 GBit/s network cards are fast enough for typical XenApp servers. Hard disks are not used much, except for storing temporary and user profile data, and large parts of the profiles are redirected to a file server anyway. CPU management in XenApp works well. That leaves us with memory as the culprit. How fast was that for performance analysis?

I must admit I lied to you. Finding a capacity bottleneck may very well be a really tough job. Every farm is different. No two XenApp customers have the same application set. But still, if we are mostly looking at typical office or task workers and taking a typical network and farm design as a basis, it mostly boils down to memory being short.

There are two kinds of memory shortage on 32-bit systems. The first is exhaustion of kernel memory (see my earlier article on the subject for details). The second simply is lack of enough RAM to satisfy the running applications’ demands.

Depending on whether your servers reach the limit of their kernel or application memory pool, one or more of the following scaling options may apply to your situation.

Option 1: Scale out by Adding Servers

As mentioned above, this may seem like the logical solution if every server has reached its capacity limit. The greatest advantage of this approach is that you need not change the way you install and manage your servers. You use the same OS and the same management tools, just on a larger number of machines. The downside is that each additional server reduces your data center’s efficiency in terms of power consumption and cooling. Also, rack space is increasingly becoming a scarce resource in many organizations.

Option 2: Scale up by Adding Memory

Deciding How Many Farms To Deployall About Citrix Service

This also sounds obvious. If more memory is needed, why, put more RAM into the machines! In practice, however, it is not so simple. In order to use more than 4 GB of RAM, you need to move from Windows Server 200x Standard Edition to Enterprise Edition, which is sold at roughly four times the Standard Edition’s price. I am told the list price difference is something around 2,000 dollars. Multiply that by your number of servers, and you may quickly come to the conclusion that other options may be more economical. Additionally, adding RAM only helps if your servers are not running out of kernel memory. Still, going from 4 GB to 8 GB RAM per server might be sensible in certain scenarios (see my earlier article on the subject for details).

Option 3: Scale up by Moving to Windows x64

Deciding How Many Farms To Deployall About Citrix Technology

64-bit Windows essentially does away with kernel memory limitations. Install as much RAM as your systems support, and the OS will use it. So is this the perfect solution? In theory, yes. In practice, you need to consider that migrating to Windows x64 is far from trivial (see my article series on the subject for details). And do not forget that you need more RAM. Much more RAM. 20-50% more only to have the system work as fast as it did with 32-bit Windows. But then it scales much better. Double or triple the amount of RAM, and you should be able to significantly increase the number of users per machine.

Option 4: Scale up and out by Virtualizing XenApp

Today’s common terminal servers with 4 GB of RAM and Windows Server Standard Edition are easy to manage because everything is well-known and OS licenses are inexpensive. Their main downside is server sprawl, the sheer number of machines required to cope with the workload. From an administration point of view that does not really matter – does it make a difference if you are managing 100, 200 or 500 machines? But server sprawl is an ecological and thus economical nightmare.

The answer to server sprawl may be virtualization. By putting multiple virtual XenApp servers on each physical machine, overall power consumption and rack space can be reduced significantly. And you get two things for free: increased flexibility (just think of VMotion/Live Migration/XenMotion) and increased complexity (another layer to manage).

Now What?

I have presented four options to choose from not only to increase farm capacity but also to improve the general layout of your XenApp servers. But the toughest part is yours – deciding which best fits your organizations needs.

Profile design for Citrix implementations has been a hotly contested debate for some time. Citrix consultants usually find themselves walking into a customer environment that was set up years before, and having to troubleshoot the current environment. Because we often have no control over what the current Citrix farm is using for profiles, I’ve devised a troubleshooting process that seems to work well for Citrix profiles, which I’ll include in a later blog, but for now I want to cover Citrix profile design.

According to Citrix, In a XenApp environment, Terminal Server profiles behave as follows:

Local Profiles	Local profiles are stored on each farm server and are initially created based on the default user profile. A user accessing applications in a load-managed XenApp farm creates an independent profile on each server. Users can save changes to their local profile on each individual server, but changes are only available to future sessions on that server. Local profiles require no configuration; if a user logging onto a XenApp server does not have a profile path specified, a local profile is used.Although local profiles are the default, Citrix does not recommend using them because profiles are created for each user on every server to which they have connected, which leads to an inconsistent user experience.
Roaming Profiles	Roaming profiles are stored in a central location for each user. The information in roaming profiles, such as a printer or a registry setting, is available to all XenApp servers in the environment. To configure a user for a roaming profile, you specify the user’s Terminal Server Profile Path to a particular location on a file server. The first time the user logs on to a XenApp server, the default user profile is used to create the user’s roaming profile. During logoff, the profile is copied to the specified location on a file server.
Mandatory Profiles	Mandatory profiles are stored in a central location for each user. However, the user’s changes are not retained on logoff. To configure a user for a mandatory profile, you create a mandatory profile file (NTUSER.MAN) from an existing roaming or local profile, and assign the users’ Terminal Services profile path to the location where the file can be accessed.Citrix recommends, where feasible, using mandatory profiles if they address the defined requirements.
Multiple Profiles	Multiple profiles combine two or more of the profile types (local, roaming, or mandatory) for the same user. Multiple profiles are useful in environments with load-managed groups or application silos. For example, in a XenApp farm with two load-managed groups serving SAP and Microsoft Office, you can configure users with a mandatory profile for the SAP servers and a roaming profile for the Microsoft Office servers. Multiple profiles are also useful for farms that span WAN connections, so that profiles can be accessed from local file servers.Multiple profiles are more complex to administer and maintain and are not widely used.

Depending on the profile that you are using, you could run into a range of different issues. Let’s examine some of each that I’ve seen most often:

Local Profiles:

Citrix exams will tell you that local profiles are the most low maint easy profile solution you can roll out to your users. While this may be true on the admin side, your Citrix user base might disagree. With local profiles, we often see users calling the help desk because their desktop icons or customized settings have seemingly disappeared. If you are publishing desktops, for example, the user might log in to find a document they had saved to their desktop the week before completely missing. This is the result of having a desktop published across multiple Citrix servers, and the user having their local profile saved on a single server. The result is that depending on which Citrix server the client logs into, they may get a different profile each time. Clients in this type of environment should understand that they can’t depend on anything saved locally to the profile, and that they must save all important data and customizations to their private sharedrive.

Roaming Profiles:

Still a popular solution for many Citrix healthcare clients, roaming profiles never seem to die. While they may initially seem to work flawlessly, as they grow in size over the years a Citrix farm can become slow and bloated. I’ve seen roaming profiles that have exceeded 500MB, with users calling the help desk to ask why their logins take 1-2 minutes to complete. If users have figured out how to save large graphics, music, or god forbid – video to their roaming profile, it can cause your profile server to run out of space after being clogged with excess “data”. The resulting profile corruption that occurs from profiles growing in size and being accessed often is commonplace in the roaming profile world, and something that most Citrix techs live with. You either decide to give your help desk the ability to log into the profile server and delete corrupt profiles from time to time, or you roll out a solution like Citrix profile manager which is supposed to limit profile corruption and last-write-wins conflicts. Either way, these types of profiles are going to be the highest maintenance solution that you could have chosen for your environment. Many Citrix techs will regret going this route sooner or later, but some don’t have a choice because of application customizations that won’t work with any other profile, etc. If you have applications that require writing to the HKEY_Current_User (HKCU) registry hive, then you are stuck using roaming profiles.

If you do decide to go with a roaming profile, it’s a good idea to deploy it with Citrix Profile Management. This will speed up logins, limit profile corruption, and eliminate last-write-wins conflicts that may occur without profile management in place.

Mandatory Profiles:

Citrix, and most savvy Citrix Techs will recommend using mandatory profiles whenever feasible. They are considered lower maintenance than roaming profiles, because your users essentially are handed a profile that is read-only every time they log in. If they need to save data or customizations, it’s a good idea to map them a share drive and consider employing some folder redirection. Mandatory profiles can’t handle applications that write to the HKEY_Current_User (HKCU) registry hive, so be aware that your applications must be tested before deployment. Mandatory profiles are a good way to ensure that logins to the environment stay quick, and that help desk calls remain low.

Multiple Profiles:

In 7+ years of working with Citrix, I’ve only ever seen someone deploy multiple profiles once. It was in an environment where users needed a roaming profile on some servers to comply with a very custom application’s requirements. On the rest of the servers in the environment, the users were given a roaming profile. This is the only scenario I can think of when it may make sense to use multiple profiles throughout an environment. This is obviously an option that is born out of necessity more than anything, and should be looked at with caution.

Deciding How Many Farms To Deployall About Citrix Using

In conclusion, profile design should be based around your user base and the applications you intend to virtualize in your environment. Only by understanding an evaluating how the applications function can you truly decide which profile solution will be best for you. User bases can vary widely with a range of technical skill and understanding. Depending on the type of users you are working with, you may choose to go with one profile solution over another.