Upgrading a Horizon View Environment

The below links assume a Horizon 5.x environment. The same general process should be followed for Horizon 6 using the appropriate documentation.

Some prerequisites that I would highly recommend before performing any actual upgrades are:

1)      Perform an end-to-end backup of your environment (kb.vmware.com/kb/1008046)
2)      Review the Network Port Requirements for View: (kb.vmware.com/kb/1027217) // Be sure to also review the network section of the install guide for any new ports that might have changed in the target version of View.

In a VMware View environment, your order of operations for a complete upgrade will likely look similar to this (with page references in the View Upgrade Guide below):

1. Connection Server / Security Server (page 34 / 39)
2. vCenter / Update Manager / Composer (page 40 / 25)
3. Hosts (page 45)
4. VMware Tools / Virtual Machine Hardware (page 46)
5. View Agents (page 47)
6. View Client (page 51)
7. Distributed Switches and Datastores (found in vSphere Networking Guide, page 28 and vSphere Storage Guide page 143, respectively)

Documentation for Reference:

VMware View Upgrade Guide (5.2/5.3 shared the same docs)
http://pubs.vmware.com/view-52/topic/com.vmware.ICbase/PDF/horizon-view-52-upgrades.pdf

Horizon View 5.3.5 Release Notes
https://pubs.vmware.com/Release_Notes/en/horizon-view/horizon-view-535-release-notes.html

Keeping a vSphere environment up to date (generic order of events)
http://kb.vmware.com/kb/2004807

vSphere Upgrade Guide (for vCenter, VUM, and ESXi)
http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-552-upgrade-guide.pdf

vSphere Networking Guide
http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-552-networking-guide.pdf

vSphere Storage Guide
http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-552-storage-guide.pdf

For a complete list of VMware Horizon View Documents, Best Practices, and Notes, please bookmark the Documentation Center link here:
https://www.vmware.com/support/pubs/view_pubs.html

I hope you've found this post helpful! Let me know in the comments. Good luck!

Read More

Understanding Authentication in vRealize Operations

// This is a guest post by Jeremy (@nakedhitman)

vRealize Operations offers a number of options for user authentication and permission management, but does not do a great job describing the differences between them and why you should care. Most of the options are fairly easy to understand, but the vCenter authentication source is special and can easily cause confusion. Let's break them down and run through the differences:

• Local Shell Users
  
  
  
  • Example: root
  
  
  • These user accounts can not log in or be imported into the application UI.
  
  
  • They can log in to the shell of the system via SSH or VM console.
  
  
  
  


• Local Application Users
  
  
  
  • Example: admin, maintenanceAdmin, automationAdmin
  
  
  • They can not log in to the shell of the system via SSH or VM console.
  
  
  • The full range of permissions can be granted to local users.
  
  
  
  


• Active Directory / LDAP
  
  
  
  • Example: youruser@yourdomain.tld, yourdomain\otheruser
  
  
  • They can not log in to the shell of the system via SSH or VM console.
  
  
  • Technically, AD and LDAP are the same technology, but with different presets. These sources allow users and groups to be imported from a domain so that they can log in with their common credentials.
  
  
  • The full range of vRealize Operations permissions can be granted to imported AD/LDAP users and groups.
  
  
  
  


• SSO SAML
  
  
  
  • Example: administrator@vsphere.local, youruser@yourdomain.tld, yourdomain\otheruser
  
  
  • They can not log in to the shell of the system via SSH or VM console.
  
  
  • Similarly to the AD/LDAP source, importing users from SSO allows you to assign vRealize Operations roles to domain users and groups. The advantage of using the SSO source is that if you have a complex domain configuration, you can use the existing configuration from SSO without having to re-implement your domain delegation and bindings in vRealize Operations.
  
  
  • The full range of vRealize Operations permissions can be granted to imported SSO users and groups.
  
  
  
  


• vCenter
  
  
  
  • Example: administrator@vsphere.local, youruser@yourdomain.tld, yourdomain\otheruser
  
  
  • They can not log in to the shell of the system via SSH or VM console.
  
  
  • Users from this source are not imported in the traditional sense and vRealize Operations simply trusts the vCenter when it says that a user has permission to log in and see objects.
  
  
  • Because vCenter is responsible for assigning permissions, and because vCenter can only ever be aware of objects in its own inventory, it cannot grant permission to view or modify objects that are internal to vRealize Operations, nor to data that comes in to vROps from other sources.
  
  
  • The vRealize Operations roles cannot be modified or expanded for users that come from the vCenter source from the vRealize Operations side.
  
  
  • vCenter users are unable to create and schedule reports in vROps.
  
  
  
  

The vCenter authentication source is enabled automatically when vCenters are registered and is one of the options for authentication on the vRealize Operations login screen. This causes a great deal of confusion for many users that are using their domain credentials and can log in without issues, yet cannot perform various tasks despite being an "administrator" in the vCenter and/or domain.

Even in situations where "real" authentication sources are configured properly, the vCenter authentication source may still cause confusion since it can present itself as the default, allowing domain users to log in with partial permissions if they are not paying close enough attention. Unfortunately, there is no way to disable the vCenter authentication source, nor to change the default, so you must make an effort to educate your users about the differences and to use the appropriate source when logging in.

Hopefully, this clarifies the differences between the authentication sources and allows you to choose the one that best suits your needs. If any of the above is unclear, please drop me a line in the comments. Thanks for stopping by!

Read More