HealthCast

Recommended Practices for Testing Deployments

Look beyond Staging and Default

Make use of these locations for their intended purposes. Staging can be used to quickly "un-deploy" a wrapper - just remove it from the location. Remember that EVERY registered PC will receive the packages listed in Default, so be sure that what you put in the Default Location is supposed to be deployed to every workstation running HCIDeploy.

Given that, think carefully about creating new locations to organize the packages for deployment.

As mentioned in Recommended Practices for Testing Deployments, consider making a few test locations and only adding workstations to those that are under IT control. Remember to consider real world usage as a potential test as well, so consider creating a pre-deployment test location where one or two production machines are associated.

A good process to follow might include the following checklist:

User Interface:

The user interface is designed to perform the following actions:

Below is the main interface to the HCIDeploy Publisher.

Click the Create button, to be presented with the following screen:

You may accept the default package information, but each package must have a unique name. Therefore, you must change the package name on this page. Once you have completed filling out the package information, select the "package content" tab to select the contents for the package.

Click the Package Content tab

A pre-created package may be imported by dragging and dropping a package.zip file onto this page. Additionally, a package may be imported from the main interface context popup menu of the Staging location.

Add files using the green add() button. This will bring up a file selection dialog where you may select multiple files to add to the package. If you have several files, and they do not all reside in the same directory, you may select the add button to select other directories and files. Note that a package must contain files that have unique names. It is not possible to add a file from a different directory with the same name as an existing file in the package. This is a requirement of the operating systems file system, as all package files will be deployed to a single directory on a client workstation. Also note that the package name must be a valid file system name. It therefore, may not contain any of the following characters:

