Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

Interoperability of VMware Carbon Black and Horizon (79180)

Last Updated: 12/28/2023Categories: InformationalTotal Views: 9412Language:
JapaneseEnglish

24 like this article

Subscribe to get an email
newsletter with new updates

24 people found this helpful Please provide article feedback:

Details

This article provides the approaches to deploying VMware Carbon Black sensor with Horizon VDI and RDSH.

Note: Horizon support for Carbon Black varies by clone type.

Horizon full clones are supported at GA capacity.

Horizon instant clones 7.12 and Horizon 2006 with 3.5 and later sensors are supported at Preview capacity.

Horizon instant clones 7.13, Horizon 2012 or later, with Carbon Black 3.6 sensor or later are supported at GA capacity

Important: We recommend you migrate from Horizon 7 to Horizon 8 as soon as possible. Horizon 8 offers numerous improvements in performance, scale, and experience for both Administrators and end users. Please see Ensuring a successful migration from Horizon 7 to Horizon 8 (89840)  for additional advice.

Solution

Pre-Requisites

Before installing the Carbon Black Cloud Sensor, ensure that you are following standard Horizon best practices, including optimizing the golden image.  For more information, see Creating an Optimized Windows Image for a VMware Horizon Virtual Desktop & Horizon View Best Practices: Parent Image Creation and Maintenance. (90152)

Ensure that the versions of Carbon Black Sensor and Horizon you are using are compatible and supported.  For information, see the VMware Interoperability Matrix.

Horizon Persistent VM Pools (Full Clone Desktop Pools) - GA Support

For Horizon full clone desktops to interact with the Carbon Black administrative console, a sensor needs to be installed on the full clone desktop VMs. There are two different approaches to deploy:

Approach #1: Install the Sensor in the Golden Image

This approach is recommended in environments entirely comprised of full-clone VMs.

Setup Steps

Create the Golden Image for the full clone pool deployment.  As per the Horizon documentation, perform the required steps including installing VMTools and Horizon Agent.

Install the sensor with the BASE_IMAGE and CLI_USERS parameters to ensure RepCLI authentication works using this command:

msiexec.exe /q /i <Sensor Installer Path> /L* msi.log COMPANY_CODE="XYZABC" CLI_USERS=sid BASE_IMAGE=1 GROUP_NAME="<NAME Virtual Policy>"

This registers the golden image VM to CBC console.

Where:

CLI_USERS: This parameter on the golden image enables REPCLI usage on the clones. The value is the Security Identifier (SID) of the user account/group that will run repcli commands on the clone.

Sensor Installer Path: Mention the path where the sensor is placed in the VM

GROUP_NAME: Mention the Policy Name which has the necessary exclusions are applied to the policy. Virtual Desktops policy would be adopted (or Standard if the Virtual Desktops policy does not exist).

(Optional) Perform the Background Scan on the golden image.

(Optional) Run this command to update the device signature of the golden image.

Repcli updateAVSignature

Shut down the golden image and convert the golden image into the template VM.

Create a full clone pool with the golden VMTemplate in Horizon Console.

Newly cloned VMs (full clones) will be registered with a new device ID within the Carbon Black Cloud (CBC) Console once the pool comes to an available state.

Ensure that the golden image never registers as a clone or gets de-registered.

Note: Do not run commands repcli reregister now or repcli reregister on a restart on the golden image. Either command turns the golden image into a clone, which might de-register other pre-existing clones because they become orphans. Also, do not enable auto-cleanup of deregistered devices. Keeping this capability off will ensure no persistent full clones get auto-deregistered.

Approach #2: Install Sensor using Customization Spec’s Run Once option

This approach is recommended in environments comprised of a combination of full clone and instant clone VMs.

Setup Steps

Create the Golden Image for the full clone pool deployment.  As per the Horizon documentation, perform the required steps including installing VMTools and Horizon Agent.

Do not run the installer on the golden image.

Place the Sensor MSI for installation on the golden image (preferably System Root Directory).

Prepare the customization spec to be used for creating the full clone pool.

Place the Sensor installation command in the Customization Specification Commands to run once the option is in the customization spec.

Use this command for deployment that can be placed in the customization spec:

msiexec.exe /q /i <Sensor Installer Path > /L* msi.log COMPANY_CODE="XYZABC" CLI_USERS=sid GROUP_NAME="<NAME Virtual Policy>"

Deploy the full clone pool from the golden image VMTemplate with the customization spec created above. This will ensure the Sensor Installation happens on each of the newly cloned VM.

