Deployment Solution

Here is the scenario - The image is laid down on a computer that already exists in 7.1. The image job includes post image software install tasks. When the image job completes, the computer actually drops out of the job so the software installation tasks never run. I've done a comparison and what is happening is that after sysprep runs and the computer reconnects to NS, the Symantec Management agent (which is installed in the image and Capture Image Prep task is run) is assigned a new guid different from the guid of the machine assigned the image job in the first place. So the image job with post image software install tasks is essentially assigned to a computer which no longer exists in the database because is has a different guid  when the agent checks back in after imaging.

Shouldn't the guid that the computer had in the database be reassigned to that machine after imaging based on serial number or MAC address?

Anyone else seen this?

Thanks for your help.

Billy Wilson.

I'm just running into this same problem as we speak.  I hadn't gotten far enough to determine that it was a GUID issue yet.  I await the replies...

Did you run a "Prepare for image capture" task before you captured the image on the source?

I can confirm that I did.

In reply to Shawn, i did use the Prepare Image for Capture task. This is not an image problem, i dont think. In checking the tasks on my NS, the updateSbsinfo and Update Package Servers tasks are failing. Anyone seen this?

I manually cleared the SBSStore folder but it solved nothing. Again, the computer has one guid when the image job with software install tasks is laid down but receives a new guid when the agent checks in after sysprep. No clue why it happening, but this needs to be fixed so i can actually use DS 7.1 for imaging.

Try creating a  server job with two client jobs inside it

One client job for Imaging and the other one is for post deployment tasks.

For example :

Master "Server Job" to do your installation.  Contains:

"Client Job" part 1 for imaging.  Contains:

Deploy Image 

Reboot to production

send inventory

"Client Job" part 2 for Post deployment tasks.  Contains:

any/all of your SWD jobs/tasks

That didnt work. If I am correct, Jobs and tasks are assigned to guids even though we see them as computers in the console. If the guid is changed before the job is finished, even if part of a Master job, the agent on the computer thinks it has no tasks assigned to it because the tasks are assigned to a guid that no loner exists.

In DS 6.9, when you image a computer and the agent checks back in after sysprep, it gets its original computerid back unless it was never in the database to begin with. This is what is supposed to be happening in 7.1 and it is not, at least not with mine. I've opened a support ticket but so far no luck.

1)  This is a new deploy image task sent to a system that is already a managed computer, right?

2) The image being deployed DID run the "prepare for image capture" task, correct?  (You may want to recapture the image just in case)

3) The system is coming up with an OLD GUID - that is, the guid of the system originally captured?

--OR--

4) the system is coming up with a NEW GUID that has never been seen before in the console?

#3 above would only happen in two scenarios.  1) if the "prepare for image capture" was not run (eg, on an image originally captured in 6.9 and imported) or 2) if the prepare for image capture failed.  The OLD GUID is stripped out during that task, so if it's still present, that's uh - a problem.  Frankly, I've never heard of this before.

#4 above would happen if the system is no longer recognized.  eg) if the original system was identified by name/domain, and the new one has a different name/domain configuration and is thus recognized as "different".  I don't know if/how often this occurs.  Technically, I suppose, it's possible, but it should be recognized by inventory.

Please help clarify the issue - both of you.

So assuming this is failing, that means that PXE updates aren't happening, but this will in no way affect your images.  That is, literally, in NO way.

Now, if you have updated an image, and that image is not being replicated so a system is getting an older version of the image, obviously, that would affect things.

1. Yes this only happens on managed systems that are already in the database.

2. Yes, that task was run before capture.

3. No old GUIDs are coming up. I have been screenshotting and doing comparisons.

4. This seems to be the case. When the system comes back up, it is no longer recognized and given a new GUID. This is where I would like to know what criteria NS uses when an agent checks in for the first time to determine where the computer is already managed or not (therefore requiring a new guid). Interestingly enough, there a a couple of machines that I have been testing that do not have this problem. They are, in fact, getting their old guids back. And they are not the reference computer the image was built on.

Do you know what criteria NS uses to determine managed/unmanaged, Thomas? it is MAC Address, Serial number, or such like DS 6.9 uses?

In Automation,the Agent will use PostEvent.asp to contact the NS, and will send up basic information to the NS.The NS will recognize the computer based on the "hash" the client sends up (which can be seen in the agent logs) and will return the known "guid" for the client.

http://www.symantec.com/docs/HOWTO21727

It would seem the issue doesnt occur in automation, but after the computer boots to production and runs sysprep setup after laying down the image. The error occurs when the production agent on the image first contacts NS. The NS should be giving the GUID-less agent the same GUID it had before the image was laid down (unless the computer was never in the database, of course) but it is, instead, giving it a new guid which is why the tasks assigned for post imaging arent running.

It seems that my issue only relates to trying to run a Run Script task.  The agent never picks up the task.  I thought it was just because it was the first task after deploying the image, but it seems I'm wrong.  Maybe the job logic will explain better:

First Test:

Deploy Image - Success

Run Script - Job fails.  Agent never picks up this task

Reboot Computer

Second Test:

Deploy Image - Success

Reboot Computer - Success

Run Script - Job fails.  Agent never picks up this task

I took a couple of tries, but we were able to get the machines to correctly check-in post imaging. We had to make some changes to the base image anyway (marketing stuff, like wallpaper) so we took the opportunity to run the Prepare Image for Capture task again and re-capture the image. It actually took a couple of runs to get results. I am not sure what happened in WinPE between the Prepare task and the image capture those 1st go-rounds. The reference computer was never booted to production after the image was sealed by the Prepare task but the 1st time we did Prepare for Capture/Capture image job, somehow the agent got a guid assigned to it so out test PCs ended up with the same GUID. We rebuilt the prep-job from scratch and did another Prepare/Capture of the base OS build and it worked.

Even though I am taking the win, I'd still like to know exactly what the Prepare for Image Capture runs on the computer so I could mount the image in case of issues like this and look for things that might have gotten missed. I still theorize that something that did or did not get done by the Prepare task, caused the NS to think the machines checking in after being re-image were new computers, not existing ones in the database as they should be.

Any insight or theories, please post to this thread before they close it.

Thanks for everyone's help.