XenApp Commands

Acrcfg: Configure auto-reconnect settings.

Use acrcfg to configure Auto Client Reconnect settings for a server or a server farm.

Syntax

acrcfg [/server:servername | /farm]   [/query | /q]

acrcfg [/server:servername | /farm] [/require:on | off] [/logging:on | off]

acrcfg [/server:servername | /farm] [/require:on | off] [/logging:on | off]

acrcfg [/server:servername] [/inherit:on | off] [/require:on | off] [/logging:on | off]

acrcfg [/?]

Parameters

servername

The name of a server running Citrix XenApp

Options

/query

/q

Query current settings.

/server

The server to be viewed or modified by the other command-line options. The server specified by servername must be in the same server farm as the server on which the command is run. This option and the /farm option are mutually exclusive. The local server is the default if neither /server nor /farm is indicated.

/farm

The options on the command-line after /farm are applied to the entire server farm.

/inherit:on | off

To use the Auto Client Reconnect settings from the server farm, set /inherit to on for a server. To disregard the Auto Client Reconnect settings from the server farm, set /inherit to off. By default, /inherit is set to on for a server.

/require:on | off

If you want users to be prompted for credentials during automatic reconnection, set /require to on. Servers inherit the server farm setting unless /inherit is off. To allow users to automatically reconnect to disconnected sessions without providing credentials, set /require to off. By default, /require is set to off for both a server and a server farm.

/logging:on | off

You can enable logging of reconnections in the Application Event log on a server. Logging can be set only when /required is set to off. Logging is set to off for both servers and server farms by default.

/?

Displays the syntax for the utility and information about the utility’s options.

Remarks

Enabling automatic reconnection allows users to resume working where they were interrupted when an connection was broken. Automatic reconnection detects broken connections and then reconnects the users to their sessions.

However, automatic reconnection can result in a new session being launched (instead of reconnecting to an existing session) if a plugin’s cookie, containing the key to the session ID and credentials, is not used. The cookie is not used if it has expired, for example, because of a delay in reconnection, or if credentials must be reentered because /require is set to on. Auto Client Reconnect is not triggered if users intentionally disconnect.

The Auto Client Reconnect feature is enabled by default and can be disabled using the icaclient.adm file or an ICA file only on the Citrix XenApp Plugin for Hosted Apps or with the Web Interface.

The /require and /logging options are valid with either /server or /farm, but /inherit is not used with /farm. If neither /server nor /farm is selected and the /inherit, /require, or /logging options are used, they are applied to the local server. You can set /require only when /inherit is set to off. You can set logging only when /require and /inherit are set to off. When logging is not valid, it disappears from later queries. A query shows the required setting whether or not it is on.

Settings and values are not case-sensitive.

Examples

The following four commands result in the following configurations:

• Require users to enter credentials when they automatically reconnect to servers configured to inherit farm-wide settings
• Show the results
• Allow users to be reauthenticated automatically to the local server and set the server to log plugin reconnections
• Show the results

C:\>acrcfg /farm /require:onUpdate successfulC:\>acrcfg /farm /qAuto Client Reconnect Info for: Farm-wide SettingsREQUIRE: onC:\>acrcfg /inherit:off /require:off /logging:onUpdate successfulC:\>acrcfg /qAuto Client Reconnect Info for: Local ServerINHERIT:offREQUIRE:offLOGGING:on

Security Restrictions

To make changes, you must be a Citrix administrator with Windows administrator privileges.

Altaddr:  Specify server alternate IP address.

Use altaddr to query and set the alternate (external) IP address for a server running Citrix XenApp. The alternate address is returned to clients that request it and is used to access a server that is behind a firewall.

Syntax

altaddr [/server:servername] [/set alternateaddress] [/v]

altaddr [/server:servername] [/set adapteraddress alternateaddress] [/v]

altaddr [/server:servername] [/delete] [/v]

altaddr [/server:servername] [/delete adapteraddress] [/v]

altaddr [/?]

Parameters

servername

The name of a server.

alternateaddress

The alternate IP address for a server.

adapteraddress

The local IP address to which an alternate address is assigned.

Options

/server:servername

Specifies the server on which to set an alternate address. Defaults to the current server.

/set

Sets alternate TCP/IP addresses. If an adapteraddress is specified, alternateaddress is assigned only to the network adapter with that IP address.

/delete

Deletes the default alternate address on the specified server. If an adapter address is specified, the alternate address for that adapter is deleted.

/v (verbose)

Displays information about the actions being performed.

/?

Displays the syntax for the utility and information about the utility’s options.

Remarks

The server subsystem reads the altaddr settings for server external IP addresses at startup only. If you use altaddr to change the IP address setting, you must restart the Citrix Independent Management Architecture service for the new setting to take effect.

If altaddr is run without any parameters, it displays the information for alternate addresses configured on the current server.

Examples

Set the server’s alternate address to 1.1.1.1:

altaddr /set 1.1.1.1

Set the server’s alternate address to 2.2.2.2 on the network interface card whose adapter address is 1.1.1.1:

altaddr /set 2.2.2.2 1.1.1.1

Security Restrictions

None.

App: Run application execution shell.

APP

App is a script interpreter for secure application execution. Use App to read execution scripts that copy standardized .ini type files to user directories before starting an application, or to perform application-related cleanup after an application terminates. The script commands are described below.

Syntax

app scriptfilename

Parameters

scriptfilename

