Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Windows XP/7 Imaging best practices

Created: 08 Feb 2010 • Updated: 29 Sep 2010 | 46 comments

I have inherited a Deployment Server 6.9 environment that is used for imaging client machines in an active directory domain environment.  Currently all machines are running Windows XP and the current practice is the following:  Create image by installing WinXP, joining domain, installing applications commonly used in our base images, installing AClient, and creating a 'Capture Image job' in DS using Rdeploy.  They still use Sidgen for SID replacement.  For the most part it seems to work ok.  I'm wondering a few things: 1) Should we be using Sysprep?  2) Is there an issue capturing the image while the computer is part of the domain?  I read somewhere that I'm supposed to take the machine out of the domain before capturing the image?  I've never done this before and never had an issue I'm aware of.  Can somebody please share a best practices approach fro creating a simple image like this and ultimately deploying the image in a domain environment?

At the same time, how does any of this fit into Windows 7?  I have been somewhat successful in imaging a Windows 7 machine that was NOT in a domain, though I had to run a BCDEDIT script in a WinPE environment and did not use Sysprep.  I have never really used sysprep so any details on that would be great. 

Basically whether it's WinXP or Win7, what I'm looking for is help in creating an image for a Windows domain computer that will have specific applications on it, i.e. adobe reader, MS Office, Quicktime, etc., and will have a unique SID.  Any information out there would be greatly appreciated!  Thank you!

Comments 46 CommentsJump to latest comment

ablumhardt's picture

The biggest reason so far that i have used sysprep in my environment is to strip the computer of its SID.  To my knowledge sidgen has been phased out for vista and beyond.  The problem I ran into when i didn't use sysprep is that my KMS server couldn't distinguish between different computers and i'm afraid that would cause licensing issues down the road. 

As far as XP i have never used sidgen or sysprep.  I just create our images and gather them.  Granted we do not take advantage of sysprep for HII on either windows 7 or XP, we build a separate image for each model.

All of the images I pull are part of a domain, and I haven't seen any issues with that at all.

Also as a side note if you get SOI (scripted OS install) working its an amazing tool for getting your images built in a timely matter.  A windows 7 base install takes about 15 minutes from blank HD to joined to the domain ready to be built.

spazzzen's picture

