Using the Hyper-V Best Practices Analyzer

I’m really not much of a fan of the term “best practices”. Most of the “best practices” that I’ve seen throughout my career are arbitrary, situational, capricious, and more dependent upon folklore than upon fact. I think that most people that have been in the industry for a few years know this, but it’s still the go-to term for people that really do want to know the proper choices when architecting, purchasing, building, and maintaining systems. To try to help out, Microsoft has been offering its “Best Practices Analyzer” as a built-in component of Windows Server for quite some time. We’re going to take a look at the Hyper-V-specific analyzer. This particular analyzer has been available since Windows Server 2008 R2, but we’re going to specifically work with the analyzer as it is found in Windows Server 2016. I don’t believe that anything has been changed in operational procedures since 2012 R2, but there are new report items.

What is the Hyper-V Best Practices Analyzer?

The Best Practices Analyzer (BPA) is a component of Windows Server that runs pre-designed tests against a target Windows Server computer and/or its applications and generates a report on its findings. The Best Practices Analyzer can be targeted against specific roles and applications. Reports are retained on the system and can be referred to later. Best Practices Analyzer can be run against multiple computer simultaneously provided that it is running under a user account that has administrative privileges on each target.

How Do I Acquire the Hyper-V Best Practices Analyzer?

The BPA itself is built into Windows Server and Hyper-V Server. Its graphical components are part of Server Manager, so you’ll need a copy of Windows with the Remote Server Administration Tools installed or a copy of Windows Server. Native PowerShell cmdlets are also available to generate reports.

How Do I Use Server Manager to Operate the Hyper-V Best Practices Analyzer?

First, you need to add in the server(s) that you’re going to run the BPA against. If you’re running it against the local system and the Hyper-V role is enabled, then you do not need to take any additional connection steps. Skip down to that sub-section. Otherwise, you’ll need to connect to those remote systems first.

Connect Server Manager to Remote Systems

These steps only need to be followed once for each instance of Server Manager that you wish to run the BPA from.

1. On Server Manager’s Dashboard page, choose 3. Add Other Servers to Manage
   

   Server Manager Add Servers Link

    

2. Use the top three items on the left to choose the criteria for severs to select. Once you have an acceptable search criteria defined, click Find Now. If you want, you can just click Find Now without choosing any items and it will return all objects in the directory. Note that there is also a DNS tab and an Import tab, so you aren’t required to search only Active Directory. I will only show the Active Directory steps.
   

   Server Search Criteria

    

3. Objects that match your search criteria will appear in the lower left. Verify that they are what you expected. If you didn’t find the server that you were looking for, simply refine your criteria and click Find Now again.
   

   Server Manager Found Servers

    

4. Click, Shift-Click, and/or Ctrl-Click to highlight the found server(s) that you wish to include. My steps are intended to guide you toward running the BPA against hosts running Hyper-V, but you can add any system that you want to manage from this particular instance of Server Manager regardless of what operating system, roles, and features it is running. You can manage up-level, down-level, and even client systems from the same Server Manager console (the Hyper-V BPA does not work against Client Hyper-V). Once you are satisfied with your selections, press the button with the right-arrow graphic to move the items into the Selected column on the right.
   

   Server Manager Selected Servers

    

5. Repeat steps 2-4 until you have selected all of the systems that you wish to manage.
6. After the loading process continues (signified by a thin rolling progress bar near the top of the Server Manager window), change to the Hyper-V pane in Server Manager. Verify that all of the expected systems appear.
   

   Server Manager Hyper-V Systems

Once connected, Server Manager will remember that system until you manually remove it from this Server Manager instance.

Requesting a Hyper-V Best Practice Analysis in Server Manager

Requesting a Best Practices Analysis in Server Manager is done in a few simple steps.

1. Switch to the Hyper-V tab in Server Manager. On the right, click the server that you wish to analyze.
   

   Server Manager Selected Hyper-V System

    

