Things Network Engineers need in their Arsenal

Things Network Engineers need in their Arsenal

 On 25 Jun, 2015

 

Bear Necessities

First and most obvious of the must have items is a console cable however lets think about this for one second. The typical blue console cable you get packed with Cisco gear fresh from the factor (Yellow now) is only about 3 ft long and can often times put you in a crunch especially when you have to work in a cold isle or hot isle of a data center. I learned my lesson early on that it is best to have a Cisco DB9 Female to RJ45 Jack Console Adapter and thus make your own console cable (mine is pink) so that you can make it up to 30ft long. The console cable you’ll need to make for this terminal adapter is just a rollover.

Why is mine pink? Because no other manly network engineer is manly enough to steal it lol and I can always identify which cable is mine. Seriously who uses pink cat5/6 in a data center any ways?

Next obvious choice would also be a Cisco DB25 to RJ45 Jack Adapter adapter for old legacy hardware. While legacy hardware is slowly going away I still encounter it from time to time and not having one of these can easily kill your change window as finding one in a data center is damn near impossible.

The obvious requirement for more newer laptops is a Plug and Play USB to Serial DB9 Adapter as newer laptops do not have serial ports on them anymore. You’ll want to get a Plug-n-Play version as fumbling around for the drivers can often times cause you time and in some situations you do not have internet access until you setup the router and you cannot setup the router until you can console into it… I’ve had this happen a few times sadly.

When it comes to needing an additional Ethernet port doing stuff like recovering Lightweight Access Points, the USB 2.0 Plug and Play Ethernet Adapter – TU2-ET100 can become a life saver. Again try to stick with plug and play if possible so if someone ask to use it, they don’t need the drivers.

Also an IDEAL RJ45/RJ12 Crimp Tool is a must have when it comes to fixing cables with broken RJ45 ends as well as the random need to make basic telephone cables (if you’re also involved in voice). It’s good practice to keep at least several RJ45 and RJ11/RJ12 ends in your bag at all times.

Nice things to have

Okay so enough with the must haves… Lets take a look at the cool stuff that is nice to have that people see and think “man i wish i had one of those…”

One of the things I have in my bad is a Bushnell 65-Lumen Multi-Color LED Hat Light. I have this attached to a “Network Junkie” baseball cap that I can easily put on when needed and have light wherever I aim it with my head and still have my hands free to do whatever. This of course is a hunting LED light however it is nice because it just takes a single AAA battery. Keep a few spare in the bag for this and that wireless mouse 

Everyone has screw drivers in their bag however it’s nice to safe a little space with a Stanley All-in-One Screwdriver. This is exactly the screw driver I carry in my bag. Simple and fits most large and small Cisco screws 

There are however other specialty tools that may be needed from time to time but carry these at your own discretion.

One of the tools that I’ve recently encountered which was included with the purchase of a Nexus blade was an SFP Removal tool which can be used in hard to get spots such as SFP’s near the eject levers of blades. I cannot find this guy for sale anywhere on the internet but if I do I’ll update this blog with a link.

If you find yourself making alot of CAT5/6 Cables than a Linkmaster UTP/STP Cable Tester can save you some time and frustration. I personally have this in my bag as well.

If you deal with cabling alot and have to trace out random cables with no labels than a Fluke Networks Pro3000 Tone Generator and Probe Kit is a handy tool to have in your bag.

There are several common FRU items that are very nice to have on hand so that if you were on call and dispatched to a site, having these in your bag can be a huge time saver. These items includes SFP’s such as GLT-T, GLC-SX-MMD and GLC-LH-SMD. These guys can commonly be obtained through your network department. It is a good idea to carry a pair of each of these guys if possible. I have a small box which has a pair of each of them in my bag. 10Gig optics are becoming more and more common, if you can have those in your bag as spares, those too can be extremely nice to have on hand when your in a bind.

When it comes to keeping spare optical SFP’s it is also nice to keep a few spare fiber patch cables in your bag. The type needed would depend on your working environment however LC-LC, LC-SC are common in most newer environments. Single-Mode (Yellow) and Multi-Mode OM4 (Aqua).

One thing that I’ve noticed that is becoming more and more popular are WiFi hotspots provided by your cell phone provider. These of course can be prepaid however they typically have a monthly reoccurring cost which can provide you internet access if you’re in a 3G/4G area. Keep in mind these guys typically do not work inside metal buildings or basements.

Items that Most Engineers Don’t Think Of…

So there are a few items that engineers typically never think of keeping in their bag but after years of experience I’ve made a nice little list to share with you guys.

First up is the Fluke 1AC-A1-II VoltAlert Non-Contact Voltage Tester

