Resetting GP desktop position and size with the Support Debugging Tool
Just recently I worked on an issue being experienced by several Microsoft Dynamics GP users in a Citrix environment. The users would report that, when double-clicking on the Microsoft Dynamics GP application launch icon, the program would "automatically minimize".
In doing some digging, I remembered a few Dex.ini settings that control whether the Microsoft Dynamics GP desktop shows maximized upon start up and the position at which the desktop appears. So, I took my good ol' friend Notepad and edited the DEX.INI to find the following:
As you can imagine, this problem can be easily replicated if you have a dual monitor and move the GP desktop off to a second monitor or by reducing the desktop size and moving the window off screen.
The fix is also pretty simple indeed. Reset the WindowMax key value to TRUE and bring the WindowPosX and WindowPosY key values back to some manageable parameter values, for example 150 and 150. End of the problem, right? Not quite.
The client then requested to put the proper controls in place to prevent this from happening in the future. In some environments where I have been, system administrators have simply decided to make the Dex.ini file read only to avoid any changes being written to the file. However, as my good friend David Musgrave over at Developing for Dynamics GP explains in his article Why making the Dex.ini file read only is evil, this is not such a good idea as it can cause a number of headaches given the dependency Microsoft Dynamics GP has on the key file.
Of course, here's where the Support Debugging Tool comes into play.
The Support Debugging Tool's Dex.ini Configuration feature allows a system administrator to manage individual key file settings at his/her discretion, with the ability to persist the key values for all Microsoft Dynamics GP clients and their respective Dex.ini file. There are 4 deployment scenarios where this can be very useful:
1. In a Server and Workstation(s) scenario, where the server and workstations each will have a copy of the Microsoft Dynamics GP client - hence, each workstation will have its own Dex.ini file.
2. In a Terminal Server or Citrix environment with a single instance of the Microsoft Dynamics GP client - hence a single Dex.ini file.
3. In a Terminal Server or Citrix environment with a single instance of the Microsoft Dynamics GP client, but multiple Dex.ini files, each stored at the user profile level.
4. In a load-balanced Terminal Server or Citrix environment where Microsoft Dynamics GP runs on each server participating in the farm - hence, each server will have its own Dex.ini file.
However, and in all cases for Dex.ini Configuration to work effectively, the Support Debugging Tool's Debugger.xml settings file must be shared (in a central location on the network) and reachable by all Microsoft Dynamics GP clients, regardless of the deployment method. To share the Debugger.xml, you must change the path to the file under the Dex.ini Settings option of the Support Debugging Tool as shown below:
For more information on installing the Support Debugging Tool, see Installing the Support Debugging Tool for Microsoft Dynamics GP FAQ over at Developing for Dynamics GP.
You can then use the Dex.ini Configuration window to control the window size and position for all workstations as shown below:
One more thing to keep in mind, is to set the Path Default Setting as indicated above to make sure all workstations inherit the same values automatically.
That's it!
Now that you know how to avoid the headache, go an install the Support Debugging Tool and come to my MSDynamicsWorld Decisions Fall 2011 session on the subject.
Until next post!
MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
In doing some digging, I remembered a few Dex.ini settings that control whether the Microsoft Dynamics GP desktop shows maximized upon start up and the position at which the desktop appears. So, I took my good ol' friend Notepad and edited the DEX.INI to find the following:
[General] . . WindowMax=FALSE . WindowPosX=1605 WindowPosY=902 WindowWidth=1200 WindowHeight=625 |
| Sample DEX.INI entries |
As you can imagine, this problem can be easily replicated if you have a dual monitor and move the GP desktop off to a second monitor or by reducing the desktop size and moving the window off screen.
The fix is also pretty simple indeed. Reset the WindowMax key value to TRUE and bring the WindowPosX and WindowPosY key values back to some manageable parameter values, for example 150 and 150. End of the problem, right? Not quite.
The client then requested to put the proper controls in place to prevent this from happening in the future. In some environments where I have been, system administrators have simply decided to make the Dex.ini file read only to avoid any changes being written to the file. However, as my good friend David Musgrave over at Developing for Dynamics GP explains in his article Why making the Dex.ini file read only is evil, this is not such a good idea as it can cause a number of headaches given the dependency Microsoft Dynamics GP has on the key file.
Of course, here's where the Support Debugging Tool comes into play.
The Support Debugging Tool's Dex.ini Configuration feature allows a system administrator to manage individual key file settings at his/her discretion, with the ability to persist the key values for all Microsoft Dynamics GP clients and their respective Dex.ini file. There are 4 deployment scenarios where this can be very useful:
1. In a Server and Workstation(s) scenario, where the server and workstations each will have a copy of the Microsoft Dynamics GP client - hence, each workstation will have its own Dex.ini file.
2. In a Terminal Server or Citrix environment with a single instance of the Microsoft Dynamics GP client - hence a single Dex.ini file.
3. In a Terminal Server or Citrix environment with a single instance of the Microsoft Dynamics GP client, but multiple Dex.ini files, each stored at the user profile level.
4. In a load-balanced Terminal Server or Citrix environment where Microsoft Dynamics GP runs on each server participating in the farm - hence, each server will have its own Dex.ini file.
However, and in all cases for Dex.ini Configuration to work effectively, the Support Debugging Tool's Debugger.xml settings file must be shared (in a central location on the network) and reachable by all Microsoft Dynamics GP clients, regardless of the deployment method. To share the Debugger.xml, you must change the path to the file under the Dex.ini Settings option of the Support Debugging Tool as shown below:
 |
