Change Deployment Share Path on Capture VM

We recently moved all deployment files and MDT shares to a new file share with a new path. Is there a way I can change this in my capture VM? By that I mean when I click the Resume button to capture an image it fails to connect with the deployment
share since it is in a different location now. I'm assuming it is in the registry somewhere but cant seem to find it. Any help would be appreciated.

It might be in Variables.dat.
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. https://social.technet.microsoft.com/Forums/en-US/ef0a9119-63b6-45ae-a871-866ea62ee3e8/mdt-technet-forum-faq-getting-started-guide?forum=mdt

Similar Messages

MDT 2010 - Validation Error: The deployment share is read-only, so no changes can be made

I keep getting the above listed error when trying to update the rules on one of my deployment shares. I've even gone so far as to remove the read-only flag on everything in the share, it doesn't help.
As a workaround, I've been editing the CustomSettings.ini directly, but I'd really like this to work. Any ideas?
As an aside, the 'Alert me when someone responds to this post' never seems to work here. And yes, I've checked my spam folder as well...

Ok, it seems to be related to the MDT WizardEditor, but I'm not sure how. I logged on to the server and was able to update the deployment share several times. I closed the MMC, opened the WizardEditor, opened the Deploy.xml thing inside the WizardEditor, closed WizardEditor, reopened MMC - READ ONLY.
Very weird.

When deploy: Wizard error a connection to the deployment share could not be made "check physical connection"

Hello everybody,
yet another issue with deploying a masterdisk. I will give you a short explanation of the situation.
I need to deploy Windows 8.1 PRO x86.
Using: Microsoft Deployment Workbench Microsoft Version: 6.2.5019.0
1. Reference PC: Windows 8.1 PRO x86 is installed on ORACLE Virtual Box.
2. I installed MDT on my workstation Windows 7 x64, where "C:\DeploymentShare\Windows8" is located.
3. To change the Unattended.xml file, I have second ORACLE Virtual Box with
Windows 8.1 PRO x86 with MDT, which connected to the DeploymentShare of Windows 7 x64.
- The reason is because the Reference PC is x86 and the Unattended.xml file can be changed only if MDT is installed on x86 Windows, otherwise it is not possible.
The image capture is successful.
Then I create bootable USB device using rufus-1.4.12.exe. I use: C:\DeploymentShare\Windows8\Boot\LiteTouchPE_x86.iso
I use a real PC (not virtual machine) and when the deployment starts
I see:
1 Welcome screen, where I select: Run the deployment wizard to install a new operating system.
2. The next screen is an error screen where I see the error:
"Wizard error
A connection to the deployment share (\\ComputerName\C\DeployemntShare )could not be made
DHCP Lease was not obtained for any Networking devices!
Possible cause: Check physical connection
I am relatively new with MDT.
Any suggestions are more than welcome.

Nick,
Thank you for the answer!
Yesterday, I figured out that I need to create an offline bootable disk.
The issue is caused, because creating a bootable disk with rufus.exe include only the ISO file and not the WIM file. That is the reason why during OS installation process it asks me for the shared folder...

Connection to the deployment share could not be made (DFS share, works fine on site A, not on Site B)

