Driver

SCCM OSD Failed Setup Could Not Configure One or More Components

Richard Green on

Last week I got asked to look at an issue where a new model of laptop was failing to deploy using a Configuration Manager Operating System Deployment Task Sequence. We knew that the environment was good as other machines were able to complete the task sequence without any issues and the first thought was that it could be a driver issue.

Initially I was sceptical of it being a driver issue as when we see problems with machines completing operating system deployment, problems with drivers normally fall into the category of silent fail whereby the driver is missing all together and we end up with the yellow exclamation mark in Device Manager or the task sequence fails because the driver missing or problematic is related to network or storage and blocks the task sequence from completing.

In this instance however, we knew that the problem was specific to this model. Given that we are failing in the Windows Setup portion of the task sequence, the usual smsts.log file is of no help because the Configuration task sequence has not yet been re-initialized after the reboot at the Setup Windows and ConfigMgr step. in this instance, we need to refer to the setuperr.log and the setupact.log in the Panther directory which you will find in the Windows installation directory. This is where errors and actions relating to Windows Setup live as opposed to the normal smsts.log file.

We rebooted the machine back into WinPE to allow us to open the log file with visual Notepad and began reading the file. Sure enough, we hit an error and the code given was 0x80004005. Looking at the activity either side of this, we can see that the machine is busy at work with the CBS (Component Based Servicing) engine and is initializing and terminating driver operations so we know that something has happened to a driver to cause this problem.

At this point, we had nothing more to go on. Two weeks’ ago, I had a similar issue with another customer whereby the issue was clearly logged to the setuperr.log file and the problem in that instance was an update we had added to the image with Offline Servicing required .NET Framework 4.5 to be present on the machine however Dism didn’t know to check that so we simply removed the update but here, we have no such helpful fault information.

Given that this was a new machine and given that we are deploying Windows 7, I had a thought? What if these drivers being applied require the User or Kernel Mode Driver Framework 1.11 updates that were released for Windows 7 some time ago?

This theory was easy to check. I mounted the Windows 7 .wim file on our SCCM server and then used the Get-Packages switch for Dism to list the installed updated in the image. Sure enough, User-Mode Driver Framework 1.11 (KB2685813) and Kernel-Mode Driver Framework 1.11 (KB2685811) were both absent from the list. I downloaded the updates from the Microsoft Download Center and Offline Serviced the Windows 7 image with the updates and commited the changed back into the .wim file.

After reloading the image in the Configuration Manager Administration Console and updating the .wim file package on the Distribution Points we re-ran the task sequence and by-jove, the machine completed the task sequence with no dramas.

For background reading, the User-Mode and Kernel-Mode Driver Framework 1.11 update is required to install any driver file which was written using the Windows 8 or Windows 8.1 Driver Kit. What I have yet to be able to determine is if there is a way of checking a driver .inf file to determine the version of the Driver Framework required. If there had been a way to determine this, Configuration Manager administrators around the world may rejoice a little so if you do know of a way to check this, please let me know as I would be interested to hear. This would have not been an issue had the reference images been patched with the latest (or at least some) Windows Updates however in this case, I was not so lucky.

Intel HD Graphics Update for Windows 10 Technical Preview

Richard Green on

Today is a good news day for Windows 10 Technical Preview users. I’ve been using the Technical Preview on my Dell Latitude E7440 laptop since it’s release and since upgrading to build 9926, I’ve been having a lot of problems with blue screens of death on startup. So much so, that from a cold boot it normally takes me four BSODs to get logged in and working so my laptop normally only ever goes to sleep to avoid the cold boots.

The problem is caused by the Intel HD Graphics driver which I’ve confirmed for myself using WinDbg to analyze the crash dumps for many of these issues. Today, it looks like my luck is in.

Windows 10 Technical Preview Intel HD Graphics Update

Delivered via Windows Update, I’ve got two new drivers waiting for me, one for the Realtek audio driver and another for the Intel HD Graphics driver. I’m installing it as you read this post but fingers crossed it is going to resolve these issues with the Windows 8.1 driver running under Windows 10.

Project Home Lab: Planning for Recovery

Richard Green on

In my last post, Server Surgery Aftermath, I talked about the issues I was having with my home server. Whilst continuing to try and identify the issues after the post, I ran across some more BSODs and I managed to collect useful crash dumps for a number of them. Reviewing the crash dumps with WinDbg from the Windows Debugging Tools, I was able to see that in every instance of the BSOD, the faulting module was network related with the blame shared equally between Ndis.sys and NdisImPlatform.sys which means that my previous suspicion of the LSI MegaRAID controller were out of the window.

