A best practice is a way of doing things that is considered by others (generally more experienced in the area) to provide the best result. For example, a best practice is to always have at least two domain controllers in case one goes down.
Following a best practice can both solve existing issues and avoid future ones, but a bit of common sense is needed to ensure that you are following the advice that is relevant for you and your organization. In a small test lab of a few VMs, having a second DC may not be needed.
The BPA is an automated tool that's built into Windows. With BPA, a best practice model is a set of specific guidelines for a single area. BPA reviews your infrastructure and points out areas where the environment is not compliant with the best practice model.
The Windows BPA framework provides PowerShell support for managing the BPA process. Windows and applications come with a number of BPA models, generally built by the relevant product group within the Windows Team. The PowerShell cmdlets let you find the BPA models, invoke them, and then view the results. Since not all BPA model guidelines are relevant for all situations, the BPA feature also lets you ignore specific recommendations that are not relevant to you.
You run this recipe on SRV1, a server that was used in recipes earlier in this book. This recipe requires IIS (the web server feature) to be loaded. Refer to Chapter 9, Managing Windows Internet Information Server, the Installing IIS recipe for details on how to install the web server feature.
- Get all BPA models on
SRV1:Get-BpaModel | Format-Table -Property Name, Id, LastScanTime -Wrap
- Invoke a BPA model for the
WebServerfeature:Invoke-BpaModel -ModelId Microsoft/Windows/WebServer
- Get the results of the BPA run:
$Results = Get-BpaResult -ModelId Microsoft/Windows/webServer
- Display how many tests/results are in the BPA model:
$Results.Count
- How many errors and warnings were found?
$Errors = $Results | Where-Object Severity -eq 'Error' $Warnings = $Results | Where-Object Severity -eq 'Warning' "Errors found : {0}" -f $Errors.Count "Warnings found : {0}" -f $Warnings.Count - Look at other BPA results:
$Results | Format-Table -Property Title, Compliance -Wrap
- Use BPA remotely—what
BPAmodels exist onDC1?Invoke-Command -ComputerName DC1 -ScriptBlock {Get-BpaModel} | Format-Table -Property Name, Id - Run BPA Analyzer on
DC1:$ModelId = 'Microsoft/Windows/DirectoryServices' $SB = {Invoke-BpaModel -ModelId $using:ModelId} Invoke-Command -ComputerName DC1 -ScriptBlock $SB - Get the results of the
DirectoryServicesBPA model fromDC1:$SB = {Get-BpaResult -ModelId Microsoft/Windows/DirectoryServices} $RRESULTS = Invoke-Command -ComputerName DC1 -ScriptBlock $SB - Review the results returned from the scan:
"Total results returned: $($RResults.Count)" $RResults | Group-Object SEVERITY | Format-Table -Property Name, Count
- View the error(s) from the scan:
$RResults | Where-Object Severity -EQ 'Error' | Format-List -Property Category,Problem,Impact,Resolution
In step 1, you obtained and displayed the details about the BPA models on the SRV1 host, which looks like this:
As IIS is installed on SRV1, in step 2, you ran the BPA model for the Windows WebServer feature. The output looks like this:
In step 3, you retrieved the results of the most recent invocation of the WebServer BPA model and stored it in $Results. This step produces no output.
In step 4, you displayed a count of the number of BPA results returned from the WebServer BPA scan, which looks like this:
Next, in step 5, you counted and displayed the number of error or warning results that were returned by the BPA scan, as follows:
In step 6, you viewed the specific items that were tested by the WebService BPA model, and the compliance status of SRV1, which looks like this:
You can also use BPA models remotely. In step7, you viewed the BPA models on DC1, a domain controller, which looks like this:
In step 8, you ran the DirectoryServices model remotely on DC1. The output looks like this:
Having run the DirectoryServices BPA model on DC1, in step 9, you retrieved the results. This step produces no output.
In step 10, you examined the BPA results. You displayed the number of BPA results and what kinds of results the BPA scan of DC1 reveals, which looks like this:
The BPA results show one error and seven warnings out of 43 BPA checks on DC1. While you should investigate the warnings, you may find some of the BPA warnings can be ignored in your environment. The BPA error results should be prioritized. In our case, the error result, which you obtained in step 11, looks like this:
In step 1, you saw the BPA models on SRV1. Depending on which other features you added to SRV1, you may see more BPA models.
In step 4, you can observe that the + BPA model checks just four configuration settings for IIS. There are not a lot of BPA checks being done by this model. Other BPA models, such as the DirectoryServices model, which you used in step 9, are much more detailed.
In step 11, you can see that when you run the DirectoryServices BPA model on DC1, BPA reports an error. The error result object includes a description of the problem, the impact, and how to resolve the issue. In this case, the problem that was found was that there was a lack of time synchronization between your forest root DC (DC1.Reskit.Org) and an external (and reliable) time source. Since all hosts in your forest ultimately get their time settings from the forest root server, it is important that the forest root server is synchronized with a reliable, external time source.