Messages

Hey JImmy_O,

May you fire an email to [email protected] and include "FAO Adam" in the subject? I have some queries regarding testing this update I'm hoping you can help answer.

Hi pmptrad,

I'm following up from Scott's reply.

Pulse Connect Secure (x86) is no longer in our catalogue. The software was bought and rebranded by Ivanti. At this time, the successor we have in our catalogue is Ivanti Secure Access Client, however, this software is only available in our catalogue as x64 and not x86.

Do you need x86? x64 is generally preferred in nearly all circumstances for our customers.

Can you send us some logs via the support portal so we can look through them to get the bigger picture and help you? You can upload them here https://patchmypc.com/technical-support

We will need the following please:-

Server
%PatchMyPCInstallDirectory%\PatchMyPC.log
%PatchMyPCInstallDirectory%\PatchMyPC*.lo_
%PatchMyPCInstallDirectory%\Settings.xml

Affected Client
%WinDir%\CCM\Logs\AppDiscovery*.log
%WinDir%\CCM\Logs\AppEnforce*.log
%WinDir%\CCM\Logs\AppIntentEval*.log
%WinDir%\CCM\Logs\CAS*.log
%WinDir%\CCM\Logs\CIAgent.*log
%WinDir%\CCM\Logs\DataTransferService*.log

Yeah, we originally added DDM 2.x to the catalogue where it would uninstall 1.x. However we found supporting documentation that Dell suggests DDM v1 and v2 are independent and v2 isn't always the best option for some monitors. Therefore we added it as a separate product and fence of detection/applicability between the major versions.

Word of mouth suggests Dell are releasing an update for DDM 2.x next month to include a newer version of .NET.

When deploying the new version of Zscaler to clients that already have a previous version (in this case v3.9.0.183), the old version gets uninstalled before the new version is installed, which would cause an outage for users during this process.

This is a functional typically carried out by installers themselves for nearly all software, with the exception of some e.g. Oracle Java where it purposefully leaves behind older versions so we by default include a pre-script to explicitly uninstall the older version.

At this time, we are experiencing issues with Zscaler detection for updates but not base / fresh installations. What issue are you experiencing exactly?

If you need to apply customisations to the update, I recommend leveraging the package from Patch My PC. Otherwise if you're just kicking out the update as-is, there really isn't a pro/con list for either approach; there isn't a difference.

No worries PaleFacedGinger. Let me know if there's more I can do.

Hey PaleFacedGinger,

Yes

Hello, I found the documentation by searching:

• https://www.dell.com/support/kbdoc/en-uk/000177325/dell-command-update
• https://www.dell.com/support/kbdoc/en-uk/000060112/what-is-dell-display-manager

Hey Ant,

Thanks for the prompt. I just approved it. Apologies for the delay, I'm not quite sure why I didn't receive a notification for that.

As you know, at this time, what's requested in this post is not existing functionality and it's not currently on the roadmap to support this style of detection, either.

I really do appreciate the candid feedback, though. I don't believe an existing requests on our uservoice for this, so it may be worth raising a new request for it: https://ideas.patchmypc.com.

A new update 109.0.1518.61 is in our catalogue. Publishing and deploying that as-is without any other special instructions should resolve the issues. Kindly test this and let us know how you get on?

It's frustrating the installer _reinstalls_ if the same version is already installed. Most installers just bail if it detects the same version is installed. That coupled, with our broken detection logic when we mislabelled .55, is what has caused the issue.

Definitely reach out to [email protected] and indicate you're impacted by this. It'll be an easier means for us to update you with progress with our remediation actions.

We released .55 on Sunday, but it was mislabelled, it should have been .52. Therefore we rereleased it with .52 on Monday.

This sequence of events causes the installer to initiate a reinstall. If software is running which depends on webview2, the reinstall would fail and leave webview2 in a partially installed state. This in turn leaves other software that depends on webview2 in a broken state.

We have repro steps but still trying to work out the best way to coordinate remediation actions for customers.

Please don't forget C:\Windows\temp\msedge_installer.log

Hi Mark, may you share the below logs please? Feel free to email to [email protected] and we can

C:\Windows\temp\msedge_installer.log
%WinDir%\CCM\Logs\CAS*.log
%WinDir%\CCM\Logs\DeltaDownload*.log
%WinDir%\CCM\Logs\DataTransferService*.log
%WinDir%\CCM\Logs\PatchMyPC-ScriptRunner.log (If exist)
This may be found in the %ProgramData%\PatchMyPC\ if the Install was initiated by the user from Software Center.
%WinDir%\CCM\Logs\ScanAgent*.log
%WinDir%\CCM\Logs\StateMessage.log
%WinDir%\CCM\Logs\UpdatesDeployment*.log
%WinDir%\CCM\Logs\UpdatesHandler*.log
%WinDir%\CCM\Logs\UpdatesStore*.log
%WinDir%\CCM\Logs\WUAHandler*.log
%WinDir%\WindowsUpdate.log
You need to run Get-WindowsUpdateLog on Windows 8.1 and newer in PowerShell.
%ProgramData%\PatchMyPC\PatchMyPC-UserNotification.log
%ProgramData%\PatchMyPC\UISettings\UINotificationSettings.xml