Hey NAP fans, I’m Alex Chalmers from Ball State University with a guest post about NPS logging.

If you made it to one of Jeff’s TechEd IT Pro presentations, you’ll remember me discussing our NAP implementation and some of the challenges that we’ve faced along the way.  Gathering accounting data across the NPS implementation for reporting is one of the largest we’ve faced so far.  With multiple NPS servers around our campus for redundancy, trying to trace a session from login to logout can be tough without some type of centralization.  There are a few possible solutions, but there are several gotchas to be aware of.

A natural reaction to the challenge might be to point to using SQL logging using a single, central data source for all of the NPS servers.  It isn’t a bad solution for a small/medium sized site and is relatively simple to manage.  But there is a pretty large problem with using this scenario when using RADIUS authentication (like with NAP)… if logging the event fails during authentication, the authentication will fail (refer to the Deploying SQL Server Logging with Windows Server 2003 IAS Guide, as it is still relevant).  This means that if the central database server is ever down or otherwise unreachable, end users can no longer authenticate (or re-authenticate) to the network.  At my site where we use 802.1X enforcement with session timeouts it would probably cause a flurry of helpdesk calls, depending on the length of the outage, and guarantee persona non grata status for me with my client services staff for a few days.

In trying to work out an alternative solution, other options were rejected for various reasons.  Logging to a flat file didn’t solve any problems; it has the same problems of the current design with the added issue of trying to get the data into a reporting format.  Trying to use SQL replication was out as we would have had to license SQL Server Standard or Enterprise for all of our NPS servers, as SQL Server Express can’t act as a publisher.  Running independent SQL Server Express instances on each NPS system on its own could have worked, but you are limited to a 4GB database and still have to manually centralize the logging.  Luckily, as we were looking at this last option some very knowledgeable people suggested we look at using SQL Service Broker.

Service Broker is a communications framework built into SQL Server 2005, and unlike replication in this case it could be used to send data from a SQL Server Express instance to a central data warehouse.  The framework design is nearly tailor-made to be used in this situation.  In its most basic sense, it enables two entities to send messages to each other while ensuring the messages are reliably received only once and in the same order they were sent.  Reliable delivery, even across system restarts and network outages, and delivery without repetition are the two keys for this particular implementation.

I’ve created a set of SQL scripts that will help you to create the necessary objects for a basic, but functional, solution.  But before we can get to implementing anything, we need some prerequisites.  You will need to download and install SQL Server Express and Management Studio Express on each of your NPS servers.  You will also need to have a server capable of storing your aggregate logging data running SQL Server 2005 Standard or Enterprise edition.  Unfortunately, Service Broker will not communicate between to Express edition server instances.  Each server must be addressable by DNS name.  Configuring Service Broker on an instance will open a TCP port for communication, which will need access through any firewalls if present.  The de facto default port is 4022, but it can be changed if needed.  You will also need to have some paths pre-created for each server’s database and transaction logs, as well as a working directory to store certificate and key backups for disaster recovery purposes.  Once you have these prerequisites complete, you can move on to running the scripts.

These scripts are sample code and assume that objects do not exist.  Please take the time to analyze what is going on in each of them, and run through the scenario at least once in a test environment to be certain that the configuration is exactly what you want before moving into production.  The script files use the Template Parameter feature of Management Studio Express to allow you to tune certain items in the scripts to fit your environment.  Before running the scripts, please fill in the template information by selecting Query->Specify Values for Template Parameters… from the menu bar.  Inside the script zip file, I have included a worksheet with the parameters used in each script to help you prepare.

Starting on the central SQL server, the first script to run is the ConfigureConsolidationServer.sql script.  This will configure the Service Broker endpoints, create the consolidated accounting database, and create the basic broker service that each NPS server will connect to.  While you should be able to execute the whole script in one batch after configuring the template parameters, I would suggest running it one section of code at a time to see the steps in action.  When the script completes, you should have several files in the working directory you specified as a parameter.  While you should store each of the files securely for disaster recovery purposes, you will need to copy the two certificates to each NPS server before running the next script.

