Important Notice: On February 29th, this community was put into read-only mode. All existing posts will remain but customers are unable to add new posts or comment on existing. Please feel to join our Community Discord for any questions and discussions.

Feature request: Get package version in PowerShell step

Thorsten Windrath

May 24, 2019 10:51

I need to manage a lot of versions of the same software for historical reasons. It would be super-handy to catch the package version (and maybe other package attributes like the package name) from within a PowerShell or Command step. Alternatively, per-package variables should work well too.

A sample use-case:

I've got a file share with more than 20 versions of MathWorks MATLAB and MATLAB DCS for different architectures and operating systems
If I could catch the version attribute (and maybe other variables), I could automatically mount the correct ISO image

The only way I could think of is to copy an additional file, which could contain informations about the version that needs to be installed. Even a simple database query against PDQ Deploy's internal database doesn't seem to be possible because there's absolutely no information available that could identify the package that is currently processed.

Am I missing something? Is that already possible out of the box?

Comments

2 comments

Patrick Pierce
May 28, 2019 21:11

Sounds like collections, deployment conditions and schedules.

This post may help you. It covers setting up a dynamic collection and using collections linked to it. I would check to see if you can create a collection for the application, then filter down. You can see I have different versions of Probook 440 and split them into different groups base on the version. This allows me to push the correct drivers to the correct model. https://community.pdq.com/posts/11270#11271

Here is a post about creating reports for an application and finding the version. Not what you asked, but it shows the conditions for application version. https://community.pdq.com/posts/9876#9878

I may have read the original post incorrect. Let me know if this is not what you are asking.

0
Thorsten Windrath
May 29, 2019 09:16

Thank you, @Patrick. This may come in handy when I need to uninstall a package (can you actually run a package against a dynamic collection? I've only used the free version in the past and just got the clearance to buy the full one today.)

Anyway, I'm afraid that your answer doesn't cover my question. Should have been more clearly I guess, just blame my bad English 😃

Just imagine that I want to maintain n versions of, let's say, Matlab. There are cases where I even need to install multiple versions on the same machine. My current workaround is a custom PowerShell script which has 2 variables on top ($arch and $release, for example "win64" and "r2017b") to determine which ISO the script later loads.

This means that I need to enter the same information (arch and release) 3 times per package (title, version and my script) which could easily become something someone may stumble upon in a few years.

So my original question simply was: Can we have per package variables for fields that already exist in package definitions (version and title for example) so we could use that in steps that supports variables?

0