Managing Automation Folders: Creation, Upgrades, and Removal
Article ID: 181407
Updated On:
Products
Issue/Introduction
This article provides information on Managing Automation Folders, and specifically in regards to creation, upgrading, and removing them.
Environment
Deployment Solution 8.x
Resolution
Automation Folders can be a powerful part of your Deployment Solution configuration.
Fundamentally, the biggest issue is that the Automation Folders need to be updated on each machine, rather than in a central location like PXE. If a change needs to be made to a PXE configuration, it is relatively centralized, and can quickly be updated in such a way as to affect all users. Automation folders are installed on each computer, so an update to all of them can be fascinating. When you toss in the inability to actually perform an upgrade, this becomes a challenge.
The biggest advantage is performance, considering getting into automation is much faster than PXE. Additionally, you don't have to manage the network protocols / issues.
The purpose of this document is to help you manage Automation Folders in your environment.
- Important Notices
- Policies & Configuration
- Creating your own Policies & Packages (custom not supported stuff)
- Automation Folder Creation and location
- Rebuilding Automation Folders
- Updating Site Servers
- Installation / Running Information
- Upgrades
- Removal
- Labs, Testing and Deployment (please read first)
Please keep these in mind as you follow the rest of the documentation below. At times, there will be referenes to these in this document by number.
- Please do not delete the default two preboot packages: PEInstall and LinInstall. These are directly associated with the policy that pushes automation folders, and removal will cause issues for using this policy in the future. It can be resolved and/or worked-around, but it is better to leave them. In a future release, the ability to remove this is blocked.
- If you create your own automation folder package, it will not, by default, be used with the policy that rolls out automation folders. You must either modify the package to point to yours, OR build your own package and/or copy file job to do so. The process to perform the latter of the two is actually detailed below as a part of testing automation folders.
The purpose of this section is to ensure you understand where automation folders reside in the console and how to manipulate these console items.
Default Policies (What you should know well)
NOTE: Symantec/Broadcom does not recommend modifying any of these policies and/or packages. if you find you need to do so, please refer to the next section in this document for some suggestions on how to do so.
In the Console, under Settings | Deployment, the only part of Automation Folders you can work with is under Create Preboot Configurations. This can be used to add new automation folder builds, or update existing ones. Take careful notice of any messages that appear though, as clicking on the wrong buttons at the wrong time can cancel new builds or upgrades.
Generally, you'll be working under Settings | All Settings.
- Settings \ Agents/Plugins \ Deployment and Migration \ Windows (x64) [ or (x86)]. There are 3 policies here worth noting:
- Deployment Automation Folder Install - We recommend leaving this turned off until you've fully tested and are sure your packages are ready. This package policy points to the default PEInstall automation folder package that comes with the installation of Deployment Solution. By default, this will exclude all site servers, which is appropriate. Site servers should not be re-imaged anyway, and that's the only valid reason to have automation folders on them, unless you intend on making backups (this is not the best method for that though).
- Deployment Automation Folder Upgrade - This policy is essentially not worth using. Leave it disabled.
- Deployment Automation Folder Uninstall - This policy should always be disabled unless you intend on removing all automation folders in the environment. When enabled, it works very well.
- A similar set of policies can be found for Linux. NOTE: Most of the testing done on Automation Folders currently is in WinPE, so this document will not have any more on Linux Automation Folders.
- Settings \ Deployment and Migration \ Symantec Boot Services (PXE) \ Preboot Configurations. This is the same as mentioned above, just a different way of getting there.
- Settings \ Deployment and Migration \ Driver Database Management. Here, you'll be adding drivers to BootWiz to augment the drivers in your automation folders. VERY important to be aware of and to do before you roll Automation folders out in your entire environment.
Default Packages
All the deployment packages can be found under Manage | All Resources and then under Default \ All Resources \ Package. If you type "Deploy" in the search field, you can find the various packages we use. Right-click any of these and choose Actions | Edit Package. This will allow you to see where the package source files are, and to force an update to distribution points (package servers).
Every package has to have a software component attached to it with rules on how to deploy the package. Installation strings, uninstall strings, etc, are stored in the Software Component. The Deployment Software Components are found under Manage | All Resources and then under Default \ All Resources \ Software Component. Type "Deploy" in the search field to narrow down the list. Right-click any of these and choose Actions | Edit. This will bring you to a screen with several tabls. The second tab has the install and uninstall strings, which can be very useful if you're creating your own packages (see next section).
Creating your own Policies & Packages
Though not technically supported, cloning default packages, policies, and reports is the best way to modify defaults to suit your own purposes, for several reasons:
- It's not supported to modify the default packages, policies, and reports anyway.
- Leaving the defaults in place serves as a backup.
- We DO support the default packages, policies, and reports, so if something really IS wrong in the console, we will see it there, and can help you.
There are, however, several valid reasons to modify our packages, policies and reports. In the event you need to do so, you should:
- Right-click the desired package, policy, or report. Select "Clone" from the menu.
- Give the new package, policy, or report a new name and click OK
- Ensure the original is disabled if it is a policy. Leave the new one disabled as well if it's a policy.
- Modify to your desire.
- Replicate (package), Enable (policy) or Run (report) the new item.
Specifically, for the purposes of Automation folders, you would use this for testing purposes to target a limited number of systems. See the Lab section below for more on testing.
Custom / Alternative Methods of Deploying of Automation Folders
Additionally, you can create your own packages, your own policies (very simlilar to what is already there) or even create a Task to perform a similar function. The latter option can be very useful in testing. A Quick Delivery task could also be used, but we would actually recommend against that as it would require a relatively complex creation of a new software delivery policy.
For deployment of Automation Folders, a "Copy File" task is well suited:
- Under Manage | Jobs and Tasks, right-click on any folder and select New \ Task
- Select Copy File from the Deployment sub-heading on the list of new tasks.
- Under the "Source" drop-down menu, select 'Upload from Local System'
- Under 'Location', use the 'Browse...' button to browse to and select the executable in the folder where your custom automation package is
- Enter credentials have permission to copy files to the target systems.
- Under 'Destination', enter a folder on the target systems where the install package will be copied to before execution. This can be a temporary folder and can be deleted later if needed.
- Under 'Command Line', enter "<destination path>\<configuration name>_x86.exe" -s -h. Note, this will be very similar to what you would see in the Software Component for the default components (see Policies and Configuration above).
- Enter credentials that have permission to run and install files to the target systems.
- Enter an appropriate/descriptive name for the task and Click 'OK'.
Automation Folder Creation and location
There is already a default "Automation Folder" configured in the console for both WinPE and LinuxPE when the product is installed. These should not be removed or deleted as noted above. The default policies use these and it is much easier to leave those policies intact rather than to try to re-create them.
As a general rule, this will be sufficient for any and all your needs.
The only time you may want a different automation folder environment would be if, for some reason, you wanted one section of your computers to have a different automation folder experience than another - not recommended. Please simply work with the default.
The default package is also built by default, and you can find the default location by looking at the package as outlined in an above section. The default location for all automation folders differes significantly from the other Deployment packages in that they are NOT in the deployment share under the agent. They are instead under Program Files \ Altiris \ Notification Server \ NSCap \ Bin \ Win32 \ X86 \ Deployment \ Automation. They are found in individual folders here named according to the package name you created (or we created in the case of the defaults). This is very important to note for other aspects of customization.
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 package of the default. Not using the default package will cause much headaches in the console!
Automation folders, like other automation environments, must be rebuilt to include any additional drivers you may have added. Unlike PXE environments, the automation folders are ONLY rebuilt on the NS, NOT on the site servers. They are rebuilt on the NS and then replicated to the site servers via package replication. Rebuilding is exactly the same - selected in the console, and then you have to wait for BootWiz to run on the NS. Then please follow the steps in the Upgrade selection below.
As mentioned before, Automation Folders are not quite like other DS packages in that they are located under NSCap instead of the Deployment share. In this way, they are actually more like the other default packages that come with NS, and are therefore replicated like those other default packages. Normal Package Replication takes care of all packages under both shares (including agents, images, copy files, etc.) and will also replicate the automation folder updates you make.
The only reliable trigger to make the site servers get the rebuilt automation folder is to run the Package Refresh schedule in Scheduled Tasks (Computer Manager). This is recommended. Without forcing this, the packages will not be updated until 3am-ish when this schedule runs on it's own.
Installation / Running Information
The purpose of this section is to help you understand what is happening during the actual installation of Automation folders. This may be useful for troubleshooting, but will also be useful in your lab environment.
When the EXE runs, it extracts the files into a folder under the root of C called "Boot". This is where you look for anything related to the automation folders. It then runs a tool to modify the boot loader to be able to boot from this WIM file in this folder.
IMPORTANT: For Windows XP systems, this means upgrading the Boot Loader, which has been known, rarely, to cause problems. The boot loader must be Windows Vista or later compatible.
IMPORTANT: For systems that are already multi-boot, this is sometimes known to cause problems. Some recovery partitions we can work with, but as a general rule, we recommend NOT having any recovery partitions on systems that are managed via Automation Folders. Any incompatibility with a recovery partition will not be resolved by Symantec, and you'll be recommended to get rid of it. The Automation Folder and Imaging overall replaces the need for recovery partitions anyway.
Running / Rebooting Information
When a task is executed to reboot to the automation folder, several things happen. First, we read critical information from the local system that will be needed in Automation. This includes if you use DHCP or Static IP in your environment and what IP address the system is using in the case of a Static system. This information is recorded in an INI file for use by WinPE when it restarts. We also flip the BootLoader to restart to the WIM file / folder on reboot. Both of those steps occur via exe/s in the BOOT folder. The Symantec Managment Agent then shuts down and restarts the system.
The policy to upgrade your Automation Folder is - fascinating, and misleading. Unlike most upgrades in NS, this one does not target a "version" of folders, but instead fires on all systems. This introduces a problem: If the automation folder installer is not yet upgraded on the site server to which you connect for packages, your system will run the old installer and apper to not get updated at all! Only a check of the file dates show that they were in fact updated, though no changes appeared.
Thus, the best thing to do for updating your automation folders is as follows:
- Disable the upgrade policy.
- Rebuild your automation folder via the console. Ensure BootWiz runs to completion.
- Run the Package Refresh schedule in Scheduled Tasks (Windows tool that can be found in Computer Manager or Administrative Tools).
- Ensure the package servers have been updated (should take no more than 30 minutes in most environments)
- Enable the upgrade policy.
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.
- Make sure to either have, or have access to, every version of equipment you own in the office (other than servers / site servers).
- Collect and install all requisite drivers as early in the process as possible to avoid rebuilding over and over. Remember this is WinPE 2.1, which is a VISTA driver set, not Windows 7.
- Don't assume that the same "name" of a system has the same driver requirements. All PC manufacturers are known for changing equipment in the same model lines, sometimes even in the same shipments!
- Clone the install policies and target the test systems before enabling the default policies to ensure the processes work well.
- Create tasks for install and removal for the "one-off" tests / fixes you may need. Test these to be sure they work.
- Test both the install and removal processes so you are comfortable with them.
- Only after you are comfortable with the entire process should you then enable the policies and push out the Automation Folders to your environment.
Additional Information
Feedback
