Messages

Will do, thanks.  I assumed it would recreate the intunewin file and upload it to the same app, or create a new app and copy the assignments over like it is set to when an updated app is created.  If that's not possible, you might want to consider a pop up notice when making changes to an intune app's settings that tells users that we will have to delete and republish the app for the change to take effect.

I have published UltraVNC to Intune using the PatchMyPC Publishing service.  After testing the install on a client, I changed some of the settings for the app in the PatchMyPC Publishing settings (Added an inf file to include and added the /loadinf parameter to the command line).  After running a publishing service sync, I tested the app install again on a pc, but it doesn't appear to have used the updated command line or inf file. 

Looking through the patchmypc log file (attached), I see when the sync ran it updated the updated command line argument and the additional file on the package source for configmgr and triggered a package refresh, but when it gets to the intune part it just says that the app is already published, with no indication that it sees changes which need to be published to the server.

Ahh, I didn't realize that subscription was required for using SCCM's Third Party Updates feature, I thought that was just for your auto-publishing service.  That would explain the failure!  I will continue using SCUP for the time being then.  Perhaps if/when a future version of SCCM improves on the feature and eliminates a step or two from the process, I'll revisit the issue.

Thanks for the fast reply!
Steve

I've been looking forward to SCCM 1806, so that I could use the new Third Party Updates feature instead of SCUP to import the PatchMyPC catalog. I was able to add the custom catalog successfully, but when I try to subscribe to the catalog I'm getting an error. 

Unable to create the subscription.  The console failed to download "PatchMyPC Updates" from "CATALOG URL" because of error code 193.  For more information, see SMSAdminUI logfile.

The log file referred to in the error message only contains one line related to the subscription attempt, which is not at all helpful:

[84, PID:5328][08/06/2018 10:38:37] :error in downloading

As a test, I pasted the catalog URL into Internet Explorer, and successfully downloaded PatchmyPC.cab, so the URL seems to be correct.

Does anyone here know what the error code '193' represents? 

What could be causing this to fail?

Edit: I just found the new guide you posted for this.  I decided to add the trial catalog, as the video demonstrated.  After adding the trial catalog, I was able to subscribe to it successfully.  I imported my patchmypc catalog URL in SCUP (my previous SCUP db was lost, so when I launched SCUP it was a fresh instance with no catalogs configured.), and it successfully imported the catalog contents. So, again, this would seem to confirm that the URL is valid, as I was able to import it in SCUP.  It's only SCCM that fails to download / subscribe to the catalog. 

Thank you, that explains things somewhat.  It does seem odd to me though that a release which is recommended only in select cases is being recommended by Java.com.  I also found this link which identifies which versions are PSU/CPU, along with the release timing.  Based on that, it looks like this is the first time a PSU release has been released to Java.com.  That would explain why I haven't seen this version discrepancy previously.

Perhaps if a PSU version is released to Java.com, it should be added to the catalog, but marked as optional in some way?  Or at least not expiring the current CPU release at the time?

Someone pointed out to me today that Java 8 update 66 has been available for download since early November, but we're running v8.55.  Looking in SCUP, it appears that PMPC hasn't put out an update for 8.66.  Was that an oversight, or is there a reason it was left out?

Thanks!

I think we're at a point now where we can deploy Java 8 without breaking anything, but now that I'm ready to do it, I wonder about the best way to do it.  Java 7 updates have been coming via the patchmypc catalog, so I don't have an application in SCCM for the version of Java 7 currently installed on our workstations.  That means I can't mark the Java 8 application as superseding the Java 7 application.  I considered just adding the guid for the Java 7 version to the "installable rules" for the java 8 update in SCUP, but would that uninstall Java 7 in the process or simply install Java 8 along side 7?

At this point, I'm thinking my best option would be to create an application for Java 7 update 71 (we hadn't moved up to 75 yet), and use it just for the sake of being superseded by the java 8 application, to be sure it uninstalls. 

Thank you for the response.  I can't speak for others of course, but for my situation I would rather accept the potential for data loss get updates installed when they're supposed to.  For one, the risk of data loss from killing open browser is lower than the risk if we just force logoff the user's windows session, which is the other option we've considered in order to ensure patches deploy successfully.  We send notices to all users reminding them when we have patches going out overnight, and tell them to log off of windows but leave the workstations turned on overnight.  If they ignore the notice or forget to log out and lose an open browser session as a result, I'm not going to lose sleep over it. 

Of course, not every organization would feel the same way, which is why if you ever do consider something to kill open browsers, it should definitely be an option, and not a default action. 

I have just started using the update catalog, and am getting the same 2 errors for ultraVNC, as well as similar errors for updates to a few other programs:

PublishItem: --- Digest verification failed on content for software update 'Java 7 Update 67 (UpdateId:'230a5b3e-b3a0-423e-9f8e-75239db7b529' Vendor:'Oracle' Product:'Java')'.   Updates Publisher   8/29/2014 11:18:48 AM   9 (0x0009)

PublishItem: --- Digest verification failed on content for software update 'Chrome 37.0.2062.94 (UpdateId:'77662cb8-7724-4e46-ace8-b49e72b909f3' Vendor:'Google' Product:'Chrome')'.   Updates Publisher   8/29/2014 11:41:50 AM   9 (0x0009)

PublishItem: --- Digest verification failed on content for software update 'Quicktime 7.75 (UpdateId:'eeff65e0-1c04-43fb-9826-c2146b20f3b1' Vendor:'Apple' Product:'Quicktime')'.   Updates Publisher   8/29/2014 12:04:22 PM   9 (0x0009)

PublishItem: --- Digest verification failed on content for software update 'UltraVNC 1.2.0.1 (x64) (UpdateId:'9e3b88da-9cbe-4ffd-8eab-51add9cc49ba' Vendor:'Uvnc Bvba' Product:'UltraVNC')'.   Updates Publisher   8/29/2014 12:06:17 PM   9 (0x0009)

PublishItem: --- Digest verification failed on content for software update 'UltraVNC 1.2.0.1 (x86) (UpdateId:'d7150315-6d3a-48fb-ae89-ee982a2fd933' Vendor:'Uvnc Bvba' Product:'UltraVNC')'.   Updates Publisher   8/29/2014 12:06:16 PM   9 (0x0009)

PublishItem: --- Digest verification failed on content for software update 'RealPlayer Cloud 17.0.10 (UpdateId:'a5be2a68-1334-4696-84ba-5e074b175492' Vendor:'RealNetworks, Inc' Product:'RealPlayer')'.   Updates Publisher   8/29/2014 12:06:15 PM   9 (0x0009)


Is there something I'm doing wrong that would cause this?

Would it be possible to add an option that either closes any conflicting programs that are running, or perhaps just force logoff of any users who are logged in?

Obviously you wouldn't push an update using that option when the computer is likely to be in use, but only in cases where patches are deployed during scheduled maintenance windows when staff aren't using the computers.  In my case, I send out emails reminding users to log off when leaving for the day if I have patches going out, but many will lock their computer instead, with one or more browser windows still open.