locked
Database Network Drive mapping during MDT Build RRS feed

  • Question

  • Edit: Wow..it looks like most of my question got cut off.  I blame the new forums.

    I'm getting the below errors during my MDT build process.  I think its because of the SQL Share information inside of MDT.  Will these errors go away if I remove this?  I'll post my CS.ini tomorrow when I'm back at work and don't have to do it via RDP.

    Validating connection to \\devsqldbmdt.DOMAIN.dev\SQLShareDEV$ ZTIGather 6/27/2013 2:38:49 AM 0 (0x0000)

    Unable to connect to share: The network name cannot be found.
    ( 0x80070043 ) , trying to connect without username.  ZTIGather 6/27/2013 2:38:49 AM 0 (0x0000)

    The network name cannot be found.
     ZTIGather 6/27/2013 2:38:49 AM 0 (0x0000)

    Unable to connect to \\devsqldbmdt.DOMAIN.dev\SQLShareDEV$.  Sleeping for 5 seconds. ZTIGather 6/27/2013 2:38:49 AM 0 (0x0000)

    Unable to connect to share: The network name cannot be found.
    ( 0x80070043 ) , trying to connect without username.  ZTIGather 6/27/2013 2:38:54 AM 0 (0x0000)

    The network name cannot be found.
     ZTIGather 6/27/2013 2:38:54 AM 0 (0x0000)

    I'm not sure where to proceed from here.  Should I remove the SQL Share from my Database Connection string?


    • Edited by Graeme Bray [MSFT] Thursday, June 27, 2013 3:31 AM Forums cut off half my post.
    Thursday, June 27, 2013 2:29 AM

