Automation Folders can be a powerful part of your Deployment Solution configuration, but in the 7.1 release of the product can also pose some tricky scenarios to make it work.
The biggest advantage is performance, considering
Please keep these in mind as you follow the rest of the documentation below.
Default Policies (What
NOTE: We do not recommend
In the Console, under Settings | Deployment, the only part of Automation Folders you can work with is under Create
Every package has to have a software component attached to it with rules on how to deploy the package. Installation strings, uninstall strings,
Though not technically supported, cloning default packages, policies, and reports is the best way to
There are, however, several valid reasons to
Custom / Alternative Methods of Deploying of Automation Folders
For deployment of
There is already a default "Automation Folder" configured in the console for both
As a general rule, this will be sufficient for
The only time you may want a different automation
The default package
NOTE: If you have deleted the default automation folder in the console, the package still exists, and the install/upgrade policies still point to it. You can either recreate it by exact name in the console (should work) or make a new one of a different name, and then when you rebuild the "new" one, use that to replace the EXE in the
Automation folders, like other automation environments, must
As mentioned before, Automation Folders are not
The only reliable trigger to make the site servers get the rebuilt automation folder is to run the
When the EXE runs, it extracts the files into a folder under the root of C called "Boot
IMPORTANT: For Windows XP systems, this means upgrading the Boot Loader,
IMPORTANT: For systems that are already multi-boot,
Running / Rebooting Information
When a task
The policy to upgrade your Automation Folder is -
Thus, the best thing to do for updating your automation folders is
By the time the clients get the upgrade instructions, they will run against your now updated package. This works. Anything short of this will give you mixed results.
Alternate Unsupported Upgrade Method
Automation Folders are essentially made of two things: a WIM image file of WinPE (or LinuxPE which is not being discussed here) and some supporting files/executables to manage the WIM and BootLoader. Microsoft has made ImageX for the express purpose of directly editing and/or creating WIM files. It can mount a WIM file into a file folder where it can be manipulated like any other set of files, and when it's run again, the files are instantly re-compressed into the original package.
So, another option (unsupported) for upgrades is to modify the WIM file directly using ImageX. For instance, you may have imported some new drivers and you may want to manually copy those into the WIM. Or you may have modified an INI file, or EXE version, and simply need to do an update. Manually, you can launch ImageX to mount the WIM, make the changes you need, and then un-mount it.
The good news here is that the policy to remove automation folders works well. Enable the policy and all automation folders will be removed.
If you need to target a selection of systems, we recommend you clone the policy leaving it disabled, modify the cloned policy to contain just your target, and then enable it. Remember, we never recommend modifying a default policy.
Because Automation Folders are not centrally managed but are installed on each computer, we highly recommend testing thoroughly before enabline the policy, on all equipment versions you own. A representative LAB or lab-environment is highly recommended.