Tuesday, July 30, 2013

Troubleshooting the Microsoft Dynamics GP 2013 Web Client - Wrap Up

Series Wrap Up

It's been a couple of exciting weeks reviewing the position, procedures, and tools available for troubleshooting the Microsoft Dynamics GP 2013 Web Client and I hope that you walked away with an idea of where to turn and what it takes to resolve your issues.

Troubleshooting may not be glamorous or exciting and frankly a lot of folks down right don't like it, but I personally find it to be a challenge. I like when stuff breaks - figuratively speaking - knowing that you (and a handful of others) are the only one capable of fixing it. Also, it is awesome when you can showcase your Angus MacGyver (yes, his first name was Angus!) ingenuity by using resources and tools that have been in the public domain for a while, "common knowledge" if you will, and can now be applied in the context of GP.

I want to synthetize the series by providing a link to all the articles covered, below:

Part 1: Microsoft Dynamics GP Support Team's Posture
Part 2: Resolving Microsoft Dynamics GP 2013 Web Client Implementation Issues
Part 3: Resolving Microsoft Dynamics GP 2013 Web Client Functional Issues
Part 4: Tools for Troubleshooting Web Client issues: the Web Client Diagnostic tool
Part 5: Tools for Troubleshooting Web Client issues: Fiddler
Part 6: Tools for Troubleshooting Web Client issues: Other Tools
Part 7: Tools for Troubleshooting Web Client issues: Command Line Tools

Well, I am preparing for a new series of articles, but in the mean time stay tuned.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

Monday, July 29, 2013

Troubleshooting the Microsoft Dynamics GP 2013 Web Client - Part 7

Part 7 - Tools for Troubleshooting Web Client issues: Command Line Tools

Parts 5 and Part 6 of this series, both look at some nice GUI-based tools to analyze web and network traffic. The good thing about these tools is that they allow you to analyze things from the comfort of an application window.

However, one needs not to discard some powerful command line base tools that have been around since the early days of DOS - and that's Disk Operating System, not DOS as in Dos Equis (XX). Today, I will talk about NETSH and NET


Netsh (Network Shell) is a command-line scripting utility that allows you to, either locally or remotely, display or modify the network configuration of a computer that is currently running. Netsh also provides a scripting feature that allows you to run a group of commands in batch mode against a specified computer. Netsh can also save a configuration script in a text file for archival purposes or to help you configure other servers.

With the Netsh.exe tool, you can direct the context commands you enter to the appropriate helper, and the helper then carries out the command. A helper is a Dynamic Link Library (.dll) file that extends the functionality of the Netsh.exe tool by providing configuration, monitoring, and support for one or more services, utilities, or protocols. The helper may also be used to extend other helpers.

You can use the Netsh.exe tool to perform the following tasks:

•  Configure interfaces.
•  Configure routing protocols.
•  Configure filters.
•  Configure routes.
•  Configure remote access behavior for Windows-based remote access routers that are running the Routing and Remote Access Server (RRAS) Service.
•  Display the configuration of a currently running router on any computer.
•  Use the scripting feature to run a collection of commands in batch mode against a specified router.

So, how does this all apply to the Web Client?

WCF services and clients can communicate over HTTP and HTTPS. The HTTP/HTTPS settings are configured by using Internet Information Services (IIS) or through the use of a command-line tool. When a WCF service is hosted under IIS, HTTP or HTTPS settings can be configured within IIS (using the inetmgr.exe tool). If a WCF service is self-hosted - like Session Service, for example - HTTP or HTTPS settings are configured by command-line entries.

At the minimum you will want to configure a URL registration, and add a Firewall exception for the URL your service will be using. Fortunately, this configuration is done for us by the InstallShield application when running the installation of the Web Client runtime services components.

In the Web Client world, we use NETSH to check for namespace reservations and look at how ports are configured in relation to SSL certificates issued.

To display discretionary access control lists (DACLs) for the specified reserved URL or all reserved URLs, proceed to type from the command-line:


To determine how ports are configured, type the following from the command-line:


If the Web Client installation process went well, the Certificate Hash assigned to each port used by Session Service (port 48650), Session Central Service (port 48651), and Runtime Service (port 48652) should match the thumbprint value of the certificate in IIS, as displayed by the show sslcert option.

Certificate hash on each listening port must match that of the certificate in IIS
Much more details can be found in my Windows 8 and Web Client installation series article, Windows 8 and the Microsoft Dynamics GP Web Client Series - Part 4.

