software distribution through ActiveDirectory

Question

Google Workspace

Hello, friends.

There is such a technology as software distribution through ActiveDirectory (msi packages). How can I find out the application logs of this policy in the domain? There is a policy, but the result of its application is not at all obvious (Maybe there wasn’t enough space to install it, or the installer version doesn’t suit you, or something is missing, such as old dotNet, etc.). Does the workstation report to the domain controller for the result of applying the policy (I know about logging in the system log)? Or is the software distribution policy only half of some tool (such as SMS) that needs to be purchased separately?

PS
While I am writing installation scripts js->WScript.Run("msiexec -i *.msi /passive /norestart", 0, true), I prescribe them to the startup of computers, then, after installation, I programmatically check through the registry (RegRead or WMI) or by the presence of certain files in a certain path, and I write the results of the check to a text file of logs in a network share. This method allows you to "distribute" not only msi, but also InstallShield, innosetup, etc. installers (but not all programs, but only those that support silent installation mode without launching extraneous windows or programs). In this case, the installation process is limited in time - the scripts are worked out in the morning, so by lunchtime I have an 80% result. But I have to prepare in advance: today I am writing and debugging scripts, before leaving work I register them in autoload, tomorrow they start in the morning.

Answer 1

Events are logged locally in the eventlog, see technet , events 101-110, 201-204, 301-308. Something more functional - yes, for example, SCCM.

Answer 2

These events are familiar to me. Somehow I wrote their interception via wmi. But it seems logical to me to approach the installation in this form:
1. Attempt to install (taking into account a small set of environmental data, for example, know the version of windows, so as not to accidentally launch a deliberately unsuccessful installation of windows installer 3.5 for X3 XP on windows server 2003).
2. Getting the installation result (determining the version of the same windows installer after installation).
3. If the result is not achieved, then even knowledge of the events is hardly worth considering for automatic adjustment of the installation algorithm. I think that in any case it is necessary to deal with an unsuccessful installation manually.
The use of SCCM (formerly SMS) is questionable, again due to the way it is supported in installer types. Do you know if it supports anything other than *.msi?
(Preparing a package of changes in the system after installing any application is not good, because such packages may be different depending on the version of windows)

Answer 3

The production path is the standardization of software by sets of workstations, then the creation of customized installation images using ADT or SCCM.
Provides the following benefits: -
checking software for compatibility,
- speeding up deployment,
- ease of recovery.