Microsoft Dynamics GP Home Page scripting errors on Citrix XenApp

November 3, 2011

For the past 2 weeks I have been working on a fairly complex installation of Microsoft Dynamics GP for a hospitality staffing company whose hardware infrastructure is hosted by a very reputable provider. My client has made all their applications available to their end users via Citrix XenApp. Xenapp is Citrix Systems’ secure on-demand application delivery platform for the Citrix Presentation Server.

After completing the installation of Microsoft Dynamics GP on the Citrix Servers, the next step was exposing the application to XenApp. This by all accounts is a fairly straightforward process. I logged into XenApp, launch Microsoft Dynamics GP and everything was working fine: home page, reports, SSRS reports, Business Analyzer, Management Reporter, the whole 9 yards!

A couple days later, users began reporting home page script errors as the one shown below:

Typically, if you follow the prescribed KB article 918313 – Frequently asked questions about the home pages and area pages features in Microsoft Dynamics GP, specifically Q21 and Q31 you end up understanding the following:

1. There must be a UserData folder under the %Appdata%\Microsoft\Internet Explorer folder. Under normal circumstances, this folder will get created when the user profile is first initiated.

2. You cannot roam user profiles and in particular the user Temp folders as this causes issues with Microsoft Dynamics GP.

We went through both questions – well, we went through all the questions – and realized that the UserData folder was not created for the end-users. Remember, I was not getting this error under my domain account, but I attribute this to the fact that I was a domain admin. Effectively, we setup the UserData folders, but the problem persisted.

I then went to the Run… command utility with my Windows account and typed %Appdata% and quickly realized that Windows Explorer was taking me to \\\UserData$\Appdata\…, in effect confirming that roaming profiles was active for all users on the domain.

This seems to contradict the previous point #2 above. However, this is where all hell broke lose with the infrastructure vendor. It turns out that disabling roaming profiles on a Citrix farm may cause all kinds of unpredictable results for other applications such as Microsoft Outlook which tend to lose personalized settings when bouncing between servers in the farm – this is a load balanced environment with 4 servers.

In short, disabling roaming profiles was not an option!

However, in working with the point Citrix and Windows engineer at the infrastructure provider and running some ProcMon traces, we realized that each time the home page attempted to load a file, ProcMon would display errors stating that the file location could not be found (effectively what the error was displaying even after the UserData folder was created). Since the profiles were being roamed this was disconcerting.

Of course, the immediate thought was, “it must be a permissions issue!”. We then tested this theory by opening Windows Explorer and attempting to navigate to the Roaming Profile location with a standard user account. No luck!

The engineer quickly realized that the only way this could happen was via a Global Policy setting. In doing some more research, the likely candidate emerged: Remove Run Menu From Start Menu.

Clearly, from the policy description above, UNC paths are blocked and accessing local folders like \temp is a no, no (temp is roamed off to another server, remember?). Once we disabled the policy, Microsoft Dynamics GP started working like a charm and the errors were gone!

Now, you may say, “not sure we want to enable the Run commad for end-users”. In my client’s particular case, this made no difference because applications are being deployed via XenApp and not accessed from a desktop, so disabling the policy won’t have any effect. At the end of the day, we all went home happy, which begs the question…

Can the above KB article be revised?

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC


Printing to screen and PDF file causes default printer to change to Acrobat PDF Writer

October 17, 2011

A user recently reported a strange Microsoft Dynamics GP behavior when trying to print any report in to file in PDF format, while simultaneously sending the report to screen.

The PDF gets created and the report appears on the screen as it would be expected. However, when she attempts to print the report from the screen to printer, the only printer available is Adobe PDF Writer. While having the report on screen, the user checked the default printer, which remained unchanged, nonetheless the report on screen would only print to Adobe PDF Writer, bypassing the default printer.

I suspect what is happening in this case is, when the report is directed to screen and a PDF file simultaneously, the Runtime Engine changes the default printer to the Adobe PDF Writer (Adobe Distiller in some cases) printer in order to write the file in PDF format – after all, Microsoft Dynamics GP does not save files in native PDF format like say, Word or Excel. At the end of writing the file, but before outputing the report to screen, the default printer is not being re-established.