The name of a script file containing app commands (see script commands below).

Script Commands

copy sourcedirectory\filespec targetdirectory

Copies files from sourcedirectory to targetdirectory. Filespec specifies the files to copy and can include wild cards (*,?).

deletedirectory\filespec

Deletes files owned by a user in the directory specified. Filespec specifies the files to delete and can include wild cards (*,?). See the Examples section for more information.

deleteall directory\filespec

Deletes all files in the directory specified.

execute

Executes the program specified by the path command using the working directory specified by the workdir command.

path executablepath

Executablepath is the full path of the executable to be run.

workdir directory

Sets the default working directory to the path specified by directory

Script Parameters

directory

A directory or directory path.

executablepath

The full path of the executable to be run.

filespec

Specifies the files to copy and can include wildcards (*,?).

sourcedirectory

The directory and path from which files are to be copied.

targetdirectory

The directory and path to which files are to be copied.

Remarks

If no scriptfilename is specified, app displays an error message.
The Application Execution Shell reads commands from the script file and processes them in sequential order. The script file must reside in the %SystemRoot%\Scripts directory.

Examples

The following script runs the program Notepad.exe. When the program terminates, the script deletes files in the Myapps\Data directory created for the user who launched the application:

PATH C:\Myapps\notepad.exeWORKDIR C:\Myapps\DataEXECUTEDELETE C:\Myapps\Data\*.*

The following script copies all the .wri files from the directory C:\Write\Files, executes Write.exe in directory C:\Temp.wri, and then removes all files from that directory when the program terminates:

PATH C:\Wtsrv\System32\Write.exeWORKDIR C:\Temp.wriCOPY C:\Write\Files\*.wri 

C:\Temp.wriEXECUTEDELETEALL C:\Temp.wri\*.*

The following example demonstrates using the script file to implement a front-end registration utility before executing the application Coolapp.exe. You can use this method to run several applications in succession:

PATH C:\Regutil\Reg.exeWORKDIR C:\RegutilEXECUTEPATH C:\Coolstuff\Coolapp.exeWORKDIR

C:\TempEXECUTEDELETEALL C:\Temp

Security Restrictions

None.

 Auditlog: Generate server logon/logoff reports.

Auditlog generates reports of logon/logoff activity for a server based on the Windows Server security event log. To use auditlog, you must first enable logon/logoff accounting. You can direct the auditlog output to a file.

Syntax

auditlog [username | session] [/eventlog:filename] [/before:mm/dd/yy] [/after:mm/dd/yy]

[[/write:filename] | [/detail | /time] [/all]]

auditlog [username | session] [/eventlog:filename] [/before:mm/dd/yy] [/after:mm/dd/yy]

[[/write:filename] | [/detail] | [/fail ] | [ /all]]

auditlog [/clear:filename]

auditlog [/?]

Parameters

filename

The name of the eventlog output file.

session

Specifies the session ID for which to produce a logon/logoff report. Use this parameter to examine the logon/logoff record for a particular session.

mm/dd/yy

The month, day, and year (in two-digit format) to limit logging.

username

Specifies a user name for which to produce a logon/logoff report. Use this parameter to examine the logon/logoff record for a particular user.

Options

/eventlog:filename

Specifies the name of a backup event log to use as input to auditlog. You can back up the current log from the Event Log Viewer by using auditlog /clear: filename.

/before:mm/dd/yy

Reports on logon/logoff activity only before mm/dd/yy.

/after:mm/dd/yy

Reports on logon/logoff activity only after mm/dd/yy.

/write:filename

Specifies the name of an output file. Creates a comma-delimited file that can be imported into an application, such as a spreadsheet, to produce custom reports or statistics. It generates a report of logon/logoff activity for each user, displaying logon/logoff times and total time logged on. If filename exists, the data is appended to the file.

/time

Generates a report of logon/logoff activity for each user, displaying logon/logoff times and total time logged on. Useful for gathering usage statistics by user.

/fail

Generates a report of all failed logon attempts.

/all

Generates a report of all logon/logoff activity.

/detail

Generates a detailed report of logon/logoff activity.

/clear:filename

Saves the current event log in filename and clears the Event log. This command does not work if filename already exists.

/?

Displays the syntax for the utility and information about the utility’s options.

Remarks

Auditlog provides logs you can use to verify system security and correct usage. The information can be extracted as reports or as comma-delimited files that can be used as input to other programs.

You must enable logon/logoff accounting on the local server to collect the information used by auditlog. To enable logon/logoff accounting, log on as a local administrator and enable logon/logoff accounting with the Audit Policy in Microsoft Windows.

Security Restrictions

To run auditlog, you must have Windows administrator privileges.

will update the below mentioned commands soon...............

change client: Change client device mapping.

 Chfarm: Change the server farm membership of the server, create an additional farm, and configure a replacement data store.

Ctxkeytool: Generate farm key for IMA encryption.

Ctxxmlss: Change the Citrix XML Service port number.

Dscheck: Validate the integrity of the server farm data store.

Dsmaint: Maintain the server farm’s data store.

 Enablelb: Enable load balancing for servers that fail health monitoring tests.

Icaport: Configure TCP/IP port number used by the ICA protocol on the server.

imaport Change IMA ports.

migratetosqlexpress Migrate the server farm’s data store from a Microsoft Access database to a SQL Server Express database.

query View information about server farms, processes, ICA sessions, and users.

twconfig Configure ICA display settings.

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