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:
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.
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.
Just a small point but GP10 can use a read-only dex.ini, you just need to specify it in the launch path.
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.
Posting from Mark Polino at DynamicAccounting.net
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!! :)
Posting from Mohammad Daoud
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.
PLEASE READ BEFORE POSTING
Please only post comments relating to the topic of this page.
If you wish to ask a technical question, please use the links in the links section (scroll down, on right hand side) to ask on the Newsgroups or Forums. If you ask on the Newsgroups or Forums, others in the community can respond and the answers are available for everyone in the future.