MDT Deployment Share on USB

Hi everyone..
can I use an external HDD to host my MDT deployment share.. Basically, I don't have enough drive space in my laptop to host the deployment share & the WIM's/Apps...
thanks in advance..

USB 3.0 drives are more than fast enough (over 1GB)
USB 2.0 drives are not as fast, but should be OK.
When combined with WDS Multicasting, I would feel confident using a 3 year old laptop to service a single install.wim over a hundred clients using USB 2.0.
However, if you are servicing more than 10 clients over unicast, you will start to get IO bound. Do your performance testing.
Keith Garner - Principal Consultant [owner] -
http://DeploymentLive.com

Similar Messages

MDT Deployment share and SQL Share on different servers

Hello Technet,
I would like help to figure out how to deal with my MDT Deployment share being on a different server than my SQL Share. I am trying to use the MDT Database in MDT 2013 and SQL Server Express 2014. My deployment share is located on a Linux File Server share,
and my MDT Server and SQL Express Server are located on the same Windows Server 2012 VM.My Bootstrap.ini therefore looks like this:
[Settings]
Priority=Default
[Default]
SkipBDDWelcome=YES
DeployRoot=\\192.168.1.10\DeploymentShare$
UserID=user
UserPassword=password
my Customsettings looks like this:
[Settings]
Priority=CSettings, CPackages, CApps, CAdmins, CRoles, Locations, LSettings, LPackages, LApps, LAdmins, LRoles, MMSettings, MMPackages, MMApps, MMAdmins, MMRoles, RSettings, RPackages, RApps, RAdmins, TaskSequenceID,Default
[Default]
CaptureOS=YES
[CSettings]
SQLServer=SQLServer
Instance=SQLEXPRESS
Database=MDT
Netlib=DBNMPNTW
SQLShare=Logs
Table=ComputerSettings
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
Therefore, the problem is that during winPE Bootup, WinPE connects to the deploymentshare using the provided credentials just fine, and tries to process customsettings. However, I can map a network drive to the SQL Share as seen in the logs by the following
errors:
1.ERROR-Unable to map a network drive to \\SQLServer\Logs
2. ZTI Error opening SQL Connection:[DBNETLIB][ConnectionOpen(Connect()).]SQL Server does not exist or access is denied.
3.Unable to establish database connection using [CAPPS] properties.
In WinPE, as soon as I hot F8, and use net use \\SQLServer\Logs, the deployment works fine and the properties are read from the database during each section process..
Why is MDT Unable to map the \\SQLServer\Logs , and it requires the manual use of net use? Must I move the deployment share to the same server as my SQL Server Server? Thanks so much.

Should work, Don't know why it's failing.
Can you post your full bdd.log file to a public site like OneDrive and share the link?
There are some inconsistencies with your written summary above.
Keith Garner - Principal Consultant [owner] -
http://DeploymentLive.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

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.

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.

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]

MDT Media - StateStore on USB Deployment media drive?

MDT 2012 update 1
I'm doing a Refresh (migrating XP to 7) using USB Media of my working task sequence.
Everything works, migrates to 7 with all user data etc..
However I noticed it takes a very long time. There's a "StateStore" folder being created on the USB drive containing the following:
USB:\StateStore\USMT\File\E$\Deploy\Applications\
USB:\StateStore\USMT\File\E$\Deploy\Out-of-Box Drivers\
USB:\StateStore\USMT\File\E$\Deploy\Scripts\
USB:\StateStore\USMT\File\E$\Deploy\Templates\
It contains some (but not all) of the folders from the USB:\Deploy\ folder.
I still have a StateStore on C:\ containing the user data like it should...
but why would it ALSO be backing up some of the deployment folders on the USB Media drive?
After deployment completes, the USB's StateStore folder is never removed either.
I'd really like to reduce the time it takes by avoiding this useless backup, and potential problems that may surround it.
I have the following in my CustomSettings.ini, but nothing that should be causing backup of anything on other drives.
USMTMigFiles001=MigApp.xml
USMTMigFiles002=MigUser.xml
USMTMigFiles003=MigFMCNA.xml