Only the cloned VMs are registered to the Carbon Black Cloud (CBC) Console. The golden image is not registered with the CBC Console (since the Sensor Isn't Installed In the golden image VM).

Background scan Is done on each cloned VM in the pool after the pool Is provisioned if dictated by Carbon Black Cloud Policy. Depending on how many VMs are placed per host, the background scan could lead to performance degradation.

Sensor settings to de-register inactive VDI machines should be enabled, for operational and management benefits about the instant clone VDI machines in a mixed environment. In the CBC console, navigate to Endpoints > Sensor Options > Sensor Settings.

Delete sensors that have been deregistered for

Deregister VDI sensors that have been inactive for

Enable the options and set the timeframe. This will ensure auto clean-up of the inactive, de-registered VMs in the CBC.

Update Signature setting should be enabled on the Assign Policy > Local Scan > Signature Update.

Comparison between Approach #1 and #2

Approach #1 is optimal for utilization in a purely persistent (Full Clone Desktop Pool) environment. This method allows for auto-installation of the CBC sensor on all clones, without the need for any post-installation script. This approach does designate the clones as VDI to the CBC backend, thus the logistical constraints of requiring the “Virtual Desktops” policy, and prohibiting the use of sensor- settings' auto-deregister capability, exist as a trade-off for the ease of deployment garnered by said approach.

Approach #1 lists background scan and AV signature pack as optional (steps 3 & 4 above), but recommended. Running the background scan, and pulling the AV signature pack to the golden image allows for auto-duplication of the reputation cache to the subsequent clones, and therefore optimizes performance on those systems. However, it is important to note, that to receive said performance benefits the background scan must be completed on the golden image, before shutting down the golden image; otherwise, the background scan will run on each clone once provisioned, or not at all, if dictated by policy.

Approach #2 is optimal for utilization in a mixed full clone and instant clone environment. This method allows for each full clone to be installed post-provisioning of said clone, thus not restricting the said system to VDI constraints. Ultimately, this lack of restriction allows for proper management of the instant clones, both through the utilization of the sensor-settings auto-cleanup and multiple policies, in conjunction with full clones which would not be subject to the auto-clean-up, and can be placed in their policy, independent of the instant clones

Approach #2 requires that a different golden image is being utilized for the full clone pool than for the instant clone pool.

Horizon Non-Persistent VMs (Instant Clone VDI Pools and RDSH Farms) - Preview Support for Horizon instant clones 7.12 and 2006 with Carbon Black 3.5 or later sensor

The following is written specifically for an instant clone pool, the same guidelines apply to instant clone farms.

In order for Horizon Instant Clone VDI desktops to interact with the CBC Console, a Sensor needs to be installed on the Instant Clones. Be sure to test the performance impact of Carbon Black with Instant Clone, specifically for initial deployment of the instant clone pool, before production deployment.
For this combination, Horizon instant clone and Carbon Black are supported on in a Preview capacity, due to known limitations.  See next section for more details.

Setup Steps

Create the golden image for the instant clone pool deployment. As per Horizon documentation, perform required Windows update and install the required VMTools and Horizon Agent.

Install the sensor in the golden image using this command:

msiexec.exe /q /i <Sensor Installer Path> /L* msi.log COMPANY_CODE="XYZABC" CLI_USERS=sid GROUP_NAME="<NAME Virtual Policy>"

Where:
CLI_USERS: This parameter on the golden image enables REPCLI usage on the clones. The value is the Security Identifier (SID) of the user account/group that will run the reregister now command on the clone.
Sensor Installer Path: Mention the path where sensor is placed in the VM
GROUP_NAME: Mention the Policy Name which has the necessary exclusions applied to the policy. Virtual Desktops policy would be adopted (or Standard if the Virtual Desktops policy does not exist).

This will register the golden image to CBC console with the new device ID.

Perform a background scan on the golden image and take a snapshot once the scan is completed. Golden Image will be placed under a policy on the CBC console different from the cloned Instant clones.
Create a separate policy on the CBC console where the background scan is disabled. The cloned Instant Clones will be placed matching the condition under this separate endpoint policy where the background scan is disabled. Best practices recommend against running a background scan or having a local AV signature pack on subsequent clones; to optimize operational workflow, and resource optimization on those systems, see Carbon Black Cloud Sensor Install Guide for further details.

See How To Run A Background Scan In a Non-Persistent VDI Environment for alternative configurations

Place the attached 79180_CB.bat (Batch) file to run the re-registration command of the sensor on the golden image.

Note: Update ‘MASTER’ in the script to the hostname of the corresponding golden image in step 3.

Take a snapshot of the golden image.

Create an instant clone pool with the golden image and snapshot in the Horizon Console.

Provide the path in Post Synchronization script (batch file path. For example: C:\CB.bat).

Once the pool becomes available in Horizon Console, check that the newly created instant clones have registered with new Device ID in the CBC console.

Note:

If the Post Synchronization script runs before the repcli port is available, which is a requirement for running the ‘repcli reregister now’ command to ensure clone uniqueness, then duplication of device IDs may ensue. Prevention on those systems should function as expected but might inhibit proper event attribution to the expected clone.

The golden of the instant clone pool may change the device name within the CBC console to reflect the internal template or replica. The golden image will still maintain a unique device ID. Therefore, this does not pose any functional issues but rather observed behaviour to be aware of in the current management of Instant Clones within the CBC Console.

Sensor settings to de-register inactive VDI machines should be enabled. In the CBC console, navigate to Endpoints > Sensor Options > Sensor Settings.

Delete sensors that have been de-registered for

Deregister VDI sensors that have been inactive for

Enable the options and set the timeframe. This will ensure auto clean-up of the inactive, de-registered VMs in the CBC. Instant clones get refreshed (deleted and re-created from the most up-to-date golden image) either when a user logs out of their instant clone desktop or other specified times (depending on the setting). Enabling this setting within the CBC console will help augment manageability of instant clones, and allow for the ability to distinguish those clones which have been refreshed, against those which are active.

Expected Limitation and Mitigation:

During the instant clone pool creation, a temporary full clone of the golden image known as the “internal template” (with a device name `itXXXXXX`) powers on and has network access, at which point the CBC sensor on that internal template device is likely to connect to the CBC backend with the same device ID as the golden image. This results in the golden image being overwritten by the `it` device in the CBC console. If and when the golden image is powered on, the sensor on the golden image re-connects to the backend, again overwriting the `it` device. In addition to the duplicate devices overwriting each other’s data on the backend, this can also lead to the backend sending a re-register request to the golden image, which causes the golden image to be considered a VDI by the backend, which then could cause the golden image to de-register due to inactivity. The duplicate device scenario can also expose a group membership bug where the golden image is no longer in the expected policy group. The negative implications of the “internal template” having the duplicate device id as the golden image are:

The IT’s events and activity could be intermingled with the golden images

The golden image’s device name in the console might flip flop based on whether it was the golden image or IT that was powered on last

If using MSM to assign device policy by device name, take caution to ensure golden image and IT names are accounted for.

The recommendation for the customers is to deploy the instant clone with the golden image powered off, to avoid the effect of the above negative implications on the golden image. This recommendation will not eliminate the internal template duplicate device id scenario, but will mitigate the downside of having duplicate device ID.

Provisioning of instant clones with the setting “Provision all machines up front”, will likely have a measurable increase in CPU utilization on the hosts and the provisioning clones during the initial provisioning operation. This is a result of additional load incurred due to the Carbon Black sensor registration happening on all the provisioning instant clone at the same time, thus creating a performance bottleneck. However, provisioning of instant clones with the setting “Provision machines on demand”, will less likely see any increase in CPU utilization because the instant clones are provisioned at different times, thus avoiding the bottleneck. As a result of higher CPU load, during initial instant clone provisioning the customization might timeout for the clones while executing the post-synchronization batch file causing number of clones in error state. This is due to the 20 seconds timeout limit for executing the post synchronization scripts on the clones, but the failed clones will auto recover. The 20 seconds default timeout of the Post Synchronization script can be adjusted using the below registry key in the golden image as a simple workaround for this problem. This will reduce the instant clones provisioning failure rate. Max suggested value being 120000ms

HKLM\System\CCS\Services\vmware-viewcomposer-ga
Type: DWORD
Value Name: ExecScriptTimeout
Units: milliseconds
Sample:
##Updated timeout value from 20000 to 120000 .
HKLM\System\CCS\Services\vmware-viewcomposer-ga
Type: DWORD
Value Name: ExecScriptTimeout
Units: 120000

To Obtain Production Support for Instant Clone with Horizon 7.12/Horizon 2006 and/or Carbon Black sensor 3.5 or earlier releases:

Given the expectation of limitation of running Horizon Instant Clone, if you still desire production support for this use case, work with your VMware sales representative to file a RPQ.

Horizon Non Persistent VMs (Instant Clone VDI Pools and RDSH Farms)- GA Support for Horizon instant clone 7.13 and 2012 or later with Carbon Black 3.6 or later sensor

The following is written specifically for an instant clone pool, the same guidelines apply to instant clone farms.

With combined changes made in Horizon 7.13 and Carbon Black 3.6 sensor, the previous approach of using post-synchronization script is no longer necessary.  The Instant Clone agent will set the following registry value to a unique GUID when IT/replica/clone nga customization begins.  Therefore, each clone will have a unique value here.

Key: HKLM\Software\VMware, Inc.\ViewComposer\ga\AgentIntegration
Type: REG_SZ
Value: CustomizationStarted

And with that, we now support Horizon instant clones and Carbon Black at the GA level. For those customers upgrading to Horizon 7.13 from a previous Horizon version, you must remove the batch file (example batch file path: C:\CB.bat)  inserted into the golden image previously

Setup Steps:

Create the golden image for the instant clone pool deployment. As per Horizon documentation, perform the required Windows update and install the required VMTools and Horizon Agent.

Install the sensor in the golden image using this command:

msiexec.exe /q /i <Sensor Installer Path> /L* msi.log COMPANY_CODE="XYZABC" CLI_USERS= <User or Group SID>GROUP_NAME="<NAME Virtual Policy>"

This will register the golden image to CBC console with the new device ID.

Perform background scan on the golden image and take the snapshot once the scan is completed. Golden Image will be placed under a policy on the CBC console different from the cloned Instant clones.
Create a separate policy on CBC console where the background scan is disabled. The cloned Instant Clones will be placed matching the condition under this separate endpoint policy where the background scan is disabled. Best practices recommend against running a background scan or having a local av signature pack on subsequent clones; to optimize operational workflow, and resource optimization on those systems, see Carbon Black Cloud Sensor Install Guide for further details.

See How To Run A Background Scan In a Non-Persistent VDI Environment for alternative configurations

Create an instant clone pool with the golden image and snapshot in the Horizon Console

Once the pool becomes available in Horizon Console, check that the newly created instant clones and Internal template have registered with the new Device ID in the CBC console.

Note: You will still need to be aware of the section below to avoid the “internal template” (with a device name `itXXXXXX`) getting de-registered from the CBC console

Known Issue: During the instant clone pool creation, a full clone of the golden image known as the “internal template” (with a device name `itXXXXXX`) powers on and has network access, at which point the CBC sensor on that internal template device is likely to connect to the CBC backend with the same device ID as the golden image. This results in the golden image being overwritten by the `internal template` device in the CBC console.

With the best practices for the golden image to be powered off state, the internal template tends to de-register due to inactivity. With the de-registration of the internal template vm, clones provisioned would not get registered with CBC, because if the clones are children of a deregistered machine (in this case the internal template) then the backend won't authorize the clone to reregister since from the backend's perspective the parent was pruned and thus no operation is performed for the same.

The Horizon Instant Clones with Carbon Black Cloud, use policy-based auto-deregistration of inactive VDI to avoid Internal Template being de-registered

Resolution or Workaround: Keep the internal template in a CB policy without time-based deregistration.  In the Carbon Black Cloud console, associate Instant Clone devices with a Group that assigns a policy with auto-deregistration of inactive VDI enabled but does not enable auto-deregistration of inactive VDI in the policy assigned to the Golden Image.

Steps:

Create a group for the internal template VM based on their device names or any criteria and assign policy on the CBC console.

Assign policy (sensor settings for specific policy) to the internal template as "auto-deregister disabled"

Make the org level setting:

Deregister VDI sensors that have been inactive for as disabled.

Deploy the sensor in the golden image using the below command to register the golden image to the CBC console with the new device ID:

msiexec.exe /q /i <Sensor Installer Path> /L* msi.log COMPANY_CODE="XYZABC" CLI_USERS=sid GROUP_NAME="<NAME Virtual Policy>"

Where:

CLI_USERS: This parameter on the golden image enables REPCLI usage on the clones. The value is the Security Identifier (SID) of the user account/group that will run the reregister now command on the clone.

Sensor Installer Path: Mention the path where the sensor is placed in the VM

GROUP_NAME: Mention the Policy Name which has the necessary exclusions applied to the policy. Virtual Desktops policy would be adopted (or Standard if the Virtual Desktops policy does not exist).

Power off the golden image and take a snapshot. Create an instant clone pool with the golden image and the snapshot. Internally the sensor policy will get assigned based on the group which was created.

With these settings, the internal template system never gets de-registered even though it remains inactive, whereas the clones will get de-registered when they are inactive.

Related Information

For more information regarding Carbon Black, see:

CB Defense: How to Perform an Unattended Installation of the Windows Sensor

CB Defense: How to Get Started With RepCLI

CB Defense: How to Deploy Sensor to a Non-Persistent VDI Master Image

CB PSC: How to locate the PSC Sensor Install Guide

For information regarding advised exclusions in Horizon Products, see:

https://techzone.vmware.com/resource/antivirus-considerations-vmware-horizon-environment

Antivirus executable exclusion list for VMware Horizon View (2082045)

For information regarding Installation:

VDI Installation Guide

Best Practices on VDI

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
JapaneseEnglish

Attachments

79180_CB

Additional Resources

KB
•
Workspace ONE Content 3.22.1 for Android リリースのお知らせ (79224)

KB
•
VMware Intelligent Hub 20.04.1 for iOS リリースのお知らせ (79195)

KB
•
CRSVC-11528：「デバイス削除」などのデバイス管理操作が断続的に失敗する (79114)

KB
•
Workspace ONE SDK 20.4 for Android リリースのお知らせ (79124)

Results 1-4 of 4

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware Horizon

VMware Carbon Black

Related Versions:

Take Our Survey

Support Assistant