Once the central server is configured, we can move to each NPS server.  Open ConfigureNPSServer.sql in Management Studio Express and configure the necessary parameters.  The certificates that you copied over in the previous step should reside in the working directory specified here.  Those certificates will be used to identify and secure the remote broker service to the NPS system.  This script will generate two similar certificates used to identify the NPS server to the central SQL server.  You will need to copy them over before proceeding.

Now that servers have a baseline configuration, running the ConnectNPSServer.sql script on the central SQL server will authorize the NPS server to communicate on the Service Broker service.  In a multi-server NPS configuration, you will need to run a version of ConnectNPSServer.sql for each NPS server in the environment.  Once the scripts have run successfully, you should configure your NPS logging to log to the local SQL server instance.  You will know if the scripts work by examining the RADIUS_Events_XML table on the central SQL server.  If events are being stored, the configuration is successful.  If you are getting data stored locally, but not to the central server, check that the addresses you’ve used in the scripts are valid and that all the ports are listening as expected.  The majority of issues that I've run into with this configuration have been caused by either a bad address or a firewall blocking the Service Broker port that was configured for each server.

The magic of this configuration happens in two stored procedures: Report_Event on the NPS server and Collect_Events on the central SQL server.  Report_Event is called whenever NPS logs an event.  NPS sends an XML fragment to the stored procedure, which is then assigned a timestamp and GUID and stored in a local table.  Additionally, the stored procedure transmits the data, including the additional timestamp and GUID, via Service Broker to the central SQL server.  Collect_Events is called whenever data is logged to the central SQL server's Service Broker queue.  It contains the logic to receive messages via the Broker service.  The raw XML data is then stored in the RADIUS_Events_XML table, along with the previously assigned GUID and event timestamp.  All of the remaining script code is used to create the infrastructure to allow these two procedures to work effectively.

Since I've said that these scripts are sample code, what could be improved upon for your environment?  The first item I would look at is managing the local logs stored on the NPS server.  These are stored there only as a safeguard until you can be certain that the data is accessible on the central system.  You could deal with this issue in many ways, including not bothering with the local cache.  The second major thing to look at is the data format on the central server.  While centralizing the data is the main goal of this post, working directly with the XML data for reporting isn't necessarily the most elegant of solutions.  You will probably want to either extend the Collect_Events procedure or create a scheduled job that will process the RADIUS_Events_XML table and transform the data into table form.  Depending on the data that you're most interested in, you may find that a given event will have multiple entries for a given attribute (SHA SoH data is one) so you might need multiple tables with relationships.  Key them off the event GUID assigned in the Report_Event procedure so that you can track an event's data where ever it may reside.  The last item that I would look at directly is whether there is any organizational data that you might need to store at or near the time of the event.  If your user population has somewhat frequent name changes, as an example, you may want to extend the data to include not only the username of the account used to login but the user object's AD GUID, SID, or some other unique identifier so that you can track a user's activities over a period of time without needing a list of usernames.

As you can see, this solution provides quite a bit of flexibility to design a system that will work for your needs.  The downside to the solution is it does require a fair amount of knowledge about SQL Server to pull data from the logs and design queries that can later be used in a reporting solution, using Reporting Services or some other mechanism.  The scripts I've implemented are really only the backbone of the solution, providing the necessary infrastructure and "glue" to allow the servers to communicate effectively.

I know that you will most likely have questions about our deployment or how these scripts function beyond the small novel of a post I have here.  I'll happily answer any question in the comments of this post, or you are most welcome to send me email.  If you have ideas, suggestions, or tips on how you've implemented something please share them as well!

- Alex B Chalmers

The latest version of the Microsoft Assessment and Planning Toolkit 3.1 (aka MAP) was released today from the Solution Accelerators team which contains a cool new feature that just might assist you in your NAP deployment planning.

