Yes there is a new driver installation framework comming,
it was covered at WinHEC this year. It is intended to allow
removal of a driver completely something you cannot currently
do.

But even then the bottom line is, only Administrators should
be able to install drivers! If you can install a driver, you
can bypass all security of the system, so this has to be protected.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting

"Pavel A." <pavel_a@geeklife.com> wrote in message
news:O2fkec8dDHA.2416@TK2MSFTNGP09.phx.gbl...

Probably, the solution is something like Windows installer (MSI) for apps.
It can run installations at "elevated" level as a service.
Currently it does not work for drivers - but rumors are that MS is beta testing a new
installer framework that will do drivers as well.

Regards,
- PA

"Don Burn" <burn@acm.org> wrote in message news:vluc4hb8sl1038@corp.supernews.com...

That's not my point.
You CAN run any installation application using RunAs, but
of course you have to know the admin username and password.
I'm talking about the fact that you can't do the same that
RunAs does from your code for the
UpdateDriverForPlugAndPlayDevices function ONLY!
because there is something that Microsoft didn't document
and is hiding (or doesn't know, is another bug, I'm
thinking I'm the first to notice that) so we can't do it!
I tried to do it, and for all other functions that require
Administrator rights I managed, EXCEPT
UpdateDriverForPlugAndPlayDevices.
The best answer from Microsoft I got:
"I spoke with the owner of newdev.dll (where it comes
from) and he said you have to be an administrator to use
it, and that the way it is".
Well, how can RunAs be a better administrator than any
code/sample available from DDK, no matter what you do?
I'm telling you, I buy the code that works for that.

Is the problem that a non-administrator user that has the "install
drivers" privilege can't call UpdateDriverForPlugAndPlayDevices? That
would seem to be a bug if it's true.

However, did you make sure to *enable* that privilege? Just because a
user has the install drivers privilege doesn't necessarily mean it's
actually usable without setting the right privilege bit (I think there
might be a hack for users actually in the Administrators group, though).

Here's a function I wrote a long time ago to do this:

BOOL HaveLoadDriverPrivilege(void)
{
HANDLE hProcessToken = 0;
BOOL bHasDriverPrivilege = FALSE;
PRIVILEGE_SET privSet;
TOKEN_PRIVILEGES tokPriv;
UCHAR tokPrivPrevBuffer[1024];
ULONG ulTokBufLen = 1024;

memset(&privSet, 0, sizeof(privSet));
privSet.PrivilegeCount = 1;
privSet.Control = PRIVILEGE_SET_ALL_NECESSARY;

if (!OpenProcessToken(GetCurrentProcess(),
TOKEN_QUERY | TOKEN_ADJUST_PRIVILEGES, &hProcessToken) ||
!LookupPrivilegeValue(NULL, "SeLoadDriverPrivilege",
&privSet.Privilege[0].Luid))
{
return FALSE;
}

tokPriv.PrivilegeCount = 1;
tokPriv.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
tokPriv.Privileges[0].Luid = privSet.Privilege[0].Luid;

if (!AdjustTokenPrivileges(hProcessToken, FALSE, &tokPriv,
sizeof(tokPriv),
(PTOKEN_PRIVILEGES)&tokPrivPrevBuffer, &ulTokBufLen) ||
!PrivilegeCheck(hProcessToken, &privSet, &bHasDriverPrivilege))
{
return FALSE;
}

CloseHandle(hProcessToken);
return bHasDriverPrivilege;
}

Alex Pranke wrote:

--
.../ray\..

I concur I had thought Alex was asking for a way to install without admin
capabilities. The Driver Install Framework beta is supposed to start
anytime.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting

"Pavel A." <pavel_a@geeklife.com> wrote in message
news:%23Zf73ZJeDHA.3584@tk2msftngp13.phx.gbl...

"Don Burn" <burn@acm.org> wrote in message news:vlusuvkiti1v41@corp.supernews.com...
Don,
Two or three years ago I'd second your opinion, but now it seems to me that Alex has a point.
I was used for "best practices", that's working under non-admin account most of the time, and use
Run As for admin tasks (entering local admin password every time).
This appears not convenient for most "power" users. I know several companies that let domain users
local admin rights on their machines - just to let everybody install whatever they want.
I really want to see if the new installer brings some heads up.
We received invitation for this beta, and mailed the forms more than month ago, but still didn't
heard back from them. Anybody already received it ?

Regards,
-PA

On Fri, 12 Sep 2003 02:11:50 -0700, "Alex Pranke" <anuofgod@hotmail.com>
wrote:

This shouldn't happen if your drivers are signed.

Also, RunAs could be used as follows to install your device:

| runas /user:MACHINE\Administrator rundll32 newdev.dll DevInstall <DevRegKey>

where <DevRegKey> is the device's registry key in the ENUM tree, for
instance USB\Vid_046d&Pid_c00e\5&255a9bd2&0&1. Or write your own
application around UDDFPPD and execute it through RunAs.

Ralf.

The device has no unique ID, it is extremely stupid. Devices with unique IDs
will not re-run the driver install if they are plugged to another USB port or
hub.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Could it be that "Load and Unload drivers" is not the only privilege
required? MSDN says you need that privilege and the ability to copy files
to windows\system32\drivers plus the ability to write entries to the
registry in the places where needed. Did you read KB 250982? It is fixed
in Windows 2000, for Microsoft's definition of fixed. Most of your post,
while correct, does not pertain to any response.

