Dell PowerEdge BIOS failed due to IPMI driver

I was updating the BIOS on a couple of Dell PowerEdge R620’s today and was presented with an error I hadn’t heard of before:

IPMI driver is disabled. Please enable or load the driver and then reboot the system.

This was very odd. A little bit of searching showed that there should be an IPMI driver service running in Windows, so I checked that:

Service 'ipmidrv (IPMIDRV)' cannot be started due to the following error: Cannot start service IPMIDRV on computer '.

Knowing this was a driver, I went to look in Device Manager, and was quite surprised to find this IPMI driver listed:

This is a Dell PowerEdge, I have no idea how this HP driver got installed – I’m not even convinced it wasn’t there prior to the other driver updates I was performing. In any case, this device wasn’t starting properly, and was preventing the service from starting. I uninstalled it and the driver:

Following this, the appropriate device appeared under “System Devices”:

Now I could start the service, and the BIOS update proceeded properly.

Powershell command as scheduled task

Here’s the syntax to use a PowerShell command in Task Schedule action, rather than a script:

Program/script:

powershell.exe

Add Arguments:

-noninteractive -executionpolicy bypass -command &{Checkpoint-VM -Name pxetest -SnapshotName 2018-06-23-PreMaintenance}

 

The key here is the ampersand before the command – when I was missing that it would not run.

 

 

SharePoint library column missing

I’ve been working on migrating documents between document libraries in a SharePoint site, and have randomly struggled with an odd issue.

In the new destination library, I’ve configured a managed metadata column based on a term store, and made it mandatory. This column does not exist on the source library.

For the majority of my documents this has been working well – after moving or copying the document I set the column value with the quick-edit info pane. However, some of the documents have a blank value rather than showing “Required Information”:

click for bigger

When I view the properties of the document on the quick-edit pane, the column doesn’t appear at all!

The root cause is that these problem documents carried over their Content Type with them into the new library, and this content type does not have the managed metadata column added to it. However, it isn’t immediately clear this is what happened because the default setting on this library is to not manage Content Types individually.

To fix this, I went into the advanced library settings, and chose Yes for “Allow management of content types”:

Once I did this, the extra content type appeared in the settings page:

click for bigger

Now when I go back to my document and open the quick-edit pane, there is a new option to select Content Type, and I can set it back to the default:

This then updates the list and puts a “Required Information” block in that column, and allows me to fill it in.

 

AppAssure Agent service not started

I have found in recent experience that the Quest RapidRecovery/AppAssure agent service frequently fails to start within the default Windows service startup timer (30 seconds).

I don’t believe this is simply my environment, as Quest has a knowledge article specifically addressing the problem.

This issue poses a problem especially after Windows Updates maintenance windows, because our hundreds of virtual machines will reboot, leaving our monitoring system with hundreds of alerts of stopped services, and many failed backups.

Unfortunately, Quest’s recommendation to simply increase the services startup timeout is system-wide, and not something I was willing to apply in full across my entire environment.

My first thought was to utilize the Recovery options with the Windows service, but upon quick inspection its clear this is only for failed services, and a service that isn’t started does not fall into that category.

Instead I decided to set a GPO with a service preference, with service action set to “Start Service”. This way, every time Group Policy is refreshed, if the service isn’t running it will be started.

The GPO itself has a bit of logic to address the AppAssure/Rapid Recovery upgrade we’re going through right now, which results in a service name change for the agent.

To accomplish this, I created two separate service preferences, each with some item-level targetting for registry matching to ensure it only applies if that service does exist (to avoid spamming Event Logs). This takes advantage of the fact that the AppAssure Agent doesn’t record a product version in the registry:

AppAssure Service

  • Service Name = AppAssureAgent
  • Match if KeyExists HKLM\Software\AppRecovery\Agent
  • AND if not ValueExists HKLM\Software\AppRecovery\Agent\ProductVersion

Rapid Recovery Service

  • Service Name = RapidRecoveryAgent
  • Match if ValueExists HKLM\Software\AppRecovery\Agent\ProductVersion

Update Quest RapidRecovery Agents silently

I’m in the process of upgrading AppAssure 5.4.3 agents to the latest version of Rapid Recovery, 6.1.3. This is done following the Core upgrade.

So far my progress has been pretty seamless. In testing I confirmed that I could push the install with a “No Reboot” force, and the agent would continue to operate normally until the next system reboot (which will occur as part of monthly Windows Updates).

This script is in no way ‘complete’, as in it could be made much better. Additional logging on success or failure, parallel processing, etc could all be done -however for simple purposes it worked quite well.

# begin a transcript to log the output to file
Start-Transcript C:\Temp\AgentUpgradeLog.txt
# Define the list of systems to update
# Gather list of older version from Rapid Recovery Licensing Portal
$systems = Get-Content -Path C:\Temp\AgentServers.txt
 
foreach($system in $systems) {
#Write-Host "Testing connectivity to $system"
$rtn = Test-Connection -CN $system -Count 1 -BufferSize 16 -Quiet
 
IF($rtn -match 'True'){
 Write-Host "ALIVE - $System"
 copy C:\Temp\Agent-X64-6.1.3.100.exe \\$system\c$\temp -confirm:$false
 $executable = "C:\temp\Agent-X64-6.1.3.100.exe"
 $session = New-PSSession -ComputerName $system 
 # Key here is the /silent and reboot=never switches
Invoke-Command -Session $session -ScriptBlock {Start-Process $using:executable -ArgumentList "/silent reboot=never" -Wait}
 remove-pssession $session
 Write-Host "$System - upgrade steps completed"
 sleep 5
# Found that we had agent services not starting following the upgrade
 get-service -name "RapidRecoveryAgent" -computername $system | Start-Service
 }
 
else
 {
 Write-Host "DOWN - $System"
 }
 
}
 
Stop-Transcript