If you’ve never heard of MAP, it is quite cool. I installed it and played around with it for the first time today. It was quite simple to use, once I overcame the installation pre-requisite hurdles (you need Word + Excel + two shared components of Office installed). Here is Baldwin Ng’s summary of what the tool is all about:

... in a nutshell, MAP is basically a network-wide agent-less tool that can help you quickly find out where your desktops and servers are and then it would auto-generate upgrade recommendations for multiple products and technologies including server, desktop and virtualization migration scenarios covering:

·         Windows Vista hardware and device compatibility assessment

·         Office 2007 hardware compatibility assessment

·         Windows Server 2008 hardware and device compatibility assessment

·         Microsoft Application Virtualization hardware compatibility assessment

·         SNMP inventory reporting

[... and new to version 3.1]

·         Hyper-V virtualization candidates assessment (+ improved virtual machines inventory)

·         SQL server discovery and assessment

·         64-bit installation support

·         Desktop Windows Security Center assessment

The last one in red is where NAP comes in. NAP out of the box in XP SP3, Vista and Server 2008 tracks compliance around the Windows Security Center. As you probably know, NAP can be extended by 3^rd parties quite easily to extend the compliance checking, but the items in Security Center are a great place to start! MAP is able to inventory your entire network and actually give you a glimpse of you NAP “compliance” without having to deploy it first to find out! Pretty cool!

I ran a short wizard to tell MAP to enumerate all the computers in my AD and to scan them for “Vista compatibility”. It found my only domain-joined computer:

The cool thing about the results is that they are available right through Excel. It showed me that if I enabled NAP today, this machine would probably need some remediation! :->

I encourage you to play around with this awesome update to a very rich tool!

Main download page –or- directly from x86 / x64

Jeff

Would you like help selecting the best NAP enforcement method to accomplish your goals? Well, you’re in luck. The fine folks on the Solution Accelerators team have created guidance on just that topic!

The document is entitled “Selecting the Right NAP Architecture”. Here is the main page which lists the available Infrastructure Planning and Design Guides.

Solution Accelerators are free, scenario-based guides and automations designed to help IT professionals who are proactively planning, deploying, and operating IT systems using Microsoft products and technologies. Solution Accelerator scenarios focus on security and compliance, management and infrastructure, and communication and collaboration.

NAP the WORLD baby,

Jeff

This is a continuation from Part 1 and Part 2.

NAP can be configured from the command-line, the MMC (except on XP SP3) and of course Group Policy (GP). Since this is a workgroup scenario, I am going to skip GP – but the principles below are the same.

·         Start the services snap-in and locate these two services – “Network Access Protection Agent” (NAPAgent) and “Wired AutoConfig” (dot3svc).

·         Start NAPAgent and Dot3svc; set both to “Automatic” startup.

sc config NAPAgent start= auto
net start NAPAgent
sc config Dot3Svc start= auto
net start Dot3Svc

·         Start the NAP Client Configuration snap-in; click on the “Enforcement Clients” link.

·         Enable the “EAP Quarantine Enforcement Client” by double-clicking on it and selecting “Enable this enforcement client”.

netsh NAP client set enforcement ID = "79623" ADMIN = "ENABLE"

·         Click on the “User Interface Settings” link; double-click on the “User Interface Settings” entry to configure text to be displayed to users when NAP is unable to (or in progress of) auto-remediate a problem on the computer.

netsh NAP client set userinterface TITLE = "I regret to inform you that you have been NAP'd!!" TEXT = "Please logoff and go home, do not collect $200"

·         You may export / import these settings if you wish.

netsh NAP client export FILENAME = "c:\NapCfg.xml"
netsh NAP client import FILENAME = "c:\NapCfg.xml"

·         Start the Network Connections folder; right-click on your network interface and select “Properties”.

