Recently we received an alert from HP that there is a huge battery recall that is affecting a lot of their laptops. We are in the process of putting together all of the information for this project so we can schedule and complete this work for our clients.
Has anyone begun to work on any type of automation for this testing and listing of all the systems that meet the criteria for the battery replacement?
We would like to know if anyone has been able to script in part or fully the setting of the battery in test mode and then running the command necessary to test if the battery meets the criteria for the recall.
I have not heard about this recall.. can you share web links as II have some in my environment
do you have more information on this recall? Weblinks? affected units?
Haven't started building the automation for it yet. I think we'd need to identify models that are potentially impacted first and build a view for them. Possibly leverage a procedure to populate a custom field to build the view from? Then run the fully loaded utility (link available in this article batteryprogram687.ext.hp.com) to ensure the basic system requirements for the utility (like .Net 4.5.2) are met.
It seems the challenge from an automation standpoint will be capturing the output and getting it added to a custom field so you can report and filter off of it. I ran this on my own HP Laptop and the "output" is a popup that basically says you're good or you're recalled. I'm not sure this is something we would be able to get the output saved into a file for.
I wonder if you can run the update from a command line and echo to output to a text file? if so, then you can read the text file and get it into a custom field
See : batteryprogram687.ext.hp.com
There is also a tool you can download from this site, I recommend the Full version : batteryprogram687.ext.hp.com/.../HP.BRCU.Full.Installer.exe
You can silent install the tool with : HP.BRCU.Full.Installer.exe /s
When installed you can start the tool from command line using : C:\Program Files (x86)\Hewlett-Packard\HP Battery Recall Utility\HPBRCU.exe -s -p:c:\temp\hpbrcu
-p = output dir .. the tool creates a .xml file that contains info about the machine and if the recall is applicable.
The details for the recall can be found here batteryprogram687.ext.hp.com/en-US . I have tested this with my HP laptop and was able to return a status from the application GUI. You are able to output the details to an xml file via command prompt silently. At the moment I am running the following which can be automated with Kaseya. I have not implemented the custom field to associate the returned status yet but it seems very possible to get the rest completed. We are on SaaS so we don't have access to the SQL side as on prem would.
1.Upload HP.BRCU.Full.Installer.exe to shared folder
2. copy file to local machine
3. run shell cmd HP.BRCU.Full.Installer.exe /quiet
4. run "C:\Program Files (x86)\Hewlett-Packard\HP Battery Recall Utility\HPBRCU.exe" -s -p:c:\kworking or other folder of choice
5. read xml details and look for line 10 <PrimaryBatteryRecallStatus> </PrimaryBatteryRecallStatus>
I did check that at least the "fully loaded" utility *does* support some commandline switches
/quiet /norestart /install works to get it silently installed, then the same with /uninstall instead of /install works to remove it.
Then running the utility from it's installed location with the -s switch results in it running silently and outputting it's data into an XML file in the current working directory. The main challenge will come in the fact that the XML file will be named with the serial# and a timestamp... For example the test machine I just did ended up naming the file:
You can also specify another commandline option of -p to specify excactly what *folder* it shoudl store that XML in.
So in theory.... The script would logically look like this..
geturl - to download the full package
execute file and wait for it to finish for the downloaded file with the /install /quiet /norestart switches.
execute file with the resultant installed utility with the -s -p commandline switches to throw the XML output into your kworking directory (maybe a subdir to make sure that it's the *only* xml file in there).
A powershell command to get the only XML in that directory and load it up into an object using the built in XML parser.... (For my example I name the variable $doc).
Then pull $doc.HPNotebookBatteryValidationUtility.SystemInfo.NumBatteriesDetected.
If that is 1 then look at $doc.HPNotebookBatteryValidationUtility.SystemInfo.PrimaryBatteryRecallStatus
If it is 2 then look at both that *and* $doc.HPNotebookBatteryValidationUtility.SystemInfo.SecondaryBatteryRecallStatus.
I'll take a look and see if I can pull this together as it's something we would find useful as well since we primarily sell HP laptops
I've got something thrown together and working right now. I'm doing a bit more testing on it and then I'll share.
I've run this against about 2 dozen machines so far with good results.
I'll get it shared on the automation exchange later today. With my setup I created a new system info field called HPBatteryRecall as a numeric field. It's blank for anything that hasn't been run yet, and a 1 if it needs a recall and 0 if everything is good.
I also created a powershell script that parses the results from the XML file. I run through the steps I outlined above, and then at the end it updates the systemInfo Field as well as writing to the procedure Log, and pulls back a summary to the "GetFile" folder for additional details.
Finished procedure is uploaded to the Automation Exchange.
Since that approval process takes 24-48, I'll upload it here for now too.
It's approved in the automation exchange now... However I may be updating it again tomorrow morning. It's functional the way that it is, however I may take things one step further. I scheduled it against all 300+ HP laptops in our environment through the day today. Of the 145 that it's run on so far, it did finally locate *one* that it shows is affected by the recall. I knew my logic was sound, but this was the first time I was able to find a positive return for a battery that needs replacement. In the output of the XML, it actually gives an exact *URL* to go to in order to order the replacement battery.
Given that I'm going to likely at another statement that will email the admin who schedules the procedure with the machine name and the exact link to order the replacement battery.
Hey Jonathan, Thanks so much for sharing your procedure! Did get a chance to update it to include the additional statement about emailing the admin?
I've updated the download in the Automation exchange this morning, so as soon as it gets approved and "relisted" it should be there. It also has the small change I made to my powershell call where I found that it was failing on about 1% of the machines I ran it on because powershell.exe was not in the "path" for the system user. So far on it's successfully run on 187 laptops in our client-base and found 1 that actually is subject to the recall. It still has a number of machines to run on that just haven't been online since I scheduled it.