Using Dynamics GP in a Citrix / TS environment

I often come across discussions in forums and community posts about the problems related to the end-user parameters stored in the DEX.ini file from GP.

Now the problem with shared environments is the reality that all the users are using the program folder to launch the application, thus also the same same settings from the DYNAMICS.SET and the DEX.ini to save the parameters. This can lead to some very confusion situations…. I had users calling in and saying they started a new GP session but only get the icon in the task bar, but actually never get to the login screen.

It took me some investigation back in 2010 or 2011 when this happened the first time, and it was coincidentally at the time when some users started to request a second monitor to increase their productivity :-)…

As it turned out at that time, Dynamics GP was used on the Citrix XenApp server by the vast majority of our users (around 120) and there was a single DEX.ini file for all the users, which means that every time a user launched the application remotely, it was showing the last user ID that logged in previously and also put the main GP windows at the screen coordinates where it was closed the last time. This was not too bad as long as everyone had pretty much the same configuration for the hardware (screen and printer), but soon as people started using 2 or more monitors, and moved the main GP window off the monitor #1, then the next user would run into troubles if he/she didn’t had the same setup.

That’s when I came across a blog post from my good friend David Musgrave  (at that time) from Microsoft Australia, who wrote something about the side-effects of shared DEX.ini files and how to avoid collisions in shared environments.

His article inspired me to find a smart way to make sure when a user would start GP the first time from the Citrix server that he would get a clean pristine DEX.ini file that become he/her own and contains only the settings from their sessions. No more hidden windows and lengthy DEX.ini files that would grow out by endless printer queue entries.

So I created a small batch file that would check the presence of an existing DEX.ini file in the owner’s home profile under the system hidden AppData folder. The content of the batch file looks like this :

 @echo off
rem This file is used to launch Dynamics GP
rem from within CITRIX MF without parameters
rem echo Press any key to start the GP apps
rem pause
rem Modified version to TEST SP3 1:07 PM 7/13/2012
c:
cd “C:\Program Files (x86)\Microsoft Dynamics\GP11SP3″
if exist %HOMEDRIVE%%HOMEPATH%\AppData\Local\Dex.ini Goto StartGP
copy C:\Users\Default\AppData\Local\Dex.ini %HOMEDRIVE%%HOMEPATH%\AppData\Local\Dex.ini
:StartGP
start Dynamics.exe Dynamics.set %HOMEDRIVE%%HOMEPATH%\AppData\Local\Dex.ini
cd \

Save the file as a .cmd in the Program Folder location of your GP application on the Citrix server. Make sure you have fresh and pristing DEX.ini file copy in the Default user home path (see location above).  You can take the current DEX.ini file from your GP Data folder and remove any references to the ‘remembered’ printers and clear out the last user in the file :

SQLLastUser=
RememberUser=FALSE

It’s important to set the 2nd value to FALSE, otherwise GP will try to auto-login the user and this would fail since there is no user-id.

Lets assume you named your file GP_Roaming.cmd, then your new launch file command line would look like this :

“C:\Program Files (x86)\Microsoft Dynamics\GP\GP_roaming.cmd”

There is no need anymore for a parameter provided in the published application for Citrix, since everything is already passed in the .cmd file itself.

One last tip when you apply a new service pack or a year-end update to your GP. When updating your client on the Citrix or TS server, only the DEX.ini that’s sitting in the GP Data folder gets updated… none of the distributed config files from the users home profile…Remember to delete them all before given the updated GP apps free again for the users (the nice thing with published apps is that you can quickly enable/disable them).

If you don’t want to delete the files, use a VBS script or Powershell to loop through all the DEX.ini’s and make the changes.. I wouldn’t necessarily recommend this way of doing it, since during a service pack upgrade, there are quite a few changes applied to the file.

Test the new launch file with a few users and do adjustments if required. This procedure has worked pretty well for our company since about 3-4 years now and has successfully been ported to a newly built Windows 2012 Remote Desktop Application Server.

Until next post…
@GP_Beat