Troubleshooting IMA..

IMA Service Failure To Start

The Independent Management Architecture (IMA) service fails to start.

Cause:

There can be a number of reasons why the IMA Service appears not to have started, including the following:

1. IMA Service load time
2. IMA Service subsystem
3. Missing Temp directory
4. Print spooler service
5. ODBC configuration
6. Roaming Profile
7. Another server with an identical NetBIOS name on the same network

IMA Service Load Time

If the Service Control Manager reports that the IMA Service could not be started, but the service eventually starts, ignore the error message. The Service Control Manager has a timeout of 6 minutes. The IMA Service can take longer than 6 minutes to start if the load on the database exceeds the capabilities of the database hardware or if the network has high-latency.

IMA Service Subsystem

• Examine the following Windows Registry setting:

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA\Runtime\CurrentlyLoadingPlugin
If there is no value specified in the CurrentlyLoadingPlugin portion of the above Windows Registry entry, then either the IMA Service could not connect to the data store or the local host cache is missing or corrupt. 

• If a CurrentlyLoadingPlugin value is specified, the IMA Service made a connection to the data store and the value displayed is the name of the IMA Service subsystem that failed to load.
• Missing Temp Directory

If administrators see an “IMA Service Failed” error message with an error code of 2147483649 when starting the MetaFrame XP Presentation Server, the local system account may be missing a Temp directory which is required for the IMA Service to run. 

To gain further insight into the situation, change the IMA Service startup account to the local administrator and restart the server. If the IMA Service is successful in starting under the local administrator’s account, then the odds are greater that a missing Temp directory for the local system account is causing the situation. If the Temp directory is not present, then manually create one as %systemroot%\Temp. For example: C:\Winnt\Temp

Also, verify that the TMP and TEMP system environment variables point to the temporary directory. Restart the server to restart the IMA Service. 

Print Spooler Service

When the MetaFrame XP Presentation Server attempts to start the IMA Service, the “Setup Could Not Start The IMA Service” error message is displayed. This error shows that the IMA Service is not starting, possibly due to the print spooler service not running or being configured incorrectly. In addition, the following error messages appear in the Event Viewer: • Failed to load plugin MfPrintSs.dll with error 80000001h • Failed to load initial plugins with error 80000001h • The Independent Management Architecture service terminated with service-specific error The error occurs because the print spooler service: • Has stopped • Is disabled • Is not configured to run under the Local System AccountTo correct this error, verify that the print spooler service was started in the context of system rather than in the context of a user. A print spooler service that is not running or has been configured incorrectly may cause the printing subsystem to fail to load.To resolve the situation, stop and start the print spooler service, making sure that it is configured to run under the Local System Account. Then once again try to start the IMA Service.

 ODBC Configuration

1. Verify that the Microsoft SQL Server or Oracle server is online.2. Verify the name of the DSN file that the IMA Service is using by looking at the following key in the Windows Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA\DataSourceName.3. Attempt to connect to the database using the DSN file with an ODBC test utility such as Oracle ODBC Test or SQL Server ODBC Test.4. Verify that the correct user name and password are being used for database connectivity.5. Change the user name and password using the DSMAINT CONFIG command, if needed.6. Enable ODBC Tracing for further troubleshooting.

Roaming Profile

When the MetaFrame XP Presentation Server attempts to start the IMA Service, the “Setup Could Not Start The IMA Service” error message is displayed. In the event viewer you might see the following error: IMA_RESULT_INVALID_MESSAGE or other events related to the IMA Service not being able to start. Verify the size of the roaming profile especially if it is crossing a WAN. Also watch for error messages related to not being able to load the profile. Test with a local user profile or one that is smaller in size. Another server with an identical NetBIOS name on the same network Verify that there is not another server on the network with the same NetBIOS name on the network. If the CurrentlyLoadingPlugin has the ImaLicSs.dll listed this might be an indication of this condition. Another symptom of ImaLicSs.dll is from the MetaFrame XP SP4 Readme:106. The IMA Service failed to start because of license group corruption in the data store. 

