peterbrown05's Posts

hi jayesh i wrote a white paper on this exact subject a few weeks back. Rather than try and repeat the summary/details here, i think best to point you at the link; https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/horizon-cloud-virtual-desktops/vmware_horizon… one thing to note ref your question on GPU; is that the current release for azure we only support 2k12 os for gpu, and this is limited (due to a driver limitation) to a max of 20sessions. We are working on 2k16 support, which will remove this 20session limitation and should be available soon. I will also update the white paper with new sizing info for 2k16 when its available. let me know if you have more questions after you have read the white paper, cheers peterb

great to hear that you got your node up and running! for GPU there are a few things to do here.... 1. Image creation in order to create an image that can be used in a farm for gpu, you have to install the gpu drivers in that vm. its not possible to install the nvidia drivers if the hardware (in our case the M60 card in an NV6) is present --> as such, you *must* create the 'image' based on an NV6 backed machine. ie in the Imported-VM's page you need to select NV6 hardware when creating it Suggest when you create it, you name it to make it clear that this is GPU enabled . eg RDS-GPU-2k12 also note we only support 2k12 in the initial release of Horizon Cloud Service on Azure. We will be adding 2k16 support soon! but for now its 2k12 only. 2. Image Prep Right now, the auto-image creation service does NOT auto-install the gpu drivers. This is something we are looking to fix, but in the meantime, you need to manually install the nvidia drivers. Azure N-series driver setup for Windows | Microsoft Docs  details this pretty well, and provides the link for the NV6 drivers (its a different driver for 2k12 vs 2k16). RDP into the desktop, (recomend creating the image with a public ip address to simplify this, if your security permissions allow this) Download the drivers, install them, and then trigger a reboot. 3. Convert VM to image Now, convert that desktop to an image in the normal way. This is a GPU enabled image 4. Create RDS Farm(s) Finally, you can create farms using this image. Make sure when you do so that again you select the NV6 (GPU backed) size of vm for the farm. This will make sure that you now have a farm with a GPU hardware, with an image with the gpu drivers installed. Once you have your farm and login; I have found that using the little nvidia UI (find it in their application folder) allows you to see if the gpu is being used in the session or not.... (I cant remember its exact name/folder off hand), alternatively run the command line tool;  nvidia-smi  as per the doc link above . our main docs also detail this in a bit more detail than I have done here. hope this helps, cheers peterb

Hi Sophia it is possible to use your own azure image; but there are several steps that need performing manually to make it workable in Horizon Cloud Service. The Auto-Import functionality is really the simplest option, as it takes a very recent (patched) version of Windows and then applies the necessary configuration to make it work. If however you wish to use your own image however, then here are the high level steps you'd follow;  (see the documentation for much more detail on this) you start with an azure created vm running a supported OS. (we dont currently support you uploading arbitrary images from outside of azure.) place this image in a specific resource group so that the azure node can 'see' the vm Ensure that the RDS role is enabled (this requires the vm to be domain join) - this is needed for RDS farms (desktop or application based) Install the Horizon7 agent (this has to be done after the RDS role is enabled) install the DaaS agent install (optionally) the UEM agent and the NVIDIA drivers (if you are using a NV6 machine) configure the daas agent, to communicate with the Azure Node (needs node's IP address) 'pair' the agent with the node by downloading the bootstrap file, and registering that in the vm. reboot the vm at this stage the vm should go 'Active' in the imported vm's page of the administration ui, and from there can be 'converted to an image' and then used in a farm as normal. The auto-import functionality takes care of all of the above (with exception currently of installing uem and nvidia agents, but this is something we are looking to enhance soon.) The documentation does a really good job to walk through the above steps in more detail, so do go and check that out, see Manually Build the Master Virtual Machine in Microsoft Azure for the html guide (similar section in the pdf version:  https://docs.vmware.com/en/VMware-Horizon-Cloud-Service/services/horizon-cloud-14-admin.pdf ) hope this helps, peterb

Hi Sophie No Problem! Its great you are asking questions. Feel free to ask as many as you need. We are here to help, :smileycool: so you are correct in that the initial release we did in October for Horizon Cloud Service on Microsoft Azure had a limitation that you could only use CN=Computers; The VMware Horizon Cloud Service on Microsoft Azure Release Notes state: Editing the default value in the domain join's Default OU field in the Active Directory page does not persist in the system. Even though you can edit the domain join's default OU value on the Administration Console's Active Directory page, the change does not persist in the system. The default OU for the AD domain registered with the node continues to be CN=Computers. However, even though the node's default OU is CN=Computers, you can change the default OU for a farm and assignments are created using the farm's OU. Workaround: Use the farm's OU field to set the default OU for assignments based on that farm. however, this being a cloud service; we did actually push an update yesterday :smileymischief: which improves this (but doesn't 100% fix the issue). let me explain.... so until Monday of this week, you could only override the default OU at the RDS Farm creation level. With the update this Monday, when you first create the node, there is a UI which allows you to override the default OU (which will be applied for all farm creation, unless also overridden as above). This will now work ! yay! If you have already deployed a node, then you can edit this setting by going to:   Settings--> Active Directory and then 'Edit' the Domain Join section. You can then update the Default OU value. Note that this should be in the form OU=NestedOrgName, OU=RootOrgName, DC=DomainComponent   etc. ive attached a screenshot of this UI. What remains however, is that importing an image from the marketplace will continue to use the CN=Computers value. This is something we are working on fixing now, and I hope to have an update for this issue very soon! hope this helps, cheers peterb

Hi Sophie cool, thanks for the info. So; you are in part right. Horizon Cloud Service on Microsoft Azure does not natively support Azure Active Directory (AAD). ie, it cannot directly use AAD for everything that Horizon Cloud Service needs. Specifically, when creating Farms for desktops/apps then we need to register machines in a domain. AAD provides an identity only. Also, our servers and agents talk LDAP rather than the RestAPI that AAD requires. HOWEVER, (and my white paper covers this in more detail), you can if appropriate make use of Azure Active Directory Domain Services (AAD-DS). This is something that acts as a managed AD service and runs in Azure (Microsoft take care of operating it, including patching etc), and it sync's its identity from AAD. There are some things to take note of here though; must have password hashing enabled in a specific way; if not, you will need all users to reset their passwords for the hashes to be regenerated for use with AAD-DS. Also, AAD-DS provides a flat hierarchy, and I do not believe it replicates any OU structure from on-premises. ie Azure then becomes like an island domain. This isnt specific to Horizon Cloud Service, and Im by no means an expert on all the options available here. But, certainly connecting What I would reccomend you investigate is configuring like this: Install AAD-Connect on premise - this will replicate your user identities to AAD (without the dependency on the VPN) Use AAD to provide common cloud identity Make use of AAD-DS to replicate that identity and allow that to be used by Horizon Cloud Service on Azure Make use of the VPN only for end user connections back to base - for data and/or any on premises hosted services/backends. https://docs.microsoft.com/azure/active-directory-domain-services/active-directory-ds-overview is a really good overview to the AAD-DS feature of Azure. as mentioned though, this isn't the only way for AD to be connected into the system. Hosting it locally, or connecting to on prem via VPN are viable options too. I will share the white paper link when it is published later this week, hope this helps, cheers peterb

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