Share via

Time for your NAP

  • Article

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 (tm) 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.

Adam Carter

Technical Evangelist and guest NAP Blogger

Find his technology blog here

Comments

  • Anonymous
    January 01, 2003
    Wie kann man sich sicher sein, dass der Rechner, der sich gerade am Netzwerk anmeldet, auch wirklich

  • Anonymous
    January 01, 2003
    Vous vous demandez peut être si nous utilisons les produits que nous sommes sur le point de rendre disponibles,

  • Anonymous
    January 01, 2003
    I've been speedlinking some interesting Network Access Protection links in the past (which you can find

  • Anonymous
    January 01, 2003
    Hello All, Brent Atkison here with the deployment team responsible for rolling out Network Access Protection

  • Anonymous
    January 01, 2003
    CNET reported that Oracle "quietly cut software prices on some lower-end servers using multicore processors." Un-related to this, if you're interested in the network access control capabilities in Longhorn, check out Adam's post about NAP.

  • Anonymous
    January 01, 2003
    I wanted to follow-up on Adam's great post from last week on NAP's roll-out here within Microsoft. He

  • Anonymous
    January 01, 2003
    I got to be a guest blogger on the NAP team blog today. You can read my post here .

  • Anonymous
    March 05, 2007
    Thanks for the post and for giving us a bit more insight.  Truly admins with Real Jobs (tm) eagerly await. :)