Note: This fix prevents corruption in the data store but it does not correct any corruption that may already exist. You need to check for corruptions present in the data store and correct them using the appropriate tools.  

More Information

• CTX101917 – Error: Error: Windows could not start the Independent Management Architecture on Local Computer .. and refer to service-specific error code �2147483647.
• CTX105166 – IMA Service Hangs In a Starting State 
• CTX103015 – IMA Service Fails on MFPrintss.dll
• CTX104200 – Could not start IMA Service in CTX_MF_IMA_StartIMAService
• CTX103253 – Error: IMA service failed to start with error 2147483649 and failed to load plug-ins
• CTX032712 – Error: IMA Service Error Message -2147483647
• CTX101667 – IMA service failed on startup. Service specific error 2147483649
• CTX103048 – IMA Service fails to start when a domain or local user is configured for logon
• CTX101877 – Error: An error occurred while attempting to start the IMA Service.
• CTX735338 – IMA failed to start with error code 2147483649

IMA Service Hangs In a Starting State 

Symptoms:

Sometimes Independent Management Architecture (IMA) service hangs in a start state. 

Causes:

There may be numerous reasons as to why this occurs.

Resolution:

1. Recreate the LHC on the faulty server. CTX759510 - Function of the Local Host Cache on MetaFrame XP
2. Check the data store for consistency. (DSCheck – Located on the Feature Release 3 Server CD or the Program Files\Citrix\system32 folder on the server.)
3. Follow Q241215 to create a dump of the IMA service and have Technical Support investigate the output.

More Information

CTX105217 – IMA Service Hangs When Stopping

CTX105292 – Troubleshooting IMA Service Failure To Start

Function of the Local Host Cache

Each MetaFrame XP server stores a subset of the data store in the Local Host Cache (LHC). 


The LHC performs two primary functions: 

• Permits a server to function in the absence of a connection to the data store. 
• Improves performance by caching information used by ICA Clients for enumeration and application resolution. 

The LHC is an Access database, Imalhc.mdb, stored, by default, in the ProgramFiles%\Citrix\Independent Management Architecture folder. 

The following information is contained in the local host cache: 

• All servers in the farm and some basic information. 
• All applications published within the farm and their properties. 
• All Windows network domain trust relationships within the farm. 
• All information specific to itself. (product code, SNMP settings, licensing information) 

On the first startup of the member server, the LHC is populated with a subset of information from the data store. From then on, the IMA service is responsible for keeping the LHC synchronized with the data store. The IMA service performs this task through change notifications and periodic polling of the data store. If the data store is unreachable, the LHC contains enough information about the farm to allow normal operations for up to 96 hours on servers running SP2/FR2 or greater. On servers with no service pack or SP1/FR1, the grace period is 48 hours. During this grace period, the server continues to service requests while the IMA service attempts to connect to the data store periodically (based on the data store query interval). If the data store is unreachable for 96 hours, the licensing subsystem fails to verify licensing and the server stops taking incoming connections. 

Because the LHC holds a copy of the published applications and Windows domain trust relationships, ICA Client application enumeration requests can be resolved locally by the LHC. This provides a faster response to the ICA Client for application enumerations because the local server does not have to contact other member servers or the zone data collector. The member server must still contact the zone data collector for load management resolutions. 

In some instances it can be necessary to either refresh or recreate the local host cache. The sections below describe these situations. 

Refreshing the Local Host Cache 

If the IMA service is currently running but published applications do not appear correctly in ICA Client application browsing, force a manual refresh of the local host cache by executing dsmaint refreshlhc from a command prompt on the affected server. This action forces the local host cache to read all changes immediately from the data store. 

A discrepancy in the local host cache occurs only if the IMA service on a server misses a change event and is not synchronized correctly with the data store. 

Recreating the Local Host Cache 

If the IMA service does not start, the cause may be a corrupt LHC. Recreating the Local Host Cache after a minimum of SP1 has been installed:Important: The data store server must be available for dsmaint recreatelhc to work. If the data store is not available, the IMA service will fail to start.

