Docstoc

USB Device Monitoring.doc - Savi_savings

Document Sample
USB Device Monitoring.doc - Savi_savings Powered By Docstoc
					Index
Index .................................................................................................................................................... 1
1. USB Device Monitoring .............................................................................................................. 2
2. Proposed implementation............................................................................................................. 2
  2.1.      USB device monitoring........................................................................................................ 2
     2.1.1.         Custom Policy Definition ............................................................................................ 2
     2.1.2.         Saving the compliance report history .......................................................................... 8
     2.1.3.         Building custom reports ............................................................................................... 9
1. USB Device Monitoring
This document describes a proposal for implementing the capability to detect devices connected to
USB ports and provide a history of data related to the usage of USB ports. Such historical data
would be used to build ad-hoc reports.


2. Proposed implementation
This section provides some details about the proposed implementation and configuration for the
above requirement.

2.1. USB device monitoring
TPDSD 7.1 does not provide the capability of scanning USB ports for detecting connected devices.
For this reason, in order to try to address the customer’s requirement, a way could be to leverage the
custom policies and the related compliance condition.
In more details, a custom policy is the most generic policy TPDSD can support, because it allows
specifying custom compliance checks in the compliance condition, as well as custom remediation
actions.
Leveraging the custom compliance check, the customer could implement a check on the USB ports
leveraging WMI queries to understand if any device is connected to any of the USB ports of a target
system.
The proposed solution to address the requirement is described by the following steps:
    1. Create a custom policy with a custom script to implement the compliance check and a
        custom script to implement the remediation action. The custom policy will be sent to all the
        agents and will be configured to run periodically on each agent and to detect non-
        compliances over time. The evaluation frequency of the policy determines the granularity of
        the information collected at the server side: a more strict control on the USB utilization will
        be achieved by keeping the evaluation frequency small.
    2. At the server side, some customization has to be implemented in order to keep track of the
        history of the non-compliance reports eventually returned by the agents, because TPDSD
        does not keep the history of such reports. A way could be to define a new table to store the
        reports history and a trigger on the TPDSD table used to store the agent compliance reports.
        Every time a new report comes in from a specific agent on this custom policy, it is stored
        inside the TPDSD table for agent compliance, replacing the previous report for the same
        agent and the same policy, but a copy of each report can be saved in the custom table by the
        trigger.
    3. Custom reports can be build using BIRT technology provided by TPAE, reading data from
        the new custom table storing the reports history


2.1.1. Custom Policy Definition
This section provides some details about how to define a custom policy to detect USB devices
connected to the target systems.
As anticipated, the custom policy will have a custom script associated with the compliance check
and another custom script associated with the remediation action.


                                                  2
The compliance check is implemented as a Boolean expression, which will indicate if any device is
connected to any of the USB ports of a target system. If the condition is verified, the remediation
action will be triggered, running the associated custom script that will list the devices attached at
that time to the USB ports. The custom remediation action has to be configured to return to TPDSD
server the Stdout and Stderr produced by the related script.

The following are example of WMI query that could be used to detect USB devices:

       To detect all the USB devices (plug-and-play devices) discarding the default USB hubs you
        can use this WMI query:
         Select * from Win32_PnPEntity where Description like 'USB%' and Service !='usbhub'

       To detect all the Storage devices connected to a USB port you can use this WMI query:
        Select * from Win32_DiskDrive where InterfaceType='USB' and mediaType != ''

Such queries can also be included inside VBScripts, which can be executed as custom command
within the compliance check (see the following paragraphs).

Another way might be leveraging some Microsoft tools, provided as debug utilities and available at
the following link:
        http://support.microsoft.com/kb/311272
The devcon.exe command can be used within a custom policy and executed as remediation action if
the compliance check fails. In this way, the command can detect which port is used by which
device. For example, using the following command:
        devcon find usb\*
will return the list of all devices that are present on the local computer.

The following is an example of a custom policy (xml representation) leveraging a couple of vbs
scripts for detecting if at a given point in time one or more devices are connected to the USB ports
and to list such devices, according to the WMI queries described above.

