IPv6: Be gone!

Let me start this piece by stating that I am not advocating that we all ignore IPv6.  There are many reasons to use it, and there is nothing wrong with it.  Sure, it is more complicated than we may like… but then again, so was IPv4 when we were first introduced to it.

But alas, if you and your organization are not using IPv6, then there is no reason to have it bound to your workstations, let alone to your servers.  Let’s get rid of it… for now, knowing we can come back and re-enable it with a simple cmdlet.

First, we need to see which network cards have IPv6 bound to it, with the following:

Get-NetAdapterBinding | where {$_.ComponentId -eq ‘ms_tcpip6’}

That will return a list of NICs that have IPv6 enabled, like so:

Get-IPv6

We can remove the binding from each adapter individually, like so:

Disable-NetAdapterBinding -Name “Wi-Fi 2” -ComponentID ms_tcpip6

Of course, then we would have to do it for each of our NICs.  Rather than doing that, it would be simpler to just use a wildcard, thus disabling it for all of our NICs simultaneously:

Disable-NetAdapterBinding -Name “*” -ComponentID ms_tcpip6

Of course, in order to do this, you must open PowerShell with elevated credentials, so make sure you Run As Administrator.

Once you have done that, you can then go back and get the same list.  Notice that the listings under Enabled all read False now.

Disable-IPv6

Now, as you may have heard me say before, PowerShell is very easy to understand… it is almost as if it were post-troglodyte grammar.  Get-Thing! Disable-NetAdapterBinding!  So it stands to reason that the reverse of the Disable-NetAdapterBinding cmdlet would be… yes, you guessed it! Enable-NetAdapterBinding!  But this time, rather than using the wildcard, let’s just do it for the NIC that I am currently using:

Enable-NetAdapterBinding -Name “W-Fi 2” -ComponentID ms_tcpip6

From this, we will now get the following results:

Enable-IPv6

…and just like that, we can now enable and disable a protocol on demand.

By the way, if you are not fond of ComponentIDs, you can also use the actual display names:

Get-Bindings

Of course, that is too much typing for a lot of people, so you could shorten it with wildcards… or you can just cut and paste the ComponentID cmdlets.

Have fun guys, and script on!

 

 

Default Gateway Corrections

PowerShell.jpgThe default gateway setting in Windows (and every other networked operating system) is a simple setting that tells your network interface card (NIC) where to send traffic when sending it outside of your domain segment.  More often than not, it will be the .1 address of a network segment (e.g.: 10.0.0.1), but that is not always the case.

It is one of those settings that you set once and forget it… It almost never needs to be changed… until it does.  Network reconfigurations do happen, and changing the default gateway is simple to do in the graphical user interface via the Properties window of your network interface, simply by modifying the appropriate field in the  Internet Protocol Version 4 (TCP/IPv4) properties.

But what if you need to do it for several machines?  Of course, PowerShell to the rescue!

First, you need to check what your NIC Interface Index is:

Get-NetIPConfiguration

This will give you an output that looks like this:

Get-Alias

As we see in this example, the server was moved from one network segment (10.128.43.x/24) to a new one (10.128.11.x/24).  Because of that, we need to assign a new Gateway in the proper network segment.

The Interface Index here lists as 3.  Remember that.

Before we add the new Gateway, we have to remove the old one.  Otherwise the NIC will have two gateways, and that can cause issues.

Remove-NetRoute -ifindex 3 -NextHop “10.128.43.1”

Notice that we put in 3 for the ifindex (the Interface Index), and the old gateway in quotes.

Now that we have a clean slate, all we have to do is configure the new default gateway, with this:

New-NetRoute -interfaceindex 3 -NextHop “10.128.11.1” -destinationprefix “0.0.0.0/0”

Again, we change our interfaceindex to 3, and our NextHop to the proper gateway.  When you run these two commands, you should get the following output:

Done

That’s all there is to it!  Of course, you may want to execute this script against a group of computers, but that’s for another time…

 

 

 

UNC Path Nightmare

imageAnyone who has taken a basic networking course will understand that UNC (Universal Naming Convention) paths are one of the common ways we in IT access file shares across our local networks.  They will usually look like this: \\oak-mgt-01\Sharename.  Of course, you can see all of the shares on a particular server by just entering the servername (\\oak-mgt-01).  Once upon a time Windows Explorer would show you that path in the address bar, but in this era of simplification of everything (i.e.: Dumbing it down) it makes it prettier by showing > Network > oak-mgt-01 > Sharename.  This changes nothing, it is the same under the hood.

Users are not the only ones who use these UNC paths.  In fact, it is our servers and applications that use them far more frequently than we do, because under the hood that is what they use to connect to any network resource.

But what happens when UNC paths stop working?

A client called me recently to tell me that none of their UNC paths were working, and because of it their production applications were down.  I checked, and sure enough a particular server could access the Internet just fine, and it could ping every internal resource it wanted, but when you tried to navigate to any UNC path, the result was a very unfriendly and generic one:

image

Not only was it not working, it was not even giving me a descriptive error code.  I started down a troubleshooting rabbit hole that would haunt me for hours before I found the solution.

