Video Screencast Help

How We Improved Our DS Imaging Procedure

Created: 19 Mar 2008 | 10 comments
Language Translations
MBHarmon's picture
+1 1 Vote
Login to vote

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 = "" 
objMessage.TextBody = "%JOBNAME% on machine %NAME% was completed successfully at %DATE% %TIME%." 

objMessage.Configuration.Fields.Item _
("") = 2 
objMessage.Configuration.Fields.Item _
("") = "	SMTPSERVER"
objMessage.Configuration.Fields.Item _
("") = 25 


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


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.

Comments 10 CommentsJump to latest comment

MBHarmon's picture

I thought it might be important to note something a person in our usergroup found. This VBscript assumes that your network allows SMTP traffic. Many of them do restrict it in some way.

Check with your e-mail administrator if you need to add credentials or change the port.

- Matt

Login to vote
dfnkt_'s picture

I have looked into HIIS and may eventually decide to go with it. I thought first however I would like to know how to do hardware independant imaging by hand before I turned it over to a tool. Now that I am almost finished I may start looking at HIIS again. Thanks for sharing your processes.

Login to vote
erikw's picture

This is a very nice piece telling how to do this. I actually do the same, but i use the HII tools. The latest version is good, but as alway's it takes some moderation to get it exactly like you wished it should be.
Thanks for sharing this with us.


Regards Erik Dinamiqs is the home of VirtualStorm (

If your issue has been solved, Please mark it as solved

Login to vote
savnhga's picture

I have seen the HIIS Demo at MangeFusion, User Group Meetings, and in a company setting. I have also tested and used it in a test environment. This product is definitely the way to go if your company is just starting with imaging. They have done all the research and automated all the processes. After doing months of research to get the perfect image, HIIS was able to do in a couple of hours!


Chris Bashlor

Login to vote
savnhga's picture

I posted some links to videos about the HIIS product.


Chris Bashlor

Login to vote
paulsmith's picture

I like the idea of PXE redirection and will have to experiment with that.

As far as HIIS goes it is a nice product but we had to go with a long driver entry in the sysprep.inf which does work great "most" of the time but requires a lot of testing to get it right.

Login to vote
Pikoshi's picture

This deffinately gives me some direction for our setup here. I didn't know that vendors were actually willing to do the extra work to get the MAC addresses. I will have to call ours.

Also, PXE redirection is a very nice way of directing traffic. We have multiple sites and currently have it running on our network for imaging. Saves us a trip out to a remote location when new computers arrive.

If your question was answered, mark the anwser as the solution
Give thumbs up if you found a post helpful

Login to vote
setral's picture

On the Vendors and Mac Addresses, this is made easier by "most" manufacturers.

Such as IBM/Lenovo has the MACs already printed on the label on the side of the box, first one is usually the wired and second is the wireless.

However, HP desktops by default do not appear to have it on the box, you have to boot the machine and at least go into BIOS to get it.

Login to vote
fschiavone's picture

Nice article. I like the PXE redirection, but I have a different method for a similar problem. As for HIIS, We don't use it - I am strickly sysprep. However, I am managing a server environment so there aren't as many "rules" to follow as there are for desktops/laptops etc.

Altiris Admin on Servers

Altiris Admin on Servers

Login to vote
johnquinn's picture

I like this idea of e-mail notification and I was able to create a job in my DS and got the simple notification functioning.

So now here is my situation that I would like to come up with a solution to.

If I'm imaging a machine, it is usually based off a helpdesk ticket I have. I would like somehow to inject that ticket number into this process so that I can direct this e-mail to my helpdesk mailbox and have it update the ticket to indicate the imaging has been done.

Any thoughts on how to accomplish this? I was thinking about something like the very first thing when kicking off an imaging job is an input box, asking for the ticket number and that gets put into a file on the machine to be read or is held somehow and applied later. Not really sure as I'm new to scripting.

Login to vote