2. Scroll down to the Best Practices Analyzer section. Click the Tasks drop-down, then click Start Scan.
   

   Server Manager Start BPA Scan

    

3. A window will pop up with all target hosts that are available for this particular scan. The one that you selected in step 1 will already be checked. Check any others that you wish to include in this scan. Click Start Scan.
   

   Server Manager BPA Target Selection

    

4. A thin progress bar will start to scroll at the top of the Best Practices Analyzer section. It will continue to run even if you close Server Manager. You can verify its status by the flag icon at the top right of Server Manager.
   

   Server Manager Running BPA Task

    

This process might take some time, especially against remote systems.

Viewing the Results of a Hyper-V Best Practices Analysis in Server Manager

This section specifically deals only with the basics of viewing the outcome. For some guidance on reading the analyses, check the “Reviewing BPA Results” section below.

One of the drawbacks of using Server Manager for the BPA is that you can only read the outcome of the latest analysis. There is no retrieving of earlier analyses for comparison purposes. If that’s what you’re looking for, check the PowerShell section below.

To use Server Manager to view the latest results of a Hyper-V Best Practices scan:

1. Switch to the Hyper-V tab in Server Manager. On the right, click the server that you wish to analyze.
   

   Server Manager Selected Hyper-V System

    

2. Scroll down to the Best Practices Analyzer section. Provided that at least one successful BPA analysis has run on the target, there will usually be at least a few entries here.
   

   Server Manager BPA Result List

    

3. If no items appear and you are certain that a scan did complete, it’s likely because you have no errors or warnings but the display is filtered to show only errors and warnings. If you’d like to modify what types of results are shown, you can click the Clear All button to remove all filters, you can type criteria into the filter box, or you can choose a pre-defined filter from the drop-down.
   

   Server Manager BPA Display Filter

    

4. If you highlight an item, it will show a Problem and an Impact section and a More information about this best practice and detailed resolution procedures link.
   

   Server Manager BPA Result Details

    

Be forewarned that Microsoft has a radically different notion for what qualifies as “detailed resolution procedures” than I do.

How Do I Use PowerShell to Operate the Hyper-V Best Practices Analyzer?

PowerShell provides much greater control over the entire BPA process from top to bottom. The only thing that it lacks is the direct graphical output capabilities of Server Manager. It can convert results into other formats, though, so it wins in overall capability. You do not need to take any elaborate steps to connect to remote servers. You can control where results are placed. You can view more than just the most recent set of results.

Using PowerShell to Invoke the Hyper-V Best Practices Analyzer

To run a Hyper-V BPA scan on the local host and place the outcome in C:WindowsLogsBPAReportsMicrosoftWindowsHyper-VResults:

Invoke-BpaModel -ModelId Microsoft/Windows/Hyper-V

To redirect the outcome of the results:

Invoke-BpaModel -ModelId Microsoft/Windows/Hyper-V -RepositoryPath C:BPA

The location specified for RepositoryPath must exist. The BPA will automatically create sub-folders MicrosoftWindowsHyper-VResults<timestamp> to hold its results.

To run BPA against a remote system (note: I am going to show you a superior way a bit later in this article):

Invoke-BpaModel -ComputerName svhv02 -ModelId Microsoft/Windows/Hyper-V

In 2016 (not 2012 R2), this will generate a complaint about not being able to locate Hyper-V.psd1 in a location that would be absurd to find Hyper-V.psd1, but the process completes. Unlike BPA under Server Manager, the PowerShell version does not store remote analyses on the remote computer. They’ll be kept locally. The above cmdlet when run on my environment produced the following tree structure on the computer where I ran the cmdlet: C:WindowsLogsBPAReportsMicrosoftWindowsHyper-VResultsHyper-V-Sunday, 20 November 2016-13-28-12Hyper-Vsvhv02

