VMware vShield End-point

From vmWIKI
Jump to: navigation, search

Originating Author

Michelle Laverick

Michelle Laverick.jpg

Barry Coombs

Screen Shot 2014-04-28 at 09.41.39.png

Video Content [TBA]

Introduction to VMware vShield End-point

Version: Horizon View 5.1

Introduction

There are many security technologies available in the market, and not to be outdone VMware has its own called “vShield”. It’s quite a broad technology that has applications above and beyond the topic of this book – virtual desktops. For example vShield forms a critical part of VMware’s “vCloud Director” their cloud automation platform. In that case vShield allows for vSphere and vacs to support a secure multi-tenancy model where every organization within its boundaries resides in its own network bubble. In terms of VMware View, vShield can contribute to improving the user experience and overall scalability of the View Infrastructure by offloading anti-virus workloads to vShield. A good analogy for this resides in the arena of backup. In the early years of virtualization many companies persisted in install backup agents to VMs and treating them the same as physicals – in fact this approach persists to this day. Unfortunately, doing so puts an unnecessary CPU and network load on the ESX host. It’s perhaps more sophisticated and efficient to backup outside of VM – or so-called VM Backup. You could say vShield Endpoint is doing the same for AV that VM Backup pioneered by the likes of VizionCore (now part of Quest Software) and Veeam did for backup. Sadly, there’s little in the way of truly independent comparisons between traditional in-guest agent-based AV and vShield – with nearly all the reports being sponsored in some shape or form by the vendors. But if you are looking for good summary the Tolly Group often have this type of compare/contrast data. A good place to start looking is here:

http://blogs.vmware.com/security/2011/03/security-conference-followup.html

Some of the performance information is now out of date since the 5.0 and 5.0.1 release of vShield that introduce architectural changes that should improve these base performance figures.

vShield is available in number of formats individually in an “a la carte” fashion or it can be procured as an all-in-one purchase. These are individual components:

vShield Manager

“Installs” as virtual appliance and optionally can be registered with vCenter – it acts the central management point for different functions of vShield App

vShield App

Firewall capabilities with the ability to set policies based on objects within the inventory of vCenter

vShield App with Data Security

As above but adds inspection of sensitive data based on violations reported by the appliance.

vShield Edge

Provides network security for applications such as vCloud Director and comes with common network components such as DHCP, VPN, NAT and Load-balancing

vShield Endpoint

Offloads anti-virus and anti-malware to dedicate virtual appliance. The appliance is always on updating signatures made available via VMware’s 3rd party partners. Protects VMs that are powered on, and automatically updates powered off VMs with new signatures when they powered back on. It ships as a virtual appliance together with a “hypervisor” module that is loaded by the ESX VMkernel. This works in harmony with what’s called the “Security Virtual Machine” or SVM. This is provider by third-party to VMware such as Trend Micro or BitDefender.

Endpoint-1.jpg

Note: This diagram is taken from Bitdefender’s website. Bitdefender “Security for Virtual Environments”. It’s quite a good graphic because it shows both the VMware and third-party together. So you can see that vShield and the 3rd party management console both speak to vCenter. vShield Manager assists in installing the “vShield Host Driver” and VMware Tools includes the “vShield Endpoint driver” on each VM.

One of the jobs of the third-party Security Console is to aid in the deployment of its Security Virtual Applianc) to each ESX host. The guest operating systems such as virtual desktops can contain optionally a “Bitdefender Silent Agent” that provides the user with an interface to check their protection status.

vShield and its version numbers is how customers referrence the product. Between VMware and its partners a separate name is used called “EPSEC” API. vShield 1.0 used EPSEC 1.0 and vShield 5.0 uses EPSEC 2.0. This can be somewhat confusing if the partner your working with refers to the EPSEC version numbering scheme. It’s perhaps best to stick with the vShield numbering, and just confirm that the version of vShield you intend to use is compatiable with your version of the vSphere platform you are using.

Below is a more vendor neutral diagram of the EPSEC 2.0 implementation from VMware:

