none
MDT 2013 Update 1 not injecting drivers RRS feed

  • Question

  • The problem involves Windows 10, Windows 10 ADK, WinPe, WMI and driver injection.

    I have been deploying Windows 7 and Windows 8.1 using the Windows 8.1 ADK and MDT 2013 without any issue for a while. I am using Johan Arwidmark total control scenario to inject the right drivers. I made a folder for each SO and a folder for each make and model of computer.

    If I run the following Powershell line in a Windows 8.1 computer I get the correct data about the manufacturer and model:
    Get-WmiObject -Class Win32_ComputerSystem

    And the query return the following data (example):
    Manufacturer        : INTEL_
    Model               : DB85FL__

    When ZTIGather.wsf runs in the MDT 2103 and queries for the make and model returns the same correct data is returned and injects the right drivers to the computer.
    I get the same result. So far, so good.

    Now the problem starts after the upgrade to Windows 2013 Update 1, Windows 10 ADK and Windows 10 SO, I noticed the following issue:
    The WMI query about manufacturer and model returns an empty string, it doesn’t matter if a run the Powershell query or the ZTIGather.wsf, and therefore MDT 2013 Update 1 fails to inject the right drivers to the computer. Now I can’t deploy any SO with the correct drivers.
    As far as I know, the problem relates to Windows 10 and the WinPE from Windows 10.
    Is this a bug?
    Is there a workaround for this problem?

    Thanks in advance.

    Tuesday, September 1, 2015 11:07 AM