1. Stop the IMA service on the MetaFrame server, if it is started. This can be done via the command line, net stop imaservice, or from services. 
2. Run dsmaint recreatelhc, which renames the existing LHC database, creates a new database and modifies the following registry key HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA\Runtime\PSRequired key to 1. Setting the value PSRequired to 1 forces the server to establish communication with the datastore in order to populate the Local Host Cache database. When the IMA service is restarted, the LHC is recreated with the current data from the data store.
3. Restart the IMA service. This can be done via the command line, net start imaservice, or from services.

OR 

To recreate the LHC database on servers that do not have a minimum of SP1 installed, follow these steps to manually recreate the LHC:Verify the data store is available before beginning this procedure. If the data store is not available, the IMA service fails to start until the data store is available.

1. Stop the IMA service on the MetaFrame server, if it is started. This can be done via the command line, net stop imaservice, or from services. 
2. Go to %ProgramFiles%\Citrix\Independent Management Architecture and rename the imalhc.mdb to imlhc.mdb.bak
3. Launch the ODBC Data Source Administrator: 
4. On Windows 2000, choose Control Panel > Administrative Tools > Data Sources (ODBC). 
5. On TSE, choose Control Panel > ODBC Data Sources. Select the File DSN tab and browse to %ProgramFiles%\Citrix\Independent Management Architecture.
6. Select the imalhc.dsn file and click Configure. 
7. In the Database area, click Create. The New Database dialog box appears. 
8. In the Database Name box, type the name imalhc.mdb for the new local host cache database. 
9. Click OK to create the database, and then click OK to close the ODBC Data Source Administrator. 
10. Open regedt32 and navigate to the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA\RUNTIME and modify the value of PSRequired (REG_DWORD): 0x1 
11. Restart the IMA service. This can be done via the command line, net start imaservice, or from services.

IMPORTANT: Restarting the IMA service instead of rebooting might cause the SNMP service to Dr. Watson if SNMP is enabled. 

Independent Management Architecture

IMA Subsystems

IMA subsystems are similar to plug-ins: They are core technologies that plug into the IMA and take advantage of its architecture. This architecture is the framework that unifies existing Citrix products and is the blueprint that Citrix will use in the future when developing new products to help integrate them all together. Currently, the IMA manages the following subsystems:
·         ICA Browser Provides backward compatibility. Its services come into use only when the farm is in mixed mode to offer older MF servers UDP broadcast capability.
·         Server Management Handles user sessions.
·         Application Management Manages published applications and their related information.
·         Runtime Offers services such as zone management and Data Collector.
·         Persistent Storage Updates the local host cache on every MF server from the Data Store.
·         Distribution Manages file transfers between different subsystems.
·         Remote Procedure Call Allows external processes to communicate with IMA.
·         User Management Provides authentication and security.
·         Printer Management Allows for printer administration.
·         Licensing Manages and enforces Citrix licensing guidelines.
·         Program Neighborhood Handles PN communications with ICA clients.
·         Load Management Handles load information and management.


The IMA Data Store

Remember that a Citrix Presentation Server farm is really just a database (called the IMA Data Store), and Presentation Servers are said to be part of the same farm if they’re sharing the same data store. The data store stores all configuration information for all farm servers. When a Presentation Server starts up (or, more correctly, when the IMA service on a Presentation Server starts up), the following process takes place:
1.     The IMA service checks the registry to find out what DSN contains the connection information to the data store. This registry location is HLKM\SOFTWARE\Citrix\IMA\DataSourceName
2.     By default, that registry key points to a file called MF20.dsn in the “%ProgramFiles%\Citrix\Independent Management Architecture” folder.
3.     The IMA service connects to the database specified in that DSN file. (Database credentials are encrypted and stored in the registry.)
4.     The IMA service downloads information that pertains to it from the central database into a local MS Jet (Access) database.
5.     Throughout its operation, the IMA service interacts with the locally cached subset of the central data store.
6.     Every 30 minutes, the IMA service contacts the central data store to see if anything has changed.

