Best-Practices Remediation Tips for Server 2012 Pt II

Part I is here.

Enable Large Send Offload (LSO) on a network adapter.


PS C:\Users\Administrator> Get-NetAdapterLso

Name                           Version         V1IPv4Enabled  IPv4Enabled  IPv6Enabled
----                           -------         -------------  -----------  -----------
Ethernet 2                     LSO Version 2   True           False        True
Ethernet                       LSO Version 2   True           False        True
Team                           LSO Version 2   False          True         True

 Now type this (it will interrupt network connectivity, but it should come back): 

PS C:\Users\Administrator> Enable-NetAdapterLso -Name *
WARNING: The network connection to DC02 has been interrupted. Attempting to reconnect for up to 4 minutes...
WARNING: Attempting to reconnect to DC02 ...
WARNING: The network connection to DC02 has been restored.

Now, let's look again:

PS C:\Users\Administrator> Get-NetAdapterLso

Name                           Version         V1IPv4Enabled  IPv4Enabled  IPv6Enabled
----                           -------         -------------  -----------  -----------
Ethernet 2                     LSO Version 2   True           True         True
Ethernet                       LSO Version 2   True           True         True
Team                           LSO Version 2   False          True         True


Enable Receive Side Scaling (RSS) on a network adapter.

Receive side scaling is a nice technology to have on servers with multiple processors and lots of network traffic. It basically spreads out processing load of network traffic across all your cores, instead of just piling it all on core 0. A good cmdlet to see what network adapters on your machine are capable of RSS:

PS C:\Windows\system32> Get-SmbServerNetworkInterface

Scope Name          Interface Index     RSS Capable         RDMA Capable        Speed               IpAddress
----------          ---------------     -----------         ------------        -----               ---------
*                   12                  True                False               1 Gbps    
*                   12                  True                False               1 Gbps              fe80::2d14:f5e1:...
*                   12                  True                False               1 Gbps              fd58:2c98:ee9c:2...

To enable RSS across all your network adapters, simply do:

PS C:\Windows\system32> Enable-NetAdapterRss -Name *

Just like you did before with LSO.


Enable IPsec Task Offload v2 (TOv2) on a network adapter.

One more. Works the same way. Try Get-NetAdapterIPsecOffload to see the status of that feature on your network adapters. If the cmdlet returns nothing, that means the feature is not available on any of your network adapters. If it is available, but not enabled, then just do Enable-NetAdapterIPsecOffload -Name *.

Cyber Monday Sale - Half Off eBooks from O'Reilly

50% off all eBooks today from O'Reilly Media. Man I love eBooks. This is probably my Generation Y showing, but most times I'll take an eBook over print. (I know that makes most book lovers cringe.)

My shopping cart keeps growing...

EventLogClearer v1.1.3.22

I have released an updated version of my EventLogClearer, bringing it up to version For the original release, see this post.


Improvements made in this version include:

  • Fixed a bug where the application acted weird if you ran the log clearing procedure two or more times in a row.
  • Added a new mechanism for supplying alternate credentials, instead of only being able to run as the currently logged on user. This applies to both auto-populating the list of computers from AD, and running the event log clearing procedure. If you leave the credentials blank or as the default, "username," the current user will be used.
  • Added the ability to clear a ton more Applications and Services logs than before, due to me realizing the potential of the EventLogSession class.

As before, .NET 4.5 is required to run the application. The project was built in Visual Studio 2012.

Here is the executable: (68.71 kb)

Here is the source code: (308.11 kb)

Sometimes I Can Access the WebDAV Share, Sometimes I Can't!

You probably already know that all of the Sysinternals tools, such as Process Monitor, Process Explorer, Autoruns, and much more, can be accessed via "shared folder" from any computer connected to the internet by navigating to \\\.  This isn't the same kind of share you'd create if you just shared a folder on your PC.  It's a WebDAV share, and is accessed over HTTP.

Sometimes though, I feel the need to access this share from the command line, either in the Cmd shell or Powershell.  Alas, here's what I see:

Network path not found*Path not found.*

I get the same result with Powershell. Bummer. Well I know I can access the path with Explorer when I type that same UNC into the address bar, or if I just type the UNC into the Run dialog box, so this must just be a limitation of those command-line tools, right?