Endpoint-2.jpg

From the guest operating system perspective an endpoint driver is installed into the virtual desktop, which communicates to an “ESX module” on the ESX host called the the “Mux” (Multiplexer). The ESX host moves information from the VMCI layer into the TCP stack, and communicates via an internal vSwitch into the Security Virtual Appliance (SVA). This means that communication is descrete and secure and neither the SVA or the VM needs to exposed to the internet for virus definition downloads, scans or remediation.

This new structure allows vShield to run with more than one partner on the same ESX host. This is inline with VMware’s cloud and multi-tennacy model where multiple tennants in the cloud may perfer to use one AV vendor over another. Additionally, within a partner they may want in future to have separate virtual appliance (VA) for each security function – like a VA for AV, a VA for encryption and so on.

As you might expect most of the AV vendors provide much the same features such as on access and on demand scanning. The biggest variance appears to be what they do if they encounter a virus. This general reflects their own position on what to do if a virus is encounted. They each have their own ideological view point, and this often reflects how they have handled virusus before virtualization became mainstream.. So some will delete an infect file, whilst some will quarantine it – others might attempt to clean-up the file. They also seem to compete around who has the best caching and filtering algorithms and tools – to reduce the burden of checking files that have been checked before, or files that are to be ignored by the scanning process. Others compete by saying they learn of new virusus quicker than their competitors, and therefore can offer more protection from rapidly spreading dangers.

Hardware and Software Requirements

To get started you need at least one vShield Manager for each vCenter – vShield App and Endpoint require on virtual appliance for each ESX host in the cluster – and one vShield Edge per portgroup on a virtual switch. Our focus will merely be on the configuration of vShield Endpoint – but we’ve chosen to include the requirements for all the features just in case you decide to adopt vShield in your wider environment.

The other thing you will need is a Security Virtual Appliance (SVA) from a 3rd party anti-virus provider. That can be a little tricky as there isn’t a huge number of them - if you are just wanting to evaluate vShield Endpoint, most of the 3rd parties do not allow you to just trip along to their website and download. Most times you will have to register and then be checked out. This is to ensure you get proper support during the evaluation, and ensure you don’t get a false impression of the quality of the implementation – that is more a reflection of your ignorance. That’s what they say. Hopefully sales people won’t harangue you!

The SVA is a virtual appliance that interfaces with the vShield Virtual Appliance and normally incorporates its own web front-end often referred to as the Security Virtual Console (SVC). This SVC can be used to deploy many SVA’s to each ESX host. Many vendors also incorporate an optional “agent” that can be installed into the virtual desktop. Strictly speaking this not required, but some times end-user like the reassurance of being able to see their security status, as they would with a conventional AV client that has been installed to the guest operating system

All the vShield components need 8GB of memory each – that includes the manger and components like App, Edge and Endpoint. The vShield Manager needs 8GB of disk space, and each vShield App and Edge requires 5GB and 100MB of disk space respectively. VMware recommend at least two 2Gps VMnics teamed together provide network redundancy to the appliances themselves.

The current edition of vShield is compatible with vCenter 4.x Update 2 and ESX 4.0 update 2 – however in the context of this book that has been based on vSphere5, both vShield Endpoint and vShield Data Security require ESXi 5.0 Patch 1. Additionally, both Endpoint and Data Security require the VMs have hardware version 7 or 8, and that VMware Tools is up to date with on version 8.6.0 or higher which was released with ESXi 5.0 Patch 1.

You can confirm the VM hardware level by adding the “VM Version” column to the virtual machine tab in vCenter, or by editing the VM’s settings in vCenter. If you are not using the “Linked Clones” feature you will need to modify you template that is used as the source for deploying new desktops.

Endpoint-3.jpg

Note: As you can see in our case we discovered the Accounts Desktop pool was running Windows 7 under version hardware level 7, rather than vSphere5 native hardware level version 8. We decided to upgrade the “Parent VM”, and the refreshed the linked clone virtual desktop manager.

You can confirm the VMware Tools version the toolbox application that sits in the virtual desktop icon tray in Windows.