I have been using sysprep for both Windows XP and 7.  I believe Microsoft wants you to build everything from scratch instead of using images, which isn't very efficant.  If you add the computer to the domain you will definitly need to either sysprep it or i am guessing Sidgen does part of the same thing.  I do not add my base image to the domain, just map a drive for all the installs.  I also only install applications that will never change, and push the other applications after the image is pushed down.  This leaves the image smaller and if you end up updating an application you don't have to re-create the image. 
It is fairly easy to create the XP unattend file to make it automatically get into windows, and Windows 7 has the WAIK to help with creating the unattend.xml file as long as you know where to put it (c:\Windows\panther\unattend\unattend.xml) if you choose to use sysprep.  I think (don't quote me) that it is better to use a configuration task to add the computer to the domain instead of the unattend.xml).  I do this as soon as the image is done and the computer boots into windows.  Once it is on the domain I have a bunch of jobs to install the default software such as Adobe, Office, ... ect.  This is completely automated so when all the jobs are complete, it is almost completely ready for the user, and has unique SIDs for all the software (Symantec Antivirus uses SIDs as well and should not be in a base image).  Making auto installs for your software is usually fairly easy.  Adobe has a customization wizard and Office 2007 you can use use the -admin on the set up.  Also, Wise Studio helps out a lot in making things automated for different OS bits and versions.

stein_brian's picture

Thank you both for the great information.  So if I can let me please ask some followup questions.  Don't ask why but the way we do our images is a bit strange and I'm wondering how sysprep might affect this.  What we do is we create a base image which is basically the OS, all latest MS updates/service packs, and base software like adobe reader, MS Office, Java, etc.  We do all this using a local administrator account so we can run the apps once and accept all EULA's and any other customization we need because our users are NOT given admin rights to the machines.  Once we're ready, we copy this profile of this local admin account to a folder on  the root of the C drive and everyone's account in Active Directory has this path for their profile location, thus C:\<Folder Name>.  We also use a product called Scriptlogic which further loclks the machines down and maps their drives and printers, etc and also redirects folders to their roaming profiles on the server.  That being said, assuming I figure sysprep out and get it to work properly, will this 'local' profile stored on the root of the C drive still be useable or does sysprep wipe out all settings?  What I need to make sure is that users aren't always prompted with EULA prompts and first time program startup screens.  Hope this makes sense to someone.  Thoughts greatly appreciated, thank you! 

ablumhardt's picture

 I got what your saying, As far as adobe reader, and Microsoft office go, they both offer great administrative installs that allow you too suppress both EULA as well as making admin configurations.

For Adobe Reader you need to download the Adobe 9 install, (if you have a lot of computers you should apply for a distribution license which is free of course you can find that info here www.adobe.com/products/reader/rdr_distribution1.html they offer licenses for flash, reader and shockwave) Once you have it downloaded follow the  instructions located here kb2.adobe.com/cps/404/kb404146.html to learn how to extract the msi for adobe 9.  Than you need to download the software to configure it which is located here www.adobe.com/support/downloads/detail.jsp.  Once you create an mst file you can create a simple bat file to install and customize adobe reader for your needs.

For Microsoft Office 2007, just run the setup.exe file in a command promt or run command with the /admin switch.  This will allow you to create and save a customization file for office.

Hope this helps somewhat

stein_brian's picture

Thank you, yes this helps a lot! 

So then are you saying that I cannot have those types of applications already installed on the image?  That I have to deploy them separately after deploying the image?  Shouldn't be a problem but I just want to make sure I'm understanding correctly?  So can I have any applications on the image, or should it just be the OS and nothing else?

bhawver's picture

Ultimately, you can have them in the image, however, every time you decide to upgrade or change an individual application, you have to redo your image.  Best practices would be to have just the OS with all of the patches and hot fixes and then kick off software packages after the image separately.  For example, you have Office 2007 in the image, what happens when you want to deploy Office 2010?  You now have to redo your image, and it isn't recommended to deploy the image, uninstall the software and then install the new software.  I have yet to ever see a clean uninstall by any software company.  Ultimately, it could be an administrative nightmare to deal with multiple images with multiple sets of software.

Brian Hawver
Systems Engineer
Yaskawa America, Inc.

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

ablumhardt's picture

It's really up to you in the end, obviously there are some programs that should be on the image, but bhawver makes a point depending on your environment you may want to do things that way. Personally we build our images once a year and do all major upgrades at that point. (This is a school district perspective.) I personally don't like the idea of running several jobs after a reimage because it allows for user interference and any other hiccups that may occur

ianatkin's picture

Lots of good info already stated here, and I know  I'm getting through this late, but just to add another two pennies.

We have an image factory of sorts and for efficiency we split the customers software into two categories; business-critical and optional. The business-critical applications are required by everyone, and the optional packages will have some variation in their distribution.

All software packages are in their own jobs, and thus we can mix and match for the image preparation process. When we build a fresh image we have a completely automated process for each unit which,

  • Scripts the OS installation
  • Patches
  • Installs all business-critical software
  • Syspreps and uploads image to central store for verification

When images are deployed to the client, additional jobs can be added to ensure the latest Adobe patches are installed for example. Deployment variations can be taken into account by selecting the "Accounts" image which for example would be the "business-critical" image with the accounts software added as a post deployment job.

Currently Office 2003 is our standard business-critical Office application and so is included in our base image. Office 2007 is currently an option, and so this install has been created to allow the dual existence of Office 2003 and Office 2007.  Installing Office after laying down the image incidently would increase your overall perceived imaging time dramatically.


Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which assist you most in resolving your problem, and give a thumbs up to useful articles and downloads

stein_brian's picture

Once again I just want to thank everyone for their input here, I can't begin to express how helpful it's been!  So just to add a thought here of which way I'm leaning.  Like 'ablumhardt' I also am coming from a school district perspective, and similarly we redo our main images once, maybe twice a year.  So basically once we have our image we deploy that image to the machines once and only do it again if a machine crashes some time during the school year, etc.  So with that approach, it sounds like I can then put the base software in the image and go from there.  Please advise if you disagree.

Lastly, will my so called 'locally stored default profile' survive the sysprep process and if the image is created from a machine already joined to the domain, will sysprep take of assigning a unique domain SID to the computers I deploy the image to?  Thank you!

ablumhardt's picture

1.  Which programs are you finding it necessary to have this default profile present for?

2.  We have been deploying our images with all software for years, and even with our windows 7 deployments, which started back in october all software has been included on the image.

3.  When I pull my images they are always joined to the domain, and i haven't had anything go wrong with the computers showing up to the KMS server or WUS.

ianatkin's picture

Hi,

SIDs won't be a problem for sysprepping computers already domain joined but I'd still try as hard as hell to avoid this. The reason is the domain policies are often outside your control, and therefore add an unwelcome degree of irreproducibility in your image creation process.

So, I tend to create my images on a virtual machine which is not domain joined, deploy all the apps/patches required for that build and then sysprep and upload. This means you always know the state of your virgin build, and it won't have been contaminated by software/policies delivered by the domain.

Kind Regards,
Ian./ 

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which assist you most in resolving your problem, and give a thumbs up to useful articles and downloads

stein_brian's picture

Sysprep question.

So I think with all your help I'm ready to take a crack at this but just one last thing I'm looking for clarification on.  In a way I'm directly asking ablumhardt since he shares my school district perspective, but really it's for anyone to answer.  When I use sysprep, do I run it on the computer I create the image from or do I do within Altiris DS when deploying the image?

What I mean is, when I am all done setting up my computer that I am creating the image on, is the last thing I do is run sysprep with the Generalize and the OOBE options and then shut it down?  Then when I create the image, do I also use the sysprep options when setting up the 'create job?'

What about once I have the image and I want to deploy it to machine(s), do I choose the Sysprep Settings option in the deploy job and specify the answer file?  I guess I'm just confused if I need to run it on the original computer and then on the Altiris create and deploy jobs as well?  This will be mostly used for Windows 7 machines, but possible XP as well so I don't know if the overall steps are similar.  Thank you!

ablumhardt's picture

Yes, make sure you have sysprep selected on the create a job.  In my experience i never ran the sysprep commands by hand.  I just selected the sysprep option in the create and it runs the sysprep options for you.  The more important part is when you restore a new computer you need to make sure you have a good answer file.  you can use the default one to make sure you are on track and then create your own later, if necessary.  I have never done any syspreping on xp unfortuently i wish i would have learned the methods earlier.

stein_brian's picture

Thanks everyone!  I will hopefully begin testing all this next week and will definitely report back on my success or any issues I run into.  I really appreciate everyone's assistance!

stein_brian's picture

So I have come across some pretty stupid questions I have in attacking this which I'm fairly confident you guys will be able to answer rather quickly, keeping in mind this is for the most part geared towards Windows 7:

1) So how do I go about creating the answer file and once created, where do I put it?

