You should specify a meaningful name for your package, certainly if you are going to offer it for download. It is very hard for the user to find out which of the half a dozen setup.exe files she downloaded will install your application. Trying each of them is a waste of time. The best name you can choose is Setup_AppName_Version.exe. This makes it immediately clear that the file is an installation program and not a regular application, and which application and which version of it will be installed. Only if the package will be burned on CD-ROM, the ordinary setup.exe will do. Then the user can look at the disc’s label to find out which application it is about.
If you added external installers on the 3rd Party tab or turned on the .NET framework requirement, you can specify two names for the final setup.exe. The first one will contain just your files and settings, including the 3rd party settings, but not the actual 3rd party installers. Your setup.exe will look for the 3rd party installers in the same folder where you or the user placed the setup.exe. If they are missing, the download URLs are displayed instead. The second setup.exe will have all the 3rd party executables integrated into it. The setup.exe will still look for external installers in the same folder, and run those if present. If they’re missing, the integrated installer is extracted from the setup.exe into a temporary folder, and run them from there.
When distributing your application with 3rd party requirements as a download, you should build both the setup with and without the 3rd party installers. People who download your software for the first time can use the integrated download. People who are upgrading can use the “lite” download. Since the lite download still does the 3rd party checks, there’s no big problem if first time users don’t download the big package. When distributing your application on CD, you should use the installer without integrated 3rd party installers. Instead, place the installers separately on the CD along with your own setup.exe. That eliminates the step of extracting the integrated installer into a temporary folder.
If your setup doesn’t reference any 3rd party packages, then it doesn’t matter whether you specify the name of your setup in the first or second box. Only one setup.exe will be generated.
To create a CD-ROM that will automatically launch the installer when the user inserts the CD into the drive, turn on the option to create the autorun.inf file. Place this file together with the setup.exe in the root folder of the CD. There are no other requirements to make this work.
You can use several placeholders to insert the version number of the installer and the application’s release date in the file name of the generated installer and in its output folder. The output folder will be created if it does not yet exist when you build your setup.
%VERSION% inserts the Application Version exactly as you specified it on the Project page. %VERSION09% inserts the Application Version stripped of all characters that are not digits. If the Application Version is “1.2.3 BETA” and you specify “SetupMyApp%VERSION%.exe” as the file name for the installer, then the final name of the installer will be “SetupMyApp1.2.3 BETA.exe”. If you specify “SetupMyApp%VERSION09%.exe”, then the final name will be “SetupMyApp123.exe”.
%DATE% inserts the release date specified on the Project page, formatted using the short date format specified in the regional settings in the Windows Control Panel on your development PC. If that date format includes slashes, those will be removed, as they are not valid in file names. Other characters such as hyphens or spaces will be preserved. If your computer’s default date format produces something like 18/Sep/2012 then “SetupMyApp%DATE%.exe” becomes “SetupMyApp18Sep2012.exe”.
%DATE09% also inserts the release date using the date format specified in the Control Panel. If that date format uses (abbreviated) month names, DeployMaster uses month numbers instead. All characters that are not digits are stripped from the date. If the default date format produces something like 18/Sep/2012 then “SetupMyApp%DATE09%.exe” becomes “SetupMyApp18092012.exe”.
%YYYYMMDD% inserts the release date in YYYYMMDD format. The benefit is that “SetupMyApp%YYYYMMDD%.exe” will always yield something like “SetupMyApp20120918.exe”, which allows your installers to be displayed in the proper order when a file manager sorts them alphabetically by file name.
You can use multiple placeholders at the same time. “Setup MyApp %YYYYMMDD% %VERSION%.exe” will produce “Setup MyApp 20120918 1.2.3 BETA.exe”. This is a very descriptive name for your installer. Multiple versions will be in the proper order when sorted alphabetically.
By default, DeployMaster automatically compresses all files that it puts into your setup.exe. DeployMaster uses the LZMA algorithm which achieves high compression ratios thus producing smaller setups that can be downloaded faster. But the LZMA algorithm is quite slow when compressing. While testing your installer on your own PC or local network, you can set “compression method” to “none” to significantly increase the speed at which DeployMaster builds your installers. When building the installer you will deliver to your customers via the Internet, set “compression method” to “best” to significantly reduce the size of the generated installer. If you work in an environment where the size of the generated installer does not matter much, you can choose the “average”, “faster”, or “minimal” compression methods to increase the build speed at the cost of a larger generated installer. The speed at which the installer decompresses the files does not change noticeably with increased compression.
If your installer includes files such as video files, music files, or image files that already use compressed file formats, you can add their file masks to the list of files that should not be compressed, e.g.: *.avi;*.mkv;*.mp?;*.jpg;*.png;*.gif. Then DeployMaster will add those files to your setup.exe without attempting to compress them. If your installer includes many such files, this will significantly increase the speed at which your installer is built if “compression method” is set to anything but “none”. As long as all the file masks only match incompressible files, then the size of the generated installer will remain the same.
DeployMaster can create installers of any size and allows you to add files of any size. Files and installers larger than 4 GB are no problem for DeployMaster. But Windows itself does not support .exe files larger than 4 GB. Some file systems, such as FAT32, also do not support files larger than 4 GB. If your installer is larger than 4 GB, DeployMaster will automatically split it into multiple parts of 4095 MB. The first part will be the self-extracting executable with the name you’ve specified. The other parts will have the same name with numbered extensions, e.g. setup.001, setup.002, etc.
You can specify a smaller size than 4095 MB. The minimum split size is 10 MB. If you want to distribute your software on CD-ROM, set it to 650 MB so each part of your setup will fit onto a CD.
You can also specify which folder the build package should be placed in. This should be a hard drive folder, so that there is enough free room for the entire installation package. Even if you select to split the setup into pieces, the whole package must fit on the drive while building. If there is not enough free space, the build will fail.
Windows itself and all major browsers display warnings and security prompts when the user tries to run software downloaded from the internet. These warnings are more severe for applications that are not digitally signed. Anti-virus and anti-malware tools also check digital signatures as part of their checks. Digitally signing your installer and your actual software is strongly recommended.
In order to digitally sign your installer, you need an Authenticode certificate. Authenticode is the specific name for code signing certificates for Microsoft Windows. You can purchase such a certificate from Certum, Sectigo, GlobalSign, DigiCert, or Entrust. The only difference between these providers is how much it’ll cost, whether they offer cloud storage, and how many hoops you’ll have to jump through to prove your (and your company’s) identity, which may differ depending on which country you’re in.
Code signing certificates must be stored on a secure USB token or on a cloud service specifically designed for storing certificates and their private keys. All providers will sell you and ship you a USB token with your certificate pre-installed. With some providers the token is included in the price while with others it’s an optional extra. Shipping is likely extra and there may be import taxes depending on your country and where your provider ships from. Most providers will allow you to reuse a USB token that you previously purchased from the same provider when renewing your certificate or ordering an additional certificate. The token comes with driver software that allows DeployMaster to access the certificate. A USB token allows unlimited signatures while your certificate is valid. But it must be plugged into the PC that you will use to build your installer, which may be a restriction if you have multiple developers building installers or that have other files to sign.
Some providers offer cloud storage as an option. It is important to check how many signatures your provider will allow per certificate or per month or whether they will charge you for each signature. Only your cloud provider will have your certificate’s private key. So each signature must be calculated in the cloud. DeployMaster needs at least 3 signatures per installer: one for the actual installer, one for the uninstaller, and one for the overall package. It needs 5 signatures for a combined 32-bit and 64-bit installer. If you have it sign your application’s .exe files too, which you should, then that’s another signature per .exe file. So make sure to check the fine print. If it says you’re allowed only 1,000 signatures for the life of the certificate then you’ll likely run out of signatures long before the certificate expires. If it says you’re allowed 5,000 signatures per month then that will allow tens of builds per day. If it says they’ll charge a fraction of a penny per signature then you simply estimate that each installer you build will cost you a penny.
When your certificate is stored in the cloud, you’ll need special software that can connect to the cloud provider to request a signature. For some this is a Windows application that you use to log onto the cloud service and then acts like a driver for a virtual USB token allowing DeployMaster to access the certificate. Look in your provider’s documentation for instructions to use their cloud service with signtool.exe. Those instructions will also allow DeployMaster to access the certificate, without needing signtool.exe. Otherwise, you’ll need to check for a solution that lets you sign an .exe from the Windows command prompt. You can have DeployMaster invoke the same command line.
Signatures are calculated based on a one-way cryptographic hash of the .exe file you're signing. The hash is calculated on your computer. Only this hash is sent to the cloud provider when requesting a signature. The .exe file itself is never uploaded. So you can safely use a cloud provider to sign .exe files that must remain private. A slow network connection is not an issue. Only a few kilobytes of data are transmitted to request and receive the signature.
All provider sell both EV certificates and OV or standard certificates. EV means Extended Validation while OV means Organization Validation. EV certificates can only be issued in the name of a company and have a more thorough vetting process to check that the company is real and that the person requesting the certificate is allowed to do so by that company. Some providers issue OV certificates only to companies, while other providers are also willing to issue standard certificates to individuals. The security warning shown by Windows shows the name on the certificate, which is either the company’s official name or the individual’s full name. EV certificates are more expensive, but some providers have raised the prices of their OV certificates to make price less of a consideration. Certum is unique in that they offer open source code signing certificates at a much lower cost. Technically these are identical to standard certificates. But they are issued in the name of “Open Source Developer, John Doe” while a standard certificate for an individual would be issued to “John Doe”. Certum also checks whether you have already published at least one open source project that you would need to sign builds for.
As far as DeployMaster is concerned, there is no difference between any of these certificates. Which type you have does not affect how you build your installer. The only real reason to get an EV certificate is that Microsoft SmartScreen gives immediate trust to EV certificates. The first person to download your installer will not see any scary warnings if it was signed with an EV certificate. But if it was signed with an OV certificate then the first people to download your installer will get a message saying “Windows SmartScreen protected an unrecognized app form starting”. It will indicate the name your code signing certificate as the publisher. They’ll then have to click “Run Anyway” for your installer to start. When people click Run Anyway that gets reported back to Microsoft. When enough people have done so SmartScreen will start to trust your OV certificate and the warnings will go away. Microsoft doesn't publish their definition of "enough". Our experience is that it takes many thousands of downloads for the warnings to go away. Individual files may build up trust faster than the certificate. A popular download may be trusted before every download signed with your certificate is trusted. So if you have a popular application that gets thousands of downloads in a short period of time then the SmartScreen warnings will go away quickly. But if you sell specialty software with few users then it may be worthwhile to get an EV certificate to remove the warnings immediately.
To properly sign a setup.exe built by DeployMaster, you have to let DeployMaster do the signing while building the setup. While you could sign the setup.exe afterwards, that is not sufficient. If you sign the setup.exe afterwards then you’ll only sign the installer stub. You can’t sign the actual installer(s) stored inside the setup.exe after it has been built. For a combined 32-bit and 64-bit setup.exe, there will be two actual installers inside the setup.exe. The setup.exe extracts the actual installer into the temp folder and runs that to perform the installation. In order to allow user-specific installs and portable installs by non-administrators, the setup.exe does not request administrator privileges when the user runs it. The actual installer will request administrator privileges when the user clicks one of the buttons create an installation for all users. This means that Windows will check the digital signature on the actual installer that was extracted into the temp folder rather than the signature on the setup.exe. Thus, if you don’t let DeployMaster sign your setup, Windows will indicate your installer is unsigned, even if you manually signed your setup.exe after DeployMaster built it.
Tick the “sign the installer” checkbox to tell DeployMaster to sign it. You should always do this for your final build. You can temporarily turn off the option to speed up internal test builds.
If you tick also sign unsigned .exe files added to the setup then DeployMaster signs all .exe files that haven’t been signed yet while building your setup. DeployMaster only checks whether the .exe files were signed at all. It will not replace the signature on .exe files that were signed with another certificate than the one you’re using.
You should definitely sign the .exe files added to your setup if your application may be run with Administrator privileges. This avoids “unknown publisher” warnings for the installed application just like it does for the installer. If your application never runs with Administrator privileges then Windows doesn’t care whether its .exe files are signed or not. But other security software that applies “heuristics” to decide whether it will allow your application to run or not may be more likely to allow signed executables. The signature also allows security software to verify that the .exe file wasn’t tampered with.
Windows doesn’t show security warnings for .dll or .ocx files loaded by your application. But you can ask DeployMaster to sign unsigned .dll and .ocx files added to your setup. This allows your users or any security software they may use to verify that your .dll and .ocx files were not tampered with.
In most cases you do not have to provide any additional information. DeployMaster will automatically find the code signing certificate that you have installed on your computer or on a USB token plugged into your computer. You do not need to specify a subject name, thumbprint, PFX file, or command line. You may need to unlock the USB token using the software that came with the token first.
If you have a SafeNet USB token then you should open the SafeNet Authentication Client, switch to the Advanced View, go into Client Settings, and tick “enable single logon”. This stops the SafeNet client from prompting for the USB token’s password for each and every file you want to sign. The password prompt may not appear automatically. In that case, use the Unlock Token button in the SafeNet Authentication Client before building your installer. With single logon enabled, you should need to do this only once each time you reboot your PC or unplug the token.
If your certificate is stored in the cloud then DeployMaster can find that automatically too if the cloud provider offered you software that you can log onto to make the certificate visible to signtool.exe. Such software acts as a device driver that makes the cloud solution appear as a virtual USB token. Certum’s SimplySign Desktop, for example, works this way. You don’t need to actually use signtool.exe. Simply log onto SimplySign Desktop with your email address and the 6-digit token from SimplySign Mobile. DeployMaster then automatically finds your certificate. SimplySign handles the cloud connection in the background.
If you have multiple code signing certificates on your PC or you want to make sure that the build only succeeds when a specific certificate is available then you can provide either the subject name or the thumbprint of the certificate. The subject name is what appears as the name of the publisher when an installer signed with your certificate requests elevation. It is possible to have multiple certificates with the same subject name. This happens when you renew your certificate before the old one expires. The subject name allows for partial matches. DeployMaster will find the certificate for “Just Great Software Co. Ltd.” even when entering “Just Great Software” or even just “G” as the subject name. But what you enter must be exact. “Just Great Software Co Ltd” (missing dots) or “Just Great” (two spaces) will not find our certificate. The thumbprint is a string of 40 hexadecimal characters that uniquely identifies a certificate. It changes each time you renew your certificate. DeployMaster will only find the certificate if you enter the full string of 40 hexadecimal characters. Anything else is interpreted as a subject name.
The management software that comes with your USB token or cloud solution should be able to show you a list of certificates. The subject name is usually easy to find. It may be indicated as “Subject”, “Issued to”, or “Common Name”. The thumbprint may be harder to find. With Certum’s SimplySign Desktop, for example, you have to right-click the certificate in the certificate list and select Show Certificate. Then on the Details tab you’ll find the thumbprint at the bottom of the list. Certificate details may include a “serial number” that consists of 32 (rather than 40) hexadecimal digits. The serial number cannot be used to look up a certificate.
If you have already signed an .exe file with your certificate then you can see the details of your certificate by right-clicking the .exe file in Windows Explorer and selecting Properties. For a signed .exe file the properties include an additional Digital Signatures tab. Select the signature in the list and click the Details button. Then click the View Certificate button. On the Details tab you will find both “Subject” and “Thumbprint” somewhere in the list.
Prior to June 2023, OV certificates could be stored complete with their private key in a PFX file. DeployMaster can load your certificate from a PFX file if you specify the full path to the PFX file. You also need to provide either the subject name or the thumbprint of your certificate. DeployMaster needs that to be able to distinguish your certificate from any intermediate certificates in the same PFX file. If your .pfx file is protected with a password then DeployMaster will prompt for the password when needed. DeployMaster keeps the password in memory as it is needed several times while building an installer. You will be prompted only once for the password when building multiple installers in a single DeployMaster session using the same certificate. DeployMaster does not provide an option to store the password. There is no way to do that securely. If you want to automate the build process without a password prompt then double-click your .pfx file in Windows Explorer. Follow the wizard to import your certificate into the Windows registry. Do not turn on the option to enable strong private key protection so that no password will be required to use the certificate. Then you can remove the reference to the PFX file in DeployMaster. DeployMaster will find your certificate in the Windows registry using its subject name or thumbprint.
If DeployMaster’s built-in code signing does not work with your code signing certificate then you can provide a custom command line for code signing. If you provide only the path to an executable then DeployMaster assumes that it takes the same command line parameters as signtool.exe which DeployMaster then automatically provides based whether you provided a subject name, thumbprint, PFX file, or not. If your executable needs different parameters then you have to use the placeholder %FILE% on your custom command line to represent the file to be signed. When %FILE% is present on the command line DeployMaster does not automatically add any other parameters but instead recognizes six additional placeholders. %DESCRIPTION% represents the name and version number of the application specified on the Project page. %URL% is the application URL specified on the Project page. %SUBJECT% is the subject name or thumbprint of the code signing certificate specified on the Media page. %PFX% is the path to the PFX file specified on the Media page. %TSURL% is the time stamping service URL selected on the Media page. %PWD% tells DeployMaster to ask for a password. It will do so the first time it needs to run a specific command line to sign a file. DeployMaster will remember the password until it needs to sign with a different command line. In most cases you’ll want to put double quotes around these placeholders on your custom command line so that paths with spaces are kept together. DeployMaster does not automatically add double quotes when a placeholder is replaced with a string that contains spaces.
As an example, you may have a code signing certificate stored in an Azure Key Vault. DeployMaster and even signtool.exe cannot access the Azure Key Vault. But AzureSignTool.exe can. You could provide something like this as a custom command line to have DeployMaster invoke AzureSignTool:
'C:\...\AzureSignTool.exe' sign -d '%DESCRIPTION%' -du %URL% -fd sha256 -kvu https://my-vault.vault.azure.net -kvi 01234567-abcd-ef012-0000-0123456789ab -kvt 01234567-abcd-ef012-0000-0123456789ab -kvs my-client-secret -kvc my-key-name -tr %TSURL% -td sha256 -q '%FILE%'
The custom command line can be anything you like. It can even launch a GUI application. DeployMaster simply waits for the application to finish running. DeployMaster assumes the file was correctly signed if the application returns exit code 0. DeployMaster shows an error if the application returns a non-zero exit code.
DeployMaster automatically uses a time stamping service to countersign your digital signature. This ensures that the signature remains valid even after the code signing certificate expires. Because of this, a working Internet connection is required for code signing to succeed, even if your certificate is stored on a USB token. You can select any of the time stamping URLs from the drop-down list. The provider of the time stamping service does not need to be the issuer of your code signing certificate. Occasionally these time stamping services go down for maintenance or are unreachable because of network outages. When that happens, select a different URL and build your installer again. DeployMaster remembers the time stamping URL as a global setting. It is not stored in your .deploy file. This way you only need to change the time stamping URL once if your previous choice becomes unavailable.
If you select Windows XP or Vista on the Platform page but not any later version of Windows then DeployMaster applies an SHA-1 signature if you specify a PFX file. Windows XP and Vista do not recognize SHA-256 signatures. But SHA-1 is deprecated. Most driver software for USB tokens and most cloud providers no longer allow SHA-1 signatures and often fail with a non-specific error message when asked to provide an SHA-1 signature. So DeployMaster no longer tries. It will refuse to build your installer unless you provide a PFX file or turn off the option to sign your installer when targeting only XP and/or Vista.
The SHA-1 signature will not have a time stamp because time stamping services compatible with Windows Vista and earlier are no longer available. Windows XP SP3 and Windows Vista will accept your digital signature without a time stamp until the code signing certificate that you used expires.
Windows XP SP2 and earlier versions of Windows will not accept any digital signature that you can apply today. Certificates compatible with Windows XP SP2 and prior are no longer issued and old certificates have all expired. DeployMaster ignores the setting to sign your installer if you select only Windows 2000 or prior on the Platform page.