Endpoint-4.jpg

Additionally, the vShield Endpoint system requires a driver that’s now installed as part of VMware Tools, if you use complete it will be installed and if you use “Custom” you have the option to install under +VMware Device Drivers, + VMCI Driver and “vShield Driver”. We would recommend incorporating it into your templates and parent VMs for linked clones. The vShield Driver is often supplemented with what’s referred to as vendor’s “Silent Agent” and is available to download from the 3rd party vendors website. For example BitDefender has both 32-bit and 64-bit Silent Agents available for Windows.

Endpoint-5.jpg

Note: The build number shows we are within the requirements within the virtual desktop. Incidentally, the vShield Appliance obliviously uses VMware Tools – but VMware’s own “Quick Start” guide indicates you should leave those well alone and not attempt to upgrade them. This driver was included in VMware Tools relatively recently – occasionally you will some vendor documentation that talks about the “Thin Driver” or the “Thin Agent” needing to be installed. That’s a little out of date, as since vSphere5 this is now include this as part of VMware Tools and is now referred to as the vShield Driver. In previous version of vShield the driver was SCSI based, and only worked with the LSI Controller inside a VM, and this cause implementation problems with guest operating systems that default to different controller types such as Windows 2000 defaults to using a BusLogic Driver. Starting with vShield 5.0, VMware switched to using their Virtual Machine Communication Interface (VMCI) model. Initially, VMCI was meant to allow for direct VM to VM communication without the need for conventional TCP networking. In new versions of VMCI the intention is just to allow for secure communication between the host and the VM. The main purpose of this driver is to allow for scanning of the VM’s virtual disk via the third-party vendors appliance. This driver is no long distributed along side the download for vShield (as it was in vShield 1.0) as its now included in VMware Tools.

The end-point driver is called vsepflt.sys is a File System Filter Driver (FSFD) and does not run as service. If you want to check that it is installed and present you can use “fltmc” to confirm it is loaded. This FSFD uses VMCI to speak to the ESX module inside the hypervisor – and the ESX module is silently installed in turn by using the vShield Management Console to all the hosts that will support vShield Endpoint functionality.

Endpoint-6.jpg

Note: fltmc shows that the vsepflt.sys drive has been loaded into the guest operating system.

Setting Up the vShield Appliance

Importing the vShield OVA File

The setup of vShield begins with downloading the single .OVA file that contains the appliance itself. Once download it can be imported into vCenter, and set to run on your chosen VMware Cluster.

Each component of vShield needs to be installed – and sadly there is not a “bulk method” to do this at a cluster level which is a shame. It is possible to automate a great deal of the vShield configuration. That’s something we have chosen not to document in this instance. However, if its matter that’s of interest to you we would recommend checking out two blog post from PowerCLI supremo and VMware employee, Alan Renaud:

http://www.virtu-al.net/2012/01/04/vmware-vshield-powershell-module/

This introductory post to separate posts:

http://www.virtu-al.net/2011/09/14/powershell-automated-install-of-vshield-5/

http://www.virtu-al.net/2011/09/30/automated-install-of-vshield-services/

1. From within vCenter, select File and Deploy OVF template

2. Browse to locate the OVA file in our case called “VMware-vShield-Manager-5.0.0-473791.ova”. You build number is likely to vary

3. Click Next to accept the description

4. Click Next to accept the EULA

5. Set the vShield Manger name for the vCenter Inventory and folder location – in our case we place the manager in the “Infrastructure” folder.

Endpoint-7.jpg

6. Next select a cluster and/or a resource pool for the appliance to reside

Endpoint-8.jpg

7. Next select a datastore to hold the appliances virtual disks

8. Next select a type of virtual disk

9. Finally, select an appropriate portgroup on a virtual switch for the appliance – remember that the appliance needs to communicate to vCenter and the ESX hosts

Endpoint-9.jpg

Configure IP Settings

Once the appliance has booted you can configure its network settings fit for your environment. After the boot process you will be challenged for the “admin” login together with its default password. Once authenticated you switch to “enable” mode with its default password that allows you to run the core setup routine.