The Local Host Cache
As previously stated, the IMA service running on each Presentation Server downloads the information it needs from the central data store into a local MDB database called the local host cache, or “LHC.” (The location of the local host cache is specified via a DSN referenced in the registry of the Presentation Server, at HKLM\SOFTWARE\Citrix\IMA\LHCDatasource\DataSourceName. By default this is a file called “Imalhc.dsn” and is stored in the same place as MF20.dsn.)
Each Presentation Server is smart enough to only download information from the data store that is relevant to it, meaning that the local host cache is unique for every server. Citrix created the local host cache for two reasons:
Increased Redundancy. If communication with the central data store is lost, the Presentation Server can continue to function since the information it is available locally.
Increased Speed. Since the local host cache contains information the Presentation Server refers to often, the server doesn't have to access the IMA data store across the network every time any bit of information is needed.
The LHC is critical in a CPS environment. In fact, it's the exclusive interface of the data store to the local server. (In other words, the local server's IMA service only interacts with the LHC. It never contacts the central data store except when it's updating the LHC.)
If the server loses its connection to the central data store, there's no limit to how long it will continue to function. (In the days of MetaFrame XP, this limit was 48 or 96 hours, but that was because the data store also stored license information.) But today, the server can run forever from the LHC and won't even skip a beat if the central connection is lost. In fact now you can even reboot the server when the central data store is down, and the IMA service will start from the LHC no problem. (Older versions of MetaFrame required a registry modification to start the IMA service from the LHC.)
The LHC file is always in use when IMA is running, so it's not possible to delete it or anything. In theory it's possible that this file could become corrupted, and if this happens I guess all sorts of weird things could happen to your server. If you think this is the case in your environment, you can stop the IMA service and run the command "dsmaint recreatelhc" to recreate the local host cache file, although honestly I don't think this fixes anything very often. (I think it's more to make people feel better. "Ahhh. I recreated the LHC, so we'll see if the problem goes away.")

Data Store Architecture
Now let's take a closer look at the actual database that's used to power the IMA data store. If you open this database with SQL Enterprise Manager (or whatever Oracle calls their database management tool), you'll see it has four tables:
DATATABLE
DELETETRACKER
INDEXTABLE
KEYTABLE
If you’re at all familiar with databases, you’re probably thinking this is kind of weird. Wouldn’t the central database of a complex product like Citrix Presentation Server have hundreds of tables? Shouldn’t there be tables that list servers, apps, users, and policies, not to mention more tables linking them all together? The reason you don’t see the database structure you’d expect is because the IMA data store is not a real relational database. It’s actually an LDAP database that Citrix sort of hacked to work on top of a relational database like SQL Server.
This is because Citrix first came up with the concept of the IMA data store when they were working on MetaFrame XP in 2000. At that time they had planned to use Active Directory as the data store instead of a database. They developed the entire MetaFrame XP product around an LDAP-based data store instead of a relational database-based data store. Then towards the end of the development process, Citrix (smartly) realized that not too many people would want to extend their AD schemas to just to use Citrix, so they quickly moved to using a regualar database instead. The only problem was that the entire IMA service and data store were all ready to go using LDAP, and Citrix couldn’t just re-write the entire product to use a relational database instead. The solution was that Citrix had to implement their own LDAP-like engine that runs on top of a normal relational database. (On top of all that, Citrix encrypts this whole thing, so the contents really are gobbledygook to the casual observer.)
This is the reason you can’t just access the IMA data store directly through SQL Enterprise Manager. (Well, technically you can, but if you run a query you’ll get meaningless hex results.) If you try to edit any of the contents of the data store directly in the database, you will definitely break it and have to restore from backup.
For those curious to learn more about the LDAP-like structure of the data store, there’s a tool on the Presentation Server installation CD called “dsview.” DSview is fun to play with but not really that useful.
One final word of caution: There is a tool in existence called “dsedit.” As you can probably guess from the name, dsedit is basically a “write-enabled” version of dsview. If you happen to find this tool out on the Internet, DO NOT use it in your environment! This is an internal Citrix tool that is not meant for general use.
Now if you’re thinking, “I know what I’m doing, so I can play with dsedit,” I’ll warn you again: Don’t do it! The problem is that since dsedit is an internal-only tool, it’s not externally version-controlled. Citrix has many different compiled versions of this tool for all different versions of Presentation Server (and in some cases with specifics for certain hotfixes). So if you just happen to find some random hacker site with dsedit for download, you have no idea whether that dsedit version is the version that’s compiled to work with your specific version of the data store. (Chances are it’s not.) And using the wrong version of dsedit with your data store an easily corrupt the entire store (since data store items are maintained in long HEX strings that represent the LDAP-like node items.)

