VMware View 5 Implementation

Date: Dec 25, 2012

Return to the article

This chapter describes how to get the components of vSphere up and running. First, however, you need to install vCenter. Let’s run through the installation of vCenter, starting from the configuration of the database.

Preparing a vCenter Installation

vCenter supports several different types of databases. The supported databases and versions are

VMware generally recommends that you use Microsoft SQL 2008 Express for smaller environments because it has a fixed limit on how large the database can grow. Although this limit used to be fixed at 4 GB, it is now fixed at 10 GB. VMware recommends that SQL Express be used in environments of no more than 5 hosts with 50 virtual machines.

The following steps assume you are deploying Microsoft SQL 2008 R2. vCenter 5 is a 64-bit operating system and so requires Windows 2008 R2. This section is by no means comprehensive, so you should check the content against your own internal SQL best practices. You can deploy vCenter as a VM or as a physical server or Linux virtual appliance.

Deploying vCenter as a VM used to be a heated topic, but doing so has now become common practice and is also a VMware best practice. What can be problematic is having vCenter as part of the environment it is managing or in the virtual cluster. This is why VMware recommends a separate management cluster in large environments. These problems can be mitigated by ensuring you have built redundancy into the vCenter Server configuration. VMware’s best practice is to run Fault Tolerance (FT), which provides a constant mirrored copy of the virtual machine so that if the primary fails, the secondary takes over with no interruption. VMware refers to this technology as virtual lockstep or vLockstep. VMware FT does have some scaling limitations, however, which may not make it ideally suited for large environments. For example, VMware FT is limited to a single vCPU, so it does not support symmetric multiprocessing (SMP). Future releases will support up to four vCPUs. If you require a multiprocessor server or intend to deploy vCenter as a physical machine, vCenter Heartbeat is the recommended solution; it is discussed in Chapter 11, “High Availability Considerations.” vCenter Heartbeat keeps two vCenter Servers in sync but provides more flexibility on the physical or virtual configuration of the server, such as the number of processors. If you mirror or cluster the SQL database, you do have a few other options for protecting the vCenter server:

VMware actually recommends using a standalone Microsoft SQL Server 2008 R2 cluster with redundant SAN and LAN connections in large scalable environments. The SQL cluster should have dedicated logical unit numbers (LUNs) based storage volumes on the SAN to offload the IO from the VMware cluster versus using datastore-based VMDKs. This option also ensures that the metadata is available outside the VMware cluster if you have a failure.

Although this chapter is not an extensive guide to vSphere 5 deployment, it is important that you configure your underlying installation properly. It also is important to ensure you have a production-grade deployment, which means proper configuration and backup.

To install vCenter, you need database services. In most cases, a separate database is recommended. For smaller environments, however, it is possible to use a copy of Microsoft SQL Server 2008 R2 Express. vCenter Server supports IBM DB2, Oracle, and Microsoft SQL Server databases. Be aware that Update Manager supports only Oracle and Microsoft SQL Server databases.

The minimum hardware requirements are as defined in Table 3.1.

Table 3.1. Minimum Hardware Requirements for Installing vCenter

Hardware

Requirement

Processor

Intel or AMD x86 processor with two or more logical cores, each with a speed of at least 2 GHz. The Intel Itanium (IA64) processor is not supported. Processor requirements might be higher if the database runs on the same machine.

Memory

4 GB RAM. RAM requirements may be higher if your database runs on the same machine. VMware VirtualCenter Management WebServices requires 512 Mb to 4.4 GB of additional memory. The maximum WebServices JVM memory can be specified during the installation depending on the inventory size.

Disk storage

4 GB. Disk requirements may be higher if the vCenter Server database runs on the same machine. In vCenter Server 5.0, the default size for vCenter Server logs is 450 MB, which is larger than in vCenter Server 4.x. Make sure the disk space allotted to the log folder is sufficient for this increase.

Microsoft SQL Server 2008 R2 Express disk requirements

Up to 2 GB free disk space to decompress the installation archive. Approximately 1.5 GB of these files are deleted after the installation is complete.

Networking

1 Gbit connection recommended.1

vCenter Server 5.0 is a 64-bit application, so it requires a 64-bit Windows operating system. The following platforms are supported for vCenter Server 5.0:

  1. Microsoft Windows Server 2003 Standard, Enterprise, or Datacenter SP2 (required) 64-bit
  2. Microsoft Windows Server 2003 Standard, Enterprise, or Datacenter R2 SP2 (required) 64-bit2
  3. Microsoft Windows Server 2008 Standard, Enterprise, or Datacenter SP2 64-bit
  4. Microsoft Windows Server 2008 Standard, Enterprise, or Datacenter R2 64-bit

Because Microsoft SQL Server is the most common platform selected, the following sample installation is based on vCenter Server 5.0 running on SQL Server. Before deploying your vCenter Server database instances, you should follow a few Microsoft SQL best practices. Microsoft recommends that you use separate accounts for all the SQL services. By default, the installer creates a virtual account, which is a local account on the server that a Windows user cannot use to log in to a Windows server. The default installation creates all services with a virtual account except for the SQL Server Browser, which is a local service account, and the SQL Server VSS Writer, which is a local system account. Unlike in prior releases of SQL in which you needed to assign permissions, now the setup takes care of assigning the appropriate permissions for you. However, you can still create the accounts manually, as shown in Figure 3.1. In most cases, the default accounts suffice; however, if you are deploying a cluster, the following need to be domain accounts:

Figure 3.1 shows the manual creation of specific service accounts.

Figure 3.1. Manually creating SQL service accounts.

Although it is dated, Microsoft provides a guide called “Services and Service Accounts Security Planning Guide.” This guide provides general best practices about securing service accounts and can be downloaded from http://technet.microsoft.com/en-us/library/cc170953.aspx.

In addition, you need to install the Microsoft .NET Framework. The installation detects if you have not done so and enables the feature for you. If you are installing VMware Update Manager and vCenter Server on the same 64-bit host, keep in mind that vCenter is a true 64-bit application and requires a 64-bit Data Source Name (DSN) file, and Update Manager is a 32-bit application that requires a 32-bit DSN. To create a 32-bit data source, you need to run the 32-bit version of the tool, which you can find at C:\Windows\SysWOW64\odbcad32.exe. To locate the 64-bit data source tool, go to the Start menu, Administrative Tools, and then click Data Sources.

Installing Microsoft SQL Server

