I can definitely see how that diagram is confusing, but it is intended to show internal clients going through the load balancer directly to the connection servers. If you look at the architecture...
See more...
I can definitely see how that diagram is confusing, but it is intended to show internal clients going through the load balancer directly to the connection servers. If you look at the architecture guide and whitepapers they all show internal clients bypassing the security servers.
There is no setting today to do that - the client will try and use all monitors available to it. You can raise this on the product feature request page but for now your workaround is probably the...
See more...
There is no setting today to do that - the client will try and use all monitors available to it. You can raise this on the product feature request page but for now your workaround is probably the only option if you want to use both 24-inch screens in multi-monitor mode.
ok, the key line I get from that is: Caused by: com.vmware.vdi.adamwrapper.exceptions.ADAMObjectAlreadyExistsException: [LDAP: error code 68 - 00002071: UpdErr: DSID-03050371, problem 6005 (EN...
See more...
ok, the key line I get from that is: Caused by: com.vmware.vdi.adamwrapper.exceptions.ADAMObjectAlreadyExistsException: [LDAP: error code 68 - 00002071: UpdErr: DSID-03050371, problem 6005 (ENTRY_EXISTS), Are you trying to create a desktop with an ID/name that already exists in your environment? Or perhaps trying to create one with an ID that's the same as a farm?
You would be better off configuring the client device with mirrored displays, not the desktop. That way it would look like a single-screen setup to View and you're only remoting one display over ...
See more...
You would be better off configuring the client device with mirrored displays, not the desktop. That way it would look like a single-screen setup to View and you're only remoting one display over the network, which will require less bandwidth, memory and CPU utilization.
No, that's the only way you can do it for both internal and external users to share the same connection server - enabling the PSG setting is per CS. If you want the PSG on for external users (and...
See more...
No, that's the only way you can do it for both internal and external users to share the same connection server - enabling the PSG setting is per CS. If you want the PSG on for external users (and this is pretty much a requirement unless you're using a thirdparty VPN), but off for internal users, they will have to point to different connection servers and therefore you'll need two.
Are you using a license type that doesn't have application remoting support? This should be listed in the license section of the admin UI. Without it you are still able to set everything up, but...
See more...
Are you using a license type that doesn't have application remoting support? This should be listed in the license section of the admin UI. Without it you are still able to set everything up, but application entries will be filtered from clients.
It sounds like you're not actually redirecting the device as USB, and instead it's being seen as a keyboard local to the zero client, with the resulting keystrokes being sent across to the deskto...
See more...
It sounds like you're not actually redirecting the device as USB, and instead it's being seen as a keyboard local to the zero client, with the resulting keystrokes being sent across to the desktop. Teradici have a support article detailing how to bridge USB devices that by default are kept local: https://techsupport.teradici.com/ics/support/KBAnswer.asp?questionID=616
Can you explain what you mean by "migrated some VMs from a manual pool to an automated pool"? Suspect that's key to what you're seeing, that's not a supported operation and the move you've done w...
See more...
Can you explain what you mean by "migrated some VMs from a manual pool to an automated pool"? Suspect that's key to what you're seeing, that's not a supported operation and the move you've done will have broken assumptions View can normally make. VM names are checked in the pool's folder in vCenter, it's not doing a simple count of entries in ou=servers.
Not on the broker, but there's the Start Session scripts on the VM itself: http://pubs.vmware.com/view-52/topic/com.vmware.view.integration.doc/view_integration_startsession_script.9.2.html Note...
See more...
Not on the broker, but there's the Start Session scripts on the VM itself: http://pubs.vmware.com/view-52/topic/com.vmware.view.integration.doc/view_integration_startsession_script.9.2.html Note that these get executed when a desktop VM has allocated the connection, not at the point the client connects - it is possible for the client to fail to complete the connection (crash, cancel, network failure), and so any solution you design needs to handle that. Mike
It sounds like using kiosk mode to do the broker authentication and desktop connection, and then disable SSO and instead have users log on manually inside the VM, would fit your usecase?
Afraid not, there's no change vs previous versions in this regard. Other than a couple of posts on the communities forums that you mention, I don't think I've seen anything official - have you ra...
See more...
Afraid not, there's no change vs previous versions in this regard. Other than a couple of posts on the communities forums that you mention, I don't think I've seen anything official - have you raised this using the Feature Request form or with a sales rep? Relying on interactive logoff scripts is generally not a good design for something like VDI - even if it was visible, if the client became disconnected for any other reason you would not be able to get back to the session.
As mentioned, this is a known issue with the vcops for view component - while it's running, it's actively using files that are part of the connection server install. The 5.1 uninstall, unable to ...
See more...
As mentioned, this is a known issue with the vcops for view component - while it's running, it's actively using files that are part of the connection server install. The 5.1 uninstall, unable to remove those files, schedules them for delete on reboot. It's a known issue that we created a KB article for, you need to stop the vcops service before upgrade as a workaround, and we plan to fix it by stopping the vcops service during the upgrade automatically in future releases. http://kb.vmware.com/kb/2075114 [Edit: the KB article was not originally marked as public, link has been updated]
2003 R2 may only be used as a terminal server source in View. You may run 2008 R2 VMs as desktop sources with View 5.3, but other than that you must use desktop OS versions. Mike
I believe this is expected - after a linked clone is created, its network settings are preserved across refresh/recompose operations. From View documentation: "During View Composer recompose a...
See more...
I believe this is expected - after a linked clone is created, its network settings are preserved across refresh/recompose operations. From View documentation: "During View Composer recompose and rebalance operations, a best effort is made to ensure that the network label of each NIC attached to each linked-clone desktop is preserved when a linked clone inherits new NICs from a new base image. View preserves the network label of a NIC that was in place before the recompose or rebalance operation as long as the new base image has an available NIC configured with the same type of network switch. (A NIC can be configured with a standard network switch or distributed virtual network switch.)"
Both options should be fine as long as you continue to make sure that the documented requirements are met (i.e. make sure that if you select to generate a new key it's still exportable like the o...
See more...
Both options should be fine as long as you continue to make sure that the documented requirements are met (i.e. make sure that if you select to generate a new key it's still exportable like the old one, and that the vdm friendly name is removed from the old cert and placed on the new one).
2014-01-29T14:04:16.249+01:00 WARN (095C-0D58) <3416> [ws_ldap] Inbound Neighbor last successful LDAP replication attempt to Graaf-VmView2.xxx.local was at Fri Aug 16 17:26:52 2013.
It lo...
See more...
2014-01-29T14:04:16.249+01:00 WARN (095C-0D58) <3416> [ws_ldap] Inbound Neighbor last successful LDAP replication attempt to Graaf-VmView2.xxx.local was at Fri Aug 16 17:26:52 2013.
It looks like you have servers that are not communicating properly with each other. If so, they could both be attempting to manage the VM. Check that this server is either uninstalled and fully removed from the environment (see vdmadmin command tool to clean up a stale server entry), or bring it back online and check ldap replication is functioning properly between all servers.
As Linjo says, the simplest solution is to set up an additional security server to point these clients to (no need for another connection server, you can pair it with the existing one). You are r...
See more...
As Linjo says, the simplest solution is to set up an additional security server to point these clients to (no need for another connection server, you can pair it with the existing one). You are required today to provide an IP address for the PSG, so you will need a second server if you need to route them through a different one. Of course, if they are completely untrusted clients then you may want to force them to go through the external access point anyway but it sounds like you need to avoid the extra traffic cost of that approach. Mike
Did you remember to add yourself to the desktop entitlement list? After setting up a pool it is an additional step. If you look at the "desktop pools" list, you can select your pool and click on ...
See more...
Did you remember to add yourself to the desktop entitlement list? After setting up a pool it is an additional step. If you look at the "desktop pools" list, you can select your pool and click on the "entitlements..." button at the top of the page.