IMA service to data store communication
Let’s take a closer look at how a Presentation Server communicates with the central data store. We initially outlined the process that takes place when the IMA service starts up. In it, we described the IMA service downloading information from the central data store that's used to create the local host cache. Of course if the local host cache is already on the server (and up-to-date) when IMA starts, there's no need to download everything again.
So how does the server know whether its local host cache is current? Citrix makes this possible via a series of "sequence numbers." Every single configuration change made to the data store is assigned a number. The number of the most recent change is stored in the local host cache. Then when the IMA service checks the central data store for changes, it only needs to download the value of the most recent sequence number. If that number is the same as what it was last time (i.e. the same number that’s in the local host cache), then no further action is needed and the server knows its local host cache is up-to-date.
If sequence number of the most recent change in the central data store is newer than what’s in the local host cache, then more data is exchanged to determine what the changes are. If they apply to the specific server requesting the updates, they’re downloaded to that server and the local host cache is updated accordingly. If the changes do not apply to the requesting server, that server still updates the most recent sequence number in its local host cache so it can continue to look for changes in the future.
The IMA service on each Presentation Server looks for changes in the central data store every 30 minutes. You can adjust this value via the registry of the Presentation Server (CTX111914), although there’s typically no reason to do that since this exchange is less than 1k if there's no change.

IMA Data Store Database Type
Since Citrix’s implementation of the IMA data store runs on top of a regular relational database, you can pretty much use whatever kind of database server you want. Most people end up using SQL Server, although others are supported. (See CTX112591 for a complete list.)
For smaller environments, Citrix used to recommend using a Microsoft Access database running locally on one of your Presentation Servers. Nowadays that's not really used anymore, having been replaced by SQL Server Express. (SQL Express is free and based on "real" SQL Server technology.)
A big topic of discussion has been what constitutes a “smaller” environment? Or to be more blunt, at what point do you need to switch to using a real database instead of using Access or SQL Express? A lot of people argue about this in the online forums, with the general consensus being in the five-to-ten server range. I don't agree though. I’ve personally seen farms (even back in the MetaFrame XP days) of 50 servers running their data stores on Access, and that was fine. Since each Presentation Server only really interacts with its local host cache, a 50-server farm using Access still wouldn’t put much strain on the Access database.
To be honest, the real problem with using Access or SQL Express for your data store is that it has to be accessed “indirectly” (to use Citrix’s term). This means that the actual files that make up your data store are physically sitting on one of your Presentation Servers. The IMA service on that server accesses the database locally, and every other server in your farm accesses the data store via the IMA protocol (on port 2512) through the Presentation Server that’s hosting it. This is bad because it’s a single point of failure. If that Presentation Server goes down, your data store won't be accessible and you won't be able to manage your environment.
This might not be a problem in a small farm of just a few servers, but you’ll probably want a more redundant database long before your farm outgrows this architecture from a technical capacity standpoint.

