Table of Contents HOL-1751-MBL-6

Transcription

1 Table of Contents Lab Overview - - Horizon 7: Advanced Concepts... 2 Lab Guidance... 3 Module 1 - Securing Horizon 7 with NSX (30 minutes)... 8 Introduction to NSX Distributed Firewall... 9 Working with Security Groups and and Security Policies for Horizon Conclusion Module 2 - Cloud Pod Architecture (30 minutes) Introduction to Cloud Pod Architecture Configuring Cloud Pod Architecture Configure Global Entitlements Conclusion Module 3 - Presenting a Linux Hosted Desktop with Horizon 7 (15 minutes)...47 Introduction to Linux Desktop Linux Desktop Deployment Linux Desktop and 3D with vdga Conclusion Page 1

2 Lab Overview - - Horizon 7: Advanced Concepts Page 2

3 Lab Guidance Note: It will take minutes to complete this lab. The modules are independent of each other so you can start at the beginning of any module and proceed from there. You can use the Table of Contents to access any module of your choosing. The Table of Contents can be accessed in the upper right-hand corner of the Lab Manual. Lab Module List: Module 1 - Securing Horizon 7 with NSX(30 minutes) - Use the NSX distributed firewall to secure communication between Horizon 7 data center components. Module 2 - Cloud Pod Architecture (30 minutes) - Walk through implementing Cloud Pod Architecture and global entitlements in multi-site Horizon 7 environment. Module 3 - Presenting a Linux Hosted desktop with Horizon 7 (15 minutes) - Overview of requirements for implementing Linux VDI in Horizon 7. Lab Captains: Ryan Costello - Staff Systems Engineer, NSX This lab manual can be downloaded from the Hands-on Labs Document site found here: This lab may be available in other languages. To set your language preference and have a localized manual deployed with your lab, you may utilize this document to help guide you through the process: Location of the Main Console 1. The area in the RED box contains the Main Console. The Lab Manual is on the tab to the Right of the Main Console. 2. A particular lab may have additional consoles found on separate tabs in the upper left. You will be directed to open another specific console if needed. 3. Your lab starts with 90 minutes on the timer. The lab can not be saved. All your work must be done during the lab session. But you can click the EXTEND to increase your time. If you are at a VMware event, you can extend your lab time twice, for up to 30 minutes. Each click gives you an additional 15 minutes. Page 3

4 Outside of VMware events, you can extend your lab time up to 9 hours and 30 minutes. Each click gives you an additional hour. Alternate Methods of Keyboard Data Entry During this module, you will input text into the Main Console. Besides directly typing it in, there are two very helpful methods of entering data which make it easier to enter complex data. Page 4

5 Click and Drag Lab Manual Content Into Console Active Window You can also click and drag text and Command Line Interface (CLI) commands directly from the Lab Manual into the active window in the Main Console. Accessing the Online International Keyboard You can also use the Online International Keyboard found in the Main Console. 1. Click on the Keyboard Icon found on the Windows Quick Launch Task Bar. Page 5

6 Click once in active console window In this example, you will use the Online Keyboard to enter the sign used in addresses. The sign is Shift-2 on US keyboard layouts. 1. Click once in the active console window. 2. Click on the Shift key. Click on key 1. Click on the "@" key. Notice sign entered in the active console window. Activation Prompt or Watermark When you first start your lab, you may notice a watermark on the desktop indicating that Windows is not activated. Page 6

7 One of the major benefits of virtualization is that virtual machines can be moved and run on any platform. The Hands-on Labs utilizes this benefit and we are able to run the labs out of multiple datacenters. However, these datacenters may not have identical processors, which triggers a Microsoft activation check through the Internet. Rest assured, VMware and the Hands-on Labs are in full compliance with Microsoft licensing requirements. The lab that you are using is a self-contained pod and does not have full access to the Internet, which is required for Windows to verify the activation. Without full access to the Internet, this automated process fails and you see this watermark. This cosmetic issue has no effect on your lab. Look at the lower right portion of the screen Please check to see that your lab is finished all the startup routines and is ready for you to start. If you see anything other than "Ready", please wait a few minutes. If after 5 minutes your lab has not changed to "Ready", please ask for assistance. Page 7