1. Open a console window to the vShield Manager, and login as “admin” with the password of “default”

2. Next type the string “enable” and supply the password at the prompt which is “default”

Endpoint-10.jpg

Note: If you can’t login with the default password chances are you experiencing some latency or keyboard repeat on your console session. This happens particularly when you’re connecting remotely to vSphere environment over say a Microsoft RDP link. Consult KB196 for changing the default keyboard repeat values for console sessions.

3. Next type the command “setup” to run the network setup wizard

4. Next configure your IP settings relative your management network

Endpoint-11.jpg

5. This will leave you with somewhat odd report that the management NIC is up, and if you press [ENTER] will return you to the Manager# prompt. You can logout using the command “exit” – and either log back in a ping the router/default gateway – or better still confirm you can ping the appliance from your management PC.

Register with vCenter; Reset Password; License

The next step is using the web-based management front-end of vShield – login as admin and default, and configure vShield to be aware of your vCenter environment.

1. Open a web-browser session and type http://a.b.c.d where a.b.c.d was the static IP address you configured earlier

2. Login to the vShield using “admin” and “default” as the username and password respectively

Endpoint-12.jpg

3. After the login you should be transitioned to the “Settings and Reports” page, where you input your vCenter credentials. We recommend NOT using the “administrator” account, but instead establish a system of authentication specifically created for vShield itself.

Endpoint-13.jpg

4. Click Save, will cause vShield to communicate to vCenter – and you should be confronted with an SSL Thumbprint dialog box, if you are using the built-in certificates from vCenter.

5. You can use the “Register” button to add the vShield Plug-in to vCenter – this allows you do 99% of your administration tasks directly from vSphere.

Endpoint-14.jpg

This should generate a plug-in SSL dialog box which is typical of newly enable vSphere Client plug-ins. You can enable the option to “Install this certificate and do not display any security warnings for your IP” and click Ignore. Unless of course, you’re Edward Haletky who never accepts any unsigned or untrusted certificate.

This adds a vShields icon to the “Solutions and Applications” section of the vSphere Client and opens the web-interface of vShield into the vSphere Client. It also enables a tab within vCenter on each cluster and ESX host that allows you to see the status of the vShield components and install the vShield components to the ESX hosts.

Endpoint-15.jpg

Note: Here the “Service VM” is the vShield Manager appliance itself.

6. Once configured for vCenter – the web-interface should be able to enumerate your inventory from vCenter like so:

Endpoint-16.jpg

7. Finally, you can reset the password for the “admin” account within the “users” tab. Running a security appliance with a known user accounts with password in the public domain isn’t not perhaps a wise management decision – so change the password at the earliest opportunity

Endpoint-17.jpg

8. By default vShield will run for 60-days in an evaluation mode with some scalability limits imposed (limited to protection 100 VMs). After 60-day period expires the appliance will no longer power on vShield App or Edge appliances or protect VMs. The licensing of vShield is managed from the very same “licensing” interface in vSphere that is used to license – ESX, vCenter and technologies such as VMware Site Recovery Manager.

Endpoint-18.jpg

vShield is licensed to protect a certain number of VMs, and most of the third-party vendors have followed suit – although some do still license their technology on a per-CPU basis. vShield is bundled with number of SKUs such as View Premier, and some of the OEM partners have the rights to resell vShield alongside their own components. It really varies from one OEM partner to another.

Installing vShield Endpoint to the ESX host

The next stage is installing the vShield “Host Driver” – this component sits inside the ESX host and interacts with the VMKernel hypervisor.

1. In vCenter select the ESX host, and select the vShield Tab. When you do this you will notice that it takes sometime to open the tab, as instructions are sent to the ESX host open firewall ports, carry out a scan for information – and then close the firewall ports on the ESX host:

Endpoint-19.jpg

2. Next click the “Install” link for vShield Endpoint

Endpoint-20.jpg

3. vShield will scan the host, leaving you with another “Install” button to commit the change to the ESX host.