·         Since you started the “Dot3Svc”, you will now see the “Authentication” tab; Enable 802.1X and caching; Make sure PEAP is selected; Clicks “Settings”.

·         In the “Protected EAP Properties” dialog, un-check “Validate server certificate”; Select MS-CHAPv2; Check “Enable Quarantine checks”; Click “Configure”.

·         In the “EAP MSCHAPv2 Properties” dialog, un-check the auto-use credentials setting – this is because we are in a workgroup – if you were in a domain you would want to leave this enabled so the domain user would automatically use his domain credentials.

·         After you “OK” all of those dialogs, the 802.1X client should now attempt to authenticate to the switch port; if not, simply enable/disable or unplug/plug the NIC; you should get prompted for credentials; type the user / password.

·         If everything works you should see something like this; any failures usually show “authentication failed”.

·         Thankfully, you can also use the command-line to export/import these settings too.

netsh lan export profile FOLDER = "c:\\"
netsh lan add profile FILENAME = "c:\LANProfile.xml"

Hopefully you now have end-to-end NAP 802.1X working. If not, my next installment includes troubleshooting! :->

Jeff

NAP 802.1X Configuration Walkthrough – Part 2

This is a continuation from Part 1.

I am going to take a slightly different approach than the 802.1X step-by-step guide. Feel free to follow either method, whatever gets it done for you!

My configuration assumes a “WORKGROUP”, not domain joined. Again, for simplicity of building a demonstration, I prefer to remove the AD component.

·         Open “Server Manager”, just in case it didn’t open for you on logon. :->

·          Add our NAP role – “Network Policy and Access Services”.

·         Add our role service – “Network Policy Server (NPS)”.

*Tip* - if you also install the “Health Registration Authority (HRA)”, this is used only if you are doing NAP + IPsec, it may save you a bit of pain getting 802.1X to work. It has an option to create a “self-signed certificate” for the server. NPS / EAP require a server certificate to do 802.1X NAP.

·         This is an important step, in case you are skipping the previous steps on installing the stuff. You should clear ALL EXISTING CONFIGURATION. Even on a default install, I clear it all out for my own sanity. Clean slate baby; easier to debug.

The four nodes to clear are 1.) RADIUS Clients 2.) Connection Request Policies 3.) Network Policies 4.) Health Policies.

·         Now that we have a clean configuration, let’s run the spiffy wizard. Click on the top “NPS” node within the tree-view. You should then see a “Configure NAP” link on the “Getting Started” page.

·         The first page of the wizard is figuring out which scenario of NAP enforcement you want to configure. For this walkthrough, I am discussing “IEEE 802.1X (Wired)”.

·         Time to configure a RADIUS client (i.e. 802.1X switch). You will have to remember the IP address and shared secret that you configured on the switch itself in Part 1. Click the “Add” button. Fill in a nice friendly name for the switch (maybe a model# and physical location and such – it will be displayed in the logs later), the IP address of the switch (use the management VLAN 1 IP interface) and the shared secret.

·         Since this is a workgroup, the next page can be skipped. This is where you can specify what machines and users should be included in your NAP deployment. This is pretty cool in that you can roll out NAP at your own pace throughout a domain.

·         As I mentioned in the *tip* above, NAP + 802.1X needs a certificate on the server-side to function. A self-signed cert is a quick and easy way to get this going for a workgroup.

I am going to be discussing user-based NAP 802.1X – thus you only need to enable PEAP-MS-CHAPv2. If you were in an AD, you could deploy auto-enrolled machine certificates and get 802.1X machine authentication working. It is pretty slick.

·         Alrighty then, this is the fun bit – configuring the VLANs. It is relatively painless. This can sometimes vary depending on the switch. I will say that all seven of the switches I configured for RSA needed the same exact settings in here.

The “Organization network VLAN” is what I am calling the Compliant VLAN. Obviously the “Restricted network VLAN” is the Non-Compliant VLAN.

Compliant VLAN settings:
Tunnel-Type             = Virtual LANs (VLAN)
Tunnel-Medium-Type = 802 (includes all 802 media ...)
Tunnel-Pvt-Group   = 2

Non-Compliant VLAN settings:
Tunnel-Type             = Virtual LANs (VLAN)
Tunnel-Medium-Type = 802 (includes all 802 media ...)
Tunnel-Pvt-Group   = 3

·         The “Health” settings that are available to you without any additional software are around the Windows Security Center. In NAP, this component is called on the NAP client “Windows Security System Health Agent” – and on the NAP server “Windows Security System Health Validator”.

You will notice in my screenshot that I have other stuff in there. These are plug-ins to NAP I was showing off at TechEd 2008 Orlando. You should be able to accept the defaults on this page and party on.

·         The wizard is done!

·         You should verify that the wizard added the configuration in the following nodes - 1.) RADIUS Clients 2.) Connection Request Policies 3.) Network Policies 4.) Health Policies.