To run BPA against a remote system and redirect the output (note: I am going to show you a superior way a bit later in this article):

Invoke-BpaModel -ComputerName svhv02 -ModelId Microsoft/Windows/Hyper-V -RepositoryPath C:BPA

As with the non-overridden version, the output was saved on the system that invoked the BPA, not the target system.

Using PowerShell to Retrieve BPA Results

To retrieve the results of the last BPA scan against the local system from the default folder (exactly what Server Manager does):

Get-BpaResult -ModelId Microsoft/Windows/Hyper-V

To retrieve results for the local computer that are stored in a redirected location:

Get-BpaResult -ModelId Microsoft/Windows/Hyper-V -RepositoryPath C:BPA

Things get interesting when run against a remote system. The directory structure created by the Invoke-BpaModel cmdlet for remote computers completely baffles the Get-BpaResult cmdlet when trying to get a single set of results as shown above. If left as-is, anything from the above will net you: Get-BpaResult : There has been a Best Practice Analyzer error for Model Id ‘Microsoft/Windows/Hyper-V’. The Result file has not yet been generated. Please perform the scan first and try again.

The result.xml file is there, and if you don’t mind looking at it in that format, then you can just deal with it. Most of us would prefer something a bit easier to read, though. If you stick with the single item technique shown above, the “best” solution is to copy the generated results.xml into an artificially constructed folder structure that matches what Get-BpaResult expects:

md 'C:BPAsvhv02MicrosoftWindowsHyper-VResultsHyper-V-Sunday, 20 November 2016-13-25-25'
cp 'C:bpaMicrosoftWindowsHyper-VResultsHyper-V-Sunday, 20 November 2016-13-25-25Hyper-Vsvhv02*.xml' 'C:BPAsvhv02MicrosoftWindowsHyper-VResultsHyper-V-Sunday, 20 November 2016-13-25-25'
Get-BpaResult -ModelId Microsoft/Windows/Hyper-V -RepositoryPath C:BPAsvhv02

Is that miserable or what? I have two options to deal with it. The first isn’t what I would call the “best” necessarily, but it has some nice capabilities.

Use the -All parameter to retrieve every single report in a repository and place them into an array of objects. Without specifying RepositoryPath, you get everything from the default location. Let’s continue using the C:BPA path:

Get-BpaResult -ModelId Microsoft/Windows/Hyper-V -All -RepositoryPath C:BPA

On my test system, I had run two scans: one locally and one against a remote system. My output was:

ScanTime              ScanTimeUtcOffset Parameters Results
--------              ----------------- ---------- -------
11/20/2016 1:22:55 PM -08:00:00                    {SVHV01, SVHV01, SVHV01, SVHV01...}
11/20/2016 1:25:31 PM -08:00:00                    {svhv02, svhv02, svhv02, svhv02...}

I can see from the compressed output which machine each was run against. I can then retrieve the output just for the remote machine (SVHV02) in several ways.  Here’s one:

Get-BpaResult -ModelId Microsoft/Windows/Hyper-V -All -RepositoryPath C:BPA | where ScanTime -eq '11/20/2016 1:25:31 PM' | select -ExpandProperty Results

Another:

(Get-BpaResult -ModelId Microsoft/Windows/Hyper-V -All -RepositoryPath C:BPA)[1].Results

Another, that would not differentiate between time stamps:

Get-BpaResult -ModelId Microsoft/Windows/Hyper-V -All -RepositoryPath C:BPA | select -ExpandProperty Results | where ComputerName -eq 'svhv02'

Remember that PowerShell works with objects, so you can store the output of a cmdlet and operate against it later:

$AllBPAResults = Get-BpaResult -ModelId Microsoft/Windows/Hyper-V -All -RepositoryPath C:BPA
$AllBPAResults | where ScanTime -eq '11/20/2016 1:25:31 PM' | select -ExpandProperty Results

