Citrix – TS

GP Power Tools build 22 hotfix available for download (May 02, 2017)

Good day GPUGgers !

As many of you may know (or not), I’m an avid user of GP Power Tools (former Support Debugging Tool, aka SDT) since the tools was launched in 2006, and recently worked very closely with David to bring fixes & enhancements to the product, as I’ve been running Windows 10 since a few months in production on my laptop, where I’ve GP 2013 R2 & GP 2016 R2 (in Test) clients installed.

Windows 10 having changed quite a few things in regards of screen management and multi-monitor setup, plus a few other small hindrance (like the invisible window frames), it has been quite an interesting journey in the past months.

Here are the changes that were brought into this update for the build 22:

Version 16.00 build 22 (Released 02-May-2017) Installer: 16.00.0022.4

  •          Updated Trigger Setup window to stop asking to reset script when changing Menu Trigger text.
  •          Updated Company Color Themes to use User Display Preference settings for Link Fields and Required Fields.
  •          Updated Company Color Themes to override User Display Preference color settings when needed for inverted themes.
  •          Added fix for Dynamics GP Bug where Apply button on User Display Preferences only works one time.
  •          Added additional checks to ensure correct window handle is used when repositioning and retitling windows.
  •          Update default values for Email, Logging and Administrator settings to enable recommended features for new installs.
  •          Adjusted window repositioning code when capturing window handle for 3rd party products to use foreground window method.

One of the important updates for me is about the handling of the windows, as I’m running a setup with 3 displays (Laptop LCD + 2 external 22″ monitors), and I think that nowadays this is a pretty common setup. Since the Windows position memory feature was introduced in build 22 by David, I had a few issues where my other application windows (Outlook, Office, Explorer) would randomly be snapped to the the lower right or left corner of the display it was showing, even it was not related to GP, and this specially annoying when you had a larger posting batch going on your GP client, as you couldn’t work with other windows without having them snapping away under your mouse :-).

Based on the feedback I provided to David, he was able to correct his code and now checks for the proper identification of the window’s title, and if that title does not match the expected value, the code will stop the Automatic Window Position check (this can also happen with 3rd-party ISV products, though part of GP, they are not recognized as such).

Thanks to a feature added a while ago, but not fully used yet,  it provides  an additional DEX.ini settings that allows you to trace in detail what’s going on with your GP forms while your client is active. That helped us to identify the issue caused by non-GP windows.

MBS_Debug_LogWinData=TRUE

Be careful to not leave that option on longer than it would be necessary for you to debug a problem with some forms in GP, because it will fill up the GPPT log quite quickly.

Each GP form/window entry would look something like this (extract from the GPPT log):

2017-05-05 09:44:07 : ** Start of Log **
2017-05-05 09:44:07 : Version: 12.00.0022, Last Modified: 02-May-2017.
2017-05-05 09:44:07 : Automatic Trigger Mode Trigger CPY_DIR_DEPOSIT Unregistered
2017-05-05 09:44:07 : Automatic Trigger Mode Trigger VENDOR_EFT Unregistered
2017-05-05 09:44:07 : ** End of Log  **

2017-05-11 08:02:24 : Automatic Window Position    : window UPR_Employee_MNT of form UPR_Employee_MNT.
2017-05-11 08:02:24 : Dynamics GP Application Pos  : (114,57), Content Offset: (202,167).
2017-05-11 08:02:24 : Dynamics GP Zero Position    : (316,224).
2017-05-11 08:02:24 : Primary Desktop Actual Size  : (1680,1050), not used if per monitor setting available.
2017-05-11 08:02:24 : Primary Desktop Work   Size  : (1680,1010), not used if per monitor setting available.
2017-05-11 08:02:24 : Monitor Desktop Actual Pos   : (0,0) - (1680,1050), Size: (1680,1050), Device: \\.\DISPLAY1.
2017-05-11 08:02:24 : Monitor Desktop Work   Pos   : (0,0) - (1680,1010), Size: (1680,1010).
2017-05-11 08:02:25 : Monitor Desktop Physical Size: (1680,1050), DPI Scaling: 100%.
2017-05-11 08:02:25 : Dexterity reports Window Pos : (9,33) - (656,489), Size: (647,456).
2017-05-11 08:02:25 : Windows reports Window Pos   : (332,257) - (981,771), Size: (649,514).
2017-05-11 08:02:25 : Windows Window Scaled Pos    : (332,257) - (981,771), Size: (649,514), use instead of Dexterity settings.
2017-05-11 08:02:25 : Windows Window Border Offset : (7,3).
2017-05-11 08:02:25 : Adjusted Dynamics GP Zero Pos: (323,224), adjusted horizontal position for border offset.
2017-05-11 08:02:25 : Updated Dexterity window Pos : (9,33) - (658,547), Size: (649,514).
2017-05-11 08:02:25 : Dexterity Window + Offset Pos: (332,257) - (981,771), Size: (649,514).