IMA Data Store Size
Another question that often comes up when designing Presentation Server environments is, “How big will this IMA data store get?” The answer, very seriously, is “Not very big!”
Of course “very big” is a relative term, but in today’s world of multi-core servers with gigabytes of memory, the data store just isn’t going to grow large enough to really matter. Citrix very roughly estimates 1MB per server. And even if you built a single farm with 1,000 servers, a 1GB database in today's world just isn't that big anymore.
If you want more precise numbers as to the size of your data store, the Advanced Concepts Guide for CPS 4 (CTX107159) has a chart that lists exactly how many bytes each object type needs in the data store. (I have not been able to find this info for CPS 4.5, but I'm going to assume it's pretty close to 4.0.

IMA Data Store replication strategy
If your server farm spans multiple physical locations, you might want to replicate your data store so that a local copy is running at each location. There are two (potential) advantages to this:
Redundancy. You don’t want a single database server failure to negatively impact your overall environment.
Performance. If your farm spans multiple WAN locations, you might want to have a local database at each location.
Before we discuss this further, I want to make a few things clear: we're talking about doing a full replication of the entire data store, so that each replica is 100% identical. Unfortunately due to the binary LDAP structure of the data store, it's not possible to just replicate a subset of the data store to a remote site.
Second, we're talking about replicating the data store between physical sites for site-to-site performance and redundancy reasons. If you want to cluster your data store servers, this is entirely possible, but not what we're talking about now. (For more information about clustering your data store servers, read the High Availability chapter later in this book.)

Replicating your data store for redundancy
If your farm spans multiple physical locations, you might be concerned about what happens when a WAN link goes down. There’s an entire chapter later in this book dedicated to helping you design a fully-redundant environment based on everything that you’ll read up until that point. But right now we can discuss the mechanics of the data store when it comes to replication for redundancy purposes.
The first and most important thing to know is this: A Citrix Presentation Server will work indefinitely even if it loses connectivity to the central data store. (Again, remember that the local IMA service on a Presentation Server works off of its local host cache, not the central data store.) So really before you can decide whether you want to replicate your database for redundancy purposes, you have to decide understand what the impact is of losing connectivity to the data store.
The main thing is that in order to use either one of the two CPS management consoles, you have to connect to a Citrix server that is communicating with its data store. So if your data store is lost, even though your Presentation Server will run and will accept new connections and otherwise be totally normal, you won't actually be able to connect to that server with a management console.
What's interesting is that this doesn't mean that you can't manage sessions on that server. If you can connect to a different server in your farm that is connected to the data store, then you can view all activity and all sessions from your farm--even the ones from servers that aren't connected to the data store. But think about this for a minute. How is it possible that your management console is able to connect to a server that can access the datas store, and it's able to see servers not connected to the data store? If this is the case, wouldn't your "down" servers also be able to see the data store?
A more likely scenario is that you have multiple WAN locations each with their own Presentation Servers all in the same farm. If a WAN link goes down and some sites do not have their own replica of the data store, the servers, sessions, and users on that site will be fine. The problem will be that admins and help desk folks won't be able to connect to any admin consoles at that site. (And people at the site with the data store will be able to connect, but of course they won't be able to see or manage servers from the site with the down WAN link.)
A solution to this is to replicate your data store so that if a WAN link goes down, there's a local replica at each location. This means that local admins will be able to connect to the management tools on those local servers and perform their typical routine maintenance tasks. (Resetting sessions, shadowing, etc.)
Of course if any admin from the "down" site makes any configuration change that's saved to the data store, that change will be lost once the WAN link comes back up and the central data store re-replicates with the local data store. (As you can imagine, "merge" replication is not possible with this binary encrypted LDAP data store format.)

Replicating your data store for performance reasons
Some people also choose to replicate their data stores to multiple locations for performance reasons. The idea is that by doing this, you Presentation Servers can always access the data store via a local network instead of via the WAN. To be honest, this probably isn't that big of a deal. Remember that each Presentation Server interacts with its own local host cache for standard operational purposes. The central data store is only accessed to download additional configuration changes. Sure, recreating the local host cache will require the download of all the contents to rebuild the MDB cache file, but that too is not typically very large. (A few megabytes maybe?) And if your WAN can’t support the transfer of a few megabytes every once and a while, then you probably shouldn’t have a single farm that spans multiple sites anyway.
All that said, it’s a nice “clean” solution when all the Presentation Servers of a remote location can access everything they need on their own local LAN, and there’s certainly nothing wrong with that scenario.
Advantages of replicating
You can manage your servers when the WAN is down
Less WAN traffic (Read the "zones" section of this chapter to understand why.)
It just "feels" better, especially for a global environment
Disadvantages of replicating
More complex
Additional database servers required
Configuring IMA data store replication
If you decide that you’d like to replicate your data store, you’ll need to do two things:
1.     Configure the database software for replication
2.     Reconfigure your Presentation Servers to point them towards the local replica