Included in the trace was the name of another application which is running on the server. I’m not going to name the application in this instance but let’s just say that said application is able to burst ingress traffic as fast as my internet connection can handle it. I decided to intentionally try and make the server crash by starting up the application and generating traffic with it and sure enough within a couple of minutes the server experienced a BSOD and restarted. This started to now make sense because the Windows Service for this application is configured for Automatic Delayed start which is why in one instance after a BSOD, the server had another BSOD about 45 seconds later.

For the interim, I have disabled the services for this application and with the information in hand, I started looking more closely into the networking arrangements. I knew that as part of the server relocation, I had switched from my dual port PCIe Intel PRO 1000/PT adapter to the on-board Intel 82576 adapters and both of these adapter ports are configured in a single Windows Server native LBFO team using the Static Team mode which is connected to a Static LAG on my switch.

To keep this story reasonably short, it turns out that the Windows Update provided network driver for my Intel adapters is quite old but yet the driver set 19.5 that Intel advertise as being the latest available for my adapters doesn’t support Windows Server 2012 R2 but will only install on Windows Server 2012. Even booting the server into the Disable Driver Enforcement mode didn’t allow the drivers to install. I quickly found that many other people have had similar issues with Intel drivers due to them blocking drivers on selected operating systems for no good reason.

I found a post at http://foxdeploy.com/2013/09/12/hacking-an-intel-network-card-to-work-on-server-2012-r2/ which really helped me understand the Intel driver and how to hack it to remove the Windows Server 2012 R2 restrictions to allow it to be installed. The changes I had to make differed slightly due to me having a different adapter model but the process remained the same.

Because my home server is considered production in my house, I can’t just go right ahead and test things on it like hacked drivers so luckily, my single hardware architecture vision came out on top because I’ve installed the hacked and updated Intel driver on the Lab Storage Server and the Hyper-V server with no ill effects. I’ve even tested putting load between the two of them over the network and there has been no issues either so this weekend I will be taking the home servers’ life in my hands and replacing the drivers and hopefully that will be the fix.

If you want to read my full story behind the Intel issue troubleshooting, there is a thread I started on the Intel Communities (with no replies I may add) but all the background detail is there at https://communities.intel.com/thread/58921?sr=stream..

Circumventing Intel’s Discontinued Driver Support for Intel PRO 1000/MT Network Adapters in Server 2008 R2

Richard Green on

In a previous life, my Dell PowerEdge SC1425 home server has an on-board Intel PRO 1000/MT Dual Port adapter, which introduced me to the world of adapter teaming. At the time I used the adapters in Adapter Fault Tolerance mode because it was the simplest to configure and gave be redundancy in the event that a cable, server port or a switch port failed.

In my current home server, I have been running since its conception with the on-board adapter, a Realtek Gigabit adapter which worked, however it kept dropping packets and causing the orange light of death on my Catalyst 2950 switch.

Not being happy with it’s performance, I decided to invest £20 in a used PCI-X version of the Intel PRO 1000/MT Dual Port adapter for the server. Although it’s a PCI-X card, it is compatible with all PCI interfaces too, which means it plays nice with my ASUS AMD E-350 motherboard, however I didn’t realise that Intel doesn’t play nice with Server 2008 R2 and Windows 7.

When trying to download the drivers for it from the Intel site, after selecting either Server 2008 R2 or Windows 7 64-bit, you get a message that they don’t support this operating system for this version of network card, which I can kind of understand due to the age of this family of cards, however it posed me an issue. Windows Server 2008 R2 running on the Home Server automatically installed Microsoft drivers and detected the NICs, however that left me without the Advanced Network features to enable the team.

I set off my downloading the Vista 64-bit driver for the adapter and extracting the contents of the package using WinRAR. After extraction, I tried to install the driver and sure enough the MSI reported that no adapters were detected, presumably because of the differences in the driver models between the two OS’s. After this defeat, I launched Device Manager and attempted to manually install the drivers by using the Update Device Driver method. After specifying the Intel directory as the source directory, sure enough, Windows installed the Intel versions of the drivers, digitally signed without any complaints.

With the proper Intel driver installed, I was now left with one problem and that was still the teaming. Inside the package, was a folder called APPS with a sub-directory called PROSETDX. Anyone who has previously used Intel NIC drivers will realise that PROSET is the name used for the Intel management software, so I decided to look inside, and sure enough, there is an MSI file called PROSETDX.msi. I launched the installer, and to my immediate horror, it launches the installer which the autorun starts.

Not wanting to give up hope, I ran through the installer and completed the wizard, expecting it to again say that no adapters were found, however it proceeded with the installation, and soon enough completed.

This part may change for some of you – Intel made a bold move somewhere between version 8.0 of the Intel PROSet driver and version 15.0 of the PROSet driver and moved the configuration features from a standalone executable, to an extension in the Device Manager tabs for the network card. I poured open the device properties, and to my surprise, all of the Intel Advanced Features were installed and available.

