What’s New in Windows Server 2012 Networking? (Part 8)

If you would like to read the other parts in this article series please go to:


It’s been a long journey, but we’re finally at the end of this octet of articles on the new features and functionalities in Windows Server 2012 networking technologies. In Parts 1 through 7, we covered more than a dozen important changes, improvements and additions. In this, Part 8 of the series, we’ll discuss Windows Server 2012’s implementation of the Windows Firewall with Advanced Security and what’s new and improved on that front.

Here’s our list again, showing the items we’ve already addressed in past articles, and the one we’ll look at in this article:

Past articles:

  • 802.1x Authenticated Wired and Wireless Access
  • BranchCache
  • Data Center Bridging (DCB)
  • Domain Name System (DNS)
  • DHCP
  • Hyper-V network virtualization
  • IP Address Management (IPAM)
  • Low Latency Workloads technologies
  • Network Load Balancing
  • Network Policy and Access Services
  • NIC Teaming
  • Windows QoS
  • DirectAccess and Unified RRAS

This article:

  • Windows Firewall with Advanced Security

There are only a few additions to the Windows Firewall with Advanced Security in Windows Server 2012, but they’re important ones. Let’s wrap this up!

Overview: The evolution of the Windows Firewall

Once upon a time, most networks relied primarily on perimeter-based firewalls to protect the network’s servers, and many IT pros considered a host-based firewall to be something that was designed to protect the desktop or laptop machines of home users or others whose computers lived outside the “walled cities” of the corporate LAN. However, the approach to network security has gradually changed over the years.

A move toward a layered security model (popularly referred to as “defense in depth”) was the initial impetus that started to change attitudes toward the host-based firewall. In a layered security approach, you start by protecting the perimeter but you don’t stop there. You assume that those edge defenses could fail, so you place additional controls inside the perimeter, creating smaller concentric circles of protection as you move inward, to protect individual parts of the network and individual machines.

Today, we’re deep into the era of “networks without borders,” a new security paradigm I’ve written about on several occasions. The edge has been declared dead, and although most organizations still place firewalls there, the focus is no longer there. Now it’s all about bringing the most concentrated protective mechanisms inward to the host machine or even to the data itself. That means host-based firewalls take on a new and more important role.

Like most of us (celebrity offspring and the progeny of royalty excluded), the Windows Firewall began its life in relative obscurity. Microsoft has been including a built-in firewall on its server operating systems since the advent of Windows Server 2003; it was first called the Internet Connection Firewall (ICF) and was also part of Windows XP, but was not originally enabled by default. At the time ICF appeared, it was looked upon as a solution for home and small business users only. Most companies that had deployed a perimeter firewall turned WF off. Microsoft’s own TechNet documentation took this either/or approach, comparing the features of the two and stating that ICF was appropriate only for businesses with fewer than five users.

Service Pack 2 added functionalities, changed the name to Windows Firewall and turned it on by default in Windows XP. However, because many web sites had compatibility problems with the firewall, IT pros often turned it off, and still considered it an unnecessary appendage on Windows Server. And because it was, in those days, a very rudimentary firewall, it wasn’t used much on either server or client; there were many third party host firewalls that were more sophisticated and effective.

However, Microsoft kept adding improvements to Windows Firewall, and with Windows Vista and Windows Server 2008, they upped the ante with the ability to go beyond the basic firewall configurations that were available through the Control Panel interface and set more complex options through a Microsoft Management Console snap-in called “Windows Firewall with Advanced Security” (which we now shorten to WFAS). One of the most welcome changes was the addition of outbound packet filtering, allowing the option to block specified types of outgoing traffic in addition to that coming in. Other improvements included the ability to create rules using source and destination IP addresses and ranges of port numbers, along with the integration of IPsec. This makes WFAS a useful tool for implementing a server isolation plan.

New features and functionalities

Windows Server 2012 brings three basic improvements to Windows Firewall with Advanced Security. This includes the ability to better control apps from the Windows Store (Windows 8 apps), support for IPsec end-to-end transport mode connections utilizing IKEv2, and new PowerShell cmdlets for configuring and managing WFAS.

