Five Troubleshooting Steps to Try Before Opening a Support Case
As a part of our Web Client blog series, I wanted to take the opportunity to share some of the most common issues and resolutions that we have seen in support cases. These steps will cover a range of issues, so if you’re experiencing any of the following, give these steps a try.
Users receive a “A problem occurred creating a session” error after entering their credentials.
Stuck on “Please wait while we get things ready” message.
Users receive an HTTP 503 error on the Web Client home page.
Receive a HRESULT: 0x80070425 error when restarting the App Pool
You receive a “CrossDomain” error after logging in, but before the GP login page.
You receive a “Server Not Found” error after logging in, but before the GP login page.
You are able to log in, but the session is stuck on the gray screen with a “Connected” status, but the login page doesn’t appear.
You are able to log in to Web Client, but you receive a “Privilege Error” once the application starts loading.
Services:
The best place to start with troubleshooting is by taking a look at the services. Web Client has two services installed. They are named: GP Session Central Service, and GP Session Services. These two services need to both be running for Web Client to work. If the Session Service is not started, users will receive the “Problem Occurred Creating a Session” error. If the Session Central Service is not started, users will hang on the “Please wait while we get things ready” screen.
The Application Pool in IIS isn’t necessarily a service, but you should make sure that the App Pool is running as well. If the App Pool isn’t running, users will get the HTTP 503 error upon hitting the Web Client site.
The last thing to look at is also not technically a service, but the actual Website in IIS can be stopped and started just like a service, so make sure the IIS site is also started. You will get a “The webpage cannot be found” error if the site isn’t started.
Service Accounts:
The next area to look into for troubleshooting is the service accounts themselves. If the password expires on a service account while the service is running, the service may stay running, but you won’t be able to restart it. The best way to test this is to just try to restart the service. If the credentials are invalid, you’ll receive an error stating that the “service started and then stopped”. Restarting the App Pool in IIS is another thing you should do to make sure that the credentials being used for the App Pool are still valid.
The service account that is being used to run the Session Central service needs to have Read access to the OU when the user logging in is, and Read access to the OU where the Web Client Users AD group is located. Upon logging in, the Session Central Service enumerates the Web Client Users group and checks if the logging in user is a member of that group. That AD call is made with the Session Central service account. If there are any invalid or orphaned users in the Web Client Users group, the enumeration will fail with a “ValidateCallerIsMemberOf()” method failure in Event Viewer.
TenantConfiguration.XML / Tenant Configuration Snapin:
If you’ve installed your environment with Tenant Services, and have multiple tenants configured, then the troubleshooting here will be done using the Tenant Configuration SnapIn in Web Management Console. If you’ve installed in Single-Tenant mode, then this troubleshooting will be done in the TenantConfiguration.XML file, which is located in the SessionCentral subfolder of the location that you installed the Web Components to.
The tenant configuration, both for multitenant and single tenant, contains several key pieces of information; the location of the Dynamics.exe, the Dynamics.SET, and the Dex.ini. In Tenant Manager and the TenantConfiguration.XML, the paths for the Dynamics.SET and the Dex.ini need to be explicitly defined, and the Dynamics.exe just needs to be pointed to the folder where the .exe is located.
C:\Program Files (x86)\Microsoft Dynamics\GP2015\
C:\Program Files (x86)\Microsoft Dynamics\GP2015\Dynamics.set
C:\Program Files (x86)\Microsoft Dynamics\GP2015\Data\Dex.ini
If these paths are wrong, unreachable, empty, or not explicitly defined as you see here, then the Silverlight XAP file will be loaded into the user’s browser, but the application won’t connect. You’ll freeze with a “Connected” message, or you’ll get an error regarding the launch file.
The desktop client installed on the Session Host Server:
Since the Web Client is simply an iteration of the desktop client that is installed on the Web Server, errors received in the Web Client can typically be reproduced in the desktop client as well. If a user reports an error message while using Web Client, or they experience some type of freezing or performance issue, have that user log into GP on the Session Host server and see if the issue occurs for them there. If they are a Web Client Only user, you can make a SQL login for them to test the issue in the desktop client.
If you receive dictionary errors, privilege errors, or other types of file errors in the Web Client, you should try launching the desktop client to resolve the issues there first, then they should be resolved in the Web Client as well. You can use the desktop client installed there to troubleshoot shared dictionary and custom report dictionaries as well.
Certificates:
The certificates that are bound to your services are the final piece to check on when troubleshooting Web Client issues. If you have bound a certificate to the Session Service and Session Central services, you need to make sure that the certificate that you’ve bound to the service is installed to the Trusted Root of the Local Machine store on the servers. You need to make sure that the Certificate that is bound to the Runtime Service is in the Trusted Root of the client machines. We have seen some issues with Certificates from Third Party Certificate Authorities throwing Cross Domain errors unless that certificate itself is explicitly in the Trusted Root. Usually, with 3rd Party Certs, they are trusted by default due to the Root CA Cert already being in the Trusted Root. However, if you’re still getting errors relating to HTTP security, then you should manually export the certificate, and install it into the Trusted Root of the Local Machine store on the computer it is being accessed from.
The quickest way to move certificates is to use the MMC tool. Add the Certificates snapin, and then select the Local Machine option after adding the snapin.
While this is not a fully comprehensive list of issues and troubleshooting steps, following this guide should get you through the majority of errors you may run into with Web Client.