peterbrown05's Accepted Solutions

Hi So you need to be running a View 5.2 Environment ie 5.2 Connection Server. If this is greenfield, then suggest you go for the latest 5.3 version, and this needs the 5.3 Connection Server. These will then detect the 5.2 (or 5.3 agents). Onto the agents you install the feature pack. You won't be able to install a 5.2 broker in a 4.6 environment as the 4.6 connection server doesn't "understand" the 5.2 agents. For RTAV support - For a 5.2 environment you need to install the Feature Pack 2 and for a 5.3 environment you'd need the FP1. Note; if this is a greenfield site - is it possible to use Lync2013? If so then View has integration with Lync 2013 which will mean that you can benefit from all the goodness of Lync (ie audio and video goes direct to the recipient rather than needing to go via the VM in the datacentre) This reduces the hair pinning effect. see Microsoft Lync 2013 Support with VMware View Desktops | VMware End-User Computing Blog - VMware Blogs and http://www.vmware.com/files/pdf/techpaper/vmware-horizon-view-microsoft-lync-install-configure.pdf cheers peterB

Thanks for the various exchange of files. So we took a look, and might see the cause of the problem - it certainly shouldn't crash (and we will be investigating that seperately, but hopefully we can get you up and running with a config change) We can tell you are configuring Folder Redirection incorrectly, which may be leading to this problem. When configuring folder redirection in the admin template, the paths need to be given as unc paths.  However, you are configuring them as local paths. For example, for Temporary Internet Files you configured "d:\temporaryInternetFiles\someuser" It’s fine for the target to be on the local machine; just needs to be a UNC path like      \\<local machine>\TemporaryInternetFiles\%username% can you try changing that and see if the problem persists? cheers peterB

those install logs look to be from the client machine, rather than the agent - so they dont help us here. the problem is clearly that the agent side is not happy - you are right with the log lines you highlight. and, from device manager, it looks like it is unhappy with several of the "virtual" drivers it has tried to install. was this a "clean" win7 guest install, onto which you installed the View Agent - or had it previously had an agent installed which you are upgrading? certainly the problem is agent side, and you should not see any warning triangles in the device manager. maybe you can try removing the agent and re installing it. cheers peterB

Hi, thanks for the logs - most useful. So - I *think* the problem is that you still have the *old* usb binaries on your system. From the log you can see:          Starting child: vmware-view-usb '-a' 'ipaddress' '-p' '32111' '-u' '[omitted]' the binary vmware-view-usb is the old named binary which didnt support the arbitrator component. We kept the support there for this as back compatability and the client will first try to load that (if its available it will) but if not it will then switch to using the new usb binaries. I presume that when you run;      sudo ./vmware-usbarbitrator -f --trivia then launch the usbd:     sudo ./vmware-view-usbd -o log:trace that both binaries run up and stay "stable" and the crash only happens once you launch the client.  the logs for the arbitrator look fine - if you waited longer before running "vmware-view" client, I think the usbd logs would also look a bit healthier. and i think its that when the old binaries are launched (which they shouldnt be) then things go wrong... As such, can you look on your system for the old usb binaries, and remove them. It should then all work fine, cheers peterB

if you want absolute confidence that usb is disabled (as some customers want in highly security conscious workplaces) then they will often NOT install the usb components on the guest vm during the agent install. Without these, then usb won't work at all. you can use either option for disabling usb. Doing so via GPO might give you more flexibility than just doing it on a per pool basis. also if i allow a class with 23xxxx - does that allow all usb? - i don't understand what you are asking here. can you elaborate? cheers peterB

Hi, I may have misunderstood your requirement, but I think you want to leave the trackball local to the client machine, but then forward all other device interfaces? The software on the guest vm desktop will need to "see" the buttons (for play , record etc) and so i'm sure they will need forwarding. If my understanding is correct then you can configure as follows: if configured guest vm agent side it would be: include vid/pid:           o:vid-0911_pid-149a split vid/pid device:     o:vid-0911_pid-149a(exintf:03) if configured client side it would be just: include vid/pid:           vid-0911_pid-149a split vid/pid device:     vid-0911_pid-149a(exintf:03) What this does is INCLUDE the whole device (normally mice/keyboards are blocked by default). and then forwards the whole device, except interface 3 (which I believe is your trackball). if you want to leave another interface local to the client, then you can do it like this:    ...  (exintf:03;exintf:04) For more information, see my blog post here: https://communities.vmware.com/blogs/horizonViewUSB/2013/03/01/filtering-and-splitting-for-usb-devices-in-vmware-view-51 and also, see What’s New with USB Redirection in VMware View 5.1? | VMware End-User Computing Blog - VMware Blogs for a worked example of splitting. Let me know how you get on, cheers peterB

Hi Romatlo USB is synchronous, and very "chatty". In order for a storage device to appear in windows (if FAT formatted) then the entire FAT table needs to be read. This can be very large, depending on the size of the storage device. The chatty nature of the transfer and the latency involved for each round trip of a message can often mean the device takes many minutes to appear in your guest vm. If the lights are flashing as you describe, then I Would hazard a guess that it is actually working, and if you leave it long enough then the device will appear.. There is some more information in my blog post here: USB Device Redirection in VMware Horizon View 5.1 and 5.2 | VMware End-User Computing Blog - VMware Blogs Also, (linked from that blog post) in my KB here - which offers some suggestions to improve performance: http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1022836 in summary - for better performance, try reformatting the device using NTFS instead of FAT. A lower network latency will also help - but - thats probably not in your control! hope this helps, peterB

Hi Geoff we have seen some people with similar issues. We believe there may be a problem when the upgrade is done from an earlier version of View. In your original post you mention: "if I reinstall or repair the View Client after running sysprep it's fixed". Did you mean reinstall/repair the agent rather than the client? The problems we have been investigating have all been caused by agent side issues rather than client problems. Wondering if you could try something to see if this resolves the problem. After getting your agent to the required version of view, but before performing the sysPrep operation. Please first confirm that the agent works for USB redirection. In order to solve the problem you are facing there are one of 2 possible ways to achieve this. One way works for some people, and another works for others. Would appreciate any feedback on your findings. prior to doing the sysPrep but having confirmed USB redirection is working; Method 1: (not works for some people, not all) 1. go into Device Manager, and delete the "VMWare View Virtual USB Hub" device. 2. right click in device manager, and scan for hardware changes. This should re-install the latest version of the vhub driver. 3. reboot the agent Now check if USB is still working, and then try your sysPrep as before. Method 2: (again prior to doing the sysPrep operation) 1. search the machine for "vmwvhub.sys". There will be several versions found, including in C:\Windows\System32\drivers\ and c:\Windows\System32\DriverStore\FileRepository. The version saved in C:\Program Files\VMware\VMware View\Agent\bin\drivers\should be the latest version for your agent install. (probably 5.5.0 xxxx) 2. delete instances of these files that have a version other than the latest of 5.5.0 build-949580. The older View drivers will probably shows a version of 5.1.0 build-668184. 3. now reboot, and confirm USB still functions. The driver loaded in device manager should be shown a 5.5.0. Now try the sysPrep operation. Let me know if one or other of these works for you, Kind Regards Peter Brown