none
Deploy OS task sequence fails when deploying to multiple computers

    Question

  • Hi gang,

    I'm running into an issue when imaging multiple computers with MDT 2012. Let me give some background info.

    I have installed Windows 7 64 bit on a laptop in audit mode, made my configurations, sysprepped the machine, and captured a .wim using WDS (captured to an external hard drive). I then imported this .wim into MDT, created a Standard Client Task Sequence to deploy the image, and successfully deployed it to a machine.

    My problem comes up when I initiate this task sequence on multiple computers simultaneously. If I put 6 computers side-by-side and run the task sequence at the same time, only a couple machines will actually succeed. The rest fail with the following:

    FAILURE ( 5624 ): 2: Run ImageX: /apply "\\CAAPPWN40\DeploymentShare$\Operating Systems\T731 (Final) Windows 7 64 bit May 2013\T731 (Final) Windows 7 64 bit May 2013.wim"

    1 C:

    Litetouch deployment failed. Return Code = -2147467259 0x80004005

    Failed to run the action: Install Operating System

    Unknown error (Error: 000015F8; Source: Unknown)

    The execution of the group (Install) has failed and the execution has been aborted. An action failed.

    Operating aborted (Error: 80004004; Source: Windows)

    Failed to run the last action: Install Operating System. Execution of task sequence failed.

    Unknown error (Error: 000015F8; Source: Unknown)

    Task Sequence Engine failed! Code: enExecutionFail

    Task sequence execution failed with error code 80004005

    Error Task Sequence Manager failed to execute task sequence. Code 0x80004005

    BDD.log is saying that "The file or directory is corrupted and unreadable."

    If I restart the computer, boot back into PXE, and run the task sequence again, this time on it's own (as opposed to 6 computers at once) it works fine.

    Can anyone help?

    Friday, June 07, 2013 9:00 PM

Answers

  • i had the same issue w/ mdt 2012 on windows 2012.  i had to disable SMB2/3 using Set-SmbServerConfiguration -EnableSMB2Protocol $false

    haven't really figured out what in particular w/ smb 3.0 is causing the issue.  the exact same wim / task sequence works fine on mdt 2012 running on windows 2008 r2. 

    Sunday, June 23, 2013 3:31 AM