2) What is the process for getting all my drivers into the deployment process?  Doesn't sysprep rip all the drivers out and they need to be 'injected' back in?  Is this part of the answer file and where do the drivers actually reside?

3) Do I have to actually install Sysprep version for Windows 7 onto my DS server?  I swear I remember when they had a consultant come in to setup out 6.9 environment he extracted the XP sysprep cab file for something.

Thanks all!

ablumhardt's picture

 1.  Depends if you are doing a scripted install or just a regular image.  If its scripted install you can piece one together from downloading the WAIK for windows 7 package.  Or if you search the internet you will be able to find some good ideas of what an answer sheet will look like.  If it is just a regular image (not a build) you can either just use the default sysprep or create your own to fit whatever needs you have again searching the internet for examples will yield the fastest results.  As for where to put it, I believe i needs to be anywhere that A. win PE can find it, and has rights too it.  The express share is a pretty good location.  Although you may want to make sure its locked down, as the answer sheet will likely have passwords and such.

2.  I have just put the drivers on my images, and they have all made the trip safely no extra steps necessary.  However, I do not partake in HII, i'm not that adventurous. 

3.  And finally no, all of the sysprep action is taking place on the windows 7computer itself, there are no necessary installs on the server.

tamahome's picture

 
You don't have to do the bcdedit stuff if you use sysprep (windows 7 enterprise/use existing key).  But you might not like what else it does.

tamahome's picture

 
For example, it disabled the administrator account, reset the preferences of the user account, and prompted for which network to go on.  I think I've read complaints about it elsewhere.

JohnyN's picture

You have to create a sysprep answer file if you want the admin account enabled, as well as being able to do any sort of default profile settings.

ablumhardt's picture

That makes more sense now, I was confused about "tamahome's post. I have a created sysprep sheet that creates a new administrator account.  And I have noticed the prompting for whether you want your network connection to be home/work/public.  I already have it set to "work" in the sheet.  But it still asks the first person to log in, however, when you selected any of them it says it can't be configured anyway.  

stein_brian's picture