Follow these steps to install Microsoft SQL Server:

  1. Launch the installation. Click OK to have the SQL Server 2008 R2 setup enable the Microsoft .NET Framework, as shown in Figure 3.2.

    Figure 3.2. Run the Microsoft SQL Server 2008 R2 Setup.

  2. Select New Installation or Add Features to an Existing Installation, as shown in Figure 3.3.

    Figure 3.3. Select New Installation.

  3. After the installer verifies that your server meets the requirements (see Figure 3.4), click OK.

    Figure 3.4. The Installer verifies the prerequisites.

  4. Accept the licensing terms, as shown in Figure 3.5, and click Next. Click the check box if you want to help Microsoft further develop SQL by sending usage data. In most production environments, this option is not selected.

    Figure 3.5. License terms.

  5. Select the SQL features. The only features you need are the Database Engine Services and the Management Tools, as shown in Figure 3.6. After selecting the features, click Next.

    Figure 3.6. Select Database Engine Services and Management Tools.

    It is quite common to run into a deployment in which the SQL Server instance is already up and running, but the management tool has not been installed. Because the 2008 Management Tools are no longer available as a separate download, it is possible to use SQL Express Management Studio 2005. An even better solution is to have a ThinApp version of SQL Express Management Studio 2005 as part of your toolkit.

  6. Set the SQL named instance (see Figure 3.7). Although using the default instance is fine, it is better if you provide a specific instance name and then click Next.

    Figure 3.7. Name the SQL Instance.

  7. Specify the SQL administrators (see Figure 3.8). After adding the appropriate SQL administrators, select Data Directories. Select Mixed Mode (SQL Server authentication and Windows authentication) if you intend to run all databases from one location. Although the vCenter database uses Windows authentication, the Event Database does not.

    Figure 3.8. Select Mixed Mode.

  8. Update the default locations for the databases and logs, as shown in Figure 3.9. Even if you are running the Windows Database Server as a VM, it is a good idea to separate the database and the logs on separate partitions. Separating the database and logs on separate partitions ensures that you can still manage the SQL Server in the event you run out of capacity on the volumes. If the SQL Server is virtual, you can separate different Virtual Machine Disks (VMDKs) on different storage tiers to more finely control IO.

    Figure 3.9. Separate the database logs from the OS partition.

After the SQL instance is installed, it is important to ensure your SQL databases are backed up properly. Microsoft SQL 2008 makes this process easy to configure. Of course, there are other third-party solutions that back up not only your database instances but also everything else in your environment. SQL supports a Simple or Full recovery model. A Simple recovery model does not back up the logs, so recovery is limited to the last backup. A Full recovery model includes the logs, so it allows you to recover the database to a certain point in time, assuming the log is not damaged.

For a VMware vCenter environment, you have a vCenter database, an Update Manager database (which is optional but highly recommended), and also with VMware View, a View Composer and Events database. We discuss View Composer more in Chapter 6, “View Operations and Management.” Make sure that you create the database and also provide the permissions necessary for connecting to the SQL database. The account requires db_owner permissions to the vCenter and Update Manager database for the installation. In addition, the account requires temporary db_owner permissions to the MSDB System database for both vCenter and Update Manager. The purpose is to ensure the installation can create SQL Agent jobs for the vCenter statistic rollups, for example. The vCenter statistic rollup jobs allow vCenter to purge data it is collecting to populate the performance data within vCenter. The tables used to store this data are as follows:

It is best to install vCenter and configure the VMware Update Manager before revoking the db_owner access to the System databases.

The default installation of SQL assigns a Simple recovery model. A Simple recovery model means that a point-in-time backup is the only one supported. Data added or changed between backups may be lost with a Simple recovery model. Changing the type to Full recovery allows you to restore data up to the point of recovery.

You can change the recovery model by selecting the properties of the database and, on the Options, changing the recovery model from Simple to Full, as shown in Figure 3.10.

Figure 3.10. Change the recovery model to Full.

Let’s step through the process required to create the database and assign the appropriate permissions; then we will review how to ensure the database is properly backed up. Create each database by opening the Microsoft SQL Management Studio and taking the following steps:

  1. Connect to the SQL database instance on the SQL Server.

  2. Right-click the Database Module and select a new database.

    Ensure your database names are indicative of what they will be used for—that is, vCenter, VMware Update Manager (VUM), vComposer, and vEvents.

  3. Expand the Security Module and add a new login.

The account should be the one that you created so that you can connect and perform the installation. In this case, we created a svc_SQL Account, as shown in Figure 3.11.

Figure 3.11. Choose the account that will be the db_owner.

Ensure the account is mapped to the appropriate database and has the db_owner permission. To ensure the SQL Agent jobs are created properly, db_owner permission is also required for the MSDB database. After the installation is complete, this permission should be revoked.

Figure 3.12 shows the three databases mapped to the db_owner role.

Figure 3.12. User mapping.

After you create the databases and have the appropriate permissions, you should schedule the database backups if an enterprise backup solution is not in place. Although most server virtualization environments do have enterprise backup solutions in place, due to the requirement of needing a second virtual server, this is not always the case in virtual desktop environments. It is recommended that you have a specific backup solution in place, but at a minimum, you should set up backups. In most cases, a dedicated SQL support team exists and has a defined backup process. The steps provided in this book are not meant to supersede established backup practices and policies, but instead serve as a reference in case an option is needed or if additional understanding is required on SQL backups.

When you are looking at a backup strategy for your vCenter and your virtual desktops, you should consider how valuable the data is, how much the data is changing, the overall size of the database, and how much the data is used. With vCenter, the database is a configuration database to store metadata. As your environment grows, however, the availability of the data and overall service becomes increasingly critical.

When using SQL Server 2008, you have three primary backup types: full, differential, and log backups.

Full Backup

A full backup copies all the information in the database. Full backups also include the transaction logs and any data that has not been written to the database. In a small virtualization environment, it is possible to run full backups for the vCenter database. When the environment grows beyond 20 ESXi hosts, the database can grow to 10–15 GB. In this case, a combination of full or differential backups might be necessary.

  1. Open the SQL Server Management Studio and connect to the SQL Server instance.
  2. Navigate to the Server\Databases folder.
  3. Right-click the database you want to back up.
  4. From the shortcut menu, select Tasks, Backup.
  5. In the Database Backup dialog box, select the type of backup you want the server to perform, the backup destination path, and the backup options.
  6. Click OK to back up the database or click the Script button if you want to generate a script to run the backup with the selected options.

