Working with the Dex.ini Settings in Microsoft Dynamics GP 2013
Dex.ini settings have always existed to provide developers and end-users with ways to set a number of preferences for their Microsoft Dynamics GP application without the need of additional development or customizations. With the release of Microsoft Dynamics GP 2013 and the web client, the Dex.ini now plays a key role in enabling (or disabling) certain elements rooted in the system's architecture itself. Today, I will address 3 new Dex.ini keys that will assist every day system administrators, developers, and hosting partners in managing their Microsoft Dynamics GP 2013 environment.
Per-User Dex.ini
With the introduction of the web client in Microsoft Dynamics GP 2013, the development team needed to make a few changes to how the Dex.ini file is handled. The result is a launch Dex.ini file (or global Dex.ini) that contains the settings necessary to get the user connected to Microsoft Dynamics GP; and a user-specific Dex.ini file that contains the user settings used after a successful connection has been established. The settings in the user Dex.ini are persisted in the Microsoft Dynamics GP system database (SY01405 - syUserDexIniSettings) so the next time they log into the system, the user Dex.ini file can be created with “their” settings. This functionality also works well in a Remote Desktop Services (aka Terminal Server) configuration where multiple users are sharing a single GP client installation.
NOTE: Traditionally, the Dex.ini file would be copied to the user profile folder to have user-specific Dex.ini settings. With Microsoft Dynamics GP 2013, this is no longer necessary.
This functionality is enabled via a Dex.ini switch in the launch Dex.ini files. (i.e. The Dex.ini used to launch GP, by default the one in the installation directory’s Data folder.)
EnablePerUserIni=TRUE
The switch is set to TRUE by default when installing the Web Client Runtime components during the Microsoft Dynamics GP 2013 installation. It can be enabled in a Remote Desktop Services (RDS) environment by editing the launch Dex.ini file and setting the switch to TRUE,
From an Independent Software Vendor (ISV) perspective, if your Dexterity application uses the Dex.ini file, you will now have a new optional parameter to choose what file you want to access via the Defaults_Read() and Defaults_Write() functions. You can then read or define if whether a setting is a global (launch Dex.ini) or per-user setting. The default is per-user if not defined, with a fallback to read or write from/to the global Dex.ini.
NOTE: If you are a Visual Studio Tools developer, you can access the Default_Read() and Default_Write() functions through the DexDefaultsRead() and DexDefaultsWrite() helper functions provided, respectively. You can read more about the helper functions library here on MSDN.
Suppressing the Server Data Source Drop-Down
In addition to the above changes released with the RTM version of Microsoft Dynamics GP 2013, a couple of other Dex.ini changes were added in Microsoft Dynamics GP 2013 SP2 (12.00.1482) to better support shared environments - a shared environment being one in which a single instance of the Microsoft Dynamics GP client is being used by multiple users or one in which there are multiple tenants/customers sharing a server.
The first change was added primarily for service providers that have multiple customers sharing Windows servers. In this situation the server could have data sources for multiple customers and you won't want user's from customer A seeing the data sources for customer B. In this case you can add the following switch to the launch Dex.ini that will default the data source field to the value from the Dex.ini and disable it.
EnableServerDropDown=FALSE
Suppressing the Last User in the System
The second change was added for RDS environments where multiple users are sharing the same Microsoft Dynamics GP instance and you don't want the user name of the last user to successfully login to default into the field. In this case you can add the following switch to the launch dex.ini that will not default in the last user name.
DefaultLastUser=FALSE
If you are interested in reading more about Dex.ini settings, please visit MVP Leslie Vail's blog and read her article Dex.ini switches – my complete list!. Leslie has worked hard to build this list over the years.
Special thanks to Daryl Anderson, Sr. Program Manager in Microsoft in Fargo for providing the base content for this article. Daryl is heavily vested with web client deployments on Windows Azure and have written most of the materials and "how to" topics for deploying web client on the Azure platform.
Until next post!
MG.-
Mariano Gomez, MVP
Intelligent Partnerships, LLC
http://www.intelligentpartnerships.com/
Per-User Dex.ini
With the introduction of the web client in Microsoft Dynamics GP 2013, the development team needed to make a few changes to how the Dex.ini file is handled. The result is a launch Dex.ini file (or global Dex.ini) that contains the settings necessary to get the user connected to Microsoft Dynamics GP; and a user-specific Dex.ini file that contains the user settings used after a successful connection has been established. The settings in the user Dex.ini are persisted in the Microsoft Dynamics GP system database (SY01405 - syUserDexIniSettings) so the next time they log into the system, the user Dex.ini file can be created with “their” settings. This functionality also works well in a Remote Desktop Services (aka Terminal Server) configuration where multiple users are sharing a single GP client installation.
NOTE: Traditionally, the Dex.ini file would be copied to the user profile folder to have user-specific Dex.ini settings. With Microsoft Dynamics GP 2013, this is no longer necessary.
This functionality is enabled via a Dex.ini switch in the launch Dex.ini files. (i.e. The Dex.ini used to launch GP, by default the one in the installation directory’s Data folder.)
EnablePerUserIni=TRUE
The switch is set to TRUE by default when installing the Web Client Runtime components during the Microsoft Dynamics GP 2013 installation. It can be enabled in a Remote Desktop Services (RDS) environment by editing the launch Dex.ini file and setting the switch to TRUE,
From an Independent Software Vendor (ISV) perspective, if your Dexterity application uses the Dex.ini file, you will now have a new optional parameter to choose what file you want to access via the Defaults_Read() and Defaults_Write() functions. You can then read or define if whether a setting is a global (launch Dex.ini) or per-user setting. The default is per-user if not defined, with a fallback to read or write from/to the global Dex.ini.
NOTE: If you are a Visual Studio Tools developer, you can access the Default_Read() and Default_Write() functions through the DexDefaultsRead() and DexDefaultsWrite() helper functions provided, respectively. You can read more about the helper functions library here on MSDN.
Suppressing the Server Data Source Drop-Down
In addition to the above changes released with the RTM version of Microsoft Dynamics GP 2013, a couple of other Dex.ini changes were added in Microsoft Dynamics GP 2013 SP2 (12.00.1482) to better support shared environments - a shared environment being one in which a single instance of the Microsoft Dynamics GP client is being used by multiple users or one in which there are multiple tenants/customers sharing a server.
The first change was added primarily for service providers that have multiple customers sharing Windows servers. In this situation the server could have data sources for multiple customers and you won't want user's from customer A seeing the data sources for customer B. In this case you can add the following switch to the launch Dex.ini that will default the data source field to the value from the Dex.ini and disable it.
EnableServerDropDown=FALSE
Suppressing the Last User in the System
The second change was added for RDS environments where multiple users are sharing the same Microsoft Dynamics GP instance and you don't want the user name of the last user to successfully login to default into the field. In this case you can add the following switch to the launch dex.ini that will not default in the last user name.
DefaultLastUser=FALSE
If you are interested in reading more about Dex.ini settings, please visit MVP Leslie Vail's blog and read her article Dex.ini switches – my complete list!. Leslie has worked hard to build this list over the years.
Special thanks to Daryl Anderson, Sr. Program Manager in Microsoft in Fargo for providing the base content for this article. Daryl is heavily vested with web client deployments on Windows Azure and have written most of the materials and "how to" topics for deploying web client on the Azure platform.
Until next post!
MG.-
Mariano Gomez, MVP
Intelligent Partnerships, LLC
http://www.intelligentpartnerships.com/
Comments
Thanks, Mariano!
EmilyH
We have many customers that use a Terminal Services environment, with multiple report dictionaries used. Even with the new functionality, I still require an individual dex.ini for each user.
If we could store the Workstation2 setting in the table, then we could have one dex.ini file, and one dynamics.set file (using multiple location IDs). This would make upgrades a breeze.
Is there any way that we can get GP to read the Workstation2 setting from the table instead of the launch dex.ini? Short of modifying Dynamics code of course.
Thanks.