It works in Explorer*Works fine in Explorer*

Oh well... but wait. Now having successfully accessed the network path with Explorer, let me now immediately go back to the Cmd shell and try it again:


Now it works in Cmd too!*Now it works in Cmd too!*

OK, now accessing the network path works fine from the Cmd shell and from Powershell, even though all I did was access it through Explorer first, and then try again. Now I just have to know what the heck is going on... and to do that, I need to use Process Monitor. Which, amusingly, is in the WebDAV share I'm trying to access. But I'll run a local copy.

I started the trace. Here's my first attempt to access the network path with Cmd.exe, which failed:

Cmd.exe network path not found*Network path not found*

This was the very first time in the Process Monitor trace when the string "" appeared in the Path field. It's also the first time the Cmd.exe process shows up in the trace. It's currently filtered to only include events where the Path field contains the string The really interesting part about this is that it appears the moment I pressed Enter on the command line, Explorer.exe was the first process to be involved, not the process I was interacting with! That's odd. Maybe a file system filter driver intercepted the call and notified Explorer? It looks like Explorer is looking for something related to named pipes and the Workstation Service (wkssvc) on the remote server, but it doesn't find it.  Then Cmd.exe first checked my local file system for a file in Windows\CSC\ directory, which it didn't find, and then it tried to access the network path that I actually asked for, which resulted in "Bad network path." Then it apparently tries again with the same local file system path, and then again with the network directory instead of the specific executable name.  All failed. "Network path not found," my command prompt tells me. But with no further input from me, Explorer takes off doing its own thing, calling cscapi.dll and loading things in the background and sending things over network. All I did was hit enter in the Command Prompt above.

So what is this CSC directory? Googling the term led me to an old post on Raymond Chen's blog. Client Side Caching. OK, so apparently both processes are looking for a cached or offline version of the network path.

Then I move over to the Explorer.exe window and type the path into the address bar. Explorer looks for some more CSC stuff first, and then svchost.exe starts communicating with the remote server over TCP. There's a lot of loading of WebDAVRedirector stuff. Finally, after a lot of work, I start seeing events like these from Explorer:

Explorer finds it, finally*Explorer starts finding it, finally*

Notice that Explorer also seems to be storing the autoruns executable in a temporary "Tfs_DAV" directory on my workstation.

Finally, after having success with Explorer, I go right back to the Command Prompt and try it again. This time, the trace looks like this:

Works in cmd.exe now too

Now I see svchost.exe stepping in with a WebDavRedirector, and cmd.exe getting some successful returns from its IRPs. Finally, after playing around in that Tfs_DAV directory and some more intermingling of svchost.exe and the System process both helping out, the process autoruns.exe finally launches.

So that's a pretty fast and loose overview of what is actually going on. The entire trace was a beast to wade through, and there is obviously a lot of orchestration and cooperation required between many different Windows components required to allow you to access a WebDAV share from within Cmd.exe and I don't fully understand all of it... but the bottom line is that at least on my Windows 7 SP1 x64 workstation, it looks like Explorer.exe is smart enough to read from a WebDAV share and cache the data locally, whereas Cmd.exe is only smart enough to read the data locally, if and only if it's already cached locally... or perhaps the redirector had to be "woken up" by Explorer first, before Cmd.exe was able to use it.

Finally, I'll leave off with a bit about the WebDAV Mini-Redirector from Wikipedia:

"In Windows XP, Microsoft added the Web Client service is also known as the WebDAV mini-redirector[11] which is preferred by default over the old Web folders client. This newer client works as a system service at the network-redirector level (immediately above the file-system), allowing WebDAV shares to be assigned to a drive letter and used by any software. The redirector also allows WebDAV shares to be addressed via UNC paths (e.g. http://host/path/ is converted to\\host\path\) for compatibility with Windows filesystem APIs."

Blog Posts You Must Read

The PFE Platforms team has published another blog post in their MCM: Active Directory series, which was such a fantastic post, it inspired me to create a "Blog Posts You Must Read" section over there on the side bar. It will be for blog posts and/or blog post series' that are so good that I find myself going back and reading them multiple times, or even going back to use them for reference material. I think that's a lot more meaningful than just a gigantic generic list of every website I know of.

More to come as I finish trawling through my bookmarks or stumble across new ones.