8 Module 1 - Securing Horizon 7 with NSX (30 minutes) Page 8

9 Introduction to NSX Distributed Firewall This lesson begins with an introduction to NSX distributed firewall, and then moves on to configuring security groups and security policies relevant to a Horizon 7 environment. All of the components required to test various firewall configurations, including identity firewall, are included in this lab. Traditional Security for Client Computing Traditional security for client computing is primarily focused on data at rest, meaning that if an end user's device is lost or stolen the contents of the hard drive are the main concern. Threat patterns in this type of environment are typically "north/south" since an attacker would still need to bypass a perimeter firewall to access systems and data inside the data center. Page 9

10 Security in VDI VDI addresses these security concerns by removing data from the endpoint. All data stays in the data center behind perimeter firewalls. Page 10

11 East-West Traffic Considerations For all the advantages VDI provides by removing locally stored data from devices, it does create some new security considerations inside the data center. It's very common for organizations to have strong security on the perimeter, and not much, if any, on east/west traffic inside the data center. Page 11

12 Firewall Considerations A full Horizon stack can include many components, each with different firewall port requirements. This can present a challenge to organizations trying to secure communication between Horizon components in the data center. NSX allows organizations to greatly simply securing the environment using dynamic groups. In the following lab exercise we will use tags and Security Groups to simply and effectively secure communication between all Horizon components. Page 12

13 Working with Security Groups and and Security Policies for Horizon 7 Tags and Security Groups provide a very simple yet effective method of creating dynamic security policies. This exercise will focus on using tags, but the NSX distributed firewall can use other vsphere constructs, such as cluster, host, VM name, computer name and many more. Ensure you are logged into the Main Console desktop Access the vsphere Web Client Open Chrome to access the vsphere Web Client Log In to vsphere Web Client Select Use Windows session authentication and click Login. Page 13

14 Access Networking and Security in the vsphere Client Page 14

15 Examine Horizon Firewall Rules For this environment I have used the Horizon Service Installer for NSX fling to pre-create the firewall rules we'll use for the Horizon environment. This tool is very useful for creating all of the Security Groups we'll use later in the lab. 1. Click Firewall 2. Expand the Horizon View Section Edit the Service Hover over the service area of the Connection Server rule and click the Edit icon that appears. Page 15

16 Search for Horizon in the list of services You can see all of the services that have been automatically created by the service installer. Let's take a closer look at HorizonView7-CS_inbound_client_1. Page 16

17 Examine the service This specific service includes the necessary ports for inbound communication between a client and a connection server. In a traditional firewall an administrator would need to create all of these rules. Click cancel after examining some of the various Horizon services. Page 17

18 View Groups in Service Composer Notice all of the groups for each Horizon component have zero members. We will use tags and security policies to populate these groups with Horizon servers in our environment. Navigate Home Page 18

19 Navigate to VMs and Templates Navigate Home to access the VMs and Templates inventory. Page 19

20 Create Connection Server Tag 1. Highlight the h7cs-01a VM, which is one of our connection servers. 2. Under the Security Tags section click Manage. For this example the tag has already been created, but we'll walk through the process to show you how simple it is to create a new tag. Page 20

21 Add new tag Click the green plus sign to add a new tag. Page 21

22 Create Horizon-CS tag This is where we create a name and description for the tag. Click cancel since the tag we'll be using already exists. Page 22

23 Assign Tag Ensure the Horizon-CS tag is assigned. Page 23

24 Navigate back to Service Composer Navigate back to Networking and Security. 1. Click Service Composer 2. Highlight the View Connection Server security group, and click the Edit button. Define Dynamic Membership Click the green plus sign to define a new dynamic membership for the group. Page 24

