UPDATE: It has been several years since I had to deal with this, so it seems that at least one of my proposed solutions are outdated. David Musgrave has weighed in with his feedback in the reader comments.
This is an oldie, but a goodie.
Dynamics GP was designed with certain assumptions in mind. For instance, as a client application, GP assumes that a user would like to save certain settings and preferences so that they are retained for the user the next time they launch GP.
This typically works great on a single client PC, but when you install Dynamics GP on a Terminal Server, sometimes this can be annoying.
One of these saved settings is the user ID of the last user that logged into GP. On a Terminal Server with numerous users logging in and out of GP throughout the day, the last User ID is generally a random user ID. When a user logs in, they have to substitute their user ID.
Some GP customers don't even notice this "feature", but other customers consider this behavior very annoying or a security issue, and demand that it be changed.
Fortunately, there is a solution. Two actually.
Option 1 is to use a VBA script to blank out the User ID field when the GP login window is displayed. This solution is discussed in KB Article 859129, "Blank User ID in Great Plains". It is simple to implement, and in my experience, works well.
UPDATED: Ignore this second suggestion! See reader comments for more information.
Another solution that I learned somewhere is to make the Dex.ini file read only. Since the Dex.ini contains the SQLLastUser setting that GP uses to populate the User ID field on startup, if you make this setting blank, and then make the Dex.ini file read only, GP will always display a blank User ID value.
Although this technically works, there are some possible drawbacks to this approach. As I mentioned, GP saves several settings and preferences to make users' lives easier, so by making the Dex.ini file read only, you are not only disabling the last user ID feature, you are preventing GP from saving dozens of other preferences, some of which may cause new annoyances for users, or even problems for GP.
I was unable to find the Dex.ini solution in the Knowledge Base (it may be in there, but my searches didn't locate it), so because of the potential side effects, I suspect that it may not be a supported solution.
But just thought I would share both since I've seen both of them implemented.
A third solution (and one that is standard in my practise) is to copy the Dex.ini file into each users' Active Directory roaming profile. This way, the GP functionality including all their user preferences work as if they are running on a personal local machine, as each user has their own Dex.ini file at that point.
ReplyDeleteThe downside of this is if you need to make a system-wide change to the Dex.ini, you either have to update each user, or overwrite their preferences.
One additional upside, however, is that some lines in the Dex.ini file control access to GP features such as the Run Integration menu that you might want only some users to have, and aren't controlled by security.
Steve,
ReplyDeleteI believe setting the Dex.ini as read-only is no longer a viable option in v10. We recently tried it (as suggested by MS) and the results were the users not been able to login into the system at all.
I've always used the read-only trick, however I can confirm that this appears to cause errors on login in GP 10. I've used the separate dex.ini file for each user profile before, but found it too much of a headache to maintain. I'll have to give the vba script a try when it comes up again.
ReplyDeleteHi Guys
ReplyDeleteA few comments.
1) Making a dex.ini read only will break many dexterity applications that expect to be able to write to the dex.ini.
2) Making a dex.ini read only does not work for v10.0 onwards as the runtime will then create a new writable dex.ini in the user's home folder.
3) There is a hybrid VBA/Dex method described in the following article:
http://blogs.msdn.com/developingfordynamicsgp/archive/2008/07/29/hybrid-clearing-the-last-user-on-a-terminal-server.aspx
4) The Support Debugging Tool's Dex.ini configuration tool can be used to change, edit or clear any dex.ini setting automatically.
5) The Support Debugging Tool's Dex.ini configuration tool can be used to roll out a dex.ini setting change to all workstations without needing any manual editing on each workstation.
http://blogs.msdn.com/developingfordynamicsgp/pages/support-debugging-tool.aspx
David
http://blogs.msdn.com/DevelopingForDynamicsGP/