image

I promptly began to configure my team and it setup without any problems and it created the virtual adapter without any issues too including installing the new driver for it and the new protocols on the existing network adapters.

With this new server, I decided to do things properly, and I’ve configured the team using Static Link Aggregation. I initially tried IEEE 802.3ad Dynamic Link Aggregation, however the server was bouncing up and down like a yoyo, so I set it back to Static. Reading the information for the Static Link Aggregation mode is a note about Cisco:

This team type is supported on Cisco switches with channelling mode set to "ON", Intel switches capable of Link Aggregation, and other switches capable of static 802.3ad.

Following this advice, I switched back to my SSH prompt (which was already open after trying to get LACP working for the IEEE 802.3ad team). Two commands completes the config: one to enable the Etherchannel and one to set the mode to LACP instead of PAgP.

interface GigabitEthernet0/1
description Windows Home Server Team Primary
switchport mode access
speed 1000
duplex full
channel-group 1 mode on
spanning-tree portfast
spanning-tree bpduguard enable
!
interface GigabitEthernet0/2
description Windows Home Server Team Secondary
switchport mode access
speed 1000
duplex full
channel-group 1 mode on
spanning-tree portfast
spanning-tree bpduguard enable
!

The finishing touch is to check the Link Status and Speed in the Network Connection Properties. 2.0Gbps displayed speed for the two bonded 1.0Gbps interfaces. Thank you Intel.

image

HP Crapware Crosses the Line

Richard Green on

I used to work for Xerox, I hide this not one ounce. One of the things I liked about Xerox most was their drivers – Lean, mean fighting machines, rarely any bigger than 10MB for the full driver.

Nicky got a new HP printer for Christmas from her Dad. I would have had him chose a Xerox Phaser 6115 MFP for us if it wasn’t for the extreme price tag on them, however the HP Photosmart series makes a good mixture of price and features for a home ‘power’ user.

HP seem to be the anti-christ when it comes to drivers. I downloaded the driver for the printer from the HP site. I would normally download the driver only package as this means you can print and it is much leaner and more stable, however the lean build isn’t even available for this model, so I was forced into the full package (also because I need to configure the networking on the device which can’t be done via the front panel) so instead I had to download and install the 180 MB package.

After several problems getting the software installed (due to the fact that HP’s installer package couldn’t handle the fact that I use a redirected home drive for my documents directory on H:) I managed to get it installed with some registry hacking.

Once the installation started I was watching it go through, I was watching the phases whir by and one of them offensively caught my eye – Yahoo Toolbar Customized by HP. This annoyed me no end, because I hate toolbars so very much because they are intrusive and 99% of the time not installed at my request such as this one. Yahoo is not my search engine of choice and never has been. If HP want to bundle the Yahoo toolbar then that’s fine with me, but at least give people the option to not install it.

Secondly, after the installation finished I noticed something else I didn’t ask for – A Windows Sidebar Gadget had been installed which allows you to drag and drop pictures onto it for instant printing. That’s a nice feature for someone who actually wants to use the printer, however I only installed this overweight bloated driver for the purpose of configuring the networking. Even though it may be a nice feature, this is again a feature which should be optional. Sidebar Gadgets can be quite intrusive at time (especially those shipped by TechGuys and PC World to name a couple).

I feel HP have crossed the line on at least three accounts here by not giving the users the choice they deserve and forcing junk bloat-ware upon it’s users, not giving users the ability to configure the networking in a lightweight fashion without installing the software and lastly for the damn software not working.

Now I have the software installed, I’ve spent the last 45mins trying to get the software to correctly assign the wireless network settings to the printer so that I can use it as planned to no avail. It would be faster for me to manually change the binary bits on the EEPROM!

HP – Make better drivers, smaller without bloat!

UPDATE 1
I just opened Internet Explorer to do something and discovered some monstrous and utterly real estate wasting piece of rubbish toolbar on the left side of the page view area has also been installed. Get real HP!

UPDATE 2
I managed to get the networking on the printer configured by setting the Configure Network application to Compatibility mode for Windows Vista Service Pack 2 and Administrator Mode in Windows 7. The irony here is that HP’s software claims to be Windows 7 compatible from the text on their website, but it’s obviously borderline compatible.

I have this morning been trying to uninstall the HP software from my machine now, as now that printer is on the network it is broadcasting itself via UPnP for all to see which I have to say is excellent (another post coming) but the shoddy software not only requires me to reboot for changes to take effect after the removal of each of the six components, but forces the immediate restart killing any open Internet Explorer tabs in the process – Rage ensues.