25 Add membership criteria Define membership Select Security Tag from the drop-down menu as the membership criteria, and type Horizon-CS for the tag name. When we finish, this will automatically include any VM with the Horizon-CS tag in the Horizon Connection Server security group. Page 25

26 Verify VM added to Security Group Notice that our Connection server VM is now included in the security group. Using this method makes securing the Horizon environment very simple. What would have been a very long list of firewall rules has been implemented very quickly using a single dynamic rule. Page 26

27 Conclusion This concludes the high level overview of securing Horizon with NSX. For a deeper dive into Horizon 7 or NSX concepts, check the HOL catalog. You've finished Module 1 Congratulations on completing Module 1. Proceed to any module below which interests you most. Module 2 - Cloud Pod Architecture(30 minutes) - Walk through implementing Cloud Pod Architecture and global entitlements in multi-site Horizon 7 environment. Module 3 - Presenting a Linux Hosted desktop with Horizon 7 (15 minutes) - Overview of requirements for implementing Linux VDI in Horizon 7. How to End Lab To end your lab click on the END button. Page 27

28 Module 2 - Cloud Pod Architecture (30 minutes) Page 28

29 Introduction to Cloud Pod Architecture 1. Cloud Pod Architecture and Multi-Data-Center View in Horizon 7 One of the key features of the Horizon Cloud Pod Architecture is the high availability and scale-out of virtual desktops in VMware Horizon 7. Many of you may have heard about this feature referred to as Linked-Mode View or Multi-Data-Center View or Federated View Pods. All of these mean the same thing. Today, virtual desktops provided by Horizon can be deployed using a block and pod architecture, or design. (Refer to sections titled View Building Blocks and View Pods in the View Architecture Planning Guide.) A single View pod can contain up to five View blocks, can scale up to 10,000 (10K) desktops, and can be deployed in a single data center. Customers looking to scale beyond 10K desktops can deploy multiple View pods. However, each View pod is an independent entity that has its own user entitlements and is managed separately. With the new Horizon 7 Cloud Pod Architecture, customers can aggregate multiple View pods in either the same data center or different data centers and entitle users to a desktop in any location. Now, let s look at an example that describes this feature in its entirety. Figure 1 below shows two View pods Pod 1 and Pod 2. Pod 1 is located in a data center in the United States, and Pod 2 is located in a data center in India. Each pod has two connection brokers VCS1 and VCS2 in Pod 1, VCS3 and VCS4 in Pod 2. Both Pod 1 and Pod 2 maintain their own user entitlements, which provide a mapping of an end user to a virtual desktop in the respective pod. The new architecture in Horizon 6 introduces two new elements: A global entitlement layer which spans multiple pods (shown as a single layer spanning Pod 1 and Pod 2 in the diagram) An inter-pod communication layer (shown with a bi-directional arrow between Pod 1 and Pod 2 in the diagram) This new architecture provides three major benefits: Support for active-active deployments Customers who have multiple data centers can now leverage all the data-center assets efficiently. They can entitle users to desktops either in one or in multiple data centers. Consolidation of multiple pods within a single data center Multiple pods of desktops within the same data center can be consolidated and managed centrally through a single global user-entitlement layer. Disaster recovery The global user-entitlement layer can be used to assign a user to desktops in both Pod 1 and Pod 2. If Pod 1 were to become unavailable either due to a data-center failure or to another form of failure, the user could always get to a desktop in Pod 2. It is important to note that this feature assumes Page 29

30 that the desktops in Pod 1 and Pod 2 are replicated using some form of datareplication technology. 2. Brokering a Desktop in a Cloud Pod Architecture The previous example conceptually illustrates how two View pods can be used to entitle users to desktops in different data centers. Brokering a desktop to a user who logs in from any location follows the simple workflow below: 1. The end user enters the URL or IP address for their View environment, which can be an address of a View Connection Server (broker) or a load balancer, and enters their credentials. 2. The broker looks up both local and global entitlements for the user. 3. The broker gets the current desktop state via inter-pod protocol and returns a list of desktops to the client. 4. The user selects a desktop. 5. If the desktop is remote, the broker launches the remote desktop via inter-pod protocol. 6. The client connects to the remote desktop directly or via a local tunnel. The top use cases for end-user desktop access are as follows: Page 30