Given the number of printer related posts on the forums lately and the responses by Microsoft staff, it seems this has been identified (along with a few more issues) as part of a list of upcoming fixes – but just in case, I am writing about it today.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

Running Fixed Assets Depreciation causes Microsoft Dynamics GP to "hang"

September 19, 2011

I just completed a full upgrade of Microsoft Dynamics GP from version 9 to version 2010 R2 for a client and they were going through their first month-end closing in the upgraded system. 3 weeks ago, after the upgrade, they reported experiencing an issue running Fixed Assets depreciation from two laptop computers, where apparently, when running depreciation the system would hang. The only option to recover would be to terminate the Dynamics.exe process from Task Manager. Nonetheless, we did not pay much attention to this at the time since the process was completed successfully from another machine, just in time to close the month of August – more on this later.

The client called back on Thursday morning, letting me know they were ready to run Fixed Assets depreciation again, and this time I offered to be onsite to see the problem first hand. So effectively this past Friday morning I drove to their location and stood behind the Sr. Accountant to see the process in action and spot any possible issues while there. The accountant proceeded to log into the company database for which he would run the depreciation, entered his September cutoff date and clicked on the Depreciate button… as luck would have it with some support cases, nothing happened and the process completed successfully. Well, after some chuckles and the typical apologies from the client, I was back in my car on the way home.

Fixed Assets – Depreciation Process Information

Halfway through, I received an email saying that as soon as I left, they logged into another company and were able to reproduce the hung up issue.

Now, I began playing all the typical troubleshooting plots in my head… the problem happens only in one company, the problem can be reproduced by all users, the problem can be reproduced on all machines. Typically, when an issue is constrained to one company, it’s related to some problem with the data or the way that company is configured. Not a bad proposition since I was only dealing with some 300 assets… but I am in my car, remember? So I offered the client to look at the issue when I was back in front of my computer, since I had discarded a user or workstation being the culprits.

Back at home I VPN’d into their system, then RDP’d to the SQL Server. I had the Sr. Accountant log into GP and start the depreciation process again. In troubleshooting the issue, I could see that the depreciation process was being correctly added to the Process Monitor and that the process showed Active, but it did not seem to complete.

Process Monitor

I also ran a SQL Profiler and noticed that the same set of T-SQL instructions would appear to be processed over and over at the database level. This told me the depreciation process was in an endless loop of some kind and something was preventing it from finishing.

SQL Profiler Trace

I then offered to run the process from the server with the ‘sa’ user and noticed that the depreciation was stopping on a particular asset ID (by clicking on the Progress button). This was now promising, because I now had a piece of data to look at.

Fixed Assets Progress window

I queried the Asset Master table and noticed that this particular asset had an acquisition cost of zero. In looking at the Asset Book, I noticed that the Cost Basis was USD $.01 (1 penny). Not sure why this grabbed my attention, but I asked the Sr. Accountant why had they set this asset up this way and he replied that they did it only to record the asset and keep track of its location, but that it had been fully depreciated in the past.

Asset General Information
Asset Book

He also added that the process was working fine in GP 9.0

So I figured I would try something by changing the Depreciation Method to “No Depreciation”. After all, if the asset had an acquisition cost of zero and a Cost Basis of 1 penny, what was there to depreciate? I ran the following statement to change the Depreciation Method to “No Depreciation”:

-- Created by Mariano Gomez, MVP
-- This code is licensed under the Creative Commons
-- Attribution-NonCommercial-ShareAlike 2.5 Generic license.

-- Remove the lock for the book being depreciated

-- Change the depreciation method

I then asked the Sr. Accountant to re-run the process and this time it completed in less than 10 seconds and produced the reports he was expecting.

Since it was not enough to fix this issue, I went out to the Microsoft Dynamics GP Partner Online Technical forum and found a case where a partner reported having the same issue at her client’s site. It seems Microsoft has identified and logged this as a problem report, but no concrete fix date has been given for it. So for now, the above query should do.