·         Navigate to the “System Health Validators” node in the tree and double-click the “Windows Security Health Validator”. Click the “Configure” button. I recommend starting small and just check for the Windows Firewall at first.

Nicely done! On to the client in the next installment!

Jeff

I just got back from TechEd 2008 North America (Orlando) where I presented two “breakout” sessions on NAP. It went off with a bang and most people really loved the sessions / demos. I have blogged a couple times in the past that I would document exactly how I made it all work and now I want to come through on that promise.

Back in April of this year I created a cool 802.1X NAP Interoperability Showcase for the RSA show – it was two mobile racks (guitar racks actually) full of vendor 802.1X wired gear. I had devices from Cisco, D-Link, Enterasys, Extreme, Foundry, HP ProCurve and Nortel. I got it all working flawlessly with NAP / NPS / Server 2008! It was quite a thing to get working being a guy who deals chiefly in Windows OS’s (and not much networking hardware). After getting it all working I felt some serious love for the scenario – it is definitely my favorite flavor of the 6 NAP enforcement methods we support (DHCP, IPsec, 802.1X, VPN, TSG and Cisco NAC).

Before I head to Windows configuration, we need to talk GEAR. Here are the devices I got working in the showcase rack. I included links to my configuration files from the first five (I need to dig up the other guys too):

1.    HP ProCurve 2626

2.    Cisco Catalyst 3550

3.    D-Link xStack DES-3828

4.    Extreme Summit X450-24t

5.    Foundry FastIron Edge 4802-POE

6.    Enterasys 2G4072-52

7.    Nortel BayStack 5520-24T-PWR

I also saved off a copy of the Network Policy Server (NPS) XML configuration file if you want to refer to it. Use caution when using these files. I don’t want you to frakk your switch! For the purposes of this walkthrough, I am going to discuss the specifics of the HP ProCurve 2626. It is a switch that is near and dear to my heart as it is the first one I ever got working. :-> Some things may vary on your brand / model.

This step caused me some serious pain for a number of reasons. I was handed 7 switches with NO power cables, NO terminal cables NOR any instruction manuals. Whoa ho! “Good luck” was something I was thinking at the time. I hope you aren’t in the same boat here. :->

The ProCurve wasn’t bad at all once I found a female-to-female DB9 cable (i.e. Radio Shack). Being a Microsoft guy, I felt obligated to use Hyper Terminal (some Linux guys later informed me about PuTTY, which is pretty cool). Since Hypertrm disappeared from Vista (huh?!?), I went to my XP SP3 box and copied the required files to my memory stick (hypertrm.chm, hypertrm.dll, hypertrm.exe, hypertrm.hlp).

To get connected to the ProCurve I used 8-N-1 @ 115,200 with Xon/Xoff and VT100 emulation. Boy, this brought me back to my modem days. After hitting “connect” and enter a couple times, you should be presented with this.

By the way, you can use HP’s web based configuration interface for some stuff, like configuring VLANs, but it isn’t able to handle RADIUS configuration – which made me move right over to terminal for everything.