For more information on configuring HTTP and HTTPS transports for WCF, take a look at the following MSDN library article:


For more information on how to configure a port with an SSL certificate, take a look at the following MSDN library article:



Netstat (network statistics) is a command-line tool that displays network connections (both incoming and outgoing), routing tables, and a number of network interface (network interface controller or software-defined network interface) and network protocol statistics. It is used for finding problems in the network and to determine the amount of traffic on the network as a performance measurement.

The specific entry we want to run from the command-line in a Web Client environment is as follows:


This will return a list of ports that are in use and the process and application using them. If you want to select a port of your own choosing when installing Web Client, you will want to verify that the post is available and it is allowed through the firewall as necessary.


For more information on netstat, take a look at the following TechNet article:


The Web Client Diagnostic tool, which I talked about in Part 4 of this series collects these two pieces of information (among other command-line tools ran) as part of the data collection procedures performed when opening a Web Client support case.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

Friday, July 26, 2013

Troubleshooting the Microsoft Dynamics GP 2013 Web Client - Part 6

Part 6 - Tools for Troubleshooting Web Client issues: Other Tools

In Part 5 we looked at Fiddler, a proxy web debugger application and how it is able to break down HTTP and HTTPS traffic between a client app and a Web Server. Today, I will look at 2 tools that go down right to the wire - literally!


Wireshark is a free and open-source packet analyzer. It is used for network troubleshooting, analysis, software and communications protocol development, and education. Originally named Ethereal, in May 2006 the project was renamed Wireshark due to trademark issues.

Wireshark is cross-platform, using the GTK+ widget toolkit to implement its user interface, and using pcap to capture packets; it runs on various Unix-like operating systems including Linux, OS X, BSD, and Solaris, and on Microsoft Windows. There is also a terminal-based (non-GUI) version called TShark. Wireshark, and the other programs distributed with it such as TShark, are free software, released under the terms of the GNU General Public License.

Wireshark Network Analyzer

Wireshark is very similar to tcpdump, but has a graphical front-end, plus some integrated sorting and filtering options. Wireshark allows the user to put network interface controllers that support promiscuous mode into that mode, in order to see all traffic visible on that interface, not just traffic addressed to one of the interface's configured addresses and broadcast/multicast traffic. However, when capturing with a packet analyzer in promiscuous mode on a port on a network switch, not all of the traffic travelling through the switch will necessarily be sent to the port on which the capture is being done, so capturing in promiscuous mode will not necessarily be sufficient to see all traffic on the network. Port mirroring or various network taps extend capture to any point on the network.

So why is Wireshark used with the Web Client? Since it analyzes TCP/IP traffic, you could potentially use it to understand if the proper ports are being used by the application when communicating with the Web Server(s) or the Session Host(s), especially when traffic has to traverse intranet, DMZs, and extranet zones on your network. You could potentially determine if there are any translation issues between external DNS addresses and internal network addresses.

ClearSight Analyzer from Fluke Networks

This product is advertised as Wireshark on steroids as it supports the Wireshark decode engine. In addition, it's able to make sense of all TCP/IP traffic by implementing some powerful graphics showing how machines and devices interact with each other.

Network diagram
Conversation Chart

ClearSight also implements a powerful bounce chart for traffic on single or multi-segment networks. Now here's the bummer: it's not free! However, for a small fee you are able to obtain a fully featured product.

If you are more like me - a visual person - then ClearSight is certainly worth the price. If you are comfortable in your own skin looking at TCP/IP raw traffic, then Wireshark is the way to go. In any event, you have two powerful tools that can really breakdown your network traffic with ease, for you to analyze where things may be breaking down, preventing Web Client from functioning.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

Thursday, July 25, 2013

Troubleshooting the Microsoft Dynamics GP 2013 Web Client - Part 5

Part 5 - Tools for Troubleshooting Web Client issues: Fiddler

In Part 4 of the series, we visited the Microsoft Fix It! solution which allows you to collect myriad of information about your Web Client environment configuration during a support case. Continuing with the series, I will look into Fiddler, which I briefly referenced in my article "Unable to access SnapIn config data Store" accessing Web Management Console when I was having problems with the Web Management Console application.

Fiddler is a free HTTP debugging proxy server application written by Eric Lawrence, formerly a Program Manager on the Internet Explorer team at Microsoft. Fiddler captures HTTP(S) traffic and creates trace files that can be used to analyze web traffic. It can also be used to "fiddle" with HTTP traffic as it is being sent. By default, HTTP(S) traffic, captured via the Microsoft's Windows Internet (WinINet) API,  is automatically directed to the proxy at runtime, but any browser or application (and most mobile devices) can be configured to route its traffic through Fiddler.