All replies

  • Sounds a bit like a locking situation.  What OS is your Deployment Share on?  Can you monitor network and file connections from the server and see the issue?

    David Coulter | http://DCtheGeek.blogspot.com | @DCtheGeek

    Monday, June 10, 2013 1:20 PM
    Answerer
  • My server is running Windows Server 2012. It never occurred to me that it might be a file locking situation, but it does make sense. I'm kind of new at the server stuff. Can you give me somewhere to start to find this info? I'm guessing I need to use perfmon but I'm not really familiar with it.

    Err, to clarify, I can see the file being accessed when using Resource Monitor but I'm not sure how to determine if, while multiple computers are being imaged, I'm running into a file locking issue.

    • Edited by Mike O'Connell Monday, June 10, 2013 8:55 PM Clarification
    Monday, June 10, 2013 8:47 PM
  • Without getting overly complicated in the search of file locks, the easiest thing may be to ensure that the ID that's connecting to the deployment share only has READ access to the WIM folder... this may prevent the lock during imaging that is causing you heartache.

    David Coulter | http://DCtheGeek.blogspot.com | @DCtheGeek

    Monday, June 10, 2013 11:45 PM
    Answerer
  • If you would like to deploy to many computers at once I would suggest you look at multicast instead of unicast. Depending on your switches configuration you may need to enable multicast. Best case cenario you only need to tick the box enable multicast in deployment workbench.
    Tuesday, June 11, 2013 6:48 AM
  • If you would like to deploy to many computers at once I would suggest you look at multicast instead of unicast. Depending on your switches configuration you may need to enable multicast. Best case cenario you only need to tick the box enable multicast in deployment workbench.

    Actually, I tried that last night! Multicasting 4 machines at the same time worked flawlessly, but took *forever*. Without multicast, the image takes about 20-30 minutes to deploy. With multicast it was over 2.5 hours. My server and clients are all on gig switches so I don't think the multicast slowness it's a network issue, but if that's the solution then I'll have to work on getting that faster.

    DCtheGeek, I just tested using imaging using an account that only has Read access to the DeploymentShare$\Operating Systems folder and got the same result. I've been watching the Disk Activity in Resource Monitor and I can see the .wim file being used, but only Read not Write.

    If it matters, I can upload the full BDD.log files once the forums let me.

    Tuesday, June 11, 2013 2:45 PM
  • Just upload to your favorite cloud storage in a shared location and provide the link.

    What happens if you clear all connections (or reboot the server), and only do imaging with the account that only has Read access?  It may have been a prior session that locked it before that attempt.  Not sure how much the BDD will help since it's probably a fileshare issue, but we can look. : )


    David Coulter | http://DCtheGeek.blogspot.com | @DCtheGeek

    Tuesday, June 11, 2013 3:00 PM
    Answerer
  • I just rebooted the server and tried again, same result.

    I keep getting a "Body text cannot contain links or images until we are able to verify your account" error when posting a hyperlink. I've had my technet account since October... weird.

    Here's the snippet that's important:

    <![LOG[  Console > [  18% ] Applying progress: 14:47 mins remaining ]LOG]!><time="11:27:10.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[  Console > [  19% ] Applying progress: 14:27 mins remaining ]LOG]!><time="11:27:18.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[  Console > [  20% ] Applying progress: 14:15 mins remaining ]LOG]!><time="11:27:32.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[  Console > [ RETRY ] Restoring C:\Program Files (x86)\Common Files\microsoft shared\OFFICE15\MSORES.DLL again (Error = 1392)]LOG]!><time="11:27:40.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[  Console > [  21% ] Applying progress: 14:06 mins remaining ]LOG]!><time="11:27:42.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[  Console > [  22% ] Applying progress: 13:49 mins remaining ]LOG]!><time="11:27:48.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[  Console > [  23% ] Applying progress: 13:29 mins remaining ]LOG]!><time="11:27:55.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[ZTI Heartbeat: command has been running for 5 minutes (process ID 516)]LOG]!><time="11:28:01.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[  Console > [ RETRY ] Restoring C:\Program Files (x86)\Intel Corporation\Intel Wireless Display\it\WiDiApp.resources.dll again (Error = 1392)]LOG]!><time="11:28:01.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[  Console > [ RETRY ] Restoring C:\Program Files (x86)\Intel Corporation\Intel Wireless Display\it\WiDiApp.resources.dll again (Error = 1392)]LOG]!><time="11:28:01.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[  Console > [ RETRY ] Restoring C:\Program Files (x86)\Intel Corporation\Intel Wireless Display\it\WiDiApp.resources.dll again (Error = 1392)]LOG]!><time="11:28:02.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[  Console > [ RETRY ] Restoring C:\Program Files (x86)\Intel Corporation\Intel Wireless Display\it\WiDiApp.resources.dll again (Error = 1392)]LOG]!><time="11:28:02.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[  Console > [  24% ] Applying progress: 13:13 mins remaining ]LOG]!><time="11:28:07.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[  Console > [ RETRY ] Restoring C:\Program Files (x86)\Microsoft Analysis Services\AS OLEDB\110\msmdlocal.dll again (Error = 1392)]LOG]!><time="11:28:13.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[  Console > [ RETRY ] Restoring C:\Program Files (x86)\Microsoft Analysis Services\AS OLEDB\110\msmdlocal.dll again (Error = 1392)]LOG]!><time="11:28:14.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[  Console > [ RETRY ] Restoring C:\Program Files (x86)\Microsoft Analysis Services\AS OLEDB\110\msmdlocal.dll again (Error = 1392)]LOG]!><time="11:28:15.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[  Console > [ RETRY ] Restoring C:\Program Files (x86)\Microsoft Analysis Services\AS OLEDB\110\msmdlocal.dll again (Error = 1392)]LOG]!><time="11:28:16.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[  Console > [ ERROR ] C:\Program Files (x86)\Microsoft Analysis Services\AS OLEDB\110\msmdlocal.dll (Error = 1392)]LOG]!><time="11:28:17.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[  Console > Error restoring image.]LOG]!><time="11:28:17.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[  Console > The file or directory is corrupted and unreadable. ]LOG]!><time="11:28:17.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[Return code from command = 2]LOG]!><time="11:28:17.000+000" date="06-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[FAILURE ( 5624 ): 2: Run ImageX:  /apply "\\MyServer\DeploymentShare$\Operating Systems\T731 (Final) Windows 7 64 bit May 2013\T731 (Final) Windows 7 64 bit May 2013.wim" 1 C:]LOG]!><time="11:28:17.000+000" date="06-11-2013" component="LTIApply" context="" type="3" thread="" file="LTIApply">
    <![LOG[Command completed, return code = -2147467259]LOG]!><time="11:28:18.000+000" date="06-11-2013" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
    <![LOG[Litetouch deployment failed, Return Code = -2147467259  0x80004005]LOG]!><time="11:28:18.000+000" date="06-11-2013" component="LiteTouch" context="" type="3" thread="" file="LiteTouch">
    

    Tuesday, June 11, 2013 3:40 PM
  • From the log it just makes it seem like either the WIM is corrupt or the local drive is having problems with the image being applied.  But you said this error happens only when you are imaging several machines at once?  That's why I don't think the BDD.log will give us anything new, and that it's something on the fileshare.

    If it's happening when you do six at once, try this just to prove the point:  replicate and import your WIM so there are a total of 6.  Then replicate your Task Sequence and point each one to a different copy of the WIM.  Then try imaging 6 at once, each using a different Task Sequence.  If it's file locking of the WIM, then all 6 should succeed.  If some fail, then it might be too many connections on the file share (although with Windows 2012, that shouldn't be the case).  Ugly, but it should provide more insight.


    David Coulter | http://DCtheGeek.blogspot.com | @DCtheGeek

    Tuesday, June 11, 2013 10:49 PM
    Answerer
  • Heh, now I get to bug my network admin for more storage. That's a good idea. I'll try that and post my results.
    Wednesday, June 12, 2013 1:14 PM
  • So... I made 4 copies of the .wim file, imported them all into MDT as separate Operating Systems, created 4 new Task Sequences, and pointed each Task Sequence to one of my copies. I booted 5 separate laptops into PXE and each ran one of the Task Sequences. 3 of the 5 laptops worked, 2 of the 5 failed with the same error. I guess that means there's some kind of network hiccup along the way?

    Any advice on what to do next?

    Wednesday, June 12, 2013 8:26 PM
  • That pretty much eliminates the file locking theory.  I think you might be right, something along the network.  Is it specific ports that tend to fail, same VLANs, etc?  Maybe run Wireshark and watch the Fileshare for the downloads to see when it starts to break?  I'm running out of ideas. =/

    David Coulter | http://DCtheGeek.blogspot.com | @DCtheGeek

    Wednesday, June 12, 2013 9:38 PM
    Answerer
  • I just did a bunch of tests monitoring the hard drive, memory, CPU, and network usage both on the server and on VMWare and it didn't show anything funky. The switch isn't reporting any dropped packets on any of the ports. Clients on different ports failed during each of my tests (on test #1, computers 2 and 4 failed, on test #2, computers 3, 4, and 5 failed). I have a pool of about 20 laptops that I've cycled for these tests so I don't think it's the client machines.

    Is it common to image 4+ clients simultaneously and not use multicast? I was under the impression that you would use unicast like I'm doing until network load became an issue, then you would switch to multicast, but from my evidence my network load isn't capping.


    • Edited by Mike O'Connell Wednesday, June 12, 2013 10:24 PM Spelling is hard
    Wednesday, June 12, 2013 10:10 PM
  • Yes, I've done many more than 4 at once (just did ~15 a day or two ago) with unicast, so that shouldn't be it.  If you aren't maxing out the nic or HDD, then something else is going on and I've run out of ideas to point my finger at.

    David Coulter | http://DCtheGeek.blogspot.com | @DCtheGeek

    Wednesday, June 12, 2013 10:15 PM
    Answerer
  • Well thanks for all your help!

    What speed are your hard drives? Mine are 7200rpm drives and I wonder if that has anything to do with it.
    Wednesday, June 12, 2013 10:26 PM
  • Don't feel I've helped other than for you to find lots of things it wasn't. : P

    Hard drives are all kinds of speeds, 5400, 7200, and even some SSDs.


    David Coulter | http://DCtheGeek.blogspot.com | @DCtheGeek

    Wednesday, June 12, 2013 10:30 PM
    Answerer
  • Heh, I guess I meant "Thanks for all your time" haha.

    You're using PXE boot as opposed to boot media to initiate your imaging, correct? I'm just trying to figure out what I have configured differently. I don't think my MDT server is configured a whole lot different than most of the turorials out there.

    Is it common for multicast to take so long, or is there a scenario where I could use multicast to image machines in some amount of time under 1 hour? I'm glad my multicast is working without error, but it just take so long.

    Thursday, June 13, 2013 2:34 PM
  • A combination of PXE boot and boot media.  I guess you could try to eliminate that specific server as the problem and put a copy of the Deployment Share on another server, regen boot images to point there, and try a few devices.

    My multicast experience is very limited.  I've seen others complain about it being slow (search this forum for related threads), but don't know enough about it to comment.


    David Coulter | http://DCtheGeek.blogspot.com | @DCtheGeek

    Thursday, June 13, 2013 2:45 PM
    Answerer
  • Are the same machines receiving the error when deploying multiple clients or is this random as well?
    (Bios of Motherboard and NIC may have an influence)

    Are you certain that you are not running out of IP addresses?

    @DCtheGeek:
    Do you have some more information with file locking issues when requesting full instead of read access?
    Seems worth a read.

    • Edited by orioon Thursday, June 13, 2013 5:56 PM
    Thursday, June 13, 2013 5:55 PM
  • It seems to be random machines on random ports. I've been able to individually image each of these laptops successfully, and different ones fail when I do them in batches.


    I might have found another clue. To test, I added my install image to WDS and tried bypassing MDT altogether. I queued up 5 machines as I did before, and some are working fine and some are failing! This time I'm getting error code 0x80070570 on the clients that are failing. I believe it has a similar description (corrupt or unreadable). some quick Googling suggested that this happens when I add my WDS Install Image to an existing Image Group, but I made a new image group for this so I'm starting to wonder if something it up with my .wim files.

    I tried another known working .wim file for a different model laptop I have here and it's giving the same result. I wonder if something with my capture process is bugging my .wim files out somehow?

    Like I stated in my original post, when making my images I sysprep my reference machine and then capture an image with WDS before the reference machine boots up for the first time. I then take that image and import it into MDT to deploy. Maybe my method of capturing images and importing is prone to corruption?


    @orioon
    I don't think I'm running out of IPs. All of the machines boot into PXE and initiate my task sequence, they just fail after some % completed.

    Thursday, June 13, 2013 7:13 PM
  • Hmm... making progress. I added a plain Windows 7 image, straight from the Windows disk, into MDT and made a default Standard Client Task Sequence. This image works perfectly imaging multiple machines! I'm starting to think that something is wrong with my thick images. I use WDS to capture my thick image after I sysprep it, import it into MDT, and make a very basic Standard Client Task Sequence to deploy it. Is that a common way to do it? I was having trouble capturing a thick image using MDT which is why I'm doing it this way.
    Friday, June 14, 2013 3:21 PM
  • In all our project we use the Sysprep and Capture task sequence.   Add a Sysprep and Capture Task Sequence to MDT.

    1.  Finish your thick image

    2.  From the Thick Image Reference Map a drive to your Deployment Share

    3.  Go to the Scripts folder and start the LiteTouch.wsf file

    4.  Select the Sysrep and Capture Task Sequence

    5.  Let MDT Capture the image to the <DeploymentShare>\Captures folder


    MDT Task Sequence Duplicator https://panaconsulting.egnyte.com/h-s/20130614/61707be809944999 Application Bundle Duplicator https://panaconsulting.egnyte.com/h-s/20130614/405e7d64e5d54610

    Friday, June 14, 2013 4:47 PM
  • I'm not 100% sure with what you mean by "use WDS to capture my thick image".  You mean you use WDS to run a Boot Image like WinPE and then run the capture from that platform?  It does seem like signs are pointing at your WIM, but I'm curious how that's possible when it works successfully on machines when imaged one at a time.

    The steps SABK gave are one of the most common ways to capture a machine.  Is the machine you are capturing from a VM or a physical device?  Building your reference image in a VM is highly suggested (and then you can snapshot it and make changes faster).  The other way people create their reference images is by using a standard Task Sequence with the original media OS and to have the capture step run at the end.  This is more of an end-to-end way of doing it and leads to more automation (since instead of manually configuring your reference machine and then capturing it, the Task Sequence configures it AND captures it).


    David Coulter | http://DCtheGeek.blogspot.com | @DCtheGeek

    Saturday, June 15, 2013 2:08 AM
    Answerer
  • In all our project we use the Sysprep and Capture task sequence.   Add a Sysprep and Capture Task Sequence to MDT.

    1.  Finish your thick image

    2.  From the Thick Image Reference Map a drive to your Deployment Share

    3.  Go to the Scripts folder and start the LiteTouch.wsf file

    4.  Select the Sysrep and Capture Task Sequence

    5.  Let MDT Capture the image to the <DeploymentShare>\Captures folder


    MDT Task Sequence Duplicator https://panaconsulting.egnyte.com/h-s/20130614/61707be809944999 Application Bundle Duplicator https://panaconsulting.egnyte.com/h-s/20130614/405e7d64e5d54610

    I actually have tried capturing this way, which worked, but I ran into trouble when deploying afterward. It seems like my unattend file's settings were being overwritten no matter what I did. If I capture this way, is there anything special I need to do in my deploy task sequence? I'm under the impression that I need separate capture and deploy task sequences.

    How I did it before (where it seemed like my unattend file settings were being overwritten) was:

    1. Create a "Sysprep and Capture" task sequence
    2. Modify the unattend.xml file in this task sequence with the settings I want
    3. On the reference machine while in audit mode, map my deployment share, run litetouch.wsf, and choose "Prepare Only"
    4. On the reference machine again, while in audit mode, run litetouch.wsf again, this time choosing "Sysprep and Capture"
    5. In the final wizard screen of the task sequence, choose to "Capture an image of this reference computer"
    6. Import my new .wim file into MDT, make a basic "Standard Client Task Sequence", and deploy to a laptop

    Is there something I'm doing wrong?

    Correct, DC. I made a WDS Capture image that I boot into using PXE, capture my image to an external hard drive, and transfer it over to my server. I'm using physical laptops, not a VM.

    Ideally I'd like to get away from the thick image model, but I need to keep my reimage time under an hour and with my current issues this seems to be the only way to do it. I only have a few different computer models so it's not a huge task... yet!

    Monday, June 17, 2013 2:32 PM
  • No need to run the "Prepare Only" first or to run LiteTouch.wsf in audit mode for the "Sysprep and Capture".  The default "Sysprep and Capture" will prep the machine, reboot to WinPE, and then grab the WIM and effectively handles sysprep related actions for you as part of the Task Sequence.  And best practice for capturing images is to do it in a VM (also helps with snapshotting and repeatability).

    Depending on where the changes you made to the Unattend.xml, you may need to make them to the "Deploy" Task Sequence's Unattend.xml instead.  Example would be if the changes were in Specialize or OOBE sections.


    David Coulter | http://DCtheGeek.blogspot.com | @DCtheGeek

    Monday, June 17, 2013 3:01 PM
    Answerer
  • Ah, ok. My unattend file does have stuff to do during the Specialize and OOBE steps, so I should make sure my Sysprep and Capture TS and my Deploy TS have the same unattend file, correct?

    For the Standard Client Task Sequence to use its unattend file, do I need the "Imaging" step under "State Restore" enabled?

    Am I understanding correctly that I don't need to use audit mode when creating images with MDT? I can install the OS normally, then when I'm ready simply map my deploymentshare and run my Sysprep and Capture TS? If that's true, is there any harm in using audit mode?

    Monday, June 17, 2013 3:48 PM
  • Well, I wouldn't say they'd use the same... as again, each one is using certain parts ("Sysprep and Capture" uses generalize/others and "Deploy" uses specialize and oobe and others).   You probably could make them the same, just understand why they don't have to be.

    The "Imaging" group under "State Restore" is only for using sysprep to prep, sysprep only, or sysprep and capture (based on DoCapture task sequence variable).  It won't run if DoCapture isn't set in CustomSettings.ini or during the Wizards.  You can remove from your Deploy Task Sequence if you desire, but you don't have to.  The Standard Client Task Sequence will use it's own Unattend.xml file (%DeployRoot%\Control\<TS ID>\Unattend.xml) in the "Install Operating System" step.

    Correct, you don't need to use audit mode since MDT will completely handle running Sysprep.  There may be no harm in doing so, I've simply never tried it.


    David Coulter | http://DCtheGeek.blogspot.com | @DCtheGeek

    Monday, June 17, 2013 3:57 PM
    Answerer
  • ^ Have an upvote, sir! Knowing this little tidbit of information would have saved me hours of troubleshooting! I was using my custom unattend.xml in either the capture TS or the deploy TS, but never both (I understand what you're saying about certain passes working during certain task sequences though). I just assumed that since the "Install Operating System" step didn't mention anything specifically about the unattend file, that it wasn't doing anything.

    Unfortunately though, even after re-capturing my reference computer using MDT and deploying using MDT, my issue is still present. I'm going to try creating my reference machine from scratch next and see if that improves anything. It may take me a day or so but stay tuned!

    For the record, I captured from audit mode using the steps above and it worked without issue.

    Monday, June 17, 2013 7:31 PM
  • Well, if you are going to rebuild it, you could do the next step in automation:  automate the reference image.

    Instead of manually installing and configuring Windows, then manually running the "Sysprep and Capture", you can create a Standard Client Task Sequence to install from the OEM image (import the Windows DVD files), install your applications, run scripts to tweak the registry/apps/config, run Updates, then run the capture.  Then your reference image is just a "Build" Task Sequence that does the whole process end-to-end and is very repeatable.  In this case, since Sysprep would run for both the Image and the Capture (from the same Task Sequence), then you'd update the single Unattend.xml for the Task Sequence with all the steps for generalize/specialize.


    David Coulter | http://DCtheGeek.blogspot.com | @DCtheGeek

    Monday, June 17, 2013 8:03 PM
    Answerer
  • I have a lot of apps to install. If I could get them all into MDT and had them install during the deploying process, wouldn't it take a long time to deploy the image? I've tried adding just Office 2010 before and it like doubled my imaging time.
    Monday, June 17, 2013 8:13 PM
  • Are you currently installing those apps into your reference image?  I'm not saying to run them during your "Deploy" Task Sequence, I'm saying to run them during your "Build" Task Sequence that you use to create your reference image.  Then you import the reference image, change "Deploy" to use that WIM, and you are all set with your apps (and a quick install).

    Time for deployment is one of the biggest reasons people move to a "thick" image.  I'm not suggestion you abandon that, I'm suggesting you fully automate that "thick" reference image. : )


    David Coulter | http://DCtheGeek.blogspot.com | @DCtheGeek

    Monday, June 17, 2013 8:19 PM
    Answerer
  • Currently I don't have any apps in MDT at all. What I've been doing is installing Windows from scratch using the DVD onto a laptop, booting into audit mode, getting all my drivers and software loaded up via USB stick, the internet, or my network drive, then capturing a "clean" image before I sysprep the machine. Finally, I sysprep and capture (which I'll be doing in MDT now :D)

    When I want to update my image, I deploy my "clean" image back to a laptop, make my changes, capture a new "clean" image, then sysprep and capture a final image.

    I essentially keep a "clean" and "final" image for each computer model I have. I'd love to automate the build process, I just don't know a whole lot about MDT (mainly Google-taught!) so I just tried to replicate my old process I used back in the day with Ghost.

    One thing I like about manually installing the software is that I can configure a lot of them myself. Things like turning first-time wizard screens off. I'll play around with adding apps and see what works easily and what doesn't. I had some trouble configuring Office 2010 in MDT to make it look the way I wanted, but now that we're on 2013 I'll have another go at it.

    Monday, June 17, 2013 9:27 PM
  • Yup, you can do all that through MDT.  For building your reference image, you should do it in a Virtual Machine to keep it hardware agnostic and keep drivers at a minimum.  There may be manual tweaks you want to make... resist the urge unless you can do it via the registry, a script, or Group Policy.  It becomes easier to manage and to repeat (and the "Buid" Task Sequence becomes like your image documentation).

    When you go to Deploy the image, you can include Drivers for each model you support on WMI condition so that one Task Sequence can deploy your one reference image to many different models.

    For Office, between OCT / GPO / Reg, there isn't a lot of anything I've found that you can't tweak programattically. : )


    David Coulter | http://DCtheGeek.blogspot.com | @DCtheGeek

    Monday, June 17, 2013 9:49 PM
    Answerer
  • i had the same issue w/ mdt 2012 on windows 2012.  i had to disable SMB2/3 using Set-SmbServerConfiguration -EnableSMB2Protocol $false

    haven't really figured out what in particular w/ smb 3.0 is causing the issue.  the exact same wim / task sequence works fine on mdt 2012 running on windows 2008 r2. 

    Sunday, June 23, 2013 3:31 AM
  • i had the same issue w/ mdt 2012 on windows 2012.  i had to disable SMB2/3 using Set-SmbServerConfiguration -EnableSMB2Protocol $false

    haven't really figured out what in particular w/ smb 3.0 is causing the issue.  the exact same wim / task sequence works fine on mdt 2012 running on windows 2008 r2. 

    This just solved my problem! I'm going to do some reading on SMB to maybe figure out why, but I just successfully imaged 6 machines unicasting, and then a batch of 12, all successful!

    Just for clarity, I haven't rebuilt my image yet. This is working with the original image I had the initial issue with.

    Thursday, July 04, 2013 4:39 PM