Environment and Configuration
Collapse the table of content
Expand the table of content

Environment and Configuration

Connected Services Framework

General Environment and Configuration Troubleshooting Steps:

  1. Verify that the component is working
  2. Check for errors in the event log
  3. Verify that messages are being sent and received
  4. Confirm expected behavior of the component


Step 1: Verify That the Component Is Working

Using Microsoft Internet Explorer, browse to the URL of the component. The URLs of the Connected Services Framework components are found in the Common.config file. Each of these URLS should return a Web Services Description Language (WSDL). The presence of the WSDL indicates that this component is up and running correctly in Microsoft Internet Information Services (IIS).

If the component does not return the WSDL, verify the following:

  • Each component has an appropriate application pool. The pool must be running. The pool must contain a valid account in the Identity tab of the pool properties. Note that the password is not validated by IIS when it is entered on this screen; the only check that is done is to verify that the user enters it in the same way twice. 
  • The identity account must be added to the local IIS_WPG group to allow it to run under IIS. 
  • This identity account must have access to the local Microsoft Windows® temp directory as well.

Each component Web service must have the following:

  • The properties of the Web service must set the Execution Permissions to allow execution of scripts and executable under the Virtual Directory tab.
  • Go into the Directory Security tab of the properties and select the Edit button of the “Authentication and Access Control” section. In the following pop-up, check the “Enable anonymous access” box. Uncheck any remaining boxes on that popup. Allowing integrated authentication will not work as the applications calling these services do not handle Windows authentication challenges.

Once a component is up and running, it will log a startup audit message to the application event log indicating that it has started. Additional events may also be logged by the component at startup; the component may also indicate at startup that other events of note are occurring.


Step 2: Check for Errors in the Event Log

The Connected Services Framework logs fatal errors to the Windows application event log. Web Services Enhancements (WSE) logs events there as well. These errors are identified by the component that logged them—Session, Service Catalog, and so on. The details of the error indicate the type of error encountered and provide information required to resolve those errors. The documentation for the various components indicates errors and possible resolutions for them. 


Step 3: Verify That Messages Are Being Sent and Received

All WSE message flows can be traced as they are sent and received from applications. The following XML, when added to the application or Web configuration file, will turn on the tracing of the message flow, both input and output, as well as turn on the tracing for the processing of WSE security policy files when they are used.

    <trace enabled="true" input="C:\ConnectorName_InputTrace.webinfo" output="C:\ConnectorName_OutputTrace.webinfo"/>
    <policyTrace enabled="true" input="C:\ConnectorName_receivePolicy.webinfo" output="C:\ConnectorName_sendPolicy.webinfo"/>

Each message in the trace file contains key header information that can provide information as to the routing of the message. The key tags to examine in the message are:

  • <wsa:Action> The action indicating the operation being invoked. The calls in the consumer API map to similar values in the action tag. In user applications, these map to Soap Methods on the service. This can be used to verify the expected message flow with what is observed. 
  • <wsa:To> The destination of the message. Since this is a URL, it can be copied and pasted into Internet Explorer to determine if the URL is valid. This can verify that the destination is correct and that the destination service is responding.
  • <wsa:From> The source of the message. This is filled out by the consumer API calls and will be used when returning responses to the caller.
  • <wsa:ReplyTo> The address to use when replying to the request. This overrides the address in the <wsa:From> tag. It can be used to redirect responses if desired. 


Step 4: Confirm Expected Behavior of the Component

If the problem persists after the messages have been successfully traced to components and no error events are logged in the event log, the problem may be in the expected behavior of the component. All of the components, with the exception of Session, have fairly simple defined behavior. They take in requests and return responses. If they encounter problems in processing, the response from the component will contain an error code and/or message. For severe errors, an event log message will be logged. Debugging of these issues can usually be handled through the examination of the error codes and the documentation for that component.

All Connected Services Framework components have tracing logs that can be turned on to give additional information about program flow. These are collected and managed through the Microsoft Enterprise Instrumentation Framework (EIF). The standard installation places a TraceSession.config file in the C:\Program Files\Microsoft Enterprise Instrumentation\Bin\Trace Service directory. This file may be edited to turn on tracing for the various components. A special reader, TraceFileReader.exe, is required to read these files and is provided in the distribution. Note that EIF files may appear to be empty despite being in use. They will not be flushed from memory to disk until the reader is used to access the data. The EIF distribution itself also provides some samples that may be used to create readers for these files.

© 2016 Microsoft