Why is this nice to have? Well lets say you want to check to see if a power line is live without plugging something in, you have the ability to just turn this little stick on and place it next to the power cable and if it lights up than it means the circuit is live.

This little guy can also be used during emergency situations such as all devices in the rack on a specific PDU has failed. The PDU appears to be dead however how do you determine if the problem is the PDU or if its the breaker “quickly” without calling an electrician? Just get this out and wave it next to the incoming power cable. If it lights up than the PDU is dead, if it does not than check the breaker.

Next up is the IEC C14 to NEMA 5-15R – 1 feet cable which allows for you to plug your laptop into a C13 receptacle which is found on most common PDU’s. Keep in mind most Data Center PDU’s are typically 220v so make sure your laptop power adapter can handle 100v-240v. Best way to tell is to check the label on the adapter, if it does not support up to 220v and you try to do this than it may catch on fire due to lack of insulation around the transformer in the power adapter. Be warned about this!

Have you ever dropped your last screw in a place where you cannot get your hands into? The Telescoping Magnetic Pick-Up Tool has prevented a lot of frustration and cursing for me.

Ironically most people do not have a Deluxe Cage Nut Insertion/Extraction Tool in their bag, they typically resort to using a flat head screw driver which can lead to some nasty cuts on your fingers and hands. Sadly I worked with a guy who had an accident and needed 9 stitches in a finger because he used a screw driver and slipped.

Dial up has long since faded into the distant past however I have encountered several companies in the past few years that use dial up out of band management to administer devices in remote places where broadband is unavailable. There is also a huge cost savings factor at play if only SSH is needed. I’ve noticed that this type of deployment is somewhat popular in Mexico as well as the great planes states such as Montana, Wyoming, Kansas, etc… So with that in mind, most new laptops do not have 56k modems anymore and you may find yourself needing a USRobotics USR5637 56K USB Modem

Last item on the list that most engineers forget to have is a beer… After a hard days work it’s nice to come home and sit by the pool and have an ice cold beer and relax and decompress......lol

Interacting with TCP/IP Through PowerShell (Part 4)

In my previous article, I showed you a somewhat cumbersome method for retrieving basic IP address information through PowerShell. Now that you know how to view the IP address configuration, I want to continue the discussion by showing you how to actually provision an IP address using PowerShell.

Before I get started, let me just reassure you that the technique that I am going to talk about in this article is easier than the one that I covered in my previous article. In the last article, I delved into some somewhat advanced techniques and I realize that some might have been put off by how much work was required to do something as simple as retrieving an IP address.

For the sake of demonstration, I have set up a Windows 8.1 machine and it is currently using a dynamically assigned IP address. If you look at Figure A, you can see that this virtual machine is currently using the address 147.100.100.222. The default gateway and the DNS server are both set to 147.100.100.100. You can also see that I retrieved this information by using the Get-NetIPConfiguration cmdlet.

Figure A: Right now this VM is using a dynamically assigned IP address.

As I am sure you already know, a computer (physical or virtual) can contain multiple network adapters. I mention this because the IP address is bound to a specific network adapter. In the interest of keeping things simple, my virtual machine only has a single virtual network adapter. Even so, we have to identify the network adapter (or virtual network adapter in this case) before we can assign an IP address to it.

The easiest way to identify a network adapter through PowerShell is by entering the Get-NetAdapter cmdlet. If you look at Figure B, you can see that my virtual machine has a single network adapter and it is named (conveniently enough) Ethernet. The virtual network adapter’s description is Microsoft Hyper-V Virtual Network Adapter.

Figure B: The virtual machine contains a single virtual network adapter named Ethernet.

We are going to have to reference this network adapter a couple of times as we configure the machine’s IP address. The easiest way to do this is to link the network adapter to a variable that will represent the network adapter. Fortunately, PowerShell makes it really easy to declare a variable. You just have to choose a name for the variable. Once you have picked out the variable name, specify a dollar sign before the name and an equal sign after the name. For instance, if I wanted to use a variable named adapter I could assign it to the network adapter by using the following command:

$adapter = Get-NetAdapter -Name Ethernet

It is worth noting that the dollar sign becomes a part of the variable’s name. From here on out, the variable $adapter will represent our network adapter.

Now that we have linked a variable to our network adapter, we are almost ready to assign an IP address. Before we can do that though, there are a few pieces of information that we will need. Specifically, we will need to choose the new IP address, the prefix length, and the default gateway.

I am assuming that if you are reading this then you are familiar with the concept of an IP address and a default gateway, but I realize that the concept of a prefix length might seem foreign to some. The prefix length essentially takes the place of the subnet mask. Rather than specifying the subnet mask, we are going to specify the number of bits that will make up the IP address prefix.

