Deployment and Imaging Group

My deploy jobs go as follows

Reboot to PXE, deploy image, run a task to do token replacement to rename machine to serial, reboot to production. This works great.  Then the job has 11 (and growing) package delivery tasks as part of the job (install flash, etc).

When deploying an image, I am having a serious problem where after the machine boots to production, it doesn't realize sysprep isn't done mini set up and goes right on to installing the first post image package delivery tasks.

This is fine except sysprep/mini set up still has 1 reboot left, and when this reboot happens it's causing my deploy task to fail wherever it is at time of reboot (sometimes it's on it's 5th package sometimes the 6th, etc).  The same packages install fine with quick delivery every time, I know it's not a package issue.

I don't think I was seeing this in my prior testing because my post image tasks ran quick enough it didn't matter. As we're adding more tasks it's becoming a problem.

I tested this as happening with and without deploy anywhere so I don't think that has anything to do with it.

After reboot to production I tried adding a task to "update client configuration" and I made my first software task that runs after that set in advanced settings to not allow other tasks to run while the first task runs thinking that the update client config would slow things down enough to give enough time for packages to install - but I'm still having the issue.

No errors on CMS server logs that I can find.

I feel like my only options would be to build these jobs into the image (don't want to do this, I wanted the image to be easy to update with as little on it as possible) or have a deploy image job and then have an install software job - however this is inconvenient for my staff who are used to DS 6.x drop the job and you're set.

Am I doing something wrong?  There has to be others out there using DS 7.x with post image tasks?

can you omit the agent from image, and script it so that it will install the agent after minisetup is finished, such as using cmdlines.txt in XP?  many of us handle it that way in ds6.  I didn't experience this issue when i tested ds7.1, but i was also working with win7 which may make a difference.  

I need at least the deployment agent on the image in order to capture it properly (unless I'm missing something?).  I am using win7.  Issue didn't happen for us until we got a larger set of post image tasks (timing issue of when that mini setup reboot happens vs what task is running... I think if the reboot happens during the 'update client config' step we're ok, otherwise it fails).

Yeah, Sally's right, we want the agent installed on the system prior to imaging, otherwise we have to run Sysprep manually, and we dont' want to do that when we can do it through the Altiris interface.

Sally, how about slowing down those tasks by making the first task after imaging a task that takes a long time to complete, either something like a scripted wait command, or an inventory task or something.

When I Bing'ed (yeah I use Bing) "Windows 7 wait command", I found a script that basically forces a wait by pinging localhost 1,000 times. That might work for you, too.

Also, the way I'm getting around this issue - mind you I'm not in production yet - is that my software all gets installed through Managed Software Delivery policies and not through tasks assigned after the Deploy Image task. Have you looked at that route?

i use ping to put waits in lots of my scripts, but i dont know if it'd work here.  when minisetup finishes and reboots on its own, it will kill the ping job without giving it a chance to exit cleanly, thus throwing an error in the console, halting the entire job chain.  

but it might be worth trying... here - so you don't have to yahoogle it:

ping -n 30 127.0.0.1 >nul

that's approximately 30 seconds wait with no visible output.  

i had forgotten about the agent having to be there so it could sysprep - that was one of the things i hated most about ds 7.1 when compared to 6.9.  made creating my image just that much more of a PITA.  

we had to use tasks to make sure software got installed in a certain order due to prerequisites, and policies can't do that.  Yes, I know that could probably be handled in the packages, but in this case it's quicker and easier to just put them in order 1,2,3,4... and be done with it, since once it's installed as part of a standard build job, you'll probably never have to reload it.

DS6.9 had the option to Continue on error; we have similar functionality, if not better in DS7.1

Thanks for the ideas.

The problem with the ping and forcing the job to complete skipping errors is then if a sw package errors out for some reason the job won't stop and techs may inadvertantly deliver a machine without all the software (their cue a machine is ready is when it's on the domain - its final task).

It's very strange, I just rebooted the server and imaged the same deploy task to 2 machines and it finished fine all the way through.  Reimaged same 2 machines again and they both errored at different points in the post image tasks, one at 3rd task, and the other on the final add to domain task. 

In the console when a package delivery task fails, I know I can drill down to c:\program files\altiris\altiris agent\agents\sw mgmt\software delivery to see individual guids with some info (specifically was the package downloaded)... in my case it seems like the pacakge it errors on was downloaded but I can't find any errors pointing to 'failed to install;?

Are there any other log files I could be looking at to try to point this to a possible network issue?  The log viewer on the server isn't showing any errors.  I just set every post image software install to not run while another task is running in the off chance that helps.

Sally - you should be able to put a task Condition on JUST that specific ping script task, so that if only THAT specific ping task fails, your other jobs will continue. You don't need to force your other tasks to continue upon failure also.

Just a couple of thoughts which might be cleaner.

For your sysprep, I would consider creating my own job which,

1. Copies the sysprep sources to the client.
    
2. Runs on the client as a script into the task scheduler to be executed in the next minute. This task would uninstall the agent, and run sysprep. After this sysprep is executed the client will automatically reboot. 
    
3. Server side pause for 2 minutes (ping). This gives the client enough time to launch the scheduled task (max 1 minute) and uninstall the agent. 
    
4. Uploads client Image

Now the sysprep process is within your own control and no agents/policies/packages are in the image.

Now, in the sysprep file have the cmdlines.txt create a Windows scheduled task which on the next reboot to install the agent and remove itself from task scheduler. When mini-setup completes, this Windows scheduled task is set, and on reboot the agent is installed.

With this setup, there is NO chance that the agent can start firing off during mini-setup. 

I appreciate all the feedback.  I now think I misdiagnosed this problem somewhat.

I was having this issue when I initially was getting my deploy task together (tasks failing because not waiting for minisetup to finish), but adding the task to "update client configuration" fixed the issue.  I think it runs long enough that it allows sysprep to finish without breaking the task sequence.  This worked great for awhile (my base image had all up to date plug ins installed).

Now I have some groups of machines that get PCanywhere client, and some that don't, so I removed PCAnywhere plugin from the base image and created plugin installers that install when computer is found in certain OU.

I think the issue I saw yesterday was this "update client config" task seeing PCanywhere wasn't there and it would install it (machine already existed in console in OU group so I think it recogizned it needed it quickly?).  This causes the whole Symantec agent to blink for a second (in the systray i saw it remove itself from toolbar for 1 second and then come back).  Now I'm thinking it's this blink that was causing the job to die randomly instead of the sysprep reboot as the agent was restarted or something.

I went back to using an earlier revision of the base image that had the PCAnywhere client installed and I see no problems with the same packages (so far).  This is ok as I can use the uninstall agent task on the OU that shouldn't get PCA.

I guess the question remains once my agents on the image are out of date as Symantec releases updates, will the same issue occur?  Also, I'll have to further test the timing of the uninstall of the agent, and if uninstall process breaks deployment task as well, or maybe deleting the client from console before reimaging would solve that timing issue?