OS Deployment v3.0

system · December 7, 2012, 6:17pm

(imported topic written by SystemAdmin)

Has anyone started working with the OS Deployment v3.0 yet? We previously were using TPMfOSD for imaging due to the bare metal imaging capabilities and are starting to look at using the new OS Deployment and Bare Metal Imaging site for image deployment.

I am just wondering if others are able to successfully deploy an image or if I am looking at some sort of issue with our image/deployment. So far we have been unsuccessful in deploying an image to any machine that already exists (have not tried bare metal until I can at least deploy 1 image successfully). We uploaded an existing WIM file to use as the image to deploy and when we deploy the job it reports that it is successful in the first 8 steps of the Part 1 deployment job. During the Initiate Re-image Action job the job fails when it tries to run the last line “waithidden startLiteTouch.bat”. The Exit Code on the job is 2. Unfortunately it does not tell us what part of the startLiteTouch.bat file fails.

I am not sure if it is related but when installing the latest version of TPMfOSD on a new server (Windows 2008R2) the Deploy OS Deployment Server job failed during the Perform Post Install Tasks at the last line:

continue if {(value “SyncTimePE” of key “HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\OSDControl” of registry as integer)|0 >= 1353969165040}

I eneded up adding this value manually on the server as it did not exist, however the other value “SyncTimeManifest” did exist.

Any ideas?

jhonda · December 7, 2012, 8:25pm

(imported comment written by JasonHonda)

Hi,

Sorry to hear you’re having issues. Looks like a couple of things going wrong here, so we’ll figure it out.

First note to start off with is that I’m trying to get a DeveloperWorks wiki page up and going for OSD in order to further elaborate on a lot of things in the User’s guide and improve troubleshooting and other help so once that’s up, that should be a good place to look for information.

It failing on the “waithidden startLiteTouch.bat” line is expected. You’ll notice the overall Multiple Action Group succeeded. This is due to the fact that the batch file shuts down the TEM client and so it is unable to verify the command ran successfully. This is by design so that we can turn the TEM client off in order to properly preserve it’s state.

The process of LiteTouch and MDT to actually do the re-image should have started on the endpoint. Not sure if you are doing this, but looking on the endpoint at the time should have shown dialogs showing progress of this portion of the re-image, if errors, possibly showing those errors. We start to get into a complex troubleshooting area depending on where the failure happened. Did it happen while running through scripts in the old OS, did it try and restart into WinPE and fail, did it fail in WinPE, etc. More information and we can help here obviously.

The second issue you mentioned regarding setting up the TPMfOSD server would be unrelated as that would be for Bare Metal imaging through PXE booting. We’re failing on purpose on this line as it failed to setup and import critical WinPE files. User’s guide has some information here about where to look for logs, but like I said, I should have more information up on a wiki page soon. Log you’ll want to look at on the endpoint would be “C:\Program Files\Common Files\IBM Tivoli\tempimportwpe.log”

Ignoring this failure will lead to issues where we think the server is up to date but is missing the critical WinPE files and bare metal images will fail.

system · December 10, 2012, 8:28pm

(imported comment written by SystemAdmin)

So my previous reimage attempts I was using a machine in my lab so I never really saw what was going on at the machine, just that once the job failed that the computer was back at the Ctrl+Alt+Del screen.

This morning I attempted to reimage a machine again but this time I set it up at my desk. The machine was at the Ctrl+Alt+Del screen when I started the imaging process it took about 40 minutes to go through the first 8 steps of the Part 1 phase. During the Initiate Re-Image Action nothing really changes on the computer before the job fails, the computer never reboots or attempts to boot into PXE at any point.

After that failed I logged into the machine as a local user account in case there is anything that should show on the local machine during the reimage process. This time I saw the messages that imaging is taking place but when it came time to the Initiate Re-Image Action the same thing happened, never rebooted.

So it appears the issue is actually when it is attempting to kick off the LiteTouch and MDT, so I am starting to think the issue could be with the MDT Bundle that I uploaded? When I uploaded the MDT bundle (version 3.0.54) I set it up for just Windows 7 SP1 32 and 64 bit and I am getting no error messages on the health check or the MDT Bundle dashboard. If this appears to be the issue any idea on what I might have missed during the creating of the MDT bundle that would cause this issue? I can create and upload a new one but I would like to know what i am missing so I do not do the same thing again.

thanks for any help or insight you can provide.

jhonda · December 10, 2012, 11:59pm

(imported comment written by JasonHonda)

Sounds like everything is going correctly from what I can tell. Unless you have reason to suspect that the MDT bundle did not create properly or you edited, I would suspect that to not be the issue.

What should happen is once the re-image Multiple Action Group completes, it will run startLiteTouch.bat which in turn runs liteTouch.vbs which really starts the process. Can’t quite tell from your description whether you see the LiteTouch dialog that states the progress or if it doesn’t even pop that up. If not, I would question and check if LiteTouch.vbs is in place on the endpoint in C:\Deploy\Scripts. If LiteTouch did start and fail, C:\Deploy should be cleaned up. In that case logs we’re trying to figure out what the error in MDT or LiteTouch was. Logs might be found c:\minint\ or c:\windows\temp\ and might have some more information.

system · December 11, 2012, 5:40pm

(imported comment written by SystemAdmin)

I did not see any messages from LiteTouch on the endpoint. Based on what you are saying it seems like the LiteTouch.vbs file is not properly ending up on the client machine.

I look on the client machine and there is a C:\Deploy folder but the only thing in the folder is a Tools\x86 directory and the application BDDRun and the extension Microsoft.BDD.Utility.dll.

The folder c:\minint\ does exist and contains the SMSOSD\OSDLOGS directory. The 3 log files appear to contain a few different error messages which I am listing below. The BDD.log looks like a combination of the other two logs.

LiteYouch.log

<![LOG

ZTI ERROR - Non-zero return code by LiteTouch, rc = -2147467259 0x80004005]LOG

!><time=“11:12:55.000+000” date=“12-10-2012” component=“LiteTouch” context="" type=“3” thread="" file=“LiteTouch”>

LTICleanup.log

<![LOG

SUCCESS: True: Delete Folder: C:\MININT]LOG

!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“1” thread="" file=“LTICleanup”>

<![LOG

Remove Folder: C:\Deploy]LOG

!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“1” thread="" file=“LTICleanup”>

<![LOG

Remove Folder: C:\Deploy\Tools]LOG

!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“1” thread="" file=“LTICleanup”>

<![LOG

Remove Folder: C:\Deploy\Tools\x86]LOG

!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“1” thread="" file=“LTICleanup”>

