Messages

This is great news, Matthias! I'm happy this works fine for you now!

[1602 (0x80070642)]

hey mdigrego,

This is a great question.
If you navigate to the Intune Portal --> Apps --> Windows Apps --> select the app you are interested in --> under "Overview" you'll find the Device status. It will show you on how many devices the software was successfully installed, on how many it is still in progress and on how many it failed.

If the user defers the installation, Intune will mark it as an installation failure.
Any installation failure marked with exit code 1602 (0x80070642) means the user deferred the installation.
PatchMyPC-ScriptRunner – Known Exit Codes

that is correct.

In addition to adding the app under "blocked apps", please make sure to deploy the software as required to the same group the Enrollment Status Page profile is deployed to.

Then Intune will only evaluate that single app during Autopilot.

[all]

hey mguenth83,

During Autopilot, Intune will evaluate all win32 apps that are deployed as Required to all your devices.
In your case, I assume all Intune Updates you package through the PMPC Publisher are deployed as required to all your devices.
This will slow Autopilot down, because the more Intune Updates you deployed through PMPC, the longer it will take Intune to evaluate all of them during the enrollment of the device.
The Intune Updates are win32 apps as well, so Intune thinks it needs to evaluate them as well during Autopilot.

Having Intune Updates being evaluated during Autopilot is not necessary, as they won't apply anyway.

The best option to go here is to have one app, maybe Company Portal or anything else, deployed as Required to All Devices and then marked as a "blocking app" in your Enrollment Status Page.
Intune will then evaluate that win32 app only.

[Required]

hey mguenth83,

We recommend configuring "blocking apps" in your Enrollment Status Page. You can find more details here.

Please ensure that you deploy any software you specify as "blocking app" as Required to the same Autopilot device as well.

By doing, only the apps you select will be evaluated during the enrollment of the device. The rest of the apps will be evaluated by Intune after the device is enrolled.

Hey TJ2940,

In addition to my colleague's reply, I would recommend checking a few other things:

1. Check if your CMG is being rate-limited.
2. One fact to take into account is the internet speed, depending on the region.
3. Consider splitting the deployment package up. To avoid this issue from happening, I would create multiple ADRs, for instance:

• One ADR with all PMPC browser updates (chrome, firefox, edge, etc)
• One ADR with all JRE and JDK updates
• One ADR with all the remaining updates

This is only an example, you can group the updates in any way you like.
We have a guide that talks about how to include or exclude updates in your ADR, you can find it here.

Finally, if the situation doesn't improve, I recommend reaching out to Microsoft and have them check if there are other issues in your environment that might reduce content distribution performance.

Hey Paul,

We have reinstated Vmware Workstation in our catalog with yesterday's catalog release.

However, you will have to manually download the installer and place it in the PMPC Publisher's local repository folder.
Broadcom doesn't offer a direct download link at the moment, so we can't automate the download.
Local Content Repository for Licensed Applications that Require Manual Download

Hey Paul,

somebody just reminded me that Broadcom have bought Vmware and pretty much demolished all things vmware in the transition, so there is likely a broken link involved there somewhere.

This is exactly the reason why.
None of the download links work anymore.
We are monitoring the situation, and as soon as the vendor fixes them, we'll update our catalog.

We are at the vendor's mercy for now, unfortunately.

Hey there iceman  ,

My logical assumption here would be that I need to apply the same customisation to the "Update" version of the app as well, but thought I would sense check first of all before applying and waiting for the next update to be released to test.

You are correct, you will have to apply the same command line customizations to the update too.
After you apply the customizations, you will have take some other actions for the changes to take effect:

• If the update is published to WSUS, you will have to republish it.
• If the update is published in Intune, then you will have to delete it, and then trigger a sync from the PMPC Publishing Service to get it re-packaged with the updated configuration.

Hey Jemkey,

The latest Docker version is now in our catalog.

[Disable Self-Updater]

Hey PaulKlerkx,

The Disable Self-Updater option only works for software that allow the configuration of the software updates check by setting an argument or a registry entry.

Handbrake, Keepass and Audacity don't. If you right-click on them in the Patch My PC Publisher, you'll find that Disable Self-Updater option is greyed out.
As I mentioned, this is due to these installers not supporting configuration of the self updater via command line or registry.
As an example, to disable the automatic check for updates for Audacity, you will have to update a Config file in the USER %appData% folder. More details here.
ConfigMgr / Intune will install the software as the SYSTEM account. To update files for the other user profiles you will have to use a custom script.

This should not apply to Google Chrome, however.
To troubleshoot this, we will need more details.
Are you deploying Google Chrome from ConfigMgr or Intune?
Are you deploying it as an Application or as an Update?
We also need some logs from the client side: Collecting Log Files to Send to Support for ConfigMgr and Intune
Once you have the logs, please open a support case.

Hey PaulKlerkx,

Software with special install behavior are documented in the Known Issues and Considerations when Using Patch My PC article.

Perfect! Great news! 

Thank you again for reporting this to us and for the feedback as well!

The command-line change is now part of our catalog as well, with yesterday's release.

Hey Bjerring,

By default, we are using the /AHMGUK argument for the silent install.
Based on the vendor's documentation, the /N* argument should create the shortcuts for all user profiles, otherwise they will be created only for the user running the install (which will be SYSTEM via Intune).

We'll add this additional argument on Thursday, but if you don't want to wait that long, right-click on Total Commander in the PMPC Console --> modify command line --> type in: /AHMGUKN*
Delete the app from Intune and then republish it from the PMPC Publisher.