0

A customer installing my companies software package has no problem installing the package silently when running as an admin account. The software and the service both install correctly and start up post installation. However - they need to push this application to all the computers in a particular group.

They are using SCCM (I do not know the version) and the software package is a InstallShield .exe packaged .msi.

When they try to use the NT Authority\System user to push the package to their test device, the installation fails soon after the 3rd party software package that is included completes. The error log displays that it is a SDDL error 1943. Any idea why this would occur on the NTA\System account and not on a local admin account for a given machine?

The silent install string we are using is setup.exe /s /v" /qn AgreeToLicense=Yes SetupType=Typical"

I'm not a dev, so I dont have direct access to any code in the software, simply a tier 3 tech support working with customers.

EJoshuaS - Stand with Ukraine
  • 11,977
  • 56
  • 49
  • 78
James F
  • 169
  • 10

2 Answers2

0

Sounds like your MSI is using the MsiLockPermissionsEx table to specify an SDDL string on some resource its installing or configuring (either file, directory, service or registry entry). Either the SDDL string is misconfigured (unlikely if it works from one account but not another) or the ACL on the target directory/service/registry key have become corrupted, which isn't completely unheard of.

You could try getting the customer to deploy a domain account as local admin to the computers and then set SCCM to run the package with this account. I wouldn't recommend this though as it carries inherent security risks of its own.

I'm afraid this may be one that your developers (or whoever created the MSI) need to work out with the customers to find out which resources are at fault and progress the diagnosis.

Sorry I couldn't be of further help.

Matt
  • 151
  • 1
  • 7
  • Its ok, I will pass this information on to the developers and hopefully they will be open to working with the customer to fix this problem. On a separate note - I forced the same error on my personal test machine by using the NT Authority\System account for install. Would this provide any more insight. It seems here the customer ACL wouldnt be to blame and somehow the SDDL string is at fault. – James F Feb 21 '17 at 20:47
  • also the installer is installing a service onto the target machines that handles communications. – James F Feb 21 '17 at 21:06
0

I think I have found the issue. During install the .msi writes a file to the desktop to be read for configuration settings for the service as being installed. I had the file (and I am sure the customer did as well) already written to the desktop when I tried to invoke the System User for install. This does seem to be an ACL issue, in reference to the System User read/writing to a local user desktop. When the file was deleted, I received error 1406, that it could not write the value of a key. Looking on the desktop, the file had also never been written to the local desktop. When the file was already there (as such with a previous install) I get the error in the original post. At this point I am moving forward testing this as an ACL error and notifying the devs of my findings.

James F
  • 169
  • 10