Messages

[Create a new application without modifying any previous applications.]

Hi,

This post is just an inquiry for information and to gain some insights on best practices and to see how others are doing stuff.

During our onboarding session a couple of months ago, we didn't enable Updates for SCCM.
Meaning: Only Applications will be updated.
Also, I am one of those who is not a fan of ADRs anyway.

However, PMPC does not deploy the new versions automatically to the same collections as a previous version, like it is the case in Intune.

We have, during our onboarding session, set this option:
Create a new application without modifying any previous applications.

The default option, which is "Update existing applications metadata, deployment type, etc..." doesn't sit right with me.
I feel more comfortable having one or two previous versions of the application, just in case I need it.

I am wondering if ADRs are really the only feasible way to automate this in SCCM? Or should I change the way SCCM Applications are deployed.

I like what is happening in Intune...
You have a regular app and an Update app. The Update app has a requirement script which makes sure the app is only updated if the requirement is met.

Any update on this issue?

Hi,

Yes, it is solved already.
See my post above for the fix.

You will have two requirement scripts in the Intune app.
Remove the script for version 5.x and only leave one.
In my case it was: PowerShell requirement script for Zoom Meetings 5.17.34827

This is a one time thing.
Future updates will then not have an issue.

[Update]

Let us know what the resolution is, we're having the same issue.

Hi,

The issue is that the Published created two requirement scripts for the Zoom Update application in Intune.
The reason for this is that Zoom has change it's name. So, the PmPC team change the title of Zoom and the publisher searches for requirement rules to move over based on title, so it copied the Zoom Meetings requirement rule assuming it was a custom requirement rule.

So, it basically copied over the old requirement script from version 5.17.xxx over to the new version 6.
So, the application has two requirements scripts.
One for version 6.xxx -> returns Applicable
One for version 5.xxx -> does not return applicable

And because requirement scripts in Intune do an AND operation and not an OR operation, unless both scripts meet the requirement the app will not be installed.

Long story short...
Solution is to remove the second requirement script of version 5.xxx
In my case, it was: PowerShell requirement script for Zoom Meetings 5.17.34827

People that started to deploy Zoom via PmPC or people that didn't have an older version packaged already by PmPC would not have been affected.


Hope this make sense to you.

Not yet fixed.
What I did try myself though is running the requirements scripts manually on my device.

When I run the requirement script, it returns "Applicable".
However, when I run the requirement script in System context (with PsExec), it does not return anything.
Might be one possible cause. That the requirement script is not returning what it should.

My Zoom client v5 was also installed with PatchMyPC, it's not like I ran a different installer for instance.

I have created a support ticket. Thank you

[Zoom (64-bit) version 5.17.34827]

Hi,

We have the Zoom client available in the Comapany Portal for all.
And we have Zoom Updates configured in PMPC.
It worked fine in the past.

Now we have noticed that none of the Zoom v5 clients have been upgraded to Zoom v6.
Latest version is: "Update for Zoom Workplace 6.0.39959 (x64)"
There are two requirement scripts for these:

• Script PowerShell requirement script for Zoom Workplace 6.0.39959 (x64)
• Script PowerShell requirement script for Zoom Meetings 5.17.34827 (x64)

For instance, I have Zoom (64-bit) version 5.17.34827 installed on my device.
The Update app shows my device as Not applicable.

Looking at the C:\programdata\PatchMyPCIntuneLogs\PatchMyPC-SoftwareUpdateDetectionScript.log I see the following entries:

05/27/2024 07:02:36~[Zoom Workplace (64-bit) {cd2bhj23-d2tte-41cd-9c3b-81bdffd5hj8fb} 6.0.39647]~[Found:False]~[Purpose:Detection]~[Context:PC-MyHostname$)]~[Hive:HKLM:\software\microsoft\windows\currentversion\uninstall\*]

05/27/2024 07:02:37~[Zoom (64-bit) 6.0.39647]~[Found:True]~[Purpose:Requirement]~[Context:PC-MyHostname$)]~[Hive:HKLM:\software\microsoft\windows\currentversion\uninstall\*]