Answers

  • Hey Guys,

    sorry, haven't yet created a call at microsoft. But i searched a little bit for a solution.

    To find the intel board type, try to use  the following query:

    SELECT * From Win32_BaseBoard where product like "DZ77SL%" (thats my intel board here)

    works under server 2016 and i think also with windows 10 and windows 10 adk.

    I tested this in two environments and the query does work for the INTEL Boards.


    Tuesday, November 3, 2015 8:23 AM
  • Hi everyone,

    After Reading the last post of Daniel Jelinek, I had an idea about how to find a workaround to the strange issue of the empty strings returned by the WMI query, when the query is done on a motherboard manufactured by Intel.

    First of all, some facts:

    I am using the total control method to inject the correct drivers to the deployed machine.

    When I was deploying using MDT2013 (without update 1) and Windows 8.1 ADK everything was working fine.

    The returned strings for Manufacturer and Model running on Windows 8.1 ADK for the Intel DB85FL are:

    Manufacturer: INTEL_ (notice the underscore at the end)

    Model: DB85FL__ (notice the double underscore at the end)

    The issue appeared when I updated my server to MDT2013U1 and Windows 10 ADK.

    The returned strings for Manufacturer and Model aren’t null nor empty, actually they are filled with a bunch of blank spaces.

    The WMI query that Daniel Jenilek suggested on Win32_BaseBoard  returns a string for a Product Code, that is almost the same string that the Win32_ComputerSystem returns for a Model.

    The file involved on doing the WMI query in order to get the Manufacturer and Model is ZTIGather.wsf, located on your deployment share inside the Scripts folder.

    What I did:

    I decided to dig about the logic of ZTIGather.wsf and I found where the query for the Manufacturer and Model is done and how it handles the values of the query response. After looking at the code for a while, I decided to tweak a little bit the logic about how to handle the query responses, and made them similar to the previous ones MDT2013 returned.

    So, I decided to edit the ZTIGather.wsf file to adjust to my scenario: almost 400 computers where 88% of them are sporting a motherboard manufactured by Intel, involving seven different models. Finally, the last 12% of computers are manufactured by HP.

    Before you start:

    DISCLAIMER: use this code at your own risk with no guaranties at all. I edited the ZTIGather.wsf file to solve my specific problem. This solution may not work in a different situation/scenario. Maybe you have to add/change the code according to your specific needs.

    Step by step procedure:

    1. Make a copy or backup your original ZTIGather.wsf file, just in case something goes wrong. The file is located on your deployment share inside the Scripts folder.

    2. Open the ZTIGather.wsf file with your favourite text file editor.

    3. There are a lot of functions inside ZTIGather.wsf. The one that is querying the WMI is GetAssetInfo(). Inside this function there are a lot of WMI queries. I am going to focus on 3 of them, the ones that queries for Manufacturer, Model and Product.

    The sequence of queries of ZTIGather.wsf is:

    First query: Win32_ComputerSystem for Manufacturer
    Second query: Win32_ComputerSystem for Model
    Third query: Win32_BaseBoard for Product

    I have to move the last query to the first position of the sequence, in order to have a valid Product value before the Manufacturer and Model queries. Actually the real sequence order of the queries doesn’t matter when the script is executed.

    Search for this block of code:

    ' Get the product from the Win32_BaseBoard class
    
    Set objResults = objWMI.InstancesOf("Win32_BaseBoard")
    For each objInstance in objResults
       If not IsNull(objInstance.Product) then
    	sProduct = Trim(objInstance.Product)
       End if
    Next
    If sProduct = "" then
       oLogging.CreateEntry "Unable to determine product via WMI.", LogTypeInfo
    End if
    

    Select the code and do a cut.
    Now search for this specific line of code:

    ' Get the make, model, and memory from the Win32_ComputerSystem class

    Paste the code you cut previously right ABOVE that line.

    Now the sequence order of queries is:
    First query: Win32_BaseBoard for Product
    Second query: Win32_ComputerSystem for Manufacturer
    Third query: Win32_ComputerSystem for Model

    4. Below the following line (is about the line 538 of the file):
    ' Get the make, model, and memory from the Win32_ComputerSystem class

    And inside a ‘for each’ loop, resides the logic that handles the values of Manufacturer and Model.

    The ORIGINAL code that queries for Manufacturer, Model and TotalPhysicalMemory looks like this:

    ' Get the make, model, and memory from the Win32_ComputerSystem class
    	Set objResults = objWMI.InstancesOf("Win32_ComputerSystem")
    	For each objInstance in objResults
    		If not IsNull(objInstance.Manufacturer) then
    			sMake = Trim(objInstance.Manufacturer)
    		End if
    		If not IsNull(objInstance.Model) then
    			sModel = Trim(objInstance.Model)
    		End if
    		If not IsNull(objInstance.TotalPhysicalMemory) then
    			sMemory = Trim(Int(objInstance.TotalPhysicalMemory / 1024 / 1024))
    		End if
    	Next
    

    Here is where I need to tweak the code to return a valid value of Manufacturer and Model for the Intel motherboards. I don’t care about the query for the TotalPhysicalMemory, as I know is working fine.

    5. The variable sMake, carries the string of the Manufacturer and the code checks for a not null value and then do a string trim, removing all the spaces. When the query is done on a motherboard NOT manufactured by Intel, the variable sMake is filled with the correct value of Manufacturer, but when the query is done on a motherboard manufactured by Intel, the string is filled with blank spaces instead, so the trim function on the string on sMake makes the string empty. In my scenario if the string is empty, it only means one thing: I am dealing with an Intel motherboard. This leads to a binary decision:

    Option 1: sMake contains a valid string: do nothing, it is NOT a motherboard made by Intel, and sMake contains a valid Manufacturer

    Option 2: sMake is empty: IT IS a motherboard made by Intel

    So, I added the logic to assign to the sMake variable the value “INTEL_”, because that is the value I had before the upgrade and to maintain the structure of drivers I already have created on MDT. You should adjust/change the value according to your needs.

    This is the part of the ORIGINAL code that needs to be modified:

    If not IsNull(objInstance.Manufacturer) then
        sMake = Trim(objInstance.Manufacturer)
    End if
    

    This is the MODIFIED code:

    If not IsNull(objInstance.Manufacturer) then
        sMake = Trim(objInstance.Manufacturer)
        ' if sMake is an empty string, it means that the motherboard is made by Intel,
        ' so I manually assign the value INTEL_ to sMake 
        If sMake= "" then
    	  sMake = "INTEL_"
        End if
    End if
    

    6. Right now, I have a valid value in sMake for the Manufacturer. Now it is time to deal with the logic to get the right Model. If sMake is equal to “INTEL_”, it means que sModel carries and empty string. At this point I already have the Product value on the sProduct variable. As I stated before, the Product and Model values for the Intel motherboards are more or less the same. So the logic will be: if we are dealing with an Intel motherboard, I need to change a little bit the value of Product to assign the new value to sModel. In my case, I need to add also two underscore signs after the Product value to get the same result I got before the upgrade. You should adjust/change the value according to your needs.

    The part of the ORIGINAL code:

    If not IsNull(objInstance.Model) then
    	sModel = Trim(objInstance.Model)
    End if
    

    The MODIFIED code:

    If not IsNull(objInstance.Model) then
    	sModel = Trim(objInstance.Model)
    
            ' if sMake equals INTEL_, I change the value of sModel according to my needs
     	If sMake = "INTEL_" then
    	      sModel = sProduct & "__"
     	End If
    
    End If
    

    7. The whole piece of code all together:

    ' Get the product from the Win32_BaseBoard class
    
    Set objResults = objWMI.InstancesOf("Win32_BaseBoard")
    
    For each objInstance in objResults
     	If not IsNull(objInstance.Product) then
    		sProduct = Trim(objInstance.Product)
    	End if
    Next
    
    If sProduct = "" then
    	oLogging.CreateEntry "Unable to determine product via WMI.", LogTypeInfo
    End if
    
    ' Get the make, model, and memory from the Win32_ComputerSystem class
    
    Set objResults = objWMI.InstancesOf("Win32_ComputerSystem")
    
    For each objInstance in objResults
    	If not IsNull(objInstance.Manufacturer) then
    	    sMake = Trim(objInstance.Manufacturer)
                ' if sMake is an empty string, it means that the motherboard is made by Intel,
                ' so I manually assign the value INTEL_ to sMake 
    	    If sMake= "" then
    	       sMake = "INTEL_"
    	    End if
    
    	End if
            If not IsNull(objInstance.Model) then
    		 sModel = Trim(objInstance.Model)
    
                    ' if sMake equals INTEL_, I change the value of sModel according to my needs
    		 If sMake = "INTEL_" then
    		     sModel = sProduct & "__"
     		End If
    	End if
      	If not IsNull(objInstance.TotalPhysicalMemory) then
    		sMemory = Trim(Int(objInstance.TotalPhysicalMemory / 1024 / 1024))
            End if
    Next
    

    8. We are done editing ZTIGather.wsf. Save the file.

    9. Update your deployment share. The process will build a new set of WIM and ISO files for your deployment. The WMI queries now will return the proper values for Manufacture and Model, and the total control scenario to inject the right drivers will work properly again.

    10. Happy deployment.

    Thanks a lot to all of you that help me, and specially to Daniel Jelinek for inspire me with the idea to make this workaround for the problem.

    • Marked as answer by Roy-Batty Thursday, November 5, 2015 12:37 PM
    Thursday, November 5, 2015 12:34 PM

All replies

  • It's possible it's a bug. I posted here https://social.technet.microsoft.com/Forums/en-US/5d836b1e-cbee-48c8-b0eb-7060c71cddc9/see-warning-final-adk-and-mdt-2013-update-1-download-locations?forum=mdt  some links on bugs that have so far been discovered.

    If you create a test deployment share and boot image, see if you can make a query. This would be to test if the bug is with MDT out of the box or if there's something from your previous share that broke after the upgrade. I'm curious too because I use a modelalias user exit script for driver injection, I'd hate for it to break when I move to the next MDT version.


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

    Tuesday, September 1, 2015 1:17 PM
  • Thanks for the answer. Following the link I found this:

    =============

    NOTE: we are also aware of reports of similar issues regarding Windows PowerShell and WMI components in Windows PE (as well as some functional issues with these components). We have not been able to reproduce these issues, and are working with the Windows team to investigate further. If you have a reproducible issue with these components in Windows PE, please open a case with Microsoft Support to troubleshoot.

    ==============

    So it seems that there are some issues on the WMI components. Anyway the easy way to test “this bug” is to install a clean copy of Windows 10. Launch a powershell command prompt and write the following line:

    Get-WmiObject -Class Win32_ComputerSystem

    You will get the manufacturer and model returned as a couple of empty strings. I think that is related to Windows 10 itself. WinPE is created from Windows 10 and inherits that behavior.

    Get-WmiObject -Class Win32_ComputerSystem, runs just fine on Windows 7 and Windows 8.1

    Tuesday, September 1, 2015 5:03 PM
  • Well I have a test machine with 10 Pro (10.0.10240) and powershell spit out the right information for me. It's probably just a PE issue.

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

    Tuesday, September 1, 2015 5:08 PM
  • Thanks again for your answer.

    After you confirm me that you are able to get the right information, I did more research and I found that the bug shows exclusively on Intel based motherboards.

    The thing is that almost every single machine at work (about 400 computers) has an Intel motherboard sporting different chipsets, so I was confused about the behavior of the Get-WmiObject -Class Win32_ComputerSystem line, because it always fails on Intel motherboards.

    I ran the same line on non-Intel motherboard based computers, and it works perfectly. So I think now that it is an Intel-Windows 10 combo issue.

    How to solve this issue?

    Any help/ideas?

    Tuesday, September 1, 2015 5:30 PM
  • For what it's worth, it worked on a Dell OptiPlex 990. Intel i5-2400 with Radeon HD 5450 video card. It might be more complex than just running on Intel based boards. I can't really help you past that, because I'm avoiding Update 1 until they re-release it later this month and even then I'm going to wait until I hear there are no show stopping bugs.

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

    Tuesday, September 1, 2015 7:03 PM
  • Roy-Batty

    I am confused by your description of the error. I have not encountered any problems in this area, and your copy/paste of the TechNet blog is unrelated to WMI query issues decribed here.

    Additionally, I'm unclear as to what you mean by "Intel based motherboards" do you mean motherboards with an Intel CPU and northbridge chipset like the SuperMicro X10SAE? or do you mean motherboards manufactured by Intel itself, like INTEL DB85FL motherboard.

    Additionally I don't see any logs or output from failed runs. You can also run wbemtest.exe on WinPE to query Win32_ComputerSystem without PowerShell.

    IF you still need help, please upload your bdd.log to a public site like onedrive and share the link.


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Tuesday, September 1, 2015 7:08 PM
    Moderator
  • I am sorry about the confusion of the error. English is not my mother language and it can be difficult to express what I really mean.

    The error shows up on motherboards manufactured by Intel, like the DB85FL. At work I have at least 7 different motherboards, all made by Intel. When I was doing several tests about this bug, I was choosing different computers, but all of them have an Intel motherboard inside, that’s why I assumed and stated that the error appears all the time.

    This morning I deployed a Windows 10 image to an HP Computer (non-Intel motherboard) and a computer with the Intel DB85FL motherboard.

    On the HP Computer the task went fine, driver injection was ok and no problems at all. The WMI query of the MDT 2013 Update 1 worked perfectly, detected the right manufacturer and model and injected the drivers correctly.

    On the Intel DB85FL the task finished ok, but no driver injection, the WMI query returned empty strings for both manufacturer and model.

    Also as Keith Garner suggested, I did a run of the WMI query executing wbemtest.exe on the Intel DB85FL motherboard running Windows 10 and WinPE with the same exact result: manufacturer and model showed empty strings.

    I am sharing a link to both BDD.LOG, one for the Intel DB85FL and one for the HP Computer.

    https://onedrive.live.com/redir?resid=7B73BBD2767EC7BE%21107

    Thanks for your help trying to solve this strange issue.

    Wednesday, September 2, 2015 10:44 AM
  • Long shot, but have you tried to update the BIOS/Firmware on those systems to see if this may resolve the issue?

    Sorry I don't have a similar system to test against.

    Wednesday, September 2, 2015 11:17 AM
  • Yes, I did upgrade the bios but the problem is still there: empty strings anyway.
    Wednesday, September 2, 2015 11:39 AM
  • Looking at the log, I can see other WMI queries are returned properly. I don't have any systems that use boards directly from Intel, so I can't test further.

    Curious if you were to make a Windows 10 disk or bootable flash drive using Microsoft's ISO and then setup an "Intel" computer with that, I wonder if the queries would still fail. In other words could it be your image?


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

    Wednesday, September 2, 2015 1:40 PM
  • Interesting...  I wonder if the issue is with the underscore characters?

    Out of curiosity if you run the WMIC equivalent what does it show?

    Command: WMIC ComputerSystem Get Model
    Wednesday, September 2, 2015 2:38 PM
  • Thanks a lot to all of you that are trying to help me.
    Just a reminder: everything was working fine before I upgraded my Windows 2012 R2 server to MDT 2013 Update 1 and the Windows 10 ADK from MDT 2013 and Windows 8.1 ADK.

    Dan_Vega
    Yes. The fails appears anytime in the Intel DB85FL. It makes no difference if I install a clean copy of Windows 10, deploy a Windows 10 image using a task sequence in MDT 2013 Update 1, or booting the machine using WinPE. At home I have an old Intel DG43GT motherboard running Windows 10 Pro, and it gives me back the empty strings when I query for manufacturer and model. At work I have 7 different models of Intel motherboards and all of them have the same behaviour. So I am thinking that is an issue focussed on Intel motherboards. This is an odd thing since I never had a problem with those Intel motherboards.

    Mirfster
    I ran the WMIC ComputerSystem Get Model on the Intel DB85FL, and the answer is always the same: an empty string, or blank spaces.

    Wednesday, September 2, 2015 6:34 PM
  • That is weird, especially since you state that it worked prior to MDT 2013 Update 1 and ADK 10.  Also, it is not working returning values with a native install of Win 10.

    Can you try to determine if the Intel Motherboard is a "Branded Retail" version of their board?

    https://downloadcenter.intel.com/download/17730/Intel-Board-ID-Tool

    Per Intel:

    If the ID Tool detects a branded retail Intel® Desktop Board, the resulting status window will display the board model, board version (AA#), BIOS version and operating system version.

    If the ID Tool does not detect a branded retail Intel® Desktop Board, the following message will display: "No Intel Desktop Board was detected in this system". If you get the message that an Intel desktop board was not detected, you likely have an OEM desktop board.

    Wednesday, September 2, 2015 8:08 PM
  • It could also be a missing system driver that is required to access the SMBIOS, or a bad BIOS.

    However you should be able to open wbemtest.exe within WinPE, and see the results.

    wbemtest.exe --> "Connect" --> root\cimv2 "Connect" --> "Enum Instances" -->
    type "Win32_BIOS" --> Select instances --> "Show MOF"

    wbemtest.exe --> "Connect" --> root\cimv2 "Connect" --> "Enum Instances" -->
    type "Win32_ComputerSystem" --> Select instances --> "Show MOF"

    If you *can* see the make and model from Wbemtest, then it's a MDT bug, if you can't see make and model, it's a Intel or Windows ADK bug. You should contact the company where you purchased the machine, or call Microsoft "ADK" support to resolve the issue.


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Wednesday, September 2, 2015 8:32 PM
    Moderator
  • I have been doing what you suggested. I executed the Intel Board ID Tool along with wbemtest.exe and I grabbed the screen to show you all the results. All Intel manufactured boards suffers the same issue when running Windows 10 or WinPE.

    I also grabbed the screen of the Intel DB85FL running Windows 8.1 and it run smoothly and show both strings, manufacturer and model.

    Ok. So, what’s the next thing/step I can do to solve this issue?

    Thursday, September 3, 2015 11:10 AM
  • Wondering if the issue may be that you are using UEFI? 

    Old posting regarding detection of Model via WMI on Intel MotherBoard with UEFI enabled:

    https://www.autoitscript.com/forum/topic/150866-strange-wmi-problem-on-intel-hardware/

    Poster stated that their workaround was to disable UEFI in the BIOS


    Might want to see if you can set the BIOS to boot Legacy first and then UEFI second or just Legacy to see if that makes a difference.
    • Edited by Mirfster Thursday, September 3, 2015 12:18 PM Added content
    Thursday, September 3, 2015 11:43 AM
  • I removed the UEFI boot from bios on the Intel DB85FL, and no luck at all, empty strings all the time. As a side note, the Intel DG35EC is very old and doesn’t have any UEFI options.
    Thursday, September 3, 2015 12:47 PM
  • I know the original issue is that the system drivers are not getting installed due to WMI detection of system model, however I am wondering if there is a driver that is missing from WinPE and Windows 10 that is needed to get the desired Model information.

    The Windows 10 machines that you tried the queries on (once Windows 10 was installed), have you installed all the drivers manually?  If not, could you try that, reboot, make sure everything is shown correctly in Device Manager and then see if you get a Model?

    If you already tried that, then let us know as well.

    Thursday, September 3, 2015 1:04 PM
  • @Mirfster - Yes, a missing winpe driver is most likely an issue.

    @Roy-Batty - At this point you have shown that this is not an MDT issue, this is a WinPE or an Intel problem. If you can't query the WMI objects from WinPE, then neither can MDT.

    Best to escalate through Intel, or open a support case with Microsoft.


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    • Marked as answer by Roy-Batty Thursday, September 3, 2015 5:51 PM
    • Unmarked as answer by Roy-Batty Thursday, November 5, 2015 12:38 PM
    Thursday, September 3, 2015 5:25 PM
    Moderator
  • Yes, I agree with Keith Garner. It isn’t a MDT problem. The reason a posted my question in this forum, was that MDT was involved and affects my whole deployments. I was searching the internet for a while, looking for some information about this issue and I ended empty handed.

    I am going to do what Keith Garner suggested, but since it is the first time I have to deal with something like this, I am pretty lost about where to start. Can someone point me how to escalate through Intel, or open a support case with Microsoft?

    Thanks to all of you that helped and suggested me to do and try a lot of things in order to find what was going on.

    Thursday, September 3, 2015 5:51 PM
  • Same problem here, are there any news? 

    WMI working fine in Windows 8.1 PE but not in Windows 10.


    Friday, October 9, 2015 8:37 AM
  • @Daniel Jelinek

    I was thinking for a while I was he only one in this planet with this strange issue.

    Latest news from me:

    I wasn’t able to open a case with Microsoft, but I contacted my motherboard provider and told him about the problem. After checking out that the WMI bug on Windows 10 is there, he sent an email four days ago to Intel on my behalf, with all the documentation I was able to gather about the issue.

    Right now, I am waiting to hear any news from Intel.

    Friday, October 9, 2015 1:33 PM
  • Hey Roy,

    thanks for the news, so keep me updated if you get anything new. 

    If it's helpful, i can try to open a case at microsoft, we have free support calls....

    But i have no hope that this will bring up anything helpful, my experiences with the microsoft support are not very good..... ;-(

    Best Regards....

    Friday, October 9, 2015 1:36 PM
  • Hey Roy,

    Just wondering if you got any answer from intel. I am experiencing the exact same problem! Since the update I am getting empty strings on my Intel NUC D34010WYK system.

    Monday, October 19, 2015 7:29 PM
  • @Guido Schuit

    I am still waiting to hear any news from Intel.

    As a workaround, in case you are interested, I am writing new task sequences using profiles using scenario #2 from Johan Arwidmark. I created one task sequence and profile combo for each one of the seven different Intel motherboards my computers have. This scenario is not as good as the total control scenario, but I think that is the best thing to do right now until this issue is fixed.

    Wednesday, October 21, 2015 6:02 PM
  • @Daniel Jelinek

    After reading the thread Guido Schuit open here

    https://social.technet.microsoft.com/Forums/en-US/9a9cc1ba-d6f2-4e20-841d-c8b809647b66/windows-mdt-2013-update-1-injecting-driver-problems?forum=mdt

    and read the answer from Intel, I wonder if you have hay news from the Microsoft support team.

    Wednesday, October 21, 2015 6:13 PM
  • Hey Guys,

    sorry, haven't yet created a call at microsoft. But i searched a little bit for a solution.

    To find the intel board type, try to use  the following query:

    SELECT * From Win32_BaseBoard where product like "DZ77SL%" (thats my intel board here)

    works under server 2016 and i think also with windows 10 and windows 10 adk.

    I tested this in two environments and the query does work for the INTEL Boards.


    Tuesday, November 3, 2015 8:23 AM
  • Hi everyone,

    After Reading the last post of Daniel Jelinek, I had an idea about how to find a workaround to the strange issue of the empty strings returned by the WMI query, when the query is done on a motherboard manufactured by Intel.

    First of all, some facts:

    I am using the total control method to inject the correct drivers to the deployed machine.

    When I was deploying using MDT2013 (without update 1) and Windows 8.1 ADK everything was working fine.

    The returned strings for Manufacturer and Model running on Windows 8.1 ADK for the Intel DB85FL are:

    Manufacturer: INTEL_ (notice the underscore at the end)

    Model: DB85FL__ (notice the double underscore at the end)

    The issue appeared when I updated my server to MDT2013U1 and Windows 10 ADK.

    The returned strings for Manufacturer and Model aren’t null nor empty, actually they are filled with a bunch of blank spaces.

    The WMI query that Daniel Jenilek suggested on Win32_BaseBoard  returns a string for a Product Code, that is almost the same string that the Win32_ComputerSystem returns for a Model.

    The file involved on doing the WMI query in order to get the Manufacturer and Model is ZTIGather.wsf, located on your deployment share inside the Scripts folder.

    What I did:

    I decided to dig about the logic of ZTIGather.wsf and I found where the query for the Manufacturer and Model is done and how it handles the values of the query response. After looking at the code for a while, I decided to tweak a little bit the logic about how to handle the query responses, and made them similar to the previous ones MDT2013 returned.

    So, I decided to edit the ZTIGather.wsf file to adjust to my scenario: almost 400 computers where 88% of them are sporting a motherboard manufactured by Intel, involving seven different models. Finally, the last 12% of computers are manufactured by HP.

    Before you start:

    DISCLAIMER: use this code at your own risk with no guaranties at all. I edited the ZTIGather.wsf file to solve my specific problem. This solution may not work in a different situation/scenario. Maybe you have to add/change the code according to your specific needs.

    Step by step procedure:

    1. Make a copy or backup your original ZTIGather.wsf file, just in case something goes wrong. The file is located on your deployment share inside the Scripts folder.

    2. Open the ZTIGather.wsf file with your favourite text file editor.

    3. There are a lot of functions inside ZTIGather.wsf. The one that is querying the WMI is GetAssetInfo(). Inside this function there are a lot of WMI queries. I am going to focus on 3 of them, the ones that queries for Manufacturer, Model and Product.

    The sequence of queries of ZTIGather.wsf is:

    First query: Win32_ComputerSystem for Manufacturer
    Second query: Win32_ComputerSystem for Model
    Third query: Win32_BaseBoard for Product

    I have to move the last query to the first position of the sequence, in order to have a valid Product value before the Manufacturer and Model queries. Actually the real sequence order of the queries doesn’t matter when the script is executed.

    Search for this block of code:

    ' Get the product from the Win32_BaseBoard class
    
    Set objResults = objWMI.InstancesOf("Win32_BaseBoard")
    For each objInstance in objResults
       If not IsNull(objInstance.Product) then
    	sProduct = Trim(objInstance.Product)
       End if
    Next
    If sProduct = "" then
       oLogging.CreateEntry "Unable to determine product via WMI.", LogTypeInfo
    End if
    

    Select the code and do a cut.
    Now search for this specific line of code:

    ' Get the make, model, and memory from the Win32_ComputerSystem class

    Paste the code you cut previously right ABOVE that line.

    Now the sequence order of queries is:
    First query: Win32_BaseBoard for Product
    Second query: Win32_ComputerSystem for Manufacturer
    Third query: Win32_ComputerSystem for Model

    4. Below the following line (is about the line 538 of the file):
    ' Get the make, model, and memory from the Win32_ComputerSystem class

    And inside a ‘for each’ loop, resides the logic that handles the values of Manufacturer and Model.

    The ORIGINAL code that queries for Manufacturer, Model and TotalPhysicalMemory looks like this:

    ' Get the make, model, and memory from the Win32_ComputerSystem class
    	Set objResults = objWMI.InstancesOf("Win32_ComputerSystem")
    	For each objInstance in objResults
    		If not IsNull(objInstance.Manufacturer) then
    			sMake = Trim(objInstance.Manufacturer)
    		End if
    		If not IsNull(objInstance.Model) then
    			sModel = Trim(objInstance.Model)
    		End if
    		If not IsNull(objInstance.TotalPhysicalMemory) then
    			sMemory = Trim(Int(objInstance.TotalPhysicalMemory / 1024 / 1024))
    		End if
    	Next
    

    Here is where I need to tweak the code to return a valid value of Manufacturer and Model for the Intel motherboards. I don’t care about the query for the TotalPhysicalMemory, as I know is working fine.

    5. The variable sMake, carries the string of the Manufacturer and the code checks for a not null value and then do a string trim, removing all the spaces. When the query is done on a motherboard NOT manufactured by Intel, the variable sMake is filled with the correct value of Manufacturer, but when the query is done on a motherboard manufactured by Intel, the string is filled with blank spaces instead, so the trim function on the string on sMake makes the string empty. In my scenario if the string is empty, it only means one thing: I am dealing with an Intel motherboard. This leads to a binary decision:

    Option 1: sMake contains a valid string: do nothing, it is NOT a motherboard made by Intel, and sMake contains a valid Manufacturer

    Option 2: sMake is empty: IT IS a motherboard made by Intel

    So, I added the logic to assign to the sMake variable the value “INTEL_”, because that is the value I had before the upgrade and to maintain the structure of drivers I already have created on MDT. You should adjust/change the value according to your needs.

    This is the part of the ORIGINAL code that needs to be modified:

    If not IsNull(objInstance.Manufacturer) then
        sMake = Trim(objInstance.Manufacturer)
    End if
    

    This is the MODIFIED code:

    If not IsNull(objInstance.Manufacturer) then
        sMake = Trim(objInstance.Manufacturer)
        ' if sMake is an empty string, it means that the motherboard is made by Intel,
        ' so I manually assign the value INTEL_ to sMake 
        If sMake= "" then
    	  sMake = "INTEL_"
        End if
    End if
    

    6. Right now, I have a valid value in sMake for the Manufacturer. Now it is time to deal with the logic to get the right Model. If sMake is equal to “INTEL_”, it means que sModel carries and empty string. At this point I already have the Product value on the sProduct variable. As I stated before, the Product and Model values for the Intel motherboards are more or less the same. So the logic will be: if we are dealing with an Intel motherboard, I need to change a little bit the value of Product to assign the new value to sModel. In my case, I need to add also two underscore signs after the Product value to get the same result I got before the upgrade. You should adjust/change the value according to your needs.

    The part of the ORIGINAL code:

    If not IsNull(objInstance.Model) then
    	sModel = Trim(objInstance.Model)
    End if
    

    The MODIFIED code:

    If not IsNull(objInstance.Model) then
    	sModel = Trim(objInstance.Model)
    
            ' if sMake equals INTEL_, I change the value of sModel according to my needs
     	If sMake = "INTEL_" then
    	      sModel = sProduct & "__"
     	End If
    
    End If
    

    7. The whole piece of code all together:

    ' Get the product from the Win32_BaseBoard class
    
    Set objResults = objWMI.InstancesOf("Win32_BaseBoard")
    
    For each objInstance in objResults
     	If not IsNull(objInstance.Product) then
    		sProduct = Trim(objInstance.Product)
    	End if
    Next
    
    If sProduct = "" then
    	oLogging.CreateEntry "Unable to determine product via WMI.", LogTypeInfo
    End if
    
    ' Get the make, model, and memory from the Win32_ComputerSystem class
    
    Set objResults = objWMI.InstancesOf("Win32_ComputerSystem")
    
    For each objInstance in objResults
    	If not IsNull(objInstance.Manufacturer) then
    	    sMake = Trim(objInstance.Manufacturer)
                ' if sMake is an empty string, it means that the motherboard is made by Intel,
                ' so I manually assign the value INTEL_ to sMake 
    	    If sMake= "" then
    	       sMake = "INTEL_"
    	    End if
    
    	End if
            If not IsNull(objInstance.Model) then
    		 sModel = Trim(objInstance.Model)
    
                    ' if sMake equals INTEL_, I change the value of sModel according to my needs
    		 If sMake = "INTEL_" then
    		     sModel = sProduct & "__"
     		End If
    	End if
      	If not IsNull(objInstance.TotalPhysicalMemory) then
    		sMemory = Trim(Int(objInstance.TotalPhysicalMemory / 1024 / 1024))
            End if
    Next
    

    8. We are done editing ZTIGather.wsf. Save the file.

    9. Update your deployment share. The process will build a new set of WIM and ISO files for your deployment. The WMI queries now will return the proper values for Manufacture and Model, and the total control scenario to inject the right drivers will work properly again.

    10. Happy deployment.

    Thanks a lot to all of you that help me, and specially to Daniel Jelinek for inspire me with the idea to make this workaround for the problem.

    • Marked as answer by Roy-Batty Thursday, November 5, 2015 12:37 PM
    Thursday, November 5, 2015 12:34 PM
  • I'm happy that i could inspire you.... :-)

    I used the query without mdt as a filter in the task sequence step, so it was a little bit easier for me.

    Have fun.

    Daniel

    Thursday, November 5, 2015 12:48 PM
  • Ah, just forgot something.

    Would be great if you can mark my post as part of the answer, perhaps some users without MDT can use the new query for their deployment and so they can find the answer on top of the thread....

    Thursday, November 5, 2015 12:55 PM