Thanks for the reply!
I put in the following entry in my custom MigFMCNA.xml, but still have no change.
<component type="Documents" context="System">
<displayName _locID="miguser.avoidusb">Avoid USB Statestore</displayName>
<role role="Data">
<rules>
<exclude>
<objectSet>
<pattern type="File">D:\* [*]</pattern>
<pattern type="File">E:\* [*]</pattern>
<pattern type="File">F:\* [*]</pattern>
<pattern type="File">G:\* [*]</pattern>
</objectSet>
</exclude>
</rules>
</role>
</component>

Single MDT Database and two Deployment shares

I have two unique Deployment shares as I have separated my Deployment shares by OS, as such I have a Windows 7 DS, and a Windows 8.1 DS. The reason behind this is shear size for the number of models I have to support, it would bloat the image over the
15GB mark it sits today.
That all being said what I am attempting to do is utilize a single database as it all houses the proper site information (all 500+ locations), however the issue I am running into is with the fact that if I have an Application bundle in my Windows 7 DS
with dependencies, and I go add the Bundle for the machine to the database in my Windows 8 DS then it overwrites the database information completely and I lose the capability to install the app bundle in my Win7 deployment.
I do understand that if I had both OS within a single DS and had multiple TS for the OS deployment and all the bundles created by OS version and utilized the logic to only install on specific OS version I could get this to work rather easily but as stated
above I support over 40 Models of PC in my windows 7 image and cannot add to its size as it is already a hassle to distribute.
Any help or suggestions would be appreciated.

Keith,
The "Completely" meant that due to the mismatched GUIDs it was overwriting the database entry for the working Deployment share when I added the new Bundle . I have since copied the Bundles from one Deployment share to the other and that seems to
have resolved most of my issues, However I am still seeing in the Applications.xml file that it pulls the applications from the Windows 7 side for Bundles if I do not have an application in that same Bundle for the Windows 8 side. This would attempt to install
even if the app was set only for the Windows 7 side as a SupportedPlatform, as it was added to the Applications.xml file and would always error out because it was unable to find the application for that GUID.
Basically I have a Bundle for all Laptops and on the Windows 7 side I have a few apps that get installed and we are not that far into Windows 8 to needs these same apps yet which is why it was empty on the Windows 8 side.
So your suggestion is indeed the solution but also wanted to make people aware that there cannot be an empty Bundle on one of the Deployment Shares if there are Apps in that Bundle on the other Deployment share.

Surface Pro 2 "A connection to the deployment share could not be made. No networking Devices were found on this machine!"

I'm trying to deploy a windows 8.1 64bit image to a Microsoft Surface Pro 2 using WDS. I am able to pxe boot the device but as soon as I click "Run the deployment wizard to install a new operating system" it comes up with the error stated above.
I have added the whole Surface driver pack into my deployment share. I'm wondering what I can do to try to get past this error.

Hi,
It is critical that the driver for the USB Ethernet Adapter is included in the boot image. When managing Windows PE drivers it recommended that you create an MDT selection profile that includes only the drivers required for Windows PE to connect to the network
and mass storage devices.
Do this then update the boot image in WDS
/ Yannick Plavonil
blog: Deploiement Windows
twitter: @yplavonil
facebook:
www.facebook.com/deploiementwindows

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...

MDT Linked Share won't replicate

I'm trying to created a linked deployment share to expand on a deployment server that is already in production.
When I replicate content from the GUI I get:
Starting MDT Linked Deployment Share Update.
Opened the linked deployment share.
Cannot find path 'LINKED001:\Selection Profiles\Everything' because it does not exist.
System.Management.Automation.CmdletInvocationException: Object reference not set to an instance of an object. ---> System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.BDD.PSSnapIn.Utility.GetFoldersForSelectionProfile(MDTObject profile, Boolean enabledFoldersOnly)
at Microsoft.BDD.PSSnapIn.ReplicateMDTContent.ProcessRecord()
at System.Management.Automation.CommandProcessor.ProcessRecord()
--- End of inner exception stack trace ---
at System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input)
at Microsoft.BDD.Wizards.ReplicateProgress.WizardProcessing()
at Microsoft.BDD.Wizards.WizardProgress.InitiateWizardProcessing()
I do in fact have a Everything profile, so something is strange. If I open the share on the remote server I have a Everything selection profile there as well.
From powershell I get this response:
VERBOSE: Starting MDT Linked Deployment Share Update.
VERBOSE: Opened the linked deployment share.
Update-MDTLinkedDS : Object reference not set to an instance of an object.
At line:1 char:1
+ Update-MDTLinkedDS -path "DS001:\Linked Deployment Shares\LINKED001" -Verbose
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Update-MDTLinkedDS], NullReferenceException
+ FullyQualifiedErrorId : System.NullReferenceException,Microsoft.BDD.PSSnapIn.ReplicateMDTContent
To verify it does in fact exist:
PS C:\Users\administrator.MURPHY> dir "DS001:\Selection Profiles"
Name
9482-AEU
All Drivers
All Drivers and Packages
All Packages
Deployments
Everything
Nothing
NUC D34010WYK
Sample
USB Boot
Anyone got any ideas about what's going on?

