IMPORTANT ANNOUNCEMENT: On May 6, 2024, Carbon Black User eXchange (UeX) and Case Management will move to a new platform!
The Community will be in read-only mode starting April 19th, 7:00 AM PDT. Check out the blog post!
You will still be able to use the case portal to create and interact with your support cases until the transition, view more information here!

Carbon Black Cloud: How to Use RepCLI to Prepare Non-Persistent VDI Clones

Carbon Black Cloud: How to Use RepCLI to Prepare Non-Persistent VDI Clones

Environment

  • Carbon Black Cloud Console: December '18 Release and Later
  • Carbon Black Cloud Sensor: Version 3.4.x.x and Higher
  • Non-Persistent VDI clones
  • RepCLI authentication is enabled

Objective

Use RepCLI to prepare images that will be used to clone non-persistent VDIs

Resolution

    1. Install the primary image OS and required applications
    2. Install the Carbon Black Cloud Sensor with CLI_USERS switch to ensure RepCLI Authentication is enabled
    3. If Background Scan or Local Scanner are disabled, please skip to Step 4
      1. Verify that Background Scan has completed and Policy has updated. See Monitor Background Scan Status with RepCLI
      2. Verify that virus signature files have been updated to the latest using RepCLI. See Endpoint Standard: How to Update Virus Definition Files With RepCLI
    4. As the final preparation step, schedule the command "repcli reregister now" to run on the clones, not on the "primary/golden" image, ideally as a scheduled task (or GPO) upon login OR restart, preferably from a batch file, and a five-minute delay if scheduled at bootup, change "Primary" with the computer name of the master machine. Use 79180_CB.bat which can be downloaded from VMware Knowledge Base
    NOTE: Do not run commands repcli reregister now or repcli reregister onrestart 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 deregister devices. Keeping this capability off will ensure no persistent full clones get auto-deregistered.
     
    1. Shut down the machine
    NOTE: By default, every newly installed sensor is assigned to the Standard policy unless otherwise specified See Carbon Black Cloud: How to Perform an Unattended Installation of the Windows Sensor. The endpoint inherits the policy from the primary image unless you have previously created sensor groups, and the installed sensor matches a sensor group’s criteria. Manual policy assignment post-installation overrides the inheritance. If GROUP_NAME or POLICY_NAME was used to install the primary image OS into a specific VDI policy (e.g. VDI Standard), move the primary image OS to a separate policy (e.g. Standard).
    NOTE: Disable Local Scanner and Background Scan on the specified VDI policy (e.g. VDI Standard) to be used for non-persistent VDI endpoints. Persistent VDI endpoints also should be managed in a separate policy.
     
    1. Create the primary image/VM template
    2. Deployed clones will register as separate devices and be assigned a new device ID at boot
    3. To create a new template, repeat steps 4-6.

    Additional Notes

    • WARNING: If VDI=1 was used and the sensor is uninstalled from the primary image, cloned VDI will fail to register and display within the Carbon Black Cloud Console. VDI=1 has been deprecated in favor of "repcli.exe register now" in sensor versions 3.4.x and Higher and is no longer supported for use in these versions. 
    • For non-persistent deployments leveraging Horizon version 7.13, 2012, and later versions, and Carbon Black Cloud sensor version 3.6+, you must remove the batch file (example batch file path: C:\CB.bat) inserted into the golden image previously. This is possible because the registry of HKLM\Software\VMware, Inc.\ViewComposer\ga\AgentIntegration is now automatically set by the the Instant Clone Agent. See Interoperability of VMware Carbon Black and Horizon for details
    • Step 4 should only be RUN ONCE per cloned device, and not on every logon or bootup 
    • This steps are not intended for image deployment of physical machines, for that, use the BASE_IMAGE=1 parameter instead
    • RepCLI authentication/authorization is not tied to any OS-side permissions, the SID could be that of a normal user with no admin permissions and they would still be able to use RepCLI functions requiring authentication. See CB Defense: Does the logged in user or system account need to be configured for repcli auth?
    • If C:\temp\cb_reregister.txt is not present on a clone, the command did not run successfully

    Related Content


    Was this article helpful? Yes No
    67% helpful (2/3)
    Article Information
    Author:
    Creation Date:
    ‎12-21-2018
    Views:
    7709
    Contributors