Deploying Carbon Black Cloud via GPO with a with a transform (MST) file fails with: “CAInstallPreCheck: Expect a cfg.ini in the same directory as the MSI, but could not find it.“

Problem

You’ve completed setting up Carbon Black Cloud to be deployed via GPO as described in one of my previous posts:

Deploying Carbon Black Cloud via GPO with a transform (MST) file specifying the Company Code and Group Name
http://terenceluk.blogspot.com/2021/04/deploying-carbon-black-cloud-via-gpo.html

But notice that it fails with the following event log errors:

Log Name: Application
Source: CbDefense
Event ID: 49
Level: Error

The description for Event ID 49 from source CbDefense cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

CbDefense

CAInstallPreCheck: Expect a cfg.ini in the same directory as the MSI, but could not find it.

Log Name: Application
Source: Application Management Group Policy
Event ID: 102
Level: Error

The install of application Carbon Black Cloud Sensor 64-bit from policy Test Carbon Black Cloud Install failed. The error was : %%1603

Solution

One of the reasons why this error would be thrown is if the COMPANY_CODE was missed when creating the transform file. Verify that both the COMPANY_CODE and GROUP_NAME exists in the transform file.

PowerShell script to check for installed software and run GPUpdate if the application is not installed

I’ve recently been asked to assist with troubleshooting an issue where remote users who VPN into the network remotely while working from home were not receiving an agent that is installed through Group Policy. Upon troubleshooting with a remote worker’s laptop, I realized that Group Policy had not been refreshed for over a month and simply executing a GPUpdate automatically installed the application. The client wanted to determine which remote devices did not have the application then proceed to run GPUpdate on them to install the application.

Many administrators will likely be familiar with the Group Policy Update… feature in the Group Policy Management Console, which automatically reaches out to all of the devices in the OU to initiate a Group Policy Update:

While this allowed us to force a GPUpdate on devices with ease, this did not provide a report on which device had the software so what I ended up doing was write a PowerShell script to accomplish this. The script reads a text file with a list of names separated by line breaks, attempts to ping the device and if it is reachable, it will attempt to determine whether it has the agent installed and if it isn’t, it would initiate a GPUpdate remotely. The result of whether it was reachable via PING, had the application installed, did not have the application installed, and not responding to the command to determine the application installed status would be written to a CSV file.

The script is provided below with the following parameters that can be adjusted:

$InventoryList > specify the text file containing the device names
$Software > Specify part of the name of the application that is being determined whether it is installed (in this example, it is anything with the word “Omni”)

Customize the $Output and Write-Host lines as required.

Note that the Invoke-GPUpdate PowerShell cmdlet will present a command prompt to the console of the remote device to initiate the GPUpdate.

The script:

$Output=@()

$InventoryList = Get-Content "C:\temp\InventoryList.txt"

$Software = "*Omni*"

ForEach ($Machine in $InventoryList -ne ''){

#Ping each machine found in text file

if (!(test-Connection -ComputerName $Machine -BufferSize 16 -Count 1 -ea 0 -Quiet))

{

$Output+= "$Machine,not reachable"

Write-Host "$Machine,not reachable" -ForegroundColor Red

}

Else

{

#Machine is reachable via Ping

#Checks installed programs for products that contain Omni in the name

Try {

$installed = Get-WmiObject -ComputerName $Machine -Class Win32_Product -ErrorAction Stop | sort-object Name |

Select-Object Name | Where-Object { $_.Name -like $Software}

If($installed) {

$Output+= "$Machine,Omni Installed"

Write-Host "$Machine,Omni Installed" -ForegroundColor Green

} else {

$Output+= "$Machine,Omni Not Installed"

Write-Host "$Machine,Omni Not Installed" -ForegroundColor Red

Invoke-GPUpdate -Computer $Machine -RandomDelayInMinutes 0}

# Write-Host "Invoting GPUpdate on $Machine" -ForegroundColor Red}

#EndofElse

}

Catch {

$Output+= "$Machine,Unable to check apps"

Write-Host "$Machine,Unable to check apps" -ForegroundColor Red

}

#EndofForEach

$Output | Out-file "InstalledSoftwareResult.csv"

}

}

Feel free to modify the script as needed for any purpose.

Configuring a GPO to permit a MMC snap-in that is not available in the list of "Restricted/Permitted snap-ins" provided by the default Microsoft Management Console policy setting

Problem

There are situations where an existing GPO is configured to restrict users from launching the MMC and the available snap-ins for non-administrative users to enhance security. To achieve this, an administrator can create a GPO with the following settings:

User Configuration > Administrative Templates > Windows Components > Microsoft Management Console > Restrict users to the explicitly permitted list of snap-ins: Enabled

Re-enabling select MMCs are fairly straight forward as a list of consoles are provided in the sub folder: Restricted/Permitted snap-ins

As the list provided in the default Group Policy ADM only includes default Windows Server snap-ins, attempting to add a MMC such as the following SQL Server 2919 Configuration Manager would become a problem:

Solution

There are two methods to address this issue. The first is to create a custom ADMX file and import it into Active Directory and the second is to apply the registry key that a custom ADMX would. This document serves to demonstrate the latter method as it is simpler for one-off configurations. To achieve this, we will need to create a GPO that will create a [HKCU]\Software\Policies\Microsoft\MMC\{MMC snap-in GUID} and set the Restrict_Run key to 0, which represents enable (1 is disabled):

Identify the custom MMC snap-in GUID

The first step is to identify the custom mmc snap-in GUID. For the purpose of this example, we will use the snap-in SQL Server 2919 Configuration Manager. Begin by navigating to:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\SnapIns\

Then locating and copying the custom snap-in’s GUID, which is the folder’s name:

{84a016c0-5617-4a05-ae8c-c806c5ff3e20}

Create a GPO with an update registry configuration

With the mmc snap-in GUID identified, proceed to create a GPO, navigate to User Configuration > Preferences > Windows Settings > Registry:

Create a registry configuration as such:

Action: Update
Hive: HKEY_CURRENT_USER
Key Path: Software\Policies\Microsoft\MMC\{84a016c0-5617-4a05-ae8c-c806c5ff3e20
Value name: Restrict_Run
Value type: REG_DWORD
Value data: 0

The policy should look as such once configured:

With the above policy created, have the user with this policy applied log off and back on to access the custom mmc snap-in.