Invoke Best Practices Analyzer on remote servers using PowerShell

Best Practices Analyzer (BPA) is a management tool integrated in Windows Server 2008 R2 used to scan server roles according to Microsoft best practice guidelines.

Included in the initial release for Windows Server 2008 R2 are the following BPA models:

• Active Directory Domain Services
• Active Directory Certificate Services
• Domain Name System (DNS) Server
• Remote Desktop Services
• Web Server (IIS)

Since then several new BPA models are released and available both as separate downloads as well as through Windows Update:

• Active Directory Rights Management Services (AD RMS)
• Application Server
• DHCP
• File Services
• Hyper-V
• Network Policy Server (NPS)
• Windows Server Update Services (WSUS)

At the time of this writing, a BPA model for 12 of 17 server roles in Windows Server 2008 R2 are available.
The 5 that are not available are:

• Active Directory Federation Services (ADFS)
• Active Directory Lightweight Directory Services (AD LDS)
• Fax Server
• Print and Document Services
• Windows Deployment Services

In Server Manager, a BPA summary are available for each installed server role that an BPA Model exists for:

When looking at the properties for an item in BPA you get more information as well as a link to Microsoft TechNet where more information are available for the specific subject:

BPA are built as a PowerShell module, meaning that a PowerShell cmdlet (Invoke-BPAModel) are run in the background when you scan a server role from Server Manager:

This is a great feature to examine if your server roles are configured according to Microsoft`s best practices, however, if you got many servers it will take some time to log on to each server and scan each server role. In addition you don`t get any centralized reporting this way.

Since BPA are based upon Windows PowerShell it`s possible to solve this using the BPA PowerShell module and PowerShell remoting:

I`ve created a sample script to accomplish this, named Invoke-BPAModeling, with the following functionality:

• Invoke BPA for all available server roles on specified remote servers
• E-mail reporting
• File reporting to CSV and HTML