You can also run backups from the SQL command line by performing the following:

  1. Browse to c:\Program Files\Microsoft SQL Server\100\Tools\Binn.
  2. Run SQLCMD. The 1> prompt tells you that you are connected to SQL Server instance 1.

  3. Enter the backup command, as shown in Figure 3.13.

    Figure 3.13. The BACKUP DATABASE command.

    The command to do a full backup is BACKUP DATABASE [Name of database] TO DISK = N’[PATH]’. In this example, we typed

    BACKUP DATABASE vCenter TO DISK = N'S:\Backup\vCenter_12282011.bak'

  4. To execute the command, type go and press Enter. The backup should process successfully, as indicated in Figure 3.14.

    Figure 3.14. A successful backup.

To set up reoccurring backups, you need to set up a maintenance plan under SQL and ensure that SQL Agent is started. If you are running a SQL Express Edition, you need to look at scheduling a SQLCMD command because maintenance plans are not available in the Express Edition.

After the SQL Agent starts, you can set the backups to happen according to a schedule. If you are not using a SQL Express Edition, you should see the Maintenance Plans module under Management, as shown in Figure 3.15.

Figure 3.15. Maintenance Plans module.

Create a Back Up Database task and set it up according to a reoccurring schedule, as shown in Figure 3.16.

Figure 3.16. Set a reoccurring schedule.

If you are using SQL Express, you can use the following process to automate the SQLCMD Backup command. First, you need to create a SQL script using the command you ran from the command line:

BACKUP DATABASE vCenter TO DISK = N'S:\Backup\vCenter.bak'

The file extension does not matter, but in this case save the database with a .bak extension so that it is easy to identify. Now you need to create a scheduled task to initiate the SQLCMD command and execute the SQL script. You also need to create a local ID under which the scheduled task can run with suitable privileges including the logon as batch job privilege. You can add a policy through the Active Directory (AD) by separating out your vCenter Server in a separate OU. You should do this through Active Directory policy, but you can configure this locally by doing the following:

  1. Navigate to Administrative Tools\Local Security Policy.
  2. Expand the Security Settings\Local Policies\User Rights Assignment.
  3. Add the account that will run the scheduled job to the Logon as Batch Job Properties and click OK.

When you are done, you can open the scheduler to create a basic task.

  1. Open the scheduler on the SQL Express Server and create a basic task. Provide a descriptive name such as vCenter Backup job and a description of when the job occurs, as shown in Figure 3.17. Then click Next.

    Figure 3.17. Create a Task.

  2. Configure the trigger; in this case, set up the backup job to be triggered weekly (see Figure 3.18). Then click Next.

    Figure 3.18. Configure a trigger (weekly).

  3. Set the frequency you would like the backup to occur at (see Figure 3.19) and click Next. If you would like the backup to happen every two weeks, you can adjust the Recur setting from 1 to 2.

    Figure 3.19. Determine the schedule and reoccurrence.

  4. Set it to start the SQLCMD command with arguments. To do so, select Start a Program (see Figure 3.20). Then click Next.

    Figure 3.20. Select Start a Program.

  5. Select the SQLCMD program and the argument as –i [Path to your SQL script], as shown in Figure 3.21.

Figure 3.21. Select SQLCMD as the program and your script as the arguments.

After you complete these steps, you need to adjust the properties a little for the job:

  1. Browse to the Task Scheduler Library and verify the reoccurring vCenter Database job appears in the right pane.

  2. Select the task, right-click, and select the properties of the newly created batch job, as shown in Figure 3.22.

    Figure 3.22. Right-click properties.

  3. Ensure Run Whether the User Is Logged On or Not is selected, as shown in Figure 3.23. Then select Change User or Group... and ensure the job is running under the proper credentials.

Figure 3.23. Select the user under which to run the task.

The preceding description is just a sample of how you can ensure you have regular full backups running if you have opted to run SQL Express. You might want to fine-tune your settings to keep several weeks’ worth of full backups and also to move them to a separate location.

Differential

If your database is getting too big for a full backup, you can perform a differential backup. A differential backup copies any changes made since the last full backup job. It is designed to reduce the time needed to perform a full backup. You can make your backup job a differential job by adding the WITH DIFFERENTIAL statement, as shown in Figure 3.24. In this case, your final backup strategy adds a combination of full and differential backups, so you must ensure you have access to all the backup files.

Figure 3.24. WITH DIFFERENTIAL command.

Log Backups

The third type of backup does not copy the changes; it copies only the transactional logs of the database. After the logs are copied, the portions of the log files not needed for active transactions are truncated. For regular maintenance, it is a good practice to back up your log files daily.

When you are happy with your scheduled job, you can quickly apply it to the remaining databases because the jobs are exportable to XML files from the Task Scheduler console. Simply export the job as an XML file, make some edits so that it can be applied to the other databases, and reimport it. In general, the VMware Update Manager View Composer or Event databases do not require the same frequency of backups as the vCenter database.

Installing vCenter

After checking to ensure the database is up and running and your backup rotations and recovery plans are properly configured, you are almost ready to begin the vCenter installation. Installing vCenter requires a domain account with local administrator privileges. If you are installing vCenter on a Windows 2008 R2 host, you have some decisions to make: Should you keep the firewall enabled, and what ports do you need to have open if you do? It is a best practice to keep the firewall active although it increases the complexity of the deployment. By keeping it on, however, you are dramatically reducing the attack vector or vulnerability of the service. This, of course, is both a judgment call and consideration of your internal security policy toward native Windows firewalls. In some organizations, the default is to turn off the firewalls. If you do want to keep the firewall on, you should be aware of which ports are opened during the installation of the vCenter Server. You can open these ports in advance, or during the installation, they are opened by default.

Table 3.2 provides a list of the ports.

Table 3.2. Port Descriptions

Port

Description

80

vCenter Server requires port 80 for direct HTTP connections. Port 80 redirects requests to HTTPS port 443. This redirection is useful if you accidentally use http://server instead of https://server/.

Note: Microsoft Internet Information Services (IIS) also use port 80.

389

This port must be open on the local and all remote instances of vCenter Server. This is the LDAP port number for the Directory Services for the vCenter Server group. The vCenter Server system needs to bind to port 389, even if you are not joining this vCenter Server instance to a Linked Mode group. If another service is running on this port, it might be preferable to remove that service or change its port to a different port. You can run the LDAP service on any port from 1025 through 65535.

If this instance is serving as the Microsoft Windows Active Directory, change the port number from 389 to an available port from 1025 through 65535.

443

This is the default port that the vCenter Server system uses to listen for connections from the vSphere Client. To enable the vCenter Server system to receive data from the vSphere Client, open port 443 in the firewall.

The vCenter Server system also uses port 443 to monitor data transfer from SDK clients.

If you use another port number for HTTPS, you must use ip-address:port when you log in to the vCenter Server system.

636

For vCenter Server Linked Mode, this is the SSL port of the local instance. If another service is running on this port, it might be preferable to remove that service or change its port to a different port. You can run the SSL service on any port from 1025 through 65535.

902

This is the default port that the vCenter Server system uses to send data to managed hosts. Managed hosts also send a regular heartbeat over UDP port 902 to the vCenter Server system. This port must not be blocked by firewalls between the server and the hosts or between hosts.

Port 902 must not be blocked between the vSphere Client and the hosts. The vSphere Client uses this port to display virtual machine consoles.

8080

Web Services HTTP. This port is used for the VMware VirtualCenter Management Web Services.

8443

Web Services HTTPS. This port is used for the VMware VirtualCenter Management Web Services.

60099

Web Service change service notification port.

10443

vCenter Inventory Service HTTPS.

10109

vCenter Inventory Service Service Management.

10111

vCenter Inventory Service Linked Mode Communication.3

After reviewing the port requirements, you are ready to begin installing vCenter. Ensure you have the latest version of the vCenter 5 software downloaded and follow these steps:

  1. Launch the installer. You will notice that several services and features can be installed from the Installation Utility, which we discuss later. To install vCenter, select the vCenter Server option and click Install.
  2. Select the language from the drop-down; vCenter ships with language support.
  3. When the installation wizard appears, click Next.
  4. After reviewing the end-user patent agreement, click Next.
  5. Agree to the license terms and click Next.
  6. Enter your user name, organization, and license key in the fields provided and click Next.

  7. You have the option of installing a Microsoft SQL Server 2008 Express instance or using a supporting database. Because vCenter is a true 64-bit operating system, it requires a 64-bit DSN. If you have not created one, you are prompted to do so. Click Next to start the creation of the DSN or select it from the drop-down list and proceed to step 15. Figure 3.25 assumes you need to create the DSN.

    Figure 3.25. Select the database.

  8. Provide a name for the vCenter DSN, provide a description, and then select the SQL instance you are connecting to (see Figure 3.26).

    Figure 3.26. Specify SQL Server information.

  9. Click With Integrated Windows Authentication, as shown in Figure 3.27. Integrated Windows security is more secure than SQL Server authentication, so you should use it. Click Next.

    Figure 3.27. Select With Integrated Windows Authentication.

  10. Ensure you are connecting to the vCenter Server, as shown in Figure 3.28, and click Next.

    Figure 3.28. Change the default database.

  11. Click Finish.
  12. Click Test the Data Source...

  13. When the installation completes successfully, as shown in Figure 3.29, click OK.

    Figure 3.29. Check your database connectivity.

  14. When you see your DSN in the highlighted area, as shown in Figure 3.30, select it and click Next.

    Figure 3.30. Select your DSN.

  15. Click Next.
  16. Accept the default location and click Next.

  17. You have the option of installing vCenter in linked mode so that you can view all vCenter information from a single management tool. It is common for the vCenter Server being deployed for the VDI environment to be the second vCenter Server deployed. If you install it in standalone mode and then want to update it to linked mode, you can be rerunning the installer. If this is the case, install the server in linked mode; otherwise, select Create a Standalone VMware vCenter Server Instance, as shown in Figure 3.31, and click Next.

    Figure 3.31. Select the standalone option unless this is the second vCenter Server.

  18. vCenter Server Web services is provided by Tomcat. In this screen, shown in Figure 3.32, you are asked to tune the maximum memory pools for Java based on the expected size of the environment. Although this screen was introduced in vCenter 4.1, the capability to tune Tomcat has been available for a while through the Configure Tomcat utility that is provided. Select the maximum memory configuration based on the expected size and click Next.

    Figure 3.32. Select the appropriate inventory size to configure the Tomcat memory setting.

  19. You have the option of increasing the number of ephemeral ports, as shown in Figure 3.33. An ephemeral port is a short-lived endpoint created by the Windows Server when a program makes a user port connection. Because virtual desktop environments can scale into the thousands of virtual desktop instances, it is typical that you adjust the ephemeral ports on both VMware View Servers and vCenter Servers. Click Install to begin the installation.

    Figure 3.33. Increase the ephemeral ports for large View environments (thousands of instances) if needed and install vCenter.

  20. Ensure the installation completes properly (see Figure 3.34) and click Finish.

    Figure 3.34. Finalize the installation.

When the installation is complete, you need to install the vSphere client to connect to the environment. The vSphere client is a Windows-based client that allows you to connect to vCenter and the ESXi hosts in your environment. The difference in connecting to ESXi versus vCenter is that ESXi uses the local root login credentials, whereas the vCenter Server uses Windows login credentials. To get access to the vCenter Server you just installed, complete the following steps:

  1. Launch the vCenter installer.
  2. Select the vSphere Client and click Install.
  3. Select the language for the installation and click OK.
  4. Click Next on the welcome screen.
  5. Click Next on the user patent agreement.
  6. Agree to the license terms and click Next.
  7. Click Install on the ready to install screen.
  8. Click Finish when the installation completes.
  9. Open the vSphere client in Programs\VMware\vSphere Client.
  10. Enter the name of the vCenter Server and the Windows username and password and click Login.

To summarize the process, the high-level installation steps shown in Figure 3.35 are necessary to complete the installation.

Figure 3.35. Installation steps.

Installing vSphere

Installing VMware View starts with the installation of vSphere and related components. With vSphere 5, there are two options for vSphere: installable and embedded. Installable is an installation of vSphere ESXi because vSphere 5 no longer supports ESX native or the version that had the console operating system (COS) for management purposes. You can download the ESXi binaries from VMware at https://my.vmware.com/web/vmware/try-vmware or order the server with the embedded version.

