Windows Enterprise Client Boot and Logon Optimization – Part 21, Infrastructure and Settings – Network

This post continues the series that started here.

Earlier in this post series, I’ve discussed the importance of client system proximity to server resources. Whether the client is retrieving group policy data from a Domain Controller or loading a roaming user profile, it’s important that the network conversations occur quickly.

Sometimes, you may be investigating a boot trace and have some uncertainty as to whether the client system is communicating on the network at all. Fortunately, Windows Performance Recorder (WPRUI) provides the ability to capture network information and using Windows Performance Analyzer (WPA) , you can create a graph that illustrates network throughput.

Boot Trace Capture

As with all analysis traces I’ve shown earlier, I’ll suggest you use Windows Performance Recorder (WPRUI) but this time, with an extra option selected, Networking I/O activity

image

You’ll need to keep in mind that this will significantly increase the size of the boot trace. A test run on my own Windows client system resulted in a trace of around 1.4 GB. For this reason, only use this option if correlating network activity with the boot phases is important.

Boot Trace Analysis

After opening the analysis trace in WPA, I get started by opening the Generic Events graph. I want to change the graph type from a checkpoint graph to a histogram. To achieve this, I’ll change the column that lies to the right of the blue bar –

From image to image

Next I want to aggregate events in a way that will make them useful to my analysis. I order the columns to the left of the golden bar as follows –

image

My goal is to correlate network activity on the wire to other graphs I may be examining in my trace. Having a look through the list of providers, I come across Microsoft-Windows-TCPIP and after I expand this provider, I notice Task Names of TcpDataTransferReceive and TcpDataTransferSend

image

This seems like the data I’m interested in and I want to filter the graph so that it only displays these events. To do so, I click the gear icon at the top of the graph –

image

This opens the Generic Events View Editor after which I click Advanced

image

Here I’ll enter an event filter for the Task Names I’m interested in and click OK a couple of times to get back to my graph –

image

Now that I’ve filtered down to the events I want, I’ll remove Provider Name from the Generic Events table –

image

Lastly, I’d prefer a histogram to a line graph so I’ll select the chart type button at the top of the Generic Events graph and choose Stacked Bars with a very tight interval –

image

Now I have a graph that illustrates how network I/O correlates to by boot phases –

image

Network Trace

Based on what I may deduce using the technique above, it may be necessary to gather a network trace for analysis in Microsoft Message Analyzer. To achieve this at boot time, I can use the following command before rebooting –

netsh trace start persistent=yes capture=yes tracefile=C:\Traces\NetworkTrace.etl

And the following command after rebooting –

netsh trace stop

The resulting NetworkTrace.etl file may be opened in Microsoft Message Analyzer for typical network analysis.

Conclusion

Today I’ve discussed a method you might use to correlate network activity with Windows boot phases. This is useful to determine whether there is some delay before network communications start or if they pause somewhere in the boot/logon process.

If a network problem is suspected, a full network trace may be recorded over a reboot using netsh and analysed with Microsoft Message Analyzer.

Next Up

Blog Post Series Wrap Up