31 Global roaming desktop This is a use case where the end user needs access to a desktop only to access their Windows-based applications. An end user can be located either in India or the U.S. with an entitlement to a nonpersistent desktop pool. The end user gets a desktop in their connected pod (that is, close to their client location If they connect from India, they get a desktop in India). Global home desktop This is the typical case where the end user wants to get the same persistent desktop every time they request access, irrespective of their location. To accomplish this, persistent desktop pools in all pods need to be set up. The FromHome policy can be used to direct the user back to their home site. The end user gets the same desktop machine irrespective of which pod they are connected to. Local scale desktop In this use case, each site has multiple pods, each offering a standard nonpersistent desktop pool. A global entitlement layer provided by Cloud Pod Architecture joins all these pools together. Using the site s Scope policy, one can control and limit access to a desktop that is available within the site. Page 31

32 3. Global Entitlement The global entitlement layer controls the mapping of end users to desktops in a Cloud Pod Architecture. Global entitlement consists of a set of parameters as shown in Figure 2: Following are the various parameters of global entitlement: Name Name of the global entitlement Members The users and/or groups that share the global entitlement Desktops Desktops that the members of the global entitlement are entitled to Scope Controls the scope of search when placing a new desktop session. This allows the administrator to control the amount of cross-data-center traffic. FromHome (true/false) This controls where the desktop search is started. When false, it starts from the current pod; when true, it starts from the user s home site. The scope can be one of: Local Look only in the local pod for available desktops Site Look in all pods in the local site (typically in the same data center) All Look across all pods for an available desktop to service the request The search order favors local resources, starting in the same pod that the user connected to, then extending to the same site, and then across the entire linked environment. In addition to this default search order, administrators can nominate a home site for a single user or for a group of users. When a global entitlement has the FromHome policy set, the search for a new desktop is started in the user s home site and not the current connected pod. This ensures that, where needed, the desktop session remains close to any backend resources it needs. Page 32

33 4. Scale Limits, Maximums, and Architectural Assumptions Scale Limits and Maximums The Cloud Pod Architecture was developed with the goal of scaling View desktop deployments to hundreds of data centers and tens of thousands of desktops. To deliver this capability in time for product launch, the VMware team has done a phenomenal job of validating this feature by focusing the testing efforts on the following scale-out parameters: Number of pods 25 Number of sites 5 Number of desktops 50,000 Architectural Assumptions A number of architectural assumptions have been made in delivering this feature: The deployment can have both persistent (stateful) and nonpersistent (stateless) desktops A third-party load balancer such as Geographic DNS or a similar product provides the single-url capability Replication of desktops or end-user data is provided by a third-party data replication technology WAN links between data centers are sufficiently provisioned and have good latency characteristics however, the feature works on low-bandwidth, highlatency connections and does not impose either a latency drag or additional bandwidth. It is important to note that user experience varies with both the latency and the bandwidth between data centers. All pods are accessible to each other across the corporate network Page 33

34 Configuring Cloud Pod Architecture 1. Access VMware Horizon 7 Administrator for Pod A 1. On the desktop of the MainConsole desktop, open a web browser and navigate to 2. Log in as corp\administrator Page 34

35 2. Navigate to View Configuration Expand View Configuration and select Cloud Pod Architecture. Click "Initialize the Cloud Pod Architecture feature" under Basic Tasks Page 35

36 3. Initialize Cloud Pod Architecture Click OK and wait for the initialization to complete. When the task finishes, click OK to reload the browser. Page 36

37 4. Edit the Default First Site In the navigation tree on the left, a new option called Sites will appear after the initialization is complete. We will rename the Default First Site to Palo Alto to create a more descriptive name for the site. 1. Navigate to View Configuration>Sites 2. Click Default First Site 3. Click Edit Page 37

