Why making the Dex.ini file read only is evil
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.
Introduction
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:
Solutions
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 Dynamics\GP\Dynamics.exe" "C:\Program Files (x86)\Microsoft Dynamics\GP\Dynamics.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.
David
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.
Comments
Anonymous
June 27, 2010
David, Just a small point but GP10 can use a read-only dex.ini, you just need to specify it in the launch path. Jon.Anonymous
June 27, 2010
Hi Jon I did not know that you could "force" it to use a read-only Dex.ini by specifying it as a parameter. If you don't specify it, it will look for a writable file in the Data folder and then the user's home folder. Still making the file read-only will break lots of code and should not be used as a solution. DavidAnonymous
June 28, 2010
Posting from Mark Polino at DynamicAccounting.net msdynamicsgp.blogspot.com/.../why-making-dexini-file-read-only-is.htmlAnonymous
June 29, 2010
Okay, so that Dictionary Location window reminds me of the Pathnames Translation window and errors from the btrieve days. That's scarey enough to make me NEVER make the Dex.ini file read only!! :)Anonymous
June 30, 2010
The comment has been removedAnonymous
October 31, 2011
Posting from Mark Polino at DynamicAccounting.net msdynamicsgp.blogspot.com/.../weekly-dynamic-last-user-fun.htmlAnonymous
March 07, 2012
We use a kix script prior to launching GP 10 which using the "writeprofilestring" function modifies the dex.ini file to pre-populate the SQLLastUser field with the logging in user's account name. After the ini is modified, we start up GP. The script is very simple to setup and use.Anonymous
February 11, 2014
Hi Dave. Any chance you can add a screenshot to the blog on how you have set up the %HOMEDRIVE%%HOMEPATH% environment variables on the GP shortcut? ThanksAnonymous
February 11, 2014
Hi Eric I have updated the article with the example Target shortcut field. Please note that this method should not be used with Microsoft Dynamics GP 2013. In general, the maintaining of separate Dex.ini files is more work that the benefits it provides, even when using the Support Debugging Tool's Dex.ini Configuration window. DavidAnonymous
June 25, 2014
David, I cannot get your last suggestion (of making the shortcut point to a user profile dex.ini) to work. Since the user profile file does not exist, it pops up the same Dictionary window as if you made the file read only. It doesn't create a new one with a copy of the original. Would I have to place a copy of the original dex.ini in every single user profile to make this work??Anonymous
July 01, 2014
Hi Josh Yes, you would need to copy the base dex.ini from application folder to the user's home folder to start with. I would avoid this method if possible as GP 2013 introduced user level dex.ini files which are contain the temp folder while the session is active and are saved in the syUserDexIniSettings (SY01405) table between sessions. David