Messages

The problem we face is when the machine-wide installer puts the Teams.exe under Program Files it's from the date of the install. This means that if Teams was installed in early 2020 and someone new logs into the computer in 2021, the Teams client that get's installed could be almost a year old. Depending on the age of the installer, the user may have to wait until Teams has been updated. My repair script runs a repair of the machine-wide MSI which updates the Teams.exe file under Program Files. Then using parts of the PSADT the script runs Teams.exe as the logged in user. So if Teams didn't auto install for a user, they can click the repair button and it will make sure they have the current Teams client right then, no waiting to update.

At this point I'm going to have to make a copy of the Team(s) applications so I can customize the repair and remove the uninstall commands.

Jim

Hello,

Are the uninstall and repair command lines replaced when the application is updated? I'm trying to use a custom repair command for the Teams x64 application and it was changed back to the PatchMyPC default. Can an option be added to not override a custom uninstall command? Also, it would be nice if the uninstall command could be turned off per app as well as the repair feature. We don't always want to enable those options.

This request covers custom repair command.
https://ideas.patchmypc.com/ideas/PATCHMYPC-I-948

Jim

I just checked, and the majority of our x64 applications created by PatchMyPC do not have any requirements. This includes Teams x64, Firefox x64, Firefox ESR x64, and Apple iTunes x64. Some of the apps were created with 1.9.2.0 and don't have the x64 OS requirement. But our 7-Zip x64 app was created with 1.8.2 and has the requirement. It seems to be hit or miss. Have you seen this before?

What happens if I delete a PatchMyPC created application? Will it just get recreated?

Thanks for your help.

Would it be possible to add a requirement for the architecture to each of the apps that have both x86 and x64? Or select the operating systems that match the architecture. Also, if I add a requirement to one of the PatchMyPC created apps, will my settings be removed when it gets updated?

Thanks,

Jim

I found this, which sums up what I want.

https://ideas.patchmypc.com/ideas/PATCHMYPC-I-779

I'll add a vote to the idea.

Jim

Hello,

I'm looking to start using the application publishing feature to keep frequently updated software current. Something I noticed is that there are no OS requirements on any of the applications with architecture specific versions. This presents a problem since we use a single deploy collection that could contain both x86 and x64 versions of Windows. What I'd like to see is a way to either combine the two architectures into a single application with multiple deployment types, or a way in the PatchMyPC tool to edit those settings similar to how you can modify the user experience and icon/properties.

Edge, as an example, has both a x86 and x64 application. The x64 will show up for install on x86 versions of Windows, as will the x86 on x64 versions of Windows. This means I need two deploy collections to prevent this from happening.

Thanks!

Jim

Is there a way to configure PachMyPC to use the FQDN of the server instead of the short name when publishing patches? Also, what about requiring the use of SSL? I'd like to be able to try the FQDN of the server using https.

https://servername.domainname.com:8531

I'll add a vote to the uservoice.

Jim

Nope. No updates fail when manually selecting and downloading in the console. They only fail when the ADR runs. The cab files are present on the WSUS server, and are available to download when the URL is pasted in a browser.

Jim

I'm working on that now. I have a lot of products published so I need to figure out which ones are failing so I can republish those. The logs list the updates by update ID so I've had to translate that into the actual name of the update. I should have more info next week.

Thanks.

Jim

Hello,

I reviewed the video and even tried the movecontent trick but I'm still getting the same error. When I try the URL from the logs in a browser, the CAB file downloads. But it still fails under the ADR.

Jim

If I open the URL in IE the files do exist. I also verified in the file system as well. What doesn't work is if I try the URL from an IE browser launched as SYSTEM, and of course the ADR.

Jim

Yes. Our organization does use a proxy and I did have it enabled in the ConfigMgr settings on the site system role for the server that hosts WSUS. I've since disabled the proxy setting "Use a proxy server when synchronizing information from the Internet" and I also unchecked the two check boxes regarding the proxy on the SUP role too. When I disabled the proxy, the error did change from from a proxy related error to the error I'm getting now.

Thanks for any help!

Jim

There are no related errors in the PatchMyPC.log file. Prior to attempting the ADR, everything has been working. In fact, if I select one of the updates that fails the ADR, right-click and download, it works. So this seems to be related to using ADRs. I attached a screenshot of the PatchDownloader.log file to better explain what I'm seeing.

Jim

I'm setting up and ADR for our third party updates. Some download okay, some error out with "HttpSendRequest failed HTTP_STATUS_NOT_FOUND" in the PachDownloader.log file. In RuleEngine.og I see
"Failed to download the update from internet. Error = 404". The URL is correct and works when copied to IE and tested. What's weird is if I copy the WSUS url to IE launched at SYSTEM, the .cab file doesn't download. I don't think this a PatchMyPC error or problem, but was hoping someone might have a simple solution before I engage Premier Support.

Thanks,

Jim