Software Deployment Question

Deploying Drivers That Require Setup

02/04/2011 12693 views
Hi Guys,

First post here, hopefully I've posted in the correct place... apologies if not.

We have just got SCCM and I'm trying to install some drivers as part of an OS deployment task sequence. Most drivers are working fine as I can extract the INF files and install these using the "Apply Driver Package" step in the sequence. However there are a couple of drivers (mobile broadband card and a fingerprint reader device) that need to be installed from a setup.exe (I believe these are known as "bad" drivers in the packaging world). So I created application packages for these and tried to install them via the "Install Software" step, using setup.exe -s as the Program to run, but this always fails with the following error (same error for both drivers):

The task sequence execution engine failed executing the action (Install Dell Mobile Broadband Card Drivers) in the group (Dell Latitude E4310) with the error code 50
Action output: The operating system reported error 50: The request is not supported.

So then I tried running a command line step rather than software install step, and ticked the box for "disable 64 bit file system redirection" but now I get the error "the required subsystem is not available" so then I tried it without that box ticked but still got the same error.

Anyway got any suggestions for what to try next or how to troubleshoot this?

0 Comments   [ + ] Show comments


Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

All Answers

You have to read the smstslog on the local computer, it´s not an easy work to try to find out the reason, but as you surely know your setup.exe must run silently, and sometimes with a local admin account, it may also need netframework or something else installed first. But I wonder if this is not a better way to solve your issue: http://www.delltechcenter.com/page/Dell+Business+Client+Operating+System+Deployment.
As you are new to OSD may i suggest you do not repeat my mistake and import drivers unless you have no choice. Just setup driver packages, It will do the job and in a year or 2 you do not have to try to find 50 drivers in different packages just to update 1 computer .model
Answered 02/04/2011 by: admaai
Orange Senior Belt

Thanks for that link, that's great that I can just download the CAB file for our models from there with all drivers in :) I'll download that on Monday and see if we can just use those drivers rather than the setup.exe

I'm not quite sure what you mean about the driver packages though. You say not to import drivers and to use driver packages instead but aren't driver packages just a group of imported drivers?
Answered 02/04/2011 by: chris128
Orange Belt

We have around 70 different models in our environment and now use "Creating driver packages without importing into database". read Creating driver packages without importing into database,http://hayesjupe.wordpress.com/sccm-osd-driver-best-practices/ but do not follow the advice on massstorage for xp there are better ways for that.
Another link: http://itechiez.com/sccm-2007/sccm-driver-structure/
Answered 02/04/2011 by: admaai
Orange Senior Belt

Unfortunately the "Driver" world is very different from the .exe world.

I wonder if your -s switch was correct. Be sure to run the exe manually (Start > cmd.exe) by entering the setup.exe /?. Hopefully a window will pop up showing you the appropriate switches to install silently (and suppress reboot, if required, etc.).

Once you have your switches set be sure to test manually using the cmd.exe window. Once it installs with no user interaction using this method, then you're ready for installing via SCCM (or Tivoli, batch, PDQ Deploy, etc.).

Let us know if you hit quicksand. We've all been there before (it tastes horrible).

Answered 02/07/2011 by: ShawnAnderson
Senior Yellow Belt

This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