Well its strange, but here's how I got it to work:
Instead of creating the remote share with:
\\remote\deploymentshare$\
I used:
\\remote\e$\deploymentshare\
Sounds like a permissions issue, the share "DeploymentShare$" was set to allow Everyone r/w access.
I have the permissions set to full control for Everyone on the e:\deploymentshare directory.
Somehow the e$ UNC path works, but the hidden deploymentshare$ does not.

A connection to the deployment share could not be made - Networking device did not have a driver installed

I have a couple of HP 8200 desktops that I think might have bad nics. When I PXE boot them and start my LiteTouch, I get a Wizard error that says
A connection to the deployment share (\\mydpshare\share) could not be made. The following networking device did not have a driver installed
PCI\VEN_8086&DEV_1502&SUBSYS_1496103C&REV_04
I have that driver in MDT and it works on other HP 8200s. Looking into the Wpeinit.log, it looks like the driver loads but maybe the nic is bad:
Installing device root\kdnic X:\WINDOWS\INF\kdnic.inf succeeded
Installing device pci\ven_8086&dev_1502 X:\WINDOWS\INF\net1ic64.inf succeeded
Spent 16903ms installing network drivers
QueryAdapterStatus: no adapters found
Spent 0ms confirming network initialization; status 0x80004005
WaitForNetworkToInitialize failed; ignoring error
Has anyone seen this before?
Orange County District Attorney

Hi,
According to your description, it should be Intel NIC driver problem. I have checked HP official website, there is new NIC driver released, please access to the link below to download the NIC driver for test:
http://h20566.www2.hp.com/portal/site/hpsc/template.PAGE/public/psi/swdDetails/?sp4ts.oid=5037932&spf_p.tpst=swdMain&spf_p.prp_swdMain=wsrp-navigationalState%3Didx%253D2%257CswItem%253Dvc_111651_1%257CswEnvOID%253D4060%257CitemLocale%253D%257CswLang%253D%257Cmode%253D4%257Caction%253DdriverDocument&javax.portlet.begCacheTok=com.vignette.cachetoken&javax.portlet.endCacheTok=com.vignette.cachetoken
Roger Lu
TechNet Community Support

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

Connection to the deployment share could not be made (network driver not installed)

Hi guys! i bought the new laptop Dell Latitude E6510 and try to install the enterprise image but i got the error:
"A connection to the deployment share could not be made. The deployment will not proceed. The following networking device did not have a driver installed PCI\VEN_8086&DEV_10EA&SUBSYS_040B1028&REV_05."
I look on internet and i found out that it is the intel network card driver missing. So i get the driver from Dell website and i added this drivers in the MDT console.
Then i have updated the deployment share to rebuild the boot images. Everything went fine but i always get this error.
Am I missing something ?

I too was having the problem...
the single thing that I was forgetting is that while I was recreating & regenerating the images in the deployment workbench. I wasn't burning & booting from a CD...
because (aha) I'm clever & using Windows deployment services to boot across the network & save all that time burning CDs etc.
Doh, I didn't update the WIM that WDS was using...
Open your windows deployment services console,
expand out servers : <server name> : boot images
Right click your boot image (I have 2, one for x86 & one for x64),
choose "replace image" then navigate to your newly regenerated WIM images
(probably C:\deployment_share\boot) & choose the appropriate WIM file.
do this for any images you have, reboot your client machine & BAM, deployment goodness.
MS should really add a module for PXE boot (etc) into the deployment workbench rather than have 2x deployment solutions & use the deployment module from one & the boot module from the other.
Anyhoo, works now, must make a mental note to remember this in future...
Cheers Toolman
Thank you for this. This resolved the issue that I had.

MDT Deployment Share on USB

Similar Messages

Maybe you are looking for