Endpoint-21.jpg

Note: When you do this – you will seen a number of “Please Wait” messages that will come, and go and then come back again. Do not be alarmed. All is well.

Endpoint-22.jpg

And as this happens – you will see events taking place in the Taskbar of the vSphere Client:

Endpoint-23.jpg

4. At the end of the installation this status should change as can be seen below:

Endpoint-24.jpg

You should also see that the vShield has created the vmservice-vswitch in the Standard vSwitches view…

Endpoint-25.jpg

This configuration of vShield opens ports 48651 to 48666 on the ESX host firewall. Two rules are created one called “vShield-Endpoint-Mux” which covers these ports and enabled by default, and one called “vShield-Endpoint-Mux-Partners” which is disabled and be enabled by third-parties to install additional components to the ESX host if needed. The internal switch is used by the Partner’s SVA to allow it to communicate to the user world components and on to the VMs.

BitDefender Security 1.2 for Virtualized Environments

Introduction

Bitdefender Security for Virtualized Environments (or SVE for short) is integrated to VMware vShield. It comes as two components – the management virtual appliance called the SVE “Security Console” and with “Security Virtual Appliance” (SVA). There is one Security Console which manages the system overall and allows you to deploy the SVA to as many ESX hosts as you require. The Security Console includes an “Update Server” component this handles all the upgrade and signature updates. In contrast the SVA handles the scanning and protection of the VMs on each ESX host to which it is deployed.

Bitdefender supports Windows, Linux and Solaris – although at the time of writing support for Solaris has yet to be released. There is also support for an optional Bitdefender “Silent Agent” that can be installed to any VM or virtual desktop giving uses access to protection status as well as a “quarantine manager”.

Import BitDefender (SVE) Security Console

WARNING: Currently Internet Explorer mishandles .OVA files. The .OVA format is in fact a .TAR zip format. Internet Explorer recognizes that the file is of an archive format, and automatically renames the file extension from .OVA to .TAR. To resolve this issue simply rename the extension. At the time of writing we understand that only Internet Explorer treats .OVA files in this way.

In our case we contacted BitDefender to gain access to their implementation. We cannot speak for how other vendors work with vShield as this is merely an introduction to the process. With the BitDefender it ships as an .OVA that needs to be imported into vCenter – and process is very similar to import of the vShield .OVA.

There aren’t special requirements to be met during the import process but needless to say it should be on your management network so it can communicate to the vShield environment. Once powered on the appliance has look and feel that is very similar to an ESXi host:

Endpoint-26.jpg

The root account has a password of “sve” and this should be changed at the earliest opportunity. Press [F2] to configure the appliance – with a static IP address (optional)

Post-configuration of BitDefender SVE is carried out at web-interface – and after accepting the EULA, you can configure vCenter hostname or IP, vShield Hostname or IP together with your license key – which is provided in PDF file generated for your evaluation.

Endpoint-27.jpg

Note: If you are evaluating BitDefender you should find the license key is inside the .PDF file sent with your evaluation.

Once configured the browser will be switched to the “login” page where you can supply your login credentials used with the vCenter:

Endpoint-28.jpg

Deploy Bitdefender SVE Security Virtual Appliances (SVA) to each ESX host

Now we have the management console of BitDefender configured we can set about deploying the Security Virtual Appliances (SVAs) to the ESX hosts where our VMs reside.

1. From the Computers menu, select the Security VMs option

Endpoint-29.jpg

2. Next click the “Deploy” button

Endpoint-30.jpg

3. Select your VMware Cluster(s) from the interface like so:

Endpoint-31.jpg

Note: The UI here allows you to configure each ESX hosts SVA, and then once completed you can hit the deploy button for each host.

Once the ESX host has been selected then its deployment options will appear on the left-hand side. Each SVA is given an unique name which is a combination of “Bitdefender SVE SVA (ESX Host’s FQDN). From the pull-down list you can select which datastore it will reside on – in our case we created a dedicated datastore called “BitDefenderSVA” to hold the appliance. We also decided to use thin-provisioning for the VMDKs.

