What do we need to know to configure Deployment Solution 7.1? What are common issues? Configuration concerns? Anything we should watch out for?
NOTE: A more updated (and downloadable) version of this can be found here: Putting it All Together: Getting Started (Quick Start) Guide
There are some common aspects to any deployment of a product which this KB shall attempt to assist you in managing. We hope you find this useful, but acknowledge that it is by no means complete. If you are struggling to ensure your environment and setup is correct, please consider assistance from Consulting.
The first thing you need to understand is that Deployment Solution is mostly dependent on Notification Server and it's scalability now. Anything you may have known about DS 6.x is now largely irrelevant and should be essentialy forgotten (other than how PXE works). Scalability has completely changed, and for the most part, this document will not discuss it, except where DS adds additional requirements to those of the overall Notification Server environment. Here's a decent starting point though as of SMP 7.0 SP4 HF1:
- Remember that Deployment Solution relies heavily on task servers for functionality and will NOT work without it. The good news is that Task Server is now built in to the core of the Symantec Management Platform (SMP). Therefore, most of your scalability issues relate to the placement and functionality of Task Servers. However, this is not all.
- All deployment "images" are distributed as "packages" via "package server replication" - another built-in process of the SMP. Because of this, you will need to have the Package Server services installed in strategic locations where you will be doing imaging, for this is how the images will get to those locations, and you really do not want to be pulling images over the WAN.
- All deployment tasks require the Deployment Task Handlers, or, in short, the Deployment Share. The Deployment share is significantly different from in 6.x days, but still has things like the executables for RDeploy and/or Ghost, along with several other critical files.
- PXE is integrated into the Deployment Task Handler installation. PXE services however are not dependent on any other process and should be considered to be completely seperate for scalability. We simply recommend having it installed wherever you intend on doing imaging, and then using Forced Mode in DHCP to ensure your clients can reach the PXE servers when they boot.
- Currently, to make imaging function, all Task Servers that a client may connect to for imaging (see #1) must also have Package Server services and the Deployment Task Handlers installed to function correctly. By design, at this time, the assumption is made that when you connect to a Task Server for your Deployment Tasks (ALL deployment tasks are delivered this way), the Task Server will also have the image stored locally, as well as having the Deployment Share for the imaging tools (see the 3rd bullet). Work is being done to allow more flexibility in your Site Server configuration, but at this time, this is a requirement.
- The opposite is not necessarily true by the way. For instance:
- If you have a Package Server without Task Services, that is fine. It will work fine.
- You can install the Deployment Task Handlers to a server you want PXE on, and not install Task Server to that server. PXE wil function fine, giving you the ability to have more PXE servers where you want them.
- OOB can exist without any of these, or with any combination of these.
- However, when a client, in automation, connects to a Task Server - any task server, that Task Server had better have Package and the DS handlers.
- NOTE: Your Notification Server(s) do not have Package Services installed by default as recommended, but they are Task Servers, which can cause a problem with Deployment Solution 7.1. More will be said about this in the "Common Issues" section below.
- The opposite is not necessarily true by the way. For instance:
- Remember that your images take a lot of space, and that they will, by default, be replicated to ALL of your package servers. By default, this will occur under your Agent folder installation in the Deployment share. Sufficient drive space should be allocated to where you install the Altiris Agent on your Package Servers.
- Generally speaking, you should plan on a single Task Server supporting no more than about 5000-10000 clients. We usually recommend 1 task server for every 5K people, so in a 13K client environment (non-distributed), 3 Task Servers would be appropriate for good functionality.
- The only catch to this is for mass-imaging. If you will be doing a LOT of imaging, you need to consider the ability of your Task Server to host that many simultaneous image processes. One way to mitigate this in large-scale deployments is to deploy in a central location and then distribute, so that your Task Server can be dedicated to just imaging. Most people who are simply "reimaging" on an as-needed basis, or placing new computers occasionally will find that the recommendations in #7 are sufficient even when including Deployment/imaging.
- In a distributed environment, you should consider placing a Task Server in all remote locations. Because of #5 above, wherever your clients are being imaged, the Task Server to which those clients connect will also distribute the image. If there is no local Task Server, then the image will be pulled over the WAN, even if there is a local package server with the images stored locally. Again, there is work being done to modify this requirement.
- Pay close attention to the source location for your images (see HOWTO21731). If the source location of a package is damaged or removed, that damage is generally replicated out to all package servers. Thus, if there is any risk of a Site Server where you capture images on being damaged or removed, you should relocate images to the NS prior to doing so. As a good "rule of thumb", you should consider "moving" any image once captured to the NS, using the Import tool to import it and create a new "version" of the image, and then removing the original version, so as to reduce this risk.
- Automation Folders are faster and easier to manage. However, they only work on functioning, managed computers. An automation folder contains WinPE in a folder on the drive that we can actually boot from. This bypasses the need for a PXE server in many re-imaging scenarios, and is much faster to load. This is the recommended method of reimaing managed systems and should be seriously considered as a standard.
Here are some basic "steps" for getting Deployment Solution 7.1 up and running.
- Enable policies (see HOWTO26165). First and foremost for DS is to be sure all your policies are up and running. Several of these have links in the Silverlight Console. Scroll through each of them and enable all of them, for the most part.
- Be careful not to enable any uninstall policies at the same time as the install policies. This is a common error.
- Remember to enable upgrade policies, not just install policies. Out-of-synch agents are a cause of many issues.
- Be sure to select "Save Changes" on the PXE Server Configuration policy. MOST policies can be enabled via right-click in the left-hand pane of the Console (the Tree view), but this policy will not work correctly if enabled that way. More on PXE can be found in HOWTO21623
- Configure your Site Servers. If you have a very small environment, this could be only your NS, or you may have several. Please keep in mind #4 in the above section. For DS 7.1, all your Task Servers must have the Deployment Task Handlers and Package Services on them to work correctly with imaging, if there is even a remote chance a client that needs an image may connect to that task server when imaging.
- Create some Preboot Configurations per your needs. It is recommended you use 32bit builds in general because of driver support limitations in 64bit mode (though this will obviously change over time). Remember that these are client policies and will take time to download and build on your PXE servers, so build these with plenty of advanced notice, or be prepared to manually "hurry up" the process. If simply waiting, you should expect from 1-8 hrs for the PXE servers to get the builds (possibly longer depending on your client policy update process).
- Set up the PXE services to start automatically on all your Site Servers with Deployment Task Handlers on them and configure DHCP to point to them (PXE Forced Mode), if using PXE. You may also be using Automation Folders, and will have to ensure those are distributed (via policies) if so.
- Note that, if you have no need or desire to use PXE, you can skip this step. However, you will have to be sure to deploy automation folders to all clients you want to image and will only be able to image managed clients. For many environments, this is enough, especially in remote locations. However, if a drive fails or you get a new box, you have to either use PXE or some form of boot media to get a preboot OS on the system for imaging.
- Create some jobs. You'll need one to capture images, and deploy images. Here is a recommended "starting point" for your images, and you can expand or modify these as desired (jobs are extremely flexible and our clients are doing a LOT with them. We recommend Consulting services if you're confused here).
- For Capture Jobs:
- Prepare for Image Capture (this runs Sysprep and will prepare the NS Agent for duplication by pulling out the GUID. It will also shut-down and restart the system.)
- Capture Image (this will run Ghost.exe. A common error is to run this step first, but then it attempts to do so in production and will fail.)
- Reboot to Production (We use a reboot task at the end to tell the system "Hey, we're done now in automation - go back into production." At this point though, because sysprep ran in the first step, the minisetup wizard will run even on the capture/source system)
- For Deploy Jobs - Reimage Jobs for managed systems:
- Capture Personality (optional - if you need to preserve the personal data of the system prior to reimaging.
- Reboot to Automation (This will put the system into Automation. Remember to select the correct pre-boot environment. Most will use PXE, but Automation Folders is faster)
- Deploy Image (this will run Ghost and put the image down on the system. A common error in this step is putting in the wrong license files and not being able to complete the task creation! We know what OS the image was, so if the license doesn't match, we wont let you use it. Another common error is forgetting to put the Reboot task in first and then Ghost attempts to run in Production. This task will also put in a customized Sysprep file to help configure the computer. This step can also include DeployAnywhere to help get around problem related to different hardware on source and destination systems.)
- Reboot to Production (this is so the newly imaged system can go to production and run the Minisetup per Sysprep)
- Run Script on Server (Needed if any other tasks will be run AFTER this one. This is a filler script to prevent another known issue where the previous task ends too soon and the next task tries to run in automation and fails. Simply make something that will run on the task server for a few seconds like a VBScript with "wscript.sleep 3000" to pause for 3 seconds while the automation shuts-down)
- Apply System Configuration (Optional - this is used to customize the image with additional information not supplied during the Deploy Image task)
- Apply Personality (Optional - if you have a captured personality, now is a good time to apply it.)
- Other Tasks (Things like adding software or copying files - whatever you need to automate further)
- For Deploy Jobs - Initial Deployment jobs for unmanaged systems.
- All the steps above are the same, except do not include Capture Personality, Reboot to Automation.
- NOTE: There is a current issue with the final step as well - the Other Tasks. Some other tasks (like Software Delivery (SWD)) will prevent you from running the job on new systems because they don't have the SWD agent in production and fail a license check. You may have to job-chain to get around this until we can get that fixed.
- For Capture Jobs:
- Test. We can not emphasize enough the value of testing. Test capturing in all your OS envirnoment, and in deploying the same.
- Hierarcy Notes: Be very aware of Hierarchy Replication issues. You'll want to be sure several policies are configured up-stream so that they don't break anything down-stream, even if not being used on top-level systems. For instance, if you do not enable the policy for Preboot Configurations at the top, it will likely break one lower down the chain. Simply enable and save changes so that any replication doesn't break something down stream. You can then not use it at all if you want. Remember too that your preboot configurations will replicate down!
Here are a few things to be aware of, some of which were mentioned above.
- Be sure to use a JOB, not just a capture or deploy image TASK. One of the first calls we often get from new users is relative to their Capture Image failing immediately, which is almost always because they ran it stand-alone as you would in DS 6.9. DS 6.9 had all of what we now do in a job of several tasks bundled into a single task, but was less flexible because of that. You'll need to be sure now to build a job with all the appropriate steps as mentioned above.
- Pay attention to Site Server configurations. Several KB's are written on this. The section above on Scalability spells this out in detail as well.
- We get a lot of questions about SBS or PXE servers, scalability, and where these should be located. The main thing to note is that DS 7.1 is no longer limited in the same way DS 6.9 was, both for management of PXE/SBS server and in scalability for how many clients it can support. Try not to think in terms of what USED to work under DS 6.9 and instead pay attention to the scalability section above.
- We get a lot of questions about PXE and how to work WITH a PXE/SBS server. Same rules apply to DS 7.1 as did in DS 6.9. PXE servers require either an IP Helper or Forced Mode in DHCP to allow clients to contact them. PXE is a standard, not something we can modify, so it's implementation is approximately the same in all circumstances.
- We get several questions about image storage location. The recommendations above apply and are designed to help you avoid running out of space. Here's a few other ideas and reminders:
- Place Deployment site services on remote locations where possible to reduce bandwidth over the WAN.
- Remember that ALL images are, by default, replicated to ALL Deployment servers (site service) via package replication (remember they're all package servers). If you don't want this replication, modify the package as soon as it's created to avoid unnecessary traffic over the WAN/LAN.
- If you find yourself out of room, consider a mount-point pointing to a SAN or another drive, OR using HTTP imaging. The agent can also be moved to another drive (just like with package servers).
- There is some confusion about what a Backup image is, which is not discussed above. Some customers have used DS to backup systems for people like Executives that may not be able to afford ANY down-time. For example, an image may be captured weekly or something. We made a custom task for this called Backup Image, which doesn't apply Sysprep or do anything else. It also doesn't replicate this image out to any Site Servers, because it's only designed to be used for the one computer. It is, what it says - a Backup Image, not an image for distribution.
- Please be aware of our Release Notes for known issues. We update this regularly. For DS 7.1, this is HOWTO21623
Imported Document Id