Unlike the original version, Fiddler 2 offers support for interception and tampering with HTTPS traffic.

Now the basics...

Once you have downloaded and installed Fiddler, you are pretty much ready to go. By simply opening the application, you can begin to capture any HTTP(S) traffic running on your machine and a server you are trying to reach.

Fiddler Web Debugger
With the Web Client in particular, you will open your browser, enter the Web Client URL, typically https://someservername/GP. You can then switch over to Fiddler to see the trace being captured.

Web Session

Each entry in the list is known as a web session. Each session captures information such the Fiddler assigned number of that session, the result, the protocol used to access the content, the host (including port numbers accessed), the URL of the session, body, caching (if required), content type, and the process. You can also add a number of columns to the list. Each Fiddler number is shown with visual cues to facilitate information reading.

Fiddler can show statistical information specific to each session, by simply highlighting the session in the list and clicking on the Statistics tab on the right pane. You can get an idea of the Web Client's overall performance metrics. You can select all sessions to see the total number of requests and bytes sent and received, broken down by content type or in a pie chart. By exposing all HTTP(s) traffic, Fiddler easily shows which files are used to generate a given page: users can multi-select the number of requests and bytes transferred to get a "total page weight".

Statistics tab
There are obviously, countless other measurements taken by Fiddler, including the powerful Timeline feature. The Transfer Timeline allows you to visualize the HTTP(S) traffic on a "waterfall" diagram. This feature has two modes of recording information: buffering mode and streaming mode.

Fiddler Transfer Timeline
Streaming mode ensures that HTTP responses are not buffered by Fiddler. Buffering alters the waterfall diagram, where none of the images begin to download until their containing page completes.

Since the purpose of this article is to expose you to Fiddler, I can only say go ahead and download the tool and begin to familiarize yourself with the features. Fiddler traffic is routinely collected by Microsoft Dynamics GP Support to determine whether there are issues between your browser and the Web Server preventing the proper functioning of the Web Client.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

Tuesday, July 23, 2013

Troubleshooting the Microsoft Dynamics GP 2013 Web Client - Part 4

Part 4 - Tools for Troubleshooting Web Client issues: the Web Client Diagnostic tool

In Part 2 and Part 3 of this series, I talked about resolving Web Client implementation (installation if you will) and functional issues, respectively, along with some specific information that must be compiled to aid in the troubleshooting process.

No troubleshooting process would be complete should we not have the appropriate set of tools to aid in capturing some of this data. Let's start with the one tool you are most likely to use when opening a support case with Microsoft: the Web Client Diagnostic tool - in reality, is more like a set of diagnostics than _a_ diagnostic in particular.

The Web Client Diagnostic tool can be accessed once you create a support case and after the creation of an MS Solve case (also known as a Microsoft Fix It center case). The tool must be executed on both web server(s) and session host(s). The tool will collect important data that will allow Microsoft Dynamics GP Support to resolve your case. If you do not receive an invitation to execute the Web Client Diagnostic tool, you are encouraged to ask the Support Engineer on your case to send said invitation.

Support Case submitted
As you become more and more familiar with Web Client support cases, the above message is quite important. If this is missed after creating the case, the support engineer taking your case has no way to provide the Fix It URL shown above back to you.

The support engineer taking your case will need to generate a new link for you to use and pull the diagnostic information. The URL in the message is what you should copy off to either your email or another editor for safe keeping. Once that is done, you can access both web server(s) and session host(s) machine(s) and then paste the URL into the Web browser and following the guidance provided.

Automated Troubleshooting Services window

This is the default page that will be presented after pasting the URL into the browser once the Diagnostic Web site is launched. Once the Web page is opened, click on the “Run” and the diagnostic package will be downloaded to the local machine.

Run the Microsoft Automated Troubleshooting Services app
Once fully downloaded, you will then again be prompted to Run (or Don’t Run) the diagnostic. At the point is where the Diagnostic starts running through its wizard based UI.

Info Screen and Online Privacy Statement

Accept the terms and condition to actually allow Microsoft to gather Web Client specific data points.

Diagnostic Components download
Once accepted, all the diagnostic components are downloaded to the server you are running it on.

Select where to run the diagnostics

Once downloaded, select This Computer as your option and choose Next. The option of A different computer is currently not working as intended.