| Support Debugging Tool's Dex.ini Settings window |
For more information on installing the Support Debugging Tool, see Installing the Support Debugging Tool for Microsoft Dynamics GP FAQ over at Developing for Dynamics GP.
You can then use the Dex.ini Configuration window to control the window size and position for all workstations as shown below:
 |
| Support Debugging Tool's Dex.ini Configuration Window |
One more thing to keep in mind, is to set the Path Default Setting as indicated above to make sure all workstations inherit the same values automatically.
That's it!
Now that you know how to avoid the headache, go an install the Support Debugging Tool and come to my MSDynamicsWorld Decisions Fall 2011 session on the subject.
Until next post!
MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
Comments
I use Citrix too to share Dynamics GP client and we had the same issue in the past with Citrix PS 4.5. It was not such a deal as long as users had only one monitor with pretty much the same configuration... but we started to get problems when several users had configs with 2 or more screens and moved the GP client off the main display. Since GP saves the XY position coordinate when it closes the session, you're screwed up if the next user doesn't have a similar configuration... the client will just open in the 'off-screen' zone :-(... The fact that you try to set the XY coordinates through the SDT doesn't change anything, because the changes are only done after the GP client starts (and not prior to the launch and reading of DEX.ini), thus the user is stuck with a client that he/she cannot close...
I solved the problem by using a batch file to launch GP and assign each user a 'roaming' DEX.ini profile... so there is no mess anymore between the various screen configs :-).
I am sure there's more than one way to address this issue. I am just communicating what I did at a client and so far, this has worked. We did some testing moving screens off to a second monitor for various users and found that, as long as the Support Debugging Tool's settings file was centralized, we were always able to recover.
MG.-
Mariano Gomez, MVP
http://blogs.msdn.com/b/developingfordynamicsgp/archive/2011/08/05/using-the-support-debugging-tool-with-real-life-examples.aspx
David
http://blogs.msdn.com/DevelopingForDynamicsGP/
"4. In a load-balanced Terminal Server or Citrix environment where Microsoft Dynamics GP runs on each server participating in the farm - hence, each server will have its own Dex.ini file."
My only question is: since the Support Tools load upon launching GP with elevated permissions, and since it does not create or use SQL tables (instead relying on the Debugger.xml file stored in a sub directory off the GP parent) do the debugging tools and this solution need to be implemented on every Citrix server GP is installed on that is included in the load balancing. My assumption is yes. Just wondering if anyone's confirmed this before I pull the trigger?