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 his/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 pristine 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 :

DefaultLastUser=FALSE
DefaultLastCompany=FALSE
SQLLastUser=
RememberUser=FALSE

It’s important to set the RememberUser 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

Update on 2015-08-21:

There is relief to all the users that have setup GP in a Citrix or TS environment. Since GP2013 was released, you don’t need anymore to have a separate DEX.ini for each user. Read on the Blog post from my friend Mariano Gomez, Dynamics GP MVP : http://dynamicsgpblogster.blogspot.ca/2014/05/working-with-dexini-settings-in.html

To me when upgrading to GP 2015 it was a real relief to not have to deal anymore with outdated DEX.ini settings every time you do apply an upgrade / service pack to your share GP client (as only the main DEX.ini got updated by the GP Utilities process). Running the GP client with wrong release information from the DEX.ini file can be very stressful as you get all kinds of strange messages and don’t necessarily think of the user’s DEX.ini (though I haven’t tested yet the user’s DEX.ini scenario after an update).

Until next post…
@GP_Beat

Update on 2016-01-25:

After we upgraded last year the GP2010R2 to GP2013R2 (not going to 2015 was a decision based on the fact that some important features from BP were missing on the Web Client PTE), I realized that the user shared DEX.ini feature was finally not so good and in some cases not useful at all. For that reason I went back to the individual DEX.ini file for each users on the TS. This way I have a much better control over the settings. I’ll post in a future blog entry, some tips on how to quickly get rid of all the DEX.ini files after an upgrade, rather then having to painfully delete them one-by-one.
Until next post…
@GP_Beat

Update on 2021-08-18:

Here is another variant of the GP launch file I came up after realizing that it might be much easier to manage all the various DEX.ini’s in a single place, namely the GP Data folder. This one doesn’t make use of the %homepath% of the user, but would rather store them all in one place. Feel free to adjust that path to a shared network location (even better than local GP folder).

@echo off
rem This file is used to launch Dynamics GP
rem from within a RDS server without parameters
rem echo Press any key to start the GP apps
rem pause
rem Modified version to include custom DEX.ini
rem 2021/08/17 16:37
c:
cd "C:\Program Files (x86)\Microsoft Dynamics\GP"
rem check if user DEX.ini already exists
if exist .\data\%USERNAME%_Dex.ini Goto StartGP
copy .\Data\Dex.ini .\Data\%USERNAME%_Dex.ini
:StartGP
start Dynamics.exe Dynamics.set .\data\%USERNAME%_Dex.ini
cd \

In case you’re running multiple GP versions (i.e. testing a new version in parallel to production), you may want to add the following entry in the DEX.ini to prevent users from switching the ODBC connections to the wrong SQL server.

EnableServerDropDown=FALSE