Quite interesting and helpful when you’re an administrator and trying to figure out what’s going on with your GP client, especially if you run that on a shared environment like Citrix or Terminal Server.

If you’re already a GPPT subscriber, go and download the latest build 22 from the Mekorma site and install it. If you’re not a GPPT user yet, I encourage you strongly to grab a copy and ask for the free 30 Days trial key. You’re going to love it.

Until next time, have a great Day!

@GP_Beat

Categories: Citrix - TS, Dynamics GP, GPPT - GP Power Tools, System Administration | Tags: , , | Leave a comment

A remove range operation on table ‘SY_Current_Activity’ failed accessing SQL data

error1

You’ve probably encounter this error message on rare occasions in Dynamics GP, but be prepared for seing an increase with GP 2015 & up.

Recently I was working on a case with a customer that upgraded last fall (2016) from GP 2010 to GP 2015, and ever since the upgrade, the users who access GP over Citrix exclusively (no local GP clients) had randomly issues with pop-ups denying them access to some of the 50 GP companies.. The corporation has office mainly on the east-coast and also over in Asia, thus making the maintenance more difficult with the 13-hours timeshift, as the system is busy most of the 24h in a day.

error2

However, as they also use tons of 3rd-party ISV products and some customization, it was hard to pinpoint the culprit / faulty module. At some point we thought that it was the “inactivity” timer of the Rockton Toolbox that was causing this, but it made no sense to me, especially as the companies were not in the user’s access list.. Disabling the feature in RSTB was only a temporary solution, as you can guess that with so many companies, comes also a lot of users and more than often they don’t exit GP properly, leaving their session run on the Citrix server.. doubled down with the fact that there was no timeout set for inactive sessions, it wasn’t helping either. On top of that, the company is using FastPath for SSO and as I discovered later, FP does also have a feature for ‘inactivity’ timeoout.. As both were enabled (FP & RSTB), it becomes really though to diagnose the source of the problem.
We tried to enable the DexSQL tracing with the help of GP Power Tools, but as it occured only randomly, it was not a solution, since all users accessed GP thru 2 Citrix servers, the logs were growing fast (because enabled to all users) and it was slowing down the system.

By early 2017, we had a confirmation from Rockton that it might have been a bug related to the Toolbox ‘inactivity’ timeout feature, and thus applied the latest build with big hopes. Alas, only a few days later, the problem was back again with some users out of Asia reporting the pop-ups.. Strangely it occured mostly at Asia’s business hours (during night on east-coast) or very early in the morning on Eastern Time. My suspiscion started towards some maintenance job that would kill user sessions without further validation, but couldn’t find any tangible hints. I tried also by all kinds of back-end manipulation of the ACTIVITY table to reproduce the behavior and get the error message, as I suspeced the shared DEX.ini  to be causing this (DEX.ini stores the last company ID when a user exits GP).

At the end, as I had a conversion with my good friend & fellow MVP David Musgrave on how I could potentially enable single user tracing, without implementing indivual user DEX.ini config files, he suggested to have a look at the ACTIVITY table from the DYNAMICS DB, and check for potential triggers that could fire up at a bad time. Low & behold, it turned out that starting with GP 2015, Microsoft implemented new feature in GP that required a trigger on the ACTIVITY table to proceed with some clean-up work on company DB tables, which whne happening under a context when users were logged into another company at the same time to which they didn’t had access, would cause the infamous pop-up to show on screen.. confusing the users about the company they didn’t access to.

Read the details in David’s blog post about the underlying details and a (temporary) resolution. For now, the trigger was simply disabled on the ACTIVITY table, to confirm the source of the problem. Further action is required to resolve the issue on a long term basis with Microsoft and/or 3rd-party providers.

https://winthropdc.wordpress.com/2017/03/08/delete-or-remove-range-errors-on-sy_current_activity-table-after-gp-2015-r2/

 

Categories: Citrix - TS, Dynamics GP, GPPT - GP Power Tools | Leave a comment

Using Dynamics GP in a Citrix / TS environment

I often come across discussions in forums and community posts about the problems related to the end-user parameters stored in the DEX.ini file from GP.

Now the problem with shared environments is the reality that all the users are using the program folder to launch the application, thus also the same same settings from the DYNAMICS.SET and the DEX.ini to save the parameters. This can lead to some very confusion situations…. I had users calling in and saying they started a new GP session but only get the icon in the task bar, but actually never get to the login screen.

It took me some investigation back in 2010 or 2011 when this happened the first time, and it was coincidentally at the time when some users started to request a second monitor to increase their productivity :-)…