Microsoft has decreed, since they own the source code to Windows, that if
you attach a USB device to one location and then reattach it to another
location, it will require the driver installation logic to run so the
correct registry entries can be created, but if it has a serial number, it
will be treated as a move and not a new device. A device without a serial
number when plugged into a new location, is a new device. Not my idea, but
you can't print your own money either.

The signed driver thing may become a requirement. I suspect if Microsoft
thinks (feels) they can get away with it, they will try it. It does have
some advantages for the user, especially if it does help OS stability. From
some of the questions on these newsgroups, I want some of the authors to get
their work signed.

Look at MSDN at "Starting a Service" for an example. I suspect that if the
user has the load and unload driver privilege, they can start and stop the
"service" name of the driver. However, they can't install the service entry
for obvious reasons.

"Alex Pranke" <anuofgod@hotmail.com> wrote in message
news:019101c37ba9$ff5ab510$a301280a@phx.gbl...

Again calm down. I understand this is frustrating for you, but this
certainly isn't any fault of mine or anyone else here.

I never said this was a requirement for operation of the device. It is just
a requirement if you don't want the "Found New Hardware Wizard" popping up
everytime you changes ports with a USB device. I am not thrilled with this
behavior, but it is what it is. The fact that these devices you mention do
not exhibit this behavior is likely because their drivers are signed, OR
they are using a co-installer DLL or some such to migrate registry settings
for the device, or perhaps (for MS or previously known devices) they cheat
in some other way. I do not know. I do know that it is expected, although
likely not well documented, behavior that a USB device without a unique
serial number will show up as a new device even if this same or a similar
device has already had a driver loaded for it on another port. It isn't
that the device will not work, it just has to have a driver loaded for it.
Again, there are ways around this, and these devices you mention must have
used one of the ways around.

--
Bill McKenzie
Compuware Corporation
Watch your IRPs/IRBs/URBs/SRBs/NDIS pkts with our free WDMSniffer tool:
http://frontline.compuware.com/nashu...es/utility.htm


"Alex Pranke" <anuofgod@hotmail.com> wrote in message
news:019101c37ba9$ff5ab510$a301280a@phx.gbl...

Guys, please, READ the entire post.
I know exactly what the serial numbers are for and how
they work.
I'm complaining about:
- You give all existing privileges to a non admin user
(Load and Unload drivers is one of them), the user changes
the device to another port and get a message "Invalid
Data".
Is this problem clear enough?

- There is no way by code you can make an application to
do the job of RunAs, even given the user all privileges,
impersonating, using CreateProcessAs, whatever. You will
became ALMOST 99% an administrator, but not enough to use
UpdatePlugAndPlayDrivers.
So, there is no way you can write an application that
solves all your installation problems on the user side,
because you cant run the function impersonating an admin.
Clear?

On Tue, 16 Sep 2003 01:04:21 -0700, "Alex Pranke" <anuofgod@hotmail>
wrote:

I agree in that tying the ability to call UDFPPD (that's my abbreviation
for UpdateDriverForPlugAndPlayDevices BTW) to membership in the
administrators group rather than to a specific privilege is not the
world's best idea. But it is definitely possible to write an application
that uses UDFPPD and then run that application via RunAs
(CreateProcessWithLogonW) under an administrative account.

As for your specific problem, AFAIK currently signed drivers are the
only way around. If the drivers are signed, the PnP manager will perform
a silent, "server side" install. Non-signed drivers will always trigger
the "Found New Hardware" wizard.

Ralf.

Please read the responses.

Your problem has nothing to do with USB, outside the fact that USB probably
makes it show up more frequently. That was my point.

My second point was that it sounds like you may or may not have a valid
issue here. However, the issue is such that no one on this list has the
power to help you solve the problem, if indeed it is a problem. As such,
have you opened a support request with MS on this?

--
Bill McKenzie
Compuware Corporation
Watch your IRPs/IRBs/URBs/SRBs/NDIS pkts with our free WDMSniffer tool:
http://frontline.compuware.com/nashu...es/utility.htm


"Alex Pranke" <anuofgod@hotmail> wrote in message
news:098501c37c29$22e28600$a401280a@phx.gbl...

....which require the user with "Load/Unload drivers" privilege to be locally
logged on.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Hi everyone,

Ralf Buschmann wrote:
One additional detail, just for the records: If you run
UpdateDriverForPlugAndPlayDevices on XP from a service running under a
user's credentials, it fails if you try to install an unsigned driver,
even if the user is member of the local Administrator's group. This is
because that service runs in a non-interactive window station and UDFPPD
tests the "Interactivity" of the processes' Window Station. On W2K you
can still find that warning window in the noninteractive window station
and dismiss it programmatically (sending it WM_COMMAND with IDOK), so
UDFPPD succeeds - on XP, UDFPPD will fail in this case.


HTH,

--
Stefan Kuhr

Well, the USB was the chosen example because it's PNP, and
one of the issues is with the mentioned updatePNPdriver
function. I agree that all the problems I mentioned are
not USB specific, but PNP and drivers related.
I tried using the support, but I was asked for my Windows
serial number and the one I have is OEM, which I was
answered doesn't entitle me for any support.

What I'm trying to achieve is to bring the problem to the
surface so other developers don't waste time trying to
solve problems that are native from Windows, and possibly
unsolvable today.
But there is always someone saying the fault is in the
drivers that are not signed or absence of a serial number
in the device, which has nothing to do with the CAUSE of
the problem because all Windows are suppose to work
without them one way or another. But they dont in the
situations I described.

Ok, end of story, as everybody wanted, let's pretend those
issues don't exist and celebrate the Windows reliability
and MS capability of solving its problems.