I am installing my application in a fully offline environment. Our machines will be completely incapable of connecting to the internet during production scenarios.
I am writing a WiX Burn custom bootstrapper, and part of the reason was to install a Microsoft root certificate required for .NET 4.7.2 to install properly on Windows versions earlier than 8.1. My original plan was to use the .NET certificate namespace to do this, but aside from the warning that popped up saying not to, I realized that Burn runs at the current user's elevation level, which means that it would likely fail to install the certificate without acquiring elevated privileges first.
According to a Microsoft document regarding installing certificates for Visual Studio, the preferred way of doing this is to bundle a copy of of certmgr.exe with your program and call it to add the certificate to the root store.
Is it best practice or even possible at all to do this using an ExePackage element? As in, setting the element to call certmgr, set InstallCommand to /add MicRooCerAut2011_2011_03_22.cer /s /r localMachine root, PerMachine to True and let it rip? Or does ExePackage have some kind of special behavior?
Related
I'm struggling to get a ClickOnce setup working successfully with a bootstrapper. I'm building a VSTO add-in, and all worked well with a self-signed cert for development, but now we're setting up a proper certificate and it's failing in interestingly challenging ways.
The deployment uses a separate bootstrapper .exe, which is set as a dependency, to prompt for a few settings. Again, all this worked with a self-signed cert.
So the add-in builds okay, with a few post-build steps on the main component, as per:
"mage.exe" -update "$(TargetDir)$(TargetFileName).manifest" -CertFile "E:\COMODOCodeSign.pfx" -Password _pass_
"mage.exe" -update "$(TargetDir)$(TargetName).vsto" -appmanifest "$(TargetDir)$(TargetFileName).manifest" -CertFile "E:\COMODOCodeSign.pfx" -Password _pass_
The build works, the publish works, all looks good.
However, running the setup starts with the bootstrapper's EULA, and after acceptance, then I get the message:
Setup has detected that the file somewheretemp\bootstrapper.exe has either changed since it was published or may be corrupt.
Now, I am not "publishing" the bootstrapper. In the directory where it's stored as a dependency, there's no manifests, and I'm not signing it at all. So I can't see how/where it has decided that's changed.
And although there are answers on the web, they all involve poking through manifests to find differences, and there aren't any manifests for the bootstrapper, and there are no traceable references to the bootstrapper in the signed VSTO manifest. At least, not that I can find with a grep on the published output.
So to the questions:
Any ideas how to proceed?
Should I sign the bootstrapper? (manifests and/or assemblies) -- I did attempt this but it didn't seem to make any difference.
The issue appears to be in Publish > Prerequisites... in the project properties. I'd set it to have an installation folder URL, but I'd not (yet) copied the files there, this was me attempting to test the installer before I got to that point.
As soon as I removed a URL from this field, all worked okay, and the bootstrapper application started correctly. So there might still be a challenge getting web install directories right, but this particular issue is resolved.
I've developed a VSTO addin with VS2012 signed by a DigiCert certificate. I need to deploy it to all the Enterprise users so the installer shouldn't prompt the user because it will fail since all the installation process is silent.
I'm not able to do it since it always ask the user if it should or shouldn't install. If I set VSTOInstaller /S it doesn't install 'silently'.
Is there any way to do this?
Thanks on advanced.
I found the answer. To solve this you have to install the public key certificate in your installer:
certutil -addstore TRUSTEDPUBLISHER "yourcertificate.cer"
Then, you just use VSTOInstaller:
VSTOInstaller.exe /I "youraddin.vsto" /S
That's all folks!
Yes you can.
Just Uncheck the ClickOnce manifest CheckBox and Check the signing the assembly using any .snk file.
You will need to create installer project and the rebuild the installer project will provide you the .msi and .exe file you can execute the following command on command prompt(Administator).
Though rebuilding of installer project will automatically check the ClickOnce checkBox but you can ignore that.
Below is the link for creating Installer project for AddIn.
https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2010/ff937654(v=msdn.10)
Looks like you need to GPO for deploying the software (using MSI installers).
How to use Group Policy to remotely install software in Windows Server 2008 and in Windows Server 2003
How to use Windows Installer and Group Policy to deploy the VPModule.msi in an Active Directory domain
Installing Software Using GPO
Also see the Deploying an Office Solution section in MSDN.
I've got an MSI built with WiX. It performs the following custom action:
<CustomAction Id='StartTray'
Directory='INSTALLDIR'
ExeCommand='[INSTALLDIR]\myapptray.exe'
Return='asyncNoWait'
Impersonate='no'
Execute='deferred' />
It is scheduled like so:
<Custom Action='StartTray' After='StartServices'>NOT Installed OR (TRAYWASRUNNING AND NOT REMOVE~="ALL")</Custom>
myapptray.exe happens to use impersonation to relaunch itself from its starting context of Local System (running from MSI context) as the user currently active on the desktop. This is not in my control and Impersonate='yes' does not work because the MSI may be invoked for an upgrade from the context of the system service, meaning Impersonate='yes' would still end up running the app as Local System.
I recently moved from including the VC9 CRT as a MSM in this MSI, to including it in a bootstrapper exe.
Doing this prevents the myapptray.exe custom action from running successfully. The impersonation fails in WTSQueryUserToken which returns ERROR_PRIVILEGE_NOT_HELD. This seems to imply that removing the MSM actually changed the user context in which the MSI runs, but that seems ridiculous. The only lines I removed from the wxs file are the <Merge> and <MergeRef> tags for the MSM, nothing else has changed.
What am I doing wrong?
I'd look more at what versions of the CRT your EXE was built against and if there are any policy rules saying what it can run against. Moving from an MSM to an EXE run before your MSI should generally be a good thing.
BTW, I did something really hacking like this once upon a time. We had to push an MSI out under the SYSTEM context using MSI. If a user was logged on we had to relaunch the application using the users desktop login session. I had a DCOM server installed configured to impersonate the interactive user to accomplish this. Really wierd, but there was a valid reason.
This was all before Restart Manager though.
I figured it out.
The CRT MSM was setting ALLUSERS=1 and the installer's behavior changed because it was not present in our base installer. The MSM's setting of ALLUSERS was inherited into the base installer as a result.
Setting ALLUSERS=1 in our wxs file fixed the problem!
I looked at this answer:
Install a pfx certificate in a users store in Windows using WiX
to install the certificate through wix and seemed to work fine, the certificates (i need two) were installed in the correct location stores and had the correct values for issues to and issued by.
However, when i tried to use them in my installed application, i get keyset does not exist exception.
When i manually install the pfx file using MMC->import from exactly the defined location in wix, it works fine.
The permissions are slightly different in the sense that wix has added owner rights and msiserver permissions and removes the temporary S-1-5-5-0-XXXXX read permission that i cannot manually add.
Does anyone have any idea what would be causing this problem?
This is not a permissions issue but a problem with the way msi's are installed.
To get the required permissions to install a cert, this action has to be run as a deferred action, which runs under the system account.
The system account has no profile which I believe is required to install the cert with the private key (I reckon the private key is temporarily written to the profile before moving to the MachineKey store).
I have managed to get my msi to install the certificate with the private key but it was a bit of a mission...
I created a console app that generates and imports the cert.
Drop this exe in the installation folder as part of the installation.
Using an impersonating CustomAction, spawn an elevated PowerShell command (-Verb RunAs).
Run a script that executes the exe.
As I said a bit of a mission but in now works perfectly! :)
On Windows, when a program installed via MSI is run through an advertised shortcut, it checks that all the installed features exist and runs self-healing/auto-repair to replace missing ones.
Is it possible to set a file's ACL as a feature on install that will be self-healed if the ACL is wrong? If it matters, the file in question
is not installed by our MSI
may not exist (not existing is OK, so long as it has the proper permission if it exists)
I'm currently using WiX to build my installers.
No; ACLs aren't resources that MSI uses to validate health. Even if they were, it would likely be tied to a file anyway.
If it's that important, you should check the ACL when your app starts.