ETW End-To-End Tracing

ETW End-To-End Tracing

Post by Gter Pross » Wed, 31 Mar 2010 22:41:47

Hello NG!

In ETW the ActivityID is provided to allow clients to analyse traces from
different providers in a End-To-End Analysis.

What I don't really understand is what is needed in the Application to
support such a scenario, and what is provided by the OS or MS-Servers to do
so (everything for Windows 2008 Server).


* I implement a Service which uses the HTTP-API to communicate with clients
* The Service calls an SQL2008 Instance


1. A SYN TCP Package is issued from the Client, this is traced by the
Windows TCP Stack with ETW
2. The TCP Session is established, this is also traced
3. The HTTP.sys takes over, parses the request, and feeds it to my service
(which has a HttpRecieveHttpRequest operation pending). AFAIK HTTP.sys also
produces ETW Traces.
4. My Service processes the request (and also produces some ETW Traces)
5. As part of the Request-Processing an Batch is send to a SQL-Server
(SQL2008, which also implements ETW).
6. The Service prepares the HttpResponse for the Client-Request
7. HTTP.sys does whatever is needed to send the HTTP-Response.
8. The Client gets it

How can the Activity-IDs be managed to support an End-To-End Tracing in such
a (common) scenario? I want an ETW-Client to build an report which starts
from the first SYN, contains HTTP.sys traces, Application traces and


* Who generates the Acticity-IDs in the first place?
* What are the best practices to serialize Actitiy-IDs in a protocol? for
HTTP a special Header may be used, but what about TDS (SQL-Server Protocol)?
* What about other services that may be involved (e.g. an ISA Firewall
between the Client and the Server, if ISA Server implements ETW (I don't
know) should it be possible to included Firewall-Logs in the trace?)
* What clients can be used to support such End-To-End Tracing Scenarios?


1. Trace file about end-to-end packet delay

2. Transitioning RPC-HTTP setup from back-end only to front-end / back-end setup

My company is currently using RPC over HTTP on a single server using the No
Front End Server scenario.

The current server is getting overused and performance is degrading so we
are bringing up a second Exchange 2003 back-end server. My understanding is
that we now also need an Exchange 2003 front-end server as well. I have
both of the new servers configured, with Exchange installed and part of the
Exchange organization. I have a few questions about the next steps.

If I configure the new server as a front-end server for testing will that
make any changes to the existing back-end server that is currently handling
the RPC-HTTP and OWA connections? My plan would be to do initial testing
using a different URL on the new front-end server and then later migrate the
existing URL and certificate from the current back-end only server. I know
that front end servers will dynamically update when a back end server is
added and I'm just concerned that if the back-end server might update
someting when a front-end server is added so users can no longer connect to
it directly.

I have not found any documentation on making this transition from back-end
only to front-end back end setup. Technet gives instructions titled "How to
Deploy RPC over HTTP for the First Time on Exchange Server 2003 SP1
(Front-End/Back-End Scenario)" but we are not deploying RPC over HTTP for
the first time, we want to transition an existing setup.
Can anyone point me to any documentation that covers our scenario?


3. in OWA, the End key should go to end of page, not end of inbox

4. Front-End/Back-End Scenario, Back End on Global Catalog Server

5. what is the meaning of "end" when using num2str(y1(end) - y2(end))

6. Mystery low-end machine; low-end grunt work; low-end (even temporary) OS anyone?

7. Qury sub-forms breaks front-end to back-end when imprting from new front-end

8. end-to-end vpn

9. Measure delay end-to-end

10. SN#14290 Securing Web Services Using End-to-End Security

11. SAS recipe for end-to-end workflow?

12. Yesterday's InfoPath WebCast: InfoPath in End-to-End Enterprise Solutions: Integrating InfoPath with Siebel and SAP

13. Universal Services (XForms, DB2 pureXML, XML end-to-end)

14. end-to-end exchange

15. End-to-End VOIP