Hi, we bought this solution for one of our customers running Vmware vSphere4 Order No. 6247 for "USB over Network (16 devices)(actually we need 10 for now) but we are facing a serious problem while trying to configure it.
Our client has 10 virtual machines Windows 2003 servers that will run as application servers and each one of them requires a hasp/Dongle. Eight of them (Usb/Hasp Dongles) are completely same devices and and in the window of UoN Server all dongles have the same name, when we are trying to enter a nickname for one of them, the nickname becomes same for all other same type shared dongles so the client side probably gets confused and maps wrong dongle to wrong Virtual machine, then the application is not running with licencing error messages(cannot find the correct dongle).
We tryed to use the advanced method (using Device Ids mapping) but as we were testing the redundancy of a failed usb port on UoN Server if the Usb hub is connected to another native usb port all Device Ids are changed!!! And this is catastrofic for our production site..!
Please advice us what is the best practice for our environment, in the forums i read that a new beta version will allow different nicknames in same hardware type of dongles. We are running now the latest build server/client v4.3. Is there any new beta version we can download from somewhere to solve this critical issue
Yes, we are aware of the issue with identical models of USB devices. The new version you mentioned is going to be developed, but unfortunately that's not going to happen in the near future.
We can offer you 3 options: 1. We are going to release a Linux version of USB over Network Server in approximately 1 or 2 weeks where this issue will be solved. If it's possible for you to switch the server to linux, you may use this linux version instead of the windows one. 2. If possible, you may try not to connect your USB hub to different USB ports, for example use another hub permanently for these usb dongles, connected to only one USB port of the machine. 3. You may wait for the new windows version to be released, but this is the worst case scenario as this won't happen soon unfortunately (no timeframe yet).
Please let us know if any of this options is acceptable for you.
1 ) We have to wait for test the linux version or there is a beta we can already download? Do we have to pay extra license for linux version or we can use the same (already purchased) license we have for windows?
2 ) Redundancy is A MUST for us, we tested the product in our labs with different usb sticks (we couldnt imagine the issue with the same type of usb dongles) and with the use of nickname on assignment to clients, there was awesome performance and stability, that's why we proposed this solution to our customer, on the other hand the use of device ids on assignment is completely rejected by customer while the device ids are being changed when the dongle is connected to another usb port and the mapping to the virtual machine is lost with all the consequences to the application servers.
Ok, i think for now we ll have to move on the process with the device ids. Please tell me something, cause of all these tests we performed for redundancy in different usb ports, the device ids are continuously growing up for the same devices that connected to other usb ports.
Is there any way to "reset" somehow these ids and start over again from 000x. At least this would be enough easy for customer to remember a smaller id number for each mapping than now. The id numbers now are above 002x.
If we uninstall and re-install the application this would be enough to fix it, to reset the ids counter, to make the machine forget the existence of the previous tests.. and make a good start.
1. Go to registry editor (Start - Run - Regedit) 2. Find the following registry branch HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\FABULATECH\USBDEVICE 3. Right click on in - permissions - check 'allow' at 'full control' 4. Delete this USBDEVICE folder (it'll show you an error not deleting all subfolders, but it's ok) 5. Go to the properties again and remove the 'allow' check mark at 'full control'
A few minutes ago I sent you the evaluation version of the server for linux, but please don't try it yet as the identical device problem is not solved there. I was just told that the version you need is being tested right now and will be available for download very very soon.
As for the windows version, unfortunately this is still unknown...
I just received a problem from customers Site, concerning a connection problem when the UoN Server, when UoN Server remains inactive (no traffic from or to the hasps) for more than one day but there are left connected, the Clients (Virtual Machines) fail to contact the hasps and when the only way to recover that is to restart the UoN Server. Our Host is running Windows XP Professional Sp3.
Is there any known issue or a setting we can avoid this situation?
Please tell me what is the version your clients are using? This is possible on older versions. If it's the latest one, our developers will start looking into this.
Home
Search
Members
Login
Register
Reply
Notify of replies
Print
Author
Quote
Modify
IP Logged