Did you read about the HII changes in SP3 before upgrading?
They changed many things and I remember something like, that WAIK must be uninstalled completely,
if you have it installed on your Core for example.
As a starting point I would contact LANDesk support and request the post SP3 sustaining patch listed in the following article.
If you read the product improvement section it mentions some improvements they have made to the HII driver management because there are some known 'driver matching' issues which would only affect specific hardware types in SP3 vanilla that might mean your devices are picking up the wrong PnP file.
Maybe if you try this patch and the problem still exists you can investigate further with their assistance. If you do request the patch make sure they advise as to what needs to be updated. e.g. Core, WINPE/PXE Reps.
We were completely dead in the water as far as imaging goes in our environment after the SP3 upgrade. After 2 weeks of trying to troubleshoot the issue we decided to roll back to SP2.
IMHO the SP3 HII Process is only suitable for a single OS platform environment (Windows 7 or XP, but not both). The good thing about the SP2 HII process is it is Reliable and Consistent and easy to manage from the GUI.......an absolute necessity in an enterprise environment. The SP3 process was more like a lucky dip as to what driver was going to be used.
I don't see how removing all visibility of the Driver Management from the Console is of any benefit to anyone? How can you see what machines your current repository supports? It's fine if you have 1or 2 admins responsible the upkeep and running of imaging tasks, but we have people using landesk on different shifts in different time zones.
The SP2 HII was easy to troubleshoot, if the HII action failed the 1st point of call was to check if the model was assigned drivers? In SP3 there is nothing to visibly check.
Looking at posts here on the forum by LANDesk employees, it is clear to see that even LANDEsk admit the solution is incomplete and as such should never have been introduced.
I don't think any employee of LANDesk would say that the solution shouldn't have been introduced. I know from previous threads that you have the belief, but I don't want to be misquoted as having said that.
I will be the first to admit that there are things that can be done to improve HII post SP3. I do believe, however, that SP3 is superior to SP2 in most scenarios. As a developer on that team I can also commit to making it better. I know that the fact that there are things to fix indicates that we didn't do a perfect job on our release. I'll own that. A lot of the pain being felt is due to decisions I've made and shortcomings in code I've written. I'm sorry to anyone who reads this that has felt that pain.
I also know that a large percentage of problems has gone away with the post SP3 patch, so I agree with Blair that it is a great starting point for trying to solve any HII problems. In addition to improved detection there is also much better logging that should persist even after you leave Windows PE. It should be in the Windows\Temp directory and has a lot of good information in it.
Definitely contact support about any problems that remain after the patch. We really do want to make this a better product and although it sometimes seems that opening a support case doesn't do anything to fix the underlying problems the reality is that number of cases raised by a problem is one of the key things we use to determine what fixes or improvements we should be working on.
Whilst I am sure that the SP3 HII Process has it's merits for some organisations. The new HII features are not compatible with our organistaion. I would be very suprised that organistations having an established LANDesk infrastructure did not experience issues with the new HII process. Our issue was so great that we had to roll back to SP2 in order to restore OSD functionality. This did not affect one model/one hardware device it affected many, so logging a case with LANDesk and awaiting a fix/patch was not an option for us.
The LANDesk Support partner who we have a support contract with didn't even try to fix the issue, they simply gave us a HII alternative.(copydrivers.exe) to bypass the issue. Even this had it's problems so we decided to roll back.
The dissapointing thing throughout all of this is that my organisation has lost what little faith it had in LANDesk to the extent that it will be unlikely that they will authorise the upgrade to SP3 in the near furture. In my opinion the the upgrade of the HII feature in SP3 should be made optional or modular. In effect the complete revamp of the HII feature by LANDesk essentially means that the product is now not what we purchased and does not function as we purchased. It is also frustrating that we cannot benefit from any of the other SP3 improvments outside of the OSD arena simply through a lack of trust in the HII process.
When we add new models into support, we download the required drivers, add those drivers into LANdesk, run test deployments and then sign off the machines to the business as being supported in our environment. With SP3 i can never "sign off" devices as being supported as i can now not guarantee that the HII process will not pick a different driver than the one i have downloaded for that particular model. I am not concerned with single instances of drivers. I am not concerned with having the latest, greatest device drivers. i am concerned with reliablity and consitancy and not getting calls at 3am to say a machine that I have signed off as being supported is bluescreening after imaging. I truly beleive that any new driver I could add to the SP3 driver repository could result in bringing my OS deployments that i have already tested and signed off to a grinding halt again. I would have to test any/every new driver i imported into SP3 against every model of machine in our environment in a lab to guarantee that it would not cause an issue......not very realistic or acheivable.
Our Helpdesk also needs to have some form of GUI regarding Driver Management, this has also been removed in SP3. They need something to be able to check against when they receive a ticket to image a particular model
Our SP2 setup is now thankfully working as we want it to work, it may not be perfect, but it works.
Sitting on fence here because having a bug with a new feature, and not liking the design/functionality of a new feature are two seperate things. I think posts regarding individual feelings on the design concept of a new feature should be placed in their own discussion post, an ER, or directed at your ESP/LANDesk account manager for discussion. Or they'll fall on deaf ears and distract from helping the orginal poster...
LDMS service packs have always been a combination of new features/changes and fixes, V9 SP3 primarily the latter. This is not a new situation, and of course the changes will naturally affect some customers and not others, because they do/do not use a particular feature the same way or because of the timeliness in which they apply the service pack before a bug is discovered and remediated.
LANDesk can do their bit to provide more detailed/visble information on what changes we might expect or have been discovered, but this also highlights the importance for customers and their support providers to consider, before application, the possible changes in a service pack/patch around the functional areas of the LANDesk solution you are using. Present the potential business impact to management and this normally raises the business case for a LANDesk test core server and lab investment, so that the service packs can be tested and new features reviewed. If as a business you authorise the application of the service pack direct to your live core server, without determining its suitability you've effectively signed off that your happy to apply it, not that your happy with the changes it makes.
I think Andy's concept of a more modular optional upgrade to specific major features when applying a service pack is interesting, and something I think could be considered. I can see that would have allowed him to see the benefits of the SP3 fixes without the impact of the major change to a new feature. As he was able to roll-back to SP2 I presume he had a restorable backup of both his core server and database, which I'm very glad to hear as he's back up and running.
Technically I also see advantages of both the SP2 and SP3 approaches. The GUI management in SP2 gives you visiblity and control, however it also introduces additional management overhead for individual systems, and duplication of drivers. The SP3 approach (which either uses or is very similar to DISM) is more dynamic but perhaps better suited only to Windows 7. I haven't tested the new patch post SP3 patch yet but hopefully they have fixed the matching issues and I can provide some more feedback on it when I have that chance.
I finally got my issue resolved. It was only the Mass Storage driver which was causing the pain so I inetgarted this in Sysprep.inf file and I am all set. I have reimaged about 4 different models and all drivers are being installed correctly. Now if I ignore the MSD issues( as its there in my image now), I do not see any issues with SP3 HII. Its working flawlesly and I believe better than SP2. However, I really would love if it recognise the MSD so that we do not have any issue in future in case there is a new controller in the market.
Why are you running HIIClient.exe on the core server?
Edit for clarity:
HIIClient is supposed to run on the client side. You should never need to run it manually. On the core you should use the HII tool in the console. Also, if you are using this with Windows XP you should contact support for the latest rollup patch that includes fixes for HII. I'm not sure what version that is, so the best way to get it would be to log a case.