The package is executed

The Diagnostic tool will then create an multi-task execution package of all the steps to be completed for data collection.

Configuration and Setup information

Next the Diagnostic will begin its first data collection process, focused on Web Client configuration and setup data, once you select on the Start button.

Session Central and Session Host machine tasks

Once the installation and configuration data is collected, the Diagnostic tool will perform data collection on the Web Server (running Session Central Service) and Session Host machines. This screen allows you to click on a hyperlink to obtain further information on the information to be collected.

Session Central and Session Host data collection executing
Click Next to begin the data collection process on Session Central and Session Host.

Diagnostic Results

After gathering all of the information requested, the Diagnostic then packages the data up for submission to the Diagnostic web site. That submission will occur once you select the Next button. The Diagnostic tool will compile a number of screenshots, a list of Internet Explorer add-ons, performance data, machine configuration data, certificates and port binding information, URL reservation, and much more. Some of this information is collected using command line programs which I will talk about in a future installment.

Send diagnostic data to Microsoft
You can then save a copy of the diagnostic data prior to submitting it to Microsoft. This data is packaged in a cabinet file (.cab) for ease of submission and compression. Click the Send button to initiate the submission of the cab file.

File sent

Once the file has been submitted, then the process is complete. The file is then attached to the original support request, via the Microsoft Service Request (SR) number created by the Fix It.

Tomorrow I will talk about Fiddler and how they can be used throughout the troubleshooting process.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

Monday, July 22, 2013

Troubleshooting the Microsoft Dynamics GP 2013 Web Client - Part 3

Part 3 - Resolving Microsoft Dynamics GP 2013 Web Client Functional Issues

Last week, Part 2 of this series dealt with resolving Web Client implementation issues. The key to remember is any exception condition prior to the Microsoft Dynamics GP login window is treated as an implementation issue and as noted back in Part 2, there are two major processes - steps, if you will - in compiling information that will lead to resolving Web Client exceptions.

Just like with the implementation issues, you must compile information related to all application exceptions. Let's see what type of information can be compiled:

  • If the problem involves product functionality, it's always a good idea to record the steps to reproduce the problem.
  • It's also possible that the issues are UI related, i.e., a window does not display correctly (though these issues are less frequent, but certainly possible).
  • Printing and data export issues. In this case, you will want to determine whether the Silverlight application is being trusted.
  • Silverlight exceptions, i.e., those displayed in a window with a stop sign
  • Third party application customization vs. standard Microsoft Dynamics GP functionality. In a multi-dictionary setting, this will play a role whether using Web Client or the Rich Client (traditional Dexterity application).
  • Enable all available Web Client logs (session management and multi-tenant logs)
  • Capture all user-machine related information with MSINFO32.EXE
  • Can you reproduce the problem in the standard Microsoft Dynamics GP rich client application
  • Can the problem be reproduced by more than one user
  • Can the problem be reproduced in more than one company

The following are sample application exceptions:

Silverlight exception

App stuck on "Initializing" upon login

As you can tell, some of the information that must be compiled is standard. What must be taken into account here is, the Session Service is a real GP client running in the background supporting the Web Client session.

With that said, the following are some key success factors for the resolution of Web Client functional issues:

  • First, all issues must be treated jointly as Microsoft Dynamics GP issues and not something isolated to the Web Client.
  • You must keep in mind that Web Client will display the same exception messages displayed by the standard Microsoft Dynamics GP rich client.
  • Breakdown the problem and make sure it's focused on the Web Client.

Finally, summarizing:

  • The Web Client functionality "resembles" that of the Microsoft Dynamics GP rich client - we use the word "resemble" here, because we know certain things like navigation are slightly different in Web Client.
  • The rich client is installed on the Session Host server(s), therefore files like DYNAMICS.SET, DEX.INI, and forms and reports dictionaries are still in the mix
  • All exceptions experienced by the rich client are submitted to the Web Client, whether handled or unhandled.
  • All Dexterity third party applications are supported in the Web Client.
  • The Web Client uses a proprietary messaging system.

In part 4 of this series, I will look into some tools available for troubleshooting both implementation and functional issues.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

Thursday, July 18, 2013

Troubleshooting the Microsoft Dynamics GP 2013 Web Client - Part 2

Part 2 - Resolving Microsoft Dynamics GP 2013 Web Client Implementation Issues

