Hi.  Thanks for the response.  I've done that but I don't think it worked.  Here's the steps I carried out:- Ran mmc Added the Certificates Snap in selecting the following options:- Computer Account Local Computer Added the certificate to the Trusted Root Certification Authorities store using the following options:- Browse to the .cer file Place certificates in the following store :  Trusted Root Certification Authorities Looked for the certificate in the certificates node and believe I can see it. N.b. When I close mmc at this point it asks me if I want to save changes to mmc.  I've saved changes but I don't think this should matter as the certificate being saved was handled by the import. Open the InstallShield package and Go to the signing tab on Prepare For Release.   Browse for the certificate and select it using the following options:- Trusted Root Certification Authorities Machine <Certificate Name> - I used view details to check this was the right one and it seems to be Based on Certificate Hash Rebuild. - The package builds fine but I still get the 1027 Failed to Sign errors. If I try to run the built Setup.exe I get the Unknown Publisher message So this feels like I'm at the same place.  I think the certificate is installed correctly but the installer package isn't using it for some reason. ... View more

Thanks for the reply and Happy Christmas I'm not really sure what I'm doing with the windows signtool as I've never used it before but I did a bit of googling and I'm not sure if it worked or not.  Here's what I did:- Found the Signtool under Windows Kits/10/xxxx/bin Copied the new pfx file to that location (n.b. as described above I think we usually use the cer file but the instructions I found were for the pfx so I went with that).  Ran the following from cmd: Signtool sign /f aquatorsigningcert-AquatorSigningCert10-XXXX.pfx /fd SHA256 "C:\Users\dhillier\source\repos\AquatorXVSuite\Aquator XV Installer\Express\SingleImage\DiskImages\DISK1\setup.exe" I got a message saying Done Adding Additional Store followed by a message saying Successfully signed: C:\Users\dhillier\source\repos\AquatorXVSuite\Aquator XV Installer\Express\SingleImage\DiskImages\DISK1\setup.exe However, if I run the setup.exe it unpacks the msi and then gives me the popup message asking if I want to install the package from an unknown provider. So if I read that correctly the tool is telling me that it worked but the exe doesn't seem to actually be signed.   Edit> I found instructions on how to verify the signing and that reports successfully verified.  I'm still getting the unknown publisher message when I run the exe though. ... View more

Yeah, that's worked.  Thanks. ... View more

Yeah, I bungled the test.  I'd accidentally copied the key path from excel into my condition🙄 So here's what I did which seems to be working:- I put "test" as the data of default value in the registry and fixed my condition to actually look for the right key and it worked.  Obviously that won't work in the real world, though, as the default value won't normally have a value. So, I simply picked an arbitrary value from that key that had data and put that value into the value of the condition.  My condition now looks like this:-     ...and this works 🙂   Markus, I cannot thank you enough.  I was out of my depth on this one and you've handheld me through it.  If ever we meet I owe you a beer. ... View more

actually, scratch that.  I think I bungled the test.  I'm retesting. ... View more

Interesting idea.  I thought I'd give it a quick test and set the default value to "test" in the registry.  I then updated the condition so that it both left the value empty and explicitly looked for a value of "test".  Neither of these has solved it which implies there's still something missing.  As before, though, I'm likely to be miss-understanding something.   Meantime I'm seeing if I can find a different key/value to look for. ... View more

Thank you.  I thought I might be miss-understanding the registry and that was really useful information.  Observing it through the 32 but regedit I can see exactly what you're talking about.  That lets me confirm that the key I should be looking for was as you described. However, my condition is still not working.  I'm now looking for key SOFTWARE\ODBC\ODBCINST.INI\Microsoft Access Driver (*.mdb, *.accdb) under HKEY_LOCAL_MACHINE.  I've set the condition to Not Found (because I want the installer to run if Access is not installed).  However, the installer runs regardless of whether the access is already present or not.  On the off chance I also tried it with the full path (Computer\HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Microsoft Access Driver (*.mdb, *.accdb)) but that made no difference.   A couple of screenies. My registry:-   My condition:-   Can you see what I'm doing wrong? ... View more

A possible wrinkle that might be affecting the above behaviour: I do have Office 365 64 bit installed, including access.  So I guess some of the registry entries I'm seeing may be coming from that.  I guess this is worth mentioning however it doesn't get round the fact that my app needs the 32 bit engine installed and doesn't explain why the registry keys aren't being found even though they're clearly present. ... View more

That hasn't worked I'm afraid.  It still runs the access installer every time.  I made the following observations that might help:- 1. When I run the access installer directly (not through my own msi) the contents of the SOFTWARE\ODBC\ODBCINST.INI path are unaffected.  The Microsoft Access Driver (*.mdb, *.accdb) key is present whether I have the access engine installed or not. 2. When I run the access installer directly (not through my own msi) the contents of the SOFTWARE\WOW6432Node\ODBC\ODBCINST.INI are affected.  The Microsoft Access Driver (*.mdb, *.accdb) key is present when the access engine is installed and absent when it is not. 3. I've double checked and believe I am building a 32 bit installer, this is based on the fact that nothing is written to the CommonFiles64Folder, ProgramFiles64Folder, or System64Folder and nothing is written to the Software (64 bit) section of the registry (the section does appear in the Destination Computers Registry view but nothing is written to it). 4. I'm confident I'm using the 32 bit Access installer. Downloaded from here.  I'm using AccessDatabaseEngine.exe, not AccessDatabaseEngine_X64.exe.   So from 1 and 2 I would have thought that the WOW6432Bit node was the right place to look as that's what's being affected by installing and uninstalling the access engine.  However, I would have expected the expected the key to be removed from the non-WOW  node when I uninstalled the access engine since it's a 32 bit version I'm using.  I'm aware that the WOW6432 is basically a redirect  but I'm outside my comfort zone with the registry and I am probably miss-understanding this. Further, it appears that the installer fails to find the key regardless of which path I check. When access is installed, it's still behaving as if the key is not found regardless of which path I check, even though the key is present on both paths.   Does any of that give any more clues as to what's going on? ... View more

Thank you very much. I should get a chance to try it this afternoon. ... View more

Hi, thanks for the response. I  believe it's a 32 bit but I don't see that setting in Install Shield.  Under Summary Information Stream I have: Title, Subject, Author, Keywords, Summary Information Stream Content, Schema and Require Administrative Privileges.  Is there somewhere else I could check that setting? ... View more