OSD HP Image Assistant Revisited – Offline – HPIA Repo in CM Packages

From Series: OSD HP Image Assistant Revisited – an Overview – Page has link to GitHub & TS Exports

This is the last topic I’m covering, because it’s the most complicated one. This can look a lot of different ways depending on the way you want to implement. I’m going to demo two potential ways you can do it yourself, one using a one step to one platform method, and the other doing everything dynamically. If you have any questions as you work through the post, please let me know, it’s a lot of content to create, and sometimes in my head I might have covered everything, when in fact, I missed some steps in the post.

In this method, I’m using a 1 to 1 method. One HPIA Offline Repository for each Platform, but for all OS Builds (that you have in your environment). I’m supporting Windows 10 22H2 and newer, so that’s what my scripts will be showing.

Lets keep going on the same test machine, my HP Prodesk 400 G5, why, because it’s what I have on hand, and it supports Windows 10 22H2 and all the way up to Windows 11 23H2.


  • Creating CM Shell Packages
  • Populating Packages with Offline Repo Content
  • Task Sequence Requirements
    • Method 1 – Create the Steps to support each Platform
      • Add a Step per Platform, set a condition on the platform to match the Product variable.
    • Method 2 – Have a Dynamic Variable Step that Maps Package to Platform
      • Run Script to update variables in Child TS for Package mapping
      • Create step to create location variables for the content
    • Step to download HPIA and Run it based on variables.

Creating Shell CM Packages

First thing I do is create emtpy “shell” packages setting up a bunch of meta data along with the folder structure on my CM Source Share.

Script to Create Packages for Driver Packs & Offline Repos CM shell packages: garytown/hardware/HP/HPIA-BlogSeries-2024/Create-HPPackages.ps1

NOTE, the Description will list ALL Models that the platform supports. Often times a single platform will support multiple models, as shown by this next example, Platform 896D

I use the Platform (Product Code) as the main mapping method. Each package has a program that does nothing, but allows the package to be used in a TS without being deployed.

The script will automatically create several fields and the associated programs. These fields are then used in other scripts.

Now that you have your packages, you’ll want to populate them. You can do this manually using HPCMSL, or you can leverage a script I have which will read the packages in CM, and then prompt you for which ones you want to update.

Populating the CMPackages with HPIA Repo Content

Script on GitHub: garytown/hardware/HP/HPIA-BlogSeries-2024/Populate-CMPackages-HPRepo.ps1

First you’ll be prompted to choose your Dev or Prod packages, I’m going with Dev:

Then you’ll be prompted to pick which Platform to setup / update. I’m choosing my test device, but you could pick all of them if you wanted, but I don’t want to wait, so I’m picking just my single device.

Next it starts to build the repo for the platform and OS build I told it to, using this code, it’s grabbing all of the Windows Builds greater than or equal to Window 10 22H2 (19045)

So if you’ve been going through the process, this code should look familiar, so instead me restating a lot of the same information, please look at the previous post concerning creating Offline Repos.

Now that it is complete, lets look at the package in CM. You can see the Version field has now been updated to show which Windows Builds are supported by this Repo, and it sets the MIF Version to the date it was last updated. MIF Publisher is set by the person running the script to modify the package. To support those 4 different Windows builds, the repo size if just over 2GB. If you want to take this to the next level, you could WIM it, but I’m not getting into that here.

Looking at the content created, the script also creates a .Readme file which some extra information, I find this handy when the package has downloaded into the CM Cache, and you’re troubleshooting, it will show the Package ID, last modified by, and the Platform & OS Build it supports.

Ok, so now we have a CM Package that consists of an HPIA Offline Repo. Now it’s time to head over to the TS to see how we can leverage this.

The Task Sequence

This is where it’s really tricky, as you’ll have several packages, one per platform, just like you do for Driver Packs. I’d recommend managing these packages the exact same way you manage your driver packs. If you list each one in your TS, or have a Sub TS that maps them all, do what works for you. I’m going to go over two methods, one where you create a step per package and set a condition based on the platform, and a more advanced method of dynamically downloading the content based on variables. Pick the one that works best for you, or your own thing.

Simple – 1 Step Download Per Platform

I’m using the Product Variable, not a default one, but one I create using Johan’s script: Gather-Script-For-ConfigMgr-TS/Gather.ps1 earlier in the TS. The Download HPIA Step should be familiar if you’ve been following along in the series.

Lastly, the passing these variables into the HPIA command line:

Advanced – Dynamic Download

I have a “Child TS” that maps the Offline Repo CM Package back to the Platform. From the image below, you can see the mapping from the Shell Packages we created. If the device is a specific Platform (859C as in our testing), it will map several items, the most important one being OfflineRepo_ID = ‘MCM003E1’, which is how we know which item to download.

Script to update the Steps with proper information. garytown/hardware/HP/HPIA-BlogSeries-2024/Set-TSVariablesRepoID.ps1
For that script to work, you’ll need to either import the export of the TS’s I’ll be providing, or create those step names correctly, so the script picks them up. When you run the script, it gathers information from the CM Packages and updates the variables in the Task Sequence step.

Now that OfflineRepo_ID is set, we can map that to a precache variable PRECACHE001 which will then be used in a dynamic download step

So now we’ve downloaded the Offline Repo CM Package dynamically, we just need to find where CM put it, and map that to a variable called “DRIVERS01”

Then the next step is grabbing HPIA

Now, we just need to call HPIA, so we could just run a command line step like we have in the past 3 posts, or since we’re already getting fancy, lets do this in PowerShell, and add the HPIA Progress Bar, and some extra logging. We’ll pass in the variables for the HPIA location and the Repo Location.

Script on GitHub: garytown/hardware/HP/HPIA-BlogSeries-2024/CMTS-RunHPIAStep.ps1

So now you’ve seen several ways to use HPIA in your OSD Task Sequences, and much of this you could leverage on already deployed machines to update their drivers. Feel free to reach out with questions.


2 thoughts on “OSD HP Image Assistant Revisited – Offline – HPIA Repo in CM Packages”

  1. Hi Gary,

    I wanted to express my sincere appreciation for your website and content. It feels tailor-made for me! Your insights have been invaluable in my new role, covering relevant and helpful topics.

    I do have a couple of questions, and I apologize if you’ve already covered them:

    1. Regarding TS Debugging: Your debugging approach is impressive! Could you share the tool you use? I’d love to incorporate it into my development environment.
    2. HPIA Offline Repo Implementation: I’m interested in setting up an offline repo for HPIA with multiple Microsoft Configuration Manager distribution points. Do you have any recommendations on how to achieve this without relying on a single source location?

    Thank you once again for your fantastic content!


Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.