A connection to deployment share (\\mdt01\deploymentshare$) could not be made? - Help MDT 2010 RRS feed

  • Question

  • Hi All,

    first of all I inherited this as part of my new role and the documentation cross over was very poor 10-15 pages only.

    MDT: it is setup on two partition one is used for deployment and one is used for capture. I have just looked into the capture partition and folders only yet.

    I have a Lenovo M70e that i am trying to sysprep and capture process on MDT 2010 (i have used the same process to capture other Lenovo makes - successfully)

    "A connection to deployment share (\\mdt01\deploymentshare$) could not be made. cannot reach deployroot. Possible cause: Network routing error or Network configuration error. "


    When I click on abort and it brings up the CMD prompt and i do ipconfig it gives me a 169 IP address.

    I have tried to change the mdt01 to the IP of the MDT server and capture using the following (from what i have read) i.e. \\\deploymentshare$ to capture Windows XP - i updated the sysprep and unattended.txt files for that task to the IP address and even the main folder in deployment work bence's Network (UNC) path. Ii use the following Net use command "Net Use * \\\deploymentshare$ /user: domain\bdbuild" then enter the password it starts the process.

    after its done the syspref it reboots and just keep giving me this error message regardless of what i have tried above.

    Am i missing something basic?









    TimeZoneName=GMT Standard Time


    Any help and advice will be really appreciated.

    this is a beginning of various other issue i have questions for, but for the time being I have spent the best part of a week.


    Tuesday, July 23, 2013 8:58 AM

All replies

  • I would not recommend you to

    a) capture an image from a physical PC

    b) capture specific images for each and every make/model

    It sounds like to don't have any of the following: A) any DHCP on the network B) Correct network drivers for that Model

    Tim Nilimaa | Global Product Manager Enterprise Client Management at Lumagate

    Tuesday, July 23, 2013 10:30 AM
  • I would not recommend you to

    a) capture an image from a physical PC

    b) capture specific images for each and every make/model

    It sounds like to don't have any of the following: A) any DHCP on the network B) Correct network drivers for that Model

    Tim Nilimaa | Global Product Manager Enterprise Client Management at Lumagate

    Hi Tim,

    Thanks for taking the time to get back to me.

    a) Could you please let me know why i should not take an image from a physical computer when i have one to use a reference to then deploy to other same make and models. 

    b) what would you recommend? as at the moment i capture an image for each make and model by installing XP/Settings/configuring etc. and the deploy using MDT Pxe boot or burn .iso disc for end users. 

    We do have a DHCP server here at work (with mac address approval system - which it has been added to) and work fine its just this one particular PC, I have all the correct drivers for it and have also loaded them to "out of box drivers" in MDT and updated the folders.

    to me it seems like just after the sysprep process the computer is installing generic network drivers and its loosing the connection or something.

    PS: I also tried to use Imagex to capture the image and uploaded it to MDT 2010, created a task sequence and then tried to use that in MDT to deploy it but it does not execute any scripts after the sysprep restore process.


    Tuesday, July 23, 2013 11:22 AM
  • Capturing reference images from Virtual Machines is considered best practice and there are a number of reasons for this.  First, it allows you to create a Snapshot of the machine prior to being captured so that you can easily Revert it, make a change, and capture it again.  It also removes the chance that something hardware specific is installed.  Lastly, it keeps the Driver Store minimized and allows you to deploy drivers "as needed" during the Deployment Task Sequence.  This Hardware Independent Image (as they used to be called) can then be deployed to any make or model and you inject the appropriate drivers at that time.  It keeps your image lighter and cleaner and is easier to maintain, as well as results in fewer (1) image instead of one for every make / model (saving disk space and more importantly, time).

    Not having an IP is a DHCP problem and it sounds like you've resolved that by adding it's mac address.  If it was a driver issue, then it is unlikely that you would have even gotten the 169 IP.  It may also be DNS related if you are already having DHCP issues.  You may want to fully qualify the DeployRoot path in your Bootstrap.ini.

    Note:  If you are using MDT 2010, you may also want to upgrade to MDT 2012 Update 1 (and soon MDT 2013).  It's best, if possible, to be on the latest version in order to avoid older issues that have already been fixed (not saying yours is an old issue, just saying it in general).

    David Coulter | | @DCtheGeek

    Tuesday, July 23, 2013 1:07 PM

  • Hi David,

    Thanks for your time, the virtual machine process sounds perfect, do you have any more details or guides on this as it would save me a lot of time. I will be rebuilding the server from scratch so i know exactly what has been done and how it is configured but that will be in the future.

    Everything works fine before hand and only in that syspref after process is where its trying to connect to the server to upload the WIM I have issue and loose IP. I will try FQDN in bootstrap.ini and UNC and see if that works.

    We are using MDT 2010 update 1 at the moment, with the upgrade would i need to reconfigure everything or does it stay intact? 

    Sorry its the first time im using MDT.

    Tuesday, July 23, 2013 3:23 PM
  • The process for imaging and capturing the Virtual Machine is pretty much the same.  I'd suggest using Hyper-V if you have it accessible as it works really well for this.  You can either manually build the VM and then run Sysprep and Capture, or you can use a Standard Client Task Sequence as a 'Capture' Task Sequence and do the entire build end-to-end with the Task Sequence (truly automated).

    Before trying an upgrade, you should backup your MDT Share (and Database if you are using that).  If the upgrade goes well, and it normally does, then you would not need to reconfigure everything.

    No problem and welcome to the MDT Family!  Feel free to search these forums and ask questions, it's a great community and full of information.  Also check out these following resources:

    David Coulter | | @DCtheGeek

    Tuesday, July 23, 2013 4:50 PM
  • Hi David,

    Thanks for the heads up, I will read through them.

    I have tried the FQDN and IP address now and still have the same error/message.


    Thursday, July 25, 2013 11:05 AM
  • Hi Majid,

    I had the same error when I set-up one new site with MDT, found the problem is with bootstrap.ini settings.

    In your case you have mentioned that bootstrap.ini setting has following,


    but it should be as below, that has actually resolved this error message.


    Please check it would have been helped to resolve your problem



    Thursday, March 20, 2014 1:10 PM
  • Hi,

    Did you already wipe the target machine you are trying to test this on? Just perform a diskpart > select disk # > clean and then reboot. This makes sure the drive is emptied. I've experienced an issue before with the bootstrap.ini not applying the right settings. In the end it appeared a local copy of bootstrap.ini on the machine was causing the trouble.

    If a local copy of bootstrap.ini or customsettings.ini is found on your machine, left over from an unfinished or suddenly aborted deployment. This can happen, even without being notified a previous operation did not complete.

    Good luck!

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

    Thursday, March 20, 2014 8:18 PM