none
Issue with Windows 7 64 bits capture RRS feed

  • Question

  • Hi,

    We've been using MDT 2010, 2011 and 2013 deploying a couple of masters on 700 computers for 3 years.

    Up to now we used to deploy 32 bits masters as our computers were only used with business softwares and were a little bit old (5 or 6 years old, but enough for Windows 7, with a Core 2 Duo and 3 Gb of RAM).

    We've installed MDT using applications, operating systems (Windows 7 SP 1 Ent 32 bits), Dell packaged drivers cabs (Dell models : OptiPlex 330, 380, 745, 755, 760, 9010, 9020, 3010, 3020, and HP4540 laptops), 15 tasks sequences and all is based on our DATABASE deployment to automate the operations.

    We're also using WDS with a couple of Lite Touch Windows PE x86 images.

    As said above everyhthing is working nice.

    But lately, we've been asked to master more and more 64 bits computers for some dedicated users, and this will probably increase !

    Obviously, we want to anticipate and we set about to generate a 64 bit master !

    To do so, as usual, the Windows 7 64 bits Wim image was imported, we have created a dedicated capture task sequence, we have checked the option to generate x86 AND x64 Win PE boot images, ticked the options to generate LiteTouch Windows PE x64 images, selected the "Drivers WinPE" selection profile in drivers and patches tab, we have updated MDT to generate it, we've imported the WinPE image in WDS, we've disabled the x86 image, we have manually installed a computer (OptiPlex 3020), applied all the Microsoft Windows Updates, removed our second partitions so that only one was left, we have removed the additional profile to leave Adminstrator only with no password, and obviously, the computer has not been added to our domain !.

    When the capture process is starting to connect to our deploymentshare with the same account as the one used to log on to our MDT server, everything is fine till the end of the sysprep process (we start as usual the Litetouch.vbs script), but when the computer reboots, the MDT blue screen is displayed, a few seconds later the DOS window pop-up and nothing else happens !

    No error, no message, no possibility to get any log apparently.

    I did the same thing with an older computer, an Opitplex 745 but with the same issue !

    I tested again with a new 32 bits capture, it's working fine...

    We searched Internet but didn't find anything relevant up to now.

    However I was thinking about something and I'm not quite sure : taking a look at MDT components, only the WAIK x86 is installed.
    Is the 64 bits which is diownloadable through the interface, necessary when MDT is broadcasting 32 AND 64 bits masters, or not ?

    I feel lost !

    Thanks in advance for your help or suggestions !

    Philippe.

    Monday, March 9, 2015 2:07 PM

