H
harry
Guest
We are running applications developed in VB6
in a citrix environment. the apps also run locally from desktops. The
citrix servers have never had a problem with recieving data from the
barcode scanners on the client machines.
But in our latest project, we are seeing PUZZLING problems in our
testing. You propably dont need to be a guru in TS but I would think
you need experience in setting up terminal services with clients that
operrate USB devices.
My problem is that in using the activex control supplied by motorola,
we have to take it out of default mode and put it into a "USB OPOS
Handheld" mode.
when we go into "USB OPOS Handheld" mode, input from the
Scanner is no longer reaching the remote application.
In fact ANY application wont work remotely; a 2nd testing application,
compiled by motorola, also is unable to comminicate when it works in
the new mode.
I think these facts have eliminated quite a few possibilities. It isnt
a mistake in coding since the supplied testing exe reacts exactly the
same in local vs citrix. The scanner itself isnt at fault. Using the
new mode will work as a local application, so by itself, its not at
fault. Its not anything about XPe on the thinclients since from either
a full desktop or from a thin client, our local vs remote test results
are the same. As to what is the weakest link -we can remove the
scanner, the new operating mode, the app and the client machine.
Leaving me to look at either citrix and or terminal services and how
they react with the new operating mode. What about this new mode
makes its scans unable to arrive at the citrix running application?
Why cant we see data from that same usb device? in the same
applications ?
I did some experimenting and looked at what the "Device Manager" had
to say about my scanner and its different modes. Let me know what you
thnk about these observations.
with nothing plugged in the usb ports of the thinclient - the device
manager shows NO Human IDs. I plug in my LS2208 barcode scanner (from
symbol now part of motorola) and a single entry appears within the
HUMAN INTERFACE DEVICES category. it is a "USB Human interface device"
looking at its drivers properties I see that this provides HidUsb
service, its enumarator is USB and its INSTANCE ID is
USB\VID_05E0&PID_1200\S/N:
2CF66B5C6C73494DA53C0D4E96FA27AF_REV:NBRMIAAS3
IN this mode, my scanner comminicates with remote applications without
any trouble.
Now I scan the special barcode that puts this device into its "USB
OPOS Handheld" Mode. The device managers tree collapses, reopens,
collapses again and reopens. The HID category now has TWO ENTRIES. The
entry that existed before is there. But its PROPERTIES have changed
value! That instance id above? its now this!
USB\VID_05E0&PID_1300\S/N:
2CF66B5C6C73494DA53C0D4E96FA27AF_REV:NBRMIAAS8
notice the PID is now 1300 and at the end its a s8 and
not an s3
Now about that new 2nd entry into the HID category, this is listed as
an HID-compliant device. this is its instance ID:
HID\VID_05E0&PID_1300\6&750D171&0&0000
I do not have much experience in registry hacking nor kernel32
knowledge, so I just might be missing a whole lot. BUT what I do
notice is that I NO LONGER HAVE A USB device that has a PID of 1200.
AND MY REMOTE APPS DO NOT receive any of the scanners input.
I gotta think this is more than a coincidence.
SO what is the answer?
we cant be the only people on the planet using a Point of Sale device
with Microsoft terminal services; someone out there must know what we
have to do to make terminal services not freak out when the usb device
switches into its new mode.
Any ideas?
thanks for reading,
Harry
in a citrix environment. the apps also run locally from desktops. The
citrix servers have never had a problem with recieving data from the
barcode scanners on the client machines.
But in our latest project, we are seeing PUZZLING problems in our
testing. You propably dont need to be a guru in TS but I would think
you need experience in setting up terminal services with clients that
operrate USB devices.
My problem is that in using the activex control supplied by motorola,
we have to take it out of default mode and put it into a "USB OPOS
Handheld" mode.
when we go into "USB OPOS Handheld" mode, input from the
Scanner is no longer reaching the remote application.
In fact ANY application wont work remotely; a 2nd testing application,
compiled by motorola, also is unable to comminicate when it works in
the new mode.
I think these facts have eliminated quite a few possibilities. It isnt
a mistake in coding since the supplied testing exe reacts exactly the
same in local vs citrix. The scanner itself isnt at fault. Using the
new mode will work as a local application, so by itself, its not at
fault. Its not anything about XPe on the thinclients since from either
a full desktop or from a thin client, our local vs remote test results
are the same. As to what is the weakest link -we can remove the
scanner, the new operating mode, the app and the client machine.
Leaving me to look at either citrix and or terminal services and how
they react with the new operating mode. What about this new mode
makes its scans unable to arrive at the citrix running application?
Why cant we see data from that same usb device? in the same
applications ?
I did some experimenting and looked at what the "Device Manager" had
to say about my scanner and its different modes. Let me know what you
thnk about these observations.
with nothing plugged in the usb ports of the thinclient - the device
manager shows NO Human IDs. I plug in my LS2208 barcode scanner (from
symbol now part of motorola) and a single entry appears within the
HUMAN INTERFACE DEVICES category. it is a "USB Human interface device"
looking at its drivers properties I see that this provides HidUsb
service, its enumarator is USB and its INSTANCE ID is
USB\VID_05E0&PID_1200\S/N:
2CF66B5C6C73494DA53C0D4E96FA27AF_REV:NBRMIAAS3
IN this mode, my scanner comminicates with remote applications without
any trouble.
Now I scan the special barcode that puts this device into its "USB
OPOS Handheld" Mode. The device managers tree collapses, reopens,
collapses again and reopens. The HID category now has TWO ENTRIES. The
entry that existed before is there. But its PROPERTIES have changed
value! That instance id above? its now this!
USB\VID_05E0&PID_1300\S/N:
2CF66B5C6C73494DA53C0D4E96FA27AF_REV:NBRMIAAS8
notice the PID is now 1300 and at the end its a s8 and
not an s3
Now about that new 2nd entry into the HID category, this is listed as
an HID-compliant device. this is its instance ID:
HID\VID_05E0&PID_1300\6&750D171&0&0000
I do not have much experience in registry hacking nor kernel32
knowledge, so I just might be missing a whole lot. BUT what I do
notice is that I NO LONGER HAVE A USB device that has a PID of 1200.
AND MY REMOTE APPS DO NOT receive any of the scanners input.
I gotta think this is more than a coincidence.
SO what is the answer?
we cant be the only people on the planet using a Point of Sale device
with Microsoft terminal services; someone out there must know what we
have to do to make terminal services not freak out when the usb device
switches into its new mode.
Any ideas?
thanks for reading,
Harry