On many occasions, I have had customers request the ability to request input from a user and then store the response for later use.  This could be to request input that will control passing input into a launched application, control which application to launch, or which data file to open.  However, this initial article will focus on providing a replacement for the "Collection Data Form" (CDF) that is used to request user input.  

The Built-in CDF with ZENworks can be used to present a GUI to collect data from users to be stored in the ZCM database.  The Built-in CDF can also be configured to silently harvest customer data from a managed device.  However, there is a significant limitation in which it is not possible to configure the CDF to do both.  Any attempt to silently collect data will always generate a user prompt.  This prevents the frequent collection of data in cases there is ever a need to also in some cases request user input.

This is where this custom solution comes into play.  Use this "CDF Alternative" to collect user input on-demand as required.  It can be scheduled to run automatically as any bundle can be scheduled or even launched manually by users.  The user input will then be stored on the device to be collected by the built-in CDF set to collect the data silently.  The "CDF Alternative" can even optionally initiate that collection.  CDFs can finally be used to both collect user input interactively as well as collect data silently.

The form above is created by a customer 'PowerShell' Script.  The script is designed so that it is easily customizable and self-formating so it can be used to meet a wide range of requirements.  The PowerShell Script has a separate section outside of the main code that is used to define most of the settings that will generate the form for ease of customization.

The form consists of the following user-definable components by default:

• Icon - By default, it is configured to use a built-in ZENworks Icon but can point to other icons.
• Form Title - "ZCM User Collection Data Form" 
• Four Labels - Each can be enabled or disabled.  The form will adjust in size based upon which ones are enabled.
• Three TextBox Fields - The form will adjust in size based upon which ones are enabled.  Masks can be used to control input.
• One Scrollbox - The form will adjust in size based on if this is enabled.

(Note: It should be simple to add additional items if required, by simply using the existing objects as a template.)

The form also contains the following settings:

• Controls the "Text" of the "OK" and "Cancel" Buttons.  Useful for other languages.
• Controls if the "Canel" button will be displayed.
• Controls if the Form can be resized
• Controls if the Form can be closed with the 'x'
• Control which field is the default field, if any, when the form initializes.

Understanding the Script Part 1: General Form Settings

The script begins with the following header which defines where most of the customizations will occur.

########################################
### Edit This Section to Modify CDF ####
########################################

$FormTitle='ZCM User Collection Data Form'
$Icon="C:\Program Files (x86)\Novell\ZENworks\zapp\assets\zapp_exe_icon.ico"
$FormWidth=400
$MinMaxClose=$False ## False will hide the icon
$FormMax=$False
$FormMin=$False
$ShowCancelButton=$True
$Topmost=$True
$OKtext = 'OKIE'
$CANCELtext='NOPIE

$Pos2Offset=10
$DefaultPos1=10
$FormPosition='CenterScreen'

The variables highlighted in 'Aqua' are items that may commonly be modified.  The use of most variables should be self-evident and control items such as the icon used, form title, button text, form width, and if it can be resized.

The variables highlighted in 'Amber' most likely do not ever need to be changed but can be modified if the form needs tweaking.

Note: FormHeight is NOT defined here because the height is calculated based upon which labels and input fields are enabled.  This prevents the need to manually adjust the value every time a component is enabled or disabled.

Understanding the Script Part 2: Configuring the Controls

As above, I have used the same color scheme.  The items in "Aqua' are the items most likely to be modified.  It is not recommended to alter the items in 'Amber'.  These fields are used to perform the automatic calculation of the placement of items on the form.  If these are adjusted, it may cause issues with the placement of items.  However, they are listed in the case tweaks are required.

If you desire to 'Disable' a Lable or Text box, simply set the value to $False.  Update the "Text" field to adjust the string displayed.

#################
#### Controls #####
#################

$ShowLabel1=$True
If ($ShowLable1) { $Pos2Offset +=30 }
$Label1Pos1=$DefaultPos1
$Label1Pos2=$Pos2Offset
$Label1Height=20
$Label1Width=350
$Label1Text='Nickname'

$ShowMaskedTextBox1=$True
If ($ShowMaskedTextBox1) { $Pos2Offset +=20 }
$MaskedTextBox1Pos1=$DefaultPos1
$MaskedTextBox1Pos2=$Pos2Offset
$MaskedTextBox1Height=20
$MaskedTextBox1Width=350
$MaskedTextBox1MaxLength = 20
$MaskedTextBox1Mask = ""

Note: If you want to control the data entered into the TextBox, define it in the "MASK" variable above.  TextBox2 and Textbox3 in the script actually make use of the mask.  See - https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.maskedtextbox.mask?view=net-5.0 for details on how to form the mask.

