The announcement that NAP was being deprecated wasn’t trumpeted. Most people who knew the technology only found out that it was going away when they studied the features removed or deprecated in R2 in some detail. Even then NAP’s inclusion on this list was a surprise. Most of the other features marked as deprecated or removed were fairly old and often a bit arcane. NAP isn’t really either.
If you’ve taken a Microsoft Official Curriculum course in the last 6 or so years, you’ll have done a module on NAP. You’ll have done labs where you configure NAP with DHCP or NAP with IPsec. Even the most recent Windows Server 2012 R2 courses include modules on NAP. For a technology that’s deprecated, it gets pretty extensive coverage. There’s even chapters on it in my Windows Server 2012 R2 books, simply because the technology is present on the exam objectives and if you’re writing an exam guide, you have to cover the material on the exam objectives rather than the material that you think should be on the exam objectives.
Deprecated doesn’t mean that the role or feature isn’t included. It just means that at some point in the future, maybe Windows Server 2014, maybe Windows Server 2014 R2 (I’m making up those names) NAP won’t be included.
Here are my guesses why NAP was deprecated:
Better ways to solve the problem
NAP helped you deal with computers that didn’t have a healthy configuration. Rather than simply alerting you to the identity of the computer that had the problematic configuration, it quarantined the computer. The hope was that the quarantine was configured in such a way that the computer could remediate its configuration by updating its anti-malware configuration or getting up-to-date with software updates.
Generally speaking, if a computer is in a position to maintain a current software update and anti-malware configuration, it will do so. You don’t need to push the computer onto a remediation network and hope that the process will happen.
In many cases though, computers that weren’t up-to-date with anti-malware definitions or software updates were not up-to-date because something was wrong with those components, not because the processes hadn’t got around to checking for updates. This meant that computers were blocked from the production network and the first thing that anyone in the IT team knew about it was a confused user ringing to ask why they couldn’t access the network.
While it was possible to configure NAP in auditing mode so that unhealthy clients were identified but not blocked from network access, the reporting interface wasn’t great. If there had been a great interface in the NPS console for identifying unhealthy clients, NAP probably wouldn’t be on life support.
You don’t have to look far to find other products that can generate great reports identifying client computers that don’t have up-to-date anti-malware or software update configurations. Why implement NAP when you can generate these reports using Configuration Manager or a 3rd party alternative?
Not widely adopted
When teaching and talking about NAP, even though most people I talked to were generally aware of it, I rarely found anyone that had actually deployed it. NAP never seemed to generate momentum. The general response I got from people when talking about it was “this technology is interesting, but we don’t think it really solves a critical problem for us”. That might be a dirty secret about NAP – that while administrators might concede that in the best of all worlds their client computers will all be up-to-date with software updates and anti-virus definitions, it has never been a critical enough problem for most of them that they’d spend time and money deploying a solution such as NAP.
Not fully compatible with BYOD scenarios
It is no secret that Microsoft has pivoted towards providing support for BYOD scenarios. One of the assumptions around NAP is that the vast majority of client computers will be domain joined computers running a Windows operating system. While NAP clients did exist for Mac OS X, it was necessary to procure them from third party vendors. This doesn’t fit well with the “bring in any computer that you want, connect it to the network, and do your work” philosophy that underlies BYOD.
One of the consequences of BYOD is a tacit admission that “it may not be critical to manage the configuration of computers connecting to the network”. In BYOD environments it is challenging to get information as to whether the computers that workers are bringing in are healthy or are poorly configured incubators of malware. With BYOD, you’re certainly passing the responsibility for managing the health of the device on to the device owner. If responsibility for client device health is something that can be passed off onto the device owner, it’s certainly harder to make the argument that a technology like NAP is as critical.
Going Forward: Client Health without NAP
NAP was designed almost a decade ago. Today, in 2014 there are better ways of accomplishing goals around identifying unhealthy client computers. You can use Configuration Manager to monitor client configuration, including whether firewalls are enabled, whether anti-malware software is up to date, and whether software updates have been applied. You can do this with client operating systems that are not domain joined. Solutions exist, from Microsoft and from third party vendors, that allow you to monitor client health. In BYOD environments this may mean that the device owner downloads and installs an agent from a self service portal, with the agent sending a message to the IT department and alerting the device owner when a client becomes unhealthy. Rather than having these devices automatically blocked from the network, the IT department can follow up with the device owner and point at the BYOD policy and only block network access if the device owner is recalcitrant and doesn’t remediate the health of their device.
Today any client health monitoring and remediation solution has to be built from the ground up to be “BYOD friendly”. When NAP was designed, BYOD wasn’t yet “a thing”. Today there are solutions that are BYOD friendly and accomplish what NAP was supposed to accomplish in a way that better meets what most organizations want out of this type of solution.