Archive for category drivers
During my project to upgrade all our Windows 7 Enterprise SP1 (64bit) devices to Windows 10 Enterprise 1809 (64bit), I ran into a compatibility issue during the task sequence. Windows 7 video drivers were detected as incompatible during the in-place upgrade to Windows 10, so I had to find a way to remove the drivers during the SCCM task sequence.
This is the batch file code I used to disable, then remove video drivers from the task sequence.
REM Driver is disabled
devcon disable =display
REM Driver is removed here
devcon remove =display
REM reg add command replaces whatever value is in the SearchOrderConfig with the appropriate value to tell the system NOT to go to windows update for driver updates
REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching /t REG_DWORD /v SearchOrderConfig /d 0x0 /f
REM Driver package is removed here
FOR /F “tokens=4 delims= ” %%A IN (‘devcon driverfiles ^=display ^| FINDSTR “Driver installed from”‘) DO devcon.exe dp_delete -f %%A
The following shows where in the task sequence I add the video driver removal step. Also, note that I have a step to copy devcon.exe utility which is not on Windows 7 by default.
I’ve extensively tested this on my DELL devices and it works perfectly.
While attempting to perform an in-place upgrade from Windows 7 Enterprise to Windows 10 Enterprise I came across Error Code 0x80004005.
Looking at C:\WINDOWS\CCM\Logs\smsts.log gave me the clues on the error message.
There are many posts on how to fix this particular error message; it seems that this error code is pretty generic and it shows up on several instances in many SCCM operations – this document particularly deals with a task sequence for an in-place operating system upgrade.
Since this was an in-place Windows upgrade, I needed to find out more detailed information and I was able to get it from C:\$WINDOWS-BT\Sources\Panther this folder contains a list of .XML files that collect compatibility data that is collected during the upgrade process.
I opened the last XML file and this gave me the actual clue as to what was failing during the upgrade process – video drivers were the culprit!
Now I know what’s going on during the task sequence and I can attempt to fix this issue.
I’ll blog about how to fix this issue in a new post, stay tuned!
Recently we started the deployment of Windows 7 Enterprise (x64) throughout the company that I work for. The targeted hardware were DELL Optiplex 980, 990 and 9010 model desktops. The nightmare began after deploying several Optiplex 990 models. We use Microsoft System Center Configuration Manager 2012 SP1 to deploy the OS and applications to these desktops.
After deploying over 20 Optiplex 990 models, we noticed that on some 990s we were getting continuous BSOD’s after a day or two (the BSOD’s also came after a week of having the computer in production!). After a desperate call to Microsoft, it was determined that the BSOD code was a generic hardware error code. However, Microsoft was unable to pin-point the issue after 3 weeks of troubleshooting!
The one thing that came to mind was that the recent models that I deployed were older model Optiplex 990 desktops (possibly 2012 and very early 2013 models) , but at that time I failed to look into this clue. Luckily, and I mean luckily, I was able to catch the culprit of this nightmare, and here are the screenshots.
Note: disregard the failed PCI driver controller installation
Basically, you’re looking at a hijacked SATA driver installation!
These DELL Optiplex 990 models come with a SATA drive and controller installed. As a matter of fact, when Windows 7 Enterprise gets installed, SATA drivers are loaded for this computer; however, sometime post installation Windows finds, or detects, an IDE ATA chipset and without any warning, it installs the Intel(R 6 Series/C200 Series Chipset drivers!
To make matters worst, I’ve configured the OS Deployment in SCCM to use native DELL drivers specific for this computer model, yet Windows Updates comes a day or two later and replaces them with the Intel(R 6 Series/C200 Series Chipset drivers.
The quick, and lazy fix, is to go to the BIOS and change the drive controller settings from Raid On (default setting) to ATA.
I’ve yet to identify the reason why this change in disk controller drivers.