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.
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.