Messages

Hey Mark,

Thanks for reaching out, please do send us those logs for further review!

However, there was an issue with our detection scripts and naming of that specific version (.52) where we had named it .55 by accident. This has since been fixed and we suggest deleting the application using the ConfigMgr Application Wizard then running a Publishing Service Sync to pull down the corrected package/detection for that product.

https://patchmypc.com/how-to-delete-applications-created-by-patch-my-pc-in-sccm

Completely understand the issue and thank you for bringing this to our attention! I see now how this can affect reporting and since the requirements are handling the architecture portion then the detection scripts should just identify and check for both architecture types.

We'll need to check and see how this will affect other products but now that this is on our radar, we can get it addressed! 

Hey Scott,

After talking with the Devs here, we may have some ideas of how to better tweak the detection logic to help in these scenarios.

Check back with us soon and we may have a solution for this!

At this time however, the suggestions above may help you in the meantime!

Hey Scott,

Based on this post it soundd like you're trying to install a 64-bit update on a 32-bit device (OS). Since those applications/updates can't be installed on a 32-bit OS the detection has been coded to show as not applicable when trying to install a 64-bit product on a 32-bit OS.

I would recommend create a separate collection with those 32-bit devices then target all 32-bit updates to that specific collection. That should help resolve any errors in the AppDiscovery Log since those updates will be applicable.

By default there are no requirement listed under the detection method. You may have the right click option enabled to set those requirements as shown below:



https://ibb.co/GRZqW6f

If you disable that option, then it will not apply to further application packages for that app. Then you can delete that requirement type from the existing package to install it on 64-bit devices.

[ConfigMgr Apps]

Hey RJ,

Thanks for reaching out!

I'll do my best to explain the main differences here but please feel free to reach back out if you need more clarification!

ConfigMgr Apps
- Provides the base installation package of the application which is Published under the Applications node in the ConfigMgr Console.
- Applications can be deployed using all 3 Intent methods (Required, Available, and Uninstall)
- If deployed as REQUIRED the application will forcibly install (If not installed) or update (If detected as installed) on the targeted client devices.
- Applications can also be used in Task Sequences for OSD. We can also update the Application package in place, providing you with the latest version that gets installed during that deployment.

Software Updates
- Provides the update .CAB file for the product which is first Published into your WSUS Database then synced over to the SCCM SUP during a SUP Sync.
- Update packages have Applicability rules defined in WSUS allowing them to only be installed if the client has the application installed and if that application version is older than what is being installed.
- Deployments of Updates can be automated by configuring Auto-Deployment Rules or ADR's within SCCM. https://patchmypc.com/how-to-use-automatic-deployment-rules-adrs-with-patch-my-pc

Overall, it's really up to you as an admin how you would like to handle deployments. I personally would recommend setting applications as available deployments (Required applications can be deployed as well to make sure they're installed) in Software Center and allowing your userbase to install any new apps that are needed. Then going forward, you can publish the update packages for those apps and deploy them during a certain period to update those Available applications. This process can then be Automated to using those ADRs mentioned above.


Just as a side note here that some products are only supported to be Published in certain ways as listed on our Supported Products page: https://patchmypc.com/supported-products

For example, some products can only be published as an Update Package (No application package is available) and vice versa. The Application Package is supported however, the update package is not.

Again, please let us know if you have further questions or reach out to our support email for further assistance!

[email protected]

[10.2.1]

It looks like version 10.2.1.20007 was an out-of-band patch that resolved some found vulns (CVE-IDs: CVE-2022-3602; CVE-2022-3786) which is also using the same major version product code. Because both versions are using the same product code (10.2.1) it breaks our detection.

For reference, I have included the link to our release catalog showing the previous version with CVE's:
https://patchmypc.com/patch-my-pc-catalog-update-11-02-22

Here is the link showing the most current release (10.2.1.20132):
https://patchmypc.com/patch-my-pc-catalog-update-11-09-22