WFAS and Windows Store Apps

The firewall service for WFAS integrates much more than the firewall itself. In fact, many Windows 8 users discovered, to their surprise, that they were unable to install apps from the Windows Store if the firewall service was not running. In that case, when you attempt to install apps, you encounter an error message that says:

The app could not be installed, because the firewall service is not running. Please enable the Windows Firewall service and try again.

If you don’t want to use WFAS (because, for example, you have a third party host-based firewall installed), you should leave the firewall service enabled and set to run automatically, and go into the firewall’s settings and set its profiles (domain, public and private) to “off.” If you do use WFAS, you can use it to isolate Windows Store apps and limit their access, so that they will only be able to access those networks to which they have been given explicit permission. You do this by creating firewall rules for the Store apps and their capabilities.

Developers of Store apps are able to configure the apps with access limited to specific types of networks. When they do this, the firewall rules are created automatically when you install the apps. You, as an administrator, can create additional rules for more control over the apps. The computers need to be joined to a Windows domain and you must define your network before creating the custom firewall rules. To define your network, you configure a Group Policy Object that defines the address space.

You can create a firewall policy in Windows Server 2012 that applies to a specific Windows Store app, or to all Windows Store apps that use a specific app capability (for example, the capability to access the Internet connection, or to access the Pictures library, or to detect/use the current location, etc.). You create a custom rule in the GPO (via the Group Policy Management editor), and apply it to the application packages. This ability to apply rules to application packages only is what allows you to create rules that only affect Windows Store apps and not other programs and services.

For detailed step-by-step instructions on how to define your network and create your rules, see Isolating Windows Store Apps on your Network on the TechNet web site.

IKEv2 and IPsec transport mode

Windows Server 2012 increases the support for the Internet Key Exchange v2 protocol, making IKEv2 available as a VPN tunneling protocol with automatic VPN reconnection. The security associations stay the same even when the underlying connection is changed. This enhanced support for IKEv2 has many benefits, including better interoperability with non-Windows operating systems that are using IKEv2.

You’ll need to have a Public Key Infrastructure (PKI), because certificates are used for authentication. The procedure for configuring IKEv2 to secure end-to-end IPsec connections depends on whether or not the computers are joined to a domain. If so, you’ll create a security group and GPO that’s linked to the domain, set permissions and the certificate to be used for authentication, and create an IKEv2 security rule. If not, you’ll create a local IPsec policy on each of the computers that are to be included in the secure connection.

Either way, you have to use PowerShell to configure IKEv2; there’s no way to do it through the graphical user interface. For step-by-step instructions on the procedure, both for domain-joined and non-domain computers, see Securing End-to-End IPsec Connections by Using IKEv2 in Windows Server 2012 on the TechNet web site.

PowerShell cmdlets

By now, most IT pros have gotten the memo: PowerShell is Microsoft’s vision for the future of Windows server administration. WFAS is no exception; you can use PowerShell to configure and manage the firewall and IPsec, and some configurations can be done no other way (such as the IKEv2 configuration discussed above). A big advantage of PowerShell is that it makes it easy to automate many of the processes, and Microsoft doesn’t leave you on your own at the PowerShell command prompt. They have provided documentation in the form of the Windows Firewall with Advanced Security Administration with Windows PowerShell Guide on the TechNet web site. This Guide includes scriptlets you can run on PowerShell 3.0 in Windows Server 2012. You’ll need to install the optional Windows PowerShell ISE through Server Manager if you haven’t already.

PowerShell cmdlets and scripts can be used to control firewall behavior, create (and change and delete) firewall rules and IPsec rules, achieve domain and server isolation with IPsec and can be managed remotely with –CimSession. The Guide contains detailed information on how to do all of these tasks.


Eight articles later, we are finally at the end of this look at what’s new in Windows Server 2012 just in relation to the operating system’s networking features and functionalities. I hope this has provided a good overview that can get you pointed in the right direction for taking advantage of these new capabilities. Thanks for reading! – Deb

If you would like to read the other parts in this article series please go to:


About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top