Coffee Break – Monitoring and Troubleshooting Services Part 2


In this post, we thought we might look into how to use Windows PowerShell to work with XML data. As a user scenario, we are continuing here on our previous post, to look further into server troubleshooting possibilities.

You might experience an error, warning, behavior that you want to analyze, but have no clear repro scenario for. Troubleshooting these scenarios normally starts with messages logged in the Application Log, and in the previous post we talked about how to check the application log using PowerShell.

However, you’ll often find that the application log contains insufficient or no details about the problem you’re analyzing.  In these cases, you can trace overall service activity to find the root cause of the behavior you’re looking into. Or the issue might affect one client only, in which case you will want to trace that client (be it Windows client or Web client), to find the cause of the problem. The best option here is to use Windows Communication Framework (WCF) tracing.

You can enable WCF message logging in the config file for the Dynamics NAV Server instance sothe messages processed by the service are logged. Message logging can be used to diagnose your applications and analyze the root cause of problems. Message logging is not turned on by default; turn on message logging by setting attributes on the <messagelogging> element in your configuration file and then add a trace listener to log the events to a file.

Similarly, you can enable WCF tracing (in the service config file) to help debug your WCF service by logging all operations on your service.

You can find more details on different tracing options here, and more details related to tracing on Dynamics NAV here. Here you will find a list of settings we will be adding to server config file to enable tracing.

Coffee Break 15 – Using Windows PowerShell to enable WCF message logging and tracing on Dynamics NAV Server

We’ll start by modifying the server config file to add these settings. You can modify your service/client config file by using the WCF Service Configuration Editor. However, as these posts are all about automation, we will naturally look into how to do this using PowerShell.

There are probably more than one ways to do this, but for this example we have chosen XMLDOM. The service config file is an xml file, so we’ll be using XMLDOM to enable tracing in the config file. To upload an XML-formatted text file as to Powershell XML, all you need to do is strong type it as XML.

Example:

$xml = [xml](Get-Content D:\Microsoft.Dynamics.Nav.Server.exe.config)

Once tracing is enabled, trace and message logs will be stored at the location that you specify:

$LogFolder = ‘c:\Logs’

if (!(Test-Path -Path $LogFolder)) {new-Item -path $LogFolder -ItemType directory} 

 

#provide server config file name

$Filename = ‘Microsoft.Dynamics.Nav.Server.exe.config’

 

#provide full path and name of the config file 

$ConfigPath = (Get-ItemProperty  ‘HKLM:\SOFTWARE\Microsoft\Microsoft Dynamics NAV\80\Service’)

 

#Upload config as xml document

[xml]$blobxml = Get-Content -Path  (join-path ($ConfigPath).Path  “\$Filename” ).ToString()

 

To see all methods and properties of the XML object, run

Get-Member -InputObject $blobxml

 

To check the childnodes of the document, use

$blobxml.ChildNodes

 

To create a node, use

$elem = $blobxml.CreateNode(‘element’,<node name>,”) 

 

To append the node:

$Node.AppendChild($elem)

 

For full reference to XMLDOM class, methods and properties, see the MSDN Library.

The complete example of enabling WCF tracing using PowerShell is attached to this post (ServiceTracing_PS.ps1).

Note that the example adds the following tracing configuration:

MessageLogging,  switchValue=”Warning, ActivityTracing”

Tracing, switchValue=”Verbose,ActivityTracing”

 

wmiProviderEnabled= “true”

 

logEntireMessage=”true”

logMalformedMessages=”true”

logMessagesAtServiceLevel=”true”

logMessagesAtTransportLevel=”true”

maxMessagesToLog=”100000″

maxSizeOfMessageToLog=”10000000″

 

These should be adjusted as needed (see tracing options).

Once the config file is modified, you must restart the service for tracing to start. Logs will be generated at the specified location (in our example c:\Logs).

 

After you have captured the event, you should turn off the tracing. One can either replace the modified .config file with the original one (that will remove tracing configuration), or modify the relevant settings (using PowerShell, of course) to turn off the tracing.

Settings to modify to turn off tracing (following the example above) are :

 

MessageLogging,  switchValue=” “

Tracing, switchValue=” “

 

wmiProviderEnabled= “false”

 

logEntireMessage=”false”

logMalformedMessages=”false”

logMessagesAtServiceLevel=”false”

logMessagesAtTransportLevel=”false”

maxMessagesToLog=”0″

maxSizeOfMessageToLog=”0″

 

Tracing will stop once the service is restarted using the above configuration (or original config file).

An example of a script to turn the tracing off is also attached to the post (Stop_Server_Tracing.ps1).

 

Run the above scripts remotely on your customer’s server to trace the customer’s service (on premises or in the cloud) to enable /disable server tracing and messaging.

Happy troubleshooting!

 

Jasminka Thunes, Escalation Engineer Dynamics NAV EMEA

Lars Lohndorf-Larsen, Escalation Engineer Dynamics NAV EMEA

Bas Graaf, Senior Software Engineer Dynamics NAV

ServiceTracing_PS.zip

Comments (2)

  1. Matthias König says:

    Hi,

    did you have an example (with screenshots) why we need this? I can not mention a reason to trace that :/

    kind regards,

    Matthias König

  2. Hi Matthias,

    This is frequently used in our support team for troubleshooting issues on server/client (issues we cannot learn enough about from event log or by c/al debugging or SQL profiling).

    This gives you the ability to trace/message overall Service/Client Activity in great details.

    We have used it for years now for range of issues: tracing server/Client crash, hang, synch issues, client/server connectivity issues in various environments, etc.

Skip to main content