Link to home
Start Free TrialLog in
Avatar of jnordeng
jnordeng

asked on

Can't create new farm, seems to be related to SQL Driver

Setup, Citrix XenApp 6.5.  Running on Windows 2008 R2.  Farm consists of 4 nodes (XenApp servers).  

Due to issues, we have been asked to create a new Farm for our Test Environment.  

Had the DBA's create a new database without any data.

So the process, have removed one of the existing FARM servers from the TST farm using the XenApp installer.  Success
So, have run the installer and selected to create a new farm, however; it keeps erroring on the Initializing the Citrix Data Store.  "Initializing the Citrix data store failed.

Check the Windows Event Log for warning or error messages that may provide details on this error and how this issue may be resolved."

I look in the Event log and I see, "Citrix XenApp failed to connect to the Data Store. ODBC error while connecting to the database: S1000 -> General error: Invalid file dsn ''

This is where I'm not sure what to do.

So, at the command line, I have Recreated the Cache (dsmaint recreatelhc) and rade cache (dsmaint recreaterade).  I have verified through ODBC that I can indeed connect to the SQL Server (which I was able to do before this upgrade as this was an active member of the existing farm).  

What appears to be happening is that though I updated the SQL Server driver and tested this to be compatible with SQL as we had to update a few months back for TLS, that something in here is not working as expected when running the installer.

I also tried from the command line running, "dsmaint config /user:CitrixUser /pwd:Password /dsn:"C:\Program Files (x86)\Citrix\Independent Management Architecture\mf20.dsn"  This shows success when I update the driver from SQL Server to SQL Server Native Client 11.0.  The installer updates this each time in the mf20 back to SQL Server.  Though I have verified on the Server itself I can connect to the Database using 'SQL Server' as the driver and it's running the same dll version as SQL Server Native Client 11.0, but it does actually update the DSN to use SQL Server Native Client 11.0 instead of SQL Server which I'm selecting

So long and short of it, the installer is altering the driver being used back to SQL Server and ignoring the fact it's the right version.  And the IMA service will no longer start.

The error for IMA is The Citrix Independent Management Architecture service terminated with service-specific error The operation completed successfully..

