I don’t remember when I first starting hearing about Network Access Protection (NAP) but I know it was over a year ago, because I used to mention it in passing when I talked to customers about Windows Server 2003 R2. I think it was originally a feature we hoped would be in R2, but was delayed until Longhorn Server instead. Many customers were already investigating Cisco’s NAC, so it gave me an opportunity to let them know that we were working on the technology as well, and that we were partnering with them so that our solutions would work together.
I think the concept behind NAP is really good, and lots of customers thought it was really good too when I shared the vision with them: regardless of how a machine connects to your network, be it RAS or VPN, or wireless or physically connected by an Ethernet cable, you can prevent that machine from having full access to the network unless it meets the criteria you specify, like up-to-date virus software and patches. Combined with technologies like IPsec, you can feel comfortable that the machines on your network are the machines you want to have on your network, and that they comply with your policies.
I’ve been doing a lot with NAP lately, including putting together some hands-on labs and having some concept and planning whitepapers written, all with the intent of making it easier for IT Pros with Real Jobs ™ to get up to speed on how all this works and what they need to know to deploy it.
I was a little surprised by an email that was forwarded to me by someone in the NAP team. Amongst other things, the email mentioned that NAP had been turned on in “deferred enforcement” mode throughout Redmond.
I was surprised, because I hadn’t heard anything about it from anyone else already. No chatter on any email DL’s about how it had disabled machines, no screams of anguish up and down the hall from people who could no longer get on the network.
That was the ‘amongst other things’ part of the email:
Number of NAP related helpdesk calls on day one: 0.
Number of desktops assumed to be compliant, but weren’t, but now are because of NAP: hundreds.
Number of things that worked as expected: Every.
In short, a huge success. NAP has been running for the past couple of months in reporting mode, so IT had a pretty good idea how many compliant/noncompliant machines were out there.
Jeff Sigman shared some pretty interesting numbers with me. There are almost 30,000 machines in Redmond that have NAP successfully installed. We’re using primarily IPSec as the enforcement method, but DHCP is configured in some buildings as well. About 70% of the machines are being reported as ‘healthy.’ That actually seemed like a low number to me, and MSIT assures me that it’s a reporting error, so I’ll update that figure when I get a corrected one. Given the number of labs we have that may require machines run in a certain configuration, and therefore non-compliant, I guess that number is pretty reasonable for a first pass, and will continue to climb as people manually update their machines, or let NAP happily do it for them in the background.
Admins have been crying out for this technology for years. How many administrators leave work hoping that their clients are configured properly and that patches all applied without error? Deploying NAP is a little like hiring a full time employee to do that worrying for you and that employee can fix the noncompliant machines he discovers.
I’m going to try and tee up an interview with the MSIT folks that did this deployment to put on Channel9. Watch this space for more info.
Oh, and if you’re interested in evaluating NAP yourself, let me know. I’d really like to put those NAP whitepapers and labs in front of as many people as I can.
Technical Evangelist and guest NAP Blogger
Find his technology blog here