peterbrown05's Accepted Solutions

hi jayesh please see my answer on your other question What Limits/Quotas do I need for Horizon Cloud Service?  as that covers a lot of this issue too. Specifically you need to increase the default quota and add the use of F Series VMs, Dv2 and Av2. I *believe* that some of these are not available on the free-trial. Once you convert the free-trial account to a paid one then Microsoft lets you increase the quotas. To help with some of the costings there are various blogs and such on the subject. I did write a white paper: RDS Desktop and Application Scalability (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/horizon-cloud-virtual-desktops/vmware_horizon_cloud_service_on_microsoft_azure.pdf ) which does attempt to provide some insights into the operating cost on Microsoft Azure at a production like scale. hope this helps, cheers peterb

Hi Jayesh To provide a little more information here, we obviously need several limits/quotas to be considered. These will need to be increased in each and every region in which you want to deploy a node (quotas are per Azure region). If you are deploying a Node with the Internet Accessible Desktops (which deploys the Unified Access Gateway appliances too) then you need a MINIMUM of: 4x VMs 12x Cores (total) 2x F Series cores 2x Dv2 cores 8x Av2 cores If you are deploying without the Internet Accessible Desktops then you need: 2x VMs 4x Cores (total) 2x F Series cores 2x Dv2 cores These may change in the future as we add new capabilities. However, when you come to deploy the node, the Administration console will actually make calls against your azure subscription and check that you have sufficient cores available to do the deployment. It should flag an error and prevent you proceeding if you dont have enough. Of course, the above doesnt actually give you any headroom for the desktops and applications in the RDSH farm (or for VDI in future when thats available). RDSH Servers today use either Dv2 Series vm's or if you want GPU backed, then NV family cores. As such, if you plan to support a farm of N servers you would need to make sure that you have    ( N * cores/server)  for the required family requested. see Windows VM sizes in Azure | Microsoft Docs for the tables of the cores/size mappings;  we use D2v2 (2 cores), D3v2 (4 cores) and D4v2 (8cores) sizes as well as the NV6 (6 cores) as options for RDSH servers. fyi; Requesting an increase to cores is pretty simple. You do this from within your Azure Portal directly, make sure you request 'Resource Manager' for the deployment type, and select the right region. hope this helps, cheers peterb

Hi Steven, Good question - specifically Horizon Cloud Service on Microsoft Azure requires the 'Contributor' role attached to the Application registration (Service principle) for the correct operations to be performed. The reasons for this are that; 1. the automatic deployment of the environment will create networks and subnets along with adding VM's and configuring network security groups (NSGs) 2. once the environment is built, then ongoing management of desktop/application assignments (e.g. RDSH Farms) requires VM's to be life-cycle managed (created, powered on/off, deleted) 3. if you need to delete the node for any reason then the deletion will remove vms subnets etc if they are not in use. (to do this go to Settings->Capacity , then select Node-->Node Details ---> Delete) As such, these require the contributor role to do so. This is covered in more detail in the Pre-Requisites document and the Getting Started Guide. Pre-Requisites Getting Started Guide both linked in the VMware docs portal (VMware Horizon Cloud Service Documentation) and also in the Overview of this community. Hope this helps, cheers peterb

Hi Steven There are a few steps to this; 1. creating an azure subscription (presumably your org already has this, but if not, then this is something you have to first set up) once you have the subscription, the service principle gives access to that environment so that we can create and manage the Horizon Cloud environment. to do this ; 2. Create an application registration in Azure Active Directory 3. Create a Key (secret) for this application registration 4. Assign this application registration to a Contributor IAM role for the subscription 5. Make sure that the necessary resource providers have been configured I suggest you take a look at the Getting Started Guide - it is referenced from the overview in the community site and on the vmware documentation site. see VMware Horizon Cloud (on Microsoft Azure)   Direct link to the getting started guide is: https://docs.vmware.com/en/VMware-Horizon-Cloud-Service/services/hzncloud-microsoftazure-14-getstarted.pdf The getting started guide walks you through all of these steps (with pictures). The process should take no more than 5minutes to complete. Once completed, this then has 4 values (subscriptionID, DirectoryID, Application ID, Application Secret) and these values can be keyed into the Horizon Cloud Service administrative console when on boarding your Azure node. NOTE: whilst you are in the Azure portal, I recommend you take a look at the quotas and limits, and make sure that you have the Av2, Dv2, FSeries vm sizes with sufficient capacity for the region(s) in which you wish to deploy your node. (you can get this from Subscriptions --> Quotas and Limits) (see https://www.vmware.com/content/dam/digitalmarketing/vmware/en/images/products/horizon-cloud-virtual-desktops/vmware-hori…  for details. hope this helps and do let me know how you get on, cheers peterb