05/27/2024 07:02:39~[Zoom*(*  5.17.34827]~[Found:False]~[Purpose:Requirement]~[Context:PC-MyHostname$)]~[Hive:HKLM:\software\microsoft\windows\currentversion\uninstall\*]

If I interpret these logs correctly, it found "Zoom (64-bit) 6.0.39647" on my device. Which does not exist on my device and never has.

See attached screenshots...

Thank you for your extensive reply Dan.
To be honest, all my apps from the last 5 years have been packaged with PSADT, before we purchased PMPC.
I know how to easily fix these things with PSADT.
But I wanted to make use of the custom app portal now that is there.

I thought it was not possible to use PSADT as you could not upload folders to the custom app.
Didn't know about the workaround.
I also don't think this is an elegant solution to be fair. So for now, I will keep the app as is, deployed to user, and with a changed detection script.


The two applications are:
https://openstepviewer.com/
https://www.visual-planning.com/en/support-portal/vpdesk-new-launcher (this one does need to be deployed as user)

I will launch an idea for these two apps.

Hi,

We have used the PMPC portal to create custom apps successfully.
With two applications, which are kind of special I would say, we see an issue with the detection script.

The applications are simple MSI applications.
However, it has to be installed as user (/qn ALLUSERS=2 MSIINSTALLPERUSER=1).

But, after installation, these two particular applications create their entries in the HKLM hive:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\

The detection script fails to detect these application as it only looks in HKCU.

My workaround currently is to change script manually. Outside of PatchMyPC.

Line 16: [string[]]$HivesToSearch = 'HKCU'
Change to: [string[]]$HivesToSearch = 'HKLM'

This fixes the detection.

Three questions here:
1. If we make a request for you guys to add these applications to your catalog (they are publicly available), will you take this into account?
The application can be installed as user and as system, but our requirement is to install it as user.

2. Is there a better way to tackle this rather than having to make changes to the detection script?

3. Would it not be feasible that you add some additional options in the PMC portal that give us some more options. One of which is in what registry hive to search in? (I know, it's a feature request).

-----------

To elaborate on the first question...
If the application is installed as SYSTEM, on first run, the application runs a repair cycle to create the HKCU application configuration keys.
But, with Intune, after installation, the IMECache folder is cleared and the original install file is gone.
The repair then fails and prompts for the original install file.


Thank you

Hi PaulReid

That is correct, however they are no longer releasing updates for Windows installers which is why we have removed them.

Updates are irrelevant in this particular case. If the software is in the catalog, we can at least make them available for our end-users without having to package everything manually.

That is too bad.
You could have at least let the lates available version in there for those in need.

Hi,

We have a requirement for having older versions of Python available for install.

Python 3.7 up until 3.12 are available in the catalog.
However, only Python 3.11 and 3.12 is actually working.

When you double click on the other version in the publisher, there is no entry there with a Download URL, Command-Line, etc...

I would appreciate if you can fix this.
Thank you

[greater than or equal to]

Hi,

We are trialing PMPC at the moment.
I now that you only use scripts as a detection method.

I do have some questions though:
If a certain version of an app is deployed as required, to a collection and the software is detected.
And then a new version is deployed also as required, will the new version supersede the previous version?
Is the detection method checking for a static version or will it check that the version is greater than or equal to?
Will the deployment of the previous app be deleted with a new version?

The use case:
For instance, Draw.io ...
If I deploy version 20.1 to a collection as required.
Then a new version is deployed, let's say version 22.1.
Will the deployment of the old version detect the new version as well or will the deployment of the old version be removed and only the new version will be kept?
Or will the new version supersede the old version?
This to avoid an old deployment to overwrite/reinstall a new version.

Hope the question makes sense to you...


Another question...
When an Application is deployed to a user, a PowerShell detection script for that Application is run as that user. But this is an issue as this is blocked for us.
So, how will PatchMyPC fix this? How will the detection method work if an app is deployed to users?

Another question...
If PMPC creates an application and we change the detection method manually. How will PMPC handle the new version? Will it still create it's own detection method.

It would be good if not always a script detection method would be used but for instance checking a file version for greater than or equal to, or checking the version by querying a registry key.