Also, you could end up with a cost basis of 1 penny at the end of the useful life of an asset, which would throw the system into an endless loop if you attempt to depreciate such assets once more. If you feel this is your case, the above script should also correct the problem.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

Default Printer not ‘sticking’ when running Microsoft Dynamics GP in Terminal Services RemoteApp

August 17, 2011

A bit of theory…

RemoteApp programs are programs that are accessed remotely through Terminal Services and appear as if they are running on the end user’s local computer. Users can run RemoteApp programs side by side with their local programs. A user can minimize, maximize, and resize the program window, and can easily start multiple programs at the same time. If a user is running more than one RemoteApp program on the same terminal server, the RemoteApp programs will share the same Terminal Services session.

The following Microsoft TechNet article explains in more detail:

Terminal Services RemoteApp (TS RemoteApp)


Microsoft Dynamics GP (versions 10.0 and 2010), is currently supported in a Terminal Server RemoteApp environment, but a number of my clients and forum users have reported in numerous occasions that the Default Printer settings are not ‘sticking’ or simply saving when loging out of the application (which also closes the RemoteApp session) and returning to it.

Print Setup window

The Solution

Puzzled by this, I began doing some digging and found out that the default printer “problem” is actually not a problem, but rather the way RemoteApp decides how the session disconnection will occur. Playing along with the disconnection, there was a new Terminal Server group policy setting that was introduced to control time limits for disconnection and there lies the dirty little secret.

If you are experiencing the issue I described above, please take a look at the following article by the Remote Desktop Services (Terminal Services) Team Blog:

Terminal Services RemoteApp™ Session Termination Logic

The article unveils the steps required to change this behavior and make your Microsoft Dynamics GP printer ‘stick’.

Also, if you are using Named Printers with Microsoft Dynamics GP in a Terminal Services RemoteApp environment, take a look at the following articles over at Developing for Dynamics GP:

Using Named Printers with Terminal Server

Named Printers application default printer selections not “sticking”

Troubleshooting Named Printers Issues

Please let me know with your comments if any of the above recommendations by the Remote Desktop Services team worked for you.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

SQL: Assigning Microsoft Dynamics GP Users to SSRS Database Roles

August 8, 2011

As I begin to wrap up a Microsoft Dynamics GP 2010 R2 production upgrade from Microsoft Dynamics GP 9.0, I ran into a small issue at my client. After deploying the new SSRS reports, and as users were getting ready to try them out, we realized that some 15 logins needed to be assigned to a number of the 24 default database security roles created for the SSRS reports.

User Mappings (some information blurred to protect the client’s identity)
This would be a bit cumbersome giving the share number of clicks required to accomplish this feat. In addition, we had just setup Microsoft Dynamics GP security, and given that the SSRS database roles were similar to those in GP, something needed to be done to automate the assignment of these roles based on Microsoft Dynamics GP security roles.
As a result, I created the following script:
-- Created by Mariano Gomez, MVP

-- This code is licensed under the Creative Commons
-- Attribution-NonCommercial-ShareAlike 2.5 Generic license.

DECLARE @userid varchar(50), @companyid varchar(5), @securityroleid varchar(200), @ssrsRole varchar(200);
DECLARE @sqlStmt varchar(255);

DECLARE c_reportsecurity CURSOR FOR

OPEN c_reportsecurity;
FETCH NEXT FROM c_reportsecurity INTO @userid, @companyid, @securityroleid;