Configuring the database for replication
All the real database servers support replication. (i.e. if you want to do this, you can't use Access or SQL Express.) Configuring the replication of your data store is 100% a function of your database software. In fact, your Citrix servers won't even know they're connecting to a database replica versus the real thing.
If you've never done this before and you're in the unfortunate position of making it happen in your environment, CTX112125 has more information and links to step-by-step instructions for configuring replication with SQL Server. The main thing you have to do is make sure that your replicas are "writable" by the local Presentation Servers. There's a few ways this can be set up, but in a CPS environment you need to ensure that one master copy of the database is in charge of all changes to it. (With that weird binary encrypted LDAP format, you don't want the database server to try to sort out two changes entered into two different replicas at the same time.)

Pointing your Presentation Servers to a new replica
Once you've got your data store replicated to your new location, you need to reconfigure the local Presentation Servers there to use the new replica instead of the old central location. Remember from the beginning of this section that a Presentation Server knows where to find the central data store via a file called MF20.dsn (which is specified in the registry). If you want to point your Presentation Server to another database (i.e. a local replica), all you have to do is to change that DSN and then restart the IMA service. (There are some command-line options for the dsmaint utility that let you change the location of the data store, but I personally find it easier to just edit the MF20.dsn file itself.)
Again, this will only work if you're pointing a server to a new database that is 100% identical to the old database. You cannot use this technique to "migrate" a server between farms since a new farm wouldn't know anything about a server that was just randomly pointed to it.

http://support.citrix.com/proddocs/index.jsp?lang=en

XenApp Terminology

Terminology and Concepts

Terminology

The XenApp planning and installation documentation uses the following terminology.

Multi-user environment

An environment, including XenApp and Terminal Services, where applications are published on servers for use by multiple users simultaneously.

Application servers

The farm servers that host published applications.

Infrastructure servers

The farm servers that host services such as the data store or the license server. Typically, they do not host published applications.

Production farm

A farm that is in regular use and accessed by users.

Design validation farm

A farm that is set up in a laboratory environment, typically as the design or blueprint for the production farm.

Pilot farm

A preproduction pilot farm used to test a farm design before deploying the farm across the organization. A true pilot is based on access by select users, and then adding users until all users access the farm for their everyday needs.

Enumeration

The process in which a client transmits data to locate servers on the network and retrieves information about the server farm’s published applications. For example, during enumeration, the XenApp Plug-in for Hosted Apps communicates with the Citrix XML Service or the ICA browser, depending on the browsing protocol selected in the plug-in.

XenApp Setup comprises two installation wizards:

• Create a New Farm. The first time you install XenApp, select Create a New Farm in the installation wizard and Setup creates the farm with that server hosting specific roles.
  The server where you installed XenApp and created the farm is the first farm server or the Create farm server.
• Join an Existing Farm. When you run Setup on servers after installing XenApp on the first farm server, you take a different path in Setup and XenApp references the settings you specified on the first farm server. These servers join the existing farm and communicate with the first server in the farm.

Citrix Licensing

A Citrix License Server is required for all XenApp deployments. Install the license server on either a shared or stand-alone server, depending on your farm’s size. After you install the license server, download the appropriate license files and add these to the license server.

Data Store

The data store is the database where servers store farm static information, such as configuration information about published applications, users, printers, and servers. Each server farm has a single data store.

Data Collector