The consolidation, memory and CPUs options all control the workload the SVA expects to take, and virtual resources allocated to deal with them. There are four options under consolidation (Low, Medium, High and Manual). Each option allocates more and more resources to the SVA based on the rate of consolidation you expect in your environment per ESX host. “Low” as assume you have around 0-24 virtual desktops and 0-2 server-based VMs whereas “High” – assumes you have 50 or more virtual desktops, and 8 or more server-based VMs. Obliviously “Custom” allows you to manual set your own preferences. Whereas “Low” allocation 2GB of RAM to the appliance, and two vCPUs – the “high” option allocates 4GB of RAM and 6 vCPUs.

We patched our appliances into the default VM portgroup of “VM Network” which we use for management traffic – and in our case allowed the appliances to use DHCP. The interface here does allow for the use of static IP address if you require them. As the UI explains if you are using DHCP it is recommend that you use static MAC address on each appliance, and reserve those MAC addresses to use IP addresses from your DHCP scope. The appliance should automatically pick up on the vShield portgroup created by the install and configuration of the vShield Manager. Finally, in this release BitDefender added the requirement to configure a “Deploy Container” or in other words a VM Folder. You must select a VM Folder in the vCenter inventory for the appliance to deploy.

As you deploy each appliance the status page updates to show the deployment progress..

Endpoint-32.jpg

At the end of this deployment phase you should have one Security Console (used to deploy the SVA and manage the solutions) and what ever number of SVA’s dependent on the size and numbers of your clusters:

Endpoint-33.jpg

Note: As you can see at the end of the process the result is that we end-up with a SVA for each ESX host. As part of the deployment process each SVA is disabled for HA, DRS and VMotion to ensure it remains on the ESX host at all times. As for maintenance mode – if you do use it VMware will evacuate all the VMs from the ESX host leaving the SVA powered on. If you gracefully shutdown the SVA on the host, maintenance mode will eventually complete.

Install the BitDefender “Thin Agent” aka Silent Agent” [Optional for Windows]

There are two ways of installing the Silent Agent – either manually or via the virtual appliance itself.

Manual Installation

The “Silent” Agent is downloadable from the Security Console web-pages under the download section. This optional component installs into the virtual desktop and gives the end-user a UI for monitoring their AV status – giving the users a reassurance that they are protected, and pop-up messages if a virus is discovered. If you are protecting Linux and Solaris this Silent Agent is mandatory. The Silent Agent in Windows also enables memory and process Scan tasks on VMs.

In future releases it is likely that this component will have the option of being installed silently into the guest operating system. Currently the “Silent Agent” can be downloaded and manually installed from the “Downloads” option on the Security Console web-pages.

Endpoint-34.jpg

During the install of the “Silent Agent” the setup program will recommend that the administrator turn of Microsoft Windows Defender.

Endpoint-35.jpg

We would recommend installing the “Silent Agent” into your templates or parent VMs for linked clones to make it part of your default build. You will also find there is a “Quarantine Tool” that can be installed as well. The installation of these components allows the system to scan processes running in the memory of the virtual desktops, and allows users to see status of their protection; view scans being performed; and allows them to take actions on detected threats.

The Silent Agent installs as .MSI and adds a shortcut to the desktop as well as the “B” icon in the taskbar tray. When launched it opens as console that allows the user to confirm they are protected. The “Quarantine Tool” is a stand-alone .EXE which can be downloaded and shortcut created if necessary. We found that Internet Explorer reacted negatively to its download and thought it was itself a suspect .EXE. We would recommend downloading it on behalf of the user and incorporating it into your template or parent VM.

Endpoint-36.jpg

Of course you will be keen to test if the anti-virus protection is in place. The easiest way do that is to use the “EICAR Test AV File” – this is a text file which contains a string that identifies itself as a virus AV software. It can be download from the eircar.org website here:

http://www.eicar.org/85-0-Download.html

Once downloaded and executed the AV should scan the file and identify it as virus:

Endpoint-37.jpg