So I finally got back to working on this and though I'm close, am running into a few issues.  Here is what I did......  Using Windows 7 Professional x86, installed the OS, updates and all my base software that we use on our school environment images, and join it to our domain.  I do this using a local account I create on the machine that is part of the Administrators group.  Once all my profile specific settings are set I log out, log back in as local admin, and copy the profile I created to the root of the C drive (as mentioned way above, this is how they do it here).   I login one last time as a domain user to make sure everything looks good.

Then I capture the image using DS.  Once complete, I then deployed this image to another machine (same model) and selected the sysprep options in my job, chose the right OS and the license key, and selected my answer file.  It seems to go fine as it deploys the image, and then I see it reboot quite a few times, and once ready the machine has it's correct computer name and is in fact back on the domain.  However upon loggin I notice 3 specific things:

1) Windows is not activated and is prompting for activation, why?
2) Even though I put a Setupcomplete.cmd file into the image which contains a command to delete the answer file on the local machine, it never runs and in fact the .cmd file is not even showing up on the computer, even though it's in the image.  It's almost like it's been purged during sysprep or something
3) Though the profile for the most part seems intact, some of the desktop icons have been moved and reset

Any thoughts would be greatly appreciated, thank you!

JohnyN's picture

It took a lot of trial and error, but for me, I narrowed down the disappearance and lack of execution on SetupComplete.cmd's part to DAgent.  If DAgent is installed in the image, SetupComplete.cmd disappears and does not delete my answer file, if I don't have DAgent installed then SetupComplete.cmd runs happily.  

So my solution was to not have DAgent installed in the image, and instead to have a WinPE script copy the the DAgent.msi file to the local computer after imaging.  From there have a line in SetupComplete.cmd to install DAgent.msi silently.

stein_brian's picture

Very interesting, I will try an image without Dagent then. 

As for my other issues mentioned, I found that if I run sysprep on the machine as thekast step prior to creating the image, instead of selecting the sysprep settings in the Altiris job, that it will activate windows for me based cscript commands entered in my answer file.  However, when I do it this way I now am prompted to create a user during the sysprep part and it does not retain my original computer.  Any help with that?

JohnyN's picture

Did you use Windows System Image Manager to create your sysprep file?  I manually run sysprep before creating the image instead of letting Altiris, just so I feel like I have more control over it.

Anyways, I think the settings in sysprep you need is "SkipUserOOBE".
This is what mine looks like for that section:

        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <OOBE>
                <HideEULAPage>true</HideEULAPage>
                <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
                <NetworkLocation>Work</NetworkLocation>
                <ProtectYourPC>1</ProtectYourPC>
                <SkipMachineOOBE>true</SkipMachineOOBE>
                <SkipUserOOBE>true</SkipUserOOBE>
            </OOBE>
stein_brian's picture

Actually my apologies, please disregard my last post as it did NOT activate Windows when I deployed it to a new machine.  So I still need some assistance with that as well.  I know the cscript commands work because if I run them both manually from a command prompt it does successfully activate Windows.  So what am I doing wrong that I can't get it to run when included in the answer file?  Thanks!

stein_brian's picture

Thanks JohnyN, your tip about adding the 'skipuseroobe' section worked perfectly, and in fact my auto activation is now working too.  But of course with progress comes more challenges.  Maybe this can't be done and that will be my answer but here is what I am struggling with now:

Previously with our WIndows XP stuff using Sidgen, we can just deploy an image to any of our current machines and it will in the end gets it's original computer name back, I believe Aclient does this.  We get no errors even though the comouter is already in Active Directory.

What I noticed on my Windows 7 sysprep testing is i get an error in Altiris that says 'Account already exists.'  I'm assuming this means in Active Directory?  Does this mean I just need to make sure i delete the computer account in AD before the sysprep portion of the imaging starts?  Or is it something completely different?

JohnyN's picture

In your sysprep file, are you specifying a computer name or did you leave it blank?

stein_brian's picture

I left it blank.  It seems this only happens if I run sysprep on the machine.  If I don't and i use sysprep thru the Altiris deploy job then it doesn't happen, and it ultimately retains it's original name, however in Active DIrectory it shows a new name even though the computer shows it's original name.  Does that make any sense?  I'm so lost now

JohnyN's picture

In my actual sysprep file, originally I didn't even have <ComputerName> at all and that worked fine for me.  Altiris named the computer based on the name it had in the console for me.  But now I have <ComputerName>%NAME%</ComputerName> and after imaging I use ReplaceTokens.  I was trying to cut down on how many reboots the computer does after imaging but I'm not sure if it has made any difference.  
If you have <ComptuerName></ComputerName> in your sysprep file, try removing it completely.  Or, if you can, look through c:\windows\panther\unattend.xml in the image you created with Altiris sysprepping and compare that to the same file in the image you sysprepped yourself.