a quote ("), colon (:), backslash (\), forward slash (/) asterisk (*) or question mark (?)

If you need to remove a file, select it from the list, and press the delete () button.

The blue buttons (), () allow you to select the scripts that indicate usage for installation and uninstallation. These files will then be marked as either install script or uninstall script. Valid scripts are BAT, VBS, or EXE files.

Once all file selections are complete, click the OK button to begin the publishing process. If the package consists of individual files, the files will be compressed into a .package.zip file.

If the package is being imported, the compression step will be skipped

The file and package information will then be sent to the server. By default, the package will be associated with the "Staging" location.

In order to deploy the package to a workstation, the package must be assigned from the "Staging" location to another location that has associated workstations. Initially, there is only a single location where this is possible, so you must assign the package to the "Default" location.

See "Assigning Packages to a location" for information on how to associate a package with a new location.

The import scenario is provided so that packages may be created at locations that do not have access to direct publishing on the HCIDeploy Server. The package can be downloaded locally, then pushed to the site using technologies such as HTTP or FTP. Alternately, packages produced by HealthCast can be released to clients for direct import without having to re-package.

There are no "required" files for a package, however, there are several files that can be added for special circumstances.

Settings may be imported by exporting .reg files and adding the .reg to the package. In this case however, it is necessary to execute an install script to merge these settings into the registry. For more advanced registry manipulations, VB script, or executables may be used instead.

Sample Scripts

Select a package from the list to enable the Update button. Using the update functionality is identical to using the create functionality with the exception that a package must be selected before you can update it. If you add files to the package, you will create a new version of the package. Package content may be completely different and is not dependent on any previous version of the package. If a previous file is not included in the new package, it will not be present on the workstation after deployment of the new version.

Administrators may also right click the package from the staging location and choose to update the package.

You may view the package information by selecting a package from the tree view. This will download the package information from the server and display the information next to the package list view. The numbers in brackets [ ] indicate the highest package version available for that package.

Comments may be added to the package, and they may be multi-line comments. It is also possible to update the comment field by clicking the Update button. Enter a new comment into the Package Comment field, then click the Save button to commit the changes.

You may also view the history by selecting the History tab on the package to display previous version information.

From the Package History list, right click on a specific version, and that version can be exported so that it can be moved to a different server. You will be prompted for a location and file name to save the exported package version.

It is possible to deactivate a version to "revert" to deploying a previous version. Additionally, the package content may be reviewed for a specific version of the package.

Workstation Locations

A package location represents a grouping for packages and workstations. This is a logical grouping only, and is provided so that packages may be distributed to the correct set of PCs representing a sub-set of users or workflows within an organization.

By selecting the refresh () button, the HCIDeploy Publisher will load the available locations from the server and display them in the list. Each location, when expanded, will display a list of packages () associated. To view computers, select the location - a new tab will display the workstations associated with the location. The Filter and workstation selector fields may be used to limit the number of workstations listed in this view.

In the staging package list, right click the desired package and select "View Locations for Package..."

From the Logical Locations, expand the location and right click on a package. Select "View Locations for Package..."

Optionally, select the package in either view and click the Find Locations button in the toolbar

The workstation selctor is sent to the server during a query for workstation information. This reduces network traffic, and makes the query execute faster. The server will discard workstations from the result that do not match what the selector contains. It is also possible to use the wildcard * to indicate match anywhere in the field data, or to specify that a field must begin or end with the text entered.

Example:

Windows 10* - will match all workstations that have an Operating system of Windows 10 (enterprise, pro) - Filter meaning: workstation starts with windows 10.

To show only Windows 10 enterprise systems, use *10 ent* - Filter meaning: operating system contains "10 ent" somewhere in the field.

Example: If you want to see only workstations that have Kiosk Mode installed - enter kiosk into the filter - the server will discard workstations that do not have this word as part of one of the fields (name, operating system, xa mode, etc) This could still return a large number of workstations, so as a further limiter, enter the maximum number of workstations for the server to return in the "Maximum Workstations field".

The filter field allows for the client side limiting of workstation information, much like a smart search, and applies after the workstation list has been retrieved from the server. It will hide workstations that do not match the filter information. For example, to show only workstations that have IE 11.5xx installed, enter 11.5 in the filter field. The filter will match all fields, including IP address, MAC address, XA version, XA Mode, IE Version, Operating System, and Workstation Name. Example: Entering [02 into the filter will display workstations that have a MAC address starting with 02. It may be necessary to enter more information into the filter to limit the view if there are multiple fields containing a match to the filter entry.

The filter feature has now been added to the staging location, and is capable of filtering available packages in the list. This may be important when dealing with a large number of packages, such as remote system info packages that have been uploaded to the server. It work like the other filters, enter some partial text to limit the display to only packages that have that text appear somewhere in the name. Press enter on the filter field to apply the filter, and click the X button next to the field to clear it.

Right click on the locations list and select "New Location..." from the context menu. You are then prompted to enter a new location name. Each location name must be unique.

If you have made a mistake when creating a location, or you no longer need a particular location, you may remove the location by right clicking on the location in the list and selecting "Delete Location" from the context menu.

Note that the location must not have any associated workstations or packages before it may be deleted.

Previous versions used the recycle bin to remove packages from a location, as they could only be associated with a single location. It is now possible (with 4.11 and above) to assign a single package to multiple locations. Instead of using the recycle bin, there is a new context menu specific to this operation.

When creating a location, it is now possible to mark the location with a special flag indicating that any workstations associated with this location can no longer be added to other locations. The purpose of which is to segregate specific workflow configurations and ensure that they are not overridden by incorrect settings. For example, creating a location that configures workstations for Locking Kiosk Mode. Workstations in this location should not also be in a location that configures the workstation for Standard Mode, as the settings would conflict and may cause the workstation to be unusable.

Locations are a simple means of segregating a particular set of workstations from the rest of the organizations workstations. These workstations may be physically located in the same building, floor or even in the same office, but that is not a requirement for associating them with a location in HCIDeploy. The concept for locations in HCIDeploy is that this set of workstations will all receive the same set of packages. Packages may contain files, installs, or just configuration settings. The commonality is that all workstations will be configured the same way (with the same workflow), or will contain the same files, or have the same applications installed when using HCIDeploy.

It is therefore recommended that location names be chosen based on the type of configuration desired which reveal the usage of the associated workstations, rather than by a geographical name such as a building, floor or office.

A Test or pre-deployment location should be created and test lab workstations be associated with this location to facilitate pre-deployment roll-out testing of deployment install scripts and connector functionality. Several such locations may be desired, so feel free to create as many as necessary. There is no imposed limit to the number of locations that may be created, but it is suggested to limit these to as few as possible to prevent excessive load times of the package location list.

There are two pre-configured locations after a fresh setup of HCIDeploy. These pre-configured locations have special meanings and also have some limitations associated with them as well.

The Default Location is a location that all unassigned workstations will be associated with. Each workstation associated with the Default Location will receive the packages associated with the Default Location. The Default Location may not be deleted, and it is not possible to browse for workstations to associate with the Default Location.

The Staging Location is a special location that all first time published packages will be associated with. No workstation may be associated with this location so that wrapper developers may publish their packages knowing that the package will not be immediately deployed. This allows for the opportunity to create a Testing or Pre-Deployment location and associate a specific set of workstations dedicated to testing the package deployment and the package functionality before it is deployed throughout the organization.

The Recycle Bin Location is a special location that is used to mark package for deletion. To completely delete a package from all locations, including staging, place the package into the Recycle Bin, then Empty the Recycle Bin from the context menu. If you add a package by mistake to the Recycle Bin Location, use the Remove Package from Location option to recover the package prior to using the Empty Recycle Bin option.

HCIDeploy running on a client will request a list of packages by asking the HCIDeploy server for a package list. This request includes sending the name of the workstation to the server. The server then determines what location the workstation is associated with, selecting all packages from that location as well as adding all of the packages associated with the Default Location.

Select the location to have workstations added, then select the Add workstation to Location option. Pick the workstation(s) from the workstation browser. Optionally, expand the location for which a workstation is associated. Select and drag the workstation to a new location and drop it on that location. The workstation will now be associated with the new location. The workstation will retain its previous location and will now receive updates from the newly selected location.

Assigning packages is done in the same manner as assigning workstations. Expand the staging location and locate the package. Select and drag the package to a new location and drop it on that location. The package will now be associated with the new location. It will retain association with other locations.

It may be desirable to remove workstation registration if the workstation name has been changed, or the workstation is no longer functional or in operation. This may be done using the HCIDeploy Publisher selecting the location the workstation is associated with, finding the workstation in the workstations list, right clicking on the desired workstation and choosing "Unregister workstation" from the context menu

If the workstation name once again becomes active, it will re-register the name and be associated with the Default Location, rather than any previously associated location.