I even know a few people who run it at their homes (nothing I would
do). If you have AD and you are not using Group Policy Objects (GPOs)
to manage things then you are wasting your time. GPOs are the main
reason to put up with a Microsoft AD network. Since I am a designer,
who seems to have little time for design these days, I am no AD/GPO
guru but can cause some damage. I would like to pass along some of my
dangerous knowledge to you!
GPOs can do all kinds of things, but they are best at messing with the
registries of the computers on the domain. GPOs can also install
applications automatically on the domain computers. If you think that
process would be easy, you are sadly mistaken. The only way a GPO can
push out an application automatically is if the application is
packaged as an MSI. Some cool programs like 7-Zip and
Libre/OpenOffice have msi versions you can download and push out.
Other, cooler programs do not.
Here is how to make your own MSI files for pushing out applications
with software installation GPOs:
Requirements: 7-Zip, the 7-Zip 7z SFX Library
(http://www.7-zip.org/download.html), exe2msi
(http://www.qwertylab.com/), and Microsoft ORCA
(http://www.technipages.com/download-orca-msi-editor)
Step One: Understand the installation process of your program. You
want a silent install of the application. If there is an installation
wizard, you need to know how to script the install of the program. If
you can't do that then you are (mostly) SOL. In my example I want to
push out a program and schedule a task to run that program
periodically. To install the program I just need to copy a file to a
directory and then run SCHTASKS to schedule the task. I will use a
regular BAT file to script this process.
Step Two: Assemble the files. I usually make a directory that will
contain all the components I need to perform the installation. This
would be like setup.exe and any associated files. If you need to run
the installation program with command switches to make it run in a
scripted and silent way then you might want to call it from a BAT
file. The important thing to know at this point is what command is
needed to kick off the installation as it will need to be configured
in the self-extracting exe in the next step. Once all the files are
in the same directory, select them and right click to add them a 7z
file (scheduleProgram.7z in my case). The files for my program
consist of an exe file and the bat file used to make a directory, copy
the exe to the directory and the SCHTASKS string to schedule the task.
Step Three: Make the self-extracting exe file. Copy the new 7z file
containing the installation files and any scripts needed to perform
the silent install to a new folder containing the 7z SFX library
(7zS.sfx in my case). You will need to make a new text file called
config.txt and insert the following into it:
;!@Install@!UTF-8!
Title="Name Of Your Program"
RunProgram="install.bat"
;!@InstallEnd@!
You will need to edit the name of your program and change
"install.bat" to whatever is needed to install your program. In my
case it is install.bat as that creates a directory, copies the files I
need and then runs the SCHTASKS command. To automate the process a
bit, I usually make a bat file in this directory to run the command to
smush all these files together to make the self-extracting exe. You
can run the same command from a command prompt in the proper directory
or you can just make a "make.bat" in the folder with the following as
the contents:
copy /b 7zs.sfx + config.txt + scheduleProgram.7z scheduleProgram.exe
The "/b" is a binary copy and the "+"s combine the files together.
Copy copies the files and combines them into "scheduleProgram.exe".
This is a good time to test the new SFX executable, check the order of
the files in the copy command and the contents of the config.txt if
you have problems.
Step Four: After your SFX exe is tested and working it is time to turn
that into an MSI. There are many options out there, a free option is
the WIX (http://wix.sourceforge.net/) package. I am not familiar with
it and have had success with the free version of exe2msi. I am not
sure about the license or how the use of the free version is limited.
As the free version has problems from time to time, I assume the "pro"
version would have less issues to warrant the $299. Since the free
version is a decent product, if you have money in your budget and want
to support decent software consider buying the pro version.
Exe2msi is simple, run the exe2msi.exe program after installing it and
browse to the SFX Exe you created. Leave the arguments field blank
and just hit Build MSI. Once it is done then just close the exe2msi
application. Now the MSI is done and can be tested for installation.
If you can install the program as expected from the MSI you are ready
for the next step. If there are problems then double-check the SFX
Exe works properly and re-build the MSI.
Step Five: Test the MSI with ORCA. This will save a lot of time if
there are problems with the way the MSI was generated. Later, if you
notice the MSI fails to install via GPO but the Windows\temp folder on
the targeted computers is getting files like "MSI----.LOG" that look
like "1: 2905 2: C:\WINDOWS\sytem32\appmgmt\MACHINE..." then you need
to run ORCA.
When you run ORCA (which is an abandoned product from Microsoft to
exit MSI files and the databases they contain), you simply install
ORCA and right click any MSI file and hit "edit with ORCA". Once ORCA
opens the MSI file hit Tools, Validate. In the validation evaluation
file box leave it to read "Full MSI Validation Suite" and hit "Go".
When I was having problems I had the errors: "The
InstallExecuteSequence table does not contain the set of actions
(PublishFeatures, PublishProduct)" as well as "The PublishFeatures
action is required in the AdvtExecuteSequence table" and "The
PublishProduct action is required in the AdvtExecuteSequence table".
To fix those errors I added a row to the InstallExecuteSequence and
AdvtExecuteSequence tables for PublishFeatures (with a sequence of
"6300") and PublishProduct (with a sequence of "6400"). After any
required edits are done, save the MSI file.
Step Six: Make a share on the server to hold your installation files.
Share out the folder with permissions to "AUTHENTICATED USERS" and
"DOMAIN COMPUTERS" to have at least read and execute permissions on
the share and to the files themselves. The Software installation GPO
runs with the computer account and not the user account, those two
groups with read and execute permissions should allow the computer
account to run the installation MSI.
Step Seven: Open Group Policy Management and make a new GPO and link
it to the OU for the computers you wish to target. It is best to make
a test OU and move a machine you wish to test the GPO with into that
OU. In the Group Policy Object Editor, under the "Computer
Configuration", "software installation" area, hit New, package.
Browse through the network to the share you created in step five and
select the MSI you wish to install. Do not browse via the "my
computer" or any path that uses drive letters as the computer account
installing the MSI will not have access to those resources, only paths
that look like "\\computer\share\install.msi" will work. Make sure
the package with the MSI located in the proper path ("source" should
be like the noted path and not have any drive letters), make sure the
package is "assigned" and the GPO link is enabled to the OU where the
testing computer is placed in Active Directory.
Step Eight: Wait and reboot the computer or run GPUPDATE /FORCE on it
to force the GPO installation to start. Either one will make the
computer reboot, check the GPO and install the MSI as you configured.
If there is a problem and you need to re-test, you can later right
click on the package and hit "all tasks", "redeploy application" to
force it to be sent back out to the computers in the linked OUs.
If you have problems in step Seven where you can't edit the new GPO
because of some "path not found" error, right-click the new GPO and
hit "Back Up..." and back up the new GPO to some location on the
server. Then, right click the new GPO and hit "Restore from
Backup..." and restore the same GPO back. For some reason this was
necessary in my situation.
Software Installation by GPO is a typical Microsoft solution where the
promised benefit is almost outweighed by the efforts to implement what
should be a simple process. The lack of tools which should come with
Microsoft Windows Server make the situation almost impossible for the
casual network admin to implement GPO software installations.
Hopefully this can guide you though the process to actually implement
GPO software installations.