Features of preparation of installation of the application for unattended installation in Windows OS

The system administrator sometimes has the task of installing or updating applications on multiple PCs. And often the problem is not in the choice of delivery system and automatic installation - there are a lot of them for every taste, from the built-in Windows OS (Active Directory) to the full-fledged Configuration Management systems such as MS SCCM, Enteo NetInstall, LanDesk Management Suite, HP Application Deployment Manager, IBM Tivoli Provisioning Manager, ManageEngine Desktop Central and many more ...

Often the problem is that the installation of applications that the manufacturer provides is not always adapted for installation in automatic (unattended) mode. On the net, you can find recommendations on how to prepare a specific application for automatic installation. Sometimes the described recommendations work for a specific software version, but not for subsequent versions, or the recommendations are associated with a decent amount of time for re-engineering the installation and creating the msi package using WiX Installer or other freeware tools. In such a situation, the system administrator has to repeatedly repeat the “dancing with a tambourine”, trying to make disobedient applications seamlessly install in unattended mode.

Unfortunately, the network almost does not contain a description of general approaches and recommendations for preparing an application for an automatic installation.

This article aims to fill this gap and describe the best practices for preparing unattended installations used in Infopulse projects.
')
In preparing applications for an automatic installation, consider the following features related to the fact that an application is installed not by a person, but by a special product or OS function that works (s) in automatic mode.

1. The application is installed under an account other than the user account under which the application will run. For example, if an application cannot work without a file that should be installed% USERPROFILE%, then this file will be missing for the user running the application, since the application was installed under a different account (often under a local system account) for which% USERPROFILE % refers to another directory.
2. The application is installed under an account that has excellent access rights than the user account under which the application will run. For example, if a user is a member of the Users group and not a local administrator on his PC (which is increasingly used in companies), then the application attempts to write some data to the per-machine resources (HKEY_LOCAL_MACHINE,% ProgramFiles%,% SystemRoot%) will fail on Windows XP, which will lead to an error in the application. For Windows 7, the situation is much more interesting; there the attempts of the process (launched in the standard, not privileged mode) to write data to the per-machine resources will be redirected to the Virtual Store, which does not always have a positive effect on the correct operation of some applications. You can of course cancel such redirection, but then we come to the situation that is described for Win XP.
3. The desktop and application windows for the account under which the unattended installation occurs are not available to the user. Therefore, if when launching the installation in unattended mode, an error message appears in the form of a modal window requiring a user response, then there will be no response from the user, since the user does not see this window on his desktop. This usually ends when the user shuts down his PC in the evening (or the system administrator removes the process), the installation process is not completed and the next day the Service Desk has a “headache” from the user (or users!) Complaining about a non-working application.

Requirements and recommendations for the preparation of installations for automatic deployment follow from the features described above.

1. If an application requires per-user resources (HKEY_CURRENT_USER keys, files in% USERPROFILE%) and cannot work without these resources, the unattended installation must ensure that these resources are installed for each user running the application, including for newly created users .
   Terminal servers have their own approaches and tools for solving this problem. For workstations, either Active Setup or using Self-Healing and Advertised shortcuts for msi installations will help you. But in this case, the msi installation must comply with the requirements of Microsoft and, accordingly, have no errors in the msi tables, which happens quite rarely: well, who among the developers of installations is serious about any Microsoft requirements there, many do not even guess about these requirements.
   In order for Self-Healing and Repair to work properly, you need to check the msi file for errors (this can be done using Orca or InstEd!) And fix errors in the msi database. But the vast majority of administrators go the other way - trying to cancel the creation of advertised shortcuts for msi installations (for example, through the DISABLEADVTSHORTCUTS property ), naturally, losing the ability to automatically install / update per-user resources for the user account.