All replies

  • Philippe,

    Could you check if x64 support is checked on the general deploymentshare properties and no particular checkboxes are marked at the specific task sequence you are using.

    Not only can you configure MDT to generate x86 and x64 iso's, you can also enable/disable support for x86 and x64 platforms separately on the deployment share properties:

    See this image as example

    And this is also configurable for your task sequence:

    So perhaps there's your problem

    Cheers! Rens


    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Monday, March 9, 2015 2:18 PM
  • If you are bugchecking in WinPE then it is possible there is a driver issue.  My personal suggestion is only have the drivers necessary to access storage and network devices for WinPE.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.


    Monday, March 9, 2015 6:22 PM
    Moderator
  • check this link in spanish http://blogs.itpro.es/octaviordz/2014/09/02/error-en-sysprep-and-capture-windows-8-1-con-mdt-2013-y-su-solucion/

    MVP Jesús Octavio Rdz http://blogs.itpro.es/octaviordz

    Tuesday, March 10, 2015 12:26 AM
  • Hi Rens,

    Thank so much for your quick reply ! ;-)

    Regarding your first screenshot, I checked both options considering that both are mandatory to be able to broadcast images for both operating systems !

    Shall I untick the x86 when I want to broadcast a 64 bit image or just to generate a 64 bit WinPE, or can both these options be left permanently ticked at the same time ?

    I also noticed the option on your second screenshot and just wondered for a while if i shoudn't force the choice for a Windows 7 64 bit, and didn't do it thinking that MDT would be Wise enough to apply the proper settings with all the other information provided by the previous steps through the 64 bit WinPE generated !

    So, what's the procedure to generate a WinPE 64 bits and then be able to use our MDT 2013 to broadcast indifferently 32 bits or 64 bits images ?

    Furthermore, shall I install the Windows Automated instalaltion kit (x64) on top of the already installed 32 bits kit !?

    Kind regards,

    Philippe.

    Tuesday, March 10, 2015 10:20 AM
  • Hi Philippe,

    You're welcome. You may leave both checkboxes ticked while working in a x86-x64 environment. Basically if one is unchecked, the first thing MDT check's when it enters WinPE which platform you are running. If it doesn't have a match it will terminate and show you the things you have experienced.

    Also it's good to know to take into consideration, that x86 boot images are capable of doing x86 and x64 deployments, while x64 boot images only will deploy... x64 operating systems. So when you have an x64 boot image, you will also experience the behavior that MDT will terminate while trying to deploy a x86 operating system.

    Regarding your question whether to tick or untick the Windows 7 64 bit option, these options are usefull for Applications and other conditions, but what's the use of ticking: Windows 7 64 bit option, on the task sequence where you deploy your 64 bit operating system from. I never use these options. If I want to filter something I'll make use of all the available properties in my bdd.log and gratefully make use of WMI queries.

    If you want to generate x86 and x64 WinPE images, then keep in mind I just explained about the capabilities of each boot image.

    Regarding your last question, if the machine you use to service your deploymentshare with is 32 bit, you use 32 bit MDT and 32 bit WAIK, and if it's x64, all the other components are x64 too!

    Again I've never used the 32 bit software, I'm 64 bit FTW all the way ;-)

    Cheers! Rens


    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Tuesday, March 10, 2015 10:29 AM
  • Hola Jesus !

    Gracias por su respuesta !

    No hay ningun problema yo puedo leer las explicaciones en espanol ! ;-)

    I will switch to English for people that could be stuck just like us and looking for some help ! ;-)

    Regarding the tutorial, everything is working fine just like in your article except that I don't have ANY error message !
    It's infuriating to be unable to debug the problem with a log, unless someone knows where I could find one because there's nothing on the MDT server except a huge WCF.log file (11 GB !!) generated on our C:\Temp folder on the MDT server!

    The computer simply reboots at the end of the sysprep, I've got the MDT background, then the DOS console pops-up and keeps displayed on the prompt for ever !

    Furthermore, I don't know if your explanation aslo applys to Windows 7 which is quite different from Windows 8 regarding partitions !?

    Kind regards,

    Philippe.

    Tuesday, March 10, 2015 10:32 AM
  • Philippe,

    To enable logging in your MDT environment, past the following line in your customsettings.ini:

    "SLShareDynamicLogging=%DeployRoot%\Logs\%COMPUTERNAME%"

    Then have a look in your .\DeploymentShare\Logs folder to find a folder starting with "MININT-" and BDD.log inside, view the logfile with CMtrace.exe, this should give you a good indication where you are looking at.

    Cheers! Rens


    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Tuesday, March 10, 2015 10:35 AM
  • Rens,

    As our MDT server is a Windows 2008 R2 64 bits (of course), and our MDT installation is 32 bits (because back then, we considered that we would not need 64 bits for a while), can I try to boot with a Win PE x86 and successfully capture my Windows 7 64 bits, or is this doomed to failure because of two antagonistic components ?

    Kind regards,

    Philippe


    • Edited by Phil49000 Tuesday, March 10, 2015 11:03 AM
    Tuesday, March 10, 2015 11:03 AM
  • Philippe,

    Your server and your share are two completely different things. You could have 10 machines with MDT and WAIK/ADK installed both x86 and x64 machines and service the share > (that's why it's called deploymentshare) individually from each machine.

    Capturing an x64 operating system with an x86 boot image works problem free, the same goes for an x64 boot image. :-)

    Cheers! Rens


    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Tuesday, March 10, 2015 11:09 AM
  • Rens,

    To sum it up, I let the options ticked at the beginning, I simply disabled the WinPE 64 bits in our WDS console and reenabled the WInPE 32 bits.

    Here's our custom.ini content working properly for our 32 bit capture :

    [Settings]
    Priority=Default
    Properties=MyCustomProperty

    [Default]
    OSInstall=Y
    SkipAppsOnUpgrade=YES
    SkipCapture=NO
    SkipAdminPassword=YES
    SkipProductKey=YES
    SkipPackageDisplay=YES
    UILanguage=fr-FR
    UserLocale=fr-FR
    KeyboardLocale=fr-FR
    SkipTaskSequence=NO
    DoCapture=YES
    TimeZone=105
    TimeZoneName=Romance Standard Time

    SLShareDynamicLogging=%DeployRoot%\Logs\%COMPUTERNAME%

    As you can notice I simply added the suggested line to generate a BDD.log.

    This line is doing it's job since I got a log file, unfortunately :

    - the capture failed with the same symptoms
    - the log file suggests that everything is working fine

    Here're a few excerpts of the last lines among which the one set in bold in french meaning that the operation is successful !

    C:\_SMSTaskSequence\Scripts\ZTIUtility.vbs]LOG]!><time="14:22:57.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[Copying Scripts ZTIDataAccess.vbs  to C:\_SMSTaskSequence\Scripts\ZTIDataAccess.vbs]LOG]!><time="14:22:57.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[LTI Windows PE applied successfully]LOG]!><time="14:22:57.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[LTIApply processing completed successfully.]LOG]!><time="14:22:58.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[Processing drivers for an X64 operating system.]LOG]!><time="14:22:59.000+000" date="03-10-2015" component="ZTIDrivers" context="" type="1" thread="" file="ZTIDrivers">
    <![LOG[TargetOS is the current SystemDrive]LOG]!><time="14:22:59.000+000" date="03-10-2015" component="ZTIDrivers" context="" type="1" thread="" file="ZTIDrivers">
    <![LOG[Property DriverCleanup is now = DONE]LOG]!><time="14:22:59.000+000" date="03-10-2015" component="ZTIDrivers" context="" type="1" thread="" file="ZTIDrivers">
    <![LOG[Compare Image processor Type with Original [X64] = [X64].]LOG]!><time="14:22:59.000+000" date="03-10-2015" component="ZTIDrivers" context="" type="1" thread="" file="ZTIDrivers">
    <![LOG[Prepare machine for Sysprep.]LOG]!><time="14:22:59.000+000" date="03-10-2015" component="ZTIDrivers" context="" type="1" thread="" file="ZTIDrivers">
    <![LOG[No driver actions can be taken for OS Images installed from *.wim files.]LOG]!><time="14:22:59.000+000" date="03-10-2015" component="ZTIDrivers" context="" type="1" thread="" file="ZTIDrivers">
    <![LOG[ZTIDrivers processing completed successfully.]LOG]!><time="14:22:59.000+000" date="03-10-2015"

    ...Further on...

    <![LOG[BCD> L'op‚ration a r‚ussi.]LOG]!><time="14:24:37.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[BCDEdit returned ErrorLevel = 0]LOG]!><time="14:24:37.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[Property BootPE is now = True]LOG]!><time="14:24:37.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[LTI Windows PE applied successfully]LOG]!><time="14:24:37.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[LTIApply processing completed successfully.]LOG]!><time="14:24:37.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">

    There's defintely another problem...

    Kind regards,

    Philippe.

    Tuesday, March 10, 2015 1:55 PM
  • Philippe,

    To have a successful capture you at least need the following 4 values declared in your cs.ini, I see only two in yours SkipCapture=NO; DoCapture=YES:

    SkipCapture=YES
    DoCapture=YES
    ComputerBackupLocation=%DeployRoot%\Captures
    BackupFile=W7ENTSP1x64EN.wim

    If set, these settings will make sure a WIM file is written back to your .\DeploymentShare\Captures folder

    Cheers! Rens


    If this post is helpful please click &quot;Mark for answer&quot;, thanks! Kind regards

    Tuesday, March 10, 2015 2:01 PM
  • Rens,

    I'm really desperate ! :-(

    I changed my custom settings adding the commands suggested, therefore my custom settings is now as follow :

    [Settings]
    Priority=Default
    Properties=MyCustomProperty

    [Default]
    OSInstall=Y
    SkipAppsOnUpgrade=YES
    SkipCapture=NO
    SkipAdminPassword=YES
    SkipProductKey=YES
    SkipPackageDisplay=YES
    UILanguage=fr-FR
    UserLocale=fr-FR
    KeyboardLocale=fr-FR
    SkipTaskSequence=NO
    DoCapture=YES
    ComputerBackupLocation=%DeployRoot%\Captures
    BackupFile=W7ENTSP1x64EN.wim
    TimeZone=105
    TimeZoneName=Romance Standard Time

    SLShareDynamicLogging=%DeployRoot%\Logs\%COMPUTERNAME%

    I've updated MDT, it detected some changes so a new WinPE was generated.

    I then imported the new image in WDS.

    I've installed my PC from scratch for the umpteenth time, I then executd the Litetouch.vbs script, but alas, with the same result...

    Same reboot with the DOS window opoin-up and then

    The BDD.log keeps saying that it's successful :

    type="1" thread="" file="LTIApply">
    <![LOG[BCDEdit returned ErrorLevel = 0]LOG]!><time="15:40:39.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[Run Command: C:\Windows\SYSTEM32\bcdedit.exe /displayorder {d22e7e91-9ee7-46eb-89d7-c5859e4302f0} /addfirst]LOG]!><time="15:40:39.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[BCD> L'op‚ration a r‚ussi.]LOG]!><time="15:40:39.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[BCDEdit returned ErrorLevel = 0]LOG]!><time="15:40:39.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[Run Command: C:\Windows\SYSTEM32\bcdedit.exe /bootsequence {d22e7e91-9ee7-46eb-89d7-c5859e4302f0}]LOG]!><time="15:40:39.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[BCD> L'op‚ration a r‚ussi.]LOG]!><time="15:40:39.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[BCDEdit returned ErrorLevel = 0]LOG]!><time="15:40:39.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[Run Command: C:\Windows\SYSTEM32\bcdedit.exe /default {d22e7e91-9ee7-46eb-89d7-c5859e4302f0}]LOG]!><time="15:40:39.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[BCD> L'op‚ration a r‚ussi.]LOG]!><time="15:40:39.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[BCDEdit returned ErrorLevel = 0]LOG]!><time="15:40:39.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[Property BootPE is now = True]LOG]!><time="15:40:39.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[LTI Windows PE applied successfully]LOG]!><time="15:40:39.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[LTIApply processing completed successfully.]LOG]!><time="15:40:39.000+000" date="03-10-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">

    Except resorting to Voodoo I don't see any solution ! :-(

    Any other idea my dear Rens !?

    Just as a reminder, x86 and x64 are still ticked in "Platform supported" section, but as we said this should have no incidence whatsoever on the process !?
    Is there any "subtlelty" when importing the 64 bit Operating System ?

    I did as I probably did 3 or 4 years ago with the 32 bit one, I set my DVD and let MDT copy and generate the WIM file, I then created the task sequence linking the operating system imported beforehand .

    I'm desperately trying to understand what I failed to do because since it's working with 32 bits, it should be likewise with 64 bits too !

    Kind regards,

    Philippe

    Tuesday, March 10, 2015 3:01 PM
  • Which distribution of MDT are you using in this scenario?

    If you're using MDT 2013, have you installed the ADK v8.1?


    V/R, Darrick West - Senior Systems Engineer, ConfigMgr: OSD

    Tuesday, March 10, 2015 3:40 PM
  • Have you imported x64 drivers for your hardware?

    How are you importing them: Importing all drivers into the Out-of-Box-Drivers node or have you created an architecture\model folder structure?


    V/R, Darrick West - Senior Systems Engineer, ConfigMgr: OSD

    Tuesday, March 10, 2015 5:05 PM
  • Hello Darrick,

    First of all, thanks for your answers.

    Regarding our MDT installation, what I can say for sure is that our version is MDT 2013 (6.2.5019.0).

    I left one of my young colleagues (who has now left our company at the end of his training), upgrade our initial installation of MDT 2011.

    I was busy on another project but asked him to keep me informed on the operations.

    WAIK is v6.1.7600.16385 and is the x86 version.

    As far as our drivers are concerned, yes, we found the model folder structure more appropriate.

    We're fully using applications, operating system was initially limited to Windows 7 SP1 Enterprise, I only added the 64 bit version, and I think we'll soon have to take a look at Windows 10 when it's available.

    We're relying on 11 drivers folders for our Dell computers (OptiPlex 330,380,390,745, 755, 760, 9010, 9020, 3020, and HP4540S as well as WinPE drivers).

    For each model, we've downloaded Dell driver cabs and we've updated them last summer.

    We also use language packages (Fr, En, Es, De, Cn and Hu).

    For task sequences, we have created one for each model and for each profile (students and permanent staff) as well as one for... O.S capture of course.

    Finally, to manage all this we're relying on the SQL Express Database, we made the choice to use roles as the center pivot.

    Each role is used to remaster a specific room, it's a mix between profile and location for us.

    All of this is working perfectly to master Windows 7 32 bits and up to now we didn't have any "serious" problem.
    The only problem we had last year was comingh from IE11 and the xml impact that was supposed to be corrected by MDT 2013.

    We've had for a while a problem of password, I mean, we had to remove the computer account in A.D before remastering a machine else the session would be locked on the domain administrator who was not supposed to be used at this step, and we had to log on as local administrator in order to let the process proceed else the master sequence would stop at this step and no application would be installed !

    But lately I noticed that this problem seems to have vanished.

    Hope this is clear enough to help you understand our installation !

    Kind regards,

    Philippe



    • Edited by Phil49000 Wednesday, March 11, 2015 8:00 AM
    Wednesday, March 11, 2015 7:48 AM
  • Sounds like a nice setup.

    Be that as it may, please note the following system requirements for MDT 2013: You must install the ADK 8.1 for all deployment scenarios:

    MDT 2013 Download and Information

    Understanding the Windows ADK for Windows 8.1 Update and MDT 2013


    V/R, Darrick West - Senior Systems Engineer, ConfigMgr: OSD

    Wednesday, March 11, 2015 2:47 PM
  • Hello Darrick,

    I've read the article related to Windows ADK for Windows 8.1 Update and MDT 2013, but I fail to see what this would change to our current problem ?

    Most of the improvements seem to be dedicated to Windows... 8 or 8.1 but not really Windows 7, unless I missed something important !?

    I'm not stubborn but I would like to know what I'm doing and just hope this wouldn't bring more problems thant it could solve ! ;-)

    Kind regards,

    Philippe.

    Wednesday, March 11, 2015 3:26 PM
  • How about the part where it says ADK 8.1 is required for all deployment scenarios when using MDT 2013? ;-)


    V/R, Darrick West - Senior Systems Engineer, ConfigMgr: OSD





    Wednesday, March 11, 2015 4:05 PM
  • Hello Darrick,

    The good news is that this update has been successfully applied, the bad news is that it doesn't make the slightest difference ! :-(

    Let me detail what I did.

    I applied the update, I let the default functions ticked, that's : deployment Tools, Windows preinstallation environment (Windows PE) and Windows performance Toolkit.
    I guess that it can detect available functions and only suggest to update latest one, so I let ACT, USMT, VAMT, Windows Asssment Services and Microsft SQL Server 2012 express unticked.

    It didnt ask to reboot the server, even though I was pretty sure it would need it, I tried to capture as usual this 64 bit image, alas I got a nice red window "ZTI error - Unhandled error retruned by LTISysprep: The system cannot find the file specified (-2147024894 0x80070002)".

    I then rebooted the server, I remastered my PC, I let the latest WinPE x86 file generated earlier this week.

    The red mesage didn't pop-up fortunately as this was certainly a consequence of the update, but any way, the same usual symptoms, I then switched to my previous WinPE file, the one we're using for 32 bit images, and alas, I got the same thing...

    Here's an excerpt of the end of the BDD file generated if it can help, but to me it looks the same as the one I posted in a previous email...

    <![LOG[BCD> L'op‚ration a r‚ussi.]LOG]!><time="16:01:05.000+000" date="03-12-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[BCDEdit returned ErrorLevel = 0]LOG]!><time="16:01:05.000+000" date="03-12-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[Run Command: C:\Windows\SYSTEM32\bcdedit.exe /bootsequence {d22e7e91-9ee7-46eb-89d7-c5859e4302f0}]LOG]!><time="16:01:05.000+000" date="03-12-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[BCD> L'op‚ration a r‚ussi.]LOG]!><time="16:01:05.000+000" date="03-12-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[BCDEdit returned ErrorLevel = 0]LOG]!><time="16:01:05.000+000" date="03-12-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[Run Command: C:\Windows\SYSTEM32\bcdedit.exe /default {d22e7e91-9ee7-46eb-89d7-c5859e4302f0}]LOG]!><time="16:01:05.000+000" date="03-12-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[BCD> L'op‚ration a r‚ussi.]LOG]!><time="16:01:05.000+000" date="03-12-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[BCDEdit returned ErrorLevel = 0]LOG]!><time="16:01:05.000+000" date="03-12-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[Property BootPE is now = True]LOG]!><time="16:01:05.000+000" date="03-12-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[LTI Windows PE applied successfully]LOG]!><time="16:01:05.000+000" date="03-12-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[LTIApply processing completed successfully.]LOG]!><time="16:01:05.000+000" date="03-12-2015" component="LTIApply" context="" type="1" thread="" file="LTIApply">

    Any idea !?

    Kind regards,

    Philippe.



    • Edited by Phil49000 Friday, March 13, 2015 6:46 AM
    Friday, March 13, 2015 6:42 AM
  • Please confirm the following:

    1. After installing MDT 2013 and the ADK 8.1, you opened and updated your deployment share in the MDT Workbench - check the Upgrade the content of the deployment share (if required) checkbox - Important!

    2. You imported a Win7 x64 operating system (preferably slipstreamed - SP#) from source media via the MDT Workbench - Full set of source files - Recommended!

    3. If necessary, completely regenerate your boot images after opening/updating the deployment share.

    4. You created a new task sequence to deploy an x64 operating system - check the MDT 2013 Release Notes.docx under Known General Issues for more information.

    Also, check your logs to determine what file was not found after a sysprep was attempted.


    V/R, Darrick West - Senior Systems Engineer, ConfigMgr: OSD





    Friday, March 13, 2015 4:00 PM
  • Hello Darrick,

    Pleased that you didn't give up yet ! ;-)

    Regarding your questions :

    1 : check the Upgrade the content of the deployment share (if required) checkbox : sorry Darrick I didn't find this mysterious option !
    When you right click the "MDT Deployment Share" object in the MDT tree you can only select "Update", "Close", Refresh", etc, but no "Upgrade" choice !
    I tried somehwere else but didn't find it !
    Maybe I got it wrong and you talk about a reference to the section of a document ?

    2. You imported a Win7 x64 operating system Full set of source files - Recommended : this is exactly what i did, I simply used the wizard and it recovered the WIM file and indeed, selected the "Full set of source files" option.
    No slipstreaming necessary as this is Microsoft Software Assurance Windows 7 SP1 Enterprise 64 bits !
    This is precisely the "SW_DVD5_SA_Win_Ent_7w_SP1_64BIT_French_-2_MLF_X17-58912" version.
    This operating sytem was imported prior to the upgrade with ADK 8.1, does it matter ?

    3. If necessary, completely regenerate your boot images after opening/updating the deployment share : as mentioned in an earlier post, this is what I did right after the upgrade !
    The boot image was imported in WDS, I kept the previous ones and simply disabled them and enabled this new one.
    I then tried to reenable the previous one (the one I successfully use with 32 bits capture and deployments) but with the same negative result.

    4. You created a new task sequence to deploy an x64 operating system : no the task sequence had been created before the upgrade, therefore Ive just deleted it (fully), and did it all over again.
    I'll let you know if it made a difference as i'm currently reinstalling Windows 7 64 bits on my good old OptiPlex 745 !

    5. Check the MDT 2013 Release Notes.docx under Known  General Issues for more information : I carefully read the document, most of the points are related to different issues and/or I'm not concerned by the scenario as this is Windows 8/8.1 related!

    Kind regards,

    Philippe.



    • Edited by Phil49000 Monday, March 16, 2015 7:37 AM
    Monday, March 16, 2015 7:35 AM
  • Hi again,

    Ok, answering to my own previous post :

    - Re-creating the capture task sequence and trying to capture failed again
    - Reimporting the operating system and trying to capture also failed

    Kind regards,

    Philippe.

    • Proposed as answer by Brunofr Monday, March 16, 2015 3:29 PM
    • Unproposed as answer by Brunofr Monday, March 16, 2015 3:29 PM
    Monday, March 16, 2015 10:26 AM
  • Hello Philippe,

    Try to add the drivers with dism manually

    dism /image:"D:\mount" /add-driver /driver:"D:\DeploymentShare4\temp\vmxnet3\vmxnet3ndis6.inf"

    above is an example of adding vmware network driver

    dism /unmount-wim /mountdir:"d:\Mount" /commit

    validate modification

    And the same for you PE

    dism /mount-wim /WimFile:D:\RemoteInstall\Boot\x86\Images\LiteTouchPE_x86-(8).wim /index:1 /mountdir:"d:\mount"

    Check the information PE in D:\mount\Deploy\Scripts\bootstrap.ini

    DeployRoot=\\yourserver\yourDeploymentShare$

    Kind regards,

    Bruno

    Monday, March 16, 2015 3:57 PM
  • Hello Bruno,

    Do you believe this would make a difference ?

    Just for your information, the computer I'm currently using for my tests is a Dell OptiPlex 745.

    This is not by chance, this one doesn't need any additional driver, all of them are provided by Windows 7.

    Regarding the bootstrap.ini, yes, indeed, here's the content :

    [Settings]
    Priority=Default

    [Default]

    DeployRoot=\\SERVER\DeploymentShare$

    SkipBDDWelcome=YES

    InputLocale=040c:0000040c
    KeyboardLocale=040c:0000040c

    UserDomain=DOMAIN
    UserID=User
    UserPassword=password

    TimeZone=105
    TimeZoneName=Romance Standard Time

    Kind regards,

    Philippe.

    Tuesday, March 17, 2015 10:07 AM
  • Are you sure this network driver is allready on your bootpe wim because install.wim and litetouchpe.wim is not the same thing.
    You are capturing an image or trying do install a new one and it's from a custom file wim or from a full set (operating system)?
    On your task sequence have you untick continue on error in options menu of your line sysrep?

    add this lines on rules menu to actvivate the monitoring after go to monitoring options and check the step number of progress may be help you to understand where is the error.

    Activate the service Microsoft Deployment toolkit monitor service.

    EventService=http://yourserver:9800
    SLShareDynamicLogging=\\yourserver\DeploymentShare$\Logs\%OSDcomputername%


    Kind regards,

    Bruno

    • Edited by Brunofr Tuesday, March 17, 2015 1:43 PM
    Tuesday, March 17, 2015 12:55 PM
  • Hello Bruno,     

    Are you sure this network driver is allready on your bootpe wim because install.wim and litetouchpe.wim is not the same thing.

    I was using DISM GUI yesterday to check out this point, however I keep using some errors, and I'm currently stuck debugging them...
    It's been a year a two since the last time I successfully used it to inject a network driver to replace a faulty one for a specific OptiPlex model.
    Furthermore, using the command lines for DISM on the server had a curious effect : the memory usage is skyrocketing to 16 GB (max memory available on this server) and process is stuck at almost 100% !
    No explanation yet...

    You are capturing an image or trying do install a new one and it's from a custom file wim or from a full set (operating system)?

    As previously stated, I'm installing "from scratch" the computer with the same content (DVD) used to generate the Install.wim on the MDT tree, make sure to delete the partitions of the previous attempt, removing the installation account, leaving only local administrator once it's enabled and with no password, I then delete the account profile used to start the installation process, then I start the capture process from the session through the network access to my MDT server executing the LiteTouch.vbs.script.
    I'm authenticated with the adminstrator account used to work on the MDT server.
    There's just one partition.
    Therefore this is a "full set".
    That's it for the capture process.

    On your task sequence have you untick continue on error in options menu of your line sysrep?

    No.
    As the problem seems to take place atthe "Gather local only" and/or "Create Wim" steps, should I enable this option on both of them ?

    add this lines on rules menu to actvivate the monitoring after go to monitoring options and check the step number of progress may be help you to understand where is the error.

    Which lines, and where ?
    Do you mean your following instructions hereunder ?

    Activate the service Microsoft Deployment toolkit monitor service.

    It's been activated since we first installed MDT 3 or 4 years ago !

    EventService=http://yourserver:9800

    I've tested the URL and it works.
    By the way, this is not the full URL, at first I thought it was down but you must type this : http://localhost:9800/MDTMonitorEvent

    EDIT [09h30] : oops, I just realized you meant it was a command line to be added to the custom settings.ini !
    It's just been added to my file, I'm restarting a capture process...

    SLShareDynamicLogging=\\yourserver\DeploymentShare$\Logs\%OSDcomputername%

    You mean adding this line to my custom settings.ini !?

    Darren suggested me to do that in one of the earlier posts.
    Thanks to this line I now have at least one log (BDD.log), but as its stops (successfully) at the end of the Sysprep, it doesn't help that much...

    Kind regards

    Philippe.



    • Edited by Phil49000 Wednesday, March 18, 2015 8:34 AM
    Wednesday, March 18, 2015 7:22 AM
  • Use trace SMStrace32.exe to inspect every log file and look for the red line error on each log file.

    Each MDT script automatically creates log files when running. The names of these log files match the name of the script—for example, ZTIGather.wsf creates a log file named ZTIGather.log. Each script also updates a common master log file (BDD.log) that aggregates the contents of the log files that MDT scripts create. MDT log files reside in C:\MININT\SMSOSD\OSDLOGS during the deployment process. Depending on the type of deployment being conducted, the log files are moved at the completion of the deployment to either %WINDIR%\SMSOSD or %WINDIR%\TEMP\SMSOSD. For Lite Touch Installation (LTI) deployments, the logs start in C:\MININT\SMSOSD\OSDLogs. They end up in %WINDIR%\TEMP\DeploymentLogs when the task sequence processing is complete.

    MDT creates the following log files:
    • BDD.log. This is the aggregated MDT log file that is copied to a network location at the end of the deployment if you specify the SLShare property in the Customsettings.ini file.


    • LiteTouch.log. This file is created during LTI deployments. It resides in %WINDIR%\TEMP\DeploymentLogs unless you specify the /debug:true option.


    • Scriptname.log. This file is created by each MDT script. Scriptname represents the name of the script in question.


    • SMSTS.log. This file is created by the Task Sequencer and describes all Task Sequencer transactions. Depending on the deployment scenario, it may reside in %TEMP%, %WINDIR%\System32\ccm\logs, or C:\_SMSTaskSequence, or C:\SMSTSLog.


    • Wizard.log. The deployment wizards create and update this file.


    • WPEinit.log. This file is created during the Windows PE initialization process and is useful for troubleshooting errors encountered while starting Windows PE.


    • DeploymentWorkbench_id.log. This log file is created in the %temp% folder when you specify a /debug when starting the Deployment Workbench.

    If you are in dos mode use edit to open it.

    Kind regards

    Bruno

    • Edited by Brunofr Wednesday, March 18, 2015 9:22 AM
    Wednesday, March 18, 2015 9:21 AM
  • Hello Bruno, 

    Did what you asked in your last post.

    Tried for the umpteenth time to capture, same result, same log, nothing more, nothing less...

    This is hopeless... :-(

    How am I suppose to exploit the "EventService=http://yourserver:9800" ?

    Is it supposed to log more things or somewhere else ?

    For the moment I will try to solve the porblem with DISM GUI and try to inject the network driver if it's not present in WinPE...

    Kind regards,

    Philippe.

    Wednesday, March 18, 2015 10:27 AM
  • Hi Philippe,

    Have you seen my last post with all log files path?

    For DISM issue mount with DISM command below the PE.wim you will see the path on the details menu of your bootpe image on WDS.
    something like:
    dism /mount-wim /WimFile:D:\RemoteInstall\Boot\x86\Images\LiteTouchPE_x86.wim /index:1 /mountdir:"d:\mount"

    dism /image:"D:\mount" /add-driver /driver:"D:\DRIVERS-SOURCES\yourdriver.inf"

    For the eventservice line it's inserted when you have the monitoring service activated it's used to monitor the machine when they are in deployment mode with rdp for example (lazy man).




    You can see the step of your task sequence in real time, if you go to details in monitoring folder on a machine.

    PS: Philippe j'aurais surement été plus compréhensible en français  :)

    Kind Regards,

    Bruno

    Wednesday, March 18, 2015 1:23 PM
  • Hello,

    Yes, I was pretty sure that Brunofr was most likely French ! ;-)

    I keep posting in English as some other people may be interested if we ever find what's going awry ! ;-)

    To get back to the issue, I'm used to take a look when broacasting an image but didn't think about doing it for the capture !

    You're right, I got the last attempt still not stopped by the way...

    Strangely enough it seems that sysprep didn't finished successfully contrary to what the behaviour would let us think !

    To me the fact that the PC was rebooting after showing up the sysprep window with no error message, and loading the WinPE file after the reboot, meant that the issue was located at one of the steps mentioned in my previous post !
    It now remains to be seen what this 16th step correspond to in order to understand what is failing !

    Any idea ?

    I'm gonna execute the DISM command again to understand what's the problem with it !

    Kind regards,

    Philippe




    • Edited by Phil49000 Wednesday, March 18, 2015 1:54 PM
    Wednesday, March 18, 2015 1:52 PM
  • Philippe,

    To answer your question concerning the step, each step for each line in your task sequence.
    Try to add a command line and you'll see 24 steps, check the 16th line of your task sequence.

    As i can see it's, execute sysprep line, then it means it's a sysprep problem check your unatend maybe.
    Perhaps it would be better to create a new one minimal with wsim to be sure is it a 64 bits unatend file?

    take a look on it.
    http://www.fogproject.org/wiki/index.php?title=Create_a_windows_7_image_for_many_different_hardware

    Kind regards,

    Bruno


    • Edited by Brunofr Wednesday, March 18, 2015 4:27 PM
    Wednesday, March 18, 2015 3:50 PM
  • Bruno,

    Well, I'm not as learned as you're with MDT, where the hell can I find those 23 steps ! ;-)

    I suppose you talk about the capture task ts and unattend.xml files ?

    If I take a look at the first one, indeed, counting the steps even though they're not clearly identified, I have 16 of them, but not a 17th, 18th and so on !

    What are those extra expected steps ?

    Here's what I've got at this supposedly "16th step" which is the "Create WIM", just after this one, we can see another step called "BDD InstallOS" :

    <step name="Create WIM" disable="false" continueOnError="true" successCodeList="0 3010" description="" startIn="">
            <action>cscript.exe "%SCRIPTROOT%\ZTIBackup.wsf"</action>
            <defaultVarList>
              <variable name="RunAsUser" property="RunAsUser">false</variable>
              <variable name="SMSTSRunCommandLineUserName" property="SMSTSRunCommandLineUserName"></variable>
              <variable name="SMSTSRunCommandLineUserPassword" property="SMSTSRunCommandLineUserPassword"></variable>
              <variable name="LoadProfile" property="LoadProfile">false</variable>
            </defaultVarList>
          </step>
        </group>
      </group>
      <step type="BDD_InstallOS" name="MDT DO NOT ENABLE OR DELETE" description="This is used only to get the Unattend files" disable="true" continueOnError="false" runIn="WinPEandFullOS" successCodeList="0 3010">
        <defaultVarList>

    All of this is generated by the wizard when creating this capture task, I didn't change anything !

    Kind regards,

    Philippe



    • Edited by Phil49000 Wednesday, March 18, 2015 4:11 PM
    Wednesday, March 18, 2015 3:57 PM
  • Hi Philippe,

    Another way to inspect the logs in your case is Booting with a winpe USB or PXE, use diskpart to list the partition drive letters, and go to the task sequence log folder on the drive.

    Below in yellow the problem line.

    Still focus on the sysprep issue, and the unatend check the link i've send you yesterday.

    Have you validate your unatend file in wsim?
    To perform that go to your workbench>DeploymentShare>TaskSequence> and rigth clic on your TS ID and click on properties go to OS Info and click on edit unatend xml it will open wsim and on the WSIM go to tools and click on Validate answer file to  check if you got an error message report it here.

    And just to be sure what is the kind of task sequence you're using?

    Here is some links they can be usefull to know how is he copied and where to find him on the machine after the task sequence.

    http://www.revuedugeek.com/post/2010/05/16/Processus-SysPrep-and-Capture-dans-MDT-2010-Unattendxml

    Kind regards,

    Bruno



    • Edited by Brunofr Thursday, March 19, 2015 12:05 PM
    Thursday, March 19, 2015 10:01 AM
  • Hello Bruno,

    Sorry, I was busy on another project !

    I've just read both your answers.

    I'll take a look to your other links and suggestions and carry them out ASAP !

    Regarding the Unattend.xml file, I checked it out and the answer is : "No warning and no error".

    As for the type of task sequence, I used "Sysprep and capture" of course ! ;-)

    Kind regards

    Philippe.

    Thursday, March 19, 2015 3:55 PM
  • Hi Philippe,

    Try to disable the entire step sysprep on the TS and if it's working without this step, launch the sysprep manualy on the local machine (the machine you want to capture), remenber after the sysprep step select the line oobe generalize with only shutdown and start the machine from your pxe or media (cd, dvd, usb) and launch your DP TS capture without the sysprep.

    It's not the final solution to do it automatically but this one can isolate the issue and and allow you to finalize the capture.

    FYI:the sysprep log are stored on C:\Windows\system32\sysprep\Panther

    Have a nice week-end

    Bruno :)


    • Proposed as answer by Ty GlanderModerator Wednesday, April 1, 2015 6:45 PM
    • Edited by Brunofr Thursday, September 17, 2015 3:02 PM
    Friday, March 20, 2015 3:45 PM