Learning to Recover from a Crashed Microsoft Access Citrix XenApp Data Store
January 13, 2009
When a Citrix Farm is created, by default, the data store is created on the first server using an Access database. From this article you will learn how to backup an Access data store and how to recover from the loss of an Access data store. This is possible ONLY if you have a backup of the data store. If there is no backup of the data store, the only way to recover is to rebuild the Farm from scratch.
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 192.168.1.100
- 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 192.168.1.102
- XenApp 5 #2: CitrixXA2
- The VM will be assigned one processor, 2GB of RAM and 16GB of Hard Drive space
- This VM will host the recovered Access data store
- Static IP Address 192.168.1.103
CitrixDC has a file share named CTXBACKUP that will contain the data store backup. XenApp 5 for Windows Server 2008 was installed on CitrixXA1 and a new Farm named Webster was created. After restarting the VM, XenApp 5 for Windows Server 2008 was installed on CitrixXA2 and joined to the Webster Farm. Two applications were published: Notepad and Paint. Both applications are configured to run from both XenApp servers.
From a command prompt on CitrixXA1, the following command was run:
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 using MSDE, SQL Server 2005 Express, SQL Server, Oracle or DB2.
This article will use the concepts from Citrix support article CTX677542.
To simulate the loss of the Access data store, CitrixXA1 was powered off and CitrixXA2 was then restarted. This forced a break with the original data store.
When CixtrixXA2 restarted, there were two errors in the System Event Log.
Starting the Access Management Console (AMC) gave the following errors:
Double-clicking on each error gives more detail.
To recover from the loss of the data store, exit the AMC and start a Command Prompt session running as Administrator.
Type in cd\Program Files\Citrix\Independent Management Architecture and press Enter.
Note: A shortcut method is:
cd c* Enter
cd in* Enter
You command prompt should read C:\Program Files\Citrix\Independent Management Architecture>_
Copy your backup copy of the MF20.MDB data store file to this folder. For this article: copy \\CitrixDC\CTXBackup\mf20.mdb
Notice there is no MF20.DSN file.You will learn how to create the necessary DSN file.
Click Start -> Administrative Tools -> Data Sources (ODBC)
Click the File DSN Tab.
Change the Look in to C:\Program Files\Citrix\Independent Management Architecture.
Click the Add button.
Click on Microsoft Access Driver (*.mdb) and click Next.
Type in C:\Program Files\Citrix\Independent Management Architecture\MF20.dsn and click Next.
Change Directories to C:\Program Files\Citrix\Independent Management Architecture and double-click mf20.mdb.
Delete admin from the Login name and click OK.
Your new MF20 DSN file is created. Click OK.
Return to your Command Prompt session, type in dir and press Enter. Your new mf20.dsn file is there.
To see the contents of mf20.dsn, type TYPE MF20.DSN and press Enter.
From your Command Prompt session, type in DSMAINT FAILOVER CitrixXA2 and press Enter.
Note: This needs to be done on all XenApp servers in your Farm.
Type in DSMAINT CONFIG /DSN:”C:\Program Files\Citrix\Independent Management Architecture\mf20.dsn” and press Enter.
Stop and restart the IMA service. Type in NET STOP IMASERVICE && NET START IMASERVICE and press Enter.
If there are other XenApp servers in your Farm, the IMA service must be stopped and restarted on all XenApp servers in the Farm.
Exit the Command Prompt session and start the AMC.
You will receive an error with the dead server’s name.
Opening the AMC shows the two published applications, both XenApp servers and the Default Zone. This proves you have successfully read from the recovered Access data store.
The dead server needs to be forcefully removed from the Farm. Citrix Best Practice for removing a XenApp server from a Farm is to uninstall all XenApp software components. Removing the XenApp software components will cleanly remove all traces of a server from the data store. For this article, our “dead” server needs to be forcefully removed.
Click the server to be removed in the left column and then in the middle column under Other Tasks, click Remove from farm.
Click Yes to forcefully remove the server from the Farm.
The dead server has been removed from the Farm and from both published applications.
To verify that the two published applications still work, use Program Neighborhood.
When Program Neighborhood starts, it sees the Webster Farm.
After successfully authenticating to the Farm, the two published application icons appear. Double-click each icon to start the published applications.
Both Notepad and Paint successfully launch.
There is one common error when installing XenApp with an Access data store that can trip up recovery efforts: logging into the local server instead of the domain. This can happen when the default account name of Administrator is used to logon to the server.
When a new Farm is created, the Domain field is the server name and not the domain name. In this screen shot, the Domain is CitrixXA1 instead of WebstersLab.
Taking the time to verify information on the install screens can prevent issues later. This screen shot shows the Farm administrator will be CitrixXA1\Administrator and not WebstersLab\Administrator. This will be a major problem when attempting to recover the Access data store. You will be logged in on another server and will not be allowed to access the data store due to an invalid login name. With this install option, only the one account, Administrator, on the server CitrixXA1 has rights to the Farm. Unless you added additional Full Farm Administrators, you will have no access to the Farm information in the data store.
When joining additional XenApp servers to the Farm, you are required to enter the account credentials from CitrixXA1 to access the Access data store.
Even if you enter the proper domain account credentials, it will not work. The Domain Admin account does not have rights to the Access data store.
After successfully running the recovery steps above, you get the starting the AMC for the first time after recovery. You will get two errors during the Discovery process. The 1st error on CITRIXXA1 is because the server crashed and is no longer available.
The 2nd error on CITRIXXA2 is because the logged in account is not a Farm administrator and cannot access the data store.
When you return to the AMC, you see there are no Applications, no Servers and no Zone.
There is one possible way of recovering from this. Use a virtualization tool to bring up a server image with the same name as the original server and go through the recovery steps above. When the AMC loads with no errors, add additional Full Farm Administrators using local administrator accounts from the other servers in the Farm. Copy the data store file, MF20.MDB, to another server and rerun the recovery steps on a different server.
You learned how to:
- backup and restore an Access data store
- Create a new File DSN for an Access data store
- Failover to the new data store
- Configure the new host server to host the Access data store
- Stop and restart the IMA service on the new host server
- Stop and restart the IMA service on all remaining servers in the Farm
- Forcefully remove a XenApp server from the Farm
- Verify published application functionality
- Prevent a common error and how to recover from that error