This is a reposting of an article I originally wrote on my Developing for Dynamics GP blog.
Time and time again I have heard consultants say that the solution to stopping Microsoft Dynamics GP remembering the last user on a Terminal Server or Citrix installation is to make the Dex.ini file read-only. There was even a Knowledge Base (KB) article that suggested clearing the SQLLastUser setting from the Dex.ini file and then marking the file as read-only. Well, in my opinion this method has always been evil and from Microsoft Dynamics GP 10.0 onwards will not work anyhow.
This topic came up a little while ago after I saw the following blog post: Making the Dynamics GP User ID field blank on Terminal Servers. I wanted to expand on the topic to explain why I believe it is evil and what you can do instead.
When a user logs into Microsoft Dynamics GP, their User ID is written down to the SQLLastUser Dex.ini setting. When Dynamics GP is launched, it reads that setting and populates the User ID on the login window. For a stand alone workstation, this is a great time saver as the user does not need to re-enter their name every time they log in. This is why the setting was created in the first place.
On a Terminal Server or Citrix system, where multiple users are running Dynamics GP from the same application folder and usually sharing a single Dex.ini, this becomes a pain as the previous User ID has to always been removed. It can also be a security risk as it provides half of the User ID / Password combination needed to login.
Making the Dex.ini file read-only after ensuring the SQLLastUser setting is either removed or blank prevents Dynamics from writing to the Dex.ini file and so the setting remains blank.
“Great, problem solved” you might think. Well, only if you don’t count the side effects….
Evil Side Effects
Not being able to write to the Dex.ini file will break any Dexterity application which expects to be able to read and write to the Dex.ini file at will. In my years of development I have stored many different values in the Dex.ini file.
For example: settings used during installation; settings relating to the physical workstation and not to any user or company; window size and position data; settings needed before actually logging in to SQL Server. If the Dex.ini is marked as read-only, any code relying on using the Dex.ini for data storage will fail to work.
When I worked as an ISV, I had a large number of support cases where the install wizard for my products failed to launch because the Dex.ini file was read-only and the setting which was used to tell the installation wizard to launch after login was missing because it failed to be written when the chunk file was installed.
That said, it is now a moot point as from Microsoft Dynamics GP v10.0 onwards, the Dexterity runtime will not use a Dex.ini marked as read-only. If the Dex.ini file in the Data folder is marked as read-only, the Dexterity runtime will create a new writable Dex.ini file in the user’s home folder. The problem is that this new Dex.ini file will be empty and will not contain all the settings required to launch Dynamics GP. Instead you will be presented with the following Dexterity Runtime window looking for the Dictionary Location ID:
So what can you do to stop the last user being shown. Below are some suggestions:
- You can use the hybrid VBA / Dexterity method described in the following article: Hybrid – Clearing the Last User on a Terminal Server Example. This does require Modifier & VBA or the Customization Site License to be registered.
- You can use the option to “forget the last user” which I originally added to Omni Login, now sold as part of Omni Tools by Rockton Software.
- My preferred solution is to use the Support Debugging Tool’s Dex.ini Configuration window to set the SQLLastUser setting to a blank value. The Dex.ini Configuration window can used to roll out any Dex.ini setting to all workstations in a system without needing to actually visit the machine.
Note: Another option is to use separate Dex.ini files for each user, then there is no need to remove the SQLLastUser setting. This is possible by specifying the pathname of the Dex.ini file as an additional parameter in the shortcut. You can use the %HOMEDRIVE%%HOMEPATH% environment variables as part of the path so that a single shortcut works for all users. If you use this method, I would still suggest using the Dex.ini Configuration window in the Support Debugging Tool to allow for centralized maintenance of the multiple Dex.ini files.
For example: the Target field in the shortcut would be: “C:Program Files (x86)Microsoft DynamicsGPDynamics.exe” “C:Program Files (x86)Microsoft DynamicsGPDynamics.set” %HOMEDRIVE%%HOMEPATH%dex.ini
Update: For Microsoft Dynamics GP 2013, the application has both System Level Dex.ini and User Level Dex.ini and so the above method is no longer recommended.
Note: The Support Debugging Tool by default stores the last company logged into in the SQLLastCompany Dex.ini setting. You can use the Dex.ini Configuration window to clear this setting when you add SQLLastUser, if desired.
For more information on the Support Debugging Tool, please visit the Support Debugging Tool Portal.
So don’t be evil.
07-Sep-2010: Added information about SQLLastCompany Dex.ini setting.
12-Feb-2014: Added example use of %HOMEDRIVE%%HOMEPATH% for Dex.ini location and mention of User Level Dex.ini files in Microsoft Dynamics GP 2013.
This article was originally posted on the Developing for Dynamics GP Blog and has been reposted on http://www.winthropdc.com/blog.