Skip to content

CategoryAllgemein

Use Terraform to deploy hundreds of full clone desktops in VMC on AWS

This blog will explain how to leverage Terraform to deploy hunderts of desktops to use them afterwards in Horizon as a Manual Desktop Pool.

First step is to install Terraform. Download Terraform from https://www.terraform.io/downloads.html Terraform is distributed as a single binary. Install Terraform by unzipping it and moving it to a directory included in your system’s. Once the download is finish

  1. Unzip
  2. Copy binary to a place in the path such as /usr/local/bin
  3. cp $HOME/Downloads/terraform /usr/local/bin/
  4. Verify installation terraform -v

Now that terraform is working let’s create a working directory where we can safe our configuration file, our provider and variable files. I used my Desktop for example purpose. I use Visual Studio and have installed the Terraform plugin. Switch to your working directory in the terminal. Create a simple first provider file and safe it into your working directory as provider-vsphere.tf

provider-vsphere.tf

# Configure the VMware vSphere Provider
provider "vsphere" {
 user = "${var.vsphere_user}"
 password = "${var.vsphere_password}"
 vsphere_server = "${var.vsphere_server}"
# if you have a self-signed cert
allow_unverified_ssl = true
}

Run the terraform init command for a new configuration — or after checking out an existing configuration from version control — which initializes various local settings and data that will be used by subsequent commands. Terraform uses a plugin based architecture to support the numerous infrastructure and service providers available. The terraform init command will automatically download and install any Provider binary for the providers in use within the configuration, which in this case is just the vsphere provider:

Since we are working with variables for the vcenter server , vsphere user and password we need to create additional files. Safe those files in your working directory.

Vars.tf

variable "vsphere_user" {}
variable "vsphere_password" {}
variable "vsphere_server" {}
variable "euconvmc" {}

variable "name_prefix" {
   default = "FC-EUCONVMC-"
}
# Define the number of resources to be deployed
variable "amount" {
   default = 100
}
# Use an offset to start counting from a certain number
# or else the first server will be named server-01 and #receive an ip address 192.168.105.51
variable "offset" {
default = 1
}


Terraform.tfvars

vsphere_user = "cloudadmin@vmc.local"
# Your cloudadmin password. That you will find on your vmc console.
vsphere_password = "your vCenter PW for Cloudadmin@vmc.local"
# your vCenter server IP adress. Find in your VMC console
vsphere_server = "3.12.16.195"
# Your password for your domain
euconvmc = "your domain password"

Now we will create our terraform file that will use those variables and clone our golden master image 100 times. Of course we prepared the GM before hand. Means a working DHCP, all needed apps and Horizon Agent 7.11 installed.

Creating the Terraform file for cloning the GM

Horizon-FC.tf


data "vsphere_datacenter" "dc" {
  name = "SDDC-Datacenter"
}