stein_brian's picture

Well I guess what I'm struggling with now is the fact that it does seem to put back the original name which is what I want yet Active DIrectory now shows it with like the Windows generated computer name, i.e. 'Win-xxxxxxxxxxxxx'  .  Yet if I go into the computer object of the computer account in AD it shows the DNS name as the appropriate name.  I don't understand.  It's like it's registering to the domain before Altiris is changing the name back or something.  I'm sure that's not really what's going on but I'm just guessing

JohnyN's picture

Oh right, so you're having the unattend join the computer to the domain?  I don't do this personally so I can't speak to it, but I've come across other comments saying that the behavior is that it joins the computer to the domain before the name change happens, so it joins with the "WIN-randomnumbers" computer name, then it changes the computer name.

stein_brian's picture

Being that the computers I am deploying my image to are already on the domain, do you think I should maybe take the join statements out of my xml file, that maybe it doesn't need that there since it's already on the domain?  Or would it still need to be in there?

JohnyN's picture

The computers I'm imaging are also already on the domain so I let Altiris handle domain joining for me and it's been working like a dream.

stein_brian's picture

So that means you don't have any reference to joining the domain in the answer file then?  I just want to confirm

JohnyN's picture

That is correct, no reference to domain joining in the answer file.

stein_brian's picture

OK thanks, then i will try it next with taking that section out of my answer file.  Perhaps it's conflicting with the answer file trying to rejoin it to the domain and then altiris doing the same thing.  Forgive me if this is out of line but you wouldn't happen to have a sample answer file I could look at would you?  Excluding any sensitive information of course.  Thanks!

Mr Gadget's picture

JohnyN,
it sounds like you might have things down pat with imaging Windows 7.  You said you Sysprep the computer to make a image yourself and don't use Altiris.  I am just getting started in Windows 7 imaging and I've found Altiris somehow makes its own answer file on the fly and after I make a image of a computer using the Deployment console, my master computer gets messed up like Admin account disabled and some other things.(If it works at all)

My problem has been Dagent is so flaky if I push a image down, I see on the screen of the imaged computer Dagent couldn't't communicate then imaging fails. This is hit and miss.
Trying to Make a image, one time it works and the next it doesn't. Always when it fails the master just hangs in " restarting the computer to prepare image" (or something like that). The master will boot back to windows but the admin account is disabled, etc and dagent icon is not there. The computer does not show in the console as blue (just gray). It takes several trys of uninstalling dagent and reinstalling to get it to come up in system tray and be blue in console.

Are you using dagent ? I tryed to image a computer out of the box, no name ,no agent, never been set up. It pxe boots to winpe, takes a long time but finally shows as new computer in console. I drag a restore image job to it and it  flakes out in winpe boot where dagent on winpe can't communicate and hangs everytime. I am not running a firewall on my deployment server and I tryed uninstalling virus protection in case that was causing the problem.
Are you having these problems?

stein_brian's picture

Hoping somebody sees this.  So I finally got my answer file to work correctly, or at least complete sysprep without throwing an error.  This new answer file no longer contains any sections about joining the domain as I want to just let Altiris automatically put the machine back in the domain as mentioned above.  And here is where I'm now stuck.  So i create my image of Windows 7 by joining the machine to the domain, throw on Dagent, then I run the following command from a command prompt - sysprep /generalize /oobe /shutdown /unattend:unattend.xml.

Everything goes smoothly, and when the machine shuts down I create my 'create image' job and upload the image using rdeploy.  I do NOT select sysprep since i ran locally on the machine and I do NOT select the box to boot to prodution prior to creating the image.  Machine boots into WinPE and captures the image successfully.  Once done the machine then reboots and automatically runs sysprep as expected, however once it completes my machine is no longer on the domain and it has a new computer name, 'Win-XXXXXXX.'  Does anybody know why Altiris (DAgent I assume) is not doing the post configuration and changing the name back to the original name and putting it back on the domain?  Does that only happen when I actually deploy that image to a computer, or does this tell me that I'm going to have the same issue when I try and deploy this image?

Also, the reason I am running sysprep manually instead of letting Altiris do it is because whenever I let Altiris do it, it totally changes my answer file and takes things out and adds some of it's own stuff in.  Has anybody else experienced this or at least knows what I'm doing wrong?  I'm so close if I can just past these remaining issues.   Any help as alwasy is appreciated, thank you!

