GPO install - Error applying changes/transformations

Question

Hi,

Goal is to deploy endpoint msi in AD enviroment.

This is the guide that we followed:

https://support.withsecure.com/userguides/product.html#business/psb-portal/latest/en/task_AF6058DE18E140BF85333F7E6C56F64C-psb-portal-latest-en

But during creation of gpo object error is shown "

Installation of software has encounter the following error: Error applying changes/transformations. Verify that path to transformation are valid"

When creating GPO without mst file everything goes fine and Elements agent is installed on applied machines but ofcourse not showing in cloud console.

I have also tried starting it from cmd prompt:

msiexec /i \server\share\mdl_withsecure.msi VOUCHER=xxxx-xxxx-xxxx and works fine.

Googleing issue gives me only this:

https://community.withsecure.com/discussion/125091/installation-using-gpo-fails

Case closed and link inside post is dead.

I have also tried in two enviroment just to eliminate issue on AD side, but on both enviroment it fails.

Is there option to use Policy Manager , installed on prem, as a workaround?

ty

Sethu Laks · Answer

Hi,

Thanks for the extra details.

If the SHA1 hash of the MSI from the Partner Elements portal and from the public Download Center is identical (5372cb6a747151ad8bbde7534adaa1dda28d1103), then the installer itself is fine and we can rule out a “wrong MSI version” problem. You also already followed the recommended method (fresh, unmodified MSI + MST created from that same MSI, both on a UNC share, added via Advanced → Modifications), so you’re definitely doing it the “intended” way.

At this point, the key test is whether the MST itself can be applied outside of GPO. On a test machine, you could try:

msiexec /i "\server\share\ElementsAgent.msi" TRANSFORMS="\server\share\license.mst" /qn

* If this fails, the transform content is the issue (even though the MSI is fine).
* If this works, then the problem is specific to how GPO/GPMC is accessing the MST (path/permissions/editor machine), not the MSI+MST pair itself.

Your current workaround (e.g. startup script using msiexec /i ... VOUCHER=...) is perfectly valid, but I understand you’d prefer the clean MSI+MST deployment.

On Policy Manager: you can’t use Policy Manager as a workaround for Elements. Policy Manager is designed for the older Business Suite products, while Elements is cloud-managed. That’s also why you were advised to move to Elements; the long‑term strategy is Elements, and Policy Manager/Business Suite are on a phased lifecycle, not the recommended path for new deployments anymore.

DrazenSego · Answer

Hi Sethu,

I can confirm that sha1 hash done on msi dowloaded from partner elements portal vs msi dowloaded from download center (https://support.withsecure.com/en/support/download) are same:

SHA1: 5372cb6a747151ad8bbde7534adaa1dda28d1103

So, i have already done as you suggested:

"The recommended approach is to start with a fresh, unmodified Elements Agent MSI, recreate the MST from that exact MSI (including the voucher there), and then place both the MSI and MST on a UNC share with read access for Domain Computers, adding the MSI as an Advanced package and the MST on the Modifications tab."

Now, i have already found workaround but i would prefer to have deployment as it was intended: msi + mst combo.

Regarding PolicyManager it was good and did job as intended, but we went to elements because of inf that Policy Manager will be abandoned , not supported any more. Is that true?

many thanks and BR

Sethu Laks · Answer

Hi @DrazenSego

Thanks for the additional information and for confirming that you’ve tested this in two separate AD environments to rule out an AD-side issue. Since the same error appears in both, it strongly suggests that the problem is related to how the MSI and MST are paired or how the transform is referenced, rather than something specific to the domain.

The “Error applying changes/transformations. Verify that path to transformation are valid” message usually means one of the following: the MST was created for a different version/build of the MSI than the one selected in the GPO, the MSI was already modified/customized and an MST is then applied on top of it, or the MST is not being accessed via a valid UNC path that the computer accounts can read.

The recommended approach is to start with a fresh, unmodified Elements Agent MSI, recreate the MST from that exact MSI (including the voucher there), and then place both the MSI and MST on a UNC share with read access for Domain Computers, adding the MSI as an Advanced package and the MST on the Modifications tab. As a practical workaround, since you’ve confirmed that manual installation with msiexec /i \server\share\mdl_withsecure.msi VOUCHER=xxxx-xxxx-xxxx works, you could deploy via a computer startup script that calls this command, or use a customized MSI with the voucher embedded and deploy it through GPO without any MST. Regarding your question about using Policy Manager on-prem as a workaround: that’s not an option here. Policy Manager is designed to manage Business Suite (on-prem) clients, whereas the Elements agent is intended to be managed from the Elements cloud portal, so installing Policy Manager would not help this specific deployment or registration issue. If you’d like, you can share the exact way the MST was created (steps and options) and the UNC paths you’re using in the GPO, and we can narrow down the remaining possibilities further.

Best regards,

Sethu

Community Moderator | Technical Support Engineer

https://www.withsecure.com/en/