38 Rename the site to Palo Alto Change the name of the site to Palo Alto and click OK. 5. Access VMware Horizon 7 Administrator for Pod B 1. On the desktop of the MainConsole desktop, open a web browser and navigate to 2. Log in as corp\administrator Page 38

39 6. Navigate to View Configuration Expand View Configuration and select Cloud Pod Architecture. Click "Join the pod federation" under Basic Tasks 7. Enter federation information for Pod A Page 39

40 8. Join the Pod Federation Click OK to join the federation. When the task completes click OK to reload the browser. 9. Add a new site to the federation When the pod B successfully joins the federation it will be automatically joined to the first site (Palo Alto) that was created when we initialized Cloud Pod Architecture. To put pod B in it's own site, we must first create the object. Navigate to View Configuration>Sites and click Add. Name the new site "Barcelona". Page 40

41 10. Move Pod B to the Barcelona site 1. Click Palo Alto to select the site. Notice that currently both pods are in the Palo Alto site. 2. Select the pod B in the list below and click Edit. Select Barcelona and click OK. Now we have two separate sites with one pod in each site. In the next section we will take a high level look at global entitlements and the available configuration options. Page 41

42 Configure Global Entitlements 1. Access Global Entitlements from the Catalog Navigate to Catalog>Global Entitlements and add a new global entitlement. Page 42

43 Select the entitlement type Choose desktop entitlement. Configure Global Entitlement Policies Scope: Specifies where to look for desktops or applications that satisfy a desktop or application request from the global entitlement. You can select only one scope policy. 1: All sites - View looks for desktops or applications on any pod in the pod federation. 2: Within site - View looks for desktops or applications only on pods in the same site as the pod to which the user is connected. Page 43

44 3: Within pod - View looks for desktops or applications only in the pod to which the user is connected. Home Site: Causes View to begin searching for desktops or applications in the user s home site. If the user does not have a home site and the Entitled user must have home site option is not selected, the site to which the user is currently connected is assumed to be the home site. Entitled Users must have home site: Causes the global entitlement to be available only if the user has a home site. This option is available only when the Use home site option is selected. Automatically clean up redundant sessions Logs off extra user sessions for the same entitlement.. This option is available only for floating desktop entitlements and application entitlements. Multiple sessions can occur when a pod that contains a session goes offline, the user logs in again and starts another session, and the problem pod comes back online with the original session. When multiple sessions occur, Horizon Client prompts the user to select a session. This option determines what happens to sessions that the user does not select. If you do not select this option, users must manually end their own extra sessions, either by logging off in Horizon Client or by launching the sessions and logging them off. Page 44

45 Page 45

46 Conclusion This concludes the high level overview of securing Horizon with NSX. For a deeper dive into Horizon 7 or NSX concepts, check the HOL catalog. You've finished Module 2 Congratulations on completing Module 1. Proceed to any module below which interests you most. Module 1 - Securing Horizon 7 with NSX(30 minutes) - Use the NSX distributed firewall to secure communication between Horizon 7 data center components. Module 3 - Presenting a Linux Hosted desktop with Horizon 7 (15 minutes) - Overview of requirements for implementing Linux VDI in Horizon 7. How to End Lab To end your lab click on the END button. Page 46

47 Module 3 - Presenting a Linux Hosted Desktop with Horizon 7 (15 minutes) Page 47

48 Introduction to Linux Desktop Why Linux Desktop's Delivering, managing and accessing Linux virtual desktops with Horizon 6 for Linux eliminate the need to license commercial operating systems. Get full support for Linux desktops and provide seamless access to office, 3D graphics, and developer applications. Horizon 6 for Linux is ideal for software developers, CAD/CAM developers, cost sensitive deployment wishing to reduce software licensing costs and anyone else who needs the cost savings, security and customization available under Linux. ** This module describes the workflow in configuring the Linux Desktop VM, installing the View agent, and configuring the Linux desktop VM for 3D vdga. All the following steps are for informational purposes only and you don't have to do anything. Page 48

