Determine Out of Policy Tags

The Last Result column provides information about if the device is either Compliant or Non-Compliant. For example, if 8 tags total are applied to a device, but just 1 tag is out of policy, the Last Result reports as Non-Compliant.

There could be several reasons for the status.

One task that ran to either ‘check’ or ‘apply’ a tagged template was successful, but a second task failed.

The successful task will report compliant security tags, but the failed template was unable to either ‘check’ or ‘apply’ the template and thereby the associated security tags. As a result, the device is reporting a ‘partial’ status and you need to determine which task failed to apply the tagged template. In the example below, although the Ports tag was part of a successful template at 7:00 am, it was then part of an unsuccessful template at 8:00 am and the tag is therefore now non-compliant.

Conflicting tags are assigned to the device

As an example of this problem, imagine you have two templates. One enables SSL communication whereas the second template disables SSL communication. You create two security tags in Security Analyst, one called SSL_ON and the other called SSL_OFF. You assign the tag to its respective template. However, somehow both templates were applied via the SAME task to the SAME device in Streamline NX. The result is that the conflicting tag causes the device to be perpetually ‘out of policy’.

The device was not reachable when SLNX attempted to check or apply a tagged template.

If the device is not reachable, the task cannot either ‘check’ or ‘apply’ a tagged template. Filter the device list by Unknown and check to see if the device is also in this list.

If this is the case, the machine has encountered an internal error (for example, the wrong java version or firmware installed...etc.) when running an ‘apply’ or ‘check’ task with a tagged template.