data "vsphere_datastore" "datastore" {
  name          = "WorkloadDatastore"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

data "vsphere_compute_cluster" "cluster" {
    name          = "Cluster-1"
    datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

data "vsphere_resource_pool" "pool" {
  name          = "Compute-ResourcePool"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

data "vsphere_network" "network" {
  name          = "Production"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

data "vsphere_virtual_machine" "template" {
  name          = "W10-GM-IM"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

resource "vsphere_virtual_machine" "vm" {
    count = "${var.amount}"
    name             = "${var.name_prefix}${format("%02d", count.index + 1 + var.offset)}"
    folder           = "Workloads"
    resource_pool_id = "${data.vsphere_compute_cluster.cluster.resource_pool_id}"
    datastore_id     = "${data.vsphere_datastore.datastore.id}"
    firmware         = "${data.vsphere_virtual_machine.template.firmware}"

    num_cpus = 2
    memory   = 4096
    guest_id = "${data.vsphere_virtual_machine.template.guest_id}"
    
   
    network_interface {
        network_id   = "${data.vsphere_network.network.id}"
        adapter_type = "${data.vsphere_virtual_machine.template.network_interface_types[0]}"
    }
    
    disk {
        label            = "disk0"
        size             = "${data.vsphere_virtual_machine.template.disks.0.size}"
        eagerly_scrub    = "${data.vsphere_virtual_machine.template.disks.0.eagerly_scrub}"
        thin_provisioned = "${data.vsphere_virtual_machine.template.disks.0.thin_provisioned}"
    }
    
    scsi_type = "${data.vsphere_virtual_machine.template.scsi_type}"

    clone {
    template_uuid = "${data.vsphere_virtual_machine.template.id}"
            
            customize {
                windows_options {
                    computer_name = "${var.name_prefix}${format("%02d", count.index + 1 + var.offset)}"
                    join_domain = "euconvmc.local"
	                domain_admin_user = "administrator@euconvmc.local"
	                domain_admin_password = "${var.euconvmc}"
                }
                network_interface {}
                
            }
    }
}

Now that we have the code ready, run a terraform plan to check what actually will happen. If you get the right output you can run a terraform apply and it will deploy 100 desktops in about 15 min on a VMC on AWS SDDC.

As we have the desktops deployed but they are not yet in the Horizon available we need to create a “manual desktop pool” in Horizon Connection Server and select the freshly created VMs. Once the desktops selected and integrated in the connection server they will switch to state ” available” and you can connect to those desktops.

VMware Carbon Black Cloud for Endpoint Security

This is an article about how I used VMware Carbon Black Cloud ONLY as a showcase to secure desktops running on VMC on AWS.

The VMware Carbon Black Cloud is a cloud-native endpoint protection platform (EPP), CB provides what you need to secure your endpoints, using a single lightweight agent and an easy to use console.

VMware Carbon Black provides:

  • Superior Protection
  • Actionable Visibility
  • Simplified Operations
VMware Carbon Black Cloud 
Built-in. Unified. App & Threat Context. 
One 
Lightweight 
Agent 
Endpoint 
Workload 
vmware 
Carbon Black. 
Cloud
VMworld 2019 Annoucement

First let’s take a look on the Console. It is a web-based Console hosted in a AWS Datacenter. You can login via SSO or E-Mail and Password. Dashboard give you a good overview about what is going on, any events or issues.

View data 
2 weeks 
All policies 
o 
VMWARE-DE.COM 
DASHBOARD 
ALERTS 
INVESTIGATE 
ENFORCE 
ENDPOINTS 
SETTINGS 
Getting Started 
Complete the fundamental tasks to set up your organization 
Carbon Black Cloud setup 
Prevent with policies 
Additional resources 
Attacks Stopped 
> Add console administrators 
Send sensor installation requests 
él View deployed sensors 
Endpc 
10+ added 
10+ sent 
10+ active 
* Curren 
Potentially Suspicious Activity 
Non-Malware 
Potential malware 
Malware 
PUPS 
2 
Attack Stages 
RECON 
Non-Malware 
Potential malware 
Malware 
Pl.-JPs 
WEAPONIZE 
DELIVER/EXPL 
INST/RIJN 
2 
CMD+CTRL 
EXECUTE GOAL 
Email 
Web

Let’s start to get CB rolling and define some policy groups. In a policy group you can define all kind of settings, what should happen if something get’s detected, or just simple things like, when should the system get scanned. To create a new Policy let’s get to enforce and then policy.

Carbon Black. 
VMWARE-DE.COM 
DASHBOARD 
ALERTS 
INVESTIGATE 
LIVE QUERY 
ENFORCE 
Policies 
Reputation 
Malware Removal 
Cloud Analysis 
Notifications 
POLICY 
Use policies to define and prioritize rules for how applications can behave on groups of devices 
Help > 
X DELETE POLICY 
Thomas Sauerer (vmware-de.com) > 
+ NEW POLICY 
NAME 
Monitored 
Standard 
Advanced 
LiveOps Test 
X DUPLICATE POLICY 
Save 
DEVICES 
6 
8 
General 
General 
Prevention 
Local Scan 
Sensor 
LOCKED POLICY 
* Policy name 
Monitored 
Policy description 
Monitor only, NO prevention.

Add a new Policy, name it, add a description and copy setting from the standard Policy Group.

Perfect, now we can do some modifications. We can change as a example what should happen, if a known malware process is running. As default it will terminate the process. It is even possible to terminate the process when it’s trying to communicate over the network.

leral 
Prevention 
Local Scan 
Sensor 
these rules to configure how sensors control process behavior 
Permissions 
Blocking and Isolation 
PROCESS 
Known malware 
SHOW @ 
Allow specific operations or bypass application activity entirely. Takes precedence over blocking and isolation settings below. 
Deny or terminate processes and applications. 
OPERATION ATTEMPT 
Runs or is running 
Communicates over the network@ 
Scrapes memory of another process 
Executes code from memory@ 
Invokes an untrusted process 
Invokes a command interpreter@ 
Performs ransomware-like behavior@ 
Executes a fileless script@ 
Injects code or modifies memory of another process 
Deny operation 
ACTION 
Terminate process 
Confirm 
Cancel

You also can change the local scans, On-Access File scan, frequency and more. Keep it in mind if you have to exclude any on-access scans on specific files/folders.

On the last, “Sensor” you can edit the sensor settings of the client. I will deploy CB to our demo and test environment, in this case I allow user to disable protection. Usually you will not allow the User to disable the security! Guess what, if user can disable it most of them will do..

Next what we need to do is to create a Endpoint Group. In Endpointgroups you can define different policys or criteria to seperate different Workloads and assign them automatically to a policy. To do this, you have to go to “Endpoint” section on the left side and add a new group.

Carbon Black. 
VMWARE-DE.COM 
SENSOR GROUPS 
t All Sensors 
DEMO EMEA (HL Buschi) 
VMC Lab (Thomas) 
Mayonez (Aleks) 
o 
VMC Lab (Thomas) 
os: Any I 
Policy: VMC Horizon Policy 
Sensors: 2 
Criteria: Subnet starts with "172.30.120" 
more 
x 
Take Action 
Notifications 
All Sig Pack Status 
Help 
Thomas Sauerer (vmware-de.com) > 
Clear search 
Status 
U CSV Export 
Policy 
-k Add Group 
Search 
TAKE ACTION 
o 
DASHBOARD 
ALERTS 
INVESTIGATE 
LIVE QUERY 
ENFORCE 
ENDPOINTS 
SETTINGS 
> 
> 
STATUS 
O 
O 
DEVICE NAME 
SET\EMEA-FC-018 
WIN-4KT1 DKDC2AO 
USER 
tsauerer@vmware.c 
om 
tsauerer@vmware.c 
om 
os 
Windows 10 
x 64 
Windows 
Server 201 6 
x 64 
SENSOR 
3.4.0.1086 
3.4.0.1086 
SIG 
POLICY 
VMC Horizon P 
olicy 
VMC Horizon P 
olicy 
T 
J 
LAST CHECK-IN 
3:37:23 pm 
Nov 22, 2019 
3:34:55 pm 
Nov 22, 2019

It makes sense to seperate different Workloads as Horizon, WebServer etc. You can set different criteria like IP Range or Operating System to automatically add the Server to different Endpoint Groups.

Last step, we need to install the Carbon Black Sensor. Basically it should make sense to add the Sensor directly to the basic Images and also define a Default/general Endpoint Group where all clients are added with a basic ruleset. When you change, as a example, the IP address from the Server it will automatically update the Endpointgroup and add the Server to the new Policy Ruleset. In my case i will just install the Sensor manually.

To download the Sensor we need to go to Endpoints -> All Sensors on the top right you will find Sensor Options -> Download Sensor kits.

Carbon Black. 
v 
VMWARE-DE.COM 
DASHBOARD 
ALERTS 
INVESTIGATE 
LIVE QUERY 
ENFORCE 
ENDPOINTS 
SETTINGS 
ENDPOINTS 
Install sensors on endpoint devices and use groups to assign and manage policies 
Status 
USER 
WIN-E023BNPMM00 
\Administrator 
os 
Server 2008 R2 
x64 SP: 1 
Windows 
Server 2016 
x64 
Signature 
SENSOR 
3.4.0.1052 
3.4.0.1070 
Notifications 
Policy 
GROUP/POLICY 
Manually Assigned 
Monitored 
Advanced 
Help > 
Thomas Sauerer (vmware-de.com) > 
SENSOR GROUPS 
t All Sensors 
VMC Lab (Thomas) 
All Sensors 
Sensors: 16 
Search 
STATUS 
Sensor Options v 
Sensor settings 
Company codes 
Download sensor kits 
Send installation request 
DEVICE NAME 
WIN-E023BNPM 
MOO 
LAB\HLWinSerO 
3 
SIG 
T 
> 
o 
o 
LAST CHECK-IN 
1 am 
Dec 6, 2019 
am 
Dec 6, 2019 
+ Add Group 
Export 
ACTIONS 
>_ 
>_

Run the installer on the target system, agree the terms and enter the License Key. We are done, the Sensor is installed! Take a look back to the Console “Endpoints”, you can see now the VM automatically added to the correct group and policy.

RDS for Horizon Eventlog Database on VMware Cloud on AWS

Amazon Relational Database Service (Amazon RDS) makes it easy to set up, operate, and scale a relational database in the cloud. It provides cost-efficient and resizable capacity while automating time-consuming administration tasks such as hardware provisioning, database setup, patching and backups. It frees you to focus on your applications so you can give them the fast performance, high availability, security and compatibility they need.

Horizon needs a Database for the eventlogs. We will use RDS to create a database for our event db in Horizon.

Deploy RDS on AWS is super easy. Just Click on the RDS service in AWS , select the DB type you need – in our case we will use MS SQL – For our Demo we will use the free tier but of course it is just for demo purpose. Once the DB instance is up and running you have to find the Endpoint URL and make sure the right port is set and it should be not public accessible since we will use the ENI connection to access the DB.

We can now proceed and try to access this new instance via a VM with SQL management tools installed on it in VMC on AWS. We will also use the management tools to create a a specific database for the eventlogs.

We are connected to the DB instance and can create a specific DB for the eventlog database.

Now we can start to configure Horizon Connection Server with the eventlog Configuration

Prerequisites for Configuring Event DB

You need the following information to configure an event database:

  • The DNS name or IP address of the database server.
  • The type of database server: Microsoft SQL Server or Oracle.
  • The port number that is used to access the database server. The default is 1521 for Oracle and 1433 for SQL Server. For SQL Server, if the database server is a named instance or if you use SQL Server Express, you might need to determine the port number. See the Microsoft KB article about connecting to a named instance of SQL Server, at http://support.microsoft.com/kb/265808.
  • The name of the event database that you created on the database server. See Add a Database and Database User for View Events.For an Oracle 12c or 11g database, you must use the Oracle System Identifier (SID) as the database name when you configure the event database in View Administrator.
  • The username and password of the user you created for this database. See Add a Database and Database User for View Events.Use SQL Server Authentication for this user. Do not use the Integrated Windows Authentication security model method of authentication.
  • A prefix for the tables in the event database, for example, VE_. The prefix enables the database to be shared among View installations.

That is only one example how to use RDS service with our EUC solutions. In further blog posts i will bring more examples specially for POC’s. Also my next blog post will bring light into how to use FSx for profile data and other file services.

Route 53 for VMware Horizon on VMware Cloud on AWS

Amazon Route 53 is a highly available and scalable cloud Domain Name System (DNS) web service. It is designed to give developers and businesses an extremely reliable and cost-effective way to route end users to Internet applications by translating names like http://www.example.com into the numeric IP addresses like 192.0.2.1 that computers use to connect to each other.

We will use Route 53 to create a DNS record that will point us to a public IP address we are requesting via VMware Cloud on AWS and pointing to our UAG.

Continue reading “Route 53 for VMware Horizon on VMware Cloud on AWS”

Leveraging AWS AD service with VMware Horizon on VMware Cloud on AWS

VMC on AWS is a great solution to use AWS native service and implement those native services into existing services. In this blog post series, I will explain how we can leverage Active Directory, RDS, FSx and other AWS native service with our EUC solutions. This will only show you how easy it is to implement AWS native service into existing services and is using ONLY for Demo purpose for this blog post.

Before we can start we need to make sure that we have set the right firewall rules on the VMC site but also in the AWS security group. We created a AWS out and AWS in policy on VMC and configured the security group on AWS site. Please make sure this connection is working before proceeding with the AWS native deployment. We will roll out an AWS managed Active Directory. This Active Directory will be used for our whole Horizon deployment on VMware Cloud on AWS. All Horizon Components are living in VMware Cloud on AWS but will attach AWS native services via the ENI for EventDatabases, Active Directory and other services. Let’s roll out our first AWS managed Active Directory. Go to your AWS account and click on Directory Services

Continue reading “Leveraging AWS AD service with VMware Horizon on VMware Cloud on AWS”