2. If an application writes data to the per-machine resources during its work, and the users do not have local administrator privileges, it is necessary to ensure that the write permissions on the resources that the application changes to the per-machine should be set for users when working on Win XP. For Windows 7, you need to check how the application works when UAC is enabled and in the redirection mode of recording per-machine files and registry in the Virtual Store. It is advisable to include in the package itself (or the script, cmd file) unattended installations a point installation of write access rights to resources modified by the per-machine application. For the purposes of the dotted write access to certain resources, tula subinacl, setacl, secedit are suitable. The latter is preferable, since it is built into all versions of Windows OS, but more complicated to use, since it requires the ability to write inf files for it.
3. It is important to make sure that the exe installation does not display error messages in the form of windows that require user interaction, if the option to output messages to the log file and the option to install in unattended / silent mode is enabled. Usually error messages occur either in the absence of the necessary resources, or in the case of the inability to update the files to be installed. Therefore, to make sure that all error messages are stored in the log file and do not appear as windows, you need to specifically simulate an error for unattended installation, for example, by moving / renaming / deleting the file whose product or key in the registry is required for successful installation of the program. For msi installations, use the / qn command line option or the LIMITUI property to suppress all windows of the user interface.
4. It is necessary to cancel the forced restart OS, which can initiate the exe installation process. Firstly, because this process may not be the last in the list of applications installed automatically. And secondly, at this time a user can work with the system, for whom an unexpected restart of the system can be an unpleasant surprise. For msi installations, this is achieved by setting the REBOOT property to ReallySuppress.
5. If the application requires additional configuration after installation, then this configuration should be included in the unattended installation. You can, of course, install an unconfigured application, and then send users instructions on how to configure it, but thereby you significantly increase the risk of having a crookedly configured application among users. Well, a crookedly configured application, of course, complicates the work of the support service, and the more users, the more difficult the life of helpdesk, but ...
6. It is important to ensure that the installation also supports unattended mode of uninstallation and repair (Repair). Many software vendors that provide an exe installation that supports command line options for unattended / silent installations forget about unattended / silent uninstallation, which can create certain problems, especially if the number of PCs on which you want to remove software is hundreds or thousands.

The process of testing unattended installations is very important, as the quality and stability of automatic software updates depends on it. And the greater the number of PCs, the more likely "surprises". Therefore, to prevent errors, it is worthwhile to test the unattended installation, if possible, by adhering to the following scenario:

1. Prepared install.cmd and uninstall.cmd files for unattended installation
2. Prepared a system (or virtual machine), as close as possible to the configuration of the corporate OS on which users work
3. Copy installation files along with install.cmd and uninstall.cmd to a local directory
4. Run install.cmd under the local system account, for example, via Psexec.exe -i -s <executable>
5. We are waiting for the completion of the process
6. Analyzing the log file
7. Create a new user, a member of the Users group
8. Log in under this user, run the application
9. If the installation provided an automatic configuration of the application, we check that the application is properly configured.
10. We perform testing of the application (basic functions), changing the configuration of the application within the limits accessible to the user.
11. We close the application, open it again and check that the application is launched with the saved configuration.
12. We logoff for the user, we go as administrator
13. Run uninstall.cmd under local system account
14. We are waiting for the completion of the process
15. Analyze the log file (If the log file is not generated for uninstallation, this is an unpleasant moment for us, meaning that we will not be able to analyze errors that occurred during unattended uninstallation)
16. We go under the user, check that the application is uninstalled, all links (.lnk files) to the application are deleted from Start menu, quick launch, desktop
17. We look at the absence of application files in% ProgramFiles%

It is worth noting that the validity of the effort and time you spend on preparing and testing unattended installation depends on the number of PCs on which you plan to install the application and on the complexity of the application itself.
If the number of PCs is small or the application is complex and requires a lot of time to prepare, then it is still reasonable to manually update the software on each PC.
But if the number of PCs exceeds 300–400, and the amount of software that needs to be updated regularly is also not small, then there is a point in fulfilling these recommendations, since a manual installation will take more time than preparing and testing an unattended installation followed by an automatic installation.