Why making the Dex.ini file read only is evil

David Meego - Click for blog homepageThis 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.

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:

  1. 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.
  2. 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.
  3. 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.

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.

This article was originally posted on the Developing for Dynamics GP Blog and has been reposted on http://www.winthropdc.com/blog.

13 thoughts on “Why making the Dex.ini file read only is evil

  1. 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.
    David

    Like

  2. 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!! 🙂

    Like

  3. 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.

    Like

  4. 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?
    Thanks

    Like

  5. 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.
    David

    Like

  6. 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??

    Like

  7. 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

    Like

Please post feedback or comments

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.