D-Root IPv4 Change - Do You Have the New One?

D-Root changed its IPv4 address back on January 3rd.  The old one is still up for now, but will be phased out in the future.  The old IPv4 address is 128.8.10.90.  The new address is 199.7.91.13. (d.root-servers.net IPv6 address is not changing.)

Today, someone asked me how to figure out, on the command-line, whether their Windows DNS server had the new updated d-root IP address or not.

After about 10 minutes of fiddling, here is what I came up with:

PS C:\> If($(Get-WmiObject -Namespace root\MicrosoftDNS MicrosoftDNS_ResourceRecord | ? DomainName -Match "root-servers.net" | ? OwnerName -Match "d.root-servers.net." | ? ContainerName -Match "..RootHints").IPAddress -ne "199.7.91.13") { Write-Host "YOUR D-ROOT IS OLD!" }

If your DNS server is still configured with the old root hints address for d-root, the command will notify you.

Best-Practices Remediation Tips for Server 2012 Pt II

Part I is here.

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

Before: 

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              192.168.1.9
*                   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 *.

EventLogClearer v1.1.3.22

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

EventLogClearer 1.1.3.22

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: EventLogClearer-1.1.3.22-exe.zip (68.71 kb)

Here is the source code: EventLogClearer-1.1.3.22-source.zip (308.11 kb)

Best-Practices Remediation Tips for Server 2012 Pt I.

I'm calling this Part 1 because I realized as I started writing that this is a lot of work, and can easily be split into 2 or more articles.

Like most of the IT Pro community, I've been getting comfortable with Server 2012 the past several weeks now, and the journey is still ongoing. As I talked about last time, I do like those Best Practices Analyzers for Windows Server. Here's me running it in Server Manager:

Best Practices Analyzer Server Manager 2012*BPA in Server Manager 2012*

Getting any of these results back means that I have some work to do in remediating them. It's not uncommon for a Server 2012 system that was just built fresh with no applications loaded or configuration changes to still have one or two compliance issues in the Best Practices Analyzers. There is a balance to be maintained between compatibility and performance optimization. Also, many of these issues that popped up for me personally were not role-specific, but rather apply to a base component of the OS. Now I'll go over some of the interesting ones I've gotten and how I fixed them:

 

[Hyper-V]: Avoid storing Smart Paging files on a system disk.

Smart paging is new with Hyper-V 2012. Read about it here. Basically, you now enter a minimum amount of RAM a virtual machine can have, you enter a maximum amount of RAM a virtual machine can have, and you also now enter the amount of startup RAM a virtual machine can have. The Windows OS can boot up more comfortably with a larger amount of RAM, but once it reaches cruising altitude and is idle, the RAM requirements go back down, which will allow the Hyper-V host to gradually start reclaiming memory from the VM. With all this dynamic shrinking and growing of the memory on all your VMs, that's where the "smart paging file" comes in. And just like you can improve performance by putting your traditional Windows paging file on its own disk, the same goes with the Smart Paging file.

[Hyper-V]: Use RAM that provides error correction.

Microsoft doesn't support Hyper-V environments on hardware that isn't using ECC RAM. This is just a lab using desktop-grade hardware, so there's nothing I can really do about this. If you're using real server gear, this should not be an issue for you.

[Hyper-V]: Virtual machines should be backed up at least once every week.

This one I still don't understand. I have all the guest operating systems backing up nightly, and then I am backing them up again through the backup of the Hyper-V host. So go away, error.

[Windows]: Short file name creation should be disabled.

Then why is it enabled by default? Oh, I know why... it's because of your crappy line-of-business apps that were written back in 1998 that you can't get rid of, right? Well I'm in a pure 2012 environment right now, so I have no such worries. Good bye 8.3 filenames. Change this registry value to 1 to disable short file name creation on all volumes: HKLM\System\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation.

[Windows]: IrpStackSize should have the recommended value.

Irp stands for I/O Request Packet. Mark Russinovich did a great job of explaining IRPs and their role in the Windows I/O system in his book Windows Internals. All the various components or layers that an I/O packet traverses on its way to and from a disk, for example, are collectively referred to as "a stack." Each filter driver you add to the file system means that the IrpStackSize needs to be increased in order to accommodate it. A common example of this is when you install an antivirus product that uses a file system filter driver. If your IrpStackSize is set too small, certain operations might fail, such as attempting to access that machine's file system remotely. Conversely, it doesn't need to be set too high, either.  It was at 11 by default on my 2012 systems. The Best Practices Analyzer says it should be at 15, so I'll set it to 15. HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters\IRPStackSize.

 

Alright, that's where I'll leave off for part 1. Part 2 will focus on some more network-specific optimizations, so check back soon!