ok... so to disable audio out from the guest on a windows client (for all users of the client) try setting this: x64 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VMware, Inc.\VMware USB\PCoIPAudioForwarding     Disabled     1 x86 HKEY_LOCAL_MACHINE\SOFTWARE \VMware, Inc.\VMware USB\PCoIPAudioForwarding I believe there is a similar key under HKCU too, but sounds like you want a blanked on/off I know this sounds like its a USB related key, but its not. its fr the audio out. cheers peterB

hi there, no answers yet - more fact finding... When you talk about Redirection - this is USB redirection of the scanner correct? Can you explain in more detail what this means: "the scanner needs setup each time it opens a new desktop.  That requires scanning in the code to the new desktop" is the problem that the usb drivers end up being installed each time a user connects? or, ...? I dont really understand what is happening here. If a user has to "scan in a code" - where do they do this and into what app do they do this? What does that app then do - write some registry keys? Is the problem that a specific device (and serial number) gets associated with a desktop, so as a user moved between rooms (but logs into the same desktop) given its a different scanner each time it then needs registering? Let me know a little more detail. Right now, my hunch would be on this being something you'd need to discuss with the scanner app vendor - if they are requiring devices to be registered per desktop. Maybe there is a way to pre-register all devices against all desktops..... anyway, provide a bit more info and i will see if i can offer any suggestions cheers peterB

so first off, the connection server has no role to play in any of the usb filtering that we are talking about here. yes, being on a more recent version of view is good, and might help, but upgrading just the connection server won't actually make a difference here. i'd like to see what you have configured, how you configured it and where. also, id like to see your client debug logs covering a time when you click on the usb menu and have it configured in the way that you mention. can you check on the agent vm that the group policy for the configuration has actually been applied maybe try doing a ; gpupdate /force gpresult and check what policy is being applied. having written ALL of the above, i just realised what your issue is.  (Ill leave the above text, since its still valid info... but read on:) You are running View agent v5.0.0 this version DOES NOT include the usb device filtering that im talking about. so yes, you need to upgrade. The earliest version that supports it is 5.1, but i would suggest you either upgrade to 6.1 (latest version) which gives you loads of new features, and fixes, or if you want / need to stay on the 5.x line, then go to the latest maintenance release version which I think is 5.3.4. Note, you need to upgrade the connection servers AND agents if you want to move up, and please note that there are additional certificate issues that need to be taken into account between 5.0 and 5.1 so make sure you read the upgrade docs appropriately. once upgraded, then apply the config, and it should work nicely. cheers peterB

so the fax/scan issue is a bug with the new scanner redirection feature. i have a blog post coming out shortly that will better explain the feature, but in summary it DOESNT use USB redirection. when you tested the zero client, or indeed the older client software without the scanner functionality installed then thats all using the original USB redirection functionality. This does in deed work in many cases, but you will find that across a WAN then scanning can then take a very long time, and for some scanners their drivers will timeout/fail. so the new scanning redirection functionality captures the image at the local client endpoint, compresses it and sends the image as a whole to the guest where its presented back via a virtual scanner device to the application. This is much like how we do the RTAV functionality. the result is that things should work much more reliably across a wan/unreliable network. the fax/scan issue with the new scanner functionality is a bug which we are working on fixing, and hope to fix it v soon, make sense? cheers peterB

unless you change the "defaults", keyboards and mice (even if they are plugged into usb ports) are not treated as usb devices. Keyboards/mice are considered essential and they get redirected via a different "channel". This means that you dont need USB redirection to be working for keyboards and mice to operate. If you really want, you can change this (ie so that they are treated as usb devices), but you get better performance if the default mode of treating these devices is left in place. This applies to zero and soft clients. the simplest way to disable usb access for offsite users (assuming they are NOT using zero clients) is to block port 32111 at the gateway. this will prevent usb traffic being routed to the guests. Internally anyone using a soft client can still use port 32111, or if they are using zero clients then use the usb embedded in the pcoip payload. if you have some users externally using zero clients, then the way you can block these from using usb would need to be discussed with Teradici. hope this all helps, cheers peterB

