• Conversant Group: On average SMBs lose $141,000 per ransomware incident. We keep the bad guys away.

    Learning to Migrate a Citrix XenApp Data Store from Microsoft Access to Microsoft SQL Server

    27When a Citrix Farm is created, by default, the data store is created on the first server of the Farm using an Access database.  This article will teach you how to backup an Access data store and migrate that data store from Access to SQL Server.

    There are a couple of advantages to using Access for the data store:

    • Easy to setup during XenApp installation
    • No complicated ODBC DSN file to create or configure

    The disadvantages to using Access for the data store:

    • If the XenApp server hosting the data store goes down or is restarted, Farm functionality is severely crippled
    • Only recommended for very small Farms because of performance reasons
    • No High Availability options
    • Rarely included in backup or disaster recovery planning

    The advantages to using SQL Server for the data store:

    • Is not run on a XenApp server
    • Can be used for any size Farm
    • High Availability options
    • Usually included in backup and disaster recovery planning

    For this article, VMware Workstation 6.5.1-126130 will be used with Windows Server 2008 Standard (x86) and Citrix XenApp for Windows Server 2008 Platinum (x86).  The following Virtual Machines (VM) will be used:

    • Domain Controller: CitrixDC
      • The VM will be assigned one processor, 1GB of RAM and 16GB of Hard Drive space
      • Domain Controller for the WebstersLab.com Active Directory domain
      • Terminal Server License server and Citrix Licensing server
      • Static IP Address
    • SQL Server: CitrixSQL1
      • The VM will be assigned one processor, 2GB of RAM and 16GB of Hard Drive space
      • This VM will host the new migrated to SQL Server data store
      • This VM will use SQL Server 2005 SP3
      • Static IP Address
    • XenApp 5 #1: CitrixXA1
      • The VM will be assigned one processor, 2GB of RAM and 16GB of Hard Drive space
      • This VM will host the original Access data store
      • Static IP Address
    • XenApp 5 #2: CitrixXA2
      • The VM will be assigned one processor, 2GB of RAM and 16GB of Hard Drive space
      • This VM is used to show how to change additional XenApp servers to use the new SQL Server data store
      • Static IP Address

    CitrixDC has a file share named CTXBACKUP that I will use to store the data store backup.  XenApp 5 for Windows Server 2008 was installed on CitrixXA1 and a new Farm named Webster was created during the installation.  After restarting the VM, XenApp 5 for Windows Server 2008 was installed on CitrixXA2 and then this instance was joined to the Webster Farm.  Two applications were published on the Farm: Notepad and Paint.  Both applications are configured to run from both XenApp servers.

    Figure 1
    Figure 2
    Figure 3

    It is a Best Practice to always backup the data store before performing the migration.  The Access based data store, by default, is located in C:\Program Files\Citrix\Independent Management Architecture and is named MF20.mdb.

    From a command prompt on CitrixXA1, the following command was run to generate a backup:

    dsmaint backup \\CitrixDC\CTXBackup

    The command “dsmaint backup” makes a copy of the MF20.mdb Access data store to the location specified.  “dsmaint backup” is used only to backup an Access data store and must be run on the XenApp server hosting the Access data store.  It cannot be used to backup a data store which is using MSDE, SQL Server 2005 Express, SQL Server, Oracle or DB2.

    This article is using the concepts from Citrix support article CTX677542.  For SQL Server Database specific information, please see page 183 of the XenApp Installation Guide.

    BEFORE YOU START THE MIGRATION, make sure the account being used for this procedure is a Full Farm Administrator.

    Note:  If you have a Microsoft SQL Server DBA available, please reference the Citrix Support article Citrix Presentation Server and Microsoft SQL 2005 Configuration.

    To create the SQL Server data store database, open SQL Server Management Studio.  Click Start -> All Programs -> Microsoft SQL Server 2005 -> SQL Server Management Studio.

    Figure 4
    Figure 5
    Figure 6

    Expand Databases in the left column.

    Figure 7

    Right-click Databases and select New Database.

    Figure 8

    It is recommended to put the Farm name in the database name.

    Figure 9

    Click Options and make sure Recovery Model is set to Full and Compatibility Level is set to SQL Server 2005 (90).  Click OK.

    Figure 10

    The new data store database is ready for use.

    Figure 11

    On the XenApp server hosting the Access data store, a new Data Source Name (DSN) needs to be created for the SQL database.

    Click Start -> Administrative Tools -> Data Sources (ODBC).

    Note: What is ODBC?  This is taken from http://support.microsoft.com/kb/110093

    “Open Database Connectivity (ODBC) is Microsoft’s strategic interface for accessing data in a heterogeneous environment of relational and non- relational database management systems. Based on the Call Level Interface specification of the SQL Access Group, ODBC provides an open, vendor- neutral way of accessing data stored in a variety of proprietary personal computer, minicomputer, and mainframe databases.

    ODBC alleviates the need for independent software vendors and corporate developers to learn multiple application programming interfaces. ODBC now provides a universal data access interface. With ODBC, application developers can allow an application to concurrently access, view, and modify data from multiple, diverse databases.”

    Figure 12

    Click the File DSN Tab.

    Note:  What is the difference between “User DSN”, “System DSN” and “File DSN”?  This is taken from http://support.microsoft.com/kb/213772.

    User DSN: The User DSN is a data source that is user-specific. A User DSN is stored locally but is available only to the user who creates it.

    System DSN: Unlike a User DSN, a System DSN is not user-specific. A System DSN is stored locally and is not dedicated to a particular user. Any user who logs on to a computer that has permission to access the data source can use a System DSN. Some programs, such as Microsoft SQL Server or Microsoft Internet Information Server (IIS), require a System DSN. This DSN must be created on the server where the program is located. System DSNs are stored in the Windows registry under the following key: HKEY_LOCAL_MACHINE\Software\Odbc\Odbc.ini\Odbc Data sources

    File DSN: The File DSN is created locally and can be shared with other users. The File DSN is file-based, which means that the .dsn file contains all the information required to connect to the data source. Note that you must install the ODBC driver locally to use a File DSN.  File DSNs are not stored in the Windows registry. The .dsn file is a text file that you can view in any text editor, such as Microsoft Notepad.

    Figure 13

    Change the Look in to C:\Program Files\Citrix\Independent Management Architecture.  The new DSN must be placed in this folder.  The IMASERVICE service is programmed to look in only this folder.

    Figure 14

    Click the Add button.

    Figure 15

    Click on SQL Server and click Next.

    Figure 16

    Type in C:\Program Files\Citrix\Independent Management Architecture\WebsterFarmDSMF20.dsn and click Next.

    Note: The DSN can be named anything as long as it has a .dsn file extension.  It does not need to contain “MF20” anywhere in the name.

    Figure 17

    Click Finish.

    Figure 18

    Enter a Description and type in the name of the SQL Server and click Next.

    Figure 19

    If a successful connection to the SQL Server is made click Next.  A common problem is the Windows Firewall is not configured to allow SQL traffic (TCP Port 1433).  To configure an instance of SQL Server 2005 to use a static port, follow the steps described in the “How to: Configure a Server to Listen on a Specific TCP Port (SQL Server Configuration Manager)” topic in SQL Server 2005 Books Online.

    Note:  If SQL Server is set to use a static port, click Client Configuration, then uncheck Dynamically determine port and enter the value for the static port number.

    Figure 20
    Figure 21

    If the account listed in the grayed out Login ID authenticates successfully to the SQL Server, Change the default database to the new SQL Server data store and click Next.

    One problem could be the Login ID account is not setup to access the SQL Server.

    Figure 22

    Click Finish.

    Figure 23

    Click Test Data Source.

    Figure 24

    If the message TESTS COMPLETED SUCCESSFULLY is shown, click OK.  Otherwise, you will need to troubleshoot the ODBC connection to the SQL Server.

    Figure 25

    Click OK.

    Figure 26

    Your new DSN is created.  Click OK.

    Figure 27

    Click Start, right-click Command Prompt and select Run as administrator.

    Figure 28

    Type in DSMAINT MIGRATE /srcdsn:”C:\Program Files\Citrix\Independent Management Architecture\MF20.dsn” /srcuser:citrix /srcpwd:citrix /dstdsn:”C:\Program Files\Citrix\Independent Management Architecture\WebsterFarmDSMF20.dsn” /dstuser:websterslab\administrator /dstpwd:password and press Enter.

    /srcdsn is the Access MF20.dsn that was created when the Farm was created

    /srcuser and /srcpwd are both, by default, “citrix”

    /dstdsn is the new DSN file

    /dstuser and /dstpwd are the username and password of the account that has rights to the new data store SQL database

    Click Yes on the Dsmaint confirmation popup.

    Figure 29

    The migration starts.

    If the following error is received:

    “Result: “an unknown error occurred while migrating the table, please verify the destination datasource is clean. [Microsoft][ODBC SQL server Driver][SQL server]violation of primary key constraint ‘CL’. Cannot insert duplicate key in object “keytable”. Indexes have been successfully patched.”

    This is usually caused by the default database being set to Master.  That is a huge mistake.  Make sure the default database for the DSN file is set to the new data store database.

    Figure 30

    When the migration completes, answer Yes to the Dsmaint comparison popup.

    Figure 31

    The comparison runs and completes.

    Figure 32
    Figure 33

    Next DSMAINT CONFIG needs to be run.  The /pwd option needs to be used and according to the XenApp Administrator’s Guide:

    “You must stop the Citrix Independent Management Architecture service before using config with the /pwd option.”

    In the command prompt window, type NET STOP IMASERVICE and press Enter.

    Figure 34

    Type in DSMAINT CONFIG /user:websterslab\administrator /pwd:password /dsn:”C:\Program Files\Citrix\Independent Management Architecture\WebsterFarmDSMF20.dsn” and press Enter.

    Figure 35

    Type in NET START IMASERVICE and press Enter.

    One cause of the IMASERVICE not restarting is the currently logged in account is not a Full Farm Administrator.

    Figure 36

    Type in CD “C:\Program Files\Citrix\Independent Management Architecture” and press Enter.

    Copy the new DSN file to the remaining XenApp server’s C:\Program Files\Citrix\Independent Management Architecture folder.

    Figure 37

    Edit the copied DSN file and change the WSID line to reflect the name of that XenApp server.

    Figure 38
    Figure 38

    On each remaining XenApp server, type in:

    NET STOP IMASERVICE and press Enter.

    DSMAINT CONFIG /user:websterslab\administrator /pwd:password /dsn:”C:\Program Files\Citrix\Independent Management Architecture\WebsterFarmDSMF20.dsn” and press Enter.

    NET START IMASERVICE and press Enter.

    On any of the XenApp servers, start the Access Management Console (AMC).

    Figure 39

    The AMC communicates with the data store to retrieve the Farm information.

    If any errors are received, go to http://support.citrix.com and search for the error number.

    An alternate way to test connectivity to the data store is from a command prompt type in QFARM and press enter.

    You learned how to:

    • backup an Access data store
    • Create a new File DSN for a SQL Server data store
    • Migrate to the new data store
    • Configure all XenApp servers to communicate with the new data store
    • Stop and restart the IMA service on a XenApp server
    • Using the Access Management Console, verify communication with the new data store
    , , , , ,

    Conversant Group: On average SMBs lose $141,000 per ransomware incident. We keep the bad guys away.

    About Carl Webster

    Webster is a Sr. Solutions Architect for Choice Solutions, LLC and specializes in Citrix, Active Directory and Technical Documentation. Webster has been working with Citrix products for many years starting with Multi-User OS/2 in 1990.

    View all posts by Carl Webster

    No comments yet.

    Leave a Reply