If you download the binaries, it is possible to create a manual embedded version by installing to a USB drive in an internal or external port on the server. The embedded version is supplied by the hardware vendors and incorporates their specific tools to enable greater visibility on the hardware and software layer. For example, you can download an ESXi version from HP, Dell, IBM, and CISCO. One of the drawbacks of the embedded option is that the build from the vendor may not have the latest and greatest utilities or tools. With vSphere 5, this issue is addressed by providing an automated build option that allows you to add OEM packs to the installation. Let’s review the installation:

To install ESXi installable, follow these steps:

  1. Boot from the ISO file. After it boots, the splash screen comes up, and the necessary files to start the installer are loaded, as shown in Figure 3.36.

    Figure 3.36. ESXi splash screen.

  2. You can maneuver around the installer by using the Tab key. To continue the installation, press the Tab key and press Enter on the keyboard, as shown in Figure 3.37.

    Figure 3.37. Select Enter to continue.

  3. Press F11 to accept the license agreement shown in Figure 3.38 and continue.

    Figure 3.38. Press F11 to accept the license agreement.

  4. Select a disk to install or upgrade, as shown in Figure 3.39. It is considered a best practice to install vSphere ESXi first before presenting storage so that you can be assured that you are installing ESXi on the right drive unless you intend to boot from SAN. Once you have selected the drive press Enter.

    Figure 3.39. Select the storage device where you would like to install ESXi.

  5. Select the correct keyboard layout (US Default), as shown in Figure 3.40, and press Enter to continue.

    Figure 3.40. Select the keyboard layout.

  6. Specify a password for the root account, as shown in Figure 3.41, and press Enter.

    Figure 3.41. Specify the password.

  7. Confirm the parameters, as shown in Figure 3.42, and press F11 to begin the installation.

    Figure 3.42. Press F11 to install.

If you are installing ESXi to a USB stick, you need to verify that your server is on the supported Hardware Compatibility List (HCL) and that the USB device is supported by the server vendor. If both conditions are met, the USB device shows up as an installable location. Rather than select a local drive, you can select the USB location to install ESXi. For detailed instructions, refer to VMware’s Knowledge Base article located at http://kb.vmware.com/selfservice/documentLinkInt.do?micrositeID=&popup=true&languageId=&externalID=2004784.

Auto Deploy

One of the other options you have is to use the new Auto Deploy feature, which essentially allows you to provision a vSphere 5 ESXi Server and apply the configurations in an unattended manner through the Configuration Manager to create a truly stateless host. Why would you use Auto Deploy in a VDI environment? VDI is a technology that scales quite quickly. To reduce the time it takes to provision additional capacity, Auto Deploy may be a good option. In addition, it allows you to design the ESXi configuration once and have it consistently applied across the board. It does require extra consideration if you are going to run vCenter in a virtual machine, however.

When you use Auto Deploy, you are creating a major dependency on the service for all hosts that are set up to use it. You therefore need to run two ESXi hosts that are not dependent on Auto Deploy in a cluster. A separate cluster ensures that your vCenter and Auto Deploy Server can reside on a set of hosts that are running vSphere HA with the boot priority properly set on the VMs so that the service is readily available all the time. Before we get too far ahead ourselves, though, let’s look at the requirements and process.

To deploy the Auto Deploy feature, you need a few additional components:

Using the vCenter that you have installed and running, you can add these additional components to take advantage of rapid provisioning of stateless ESXi hosts in the VDI environment.

The architecture of Auto Deploy is made up of the following components, also shown in Figure 3.43:

Figure 3.43. Auto Deploy components.

Let’s enable and step through each of the components.

PowerShell is included in Windows 2008 R2, but you do have to add it as a feature. PowerShell should be installed on the vCenter Server along with the VMware PowerCLI. To install PowerShell, follow these steps:

  1. To add PowerShell, open Server Manager.
  2. Browse to the Add Features module and right-click Add Feature.
  3. Select the Windows PowerShell Integrated Scripting Environment.
  4. Click Install.
  5. Open a PowerShell script window, browsing to Start\Programs\Administrative tools and opening a Windows PowerShell Module.
  6. Enable the PowerCLI by changing the remote execution policy for scripts by typing Set-ExecutionPolicy RemoteSigned. This allows scripts that are not signed by a vendor to run on the vCenter Server.

You can download the VMware PowerCLI directly from VMware. After downloading it, simply follow these steps to install it properly:

  1. Run the VMware Power CLI executable.
  2. Click Next on the Installer screen.
  3. Click Next on the Patent information screen.
  4. Accept the license agreement and click Next.
  5. Accept the default location and click Next.
  6. Click Install.
  7. Click Finish.

NOTE

You may be prompted to install the VMware VIX files; VMware VIX is an API that allows you to automate VM and guest operations. You should install VIX when prompted.

To get the boot loader files, you need to install the plug-in in vCenter for Auto Deploy. You can install the plug-in using the VMware vCenter Installer:

  1. Click the VMware Auto Deploy, as shown in Figure 3.44, and click Install.

    Figure 3.44. Select VMware Auto Deploy.

  2. Choose the setup Language and click OK.
  3. Click Next on the Auto Deploy Installation Wizard.
  4. Click Next on the patent information screen.
  5. Accept the license agreement and click Next.
  6. Accept the default location and set the Auto Deploy Repository location and size. The default repository size is 5 GB. Because Auto Deploy is being used to provide ESXi images, the default size is sufficient.

  7. Enter the IP address or hostname of the server, leave the default HTTP port, and enter the username and password. Then click Next.

    NOTE

    For network-based services, I prefer to go with IP addresses so that name resolution is not a requirement for the service. If you are likely to change IP addresses, it is best to put in a hostname.

  8. The default Auto Deploy Server Port is 6501. Leave this setting and click Next.

  9. Specify how vSphere Auto Deploy should be identified on the network and click Next.

    My recommendation is to use the IP address so that name resolution is not required for the deployment server to run.

  10. Click Install.
  11. Click Finish.

When you reconnect to vCenter, you see a new administration plug-in called Auto Deploy. Launch the Auto Deploy plug-in, which should look similar to the one in Figure 3.45.

Figure 3.45. Auto Deploy appears under Administration.

The plug-in displays the boot loader filename, which in this case is undionly.kpxe.vmw-hardwired. The boot loader files can be downloaded from here, as shown in Figure 3.46.

Figure 3.46. Download bootloader files.

Now that you have the name of the boot loader file and the zip files containing those files, you can set the attributes for your DHCP scope and unzip the files on your TFTP Server. The files are downloaded as deploy-tftp.zip. When you unzip them, by default, they are placed in a subdirectory of your root folder (deploy-tftp) on your TFTP Server. To ensure you can find the files, unzip them in the root directory of your TFTP Server without the default subdirectory.

It is recommended that you restrict your Auto Deploy process to a service network. This means that your builds should happen on an isolated network segment separate from your production network. By doing so, you ensure that even though the building of an ESXi host involves a very small image file, the downloading and installing do not interfere with production traffic. In addition, DHCP is required for this process to work. From a security perspective, DHCP traffic should not be run on the same network as your ESXi management traffic. If you do not have the flexibility of separating your management and Auto Deploy service network, use nonroutable IP addresses to build the hosts and then apply production IPs afterward. A separate Auto Deploy network may require a dedicated port group on your vSphere ESXi vSwitches, so make sure that you build this into your planning.

When the boot loader files are in place, update options 66 and 67. In a Windows-based DHCP Server, follow these steps:

  1. From the DHCP Management Utility, browse to the scope that you will be using to enable the Auto Deploy process.
  2. Expand the scope and select Options. Then right-click and select Configure Options.
  3. Under Available Options on the General tab, select 066 and add the IP address of your TFTP host under the string value.
  4. Select 067, and under the string value, add the name of the boot loader file, which in this case, is undionly.kpxe.vmw-hardwired.
  5. Click OK.

At this point, you should have the boot loader process running. If you boot a physical server, it gets a DHCP address, contacts the TFTP Server, and downloads the boot loader file. It connects to the Auto Deploy service on the vCenter Server and halts because no rules have been configured to tell the server which image profile is assigned to the host. After downloading the boot loader file, the server contacts the vCenter Server but stops because the image profile has not been assigned to the host yet, as shown in Figure 3.47.

Figure 3.47. The server contacts vCenter.

To complete the Auto Deploy configuration, you must run some PowerCLI scripts from the vCenter Server to specify a software depo. Extract the ESXi downloadable images into the software depo and create a rule to associate the image with an image profile. The final step is to make this the default image profile.

Log in to your vCenter Server and start the PowerCLI interface. If you get an error message, it is likely that you have not set the execution policy properly in PowerShell. In this instance, run PowerShell and set the execution policy, as shown in Figure 3.48:

"Set-ExecutionPolicy RemoteSigned"

Figure 3.48. Set the execution policy to unsigned.

This command allows code that has not been signed by a trusted publisher such as Microsoft to run.

Run vSphere PowerCLI and connect to your vCenter Server by typing Connect-VIServer [servername], which results in the output shown in Figure 3.49.

Figure 3.49. Connect to your vCenter Server.

After you are connected, you need to create a software or repository. You do this by running the Add-EsxSoftwareDepot command along with the path to your ESXi downloadable files. For example:

Add-EsxSoftwareDepot S:\Depo\VMware-ESXi-5.0.0-469512-depot.zip

After creating the software depo, you should verify it is set up properly by running the Get-EsxImageProfile command. The command should return information on the image profiles available in the software depository, like those shown in Figure 3.50.

Figure 3.50. Image profiles.

Although the initial images are fine for a proof of concept, you need the vSphere HA modules for production deployment. These modules are part of the Auto Deploy software depot and can be added by running Add-EsxSoftwareDepot http://vCenterServer/vSphere-HA-depot. The output is shown in Figure 3.51.

Figure 3.51. Add the software depository URL.

To add the HA options, add the HA software depot on the vCenter Server, as shown in Figure 3.52.

Figure 3.52. Add HA to your ESXi image.

After adding the HA files, you need to create a copy of the existing images so that you can add the new files to it. To take one of the existing images and clone it, run the following command:

PowerCLI> New-EsxImageProfile -CloneProfile ESXi-5.0.0-469512-standard -Name "ESXi-5.0.0-469512-HA"

In this example, you are taking the ESXi-5.0.0-469512-standard image and copying it to one called ESXi-5.0.0-469512-HA, shown in Figure 3.53 (Note that the HA components were not included in the original ESX software depo zip files, but now they are).

Figure 3.53. Make a copy of the original image.

If you rerun the Get-EsxImageProfile command, you see an additional image profile. You still need to add the vmware-fdm or HA package to the image. You do this by running the following command:

PowerCLI> Add-EsxSoftwarePackage -ImageProfile "ESXi-5.0.0-469512-HA"
-SoftwarePackage vmware-fdm

After verifying that the software depository is working and that you have images available, you can create a deployment rule. The syntax for creating a deployment rule is

New-Deployment—Name "Name of Rule"—Item "Image Name"

You have the option of pattern matching or making this image file available as the default by adding switches. The –Allhosts switch applies the rule to any server, and the –pattern switch allows you to specify specific attributes to match, such as vendor=VMware, Inc. You can concatenate multiple patterns by separating each with a comma. Perhaps the most useful of the patterns is specifying an IP range. If you have separated your build network and use a set range of IP addresses, you can restrict the build process to that range.

The syntax used in this example is as follows (see Figure 3.54):

PowerCLI> New-DeployRule -Name "ESXi Default Build v.01" -Item "ESXi-5.0.0-
469512-HA" -Pattern "ipv4=192.169.9.0-192.169.9.255"

Figure 3.54. Associate the image to an IP pattern.

After creating the build rule, you must activate it. The command to activate it is Add-DeployRule –DeployRule “Name”, as in this example:

Add-DeployRule –DeployRule "ESXi Default Build v.01"

One point to keep in mind with Auto Deploy is that the deployment can generate a significant load on the Auto Deploy service. Because the location of the image file is essentially a web server, it is possible to use reverse proxies to offload some of the overhead. A reverse proxy can also store the image file. It is possible to redistribute the load to the reverse proxy by editing one of the boot loader files. If you go into the TFTP root directory and edit a file called tramp, you can specify alternate locations. If you open the tramp file, you can easily specify alternate locations, as shown in Figure 3.55.

Figure 3.55. Edit the tramp file.

Host Profiles

After you set up Auto Deploy, essentially you have ESXi Servers that are running, but they do not yet have a production configuration applied to them. The other component to vCenter that you need to integrate is host profiles.

Host profiles allow you to create a set of configurations that can be consistently applied across the environment. They eliminate the manual configuration of ESXi hosts on an individual basis. Host profiles also allow you to force compliancy across your environment because after a host profile is associated, any changes made are identified and remediated. Because Auto Deploy essentially creates an installed ESXi, you need to use host profiles to apply a consistent production configuration. There are two ways to configure a host profile: You can import an existing profile through the vCenter console or create one from an existing ESXi host. Unless you have a company standard (and this should be adjusted for a VMware View environment), the easiest way is to just configure an ESXi host as you would like and create one from the host. A host profile assumes that the EXi hosts are configured the same way, so it is important to have everything configured properly on your reference ESXi Server.

Using host profiles is a four-step process:

  1. Create a reference profile from an ESXi host.
  2. Attach the profile to an existing host or cluster.
  3. Run a comparison against the hosts assigned to the profile and the profile itself.
  4. Apply the profile to fix any differences between the assigned hosts and the profile.

The actual process is as follows:

  1. From vCenter, navigate to Home, Management and Host Profiles.

  2. Click the Create Profile button and provide a name and description for the profile, as shown in Figure 3.56. Then click Next.

    Figure 3.56. Create a host profile.

  3. You can edit the profile to make any additional changes. Simply open the profile and expand the profile policies to update the settings, as shown in Figure 3.57.

    Figure 3.57. Expand the profile policies to edit settings.

  4. You can select to attach the profile to an ESXi host or cluster.
  5. After attaching the profile, click Check Compliance.
  6. If anything is noncompliant, click Apply Profile to have the changes made.

At this point, you have deployed vCenter and have the ESXi hosts coming online. Now make sure that the reference server is properly configured before you build your host profile. For an ESXi Server, you should ensure that the storage is properly attached and that key features such as VMotion and DRS are set up and working. Let’s review each of the technologies and the configuration so that the reference server is representative of what you want in production.

VMotion allows the virtual machine to be hot migrated from one ESXi host to another. To set up VMotion properly, you must make sure that any ESXi host you are migrating to and from has access to the same storage. ESXi supports just about every type of shared storage configuration out there, whether it is Fiber Channel (FC), iSCSI, or NFS.

VMware View environments are unique in that you have two kinds of I/O to contend with: operational I/O and burst I/O. Operational I/O is essentially the storage throughput requirement while the virtual desktop is on, whereas burst I/O, or “boot storms,” is typically experienced when multiple virtual machines are being created. We look at the design principles in Chapter 12, “Performance and Monitoring,” when we review performance, but for now let’s talk mechanics. Rather than go into every aspect regarding storage considerations and configurations, let’s stick to a few important considerations in setting up storage.

No matter which storage solution you select for your VMware View installation, you should understand and have calculated your throughput requirement. In addition, your storage connections from the ESXi host to the storage solution should use multipathing. Multipathing allows you to segregate the storage paths on isolated networks and ensure there are redundant paths to the same storage pool.

Storage Connectivity

vSphere 5 has simplified the setting up of multipathing using the iSCSI software initiator. In vSphere 5, a new graphical interface allows you to set up multipathing. You therefore can set up multiple VMkernel ports quickly and easily. You can now bind multiple VMkernel ports to the iSCSI software initiator. After you do so, however, the iSCSI traffic must be restricted to layer 2 traffic or nonroutable. If you use a single VMkernel port, you can route iSCSI traffic. In addition, if you have both VMkernel ports on the same vSwitch with two uplinks, one must be active and the other passive. Let’s look at the configuration to understand how this works.

If you want two active paths to your iSCSI storage device, you need to create two separate vSwitches with two separate VMkernel ports with one active uplink each. This configuration has a separate management network and two separate paths to the iSCSI appliance, as you can see in Figure 3.58.

Figure 3.58. Two separate paths to the iSCSI appliance.

When you have the networking configuration in place, you can bind the second VMkernel port to the software initiator using the following process:

  1. Log in to the vCenter.
  2. Select the Configuration tab from the ESXi host.
  3. Select Storage Adapters and the properties of the software iSCSI initiator.
  4. Under the Network Configuration tab, add the second VMkernel port.

After the second VMkernel port is added, check the paths to ensure you have the appropriate number of paths, as shown in Figure 3.59:

Figure 3.59. Check to ensure you have multiple paths.

Installing VMware View

If you are running VMware View as a virtual machine on Windows 2008 R2, much of the performance tuning is complete. You should, however, make the following changes to your VM.

Manually set the pagefile for the system based on 1.5 times the memory assigned to the VM. You can complete this process using the following steps:

  1. Open Server Manager on the VM.
  2. Select Change System Properties.
  3. Select the Advanced tab and settings.
  4. Select the Advanced tab, and under Virtual Memory, select Change.
  5. Select Custom Size and set the minimum and maximum value to 1.5 times the memory allocated.
  6. Click Set and click OK and OK again.
  7. When prompted, reboot the VM.

The first server you should install is a standard Connection Server. As mentioned, there are actually four kinds of Connection Servers you can install: View Standard (or the first Connection Server in the environment), View Replica (or all servers after the initial Connection Server is installed), Security Server, and Transfer Server for local mode VMs.

To install the first Connection Server, follow these steps:

  1. Launch the VMware View Installer and click Next on the welcome screen.
  2. Click Next on the end user patent agreement.
  3. Accept the license agreement and click Next.
  4. Accept the default location and click Next.

  5. Because this is the first server, select View Standard Server, as shown in Figure 3.60, and click Next.

    Figure 3.60. Choose View Standard Server.

  6. Have the installer automatically configure the Windows Firewall and click Next. Note: The installer does not check the firewall state during the installation; it simply prompts you to configure it automatically or not to (see Figure 3.61).

    Figure 3.61. Adjust the Windows Firewall.

  7. Click Install, as shown in Figure 3.62.

    Figure 3.62. Click Install.

  8. Click Finish, as shown in Figure 3.63.

    Figure 3.63. Click Finish.

The installer installs eight services on the Windows Server:

After VMware View is installed, you can connect to it by launching the shortcut on the desktop or by opening a web browser and going to http://[Connection Server]/admin. Be aware that the admin is case sensitive, and the IP address can be used in place of the server name, which is not case sensitive. If you omit the /admin, you are redirected to the client installation page. When you connect to the console for the first time, you are prompted to install Adobe Flash Player. The Administrator Console requires Adobe Flash version 10 or higher. After you have logged in, you will need to configure the environment so that everything is running properly.

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:

  1. Click Next on the installation wizard screen.
  2. Click Next on the end user patent agreement.
  3. Accept the license agreement and click Next.
  4. Accept the default path for the installation and click Next.

  5. 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.

  6. Accept the default port and have the installer create an SSL certificate, as shown in Figure 3.68.

    Figure 3.68. SOAP port.

  7. 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.

Warning

Although Transfer Servers have to be virtual machines, you cannot use the LSI SAS adapter, which is the default for Windows Server 2008 R2, because it is unsupported.

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

  1. Launch the Connection Server Installer and click Next.
  2. Click Next on the patent agreement screen.
  3. Accept the license agreement and click Next.
  4. Accept the default location and click Next.
  5. Select View Transfer Server and click Next.
  6. On the Transfer Server Configuration screen, provide the name of the domain, server, and email address of the administrator.
  7. If the firewall is enabled, select Configure Firewall Automatically; otherwise, skip this step.
  8. 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:

  1. Log in to the View Connection Server using the View Administrator Console.
  2. Under View Configuration, select Server and select Add Transfer Server.
  3. Ensure your vCenter Server is listed as the source for the Transfer Server and click Next.
  4. The utility queries the inventory of VMs, or you can manually enter the name.
  5. 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:

  1. Log in to the View Connection Server using the View Administrator Console.
  2. 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:

  1. Log in to the View Connection Server using the View Administrator Console.
  2. Under Transfer Server Repository and under Content, select Publish.
  3. 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:

  1. Open SQL Management Studio and connect to your database instance.
  2. Open the Security and then the Logins modules.
  3. Right-click Login and select New Login.
  4. Under the General Settings, ensure SQL Server authentication.
  5. 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.
  6. Retype the password to confirm it.

  7. Because this is a service account, deselect the following:

    • Enforce Password Policy
    • Enforce Password Expiration
    • User Must Change Password at the Next Login
  8. Under the default database, select your Event Database, such as vEvents.
  9. Select the User Mapping page.
  10. 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.

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.

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:

  1. Open your Group Policy Management Console.
  2. Right-click your View Desktop OU and create or link a GPO policy.
  3. Enter a name such as View Persona Management Policy.
  4. Right-click the new policy and select Edit.
  5. Browse to Administrative Templates and select Add/Remove Templates.
  6. Click Add again, browse to the location on the View Server, and select the ViewPM.adm template.
  7. Expand Administrative Templates and VMware View Agent Configuration and Persona Management.

To import these policies into the local user policy, follow these steps:

  1. Open Local Security Policy.
  2. Right-click Administrative Templates and click Add\Remove Templates.
  3. Click Add again, browse to the location on the View Server, and select the ViewPM.adm template.
  4. 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:

  1. PCoIP traffic between the View Client and Security Server (External)

    1. TCP 443 for the website
    2. TCP 4172 from Client to Security Server
    3. 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.

  2. PCoIP traffic between the View Security Server and Virtual Desktop (Internal)

    1. TCP 4172 from Security Server to virtual desktop
    2. 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:

  1. Launch the Connection Server Installer and click Next.
  2. Click Next on the patent agreement screen.
  3. Accept the license agreement and click Next.
  4. Accept the default location and click Next.
  5. Select View Security Server and click Next.
  6. Provide the IP or hostname of the Connection Server to which this Security Server will be associated and click Next.
  7. Provide the pairing password you configured in the View Server and click Next.
  8. 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.
  9. 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.
  10. 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.

Summary

It is important to ensure each component of the VMware View environment is functioning properly. Check the Event Viewer on the Windows Server for error messages related to the installation. In addition, make sure that the services start properly.

At this point, you have all the major infrastructure pieces of the VMware View environment up and running. You need to create virtual machines and tune them for optimal performance. Before you do, though, you should look at one other important piece of the VMware View platform: application virtualization. When you understand the benefit of application virtualization, you can integrate it into your View desktops. We discuss application virtualization next in Chapter 4, “Application Virtualization,” and then put all the pieces together in Chapter 5, “Building Your Virtual Desktop.”

© 2024 Pearson Education, Pearson IT Certification. All rights reserved.

800 East 96th Street, Indianapolis, Indiana 46240

sale-70-410-exam    | Exam-200-125-pdf    | we-sale-70-410-exam    | hot-sale-70-410-exam    | Latest-exam-700-603-Dumps    | Dumps-98-363-exams-date    | Certs-200-125-date    | Dumps-300-075-exams-date    | hot-sale-book-C8010-726-book    | Hot-Sale-200-310-Exam    | Exam-Description-200-310-dumps?    | hot-sale-book-200-125-book    | Latest-Updated-300-209-Exam    | Dumps-210-260-exams-date    | Download-200-125-Exam-PDF    | Exam-Description-300-101-dumps    | Certs-300-101-date    | Hot-Sale-300-075-Exam    | Latest-exam-200-125-Dumps    | Exam-Description-200-125-dumps    | Latest-Updated-300-075-Exam    | hot-sale-book-210-260-book    | Dumps-200-901-exams-date    | Certs-200-901-date    | Latest-exam-1Z0-062-Dumps    | Hot-Sale-1Z0-062-Exam    | Certs-CSSLP-date    | 100%-Pass-70-383-Exams    | Latest-JN0-360-real-exam-questions    | 100%-Pass-4A0-100-Real-Exam-Questions    | Dumps-300-135-exams-date    | Passed-200-105-Tech-Exams    | Latest-Updated-200-310-Exam    | Download-300-070-Exam-PDF    | Hot-Sale-JN0-360-Exam    | 100%-Pass-JN0-360-Exams    | 100%-Pass-JN0-360-Real-Exam-Questions    | Dumps-JN0-360-exams-date    | Exam-Description-1Z0-876-dumps    | Latest-exam-1Z0-876-Dumps    | Dumps-HPE0-Y53-exams-date    | 2017-Latest-HPE0-Y53-Exam    | 100%-Pass-HPE0-Y53-Real-Exam-Questions    | Pass-4A0-100-Exam    | Latest-4A0-100-Questions    | Dumps-98-365-exams-date    | 2017-Latest-98-365-Exam    | 100%-Pass-VCS-254-Exams    | 2017-Latest-VCS-273-Exam    | Dumps-200-355-exams-date    | 2017-Latest-300-320-Exam    | Pass-300-101-Exam    | 100%-Pass-300-115-Exams    |
http://www.portvapes.co.uk/    | http://www.portvapes.co.uk/    |