Here is a simple diagram of what every switch looked like. 3 VLANs total:

·         VLAN 1: Management VLAN. Each of the seven switches had an IP address on the 10.x network. This is so they could do two things – authenticate to the NPS via RADIUS + relay the DHCP/BOOTP traffic to the DHCP server running on Windows Server 2008.

·         VLAN 2: Compliant VLAN. AKA – the “healthy network”. Clients on this network are compliant with your policy.

·         VLAN 3: Non-Compliant VLAN – AKA – the “unhealthy network”. Clients on this network are not compliant with your policy. They should not be able to contact clients in Compliant VLAN. It is also advisable to restrict what they can reach on the Management VLAN – only resources required to get them fixed up as well as infrastructure (e.g. AD).

Let’s take a look at the ProCurve configuration I am using:

Startup configuration:

; J4900B Configuration Editor; Created on release #H.10.45

hostname "HP ProCurve 2626"

ip routing

vlan 1

   name "Management"

   untagged 2,4,6,8-26

   ip address 10.0.0.2 255.0.0.0

   no untagged 1,3,5,7

   exit

vlan 2

   name "Compliant"

   ip address 20.0.0.1 255.255.0.0

   ip helper-address 10.0.0.1

   exit

vlan 3

   name "NonCompliant"

   untagged 1,3,5,7

   ip address 30.0.0.1 255.255.0.0

   ip helper-address 10.0.0.1

   exit

aaa authentication port-access eap-radius authorized

radius-server host 10.0.0.1 key secret

primary-vlan 3

aaa port-access authenticator 1,3,5,7

aaa port-access authenticator active

aaa port-access 1,3,5,7

Since I have multiple IP segments, I needed to enable IP Routing on the switch. This line makes that happen:

ip routing

Here are the VLANs. The names are self-evident. I only wanted 4 ports available for clients to authenticate with 802.1X (ports 1,3,5,7). I am not using 802.1X’s notion of port tagging the Ethernet frames, which I won’t go into here. I was going for simplicity, so I treated all seven of the switches like a completely separate network (non-routable between each switch).

vlan 1

   name "Management"

   untagged 2,4,6,8-26

   ip address 10.0.0.2 255.0.0.0

   no untagged 1,3,5,7

   exit

vlan 2

   name "Compliant"

   ip address 20.0.0.1 255.255.0.0

   ip helper-address 10.0.0.1

   exit

vlan 3

   name "NonCompliant"

   untagged 1,3,5,7

   ip address 30.0.0.1 255.255.0.0

   ip helper-address 10.0.0.1

   exit

We need to enable 802.1X on a port by port basis, as well as tell the switch how we intend to authenticate these ports. This is where we point the switch at the Windows Server 2008 machine running Network Policy Server (NPS). The shared secret I am using in this example is complex – it is “secret”. :->

aaa authentication port-access eap-radius authorized

radius-server host 10.0.0.1 key secret

primary-vlan 3

aaa port-access authenticator 1,3,5,7

aaa port-access authenticator active

aaa port-access 1,3,5,7

Make sure you commit the configuration to memory!

HP ProCurve 2626# write memory

Got more coming at you tomorrow! Stay tuned.

Jeff

Hey NAP’ers, Rhys Ziemer coming to you from deep within the concrete jungles of Washington DC. I’ve been working with NAP for a while now, so I wanted to share something that is making my life easier!

As previously discussed on the NAP blog, the preferred method of HRA discovery is through the registration of HRA servers in DNS using SRV records. The challenge is in communicating to clients the desire to use DNS for HRA discovery instead of using the existing store of trusted HRA servers as specified through group policy. Trusted HRA servers are traditionally specified through the Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Network Access Protection node. Here a system administrator can hard code the list of HRA URL addresses that clients can contact when the IPsec NAP agent is enabled on client machines. For large NAP deployments, DNS round-robin service discovery is ideal for load balancing across HRA’s, as well as being able to easily link specific HRA’s to specific sites and domains. In these cases, the EnableDiscovery flag must be set to allow for this discovery to take place. Unfortunately, there is no group policy setting and no template that allows for this registry setting to be enabled uniformly across an enterprise. This is all detailed in Gavin’s post.