hi there can you confirm which version of view agent you are connecting to? we have seen several issues with Epson devices (including this specific check scanner). Problem is actually in the epson driver themselves and it starts up in a sequence that doesnt conform to usb spec. As a result it doesnt get redirected properly and actually ends up in a stuck state. HOWEVER, good news is that there is a registry key that you can set that should make it work; on the agent vm set the following key: HKLM\Software\VMware, Inc.\VMware VDM\USB\Vid_04b8&Pid_0202\DeviceFlags = DWORD: 0x1000 please note, Im pretty sure the Vid/Pid of the TM-S1000 is Vid=04b8  Pid=0202  but please check that, and replace with the correct vid pid for your device if its different; Please see VMware KB: Epson printers become unresponsive in VMware Horizon View   for more details; I believe this registry key (workaround) is available in View Agents v5.2.1 and later. cheers peterB

unfortunately the logs don't show much... (note - they dont contain the client side logs) one thing I was thinking though.... since this is a thinClient - we have seen issues whereby the thinClient manufacturers install some of their own "management" software on the client. This often tries to do stuff with usb devices (perhaps trying to share them between a citrix receiver client app and a view client app, or maybe just there is a citrix receiver app installed too). In our experience we have seen these apps interfere with each other since they are trying to hook the usb devices low down in the kernel. as such, could you try stopping any 3rd party services - either citrix or from your thin client vendor, and then try again. if the problem persists, can you be sure to also collect these logs from the thinclient: Windows Client %PROGRAMDATA%\VMware\VDM\logs\debug-*.txt     AND C:\Windows\Temp\vmware-SYSTEM\vmware-usbarb-*.log Linux Client /tmp/vmware-root/vmware-view-usbd-*.log by default AND /Library/Logs/VMware/vmware-usbarbitrator-<process_id>.log for reference, the Agent side usb logs: %PROGRAMDATA%\VMware\VDM\logs\debug-*.txt cheers peterB

ah - this all starts to make sense I think... we have seen problems in the past when third party tools are used - I believe HP may have had an issue before. They try to do their own usb device management which interferes with the VMware usb device management... Reference setting the autoconnect options ; there are 2 config options available that are most easily set via the CLient side GPO template. Autoconnect on startup - when enabled connects all devices that are present when the session is launched Autoconnect on insert - when enabled connects devices automatically if they are inserted after the session is already started both are disabled by default on Windows and OS X, but enabled by default on Linux. cheers peterB

hi unfortunately at this time - you are right that the audio is limited to 8kHz, mono. This is something we have been thinking about making adjustable - but up until your post - we have had no feedback that suggested we needed to and so it has remained at this sample rate since the initial release. Would you be willing to elaborate on your use case so we can better understand the requirements and identify what sort of audio controls you'd ideally like to see. I can't promise we will implement nor provide a timescale, but having your feedback will definitely help. many thanks, peterB

FYI; Real Time Audio Video should work with *any* cameras. We have tested a huge range from the super cheap to super expensive. The most common seem to be the Logitech's the Microsoft LifeCams, and also the Creative Live! webcams. Im almost certain that all three of them offer hd and non hd webcams, but note that RTAV is configured to sample by default at 320x240, and so even if a webcam advertises that it is a HD webcam, RTAV wont have to push thru such a high resolution and would use the smaller 320x240 sized image (which btw works great in skype). So, really, don't be put off by a HD camera. That doesnt matter, and actually if you wanted to use it for other purposes then maybe good. Probably the biggest deciding factor then would be price. All three of the companies above (and all the other webcam manufacturers) usually have a good range of cameras to suit any budget! Hope this helps, cheers peterB

have a look in Add Remove Programs on the guest vm. You should see a Remote Experience Agent application listed there with a version. For 5.2, you have 1 of 3 possibilities; no feature pack at all Feature Pack 1 or Feature Pack 2. cheers peterB

I am excited to be able to tell you that today we released the v2.3 clients, and the good news is that Mac OS X now supports RTAV! RTAV is only supported on Mountain Lion (10.8) and later. See the release notes here: VMware Horizon View Client for Mac OS X Release Notes Download from here: Download VMware Horizon View Clients for View Documentation here: https://www.vmware.com/pdf/horizon-view/horizon-view-client-mac-document.pdf I will be following up with a blog post shortly talking more about RTAV on OS X. Until then, hope this solves your problem! cheers peterB