Sign in
 
HomeLibraryWikiLearnGalleryDownloadsSupportForumsBlogs
Resources for IT Professionals >
> 
> 
> 
MDT Deployment procedures? Process to deploy custom image?

问题 MDT Deployment procedures? Process to deploy custom image?

  • Tuesday, April 24, 2012 3:36 PM
     
     
    Sign In to Vote
    0

    I've searched everywhere to answer this... and found nothing.

    I am attempting to deploy a custom image with MDT.

    That's it.

    I've never found a procedure that works.  If anyone knows how to make this work, I would appreciate the assistance.

    I've tried creating a custom unattend file, capturing it with ImageX and deploying it, I always get the error "Windows could not parse or process the unattend answer file for pass [specialize]. A component or non-list setting is specified more than once in the answer file."... Even when the [specialize] section is completely empty. It is obviously a fault with MDT.

    I've tried creating a "Sysprep and Capture" task sequence and use that, but then I either get "Out of disk space" (80 gigs free?) or "Empty URL".

    If anyone knows where I can find a WORKING STEP-BY-STEP procedure for creating, capturing, and deploying a custom image with MDT, please let me know.

     

All Replies

  • Tuesday, April 24, 2012 4:36 PM
     
     
    Sign In to Vote
    0

    "I've tried creating a custom unattend file, capturing it with ImageX and deploying it"

    That's not how you use MDT.

    http://www.deployvista.com/Blog/JohanArwidmark/tabid/78/EntryID/161/language/en-US/Default.aspx

    http://www.amazon.com/Deployment-Fundamentals-Vol-Migrating-Windows/dp/1451570031


    • Edited by JoeZeppy Tuesday, April 24, 2012 4:38 PM
    •  
     
  • Tuesday, April 24, 2012 10:07 PM
     
     
    Sign In to Vote
    0

    Hiya Gary,

    Are you building your custom image with MDT?  If so, are you using a Lite Touch installation?

    I might be able to help out if this is the case.

    Jared

     
  • Wednesday, April 25, 2012 12:06 PM
     
     
    Sign In to Vote
    0

    I've tried it both ways.  I deploy bare Windows 7 using MDT. I select the method "Prepare for capture". That part works just fine.  I then customize the installation, install Adobe, Office, Java... etc.  I then captured an unprepped imagex image of it. (Because I just knew I'd have problems)

    It's the next steps that I can't figure out.

    I've tried doing it by hand, sysprepping it using a custom Unattend.xml (that has been validated by SIM), capturing it with imagex and upload the image into MDT... that didn't work. It gives me the duplicate specialize pass entry error every time, even when the entire specialize pass section is empty.

    I've created a task sequence in MDT, "Sysprep and Capture". I read in a MS blog that I should then execute "cscript \\DeploymentSvr\$DeploymentShare\Scripts\LiteTouch.wsf".  That one has given me both "Out of disk space" (When I have 60-70 gigs free on the PC and four times that free on the server) and another error something about an empty URL.

    I'm willing to rebuild my image again, whatever it takes to get this thing working.  It shouldn't be this difficult.  I've never had this many errors trying to deploy an OS.  Even RIS was easier than this.

    I'll definately look through that first link... looks like a lot of good info there.  Although I'm not about to purchase your book until I learn if the process actually works first :)

     
  • Wednesday, April 25, 2012 12:13 PM
     
     
    Sign In to Vote
    0

    I use MDT to install the bare OS, I then customize it.  My intention is to use MDT's Lite Touch to deploy the custom image but I can't figure out the procedure to sysprep, capture, and get it back into MDT for deployment.  All documentation is extremely vague on that.

    My LiteTouch settings are working fine, I can use the LiteTouch task sequence I've set up to deploy the bare OS to a PC just fine... but getting it to deploy my customized image is proving extremely difficult.

     
  • Wednesday, April 25, 2012 12:56 PM
     
     
    Sign In to Vote
    0

    It seems like some customsettings.ini settings can interfere with the sysprep and capture process.  I actually ended up setting up a deployment share that I use exclusively for building and capturing reference images.  

    I found Mitch Tulloch's step by step tutorial to be very helpful when I was first learning MDT LiteTouch

    http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part10.html

    I will also vouch for the Deployment Fundamentals book, I found it to be very usefull as well.

     
  • Wednesday, April 25, 2012 1:03 PM
     
     
    Sign In to Vote
    0

    Well, my customsettings.ini has been configured for the LiteTouch deployment scenario... I know in that regard it works perfectly... but since those setting apply to ALL task sequences, it makes sense that it could interfere with the Sysprep and Capture task sequence... since it wasn't designed for that task sequence.

    I'll try resetting it back to the defaults and try the sysprep and capture task sequence again.

    It just seems a bad design to have to change it to sysprep and change it again to deploy...

     
  • Wednesday, April 25, 2012 1:12 PM
     
     
    Sign In to Vote
    0
    Yes, I thought that to be odd as well...  It was Mitch Tulloch's tutorial that pointed me in that direction since he alters the ini before doing a capture.  In the end, that is why I found it easier to keep another deployment share for making reference images.
     
  • Wednesday, April 25, 2012 1:19 PM
     
     
    Sign In to Vote
    0

    That is a very interesting idea... use one for the public LiteTouch deployment sequences and one for just creating the reference image.  I'll defintely look into that in the future.

    I just read that blog you linked, he basically says that in part 11, reset the customsettings back to defaults.

    I'm re-applying my unprepped image and will try the capture again once I've reset those files.

     
  • Wednesday, April 25, 2012 1:30 PM
     
     
    Sign In to Vote
    0
    Maintaining another share doesn't not take much overhead.  It can also make a lot of sense if you have lots of techs deploying machines, but another smaller set of techs (in my case just me) building and maintaining the images. 
     
  • Wednesday, April 25, 2012 5:16 PM
     
     
    Sign In to Vote
    0

    It failed again, with the same error I got when I captured the image myself with imagex and imported it...

    "Windows could not parse or process the unattend answer file for pass [specialize]. A component or non-list setting is specified more than once in the answer file."

    Well, thanks for trying. I'll keep researching.  Hopefully I'll stumble across the answer someday...

     
  • Wednesday, April 25, 2012 7:24 PM
     
     
    Sign In to Vote
    0

    Ok, I figured it out.

    Apparently, the unattend.xml file that gets used when you install the original OS gets somehow merged with the unattend.xml file that gets used when you deploy the custom image.  Any settings in one cannot exist in the other or else that error appears... even though they're different files used at different times.

    It seems MDT still needs some work... but at least we can progress now...


     
  • Thursday, April 26, 2012 1:31 PM
     
     
    Sign In to Vote
    0
    I'd just like to say that I've been using MDT extensively to build and deploy custom images for almost two years, and I've *never* edited an unattend.xml file manually or through WSIM to solve a problem. Not to say it should never be done, but I think it's quite rare. The whole point of the tool is to make these changes for you dynamically.
     
  • Thursday, April 26, 2012 1:49 PM
     
     
    Sign In to Vote
    0

    Well, that's kinda the thing isn't it? It isn't making dynamic changes to the XML files.

    Granted, the fault was mine in that I made valid changes to the OS unattend.xml, the sysprep unattend.xml, and the deployment unattend.xml files. Individually, each customization was completely valid and authenticated by SIM. It's the fault of MDT not handling it properly. I figured once the OS install unattend.xml was processed, it would never be run again... the sysprep unattend would only be run during sysprep, and so on... apparently that's not the case. All previous files are merged at each run.  OS install runs unattend1.xml, sysprep runs unattend1.xml and unattend2.xml, and the deployment runs unattend1 & unattend2 & unattend3.xml... if anything is common, it fails.

    Granted, if you never make any customizations, you'll never have a problem... but what's the point of using the tool if you never configure it for your company?

     
  • Thursday, April 26, 2012 2:58 PM
     
     
    Sign In to Vote
    0

    I customize the crap out of my installs. I just don't touch the unattend.xml files. I use the task sequencer to run Powershell, vbScript and command line tools, I use the customsettings.ini and bootstrap.ini files, the deployment database and command line arguments while running the LiteTouch.vbs. I suppose if you wanted to remove base components from the OS there might be a reason to monkey around in there.

    What is it that you are modifying? I'm not being a jerk, I'm just curious, I truly have never had a need to open the Win 7 unattend.XML file to solve a production problem.

     
  • Thursday, April 26, 2012 3:04 PM
     
     
    Sign In to Vote
    0

    To add to that, I am finding that a best practice is to minimize customizations of the reference image and do the customizations when it is deployed.  This allows for better flexibility to make small changes without needed to rebuild your image.  This is where MDT really shines in my book.

      Like JoeZeppy, I too am curious about what you are doing.  Perhaps we can all learn something new...

     
  • Thursday, April 26, 2012 5:16 PM
     
     
    Sign In to Vote
    0

    Thin image or thick image is a matter of much debate :'). It depends on how quick you want to deploy an image, and often you want to refresh your base image. We want to put one out quarterly, so it doesn't get too out of date, but we have a big push to get everyone migrated, so the base images (x86 and x64) are pretty stale. I'm finding now, that since you *can* easily add things at deploy time, its hard to know when to stop updating stuff. You're literally never done unless you draw a line in the sand.

    I install Office 2010, Visio viewer, Acrobat flash and reader, Java, Quicktime, IE9, PDF creator, set a local GPO and tweak default user settings, turn off the firewall, turn on RDP and remote registry, set powersave levels, disable IPv6 and offline files, copy the corporate screen saver and install antivirus on my base image, then run Windows Update and sysprep and capture. That is all done by task sequence, no manual intervention needed. (that also makes the build process self-documenting and repeatable.)

    When I deploy I re-initalize the AV to get a unique guid, install a security app to block write access to peripherals. I install certain apps and run Mcafee full-disk encryption if its a laptop, add OMCI asset management if it is a Dell, install VMWare tools if it's a VM. Add asset info to a registry key using a modified ZTITatoo.wsf, install the Altiris agent and point it towards the proper server based on subnet location. Hard-code the KMS server address and activate the OS, (because our DNS is Unix-based and pitiful), update a couple things that are out of date since the last image build, change the local admin account name and password, and reboot. Again, all hands off after the initial litetouch.vbs kicks off.

    If we PXE boot or boot from flash drive, I have to supply a PC name and pick a task sequence. We do an in-place xp to win 7 migration using an Altiris job which kicks off Litetouch.vbs with the /TaskSequenceID: switch set, so that is totally zero touch. USMT data is collected and restored via hard-link migration. A lot of this is done with the MDT database per-subnet, but theres still quite a few things in the task sequence, and we're minimizing the customsettings.ini to just a few global settings.We have a pretty cool trick where we query the DB from bootstrap.ini instead of customsettings.ini, so we can use subnet data to choose the deployment share using the %ServerA% value in the location record. This way all our shares are identical, there is nothing location specific on them.

    We have three domains and probably 50 or more deployment shares currently. By the time we're done we'll be deploying in half a dozen different languages.

    So, yes, I do a couple customizations. Never had to modify the unattend.xml.



    • Edited by JoeZeppy Thursday, April 26, 2012 5:21 PM
    •  
     
  • Friday, May 04, 2012 12:06 AM
     
     
    Sign In to Vote
    0

    Well, a thick image is going to happen, one way or another.  If I can't get MDT working properly then we'll resort to using a PXE or thumb drive PE boot and deploy using imagex scripts manually.

    I got MDT working once but it then continued to fail again.

    So, I took your advice to heart and started over.  I created a new bare OS install task sequence with no customizations to the unattend and deployed it to a reference PC. I then immediately turned around and ran a new Sysprep and Capture sequence (also with no customizations... it was a test after all).  I then uploaded it into MDT and created a final deployment task sequence also with no customizations.  I re-imaged the PC with Windows XP and started the litetouch upgrade deployment sequence.  That ran just fine. So I guess that was a success.

    My question now is, I still need to modify one of the task sequence unattend.xml files, but since three are involved (OS deployment, sysprep, and final deployment), I don't know which one to make the mods to.

    I want to add the <CopyProfile> command, I want to add favorites to the Favorites Bar for all new logon users, and preferably add links to Excel and Word to the new task bar... although the last one is optional.

    Where should I make these changes?  I'd prefer it if they were all in the same place like the final deployment unattend.xml so I won't have to worrry about maintaining the other two.

    WindowsNetworking.com says to put the CopyProfile command in the final deployment unattend.xml and the IE customizations in the original OS deployment unattend.xml, but the last time I tried that, it kept failing.

    Where would the best place to add those commands?

     
  • Friday, May 04, 2012 12:13 AM
     
     
    Sign In to Vote
    0
    You should be able to modify the unattend.xml for the final deployment.  I have been able to make changes in that file without a problem (I think I was just changing some IE settings).  I suspect you will have your best luck if this is the only one you are trying to change.  
     
  • Friday, May 04, 2012 7:09 PM
     
     
    Sign In to Vote
    0

    Ahh, well you got me there. We don't do much local modification of the default profile, most of that is handled with GPO's. What I do change, I edit the ntuser.dat for the default profile or import a local policy.

    Johan has a post about CopyProfile and alternate methods here:

    http://www.deploymentresearch.com/Blog/tabid/62/EntryId/43/How-CopyProfile-really-works-in-Windows-7-Deployments.aspx

    I script modifying the Default user profile by using "REG Load " to mount it, make my changes via importing a .reg file or vbscript and then "REG unload" it