To confirm my understanding, when an application is updated, I will observe two applications with the same name in the list. To differentiate between them, I will need to rely on the metadata, is that correct?
Yes, you are correct! You'll only see the application names listed (without version numbers) and will have to look at the metadata below to verify that version.
As a follow-up question, I would like to know what will happen to existing applications with versions in their names when I enable the "do not include..." setting. Will they gradually disappear as I receive new updates, or will they be immediately updated to reflect the new configuration?
This setting is not retroactive, so it won't remove the version numbers for existing applications. This will only affect newly published apps going forward. Once the older versions fall out of retention, then they will be removed from the console along with their source content from the AppSouce.
If you have both of those options enabled, then any newly published application will only include the name of the product and not the full version number (Google Chrome (x64) instead of Google Chrome 119.x.x.x (x64)). The version info can be found in the metadata of the application, so that's one way you can keep track of new versions.
When retention is enabled, the publisher will first make a copy of the deployed application (older version) before doing the in-place update to the content. This means that you'll see multiple packages titled Google Chrome listed in the console (up to the retained amount).
For Apps to show in the company portal they'll need to be assigned as Available. You may have Assignment groups listed in the right-click option "Manage Assignments" set as available if they're showing in the company portal.
You can validate this by right-clicking on the app in the publisher and checking "Manage Assignments." If you see groups listed under "Available for Enrolled Devices" then you'll want to remove them or change them to required deployment.
Please Note: That Assignments can be configured at every level in the Publisher product list. I would confirm All Product > Vendor > Product levels do not contain available assignments to ensure apps don't show in the company portal.
Let me know if you have further questions or concerns! 😊
Can you please collection the publisher log bundle and send that over to [email protected] with a descript of the issue/screenshots?
In the General tab of the Publisher, click on the Collect Logs button under Logging Options Pick a Folder where you want to save the logs to a ZIP file containing the relevant server-side logs needed for troubleshooting will be created in that location. You can then send that ZIP file over to us.
We'll look through the logs and try to repro this issue in our lab environments!
Thank you! Looks like an issue with removing the previous version.
Could you please collect and send the following logs to [email protected]. We'll review them and see if we need to pull or modify the patch.
When troubleshooting ConfigMgr application installation errors on a client, we will need multiple client logs. Please include the following logs:
%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 %WinDir%\CCM\Logs\PatchMyPC-ScriptRunner.log This may be found in the %ProgramData%\PatchMyPC\ if the Install was initiated by the user from Software Center. %WinDir%\CCM\Logs\PatchMyPC-SoftwareDetectionScript.log This may be found in the %temp% of the user who clicked 'Install' in Software Center if it was an 'Available' deployment. %WinDir%\CCM\Logs\StateMessage.log %ProgramData%\PatchMyPC\PatchMyPC-UserNotification.log %ProgramData%\PatchMyPC\UISettings\UINotificationSettings.xml
We'll also want to take a look at the msi install log.
For this error we'll want to take a look at some of the client side log files! Can you please collection the following and email them over to [email protected] with a description of the issue and we can investigate further!
When troubleshooting update installation errors on a client, we will need the following client logs:
%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
Can you also run the following script and send over the outputted CSV file: