11-25-2018 11:33 PM - last edited on 11-27-2018 08:34 AM by richk
I received a batch of these units to image and deploy recently however have had hit and miss results with MDT to deploy Windows 10.
This is my environment;
Server 2012 R2, MDT version 8450, ADK version 10.1.17763.1 (with PE add on).
Imaging works fine with any other unit, just this model it refused to deploy. I've injected the SCCM pack for the 20LN model and updated the deployment share/replaced the boot images.
Errors included 'Connection OK, check credentials'. 'Can not connect to deploy root'.
Debugged both those errors being able to get an IP address and credentials connect find via net share.
Anything I'm missing? I'm honestly convinced the machine is the issue.
No longer an issue per original poster - mod
01-11-2019 12:38 PM
To add on to what @Mattevy said, if you import the driver pack into the deployment tool, then add the Realtek NIC driver from the imported driver pack to the boot image. At that point, you should be able to get a network connection. I just checked the web and this model does not have a WinPE driver pack unfortunately.
01-11-2019 12:46 PM
PXE booting fine, it's the driver installs. I've tried every version. Downloaded Modern driver management from http://www.scconfigmgr.com/modern-driver-management/ and got the task sequence to finish. New problem is 802.1x profile is not connecting.
01-17-2019 04:01 PM
Just going to add to this with my experience as I couldn't find a solution that worked for me online, although basically the same issue as OP. This is definitely driver related. I did not find any mention anywhere of the final piece to the puzzle - a BIOS update.
We are using 20LNS09W00 11e 5th Gens. I am using MDT build 8450. Deploying Windows 10 1809. The issue I was having was about 50% of the units would fail to connect to the deployment share. Error was check network configuration / dhcp error. They would PXE boot just fine but would fail to connect to the deploy share once in the MDT environment. Of the ones that successfully pushed out the wim, some would fail randomly during app depployment, leaving a blank white Wizard.hta screen. Both of these issues as far as I learnt are due to the way MDT would inject the Realtek NIC driver into the wim. At the time of the initial issues, I was using the SCCM pack for version 1709.
The first way I circumvented the issues was to use DISM to force load the driver into my LiteTouchPE_x64 wim. This fixed the Deployment share connection issues in the PE environment however some would still fail during the App deployment and give me a white wizard.hta screen. I then tried force injecting my Golden image wim with the Realtek driver which did not fix the issue, I was still getting failures. I was injecting version 06/15/2018,10.028.0615.2018 which is recommended from 1709 and up. I should note that it did help, it brought my failure rate fropm 50% down to about 10-20%.
I then tried doing a BIOS update on the affected units. They come shipped with 1.17. Updating them to 1.23 fixed all remaining issues. No more connection issues and no more premature failures with white wizard screen. This could mean that doing a BIOS update could have been the solution all along.
ANyone having this issue I would recommend the following steps:
1. Add latest applicable SCCM driver pack to MDT/SCCM (1809 is now out) and update boot images
2. BIOS Update pre deployment
3. If still issues - inject driver mentioned above into boot wim
4. Inject driver into golden image
01-31-2019 01:50 PM
We are also using the Modern Driver Management (henceforth MDM) solution to solve getting our 20LNS04700 machines to image. In our case, as we have a wide variety of Yoga 11e machines in different generations, we have a problem because the 11e 5th gens have a problem where their internal name (ComputerSystemProduct.Version) doesn't match what Lenovo expects. While the Lenovo catalog says that it should be ThinkPad Yoga 11e 5th Gen, in actual fact they're all returning ThinkPad 11e 5th Gen, without the Yoga identifier. If you just have a few devices, you might be able to manually fix this by downloading a BIOS update and, from the extracted folder, running:
Winflash64 -patch -dvs "ThinkPad Yoga 11e 5th Gen"
This should fix the internal name and might fix the issue where traditional non-MDM drivers don't install as well.
Our problem is that, due to the internal name not matching, when the Driver Automation Tool from MDM downloads and added Yoga 11e drivers for our legacy models, they're matching on all of the different potential versions, including the 5th Gen. This makes the MDM script require an exact match from the internal name as well as the SKU, and the lack of matching internal name causes it to strip both the generic 11e driver as well as the specific 11e 5th Gen driver from contention, as neither one will match "ThinkPad 11e 5th Gen" internally.
If there was a better way to fix the internal name rather than manually patching it in production, that would be appreciated.
02-01-2019 08:00 AM
Thanks for the update. I will see if we can update the info that modern driver management is using to alleviate this issue. In the case of differentiating between the Yoga 11e 5th and the 11e 5th, it would be best to use the following:
SELECT * FROM Win32_ComputerSystemProduct WHERE Name LIKE '20LQ%' OR Name LIKE '20LR%'
Yoga 11e 5th
SELECT * FROM Win32_ComputerSystemProduct WHERE Name LIKE '20LM%' OR Name LIKE '20LN%'
02-01-2019 09:28 AM
02-02-2019 11:54 AM
From the other / another thread, I am seeing more information around what you are referring to. I will look into changing the recipe cards and the data that is provided from the catalog.xml that is used. Thanks for the input.