49 Top Use Cases Government, Energy, Simulation, Transportation, Manufacturing, Media & Entertainment and Aerospace are key industries using Linux desktops today. RedHat has a number of customers using RHEL for Mathematical and numerical analysis. With Horizon 6 for Linux, organizations can now extend the benefits of desktop and application virtualization to Linux users. Horizon for Linux centralizes desktop management and secures data in the data center while supporting end users with seamless access to Linux services across devices, locations, mediums, and connections. Furthermore, this solution allows organizations to move away from costly Windows licensing and to embrace low-cost endpoints to deliver the best possible total cost of ownership. Supported Distributions Ubuntu LTS (32bit and 64bit) Ubuntu LTS (Long Term Support) is 10.04, and RedHat Enterprise Linux 6.6 (RHEL 6.6) CentOS 6.6 CentOS 7 works but is not supported at GA Page 49

50 NeoKylin (Tech Preview) Requirements Horizon or higher vsphere* 5.5 U2 or higher (6.0 or higher recommended) Horizon Client for Windows, Mac or Linux 3.3 or higher Linux agent (Latest) *vdga requires vsphere 6.0 or higher Pre-Requisites Java Runtime Edition (JRE)* 7 update 75 (Update 76 for Ubuntu) DNS & Hostname /etc/resolv.conf /etc/hosts /etc/sysconfig/network-scripts/ (RHEL) VMware Tools Page 50

51 Latest version Windows Active Directory Join to AD domain Store password using reversible encryption for Windows Server 2012 and R2 *The agent installer with download JRE if it is not present Supported Features * HTML Access works on some browsers but is not supported Sizing Guidelines for Linux Desktops Page 51

52 Linux Desktop Deployment It is important to understand the possibilities of creating a Linux pool in an automated fashion, at the moment this is not possible with Horizon direct. Provisioning You have the ability to create an automated pool in three different ways by using different tools. Depending on what you consider to use, the diagram above gives you indication on the level of complicity. Page 52

53 Steps to Prepare a Template PowerCLI Power shell scripts are the easiest way to automate the pool cloning for Linux virtual machines. Page 53

54 Benefits Automate the cloning of multiple (hundreds) of Linux virtual machines No prior PowerShell knowledge is necessary using supplied scripts Use kickstart (.ks) scripts to customize your master images (optional) Use PowerCLI to add Linux desktops to pool Get creative and create your own scripts! Note: PowerShell Scripts and CSV can be found in DeployLinuxAgents.zip Page 54

55 vrealize Orchestrator To automate the pool creating with vrealize Orchestrator is a medium easy way to manage your Linux desktop pool creation. Benefits vrealize Orchestrator (vro) is already included with vcenter Server Horizon vro plugin allows for further integration like adding desktops into the pool, as well as management of the user entitlement Self-service for end user enablement by integration with vrealize Automation (requires vra license) Kickstart / PXE Boot To automate the pool creating with Kickstart / PXE Boot is a harder way to manage your Linux desktop pool creation as it requires more backend components like the PXE server. Benefits Use Kickstart Configurator to create or modify scripts Graphical interface allowing full customization Use PXE boot for automated installation Page 55

56 yum install system-config-kickstart or apt-get install system-config-kickstart Preparing the Linux Virtual Machine VMware Tools can be installed using apt-get install open-vm-tools which will stay up-todate with Linux updates (apt-get update). Name resolution and a working DNS is critical for successfully creating a Linux pool Page 56

