Skip to main content

Does anyone else have this issue, during deployment of PMC Package Manager in Intune Autopilot & MS Endpoint Manager OS Provisioning, it downloads the 2 components, the client and the cloud adapter and then when other Intune/MECM MSI packages are coming in, there is error 1618 (Another installation is already running), this can happen vice versa, depending which tool runs the MSI first, Package Manager or Intune/MECM. 

We are currently thinking of getting rid of Package Manager and use these deployment tool to install these 2 components, so such a clash doesn't happen. But if anyone else has better ideas, most welcomed.

I don’t see that as an issue—you are attempting to perform two installations simultaneously, which is causing an error.
You have multiple solutions to resolve this issue:
- Push the Package Manager as the final step of your build process.
- Use a script to check if the Windows Installer is available before starting new installations when installing from Intune.
- Deploy without using the Package Manager.
Additionally, ensure that policies are not enforced for specific versions of the EPM components, as that is likely to create issues. The Package Manager is the only component you do not control. When BT updates your PM Cloud instance, it will also update the package manager.
I really like the Package Manager, but I also recognize that there is always some risk when using software that auto-updates.

 


Does anyone else have this issue, during deployment of PMC Package Manager in Intune Autopilot & MS Endpoint Manager OS Provisioning, it downloads the 2 components, the client and the cloud adapter and then when other Intune/MECM MSI packages are coming in, there is error 1618 (Another installation is already running), this can happen vice versa, depending which tool runs the MSI first, Package Manager or Intune/MECM. 

We are currently thinking of getting rid of Package Manager and use these deployment tool to install these 2 components, so such a clash doesn't happen. But if anyone else has better ideas, most welcomed.

We actually found it easier to make this a required app to install post Autopilot installation to avoid having to do any scripting checks and mitigate the installer in use issue.

The required installer checked for version xx or greater so that the system doesn’t attempt to install an older version that is already being patched, this way we can keep the latest version of Package Manager rolling and choose when we update the required deployment package.


Thanks for the useful tips, we will consider internally which way best to proceed. Pushing Package Manager as the final step → not an option for us, we do it at first because when something else fails later, support personnel can remote in and use the admin rights to fix issues. We rely fully on EPM for admin rights, apart from lapmin which is not user friendly. Option 2 and 3 can be considered, many thanks once again.


Reply