I'm trying to isolate this problem with MDT..., unable to find a solution matching this error.
We have two sites, with a DFS replica between the servers, which works fine.
Server A: Windows 2012 R2 standard
Windows Automated Installation Kit for Windows 7
MDT 2012, Update 1
WDS configured for PXE boot
Distributed File Share
Server B: Windows 2008 R2 Standard
MDT 2012, Update 1
WDS configured for PXE boot
Distributed File Share
The local path on both servers is on E:\DFS-Deploymentshare
The DFS path is \\domain.com\it\deploymentshare
When deploying on Site A, the deployment run smooth without problems.
When deploying on Site B, the deployment fails to create connection to the share.
A connection to the deployment share (\\domain.com\it\deploymentshare) could not be made.
Connection OK. Possible cause: invalid credentials.
Pressing F8, to reach a command prompt. "ipconfig" shows an IP-address. I can PING the deployment server. I can mount the Deployment share using "net use" and providing the username/password added in the bootstrap.ini and "retry"
in the message box and the deployment continues.
In the BDD log i get this timeout:
<![LOG[Unable to connect to \\domain.com\it\deplomentshare. Sleeping for 5 seconds.
<![LOG[<Message containinng password has been suppressed>
<![LOG[Access is denied.
However everything is the same both in site A and B so this seems very strange!
The complete system has worked this way before.
Bootstrap.ini contains:
DeployRoot=\\domain.com\it\deploymentshare
UserDomain="domain"
UserID="mdt-account"
UserPassword="password"
I've been trying all I can think of, but Im still faced with this error and to keep in mind the same share working on another site.

Ok, so by the sounds of it, there is something wrong with the share permissions (especially if your account works fine but the MDTserviceaccount does not work even when part of Domain Admins).
So you need to do the following:
Start in Site A:
Boot into WinPE on a workstation in site A
Ping server-a
Ping server-b
Run "net use * \\server-a\deploymentshare$ /user:DOMAIN\MDTserviceaccount"
Type in the password for MDTserviceaccount when prompted
Browse to the newly mapped drive and list the files/folders
Make sure you can see the relevant MDT folders, like Applications, Out-of-Box Drivers, etc
If all that works, then you can move to site B
Start in Site B:
Boot into WinPE on a workstation in site B
Ping server-a
Ping server-b
Run "net use * \\server-b\deploymentshare$ /user:DOMAIN\MDTserviceaccount"
Type in the password for MDTserviceaccount when prompted
Browse to the newly mapped drive and list the files/folders
Make sure you can see the relevant MDT folders, like Applications, Out-of-Box Drivers, etc
By going through all of the above, you should be able to see where the problem lies.
If all of the above works with no problems, then you have the details incorrectly specified in the BootStrap.ini (or possibly CustomSettings.ini). Confirm that you have the following specified in the relevant ini file:
DeployRoot
UserID
UserDomain
UserPassword
You can have a look in the help file if you need to confirm that these properties are configured correctly. Look under
Toolkit Reference - Properties - Property Definition in the help file.
Both Site A and Site B is successfully
I have changed the Password of deployuser to test if it is correct. and i have copy/pasted the password into the DC when changing the password.
I have tested the password by logging on to a client-pc with the deployuser as username and the temp password "Pa$$w0rd" successfully.
Both UserID, UserDomain and UserPassword is entered after the help file for Property Definition.
Please see the Bootstrap.ini and Customsettings.ini (NB! Servernames, Domainname and Passwords are fictive.)
http://1drv.ms/1tGDlUt

Administrator account is disable when deploying windows 7 x64 captured image

I’m using MDT 2012 update 1. I create one deployment share with two task sequence.
The task sequences are: one for windows 7 x86 and the other one is windows 7 x64.
Both are working fine until I try to sysprep and capture with all the windows updates.
Sysprep and capture windows 7 x86 with all windows update work fine. I’m able to deploy the captured image without an error.
My problem is with the windows 7 x64 captured image. I’m able to sysprep and capture the windows7 x64 with all the windows update. Once the capture is completed, I change the .win file in my windows 7 x64 task sequence to point to the new .win file (capture
image with all the windows update). When I deploy windows 7 x64 on a pc, the OS get install but boot up to the sign on screen. The Task sequence does not complete. No error message. Cannot log in as local or domain administrator, account is disable.
Why does it work with my windows 7 x86 image and not with my windows 7 x64 image?
With my windows 7 x86 image the task sequence completed successfully with no error and it logon automatically in windows but not with my windows 7 x64 image.
Both task sequences are the same.
Let me know if any info for this please.
thanks

They should both work, perhaps you missed a step when creating the x64 image.
1. Verify that the Windows 7 x64 image was created cleanly, with no errors. Sysprep ran with no errors.
2. Verify that you created the windows 7 deployment task sequence cleanly. I would do a windiff of the TS.xml and unattend.xml file from both folders in the deployment share.
3. Try running without a domain. Some domain's have a GP set to disable the local administrator account.
Keith Garner - keithga.wordpress.com

Unable to connect to Deployment share via the 2012 Update 1 workbench.

Hi Everyone,
This is a tricky one, I've been scratching my head for a few days now. I have a MDT deployment share, which lives on a server, for argument sake, lets call it: MDT-01. Via the Servers MDT Workbench, I can connect to the deployment share just fine, from
any PC, other than my main PC (which is running Windows 8.1), I can connect to the deployment share just fine. If I load the MDT Workbench on my main PC, it just has a deployment share folder with a red cross on it. If I attempt to remove it, it crashes the
MMC, if I try and open the same deployment share it crashes the MMC. If I give the Deployment Share a different share name, it errors and says I can't use an existing deployment share folder.
I used to be able to connect to the share just fine, but since the last couple of days I've not been able to connect.
Further investigation with PowerShell reveals that the console thinks it has a persistent drive, DS001, but the path is blank, as in ''.
Restore-MDTPersistentDrive -verboseVERBOSE: Restoring drive 'DS001' with path ''WARNING: Unable to restore drive DS001.
If I try to remove the Persistent drive, it errors, and if I try to add any new drive to either the same deployment share, or an alternative, it fails.
I can use the New-PSDrive and Remove-PSDrive Powershell commands to create/remove a replicated drive, but that doesn't actually change the Path value in the Get/Restore-MDTPersistantDrive, as they seem to be separate, even though I think they should
be linked.
The Internet has been no help, so I'm asking the Microsoft crew to be helpful, and not just do the usual "This is posted in the wrong place, this question will now be closed... etc, etc!" This is an MDT question, not a Powershell question, I just
need anyone who has indepth MDT knowledge to look at this.
To make clear, this is not a question about a client connecting to the deployment share, that all works fine, and I can update the deployment share fine from any other workbench.
I cannot connect to my deployment share, from my local MMC MDT workbench, as it thinks it already has one, but with a blank path. I've uninstalled, and reinstalled both the MDT, and ADK components on my Local PC, but I still cannot connect to the Share.
My question is this: The files/registry that stores this DS001 path setting is clearly local to my PC, but where is it, I've search the reg, and I've check files, but to no avail, I'm likely to rebuild my PC because of this, but I'd rather not if I can help
it.
Any Ideas people?
P.s. Sorry if this post seems rude, I do appreciate the help, I just don't have time for being messed about, as we're migrating our XP system to 7, and with less than 60 days remaininf, I could do without this... Thanks for understanding. :D

Persistent drives are just a easy way for the MDT console to keep track of the Deployment Shares you like the most (think of it as "pinning" Deployment Shares to the console).
The list of persisted Deployment Shares are per user and stored in the file:
"%AppData%\Microsoft\Microsoft Deployment Toolkit\User.Config"
Mine looks like:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<userSettings>
<MDTProvider>
<setting name="Drive1Name" serializeAs="String">
<value>DS001</value>
</setting>
<setting name="Drive1Path" serializeAs="String">
<value>C:\DeploymentShare</value>
</setting>
<setting name="Drive1Description" serializeAs="String">
<value>MDT Deployment Share</value>
</setting>
</MDTProvider>
</userSettings>
</configuration>
Make sure the Drive Path points to something valid, otherwise, I would delete (rename) the file and let MDT re-create the file.
I hope this answers your question.
Keith Garner - keithga.wordpress.com

MDT - iaStorA.sys error when starting up, Status: 0xc0000098, multiple errors updating deployment share

I recently had rearranged our imaging by creating selection profiles for each computer model and then creating a task sequence for each model so that it looks for a model and only injects the drivers for that model. Everything had been working great
and then we got a new batch of Dell Latitude E6440's in. I checked over the machine and just wanted to make sure nothing changed so i grabbed a couple drivers off of it and uploaded them into mdt under that model. I went to update the deployment
share and started to get a whole host of Error: 2, no driver packages were found on the specified path. Verify the driver .INF file are in the specific location and try the command again. It points to the dism log and exit code is =2 then it says DISM
/Add-Driver failed, rc = 2 and lists all the drivers that had failed. It was a whole bunch for both the x86 and x64. Although i didnt add all these drivers. I only messed with the wifi and nic driver and it was only two files. I ran
through imaging and there were no issues it rebooted windows is about to start and it goes to the black screen with the iaStorA.sys message. I checked everything, i looked over all the chipset drivers i knew i imported and those were still there. I
downloaded the WINPE stuff from dell and found the driver and made sure to import everything in that folder and it skipped it as it said it was still there. I wanted to make sure it wasnt the whole mdt server so i imaged a different computer model all
together and that worked. So i deleted every driver out for this model made sure to delete it if it was in other places. I am now in the process of only including very specific drivers ie just the nic and display and audio and see if it will get
passed first bootup. But what would make it go from working every time for about 3 weeks now to all of a sudden not injecting drivers through updating the deployment share and causing a problem for just this image. I am including the dism log and
it is lengthy. The drivers are all sitting all sorted out in their respected folders on the desktop of the share. This has never been an issue before. here is the log
=== Making sure the deployment share has the latest x86 tools ===
=== Processing LiteTouchPE (x86) boot image ===
Building requested boot image profile.
Determining if any changes have been made in the boot image configuration.
No existing boot image profile found for platform x86 so a new image will be created.
Calculating hashes for requested content.
Changes have been made, boot image will be updated.
Windows PE WIM C:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\en-us\winpe.wim will be used.
WIM file mounted.
Deployment Image Servicing and Management tool
Version: 6.3.9600.17029
Image Version: 6.3.9600.16384
There was a problem opening the INF file. D:\Windows7\Out-of-box Drivers\hdc\iaAHCI_8.9.8.1005_157DE4AE7437DC1A46C7E0E4B3294E513CB47D80\iaAHCI.inf Error: 0x80070002.
Error: 2
No driver packages were found on the specified path.
Verify that the driver .INF files are in the specified location and try the command again.
The DISM log file can be found at C:\Windows\Logs\DISM\dism.log
Exit code = 2
DISM /Add-Driver failed, rc = 2.
Injected driver Intel hdc iaAHCI.inf 8.9.8.1005 (2)
Injected driver Intel hdc ibexahci.inf 7.0.0.1013 (14)
Deployment Image Servicing and Management tool
Version: 6.3.9600.17029
Image Version: 6.3.9600.16384
There was a problem opening the INF file. D:\Windows7\Out-of-box Drivers\hdc\ibexahci_7.0.0.1013_CDE6EABDFCC22A23476F9CB4EA115D63FF4A6DBE\ibexahci.inf Error: 0x80070002.
Error: 2
No driver packages were found on the specified path.
Verify that the driver .INF files are in the specified location and try the command again.
The DISM log file can be found at C:\Windows\Logs\DISM\dism.log
Exit code = 2
DISM /Add-Driver failed, rc = 2.
Injected driver Intel hdc ibexahci.inf 7.0.0.1013 (15)
Injected driver Intel hdc ibexid2.inf 9.1.1.1013 (6)
Deployment Image Servicing and Management tool
Version: 6.3.9600.17029
There were about 2,000 plus more lines of the same stuff.
For future purposes where should the driver be when import them into mdt and do i need to then keep them? I am still learning all this stuff after taking over the roll in October of 2014. Any help would be greatly appreciated.

Hi KheenanHalvorson,
According to the log ,it seems that there is something missing in the driver package .
According to your description ,I assumed that you have configured the whole process correctly.
To deploy the drivers in this way the driver package should include two files an INF and SYS file .We may need to replace the driver package with another one including the INF file .
Here is a link for reference:
How to manage Out-of-Box Drivers with the use of Model Specific Driver Groups in Microsoft Deployment Toolkit 2012 Update 1
http://blogs.technet.com/b/askcore/archive/2013/05/09/how-to-manage-out-of-box-drivers-with-the-use-of-model-specific-driver-groups-in-microsoft-deployment-toolkit-2012-update-1.aspx
"One thing to note about Driver injections is that the driver must have an INF and SYS file in order for us to install the driver this way. If a driver installs via an EXE and there is no way to extract that driver to reveal the actual INF
and SYS file, then you would be forced to add that driver EXE package as an application and install it as an application. "
Best regards
Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact [email protected]

How do I stop iCal from changing the server path of CalDAV accounts?

I'm using Davical as a calendar server for our family. Some may wonder why I use Davical and not iCloud. I do for one reason...there is no way to disable getting other users' alarms on the iPhone. I want to be able to view my wife's calendar but not get her alarms and have her be able to view my calendar and not get my alarms.
So, now onto the issue with server path setting changing in iCal. We each have our own calendar set up within our own accounts on our Davical server. We each have read access to the other's calendar. Within iCal account settings I have her account set up on my Mac with my username/password (jason/****) and, under server settings, the server path points to her calendar /caldav.php/juiper/). After a few days, sometimes just a few hours, suddenly I will have duplicate events throughout my calandar in iCal. Going to preferences I will see that the server path for her calendar will have been changed to the location of my calendar (/caldav.php/jason/). I'll correct the server path, restart iCal and then the calander will be correct for a while unitl the server path is automatically and incorrectly changed again and I must manually correct it again.
Thanks!

My coworkers and I use DavMail to share access to a shared Exchange calendar, authenticating with our own ADS credentials. We also see the behavior where iCal will reset the CalDav calendar path to the username (our own) that is authenticating to the CalDav service. In Lion this wasn't a deal breaker for us. While very annoying, the work around was simple. Update the path via preferences, and restart iCal. However in Mountain Lion, the issue has become a lot more difficult to fix. It's no longer a matter of updating the path via preferences and restarting.
In Mountain Lion the solution to change the CalDav path back to the original path requires you to edit the file ~/Library/Calendars/<somehash>.caldav/Info.plist
Contained within this file is a value "CalendarHomePath", simply update the string to your desired path, clear out the 'Calendar Cache' file for good measure, then restart iCal.

Dell Laptops E7440 & E7240 - Issues with connecting to MDT 2012 deployment share

Hi,
Good afternoon.Need help on this please
-Test laptops Iam using are 2 * E7440 and 1*E7240. One laptop of model E7440 has our image installed and other two (1*E7440 & 1*E7240) are shipped from Dell with default Win 7 64 bit OS.
-Test desktops Iam using are Dell Optiplex 3020 & Dell 3010 . Both models have our own images of Win 7 64 Bit.
-Laptops and desktops are on same network .
-For OS deployments we have MDT 2012.
-While there are no issues with desktops, all the laptops mentioned above don’t connect to MDT deployments share . The detailed error message I get when I run a litetouch ISO is ‘A connection to the deployment share could not be made. Connection OJ.Possible
cause:invalid credentials. Retry : Try again to connect to the deployment share.’
-Have injected all possible network & storage drivers mentioned by Dell & Intel into MDT boot image but the problem still persists. Still WinPE doesn’t detect network adapter wherein IPaddresses are not picked in WinPE mode.
-Have been testing each and every driver by manually loading them into Winpe mode to see if they pick up the IP addresses and I finally found one driver by name ‘e1d63x64.inf ‘ which I downloaded directly from Intel website. This one is picking IP Address
in WinPE mode when loaded manually. Also have tested the connectivity to MDT server in WinPE mode with net use command and it was successful.
Have injected this driver into MDT Laptop deployment share, regenerated the ISO and tried again however Iam still unable to connect to the deployment share with litetouch ISO.
The above driver is very much part of set of network drivers on Dell website too.But it doesn’t work.
-Have also tried combination of network & storage drivers from Dell website (along with the above one mentioned ) injecting them into the MDT laptop boot image but no luck.
-Every time I make changes to drivers in boot image,I update deployment share & recreate boot image .
-This very litetouch iso connects to MDT deployments share for Dell desktop models 3010 & 3020 but have issues with laptop models E7440 & E7240. This means any connectivity or access issues can be ruled out. Also no problem with our image cause
this happens even with brand new shipped laptops with your inbuild win 7 OS.
-Have tried all options suggested on internet,tested all the drivers suggested but no luck.
-For example I tried latest E7440 netwrok & storage drivers ,Dell Win PE drivers,drivers from Intel website,etc individually as well as in combinations but the issue persists.
-If you google many express similar issues with these laptop models.
Though I used the drivers suggested by various bloggers,nothing worked for me.
Any help on this is appreciated.Thanks in advance.

Hi,
I have several E6420, O3010 and since a week also some E7440 and E7240 on site.
I never had issues using the current Dell PE package for MDT.
At the moment my PE contains only the drivers from the Dell PE 3.0 package (WinPE3.0-Drivers-A13-D67JC)
and all my systems mentioned abobe have no issues connecting to the deployment share.
(btw: I have also some older E6400, E6410 and O390 I do no longer support, they
are supported by the pack Dell-WinPE-Drivers-A05.CAB according
to the Dell site, but I just started a deplymenst on a E6410 and is is also workign with just the latest PE pack)
I'd
suggest you start over with your deplyoment share using at least MDT2012 Update 1.
Create a folder "PE" under "Out-of-Box Drivers" and extract latest Dell PE pack and import he drivers there
Create a selection profile e.g. "PE Drivers" and include just the "PE" folder created above
When configuring the Windows PE settings of your deployment share select "PE
Drivers" selection profile for the driver injection in the "Drivers and Patches" to keep the PE image free of not needed drives.

MDT 2013 - A Connection to the deployment share could not be made - DHCP Lease was not obtained

First, let me give you some context:
Framework: MDT 2013 with MS SDK 7.1
Task Sequence: Standard Client TS with sysprep and capture.
Target workstation (build workstation): VM Guest on ESX 5.5 host, 8 vCPU, 8GB RAM, LSI Logic SAS Controller, E1000 NIC, SSD DAS
Behavior: The VM loads and installs the OS fine in PE, VM boots into OS successfully and resumes the TS, after the first system reboot, the error message occurs and it reads:
A connection to the deployment share (\\*********\DeploymentShare$) could not be made. DHCP Lease was not obtained for any Networking device! Possible Cause: Check physical connection. Retry:...... Cancel:.....
While observing this error, I didn't notice the NIC hadn't completely initialized and obtained an IP yet (network adapter icon in systray), additionally hitting retry after the NIC was initialized resumed the TS.
This behavior reoccurs with several subsequent reboots until a few more applications (Citrix Receiver, VMware Tools) with services are installed which seem to then slow the system boot-up time and then allows the TS to start after the NIC has initialized.
From several posts I've read on this forum, this particular behavior was alleviated by a "wait for IP lease" mechanism built into the TS engine which was introduced in MDT 2010 SP1, I wasn't able to find any other confirmation whether
this mechanism is still in effect with MDT 2013. Another point worth mentioning from several other posts I was able to find is that this behavior appears to manifested itself on target workstations with SSDs, which would somewhat explain the faster
TS load time vs waiting for an IP lease. I've also tried to replicate this behavior in a non-SSD and low-performance VM environment and I wasn't able to replicate it.
My question: Does anyone else have experienced this behavior with MDT 2013 and if so, how did you resolve it? Or is this a bug?

I have this issue intermittently as well. For us, it coincided with the deployment of IP phones, which meant PoE switches all around. However, the problem persisted even after we turned off PoE to the ethernet ports from which we normally PXE
boot.
As this issue has been intermittent, I've backburnered it. When it does happen, I just wait for the lease to arrive then rerun the wizard.
Thanks for the feedback, that's true the TS can be resumed manually once the lease has occured but it defeats the purpose of an automated TS if I have to keep an eye on it and intervene if I need to.
The network guys here recommended putting wireshark or network monitor on it and figuring out just what the heck is going on. Basically, what Keith Garner said. They also disabled PortFast awhile back to see if that made any difference, and it did
not.

Windows 10 TP build 10041 seen as Windows 8.1 OS when imported to a Deployment Share

Hi all,
I tried to import the Windows 10 TP build 10041 as operating system to a new deployment share created with MDT 2013 U1.
I referenced the DVD iso image of Windows 10 Technical Preview 10041 and os type was recognized as Windows 8.1. Is there a plan to fix this issue?
Thanks

Hi Michael, unfortunately it does not. I updated MDT with the new files, but I think that problem is inside the image of Windows 10 TP build 10041. Let's have a look to the output of imagex /info d:\sources\install.wim command from ADK for Windows 10 to
the install.wim file inside the .iso image.
When the image information will be updated correctly?
ImageX Tool for Windows
Copyright (C) Microsoft Corp. All rights reserved.
Version: 10.0.10011.0
WIM Information:
Path: d:\sources\install.wim
GUID: {88c8be92-f7bb-49a7-8c75-b6af1c3d90d0}
Image Count: 2
Compression: LZX
Compression chunk size: 32768
Part Number: 1/1
Attributes: 0xc
Integrity info
Relative path junction
Available Image Choices:
<WIM>
<TOTALBYTES>2318085699</TOTALBYTES>
<IMAGE INDEX="1">
<DIRCOUNT>13795</DIRCOUNT>
<FILECOUNT>67776</FILECOUNT>
<TOTALBYTES>7908994779</TOTALBYTES>
<HARDLINKBYTES>3235690022</HARDLINKBYTES>
<CREATIONTIME>
<HIGHPART>0x01D05E2B</HIGHPART>
<LOWPART>0xC1BAA0A1</LOWPART>
</CREATIONTIME>
<LASTMODIFICATIONTIME>
<HIGHPART>0x01D05E2B</HIGHPART>
<LOWPART>0xCEFDD121</LOWPART>
</LASTMODIFICATIONTIME>
<WIMBOOT>0</WIMBOOT>
<WINDOWS>
<ARCH>0</ARCH>
<PRODUCTNAME>Microsoft® Windows® Operating System</PRODUCTNAME>
<EDITIONID>Professional</EDITIONID>
<INSTALLATIONTYPE>Client</INSTALLATIONTYPE>
<SERVICINGDATA>
<GDRDUREVISION>0</GDRDUREVISION>
<PKEYCONFIGVERSION>10.0.10041.0;2015-03-14T02:32:33Z</PKEYCONFIGVERSION>
</SERVICINGDATA>
<HAL>acpiapic</HAL>
<PRODUCTTYPE>WinNT</PRODUCTTYPE>
<PRODUCTSUITE>Terminal Server</PRODUCTSUITE>
<LANGUAGES>
<LANGUAGE>en-US</LANGUAGE>
<DEFAULT>en-US</DEFAULT>
</LANGUAGES>
<VERSION>
<MAJOR>10</MAJOR>
<MINOR>0</MINOR>
<BUILD>10041</BUILD>
<SPBUILD>0</SPBUILD>
<SPLEVEL>0</SPLEVEL>
</VERSION>
<SYSTEMROOT>WINDOWS</SYSTEMROOT>
</WINDOWS>
<NAME>Windows 8.1 Pro</NAME>
<DESCRIPTION>Windows 8.1 Pro</DESCRIPTION>
<FLAGS>Professional</FLAGS>
<DISPLAYNAME>Windows 10 Pro Technical Preview</DISPLAYNAME>
<DISPLAYDESCRIPTION>Windows 10 Pro Technical Preview</DISPLAYDESCRIPTION>
</IMAGE>
<IMAGE INDEX="2">
<DIRCOUNT>13705</DIRCOUNT>
<FILECOUNT>67071</FILECOUNT>
<TOTALBYTES>7889228575</TOTALBYTES>
<HARDLINKBYTES>3205627242</HARDLINKBYTES>
<CREATIONTIME>
<HIGHPART>0x01D05E2C</HIGHPART>
<LOWPART>0x73196F39</LOWPART>
</CREATIONTIME>
<LASTMODIFICATIONTIME>
<HIGHPART>0x01D05E2C</HIGHPART>
<LOWPART>0x7D2E91DF</LOWPART>
</LASTMODIFICATIONTIME>
<WIMBOOT>0</WIMBOOT>
<WINDOWS>
<ARCH>0</ARCH>
<PRODUCTNAME>Microsoft® Windows® Operating System</PRODUCTNAME>
<EDITIONID>Core</EDITIONID>
<INSTALLATIONTYPE>Client</INSTALLATIONTYPE>
<SERVICINGDATA>
<GDRDUREVISION>0</GDRDUREVISION>
<PKEYCONFIGVERSION>10.0.10041.0;2015-03-14T02:30:40Z</PKEYCONFIGVERSION>
</SERVICINGDATA>
<HAL>acpiapic</HAL>
<PRODUCTTYPE>WinNT</PRODUCTTYPE>
<PRODUCTSUITE>Terminal Server</PRODUCTSUITE>
<LANGUAGES>
<LANGUAGE>en-US</LANGUAGE>
<DEFAULT>en-US</DEFAULT>
</LANGUAGES>
<VERSION>
<MAJOR>10</MAJOR>
<MINOR>0</MINOR>
<BUILD>10041</BUILD>
<SPBUILD>0</SPBUILD>
<SPLEVEL>0</SPLEVEL>
</VERSION>
<SYSTEMROOT>WINDOWS</SYSTEMROOT>
</WINDOWS>
<NAME>Windows 8.1</NAME>
<DESCRIPTION>Windows 8.1</DESCRIPTION>
<FLAGS>Core</FLAGS>
<DISPLAYNAME>Windows 10 Technical Preview</DISPLAYNAME>
<DISPLAYDESCRIPTION>Windows 10 Technical Preview</DISPLAYDESCRIPTION>
</IMAGE>
</WIM>

Change include file paths

change include file paths

Hi Palm566,
Thank you for posting in MSDN forum.
About you issue, could you please tell me more detail message about your issue?
For example, where did you want to change the file path?
What file you want to change the path?
To further help you solve this issue, I suggest you can share more message about your issue.
Thanks for your understanding.
Best Regards,
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.

A connection to the deployment share issue MDT2010

I am getting the following error, when the pc reboots, during any of the following: applying pre-application updates, installing applications, applying post-application updates on our Lenovo M73 Windows 7 desktop computers. It doesn't happen
on the Dell OptiPlex desktops or Lenovo/Dell Laptops.
The error is "A connection to the deployment share (\\server.xxx.local\DeploymentShare$) could not be made. DHCP Lease was not obtained for any Networking device! Possible Cause: Check physical
connection.
If I click on retry the task sequence carries on as normal but the error can happen again when the pc reboots next. I have tried changing the server name for the IP address and also just used the server name. The pc is on the network
correctly as I can get the IP address via IPConfig and it shows that it has a current lease as well. If I look in device manager the network card is installed correctly and there are no devices not found.
Here is the end of the BDD log:
<![LOG[Property InstalledUpdates167 is now = 9655393d-1b46-46a2-ac21-c4d1b5e960d1]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="ZTIWindowsUpdate" context="" type="1" thread=""
file="ZTIWindowsUpdate">
<![LOG[Property InstalledUpdates168 is now = 884c7884-5970-4fd5-8afb-f52a0bd8204f]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="ZTIWindowsUpdate" context="" type="1" thread=""
file="ZTIWindowsUpdate">
<![LOG[More to install, Please reboot and run again!]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="ZTIWindowsUpdate" context="" type="1" thread="" file="ZTIWindowsUpdate">
<![LOG[Property SMSTSRetryRequested is now = true]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="ZTIWindowsUpdate" context="" type="1" thread="" file="ZTIWindowsUpdate">
<![LOG[Property SMSTSRebootRequested is now = true]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="ZTIWindowsUpdate" context="" type="1" thread="" file="ZTIWindowsUpdate">
<![LOG[ZTIWindowsUpdate processing completed successfully.]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="ZTIWindowsUpdate" context="" type="1" thread="" file="ZTIWindowsUpdate">
<![LOG[Command completed, return code = -2147021886]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[Property LTIDirty is now = FALSE]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[If there is a drive letter defined, make sure we clear it now so we can *force* recalcutation.]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread=""
file="LiteTouch">
<![LOG[Property OSDTargetDriveCache is now = DIRTY]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[LTI initiating task sequence-requested reboot.]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[Shortcut "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\LiteTouch.lnk" already exists.]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="LiteTouch" context="" type="1"
thread="" file="LiteTouch">
<![LOG[Property BootPE is now = ]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[Microsoft Deployment Toolkit version: 6.1.2373.0]LOG]!><time="16:50:06.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[ZTIUtility!GetAllFixedDrives (False)]LOG]!><time="16:50:06.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[New ZTIDisk :
<time="16:50:06.000+000">\\pcnumber\root\cimv2:Win32_DiskDrive.DeviceID="\\\\.\\PHYSICALDRIVE0"]LOG]!><time="16:50:06.000+000" date="02-28-2014" component="LiteTouch" context=""
type="1" thread="" file="LiteTouch">
<![LOG[New ZTIDiskPartition :
\\pcnumber\root\cimv2:Win32_DiskPartition.DeviceID="Disk #0, Partition #1"
<time="16:50:06.000+000">\\pcnumber\root\cimv2:Win32_LogicalDisk.DeviceID="C:"]LOG]!><time="16:50:06.000+000" date="02-28-2014"
component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[New ZTIDisk :
<time="16:50:06.000+000">\\pcnumber\root\cimv2:Win32_DiskDrive.DeviceID="\\\\.\\PHYSICALDRIVE0"]LOG]!><time="16:50:06.000+000" date="02-28-2014" component="LiteTouch" context=""
type="1" thread="" file="LiteTouch">
<![LOG[ZTIUtility!GetAllFixedDrives =   C:]LOG]!><time="16:50:07.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[Found existing task sequence state information in C:\_SMSTaskSequence, will continue]LOG]!><time="16:50:07.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread=""
file="LiteTouch">
<![LOG[Not running within WinPE.]LOG]!><time="16:50:07.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[DeploymentMethod = UNC]LOG]!><time="16:50:07.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[Validating connection to
\\server.xxx.local\DeploymentShare$.
DHCP Lease was not obtained for any Networking device! Possible Cause: Check physical connection.]LOG]!><time="16:50:07.000+000" date="02-28-2014" component="LiteTouch" context="" type="3" thread=""
file="LiteTouch">
Any advice would be appreciated as we are going to have a large quantity of these to roll out.
Many Thanks
James

I am getting the following error, when the pc reboots, during any of the following: applying pre-application updates, installing applications, applying post-application updates on our Lenovo M73 Windows 7 desktop computers. It doesn't happen
on the Dell OptiPlex desktops or Lenovo/Dell Laptops.
The error is "A connection to the deployment share (\\server.xxx.local\DeploymentShare$) could not be made. DHCP Lease was not obtained for any Networking device! Possible Cause: Check physical
connection.
If I click on retry the task sequence carries on as normal but the error can happen again when the pc reboots next. I have tried changing the server name for the IP address and also just used the server name. The pc is on the network
correctly as I can get the IP address via IPConfig and it shows that it has a current lease as well. If I look in device manager the network card is installed correctly and there are no devices not found.
Here is the end of the BDD log:
<![LOG[Property InstalledUpdates167 is now = 9655393d-1b46-46a2-ac21-c4d1b5e960d1]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="ZTIWindowsUpdate" context="" type="1" thread="" file="ZTIWindowsUpdate">
<![LOG[Property InstalledUpdates168 is now = 884c7884-5970-4fd5-8afb-f52a0bd8204f]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="ZTIWindowsUpdate" context="" type="1" thread="" file="ZTIWindowsUpdate">
<![LOG[More to install, Please reboot and run again!]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="ZTIWindowsUpdate" context="" type="1" thread="" file="ZTIWindowsUpdate">
<![LOG[Property SMSTSRetryRequested is now = true]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="ZTIWindowsUpdate" context="" type="1" thread="" file="ZTIWindowsUpdate">
<![LOG[Property SMSTSRebootRequested is now = true]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="ZTIWindowsUpdate" context="" type="1" thread="" file="ZTIWindowsUpdate">
<![LOG[ZTIWindowsUpdate processing completed successfully.]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="ZTIWindowsUpdate" context="" type="1" thread="" file="ZTIWindowsUpdate">
<![LOG[Command completed, return code = -2147021886]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[Property LTIDirty is now = FALSE]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[If there is a drive letter defined, make sure we clear it now so we can *force* recalcutation.]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[Property OSDTargetDriveCache is now = DIRTY]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[LTI initiating task sequence-requested reboot.]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[Shortcut "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\LiteTouch.lnk" already exists.]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[Property BootPE is now = ]LOG]!><time="16:49:46.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[Microsoft Deployment Toolkit version: 6.1.2373.0]LOG]!><time="16:50:06.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[ZTIUtility!GetAllFixedDrives (False)]LOG]!><time="16:50:06.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[New ZTIDisk :
<time="16:50:06.000+000">\\pcnumber\root\cimv2:Win32_DiskDrive.DeviceID="\\\\.\\PHYSICALDRIVE0"]LOG]!><time="16:50:06.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[New ZTIDiskPartition :
\\pcnumber\root\cimv2:Win32_DiskPartition.DeviceID="Disk #0, Partition #1"
<time="16:50:06.000+000">\\pcnumber\root\cimv2:Win32_LogicalDisk.DeviceID="C:"]LOG]!><time="16:50:06.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread=""
file="LiteTouch">
<![LOG[New ZTIDisk :
<time="16:50:06.000+000">\\pcnumber\root\cimv2:Win32_DiskDrive.DeviceID="\\\\.\\PHYSICALDRIVE0"]LOG]!><time="16:50:06.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[ZTIUtility!GetAllFixedDrives =   C:]LOG]!><time="16:50:07.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[Found existing task sequence state information in C:\_SMSTaskSequence, will continue]LOG]!><time="16:50:07.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[Not running within WinPE.]LOG]!><time="16:50:07.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[DeploymentMethod = UNC]LOG]!><time="16:50:07.000+000" date="02-28-2014" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
<![LOG[Validating connection to
\\server.xxx.local\DeploymentShare$.
DHCP Lease was not obtained for any Networking device! Possible Cause: Check physical connection.]LOG]!><time="16:50:07.000+000" date="02-28-2014" component="LiteTouch" context="" type="3" thread="" file="LiteTouch">
Any advice would be appreciated as we are going to have a large quantity of these to roll out.
Many Thanks
James
On the problem desktop do you have a vaild IP?

A connection to the deployment share cannot be made

i am trying to update a PC from XP to windows 7 with MDT2012.
i have import the OS in the workbench,and created a task sequence,then i update the deployment share.On the XP machine I have started the LiteTouch.vbs script.After it capture the user profile,and restart the machine.The problem start.It printde "A
connection to the deployment share cannot be made".

WHen in WinPE, you can press F8 to get a command prompt. You should then go through the usual steps to debug the bad network connection, ipconfig /all, ping GZZJOPC998, net use * \\GZZJOPC998\DeploymentShare$ .
Chances are that WinPE does *not* have the latest and greatest drivers for your device. check the x:\windows\system32\wpeinit.log to verify that the OS found the driver and installed it. If not, find the driver from your OEM/IHV, and import into MDT. Don't
forget to update the deployment share when done.
Keith Garner - keithga.wordpress.com

A connection to the deployment share could not be made. connection ok

hi,
i have deployment windows 7 by MDT，and there is something wrong with the test. i have a MDT Service and 2 clients that one is updated and another is used to capture the image.but when i captured the image,there is error."a connection to the deployment
share could not be made. connection ok"

i create and capture the image from a physical
machine,and i create the network drivers on the MDT console. And it will generate the winPE.When i capture
and restart the machine, it will get the error.

Change Deployment Share Path on Capture VM

Similar Messages

Maybe you are looking for