You need to customize the initial variables on the top of the script. You can enable/disable reporting using these variables, as well as specify which servers to work against, SMTP server for e-mail reporting and paths to CSV/HTML reports.
By default, only items with a severity of “Error” and “Warning” are reported. You can change this to also include “Informational” severities by configuring IncludeAllSeverities to true.
On the server running the script from, the Active Directory module for PowerShell must be installed if you want to retrieve computer names from Active Directory. In the sample,  the script are configured to retrieve all computer accounts listed with Windows Server 2008 R2 as operating system.
You might choose alternate methods, like importing the computer names from a csv-file.
.
I would recommend that you approve the new BPA models mentioned at the beginning of this blog post in WSUS prior to running the script.
The script requires that PowerShell remoting are enabled and configured on the remote servers. Also note that there is a known issue with the BPA module; When the PowerShell execution policy are set to any other than “Undefined” or “Unrestricted” , an error occurs. I`ll update this blog-post as soon as a fix are provided from Microsoft.

When the script executes, it displays the progress based upon the total number of computers running against:

Sample e-mail report containing both CSV and HTML reports as attachment:

Sample HTML-report:

Sample CSV-report converted to an Excel spreadsheet:

Feel free to customize the script for your needs, as well as suggest improvements.

Resources

Best Practices Analyzer on Microsoft TechNet

DD-WRT RADIUS Authentication w/ Server 2008 R2

I presume you know what you’re doing and why you need this. And I also presume you have a working WPA2 Personal wireless access point running DD-WRT – if you’re running something else this howto will still be useful but you will need to adjust the DD-WRT specifics.

Now on with the show:

1. Install the Network Policy and Access Services role with it’s Network Policy Server service.
   
   
2. Create a certificate for RADIUS (hint: MMC is available already on Server 2008 R2 – Start -> Run: MMC) by opening MMC and adding the Certificates snap-in for a Computer Account on the Local Computer and then Requesting a new certificate (see image).
   When you are creating your certificate it needs to be for a Computer.

   If “Computer” is not available under Active Directory Enrollment Policy then you will need to grant the Enrol privilege to the machine you are requesting the certificate on. If you have multiple sites with a DC at each site (that will be doing RADIUS authentication) just grant the Domain Controllers group the Enrol privilege. You have to do this from Server Manager on the server that has ADCS installed.
   

   Back to requesting the certificate. Click the details button and then properties: fill in any information you want for the certificate. At the very least give your certificate a Friendly Name so you can recognise it later.
   

   When you’re ready click the Enrol button. You should now see your new certificate listed in the Certificates folder in the Certificates snap-in. Close the MMC now – save if you want.

3. Startup the Network Policy Server (either standalone or through Server Manager).
   
4. Register NPS in Active Directory.
   
5. First we’ll create a RADIUS Client (this is your DD-WRT AP). The guides I referenced above suggest using the wizard now… you can do that but it didn’t fully work for me – some of the policies had to be removed.
   The settings for your RADIUS Client are fairly straight forward just make sure you keep a copy of your shared secret for later on (especially if you use the generate function).
6. Now we need to update the default Connection Request Policy (I chose to adapt the default as it suited me well; you could duplicate and disable or start from scratch it’s up to you). The default policy essentially allows anyone to attempt local authentication 24/7. I changed the policy in two areas: firstly the name and secondly the time and days (i.e. turn off weekend access).
   You should not need to change ANYTHING on the Settings tab. But make sure that under Authentication the Authenticate requests on this server option is selected.
7. Next create a new Network Policy:
   • Give your policy a name.
   • Type of network access server: Unspecified.
   • Conditions: Whatever you want! Seriously there are plenty of options here.My implementation called for two groups (i.e. AD Security Groups): one for Users with access to wireless and another for Computers that may connect wirelessly. I have two groups due to other group policy design considerations you could achieve the same thing with one group. Or you could list users with wireless access here. Or IP addresses. Or… as stated before there are plenty of options. It is worth noting here that ALL conditions must be met so I would suggest you use Windows Groups if you want an “in either” implementation – it does NOT make sense to use both Machine and User groups in the same policy (unless you have users that should not have wireless access, logging on to a machine, that can be used wirelessly, and has other users logging on that should have wireless access… in other words keep it simple!).Remember if you are logging in over wireless it will help if your computers can join the network before the user logs in (i.e. make sure KNOWN wireless computers are granted access here).

     There is one essential condition: NAS Port Type! You only want Wireless clients right?

   • Generally speaking you’ll want: Access granted. It’s all I’m covering too.
   • EAP Types:
     • Click Add: Choose “Microsoft: Protected EAP (PEAP)”
     • Select the added entry click Edit.
     • Nominate the certificate you created above (see the Friendly Name).
     • You’ll also want to enable fast reconnect and have “Secured Password (EAP-MSCHAP v2)” under Eap Types.
     • Leave the Less secure authentication methods enabled (change it later once it’s working – or leave it to support older/other clients).

     

   • Constraints: I left all defaults as I covered everything with Conditions already. What’s the difference? Conditions determine if the policy should be used; Constraints grant/deny access. For my limited restrictions they are essentially the same thing.
   • Settings: More choices for you to make! Two things you definately must do:
     • Delete: Framed-Protocol PPP.
     • Encryption: Choose what you want – I only have strongest enabled.
   • Check your settings and click Finish.
   • At this stage you should restart the Network Policy Server service.
8. It’s time to configure DD-WRT browse to: Wireless -> Wireless Security.
   

And that’s it!

Well ok not really now you should test! You can find the NPS log files in %WINDIR%System32LogFilesIN*.txt – configured correctly the old IAS Log Viewer can read the files. But be warned the LogFiles folder doesn’t show up in a file tree (you’ll have to type).

Once you are confident your clients and users can authenticate properly you should consider using group policy to deploy the wireless profile.

I presume you know what you’re doing and why you need this. And I also presume you have a working WPA2 Personal wireless access point running DD-WRT – if you’re running something else this howto will still be useful but you will need to adjust the DD-WRT specifics.

Now on with the show:

1. Install the Network Policy and Access Services role with it’s Network Policy Server service.
Install NAP Role
Install NPS Service
2. Create a certificate for RADIUS (hint: MMC is available already on Server 2008 R2 – Start -> Run: MMC) by opening MMC and adding the Certificates snap-in for a Computer Account on the Local Computer and then Requesting a new certificate (see image).
New Certificate

When you are creating your certificate it needs to be for a Computer.

If “Computer” is not available under Active Directory Enrollment Policy then you will need to grant the Enrol privilege to the machine you are requesting the certificate on. If you have multiple sites with a DC at each site (that will be doing RADIUS authentication) just grant the Domain Controllers group the Enrol privilege. You have to do this from Server Manager on the server that has ADCS installed.
Computer Certificate Template Properties

Back to requesting the certificate. Click the details button and then properties: fill in any information you want for the certificate. At the very least give your certificate a Friendly Name so you can recognise it later.
Certificate Details

When you’re ready click the Enrol button. You should now see your new certificate listed in the Certificates folder in the Certificates snap-in. Close the MMC now – save if you want.
3. Startup the Network Policy Server (either standalone or through Server Manager).
Open NPS Role Manager
4. Register NPS in Active Directory.
Register NPS in AD
5. First we’ll create a RADIUS Client (this is your DD-WRT AP). The guides I referenced above suggest using the wizard now… you can do that but it didn’t fully work for me – some of the policies had to be removed.
New RADIUS Client

The settings for your RADIUS Client are fairly straight forward just make sure you keep a copy of your shared secret for later on (especially if you use the generate function).
6. Now we need to update the default Connection Request Policy (I chose to adapt the default as it suited me well; you could duplicate and disable or start from scratch it’s up to you). The default policy essentially allows anyone to attempt local authentication 24/7. I changed the policy in two areas: firstly the name and secondly the time and days (i.e. turn off weekend access).
Connection Request Policy Properties

You should not need to change ANYTHING on the Settings tab. But make sure that under Authentication the Authenticate requests on this server option is selected.
7. Next create a new Network Policy:
* Give your policy a name.
* Type of network access server: Unspecified.
* Conditions: Whatever you want! Seriously there are plenty of options here.

My implementation called for two groups (i.e. AD Security Groups): one for Users with access to wireless and another for Computers that may connect wirelessly. I have two groups due to other group policy design considerations you could achieve the same thing with one group. Or you could list users with wireless access here. Or IP addresses. Or… as stated before there are plenty of options. It is worth noting here that ALL conditions must be met so I would suggest you use Windows Groups if you want an “in either” implementation – it does NOT make sense to use both Machine and User groups in the same policy (unless you have users that should not have wireless access, logging on to a machine, that can be used wirelessly, and has other users logging on that should have wireless access… in other words keep it simple!).

Remember if you are logging in over wireless it will help if your computers can join the network before the user logs in (i.e. make sure KNOWN wireless computers are granted access here).

There is one essential condition: NAS Port Type! You only want Wireless clients right?
* Generally speaking you’ll want: Access granted. It’s all I’m covering too.
* EAP Types:
o Click Add: Choose “Microsoft: Protected EAP (PEAP)”
o Select the added entry click Edit.
o Nominate the certificate you created above (see the Friendly Name).
o You’ll also want to enable fast reconnect and have “Secured Password (EAP-MSCHAP v2)” under Eap Types.
o Leave the Less secure authentication methods enabled (change it later once it’s working – or leave it to support older/other clients).

EAP Security Types
* Constraints: I left all defaults as I covered everything with Conditions already. What’s the difference? Conditions determine if the policy should be used; Constraints grant/deny access. For my limited restrictions they are essentially the same thing.
* Settings: More choices for you to make! Two things you definately must do:
o Delete: Framed-Protocol PPP.
o Encryption: Choose what you want – I only have strongest enabled.
* Check your settings and click Finish.
* At this stage you should restart the Network Policy Server service.
8. It’s time to configure DD-WRT browse to: Wireless -> Wireless Security.
DD-WRT Settings

And that’s it!

Well ok not really now you should test! You can find the NPS log files in %WINDIR%System32LogFilesIN*.txt – configured correctly the old IAS Log Viewer can read the files. But be warned the LogFiles folder doesn’t show up in a file tree (you’ll have to type).

Once you are confident your clients and users can authenticate properly you should consider using group policy to deploy the wireless profile.