So for the sake of demonstration, I am going to set the virtual machine’s IP address to 10.1.0.1. I will use 10.1.0.10 as the default gateway, and I will set the prefix length to 24.

We can assign their new values to the network adapter by using the New-NetIPAddress cmdlet. The cmdlet requires us to specify an interface alias. The interface alias is really just the name of our network adapter, as we are using a variable for that. We will also have to specify the IP address, the prefix length, and the default gateway. The other piece of information that we have to supply is the IP address family. Since we are working with IPv4 addresses, the address family is IPv4. The actual command looks like this:

New-NetIPAddress -InterfaceAlias $adapter.Name -AddressFamily IPv4 -IPAddress 10.1.0.1 -PrefixLength 24 -DefaultGateway 10.1.0.10

There is a chance that when you run this command, you will receive an error message like the one that is shown in Figure C. As you can see in the figure, PowerShell is giving us an Access Denied message.

Figure C: You may receive an Access Denied error.

The reason for this error is that you will only be able to use PowerShell to change the IP address if you are using an elevated PowerShell session. To open an elevated PowerShell session, move your mouse pointer to the upper right portion of the screen (in Windows 8) and click on the Search charm. Enter PowerShell into the search box. When the search results are displayed, right click on the listing for PowerShell and choose the Run As Administrator option from the shortcut menu.

If you do forget to run PowerShell as an administrator and then have to go back and open an elevated window, you will have to re-declare the $adapter variable. Variables are session specific and do not carry over between PowerShell sessions. You can see what the command looks like when run in Figure D.

Figure D: We have changed the IP address from PowerShell.

We are almost done, but we have not yet made a DNS server assignment. To do so, enter the following command:

Set-DnsClientServerAddress -InterfaceAlias $adapter.Name -ServerAddresses 10.1.0.3

In this case, the ServerAddress parameter is used to specify the address of our DNS server. You can see what this looks like in action in Figure E. As you can see in the figure, I have used the Get-NetIPConfiguration cmdlet to verify the DNS server assignment.

Figure E: We are assigning a DNS server.

Given the length of some of the PowerShell commands that we have used, it is easy to make a typo. If you make a mistake, the command won’t usually work. Worse yet, the New-NetIPConfiguration cmdlet tends to return some really cryptic error messages. Fortunately, there are a couple of things that you can do when things go wrong.

First, try typing the name of the variable. You saw me do that in Figure D. Entering the variable name by itself allows you to confirm that the variable contains good data.

The other thing that you can do is to use the Get-NetIPConfiguration cmdlet to test the information that you are trying to enter into the New-NetIPConfiguration cmdlet. Both cmdlets use the same parameters. As such, you might type something like:

Get-NetIPConfiguration -InterfaceAlias $adapter.Name -AddressFamily IPv4

This will return the current IP address for the specified network adapter and will allow you to verify that a portion of the information that you are entering is correct.

Interacting with TCP/IP Through PowerShell PART 3

In the previous article in this series, I explained that although the Get-NetIPAddress cmdlet is able to retrieve IPv4 addresses, it is not capable of retrieving other basic IP address configuration information such as the default gateway address or the DNS server address. In order to do that we need to use some different cmdlets.

At the end of my last article, I incorrectly stated that you must use WMI in order to retrieve IP address configuration information. Certainly you can use WMI, and I will show you how to do so. However, it is possible to retrieve IP address configuration information using a normal PowerShell cmdlet. You just can’t do it using the Get-NetIPAddress cmdlet. Instead, you will have to use the Get-NetIPConfiguration cmdlet. As you can see in Figure A, this cmdlet returns the interface alias, the interface index, the interface description, the net profile name (which is usually the domain name), the IP address, the default gateway, and the DNS server. Furthermore, this cmdlet is able to return IPv4 and / or IPv6 information.

Figure A: You can retrieve IP address configuration information using the Get-NetIPConfiguration cmdlet.

On the surface, the screen capture shown above looks really simple and straightforward, but there is more going on here than meets the eye.

To show you what I mean, think back to my previous article when I discussed the Get-NetIPAddress cmdlet. As you will recall, you can use the Get-NetIPAddress cmdlet by itself and PowerShell will provide you with some basic information related to IP address usage. However, there are some attributes that are hidden by default. If you want to see the full list of attributes, you will have to enter Get-NetIPAddress | Select-Object *