Not sure what to do here.  One thought, completely uninstall Citrix and reinstall rather than just create a new farm.  (Have also verified in the registry at HKLM\Software\Wiw6432Node\Citrix\IMA that the Neighborhood is the new farm I'm trying to create.

Also as a troubleshooting step, I reverted the node to rejoin the old/existing farm and it worked first try, like a charm, it's just generating a new farm that fails.

Any help is greatly appreciated.
Avatar of Raja Jegan R
Raja Jegan R
Flag of India image

>> "Citrix XenApp failed to connect to the Data Store. ODBC error while connecting to the database:

Since the error is related to ODBC, I would suggest you to first try installing the below ODBC driver to see whether it helps out or not..
https://www.microsoft.com/en-us/download/details.aspx?id=53339

If it doesn't help, then you can try starting from scratch..
Try creating the DSN this way

Logon as "Citrix Service Account" credentials (unless your using SQL authentication and ignore this step...will address in last step)
Click Start -> Administrative Tools -> Data Sources (ODBC)
Click the File DSN Tab
Change the Look in to C:\Program Files (x86)\Citrix\Independent Management Architecture
Click the Add button
Click on SQL Server Native Client 11.0 and click Next
Type in C:\Program Files (x86)\Citrix\Independent Management Architecture\NewMf20.dsn (use a different name other than mf20.dsn)
Click Finish
Enter a Description, type in the name of the SQL Server and click Next.
If a successful connection to the SQL Server is made click Next
Define the static port (generally 1433) (unless Dynamic otherwise uncheck Dynamic)
Check authentication (will used logged on credentials and greyed out (best to login first as Citrix Svc account)
Set the Default Database to your new Citrix DB
Click Finish
Test Data Source
Click OK

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

Type:

dsmaint migrate /srcdsn:”C:\Program Files (x86)\Citrix\Independent Management Architecture\MF20.dsn” /srcuser:citrix /srcpwd:citrix/dstdsn:”C:\Program Files (x86)\Citrix\Independent Management Architecture\NewMF20.dsn” /dstuser:administrator /dstpwd:password

Press Enter

Note: /dstuser and /dstpwd is the user and password for the SQL account or other user that has access to the DB

Upon completion and "Yes" to Dsmaint popup

Open CMD prompt
Type "net stop imaservice"

Then type:
dsmaint config /user:YOURDOMAIN\someadmin /pwd:password /dsn:”C:\Program Files (x86)\Citrix\Independent Management Architecture\NewMF20.dsn”

Then:
dsmaint recreatelhc

Then:
net start imaservice
Avatar of jnordeng
jnordeng

ASKER

Awesome, thanks for the feedback, I will give that a shot and report back here.
One question, will the migrate simply take a copy, and not remove what's currently in the database?
Well, it would migrate data from existing SQL to your new SQL for that one test server and SQL server in Test so that you have that information in test.  It doesn't remove data from existing production.

Since your going from SQL to SQL, however, I checked the old KB and they recommend

I would take a look at
https://support.citrix.com/article/CTX123111

The section: Migrating the Database to a Different Version of the Same Software
Migrating from one database version to the other might be necessary to move the data store to a more powerful server. The best method for migrating between versions of the database is to back up and restore the database using the utilities provided by the database software vendor.

Take out the dsmaint migrate and use this for that step.  If memory serves, I had used this to migrate from Access to SQL but it would be easier in this case to do the backup and restore.

I would review this CTX article as well, first, and let me know if you have any other questions before moving forward.

And then
To Migrate between SQL servers
On the SQL Management Studio in SQL Server, right click on the database and select Export. in the options make sure you are exporting full database.
https://msdn.microsoft.com/en-us/library/ms187510.aspx 
Copy the back file over to the new SQL server
On the new SQL server, right click and say restore database. Select device and point to the back file in step 2
https://msdn.microsoft.com/en-us/library/ms177429.aspx
Thanks, we started with a shell as there is an issue in our test farm that we do not have in production.  It is related to our Java based applications.  They randomly error.  We've tested various things including pulling a production server was switched to the test farm to rule out vm/frame setup and that production system errored.  So the the next thought is that there is a problem in the test farm itself .  So, we were trying to create new in the event there is something wonky in the database/farm.

However; I don't understand how there would be an issue in the farm as Citrix.  So a troubleshooting step.

Good information though, really don't understand why trying to generate a new farm has broken this server though.  Though I can connect back to the existing test farm, I did noticed in troubleshooting creating a new one that MFCOM is now stuck in a starting state and IMA won't start.  So seems there is something else happening now on this particular server.
Having a Test farm is mandatory and best practice.

Citrix didn't break anything.... Things like this happen when you change the parameters like version of SQL Server.  This is a deviation from current Prod.  

Best Practice is to stand up a Test environment that is identical to your production, being it is after the fact - preferably before.

Then you stand up a Dev Farm to change your parameters like moving to a new version of SQL...So, yes, technically three farms because one of those Test environments is for you and the other is for your development team to have full fledged access to test their code in the actual operating system with the same parameters as production.  I'm surprised they have not requested this or not been given access to such a thing.

Keep in mind too that 6.5 is EOL.  Time to   So is 2008R2.

You really need to stand up a 2012R2 environment, port the application, and migrate to XenApp 7.X.

It only get's worse the longer you wait.  

Hopefully your development team is keeping that Java code updated and corresponding JVM but they should probably look at alternate programming language.

Citrix is merely the conduit to the business application.  It cannot fix applications and it doesn't break them.  It often becomes a dumping ground for applications developed in single-user operating systems like Windows 7 or earlier.  Then, an excuse is made not to update the code...just throw it in Citrix.

Well, Citrix runs on top of Windows Server operating system then Terminal Services/Remote Desktop Services which enables a multi-user component not present in a distributed client architecture and then Citrix adds the ICA/FMA protocol, Citrix Policies, Universal Print Driver, User Profile Management, Storefront/Web Interface, Netscaler, Delivery Controllers and a bunch of other stuff....just so you can get to the application which at the core is hosted on a Windows Server OS enabled for multi-user.

If the application doesn't work it has nothing to do with Citrix.
Thanks, appreciate your input.  I am in fact setting up a new farm, 7.15.  Wading my way through as it is a bit different and we are only using XenApp and not XenDesktop features ;)

I agree, that Citrix is just putting it out there, but most don't wish to accept that and assume since it's presenting the apps there is something with Citrix.  Why I agreed to even try this as I didn't think I'd run into so many issues as joining a node and removing a node from a farm is easy to do.

I do like the idea of my own instance, that is a great idea to have 2 Test farms instead of one.  1 for the users, 1 for those of us that are Admin's for Citrix.
I would consider the other farm for Development as well.


If you have internal or external vendors for development they need an environment that is identical to production so they can develop in the platform versus another environment that doesn't mimic current Citrix production.

It can even be in the one Test farm scenario and you simply spin up a "developer" image.

Have one read-only image using PVS as their play bed and baseline so the can do whatever.

This way you can easily revert back to baseline with a reboot.

Once they have worked out the kinks, spin up another image that is in write mode so they can implement their final change to the image and documentation.  

Bring this up in read only mode and now you have UAT image that the developers and designated end-users can perform UAT.
ASKER CERTIFIED SOLUTION
Avatar of jnordeng
jnordeng

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial