- Preparing a vCenter Installation
- Installing Microsoft SQL Server
- Installing vCenter
- Installing vSphere
- Installing VMware View
- Configuring the View Connection Server
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Configuring the View Connection Server
As mentioned in Chapter 1, “Virtual Desktop Infrastructure Overview,” there are two versions of VMware View: Enterprise and Premier. Premier includes local mode and View Composer. If you apply a Premier license, you see View Composer and local mode VMs as options. After logging in, you need to add the license. Click Edit License, as shown in Figure 3.64.
)
Figure 3.64. Add the license.
Enter the VMware View Serial Number in the provided field (see Figure 3.65).
)
Figure 3.65. Enter the license key.
Premier licenses enable View Composer and local mode, as shown in Figure 3.66.
)
Figure 3.66. Premier enables View Composer and local mode.
You now have to add vCenter Server, but you should ensure the View Composer service is running first. View Composer supports both 32-bit and 64-bit versions of SQL and Oracle. In addition, VMware View 5.1 can be installed on a separate server, or with vCenter. In View 5.1, View Composer creates a self-signed certificate during installation, so a certificate exchange is done when configuring View to communicate with View Composer. It is also a good idea to ensure you can resolve the vCenter hostname from the Connection Server. You should do a forward-and-reverse lookup using the hostname and then IP. This can easily be done by running nslookup from the command prompt.
To install View Composer on vCenter, follow these steps:
- Click Next on the installation wizard screen.
- Click Next on the end user patent agreement.
- Accept the license agreement and click Next.
- Accept the default path for the installation and click Next.
Type in the name of the ODBC connection you created, as shown in Figure 3.67. You have the option of specifying a username and password. By default, the connection uses Windows NT integrated security. You should avoid hard-coding a password and ID because doing so creates a major security weakness.
Figure 3.67. Specify the DSN connection.
Accept the default port and have the installer create an SSL certificate, as shown in Figure 3.68.
Figure 3.68. SOAP port.
Click Install to install the View Composer service, as shown in Figure 3.69, and click Finish when it is complete.
Figure 3.69. Click Install.
)
)
)
Adding vCenter Server
You are now ready to add vCenter Server to the View Connection Server. Under View Configuration and Servers in the right pane, click the Add button to configure your vCenter Server connection, as shown in Figure 3.70.
)
Figure 3.70. Add vCenter Server.
Specify the Fully Qualified Domain Name (FQDN) of your vCenter Server and the VMware View Service Account name created in Chapter 2, “VMware View Architecture.” Enable View Composer because you have verified that the Composer service is running on the vCenter Server, as shown in Figure 3.71. It is important for View Composer connectivity that you use the format [Domain\User Name], but the vCenter connectivity accepts User Name only. For consistency, it is best to use the same format in both.
)
Figure 3.71. Add vCenter Server.
Click Add under Domains in the View Composer Settings, as shown in Figure 3.71. Then add the domain information in the Add Domain box, as shown in Figure 3.72. This enables the management of computer accounts in the Active Directory. Click OK and OK again to save the configuration.
)
Figure 3.72. Enter domain information.
You should now see the vCenter Server and your first Connection Server as part of the configuration, as shown in Figure 3.73.
)
Figure 3.73. vCenter Server is added.
To ensure reliability, you should install a second View Server. For a PoC, you could use any one of the methods discussed to ensure a single connection broker such as VMware FT or vSphere VM HA is highly available. Keep in mind that VMware FT is limited to a single vCPU at this point in time. VMware recommends that two vCPUs be used for a View Connection Server, so it would not be suitable for a production deployment. For production, you want at least two View Servers that use an appliance-based load balancer such as F5. The process to install the second View Server is identical to the first, except that the second server is a Replica Server. The second Replica Server points to the first View Connection Server, as you can see in Figure 3.74.
)
Figure 3.74. Adding a second View Connection Server.
Configuring the Transfer Server
If you intend to use local mode VMs, you need to set up a Transfer Server and image repository. After setting up a Transfer Server and repository, you publish a desktop for offline mode. The publishing process copies the base image into the image repository.
Local mode allows users to check out, check in, roll back, and back up the local mode VM. When the user checks out a VM, a copy of the base image is copied out of the image repository on the Transfer Server and placed on the user’s local desktop hard drive. The virtual desktops are made up of a base image and a delta file. All changes are recorded in the delta file, and it is this file that is used to facilitate the functionality of the other three options. When the virtual desktop is checked out, the base and delta files are downloaded to the user’s desktop and disk files are locked within the vCenter Server so that no changes can be made to the original source files.
Local mode can be a good option for roaming users who need to get work done both online and offline. It also is ideal if you have a remote branch with slow access to the datacenter. Local mode does enable you to copy any changes back the centralized VMware View environment to ensure that the local VM and locked VM stay in sync.
Checking in synchronizes the delta files stored locally to the one located in the VMware View environment and then deletes the base image on the local desktop and unlocks the files within the virtualization environment for use.
Rolling back does not synchronize; it simply deletes both files on the local user drive and unlocks the files within the virtualization environment for use.
Backing up synchronizes the delta files stored locally and the ones located in the View environment; however, it does not unlock the centrally stored files because a backup allows the local mode VM to keep running or remain primary for the user.
The process for setting up the Transfer Server is similar to the installation of the Connection Server. There are a few things to keep in mind if you are planning on using a virtual machine as the Transfer Server. Each Transfer Server can handle a maximum of 20 check-in or check-out requests according to VMware (http://pubs.vmware.com/view-50/index.jsp?topic=/com.vmware.view.installation.doc/GUID-1A3719FC-C75A-4ED9-B5D3-70334150BD39.html). After they are added to the View Configuration, they are disabled from DRS. In addition, the servers are configured with an additional three SCSI LSI Logic Parallel controllers to allow them to handle more user requests, as shown in Figure 3.75.
)
Figure 3.75. Three additional LSI Logic SCSI controllers are added for a total of four.
If you are deploying the Transfer Server as a new VM, select the LSI Logic adapter, as shown in Figure 3.76.
)
Figure 3.76. You must use the LSI Logic adapter.
To install the Transfer Server, follow these instructions
- Launch the Connection Server Installer and click Next.
- Click Next on the patent agreement screen.
- Accept the license agreement and click Next.
- Accept the default location and click Next.
- Select View Transfer Server and click Next.
- On the Transfer Server Configuration screen, provide the name of the domain, server, and email address of the administrator.
- If the firewall is enabled, select Configure Firewall Automatically; otherwise, skip this step.
- Click Install and then Finish.
Adding the Transfer Server
To add a Transfer Server, you must first add the Transfer Server and then add the virtual machine storage repository as follows:
- Log in to the View Connection Server using the View Administrator Console.
- Under View Configuration, select Server and select Add Transfer Server.
- Ensure your vCenter Server is listed as the source for the Transfer Server and click Next.
- The utility queries the inventory of VMs, or you can manually enter the name.
- Select your Transfer Server and click Finish.
Adding the Image Repository
After adding the Transfer Server, you need to add an image repository. The image repository is the place where VMDKs are copied and stored so that they are available for check-out.
To add a storage repository, complete the following steps:
- Log in to the View Connection Server using the View Administrator Console.
- Under Transfer Server Repository, click Edit to add the image repository information. You can specify a repository stored locally on a Transfer Server or on a centralized file share.
Publishing Virtual Machine for Offline Mode
To publish a VM for offline mode, you need to create a desktop virtual machine and take a snapshot to create the delta disk. After creating the snapshot, you can publish this virtual desktop for use as a local mode VM as follows:
- Log in to the View Connection Server using the View Administrator Console.
- Under Transfer Server Repository and under Content, select Publish.
- Select Snapshot Created Off Your Base Image.
The Event Database
The Event Database was introduced in VMware View 4.5 to allow you to store any event that occurs in the View environment to an external database. Adding an Event Database is optional but highly recommended. It is difficult to manage the Connection Server without the Event Database, which can be a key source of information when you are troubleshooting issues. The database is supported on Microsoft SQL Server or the Oracle database. You can create an Event Database by first creating the database in SQL and then configuring the connection within VMware View. With the Event Database, unlike other database configurations, you don’t need to create an ODBC connection. You simply add the connection information to View. The Event Database requires local SQL authentication, so the first step is to create a local SQL account and ensure it has the appropriate access to the Event Database. You can create a local SQL account using the following procedure:
- Open SQL Management Studio and connect to your database instance.
- Open the Security and then the Logins modules.
- Right-click Login and select New Login.
- Under the General Settings, ensure SQL Server authentication.
- Provide a login name such as svc_Events and provide a password. Note: SQL 2008 requires this to be a complex password, so stay away from any dictionary words.
- Retype the password to confirm it.
Because this is a service account, deselect the following:
- Enforce Password Policy
- Enforce Password Expiration
- User Must Change Password at the Next Login
- Under the default database, select your Event Database, such as vEvents.
- Select the User Mapping page.
- Select db_owner in addition to the default public access and click OK.
After creating the local SQL account, you can then add the Event Database from the View Administrator Console. Under View Configuration select Event Configuration.
Provide the name of your database server, the type, and a user ID in the fields shown in Figure 3.77 to connect. The table prefix ensures that the Event Database can be unique to this collection of VMware View Servers. If you have another site, both can use the same database service because the table prefix is unique. You have to provide a prefix, however, if you have only a single site for VMware View Servers.
){kind=link}
Figure 3.77. Add an Event Database.
After you connect the Event Database, you can set the period in which events appear in the console and the duration in which events are considered new, as shown in Figure 3.78. After you have the settings configured, click OK.
){kind=link}
Figure 3.78. Set the event display options.
Persona Management
Persona Management, which is new to VMware View 5, allows you to deliver, synchronize, and manage user profiles. Persona Management came from a licensing and co-development agreement with RTO Software (http://www.vmware.com/company/news/releases/rto-vmworld09.html). It can be used as a replacement or an enhancement to Windows profiles. The difference between Persona Management and Windows profiles is that only the registry information that is required for the user to log in is downloaded, not the entire profile. As the user opens additional applications, the remaining files are downloaded. The minimalistic approach to data at the start keeps the user logon process quick and streamlined. Like Windows profiles, this feature uses a file server or CIFS share to ensure the user data is centralized. Persona Management also gives you finer control of the synchronization of data between the local user session and the storage repository. By default, this happens every 10 minutes but can be adjusted.
Prior to Persona Management, VMware View offered user data disks, which have now become persistent attached disks. A persistent attached disk is a second VMDK where any user writes (including the profile) could be stored. The only challenge with a secondary drive approach is that the information is local and associated with a virtual desktop versus centrally available. You can now use both of these technologies to essentially provide a local user cache. You can use the user persistent disk to provide a local user repository for linked clones or Composer-created View desktops and Persona to make sure the changes are synced centrally so that they are preserved in case the virtual machine drives are lost. You should ensure the local Persona persists between logoffs, so do not enable the Remove Local Persona at Log Off setting in this case. We review this topic more in Chapter 6.
The nice thing about Persona Management is that it applies to both physical and virtual desktops as of VMware View 5.1. Keep in mind that if you are using shared server-based desktops (TS Servers), Persona Management is not supported. If you have users accessing View desktops using Persona Management and Windows roaming profiles on regular desktops, the best solution prior to 5.1 was to separate them. Now you can use a single Persona profile. If you are using a combination of Windows and View profiles, the View desktops can be configured to override an existing Windows profile in the configuration settings. This ensures that the Windows roaming profiles don’t overwrite Persona profile settings when the user logs out.
Outside the file server requirement, Persona Management does not require any additional infrastructure because it can be installed with the View Agent on the virtual or physical desktop. The configuration of Persona Management is managed through an Active Directory Administrative template, which can be imported into the OU that you are deploying the virtual machines to or the local policy settings of the virtual desktop. The Administrative template is located on the View Connection Server:
<install_directory>\VMware\VMwareView\Server\extras\GroupPolicyFiles\ViewPM.adm
To import these policies into the AD, follow these steps:
- Open your Group Policy Management Console.
- Right-click your View Desktop OU and create or link a GPO policy.
- Enter a name such as View Persona Management Policy.
- Right-click the new policy and select Edit.
- Browse to Administrative Templates and select Add/Remove Templates.
- Click Add again, browse to the location on the View Server, and select the ViewPM.adm template.
- Expand Administrative Templates and VMware View Agent Configuration and Persona Management.
To import these policies into the local user policy, follow these steps:
- Open Local Security Policy.
- Right-click Administrative Templates and click Add\Remove Templates.
- Click Add again, browse to the location on the View Server, and select the ViewPM.adm template.
- Expand Administrative Templates and VMware View Agent Configuration and Persona Management.
Security Servers
Security Servers are another type of View Server but designed to be deployed to simplify remote access. Because they are usually deployed in a DMZ situation, they are not required to be part of the Active Directory. They reduce the number of connections that are required to be open on the forward-facing firewall of a DMZ (demilitarized zone) and corporate or internal firewall. Each Security Server is paired with a specific Connection Server, so if you are load balancing two Security Servers in the DMZ, you require two View Servers deployed internally.
New in VMware View 5 is the capability to proxy PCoIP. Prior to version 5, only the Remote Desktop Protocol (RDP) was available through a Security Server. To work, the connections must be tunneled through the Security Servers. Typically, the Security Servers are deployed in a DMZ and should be load balanced behind an appliance-based firewall such as F5, as shown in Figure 3.79. If you are load balancing the Security Servers, you should not load balance the connectivity from the Security Servers to the Connection Servers because there is a one-to-one relationship between Security Servers and Connection Servers.
)
Figure 3.79. Security Servers are deployed in the DMZ.
Firewall Rules
To allow the traffic to pass through the external firewall to your Security Server, you should translate the external IP to the internal IP and ensure the required ports are open using NAT. You can find a detailed network flow diagram in the View 5 Architecture planning guide starting on page 61; it is downloadable from http://pubs.vmware.com/view-50/topic/com.vmware.ICbase/PDF/view-50-architecture-planning.pdf. The following ports need to be open:
PCoIP traffic between the View Client and Security Server (External)
- TCP 443 for the website
- TCP 4172 from Client to Security Server
- UDP 4172 between client and security server in both directions
To allow the traffic to pass, you must set the following rules on the internal firewall.
PCoIP traffic between the View Security Server and Virtual Desktop (Internal)
- TCP 4172 from Security Server to virtual desktop
- UDP 4172 from Security Server to virtual desktop in both directions
You must set up several things for the Security Server to work properly. The first consideration is the external URL. If you are going to provide access to a View environment remotely, you must register a public-facing IP address and register it in DNS. Let’s use the example of access.virtualguru.org. The DNS name is important because during the configuration of the Security Server, you configure it to respond to this external URL versus its own hostname. Although we discuss straight installation in this chapter, it is not typical that remote access is offered with single-factor authentication. It should always be combined with a two-factor authentication method such as RSA.
Adding the Security Servers
The first thing you should do is define a pairing password, which you do from the View Connection Server, not the Security Server.
First, log in to the View Connection Server. Then, under View Connection Servers, select the More Commands button, as shown in Figure 3.80.
)
Figure 3.80. Add the Security Server.
Specify the Security Server pairing password, confirm the password and set the password timeout. You should specify a short amount of time for security reasons and also ensure that the Security Server pairing is done before the expiry.
Now you can install your Security Server using the following steps:
- Launch the Connection Server Installer and click Next.
- Click Next on the patent agreement screen.
- Accept the license agreement and click Next.
- Accept the default location and click Next.
- Select View Security Server and click Next.
- Provide the IP or hostname of the Connection Server to which this Security Server will be associated and click Next.
- Provide the pairing password you configured in the View Server and click Next.
- Specify the external URL that this Security Server should respond to—for example, access.virtualguru.org—and also the IP address that this DNS name is registered to for PCoIP connections. Then click Next.
- Allow the installer to automatically configure the firewall. I recommend that you definitely leave the firewall intact when deploying the Security Server Security Server in the DMZ and click Next.
- Click Install and then Finish.
If you are going to tunnel PCoIP, you must tell the View Server paired with the Security Server to use PCoIP Secure Gateway for PCoIP to desktop. Under the View Server, select Edit and ensure User PCoIP Secure Gateway for PCoIP Connections to Desktop is selected. The Use Secure Tunnel Connection to Desktop setting is the default and should be left as is, as shown in Figure 3.81. The External URL and PCoIP External URL point to themselves for the internal View Server, which is fine. Only the Security Server needs to respond to the external IP addresses.
)
Figure 3.81. Enable the PCoIP Secure Gateway.
After the gateway is properly installed, if you refresh the View Administrator Console under Security Servers, you should see your server there, as shown in Figure 3.82.
)
Figure 3.82. View your Security Servers.
If you need to change the External URL or IP for tunneling PCoIP, you can click Edit on the Security Server.