So what does all of this have to do with the screen capture shown above? Well, the Get-NetIP Configuration cmdlet works the same way. Well, sort of. Like most PowerShell cmdlets that are based around the Get verb, the Get-NetIPConfiguration cmdlet displays some basic information, but there are some hidden attributes. As was the case with the Get-NetIPAddress command, you can see all of these attributes by appending the pipe symbol (|) and Select-Object *

In all honesty, the full attribute set doesn’t contain much more information than what is shown above. Even so, there are some really interesting things going on with the result set.

To show you what I mean, take a look at Figure B. I start out by entering the Get-NetIPConfiguration cmdlet without any supplementary cmdlets. As you look at the cmdlet’s results, pay attention to the default gateway and the DNS server. Both are IPv4 addresses. Now, take a look at the default gateway and the DNS server addresses when I append the Select-Object cmdlet. Both are blocks of text rather than addresses. So what’s going on here?

Figure B: The Get-NetIPConfiguration cmdlet does not always return the results that you might expect.

To show you what is happening, we will need to focus on a single attribute. Let’s use the IPv4DefaultGateway. Suppose that we enter the following command:

Get-NetIPConfiguration | Select-Object IPv4DefaultGateway

PowerShell returns the following results (at least on my server):

{MSFT_NetRoute (InstanceID = “:8:8:8:9:55?055;7AB;::8;::8;::55;”)}

Obviously the text above looks nothing like an IPv4 address. Even so, forget about what the line above says for a moment. The first clue that something different is going on is that the result is enclosed in braces {}. If you look back at the screen capture above, you will notice that when I entered the Get-NetIPConfiguration cmdlet by itself, none of the results were enclosed in braces. Instead, the results consisted solely of a text string. So why are we seeing braces now? Let’s dig into this a little bit deeper.

To solve the mystery of why we are seeing coded text enclosed in braces, let’s put the Get-Member cmdlet to work. We will do this by entering the following command:

Get-NetIPConfiguration | Get-Member –Name IPv4DefaultGateway

You can see the results of this command in Figure C.

Figure C: This is what happens when we use the Get-Member cmdlet.

As you can see in the figure above, the definition for the IPv4DefaultGateway is listed as ciminstance[]. In other words, the property is based on a CIM Instance.

CIM stands for Common Interface Model. It is based on a standard for describing the structure and behavior of managed resources. When we enter the Get-NetIPConfiguration cmdlet by itself, the cmdlet is smart enough to interpret the CIM data and gives us the information that we want. When we start looking at individual properties such as the IPv4DefaultGateway however, PowerShell shows us the raw CIM data.

OK, that’s great, but what do we do if we need to work with a CIM based value? We obviously can’t select the property from the Get-NetIPConfiguration command.

The solution to this problem is to delve into CIM. It’s actually not that complicated to do. Let me show you how it’s done.

The Common Interface Model is divided into classes and each class is related to a specific aspect of the operating system. Therefore, our first task is to figure out which CIM class is responsible for IP address configuration.

One way that you can accomplish this task is to generate a list of the CIM classes and take an educated guess. To see a list of CIM classes, enter the following command:

(Get-CimClass | Sort-Object –Property CimClassName).CimClassName;

You can see a partial list of the results in Figure D.

Figure D: These are the default CIM class names.

I will save you the trouble of guessing the correct CIM class name and tell you that IP configuration information is controlled by a CIM class named Win32_NetworkAdapterConfiguration.

The next thing that we need to do is to figure out what property names are used within the Win32_NetworkAdapterConfiguration class. To do so, we simply have to look at the Name property for each object in the class. This can be accomplished by using the following commands:

$NetworkAdapterConfigurationClass = Get-CimClass -ClassName Win32_NetworkAdapterConfiguration;

($NetworkAdapterConfigurationClass.CimClassProperties).Name | Sort-Object;

The first line of code defines a variable called $NetworkAdapterConfigurationClass and associated it with the Win32_NetworkAdapterConfiguration class. The second line of code retrieves all of the property names within the class and displays them in alphabetical order. You can see the results in Figure E.

Figure E: These are the property names used within the NetworkAdapterConfiguration class.

As you look at the figure above, you will notice that there is a property named DefaultIPGateway. If we want to display the default gateway then all we have to do is to retrieve the value of this property. Doing so requires us to use the following two lines of code:

$NetworkAdapterConfigurationList = Get-CimInstance -ClassName Win32_NetworkAdapterConfiguration;

$NetworkAdapterConfigurationList | Select-Object -Property DefaultIPGateway

You can see the output from these commands in Figure F. In this case the output is readable text, but the result is still enclosed in braces. The reason for the braces is that the result is part of an array. Microsoft treats the default gateway as an array of values because it is possible for a system to have multiple default gateways.

Figure F: We are able to retrieve the default gateway.