A data collector is a server that hosts an in-memory database that maintains dynamic information about the servers in the zone, such as server loads, session status, published applications, users connected, and license usage. Data collectors receive incremental data updates and queries from servers within the zone. Data collectors relay information to all other data collectors in the farm. By default, the first server in the farm functions as the data collector.

By default, the data collector is configured on the first farm server during the Create Farm Setup and all other servers are configured with equal rights to become the data collector if the data collector fails. When the zone’s data collector fails, a data collector election occurs and another server takes over the data collector functionality. Farms determine the data collector based on the election preferences set for a server

The data collector is an infrastructure server and applications are typically not published on it.

Zone

A zone is a grouping of XenApp servers that communicate with a common data collector. In large farms with multiple zones, each zone has a server designated as its data collector. Data collectors in farms with more than one zone function as communication gateways with the other zone data collectors.

The data collector maintains all load and session information for the servers in its zone. All farms have at least one zone, even small ones. The fewest number of zones should be implemented, with one being optimal. Multiple zones are necessary only in large farms that span WANs.

Streaming File or Web Server

Applications can be delivered to users by either streaming or hosting the applications on the server. If you are streaming applications, either to client or server, you must install a streaming file server in your environment. When streaming applications, you create profiles of the application and then store the profile on a file or Web server. The profile consists of the manifest file (.profile), which is an XML file that defines the profile, as well as the target CAB files, a hash key file, the icons repository (Icondata.bin), and a scripts folder for pre-launch and post-exit scripts.

Web Interface

The Web Interface is a required component in any environment where users access their applications using either the XenApp plugin or a Web browser. Install the Web Interface on a stand-alone computer; however, where resources are limited, the Web Interface is sometimes collocated with other functions..

XenApp Web and XenApp Services Sites

XenApp Web and XenApp Services sites (formerly known as Access Platform and Program Neighborhood Agent Services sites, respectively) provide an interface to the server farm from the client device. When a user authenticates to a XenApp Web or XenApp Services site, either directly or through the XenApp plug-in or the Access Gateway, the site:

• Forwards the user’s credentials to the Citrix XML Service
• Receives the set of applications available to that user by means of the XML Service
• Displays the available applications to the user either through a Web page or by placing shortcuts directly on the user’s computer

Citrix XML Service and the Citrix XML Broker

The Citrix XML Broker functions as an intermediary between the other servers in the farm and the Web Interface. When a user authenticates 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 retrieves this application set from the Independent Management Architecture (IMA) system and returns it to the Web Interface.
• Upon receiving the user’s request to launch an application, the broker locates the servers in the farm that host this application and identifies which of these is the optimal server to service this connection based on several factors. The XML Broker returns the address of this server to the Web Interface.

The XML Broker is a function 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 functions as the broker. (The XML Service on other farm servers is still running but is not used for servicing end-user connections.) In a small farm, the XML Broker is typically designated on a server dedicated to several infrastructure functions. In a large farm, the XML Broker might be configured on one or more dedicated servers.

The XML Broker is sometimes referred to as a Citrix XML Server or the Citrix XML Service. For clarity, the term XML Broker is used to refer to when the XML Service functions as the intermediary between the Web Interface and the IMA service, regardless of whether it is hosted on a dedicated server or collocated with other infrastructure functions..

Infrastructure Servers

XenApp farms have two types of servers: infrastructure servers and member servers that host published applications. Infrastructure servers perform specific functions and do not typically host published applications, except in small farms. The services include:

• Farm infrastructure services - Data store, data collector, and the Citrix XML Broker.
• Access infrastructure services - Web Interface, Secure Gateway (optional), and Access Gateway (optional).
• Additional services - Citrix License Server, Streaming File or Web Server (optional), a computer for profiling applications, Configuration Logging database (optional), EdgeSight database (optional), and SmartAuditor player (optional).

One or more infrastructure services can be grouped together in small farms. In large deployments, each service runs on one or more dedicated servers.

http://support.citrix.com/proddocs/index.jsp?topic=/xenapp5fp-w2k8/ps-planning-farm-concepts-v2.html