<?xml version="1.0" encoding="UTF-8"?>
<policy:policies xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:policy="http://www.ibm.com/xmlns/prod/DTM/1.0/policy">
   <policy:customPolicy>
        <policy:identity>
             <policy:name>check USB activity</policy:name>
             <policy:category/>
             <policy:revision>2</policy:revision>
             <policy:description/>
             <policy:DTMschemaVersion>1</policy:DTMschemaVersion>
        </policy:identity>
        <policy:modificationInfo>
             <policy:changeable>false</policy:changeable>
             <policy:changeDate>2009-11-11T11:44:01Z</policy:changeDate>
             <policy:changeBy>MAXADMIN</policy:changeBy>
        </policy:modificationInfo>
        <policy:processingOptions>
             <policy:interval>1</policy:interval>
             <policy:severity>warning</policy:severity>
        </policy:processingOptions>
        <policy:applicabilityCondition>
             <policy:booleanExpression/>



                                                          3
        </policy:applicabilityCondition>
        <policy:complianceCondition xsi:type="policy:BooleanConditionType">
             <policy:booleanExpression>ExecProgram("cscript c:/temp/wmi_check.vbs")==0</policy:booleanExpression>
             <policy:fileDependencies>
                 <policy:corequisiteRef>
                     <policy:name>wmi_check.vbs</policy:name>
                     <policy:version>1</policy:version>
                     <policy:logicalFolder>image_repository</policy:logicalFolder>
                     <policy:targetPath>c:/temp</policy:targetPath>
                     <policy:isTemporary>false</policy:isTemporary>
                 </policy:corequisiteRef>
             </policy:fileDependencies>
        </policy:complianceCondition>
        <policy:remediationAction xsi:type="policy:ExecuteProgramRemediationType">
             <policy:exec>
                 <policy:fileDependencies>
                     <policy:corequisiteRef>
                          <policy:name>wmi_query.vbs</policy:name>
                          <policy:version>1</policy:version>
                          <policy:logicalFolder>image_repository</policy:logicalFolder>
                          <policy:targetPath>c:/temp</policy:targetPath>
                          <policy:isTemporary>false</policy:isTemporary>
                     </policy:corequisiteRef>
                 </policy:fileDependencies>
                 <policy:command>
                     <policy:commandAction>cscript c:/temp/wmi_query.vbs</policy:commandAction>
                     <policy:actionLogType>reportAlways</policy:actionLogType>
                     <policy:actionLogFull>true</policy:actionLogFull>
                 </policy:command>
             </policy:exec>
        </policy:remediationAction>
        <policy:remediationType>remediate</policy:remediationType>
    </policy:customPolicy>
</policy:policies>