These techniques aren’t terrible, and they have a definite advantage in that you can run the BPA against multiple remote targets and aggregate all of their results on a single system. The downside, of course, is that this is a lot more PowerShell than a lot of people want to commit to when all they’re looking for is a BPA run. I will revisit this with what I think is a much simpler way, but I want to show you formatting first, because that is the real reason you want to use PowerShell instead of Server Manager for the Best Practices Analyzer.

Using PowerShell to Format BPA Results.

So far, what I’ve shown you in PowerShell just dumps everything to screen. Not very useful, is it? Makes you think that Server Manager is better, right? With a few extra keystrokes, you can make PowerShell worth every bit.

Would you like your results in CSV format?

Get-BpaResult -ModelId Microsoft/Windows/Hyper-V | Export-Csv -Path c:BPAresults.csv -NoTypeInformation

How about HTML?

Get-BpaResult -ModelId Microsoft/Windows/Hyper-V | ConvertTo-Html | Out-File C:BPAresults.htm

You can use any Export- and ConvertT0- cmdlets that you have on your system that can work with general PowerShell objects.

If that’s not enough, you can also use any tool in your arsenal that can process XML (including roll-your-own solutions in PowerShell, Excel, C#, VB, etc.) to do anything that you like. With only a bit of effort, you should be able to discover how to insert the data into a SQL table for historical data, if that’s something that you’re interested in.

An Alternative Method to Running BPA Against Remote Systems

Running BPA against remote systems can be a miserable experience. It’s always slow, often crashes, it’s difficult to read the results in PowerShell, and it’s just a generally horrid experience that is barely worth the effort. So, I’m going to show you a much easier way, using PowerShell Remoting, with overall superior outcomes:

'svhv1', 'svhv2', 'svhv01', 'svhv02' | foreach { Invoke-Command -ComputerName $_ -ScriptBlock { Invoke-BpaModel -ModelId Microsoft/Windows/Hyper-V } }

In my unscientific testing, that completed against all four hosts in less time than was necessary to run against even a single remote system and nothing crashed.

The benefits of using PowerShell Remoting to generate BPAs:

• Speed! I have no idea why remote scans take so long, but with PowerShell Remoting, they run more closely to the same amount of time as a local scan. They still take longer, and still sometimes take much longer than running locally.
• Stability! This method has never crashed (for me — your mileage may vary).
• Server Manager compatibility. Typed exactly as I did above, each result will be stored in the default location. When Server Manager reads that host for BPA results, it will retrieve the results of that scan. That means that you get the easier readability of Server Manager without needing to wait hours for Server Manager to scan a single remote system.
• Expandability. You could use this as line 1 of a PowerShell script that does most anything.
• Parallelizable! Submit Invoke-Command with -AsJob and each BPA will run in parallel.

Notes About and Troubleshooting the BPA Scan Procedure

There are a few things to be aware of with BPA Scans.

Local scans typically complete quickly. Remote scans can take a long time.

• Scanning up- and down-level Hyper-V hosts does work, but it can take an extremely long time and throw errors… even though the scan usually works anyway.
• The outcomes of all BPA scans operated by Server Manager are kept in C:WindowsLogsBPA on the target system. The full path to locate Hyper-V BPA results is: C:WindowsLogsBPAReportsMicrosoftWindowsHyper-VResults. Beneath that will be individual folders that contain the separate outcomes of each BPA scan.
• Scans work with the BPA on the target system, not the source system. Therefore, BPA conditions will always match the target system version.
• Errors will appear like the following screen shot. Click the More… link to be taken to a list of recent outcomes. It will not automatically select the item that threw the error, so you might need to hunt through the list a bit.
  

  BPA General Fault Light

   

• Error messages related to failed scans rarely make any sense or contain any useful information. Some that I’ve seen:
  • Out of memory — I have no idea what it’s doing that needs so much memory or what to do about it. I gave up waiting on the scan in question after two hours. I came back a couple of days later and had this error message but the scan had completed and generated results.
  • A Best Practice Analyzer is currently running — The complete text of this error contains a great deal of gibberish, but the basic premise that it’s trying to convey is that there’s already a BPA scan running. You’ll get this even in times when you can’t find any other BPA running against that system. If you are absolutely certain that there is no BPA running against that host anywhere, navigate to C:WindowsLogsBPAReportsMicrosoftWindowsHyper-VResults on the target system and delete the file named Hyper-V_lock. This message will almost always appear after the “out of memory” error because the BPA doesn’t properly clean up after itself if it crashes.
  • The WSMan provider host process did not return a proper response — Basically, the BPA crashed. I get this when I force the BPA to stop.

How Do I Stop a BPA Scan In-Progress?

I don’t know of any graceful way to stop an in-process BPA. It does not have its own Windows process. Follow these directions at your own risk.

On the target system, use Task Manager or PowerShell to locate the process named Host process for WinRM plugins (wsmprovhost). Ending this process will stop the current BPA scan — and anything else using that host process.

View of a Running BPA in Task Manager Processes

View of a Running BPA in Task Manager Details

View of a Running BPA in PowerShell

When running a BPA scan from up- or down-level servers, I find that this process has some fairly high CPU and memory usage and just runs on and on.

Reviewing BPA Results

So, you’ve got your BPA results. Now what? A few pointers:

• As you might have noticed from all of my mentions of crashes and workarounds etc., Microsoft has not put a great deal of effort into the BPA. Don’t expect too much from it and you won’t be disappointed.
• You will probably not be able to make every warning and error go away.
• Many of the recommendations are arbitrary.
• Many of the solutions cannot and should not be implemented universally.
• The BPA will sometimes return false positives.

If your boss has issued some mandate to fix every issue, then you should probably just quit your job. You can make things worse by trying to force the BPA to be happy. It is possible to make the BPA exclude certain results, if that would work out better for you. Just experiment a bit with the right-click in Server Manager and you’ll find what you need to do. There is a “Set-BpaResult” cmdlet that can modify results to exclude certain items as well, but it is tougher to figure out than Server Manager’s right-click menu. My personal preference is to generate a complete report and annotate why unaddressed items remain unaddressed.

Example items to leave:

• Ensure sufficient physical disk space is available when virtual machines use dynamically expanding virtual hard disks. This BPA result marks any and all dynamically expanding disks as a “problem”. They’re only a problem in such broad categorical terms for those institutions and administrators that aren’t quite ready for virtualization.
• VMQ should be enabled on VMQ-capable physical network adapters bound to an external virtual switch. There are multiple problems with this BPA result. First, gigabit adapters don’t need VMQ because it does nothing for them. Second, many gigabit adapters with VMQ enabled behave poorly. Third, and in my opinion most egregiously, this BPA was thrown on my system because my logical team adapter has VMQ disabled. The underlying physical adapters don’t support VMQ at all. Enabling VMQ on that adapter would be a bad thing for me. Following this BPA result’s advice would absolutely cause problems for my host.
• The Windows Filtering Platform (WFP) virtual switch extension is disabled. I am not using any WFP-based extensions, so I have no use for these extensions. I suspect that most of my readership doesn’t use WFP-based extensions, so you probably don’t have a reason to enable it either. If I installed a WFP-based extension and it didn’t at least mention that I needed to enable WFP extensions, then that would be a very poor WFP-based extension, wouldn’t it? So, can someone explain to me why it is considered a “best practice” to enable an extension that I am not using and will probably never use on the grounds that I might use it? In my mind, that is the opposite of a “best practice”.

The BPA does have its uses and you might find items that you need to fix. Do not be overly concerned about issues that it finds. Research them beyond just the recommendations that the BPA and its links present, and address items that have merit. Don’t expect the success or failure of your deployment to be closely tied to anything that the BPA reports.