SELECT @ssrsrole =
WHEN @securityroleid = 'ACCOUNTING MANAGER* ' THEN 'rpt_accounting manager'
WHEN @securityroleid = 'AP CLERK* ' THEN 'rpt_accounts payable coordinator'
WHEN @securityroleid = 'AR CLERK* ' THEN 'rpt_accounts receivable coordinator'
WHEN @securityroleid = 'BOOKKEEPER* ' THEN 'rpt_bookkeeper'
WHEN @securityroleid = 'CA AGENT* ' THEN ''
WHEN @securityroleid = 'CA MANAGER* ' THEN ''
WHEN @securityroleid = 'CA STAKEHOLDER* ' THEN ''
WHEN @securityroleid = 'CERTIFIED ACCOUNTANT* ' THEN 'rpt_certified accountant'
WHEN @securityroleid = 'CL AGENT* ' THEN ''
WHEN @securityroleid = 'CL DISPATCHER* ' THEN 'rpt_dispatcher'
WHEN @securityroleid = 'CL MANAGER* ' THEN ''
WHEN @securityroleid = 'CL STAKEHOLDER* ' THEN ''
WHEN @securityroleid = 'CUSTOMER SERVICE REP* ' THEN 'rpt_customer service rep'
WHEN @securityroleid = 'DP MANAGER* ' THEN ''
WHEN @securityroleid = 'DP STAKEHOLDER* ' THEN ''
WHEN @securityroleid = 'DP TECHNICIAN* ' THEN ''
WHEN @securityroleid = 'FA MANAGER* ' THEN 'rpt_accounting manager'
WHEN @securityroleid = 'FA STAKEHOLDER* ' THEN 'rpt_certified accountant'
WHEN @securityroleid = 'IT OPERATIONS MANAGER* ' THEN ''
WHEN @securityroleid = 'MBS DEBUGGER ADMIN ' THEN ''
WHEN @securityroleid = 'MBS DEBUGGER USER ' THEN ''
WHEN @securityroleid = 'OPERATIONS MANAGER* ' THEN 'rpt_operations manager'
WHEN @securityroleid = 'ORDER PROCESSOR* ' THEN 'rpt_order processor'
WHEN @securityroleid = 'PAYROLL CLERK* ' THEN 'rpt_payroll'
WHEN @securityroleid = 'PM AGENT* ' THEN ''
WHEN @securityroleid = 'PM MANAGER* ' THEN ''
WHEN @securityroleid = 'PM STAKEHOLDER* ' THEN ''
WHEN @securityroleid = 'POWERUSER ' THEN 'rpt_power user'
WHEN @securityroleid = 'PURCHASING AGENT* ' THEN 'rpt_purchasing agent'
WHEN @securityroleid = 'PURCHASING MANAGER* ' THEN 'rpt_purchasing manager'
WHEN @securityroleid = 'RT AGENT* ' THEN ''
WHEN @securityroleid = 'RT MANAGER* ' THEN ''
WHEN @securityroleid = 'RT STAKEHOLDER* ' THEN ''
WHEN @securityroleid = 'SHIPPING AND RECEIVING* ' THEN 'rpt_shipping and receiving'
WHEN @securityroleid = 'WAREHOUSE MANAGER* ' THEN 'rpt_warehouse manager'
WHEN @securityroleid = 'WENNSOFT SMS CONTRACTS* ' THEN ''
WHEN @securityroleid = 'WENNSOFT SMS DISPATCHER* ' THEN ''
WHEN @securityroleid = 'WENNSOFT SMS POWER USER* ' THEN ''
WHEN @securityroleid = 'WENNSOFT SMS SETUP* ' THEN ''
WHEN @securityroleid = 'WSJC ACCOUNTANT* ' THEN ''
WHEN @securityroleid = 'WSJC ACCOUNTING MANAGER* ' THEN ''
WHEN @securityroleid = 'WSJC ADMIN* ' THEN ''
WHEN @securityroleid = 'WSJC BILLING CLERK* ' THEN ''
WHEN @securityroleid = 'WSJC POWERUSER* ' THEN ''
WHEN @securityroleid = 'WSJC PROJECT MANAGER* ' THEN ''
WHEN @securityroleid = 'WSTT PAYROLL CLERK* ' THEN ''
WHEN @securityroleid = 'WSTT POWERUSER* ' THEN ''