Understanding the Script Part 3: The Untouchable Part (Almost)

The next part of the script does most of the heavy lifting of building the form. 

###################################
### Do not Edit MakeCDFGUI Function ###
###################################

Other than a few exceptions I will note, NOTHING in this part of the script should be touched.  The settings defined in the sections above should be used to alter the behavior in this section.

The Exceptions -

If you wish to "Hide" the input as a user is typing into a TextBox, uncomment the "Password" character definition by removingthe # sign.  For Example change

• #$MaskedTextBox1.PasswordChar="*"  to
• $MaskedTextBox1.PasswordChar="*"

If the List box will is enabled, this section contains the entries in the list.  This list needs to be updated to include the desired values.  The default entries which need to be updated look like this:

[void] $listBox.Items.Add('Broccoli ')
[void] $listBox.Items.Add('Carrots')
[void] $listBox.Items.Add('Cucumbers')
[void] $listBox.Items.Add('Garlic')
[void] $listBox.Items.Add('Lettuce')
[void] $listBox.Items.Add('Onion')
[void] $listBox.Items.Add('Suspension Bridge')

Other than those two exceptions, nothing else should be modified in this section

Understanding the Script Part 4: The Main Code...which has minimal code

Again, in this section, the areas highlighted in 'Aqua' are designed to be modified.  Nothing else would be modified.  The response for each user input field will be stored in a registry key.  Those areas are highlighted in aqua.  Simply update the Registry Keys and Values to match the desired values.  If a particular input field is not disabled, do not delete the lines, simply ignore the entry since it will be skipped if those fields are disabled.

###################
### Main Script ###
###################

$ErrorActionPreference = 'SilentlyContinue'
$Results=MakeCDFGUI #Call Function to Make GUI

if ($results[0] -eq [System.Windows.Forms.DialogResult]::OK) {
New-Item -Path 'HKLM:\Software -Name Acme'   #Creates HKLM\Software\Acme if it does not exist
If ($showMaskedTextBox1) {
Set-ItemProperty -Path 'HKLM:\Software\Acme' -Name 'Nickname' -Value $results[1]  #Creates and Populates Registly value named 'Nickname'
}

If ($showMaskedTextBox2) {
Set-ItemProperty -Path 'HKLM:\Software\Acme' -Name 'Age' -Value $results[2] #Creates and Populates Registly value named 'Age'
}

If ($showMaskedTextBox3) {
Set-ItemProperty -Path 'HKLM:\Software\Acme' -Name 'SocialSecurity' -Value $results[3] #Creates and Populates Registly value named 'Social Security'
}

If ($ShowListBox1) {
Set-ItemProperty -Path 'HKLM:\Software\Acme' -Name 'Vegetable' -Value $results[4] #Creates and Populates Registly value named 'Vegetable'
}
}

Understanding the Script Part 5: Understanding the ZCM Bundle

Below is the exported Bundle - "User_Input".  It contains the following settings:

• System Requirement for the Environment Variable "LOGONSERVER" to Exist will ensure it only runs when a user is logged into the PC.  This is only required if the bundle is "Device Assigned".  If "User Assigned", this check is not necessary but not harmful.
• Run Script Action (See Script Above) that runs as "Dynamic Administrator" so that there is both User Interaction and has sufficient rights to update the Registry.
• Launch Executable as User:  "zac inv cdf" to upload the user responses collected in the script.  (Note: This command was not properly processed from Powershell when it was run as the Dynamic Administrator User, so it was separated out.)

ADFs: Ensure the Administrative Defined Fields are Defined in the ZCC

Before the information in the registry entries above can actually be stored in the Database, "Administrator Defined Fields" (ADFs) must first be defined in the database.  To do this, go to ZCC->Configuration->Asset Inventory(Tab)->Administrator-Defined Fields->Workstation.  Select "New" and define the desired fields.  In this case I create: Age(Integer), SocialSecurityNumber(Char:12), and Vegetable(Char:20).  (See Picture Below)

CDFs: Define the Collection Data Form to map fields to registry values.

To Map the field go to ZCC->Configuration->Inventory->Collection Data Form.  Ensure the "Invisible Mode" is selected in the checkbox near the top of the page.  Then find the fields defined above and set "AutoFill" to yes.  Fill in the Registry Key value to map to the field.  (See Picture below)

Sample Bundle: Download and Import the ZIP to test this Sample Bundle: Sample Bundle: UserInputSample.zip

Note: Follow-up Articles will discuss many other uses for CDFs for collecting Custom/Advanced information Computers.  In the Picture above, we can also see that this PC has a statically assigned IP address as well as the ethernet adapter which is static.  This is just one example of the myriad of additional data ZCM can be configured to collect.