The first thing that we confirmed is that while we were pretty sure that this was a networking issue, it was contained within the specific server.  How did we determine this?  We discovered that we got the same result when we tried to navigate to \\localhost.  Localhost is that trusty loopback adapter that exists in every network device, and is the equivalent of \\127.0.0.1… which of course we tried as well.  Because we know that Localhost lives within the server, we knew that it was not an external issue.

Before we went out to the Internet for other ideas, we tried all of the obvious things.  We changed the NIC, we verified DNS, WINS, and even NetBIOS over TCP/IP.  We reset the network connection (netsh ip reset c:\resetlog.txt).  Nothing doing.

We went out to the Internet and followed the advice of several people who had been in our spot before.  We uninstalled and then reinstalled several networking components.  We deleted phantom devices, we ran network reset tools.  No joy.

When I came across Rick Strahl’s Web Log I thought I was close…he had experienced exactly the same symptoms, and in his article UNC Drive Mapping Failures: Network name cannot be found I was hopeful that when I re-ordered the Network Provider Order in the registry (HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order) I would be home free.  Unfortunately I was wrong… but I was in the right place.

When Rick’s solution didn’t work, I was disheartened.  I was about to close it out and look at the next ‘solution’ on-line.  My instinct however told me to look again… to look closer.

image

There was a typo… but you have to really know what you are looking at to see it.  In fact, even if you really know what you are looking at, it is easy enough to miss.  Take a look… do you see it?  Look closer… The entry LanmanWorkstation is right there, clear as day, right?

Nobody would blame you for not noticing that there is an S at the end of the string… because S is so common at the end of words – it just makes them plural, right?  Well computers – and especially the Windows Registry – does not know English grammar, it knows binary… and the difference between LanmanWorkstation and LanmanWorkstations is the difference between working… and not working.

When I made the change it was instant – no reboot was required, the server application started working immediately.  A big sigh of relief permeated the office.

The server in question is one that several people were working on when it stopped working, and nobody is entirely sure how it happened… was it human error, or did a rogue process cause it?  We will look in our logs and figure that out later.  For the moment though, our UNC paths are back, and my client is back at work.

Server Core Address Woes

From the files of “What the F@rk?!”

Here’s a little gotcha that I’ve been wrestling with all afternoon.  I hope this post can save some of you the frustration (exacerbated by jetlag) that I have been experiencing.

I am configuring a bunch of virtual machines as domain controllers for the company I am consulting for in Japan.  Things are going really smooth on the project, but we wanted to spin up half a dozen DCs for the new environment, so I figured I’d just spend a few minutes on it.  Then I had to configure the IP Addresses… something I have done thousands of times, both in Server Core and the GUI.  I have never encountered THIS before.

Server 1: Done.

Server 2: Done

Server 3: NO

Server 4: Done

…and so on.  I went back to Server 3 figuring there was a bit of a glitch, and sure enough, it had an APIPA (Automatically Provided IP Address) assigned.

I loaded up the sconfig menu, and set the IP Address by hand.  The weirdest thing happened… it replaced my IPv6 address with the Class A address I assigned, and left the APIPA address.

I went down to the command line… netsh interface ipv4 set address name=”Ethernet” static 10.x.y.z…  and it still gave me an APIPA address.

I was getting frustrated… something was simply not going right.  And then it occurred to me… someone else was playing on my network.  Sure enough, he had already assigned that address.  Instead of giving me a warning, it simply wouldn’t duplicate an address that already existed.

Now if I had already implemented my monitoring solution, this would never have happened!

Virtual Networking in Hyper-V 2012

Microsoft has released a poster diagramming virtual networking in Hyper-V 2012.  Much of it revolves around Virtual Machine Manager, and is actually branded System Center 2012 SP1.  If you are building or managing datacenters – even smaller ones – you should download this document and review it.  We all have something to learn from it!

The VMM networking poster is available for download here.

Now: If you are going to be at MMS, I am told that the Windows Server team will be giving out printed copies – I had one of the original Hyper-V environment and wore it out – it was my most referenced document for months!

If you are interested in evaluating Windows Server or System Center 2012 you can can do so by clicking here:

Managing Wireless Networks in Windows 8

Many of us take our laptops all over the place, and it is not uncommon for us to connect to several wireless networks on an ongoing basis.  In Windows 7 there was a simple way to manage the wireless networks that you connect to, but it seems to be missing from Windows 8.  This doesn’t mean that you can’t manage your networks, but it has to be done in different ways.

There is a third-party tool that seems to makes this task easy.  The WiFi Profile Manager 8 (developed by Lee Whittington for The Windows Club) lets you view preferred networks, change the order, export and import the list to XML, and remove wireless profiles.  If you are familiar with the old tool from Windows 7 then you will not have any trouble using this tool.  It can be downloaded from TWC by clicking here.

If you are wary of third-party tools and are pretty handy with the command line, then you can manage your wireless networks from the command line.

(To open a Command Prompt either type cmd from the Start Menu, or from the desktop press Win-R and then type cmd)

List all stored wireless profiles: netsh wlan show profiles |more

Show the profile information (profile, connectivity, security, and cost settings): netsh wlan show profiles name=<profile name> key=clear

Delete a profile: netsh wlan delete profile name=<profile name>

The netsh command is not new, and any IT Pro with some command line experience will recognize it.  Of course the GUI has made us lazy… you probably already knew about this, and just needed to be reminded of it.  As for me… let’s just say that Bing is my friend too Smile