IF (@ssrsRole <> '')
SET @sqlStmt = 'USE ' + rtrim(@companyid) + '; EXEC sp_addrolemember ' + QUOTENAME(@ssrsRole, '''') + ',' + QUOTENAME(rtrim(@userid), '''');
FETCH NEXT FROM c_reportsecurity INTO @userid, @companyid, @securityroleid;

CLOSE c_reportsecurity;
DEALLOCATE c_reportsecurity;
The script looks at the Security Assignment User Role table (SY10500) and retrieves the physical company database from the Company Master table (SY01500), then assign an SSRS database security role to each of the Microsoft Dynamics GP default roles. If a role does not exist, you can choose to leave the assignment blank.

The script then proceeds to evaluate the database security role obtained, then creates a SQL string that can be executed. The SQL string uses the sp_addrolemember system stored procedure to add the corresponding SQL login to the role. A cursor is used to loop through each user, company, and security role combination to obtain and assign the proper SSRS database role.

You can choose to add custom security roles or roles for third party applications that deploy their own SSRS reports to the above script.

This definitely helped saving some time… phew!

Until next post!


Mariano Gomez, MVP
IntellPartners, LLC

Support Debugging Tool Build 15 now released

June 30, 2011

These are exciting times… the Support Debugging Tool Build 15 has been released! If you attended our session, CSGP014-R2 Administering Microsoft Dynamics GP Like a Pro with the Support Debugging Tool during Convergence Atlanta 2011, you may recall that the features David Musgrave (author of the Support Debugging Tool) and I presented were all part of the Build 15 beta release at the time. Since then, the Support Debugging Tool has been propped up with a number of enhancements and bug fixes that make the wait while worth.

Support Debugging Tool Build 15 – UI Facelift

Take a look at David Musgrave’s release article, Support Debugging Tool Build 15 released, for a complete list of fixes, enhancements, performance improvements, usability and  features included in the new build.

Build 15 is only available for Microsoft Dynamics GP 10.0, Microsoft Dynamics GP 2010, and Microsoft Dynamics GP 2010 R2. You can download Build 15 at:

Support Debugging Tool for Microsoft Dynamics GP 10.0 Secure Link
Support Debugging Tool for Microsoft Dynamics GP 2010 (v11.0) Secure Link

Also, I will be writing in the coming days on some of the features I personally suggested and that are now a part of the Support Debugging Tool.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

SmartList Builder "Display as a negative value based on field" option not working as expected

December 14, 2010

Just recently on a newsgroup forum, a partner brought up an issue affecting SmartList Builder. The partner had just recently upgraded the client from version 9 and was testing the Smartlists the customer had built prior to the upgrade to ensure they were still working as expected. In the partner’s own words:

“It was working when we were on GP9, but now we’re on GP2010 SP1 none of my fields set up with Negative Values are showing up with Negative Values. When I run the smartlist from the old GP9 server, amounts are showing negative amounts for Return documents. But when we run the smartlist on GP2010, the amounts are now positive amounts, and when I check the Set Field Options window, they are still set up to “Display as negative based on field” when SOP Type = Return.”

In order to verify this I launched GP 2010 and recreated the SmartList mentioned above by the partner, setting the field option for the Document Amount to display a negative value based on a SOP Type of Return:

Set Field Options window

After saving the SmartList Builder option, I launched SmartList and had it build the newly created option. Once I checked the entry I had just created, effectively Returns were no displaying as negative.

BUG: Returns document amounts not displayed as negative

This bug seems to be confined to Microsoft Dynamics GP 2010 RTM (Build 11.00.1247) and Microsoft Dynamics GP 2010 SP1 (Build 11.00.1524). I could not replicate this issue for version 10.0 SP5 (10.00.1579) or earlier.

As a workaround, you can create a SmartList Builder calculated field to change the sign of the amount being displayed based on the SOP Type, as follows:

Add Calculated Field

NOTE: You can perform a similar CASE statement for any other SmartList you have created based on the field(s) criteria you are using to render the value a negative value.

This problem has been reported to Microsoft and a bug report is being written up to address the issue as of the publishing date of this article. For more information, contact Microsoft Dynamics GP Support.

Until next post!

Mariano Gomez, MVP
Maximum Global Business, LLC