Mr Gadget's picture

Stein_Brian,

I have the same issue except I don't run sysprep on the master manually. I choose Use Sysprep in the Create image job, and I get the same results as you. I thought it was because I choose those settings and did not do sysprep manually but you proved it is not the case so something is causing this and i would like to know what also.

JohnyN's picture

I suggest removing the computer from the domain manually before you sysprep, as sysprep will remove the computer from the domain as part of it's process anyways.  I also ran into weird behavior if I leave the computer on the domain prior to sysprepping, such as the local administrator account not becoming enabled.

Mr Gadget's picture

I read the User Guide for Client Management  7 and it stated this would happen. They gave the steps as Image the Master without Sysprep, then image with sysprep. After it images using sysprep it will have changes made to it. Take the first image and reimage master with it and use that image only for your master to get it back to its previous settings.

I have a question for JohnyN
You had in your answer file:      <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

            <OOBE>
                <HideEULAPage>true</HideEULAPage>
                <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
                <NetworkLocation>Work</NetworkLocation>
                <ProtectYourPC>1</ProtectYourPC>
                <SkipMachineOOBE>true</SkipMachineOOBE>
                <SkipUserOOBE>true</SkipUserOOBE>
            </OOBE>

What does the ShipmachineOOBE>true do and SkipMachineOOBE>true do?

JohnyN's picture

SkipMachineOOBE

http://technet.microsoft.com/en-us/library/cc765947(WS.10).aspx

With it enabled it skips the Windows Welcome screen and ignores ProtectYourPC and NetworkLocation.  I can set the Windows Automatic Update settings through registry keys so that's not important, and NetworkLocation really isn't either.  

The main reason I have it on right now is so I can skip having to put my Product Key in the sysprep file, or even typing it in anywhere at all.

The Technet article explains it pretty well.

Mr Gadget's picture

Thats great if it works for you.
I do not use it in my answer file and my answer file actually boots the computer after its imaged into the administrator account. After the next reboot it doesn't ask anything when a user logs on then either. I do not put a product key in my answer file or anywhere else it keeps it from the master I made the image from, of course it won't  activate because of license duplication, we are trying to get a volume license.
I'm struggling now with computer name. We use a specific name for each of our computers. When I Distribute my image to multiple computers each will get a random name, this I think is because I use a * in the computername portion of the answer file. Then you have to go back and touch each one again to name it.
 In lies my problem is using one image and having each computer that the image is sent to have a specific name that I want, without making a seperate answer file for each.
You mentioned using tokens after imaging to name yours. How do you do that?

stein_brian's picture

So I think I finally got this to work.  I just tested with a very basic image, literally just the Windows 7 OS with a few tweaks, like UAC off, firewall off, installed DAgent, etc.  I didn't load up any apps or anything because I wanted to keep the image as small as possible until I got it to work.  Basically I created a new answer file using WAIK, and this time I left off any references to adding the machine to the domain and also included things like enabling the administrator account, and activating Windows.  I did however keep the master computer on the domain.

Once ready I manually ran sysprep on the master computer and pointed it to my new answer file and once it shut down I captured that image.  Once the capture was done and the master computer rebooted it ran through sysprep and at first I thought I was in trouble because once done, the master was not put back on the domain nor did it retain it's original computer name.

I tried deploying this image anyway to an existing computer on my network that was actually running Windows XP and to my surprise it worked.  Once this computer finished imaging, it ran thru sysprep, and at the end the computer was still on the domain and had it's original computer name, as well as had the local admin account enabled and Windows was activated.  I then deployed this same image to another computer that already had Windows 7 on it and it worked on that one as well.  Now my next test is to actually build out my real image with a default profile and everything and see if I can still make this work.

I'm guessing the reason the master computer did not stay on the domain or retain it's computer name is because there is no Altiris configuration options for 'create' jobs, they only seem to exist for 'deploy' jobs.  Not sure, but I'm hoping that's the case.  Will follow up after my next test.  Hope this helps

stein_brian's picture

Don't know if this helps but as long as i have Aclient or Dagent loaded on the machine I'm deploying my sysprep image to, it ultimately retains it's original computer name.  To get this to work I took JohnyN's advice and removed the entire ComputerName field from my answer file.  I also had to make sure that the deploy job is configured to run the configuration task a well.  I still haven't had a chance to run my big final test with my real image and default profile but hopefully will get to it tomorrow.