As development on the version of Windows Server due out in 2016 continues, it's time to consider networking changes....
The new version lacks NAP support, adds new support for GRE tunneling between virtual networks and gateways and changes DNS Client behavior.
You are too old for a NAP
As early as 2004, some of us saw network access protection as a networking panacea. We could quarantine suspicious devices until we were able to satisfy our own criteria that such devices were up to date with the latest patches, scanned for and free of malware, and generally were considered to be good citizens before we unleashed them on our network with full privileges. We could designate certain areas of the network and certain servers as remediation servers where antivirus protection and patches could be downloaded. And if a vendor ever brought a crap filled laptop onto the network during a 30 minute presentation before they vanished into thin air, we did not have to spend three days cleaning up the mess. (Some of you may even replace "vendor" with "remote employee.")
For whatever reason, though, NAP never really hit its stride. This could be for a number of reasons:
- There was no unified industry standard, so Juniper implemented one way, Cisco implemented another, among others, and making them all work together was possible but time and skill intensive.
- There were multiple ways to skin the cat such that you could prohibit DHCP assignments, perform port blocking on a switch, use custom access control lists, and so on.
- There was user rebellion. At the end of the day, when your remote users came into the office, they did not want to spend four hours patching their machines "which worked just fine when they were at home." So edicts were issued, policies relaxed and NAP died before it ever lived.
Alas, the industry has moved away from network access quarantine and protection and so has Microsoft in response. Support for NAP is deprecated in Windows Server and is extremely unlikely to be further developed.
With the consolidation of many virtual machines on one host and the proliferation of cloud services that let you run virtual machines on your own premises and data centers as well as in the public cloud, and move them back and forth, there has needed to be improved support for tunneling over the public Internet. While VPNs are generally useful on the data layer, to rework some of the plumbing in multitenant installations of Windows Server, especially in high density configurations, required work lower down the stack.
Generic Routing Encapsulation, or GRE, is the protocol of choice in Windows Server for wrapping up a bunch of different protocols that operate on the network layer of the OSI stack and shuttling them across the Internet between cloud data centers and your data centers. With GRE, Windows can now send network layer traffic between virtual networks on a hypervisor and external networks, including the Internet. GRE is almost universally understood by routers and switches so they will not require much, if any, reconfiguration, and GRE is so lightweight that it will work well even over the Internet from one virtual network in one location to another virtual network in a very geographically different location.
DNS updates for servers with multiple NICs
Many servers these days ship with multiple network cards, either as something like a quad port network interface device built into the server's motherboard, or with a single or dual port card built into the motherboard and a separately installed single interface card on the PCI bus (many custom Dell servers ship in this configuration). Assuming that all of these different network interface cards are connected to the network simultaneously, and all have slightly different DNS server configurations that they received either via an assignment over DHCP or statically, this can make for some weird name resolution issues when the DNS Client service cannot figure out which DNS server to use to issue a name resolution query. In the next version of Windows Server, when any given DNS server configured on any given NIC is used to resolve a DNS query, the DNS Client service will bind to that NIC -- this gets rid of a lot of vagaries, especially on servers hosting tons of virtual machines with lots of network traffic -- and should clear up some issues that cropped up from time to time but that were really hairy to troubleshoot and repair.
Additionally, the DNS Client will not perform this binding if you are using Group Policy to deploy a Name Resolution Policy Table, or NRPT -- this is generally applicable only to large enterprises and is not configured by default, so if you have not configured this setting, this does not apply.
Read a preview of Windows Server
Read the top 5 Windows Server news stories of the year here
3 common Windows Server security flaws and how to fix them