DS 7.1 finally introduced a usable PXE implementation, but for everything but bare-metal deployment, I'd argue that automation folders are a better solution. They boot into automation faster, they are easier to configure, and best of all they don't require a CCNA and access to your entire networking infrastructure to install (especially in a modern VLAN environment)! Unfortunately there's really very little documentation on them. In the console you basically only have a package, a policy to push it, and the Preboot Configurations pane with its mysterious Recreate Preboot Environment button. In the following I will attempt to remedy the lack of information and hopefully provide you with a better working knowledge of this important tool.
The precursor to the automation folder (AF from here on out) in DS 6.x was the automation partition, and boy was it a pain. It was unreliable, frequently caused issues with the host drive partitioning and to top it off did not support access to the production drive directly in WinPE! In 7.x these were replaced with AF, which are much more robust and trouble-free. An AF is just that, a folder on the production drive containing files and scripts necessary to create an automation ramdisk which can be booted to without messing with the partition table and while providing full access to the production drive in automation.
At the heart of AF is the Boot Disk Creator, or bootwiz utility. Anyone familiar with DS 6.x (or 5.x.. and even farther into the past) will be familiar with bootwiz. It's a command line utility whose job is to configure and package up preboot environments. In both 6.9 and 7.1 it can create PXE automation boot images and automation boot media (CDs and USB drives that can boot into automation). In 6.9 it could also create the dreaded automation partition. In 7.0 these were dropped and replaced with AF. There is plenty of documentation out there on bootwiz from 6.9 and previous, and largely it has not changed. There is a ton of customization of the preboot environment available that is not exposed in the 7.1 web console. I urge you to explore bootwiz documentation and play around! You can add support for more WinPE options (hta support, etc), files and scripts necessary to access your preboot environment via remote control, really anything you want that works in WinPE. You will need to create at least one configuration (I chose to call it PEInstall to match the 7.1 name).
The AF relevant changes to bootwiz consist of new options in the file menu to create AF installers and uninstallers. It's relatively straightforward, with one caveat: if you are looking to create 64bit AF installers, only pick the first x64 option (automation environment type). The second one (boot media processor type) controls the installer, and it's really more trouble than it's worth to have a 64 bit installer which won't work in a 32bit OS.
Once you have your installer (uninstallers are universal, you really don't need to create a new one) you have two choices. You can copy them on top of the ones generated by the 7.1 Recreate Preboot Environment button (by default in nscap\bin\Win64\x64\Deployment\Automation\PEInstall_x64 and PEInstall_x86), or you can create your own packages for them along with your own policies and/or tasks to deploy them. The command line attributes you want are -s -h to run it silently.
Finally you now have your own customized AF installer. What does it consist of? Besides the WinPE or Linux image and ramdisk, there are really two tools of interest. The first is autoinst.exe, which gets installed to C:\boot\altiris\iso by default. This is run by the installer to set up the boot loader. In Windows XP, it actually replaces the XP boot loader with a vista bootcfg-based bootloader (needed to enable WinPE 2.1 booting). Generally you won't need to run this manually, but of particular interest is the log file it drops in the root of C: when it's run by the installer. C:\autoinst.log. This is the first place to look when you have installed your AF but it doesn't work. Subsequent runs of the installer will append a number (autoinst2.log, etc). The second tool is autoutil, also in C:\boot\altiris\iso. This is the tool which does the actual work to switch whether the PC will reboot into production or automation next. You can run it with /? for syntax, but the most useful option is -a. Autoutil -a sets the bootloader to reboot into automation at the next boot (but only once!). Now you can do things like (in a mixed environment of DS 6.9 using PXE and DS 7.1 using AF) use the DS 6.9 console to install an AF, run autoutil -a, and reboot into 7.1 automation to push an image from 7.1!