mpryor's Posts

Linked clone pools provisioned by Composer require a domain to be specified as part of the customization. The older full clone pools only require a vCenter Customization Specification to be used ... See more...
Linked clone pools provisioned by Composer require a domain to be specified as part of the customization. The older full clone pools only require a vCenter Customization Specification to be used however, and it's not required to specify a domain as part of that. You can also set up your VMs by hand or an external tool and add them to a manual vCenter pool instead of provisioning them through View. Note that if they are not joined to a trusting domain your users will need to authenticate twice when connecting - once to the connection server and a second time to the desktop VM itself with local credentials. Mike
This should be the same process for 2012/Win8 as it is for 2008/Win7 : Install Desktop Experience on an RD Session Host Server
I know it sounds crazy, but it really is working as designed. If for example you've got the value set to 50 then you should be able to have 50 sessions running in the pool during the recompose, t... See more...
I know it sounds crazy, but it really is working as designed. If for example you've got the value set to 50 then you should be able to have 50 sessions running in the pool during the recompose, the fact that 30 of them are already connected before you start is unrelated. What you're looking for is a feature that always preserve the pool headroom value during a recompose, so that a recompose will not happen if it's expected to violate the headroom count - this is slightly different, would be very useful but sadly doesn't exist today.
> I still don't understand (according to the link again) why a user connected to a desktop be considered a 'READY' state? As I said in my last reply, the 'ready' state is an internal state whi... See more...
> I still don't understand (according to the link again) why a user connected to a desktop be considered a 'READY' state? As I said in my last reply, the 'ready' state is an internal state which is defined to mean one thing to the provisioning engine only. It doesn't correspond to what most people using the UI would think it does - the UI has a different state it displays that also accounts for existing sessions ('available') which is not the same as the internal 'ready' state. This has now been flagged internally that using the name adds confusion because the average user will misunderstand what it is. > So are you saying that if I change the "Minimum number of ready (provisioned) machines during View Composer maintenance operations" to a number that is slightly higher than the number of users currently logged in that it will leave desktops available during the recompose?  Granted I would have to change this number every time I issue a recompose. Yes, that's correct.
There is no current option to specify a fixed resolution for the connect and have it scale to fit the screen, there is however experimental support for DPI scaling mode in the client which may gi... See more...
There is no current option to specify a fixed resolution for the connect and have it scale to fit the screen, there is however experimental support for DPI scaling mode in the client which may give you what you need. In the registry, set: [HKLM\Software\VMware, Inc.\VMware VDM\Client] "EnableSessionDPIScaling”=“true" This feature is not currently officially supported but feel free to play with it and provide feedback. Don't forget that on 64-bit systems this key would instead be at HKLM\Software\Wow6432Node\VMware, Inc.\VMware VDM\Client.
Was this a physical machine? If so it really should have defaulted to that umanaged setting, it may be an installer bug. If it was an ESX VM, it's expected behaviour to be in managed mode by defa... See more...
Was this a physical machine? If so it really should have defaulted to that umanaged setting, it may be an installer bug. If it was an ESX VM, it's expected behaviour to be in managed mode by default and not prompt.
After an initial read of the issue internally, there's been a bit of confusion about the underlying problem which resulted in the SR you created not being picked up immediately. Fundamentally, it... See more...
After an initial read of the issue internally, there's been a bit of confusion about the underlying problem which resulted in the SR you created not being picked up immediately. Fundamentally, it boils down to a disconnect between what the product does and what the average user would interpret the feature as. To elaborate: the documentation (https://pubs.vmware.com/horizon-view-60/index.jsp?topic=%2Fcom.vmware.horizon-view.desktops.doc%2FGUID-D9EBE966-A755-4618-B20D-B8CD74F128BF.html) refers to "Minimum number of ready (provisioned) machines during View Composer maintenance operations". Internally, this has a very specific definition that means it was successfully provisioned and is not in a maintenance operation such as an initial clone or recompose - it does not mean 'ready to be logged into' since that is the more specific 'available' state, that also takes into account whether the VM is already in use, currently booting up, etc. This is reflected in the documentation but could be made clearer in the product itself, to quote: The term "ready" applies to the state of the linked-clone virtual machine, not the machine status that is displayed in View Administrator. A virtual machine is ready when it is provisioned and ready to be powered on. The machine status reflects the View-managed condition of the machine. For example, a machine can have a status of Connected, Disconnected, Agent Unreachable, Deleting, and so on. From the SR you mentioned, the recompose left the minimum number of VMs alone in a "ready" state at any one time but they were all either connected/disconnected and hence not available for other users. I do agree that it doesn't really fit in with what the average administrator would want to happen though for a floating pool, which is really about preserving spare VMs that are ready to log into at any given point in time, but it is technically working as designed and documented. I've raised it internally to look at providing something that more closely matches what you want but it would be considered a feature request rather than bug fix. Hope that clears things up for you, Mike --- A concrete example for those reading the thread: Pool of max size 60, 25 VMs in 'connected' state and 35 in 'available' state Minimum ready VMs set to 40. Maximum concurrent operations set to 100 Trigger a recompose, leave existing sessions intact In this case, when recompose is triggered 20 of the 'available' VMs will be immediately recomposed leaving the remaining 40 VMs intact,  15 of which are available for new users and 25 of which are currently in use but can be reconnected to by their current user. As those in the initial 20 complete, the remaining 15 available VMs will be recomposed. The 25 connected VMs will be recomposed after the existing sessions are finished. Edit: fixed formatting, tweaked example
This thread caught my eye, I'll check with the support team. Mike
You may only select the cluster. "Host or cluster" refers to the fact that if you have a standalone host that is not in a cluster, you may use it - so you'd have to move the host you want to use ... See more...
You may only select the cluster. "Host or cluster" refers to the fact that if you have a standalone host that is not in a cluster, you may use it - so you'd have to move the host you want to use out as a standalone host or into its own cluster. Mike
There's no change with View 6.1 vs older releases - the option you describe is explicitly to allow the same user account to launch multiple sessions from different client machines only. Specifica... See more...
There's no change with View 6.1 vs older releases - the option you describe is explicitly to allow the same user account to launch multiple sessions from different client machines only. Specifically, it will only allow reconnection to an existing session if both user and client match from the previous connection (you may see this described elsewhere as "classroom mode", where unique user accounts aren't needed and differentiation only needs to be made based on which terminal is connecting). You may not launch multiple instances of the client on the same machine in order to get multiple desktops from the same pool with this flag, since they will both match.
Yes that is correct, it is warning because all the hosts in the same cluster do not have the same vGPU support. This means that VMs will not be able to migrate between all hosts, since one with a... See more...
Yes that is correct, it is warning because all the hosts in the same cluster do not have the same vGPU support. This means that VMs will not be able to migrate between all hosts, since one with a K1 vGPU will not be able to run on the K2 host. Best practice is to have a consistent setup within a cluster - while things will continue to work with the mix you have it's not optimal. To remove the warning, move one of the hosts into its own cluster.
Yes they're primarily for security (they will only let traffic through for authenticated users) and for cases where direct access is not possible, such as if the environment is firewalled off or ... See more...
Yes they're primarily for security (they will only let traffic through for authenticated users) and for cases where direct access is not possible, such as if the environment is firewalled off or behind a NAT. It's fairly common to only enable them for external access and leave disabled for internal clients.
No, it is not required. If these options are disabled client connections will be made directly to the desktop VMs, so make sure that it's directly routable and there are no firewalls blocking tra... See more...
No, it is not required. If these options are disabled client connections will be made directly to the desktop VMs, so make sure that it's directly routable and there are no firewalls blocking traffic between the subnets.
The time zone on the desktop VM will be inherited from the client device during connection. I don't know how you're managing your clients but if they've got the correct timezone set everything el... See more...
The time zone on the desktop VM will be inherited from the client device during connection. I don't know how you're managing your clients but if they've got the correct timezone set everything else should follow, any chance the timezone setting is being lost for them when powered off? This MS KB might be relevant to you: https://support.microsoft.com/en-us/kb/2634150
I believe you're looking at an automated pool with specific names, not a manual pool. For those you do not specifically add an existing VM - View itself will create the VM, you just need to add t... See more...
I believe you're looking at an automated pool with specific names, not a manual pool. For those you do not specifically add an existing VM - View itself will create the VM, you just need to add the name to the existing list. The create is likely failing because you already have a VM with that name, check your events log to confirm.
Not tried it myself but I don't think "start" will work. That attempts to start a new command prompt in a window to run the file, which is not applicable for a launch from the service. Instead yo... See more...
Not tried it myself but I don't think "start" will work. That attempts to start a new command prompt in a window to run the file, which is not applicable for a launch from the service. Instead you should call it directly with "call myfile.bat"
Depends on what you mean by not supported - View 6.1 continues to fully support vSphere 5.5 for backwards compatibility so you can use it and keep the AMD vSGA support while trying out the other ... See more...
Depends on what you mean by not supported - View 6.1 continues to fully support vSphere 5.5 for backwards compatibility so you can use it and keep the AMD vSGA support while trying out the other new features that View 6 gives you (check the compatibility matrix for exact versions at http://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsga). I'm afraid I don't know the answer with regards to vSphere 6.0 support of the Firepro 9000, hopefully someone else can expand on that.
The client has to explicitly request a particular desktop pool, so unless you've got some thirdparty component intercepting and rewriting the requests it must have originated from it. Can you pro... See more...
The client has to explicitly request a particular desktop pool, so unless you've got some thirdparty component intercepting and rewriting the requests it must have originated from it. Can you provide more information on your environment including client type, version, any frontend load balancers etc? Presumably you also confirmed that the client device in question hasn't been configured by GPO or command line options to always try a specific resource? How is the client being launched, via a jumplist,shortcut or viewclient:// url link that may be incorrect? The client logs should show what was requested. e.g. 2015-04-16 13:16:50.134+00:00 INFO (0CAC) [WinCDK] LaunchItem::Connect : [User] Enter ConnectToItem:sample-win8-desktop.
Are you able to share a copy of the script with me to reproduce the problem? Sounds like it would be difficult to work out without a live demo. Mike
You checked config.properties, but did you check in locked.properties for the port setting to see if it's been moved in there before/during the upgrade? Locked.properties will override any settin... See more...
You checked config.properties, but did you check in locked.properties for the port setting to see if it's been moved in there before/during the upgrade? Locked.properties will override any settings in config.