All replies

  • The SQL Share should be pointed at your MDT Deployment Share.  Is your Deployment Share called SQLShareDEV$?


    David Coulter | http://DCtheGeek.blogspot.com | @DCtheGeek

    Thursday, June 27, 2013 4:04 AM
    Answerer
  • Let me elaborate on my original post..since I'm at work now and I can post my CS.ini.

    I have two servers based on how we would go to production.

    DEVMDT001

    DEVSQL508

    The MDT server hosts WDS and the Deployment Share.  SQL is on the remote server with some of our other infrastructure applications.  This is how our SQL team wants to support SQL rather than SQL Express.

    How do I need to set up the SQL Share (and do I need to?)

    Heres my CS.ini (with some editing done.)

    [Settings] Priority=DefaultGateway, CSettings, CRoles, Locations, LSettings, MMSettings, RSettings, RApps, Init, ByIsVM, Default Properties=SQLServerName, SQLDatabase, BIOSVersion, SMBIOSBIOSVersion, ProductVersion, ScottServerConfig, SkipScottComputerSettings, SkipDRACSettings, DRACConnection, DRACDHCP, DRACIP, DRACSubnet, DRACGateway, MyCustomProperty [DefaultGateway] 172.30.23.1=DEV [DEV] SQLServerName=devsqldbmdt.DOMAIN.dev SQLDatabase=MDTDEV [CSettings] SQLServer=%SQLServerName% Database=%SQLDatabase% Netlib=DBNMPNTW

    SQLShare=DeploymentShare$ Table=ComputerSettings Parameters=UUID, AssetTag, SerialNumber, MacAddress ParameterCondition=OR [CRoles] SQLServer=%SQLServerName% Database=%SQLDatabase% Netlib=DBNMPNTW Table=ComputerRoles Parameters=UUID, AssetTag, SerialNumber, MacAddress ParameterCondition=OR [Locations] SQLServer=%SQLServerName% Database=%SQLDatabase% Netlib=DBNMPNTW

    SQLShare=DeploymentShare$ Table=Locations Parameters=DefaultGateway [LSettings] SQLServer=%SQLServerName% Database=%SQLDatabase% Netlib=DBNMPNTW

    SQLShare=DeploymentShare$ Table=LocationSettings Parameters=DefaultGateway [MMSettings] SQLServer=%SQLServerName% Database=%SQLDatabase% Netlib=DBNMPNTW

    SQLShare=DeploymentShare$ Table=MakeModelSettings Parameters=Make, Model [RSettings] SQLServer=%SQLServerName% Database=%SQLDatabase% Netlib=DBNMPNTW

    SQLShare=DeploymentShare$ Table=RoleSettings Parameters=Role [RApps] SQLServer=%SQLServerName% Database=%SQLDatabase% Netlib=DBNMPNTW

    SQLShare=DeploymentShare$ Table=RoleApplications Parameters=Role Order=Sequence



    Thursday, June 27, 2013 1:38 PM
  • Now I'm with you.... so since it (SQL) is on a different server than yes, the SQLShare you point to will need to be on the SQL server.  My comment previously was under the assumption that your SQL was on your MDT Server.  Also, I noticed that you didn't specify an Instance value anywhere in your CustomSettings.ini.


    David Coulter | http://DCtheGeek.blogspot.com | @DCtheGeek

    Thursday, June 27, 2013 1:59 PM
    Answerer
  • Thanks David.

    So can I call the Share MDTSQLShare$ on the SQL server?  If so, will this cause issues with the deployment?  I tried this and then did a test deployment on a VM, however it failed with some ZTIDriver issue, which I haven't had before.

    What is the purpose of the share (is it needed?)

    The Instance is the default instance on the SQL system, so nothing was need to be configured there.

    Thursday, June 27, 2013 2:29 PM
  • The share is just needed to establish a secure connection with the SQL Server, and from what I can tell in the scripts (ZTIDataAccess.vbs), it is only really needed if Netlib=DBNMPNTW, which is what you are using.


    David Coulter | http://DCtheGeek.blogspot.com | @DCtheGeek

    Thursday, June 27, 2013 5:07 PM
    Answerer
  • I ran into the same issue where MDT and SQL are installed on separate servers. MDT assumes that SQL is installed on the same sever. In order to get MDT to work I had to create a share on the SQL server (it doesn’t matter what drive) just make sure that you name it the same as you MDT share. There should be one SQL share for each MDT deployment share.

    For example: I created an MDT deployment share which was shared as ‘MDT-Lab$’ (\\MDT-Server\MDT-Lab$) than I created another share on the SQL server and shared it as ‘MDT-Lab$’ (\\SQL-Server\MDT-Lab$) these two shares must have the same name. MDT maps 2 drives, the first drive is for the MDT files and the second for the SQL connection. You don’t need to have any files on the SQL share but they are required for MDT to work. Make sure to set the appropriate permissions for the accounts that are going to be used.
     
    The ‘C:\MININT\SMSOSD\OSDLOGS\ZTIGather.log’ file help me troubleshoot this issue. This is where I found out that MDT was trying to connect to a share on the SQL server that did not exist. The lines that got my attention were where it read ‘Unable to connect to \\SQL-Server\MDT-Lab$.’ and ‘Property DeployRoot is now = \\MDT-Server\MDT-Lab$.’

    The value set in the ‘SQL share’ is put into a variable which is also used as the MDT share. Which means that if your DMT share is different than your SQL share one of them if going to fail which why it is important that you set the two share names the same to avoid any connection issues to either the MDT share or the SQL share.

    My solution was to setup the following shares:
    * \\MDT-Server\MDT-Lab$ (MDT deployment files)
    * \\SQL-Server\MDT-Lab$ (It could an empty folder just make sure that the account you’re using for MDT has access to this share)
    * \\MDT-Server\MDT-Prod$ (MDT deployment files)
    * \\SQL-Server\MDT-Prod$ (It could an empty folder just make sure that the account you’re using for MDT has access to this share)

    I could provide more details upon requests. I hope this helps.
    Wednesday, April 23, 2014 11:05 PM