As it turned out at that time, Dynamics GP was used on the Citrix XenApp server by the vast majority of our users (around 120) and there was a single DEX.ini file for all the users, which means that every time a user launched the application remotely, it was showing the last user ID that logged in previously and also put the main GP windows at the screen coordinates where it was closed the last time. This was not too bad as long as everyone had pretty much the same configuration for the hardware (screen and printer), but soon as people started using 2 or more monitors, and moved the main GP window off the monitor #1, then the next user would run into troubles if he/she didn’t had the same setup.

That’s when I came across a blog post from my good friend David Musgrave  (at that time) from Microsoft Australia, who wrote something about the side-effects of shared DEX.ini files and how to avoid collisions in shared environments.

His article inspired me to find a smart way to make sure when a user would start GP the first time from the Citrix server that he would get a clean pristine DEX.ini file that become he/her own and contains only the settings from their sessions. No more hidden windows and lengthy DEX.ini files that would grow out by endless printer queue entries.

So I created a small batch file that would check the presence of an existing DEX.ini file in the owner’s home profile under the system hidden AppData folder. The content of the batch file looks like this :

 @echo off
rem This file is used to launch Dynamics GP
rem from within CITRIX MF without parameters
rem echo Press any key to start the GP apps
rem pause
rem Modified version to TEST SP3 1:07 PM 7/13/2012
c:
cd “C:\Program Files (x86)\Microsoft Dynamics\GP11SP3”
if exist %HOMEDRIVE%%HOMEPATH%\AppData\Local\Dex.ini Goto StartGP
copy C:\Users\Default\AppData\Local\Dex.ini %HOMEDRIVE%%HOMEPATH%\AppData\Local\Dex.ini
:StartGP
start Dynamics.exe Dynamics.set %HOMEDRIVE%%HOMEPATH%\AppData\Local\Dex.ini
cd \

Save the file as a .cmd in the Program Folder location of your GP application on the Citrix server. Make sure you have fresh and pristing DEX.ini file copy in the Default user home path (see location above).  You can take the current DEX.ini file from your GP Data folder and remove any references to the ‘remembered’ printers and clear out the last user in the file :

SQLLastUser=
RememberUser=FALSE

It’s important to set the 2nd value to FALSE, otherwise GP will try to auto-login the user and this would fail since there is no user-id.

Lets assume you named your file GP_Roaming.cmd, then your new launch file command line would look like this :

“C:\Program Files (x86)\Microsoft Dynamics\GP\GP_roaming.cmd”

There is no need anymore for a parameter provided in the published application for Citrix, since everything is already passed in the .cmd file itself.

One last tip when you apply a new service pack or a year-end update to your GP. When updating your client on the Citrix or TS server, only the DEX.ini that’s sitting in the GP Data folder gets updated… none of the distributed config files from the users home profile…Remember to delete them all before given the updated GP apps free again for the users (the nice thing with published apps is that you can quickly enable/disable them).

If you don’t want to delete the files, use a VBS script or Powershell to loop through all the DEX.ini’s and make the changes.. I wouldn’t necessarily recommend this way of doing it, since during a service pack upgrade, there are quite a few changes applied to the file.

Test the new launch file with a few users and do adjustments if required. This procedure has worked pretty well for our company since about 3-4 years now and has successfully been ported to a newly built Windows 2012 Remote Desktop Application Server.

Until next post…
@GP_Beat

Update on 2015-08-21:

There is relief to all the users that have setup GP in a Citrix or TS environment. Since GP2013 was released, you don’t need anymore to have a separate DEX.ini for each user. Read on the Blog post from my friend Mariano Gomez, Dynamics GP MVP : http://dynamicsgpblogster.blogspot.ca/2014/05/working-with-dexini-settings-in.html

To me when upgrading to GP 2015 it was a real relief to not have to deal anymore with outdated DEX.ini settings every time you do apply an upgrade / service pack to your share GP client (as only the main DEX.ini got updated by the GP Utilities process). Running the GP client with wrong release information from the DEX.ini file can be very stressful as you get all kinds of strange messages and don’t necessarily think of the user’s DEX.ini (though I haven’t tested yet the user’s DEX.ini scenario after an update).

Until next post…
@GP_Beat

Update on 2016-01-25:

After we upgraded last year the GP2010R2 to GP2013R2 (not going to 2015 was a decision based on the fact that some important features from BP were missing on the Web Client PTE), I realized that the user shared DEX.ini feature was finally not so good and in some cases not useful at all. For that reason I went back to the individual DEX.ini file for each users on the TS. This way I have a much better control over the settings. I’ll post in a future blog entry, some tips on how to quickly get rid of all the DEX.ini files after an upgrade, rather then having to painfully delete them one-by-one.
Until next post…
@GP_Beat

Categories: Citrix - TS, Dynamics GP, SDT - Support Debugging Tool, System Administration | Tags: , , | 4 Comments

Blog at WordPress.com.