PART 2 ....Interacting with TCP/IP Through PowerShell

Interacting with TCP/IP Through PowerShell ---PART 2

In my previous article in this series, I showed you how to use PowerShell’s Get-NetIPAddress cmdlet. As you may recall from that article, the cmdlet returned an abundance of information. I narrowed down the results by appending the –AddressFamily IPv4 switch, but the cmdlet still might not have returned exactly the information that would be required by the circumstances of the moment.

So with that said, let’s take a look at how we might further filter the results list. If you look at Figure A, you can see that only two results were returned. We have the machine’s primary address and the machine’s loopback address (127.0.0.1). The cmdlet also shows us quite a bit of information for each result, such as the address type, address state, and policy store. So with that said, let’s look at some ways in which we might fine tune the results.

Figure A: This is the result that we get by entering Get-NetIPAddress –AddressFamily IPv4

Like most PowerShell cmdlets, the Get-NetIPAddress cmdlet is constructed in such a way that we can view the full cmdlet syntax by entering the following command:

Get-Help Get-NetIPAddress

As you can see in Figure B, there are a number of different switches that we can use to filter the results.

Figure B: The Get-NetIPAddress cmdlet includes a number of optional switches.

Of the switches that PowerShell makes available, one of the most useful switches for filtering the result list is the IPAddress switch. We can use this switch to narrow the results down to the adapter that is using a specific IP address. Let’s suppose for a moment that I wanted to view IPv4 information for the machine’s primary IP address. In this particular case, that address is 147.100.100.151 (I do not actually own this address range). To narrow the results to that IP address, I would use the following command:

Get-NetIPAddress –IPAddress 137.100.100.151

You can see the results in Figure C.

Figure C: This is what happens when we filter the cmdlet’s results by IP address.

Obviously this technique is useful for narrowing down our results, but occasionally we may wish to further fine tune the results. Perhaps there is a specific thing that we want to know about the IP address and we would like to hide everything except for the information that we specifically need.

The easiest way to do this is to combine the Get-NetIPAddress cmdlet with the Select-Object cmdlet. As you probably know, PowerShell allows cmdlets to be joined together by using the pipe symbol (|). When the pipe symbol is placed between two cmdlets, the first cmdlet’s output becomes the second cmdlet’s input. That being the case, we can use the Get-NetIPAddress cmdlet to retrieve IP address information and then pipe the results into the Select-Object cmdlet as a way of filtering the results. Let me show you how this works.

Let’s pretend for a moment that like before, we are interested in the IPv4 information for this computer’s primary address. Let’s also pretend that we want to see every bit of information that the Get-NetIPAddress cmdlet can show us for this particular address.

Now I’m sure that some of you are saying to yourselves, “Wait a minute Brien, isn’t that what we just did?” Well, it sort of is. The thing is that most Get cmdlets will display a preconfigured set of information. The information that is displayed by default (like what you see in the figure above) may or may not be all of the available information. In many instances PowerShell is capable of providing a lot more information than what it shows by default.

So if our goal is to display all of the available information for this particular IP address, we could do so by using the following command:

Get-NetIPAddress 147.100.100.151 | Select-Object *

You will notice in the command shown above that I entered an asterisks after the Select-Object cmdlet. This asterisks tells PowerShell that we want to select all objects. In other words, we want to see all of the information that the Get-NetIPAddress cmdlet can show us for this address. You can see what this command looks like in action in Figure D.

Figure D: This is what happens when we select all objects.

As you can see in the figure above, there are a lot more pieces of information available than what PowerShell displays by default. Granted, some of the attributes are blank, but that’s beside the point.

So now that I have shown you the type of information that is available, let’s go back to the question of what we would do if we only wanted to view very specific information. The Select-Object cmdlet allows you to specify the attributes that you want to see. All you have to do is to replace the asterisks with the attribute name. If you want to see multiple attributes then you separate each attribute with a comma.

To show you what I mean, let’s pretend that we wanted to see the IP address and the address type for each IPv4 address used by the system. We could do this by entering this command:

Get-NetIPAddress –AddressFamily IPv4 | Select-Object IPAddress, Type

You can see the command’s results in Figure E.

Figure E: This is what the above command does.

As you can see, it is relatively easy to display information from the Get-NetIPAddress cmdlet. Even so, you might have noticed some things missing. After all, the Get-NetIPAddress cmdlet is supposed to retrieve IP address information and yet there was no information provided about DHCP leases, DNS configurations, subnet masks, default gateway usage, or other basic information related to the IP address.