<![LOG!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“1” thread="" file=“LTICleanup”>

<![LOG!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“2” thread="" file=“LTICleanup”>

<![LOG!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“1” thread="" file=“LTICleanup”>

<![LOG!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“2” thread="" file=“LTICleanup”>

<![LOG

FAILURE (Err): 70: Delete Folder: C:\Deploy\Tools\x86 - Permission denied]LOG

!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“2” thread="" file=“LTICleanup”>

<![LOG

FAILURE (Err): 70: Delete Folder: C:\Deploy\Tools - Permission denied]LOG

!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“2” thread="" file=“LTICleanup”>

<![LOG

FAILURE (Err): 70: Delete Folder: C:\Deploy - Permission denied]LOG

!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“2” thread="" file=“LTICleanup”>

BDD.log

<![LOG

SUCCESS: True: Delete Folder: C:\MININT]LOG

!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“1” thread="" file=“LTICleanup”>

<![LOG

Remove Folder: C:\Deploy]LOG

!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“1” thread="" file=“LTICleanup”>

<![LOG

Remove Folder: C:\Deploy\Tools]LOG

!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“1” thread="" file=“LTICleanup”>

<![LOG

Remove Folder: C:\Deploy\Tools\x86]LOG

!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“1” thread="" file=“LTICleanup”>

<![LOG!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“1” thread="" file=“LTICleanup”>

<![LOG!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“2” thread="" file=“LTICleanup”>

<![LOG!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“1” thread="" file=“LTICleanup”>

<![LOG!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“2” thread="" file=“LTICleanup”>

<![LOG

FAILURE (Err): 70: Delete Folder: C:\Deploy\Tools\x86 - Permission denied]LOG

!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“2” thread="" file=“LTICleanup”>

<![LOG

FAILURE (Err): 70: Delete Folder: C:\Deploy\Tools - Permission denied]LOG

!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“2” thread="" file=“LTICleanup”>

<![LOG

FAILURE (Err): 70: Delete Folder: C:\Deploy - Permission denied]LOG

!><time=“11:12:55.000+000” date=“12-10-2012” component=“LTICleanup” context="" type=“2” thread="" file=“LTICleanup”>

<![LOG

ZTI ERROR - Non-zero return code by LiteTouch, rc = -2147467259 0x80004005]LOG

!><time=“11:12:55.000+000” date=“12-10-2012” component=“LiteTouch” context="" type=“3” thread="" file=“LiteTouch”>

jhonda · December 12, 2012, 1:17am

(imported comment written by JasonHonda)

Ok, based on the fact that c:\deploy looks like it does is indicative that LiteTouch did run, but an error occurred and it performed cleanup. As part of the cleanup process the logs should have been moved to c:\windows\temp\deploymentlogs and you should see much more useful logs with some sort of error prior to cleanup. The logs you’re seeing are just the logs related to cleanup.

system · December 12, 2012, 9:46pm

(imported comment written by SystemAdmin)

I was able to find two logs (although they appear the same) within the C:\windows\temp folder, both are named smsts.log and one is on the root of the temp folder and the other is in a smsts.log folder. These log files are rather large so I had a hard time trying to parse out what the exact error message is. Below is what I think is the issue and attached is the full log file.

!--------------------------------------------------------------------------------------------!]LOG

!><time=“11:40:29.884+360” date=“12-12-2012” component=“TSManager” context="" type=“1” thread=“1584” file=“instruction.cxx:3010”>

<![LOG[Failed to run the action: Apply Windows PE.

The network path was not found. (Error: 00000035; Source: Windows)]LOG]!><time=“11:40:29.884+360” date=“12-12-2012” component=“TSManager” context="" type=“3” thread=“1584” file=“instruction.cxx:3101”>

<![LOG

http://Sending status message . . .]LOG

!><time=“11:40:29.884+360” date=“12-12-2012” component=“TSManager” context="" type=“1” thread=“1584” file=“utility.cxx:292”>

<![LOG

http://Executing in non SMS standalone mode. Ignoring send a task execution status message request]LOG

!><time=“11:40:29.884+360” date=“12-12-2012” component=“TSManager” context="" type=“1” thread=“1584” file=“utility.cxx:302”>

<![LOG

Set a global environment variable _SMSTSLastActionRetCode=53]LOG

!><time=“11:40:29.884+360” date=“12-12-2012” component=“TSManager” context="" type=“0” thread=“1584” file=“executionenv.cxx:668”>

<![LOG

Set a global environment variable _SMSTSLastActionSucceeded=false]LOG

!><time=“11:40:29.884+360” date=“12-12-2012” component=“TSManager” context="" type=“0” thread=“1584” file=“executionenv.cxx:668”>

<![LOG

Clear local default environment]LOG

!><time=“11:40:29.884+360” date=“12-12-2012” component=“TSManager” context="" type=“0” thread=“1584” file=“executionenv.cxx:807”>

<![LOG

Let the parent group (Refresh only) decides whether to continue execution]LOG

!><time=“11:40:29.915+360” date=“12-12-2012” component=“TSManager” context="" type=“0” thread=“1584” file=“instruction.cxx:3210”>

<![LOG

Let the parent group (State Capture) decide whether to continue execution]LOG

!><time=“11:40:29.915+360” date=“12-12-2012” component=“TSManager” context="" type=“0” thread=“1584” file=“instruction.cxx:2461”>

<![LOG[The execution of the group (State Capture) has failed and the execution has been aborted. An action failed.

Operation aborted (Error: 80004004; Source: Windows)]LOG]!><time=“11:40:29.915+360” date=“12-12-2012” component=“TSManager” context="" type=“3” thread=“1584” file=“instruction.cxx:2424”>

<![LOG[Failed to run the last action: Apply Windows PE. Execution of task sequence failed.

The network path was not found. (Error: 00000035; Source: Windows)]LOG]!><time=“11:40:29.915+360” date=“12-12-2012” component=“TSManager” context="" type=“3” thread=“1584” file=“engine.cxx:214”>

<![LOG

http://Sending status message . . .]LOG

!><time=“11:40:29.915+360” date=“12-12-2012” component=“TSManager” context="" type=“1” thread=“1584” file=“utility.cxx:292”>

<![LOG

http://Executing in non SMS standalone mode. Ignoring send a task execution status message request]LOG

!><time=“11:40:29.915+360” date=“12-12-2012” component=“TSManager” context="" type=“1” thread=“1584” file=“utility.cxx:302”>

<![LOG

Execution::enExecutionFail != m_eExecutionResult, HRESULT=80004005 (e:\nts_sms_fre\sms\client\tasksequence\tsmanager\tsmanager.cpp,767)]LOG

!><time=“11:40:29.931+360” date=“12-12-2012” component=“TSManager” context="" type=“0” thread=“1584” file=“tsmanager.cpp:767”>

<![LOG

Task Sequence Engine failed! Code: enExecutionFail]LOG

!><time=“11:40:29.931+360” date=“12-12-2012” component=“TSManager” context="" type=“3” thread=“1584” file=“tsmanager.cpp:767”>

jhonda · December 12, 2012, 10:16pm

(imported comment written by JasonHonda)

From what I can tell, and I think you did determine quite appropriately where in that file failure happened. The line indicates it failed in the LTIApply.wsf script. If you look around in c:\windows\temp\deployment logs\ you should hopefully see some other logs, including ones matching each script ran. So there should be something like BDD.log and LTIApply.log. Might be in a couple other locations.

system · December 13, 2012, 5:19pm

(imported comment written by SystemAdmin)

So the log files were not located under c:\Windows\temp directory but instead they were found with the other BigFix logs (c:\Program Files\BigFix Enterprise\BES Client__BESData__Global\Logs\DeploymentLogs).

I started to scan through the BDD.log and think I found the first sign of error in the logs, based on this information and the information from the LTIApply.log file it seems like the job is failing because the LTIApply file cannot be found (bootmgr or TsmBootstrap.exe?).

BDD.log - first sign of failure in the logs

<![LOG

------ Applying bootable Windows PE image ------]LOG

!><time=“11:40:29.000+000” date=“12-12-2012” component=“LTIApply” context="" type=“1” thread="" file=“LTIApply”>

<![LOG

LTI applying Windows PE]LOG

!><time=“11:40:29.000+000” date=“12-12-2012” component=“LTIApply” context="" type=“1” thread="" file=“LTIApply”>

<![LOG

http://Will boot into Windows PE architecture x86 to match OS being deployed.]LOG

!><time=“11:40:29.000+000” date=“12-12-2012” component=“LTIApply” context="" type=“1” thread="" file=“LTIApply”>

<![LOG!><time=“11:40:29.000+000” date=“12-12-2012” component=“LTIApply” context="" type=“1” thread="" file=“LTIApply”>

<![LOG

Copying C:\Deploy\Boot\x86\bootmgr to C:\bootmgr]LOG

!><time=“11:40:29.000+000” date=“12-12-2012” component=“LTIApply” context="" type=“1” thread="" file=“LTIApply”>

<![LOG

ZTI ERROR - Unhandled error returned by LTIApply: File not found (53)]LOG

!><time=“11:40:29.000+000” date=“12-12-2012” component=“LTIApply” context="" type=“3” thread="" file=“LTIApply”>

<![LOG

Litetouch deployment failed, Return Code = -2147467259 0x80004005]LOG

!><time=“11:41:33.000+000” date=“12-12-2012” component=“LiteTouch” context="" type=“3” thread="" file=“LiteTouch”>

<![LOG

http://For more information, consult the task sequencer log …\SMSTS.LOG.]LOG

!><time=“11:41:33.000+000” date=“12-12-2012” component=“LiteTouch” context="" type=“1” thread="" file=“LiteTouch”>

<![LOG

Property RetVal is now = -2147467259]LOG

!><time=“11:41:33.000+000” date=“12-12-2012” component=“LiteTouch” context="" type=“1” thread="" file=“LiteTouch”>

<![LOG

CleanStartItems Complete]LOG

!><time=“11:41:33.000+000” date=“12-12-2012” component=“LiteTouch” context="" type=“1” thread="" file=“LiteTouch”>

<![LOG

http://Unable to copy log to the network as no SLShare value was specified.]LOG

!><time=“11:41:33.000+000” date=“12-12-2012” component=“LiteTouch” context="" type=“1” thread="" file=“LiteTouch”>

<![LOG

CleanStartItems Complete]LOG

!><time=“11:41:33.000+000” date=“12-12-2012” component=“LiteTouch” context="" type=“1” thread="" file=“LiteTouch”>

<![LOG

http://Unregistering TSCore.dll.]LOG

!><time=“11:41:33.000+000” date=“12-12-2012” component=“LiteTouch” context="" type=“1” thread="" file=“LiteTouch”>

<![LOG!><time=“11:41:33.000+000” date=“12-12-2012” component=“LiteTouch” context="" type=“1” thread="" file=“LiteTouch”>

LTIApply.log - full log listed below

<![LOG

Property PE is now = ]LOG

!><time=“11:40:29.000+000” date=“12-12-2012” component=“LTIApply” context="" type=“1” thread="" file=“LTIApply”>

<![LOG

Microsoft Deployment Toolkit version: 5.1.1642.01]LOG

!><time=“11:40:29.000+000” date=“12-12-2012” component=“LTIApply” context="" type=“1” thread="" file=“LTIApply”>

<![LOG

The task sequencer log is located at C:\windows\TEMP\SMSTSLog\SMSTS.LOG. For task sequence failures, please consult this log.]LOG

!><time=“11:40:29.000+000” date=“12-12-2012” component=“LTIApply” context="" type=“1” thread="" file=“LTIApply”>

<![LOG

SUCCESS: 0: Create object: Set oScriptClass = New LTIApply]LOG

!><time=“11:40:29.000+000” date=“12-12-2012” component=“LTIApply” context="" type=“1” thread="" file=“LTIApply”>

<![LOG

------ Applying bootable Windows PE image ------]LOG

!><time=“11:40:29.000+000” date=“12-12-2012” component=“LTIApply” context="" type=“1” thread="" file=“LTIApply”>

<![LOG

LTI applying Windows PE]LOG

!><time=“11:40:29.000+000” date=“12-12-2012” component=“LTIApply” context="" type=“1” thread="" file=“LTIApply”>

<![LOG

http://Will boot into Windows PE architecture x86 to match OS being deployed.]LOG

!><time=“11:40:29.000+000” date=“12-12-2012” component=“LTIApply” context="" type=“1” thread="" file=“LTIApply”>

<![LOG!><time=“11:40:29.000+000” date=“12-12-2012” component=“LTIApply” context="" type=“1” thread="" file=“LTIApply”>

<![LOG

Copying C:\Deploy\Boot\x86\bootmgr to C:\bootmgr]LOG

!><time=“11:40:29.000+000” date=“12-12-2012” component=“LTIApply” context="" type=“1” thread="" file=“LTIApply”>

<![LOG

ZTI ERROR - Unhandled error returned by LTIApply: File not found (53)]LOG

!><time=“11:40:29.000+000” date=“12-12-2012” component=“LTIApply” context="" type=“3” thread="" file=“LTIApply”>

LiteTouch.log - sign of failure with similar negative error code

<![LOG

LTI beginning deployment]LOG

!><time=“11:40:17.000+000” date=“12-12-2012” component=“LiteTouch” context="" type=“1” thread="" file=“LiteTouch”>

<![LOG!><time=“11:40:17.000+000” date=“12-12-2012” component=“LiteTouch” context="" type=“1” thread="" file=“LiteTouch”>

<![LOG

Litetouch deployment failed, Return Code = -2147467259 0x80004005]LOG

!><time=“11:41:33.000+000” date=“12-12-2012” component=“LiteTouch” context="" type=“3” thread="" file=“LiteTouch”>

<![LOG

http://For more information, consult the task sequencer log …\SMSTS.LOG.]LOG

!><time=“11:41:33.000+000” date=“12-12-2012” component=“LiteTouch” context="" type=“1” thread="" file=“LiteTouch”>

<![LOG

Property RetVal is now = -2147467259]LOG

!><time=“11:41:33.000+000” date=“12-12-2012” component=“LiteTouch” context="" type=“1” thread="" file=“LiteTouch”>

<![LOG

CleanStartItems Complete]LOG

!><time=“11:41:33.000+000” date=“12-12-2012” component=“LiteTouch” context="" type=“1” thread="" file=“LiteTouch”>

<![LOG

http://Unable to copy log to the network as no SLShare value was specified.]LOG

!><time=“11:41:33.000+000” date=“12-12-2012” component=“LiteTouch” context="" type=“1” thread="" file=“LiteTouch”>

<![LOG

CleanStartItems Complete]LOG

!><time=“11:41:33.000+000” date=“12-12-2012” component=“LiteTouch” context="" type=“1” thread="" file=“LiteTouch”>

jhonda · December 18, 2012, 1:07am

(imported comment written by JasonHonda)

Ok, that’s pretty interesting that it moved the logs to that directory. It does that when the second part of the re-image runs, which should only happen after success and it comes back online. Either way, it does appear to be the issue with the files not being there as you guessed. This obviously should not have happened. Maybe a error with the extraction process did not extract everything, or maybe the files never existed in the first place, or maybe an incomplete attempt earlier is messing things up.

Couple of things to look at would be wherever you may have the MDT bundle that you uploaded, if it’s still somewhere, I would take a look to see if the files in C:\BigFixOSD\Deploy\Boot\x86… exist as they should. If they do, this is quite odd then.

One thing you can do, is initiate a re-image action. First clear out and delete C:\Deploy. If you’re watching the re-image as it runs through the first Multiple Action Group, after about the third subaction, C:\Deploy will exist, at this point you can take a look inside to verify the files in the Boot folder are there as well. If you need more time to look, you can rename C:\Deploy\Scripts\LiteTouch.vbs to anything you want, and then you have all the time you need. Once done looking around, just run whatever you renamed the script to in order to continue the process, obviously making sure the action is done though.

system · December 18, 2012, 1:17am

(imported comment written by SystemAdmin)

Couple of things to look at would be wherever you may have the MDT bundle that you uploaded, if it’s still somewhere, I would take a look to see if the files in C:\BigFixOSD\Deploy\Boot\x86… exist as they should. If they do, this is quite odd then.

So when I look at the MDT Bundle that was uploaded there is C:\BigFixOSD\DeploymentShare and C:\BigFixOSD\MDTBundle.

Under the DeploymentShare directory are 12 folders including $OEM$, Applications, Boot, etc (however Boot is empty)

Under the MDTBundle\Content folder there are Boot,Deploy,EFI, +3 files. Deploy folder contains the same folders as the Deployment Share (listed above) and the sub folder Boot folder does contain the x86 and subfolders.

I will kick off another deployment in the morning where I can dedicate time to watch the installation and see if the c:\deploy creates and from there I will look for the LiteTouch.vbs and see what it is doing (or not doing).

system · December 28, 2012, 6:33pm

(imported comment written by SystemAdmin)

Jason,

I finally got around to watching the installation happen and I do believe I know what the issue is, however I am not sure how to correct the issue. So in my error logs I previously posted I have a line in there “Copying C:\Deploy\Boot\x86\bootmgr to C:\bootmgr” and this is where the first error messages occur. Following the steps you listed (delete the deploy folder and run the action again) I was able to see the full Deploy folder before further actions occured. When I look at the “C:\Deploy\Boot\x86” directory I only have folders for Boot and EFI, there is nothing for bootmgr. Under the x64 directory I see the same Boot and EFI folders but there is also a bootmgr.efi file.

The MDT Bundle that I created and uploaded does appear to have the bootmgr file in the directory on the server C:\BigFixOSD\MDTBundle\Content\Deploy\Boot\x86

All my previous attempts have been Win7 32 bit to Win7 32 bit. So I reimaged a machine as XP and started the process again. I took a look at the “C:\Deploy\Boot\x86” directory I still only have folders for Boot and EFI, there is nothing for bootmgr. In the end the image did not complete and failed at the same point.

So would this mean that something happened with the MDTBundle upload and that file did not properly upload?

system · December 29, 2012, 12:01am

(imported comment written by SystemAdmin)

Hi,

Please attach new MDT logs (full logs instead of snippets) (should be at c:\windows\temp\DeploymentLogs). Also, check the timestamp and verify that the logs match up with the deployment time/time of failure.

Also, for future reference, the best tool to read the log files is Trace32.exe (downloadable here: http://www.microsoft.com/en-us/download/details.aspx?id=9257)

system · January 2, 2013, 7:00pm

(imported comment written by SystemAdmin)

Here is the whole DeploymentLogs folder. They were not located in the c:\windows\temp directory but in the c:\Program Files\BigFix Enterprise\BES Client__BESData__Global\Logs\DeploymentLogs folder.

I am going to try deploying again after disabling our AV solution in case something is getting deleted as its being copied over on the workstation, I dont see anything in the logs of files being deleted or quarunteed but I figure its worth trying.

system · January 7, 2013, 9:50pm

(imported comment written by SystemAdmin)

A couple of things come across to me as being strange:

Why your MDT logs end up in your TEM client log directory (this should only happen in MAG 2 - which presumably would not have run due to failure to even get into WinPE).
Why the bootmgr file(s) are missing…

Can you please post the contents of the file called BundleVersion.txt which lives under your Deploy folder that you would have uploaded? This will tell us whether you have, for example, the wrong version of WAIK installed.

Also, prior to running more tests, can you ensure that, on the machine being imaged, c:\Deploy does not exist.

system · January 8, 2013, 12:18am

(imported comment written by SystemAdmin)

The last time I attempted the OSD I did breifly see a LiteTouch status bar appear, it did not error out and the computer never rebooted at any point during the process.

Attached is the BundleVersion.txt file from the c:\bigfixOSD\MDTBundle\Content\Deploy directory (also copied below).

MDTBundleCreatorVersion=3.0.54

WAIKVersion=6.1.7600.0

MDTVersion=5.1.1642.1

RBAgentVersion=7.1.110.18517

Multiple times and with multiple OS’s (both XP and Win 7 32 bit) I have used a freshly imaged machine where c:\deploy does not exist. I am reimaging the machines with our existing imaging solution (Altiris) prior to attempting to reimage with OSD and this directory does not exist. In between attempts I am reimaging the machine to ensure that any files that are created/copied are recopied to the machine.

I imported the WIM file that we are using, should I attempt to upload a live sysprep’ed OS if you think it is an issue with the image itself?

system · January 8, 2013, 10:57pm

(imported comment written by SystemAdmin)

So reading what you wrote here:

All my previous attempts have been Win7 32 bit to Win7 32 bit. So I reimaged a machine as XP and started the process again. I took a look at the “C:\Deploy\Boot\x86” directory I still only have folders for Boot and EFI, there is nothing for bootmgr. In the end the image did not complete and failed at the same point.

I would say that you should re-create your MDT bundle and validate that you have this file in place before you try to upload it again. This is a critical file and should have been copied.

Make sure that you run the appropriate executable that matches the architecture of the system on which it is being run. Also, can you redirect std err and std out like this: MDTBundleCreator.exe > C:\out.out 2>&1

system · January 10, 2013, 12:50am

(imported comment written by SystemAdmin)

ran the following to create MDT Bundle on my workstation running Windows 7 64 bit. Building it using two media ISO’s (Win 7 32 bit and 64 bit)

c:\OSDSETUP\MDTBundleCreator-3.0.55\MDTBundleCreator-3.0.55>MDTBundleCreator64.exe > c:\out.out 2>&1

instructions says 30-60 minutes, mine to just over 20 minutes

Copied c:\BigFixOSD to the server. Prior to uploading I verified that the file C:\BigFixOSD\BigFixOSD\MDTBundle\Content\Deploy\Boot\x86\bootmgr exists also C:\BigFixOSD\BigFixOSD\MDTBundle\Content\Deploy\Boot\x64\bootmgr exists too (I did notice that the x64 also has a bootmgr.efi file where the x86 folder does not.)

I uploaded using the dashboard and pointed to the directory I just copied (C:\BigFixOSD\BigFixOSD\MDTBundle). The dashboard shows the MDT 3.0.55 and both Win 7 resources

I had to run a job to “Update WinPE Resources and Profiles on Bare Metal Servers” for the two servers that I currently have upgraded to 7.1.1.10 (185.17), the one server not being used for this testing was successful but the relay server being used in this test failed on the last line “continue if {(value “SyncTimePE” of key “HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\OSDControl” of registry as integer)|0 >= 1357679933066}”. This is the same regkey that I mentioned in the initial post of this thread.

So I attempted to reimage a fresh Win XP machine (no other reimage attempts) and it looks like the same thing happened. Within the c:\Deploy\Boot\x86 folder there does not appear to be the bootmgr file that is expected. I attempted to reimage again on a fresh Win XP machine after uninstalling the Sophos AV (in case thats deleting the file) and once again the same thing happened.

Attached is the out.out file from the MDT Bundle creation process.

below is the updated BundleVersion.txt

MDTBundleCreatorVersion=3.0.55

WAIKVersion=6.1.7600.0

MDTVersion=5.1.1642.1

RBAgentVersion=7.1.111.19017

system · January 10, 2013, 3:01am

(imported comment written by SystemAdmin)

That is very strange. Let’s try and figure out where its getting deleted…

Can you try to run ONLY the second sub-action of Multiple Action Group 1 (Download and Set up MDT Resource Files). You can do this simply by selecting it, and hitting Copy (one of the buttons in the console just above the Summary/Computers/Target tabs.

Take this action on any computer that does

not

already have the deploy folder in place. Does the bootmgr file exist?

If so, then we can try something a little more complicated to try and figure out who’s eating it.

system · January 10, 2013, 6:41pm

(imported comment written by SystemAdmin)

I ran the “Download and Setup MDT Resource Files” job on 4 machines that have previously not been used for Imaging (two xp and two Win7) and all 4 of them do not have the bootmgr file in the C:\Deploy\Boot\x86 (or x64) directory.

Is it possible that AV could have stripped the files out during the upload from the c:/BigFixOSD folder? I would think if AV is stripping it out that it would have removed it from the c:/BigFixOSD folder on the main server in the first place.