57 Virtual Machine Display Settings Configure the video memory and number of displays Configure the.vmx for RHEL, Ubuntu, or CentOS multi-display svga.maxwidth="8192" svga.maxheight="2048" It is important to understand why the number of displays and video RAM is important. Leaving this as the default (4MB) will result in low screen resolutions and the VM being unable to resize to the Horizon Client s display resolution Installing the Horizon Agent 1. Copy the Horizon agent.tar to the virtual machine 2. Extract the.tar file and CD to VMware-viewagent directory 3. Execute./install_viewagent.sh and specify parameters Values: -b -d -u -p -j -n -s Horizon Connection Server AD domain name AD username AD password JMS SSL keystore password VM name for agent* SSL subject DN *-n specifies a name for the Linux agent on that virtual machine. It s not required, but an example would be (linux-centos-x64-1) Page 57

58 Create a Linux Desktop Pool 1. Create a manual desktop pool 2. Select Other sources 3. The display protocol selection is ignored for Linux Desktops 4. HTML Access may work, but is NOT supported! (yet) Page 58

59 Linux Desktop and 3D with vdga This part will show the steps required to configure vdga with Linux desktop. Linux 3D Graphics Primer Disabling Compiz will improve performance on Ubuntu. Nouveau must be disabled for NVIDIA drivers to be loaded. Linux uses OpenGL (not DirectX) for 3D graphics. Preparing the Linux desktop for vdga Disable the Nouveau driver 1. Edit /boot/grub/grub.conf and add rdblacklist=nouveau Page 59

60 2. Edit /etc/modprobe.d/blacklist.conf and append with Note: Ubuntu requires you to create /etc/modprobe.d/blacklist-nouveau.conf Install the NVIDIA Driver 1. Install the prerequisites # yum install gcc-c++ kernel-devel kernel-headers -y 2. Download the NVIDIA driver and enable the execute bit # chmod +x NVIDIA-Linux-x86_ run 3. Exit X and run the installer # init 3 #./NVIDIA-Linux-x86_ run -kernel-source-path=/usr/src/kernels/ el6.x86_64/ Note: For Ubuntu, install driver with sudo apt-get install nvidia-current-updates Page 60

61 Configure X.Org 1. Get the NVIDIA GPU Device ID: lspci grep VGA 2. Edit /etc/x11/xorg.conf Linux Desktop Best practices This section covers some of the best practices. Environment & Setup Use domain service account for Horizon - Avoid using built-in Administrator account Make sure DNS is fully configured Use master VMs to manage Linux golden builds -Clone from the master Don t store plain text passwords in Kickstart scripts! -Use rootpw iscrypted <encrypted_password> -Use OpenSSL to generated hashed password: openssl passwd -1 <password> Optimizing Linux Desktops This section talks about some of the optimizations you could do in Linux desktop. Page 61

62 Disable Compiz (Ubuntu) Disable Compiz for better desktop performance Disable Unnecessary Services Disable unnecessary services bluetooth postfix netfs mdmonitor Page 62

63 Troubleshooting the Horizon Agent 1. Check that the agent is running 2. Check agent config files (make sure they are not empty!): 3. Make sure DNS name resolution is working The Horizon Agent is installed to /usr/lib/vmware/viewagent Un-installing the Horizon Agent Page 63

64 Linux Command 1. $ sudo /usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh 2. $ sudo rm /etc/vmware/jms /etc/vmware/ssl -R 3. $ sudo rm /etc/vmware/viewagent-machine.txt /etc/vmware/viewagent-config.txt Remove Horizon desktop pool and registered machine Page 64

65 Conclusion This concludes the high level overview of securing Horizon with NSX. For a deeper dive into Horizon 7 or NSX concepts, check the HOL catalog. You've finished Module 3 Congratulations on completing Module 1. Proceed to any module below which interests you most. Module 1 - Securing Horizon 7 with NSX(30 minutes) - Use the NSX distributed firewall to secure communication between Horizon 7 data center components. Module 2 - Cloud Pod Architecture(30 minutes) - Walk through implementing Cloud Pod Architecture and global entitlements in multi-site Horizon 7 environment. How to End Lab To end your lab click on the END button. Page 65

66 Conclusion Thank you for participating in the VMware Hands-on Labs. Be sure to visit to continue your lab experience online. Lab SKU: Version: Page 66