In this custom policy the compliance check is handled by the wmi_check.vbs script, listed below:
    strComputer = "."

    Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer
    & "\root\cimv2")

    Set colItems = objWMIService.ExecQuery("Select * from Win32_PnPEntity where Description like
    'USB%' and Service !='usbhub'")

    intCount = 0
    For Each drive In colItems
        intCount = intCount + 1
    Next
    WScript.Quit(intCount)


The remediation action instead, is handled by the wmi_query.vbs script, listed below:
    strComputer = "."

    Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer
    & "\root\cimv2")

    Set colItems = objWMIService.ExecQuery("Select * from Win32_PnPEntity where Description like
    'USB%' and Service !='usbhub'")

    For Each objItem in colItems
      Wscript.Echo "Availability: " & objItem.Availability
      Wscript.Echo "Caption: " & objItem.Caption
      Wscript.Echo "ClassGuid: " & objItem.ClassGuid




                                                           4
     Wscript.Echo   "ConfigManagerErrorCode: " & objItem.ConfigManagerErrorCode
     Wscript.Echo   "ConfigManagerUserConfig: " & objItem.ConfigManagerUserConfig
     Wscript.Echo   "CreationClassName: " & objItem.CreationClassName
     Wscript.Echo   "Description: " & objItem.Description
     Wscript.Echo   "DeviceID: " & objItem.DeviceID
     Wscript.Echo   "ErrorCleared: " & objItem.ErrorCleared
     Wscript.Echo   "ErrorDescription: " & objItem.ErrorDescription
     Wscript.Echo   "InstallDate: " & objItem.InstallDate
     Wscript.Echo   "LastErrorCode: " & objItem.LastErrorCode
     Wscript.Echo   "Manufacturer: " & objItem.Manufacturer
     Wscript.Echo   "Name: " & objItem.Name
     Wscript.Echo   "PNPDeviceID: " & objItem.PNPDeviceID
     Wscript.Echo   "PowerManagementSupported: " & objItem.PowerManagementSupported
     Wscript.Echo   "Service: " & objItem.Service
     Wscript.Echo   "Status: " & objItem.Status
     Wscript.Echo   "StatusInfo: " & objItem.StatusInfo
     Wscript.Echo   "SystemCreationClassName: " & objItem.SystemCreationClassName
     Wscript.Echo   "SystemName: " & objItem.SystemName
     Wscript.Echo
   Next

   WScript.Quit(0)


The script in this case just lists for each USB device detected by the WMI query all the attributes
associated to the Win32_PnPEntity class for Plug and Play devices.

The custom policy is also configured to return to TPDSD server the Standard out and Standard error
produced by the program associated to the policy’s remediation action, as described by the
attribute:
       <policy:actionLogType>reportAlways</policy:actionLogType>


The previous examples can be used to define a custom policy in TPDSD according to the following
steps:
    1. Copy the xml listed above and save it in a file on your local system.

   2. Copy the two VB scripts in two separate files on your local system, named wmi_check.vbs
      and wmi_query.vbs.

   3. Open the TPDSD web console and select the “Software and Patch Catalog” application.

   4. From the toolbar select the “Select Action” drop-down menu and the “File Repository ->
      Manage Files” item.

   5. A dialog will show up, allowing to add the two .vbs files created at the previous step 2, as
      described by Figure .




                                                        5
                                 Figure 1 How to add a new file


6. Click the “Add a File to the Repository” button and select the “Add New File” menu item,
   like described in Figure .

7. When selecting the files to be added to the file repository you need to select which logical
   folder is going to contain those files. The policy example refers to the “image_repository”
   folder for the vbs scripts (as described in Figure ). If you decide to change that folder you
   need to modify also the reference to that folder in the custom policy xml representation.
   You need also to specify the file type, being “Corequisite File”.




                                    Figure 2 Add File Dialog


8. Once the two vbs scripts have been imported in the catalog, the custom policy can be
   imported as well. In order to import the policy definition, move to the “Policy and
   Compliance Setup” application.

9. In the main toolbar select the “Import Policy Definition” button, as indicated in Figure 3.




                                Figure 3 Import policy definition




                                               6
10. The “Import Policy Definition” dialog allows browsing the local file system to retrieve the
    custom policy xml representation. Leave the “Include Policy Dependencies?” check-box
    unchecked, as described in Figure .




                                     Figure 4 Import dialog


11. At this point the policy will be imported in the Policy repository and you should get a
    success message as in Figure .




                                    Figure 5 Success message


12. The policy will show up in the main UI page, as in the following Figure .
    You can see that the default evaluation frequency has been set to 1 minute, and the vbs
    scripts used by the policy will be placed in the “C:\temp” folder at the target side. If you
    wish to change any of those default values, you can do it and save the policy.

13. At this point, moving to the “Target Computer Groups” you can associate the policy to one
    or more target computer groups (“Add Groups” button related to the “Target Computer
    Groups” table) and activate the policy on those groups (“Activate” button).

14. The policy will be sent to all the computers belonging to the selected groups, which will
    start evaluating the policy with the specified evaluation frequency, reporting results to the
    TPDSD server.




                                               7
                                   Figure 6 Imported policy details



2.1.2. Saving the compliance report history
At the TPDSD server side, Standard out and Standard error returned by the remediation action are
stored into the DTMAGTCMPSTATE table, which exposes the following interesting fields:
     REMRETCODE: integer to store the return code of the remediation action;
     REMSTDOUT: a CLOB to store the standard out produced by the command
     REMSTDERR: a CLOB to store the standard error produced by the command.
     CMPSTATE: an integer to store the agent compliance state for a specific policy

Customization at this level will require building a new table, similar in content to the
DTMAGTCMPSTATE, but with the capability of storing a history of reports for a specific
agent/policy pair.
A trigger can be defined on the DTMAGTCMPSTATE (on insert and update) to replicate the
compliance report info on the new custom table. You can identify the proper condition to be met for
the triggered action to be executed: you might probably want to avoid replicating every compliance
state for every policy to every task, so using a naming convention on the policies that you want to
replicate in the history might address your needs.
The following picture (Figure 7) shows a view of some of the involved tables, which might be
helpful to identify the relationships between tables to build your trigger conditions.




                                                  8
                                        Figure 7 Data model

2.1.3. Building custom reports
TPDSD provides the capability of extending the default set of BIRT reports by implementing
custom reports. A custom report can be built on any of the database tables in the TPDSD database.
This means that also the new custom table for history data can be used as the datasource for
building ad-hoc reports.
Please refer to the TPDSD documentation to see how to implement custom reports.
The documentation is provided in two separate doc files (“BIRT Install for DTM.doc” and
“BIRT_developer.doc”).




                                                9

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:11
posted:5/30/2010
language:English
pages:9