Deployment server has some great options for automating process. However many of those options can go unused for awhile simply because you are not exactly sure of how your organization would use those abilities granted by Deployment server. Recently at our organization we went through a close review of options to streamline the new equipment process. Here are some details for how we proceeded.
Please note that much of this will seem very basic to most people, but often times, ideas on how to use those basic processes can lead to much more advanced processes.
Problem: Bulky Hardware Independent Image
I would like to give a little background on how we were using Altiris Deployment Solution before we talk about what changed. Hardware independent imaging is quite a powerful option available to those of us using the Altiris Deployment Solution. By using the firm command we would inject the drivers and applicable HAL files onto the computer similar to what's been documented by so many other people. The problem was when we first setup our Deployment Server we did not know about Tokens or really even much about scripting so each computer model, while using the same image file, had it's own job that had separate tasks within it that would load those model specific utilities that come from some manufacturers.
Solution: HIIS
We quickly overcame that problem by using Altrinsic's Hardware Independent Imaging Solution (HIIS). The HIIS product identifies hardware classes for us and gathers drivers so much of the manual work separating those out is now being done for us. If you are looking for an easier way I would recommend investigating it, still however we could have used tokens to identify our computer's model and drop those drivers from an appropriately named folder onto the computer. Also you could use the HII Tools that are available for download here on Juice.
Problem: Multiple Locations
Like many companies we have multiple locations that we image computers from. Each location has a package server and PXE running on those servers. By imaging locations we initially made the mistake of creating a single PXE entry for each location that would map a drive to the deployment servers at those locations. So we soon ended up with a long list of locations; Denver, St. Louis, Chicago, and so on. Of course we also created separate jobs for each of our models again in those locations. I assume by now you are seeing the management nightmare we had created for ourselves. However tokens couldn't resolve this for us immediately. The DOS PXE options we are using don't display IP address information in the console until it's booted into windows.
Solution 1: PXE Redirect
By taking the time to use a PXE Redirect we were able to condense all of those PXE options all down into one "Regional" Shared PXE option that would re-direct to a local PXE option to map the drive accordingly.
Solution 2: Assign a separate Job with conditions
By waiting until a computer had booted into windows we were able to get IP address information into the console to run conditions from. It was easily done by adding a Run Script at the end of the job with a single line with the word EXIT and any number following it. Then you can quickly add that number to your list of return codes and have it assign your separate job.
When you are finished, the last screen on your Run Script will look something like this:
When creating the next job the feature we were using is called a "Condition". Conditions are found on the console's right hand pane. You can see an example here.
As you setup each condition you'll want to make sure you know that they'll be evaluated in order presented. In this example if the conditions for the Chicago Basic Load are met, in this case it is an IP range, then the set of tasks for that load are run. If not then it moves down the line and checks against the Houston Base Load, continuing until it finds a match. If it doesn't find one a computer will run the information found in the "(default)" condition. In our example we're running those installs from here in our main corporate office.
Problem: Model Specific Tools
Obviously there are a number of model specific tools that laptops come with. Many of them are very useful and in the case of Lenovo/IBM can be the reason that manufacturer is chosen to provide products. Now we can handle that information with a DS token in the main image that will copy a custom commandlines.txt file down for sysprep to use, but it made me feel like I was losing some good logging information.
Solution: Another Job and More Conditions
By following the same steps as above and having a Run Script assign the model specific tools job I could use conditions on that job to make sure that the appropriate tools got installed. Everything from DVD player software to Wireless networking tools is installed based off the computer's model.
Problem: The 50 computer week
I am sure we have all had these weeks when suddenly an entire department decides they need to have all of their computers replaced. Oh yeah, and we need to have it done before this big new project starts on next Monday. If you have a miracle vendor then they might be able to get you that hardware in time, but how do you set all of those up and get them ready to go?
Solution: ImportComputers55.xls and your vendor
Many vendors can provide some information to you when you order a new workstation. In our case we have contracted our hardware vendor to do a bit more. Currently we are having our vendor configure all hardware and place an asset tag, which becomes the computer's internal name, on each workstation for us. In addition to that we asked them to provide us with a list of those Asset Tags and the MAC address for each of them. Using this information we're able to setup those computers in the Deployment Server.
On a one for one basis it isn't hard, but when receiving 50 computers at a time we need an automated process to get those imported and get a job assigned to them. Altiris helps out by providing an example file to help you import those computers. When you first look at the ImportComputers55.xls file there is a lot of information in there. However we don't need all of that filled out. When you edit the file with excel the bare minimum we had to fill out were columns A and B (Name and MAC Address 1, respectively). This would get a computer object into the "All Computers" folder.
Still we wanted to do more. By looking through the available options we found column AP to be handy. This will allow you to specify what folder to store these computers in, thus separating them out. However maybe you want to take it even further and begin a new image. By specifying the name of a job located in the root of the Jobs pane and a scheduled time in columns AQ and AR, respectively, you can have a job automatically kick off.
We are sticklers on organization so we had that job assign our base image job similar to the methods I mentioned above.
Problem: Tracking Completion
Now that we had improved the flow of our jobs and the technicians only have one to assign instead of one for each model in each location, we wanted to make sure they were notified about when those jobs were completed. Those technicians obviously couldn't sit around and wait for Altiris to finish running a large imaging job such as we had setup.
Solution: E-mail Notification with Deployment Server
Notifying the technician that the computer load had been completed can be a tricky thing. There are not any built in e-mail options I've seen with Deployment Server and though we could do a "Net Send" command many networks, including ours, disable those services on workstations. By using a tokenized VB script we can not only e-mail our techs, but also let them know some additional information.
NOTE: I believe this does require security to be enabled as it will record the user assigning the job.
We first created a tokenized txt file that would create our VB script with the custom information we need. Here is an example of what I have. Of course you can include more if you need.
Set objMessage = CreateObject("CDO.Message")
objMessage.Subject = "Job Completed"
objMessage.From = "%DSSERVER%"
objMessage.To = "%JOBUSER%@domain.com"
objMessage.TextBody = "%JOBNAME% on machine %NAME% was completed successfully at %DATE% %TIME%."
objMessage.Configuration.Fields.Item _
("http://schemas.microsoft.com/cdo/configuration/sendusing") = 2
objMessage.Configuration.Fields.Item _
("http://schemas.microsoft.com/cdo/configuration/smtpserver") = " SMTPSERVER"
objMessage.Configuration.Fields.Item _
("http://schemas.microsoft.com/cdo/configuration/smtpserverport") = 25
objMessage.Configuration.Fields.Update
objMessage.Send
After saving the file in a location you simply need to run a script to create the token and execute it. Ours looks like this.
REM ReplaceTokens \\DSNAME\express\scripts\completed.txt \\DSNAME\express\temp\%ID%.vbs
\\DSNAME\express\temp\%ID%.vbs
Now our team members can assign this job after their first image to be notified when all those jobs have been completed. There are some great, and not so great, things about this script. It can be included on nearly any job for someone to be notified when those jobs are completed. However, when having one DS job assign another the %JOBUSER% token doesn't come over properly. It is a bit frustrating, but in our case there may still be follow up applications scheduled so we also made this its own separate job so it can be scheduled. Also if your deployment server has as many jobs as ours, adding this Run Task to each one can be a daunting task.
But in our case just because the Deployment Server assigned a job doesn't mean we can't send an e-mail. Static e-mail addresses or distribution lists can be substituted in the script so that your team or even designated technician is notified that the install has been completed. This can be especially helpful if you are in a rollout situation and you have helpdesk Solution. By sending an e-mail to a box monitored by helpdesk solution you can have an incident automatically generated to help handle any additional work required for this install.
I hope taking the time to look at a detailed view of another company's deployment process might give you some ideas. I'm always open to more so please let me know if you have any for me as well. I want to thank Nick on Altirigos for his initial inspiration with my VB Script. It is certainly important to share with others because not only does it help them you will often find you have found some great information you never would have otherwise.