Prep For Image Capture Task

[Migration User]

When using the prepare for image capture task I understand the SMA GUIDs are stripped, and sysprep is ran against the client.

Is an unattend file used for this sysprep?  Can we force it to use a particular unattend file?

I understand there are ways to avoid using the prepare for image capture task by doing all of your syspreping/SMA prep manually, but I am hoping to avoid this to make a clear and simple process for a tech who is trying to capture and deploy an image.

[Migration User]

short answers.  Yes and Yes.

an unattend file is created from collection or you could provide you own unattended file.

 

Nelo

[Migration User]

Thanks for the response Nelo.  However, this does not answer my question.  Where is the unattended file located at that we can manipulate or replace so that when running this task it uses mine?

I'm really just looking to add a Skip Rearm line to the sysprep process.

[Migration User]

Hi AMilbut,

the unattend.xml file is located in x:\Program Files\Altiris\Notification Server\NSCap\bin\Win32\X86\Deployment\. You can edit it with notepad and browse and point to it in the deploy task.

[Migration User]

What happens if one boot to winpe task a computer, and then capture image. 
Deploy that image, with a sysprep, should do the same thing, right ?

Or is prepare for image capture 100% necessary ?

[Migration User]

Hi Steffen, for your question, different people got different answers. For some people, sysprep is necessary as they want to reduces the risk of hardware compatibility problems. Sysprep uninstalls all PNP device drivers. Also, if you don't want to have duplicate SID on your network, you will have to sysprep your PCs. For other people, they don't need to sysprep as they haven't got any problem without doing it. In my opinion, I choose to sysprep.

[Migration User]

Is the same unattend.xml file used during the capturing process the same unattend.xml file used for deploying?  I know you can change your unattend file upon deployment, and even import your own.  I want to change it upon capturing though, not deploying.

[Migration User]

Steffen,

There's a few reasons to not just sysprep a machine, but use the prepare for image capture task provided by Symantec.

The prepare for image capture tasks does two things...

1:  It runs sysprep on your machine; which as already mentioned is integral for removing the SID for your computer and ensuring you are provided with a new SID.  Duplicate SID's can cause many problems in a network environment.

2:  It strips the GUID from your Symantec Management Agent.  This is extremely important if you are imaging with an agent installed as duplicate GUID's in your database can cause as big as problems as having duplicate SID's in your network environment.

There is a process should you not want to simply use the "Prepare of Image Capture" task and manually sysprep/strip SMA GUID's yourself in a KB article on the forums here.

[Migration User]

Can you use your own Unattend for the "Prepare for image capture" task?  Sure, but the real question is - why?

Let's look at it another way.  The unattend file is NOT used during this phase, not really.  It MIGHT be used for populating a driver list, but ... oh yeah!  We're going to replace it anyway!  What then IS this unattend file for?  It's an answer file for MiniSetup.  During image capture, we don't RUN MiniSetup.

MiniSetup happens (well, except on the capture system) AFTER image DEPLOY.  THAT is where the unattend file matters.

How you run Sysprep DOES matter on image capture - I'll frankly admit that.  We do things in a simple / generic way and we don't bother with the "perfect" replication of the administrator profile, etc.  Fine - if you want to get everything perfect, it's no big.  Run Sysprep manually, do all your installs while your in audit mode, etc.  Fine with me.

But the Unattend file isn't really used during image capture anyway, so why do we even care which one is used during image capture?  We use an unattend that is generic and gets the system into a pre-OS-ready state.  It does the job.  Is it in the image?  Yup.  But as soon as you run a deploy image task, we rip it out and replace it with one that is designed for your system.  OR one that you give us.  So what's IN the image doesn't matter (well, again, except for the system from which you captured the image, for it reboots after image capture and is the ONLY computer that will use this initial unattend file).

 

Does that make sense?

[Migration User]

It does make sense Thomas.

My reason for asking is because we use one master laptop per image for capturing.

Using the prepare for image capture task because sysprep is ran with the generic answer file will eat my rearm counts on this image.

So end goal I simply want to add a <SkipRearm> to my sysprep process during the prepare for image capture task to avoid this problem.

I know there are ways around it, like creating a back up of this image prior to every capture, and then restoring to this back up after the capture process, but that's simply another step that can be avoided with one line change.

Does that make sense?

So as you stated, you can use your own using this prepared task...where is the file that the task points to?

[Migration User]

Hi AMilbut, the unattend.xml file is not used during capture. It is only used after deploy. The file is an answer file which is used for minisetup.

[Migration User]

That makes sense, Thomas.

[Migration User]

I THINK it's the Unattend in this folder:

C:\Program Files\Altiris\Notification Server\NSCap\bin\Win32\X86\Deployment

 

That said, I'd have to test to be sure.  I'm assuming you tried that, or not?

[Migration User]

I know it would take a little bit of work to get back to where your image is, but have you thought of building it in VM environment?

When I am done updating my source image, I take a snapshot, do some final cleanup and then start the image capture. 

This is beneficial for a couple of reasons:

I dont have to worry about hardware failures since I am doing this in vcenter.

I dont have to worry about the re-arm issue.

If a problem is discovered during testing of an image, I can easily go back and fix whatever issues were discovered.

If needed, a flat vmdk can easily be converted to a gho with proper switches.

[Migration User]

1 million percent agree with you Burndt.  Unfortunately, VM is not an option.  I so wish it was.  Would make my life 1000x easier.

[Migration User]

Tested this morning to be 100% certain.  This seemed to work, and adding the line in manually to the unattend you referenced above inserted it into the unattend generated using the "Prepare for capture" task.

Thanks Tom.