Silent Deploy of the Silent Agent:

In the context of virtual desktops we feel the most efficient way to install or upgrade the Silent Agent is by incorporating it into your templates or ParentVM. Of course that might not address every requirement. For example if you run dedicated desktops or you want to deploy the agent other systems such as your View Infrastructure servers. For these reason and usage cases you can use the new silent tasks feature in BitDefender SVA to remotely install the agent to the VMs required. There are a number of perquisite’s that must be met first including:

• You must provide the administrative credentials required for authentication on VMs

• Make sure VMware Tools 8.6.0 build 446312 or newer is installed on VMs (including those running on Linux or Solaris) with the Endpoint Driver installed. If not BitDefender will report that the “Thin Agent” is not installed. Remember “Thin Agent” is how some vendors refer to the Endpoint Driver

• Windows User Account Control must be disabled

UAC can be disabled via group policy settings. These are located in n the Group Policy Editor window, in the Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. To disable UAC you need to disable four policy settings in total:

• User Account Control: Behaviour of the elevation prompt for administrators in Admin Approval Mode - Set its value to Elevate without prompting.

• User Account Control: Detect application installations and prompt for elevation - Set its value to Disabled.

• User Account Control: Only elevate UIAccess applications that are installed in secure locations - Set its value to Disabled.

• User Account Control: Run all administrators in Admin Approval Mode - Set its value to Disabled.

Endpoint-38.jpg

To install the silent agent from the BitDefender appliance follow these steps:

1. Select Task in the main menu, and New Task

2. Type in a friendly name for the new task, and select from the pull-down list to option called “Silent Deploy”

Endpoint-39.jpg

3. The Apply option with the “Chose” link allows the administrator to control the scope of the installation:

Endpoint-40.jpg

4. Similarly the Credentials option allows you to add and save a user account to carry out the installation:

Endpoint-41.jpg

5. Once configured you can Save the task and commit it to the BitDefender Appliance

Endpoint-42.jpg

Conclusions

As you can see vShield is very easy to setup and configure – and by relocating the functions of AV out of the guest operating system it affords for great control over the impact of this process. Remember though that vShield itself is not “free”. You need resources to run each of the appliances (SVA) as well at the two or more management consoles. We estimate that you would need to get significant density of VMs to ESX host to both offset the license and resource costs when compared to traditional methods of managing AV. Consider also that introducing new method of AV is yet another set of changes on what be already a radical departure from the existing model of delivering desktops.

Finally, you might want to review your current methods for patching and updating ESX hosts. As you might recall the virtual appliances that make up a vShield deployment are patch to “internal” standard switches on each hosts. Any VM configured to such a type of vSwitch is not open for vMotion. So if you used to using VMware’s Update Manager to automatically remediate host then maintenance mode with fully-automated DRS cluster will not work as expected. You will find maintenance mode will get “stuck” at 2% because vMotion cannot move the SVA to another host. The simplest way to deal with this is shutdown the SVA once all the other VMs have been migrated to other ESX hosts in the cluster. Do not be tempted to power down the SVA prior to carrying out maintenance mode, as this will leave your VMs in an unprotected state. If the SVA is powered down before the VMs its protecting then technically they are in an unprotected state. In the case of BitDefender the Silent Agent will report the VM is not protected.

Endpoint-43.jpg

and this will trigger a customer BitDefender SVE SVA Alarm in the vCenter inventory.

Endpoint-44.jpg

So this raises an important dependency issue. Once your AV is dependent on the appliance ensuring this appliance is only powered off in a controlled way is imperative. Additionally, when an ESX host is brought out of maintenance mode the first VM that should be powered on is the SVA before any other VMs are powered on.

Our next chapter concerns using PowerCLI with VMware View to automate many of the administration tasks carried out within the product. You can see it as “command-line” approach to popular management tasks. If this isn’t of interest we have two more chapters that might. We have a chapter on getting started with VMware ThinApp which has integration points into VMware View, and we also have chapter about some of the end-user computing initiatives that VMware will be bringing to market throughout 2012.