I’m sure that this has happened to everyone, you follow the steps and you launch your web client web page. Then, after you log in you receive the dreaded error, “A problem occurred creating a session error.” Often the first response is to repair the web client and proceed to check the local certificate. This is followed by checking the services. And alas, nada. None of these processes fix the error.
The problem is not the web client install, but the added feature on the actual Microsoft Dynamics GP installation. One misconception about installing the web client is that multiple Runtime installs exist. You have the Web Client Runtime and the Web Services Runtime. The Web Client Runtime is often missed because it hides in the Microsoft Dynamics GP install.
1. Web Client Runtime: On the Web Client server go to Programs and Features, select Microsoft Dynamics GP 2015 (Desktop Client Install), click Add/Remove Features and check if Web Client Runtime is installed. If this runtime is not installed edit and then try logging into the Web Client.
2. Web Services Runtime: The second Runtime is located in the GP installation. When you open the installer you will see the Web Services Runtime.
I’m certain that this has taken place in many businesses. Someone logs in for the day and when they print a report or a check, they receive this error. Or they receive a new computer with a fresh copy of Microsoft Dynamics GP and when they try to print a report, the error stops them. This error is interesting because it can happen in different circumstances. It is one of three problems, a missing reports dictionary, a missing 3rd party, or a communication issue with the reports share. Every time I see this error I take specific troubleshooting steps.
1. If the install is a new install on the PC, I check the reports dictionary by going to Tools>> Customize >> Customization Maintenance. If there are no reports stored here, my next step would be to identify the storage location of the reports. On new installs, the reports need imported or pointed to the shared location. If they are on a share, I would point the GP installation to the share.
2. If there are reports visible and they will not print, I navigate to the shared reports folder while logged in as the user. This verifies that the user has access to the share. If you cannot navigate to the shared file location, it may not be a problem with Microsoft Dynamics GP. The permissions to the folder the reports dictionary writes to could have communication issues. Anytime there is a communication issue, I recommend having the server checked over by your IT department. If you are a technical consultant, I would recommend that you take a more in-depth look at why the communication issue appeared. In past situations, I identified communication issues because disks malfunctioned or the operating system corrupted. The result was the server being decommissioned and replaced. Another example, I discovered that they had Cryptolocker on the file share and the virus encrypted the dictionary within the shared folder.
3. Check the form to verify that the correct security is set by going to Tools >> Setup >> System >> Alternatives/Modified Forms and Reports. If you had a 3rd party and removed it, this could have no selection. In one example, I had no selections in this window. By selecting the default Microsoft Dynamics GP report in this window, the report could print again.
Microsoft Dynamics GP Deleting User Error “Deleting the login failed for an unknown reason. Contact your SQL Server administrator for assistance.”
￼Every time I have encountered this is when a user is set up to a specific company database. To resolve this follow these steps:
- Go to your SQL and verify that the user has a SQL login setup. If they do then follow
- Expand your company database
- Expand Security
- Expand Users
- Right-click on the user you are trying to delete and select Delete. This will remove the user’s SQL profile from the database and any schema’s that are causing the error.
- Repeat for all company databases
- Repeat in the Dynamics database
NOTE: DO NOT REMOVE THE OVERALL SQL LOGIN only under each specific database
Log back into Microsoft Dynamics GP and remove the user through the normal user setup. This will remove the user from Microsoft Dynamics GP and also SQL.
This error has been the most troublesome for me in the past. Typically of you try searching the error you will get pointed to KB article 943948. What I have found is that this is caused when you run an integration and Microsoft Dynamic GP seems to disappear and Integration Manager freezes or gets closed down integration. I have also seen this occur after an error and the user tries to re-run the integration.
What is occurring is that Integration manager and Microsoft Dynamic GP still has processes running in the background. If you go into task manager and look at the running processes you will see multiple for Microsoft Dynamics GP for the user trying to run Integration Manager. You have two solutions, either go into task manager to stop the processes and test again or have the user reboot.
Sometimes just stopping the services does not resolve the error and a reboot is still required. If a user is logged into a terminal server it is important to verify that they fully log off the server and simply does not disconnect.
In Microsoft Dynamic GP, there is a direct scanning button that is available. For the direct scan button to activate you must have a WIA driver installed. If it does not detect the driver it will appear grayed out (as the screenshot above shows).
I ran into an issue recently where I needed to have the users RDP into a terminal server and be able to utilize an activate scan button. Microsoft redirect did not work and I tested several third-party scanning redirect software programs, such as TSscan and scanredirect. Neither of these products worked to activate the scan button because they installed a TWAIN driver on the terminal server. I had tested about 6 scanning redirection options before I found one product that installed a TWAIN and WIA driver on the server side and pulled the scanner’s default scanning options into the server. This product is Scanner for Remote Desktop. Here is their guide to their product with instructions on how to install.
I was not paid to represent this product and earn no money placing this on my blog. I found that this product assisted in resolving a problem that took me over a month to find a solution. If you have another scanner redirection product that also installs a WIA driver on the server I would be more than happy to edit this post and add it.
With Microsoft Dynamics GP permissions come from two different types of accounts. There are local accounts and GP accounts. Local accounts are setup on a domain in Active Directory. GP accounts are setup within the GP programs.
The permissions for excel reports pulls from Active Directory and not Microsoft Dynamics GP. Specifically, it is an active directory account setup in SQL and set DYNGRP and rpt_power_user for it to access the account.
First login to SQL and expand security. Under the security right click on login and select ‘new login…’. After you select new login you will be able to see the option to search for a login. This search will allow you to search in Active Directory. After you add the new user under the general tab, then select the user mapping. Under the user mapping, select all the databases that the user should be able to run excel reports in and add the permissions DYNGRP and rpt_power_user. If you do not want to provide them the rpt_power_user role, then you would be able to select the rpt_%rolename% that best fits your company’s security policy. This can also be matched to their GP logins permissions.
For the error, “An error has occurred in the script on this page” URL: “https://online.dynamics.com/us/WebResource.axd?d=2eiL_4UDyPKUYbDwJbaFejBYJ44y52hSWZGz5-A7NDC2pVxbl2HB1Ni-” the solution is not within the GP software. The first time I came across this error and attempted to resolve it, I followed https://support.microsoft.com/en-us/kb/2702223. None of these solutions fixed the error. Steps I had taken was to proceed to clear the temp folder from the user directory and then verified the permissions for GP. Most directions that I find online refer to these steps.
In the end, the solution was within Internet Explorer. The error was typically occurring for our hosted Terminal Servers. This is because security is typically stronger on the server due to group policies and security. One of the resources I had referenced clearing cookies. This prompted me to look at compatibility settings and trusted sites.
In Internet Explorer, Go to Tools- Compatibility View Settings
In Internet Explorer, Go to Tools-Internet options
Select the security tab
Select Trusted Sites
Then select Sites
Uncheck “Require server verification (https:) for all sites in this zone
Restart Internet explorer