The reason for this is that contrary to what you might expect, the Get-NetIPAddress cmdlet is not capable of retrieving any information beyond what you saw in Figure D. This isn’t to say that you can’t get this information through PowerShell. It’s just that you can’t get the information by using the Get-NetIPAddress cmdlet.

If you think back to the previous article in this series, you will recall that you can acquire IP address configuration information by using the IPCONFIG /ALL command. Even so, this command isn’t really a PowerShell command and I promised to show you how to retrieve IP address information using only native PowerShell.

In order to retrieve the information that we need, we are going to have to delve into the Windows Management Instrumentation (WMI). By using WMI, we can access information that is not directly exposed through PowerShell. To give you a quick example, suppose that you wanted to check a system’s BIOS. BIOS information isn’t exposed directly through PowerShell, but we can get it by making a WMI call. An example of such a command might be:

Get-WMIObject Win32_Bios

You can see the output of this command in Figure F.

Figure F: I used WMI to retrieve BIOS information.

So why didn’t I just use a WMI call to retrieve IP address information? Unfortunately, things aren’t quite that simple. We are going to need to write a script in order to retrieve the IP address information that we are interested in. I will show you how in Part 3.

Interacting with TCP/IP Through PowerShell (Part 1)

A couple of weeks ago someone asked me if it were possible to access a computer’s TCP/IP configuration information through Windows PowerShell. At the time, I really didn’t put a lot of thought into the answer. My reply was that although the IPCONFIG command was really designed to run in a Windows command prompt environment that it would also work in PowerShell. Later on, I started thinking about the question a little bit more and realized that my answer while true, may have been inadequate (I’m not really sure what the person wanted to accomplish).

The reason why I say this is because IPCONFIG is more of a diagnostic tool than a configuration tool. As such, there are some areas in which IPCONFIG truly excels, but there are a lot of things that IPCONFIG can’t do. So with that said, let me take a little bit of time and show you what IPCONFIG is and is not able to do.

Normally when I use the IPCONFIG command, I use it to get an overview of a computer’s IP address configuration. You can do so by entering IPCONFIG /ALL at the Command Prompt (or at the PowerShell prompt). Upon doing so, Windows will display the IP address information for each network adapter that is installed in the system, as shown in Figure A. If you want to narrow things down a bit then you can specify the name of an individual network adapter and IPCONFIG will show you that adapter’s configuration.

Figure A: IPCONFIG can retrieve a system’s IP address configuration.

Of course acquiring an IP configuration summary isn’t the only thing that the IPCONFIG command can do. As I said before, IPCONFIG is designed to be a diagnostic tool and you can use it to try to fix some common IP configuration problems.

Suppose for a moment that a particular system is having trouble communicating on the network and you suspect a DHCP problem or possibly even an IP address conflict. In that type of situation, you can use IPCONFIG to release the current IP address lease and then acquire a new DHCP lease. You can accomplish this by using the IPCONFIG /RELEASE and IPCONFIG /RENEW commands. Similarly, if you suspect that the DNS resolver cache may contain an invalid entry you can clear the cache by using the IPCONFIG /FLUSHDNS command.

I don’t want to turn this article into a full blown tutorial on the IPCONFIG command, but I did want to spend a little bit of time talking about it for the benefit of anyone who might not have previously used this command. If you want to see the full command syntax, just enter the IPCONFIG /? command, as shown in Figure B.

Figure B: The IPCONFIG command has several command line parameters.

OK, so obviously the IPCONFIG command is useful and it can be used through PowerShell. Even so, what you saw in the previous screen capture is more or less the limit of what IPCONFIG can be used for. So how else can we interact with TCP/IP through Windows PowerShell?

As you would probably expect, PowerShell natively includes really good support for networking. There are PowerShell cmdlets for configuring TCP/IP, network adapters, and even infrastructure components such as IPAM. So with that said, let’s take a look at some of the available TCP/IP related cmdlets.

As you are no doubt aware, native TCP/IP cmdlets are made up of verb-noun combinations. The verbs that are used for configuring TCP/IP through Windows PowerShell are really straightforward. In fact, if you have ever used PowerShell for any purpose in the past you have most likely used most if not all of these verbs. The verbs that are supported for use with TCP/IP include:

• Find
• Get
• New
• Remove
• Set
• Test

The nouns that are used by the native PowerShell cmdlets for TCP/IP are a lot more varied. Even so, there is at least a degree of consistency. All of the TCP/IP related nouns (at least the ones that are being discussed in this article series) start with the word Net. You can see the list of TCP/IP related nouns below. As you look at the list, you will see that at least some of the nouns are relatively intuitive in terms of what they relate to. The list of TCP/IP related nouns includes:

