So the process of deploying software (MSI packages) to domain member machines is well documented, and won't be repeated here. What's not so well documented is what happens when you try to deploy software to domain controllers. If the installation binaries are stored on a plain vanilla fileshare, no problem. However if the binaries are stored on a DFS share (for example, the SYSVOL share...), there is an important rule to follow: make sure that the binaries are stored under the built-in "scripts" folder, and not under a folder directly under SYSVOL -- i.e., don't modify the default SYSVOL folder structure.

The scripts folder is a holdover from NT4 days -- it's the NETLOGON share, where logon scripts were stored, once upon a time. In Active Directory, this folder can be found at \\{domain}\sysvol\{domain}\scripts), or \\{domain}\scripts.

The issue is that DFS (and therefore the SYSVOL share, which is just a glorified DFS share) doesn't come online until AFTER the software installation (and startup script) portion of the GPO executes. And since DCs always point locally for SYSVOL data, if you try to be clever & create a top-level folder for software binaries directly under SYSVOL, the software installation will fail with a Software Installation error 103 (in the Application log) "No package in the software installation data in the Active Directory meets this criteria."

Because the scripts folder is available prior to DFS and SYSVOL, both startup scripts and software pushed from this location via GPO will install correctly.