none
Windows MDT 2013 Update 1 & Injecting driver problems RRS feed

  • Question

  • Hello,

    Since I started working with MDT 2013 Update 1 and the Windows 10 ADK, I am experiencing problems with the model based driver injection. I already found a thread that exactly described my problem from the beginning to the end. Sadly enough this thread was closed and I am afraid I will never get a answer on my reply.

    https://social.technet.microsoft.com/Forums/en-US/18bba33c-490d-4334-a88f-af18c4c791e6/mdt-2013-update-1-not-injecting-drivers?forum=mdt

    In this thread, Keith Garner wrote a reply that this problem is not related to MDT, most likely to WinPe or Intel.

    Like Roy-Batty already wrote in the original thread, I can confirm that this issue occurs during the ZTIGather process in the new WinPE.

    System: Intel NUC D34010WYK

    In the same thread, Mirfster asked the question if the information was available after the deployment was done and all drivers were installed manually. By coincidence I am using the same workstation as the one I am trying to image. As requested, I Installed the most recent drivers and BIOS updates. To test if this would solve my problem, I did the following:

    1. Open msinfo32.exe to see if there was any system information: Empty strings

    2. Execute  “wmic computersystem get model” in command prompt: Empty string.

    3. Executed the Wbemtest.exe solution that Keith Garner provided in the original thread: Empty strings

    So it seems the problem also occurs within Windows 10 itself. To be sure I checked the information on a HP Pro 3120 MT workstation with Windows 10 64-bit installed, al the necessary information was there. This made me believe that this indeed is an Intel problem.

    With all the information gathered, I decided to open a chat support with Intel. After 1 hour of explaining, the answer was: Remember that this is an issue within the operating system, not from the hardware. The software reads the information from the hardware, why the software is not reading this information correctly is a question to the operating system developer which in this case is Microsoft.

    So I am kinda stuck on this one. Who should I contact to find out what is causing this problem?

    I also would like to point out that the driver injection during the deployment of Windows 8.1 or Windows 7 also fails. The only difference with windows 10 is that after the deployment all information is available trough msinfo32 or a WMI query in command prompt.

    All help is appreciated.

    Tuesday, October 20, 2015 8:05 PM