To remediate this, we will either be adding the latest version 10.3.0 (If it's Stable - Pending confirmation) or included a Pre-Req script that will properly identify the 10.2.1.20007 version.

Hopefully that helps answer your question! Unfortunately, I wasn't able to find anything regarding the previous update .20007 just links back to the overall 10.2.1 release notes.

Hello and thank you for bringing this to our attention! We have checked and confirmed that Tenable released a newer version today (10.3.0) that should resolve this issue!

https://docs.tenable.com/releasenotes/Content/nessusagent/agent1030.htm

At this time, I would decline the current Nessus updates as to not cause further failures on pending clients. Once the new version has been added, run a Publisher sync and you should see the latest version being pulled in.

To keep tabs on catalog updates, you can visit our change log here: https://patchmypc.com/category/catalog-updates

Hey Ben,

Thanks for reaching out here! I have created the following idea on our uservoice page requesting the JRE version be added to the catalog. If/when it's been added you will receive a notification so you can enable it in the Publisher!

Here is the link to the idea: https://ideas.patchmypc.com/ideas/PATCHMYPC-I-2547

Let us know if you have further questions!

Best,

Spencer

Thanks for reaching out here!

In a Co-Managed situation, you have a couple ways you can configure this to work in your environment. Since SCCM is not handling Windows Updates, you can enable the Dual Scan functionality so that WSUS/SCCM will still push out Third-Party Updates while Intune will control your Windows Updates.

Here is the Microsoft Learn Document about the Dual Scan Feature - https://learn.microsoft.com/en-us/windows/deployment/update/wufb-wsus

This will allow you to control both Applications and Third-Party Updates via SCCM. Now when you're ready to switch the Client Apps workload over to Intune, then that will also allow you to deploy and control SCCM apps on a Co-Managed device. You can ALSO push both Apps and Updates from Intune to those Co-Managed machines making the need to enable Dual Scan obsolete.

Hopefully that helps you out here, however if you'd like more information on Co-Management Workloads you can reference this here: https://learn.microsoft.com/en-us/mem/configmgr/comanage/workloads

Also, feel free to respond back and we can always follow-up!

Hey joeOPD,

This is correct, if you have a group scheduled to deploy after 8 days and are syncing in new updates weekly (every 7 days) then that group will never receive those deployed updates.

You can mitigate that by changing the option for Automatically deleting assignments from older versions of the update/app when a newer version is published.

That way those group don't get removed and will still apply to the 8 Day staggered group when new updates are published. You will need to manually remove those group if you no longer need to deploy the update but that can easily be managed via our Intune Application Manager Utility: https://patchmypc.com/intune-application-manager-utility


This can be done globally in the Options menu or individually per app!

Global Options

Override Win32 Global Options

My pleasure! If you have further questions always feel free to reach out on any of our Support methods! 😊

If you're going to do it that way, then I would set the Publisher sync to run at least once a week. If you do it more frequently and updates are published, then it will override that set ring schedule and start from scratch.

If you change some of the default option under the Options menu in either the Intune Apps or Updates tabs, then you can make it, so assignments never get copied over to new apps or updates. This of course is more manual work as you'll need to manage and assign the groups to every newly published update.

However, I think just by changing the Sync Schedule to run at least every week that should prevent those issues from occurring!

Hello Hinkleyw,

Thanks for reaching out here! Best example I can give for setting up a "Ringed Deployment" Method for Intune would be to create at least 2 or more Azure AD groups which will act as your "Rings".

Then when you're adding your groups for the initial deployments via the Publisher's "Manage Assignments" template you can specify those groups for the selected deployment (If deploying updates then these can be applied at the top All Products level under the Intune Updates tab, as a required deployment to ensure all selected updates receive those groups during Publishing).

Once your groups have been selected you can then use the "Availability" options to stagger out the deployment of the updates to the latter groups.

For example, you have 3 groups selected as a Required Deployment for Intune Updates that are the following:
- Patching - Pilot Group 1 - Availability Time - ASAP
- Patching - Broad Group 2 - Availability Time - 3 days
- Patching - Prod Group 3 Availability Time - 7 days

Ringed Intune Groups

Once you have those in place then all your updates will adhere to that set deployment schedule based on the time that they're published.

For more information, please see the following KB article: https://patchmypc.com/custom-options-available-for-third-party-updates-and-applications#ManageAssignments

Hello,

This is a know bug that was in the 2.1.7 release. We have since mitigated this bug and have released the following fix in version 2.1.8

https://docs.patchmypc.com/release-history/production-releases

You can update the publisher via the "About" tab to the latest version. Once you've updated, you'll then need to republish all of the affected applications.

More information on republishing can be found here: https://patchmypc.com/when-and-how-to-republish-third-party-updates