palm usb drivers 6.0.1.0 under user account
Hello packagers,
I have a question i anyone can set me on the right track. The problem i´m having is the automatically installation of the new palm usb drivers 6.0.1.0.
I have made 3 msi packages, all 3 are different. One package that i created uses difxapp 2.0, the other one uses the pnp driver template (Look above the forums), and the third one uses a custom action that uses palmusb.exe /i. When running, under a user account, these 3 msi´s they tell me that the user doesn´t have enough rights to install. When instaling the 3 msi´s under administrator the msi package works just fine. The usb cable is plugged in and the driver is getting installed. Just the way i want.
BUT the funny part is: When installing the windowsCE drivers (Using the difxapp 2.0 and the pnp driver template) under a user account the msi is working just fine.
We also have made pacakges of the palmusb 1.4.0.0 drivers. They work on both methodes just fine. So i´m stuck on the new palm drivers.
So conclusion:
palm usb 1.4.0.0 works fine with pnp driver template and difxapp
windows ce drivers works fine with pnp driver template and difxapp
palm usb 6.0.1.0 doesnt work for both mehods????
can anybody tell me what to do? Is it even possible to package the palm usb driver 6.0.1.0
I have a question i anyone can set me on the right track. The problem i´m having is the automatically installation of the new palm usb drivers 6.0.1.0.
I have made 3 msi packages, all 3 are different. One package that i created uses difxapp 2.0, the other one uses the pnp driver template (Look above the forums), and the third one uses a custom action that uses palmusb.exe /i. When running, under a user account, these 3 msi´s they tell me that the user doesn´t have enough rights to install. When instaling the 3 msi´s under administrator the msi package works just fine. The usb cable is plugged in and the driver is getting installed. Just the way i want.
BUT the funny part is: When installing the windowsCE drivers (Using the difxapp 2.0 and the pnp driver template) under a user account the msi is working just fine.
We also have made pacakges of the palmusb 1.4.0.0 drivers. They work on both methodes just fine. So i´m stuck on the new palm drivers.
So conclusion:
palm usb 1.4.0.0 works fine with pnp driver template and difxapp
windows ce drivers works fine with pnp driver template and difxapp
palm usb 6.0.1.0 doesnt work for both mehods????
can anybody tell me what to do? Is it even possible to package the palm usb driver 6.0.1.0
0 Comments
[ + ] Show comments
Answers (14)
Please log in to answer
Posted by:
kkaminsk
18 years ago
Check that the custom actions installing the driver are in the execute deferred sequence.
Posted by:
sejacru
18 years ago
hellp kkaminsk,
monday morning i shall check it out.
thanx for your reply.
monday morning i shall check it out.
thanx for your reply.
Posted by:
Ilikebananas
18 years ago
Hi sejacru,
We ran into the same problem. We have put in quite a lot of time, but since we where close to a deadline we had to settle for second best.
We where only able to create a script which eliminates the need to be admin, but it has to be started manualy. It can probably be made silent also, but we didn't have the time.
What we did:
When you check out the .inf a kernel service is created, you can do that using custom actions.
When you connect your device some regkeys are written here: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\... Then the driver install adds some more keys after which everything is OK.
The problem is that some of the keys contain a unique serialnumber, that will be available only after the device is connected, and therefor they are unscriptable.
The idea is that the user conects the device, cancels the "only admin notification" for the driver install and starts the script. The script queries the serial from the registry and writes the appropriate extra keys. When the user now reconnects the device its ready to go.
We had to give the user extra priveliges in the registry, but this could be done on HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\Vid_....&Pid_.... since we did know the Vid and Pid of the devices in use.
We realy didn't like this solution, but under the circomstances it was the best we could come up with. If anyone has a better solution (the one we came up with was subject to a good amount of group thinking!) I will be very interested.
We ran into the same problem. We have put in quite a lot of time, but since we where close to a deadline we had to settle for second best.
We where only able to create a script which eliminates the need to be admin, but it has to be started manualy. It can probably be made silent also, but we didn't have the time.
What we did:
When you check out the .inf a kernel service is created, you can do that using custom actions.
When you connect your device some regkeys are written here: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\... Then the driver install adds some more keys after which everything is OK.
The problem is that some of the keys contain a unique serialnumber, that will be available only after the device is connected, and therefor they are unscriptable.
The idea is that the user conects the device, cancels the "only admin notification" for the driver install and starts the script. The script queries the serial from the registry and writes the appropriate extra keys. When the user now reconnects the device its ready to go.
We had to give the user extra priveliges in the registry, but this could be done on HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\Vid_....&Pid_.... since we did know the Vid and Pid of the devices in use.
We realy didn't like this solution, but under the circomstances it was the best we could come up with. If anyone has a better solution (the one we came up with was subject to a good amount of group thinking!) I will be very interested.
Posted by:
sejacru
18 years ago
Hi,
Thanx for explaining.
Why did you not used the old drivers? I understand that you had a deadline but the old drivers also works for the, lets say, palm treo.
Thanx for explaining.
Why did you not used the old drivers? I understand that you had a deadline but the old drivers also works for the, lets say, palm treo.
Posted by:
Ilikebananas
18 years ago
Hi,
Well, that's group thinking, you tend to overlook the easiest of solutions. Once we got started on the problem, we never even bothered to check if the old drivers would do just as well. Did you by the way test them on a T5?
Ilikebananas
Well, that's group thinking, you tend to overlook the easiest of solutions. Once we got started on the problem, we never even bothered to check if the old drivers would do just as well. Did you by the way test them on a T5?
Ilikebananas
Posted by:
sejacru
18 years ago
No that device is not yet tested. I shall try this (when i get this device in hand) and let you know. Do you think this wil not work?
Posted by:
Ilikebananas
18 years ago
I think it probably will, but it will be some time before I can test it myself...
Posted by:
sejacru
18 years ago
I have the same problem. All our devices (about 350 palms) are away, so i don't know where i can find a "lost" palmtop.
Posted by:
sejacru
18 years ago
I have the msi working with the palm 6.0.1.0 drivers.....so if you want more info just let me now
Posted by:
Ilikebananas
18 years ago
Hi sejacru,
You can send it to wat_een_geharrewar@hotmail.com.
btw I use Wise so, if you use wise also, a .wsi + essential files you added could be more efficient.
Thanks in advance...
You can send it to wat_een_geharrewar@hotmail.com.
btw I use Wise so, if you use wise also, a .wsi + essential files you added could be more efficient.
Thanks in advance...
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.