• NetRoute
• NetCompartment
• NetIPAddress
• NetConfiguration
• NetIPInterface
• NetIPv4Protocol
• NetIPv6Protocol
• NetNeighbor
• NetOffloadGlobalSettings
• NetPrefixPolicy
• NetTCPConnection
• NetTCPSetting
• NetTransportFilter
• NetUDPEndpoint
• NetUDPSetting

Now that I have shown you the list of available nouns and verbs, let’s talk about some of the things that you can do through PowerShell. If you think back to the beginning of this article, you will recall that the first thing that I showed you was how to use the IPCONFIG command to retrieve IP address information. That being the case, let’s get started by doing the same thing, but this time we will use native PowerShell cmdlets.

The PowerShell cmdlet that is used for retrieving IP address information is Get-NetIPAddress. As you can see in Figure C, this command returns both IPv4 and IPv6 address configuration information for all of the network adapters in the system.

Figure C: This is what the Get-NetIPAddress cmdlet does.

As you look at the figure above, you will notice a couple of things. First, the Get-NetIPAddress cmdlet returns some really useful information. Second, the volume of information that is returned has the potential to become overwhelming. I made the screen capture on a small lab server, but you can only imagine how much data would be returned if this were a production server with lots of network adapters.

This of course raises the question of how we can begin to filter the output to make it more readable. If you only want the most basic information then you might be able to get away with appending the Format-Table cmdlet. However, the information that is returned by doing so might not be what you need, as shown in Figure D.

Figure D: The Get-NetIPAddress | Format-Table cmdlet returns basic IP address information.

One way that you might be able to shorten the list is by specifying the type of address that you want to examine. For instance, if you are only interested in IPv4 addresses then you could append the –AddressFamily switch to the cmdlet, as shown in Figure E. The actual cmdlet looks like this:

Get-NetIPAddress –AddressFamily IPv4

Figure E: You can filter the results by address type.

Obviously the volume of data that has been returned by this cmdlet is a lot more manageable. Even so, there is no denying the fact that this is a lab server with a single network adapter (actually it has three network adapters that are bonded to act as a single network adapter). You can only imagine if this server had more adapters. Fortunately, there are other tricks that you can use to extract exactly the information that you need while also cutting through the clutter.

Patch Management: More Important than Ever (Part 2)

In this, Part 2, we’ll go a little more deeply into patch testing and the many patch deployment options that are currently available, including both on-premises and cloud-based solutions for automating the patch management process.

If you would like to read the first part in this article series please go to Patch Management: More Important than Ever (Part 1).

Introduction

In Part 1 of this series, we looked at both the history and the current state of the security patching landscape, and began discussing your options for meeting the increasing challenge of managing the patching process in today's

Best Patch Testing Practices

Patch testing should be a routine process that follows a prescribed pattern, not a haphazard task. Your team should lay out written procedures for testing and it should be done in a test lab that is as similar as possible to the configuration of your production network.

Some organizations completely isolate the test network from the production network. Others use a small group of production machines on which to test the patches. The sophistication of the testing environment that you’re able to construct may, of course, be subject to time, personnel and budgetary constraints. Virtualization can help to cut the costs of setting up a test environment; this will allow you to use one physical machine to duplicate many of your production machines.

Before the updates are applied to the test lab machines, though, the integrity of the patches should be checked to ensure that they are valid updates from the vendor and haven’t been deliberately or unintentionally modified. This is the patch validation process and can be done by verifying digital signatures or checksums.

Thorough testing involves applying the patches and rebooting the machines – whether or not a reboot is deemed necessary for the changes to take place. This is done to ensure that the operating system’s boot process hasn’t been affected by the patch. It’s no fun to apply a patch and think all is well, and then get a nasty surprise days or weeks later the next time the system restarts.

A normal reboot doesn’t necessarily mean you’re home free, however. The infamous “blue screen of death” is the most severe but by no means the only impact that a bad patch can have. You should have a set of test scripts that will help you determine whether the operating system and your applications continue to operate correctly after the patch application. A security patch can affect many different parts of the system so you need to test it in different scenarios that mirror the most commonly performed system tasks.

A change management solution should be a part of your test environment, as this will automate the detection and pinpointing of changes that the patch may have made to your systems, such as modification of permissions and access controls. Patches may also disable or enable services, make changes to the registry or changes to system or application code that can cause OS features or application functions to fail completely or to behave abnormally.

If the patches cause no problems in the test environment, then you can prepare to roll them out to production machines. Depending on the severity of the vulnerability, the impact (based on the mission-criticality and sensitivity of your machines) and the likelihood of exploit (based on your machines’ level of exposure and whether there are exploits already in the wild), you may deploy the patches across your entire network at the same time, or you may roll them out in phases.

Doing it in phases can be safer, and can function as an extension of the patch testing process. You would apply the patches to less critical systems first and then evaluate the impact on those machines for any negative consequences before rolling out to your more important servers. If at any point in the testing process, including after part of a phased rollout, you shouldn’t deploy the patches to any additional machines until the problems are resolved.

Because something can always go wrong even after thorough testing, part of the testing process should include ensuring that the patches can be uninstalled and the systems restored to their former state without problems. Be sure that you have a contingency plan if you need to back out of the patch as well as a recovery plan if important systems are affected.

Patch deployment options

The deployment phase is where the patches are installed on the machines on your production network, and today’s IT pros can be thankful that this is no longer the tedious manual task that it was in the early days of computing. There are numerous tools that can be used to automate the deployment process – but therein lies the problem: you have so many options that it can be difficult to decide which approach to take.

Some organizations still use their own custom scripts to apply patches, but an entire industry has grown up around patch deployment and there are now many commercial products that can make the whole process much easier. Some support only a single platform (e.g., Windows) while others can manage the patches for different platforms in a hybrid network environment.

Since Windows Server 2003, Microsoft’s server operating systems have included built-in update management functionality in the form of Windows Server Update Service (WSUS), which was first called Software Update Services (SUS) in the earlier versions. It has expanded its scope from being limited to updates for Windows only to being able to update other Microsoft products such as Office. WSUS is now installed as a server role on Windows Server 2012/2012 R2.

The WSUS server connects to the Microsoft Update Service to get current update information; it downloads the updates and then distributes them to the computers on your network according to your specifications. In a large organization, WSUS servers can function in a hierarchical manner, with an upstream WSUS server distributing the updates to other WSUS servers on the network, which in turn distribute the updates to the local servers and clients.

The big advantage of WSUS is that it comes with Windows Server, so you don’t have to buy additional software. Microsoft’s System Center Configuration Manager can be used for patch management along with asset discovery. SCCM is well integrated with WSUS and Windows Update Agent. The patching process can be automated with, for example, different patching schedules for different departments or other groups within the company and it’s easy to exclude some machines from the patch deployment and also customize restart behavior for different groups of machines.

Whereas WSUS provides good, basic update control for Microsoft software and SCCM gives you more options and flexibility, there are much more sophisticated patch management solutions that are offered by third party vendors, and many of these also integrate with WSUS and/or System Center.

These systems can enable you to more easily manage patching in a centralized way for hybrid networks that have non-Microsoft operating systems running, as well as easier patching of third party application software on Windows. Although you can integrate System Center Updates Publisher (SCUP) with SCCM, it takes a great deal of administrative overhead (read: time and effort) to apply third party application updates, especially when the application vendors don’t provide SCUP-compatible CAB files for their updates. Third party products can also provide you with such extras as real time patch failure reporting and notification and compliance scanning.

There is a plethora of patch management solutions available and it’s beyond the scope of this article to attempt to review or recommend one, since the best solution for you depends on your organization’s specific needs and your network’s configuration. Some of the best available products include GFI’s LanGuard, Lumension Patch & Remediation, SolarWindows Patch Manager and Secunia CSI (Corporate Software Inspector).

In selecting the best patch management solution for your organization, you’ll want to think about such issues as whether to deploy all patches from a centralized location or have multiple update servers located at different places on your network to serve particular groups or departments. This will depend on how large your organization is and how it’s structured. In either case, a good patch management solution will be able to validate the patches.

Another consideration is whether to use a patch management solution that uses client agents or one that is agentless. There are advantages and disadvantages either way. The agent-based systems require that you install software on each of the clients, but they work better for updating machines that are in a DMZ and they can use less bandwidth and spread the processing load between client and server. Agentless solutions can discover computers that are new to the network without installing agents on those clients and reduce the administrative overhead of installing agents. You can combine the two solutions, as well.

An important criteria for selecting a patch management system is to be sure that it can evaluate whether the patches themselves have been updated or revoked or replaced. It should also be able to take into account whether patches need to be applied in a specific order. Finally, it should have good reporting capabilities. This is even more important if your organization is part of a regulated industry that falls under compliance mandates, since you will have to be able to document that your machines have all the correct security updates applied.

Summary

Patch management isn’t something that most IT pros get excited about, but it’s a good idea to reassess your patching strategy and tools every now and then, to ensure that your updating process is as efficient as possible and to save yourself unnecessary work. There are many options available today for automating the tasks involved in keeping your systems updated and secure, so go out there and check them out.

If you would like to read the first part in this article series please go to Patch Management: More Important than Ever (Part 1).