Nutanix Prism has a neat Health check dashboard. From here you can find out what errors you have in your environment.
The health checks can be either run individually or you can opt to run all checks.
I was trying to upgrade the version of Acropolis to version 5.0.2 and it failed. The reason that the upgrade was failing was due to an inconsistency between each of my Hyper-V hosts. When looking at the Health dashboard I had the “Hyper-V Host pending reboot check” fail.
During one-click NOS or Acropolis upgrade, the Hyper-V utilities (sas2ircu.exe, sas3ircu.exe, Megacli.exe, LsiUtil.exe) might not display any disks or controllers although the disks or controllers are physically attached to the Hyper-V host.
This issue might occur on Hyper-V hosts that have pending restarts after Windows cluster aware or other updates. In this case, the check returns a FAIL status.
I knew that I had not installed any software or updates to the Hyper-V hosts, and had already checked the disks and controllers.... so I proceeded to do a precautionary reboot of the two hosts after shutting down the associated CVM's.
After the reboot I logged onto the two hosts to confirm that everything was running correctly and that the CVM's had started up. I then ran the individual check again... it again failed.
When you get a Health warning or failure in Prism, you also get a nice link to a Nutanix KB article to help with troubleshooting. In my case it was KB 2713, this article mentions about the disk/controller issue and also that it may be due to a pending reboot. Now we had just rebooted the two hosts so why was it still needing a reboot?
The KB article advises to run the following PowerShell command to identify any files that are pending a file rename operation:-
Get-ItemProperty -Path 'HKLM:SYSTEM\CurrentControlSet\Control\Session Manager' -Name PendingFileRenameOperations | select -Expand PendingFileRenameOperations
If any files are pending a rename they will be listed out.... if not you will get an error as the registry key will not exist.
When I ran the command I was surprised to get output listing files that needed to be renamed similar to below...
Reading further into the KB article I found that this is due to printer drivers being installed....and can be caused if you have a GPO that pushes printer out to users on logon.
In my environment this is not the case... so what was installing the printers?
What I found was that my default settings configured in my Remote Desktop Client had a tick in the box for making local printer resources available in my RDP session.
By default the printer and smart card were ticked and every time that I logged onto one of the Hyper-V hosts it was installing the drivers, thus files were pending a rename and the check was failing.
I followed the articles advise and set the "Print Spooler" service to manual, then I also cleared the tick box for resource redirection for local printers in RDP.
Then once more rebooted the affected Hyper-V hosts.
This time the check completed without an issue and I was then able to upgrade to version 5.0.2 of Acroplois.