All replies

  • Going back to what Keith said... This is out of MDT's hands.  That being said a clever way of getting around this issue is what you are asking for.  This might work:

    So using a variation of Johan's Total Control Method (Hopefully you get the idea here)

        <step type="SMS_TaskSequence_SetVariableAction" name="DriverGroup001 with valid Model" description="" disable="false" continueOnError="false" successCodeList="0 3010">
          <defaultVarList>
            <variable name="VariableName" property="VariableName">DriverGroup001</variable>
            <variable name="VariableValue" property="VariableValue">Windows 8.1 x64\%Model%</variable>
          </defaultVarList>
          <action>cscript.exe "%SCRIPTROOT%\ZTISetVariable.wsf"</action>
          <condition>
            <expression type="SMS_TaskSequence_VariableConditionExpression">
              <variable name="Variable">Model</variable>
              <variable name="Operator">notEquals</variable>
              <variable name="Value"></variable>
            </expression>
          </condition>
        </step>
        <step type="SMS_TaskSequence_SetVariableAction" name="DriverGroup001 without valid Model" description="" disable="false" continueOnError="false" successCodeList="0 3010">
          <defaultVarList>
            <variable name="VariableName" property="VariableName">DriverGroup001</variable>
            <variable name="VariableValue" property="VariableValue">Windows 8.1 x64\NUC D34010WYK</variable>
          </defaultVarList>
          <action>cscript.exe "%SCRIPTROOT%\ZTISetVariable.wsf"</action>
          <condition>
            <expression type="SMS_TaskSequence_VariableConditionExpression">
              <variable name="Variable">Model</variable>
              <variable name="Operator">equals</variable>
              <variable name="Value"></variable>
            </expression>
          </condition>
        </step>


    Logs are very important. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/ Also if you have made customizations please mention them when asking for help.


    Tuesday, October 20, 2015 8:57 PM
    Moderator
  • Hi there,

    About a month ago after upgrading to the latest ADK and MDT releases, I also had issues with my task sequences not injecting drivers for specific makes\models. Eventually after going round in circles the solution for me was to completely redo my task sequences. Strangely this issue only seemed to affect 64 bit Task sequences\ or to be more specific 64 bit OS's.

    The current MDT\ADK has been very challenging regarding existing Task sequences, and if in doubt, you need to start again. This in many environments must be soul destroying, I am lucky that I don't have many TS's that are specific, so the changes were not that time consuming. however there are always possibilities that mistakes are made, therefore testing after the event can take a lot of your time up.

    Deployment Solutions saves everybody time except the person that is responsible for implementing the solution :)

    Ewen.

    Wednesday, October 21, 2015 12:03 AM
  • Thank you for the time to reply.

    I am already using one of his vartiations (Scenario #3 – Total Control). The only problem is that ZTIGather is unable to aquire this information trough a WMI query.

    Sample of ZTIGather.log:

    <![LOG[MAC address = B8:AE:ED:74:E2:A6]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[IP Address = 192.168.130.105]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[IP Address = fe80::8550:a437:103c:3ac1]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[Default Gateway = 192.168.130.1]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[Property IPAddress001 is now = 192.168.130.105]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[Property IPAddress002 is now = fe80::8550:a437:103c:3ac1]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[Property MacAddress001 is now = B8:AE:ED:74:E2:A6]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[Property DefaultGateway001 is now = 192.168.130.1]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[Finished getting network info]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[Getting DP info]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[Unable to determine ConfigMgr distribution point]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[Finished getting DP info]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[Getting WDS server info]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[Property WDSServer is now = SRV-WDS]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[Finished getting WDS server info]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[Property HostName is now = MININT-UBA1JSK]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[Getting asset info]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[Unable to determine asset tag via WMI.]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[Unable to determine serial number via WMI.]LOG]!><time="18:32:40.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[Unable to determine make via WMI.]LOG]!><time="18:32:42.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">
    <![LOG[Unable to determine model via WMI.]LOG]!><time="18:32:42.000+000" date="10-20-2015" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">

    After deployment of the OS, this query works fine within Windows 7 or Windows 8.1. It seems like I am only experiencing this problems using Windows 10 and the new WinPE.

    Wednesday, October 21, 2015 7:53 AM
  • Hi Jewen,

    I also would like to thank you for your the time to reply.

    The only difference in our situation is that I deleted the old MDT and ADK, I did this on purpose so things would not get screwed up. And yes, the deployment solutions are awesome. As long as you dont have to configure it yourself ;)

    Wednesday, October 21, 2015 8:02 AM
  • Using Johan's method, will windows 10 deploy to that system if you don't inject any drivers (except for network)? If so, are there Intel executables that can be used to install the missing drivers? If there are, you can use the MDT database and have those apps as mandatory for that particular make/model.

    If this post is helpful please vote it as Helpful or click Mark for answer.

    Wednesday, October 21, 2015 1:30 PM
  • Using Johan's method, will windows 10 deploy to that system if you don't inject any drivers (except for network)? If so, are there Intel executables that can be used to install the missing drivers? If there are, you can use the MDT database and have those apps as mandatory for that particular make/model.

    If this post is helpful please vote it as Helpful or click Mark for answer.


    If I understood the question correctly the particular Intel NUCs used don't return their %MAKE% %MODEL%.

    Logs are very important. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/ Also if you have made customizations please mention them when asking for help.

    Wednesday, October 21, 2015 8:05 PM
    Moderator
  • Right, duh...I'm sorry I've been out of it due to allergies. Your workaround or creating an "Intel" TS with a DriverGroup variable that points directly to a group with drivers for these types of systems should work.

    If this post is helpful please vote it as Helpful or click Mark for answer.

    Wednesday, October 21, 2015 8:16 PM
  • To be fair I suspect the NICs on these NUCs will have issue installing their drivers because of the parent child problem.  So your direction would help with that :)

    Logs are very important. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/ Also if you have made customizations please mention them when asking for help.

    Wednesday, October 21, 2015 8:28 PM
    Moderator
  • Dan_Vega,

    Thank you for your input. I did not even think about a solution like that, It is an easy workaround for this issue

    Thursday, October 22, 2015 9:16 PM
  • Ty_Glander,

    Sorry, I am having difficulties trying to understand your reply. Do you mean that the workaround Dan_Vega provided wont work?

    Thursday, October 22, 2015 9:17 PM
  • The main issue you have is that the NUC doesn't return MAKE MODEL.  What I am talking about is for the NUC is create a set MDT variable step that is along with the traditional step:

    name: DriverGroup001 without valid Model

    DriverGroup001=Windows 8.1 x64\NUC D34010WYK

    On the Options Tab

    Task Sequence Variable: Model equals <Blank> <-Really blank not what it says :)

    Then for machines with valid MAKE MODEL

    name: DriverGroup001 with valid Model

    DriverGroup001=Windows 8.1 x64\%Model%

    On the Options Tab

    Task Sequence Variable: Model not equals <Blank> <-Really blank not what it says :)

    Similar to Johan's Total Control Method 


    Logs are very important. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/ Also if you have made customizations please mention them when asking for help.



    Thursday, October 22, 2015 9:26 PM
    Moderator
  • I know this is an older post, but I am getting the exact same issue. Two different models of Intel NUC. We had MDT 2012 deploying Win 7 and recently began looking at Win 10 deployments. Whenever I use a Win 10 based MDT lite touch PE disk (beginning with 2013 U1 and also tried update 2) the WMI make and model cannot be read. (Null) With the Windows 8.1 based media it works perfectly. I'm verifying by wmic at the command prompt. It's hard to believe this is an issue with the hardware and has to have something to do with the way the WMI query is working. Modifying the task sequence to manually set the variable will not work here since there are multiple models involved.  Has anyone found a proper solution? I have updated the BIOS to the latest available version also.  
    Friday, December 9, 2016 6:11 PM
  • I had the exact same issue on any motherboard manufactured by Intel when I began to deploy Windows 10.
    I solved the issue for good by using the script AliasUserExit.vbs
    You can read the Mikael Nystrom article here

    https://deploymentbunny.com/2015/11/24/osd-deployment-deploying-intel-nuc-and-getting-drivers-and-settings-assigned-using-the-aliasuserexit-vbs-converting-product-into-modelalias/

    Saturday, December 10, 2016 5:38 PM