The Get-SPHealthScore power shell commandlet is a simple commandlet that will query the value of the health score for any SharePoint 2010 URL (providing the header hasn’t been removed for security reasons which I will discuss in a later post).
$request = [System.Net.WebRequest]::Create($url)
$request.Method = "HEAD"
$response = $request.GetResponse()
if(($score = $response.Headers.Get("X-SharePointHealthScore")) -ne$null)
Write-Host 'The specified URL is not a SharePoint 2010 site or does not contain a health score'
If you’re not familiar with the health score header, it is added to any SharePoint response for use by Microsoft Office applications in order for them to reduce their request rate if the server is particularly busy. The score ranges from 0 – 10 although the server would unlikely respond with anything higher than an 8 as the higher the value, the busier the server up until the request is throttled.
After moving a few Windows Server Hyper-V hosts recently from one Virtual Machine Manager server to another, a couple of virtual machines started exhibiting some strange behaviour in regards to networking. So I break out trusty “ping” and it doesn’t report any problems. At that point the remote desktop session is working again so I lost interest assuming it to be “one of those things…”.
After a couple of days this started happening more and more. It wasn’t till I needed to do something one of the servers using remote desktop that I noticed the machine I was expecting to connect to wasn’t the machine I got. At this point it started making a little bit of sense and on inspecting the mac address to look-up the DHCP lease that I realised what it was.
Unlike physical machines, virtual machines do not have hardware generated mac addresses for the network adapters, instead they are taken from a pool of possible mac addresses which can be modified in Hyper-V. Normally Virtual Machine Manager will take care of this for you however as the virtual machines existed before the host was linked to the new Virtual Machine Manager, the issue wasn’t resolved automatically… or highlighted for that matter in the management console (anyone know if you can write your own jobs?).
The fix in my case was to shutdown the virtual machine and remove the network adapter assigned to it and add another. Now you could just change the mac address yourself if you wanted but the adapter in question was legacy so for me it was easier to replace with a synthetic adapter. If you do change the adapted and you were previously using a legacy network adapter also check if you have the option to upgrade the client additions before starting the virtual machine again, as the drive may not be present for the new adapter.