This thus requires either creative logon script processing to enable auto-discovery or HRA’s, the purchase of a 3^rd party product to create an ADMX template to provide a basis for implementing HRA auto-discovery, or a knowledgeable SA to create their own ADMX template for the setting from scratch. I personally got tired of hard coding this setting on all of my demo clients for the enablement of HRA auto-discovery and thus wrote my own ADMX template. This link provides the ADMX template and the associated ADML language file in the en-US locale.

For those that aren’t aware, one of the benefits of an ADMX template is that the strings are removed to the <Locale>\<ADMX Root Filename>.ADML location thus supporting multiple localized strings per template. Since I only speak US English fluently, I have only provided an en-US language file, appropriately name en-US\HRAAutoDiscovery.ADML to match the HRAAutoDiscovery.ADMX file. If US English isn’t your localization, feel free to create your own HRAAutoDiscover.ADML template in the appropriate localization. It should be relatively obvious as to how to hack up this ADML file to provide appropriate localized strings.

Within this template, both the workgroup and domain policies are provided for enabling the HRA auto-discovery. In order to load these templates, place the ADMX and ADML files into c:\Windows\PolicyDefinitions for local stores and on the Domain Controller for central GP stores. Additionally, if you are taking advantage of the central ADMX template store within Windows Server 2008, you can add these templates to that store to populate them throughout your enterprise.  Once loaded, if you navigate to the Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Network Access Protection, you’ll notice that there is a new sub-directory entitled Health Registration Authority. Here both the Domain and Workgroup policies are exposed. Note that the Workgroup policy is tattooing the registry, and if a policy with the Workgroup policy is unlinked, the setting will not become disabled or unset. This is not the case for the Domain policy which is a fully managed and standard group policy setting. I included the Workgroup Policy solely for the case of loading the templates onto a local client and configuring local policy to enable HRA auto-discovery.  In an enterprise scenario, this template will most likely not be used, and the registry will simply be hard coded through a script.

Finally, my last comment on the policies is that they are based on the shipping Windows Server 2008 templates and pre-requisites. As such, this particular policy requires Windows XP SP3 or Windows Vista SP1 for proper processing; however, these requirements are not addressed by the Windows ADMX namespace since these products were not released at the time of shipping. If and when this namespace becomes updated to handle Windows XP SP3 and Windows Vista SP1 for minimum requirements, I will update these templates to reflect this base requirement. As such, right now, these templates have a Windows Vista requirement for application, and thus they will not affect Windows XP deployments.

I hope these templates make your NAP deployments just a little bit easier, and if you have any questions or issues with the templates, please feel free to follow-up and I’ll do my best to address the questions and correct problems that you encounter with the templates.

NAP the WORLD!

Rhys (rhysz at Microsoft.com)

Hey NAP bloggers; Jun Wang and Howard Lee here from the NAP engineering team! We just got back from having a great time down in Orlando, FL talking with our fellow developers about NAP. We contributed to two sessions during the TechEd Developers show:

“Ask the Expert” Session

This session was held at 9:00am on Friday 6/6/2008. The lounge was full of visitors during our session, which we were glad to see. We received valuable questions from visitors, ranging from software licensing, Linux/Mac interoperability, NAP-IPsec, to general questions about the NAP solution.

NAP Breakout Session

Our joint presentation on NAP including the NAP SDK went smoothly as planned. We thank those of you who have stayed for the last session (4:30pm) on Friday 6/6/2008, which happened to be the very last session of the Developers conference. Your enthusiasm about NAP was highly appreciated. In the future, moving our session to earlier in the week and earlier in the day should