Contents
1. Testing and Deploying Collector
It is important to have a testing phase before starting the actual deployment. Such a testing phase allows validating the installation on endpoints before large-scale deployment. This chapter presents a best practice testing and deployment strategy.
Collector testing and deployment best practice is a 6 phases procedure:
Phase 1 : Preparation
Phase 2 : Unitary software testing
Phase 3 : Deployment testing
Phase 4 : Mass testing
Phase 5 : Network-wide deployment
Phase 6 : Maintenance
This section does assume that NEXThink Engine is already installed and running. The rest of this chapter will first highlight upgrade and digital signatures considerations before detailing each of the aforementioned phases.
1.1. Upgrade Considerations
The Collect MSI package is able to uninstall any previously installed NEXThink driver. Consequently, it is not necessary to explicitly uninstall deprecated NEXThink drivers before installing Collector. However, it is of course required to stop deployment of such drivers as soon as Collector deployment is started. The following figure depicts a GPO unassignment and the possible choices regarding the old package handling after uninstallation, the second being the one to adopt.
1.2. Digital Signatures Considerations
The Collector binaries and the MSI package are not signed. It is left to the customer’s discretion to digitally sign these files before deployment . This may be required by some system policies.
1.3. Phase 1: Preparation
1.3.1. Understand Collector functioning
First, a good understanding of Collector functioning, as it was detailed in the previous chapters, must be acquired. See the page advanced/UnderstandingCollector for more information.
1.3.2. Company network map
Second, a network map of the company where Collector will be installed must be obtained. In the rest of this chapter, an example will support instructions: the BigCompany company has a network consisting of multiple abroad locations.
1.3.3. Identifying Engine profiles
On a company network, different machines may have different Collector configuration. For example, more than one Engine could be the target of activity packets or the maximum payload size may differ. Therefore, it is necessary to identify the different Engine profiles. From two Collector installations point of view, two Engine profiles are different from each others if:
- The two Collector drivers are not located on the same network;
- The two Engines are not accessed with the same IP/port pair;
- The two Collector drivers are not configured in the same way (e.g. changes in maximum payload size).
Identifying Engine profiles is consequently a mixture of Engine and company network analysis. The following figure depicts Engine profiles for the sample company.
In this example, there are 5 engine profiles:
- EP1 and EP2 are different as the maximum payload size (mss) settings are different.
- EP3, EP4, EP5 are on specific networks.
1.3.4. Creating configuration transforms
For each Engine profile as described in the previous section, an MSI transform reflecting the profile-specific configuration must be created. This is done by following the instructions for configuring the Collector MSI installation using MSI transforms, which was discussed in the previous chapter. For the BigCompany example, there would therefore be 5 resulting MSI transforms, one for each identified Engine profile:
- config_CH.mst: configuration for sedentary users from Lausanne
- config_CH_low_mss.mst: configuration for nomad users from Lausanne
- config_F.mst: configuration for all Paris machines
- config_CN.mst: configuration for all Shanghai users
- config_USA.mst: configuration for all New York users
1.3.5. Targets of unitary tests
Unitary tests will prove compatibility of NEXThink Collector with software already installed on the network. For this matter, sensitive software being used on the different company networks, for each Operating system, must be identified. The following categories are considered to be sensitive software:
- Security software: Antivirus, Firewalls, VPN clients, etc
- Early-boot software: programs that are launched very early after computer boot (e.g. GINA).
- Sensitive corporate software: programs that are installed network-wide, possibly proprietary, and required for business operations.
- Kernel-mode network software: programs using Windows drivers that may generate network connections (e.g. network file system).
- Major configuration change (e.g. firewall rules).
The following table depicts a software analysis for the BigCompany networks. 4 software components have been considered to be sensitive.
From this table, one can see that 4 machine profiles must be tested against compatibility issues (highlighted in yellow):
- Windows 2000 machine in Shanghai
- Windows XP machine in Lausanne
- Windows Vista machine in Lausanne
- Windows Vista machine in New York
For each of these profiles, one or more machines must be selected for unitary tests. These machines must be active (i.e. every-day use) and not critical (i.e. no important service running on the machine).
- UT1 = at least 1 active and non-critical machine for each found software profile
Moreover, mass testing will require a few of such machines, too.
- MT1 = N active and non-critical machines from each found software profile
In the previous sections, Engine profiles were defined. As Collector 3 may encounter connectivity issues, it is necessary to include one active (i.e. every-day use) and not critical (i.e. no important service running on the machine) machine per Engine profile in the Unitary Test phase.
- UT2 = at least 1 active and non-critical machine for each found Engine profile
Likewise, mass tests will be performed on machines of Engine profiles.
- MT2 = N active and non-critical machines from each found Engine profile
The set of machines where unitary tests must be performed is in conclusion the union of UT1 an UT2.
- UT = UT1 + UT2
The set of machines where mass test must be performed is, similarly, the union of MT1 and MT2.
- MT = MT1 + MT2
1.3.6. Targets of deployment tests
Deployment tests are performed for confirming the possibility to install the Collector MSI package on a set of machines. Considering the company network map, machines must be categorized in deployment profiles. Two machines are in different deployment profiles if:
- They are in different networks.
- They cannot access the same network share.
- They have different security settings (e.g. unsigned MSI package are accepted or not).
For deployment tests, one or more active and non-critical machines must be selected in each deployment profile of the company network.
- DT = at least 1 active and non-critical machine for each found deployment profile
1.4. Phase 2: Unitary Software Testing
Unitary testing of Collector is done by following the below procedure. These instructions must be repeated for every sample machine in the Unitary Testing machine set
- Make sure that the Engine to which the test machine will report users’ activity is running.
- Install Collector on the test machine using the appropriate configuration MSI transform (you must have administrative rights):
msiexec /qr /i NEXThink_Collector.msi TRANSFORMS=config_<engine-profile-id>.mst
- If the installation procedure fails:
- Enable logs and try again.
- Identify the problem in the log file
- If the installation cannot be done, advise NEXThink support.
- Reboot the test machine.
- Check in the Windows events viewer that the Collector driver has been successfully loaded. If this is not the case, please submit a bug report to NEXThink.
- Check that the driver is active by opening NEXThink Finder and making an investigation on the test machine NetBIOS name. If this is not the case, you may suspect a connectivity issue between the target machine and the Engine.
- Collector must be left running on the system for at least 5 working days before continuing the installation strategy. It must report machine activity correctly and without system stability or other problems of any kind during this period.
Any problem at this stage must be investigated and solved before going on.
1.5. Phase 3: Deployment Testing
For each machine in the Deployment Testing machine set (DT in Phase 1), the following procedure must be followed:
- Make the Collector MSI package available to all machines in the deployment profile by putting it on a network share.
- Deploy the package with your deployment tool (e.g. GPO, psexec, etc), using the appropriate transform.
The Collector MSI package supports both per-user and per-machine installation. However, per-machine installations are the recommended method. If the user executing the installation process does not have enough privileges and if the system is configured for allowing such behavior, the installation can be deferred to the system context, hence allowing installation of the MSI package by non-administrator users. Further information on deployment can be found here: REF The deployment success must be confirmed by:
- Checking the deployment tool logs.
- Checking the Collector driver activity in the Finder.
Deployment testing for each deployment profile as defined in phase 1 is a mandatory task. Any problem must be solved before continuing to the Mass Testing phase.
1.6. Phase 4: Mass Testing
Mass testing is the next step toward validation of Collector with the company network. It is set up by performing the following steps:
- Sort machines in the Mass Testing machine set (MT in phase 1) by deployment profile as defined in phase 1
- For each deployment profile
- Install Collector machines from the Mass Testing machine set using the deployment method that was tested in the previous section.
- Check that the installation went fine by looking at the deployment tool logs.
- Check that the machines are correctly by making an appropriate investigation in the Finder.
- Run Collector on these machines for at least 5 working days. Collector must report machines activities without instability or problem of any kind during this period.
Mass testing is a mandatory task before starting network-side deployment.
1.7. Phase 5: Network-Wide Deployment
After successful completion of the unit test and mass test, Collector is ready for network-wide installation. Follow the procedure described under Mass Test on all the machines of all deployment profiles. All network-wide software deployment should be phased, and this is especially the case for kernel-mode components like Collector.
1.8. Phase 6: Maintenance
Maintenance is an important task of Collector deployment. Two major tasks must be performed:
- Collector must be kept up to date. NEXThink support web site gives information about latest releases.
The CrashGuard feature may have disabled some of the Collector drivers on the target network because of suspected computer crashes. Consequently, it is good practice to watch the number of active and inactive machinse in NEXThink Finder. Moreover, a script gathering information regarding this feature on endpoints can be downloaded from NEXThink support website (checkCrashGuard.vbs).
Ideally, this check should be performed at least every 6 months.