Yesterday, in Part 1 of this series, I addressed the Microsoft Dynamics GP Support Team's posture when addressing Web Client support cases, by cataloging each reported issue as either implementation- or functional-related. In this opportunity, I will look at the major processes involved in driving your implementation-related support case to a rapid and successful closure.

In the process of troubleshooting your Web Client implementation issue, there are two categories of data that need to be compiled to close a support case: installation information and application related exceptions.

Compiling the installation information typically involves gathering the following information:
  • Type of installation (Intranet/Extranet/both)
  • Information about certificates
  • Firewall and Ports information
  • Number of servers supporting the installation (Web Servers/Session Hosts/SQL Servers)
  • Information about load balancers (if exist)
  • Domain security groups and user accounts
  • Run the Web Client Diagnostic Tool available as an option when you open a support case.
  • Provide the XML output file created by the Web Client Implementation Tool, if available

Compiling the Web Client application related exceptions involves gathering the following information:
  • Dynamics application log events
  • Session Service logs (if enabled)
  • Session Central logs (if enabled)
  • Internet Information Services (IIS) logs
  • Web page exception messages
  • Tenant exception information (if using Multi-tenant Services)
  • Fiddler and Microsoft Network Monitor (Netmon) traces

Web Client implementation exceptions can usually be identified by an "Unexpected Error" message in the browser as shown below:

Web Client application exception

Traditionally a support case would be started with a screenshot of an issue. However, as it relates to Web Client, Microsoft Dynamics GP Support cannot determine what an exception really means other than the fact that you encountered an exception. As such, Web Client implementation cases will usually require running the Web Client Diagnostic Tool in addition to providing Event Viewer information related to the Correlation ID displayed in the browser.

Event Viewer: Dynamics application event log

In a future installment, I will be covering all the troubleshooting tools available at your disposal, including the Web Client Diagnostic Tool, Web Client Implementation ToolFiddler, and Netmon among others.

In Part 3 of this series, I will address functional exceptions and resolution of functional issues.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

Wednesday, July 17, 2013

Troubleshooting the Microsoft Dynamics GP 2013 Web Client - Part 1

Part 1 - Microsoft Dynamics GP Support Team's Posture

With the introduction of the Microsoft Dynamics GP 2013 Web Client, system administrators now face additional challenges when troubleshooting errors produced while accessing the Web Client all the way to using the Microsoft Dynamics GP application itself over the browser.

To understand the troubleshooting process, it's best to explain the Microsoft Dynamics GP Support team's posture when addressing a support case: any error event that occur before the Microsoft Dynamics GP login window is presented to the end-user will be treated as a Web Client implementation support issue.

Issues in this category involve everything from the deployment planning of the Web Client up to the point where you obtain the Microsoft Dynamics GP Login window. Items such as issues during the installation of the Web Client, network configuration, certificates, routers, firewall configuration, DNS resolution issues, issues preventing access to the web client Sign In window are all considered issues that prevent an end user from using the Web Client and therefore access Microsoft Dynamics GP.

Web Client Sign In window (Windows Authentication)

Any error event that occurs after the Microsoft Dynamics GP application Login window is presented, and during the normal use of Microsoft Dynamics GP is considered a functional support issue.

Microsoft Dynamics GP Login Window (SQL authentication)

Functional support issues involve everything from issues accessing Microsoft Dynamics GP all the way through using all the application functions within the Web Client: data entry, printing problems, posting issues, Report Writer reporting, SSRS reports, Excel reports, and all issues that may happen within the Microsoft Dynamics GP application while using the Web Client.

Having a clear cut definition between problems will allow you to reach the right support engineer at Microsoft. In addition, implementation issues may require the use of specialized diagnostic tools to collect information about the Web Client installation environment that will allow the support engineer or escalation engineer to better understand how your environment is configured.

In contrast, functional issues would typically follow the standard support protocols you have come to know over the years.

There are some clear benefits to this posturing:

1. A reported problem can be routed to the right support team the first time around. After all, an issue with a certificate may require someone technical from within the support team to address the problem, as opposed to a problem printing a report.

2. Having the right team addressing the issue will allow Support to issue whitepapers, videos, or even training content on how to address the most frequent issues that come to them.

3. Diagnostic information can be served up to the right support engineer at the time a case is created. This is only possible if a problem is tagged as an implementation issue versus a functional issue.

4. It allows both technical and functional support teams at Microsoft to keep stats on product quality, which may result in targeted hotfix or service packs.

Tomorrow I will address the steps involved in resolving an implementation problem and how you can take advantage of some of the latest tools available from Microsoft to assist in the process.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC