Tag Archives: configuration

Selecting network configuration software for automation

Ivan Pepelnjak, blogging in IP Space, explored what network configuration software is best for automation. Ansible, Chef and Puppet are commonly cited network configuration software options, with Salt becoming increasingly commonplace and CFEngine used occasionally. According to Pepelnjak, most network engineers prefer Ansible. Chef and Puppet focus mainly on configuration and state management and don’t make changes unless necessary and tend to manage dependencies — such as creating groups and then accounts within a group.

In Pepelnjak’s view, managing configuration and soft state services is a good goal but doesn’t go far enough. Among network configuration software, Ansible is unique, aiding in device provisioning, validating network topologies, upgrading software, helping with compliance and generating reports. Engineers can often get started more quickly with Ansible, learning the basics in a matter of hours. “Maybe it’s just our mentality, or maybe we have to do things a bit different because of the huge blast radius of our mistakes. In any case, Ansible (which is just a generic automation/orchestration framework) fits better to our way of doing things,” he said.

Read more of Pepelnjak’s thoughts on network configuration software.

New developments in endpoint detection and response

Jon Oltsik, an analyst at Enterprise Strategy Group in Milford, Mass., reflected on a 2016 project where he interviewed 30 enterprises about endpoint security strategies. At the time, Oltsik came up with a concept he termed a continuum of endpoint tools, with advanced threat detection at one end and endpoint detection and response (EDR) on the other end.

Based on the interviews, Oltsik and his colleague guessed that 75% to 80% of the market would steer toward advanced protection, while the remainder would pursue EDR. He also predicted that vendors would work to bridge the gap with combined offerings.

Now, in 2018, Oltsik said that the hypothesis has mostly played out. ESG research indicates that 87% of organizations are planning to buy comprehensive endpoint security suites and 28% of cybersecurity professionals identified EDR as the most attractive feature of the offerings. He projected that EDR will now undergo additional market segmentation. Traditional EDR, anchored by on-premises infrastructure, will continue as a niche market for high-security industries. A lighter, “trigger-based” version of EDR — one that collects data when a behavioral anomaly occurs — will appeal to purchasers in the midmarket, he said.

Managed EDR may also appear, with subsegments, catering to companies that want full EDR capabilities but lack personnel to oversee it. “Rather than default to a product, security managers really need to assess their needs, resources, and skills before making an EDR decision. There will be a lot of options to choose from, so CISOs must choose wisely,” Oltsik said.

Dig deeper into Oltsik’s predictions about EDR.

Streamlining with SD-WAN and network functions virtualization

Mike Fratto, an analyst at GlobalData in Sterling, Va., said he’s heard commentary about stand-alone SD-WAN disappearing, instead becoming just another feature on routers and firewalls. Although he said many vendors will eventually consolidate features like these into a single appliance, he does not see the end of single-function SD-WAN devices.

That’s because enterprise IT teams like bespoke products and many teams like the ability to swap out older stand-alone products for newer offerings as they become available.

Second, the shift to software-defined everything will let enterprises rely more on virtualized instances of SD-WAN. This will permit companies to consolidate network functions into fewer appliances.

Third is the fact that enterprise IT teams are often loath to replace tried and true systems with new options that may not be as capable.

“What enterprises want — what they would pay for but will likely never get — is an environment of deep management integration across multiple vendor products which could ultimately reduce operational overhead, unlock more efficient workflows, and generate significant operational cost savings along with way,” Fratto said. “Here’s where managed service providers have a unique advantage, provided they dedicate the resources to creating a portal that integrates the management functions across vendor products,” he added.

Explore more of Fratto’s ideas on SD-WAN as a stand-alone product.

The Really Simple Guide to Hyper-V Networking

If you’re just getting started with Hyper-V and struggling with the networking configuration, you are not alone. I (and others) have written a great deal of introductory material on the subject, but sometimes, that’s just too much. I’m going to try a different approach. Rather than a thorough deep-dive on the topic that tries to cover all of the concepts and how-to, I’m just going to show you what you’re trying to accomplish. Then, I can just link you to the necessary supporting information so that you can make it into reality.

Getting Started

First things first. If you have a solid handle on layer 2 and layer 3 concepts, that’s helpful. If you have experience networking Windows machines, that’s also helpful. If you come to Hyper-V from a different hypervisor, then that knowledge won’t transfer well. If you apply ESXi networking design patterns to Hyper-V, then you will create a jumbled mess that will never function correctly or perform adequately.

Your Goals for Hyper-V Networking

You have two very basic goals:

  1. Ensure that the management operating system can communicate on the network
  2. Ensure that virtual machines can communicate on the network


Any other goals that you bring to this endeavor are secondary, at best. If you have never done this before, don’t try to jump ahead to routing or anything else until you achieve these two basic goals.

Hyper-V Networking Rules

Understand what you must, can, and cannot do with Hyper-V networking:

What the Final Product Looks Like

It might help to have visualizations of correctly-configured Hyper-V virtual switches. I will only show images with a single physical adapter. You can use a team instead.

Networking for a Single Hyper-V Host, the Old Way

An old technique has survived from the pre-Hyper-V 2012 days. It uses a pair of physical adapters. One belongs to the management operating system. The other hosts a virtual switch that the virtual machines use. I don’t like this solution for a two adapter host. It leaves both the host and the virtual machines with a single point of failure. However, it could be useful if you have more than two adapters and create a team for the virtual machines to use. Either way, this design is perfectly viable whether I like it or not.


Networking for a Single Hyper-V Host, the New Way

With teaming, you can just join all of the physical adapters together and let it host a single virtual switch. Let the management operating system and all of the guests connect through it.


Networking for a Clustered Hyper-V Host

For a stand-alone Hyper-V host, the management operating system only requires one connection to the network. Clustered hosts benefit from multiple connections. Before teaming was directly supported, we used a lot of physical adapters to make that happen. Now we can just use one big team to handle our host and our guest traffic. That looks like this:



VLANs seem to have some special power to trip people up. A few things:

  • The only purpose of a VLAN is to separate layer 2 (Ethernet) traffic.
  • VLANs are not necessary to separate layer 3 (IP) networks. Many network administrators use VLANs to create walls around specific layer 3 networks, though. If that describes your network, you will need to design your Hyper-V hosts to match. If your physical network doesn’t use VLANs, then don’t worry about them on your Hyper-V hosts.
  • Do not create one Hyper-V virtual switch per VLAN the way that you configure ESXi. Every Hyper-V virtual switch automatically supports untagged frames and VLANs 1-4096.
  • Hyper-V does not have a “default” VLAN designation.
  • Configure VLANs directly on virtual adapters, not on the virtual switch.

Other Quick Pointers

I’m going to provide you with some links so you can do some more reading and get some assistance with configuration. However, some quick things to point out:

  • The Hyper-V virtual switch does not have an IP address of its own.
  • You do not manage the Hyper-V virtual switch via an IP or management VLAN. You manage the Hyper-V virtual switch using tools in the management or a remote operating system (Hyper-V Manager, PowerShell, and WMI/CIM).
  • Network connections for storage (iSCSI/SMB): Preferably, network connections for storage will use dedicated, unteamed physical adapters. If you can’t do that, then you can create dedicated virtual NICs in the management operating system
  • Multiple virtual switches: Almost no one will ever need more than one virtual switch on a Hyper-V host. If you have VMware experience, especially do not create virtual switches just for VLANs.
  • The virtual machines’ virtual network adapters connect directly to the virtual switch. You do not need anything in the management operating system to assist them. You don’t need a virtual adapter for the management operating system that has anything to do with the virtual machines.
  • Turn off VMQ for every gigabit physical adapter that will host a virtual switch. If you team them, the logical team NIC will also have a VMQ setting that you need to disable.

For More Information

I only intend for this article to be a quick introduction to show you what you’re trying to accomplish. We have several articles to help you dive into the concepts and the necessary steps for configuration.

Windows PowerShell DSC book trains IT to lock down systems

When a server configuration drifts from its approved baseline, bad things happen.

A seemingly innocuous setting change can trigger a catastrophic domino effect that ripples through the data center. A high availability cluster could crumble, or a disaster recovery configuration could collapse just when it’s needed most. To protect the business — and themselves — the IT department should implement a change management tool, such as Windows PowerShell Desired State Configuration (DSC).

Windows PowerShell DSC is a management extension in PowerShell that gives administrators more control over Windows machines. Introduced with PowerShell 4.0, Windows PowerShell DSC builds on that automation tool with its own cmdlets and language extensions to tighten controls on software deployments and server configurations. Windows PowerShell DSC sets a desired state for a server, which the IT department applies to existing or new machines. Administrators set up Windows PowerShell DSC to use push mode to send configurations to machines, pull mode to have the machines retrieve configurations from the server or a combination of these two modes.

In The DSC Book by Don Jones and Melissa Januszko, the authors explain these nuances and why administrators should use Windows PowerShell DSC for more than simple server deployments. The book, which comes in a Forever Edition format, meaning the authors will continually update and expand it, consists of six parts. After an introduction that details why Windows PowerShell DSC exists, the authors get into advanced territory, such as partial configurations and best practices for resource design. The book also covers common trouble spots and error messages in PowerShell DSC, with possible resolutions.

In this excerpt taken from the book’s introduction, Jones and Januszko describe the difference between Windows PowerShell DSC and the Group Policy management tool:

On the surface, DSC and Group Policy seem to serve the same high-level purpose. Both of them enable you to describe what you want a computer to look like, and both of them work to keep the computer looking like that. But once you dig a little deeper, the two technologies are grossly different.

Group Policy is part and parcel of Active Directory (AD), whereas DSC has no dependency on, or real connection to, AD.

The DSC BookThe DSC Book

by Don Jones and Melissa Januszko

Group Policy makes it easy to target a computer dynamically based on its domain, its location (organizational unit, or OU) within the domain, its physical site location, and more. Group Policy can further customize its application by using Windows Management Instrumentation (WMI) filters and other techniques. DSC, on the other hand, is very static. You decide ahead of time what you want a computer to look like, and there’s very little application-time logic or decision-making. Group Policy predominantly targets the Windows Registry, although Group Policy Preferences (GPP) enables additional configuration elements. Extending Group Policy to cover other things is fairly complex, requires native C++ programming, and involves significant deployment steps. DSC, on the other hand, can cover any configuration element that you can get to using .NET or Windows PowerShell. Extending DSC’s capabilities is a simple matter of writing a PowerShell script, and deploying those extensions is taken care of by DSC’s infrastructure.

Editor’s note: This excerpt is from The DSC Book, authored by Don Jones and Melissa Januszko, published by Leanpub, 2016.

Powered by WPeMatico

Editing a .VMCX file

In Windows Server 2016 we moved from using .XML for our virtual machine configuration files to using a binary format – that we call .VMCX.

There are many benefits to this – but one of the downsides is that it is no longer possible to easily edit a virtual machine configuration file that is not registered with Hyper-V.  Fortunately – we provide all the APIs you need to do this without editing the file directly.

This code sample takes a virtual machine configuration file – that is not registered with Hyper-V.  It then:

  • Loads the virtual machine into memory – without actually importing it into Hyper-V
  • Changes some settings on the virtual machine
  • Exports this changed virtual machine to a new .VMCX file

Using this method you can make any changes you need to a .VMCX file without actually having to import the virtual machine.  The key piece of information here is that when you perform a traditional import of a virtual machine you use ImportSystemDefinition to create a planned virtual machine (in memory copy) which you then realized to complete the import operation.  But if you do not want to import the virtual machine – but just want to edit it – you can modify the planned virtual machine and pass it into ExportSystemDefinition to create a new configuration file.


Powered by WPeMatico