Since LANDesk HII now relies on driver's inf file, you need to look in there and see where the issue lies. If a wrong driver is being installed it's because the inf has a vendor and hardware ID that exists on that machine. Find out the ID and search for it in the inf. You can remove it from the inf if you choose to. I also heard that if the inf has a blank ID, it can cause this as it will be sort of like a wildcard and apply to all. Worth checking it out.
I like the approach but, in my opinion, it should be a hybrid of old and new. Let LANDesk create the associations for you but provide a gui that I can manually make changes to.
Ditto and thinking the approach needed to be a mix of the old and new...
We've not so much seen a problem with the hardware detection (we've seen the odd driver detected that didn't actually exist) however the main issue we've seen is Windows 7 Drivers being picked and installed over Windows XP Drivers.
This was from the customers working HII process pre-sp3 to the mess that it is now.
We've had to take an alternative hybrid approach in which we're using copydrivers for the XP Driver copy, LANDesk HII Client for XP MSD and also the Win7 driver injection. Then running ldprep.exe AFTER the two have gone through to essentially overwrite what HII puts in the registry with the actual detected WinXP drivers.
The new approach feels like a small step forwards but at the same time a large step backwards and is going to cause havoc for every single one of our customers when upgrading bar 1 who has a full Windows 7 environment.
I wanted to let you guys know that there is definitely a need for more improvement within the new process. The two things that really need to be addressed (and are being addressed) are user controlled granularity and accuracy. It seems like the problems aren't really with the process, but are when the process fails (through a bad driver being installed or a valid driver being ignored). Both of these issues are being addressed. I'm on the development team that works with this and can definitely tell you that it comes up every day in our conversations, and that solutions are being built.
I know this doesn't take away the pain you are feeling right now, but I at least want you to know that your pain is recognized and that we are working to improve the situation.
Let me know if you have any questions for me about this or anything else.
More information before the release of the service pack would have helped on the forum, not just hidden away in the download section.
I cannot stress how important its is, a major change like the HII implimeted in the SP3 has massive impact.
Perhaps a pre-flight HII, as simple template or a winpe image that "ghost" checks the image with HII that runs and reports back any driver issues, before running a normal deploy run. With a Pre-flight, at least I can tell if any drivers would fail and can be changed without having a machine blue/black screen.
Added an enhancement request that might help with this:
LANDesk Silver ESP
The One-Stop Shop for LANDesk Enhancements
Love to see it, but i'm getting "page not found"...so looks like i'm STILL not getting access, after all that emailing asking for access, perhaps, after asking over a year to get access someone will let me get in...
I just upgraded to SP3 yesterday and I am already feeling this pain. I had a flawless working environment within SP2. I knew OSD was going to be my biggest challenge post service pack, but I figured the issues would be easy to identify and resolve. I didn't expect this.
In SP2, the GUI interface worked perfectly to assign drivers to specific models and OS. As I'm sure most others have, after applying SP3 I left the default \\core\ldmain\landesk\files\drivers repository as the main location for drivers. Well, when we add a new machine model to HII, we typically only do the SATA and NIC drivers and accomodate for the rest via other means. However, there is redundancy in the Intel Storage drivers and several of the NIC drivers as well. The problem is they are different revisions of the same driver and contain the same hardware IDs as several other drivers in the repository. I imaged an HP Z200 with Windows XP and looking at the LDDriverstore folder, it pulled about 8 different drivers down and none of them were for the Z200. The machine wouldn't boot because it doesn't have the correct SATA controller driver.
I realize I can go in and remove all the "offending" drivers from the repository and chances are the XP machine will image and boot just fine, but what happenes to the other models that require those drivers? Do I have to put them back in on the fly?
I also imaged an HP 6450p with Windows 7. It imaged and booted fine, but on closer inspection it had pulled the controller driver from a DC7900. That doesn't give me warm and fuzzy that the rest of my machines are going to work as well. Again, I understand why it's doing this...it's basically first come first serve. If HIIClient detects a hardware ID and "finds" a compatible driver it is downloaded and made available to the OS, but what if it's not the one you want it to install? What if you want the one that's a little further down the folder structure?
Basically, I don't get why this was changed. It was working just fine in SP2. Now I have to jump through a bunch of hoops to hopefully get this square. I have technicians waiting to image machines....like TODAY...and I need a resolution for them.
Does anyone have a quick workaround strategy? Are you removing redundant drivers? How did you determine which were redundant? Our old driver repository was set up using machine model names when they were added to HII. It seems LANDesk wants this to be set up based on the specific component and make us do the legwork to determine which model has which hardware?
Any help is appreciated. This was a dumb move and is painful right now.
We as Axle-IT (ESP for the Netherlands) always included our own developed HII. Actually, thanks to an old colleague, this was the basis of the LANDesk HII as in pre-SP3 Our version is running a single executable that can be called from OSD or Provisioning and does what LANDesk did. Create a folder on a share with the name of the model if it doesnt exist and pull down the model specific drivers populated in that folder, including integrated SATA controller support. For XP it also does HAL detection and integration. Completely independent from LANDesk HII.
It might be a good solution for those who run into problems now. Contact me for more information if any of you are interested.
Hell, I'd be fine if I just got the GUI back. I know this process will be ironed out at some point, but I don't see why the process was changed. It worked just fine.
Pre-SP3 I used a hybrid of HII and DSIM for Win7 deployment. It worked great. I didn't need to do that for WinXP, the standard HII setup worked fine for that. Now I'm stuck trying to remove redundant drivers from the repository, but I won't know if the drivers I'm removing will be necessary for another model until I need to image one. We support over 20 models of PCs and laptops and we don't always have a spare around to test.
I'd like to clarify that the driver detection is not first come first serve on how it was entered into the folder. Each driver is ranked in roughly the same way as Windows ranks drivers.
For some of the problems you are seeing with false positive matches I would recommend asking for the latest patch that includes HII. It includes a number of tweaks to how that detection is done and seems to have done a wonderful job eliminating scenarios where too many drivers are pulled down. You should be able to get it from Support.
Please try that patch and let us know the results. I agree that the process needs to be massaged a bit, but this new patch takes a huge step toward getting you the correct results.
I contacted support re: this issue. After speaking with the tech, I was told this patch would not resolve the issues I'm currently having with XP deployments. Although Windows 7 deployments are able to boot up, upon closer inspection the Win7 machines are not pulling the drivers we would prefer. They are pulling a compatible driver, but the description is completely wrong. For example, a HP 6450b ProBook which I just imaged pulled the "Intel PCHM SATA AHCI Controller 6 PORT" driver, the 6-port part being incorrect as this is a laptop. Turns out HII pulled the driver for a HP DC7900 workstation, whose /INF description for the 6450s hardware ID is exactly that, the 6-port driver. It works, but it is not the preferred driver.
Apparently the issue I'm having with XP deployments is regarding the .db3 file in the driver repository. When HIIClient tells Windows where to find the drivers, the location path uses forward slashes instead of back slashes. This is a bug and I'm working with them to get this resolved.
Even with the XP forward-slash bug however, auto-detecting drivers is going to continue to cause issues, whether LANDesk or WINDOWS is doing the auto-detecting. If i were to make all these drivers available to Windows and not use LANDesk at all, I would run into the exact same issues with incorrect, or should I say less-than-desirable, drivers being installed. They will work, in most cases, but if more than one INF contains the same hardware ID or similar identifier then this issue will persist.
My main question remains: why was this changed? It worked just fine in SP2. I can see where this approach seems easier to someone unfamiliar with HII, but try asking that same person to troubleshoot issues under the new environment if incorrect drivers are being deployed. I'm not sure what I'll wind up doing to get my techs back up and imaging (they're banging on my door), but I can honestly say this wasn't broken in SP2. At all. Maybe it was my fault for assuming an upgrade to SP3 would be fairly painless, but I don't think my opinions are unjustified here.
You are correct about the slash problem on XP machines. You are also definitely justified in having your opinion on HII in SP3, etc.
The only part of your original statement I wanted to clarify is that drivers are not selected based on a "first hit" search. We do a ranking and a "best hit" is what's taken. I'll be the first to admit that having "best hit" is a great start, but for the solution to fully mature we need to get user control back into HII. I know this doesn't help in the short term, but we are aware of the problem and are working toward improving the solution.
If you are able to, could you post a copy of the .inf file that you referenced in your post as well as the device id in question? In fact, both the auto-detected inf file and the incorrect inf file would be great. If you are too busy, that's completely understandable also.
Here are the INFs in question. Now that I've had a bit to calm down (sorry if any previous posts came across as abrupt, I was just hoping to be done with the SP3 upgrade), I see why the EliteBook 2540 driver may have been injected over the Z200. It is a newer version of the exact same driver. In this case I don't have an issue with this swap other than the fact that the swap was out of my control.
I do have issues with other swaps, specifically when the wrong INF is nominated/injected and contains identical hardware IDs resulting in the device itself being named incorrectly. I fully attribute this to poorly written driver files, but I don't see how LANDesk (or anyone) would be able to determine which driver file to use if multiple drivers exist with the same hardware IDs/identifiers.
At this point I'm just waiting on my LD tech to modify my DB3 file so I can try it out and rule out any path issues before moving on. As long as my techs can image and get machines cuilt, we can double-check device manager post-image and verify all is how we want it. I can deal with misnamed items, but ultimately that means it received a driver that we did not intend.
Can't upload right now. Gets to 79% and hangs. Tried different browsers etc. Anything going on with the community page right now?
Message was edited by: Silvercoupe
No worries at all about your last post. I do agree that until we get selection control back into the solution in some way (that doesn't require editing inf files or db3 files) we can call this solution incomplete.
I don't know of any problems with the Community, but I'm not in a situation where I can attempt an upload right now. If you're not able to get it uploaded before too long then don't worry about it. I don't want to take up all your time. As much fun as taking way too much of your time would be, I really don't want to go down that road. [-8