You are on page 1of 566

CA DLP

Deployment Guide
r12.0

This documentation and any related computer software help programs (hereinafter referred to as the “Documentation”) is for the end user’s informational purposes only and is subject to change or withdrawal by CA at any time. This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA. This Documentation is confidential and proprietary information of CA and protected by the copyright laws of the United States and international treaties. Notwithstanding the foregoing, licensed users may print a reasonable number of copies of the Documentation for their own internal use, and may make one copy of the related software as reasonably required for back-up and disaster recovery purposes, provided that all CA copyright notices and legends are affixed to each reproduced copy. Only authorized employees, consultants, or agents of the user who are bound by the provisions of the license for the product are permitted to have access to such copies. The right to print copies of the Documentation and to make a copy of the related software is limited to the period during which the applicable license for the product remains in full force and effect. Should the license terminate for any reason, it shall be the user’s responsibility to certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed. EXCEPT AS OTHERWISE STATED IN THE APPLICABLE LICENSE AGREEMENT, TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION “AS IS” WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO THE END USER OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED OF SUCH LOSS OR DAMAGE. The use of any product referenced in the Documentation is governed by the end user’s applicable license agreement. The manufacturer of this Documentation is CA. Provided with “Restricted Rights.” Use, duplication or disclosure by the United States Government is subject to the restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.2277014(b)(3), as applicable, or their successors. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies. Copyright © 2009 CA. All rights reserved.

Contents

Contents
Chapter 1

Introduction
Contact Technical Support .................................................... 23 Deploying CA DLP ............................................................... 23 Database tasks................................................................... 23 Hardware and software requirements ....................................... 24 CMS, gateway servers and utility machines ............................ 24 Client machines ........................................................... 25 Event Import and Import Policy machines ............................ 26 E-mail server agent and policy engine hub Policy engine host machines External Agent machines ........................ 26 ........................................... 26

iConsole machines ........................................................ 27 ............................................... 27 Archive integration host machines ...................................... 27 Architecture ..................................................................... 28 Upgrading CA DLP .............................................................. 28 Post-upgrade tasks ......................................................... 28 Version compatibility...................................................... 28

Chapter 2

CA DLP servers
Server types...................................................................... 29 CMS (Central Management Server) ...................................... 29 Gateway servers ........................................................... 30 Utility machines ........................................................... 30 Before installing................................................................. 30 Server name resolution ................................................... 30 Database configuration.................................................... 30

4

CA DLP Deployment guide

Disable 8.3 file names

.................................. 30

Gateways ................................................................... 30 Utility machines............................................................ 30 Server installation features .................................................. 31 CA DLP Server .............................................................. 31 Enterprise Server .......................................................... 31 Management Console ..................................................... 32 Documentation ............................................................ 32 Installing a CMS, gateway or utility machine .............................. 33 Assign the ‘Log on as a service’ privilege .............................. 37 User accounts created automatically on the CMS .............................. 38 Installations using Terminal Services .................................. 39 Unattended installations.................................................. 40 Uninstalling a CMS, gateway or utility machine ........................... 41 Manually uninstalling a server ........................................... 41 Installing an Administration console ......................................... 42 Is the Administration console already installed? ...................... 42 Console-only installations ................................................ 42

Chapter 3

Before you start using CA DLP
1 2 3 4 5 6 7 8 9 Choose an appropriate account to configure CA DLP ................ 43 Install your license file.................................................... 43 Configure your CMS machine policy to handle new accounts ...... 44 Configure event purging ................................................. 45 Configure the management of free disk space on servers .......... 46 Configure the common client and gateway policies.................. 47 Synchronize the clocks on your CA DLP machines .................... 47 Configure the policy for the default user group ...................... 48 Create and organize a hierarchy of user groups ...................... 49

10 Create your administrators and managers ............................. 49 11 Set up support for Unicode characters ................................ 50 12 Install iConsole searches.................................................. 51 13 Integrate with third party object storage solutions .................. 51 14 Configure event auditing labels ......................................... 51 15 Set up policy engines...................................................... 51

Contents

5

Chapter 4

Client machines
Client installation features .................................................... 53 CA DLP ....................................................................... 54 Management Console ...................................................... 54 Client Integration ......................................................... 54 Before installing ................................................................ 55 Manual installations (setup.exe).............................................. 55 Uninstalling client machines .................................................. 56 Using Add/Remove Programs ............................................ 56 Manually uninstalling ...................................................... 56 Command line operations ..................................................... 57 Installing with msiexec.exe .............................................. 57 Installing with setup.exe.................................................. 58 Uninstalling ................................................................. 58 Group Policy operations ....................................................... 59 Before installing............................................................ 59 GPO installation ............................................................ 60 Group Policy uninstallation............................................... 61 SMS operations .................................................................. 62 Before installing............................................................ 62 SMS installation ............................................................ 63 SMS uninstallation.......................................................... 65 Snapshot operations ........................................................... 66 Snapshot installation ...................................................... 66 Follow-up installations .................................................... 68 Snapshot considerations .................................................. 69 Integration with centralized applications ................................... 70 Lotus Notes integration .................................................. 70

Chapter 5

iConsole
Software components .......................................................... 71 iConsole architecture .......................................................... 72 iConsole registry values ........................................................ 73 Deployment procedure ......................................................... 74 Pre-deployment tasks .......................................................... 74 Requirements: servers .................................................. 74 Requirements: browser host machine .................................. 78 Version check utility: Wgncheck.exe ................................... 78 Set up SMTP e-mail ....................................................... 79

6

CA DLP Deployment guide

Deploy the iConsole ............................................................ 81 Before installing............................................................ 81 Install the iConsole ........................................................ 81 Post-deployment tasks ......................................................... 82 Install iConsole searches and reports ........................................ 83 Install default searches and reports ................................... 83 Set up the Review Queue ................................................ 83 Set up iConsole connectivity .................................................. 84 Rename IIS virtual directory for front-end Web server ............. 84 Connect iConsoles to multiple CMSs ................................... 84 Enable pre-authentication Enable anonymous access ............................................. 85 .............................................. 86

Specify disallowed characters in logon passwords.................... 86 Specify a non-default TCP port ......................................... 87 Hide user logon credentials in the iConsole .......................... 88 Set up iConsole timeouts ...................................................... 90 Modify the session timeout .............................................. 90 Modify the event timeout ................................................ 91 Modify the Web Service timeout ........................................ 92 Modify the results conversion timeout ................................ 92 Set up search results handling ............................................. 93 Specify the default format for downloaded search results ......... 93 Specify the format for downloaded e-mails .......................... 94 Creating an additional download button on the toolbar............. 94 Setting the default format for displaying search results ............ 95 Configure how many participants are displayed .................... 96 Configure the search results cache ................................... 97 Set up event auditing .......................................................... 99 Set up the auditing feature .............................................. 99 Enable time recording for reviewed events ........................... 99 Configure audit e-mails ................................................100 Specify an address mask for audit e-mails .........................102 Specify the LDAP attribute used to populate To, Cc and Bcc lists .. 103 General setup tasks ...........................................................104 Modify the iConsole log file registry values ..........................104 Set up iConsole servers for Network Load Balancing ...........105 Set global preferences ..................................................107

Contents

7

Start the iConsole ............................................................ 107 Defining new iConsole event searches .................................... 108 Back up search files .......................................................... 109 About single sign-on ......................................................... 109

Chapter 6

Install iConsole searches and reports
Available searches and reports ............................................. 111 Compliance reports ...................................................... 112 Dashboard ................................................................. 112 Incident reports .......................................................... 112 Issue reports .............................................................. 113 Review Queue ............................................................ 113 Standard Searches ....................................................... 114 Additional notes .......................................................... 114 Requirements .................................................................. 115 CA DLP requirements ................................................... 115 Supported databases .................................................... 115 Oracle user privilege .................................................... 115 iConsole dashboards .................................................... 115 Database configuration ...................................................... 116 Primary user requirements for iConsole dashboard ................ 116 SQL Server CMSs: SQLAgentUserRole role ............................ 116 Installing searches and reports ............................................. 118 CMS ......................................................................... 118 iConsole application servers............................................ 118 iConsole front-end Web servers ....................................... 118 Setting up dashboard data aggregation ................................... 119 Configurable aggregation parameters ............................... 119 Configure the aggregation .............................................. 120 Aggregation parameters ................................................ 121 AF1, AF2 and AF3 aggregation parameters .......................... 124 Change the aggregation frequency.................................... 124 Manually schedule aggregation jobs for SQL Server Express ...... 125 Event totals can appear incorrect when drilling into snapshot data.. 126 Report customizations ....................................................... 127 Incident Rate By Policy Report......................................... 127

8

CA DLP Deployment guide

Chapter 7

Quarantine Manager
Quarantine Manager architecture ..........................................130 Pre-deployment considerations..............................................131 If using e-mail client agents and the Exchange server agent ......131 Multiple Quarantine Managers ..........................................131 If using a Milter MTA agent, some e-mails may not be quarantined . 131 Deploy the Quarantine Manager .............................................132 Specify a QM domain user ..............................................132 Allow access to the designated mailbox ..............................134 Install the Quarantine Manager ........................................135 Configure the Quarantine Manager ....................................135 Mark e-mails for Quarantine ............................................135 Log files ...................................................................135 Quarantine Manager registry values .......................................136 E-mail release procedure .....................................................140 Automatic release of timed-out e-mails ..............................140 Failure to forward released e-mails ...................................140 Encrypted e-mails.........................................................140

Chapter 8

Secure private tunnel
Configure the secure private tunnel .....................................142 Certificate management ...............................................142 Generating authentication certificates ...............................142 Configuring the secure private tunnel ...............................145

Chapter 9

Account Import
Synchronizing users............................................................147 Synchronizing e-mail addresses ............................................147 Import methods and sources .................................................148 Import methods ..........................................................148 Import sources ............................................................148 Account Import log files ......................................................149 Account Import privileges ....................................................149 Account Import wizard .......................................................150 Command line import operations ...........................................158 Set up Secure Sockets Layer (SSL) .....................................159

Contents

9

Parameter files ............................................................... 160 Parameter rules .......................................................... 161 Operation parameters ................................................... 161 Data source parameters................................................. 161 LDAP logon parameters ................................................. 162 Source container and target group parameters ..................... 162 Error handling parameter ............................................... 164 LDAP filter attributes.................................................... 165 Source and target file parameters .................................... 165 Comment markers ....................................................... 165 User mapping and identification parameters ........................ 165 Example parameter file ................................................. 167 Multiple attribute values .................................................... 168 Importing a single LDAP attribute with multiple values ........... 168 Combining multiple LDAP attributes in single CA DLP attributes. 168 Command files to import users ............................................. 169 Command file format.................................................... 169 Format notes ............................................................. 172 Group and user name requirements................................... 173 Example group path ..................................................... 173 Example Command file 1: new users and groups ................... 174 Example Command file 2: user properties ........................... 175 Command files to import machines ...................................... 176 Import from a command file ........................................... 176 Command file format.................................................... 176 Example Command file ................................................ 177 Modify LDAP values with conversion expressions ....................... 178 Conversion expression syntax .......................................... 178 Section syntax ............................................................ 179 Conversion expression variables ..................................... 179

Chapter 10

Object storage
Overview ....................................................................... 183 Concurrent use of multiple object stores ........................... 183 Integrating with EMC Centera .............................................. 184 About Centera integration.............................................. 185 Set up Centera integration ............................................ 187 Configure Centera integration ........................................ 187

10

CA DLP Deployment guide

Integrating with IBM DB2 Content Manager ...............................189 About IBM Content Manager integration ..............................190 Set up IBM DB2 Content Manager integration ........................191 Configure Content Manager integration ...............................192 Integrating with NetApp SnapLock .........................................194 Set up SnapLock integration ............................................194 Temporary object store ......................................................195 How are CA DLP events stored?.........................................195 Configure the temporary object store.................................195 Managing the temporary object store .................................196 Optional data location structure .......................................197

Chapter 11

Policy engines
Overview ........................................................................199 Policy engine architecture ................................................200 Deploy policy engines ........................................................201 Active and standby policy engines ....................................201 E-mail address mapping .................................................201 Policy engine requirements ............................................202 Specify user accounts .......................................................203 Specify a PE domain user ..............................................203 Create a corresponding CA DLP user ..................................203 Install policy engines .........................................................204 Configure policy engines .....................................................205 Configure the local machine policy ...................................205 Configure the policy engine registry values ..........................208 Monitor policy engines ........................................................210 Performance counters ...................................................210 Log files ....................................................................210 Uninstall policy engines.......................................................210 Policy engine maintenance...................................................210

Chapter 12

Policy engine hubs
Policy engine hub architecture .............................................212 Hub event queues ........................................................213 Registry flow chart: e-mail processing on the hub ......................214 Deploy the policy engine hub ..............................................215 Host machine requirements ..........................................215

Contents

11

Install the hub ................................................................ 216 Automatic installation with server agents ........................... 216 Configure the hub............................................................. 217 Modify the hub registry values ......................................... 217 Assign security privilege to the PE domain user..................... 217 Policy engine hub registry values .......................................... 218 Policy Engine Hub key ................................................... 219 Policy Engines subkey ................................................... 222 DefaultSettings subkey .................................................. 222 <Machine name> subkey ................................................ 222 Queues key ................................................................ 222 <Queue name> subkey .................................................. 223 Security key ............................................................... 223 Hub maintenance ............................................................. 224 Stop the policy engine hub ............................................ 224 Monitor policy engine hub activity ......................................... 225 Performance counters .................................................. 225 Log files .................................................................. 226 Uninstall policy engine hubs .............................................. 226

Chapter 13

Import policy
Direct mode and hub mode.................................................. 227 Which imported e-mails are converted into events? ................... 227 Import policy versus server agents ......................................... 228 Architecture diagrams........................................................ 229 Direct mode ................................................................... 230 Install Import Policy in direct mode .................................. 230 Configure the Event Import job........................................ 230 Hub mode ..................................................................... 231 Specify user accounts ................................................... 232 Install a remote policy engine ......................................... 232 Install Import Policy in hub mode ..................................... 233 Configure the Remote PE Connector ................................. 233 Configure the Event Import job........................................ 234 Event Import parameters ................................................... 234

............................................................................................................255 Uninstall Exchange or Domino server agents ...........260 Applying policy triggers to Sendmail and Postfix e-mails..............................................257 Turn on ISS SMTP integration ......................................................................256 IIS SMTP integration .................237 Host machine requirements .....260 Deployment architecture .....262 Create user for Milter MTA agent ...............261 Host machine requirements .......................................12 CA DLP Deployment guide Chapter 14 E-mail server agents E-mail server integration .....257 Host machine requirements ...................................................................237 Deploy policy engines ......................................................260 Deployment process ...262 Configure Postfix.......247 Turn on Exchange or Domino integration ...................253 Monitor the Exchange and Domino server agents.................255 Diagnostic files for Exchange server agent ..........................................................................251 Warnings and follow-up messages....................................238 Configure the Exchange or Domino agent ..........................258 Sendmail and Postfix integration .........250 Set up server-side interactive warning messages ...............................................................................................................................................................................................................................................237 Install a Exchange or Domino server agent ...238 Configure the hub ..............................................................241 Automatic registry values ...........262 Deploy policy engines ..............236 E-mail integration: server-side versus client-side .................................236 Exchange 2007 server agent .................................236 Deploy the Exchange or Domino server agent .......257 Configure the IIS SMTP agent ...238 MIME configuration for Domino servers ..........................................257 Install the IIS SMTP agent.....................................257 Hosting a CA DLP service for use by other organizations ...................251 Deployment procedure ...........................................................................................................................................................................................242 Manually created registry values ............255 Log files ......................239 E-mail server agent registry values ..................262 .....262 Deploy the Socket API and a remote PE connector ..................................

........................... 276 Applying policy to scanned items..................................................... 270 Uninstall the Milter MTA agent ......................................................................... 273 Chapter 15 File Scanning Agent (FSA) About the FSA ............................................................................................................... 285 ........................................................................................................ 270 Stop or start the Milter MTA agent ....................... 266 Turn on Sendmail and Postfix integration .. 271 Prevent users receiving multiple notifications from single e-mail 271 Prevent repeat processing by server agents in multiple domains 271 Using e-mail client agents and e-mail server agents together ..................................................... 270 E-mail integration issues......................................................... 278 Database scans ................. 281 Deploy a NIST database . 276 Scanning jobs .....................conf parameters ............................................................................................................................................... 279 File hashes ................................................................................ 272 Integration with an Exchange Server cluster ....................................................................................................................... 276 File system scans..................................................................... 279 DSN .................................................................... 278 FSA terminology .......................................................... 266 Wgnmilter........... 279 FSA architecture ................................................Contents 13 Configure Sendmail integration ....................................... 273 Configure all Exchange server agents.......................... 279 Scanned file database ........................................................................................................... 264 Configure the Milter MTA agent .... 279 NIST database........... 276 SharePoint scans ............................................................................... 284 FSA Run As user .......................................................... 277 Exchange Public Folders scans .............. 284 FSA job setup user .... 283 Install database client tools ................ 283 Specify FSA user accounts .................................................................... 281 FSA requirements ................................................. 280 Deploy the FSA .......... 279 DoD deletion ....................... 263 Install the Milter MTA agent.............................. 270 Disable or enable integration ........ 284 FSA service user ........... 272 Do not release ‘dead’ messages in Domino Administrator ......

.....299 Uninstall the FSA......................286 Configure the hub................................................................................298 Do I use multiple scanning jobs or multiple FSAs? ....................298 Can jobs overlap? ........306 Which policies are applied? ...........294 Add a scanning job..............................288 Why deploy an FSA Remote Connector? ..........14 CA DLP Deployment guide Install the FSA .......................292 Which user policy gets applied? .............................................293 Apply smart tags to scanned items...................................................................................................304 How does the CFSA apply policy to protect files? ...................................................................288 Install the FSA Remote Connector........ network folders 303 CFSA flow chart: scanned files on local hard disk .........................311 ....289 Set up CA DLP policy triggers ..............................306 Configure the local machine policy ...........................................299 Chapter 16 Client Agents: File and Print About the Client File System Agent .....298 How do I delete a scanned file database?.................304 Terminology .......................................................................................302 What filters does the CFSA use? .................................294 Run a scanning job....295 Schedule a scanning job ............................297 Scanning job FAQs .........................292 Data At Rest triggers .......294 Scanning job log files.....288 Configure the FSA ..................................................................................... CD drives............................292 Data At Rest control actions .............................................................................................................302 CFSA flow chart: Removable devices.................................297 Purge the scanned file database ............................................................305 Deploy the CFSA ...................................................................................................307 Configure the user policy ....................................296 Stop and restart a scanning jobs .......................................................................................287 Deploy FSA Remote Connectors ...............................................................287 Securely store logon credentials for database scans .............................................293 Scanning jobs ...................................298 How are scanned items associated with CA DLP users? ........................................298 What happens if no event participant is specified? ................................................................

..................................................................... 332 Configure Enterprise Vault integration .......................................................................................... 331 Register the EV archive agent............. 342 IBM DB2 CommonStore for Lotus Domino ................ 326 ZANTAZ EAS integration .. 328 Symantec Enterprise Vault integration ................ 315 Deploy the CPSA........... 327 Set up EAS integration ......... 318 Chapter 17 Third party integration Integration components........................ 351 ..... 324 CA Message Manager integration .................................................... 314 What filters does the CPSA use? .................................................. 340 Install CommonStore for Exchange .......................................................................................................Contents 15 About the Client Print System Agent .................................. 329 About Smart Tagging ................................................................................................................. 340 Configure integration with CommonStore for Exchange ............................................. 321 Model 1: Push from archive .............. 338 Turn on Enterprise Vault integration ....... 314 CPSA flow chart .................... 339 Deployment procedure .............. 316 CPSA optional registry changes ..... 328 Retrieve archived events with RDM ............................... 316 CPSA user policy changes ................................................ 330 Deployment procedure ..................... 333 Install and configure RDM ................................... 322 Model 3: Push to archive (via mailbox) ........................................ 325 Set up CA Message Manager integration .............................................. 314 Which user policy is applied?.... 331 Set up Enterprise Vault integration ..... 338 IBM DB2 CommonStore for Exchange .................................................... 323 Comparison of ingestion methods into CA DLP .......................................... 319 Supported archive versions ................................................................................................................... 321 Model 2: Push to archive (direct) .................................................................................. 320 Integration models ...................................................................................................................... 348 Deployment procedure ................... 328 Configure EAS integration ................................................... 349 Configure integration with CommonStore for Domino . 349 Install CommonStore for Domino ......................................

.....................................................................................................................369 Integrating programmatically with the External Agent API ..........372 Socket API ....................................................382 Deployment procedure...............................381 Monitoring the Socket API ..........................................372 Configuring the External Agent API ...............................358 Deployment procedure ....................................................................374 Requirements .............................................369 Installing the External Agent API .391 Support for multiple RDM servers ................................364 Set up EmailXtender integration .........................................16 CA DLP Deployment guide ZANTAZ Digital Safe integration ......384 Import DN details to CA DLP user address lists ...383 Configuring the proxy server and ICAP client .......................................................388 Post-installation tasks ...........388 RDM requirements .........................................384 Configuring the ICAP agent ........................................................................374 Socket API throttling ...374 Installation methods.........................................................................367 Configure SourceOne business components.............................383 Install the ICAP agent and PE hub ......................................................369 Requirements .........365 Configure EmailXtender integration .....................................................................................391 .......369 Output destinations ..................................370 EVF file cache guidelines ...................385 Remote Data Manager..................388 Install the RDM ........381 ICAP Agent .............................366 Deployment procedure....................365 EMC SourceOne for Exchange integration ....................................................390 Do not rename archive servers .....................................................................................................................................367 Set up SourceOne integration.....368 Retrieve archived events with the RDM ......................................................................................................................................365 Retrieve archived events with RDM ..................................................................................................................................................374 Configure the Socket API ............358 Secure communication based on SSL authentication ...............................................................357 About the Digital Safe Adapter ...............359 Set up Digital Safe integration ..................368 External Agent API ..........................................359 Configure Digital Safe integration ....................361 EMC EmailXtender integration ...................................................................

........................................... 403 Multiple import operations ....... 401 Individual import operations ........ 414 E-mail general parameters ...... 405 Import failures .................................................................................................................................. 396 Synchronize e-mail accounts and CA DLP users ................................................................................................................................................. 409 Event Import parameters ................... 404 Event Import types .... 400 Logon requirements for Event Import .... 419 File handling parameters ......................................... 410 Import type parameter ...... 400 Installing Event Import .......................................... 395 Identifying the owners of imported e-mail events........ 406 Imported events cached if replication fails......................................................................... 401 Continuous import operations........................ 408 Bloomberg message attachments .................................................................... 408 Example import configuration file ......................... 397 Single import operations only from each Exchange mailbox ..................... 398 Event Import operations .................................................................................. 406 Continuous jobs importing from PST or MSG files... 396 Filtering e-mail import operations ........ 407 Event Import log files .......... 396 E-mails ignored by Event Import.......... 399 Event Import requirements .............................. 413 Engine parameters .................................................................................Contents 17 Chapter 18 Event Import Software components ........................................................................................................................................................................................................................... 406 Remote CMS import failures ......... 423 ...... 397 Support for Exchange envelope journaling ............ 407 Template configuration files ........... 396 Events abandoned by Event Import ............................................................................ 406 Batch jobs importing from files................................. 408 Import template files....................................................... 401 Running an Event Import operation ...................... 399 Logon requirements for the CMS............................... 402 Scheduling remote CMS import jobs .......................................................... 398 E-mails sent from Outlook 2003 in Cached Exchange mode ....................... 406 Exchange mailbox import jobs ..... 394 Importing from e-mail archives ...............

.........................436 File import parameters ........................................463 Install Cnv2email..................441 Chapter 19 IM Import About IM Import ........430 PST file parameters ...............................................................................................................435 Bloomberg e-mail parameters ..434 EML file parameters ..............................................................................466 .........................465 Bloomberg e-mail conversion process .......................................................................................452 Parameter requirements..............................................................465 Converting Bloomberg e-mails to EML e-mails .....464 BB2email.exe) ...........463 Converting IM conversations to EML e-mails.......................................................426 NSF file parameters ..............................................18 CA DLP Deployment guide Exchange Server import parameters .................................453 Configure IMlogic dump files .450 Mapping IM conversations to users ..................................................463 IM conversion process ......................................................................................................................................................................451 Embedding IM conversations in e-mails ..............................................................................................................................exe ..........................452 IM Import parameters (IMFrontEnd........437 Remote CMS Import parameters ........462 Cnv2email........................465 Install BB2email......................................................exe .....................exe utility ..........451 Deploy IM Import........................................460 Chapter 20 EML utilities: Cnv2email and BB2email EML utilities: deployment architecture .....................................................................exe utility .........466 Run a Bloomberg e-mail conversion job................452 Software requirements....................................................................................452 Installing IM Import .......465 Ingesting attachments ...............450 Supported IM formats ..........464 Run a CNV conversion job ...........451 How is the IM network assigned? .............

........................................................ 493 Chapter 24 Log files About log files ................................. 490 Chapter 23 Backing up and restoring the CMS Database backup tasks .............................. 491 Back up the Data folder... 467 Configure policy engines to detect embedded content e-mails ............................ 496 Log file types ..... 467 Conversion parameters .. 481 Which events are extracted? . 469 UE requirements . 488 Which features use e-mail address mapping?.........................................................................................Contents 19 Embedded content details saved in EML x-headers ........................................................................................................................ 482 Monitor metadata extraction jobs..................................................................................................................... 481 Format for XML output files ......................... 492 Restoring the CMS..................................................................................................................... 482 Archive acknowledgements............. 482 Extraction job parameters......................................................................................................................................................................... 480 XML metadata extractor ......... 489 Synchronizing e-mail accounts addresses ................... 477 Chapter 21 Universal Extractor XML schema for UE job definitions .................................. 490 E-mail address FAQs ......... 498 ...................................... 491 General backup tasks.................................... 477 Run an extraction job .......... 467 Custom x-headers in EML e-mails contain event details ....... 482 Chapter 22 Mapping e-mail addresses to users Address mapping procedure .............. 493 Restoring a CMS ............................................................................................... 496 About policy incident logs .................................................................................... 495 Log file names ........................................................................................... 491 Back up the master encryption key .................... 481 How is event metadata selected for extraction?... 478 Example job definition ...........

...506 Prevent automatic start-up: DisableAutostart......500 Configuration for non-infrastructure logs ..............500 Policy configuration for specific log types .............................mst .........................519 Manually uninstalling CA DLP ...........................................................................................................................509 Operations ........499 Configure log files ....................................................518 Account credentials operations.............................................................503 Chapter 25 Technical information Performing an administrative installation ..................................................499 View log files in the Administration console.............................mst .....512 Standalone installations .....................................516 Installing a standalone to demonstrate client agents ..........507 Install application integration: EnableAppmon.506 Prevent consoles being installed: HideConsole........................................506 Identify the CMS: SetParentName...........................................502 Registry configuration..........................508 Silent uninstallations for SMS: SMSQuietUninstall.......................................516 Installing a full-featured standalone ............................mst ..mst ........................508 Stopping and restarting the infrastructure ...499 Where are log files saved?.....505 Installation transforms ..520 ........................................................................502 Machine policy configuration ........................510 Database variables...................................exe ....................................................................................mst ...........................................................................507 Configure Outlook client agent: EmailClientOptions.503 Machine policy configuration ............518 Supported components............................509 General variables ...........mst ........................508 Command line parameters for Msiexec............................................500 Write to the Windows event log .........exe ...............mst ...................................20 CA DLP Deployment guide Viewing log files ...........................................507 Prevent unauthorized uninstallations of CA DLP: ClientLockDown..........................502 Write to Syslog servers ................................................................500 General log configuration in machine policy ..........................................................517 Prevent standalone installations ......517 Set account credentials with wgncred.............

................................................... 535 CA DLP installations on 64-bit machines ................................................... 522 Import a CMS profile..............Contents 21 Importing and exporting CMS profiles ................. 527 Wgnpol...................................................................................... 536 Exchange 2007 server agent and policy engine hub ...................... 541 Displaying Far Eastern characters ........ 534 Cache configuration .................................... 524 Controlling port allocation .............. 525 Configuration changes to support an Internet firewall or router 526 Export...................... 522 Retain existing properties .................................... 522 Export a CMS profile . 534 Reset the holding cache ........................................................ 540 Laptop users and dial-up connections .............. 539 Stopping or starting the infrastructure without rebooting ................. 540 Far Eastern characters .......... 523 Allocating UDP and TCP ports .................................................. 527 Wgnpol........ 540 Policy engine upgrades from version 3........ 541 Do not use Far Eastern characters in installation paths ... 523 Reset CMS profile default properties ....................................... import and copy policies ......... 542 Failure to generate e-mail events ........................... 542 Unable to expand distribution lists with hidden membership.................... 524 Example communication sequence...................................................exe examples .......................................................................................... 524 Reallocating default port numbers .........0 ............................................. 531 Replication holding cache .......exe command line syntax .................. 539 Do not install to encrypted folders.................................................... 542 Multiple notifications in response to a single e-mail .............................................................................................. 543 ............................................... 540 Policy engines ............. 541 Computer names with Far Eastern characters............................................................ 541 E-mail server agents......................... 536 Chapter 26 Known issues General deployment.............................................................. 534 Managing the cache ..............................................

...................................................548 iConsole ..................547 Do not quarantine encrypted e-mails captured by server agents ...........550 Display problems due to IE Enhanced Security Configuration......................................................................548 RDM............................................547 Encrypted e-mails decrypted when released from quarantine ...........544 Imported e-mail timestamps are truncated ........................................................544 Cannot access an Exchange mailbox ...........549 Problem with multiple iConsoles on the same client machine ..................548 Firewall configuration on Windows XP SP2 and 2003 SP1..550 Index.............................CNV cache to improve import performance .......547 Mismatch between participants information .............................msg file .....546 Bloomberg IM dump files are in US ASCII format....................................546 Increase size of ......22 CA DLP Deployment guide Event Import .....545 Cannot import unparented e-mails from a Notes database ..............549 Unable to download or forward original .......1 ........2..............546 ‘More recipients’ entries are ignored...................545 NSF import and ‘End MIME to CD Conversion’ messages .546 Timestamps in IB Unified dump files are in EST ................................................................546 Format requirement for imported attachments ..........547 Quarantine Manager .........545 IM Import ...................................................547 Anomalous Join and Leave chat room actions....... EAS and Windows 2003 ....................................................................................544 Importing from Exchange requires MAPI and CDO 1.............................549 Unable to send audit e-mails ..................549 HTTP 404 error when browsing to the iConsole URL ..............551 ..546 Identifying conversation participants....................................................547 Windows XP and 2003 .....

chapter 1 T Deploying CA DLP After installing CA DLP on your CMS. Database tasks Before installing the CMS or a gateway. .1. Contact Technical Support To contact Technical Support. plus details about purging and backing up your database. Introduction Introduction his chapter outlines the recommended methods for installing and deploying CA DLP.out. you can install CA DLP on as many gateways and client machines as your license agreement permits. Known deployment issues are also covered in chapter 25. CA DLP currently supports Oracle and SQL Server database engines. gateways and client machines. and incremental backups on a daily basis. Technical information. your chosen database engine must already be installed and correctly configured on the target server. some further configuration is needed before continuing with the deployment.com/support If you do contact Technical Support. These take the format: stderr_200201200945. For configuration guidelines. We also recommend that you make a full backup of your CMS at least once per week. It also presents the hardware and software requirements for the Central Management Server (CMS). go to: http://ca. they may ask you to supply the following log files: The infrastructure log file. wgninfra. see page 499. When this is complete. Any relevant system log files. These are all located in CA's \data\log subfolder of the Windows All Users profile. All of these tasks are described in the following chapters.log. please refer to the Database guide.

or Data Management console. (Note that you can purge this captured data as soon as it has been replicated to the CMS.0. Note: ` Microsoft Windows Server 2003 or 2008 CA DLP servers need sufficient memory and processing power to run your chosen database application. for SQL Server 2005. The supported databases are: ` The CMS needs sufficient free disk space to store data captured on all client machines. ` Oracle 10g ` Microsoft SQL Server 2005 Recommended: SQL Server 2005 SP2 ` A gateway server needs enough free disk space to store data captured on the client machines that it serves. search the index for ‘SQL Server 2005’. Windows Installer Windows Installer 2. gateway servers and utility machines Item Operating System Database Details Item Disk space Details 20Gb Ultra ATA or SCSI This storage estimate covers the CA DLP infrastructure. Also. 3.0. See your database documentation for details. See the Database guide.) See also the ‘Calculate disk space values’ section on page 46. be aware that because CA DLP is an IE extension. you require: Microsoft Internet Explorer 6 or 7 . consoles and captured data (based on typical usage rates). Browser integration Microsoft Internet Explorer 6. 7 or 8 i If using Internet Explorer 8.24 CA DLP Deployment guide Hardware and software requirements CMS. ` Microsoft SQL Server 2005 Express Edition Not recommended for CMSs ` Microsoft SQL Server 2008 i SQL Server supported on Windows servers only.0 Console To run the Administration console. 3.1 or 4. ensure that the SQL Server Browser service has started. it will be disabled if InPrivate Browsing is enabled (this is an IE safety feature) on the CA DLP host machine.

6. XP. You also need sufficient free disk space to store captured data in a local database. 7. or 8 ` Microsoft Internet Explorer 6. you require: Windows Installer Windows Installer 2. 3. File system integration Print integration The CFSA requires Windows XP SP2 or later Before installing the CPSA. or Vista ` Microsoft Internet Explorer 6. close down any applications that are running. 3. 7 or 8 i For details about CA DLP and the Windows XP SP2 firewalls. see ‘Known Issues’ on page 548. For details.0 Console ` Microsoft Windows 2003. be aware that because CA DLP is an IE extension. To run the Administration console or Data Management console. see page 55. or 2007 ` Lotus Notes Release 6. (Note that you can purge this captured data as soon as it has been replicated to the parent server. Item E-mail integration Details ` Microsoft Outlook 2003. i If using Internet Explorer 8. it will be disabled if InPrivate Browsing is enabled (this is an IE safety feature) on the CA DLP host machine. the Client File System Agent (CFSA) requires SP2 or later.0.0. 7 or 8 ` Integration with the Microsoft Outlook browser requires Microsoft Internet Explorer 6. 7 or 8 . Browser integration Memory Disk space 128MB You must allow approximately 45MB for the CA DLP infrastructure plus an Administration console.) See also the ‘Architecture’ on page 28.1 or 4.Chapter 1 Introduction 25 Hardware and software requirements Client machines Item Operating System Details Microsoft Windows Vista or XP On XP machines.5.

4. CA DLP server .PST import operations.0. or 2007.26 CA DLP Deployment guide Hardware and software requirements Event Import and Import Policy machines Item Host server Details You must install Event Import and Import Policy on a gateway server—see page 24 for their requirements. E-mail server agent and policy engine hub Host machine Operating system Exchange server agent Domino server agent Details Microsoft Windows 2003 ` Microsoft Exchange Server 2003 or 2007 Lotus Domino 6.0. i For .5.0.4. It may work with other versions. See page 202. 7. i Integration has been tested using the Domino versions listed above. 6. or 8 E-mail Exchange import: Host machines must be running an Exchange-compatible e-mail application such as Outlook 2003. 6. Notes import: Host machines must be running Lotus Notes 6.2.5.5. The host machine must be the CMS or (recommended) a gateway. note also the Outlook requirement on page 405. or 8 Policy engine host machines Host machine Operating System Disk space Details Windows 2003 The host machine needs sufficient memory to cache all ‘effective’ user policies. 6. 7. E-mail server Exchange server: 2003 or 2007 Lotus Domino server: 6. 7. but these have not been tested. ! This must be the default e-mail application on the host machine.2. or 8.0.

Net Framework 2.0. The can only process e-mails extracted from Microsoft Exchange Server 2003—see page 331. 6. see page 74. 7 or 8 Browser host machines must be running: Adobe Flash Player 9 or later (minimum version 9.0) ` . see page 369. see page 359. . or 2007) or Lotus Notes 6.Net Framework 2. 2003. i For version details of all supported archive integrations. The host server requires: These requirements apply to the iConsole front-end Web server and application server host machines.124.0 Browser Dashboard Microsoft Internet Explorer 6. Operating System Web service Microsoft Windows Server 2003 or 2008 Enterprise Vault The host server requires: ` Microsoft Internet Information Services (IIS) version 5 or 6 ZANTAZ Digital Safe ` . i For full External Agent requirements.Chapter 1 Introduction 27 iConsole machines Item Details Archive integration host machines Archive ZANTAZ EAS Details You need to install the External Agent API on the EAS server—see the next table. or 8. External Agent machines Item Operating System E-mail Details Microsoft Windows Server 2003. The Dashboard requirement applies to browser host machines. 2008. i For full iConsole requirements.5. 7. Windows XP or Vista Host machines must be running a Microsoft Exchange-compatible e-mail application (such as Outlook 2002. see page 320.0 ` Web Services Enhancements (WSE) SP3 ` Outlook 2003 For details.

The CMS acts as a central repository for all policy details and captured data. Similarly. When this is complete. gateway servers. Event Import machines. . captured data and local policy changes are copied automatically up to the CMS. These changes can include policy updates and modifications to user and machine accounts. 3 4 2 4 Upgrading CA DLP For details about upgrading CMSs. this is not possible and an upgrade rollout can easily take several weeks. Do this during a period of minimal user activity. and so on) at the same time as the CMS. you need to understand how CA DLP handles data transfers (policy changes and captured data) between machines running different versions of the product.0. 2 Gateway servers. You manage CA DLP using a console. please see the Upgrade guide. Below the CMS. policy engines. and each gateway can serve multiple client machines. Full details about version compatibility are provided in the Upgrade guide. 3 Client machines. Version compatibility Ideally. For these reasons. Likewise. Before starting the rollout.0 to optimize performance in many key areas and to support emerging customer requirements. that is. This need not correspond to your actual network topology. with the central management server (CMS) as the top level server. again via gateway servers. 5 Console-only machine. This guide highlights the essential issues you need to be aware of when rolling out an upgrade across your organization and describes the necessary post-upgrade tasks. In practice. each branch of the hierarchy is optionally managed by a gateway. when upgrading individual CA DLP machines we recommend that you upgrade all your CA DLP servers (gateways. these tasks are described in the Upgrade guide. 1 4 5 Example machine hierarchy CA DLP machines are organized in a virtual hierarchy. you will inevitably have different version machines operating alongside each other during the upgrade rollout. unforeseen complications may force you to upgrade some child machines before their parent server has been upgraded. You can deploy consoles on any machine in your CA DLP installation. 1 CMS. beginning with the CMS and then working down the machine hierarchy to each server successively. we also recommend that you upgrade your client machines as soon as possible to reduce the amount of event data that needs to be periodically upgraded. and client machines to the latest version of CA DLP. at intervals defined in the machine policy. 4 Consoles on CA DLP machines. two post-upgrade tasks are also required when upgrading to version 4. You can also have console-only installations. Database changes on the CMS are copied automatically via gateway servers to local databases on client machines. you can install the console without installing any CA DLP server software or client integration features—see page 42.28 CA DLP Deployment guide Architecture CA DLP machines are organized into hierarchical branches. Post-upgrade tasks The database schema was substantially revised in CA DLP 4. Because of this.

You must also install an Administration console: you will use the console to perform various configuration tasks before you roll out CA DLP across your organization. . backup and restore operations are described in chapter 23. 2 CMS. e-mails. ‘Backing up and restoring the CMS’. plus all the captured data (Web pages. it provides instructions for running the CA DLP server installation wizard (on Windows computers). ‘Client machines’. This chapter also highlights the various server requirements that you must address before installation. You must install the CMS before deploying CA DLP to client machines. CA DLP servers CA DLP servers his chapter describes how to install and uninstall CA DLP servers. gateways and utility machines. gateways and utility machines. ` CMS upgrades are described in the Upgrade guide. In particular. This database contains the policies for all your machines and users. Instructions for a console installations are given on page 42: 1 2 3 4 5 6 Administration console: CA DLP servers 1 Machine Administration branch. You manage CA DLP servers in the Administration console. 4 Client machines. 3 Gateway. CMSs. that is.2. i Note the following: ` Standalone ` CMS CMS installations are described in chapter 4. 5 Active utility machine. CMS (Central Management Server) The CMS holds the central database for your CA DLP installation. See also page 28. 6 Disconnected utility machine. and application events) associated with these users. transactions. chapter 2 T Server types This section summarizes the key characteristics of CMSs.

you need to configure your database and ensure that computer name resolution is operating correctly on your network. performance may be adversely affected. Choose a method of computer name resolution that suits the needs of your organization. see also page 28. Utility machines Utility machines inherit the common client machine policy. DNS or a WINS server. Utility machines enable you to run these components without overloading your existing CA DLP servers.3 file creation. but you must install a utility machine separately before installing an iConsole application server (page 81). The parent is either the CMS or another gateway—see the architecture diagram on page 28. For Oracle and SQL Server configuration guidelines. the Communications Encryption policy setting (in the Security folder) and settings in the Logging folder are relevant.3 file names For NTFS file systems. If you specify the CMS or gateway by its name. operating between the CMS and client machines. If 8. Before installing Before installing a CA DLP server. Database configuration Before installing a CMS or gateway server. we recommend that you disable creation of 8.3 file creation remains enabled. This enables you to deploy multiple gateways using a single source image (which identifies a single parent server) whilst ensuring that each gateway automatically connects to its 'correct' parent server immediately after installation. they will be unable to locate it. Gateway upgrades are discussed in the Upgrade guide.microsoft.com. you must ensure that the client machines can resolve this name. . To disable 8. The Event Import utility is described in chapter 18. The Event Import utility is also hosted on a gateway.support. Each gateway can serve multiple client machines and is connected to a single parent server.30 CA DLP Deployment guide Gateway servers Gateways are optional data-routing servers. you will need to identify its parent server (the CMS or gateway) by name or IP address.3 file names on the machine hosting the CA DLP data folder (see step 6 on page 33). you set the NtfsDisable8dot3NameCreation registry value to 1 (one) and reboot. you use the Account Import feature—see page 169. If they cannot do so. please refer to the Database guide. Gateways To simplify mass deployments. for further details. A utility machine is created automatically when you install a Content Proxy server (see page 462). Disable 8. for example. Event Import and Import Policy requirements: If you install Event Import or Import Policy on a gateway. Utility machines These act as Content Proxy servers or iConsole application servers. Server name resolution When you deploy CA DLP to client machines. For Content Proxy servers and iConsole application servers. search for this registry value on www. This type of hierarchical. the target server must meet the e-mail archive integration requirements—see page 26. ‘Event Import’. your chosen database engine must already be installed and correctly configured on the target computer. you can bulk create new gateway accounts and pre-assign gateways to parent servers in advance of the CA DLP rollout. distributed deployment provides resilience and network load balancing. i Gateways are optional. You can connect any client machine directly to the CMS if preferred. To bulk create new accounts.

IBM Content Mgr. ` Content Indexer Console: The console lets you specify which events to index. Policy Engines are normally installed on a gateway server. It is part of the Import Policy feature—see page 227. Enterprise Server This enables the local computer to function as a CA DLP server. Content Indexer Serv. see page 388. see page 204. Quarantine Manager: This component ensures that e-mails released from quarantine are sent on to their original recipients. ` Socket API: Enables you to call a policy engine from a remote location (via the External Agent API). Remote Data Manager: This enables the Data Management console to retrieve and display events archived in third party remote storage locations. ` Remote Policy Engine Connector: This installs a modified policy engine hub that enables Event Import to connect to policy engines. enabling the various components to run and communicate. Content Proxy Server Remote Data Manager Quarantine Manager CMS Storage Connectors EMC Centera Conn. ` Templates: This installs predefined import configuration files. For details. . see page 129. please contact Technical Support—see page 23. These can be customized as required—see page 408. Templates Content Services Content Indexer Con. the following features are available: CA DLP Server Enterprise Server Policy Engine Socket API Event Import Policy Engine Conn. including from a non-Windows system. This feature is normally installed on a utility machine. For example the CA DLP Network Boundary Agent uses the Socket API to analyze traffic leaving or entering the corporate network from the internet. Management Console Administration Console Data Management Console Documentation Custom Setup screen: Available server features Policy Engine: Policy engines permit CA DLP to integrate with Microsoft Exchange and other external e-mail sources. See page 401. ` Content Proxy Server: This installs the service that the CMS uses to connect to a content database. For details. Content Services: This installs the content proxy server and content indexer components that interact with the CA DLP infrastructure—see page 472. For details. Event Import: The Event Import utility can import e-mails and IM conversations from external sources such as Microsoft Exchange mailboxes. For details. service to index events into a Content database.Chapter 2 CA DLP servers 31 Server installation features When you install a CA DLP server. Exclude this feature if you want a console-only installation—see page 42. ` Content Indexer Server: This installs the indexing CA DLP Server This installs the CA DLP infrastructure.

plotting each major task. The first chapter summarizes the product architecture. instructions for setting up database purges. Event Import. Data Management Console: This allows reviewers to search for. policy engines and hubs. only the Administration console is installed with the Management Console. see page 184. Documentation This installs the following CA DLP manuals in PDF format to guide you through the various aspects of the CA DLP enterprise: Upgrade guide This guide is for administrators. and client machines to the latest version of CA DLP.32 CA DLP Deployment guide CMS Storage Connectors: This installs the connectors needed to implement third party object storage integration. reviewers and compliance officers. gateways. For details. The second chapter maps a route through the overall deployment process. It provides guidelines for creating and modifying event searches in the iConsole. and so on. iConsole search definition guide This guide is for administrators and DBAs. archiving and retrieval of large volumes of captured data. For details. This manual provides an overview of the overall process and summarizes the key deployment tasks. Exchange and Domino integration. This feature allows storage management. Management Console This enables the host machine to run these consoles: Administration Console: This enables administrators to manage users. ` EMC Centera Connector: This enables EMC Corporation's Centera content addressed storage (CAS) solution to integrate with CA DLP. configure and back up CA DLP. For details. train content agents. see page 183. view log files. and the Quarantine Manager. gateway servers. Deployment guide This guide is for administrators. see page 189. Deployment Overview CA DLP deployments can be very complex and vary from one organization to the next. It contains guidelines for setting up Oracle or SQL Server database engines. auditors. secure private tunnels. integration with third party storage and archive solutions. . machines and policies. content services. Separate chapters provide general indexing advice. ` IBM Content Manager: This enables IBM DB2 Content Manager to integrate with CA DLP. Import Policy. Account Import. view and update the audit status for captured and imported events. Separate chapters describe: installation methods for the CMS. It also includes reference information for stored procedures and XML search definition files. i By default. client machines and the iConsole. and information on database partitioning and backing up Oracle and SQL databases. then breaking each task down into a series of installation or configuration steps. It contains instructions for upgrading CMSs. It describes how to install. Database guide This guide is for DBAs. It is aimed at system administrators. It also highlights the essential issues you need to be aware of when rolling out an upgrade across your organization.

using the universal naming convention (UNC) or mapped network drive. policy engines. you cannot specify a network file share. note that three user accounts are created automatically—see page 38. In the Connectivity screen. In the Customer Information screen. 3 3. ` Utility Machine For guidance on when to choose a utility machine. search the index for ‘Data folder: remote. Remote locations and NAS devices are also described below. ` Specify a different location. This information is required for licensing purposes. In the Custom Setup screen. . note the warning below.2 Free disk space: To check whether the target volumes have sufficient free disk space for the selected features. ! Do not install the data folder to an encrypted folder or file system! Also. You can either accept the default location or click Change to specify a different location. specify the name and network location of the data folder. do not compress the data folder if you are using SQL Server.3 Other features: For details about installing Event Import. enter your user name and organization. In the Data Location screen. ! If you install to a non-default location. i See the recommendation to disable 8. go to step 7. or the RDM. ` Specifying a remote data folder: If you want to specify a remote location. run setup. please see: ` Event Import: page 401 ` Policy engines: page 204 ` Remote Data Manager: page 388 4 In the Server Type screen.1 Installation folders: To install these components to a non-default location. 3. ` Gateway You typically use a gateway to host Event Import or a policy engine. you can specify a network file share. 5 This section describes how to install a CA DLP server using the Windows server installation wizard.Chapter 2 CA DLP servers 33 Installing a CMS. enter the name or IP address of the parent server. you need local administrator rights on the target server. This may be the CMS or a gateway server. ` Central Management Server If you install a CMS. These are described on page 31. choose the features that you want to install. see page 30. This contains all the configuration data and captured data associated with the current server. gateway or utility machine. choose to install one of the following: \\NAS_device\share_name\target_folder Sharing and Security settings for the remote folder must allow Full Control for both the user running the installation wizard and the machine running the CA DLP Enterprise Server software.3 file names on page 30. For example: \\MyMachine\share_name\target_folder or 3. the target path must not include folders whose names contain Far Eastern characters. gateway or utility machine i To install a CMS. See the Database guide. Find this in the \Server folder on your CA DLP distribution media. The CA DLP infrastructure cannot handle these paths. This is a known issue. and SQL Server’. For gateways and utility machines only. i For SQL Server users. If you: 6 2 ` Accept the default location. click the Change button. click the Disk Space button. 1 To launch the CMS installation wizard.exe.

in the Data Location screen.2 Depending on your chosen database engine.1 You can select a local or remote database. enter details about your chosen database. the installation wizard displays details about the database here. for example because it is not switched on. Now go to step 13. 9 10 In the Database Identification screen. Choose Oracle or Microsoft SQL Server. in the Data Location screen. 1 2 ` If this is a wholly new installation. If you want to re-use this database and the original Data folder. In either case. no further configuration is required. you must specify the host server (enter localhost to specify a database on the local machine) and the TCP/IP port number used by the host server. The installation wizard attempts to validate this SID if you chose the current machine as the host server. go to step 9. you need to supply further details. The SID corresponds to the SID_NAME value in the listener. Go directly to step 19.34 CA DLP Deployment guide 7 The next step depends on whether you are reusing an existing CA DLP database: 11 Oracle database You must provide an appropriate service identifier (SID) to identify the correct database. ` If an existing CA DLP database is detected. 3 Database SID. go to step 12. the wizard adds a Bypass Database Validation check box to the screen. You can select this check box to skip the validation.ora file on the Oracle host server. and the installation wizard does not detect any existing CA DLP database. ` SQL Server. the installation wizard displays details about the database here. simply click Next. if the installation wizard is unable to validate the host server. In the Database Type screen. go to step 9. For: ` Oracle. select the database engine that you will use on the current server. . go to step 11. 10. 2 Port number used by the host server. 3 Installation wizard: Database Identification screen for Oracle 1 Server hosting the database. If you do not want to re-use this database or you do want to re-use the database but in step 6 you specified a new Data folder. otherwise the installation will fail! 10. i Regardless of the type of database engine. but you must ensure you have correctly spelt the server name. 8 If an existing CA DLP database is detected.

` Search User: The CA DLP consoles use this account when running event searches. see the Database guide. change the default name to the name used in SQL Server. Where <machine name> is the name of the server on which SQL Server is running. i For SQL Server 2005 databases. Some organizations choose to have separate accounts for the primary user and the database owner. This ensures that reviewers cannot see events associated with users outside of their management groups. you must ensure that the SQL Server Browser service has started. all you need to do is select the host server. 3 Port number used by the host server. you can specify existing database accounts or instruct the wizard to create new ones. the primary user owns the schema. 5 Database name. and <Instance name> is the name of the SQL Server instance. You do not normally need to change this. If you specify existing accounts. the dialog identifies each instance as: <machine name>\<Instance name> For example. This dialog lists any servers found to be hosting SQL Server. This is typically for security reasons. though both can be changed. 12. MyDBServer\Instance_1 ` Schema Owner: Only available for Oracle CMSs. 4 Port button. But if necessary. to ensure that employees cannot connect to the CMS database as the primary user and delete sensitive data or drop the underlying database objects. This optional account owns the database schema. In all cases. click the ‘Port’ button to manually set the port number. For details. 2 Server button. you must ensure that they have appropriate roles and privileges. . the IP port and database name are then set automatically.1 Click the ‘Server’ button to select the host server in the Database Server dialog. This defaults to: WGN_<local machine name> For example. WGN_CMS-HARDY Where <local machine name> is the name of the server on which you are installing the CMS (CMSHARDY in the example above). 1 2 3 4 12. The requirements for your Oracle users or SQL Server logins are provided in the Database guide. ` Primary User: This is the main CA DLP database login. In the case of multiple SQL Server instances running concurrently on the same computer.3 Enter the database name. for example. This is a secure account that is subject to ‘row level security’ when searching the database for events. 12.2 The IP port is set automatically when you choose the host server. search the index for ‘SQL Server 2005’. you must specify the database accounts used by CA DLP to access the CMS database: 5 Installation wizard: Database Identification screen for SQL Server 1 Database host server. For SQL Server databases. 13 In the Database Accounts screen. If you have already created a database for CA DLP.Chapter 2 CA DLP servers 35 12 SQL Server database Typically.

go to step 15.1). optionally for Oracle CMSs. otherwise the installation will fail! 3 Installation wizard: Database Account screen for Oracle 1 CA DLP database user accounts. This has several advantages. go to step 14. i The installation wizard does not try to validate these account details.1 For the Primary User account. go directly to step 17. ` For SQL Server CMSs. it allows precise monitoring of the CMS database and also permits off-line maintenance of the tablespace without disrupting other products that may be sharing your Oracle server. In the Database Tablespace Names screen. 13. 14 Still in the Database Accounts screen. click the button. Oracle creates all new databases in the ‘Users’ tablespace. 15 For Oracle CMSs only. you must specify an existing database account (the ‘Database Administrator user’) that the installation wizard can use to log in to SQL Server or Oracle to create the new accounts. 2 These buttons display account credentials dialogs. 13. go to the Database Administrator User field and click the button. 1 Database Primary User Credentials dialog 1 Create User check box . go directly to step 17. 3 Create User check boxes.2 Repeat the above steps for the Search User account (but see the SQL Server warning above) and. for the Schema Owner.3 If any of the specified database user accounts are new. Search User. These enable the Database Administrator User input box (4) 4 Database Administrator User. For example. you must define the tablespace names for each new account. and even the database administrator in step 14—must use SQL Server Authentication!. If this is a new account. To specify the database user credentials: 13. specify the username and password for the database account (but see the following warning). In the resulting User Credentials dialog. select the Create User check box. for creating new accounts. By default. but we strongly recommend that you create separate tablespaces for the CA DLP database accounts. In the resulting User Credentials dialog. specify the username and password for the database administrator account (but see the SQL Server warning in step 13. You specify the authentication method in the Login Properties dialog in SQL Server Enterprise Manager. you now need to define a tablespace for each new user. You must ensure that you have entered them correctly. ` For Oracle CMSs.36 CA DLP Deployment guide 1 2 3 ! All SQL Server accounts—for the Primary User. If all the specified accounts are existing database user accounts.

specify the logon accounts used by the various CA DLP services. you will need to change the credentials of the infrastructure service. you must manually assign the ‘Log on as a service’ security privilege to this account: 1 Ensure that you are logged on to the target server with local administrator rights on. Both applets are available in Administrative Tools. enter account details (name and password) for the Primary Administrator. You must use this account to configure CA DLP after deployment—see page 43. 2 3 17 In the Service Accounts screen. i Before you start using CA DLP. This is one of three accounts created automatically on the CMS—see page 38. you must manually assign the ‘Log on as a service’ security privilege to this account. For example.Chapter 2 CA DLP servers 37 16 Only applies to CMS installations. see the next section. If installing the Remote Data Manager. Expand the Local Policies branch and select User Rights Assignment. This security area determines which users have logon privileges on the local computer. 4 ! If you change any service logon account to a named user. Otherwise. open the Local Security Policy applet or. Assign the Log on as a service privilege to the service logon account. if this server is a domain controller. Click Install to start the file transfer. there are things you must do first. see page 388. Before you start using CA DLP. This means it is not possible to withdraw a privilege from this account. or to assign a management group that excludes some groups or users. i The administrative privileges and management group assigned to the Primary Administrator can never be changed. CA DLP creates the Primary Administrator account during installation. the infrastructure defaults to the LocalSystem account. open the Domain Controller Security Policy applet. 18 The next screen depends on which you have chosen to install. In the Administrator Credentials screen. Assign the ‘Log on as a service’ privilege If you changed any service logon account to a named user in step 17. For details. On the target server. 19 The installation wizard now has all the information it needs. . This account has full administrative privileges and full management group coverage. the Remote Data Manager Configuration screen permits you to specify which archives to integrate with. ! If you chose to specify a remote data folder in step 6. go directly to step 19. For full details. These are described in chapter 3.

It has no management or administrative privileges. When you install a CMS.38 CA DLP Deployment guide User accounts created automatically on the CMS When you install a CMS. UnknownInternalSender: This account is created in the top-level Users group. but does have the following administration privileges assigned: ` Events: Allow bulk session management ` 'Admin: Manage iConsole ` Admin: Use single sign-on These privileges allow a user to: access multiple user accounts. and install and publish search definition files. access the Manage Searches section in the iConsole. and log on with Single Sign-on. the Unknown Internal Sender setting in the machine policy defaults to this UnknownInternalSender user account. the following user accounts are created automatically. the External Sender setting in the machine policy defaults to this ExternalSender user account. For details. ExternalSender: This account is created in the top-level Users group. its sole purpose is as a conduit to enable policy engines to apply policy to scanned. NT_AUTHORITY\SYSTEM: This account is created in the top-level Users group. when logging on to the CMS. It has no management or administrative privileges. It is created in the top-level Users group. the Default Policy for Data At Rest setting in the machine policy defaults to this DefaultClientFileUser user account. When you install a CMS. DefaultClientFileUser: This account is very similar to the DefaultFileUser account. See page 206. This account is used to apply the same policy to scanned files across all workstations. When you install a CMS. This account has no management group defined. It has no management or administrative privileges. its sole purpose is as a conduit to enable policy engines to apply policy to internal e-mails from unrecognized senders. See page 310. When you install a CMS. its sole purpose is as a conduit to enable policy engines to apply policy to external e-mails. Two of these accounts are created solely for use by policy engines: Primary Administrator: This is the account you created in step 16 of the CMS installation. the Default Policy for Files setting in the machine policy defaults to this DefaultFileUser user account. It is used by policy engines running as LocalSystem. see page 206. See page 207. respectively. It is used solely by the Client File System Agent (CFSA) when scanning local machines. . captured or imported files if no other means are available to determine the policy participant. DefaultFileUser: This account is created in the top-level Users group.

the installation will fail. you must log on to the server or utility machine using the same account that you used to start the installation wizard! This is because for server or utility machine installations using Terminal Services. Restarting the utility machine: If you do need to restart the server or utility machine. If a different account is the first to log on after the server or utility machine restarts.Chapter 2 CA DLP servers 39 Installations using Terminal Services We strongly recommend that you install the CMS server. when you log on to the target server or utility machine using a Terminal Services connection. But if this is not possible and you do need to use Terminal Services. ensure that the colleague who will restart the server or utility machine on your behalf is already logged on before you run the installation wizard. . Logging on to the server or utility machine: Specifically. you will need to reopen your Terminal Services connection. it is essential that the first account to log on to the server or utility machine after it restarts is the same account that launched the installation wizard. If your colleague attempts to log on to the server or utility machine after the wizard has started. If you do not have rights to restart the server or utility machine. the installation will fail. ! When you do this. This is because the installation wizard may sometimes prompt you (during the file copying stage) to restart the target server or utility machine. gateway server. or CA DLP utility machines directly on the target server and do not user Terminal Services. we recommend you use an account with rights to restart it. be aware of the logon requirements on the target server or target machine.

exe to install or uninstall. This enables you to use command line options of msiexec. you need to supplement this basic syntax with parameters to configure the installation folder. WGNDATA Specifies the name and network location of the CMS data folder. Msiexec. These are discussed in the next section. WGNADMINPASSWORD For CMSs only.exe. For example. WGNDATABASESERVICENAME For Oracle databases. i Unlike command line deployment of client machines. Specifies the primary administrator’s password in CMS installations. Instead. Specifies the primary administrator in CMS installations. Identifies the parent server. To deploy multiple CMSs or gateways. The key variables are: WGNPARENTSERVERNAME For gateways and utility machines only. server type. WGNADMINUSERNAME For CMSs only. .msi Where Server. you can install CMSs or gateways on multiple machines using logon scripts or other third party deployment software. i These instructions also apply to utility machines. this specifies the name of the database.40 CA DLP Deployment guide Unattended installations CA DLP installs using the Microsoft Windows Installer service.exe parameters CA DLP supports a range of variables that you can use as Msiexec. You can then install the CMSs or gateways automatically using a script based on standard command line options for Msiexec. Installing CMSs or gateways When installing CMSs or gateways from a command line. WGNDATABASENAME For SQL Server databases. However. you need to copy this source image to each target server. The basic syntax for an installation is: msiexec /i <Path>\server. WGNDATABASESERVER Identifies the host server for your database. there is no need to perform an administrative installation of the CA DLP source image for servers. WGNDATABASETYPE Identifies the database engine that you will use on the CMS—Oracle or SQL Server. Variable INSTALLDIR Specifies the installation folder. Full details are given on pages 509 to 516. you must reference the source image for CMSs and gateways that ships with CA DLP. WGNSERVERTYPE Specifies whether to install a CMS or gateway. this specifies a service name to identify the correct database tables. the primary administrator account. you can directly reference the server source image that ships with CA DLP. plus various proprietary variables unique to CA DLP. and so on. WGNDATABASEPASSWORD Specifies the password for the database account.exe parameters to configure any server installation from a command line.msi is the CA DLP source image and <Path> points to the location of this image. WGNDATABASEUSERNAME Specifies the database account used by CA DLP to access the CMS database. details about the database engine.

4 . ‘Technical information’. or CA DLP utility machine using Add/ Remove Programs. 6 i If you click Remove instead. go to the Program Maintenance screen. The wizard now has all the information it needs and begins the uninstall immediately. 3 When the Installation Wizard starts. ` If you choose to delete the database. launch the installation wizard: Select ‘CA DLP Server’ and click Change: Installation wizard. you can choose to keep or remove the database. note that: SQL Server: The database and its contents are removed completely. you can reconnect to it when you reinstall CA DLP. Windows XP Change and Remove buttons. CA DLP is uninstalled but you do not get the option to keep the database (see step 5). Add/Remove Programs. 1 In the Add/Remove Programs dialog. This applet is part of the Control Panel. to uninstall CA DLP from the Manually uninstalling a server If Windows Installer fails to uninstall CA DLP. gateway or utility machine This section describes how to uninstall a Windows CMS. Oracle: The database contents are deleted but the database itself is not deleted. Remove the Program screen 5 In the Remove the Program screen. To do this. Choose Remove current machine.Chapter 2 CA DLP servers 41 Uninstalling a CMS. you simply re-enter the user name and password for a valid database account when you run the installation wizard (see step 8 on page 34). 2 ` If you choose to keep the database. Windows gateway. you can uninstall manually using the procedure described on page 520 in chapter 25.

Console-only installations 1 Choose the machine on which you want to run the Administration console. you use an Administration console. i You can install the Administration console on as many machines as you like.exe to launch the CMS installation wizard. choose Custom Setup.42 CA DLP Deployment guide Installing an Administration console After deploying CA DLP to your CMS. This mainly involves changes to the default policies. In the Setup Type screen. When you install a CMS. this console is normally installed automatically on the target machine. This file is in the \Server folder on your CA DLP distribution media. ‘Before you start using CA DLP’. These configuration tasks are fully described in chapter 3. run setup. then you will need to install the console on another machine. Click Install to start the file transfer. 3 On the target machine. exclude the Enterprise Server feature and include the Management Console. only the Administration console is installed with the Management Console feature. In the Custom Setup screen. The Documentation feature is optional: i By default. In the Customer Information screen. and some user administration. . some further configuration is needed before you deploy across your organization. 2 Is the Administration console already installed? To perform these tasks. CA DLP Enterprise Server Management Console Documentation 4 5 Custom Setup screen Features required for a console-only installation. 6 The installation wizard now has all the information it needs and so it skips the screens normally associated with a CMS or gateway installation. But if you chose a Custom setup type and excluded the Management console feature (which incorporates the Administration console only). enter your user name and organization.

You also need to edit the account properties of any new administrators and managers (though you may prefer to leave this task until you have deployed CA DLP to your client machines). you may need to install a license file before you can start using the product. This account is created during the CMS installation and has full administrative privileges and full management group coverage. This mainly involves changes to the default policies for key user groups and new machines. As soon as your CA DLP installation is authenticated. 1 Choose an appropriate account to configure CA DLP To configure CA DLP as described here. To find your installation code. your licensed policy modules are unlocked and available to use. Your license file unlocks the CA DLP policy modules available to your organization.3. some further configuration is needed before you start using CA DLP. see page 23. choose Tools > Install license file. . Before you start using CA DLP Before you start using CA DLP fter deploying CA DLP to your CMS. Install a license file 1 2 In the Administration console. The license file uses this code to authenticate your CA DLP installation. you must log on to the Administration console using an account with adequate administrative privileges and management group coverage. choose Tools > Install license file in the Administration console. chapter 3 A 2 Install your license file After installing CA DLP. The simplest way to ensure this is to log on using the Primary Administrator account (page 37). Select your license file and click Install. To contact Technical Support. Finally. you may need to amend your browser security settings if you intend using any Web page control triggers. Obtain a license file Contact Technical Support and quote your installation code. The Install License File dialog shows your installation code. This chapter covers the complete range of post-deployment tasks.

When you use CA DLP for the first time after installation. It can either create new accounts automatically. for example. 2 3 In the Machine Policy Editor. ` Disable Internet applications: A new account is not created and the user is blocked from using their browser and e-mail application.44 CA DLP Deployment guide 3 Configure your CMS machine policy to handle new accounts A machine policy governs how CA DLP machines operate. communicate with each other. ` Disable Internet applications: A new account is not created and users on the machine are blocked from using their browser and e-mail application. In the right-hand pane. double-click the setting Account Handling for New Client Machines and set it to: 4 New user accounts: Configure how the CMS handles new users. Machine Policy [CMS-HARDY] Infrastructure Security Data Management Replication Logging Filter Account Import Lookup Cache Management Diagnostics Policy Engine Central Management Server ` Create New Account: CA DLP creates a new machine account automatically. or it can require an administrator to manually add new machines in the Administration console. double-click the setting Account Handling for New Users and set it to: ` Create New Account: CA DLP creates a new user account automatically. In the right-hand pane. UNIPRAXIS\srimmel. you must edit the CMS policy to determine how it handles new machine accounts. ` Ignore: A new account is not created but the user is permitted to continue using their browser and e-mail application. User names for the new accounts are generated automatically based on Microsoft Windows authentication and include a domain prefix. 1 In the Administration console. or 5 New machine accounts: Configure how the CMS handles new client machines. Select the CMS and click Edit Policy right-click and choose Edit Policy. The machine policy on the CMS uses some extra settings to control account handling for unknown users or machines and database management. browse to the Central Management Server folder. and protect confidential data. ` Ignore: A new account is not created but users on the machine are permitted to continue using their browser and e-mail application. CMS Machine Policy . expand the Machine Administration branch.

or you can schedule purges to run at regular intervals. The default is 1095 days (three years). ` Purging after replication: For gateways and client machines. ` All gateways. which holds captured data for your entire organization. browse to the Data Management folder. These run at regular intervals and are configurable in the CMS machine policy. You may need to change this period on the CMS to meet regulatory requirements. This setting is ignored on CMSs. Set the minimum retention period: This determines how long events are retained before they become eligible for purging. set Purge Events on Replication? to False (clear the check box). Event purging is turned on as soon as the new settings replicate to the target CA DLP machines. it is intended for use only with gateways and client machines. and one or more strategies for your gateways and client machines.Chapter 3 Before you start using CA DLP 45 4 Configure event purging ! Before using CA DLP for the first time after installation. 6 7 . Machine Policy [MachineCommonClient] Infrastructure Security Data Management Replication Logging Filter Account Import Lookup Cache Management Diagnostics Policy Engine Central Management Server After installing CA DLP. You need a separate purging strategy for your CMS. events are purged automatically after replication to the parent server. we strongly recommend you turn on event purging in your common client machine and common gateway policies. we recommend you reduce this period to prevent a shortage of free disk space. the Purge Events on Replication? setting defaults to True. To implement these strategies. Gateway and client machine purges: Events stored on these machines are eventually replicated up to the CMS. For example. you need to turn on event purging. if you schedule purges on gateways and client machines. CMS purges: A strategy that meets regulatory requirements on the retention of electronic communications typically requires scheduled event purges. By default. ` The CMS. you need to configure the relevant machine policies: 1 2 Expand the Machine Administration branch To configure event purging for: . Set the purge frequency: You can configure purges to run immediately after the data has been replicated. but purging prevents free disk space falling to dangerously low levels (with the attendant risk of the CA DLP infrastructure being suspended—see task 5 on page 46). you can suspend the CA DLP infrastructure during purge operations or you can specify a purging timeout. ` All client machines. Likewise. right-click the CMS Policy. Save the policy. 5 and choose Edit Machine Policy: Data Management folder ` Scheduled purges: To schedule regular purges. right-click the CMS and choose Edit Common Client Policy. right-click the CMS and choose Edit Common Gateway Policy. though you can disable this feature if required and run scheduled purges instead. Configure purge performance: Other settings in the Data Management folder provide further control over purge operations. This purges events stored locally as soon as they have been replicated to the parent server. 3 4 In the Machine Policy Editor. Then configure the settings for the minimum retention period (step 5) and the event purge frequency and time.

for example. the CA DLP infrastructure is suspended. For example. multiply the Disk Space Error Level by five. if CA DLP imports events at a rate of 50MB per minute and the Disk Space Check Interval is set to 10 minutes. By default. for example. i The warning level also represents the 'safe' level at which the infrastructure automatically restarts following a suspension and subsequent recovery in free disk space. This opens the Machine Policy Editor. 7 . Set the Disk Space Warning Level. 6 Set the Disk Space Error Level. When CA DLP detects that free disk space has fallen below this level. To roughly calculate the Disk Space Warning Level value. 3 4 5 Calculate disk space values The amount of free disk space you require essentially depends on the expected disk usage. Right-click the CMS and choose Edit Policy or Edit Common Gateway Policy. You can calculate how much this will be using two factors: The rate at which CA DLP imports data.46 CA DLP Deployment guide 5 Configure the management of free disk space on servers ! Make these changes in both the CMS and common gateway policies. In the Machine Policy Editor. how frequently CA DLP checks the amount of available free disk space. browse to the Data Management folder (see the policy tree page 45). Settings in the machine policy determine how low free disk space can fall on these drives before the CA DLP infrastructure is suspended. and the level at which the infrastructure automatically restarts. When CA DLP detects that free disk space has fallen below this level. This setting is in the CMS policy—see next section. Specify how often free disk space is checked. This would mean that the Disk Space Error Level had to be at least 500MB. these settings are optimized for client machines so you need to adjust these values in your CMS policy and common gateway policy. The Disk Space Check Interval. That is. CA DLP automatically monitors the level of free disk space on the drive hosting the data folder (for the CMS and gateways) or on the drive hosting the installation folder (for client machines). to 1G. then you can potentially write 500MB of data between disk space checks. Save the policy. it adds a warning to the Audit log file. to 2G. Set Disk Space Check Interval to one minute. Set disk space levels 1 2 Expand the Machine Administration branch .

while new gateway servers automatically inherit the common gateway policy. For details about time zone handling. but you will probably want to amend other policy areas. These notification messages act as triggers for data replication. their clocks are probably synchronized automatically by a network time server. it is important that all of your CA DLP machines are set to the correct date and local time. This normally happens automatically. Machines that are not members of a domain are probably synchronized by an Internet time server. search the index for ‘time zones’. If your CA DLP machines are all members of a domain. because a firewall blocks time synchronization. When a reviewer updates an event’s audit trail in the Data Management console. 7 Synchronize the clocks on your CA DLP machines When an event is captured on a client machine. For this reason. this automatic synchronization may not occur. i Note the following: Right-click the CMS and choose Edit Common Client Policy or Edit Common Gateway Policy. if a machine is set to the wrong date set. see the Data Management console online help. CA DLP automatically takes account of time zone differences. Likewise. the audit entry is always time stamped on the CMS. This time stamp is preserved when the event is replicated up to the CMS. Machine Policy [MachineCommonClient] Infrastructure Security Data Management Replication Logging Filter Account Import Lookup Cache Management Diagnostics Policy Engine Central Management Server 3 ` Such problems cannot affect event auditing. make sure that the owners of these machines understand the need to keep their machine set to the correct date and time. This opens the Machine Policy Editor. if CA DLP is installed on any machines that are not members of a domain. it is time stamped. Edit the policies as required. Similarly. For example. The need for a purging strategy was discussed in task 4 on page 45. If a machine is set to the wrong date. Machine Policy: Security and Replication folders . You need to configure these policies to suit your requirements.Chapter 3 Before you start using CA DLP 47 6 Configure the common client and gateway policies New client machines automatically inherit the common client policy. But if a CA DLP machine does not have a continuous Internet connection. To edit the common client or common gateway policies: 1 2 Expand the Machine Administration branch . the Replication settings determine how often CA DLP machines send notification of newly captured data or local infrastructure changes. settings in the Infrastructure > Security folder let you configure an encryption strategy for data sent across the network to the CMS from gateways and client machines. Therefore. incorrect capture dates are saved with any events captured on that machine. ` When displaying event capture times. clock synchronization is blocked. for example.

if you want to: ` Disable a folder.exe. see WGNDEFAULTUSERGROUPPATH on page 511. This means any new user who inherits this policy has complete freedom to change any setting in their policy. Users New Users ‘Users’ group Default group Example default group All self-enrolled new users are added to this group. there is only one existing group. Each group has its own customizable policy. 'Users' has—and must have— a non-restrictive policy: no settings are disabled. This allows different teams or departments to install CA DLP from separate source images so that their respective users are added automatically to separate groups. This is the 'Users' group and so it is automatically set to be the default group. CA DLP ignores all settings in the folder itself and its subfolders. ` Disable Web and e-mail applications when the CA DLP infrastructure is not running. Find this in the Initialization subfolder. 3 Select the new group and choose Edit > Set As Default. (Click Find to locate this setting). right-click and choose Enforce Branch. But you can easily prevent this by choosing a default group with a restrictive policy. In other words. edit the Infrastructure Failure setting. Why is this a problem? The default group is effectively a holding group until you can move new users into more appropriate groups. they are automatically assigned to the default group. Of necessity. X Create a new default user group 1 In the Administration console. That is. For details. Predefining the default group For deployment operations based on Msiexec. ` Enforce a current folder plus its subfolders. you must first expand the User Administration branch. But when you use CA DLP for the first time. click or right-click and choose Disable. you can use a variable to customize the parent group for newly created users. A user group is a collection of associated users that share a common policy. 2 Click or choose Edit > New Group. providing you with a centralized but highly flexible method of user administration. enforced or hidden. key policy settings are enforced. X Edit the default group policy or choose 1 Select the default group and click Edit > Edit Policy.48 CA DLP Deployment guide 8 Configure the policy for the default user group ! Before using CA DLP for the first time after installation. 2 Now amend the policy to suit your requirements. When new users add themselves to CA DLP. You make any user group the default group. we strongly recommend you choose a new default group and define a restrictive policy for this group. This ensures that new users adhere to the rules governing acceptable Web and e-mail usage. they could potentially define their own policy to dodge the rules in your organization governing acceptable Web and e-mail usage. When you disable a folder. hidden or disabled. This opens the User Policy Editor. For example. or choose Edit > .

. in order to allow users to enroll themselves as CA DLP users. and configure the policies for these groups. in order to allow users to enroll themselves as CA DLP users. you can withhold specific privileges and assign a management group (this limits which groups they can manage). click the Privileges tab. 2 In the Properties dialog. To limit the scope of their authority. You can create as many user groups as you need and arrange them in any way you want. you can organize users into groups based on location. X Assign a management group 1 Right-click a user and choose Properties. job. You need to create and organize an initial set of user groups. i You will need to provide administrators and managers with details of their CA DLP account (their X Edit a group policy 1 Select the group the want and click Edit > Edit Policy. Example hierarchy of user groups You create and organize user groups in the Administration console. You can promote ordinary users into administrators or managers by granting them administrative privileges. X Create new user groups 1 In the Administration console. you will almost certainly need to share the administrative workload with selected colleagues. 10 Create your administrators and managers i You may prefer to leave this task until you have deployed CA DLP to your client machines. or purchasing permissions: Users New Users Management Board Finance Legal Marketing Sales For CA DLP installations with large numbers of client machines. expand the User Administration branch. This entails setting up the CMS machine policy to permit self-enrolment (see task 3 on page 44). edit the settings and folder attributes to suit your requirements. X Assign administrative privileges 1 Right-click a user and choose Properties. 2 In the User Policy Editor. This entails setting up the CMS machine policy to permit self-enrolment (see task 3 on page 44). 3 Select the administrative privileges as required. For example. 3 Click the Browse button and choose which group you want as the management group. or choose user name and password) before they can run the Administration console. 2 In the Properties dialog. You will also need to provide senior executives with the ability to manage users and extract information held in CA DLP databases. 2 Click or choose Edit > New Group.Chapter 3 Before you start using CA DLP 49 9 Create and organize a hierarchy of user groups i You may prefer to leave this task until you have deployed CA DLP to your client machines. click the Details tab.

To implement Unicode support on each of these client machines. you must edit the startup. SQL Server databases automatically support Unicode characters. All CA DLP consoles now support Unicode character sets. run: net stop wgninfra CMSs and gateways To implement Unicode support on Oracle CMSs or gateways. . Find this file in the \system subfolder of the CA DLP installation folder. Far Eastern text captured on an English OS). please contact Technical Support. From a command prompt.properties file. it is now possible in the Data Management console to search for e-mails containing strings of Far Eastern characters. 3 Open this file and add the following line to the [Database] section: db. i There is no equivalent requirement for SQL Server databases. see page 23.properties file on each one to manually specify UTF-8 character encoding: 1 Stop the 'CA DLP infrastructure' service. From a command prompt. search the index for ‘UTF-8’.50 CA DLP Deployment guide 11 Set up support for Unicode characters ! For full deployment details. run: net start wgninfra Client machines You need to implement Unicode support on all CA DLP client machines that are likely to capture e-mails and other events containing Unicode characters (for example. For details. you need to set up the database for CA DLP to use UTF-8 encoding for the DBMS code page. 2 Edit the startup.charset=UTF-8 4 Restart the CA DLP infrastructure service. see the Database guide. For example.

. Full details are available in the Administration console online help. the following third party solutions can integrate with CA DLP to work as an alternative object store: EMC Centera: For integration details. search the index for ‘event auditing. archiving and retrieval of large volumes of captured data. including the PE domain user and a matching CA DLP user account. You may also need to edit the registry on host machines to enable user lookup operations.and post-installation tasks. we recommend that you set up integration as soon as possible after deploying CA DLP. you must install and publish the default iConsole event searches.and post-installation tasks. In particular. 13 Integrate with third party object storage solutions CA DLP can integrate with third party object storage solutions to allow storage management. Specifically. i For full details about deploying the iConsole. To do this. 15 Set up policy engines Setting up policy engines requires a number of pre. configuring audit features’. only events captured by CA DLP after integration has been set up will be migrated to the third party object store. NetApp SnapLock: See page 194. see chapter 11 ‘Policy engines’ on page 201. Instructions are on page 83. For this reason. reviewers will not be able to audit events. see page 184. In each case.Chapter 3 Before you start using CA DLP 51 12 Install iConsole searches After deploying the iConsole. If these audit features are not fully configured. you must configure the Internal E-mail Address Pattern setting. including and all pre. you must then edit the machine policy on each host machines. then they will not be available in the iConsole. Specifically: Before installing policy engines. That is. they must use the Administration console. Events captured and replicated to the CMS before integration has been set up will not be migrated. We therefore recommend that you configure these event auditing features before your reviewers start using CA DLP to audit captured events. After installation. IBM DB2 Content Manager: See page 189. you must first set up the necessary user accounts. but administrators must first configure audit status labels and the contents of the auditing dialogs. 14 Configure event auditing labels Full CA DLP auditing features are available in the iConsole. see chapter 5 ‘iConsole’. For details about each of these tasks.

52 CA DLP Deployment guide .

` Standalone installations. MS Outlook Integration Lotus Notes Integration Application Integration Client File System Agent Client Print System Agent ` Client upgrades are discussed in the Upgrade guide. and how to upgrade. For details about each feature.exe. . : CA DLP Management Console Administration Console Data Management Console Client Integration MS Internet Explorer Integ. See also page 28. The main supported methods are Windows XP Group Policy and Microsoft SMS.4. This chapter also discusses ‘snapshot’ deployments (also called ‘ghost imaging’). see page 54.exe to install or uninstall. Command line operations: CA DLP installs using the Microsoft Windows Installer service. This enables you to use the command line options of Msiexec. setup. plus managed methods of installing to multiple clients: Managed operations: These enable you to simultaneously install or uninstall CA DLP on multiple client machines across your organization. Client machines Client machines his chapter describes how to install and uninstall CA DLP from client machines. the following features are available. where a single machine operates simultaneously as a CMS and client machine. i Note the following: chapter 4 T Client installation features When you install a CA DLP client machine. It covers manual and command line operations. Client machines: Available features These features are listed in the Custom Setup screen of the client installation wizard (step 4 on page 55). are described on page 516. Manual operations: You can manually install or uninstall CA DLP from individual client machines using the installation wizard.

Client agents include: Microsoft Internet Explorer Integration: This enables capture or control of any Web activity in Internet Explorer or Windows Explorer. Microsoft Outlook Integration: This enables capture or control of any Outlook-based e-mail activity. Application Integration: This enables CA DLP to monitor usage of other desktop applications and capture application usage metrics. and configure event auditing options. to administer users and machines. For details. and to detect when other specified applications are being used. Lotus Notes Integration: This enables capture or control of any Notes-based e-mail activity. see page 302. You cannot install other features without also installing the infrastructure. see page 511. the CFSA can also apply policy in real time to the file being copied. Administration Console: This enables you. Client File System Agent: The CFSA enables CA DLP to control attempts to copy or save files to removable devices. Client Integration These features (or ‘client agents’) enable CA DLP to integrate with e-mail and browser applications on the client machine. for example.exe variable. i Integration with Outlook browsers requires a minimum version of Internet Explorer (page 25) and can be optionally disabled (page 511). Management Console This enables host machines to run CA DLP consoles. For details. manage policies. only the Administration console is installed with the Management Console feature. If Windows Explorer or a DOS command is used to copy files to removable devices. such as USB flash drives. i You can optionally turn off integration with Windows Explorer using an Msiexec.54 CA DLP Deployment guide CA DLP This feature installs the CA DLP infrastructure. Client Print System Agent: The CPSA enables CA DLP to capture or control attempts by users to print documents on local or network printers. see page 314. This enables the various components to run and communicate. For details. If both the Outlook and Internet Explorer integration features are installed. i By default. Data Management Console: This allows you to search for and audit captured data. . CA DLP can also capture or control any Web activity when Outlook is used as a Web browser.

After installing. 1 To launch the client installation wizard. Complete: The standard installation for managers or administrators. you use the Account Import feature to import the client machine details from a CSV file. the CPSA will be able to detect print jobs sent from these applications. For details about CA DLP and this firewall.exe) i To manually install CA DLP. you must have local administrator rights on the client machine. 4.Chapter 4 Client machines 55 Before installing Before you install CA DLP on your client machines. choose the type of installation that you want: Typical: The standard installation for end-users. the target path must not include folders whose names contain Far Eastern characters. see page 176. click the Disk Space button. click the Change button. 2 3 4 In the Custom Setup screen.) If you anticipate your users printing .EMF files (a Windows graphics file format) directly from Windows Explorer. In the Setup Type screen. enter your user name and organization. In the Customer Information screen. Manual installations (setup. This ensures that. you can bulk create new client machine accounts and pre-assign machines to parent servers in advance of the CA DLP rollout. To bulk create new accounts. Deploying across multiple subnets CA DLP is designed to operate across subnets. select the features you want to install. Close all applications before installing CPSA You must close down all applications that support printing before installing the CPSA (for example. (If an application is already running when you install the CPSA. Find this in the \Client folder on your CA DLP distribution media. 4. you must follow the instructions on page 301. note the following issues. CFSA requires Windows XP SP2 On Windows XP machines. This does not include the consoles.exe. If some or all of your client machines are on a separate subnet to your CMS. follow the post-install instructions on page 301. Go to step 5. see page 25. after installation. before installing the agent you must close down all applications. CPSA: If you install the Client Print System Agent. Go to step 5. you will need to restart the client machine after installing the CPSA to ensure that it can fully control attempts to print these files. any Microsoft Office application). Go to step 4. CFSA: If you install the Client File System Agent. Custom: Choose which components to install. run setup. The CA DLP infrastructure cannot handle these paths. This enables you to deploy multiple client machines using a single source image (which identifies a single parent server) whilst ensuring that each client machine automatically connects to its 'correct' parent server immediately after installation. Windows XP SP2 firewall The firewall setting ‘Don’t allow exceptions’ must be turned off on the target machine.1 Installation folders: To install these components to a non-default location. ! If you install to a non-default location. Creating machine accounts before installing the client software To simplify mass deployments. computer name resolution must work in both directions. It includes all the consoles. These are described on page 53.2 Free disk space: To check whether the target volumes have sufficient free disk space for the selected features. For full details. . This information is required for licensing purposes. see page 548. the Client File System Agent requires SP2 or later. it will be unable to detect print jobs sent subsequently from that application.

The installation wizard tries to confirm that the specified server exists on the network.56 CA DLP Deployment guide 5 In the Connectivity screen: 5. there are things you must do first. If you specify the CMS or gateway by name instead of IP address. i Before you start using CA DLP.1 Choose the Enterprise Mode option. Simply reenter the user name and password for a valid database account when you next run the installation wizard (see step 10 on page 34). make sure you correctly type the parent server name or IP address otherwise the installation will fail! 6 In the Service Accounts screen. the infrastructure logs on using LocalSystem. If you choose to bypass the validation. . 2 When the Installation Wizard starts. 3 to uninstall CA DLP from the 5.2 Enter the name or IP address of the parent server (either your CMS or a gateway server). i If you click Remove instead. It does not check whether it is a valid CMS or gateway. you can reconnect to it when you reinstall CA DLP. In this situation. you do not get the option to keep the database (see step 3). 1 In the Add/Remove Programs screen: Windows XP: Select ‘CA DLP Client’ and click Change. Before you start using CA DLP. specify the logon accounts used by the CA DLP service. 5. you can choose to keep or remove the local database. See page 30 for details. either re-enter the correct parent server details or select this check box to bypass or skip the validation. Choose Remove current machine. the client machine must be able to resolve this name. If you choose to keep the database. By default. The installation wizard now has all the information it needs. 7 Manually uninstalling If Windows Installer fails to uninstall CA DLP. 4 The wizard now has all the information it needs and begins the uninstall immediately. These are described in chapter 3. for example because it is not switched on or because you mistyped its address or name. This installs the client machine as part of a general CA DLP deployment. This applet is part of the Control Panel. Click Install to start the file transfer. go to the Program Maintenance screen. You now need to specify the parent server. you can uninstall manually using the procedure described on page 520 in chapter 25. Uninstalling client machines Using Add/Remove Programs Use Add/Remove Programs to manually uninstall CA DLP from a machine. In the Remove the Program screen. the wizard adds a Bypass Server Validation check box to the screen when you click Next.3 If the installation wizard is unable to connect to the specified parent server. i Standalone Mode is described on page 516. Technical information.

you can add further transforms to: Prevent unauthorized uninstallations Installing with msiexec.mst transform. Full instructions are given on page 509.Chapter 4 Client machines 57 Command line operations CA DLP installs using the Microsoft Windows Installer service.msi TRANSFORMS=SetParentName. To do this. specify the ClientLockDown.msi /qn Other available transforms If required.msi WGNPARENTSERVERNAME=<Server> Where <Server> is the name or IP address of the parent server. For example. you can use logon scripts to deploy CA DLP to multiple machines. This enables you to use command line options of msiexec. You can also install from a command line using a combination of setup.mst.mst .ini. the syntax is: msiexec /i <Path>\client. to specify a completely silent installation that requires no user interaction.mst To prevent users from uninstalling CA DLP with the Add/Remove Programs utility. The command line syntax is: msiexec /i <Path>\client. To create this transform.exe and setup. you can install CA DLP on multiple client machines using logon scripts or other third party deployment software. though it does provide all the necessary command line details. Using the SetParentName.msi TRANSFORMS=SetParentName. You can find details about WGNPARENTSERVERNAME property on page 510. For example. Install the application integration software A default CA DLP installation (that is.mst transform.mst. You can also use command line operations in a managed deployment. a Typical setup in the installation wizard) does not include application integration. This guide does not provide explicit instructions for such deployment methods. you run a provided script. EnableAppmon. Silent installations Various msiexec. Full instructions are given on page 506. The command line syntax is shown below. For example. Full instructions are given on page 508. Full instructions are given on page 506. specify the EnableAppmon. there are two possible methods for identifying the parent server (either the CMS or a gateway): Using a property The basic command line syntax for an installation is: msiexec /i <Path>\client.exe Identifying the parent server When using command lines to install CA DLP on client machines.exe to install or uninstall.exe options let you specify silent or near-silent installations (or uninstallations). The command line syntax is: msiexec /i <Path>\client. ClientLockDown.mst transform You can use this transform file to identify the parent server.

for example. you must edit setup.ini to prevent standalone installations. you can run setup.ini and find the following line: CmdNew=/i 3 Change this line to: CmdNew=WGNPARENTSERVERNAME=<Server> /i Uninstalling When uninstalling. For details. This installation is configured by the contents of setup. You may need to do this if you cannot specify a path to the Client.msi WGNDELETEDATABASE=0 2 Uninstall and delete the existing database Use the following command line syntax: msiexec /x <Path>\client. for example. <Path>\client. Find this file in the \win32\Client folder on your CA DLP distribution media.exe are preferable to methods based on Setup. In the above commands.exe provides better support for unattended installations.msi file because. 1 First.exe.exe.58 CA DLP Deployment guide Installing with setup. 4 Then run this command: setup You can also configure setup.msi. In particular. Open setup. either the CMS or a gateway.msi Uninstall using the product code Where <Server> is the name or IP address of the parent server. with this product code. Do include the { } brackets: {94FD0328-5120-432B-AE46-F30A312AEA95} .exe from a command line. Note that /i is preceded by a space and must be at the end of the line. the syntax depends on whether you want to keep or delete the existing database: Uninstall but keep the existing database Use the following command line syntax: msiexec /x <Path>\client.ini. i Command line installations based on Msiexec. to eliminate potential security problems.exe As an alternative to Msiexec. Msiexec. The WGNPARENTSERVERNAME property is described on page 510.ini to identify the parent server. replace the reference to the source image. see page 517. the file is in a shared network folder but a network failure has made the folder temporarily unavailable.

2 Create a new group policy object (GPO) to control the software installation package. We recommend that you create an administrative installation source image. This enables client machines to install CA DLP directly from the network without generating excessive network traffic or requiring excessive free disk space on the client. The procedure is illustrated below: Create an administrative installation source image: Client. i For full details about performing an administrative installation.msi). Note that we recommend using the ‘Assigned’ deployment method because. the ‘Assigned’ method enables you to enforce deployment. but after deployment you can assign them to the required gateways using the Administration console. 5 Deploy Group Policy installation 1 Select an organizational unit (OU) containing the machine accounts.msi To deploy using Group Policy. Generate this transform and copy it into the same folder as Client. you must assign to computers. . unlike the ‘Published’ method which requires user cooperation. or XP environment. Using this method. we recommend that you create an administrative installation source image.mst Package MSI Installation File Deployment Method Deployment Options MST Transform File Transform files let you apply customized configuration changes to a Windows Installer package. you must not assign to users. you must use an alternative method of installation. including the MSI installation file. All client machines initially connect to this server. i To avoid the need for separate transforms for the CMS and each gateway. and the MST transform file. 1 Organizational Unit 2 3 4 Group Policy Object Machines Create a transform: SetParentName. For a Group Policy installation. You can remotely deploy CA DLP to Windows XP client machines by using Group Policy. you need a transform to specify the name or IP address of the parent server (the CMS or a gateway) that the client machines connect to. 4 Define the GPO package properties. see page 506. deployment options. 5 Deployment starts as soon as the client machines restart. If your domain controller or CA DLP clients use other Windows operating systems.msi. You must also create a Windows Installer transform file so you can specify the name of your CMS or gateway server. For details about generating this transform. the CMS. Before installing Before using Group Policy to deploy CA DLP. you may want to generate a single transform that specifies. your administrative installation source image (see above). you will need to use a CA DLP source image (Client. the deployment method (‘Advanced assigned’).Chapter 4 Client machines 59 Group Policy operations i This method can only be used in a Windows 2003. 3 Filter the GPO security properties so they apply to the target machines. see page 505. say.

you must enable the Apply Group Policy permission. 1 Open Active Directory Users and Computers (located in the Administrative Tools folder). You now need to define the properties of the installation package.2 Deployment options If you want to be able to: 2 ` Selectively uninstall CA DLP from client machines (see page 61). This must contain machines targeted for CA DLP deployment (because you will base the GPO on computer accounts. choose the ‘Advanced assigned’ method. not user accounts). 7 7. This enables the installation package to correctly identify its nominated parent server. please refer to your Windows 2003 documentation. for each target machine.3. ‘CA DLP Rollout’. 3 ` Forcibly overwrite any existing versions of CA DLP on client machines. Specify which machine accounts the GPO will apply to. 7.60 CA DLP Deployment guide GPO installation i For full details about Group Policy. You must choose the ‘Advanced’ method so that you can apply modifications to the package—see step 7. select the advanced option Remove previous installations of this product from computers if the product was not installed by Group Policy-based software installation. This enables you to forcibly assign the software to target machines. 4 7. CA DLP is deployed to the target machines when they next reboot. you first select an appropriate Active Directory organizational unit (OU) that ‘contains’ target machines. Then you define a group policy object (GPO) that contains a software installation package. for example. You do this by editing the GPO Security settings. client machines cannot identify their parent server and CA DLP will not install.3 Modifications You now need to specify various transforms to modify the installation package. As soon as the GPO is created.mst transform (see Before Installing on page 59). Then create the GPO via the Group Policy properties of your chosen OU and create a new GPO. select the option Uninstall this application when it falls out of the scope of management. specify the SetParentName. Select an organizational unit (OU). 6 To deploy using Group Policy.1 Deployment method When prompted.msi file that you created as part of your administrative installation source image (see Before Installing on page 59). GPO Computer Configuration. Software Installation . Create a new software installation package for the GPO Computer Configuration (this is a Group Policy property of the OU). ! This transform is essential! Without the transform. CA DLP Rollout Policy Computer Configuration Software Settings Software Installation Windows Settings Administrative Templates User Configuration Configure the software installation package to point to the Client. 5 ` First.

See page 508 for details. These are described in chapter 3. Full instructions are given on page 506. i Before you start using CA DLP. specify the ClientLockDown. we recommend that you uninstall using Group Policy. Group Policy uninstallation If you installed CA DLP to a client machine using Group Policy.Chapter 4 Client machines 61 ` Without modifications a GPO installation will only perform a ‘Typical’ setup. Alternatively. CA DLP is deployed automatically to the target client machines when they next reboot. ` If required. which excludes application integration.mst transform. remove the Apply Group Policy permission. This uninstalls CA DLP all from client machines referenced by the GPO. you can simply delete the entire GPO. If you want to install application integration (this enables CA DLP to monitor usage of desktop applications).mst transform. 8 The GPO is now complete. go to Active Directory Users and Computers and simply edit the GPO Security settings (see GPO Installation. you can add a further modification to prevent users from uninstalling CA DLP with the Add/ Remove Programs utility. Before you start using CA DLP. step 4). CA DLP is uninstalled automatically when the client machine next reboots. there are things you must do first. For each client machine. To do this. To do this. specify the Appmon. .

see page 505.62 CA DLP Deployment guide SMS operations i CA DLP deployment has been tested using SMS 2. 8 Deployment start time is defined by the assignment schedule. you base the deployment on a collection of machine accounts. SMSQuietUninstall. When deploying CA DLP using SMS. If you require silent uninstallations. We recommend that you set up the package to use a scheduled.mst Transform files let you apply customized configuration changes to a Windows Installer package. 4 Define an installation program.0 SP3 in conjunction with Windows 2000 SP2. 6 & 7 Create an advertisement containing the assignment schedule. Then you set up a software installation package for this collection.msi) for your SMS clients to use. Here you can use a transform. you run a provided script. mandatory assignment. i For full details about performing an administrative installation. Full instructions for running the script and creating the transform are given on page 506. i To create this transform.msi We recommend that you create an administrative installation source image (Client. your administrative installation source image (see above). 5 Choose the machines to act as package distribution points. there are some preliminary steps you must follow. The procedure is shown opposite: Create an administrative installation source image: Client. but these have not been tested. You can remotely deploy CA DLP to client machines using Microsoft Systems Management Server (SMS). 3 Specify the package folder containing the source files. This enables client machines to install CA DLP directly from the network without generating excessive network traffic or requiring excessive free disk space on the client.msi. to allow silent uninstallations. That is. this ensures that CA DLP is installed to the client machines at the time when you want. 2 Create a new software installation package. 6 7 Advertisement Schedule 8 Deploy SMS installation procedure 1 Select a machine-based collection.mst. Before installing Before using SMS to deploy CA DLP. you must already have discovered the client machines and confirmed that the SMS client software has been installed on these machines. the transform removes the need for user cooperation when uninstalling. . CA DLP may deploy successfully using other versions of SMS and under other service packs. Discover the SMS clients Before installing with SMS. 1 Collection 2 3 4 5 Package Data source Program Distribution Points Create a transform: SMSQuietUninstall. copy this transform into the same folder as Client.

you must include the SMSQuietUninstall. Before installing). you edit the Membership Rules. but they have not been tested. Other versions may successfully install CA DLP to client machines. See page 30 for details. Of particular use is the white paper. and advertisement. 2 Now you must set up a new software distribution package. ` If you want to enable application integration (this enables CA DLP to monitor usage of desktop applications) include the Appmon. The simplest method is to use the Distribution Software Wizard. This collection must contain all the client machines that require CA DLP.0 SP3. . ` If you want to prevent users from uninstalling CA DLP with the Add/Remove Programs utility.2 Environment: Specify when the program can run: Choose the option ‘Whether or not a user is logged on’.mst. ClientLockDown.mst transform. distribution points. 4. ` Choose the option ‘Always obtain files from source directory. EnableAppmon.msi WGNPARENTSERVERNAME=<CMS> TRANSFORMS=SMSQuietUninstall.mst i Command line options for Msiexec. When you enter the program command line. To add machines to a collection.mst. 3 Create a new package and define its Data Source properties. you must ensure that the client machines can resolve its name.exe are defined on page 509. See page 65 for details.Chapter 4 Client machines 63 SMS installation i These instructions apply to Microsoft Systems Management Server 2. 4 Create a new program for the package and define its properties: 4. This includes properties that identify the CMS or gateway server and apply a transform: msiexec /i <Path>\client.0’. These are a property of the collection. ` If you will require silent uninstallations. ` Select the folder containing your administrative installation source image (see the previous section. Full instructions are given on page 506.1 General: Enter the following program command line. Full instructions are given on page 508. ` If you specify the CMS or gateway by name. ‘Deploying Windows Installer setup packages with Systems Management Server 2. please refer to your SMS documentation. in conjunction with Windows 2000 SP2. Do not choose a user-based collection. note the following: 1 Open the SMS Administrator console and select the collection you want. If you prefer to set up a package manually.mst transform.mst transform in the installation program. For full details about using SMS.’ This permits you to change or update the source files in the administrative installation folder if necessary. include the ClientLockDown. the following steps provide the necessary details for the installation program.

4 Now define the program distribution points for the package you created in step 2. define the General properties. Package distribution points and Advertisement .64 CA DLP Deployment guide 4. You must select the Package (see step 2). the Program (step 4). and the Collection (step 1): 4. To do this. General tab 1 Advertisement 2 Package 3 Program 4 Collection Distribution points Programs Advertisements Product Compliance SMS Tree. and enter the following registry key (the ‘product code’). These are the source machines from which SMS distributes the installation files contained within the package.3 Advanced: Specify the uninstall settings: Select the check box ‘Remove software when no longer advertised’. Do include the { } brackets: {94FD0328-5120-432B-AE46-F30A312AEA95} 5 Now set up the package advertisement. use the New Distribution Points wizard: 1 2 Systems Management Server Site Database Site Hierarchy Collections Packages CA DLP package Access points 3 4 Advertisement Properties dialog. First.

. 7 When the advertisement is complete. Before you start using CA DLP. e-mail and other applications for the CA DLP integration features to start (see page 54). SMS deploys CA DLP to the target clients as scheduled. SMS then immediately uninstalls CA DLP from the target machines. you must specify the SMSQuietUninstall. the uninstall goes ahead but does not complete until the user closes the application. users must restart their browser. Schedule tab 1 Click here to schedule a mandatory assignment. This transform removes the need for user cooperation when uninstalling. These specify when the package is advertised to SMS clients. you edit the membership rules. We recommend that you schedule a Mandatory Assignment to ensure that CA DLP is installed on the target clients. there are things you must do first. General properties. SMS warns users on the target machines that an installation is imminent. SMS uninstallation Standard uninstallation You can use SMS to uninstall CA DLP from a client machine. If a browser or e-mail application is open on a target machine.Chapter 4 Client machines 65 6 Next. These are described in chapter 3. 2 Scheduling details for the Mandatory Assignment. As soon as the installation has completed. Advertisement Properties dialog. Simply remove the machine account from the CA DLP collection. i You created this transform on page 62.mst transform in the program command line when you set up the installation package (see step 4. define the advertisement Schedule properties. Just before deployment. these are a property of the collection. 2 1 Silent uninstallation If you want to uninstall CA DLP silently. 8 i Before you start using CA DLP. To do this. on page 63).

However. This is necessary to prevent your source machine starting the CA DLP service automatically after step 3.mst /i Snapshot installation 1 Prepare the source machine for a CA DLP installation. ghosting. Open this file and find the following line: CmdNew=/i Change this line to: CmdNew=TRANSFORMS=DisableAutostart. See also the considerations on page 69.66 CA DLP Deployment guide Snapshot operations This method involves taking a snapshot image of a CA DLP installation on a source machine. The TRANSFORMS property is described on page 511. 3 Install CA DLP. 5 Optional. For details about generating the transform. The transform prevents CA DLP starting automatically after installation. 4 Generate a snapshot image. i The snapshot image used when testing these instructions was a RapidInstall Package (RIP). The basic procedure is the same.2 Add the DisableAutostart. Note that there is no single term to describe this deployment method (or its variants). while the snapshot images themselves are also called wraps. 3 Install CA DLP 4 Create a snapshot image 5 Create a follow-up baseline image 6 Deploy the snapshot Target machines 1.1 Copy the \Software\win32\Client folder from your CA DLP distribution media to the source machine. disk-imaging and cloning. Snapshot installations break down into a six step procedure: Source machine 1 Prepare the source machine Snapshot installation This section covers the general procedure for snapshot installations. regardless of which third-party tool you use. 2 Using your preferred software tool. wrappers or packages. you must edit the setup. . we recommend you create and save a new baseline image at this stage. see page 506. based on the changes made by the installation wizard. Other common names include ghost imaging. 1 Prepare the source machine Some pre-configuration of the source machine is necessary to ensure that the final snapshot image contains the correct CA DLP installation information.mst transform to the \Client folder on the source machine. create a baseline image of your source machine. 2 Create a baseline image 1. 1. then transferring this image to multiple target machines (using a thirdparty tool). Note that /i is preceded by a space and must be at the end of the line.3 Still in the \Client folder on the source machine.1. the exact procedure for generating the snapshot image will naturally vary depending on the tool. 6 Deploy the CA DLP snapshot image to your target machines. You may find other third-party tools to be equally effective but these have not been tested. created with Altiris RapidInstall 3. To simplify any follow-up snapshots.ini file to reference the transform.

you can enter a ‘placeholder’ IP address and select the Bypass Validation check box. For example.Chapter 4 Client machines 67 2 Create a baseline image Using your preferred snapshot tool. Proceed to the Installing Applications screen. i The placeholder address can be the address of any real machine that is not a CMS or gateway server. 3.2 In the Connectivity Screen. To do this. otherwise the installation will fail and the snapshot will be incomplete. This is an image of the machine before CA DLP has been installed. then stop and create a baseline image. you can attach the snapshot to an e-mail and send it to your users. For example. you can save the snapshot to a shared network location. go to step 4. 6 Deploy the CA DLP snapshot To deploy the snapshot to your target client machines. You can then retrieve and use this baseline to generate future follow-up snapshots. create a baseline image of your source machine. to install CA DLP features omitted from the original snapshot). if you want a generic snapshot that can be easily customized and reused to install clients to different parent servers. third-party tools let you configure the snapshot image. (for example. This approach allows you to deploy several versions of the snapshot (for example. enter the name or IP address of the parent server. if you are using RapidInstall 3. 3. with each version specifying a different gateway as the parent server. omitting the CA DLP consoles). ` If you specified the actual parent server in step 3.1 If you want to customize the CA DLP installation. no further steps are required. if you are using RapidInstall 3. you can now set a baseline using the Altiris RIP creation wizard. go to the \Client folder on the source machine and run setup. to automatically reboot the target system after installation. When this completes. do so in the Custom Setup screen (see page 55).2.3 The installation wizard now has all the information it needs. 5 Create a follow-up baseline image If you anticipate a future need for follow-up snapshot images (for example. 3 Install CA DLP on the source machine Now run the CA DLP installation wizard. However: 3. choose any method that best suits your organization.exe: 4. This is an image of the source machine after CA DLP has been installed. 4 Create a snapshot image of the CA DLP installation Now create a snapshot image of the changes made by the CA DLP installation wizard.1 Typically.1. we recommend you now create and save a follow-up baseline image at this stage.1. For example. for example. Alternatively. you can resume the Altiris RIP creation wizard and proceed to the Build RIP screen. . Click Install to start the file transfer. or you can include it in a login script. Now is the time to configure the snapshot to meet your deployment requirements. one for each department in your organization). You must specify a real machine. The snapshot is ready to be installed.

1.parent=<actual parent> 1 Where <actual parent> is the name or IP address of your CMS or a gateway server. page 67). select the follow-up baseline image (see step 5 on page 67). In detail: 1 Specify the follow-up baseline image Using your preferred snapshot tool. start creating a new snapshot image.68 CA DLP Deployment guide ` If you used a placeholder IP address in step 3. you must (1. you can deploy follow-up snapshot images to machines already running CA DLP. To do this. you then create and deploy a follow-up CA DLP snapshot.2.parent=<placeholder parent> baseline image directly after creating the original snapshot. effect of installing Application Integration on top of existing CA DLP installations. adding or removing features as required. you could configure a follow-up snapshot to have the additive. First. Source machine Specify the follow-up baseline image Where <placeholder parent> is the name of the machine whose IP address you specified in step 3. you must: 1.2.properties file once again. For example.2) rerun the original CA DLP installation. This matches the follow-up baseline referred to in step 5 on page 67.3 Create a new baseline image 2 Modify the original CA DLP installation 3 Create a follow-up snapshot 4 Deploy the follow-up snapshot Target machines Installing a follow-up snapshot 1 If available.2 Rerun the original CA DLP installation (see step 3. 2 Rerun the CA DLP installation wizard.1 Rebuild your source machine. if you need to recreate this baseline.3 Create a new baseline image. if you initially chose not to deploy the Application Integration feature (see page 53) to client machines. you rerun the CA DLP installation wizard on your source machine and choose any new features you want. locate the startup. Find this line: default. you (or the target users) must now modify the snapshot to replace the ‘placeholder’ address with the actual parent server.3) create a new baseline image of your source machine. 1. However. If this is not available.2 Rerun the original CA DLP installation 1. and (1. (1. or cumulative. To ensure the follow-up snapshot only contains the latest modifications by the CA DLP installation wizard. . This is in the \System subfolder of the CA DLP installation folder. The procedure is summarized opposite: The basic idea is straightforward: on your source machine. 4 Deploy the new snapshot image to your target machines. This is why we recommend that you create and save a follow-up 1. See the previous column for an example file extract. Now change this line to: default. specify the baseline image that you created in step 5 on page 67. 3 Generate a follow-up snapshot image. 1. you must generate the snapshot from a baseline image of your source machine immediately after the original CA DLP installation.1 Rebuild the source machine Follow-up installations If required.1) rebuild the source machine.

Unlike the original snapshot. for Microsoft Outlook and Lotus Notes the source and target machines must use the same version of e-mail application. For example. if the target client machines use Microsoft Outlook 2007. Specifically. create a snapshot image of the changes made by the CA DLP installation wizard. the source machine must have the same operating system and same e-mail application as the target machines.Chapter 4 Client machines 69 2 Modify the original CA DLP installation Rerun the installation wizard and choose the new features you want to add (or the features you want to uninstall). using any method that best suits your organization. 4 Deploy the follow-up snapshot Now deploy the snapshot to your target client machines. 3 Create a follow-up snapshot Using your preferred snapshot tool. this time you do not need to edit startup. . Snapshot considerations If you use snapshot deployment methods. we recommend that you generate a snapshot image on a source machine that has the same configuration as the target client machines. Likewise.properties. we recommend that the source machine is running Microsoft Outlook 2007 when you generate the baseline image.

Integration with a new Notes installation If you are deploying a centralized Notes installation for the first time. Lotus Notes integration At install time. but they have not been tested. You can do this manually or. Updating notes. Specifically.0 with Service Pack 2 and Feature Release 2. i For Terminal Services and Citrix MetaFrame implemented on IBM Netfinitity Servers. CA DLP amends the ‘base instance’ of notes. we have tested the following Citrix configuration: Machine Citrix server Details Product: Citrix MetaFrame XP Application Server for Windows. However. when Notes is running as a centralized application on a terminal server or accessed via Citrix. and that their Notes e-mail activity is not monitored. you must ensure that each user’s copy of notes.redbooks.ibm. visit www.dll.dll add-in (see above). You do not need to manually update notes.70 CA DLP Deployment guide Integration with centralized applications CA DLP can integrate with centralized applications running on a terminal server or accessed via a Citrix application server product. more likely.ini files.5 and MS Outlook 2000 3 Client machine Operating system: Windows 2003 Professional i CA DLP may integrate successfully under other configurations. If this problem is not addressed. version 1. Integration with existing Notes installations If you have already deployed a centralized Notes installation.ini configuration files to include the CA DLP Notes client agent as a Notes add-in.ini is updated to reference wgnemno.dll add-in (see above). 4 Copy the base instance notes. CA DLP is not always able to locate and update the relevant notes.com.dll . For details. this can mean that CA DLP integration fails for some Notes users.0 2 Applications: MS Internet Explorer 5.ini to reference the wgnemno. CA DLP uses the Path registry value to locate and edit the ‘base instance’ notes. 1 Run a shared installation of Notes on the terminal server or Citrix server.ini to each user’s home drive.ini. You must then copy this base instance to all users’ home drive (as recommended by IBM—see the note below).ini To ensure that Notes integration operates correctly.ini.ini to reference the wgnemno. In particular. IBM provide recommended installation procedures for Lotus Notes. by some automated method. Find this registry value in the following registry key on the terminal server or Citrix server: HKEY_LOCAL_MACHINE\Software\Lotus\Notes\6. you must add this line: EXTMGR_ADDINS=wgnemno. you must install the CA DLP Notes client agent on the terminal server or Citrix server and then update each user’s copy of notes. CA DLP modifies users’ notes. Install the CA DLP Notes client agent on the terminal server or Citrix server.

It enables iConsole users to search for. That is. iConsole example search results screen i For iConsole known issues. including much simplified deployment and upgrade procedures and a significant reduction in maintenance and support overheads. they must direct their browsers to a URL based on the name or IP address of the machine hosting the front-end Web server. Application server: Sometimes referred to as the ‘back-end server’. Because it is browser-based. The front-end Web server generates the HTML content for the various screens in the iConsole. reviewers and compliance personnel. Front-end Web Server: iConsole users must direct their browser to the front-end Web server. it is also highly suitable for deployment in hot desking environments or a disaster recovery situation.5. It enables all event search and auditing activity conducted in the iConsole to be written to the CMS. . see page 549. It also minimizes the impact on network bandwidth and allows end-users to access a CMS over the Internet (for example. chapter 5 T Software components The CA DLP iConsole comprises the following components: iConsole: This is a lightweight. by using a virtual private network). browser-based application providing event searching and auditing features previously only available in the Data Management console. retrieve and audit events stored on the CMS. This chapter describes how to deploy the iConsole and its supporting Web services. It also submits all event searches generated in the iConsole to the application server (see below) and renders the matching events returned from the application server as HTML search results screens. this component provides the Web service that connects to the CMS. iConsole iConsole he iConsole delivers extensive benefits. It is primarily aimed at auditors.

Each application server is parented to a single CMS. This services all search requests submitted by the application server. Finally. while the Paris iConsoles (4b) connect to front-end Web server 3b. For example. 3a. 3b iConsole front-end Web servers. the New York iConsoles (4a) connect to front-end Web server 3a. but connect to a single shared application server. 4a. this configuration enables each user to connect to a local front-end Web server. 4b Browser-based iConsoles. The iConsole URL incorporates the name or address of the front-end Web server host. all XML search definition files are stored in the CMS file system. multiple application servers can connect to a single CMS. Each front-end Web server can only connect to a single. each serving different front-end Web servers but all connected to the same CMS. each application server has a default parent CMS. For example. but can be configured to connect to multiple CMSs if required (see page 84). . but it is possible to connect multiple front-end Web servers to a single application server. In this example. If required. two front-end Web servers each serve separate groups of iConsole users (for example users based in New York and Paris). 4a 4a 1 3a Internet 2 3b 4b 4b iConsole example deployment 1 CMS. with each front-end Web server connected to a central application server. Installation instructions on are on page 74. specific application server.72 CA DLP Deployment guide iConsole architecture The iConsole front-end Web server and application server are provided as separate components to allow maximum flexibility when deploying the iConsole. Reviewers and administrators use the iConsole to search for and retrieve events stored on the CMS and to update audit details for these events. Larger organizations may choose this configuration for load-sharing purposes. this may be preferable if your iConsole users are based in various offices around the world. All search SPs are stored in the CMS database. you may prefer to install the front-end Web server on your existing corporate Web server while installing the application server on an existing CA DLP server. This submits iConsole event searches and audit updates to the CMS and returns search results to the front-end web server. You can also have multiple application servers. In this example. 2 iConsole application server. These generate the HTML content for the various screens in the iConsole.

MaximumBulkAuditEvents MaximumResultSetSize PasswordExcludeChar PreAuthenticate SearchParamsCachePeriodMinutes SearchResultsCachePeriodMinutes SearchResultsConverterTimeoutSecs Page 104 104 104 90 101 98 97 86 85 97 97 92 SearchResultsDownloadConvertTo<Format> 95 SearchResultsDownloadFormat SearchResultsDownloadExt SearchResultsPageSize SearchResultsUpdateAuditStatus SessionTimeoutMinutes SessionTimeoutWarningSeconds SMTPServer WebServiceMachine WebServicePort WebServiceTimeoutSeconds WebServiceUseSSL 93 93 97 97 91 91 79 87 87 92 87 . Page 84 80 98 89 104 100 101 102 99 85 80 89 90 91 96 96 96 96 94 103 * Found in the \Web\Logging subkey. If you need to configure the iConsole or change its default behavior. you can find these registry values in the following registry keys: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web or WebService Registry values LogLevel * LogMaxNumFiles * LogMaxSizeBytes * LogonTimestampInterval LookupLDAPServers Registry values AdditionalCMSList AddressBookSearchLDAPFilter AllowUnlimitedSearch AllowURLLogon AlwaysLogSearchCriteria * ApplyPolicyToAuditEmails AuditEmailAddress AuditEmailAddressMask CaptureEventReviewTime DisableLoopbackCheck EnableAddressBookDropDownMenu EnforceEncryptedLogon EnforceLogonTimestamp EventCachePeriodMinutes EventDisplayIMActiveParticipantsOnly EventDisplayMaxIMParticipants EventDisplayMaxMailAddresses EventDisplayMaxSummaryParticipants EventMailDownloadFormat FriendlyNameLDAPAttribute * Found in the \Web\Logging subkey.Chapter 5 iConsole 73 iConsole registry values The table below describes the available registry values for the iConsole servers.

0 3 Post-installation tasks 5 Microsoft IIS 5. In particular. iConsole servers: pre-deployment checklist The host machine requires an appropriate operating system (1) and Microsoft Outlook (2). It must be a CA DLP server (3). Finally. Pre-deployment tasks Before deploying iConsole application servers and Front-end Web servers. 1 Operating system: Windows Server 2003 or 2008 2 CA DLP server 1 Pre-deployment tasks 3 Microsoft Outlook 2003 2 Install the iConsole 4 . Then you need to perform certain post-installation tasks. It also needs appropriate versions of . Kerberos must also be correctly configured (6). you must install an iConsole application server and one or more front-end Web servers. These steps are described in the following sections. you need to install the default event searches.NET Framework 2. .NET Framework (4) and Microsoft IIS (5). you must ensure that the target machines have .x or 6. you must provide them with the correct URL. to permit your reviewers to start using the iConsole. you need to confirm that the target machines meet the necessary software requirements (see below). Requirements: servers Application server and Front-end Web server Before installing an iConsole Application server or Front-end Web server. Next. check the host machine requirements on page 78. The overall procedure is summarized below. Before running the iConsole itself in a browser. First.x 4 Start the iConsole 6 Kerberos authentication iConsole deployment procedure These steps are described on the following pages. before installing an iConsole application server or front-end Web server. Other optional tasks include configuring a global sender for audit e-mails and renaming the iConsole virtual directory. you need to confirm that the target machine has the necessary software installed.74 CA DLP Deployment guide Deployment procedure Deploying the iConsole across your organization is a fourstep procedure. To do this. You must also ensure that the iConsole servers are correctly configured to communicate with your chosen SMTP server. Individual steps are described in detail on pages 74 to 107. you run the iConsole installation wizard on an existing CA DLP utility machine.NET Framework and Microsoft IIS correctly installed and configured (this allows the necessary Web services to run).

NET Web Service extensions—see page 76. Instructions for switching to the 32-bit ASP. i If running Windows Server 2008.NET Framework The host server must be running: .NET 2. We recommend that . . or is not practical. Microsoft Outlook For iConsole application servers only. i iConsole front-end Web servers do not require any other CA DLP software on the host machine.NET Framework is installed on the target server before Microsoft IIS.NET Framework section. if this was not the case. Special requirement for Windows Server 2003 x64 edition If you want to deploy an iConsole server on a machine running Windows Server 2003 x64 edition.0 To check the installed version of ASP.NET Framework .0 (32-bit) and the script maps. you may need to manually register the necessary ASP.NET. you must first install the 32-bit version of ASP.exe.0 are available in Microsoft Knowledge Base article 894435. run the CA DLP Version Check utility. .NET 2. The host server must be running: Microsoft Outlook 2003 or 2007 This ensures that CA DLP e-mail events are correctly converted to MSG files when downloading e-mails in the iConsole Search Results screen or when attaching original messages to audit e-mails.NET 2.Chapter 5 iConsole 75 Operating system The host server must be running Windows Server 2003 or 2008. i iConsole front-end Web servers do not require any Microsoft Outlook on the host machine. note the special requirement for Microsoft IIS 6 WMI Compatibility (see opposite). CA DLP server For iConsole application servers only. The host server must be a CA DLP server.NET 2. Search the output for the Microsoft . wgncheck.exe is described on page 78. This automatically connects the application server to a parent CMS. This article describes how to enable 32-bit mode and then install ASP.NET Framework provides various IIS Web Service extensions required by iConsole application servers and front-end Web servers. Wgncheck. We recommend that you install iConsole application servers on CA DLP utility machines—see page 30. You must also ensure that the status of ASP.0 is set to ‘Allowed’ in the Web service extension list in IIS Manager. About .NET Framework 2.0.

When you check the IIS version. we strongly recommend that you install.x (see next page). Finally. ensure that the following role services are installed: 4 ` Web Server > Management Tools Choose all IIS 6 Management Compatibility items ` Web Server > Application Development Choose ASP. ` Web Server > Common HTTP Features Choose Static Content. you must register it manually—see page 76. or enable. SMTP Service. For this reason. Special requirements for Windows Server 2008 If you are running Windows Server 2008.0.NET. Browse to Roles > Web Server (IIS) and choose Add Role Services.exe is described on page 78. the IIS subcomponent.x and 6.NET\Framework\v2. In the Select Role Services screen.NET. must be running on the target server—see page 79. To check the installed version of ASP.76 CA DLP Deployment guide Microsoft IIS The host server must be running: Microsoft Internet Information Services (IIS) version 5 or 6 But note the special requirements for IIS extensions for machines running IIS 5. Search the output for the Microsoft IIS section.NET Framework (the minimum versions are specified above). ` Web Server > Security Choose Windows Authentication. If this is not possible or practical. Registering IIS extensions iConsole application servers and front-end Web servers require IIS and various Web Service extensions provided with . .exe. you also need to install various Web Server role services: 1 2 3 Log on to Windows Server 2008. Click Start and choose Server Manager. you also need to confirm that the ASP. All associated role services are installed automatically. run the CA DLP Version Check utility. but you must then manually register the Web Service extensions before running the iConsole installation wizard: 1 On the target server. run the following command: aspnet_regiis /i 3 Restart the target server. Wgncheck. wgncheck.NET Framework. If it is not. you can install . IIS on the host server before installing . go to the following folder: %windir%\Microsoft.NET Web Service extension is registered with IIS.50727 2 In this folder.NET Framework before you install IIS.

com/technet/prodtechnol /windowsserver2003/library/ServerHelp /b207ee9c-a055-43f7-b9be-20599b694a31.50727\CONFIG This file is in XML format. i In order for IIS 5. this account has minimal rights to run system processes. For details.x to use MAPI services on the application server. Kerberos must be correctly configured.NET\Framework\v2.0. you must assign administrator rights to the local IWAM_<machinename> user—see page 549. 3 i You do not need to change the default account for IIS version 6 and higher.x installed.x By default. For security reasons.x runs under the ASPNET user account. The URL for this article is: http://www. You must do this before installing the iConsole! Kerberos authentication Applicable if the application server and front-end Web server are on separate machines. see the Microsoft TechNet article ‘Allow a computer to be trusted for delegation’. Check the Windows System Event log for errors. Internet Explorer on the user's machine must have the Enable Integrated Windows Authentication (requires restart) setting enabled. which has the system privileges required by the iConsole servers. you mst adhere to the following requirements: 1 The iConsole servers must be in the same Active Directory domain.config.microsoft. IIS 5. you need to change this account to one with sufficient privileges—see below.x process runs using the LocalSystem account. To change the account. See the next section for details. 4 . If the value for WebServiceMachine is not the Fully Qualified Domain Name (FQDN).mspx 2 You must configure the Microsoft Internet Information Services (IIS) version 6 Application Pool to run as the Network Service account. then the front-end machine must be trusted for Delegation. or to record the native user name being used to access the CMS). This is the default configuration. using Windows Delegation. <processModel autoConfig="true"/> To this: <processModel autoConfig="true" userName="SYSTEM"/> This change ensures that the IIS 5. This is the default setting in most configurations of Internet Explorer.Chapter 5 iConsole 77 Special requirements for IIS 5. if the target machine has IIS 5. Locate the <processModel> tag and change the following entry: From this: The iConsole uses Microsoft's Kerberos Authentication to allow the credentials of the user accessing the iConsole to be passed to the CMS for logon (either for direct use if using CA DLP single sign-on functionality (see page 109). Therefore. For this process to work if the iConsole front-end server and application server are on separate machines. machine.NET Framework file. You can find the file in this folder: %windir%\Microsoft. you need to edit the .

if Kerberos is not active. Dashboard: To display the iConsole dashboard. The connection is with the machine \\UX-SRVR. The command completed successfully. Find this utility in the \Win32\Support folder on the CA DLP distribution media. Is Kerberos active? To check whether Kerberos is active on an iConsole server. such as: The secure channel from UX-HARDY-AS to the domain UNIPRAXIS. These requirements apply to the browser host machine. please refer to support.124.exe detects the file version of various software components (for example. they want to open a downloaded . the account must be reset on the domain controller. The most common local problem is timing. check for Kerberos entries in the Security event log in Windows Event Viewer.exe Wgncheck. if Kerberos cannot authenticate a user because their account has become corrupt in Active Directory. this command generates a confirmation.78 CA DLP Deployment guide If you do not adhere to these requirements. Microsoft Windows Installer and Internet Explorer). 7 or 8. . the browser host machine must be running: Adobe Flash Player 9 or later (Minimum version 9. Other Kerberos problems typically affect the entire domain or require domain administrator permissions. also in the \Win32\Support folder. the reviewer can still save the downloaded .cab in the \Support\Tools folder on your Windows distribution media. this can result in the error ‘You are not authorized to connect to the CA DLP iConsole’.com ux-hardy-as i netdom is not installed by default.msg file). compares these local versions against the minimum version supported by CA DLP.0.COM has been verified. run a netdom command: Syntax Requirements: browser host machine The iConsole is a browser-based application. with a 401 error code. and displays the results for each component. but is available from support. the server clock must be within five minutes of the domain controller clock.htm. For usage instructions.COM.0) Version check utility: Wgncheck. For example. netdom verify /d:<domain> <server> Example netdom verify /d:unipraxis. Internet Explorer: You need to run the iConsole in Microsoft Internet Explorer 6. if a reviewer wants to view a copy of an actual e-mail (that is. Outlook: When browsing search results.UNIPRAXIS. If Kerberos is active. i If Outlook is not available. the browser host machine also needs Microsoft Outlook 2003. or 2007.msg file.

remote SMTP server. Select Internet Information Services (IIS) and click Details to display the IIS subcomponents. you must edit the registry on the front-end Web server to point to a remote SMTP server. 2 Configure the SMTPServer registry value If the SMTP service is not being used on the local server. These e-mails are referred to as ‘audit e-mails’. then click Finish to close the wizard. Open the Windows Components Wizard. see page 100. the DNS name of the server hosting the SMTP service. Enable the SMTP Service The SMTP Service allows the local machine to deliver SMTP e-mails. a machine that can deliver SMTP e-mails).Chapter 5 iConsole 79 Set up SMTP e-mail From the iConsole reviewers can send e-mails to colleagues. 3 4 Windows Components Wizard: IIS subcomponents 5 Click Next to build the new configuration settings. ensure that you are logged on with local administrator rights. . alerting them to messages or issues that require their attention. you must configure the front-end Web server so it can connect to an SMTP server (that is. locate the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web Within this registry key. If the SMTP service is not being used on the local server. Select the SMTP Service subcomponent and click OK to return to the Windows Components Wizard. 1 On the host machine for the front-end Web server. you can set this value to your Exchange server (if it is configured to relay SMTP messages). but if required you can enable the SMTP service locally. the front-end Web server points to an existing. This is available from the Add or Remove Programs applet. For example. set this value to a remote SMTP server. i The SMTP server must be configured for pass-through authentication. i To determine the identity of the sender for audit e-mails. edit the following value: SMTPServer SMTPServer Type: REG_MULTI_SZ Data: This defaults to localhost. To allow iConsole users to send audit e-mails. To do this. Typically. that is. This service supports the transfer of e-mails.

edit the following values: EnableAddressBookDropDownMenu EnableAddressBookDropDownMenu Type: REG_DWORD Data: This defaults to 1. from the address book. 1 2 3 iConsole Compose Mail dialog: Autocomplete enabled As a reviewer types letters in the To. You only need to do so if. the iConsole automatically shows a list of matching entries in the address book. but not groups. Cc or Bcc address fields by searching for matching entries in an address book such as Active Directory. i The LDAP directory is specified by registry value LookupLDAPServers. AddressBookSearchLDAPFilter AddressBookSearchLDAPFilter Type: REG_SZ Data: This value defines the filter used to query the LDAP directory for matching address book entries. . But you can configure by editing values in this registry key: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web Within this registry key. for example. But reviewers can still search for matching address book entries using the iConsole Address Selector dialog— see the screenshot below . See page 101. Cc or Bcc field (1). a reviewer can click Search (2) to list matching address book entries (3). Address book searching is automatically enabled when you install a front-end Web server. iConsole Address Selector dialog After typing the first letters of a recipient’s name in the Search Address Book field (1). 1 2 If set to zero. reviewers can fill in the To.80 CA DLP Deployment guide Configure address book lookups When composing audit e-mails in the iConsole Compose Mail dialog. Cc or Bcc fields of the iConsole Compose Mail dialog. Set this value to 1 to enable autocomplete in the To. That is. autocomplete is disabled. you only want to return users. matching address book entries are automatically listed (2). as a reviewer types the first letters of a recipient’s name. The default query is: (&(|(givenname={0})(samAccountName= {0}))(|(objectCategory=person) (objectCategory=group))) You do not normally need to change this value.

see page 82. ` Use SSL: If you intend to use SSL to communicate over a secure port (for example. Type localhost to specify the local machine. Install on a utility machine: If you plan to install an iConsole application server. you must also update the application server to use the same port. go to step 3. select this check box. This defaults to port 80. 5 . Install the iConsole You install the iConsole servers using the CA DLP iConsole installation wizard. Click Install to start the file transfer. 4 The installation wizard now has all the information it needs. ` Port: Specify the TCP port used for communication between front-end Web server and the application server. 1 To launch the iConsole installation wizard. CA DLP iConsole Front-end Web Server Application Server 2 iConsole installation wizard: Configuration screen for front-end Web server Custom Setup screen If you only install the front-end Web server. ` Server: Specify the name or IP address of the machine hosting the application server.exe. the host machine must already have a CA DLP server installed. You do this in the iConsole Configuration screen. install a server now—for details. These are described on page 71. run setup. We recommend installing the application server on a CA DLP utility machine—see page 30. Go to step 4. you must specify which application server it connects to. choose the features you want to install. see chapter 2 ‘CA DLP servers’. 443). 3 If you only install a front-end Web server. There are several optional post-installation tasks.Chapter 5 iConsole 81 Deploy the iConsole Before installing Before you launch the iConsole installation wizard: IIS: Note the IIS requirements on page 76. This ensures that the port used for communication between the front-end Web server and the application server will use SSL. If this is not so. If you specify a non-default port. If you install both the application server and front-end Web server on the same machine. In the Custom Setup screen. For details. the front-end Web automatically connects to the local application server. Find this in the \Win32\Web folder on your CA DLP distribution media.

see page 92. you need to change the TCP port used by the iConsole servers to communicate. you can increase the time available to display the event in the Search Results screen. iConsole timeouts Modify the session timeout: By default. Enable pre-authentication: This ensures that iConsole performance is not undermined by slow authentication See page 85. see page 83. Hide user logon credentials in the iConsole: If integrating the iConsole with your own Web application. Disallow specific password characters: You can prevent users having specific characters in their iConsole passwords. . Create a download button: To add a button that enables reviewers to download search results to a different format. These are listed below and on page 83.82 CA DLP Deployment guide Post-deployment tasks After installing the iConsole. To rename it. iConsole connectivity Rename IIS virtual directory for front-end Web server: This virtual directory is incorporated into the target URL for iConsole users. See page 86. see page 84. and to specify the retention period for these searches. Search result handling Specify the format for downloaded search results: You can set the download format for all search results. Enable anonymous access: This is necessary if your iConsole servers cannot communicate using Windows authentication. see page 93. Configure the search results cache: To specify the maximum number of search results. See page 86. Changing the TCP port: If. Configure how e-mail or IM participants are displayed: You can configure how many e-mail or IM recipients the iConsole displays in the Search Results screen. see page 94. after installation. See page 91. Set up the Review Queue: To install the Review Queue search and reports. List continues on next page. Modify the Web Service timeout: To change how long search results are retained in the cache list. there are two supported methods for passing user credentials to the CMS. see page 84. see page 94. iConsole sessions terminate automatically. Modify the event timeout: For very large events. Searches and reports Install default searches and reports: To install the default iConsole event searches and reports. see page 83. there are various optional post-deployment tasks. To change the default timeout. Set e-mail download type: To specify the file format for downloaded e-mails. Modify the results conversion timeout: To specify the maximum time allowed for converting results to formats such as PDF. see page 87. To do this. Connect iConsoles to multiple CMSs: To allow iConsole users to connect to multiple CMSs. see page 92. see page 90. See page 96. See page 88. see page 97. or enable unlimited results sets.

0 CMS. before your reviewers can run the RQ search. It also includes various reports that provide administrators with technical information about RQ database searches. see page 99. your DBAs must populate the queue with events that need to be reviewed. Set an address mask: This is an e-mail address pattern that helps the iConsole populate To: and From: fields in audit e-mails.msi) to install the iConsole search and reports for the Review Queue. You must run this installation wizard separately on your CMS and on each of your iConsole application servers and front-end Web servers. Install iConsole searches and reports Install default searches and reports Use the reports installation wizard (reports. . see the Review Queue Guide. see page 103. see page 100. see page 99. However.msi) to install the iConsole standard searches for CA DLP r12. Set up iConsole servers for Network Load Balancing: To deploy your iConsole servers in a cluster (or Web farm) using Windows Network Load Balancing.Chapter 5 iConsole 83 Auditing and audit e-mails Enable audit functionality: To enable the auditing features in the iConsole. i Defining new custom event searches is discussed on page 108. For full details. Set global preferences: These cover auditing and printing preferences.0. Specify the LDAP attribute used in recipient lists: To change the LDAP attribute used to populate To. Configure audit e-mails: These are e-mails sent by reviewers to colleagues. To determine how the From: field is set. see page 23. You can also specify whether users can override these global preferences. be sure to install the same combination of searches and reports. Note that the required RQ database components are installed automatically when you when you install or upgrade to an r12. this is available to download from CA Technical Support. you must install the RQ search and reports on your CMS and on each of your iConsole application servers and front-end Web servers The Review Queue (RQ) feature enables to reviewers to generate lists of events that they need to review or audit. For a summary of the deployment procedure. Set up the Review Queue Use the reports installation wizard (reports. Specifically. it provides an iConsole search that reviewers can run to retrieve all unreviewed events in their review queue (unreviewed events are assigned to reviewers based on their management groups). See page 107. As for the default searches. see chapter 6 on page 111. see page 105. In each case. Cc and Bcc lists in Compose Mail dialogs. For installation details. and the maximum events shown on each page of search results. Enable time recording for reviewed events: To record how long reviewers spend viewing or auditing individual events. see the Database guide. General Modify the iConsole log file registry values: To configure iConsole logging levels. See page 102. see page 104.

you must configure the application server: 1 On the application server host machine. modify this registry value: AdditionalCMSList AdditionalCMSList Front-end Web server The installation wizard creates this virtual directory: CADLP This virtual directory is incorporated into the target URL for iConsole users—see the previous section. 3 Now. you can rename this virtual directory in IIS. If required.84 CA DLP Deployment guide Set up iConsole connectivity Rename IIS virtual directory for front-end Web server This task is optional. Connect iConsoles to multiple CMSs To allow iConsole users to connect to multiple CMSs. Application server The installation wizard creates this virtual directory: CAWebService ! Do not rename this virtual directory! iConsole logon screen 1 1 Choose which CMS to connect to. . Both are installed onto the default Web site for IIS (also called the home directory). For example. you may want to rename it to Compliance. go to the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\WebService 2 Within this key. when users next use the iConsole they can browse to the Logon page and choose which CMS to connect to. Type: REG_SZ Data: Specifies a comma-separated list of CMSs that the local application server can connect to. The iConsole installation wizard creates separate virtual directories for the front-end Web server and application server.

HTTP 401. locate the following registry key: HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Control\Lsa After making this registry change. you must now implement a Microsoft workaround. you will also need to implement a Microsoft workaround to accommodate security fixes introduced for Windows XP SP2 and Windows Server 2003 SP1. If you experience poor performance and you suspect that this is due to slow authentication. This article describes two alternative workarounds: disabling the loopback check. set the following value to True: PreAuthenticate PreAuthenticate . configure the front-end Web server to use pre-authentication.1 errors). 1 First. This ensures that the logon credentials are always passed to the application server. you can modify the registry on the iConsole front-end Web server to use pre-authentication. 1. i This improvement does not apply to search performance. Authentication between the front-end Web server and application server must be correctly configured for best performance.2 Within this registry key. when displaying individual events or paging between screens. for example. To prevent this instability. DisableLoopbackCheck DisableLoopbackCheck 3 Restart the machine hosting the front-end Web server. 2 Changing this registry value can lead to instability (for example. which is dependent on how the CMS database is configured.Chapter 5 iConsole 85 Enable pre-authentication This task is optional.1 Locate the following registry key on the frontend Web server: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web 1. rather than using 'anonymous access'—see page 90.1 As described in article Q896861. and specifying host names. 2. The required workaround is described in MS Knowledge Base article Q896861. create the following registry value and set it to a DWORD value of 1. We recommend that you implement the first method and disable the loopback check: 2.2 In this registry key.

x) or Authentication and Access Control (IIS 6. For example. you must enable anonymous access for both of the iConsole virtual directories. By default. For example.x) to open the Authentication Methods dialog. you need to configure the authentication methods for both of the iConsole virtual directories. To enable anonymous access. locate the following registry key on the front-end Web server: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web 2 Within this registry key. create or modify the following value: PasswordExcludeChar PasswordExcludeChar Type: REG_SZ Data: Defaults to empty. enable anonymous access only. 2.1 As before. in the Properties dialog. to disallow: < > ( ) " ' % .86 CA DLP Deployment guide Enable anonymous access If your iConsole application servers and front-end Web servers are deployed in an environment where they cannot communicate using Microsoft Windows authentication.x) or Authentication and Access Control (IIS 6. To do this: 1 In ISS. . Specify disallowed characters in logon passwords The iConsole provides CA DLP users with the ability to change their logon password. 1. no authentication credentials are required. now edit the properties of the front-end Web server virtual directory (its default name is cadlp).&+-= The new password rules become effective for all subsequent logon sessions. & + .x) to open the Authentication Methods dialog.2 In the Authentication Methods dialog. 1. edit the properties of the application server virtual directory. for security reasons.2 In the authentication dialog. 2 Still in ISS. the front-end Web server’s domain is not trusted by the application server’s domain. go to the Directory Security tab and click the Edit button under Anonymous Access and Authentication Control (IIS 5. CAWebService. 2. i We recommend that you specify this list globally using the machine policy setting ‘Prohibit password characters’ on the CMS. This method ensures that when the front-end Web server accesses the CAWebService virtual directory. Specifies which characters are not allowed as part of a password. To do this: 1 On the iConsole front-end Web server.= Set this registry value to: <>()"'%. you may need to do this if the application server and front-end Web server are in separate domains and where. You can configure the iConsole to disallow specific characters in these passwords.1 In the Properties dialog. go to the Directory Security tab and click the Edit button under Anonymous Access and Authentication Control (IIS 5. these are named CA and CAWebService (see page 84). enable anonymous access only.

you need to edit the registry on the front-end Web server: 1 On the host machine for the front-end Web server. This section provides instructions for changing the application server or TCP port after installation.Chapter 5 iConsole 87 Specify a non-default TCP port When installing the iConsole application server and front-end Web server separately using the installation wizard.3 If you are using SSL to communicate over a secure port (for example. you need to configure the following registry value: WebServicePort WebServicePort This REG_SZ value defaults to 80. you must ensure that the application server is communicating on the same port. 3. ` If this value is set to either LocalHost. the iConsole assumes that both components are hosted on the same machine. but if required you can specify a non-default port at installation. This can be checked using Internet Information Services (IIS). ` If this value is not set to Localhost or the host machine for the front-end Web server. This defaults to port 80. 3.1 Change this value to the TCP port number you want to use. . you must specify the TCP port used for communication between them (see page 81). locate the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web 3 In the same registry key located in step 1. you need to configure the following registry value: WebServiceUseSSL WebServiceUseSSL This REG_DWORD registry value defaults to zero. It specifies the TCP port used for communication between the front-end Web server and the application server. Set this to 1 if you want the port used for communication between the front-end Web server and the application server to use SSL. 443). or the name of the machine hosting the front-end Web server. 2 In this registry key. you need to specify the name of the machine hosting the application server. you need to check the following registry value: WebServiceMachine WebServiceMachine This REG_SZ value specifies the name of the machine hosting the application server. 3.2 If you do change the TCP port. To do this.

i Both methods are supported by SSL connections. But see next column. so avoiding the need for users to manually log on.88 CA DLP Deployment guide Hide user logon credentials in the iConsole If integrating the iConsole with your own Web application. These methods are: Web form logon. Web form logon method Using this http post method. The form then submits these credentials to the iConsole front-end Web server. ` The virtual directory for the iConsole front-end Web server is ‘cadlp’. ` Your CMS is not using single sign-on. which uses http get. The example assumes your CMS is not using single sign-on (page 109). You do not need the username and password fields. you can omit the "username" and "password" fields --> <input type="hidden" name="formAction" value="login" /> <input type="hidden" name="username" value="unipraxis\srimmel" /> <input type="hidden" name="password" value="password" /> <input type="submit" value="Logon" /> </form> . your Web application passes the user's CA DLP account credentials to an HTML form. <form id="friConsole" method="post" runat="server"> <!-. so user credentials are submitted using HTTPS. which uses http post and URL query string logon. ` The iConsole front-end Web server is running on the local machine.aspx"> <!-. Also. ` Your form only needs to include the formAction and submit input fields.If your CMS is using single sign-on. This ensures that user credentials are not exposed in the browser Address bar. Web form logon method: HTML syntax Note that the formAction name is case-sensitive. there are two supported methods for automatically passing user credentials to the CMS. this example assumes that: If your CMS is using single sign-on: ` You can set the action to use HTTP when submitting the user credentials. Example HTML syntax is shown below. you can use "http" --> <action="https://localhost/cadlp/default.If your CMS is using single sign-on.

set the following REG_DWORD registry value to 1: AllowURLLogon AllowURLLogon i For full implementation details. If it is not. CA DLP also enables you to encrypt HTML POST form variables using either ‘Triple DES’ (Data Encryption Standard) or ‘AES’ (Advanced Encryption Standard). For example. This further encryption can help to prevent ‘replay’ and ‘man-in-themiddle’ attacks. To enable this method: 1 Locate this registry key on the front-end Web server: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web 2 Within this registry key. Enforcing encrypted logons In addition to SSL support. where users are working remotely and creating traffic across the internet. then the POST form variable supplied with the Web form logon method must be encrypted. This additional encryption can be used in environments where an SSL session could potentially be intercepted. This is because the user's name and password are appended to the iConsole URL in the Address bar and are therefore potentially visible to other users. However. this logon method is only suitable for iConsole deployments that hide the browser Address bar. please contact Technical Support—see page 23. . To enforce encrypted logons: 1 Locate registry key on the front-end Web server: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web 2 Within this registry key.Chapter 5 iConsole 89 URL query string logon method This logon method uses http get and passes a user's CA DLP account credentials to the iConsole in the form of a URL query string. set the following REG_DWORD registry value to 1: EnforceEncryptedLogon EnforceEncryptedLogon ! If encryption enforcement is applied. then the logon fails.

Results conversion timeout—see page 92. LogonTimestampInterval LogonTimestampInterval Type: REG_DWORD Data: Defaults to 5 (minutes). If set to 5. if the timestamp is 12:00. please contact Technical Support— see page 23. Modify the session timeout By default. the logon timestamp must be within 5 minutes either side of the current time. i For full details on implementing these additional security measures. Specifies a valid time interval.90 CA DLP Deployment guide Enforcing a logon timestamp and timeout For added security. then the POST variable supplied with the Web form logon method may include a timestamp which is checked to see if it is within a specified time range. a session will fail to terminate correctly if a user quits the iConsole by clicking the browser Close button instead of clicking the Logoff button in the iConsole. The warning message itself will timeout after 20 seconds if no action is taken and the user is redirected to the Reconnect screen. The automatic session timeout ensures that disconnections are handled efficiently and ensures that hung sessions do not remain on the iConsole application server. For example. which determines if a logon request occurs within a configurable time period. If this happens. ! If it is enabled. Set up iConsole timeouts The section describes how to modify the default timeouts for the iConsole. formatted in US date format (that is. then the timestamp is valid from 11:55 to 12:05. To enable and configure the allowed range of timestamps. the session will persist on the application server. Event timeout—see page 91. i The iConsole session timeout overrides any specified Microsoft IIS timeout. it displays a warning that the current session is about to expire. If it is not within this range. These are the: Session timeout—see below. . you can set up a timestamp variable. This can help to prevent 'replay attacks'. For example. you need to configure these registry values on the front-end Web server: EnforceLogonTimestamp EnforceLogonTimestamp Type: REG_DWORD Data: Defaults to 0. then the logon fails. the time of the request (in UTC time) must be submitted via the ‘timestamp’ POST variable (embedded inside the encrypted ‘agentID’ variable). To use this optional timestamp. The automatic timeout ensures that the residual session left after clicking the Close button is eventually terminated when the timeout expires. Clicking Cancel enables you to reset the session timeout for a further 20 minutes. Set to 1 to enforce the timestamp in the POST form variables. Web service timeout—see page 92. if the iConsole detects no user activity (such as running a search or auditing an event) for 20 minutes. ‘mm/ dd/yyyy hh:mm:ss’). where they can consume system resources.

Specifies the cache timeout (in minutes) for viewed events in the iConsole. . You can therefore configure how long these events are retained in the cache list. This is especially noticeable when viewing large events. its details are cached by the iConsole application server to enable faster viewing of the same event in future. modify the following values: SessionTimeoutWarningSeconds SessionTimeoutWarningSeconds Type: REG_DWORD Data: Defaults to 20. Specifies the session timeout (in minutes) for the iConsole. The timeout countdown begins as soon as the user logs on to a CMS and restarts each time CA DLP detects a key press or mouse click. If the timeout expires and no user activity was detected. you need to modify values in the following registry key on the front-end Web server: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web Modify the event timeout When an event is viewed in the iConsole. modify the following value: EventCachePeriodMinutes EventCachePeriodMinutes Type: REG_DWORD Data: Defaults to 5.Chapter 5 iConsole 91 Configure the session timeout and warning message To lengthen or shorten the automatic session timeout. The timeout begins when the event is added to the cache. SessionTimeoutMinutes SessionTimeoutMinutes Type: REG_DWORD Data: Defaults to 20. To configure this timeout. or to adjust how long the session timeout warning is displayed. Within this registry key. these lists of cached events can potentially use up a large amount of resources. after which they are released. If multiple users perform large searches and then view multiple events. When the timeout expires. that event is removed from the cache. CA DLP terminates the current session and displays the iConsole Logon screen. Specifies how long (in seconds) the session timeout warning is displayed before the user is redirected to the Reconnect screen. you need to modify a value in the following registry key on the iConsole application server: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web Within this registry key.

That is. By default. Each time an individual event is viewed in the iConsole. the front-end Web server has 100 seconds to download and display the event in the Quick View pane of the Search Results screen.config file on the front-end Web server. you may need to increase the Web service timeout.2 Find the httpRuntime executionTimeout attribute and set this timeout to be slightly longer than the WebServiceTimeoutSeconds timeout. Apache FOP) to convert the output. To safeguard against the conversion process failing or taking too long. Specifies the maximum time allowed (in seconds) for the results conversion. If you do increase the timeout. the front-end Web server calls the Web service on the application server. this call times out after 100 seconds. . To do this. you need to modify a value in the following registry key on the iConsole front-end Web server: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web Within this registry key. this timeout may expire before the event has fully downloaded. Such reports typically require a post-processing application (for example. you need to modify a value in the following registry key on the iConsole application server: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\WebService Within this registry key. modify the following value: WebServiceTimeoutSeconds WebServiceTimeoutSeconds Type: REG_DWORD Data: Defaults to 100. modify the following value: SearchResultsConverterTimeoutSecs SearchResultsConverterTimeoutSecs Type: REG_DWORD Data: Defaults to 90. it does not apply to the time taken to retrieve the report results from the database. Specifies the timeout (in seconds) for the Web service running on the application server.1 Edit the web. An on-screen warning notifies the reviewer that the report has failed and a corresponding entry is written to the iConsole log file (see page 104).92 CA DLP Deployment guide Modify the Web Service timeout i It is highly unlikely that you will need to modify this registry value. To configure the results conversion timeout. the report is canceled. If extremely large events are failing to display in the iConsole Search Results screen. you also need to increase the iConsole request timeout: 2. When the timeout expires. If this timeout expires before the conversion is complete. the iConsole displays reports in XML Spreadsheet format. The timeout begins when the conversion process starts. find this file in the CA DLP installation folder. you can specify the maximum time allowed for the conversion. then increase this timeout. Modify the results conversion timeout By default. But for extremely large events (whose size is measured in tens of megabytes). the report is effectively canceled. but some reports output results in other formats such as PDF. 2. In these exceptional conditions.

i To set the default format for downloaded e-mails. in the various tabs at the bottom of the Search Results screen. set this value to csv to download search results to a comma-separated value file. the iConsole displays all event information. including recipient details. You can download the entire set of search results to formats such as XLS and CSV. see page 23. You can configure how the iConsole handles these results. set this value to xml to download search results to a spreadsheet file compatible with Excel 2007. To set this to a different download format. the ‘Download all results’ button downloads results to XLS. For example. CA DLP provides built-in support for xls and csv format. custom file formats. see the iConsole search definition guide. Specify the default format for downloaded search results i For full details. This registry value then ensures that the downloaded file is associated with correct application.’ This guide is available to download from CA Technical Support. search the index for ‘downloads. add these registry values: SearchResultsDownloadFormat SearchResultsDownloadFormat Type: REG_SZ Data: Specifies the file type for downloaded search results. see page 94. or xls to download to an Excel spreadsheet. Within this registry key. For example. SearchResultsDownloadExt SearchResultsDownloadExt Type: REG_SZ Data: Specifies the file extension the iConsole will use when downloading search results. you need to configure the following registry key on the iConsole application server: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web . By default.Chapter 5 iConsole 93 Set up search results handling When you run a search and view its results.

or 2007. add the following value: EventMailDownloadFormat EventMailDownloadFormat Type: REG_SZ Data: Specifies the default file format for any e-mail downloaded using the iConsole which is not automatically downloaded in . Creating an additional download button on the toolbar You can configure the iConsole to add a toolbar button to the Search Results screen that enables reviewers to download search results to a different format.MSG format. the iConsole host server must be running Microsoft Outlook 2003. you need to add it to the following registry key on the front-end Web server: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web Within this registry key. ZIP. } --> </script> ]]> </script> … . then the iConsole checks a registry value on the front-end Web server to see which file format to use.MSG file format if the mail body is in . then the e-mail can only be downloaded in .MSG file format: Microsoft Outlook Exchange Server Exchange Journal mailbox Symantec Enterprise Vault If the e-mail is from a different source. See the example below: <tool name="TXT_download" tooltip="Download file in TXT format" icon="download-TXT. If this setting does not exist or is left blank. you need to configure the <tool> element and DownloadResults function in the iConsole search definition. Otherwise. If this flag does not exist. i To enable . plus any attachments.ZIP file containing an RTF representation of the e-mail message.MSG e-mail download.94 CA DLP Deployment guide Specify the format for downloaded e-mails You can specify the supported file formats for e-mails downloaded via the iConsole Search Results screen. and the e-mail does not satisfy the criteria listed above. or cannot be read. To do this. then the iConsole checks the event for a ‘MAPI-enabled’ flag.gif" function="DownloadTXT"/> <script> <![CDATA[ <script language="javascript"> <!-function DownloadTXT() { DownloadResults('txt'). To configure this registry value. it will be downloaded as a . Set this to MSG.RTF format. E-mail events from the following sources are automatically downloaded in . or TXT.

Post processing To configure the iConsole to download search results to non-binary formats such as PDF. ` Write a transformation to render the search results to the custom format. you will need to create it. Type: REG_SZ Data: Specifies the full path and file name of the post processor. <results … format="$doc:results. SearchResultsDownloadConvertTo<Format> Name: Replace <Format> with the download format created by the post processor. the iConsole displays search results in XML Spreadsheet format. This post processor is specified in the following registry key on the iConsole application server: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\WebService In this key. If the file does not already exist. such as PDF. For example. For a more detailed description of supported functionality. you need to: ` Define the custom format you want using an xsl:choose tag. accessible on the iConsole application server. 1 In the custom format stylesheet results-formatscustom. see the iConsole Search Definition guide. To do this. reference the custom format using the format attribute in the <results> element. Writing such transformations is beyond the scope of this Deployment guide. i For full details. downloading’. to convert downloaded search results to PDF format: 1 Create the following registry key: SearchResultsDownloadConvertToPDF 2 Set the data to C\Myfolder\MyConvertor. but you can also implement custom formats using Extensible Stylesheet Language Transformations (XSLT). you must create the following registry value: SearchResultsDownloadConvertTo<Format>> Custom file formats CA DLP provides built-in support for XLS and CSV download formats (see above). 2 In the search definition file. i This file is located on the iConsole application server in the \Web\transformations folder. that takes the names of an input file and output file as parameters and performs the conversion from one to the other.bat. you need to define a custom download format that uses a post processing step to make the conversion. These can then be exported into Microsoft Excel.Chapter 5 iConsole 95 Setting the default format for displaying search results By default. This must be a command line application.xsl. you need to configure the search definition file and the custom format stylesheet. search the index for ‘results.txt"> . see the iConsole search definition guide.

96

CA DLP Deployment guide

Configure how many participants are displayed
When you view an e-mail or IM event in the Search Results screen, the iConsole lists all the ‘participants’ (e-mail recipients and senders or IM participants) in the Mail and Information tabs. If the event has a large number of participants, the process of retrieving them can take a long time and sometimes causes timeout problems. You can configure how many participants are displayed in these tabs by configuring values in this registry key on the iConsole application server: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web If this number is exceeded, the list of e-mail addresses in the Mail tab is truncated. The full list of recipients for outgoing e-mails is available in the Summary section of the Information tab. For incoming e-mails, CA DLP only stores the details for a single sender and recipient.

Configuring the number of IM participants
You can configure how many participants the iConsole displays in the IM Message tab of the Search Results screen. To do this, modify the following values: EventDisplayMaxIMParticipants EventDisplayMaxIMParticipants

Configuring the number of event participants
You can configure how many participants the iConsole displays in the Information tab of the Search Results screen. To do this, modify the following registry value: EventDisplayMaxSummaryParticipants EventDisplayMaxSummaryParticipants Type: REG_DWORD Data: Defaults to 0. Specifies the maximum number of participants that the iConsole will process in order to display them in the Information tab of the Search Results screen. If this registry value is set to zero or does not exist, the list of participants is not capped and all are displayed.

Type: REG_DWORD Data: Defaults to 0. Specifies the maximum number of participants from the original instant message to display in the IM Message tab of the Search Results screen. If this registry value is set to zero or does not exist, then all participants are displayed. i Any participant names that have not been
retrieved due to capping but appear in the message itself are displayed as <unknown>.

EventDisplayIMActiveParticipantsOnly EventDisplayIMActiveParticipantsOnly Type: REG_DWORD Data: Defaults to 0. Set this to 1 to specify that only the active participants of the original instant message are listed in the Message tab of the Search Results screen. That is, the participants that appear in the message lines of the IM event. If this registry value is set to zero or does not exist, then all participants are displayed. i If EventDisplayMaxIMParticipants is set to
a lower value than the actual number of active participants, then it overrides the value of

Configure the number of e-mail recipients
You can configure how many recipients the iConsole displays in the Mail tab of the Search Results screen. To do this, modify the following values: EventDisplayMaxMailAddresses EventDisplayMaxMailAddresses Type: REG_DWORD Data: Defaults to 1000. Specifies the maximum number of e-mail addresses that the iConsole will process in order to display e-mail event recipients in the Mail tab of the Search Results screen.

EventDisplayIMActiveParticipantsOnly and
only a subset of the active participants is displayed.

Chapter 5 iConsole

97

Configure the search results cache
When you run a search, the iConsole caches the results to support faster paging through the results. You can configure how the iConsole handles the search results cache. To do this, you need to modify values in the following registry key on the iConsole application server: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web SearchParamsCachePeriodMinutes SearchParamsCachePeriodMinutes Type: REG_DWORD Data: Defaults to 5. Specifies how long search parameters (obtained through database stored procedures) are cached for. This enables the iConsole to display the Customize Search screen without making frequent calls to the CA DLP database. SearchResultsCachePeriodMinutes Within this registry key, modify the following values: MaximumResultSetSize MaximumResultSetSize Type: REG_DWORD Data: Defaults to 1,000. Specifies the maximum number of results that can be returned by a search for events. Because search results are cached in memory on the iConsole application server, setting a maximum result limit prevents the cache consuming excessive memory and adversely affecting system performance. SearchResultsPageSize SearchResultsPageSize Type: REG_DWORD Data: Defaults to 25. Specifies the number of results to display on each page after running a search or report. This can be useful when showing events in the Microsoft Excel view, allowing a larger number of results to be exported to Microsoft Excel; the Show Excel View button only shows events from a single page of results. If you set this to higher than the value of the MaximumResultSetSize registry setting, the iConsole will only display the number specified in MaximumResultSetSize—see above. SearchResultsCachePeriodMinutes Type: REG_DWORD Data: Defaults to 20. Specifies the result retention period (in minutes) for the event cache on the iConsole application server. Events are flushed from the cache if it is not accessed before this period elapses. The cache period countdown begins as soon as the search results are displayed and restarts each time the iConsole detects a ‘cache access’, such as the user browsing to a different results page or selecting an individual event. For example, the retention period is set to 30 minutes. If a user runs a search but then does not use the iConsole for 30 minutes, the search results are flushed. If the user subsequently wants to view the results again, they will need to rerun the search. SearchResultsUpdateAuditStatus SearchResultsUpdateAuditStatus Type: REG_SZ Data: Defaults to True. Determines whether the iConsole updates the Audit Status column in the list of search results after an event has been reviewed. Setting this to False can speed up switching between events.

98

CA DLP Deployment guide

AllowUnlimitedSearch AllowUnlimitedSearch Type: REG_SZ Data: Defaults to False. Determines whether reviewers are permitted to run ‘unlimited’ (or ‘uncapped’) event searches. That is, the iConsole will return all events that match the search criteria, even if the total exceeds the limit specified by the MaximumResultSetSize value (see above). To enable ‘unlimited’ (or ‘uncapped’) event searches, set this registry value to True. i This registry value simply configures the
iConsole application server to support unlimited searches; individual reviewers require the ‘Events: Allow searches of unlimited size’ privilege before they run these searches. See the Administration console online help for details; search the index for ‘privileges’.

MaximumBulkAuditEvents MaximumBulkAuditEvents Type: REG_DWORD Data: Defaults to 0. Specifies the number of results that can be processed as part of a bulk review. That is, how many events you can select and then use one of the ‘one-click review’ buttons. The default value of 0 enables an ‘unlimited’ number of events to be reviewed in this way. You may want to adjust this setting if you are displaying a large number of events on the same page. For example, if you have:

` Set the registry value SearchResultsPageSize to, say, 100 or more—see above. ` Instructed the current results page to display all
events returned by the search on the same page by typing a or A in the Results input box—see the iConsole user guide; search the index for ‘a keyboard shortcut’.

Chapter 5 iConsole

99

Set up event auditing
Set up the auditing feature
By default, CA DLP does not enable the auditing feature in the iConsole. To enable your reviewers to audit events using the iConsole, you need to manually set up this feature in the Administration console: 1 In the Administration console, choose Tools > Options. The following message is displayed: ‘The audit strings have not been configured yet. Would you like to create the default settings? Note: If you select 'No', the audit tab will not be available on this options dialog, and you will not be able to perform auditing operations.’ 2 Select Yes to enable the audit functionality in the iConsole and its subsequent configuration in the Administration console.

Enable time recording for reviewed events
You can optionally configure the iConsole to record how long reviewers spend viewing or auditing individual events. The associated metrics (including the average review time per event for each reviewer) can be optionally included in ‘View Time’ columns in the results screen of the Compliance Audit Report; for details, see the online help for the report’s Customize and Results screens. To enable time recording, you need to edit a registry value on the machine hosting the iConsole front-end Web server. On the host machine, locate the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web

i For details on configuring the iConsole audit
strings, see the Administration console online help; search the index for ‘iConsole, configuring event audit features’.

Within this registry key, you need to edit this value: CaptureEventReviewTime CaptureEventReviewTime Type: REG_DWORD Data: Defaults to 0. Specifies whether to record the time spent reviewing events. By default, time recording is not enabled. Set this registry value to 1 to enable time recording.

100

CA DLP Deployment guide

Configure audit e-mails
From the iConsole reviewers can send e-mails to colleagues, alerting them to messages or issues that require their attention. These e-mails are referred to as ‘audit e-mails’. When a colleague receives an audit e-mail, the From: field indicates the sender.

How does the iConsole set the From: field in audit e-mails?
The sender identity is generated automatically, unless you have defined a global sender—see page 102. If the global sender has not been defined, the iConsole retrieves the SMTP addresses associated with the currently logged-on CA DLP user account. If AuditEmailAddressMask is configured: the iConsole uses the first valid SMTP e-mail address that matches the address mask. If AuditEmailAddressMask is not configured: the iConsole uses the first valid SMTP e-mail address. i For details about e-mail address masks and AuditEmailAddressMask, see page 102. If there are no valid e-mail addresses, or none match the mask, then the iConsole will attempt an LDAP lookup (see the next section) on the Windows account of the logged-on user: If this lookup succeeds, it then extracts the display name configured for this Windows user in the LDAP directory and writes this in the From: field (for example, ‘Lynda Steel’). If this lookup fails (that is, there is still no match), it discards any domain (‘UNIPRAXIS\’) and simply writes the remaining name directly into the From: field. For example, a reviewer logs onto the CMS using a bespoke CA DLP account, ‘Unipraxis Compliance Officer’. This account has no corresponding LDAP entry, so the From: field is simply set to ‘Unipraxis Compliance Officer’. i This lookup is only possible if Single-Sign-on
is enabled on the CMS, or the user logged on manually with a valid Windows account.

Does CA DLP apply policy to audit e-mails?
By default, CA DLP excludes audit e-mails from policy. That is, these e-mails are ignored by the policy engine. To change this behavior, you need to edit a registry value on the machine hosting the iConsole front-end Web server. On the host machine, locate the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web

Within this registry key, you need to edit this value: ApplyPolicyToAuditEmails ApplyPolicyToAuditEmails Type: REG_DWORD Data: Defaults to 0. Specifies whether policy is applied to audit e-mail. By default, policy is not applied. Set this registry value to 1 to ensure that policy is applied to audit e-mails.

Chapter 5 iConsole

101

Specify a global sender
You can define a ‘global sender’ for iConsole audit e-mails. That is, you can configure the iConsole so that the From: field in audit e-mails is always set to the same sender, such as ‘compliance@ unipraxis.com’. This is useful if you want to anonymize audit e-mails (that is, you want to conceal the reviewer’s identity). To set up a global sender, you need to add a value to the following registry key on the front-end Web server: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web

Select a specific LDAP directory
i In the current release, the iConsole only supports
lookup operations for Active Directory.

If the iConsole front-end Web server is running in a domain under Windows 2003 or XP, the front-end Web server will automatically detect an Active Directory server. However, you can configure the front-end Web server to use a specific, non-default LDAP directory. To do this, you need to edit a registry value on the machine hosting the iConsole front-end Web server. On the host machine, locate the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web

Within this registry key, add the following value: AuditEmailAddress AuditEmailAddress Type: REG_SZ Data: Specifies a text string representing the global sender. This text appears in the From: box in all audit e-mails. This registry value overrides the default sender (see the previous sections) and also the AuditEmailAddressMask registry value (see the next section). The text string must be in the form of a valid e-mail address and must not contain spaces. Within this registry key, you need to edit this value: LookupLDAPServers LookupLDAPServers Type: REG_MULTI_SZ Data: CA DLP policy engines permit you to define multiple LDAP servers for this registry value. Specify a list of servers hosting the LDAP directory you want to use. Server names can be ‘plain’ or include a domain suffix (UNI-EXCH or UNI-EXCH.UNIPRAXIS.COM). If the LDAP port number is not 389, you can add it after the server name; prefix the port number with a colon (UNI-EXCH:319). You can also prefix the server name with the account credentials used to access the LDAP database. The syntax is: <username>:<password>@<server name>

102

CA DLP Deployment guide

Specify an address mask for audit e-mails
CA DLP users may have multiple e-mail addresses associated with their user accounts. Consequently, when sending an audit e-mail or notification message, the iConsole may need to choose the most appropriate addresses when populating the From: and To: fields. Specifically, this situation arises if audit e-mails do not use a global sender or if the recipients were chosen using the iConsole Address Selector dialog (that is, the reviewer sent the e-mail to members of a specific user group or dynamic address list). In this situation, you can define an e-mail address mask (that is, an address pattern such as @unipraxis.co*) to enable the iConsole to select the most appropriate address. To do this, you need to add a value to the following registry key on the front-end Web server: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web

Fitting a mask to recipient addresses
If a reviewer uses the iConsole Address Selector dialog to send an e-mail to all members of a user group or dynamic address list, the iConsole uses the address mask to pick the most appropriate recipient addresses. It then writes these addresses to the To: (or Cc: or Bcc:) field. How does it pick recipient addresses? When a reviewer clicks the Send button, the CMS returns a list of matching user accounts. For each user account, the iConsole then examines the e-mail addresses associated with that account and chooses the first address that fits the address mask. Finally, it writes that address to the To: field. If no SMTP addresses fit the mask, the iConsole attempts an LDAP lookup (see page 100) on the recipient’s Windows account in order to find an address. If successful, that address is written to the To: field.

Fitting a mask to the sender’s address
Within this registry key, add the following value: AuditEmailAddressMask AuditEmailAddressMask Type: REG_SZ Data: Specifies a text string that represents an SMTP address pattern. The iConsole populates the From: or To: fields with addresses that fit this ‘mask’. For details, see the following sections on page 102: If audit e-mails do not use a global sender, you can set an address mask to ensure that the From: field is always populated with a sender address that matches a designated SMTP address pattern. When a reviewer sends an audit e-mail, the iConsole compares all SMTP e-mail addresses associated with the reviewer’s CA DLP account. It then chooses the first address that fits the address mask and writes that address to the From: field. If no SMTP addresses fit the mask, the iConsole attempts an LDAP lookup (see page 100) on the reviewer’s Windows account in order to find an address. If successful, that address is written to the From: field.

` Fitting a mask to recipient addresses ` Fitting a mask to the sender’s address ` Address mask example ` Address mask notes

Chapter 5 iConsole

103

Address mask example
If the address mask is .@unipraxis.com and the reviewer is Lynda Steel, then these two addresses fit the mask: LyndaSteel@unipraxis.com lsteel@unipraxis.com But these addresses do not: LyndaSteel@unipraxis.co.uk lsteel@unipraxis.co.uk In this example, the iConsole would choose the first matching address it finds (LyndaSteel@unipraxis.com in this case) and writes that address to the From: field in the audit e-mail.

Specify the LDAP attribute used to populate To, Cc and Bcc lists
In the iConsole Compose Mail dialog, when a reviewer starts typing an address in the To, Cc, or Bcc fields, the iConsole displays a drop-down list of all matching users in Active Directory. By default, this list is based on an LDAP lookup operation that queries the displayName attribute in Active Directory. But if required, you can specify which Active Directory attribute is used to populate the drop-down lists. To do this, you need to edit a value in this registry key on the front-end Web server: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Web

Address mask notes
Note the following: Sender address masks only

` If both AuditEmailAddress and
AuditEmailAddressMask are specified, then AuditEmailAddress takes precedence.

Within this registry key, edit the following value: FriendlyNameLDAPAttribute FriendlyNameLDAPAttribute Type: REG_SZ Data: Defaults to displayName. This specifies the Active Directory attribute that the iConsole uses to generate drop-down lists of matching users in the To, Cc, or Bcc fields of the Compose Mail dialog. For example, to revert to version 6.0 behavior you can set this registry value to cn. This will force the iConsole to query the ‘common name’ Active Directory attribute.

` If AuditEmailAddress is present but empty, the
iConsole uses the first address that matches AuditEmailAddressMask.

` If a CA DLP user has no associated e-mail
addresses, then the sender identity is generated automatically, depending on whether single sign-on is enabled on the CMS—see page 100. Sender and recipient address masks

` If a template is used to compose the audit e-mail,
any sender or recipient addresses specified in that template will take precedence.

` An empty value in AuditEmailAddressMask is equal to a .* regex (regular expression). That is, the mask fits all e-mail addresses associated with the user. If the mask fits more than one e-mail address, then the iConsole uses the first one in the list.

104

CA DLP Deployment guide

General setup tasks
Modify the iConsole log file registry values
To configure the level of logging used by the iConsole, you need to modify a value in the following registry key: HKEY_LOCAL_MACHINE\Software \ComputerAssociates\CA DLP \CurrentVersion\Web\Logging LogMaxNumFiles LogMaxNumFiles Type: REG_DWORD Data: Defaults to 10. This specifies the maximum number of log files. When the maximum number of log files exists and the maximum size of the latest is reached (see below), the oldest log file is deleted to enable a new one to be created. LogMaxSizeBytes LogMaxSizeBytes Type: REG_SZ Data: Defaults to 1,000,000. This specifies the maximum size for each log file. When the current log file reaches its maximum size, the iConsole creates a new log file. Log entries are written to a iConsole_<date>.log file, where <date> is the date and time when the log file was created. AlwaysLogSearchCriteriaria AlwaysLogSearchCriteria Type: REG_SZ Data: Defaults to False. If set to True, this value configures the iConsole to automatically add information messages containing search criteria and parameters to the iConsole log file regardless of the LogLevel entry. Search criteria are logged before the search is run and include the name and version of the associated stored procedure file, plus the parameters used. The search outcome indicates the success or failure of the search, plus:

Within this registry key, edit the following value: LogLevel LogLevel Type: REG_DWORD Data: Defaults to 2. This determines the level of logging for the iConsole. For example, you can configure the iConsole to only log errors or important system messages. Log entries are written to the iConsole_<date>.log file, where <date> is the date and time when the log file was created; the file is located in CA's \data\log subfolder of the Windows All Users profile; see page 499. The supported logging levels are: 1 Errors only 2 Errors and warnings 3 As 2, plus informational and status messages i Setting LogLevel=3 will cause the log file to
grow extremely rapidly. This level of logging is provided for testing and diagnostic purposes, for example, it shows storage and retrieval on every resource item.

` If the search succeeds, it also shows the number of results returned and how long the search took. ` If the search fails, it gives a reason for the failure.
If set to False, the iConsole uses the value of LogLevel.

Chapter 5 iConsole

105

Set up iConsole servers for Network Load Balancing
If required, you can deploy your iConsole servers in a cluster (or Web farm) using the Windows Network Load Balancing technology. If you do implement an iConsole clustered deployment, note the following: You can cluster both your application servers and front-end Web servers (both must be installed on each node) or just the front-end Web servers. The software environment (operating system and node configuration) must be identical on each node. On each node, the cluster operation mode must be configured to use the IGMP multicast protocol. Do this in the Cluster Parameters tab of the Network Load Balancing Manager. 1 When defining the port rules on each node, the filtering mode must be set to ‘Multiple host’ and, crucially, the Affinity setting must be set to ‘Single’. Set these options in the Add/Edit Port Rule dialog of the Network Load Balancing Manager. For details about assigning ports, see the next section.

2

3

Add/Edit Port Properties dialog 1 Port range: These must both be set to 80 (see next section). 2 Affinity: This must be set to Single. See warning below. 3 Load weight: Defaults to 50 (ideally suits a two-machine cluster). ! The Single Affinity setting is essential. Network Load Balancing Properties dialog: Cluster Parameters tab
It ensures that iConsole users cannot be switched to an alternative node midway through a session. This configuration is also known as ‘sticky sessions’.

On each node, configure a common encryption key for the ViewState encryption—see page 106.

106

CA DLP Deployment guide

ViewState encryption
If you deploy your iConsole front-end Web servers in a cluster, you need to use a common encryption key for the ViewState encryption. By default, the cluster nodes each use an auto-generated encryption key, but this can cause problems if a node switch occurs. Specifically, the iConsole browser can lose its connection to the CMS after the iConsole session times out. To prevent this, you need to specify a common encryption key on each node in the cluster: 1 On each node, you need to edit the .NET file machine.config. Find it in this folder: %windir%\Microsoft.NET\Framework\v2.0.50727 \CONFIG 2 In this XML file, locate the machineKey: <machineKey validationKey="AutoGenerate... decryptionKey="AutoGenerate... validation=<encryption_algorithm>” /> Note that the validation parameter can be set to any encryption algorithm, such as SHA1 or 3-DES. 3 Now change the machineKey parameters to: <machineKey validation=<encryption_algorithm>” validationKey=<hex_key>” /> Where hex_key is an encryption key (in hexadecimal format). You can use any length key, but be aware that there is a trade-off between security and response times. Longer keys, (say, 128-bit) provide stronger security but also mean that

data requests take longer to service. Conversely, shorter keys mean data requests are serviced more quickly but provide weaker security. 4 Make this encryption change on all nodes (that is, iConsole servers) in the cluster. Finally, you need to restart Microsoft IIS on each node:

5

5.1 In Cluster Administrator, take the cluster offline. 5.2 Restart IIS on all nodes. 5.3 Bring the cluster back online.

Port rules
When you define the port rules for your cluster nodes, we recommend that you filter on specific ports. We also recommend separate rules for HTTP and SSL for each port, across all nodes. Filtering on a specific port rather than a port range eliminates the risk of a third party application triggering a node switch if it takes up resources on a port covered by your iConsole port rule. For example: HTTP: Set the start port and end port to 80. SSL: Set the start port and end port to 443. Note that these ports must match those TCP and SSL ports defined in Microsoft IIS in the Advanced Web Site Identification dialog (this is where you define multiple identities for the iConsole Web site).

For full details.Chapter 5 iConsole 107 Set global preferences i Only available to users with the administration privilege Admin: Manage iConsole (previously Admin: Manage iConsole searches). . For example. Use this screen to specify which settings users can change in their personal user preferences. Start the iConsole Users simply browse to a specified URL to start iConsole. or you can ensure that events are removed after they have been audited. This defaults to ‘cadlp’ but you can rename it—see the next section. <virtual dir> is the virtual directory for the front-end Web server. i Note the following: using the (see next begin URL is: ` All 'enforced' preferences are grayed out in the changes made to global preferences are User Preferences screen. You can also use these check boxes to fix preferences so that users cannot modify them. If single sign-on is enabled on the CMS section). For example. printing events and the maximum number of events shown on each page of search results. see page 549. you can prevent users from selecting a different content proxy server. The iConsole http://<FE_Server>/<virtual dir> Where: <FE_Server> is the name or IP address of the host machine for the front-end Web server. but can searching for events immediately. you can only overwrite them using the 'Enforced' check boxes. For example. you need to select the Print Extended Information Enforced check box. Administrators can set global default preferences for all iConsole users via the Global Preferences screen. For example. but a user has deselected it in their User Preferences screen. ` Any available to users the next time they log in. and also to overwrite any settings they may have changed. they will not need to log on. you can specify whether events are removed from a results list after they have been audited or whether reviewers are allowed to print audit summary details. If a user has set any personal user preferences. You can set global preferences for auditing events. if you have selected Print Extended Information in the Global Preferences screen. see the iConsole online help for the Global Preferences screen. the iConsole URL is: http://UX-WebSvr-01/cadlp i For advice if users are unable to browse to the iConsole. if the front-end Web server is hosted on the server UX-WebSvr-01.

. The search definition file defines the search parameters. including customizable parameters. For further information. After installing the search definition file. 5 Test that the search correctly references the search SP and returns a valid set of search results. and the layout of the search results screen in the iConsole. you must publish it. it becomes available to all other iConsole users and is listed in the Predefined Searches list in the iConsole Search screen. you need to confirm that the search correctly references the search SP and returns a valid set of search results. 4 Install the XML search definition. CA DLP supports search SPs for both Microsoft SQL Server and Oracle databases. after testing a new search. you must first write a stored procedure (SP) in the CMS database. This file gets installed onto the CMS. 2 The search definition file specifies the search parameters and screen layouts. including a standard event search and a search for quarantined e-mails. you can test a new search in the iConsole. You must then create and install an XML search definition file onto the CMS. It also references the name of a stored procedure (SP) in the CMS database. i CA DLP ships with several predefined (but customizable) searches. 2 Create XML search definition 3 4 5 6 Manage new search in iConsole Install XML search definition Test new search Publish new search Define new iConsole searches 1 Each new event search requires an associated search SP in the CMS database. This ‘search SP’ contains SQL statements that define a specific search for captured or imported events. This guide is available to download from CA Technical Support.108 CA DLP Deployment guide Defining new iConsole event searches Defining a new event search for the iConsole involves the following steps: 1 Define search SP To create new event searches and make them available to all iConsole users. Specifically. see the iConsole search definition guide. When you publish a new search. Finally. see page 23. 3 You perform the following tasks in the Manage Search screens of the iConsole. 6 Publish the new search to make it available to all other iConsole users.

sql and . so these will be covered by your general database backup procedures. . unipraxis\lsteel. see the Administration console online help. users skip the logon dialog when they start up the iConsole. you must edit the CMS machine policy. an account name prefixed with the user’s domain.sql and . CA DLP relies on the fact that the user has successfully logged into Windows as sufficient authorization to allow them to log on to the CA DLP account of the same name. then log back on from the Logon screen—see step 3 on page 84. for example. (To log on using a different account. Instead of the user supplying credentials to access the console.Chapter 5 iConsole 109 Back up search files All stored procedures (SPs) and search definitions are stored in the CMS database. we strongly recommend that you also back up any . Backing up and restoring the CMS database is described in the Database guide.) To configure CA DLP to use single sign-on.xml files created for your custom searches so that you can reapply these if you need to rebuild your CMS database. search the index for ‘single sign-on’. a user must first log out of the iConsole. That is. You can also grant the administrate privilege Admin: Use single sign-on to individual users (this overrides the CMS policy). i The . search the index for ‘backups’.xml files for the default searches are available on the CA DLP distribution media if you need to rebuild your CMS database. Note that account names for CA DLP users must be the same as their native Windows user name (sometimes referred to as the user logon name). However. About single sign-on If single sign-on (or ‘SSO’) is enabled for the parent CMS of the application server. For full details.

110 CA DLP Deployment guide .

Report customizations. Requirements. see page 112. see page 114. Install iConsole searches and reports Install iConsole searches and reports his chapter describes the iConsole searches. see page 127. see page 113.msi installation source image.msi installation package: Compliance reports. The following sections summarize: Available searches and reports. see next section. see page 112. Setting up dashboard data aggregation. Incident reports. Review Queue . see page 112. see page 113. reports and dashboard available in the reports. chapter 6 T Available searches and reports The following searches and reports are available in the reports. Dashboard. see page 116.6. Database configuration. see page 115. Issue reports. see page 118. But see also the additional notes on page 114. . Installing searches and reports. see page 119. Standard Searches.

delete. see page 119.112 CA DLP Deployment guide Compliance reports Compliance Audit Report: This report enables managers to view workload statistics for each reviewer in their management group(s). Incident Summary Report: This report provides reviewers with a list of how many times a user (employee) has caused a trigger to fire during a specified period. Data is shown in separate panes which you can configure and rearrange to focus on the areas of most interest. You can use the report to search for details of captured events associated with a specific user. i Dashboard charts and metrics are based on aggregated data. By default. You can also drill down into a pane to view a list of the underlying events or. Employees Not Reviewed Report: This report provides reviewers with a list of employees who have had a sample of their events reviewed over a specified period. a further chart showing a breakdown of the data in an individual pie slice. CA DLP can implement these capture and control actions in real time when a potential violation is detected. you can manually specify a total event figure as the basis for the percentage calculations. Dashboard The iConsole dashboard allows you to track user activity across the organization. for pie charts. move. Incident reports Incident Rate By Policy Report: This report shows a breakdown of all the policies that have been triggered over a specified period. it also indicates how long reviewers spend reviewing individual events. you can click a policy name to drill down and see the actual events that triggered that policy. List continues on next page. They can be the sender or a recipient of the message. Repeat Offender Report: This report shows the number of incidents associated with each 'offender'. it includes all policies. in a 'table' pane you can click individual cell values to view the underlying incidents. showing their counts as a percentage of all events processed. broken down by policy. On the Report Results page. It shows charts and metrics of incidents and violations. A 'reviewed event' is an event with one or more issues. . It calculates percentages based on all events in the database captured over the specified period. Incidents By Location Report: This report provides a summary of 'Data At Rest' trigger violations by location. group or trigger. but it can be refined to focus on just a subset. channel or impact. copy) for the captured file events. Incidents By Policy and Action Report: This report provides reviewers with total number of file policies that were triggered and the subsequent actions (for example. An offender is any user associated with an issue. or events captured over a specific period. see page 127. by user or group. Proof of Supervision Report: This report shows reviewed events as a percentage of all captured events. Alternatively. incoming or outgoing events. This is useful if you have customized the report to only include a subset of events processed by policy or if your database is regularly purged and so may not give an accurate figure for the total number of captured events over the report period. Likewise. It shows the number of reviewed events per reviewer over a specified period. Optionally. capture. For instructions on customizing the data aggregation jobs. i i To configure the iConsole to color-code the results table.

Review Queue This Review Queue feature is optional. For each step. or events captured over a specific period. Reviewer Search: This search retrieves events awaiting review by the current user. This is available to download from CA Technical Support. see page 23. the actual query statement and the status. It includes the following reports and search: Admin Reports: This include the following reports: ` Review Queue Configuration: This report shows the 'event selection rule' for each of your management groups.Chapter 6 Install iConsole searches and reports 113 Incidents By Policy and Channel Report: This report shows the number of violations by policy or class for specific users or groups. For example. for specific users or groups. ` Review Queue History: This report shows summary details for previous database review queue searches. it shows the execution time. For example. when you run the search it retrieves all unreviewed events assigned to you. see the Review Queue Implementation Guide. it can show changing violation counts on a weekly or monthly basis. . Issue reports Detailed Issue Report: This report provides details regarding all created issues. You can then use the report to search for details of captured events associated with a specific user or group. broken down by channel. reviewers can see the number of issues with an audit status of 'Escalate' or 'Pending' for events captured in the last month. For example. Issues By Status or Resolution Report: This report shows the number of issues for specific users or groups. audit status. For example. ` Review Queue Diagnostics: This reports provides details about the most recent database search for events in the review queue. including run times and event counts. Reviewers can analyze the results to see which policies trigger most often and on which communication channels. broken down by audit status or resolution. FTP transfers or instant messages. For instructions on how to customize and manage the Review Queue. it shows how many violations were caused by e-mails. Reviewers can analyze the results at a policy or class level to understand the overall trend over time. Incidents By Policy and Time Period Report: This report shows the number of violations over time broken down by policy or class.

For details. 3 Save a 'derived' version of the report. or instances when a user runs a specific application.0 GA using Oracle 10g and Microsoft SQL Server 2005. These events typically include files copied or saved to removable devices (such as USB flash drives) and writable CD and DVD drives. . IM conversations. and network locations. sender and confidence level. Data At Rest Standard Search: This search retrieves Data At Rest events that match specific criteria. Standard Search: This search retrieves events that match specific criteria. how many have already been reviewed. search the index for '$ROWLIMIT parameter'.114 CA DLP Deployment guide Standard Searches The Standard Searches feature includes the following searches and report: Content Search: This search retrieves items (e-mails. i While these reports can be used with any supported security model. Data In Motion Standard Search: This search retrieves Data In Motion events that match specific criteria. for example. it is defined by the MaximumResultSetSize registry value). These events typically include files sent to a printer. they have been optimized for best performance with the default security model (based on management groups). Personal Audit Report: This report shows the workload statistics for the current user. Quarantine Search: This search retrieves quarantined e-mails. and so on. This model uses e-mail addresses to map participants to CA DLP users. but these have not been tested. date. i If you are using a version 5. you will need to configure the $ROWLIMIT parameter in the report definition XML and republish the reports. however. attachments and so on) based on their text content. note the following: DBMS testing: These reports have been tested using CA DLP r12. see respectively: iConsole online help: Search for 'Capped searches' Deployment guide: Search for 'MaximumResultSetSize'. It includes all the commonly used search filters. You can also filter content searches by. files being saved to a specific location on a local or network disk volume. To increase this limit. see the iConsole search definition guide. Additional notes For all reports and the dashboard. that this method does not permit to increase the results row limit above the search 'cap' (this is the maximum number of results that can be returned by an event search. when you run the report it shows how many e-mails are assigned to you for review. Reports may work with other database versions. They can also include items entering or leaving your corporate network. For example. These events typically include scanned items or files stored in an archive. Be aware. Data In Use Standard Search: This search retrieves Data In Use events that match specific criteria. See also page 115. For details. Maximum results rows: For performance reasons these reports default to a maximum of 1000 rows of results. you can increase this limit in the Customize screen of a report: 1 Click the Show Hidden Parameters button 2 Edit the Results Row Limit value.0 iConsole (or later).

This object privilege is granted automatically when you install a new r12. For the iConsole dashboard. SQL Server: SQL Server 2005.0 CMS. you must grant this privilege manually before running Review Queue searches and reports on a: 6. i If you want to set up your CA DLP primary user before installing a new r12. you can find instructions in the Database guide on manually creating Oracle users and SQL Server logins. iConsole dashboards To display the iConsole dashboard: The browser host machine must be running: Adobe Flash Player 9 or later (Minimum version 9. . For details about supported database engines.msi support the following databases: Oracle: Oracle 10g Release 2. including SQL Server 2005 Express Edition.0 CMS. the iConsole servers must be version 6. the CMS must be version 6.0. See page 116 for database configuration details.0 or later. Oracle user privilege In order to run Review Queue searches and reports on an Oracle CMS.0 or later. For the iConsole dashboard. see page 115. Be aware that Oracle 9i is not supported. iConsole servers: Version 6. your Oracle primary user and. Be aware that SQL Server 2000 is not supported. See page 116 for database configuration details.msi. if specified. For additional CMS requirements for the dashboard. you must ensure that the following components are already installed: CMS: Version 6.0 CMS r12. the schema owner must have the object privilege EXECUTE ON DBMS_LOCK.0 CMS that has been upgraded from an earlier version CA DLP requirements Before you install reports.0 SP1 or later.0 SP1 or later Supported databases The reports and dashboard reports.0 SP1 or later.Chapter 6 Install iConsole searches and reports 115 Requirements Note the following requirements for the iConsole searches. see page 116.0) The CMS and iConsole servers must be running: CA DLP 6.124. see the 'Oracle Guidelines' and 'SQL Server Guidelines' chapters respectively. reports and dashboard. However.

Oracle CMSs Before you install the dashboard. To successfully install the dashboard. New CMSs The SQLAgentUserRole role in the msdb database is granted automatically to your primary login when you install a new r12. the CA DLP primary login in r12. To confirm that your primary user has this privilege. Specifically.116 CA DLP Deployment guide Database configuration When describing SQL Server CMSs. This is the account you specify in the Database Accounts screen of the CMS installation wizard. ensure that your CA DLP primary login (such as WGNUSER) has been added as a user in the msdb system database and has been already granted the msdb database role SQLAgentUserRole.0 or earlier (when the product was called Orchestria APM). your CA DLP primary login must be correctly configured to run data aggregation jobs. the following sections use the term primary login to refer to the CA DLP 'primary user'. run the following command line as an Oracle SYS user: GRANT CREATE JOB TO WGNUSER. be aware that the primary login name previously defaulted to APMUSER. see page 116. It is the main account that CA DLP uses to access the CMS database. ! Do not confuse this WGNUSER database user in the msdb system database with the WGNUSER instance-level login! Primary user requirements for iConsole dashboard To ensure that the dashboard is correctly populated with data. If upgrading from version 6. you must first clean up the database before attempting to reinstall (see page 117). If you primary user does not have this privilege.0 is WGNUSER. For details.0 CMS. . if the reports. ensure that your CA DLP primary user has been granted the CREATE JOB privilege (aggregation jobs must be owned by the primary user). This database user must already been granted the SQLAgentUserRole role. your CA DLP primary login (such as APMUSER) must have a database user in the msdb database. run this command: SELECT * FROM DBA_SYS_PRIVS WHERE PRIVILEGE ='CREATE JOB'. SQL Server CMS Before you install the dashboard. SQL Server CMSs: SQLAgentUserRole role i This section does not apply if your CMS uses Oracle or SQL Server 2005 Express.msi installation failed on a new r12. This allows it to create and schedule SQL Server Agent jobs. However. COMMIT. i By default. your primary login needs to create and run scheduled aggregation jobs (see page 119).0 SQL Server CMS.

Specifically. you will need to remove any orphaned database users (that is.msi installation fails (for example. ! Do not delete the primary login from the \Security\Logins branch! . 1. In the 'Users Mapped to this Login' table.1 Select the msdb database in the \Databases\Systems Databases branch. 2 3 3 Now you need to delete any aggregation jobs and schedules: 3. you will need to clean up your CMS database before trying to reinstall. 4 5 6 Cleaning up after a failed installation If the reports.Chapter 6 Install iConsole searches and reports 117 Upgraded CMSs If you have upgraded your CMS to r12.1 Select the master database in the \Databases\Systems Databases branch. In SQL Server 2005 Management Studio: 1 In the Object Explorer pane. In the 'Database Role Membership' list.2 Right-click the \SQL Server Agent\Jobs folder and choose Manage Schedules.2 Navigate to the \msdb\Security\Users branch.2 Navigate to the \master\Security\Users branch. users no longer associated with a login). 3. navigate to the \Security\Logins branch.3 Delete any msdb database users with the same name as the CA DLP primary login. Edit the CA DLP primary login's properties.0 or earlier. you will need to grant SQLAgentUserRole manually. 2. select the msdb database. go to the User Mapping page. because your primary user did not have the correct database roles).1 Navigate to the \SQL Server Agent\Jobs branch and delete any DLP_Aggregation_<DB_name> jobs. select the SQLAgentUserRole role. plus any dashboard aggregation jobs and related schedules. 1. Click OK to save the change. In the Object Explorer pane: 1.0 from version 5. 2. 2 Next. 2.3 Confirm that all schedules named DLP_Aggregation_Schedule_<DB_name> have been deleted. 3. you need to delete any orphaned users in the master database. you need to delete any orphaned users in the msdb database. In SQL Server 2005 Management Studio: 1 First.3 Delete any master database users associated with the CA DLP primary login. In the resulting Login Properties dialog.

msi on your CMS (see the previous section). In the Custom Setup screen. see page 116.msi. enter account details (name and password) for the Primary Administrator. If you specify a nondefault port. This defaults to port 80. Click Install to start the file transfer. 3 4 The installation wizard now has all the information it needs. Type localhost to specify the local machine. you must run reports.118 CA DLP Deployment guide Installing searches and reports To install iConsole standard reports. if no iConsole application server is installed locally you will need to specify which iConsole application server to connect to. Server: Specify the name or IP address of the machine hosting the application server. Run reports. you run reports. i i CA DLP creates the Primary Administrator account during installation. Use SSL: If you intend to use SSL to communicate over a secure port (for example. This is particularly important if you are installing the dashboard. In the Custom Setup screen. choose the reports you want to install. choose the reports you want to install. choose the reports you want to install.msi on your iConsole servers (see the following sections). . Click Install to start the file transfer. The installation wizard now has all the information it needs. In the Custom Setup screen. your iConsole application servers and your iConsole front-end Web servers. Click Install to start the file transfer.msi on your CMS. CMS 1 Make sure that your database engine is properly configured. You must choose the same combination of reports that you choose when running reports. you must also update the application server to use the same port. Find this in the root of your iConsole reports distribution media. This ensures that the port used for communication between the front-end Web server and the application server will use SSL. Port: Specify the TCP port used for communication between front-end Web server and the application server.msi on your CMS (see above). 443). In the iConsole Application Server Details screen. This account has full administrative privileges and full management group coverage. 3 2 3 4 iConsole application servers 1 2 Run reports. select this check box. You must choose the same combination of reports that you choose when running reports. Specifically. In the Administrator Credentials screen.msi. You must choose the same combination of reports when you run reports. 4 The installation wizard now has all the information it needs. iConsole front-end Web servers 1 2 Run reports.msi.msi.

` If your CMS uses a SQL Server Express database. The presence of any value in these audit fields is taken as confirmation that the incident has been audited by a reviewer. see page 115. you can customize the following aggregation parameters. ` The dashboard requires that Adobe Flash Player is installed on browser host machines. you can specify how often aggregation jobs run by editing the SQL Server job directly or by running an Oracle PL/SQL command. i Note the following: Purge existing data: You can optionally purge all existing aggregated data from the database. This section describes how to customize the aggregations. But you can change this definition so the metric only counts incidents with some other combination of values in these audit fields. for example. For syntax details. But you can narrow the metric definition to only include incidents with specific values in these audit fields. but you can change it to any date or time. see page 125. Configurable aggregation parameters For both SQL Server and Oracle CMSs. Escalated Events metric: By default. Be aware that shorter timeslots ('higher granularity') require more DBMS storage. Start date: This specifies the start date and time for the initial aggregation. see page 126. The default length is 60 minutes. Frequency: By default. Although there is no job parameter to configure this. The minimum timeslot length is 30 minutes. Scheduled aggregation jobs are created automatically when you install your dashboard page 118. that the number of blocked e-mails or disregarded warnings are aggregated over consecutive 60 minute periods. Incidents with a capture timestamp after this start date are included in the aggregation. This means. this count only includes incidents with one or more values set in the Audit Status. i i New incidents are defined as incidents with no associated issues. By default. aggregation jobs run every hour. and replace it with data re-aggregated from a new start date. aggregation jobs include incidents associated with any predefined or custom policy. Root policy node: By default. You cannot customize the 'New Events' metric. Timeslot length: Also known as 'timeslot granularity'. you will need to manually schedule the aggregations. see page 121. . ` For details about an apparent mismatch in event totals that can arise when drilling down into a dashboard pane. this metric only counts incidents with a value of 'Escalate' in the Audit Status field. But you can use this parameter to customize aggregation jobs to only include incidents associated with specific policies. The start date defaults to midnight on the first day of the current month. Reviewed Events metric: This metric calculates the total number of incidents that have been reviewed over the period.Chapter 6 Install iConsole searches and reports 119 Setting up dashboard data aggregation Dashboard charts and metrics are based on aggregated data. Data age: This specifies the maximum age for data in the aggregation tables. This parameter enables you to regularly purge database tables containing the aggregated incident data used to generate the dashboard charts and metrics. Action Taken or Resolution audit field. this is the number of minutes for each timeslot in the aggregation.

separated by commas. which is implicitly set if you change the aggregation start date or timeslot length. rut_dlp_set_aggregation_values (<parameter>[. But if required. This number is not specified here because it can vary due to various factors. If a parameter is not explicitly specified. The example below resets the aggregation start date to 1 July and the timeslot length to 24 hours: begin dlp_agg. run this database statement: exec rut_dlp_set_aggregation_values @<parameter>[. Using a utility such as Oracle's SQL Plus. purge_data=>1). which is implicitly set if you change the aggregation start date or timeslot length. it retains its current value.'yyyymmdd'). commit. start_ts=>to_date('20080701'. You then run a second statement to go live with these values so they are used in the next aggregation.@purge_data=1 2 Go live with the new parameters: After running the previous statement. you need to run a database statement to set the required parameters to their new values. The available aggregation parameters and their associated syntax are described in the following section. Each query can include multiple parameter definitions. the Output pane displays confirmation details of the new parameters plus the following 'go live' statement: EXEC rut_dlp_set_new_values_live <n> Where <n> uniquely identifies the new set of aggregation parameters. The exception is the purge parameter. Oracle CMSs To configure aggregation jobs for Oracle CMSs. . Each query can include multiple parameter definitions. 1 Set the aggregation parameters: In SQL Server Enterprise Manager Studio. you need to run a database command to set the required parameters to their new values. The example below resets the aggregation start date to 1 July and the timeslot length to 24 hours: exec rut_dlp_set_aggregation_values @start_ts='2008-07-01 00:00:00'. See page 124.<parameter>]). commit. 3 Set the aggregation frequency: This step is optional. aggregations run every hour. This ensures that the next time the aggregation process runs. The available aggregation parameters and their associated syntax are described on pages 121 to 123. end. it retains its current value. By default. You now need to run this go live statement (we recommend you simply copy it from the Output pane into the query pane).@<parameter>] Where @<parameter> defines the new value for an aggregation parameter. end. Where <parameter> defines the new value for an aggregation parameter. separated by commas. it will use the new parameter values defined in step 1. The exception is the purge_data parameter. run this command: begin dlp_agg. SQL Server CMSs To configure the aggregation job for SQL Server CMSs. rut_dlp_set_aggregation_values (granularity=>1440. If a parameter is not explicitly specified. @granularity=1440.120 CA DLP Deployment guide Configure the aggregation Note the following requirements for SQL Server and Oracle CMS. you can change the aggregation frequency.

n specifies the timeslot length in minutes and must be a factor of 1440. Data is reaggregated from the start date specified by @start_ts or start_ts. i i If you set a new timeslot length (@granularity or granularity. But see the note below. to specify an aggregation start date of 6:00 am. it defaults to 0 (zero). data is re-aggregated from the start of the current month. . 1 July 2008: @start_ts='2008-07-01 06:00:00' start_ts=>to_date('20080701 06:00:00'. to set a 12 hour timeslot. That is. see above). this will force the purge parameter to 1 (even if you have explicitly set the purge parameter to zero). changing the timeslot length will result in all existing aggregated data being purged. the timeslot length must divide exactly into the number of minutes in a day. the purge parameter defaults to 0 (zero). You typically need to purge the aggregated data if you change the timeslot length or the start date. Any aggregated data for the period after the new start date is deleted. 0 Start date SQL Server: @start_ts='<date>' Dates are always in the format: yyyy-mm-dd hh:mm:ss Oracle: start_ts=>to_date('<date>'. See ‘Purge existing data’ for details. all existing aggregated data is automatically purged.'<pattern>') The <date> format is defined by <pattern>. Note also that if you change the aggregation start date. Here. causing all existing aggregated data to be purged (even if you have explicitly set the purge parameter to zero). Data is then re-aggregated from the start date specified by @start_ts or start_ts. 'YYYYMMDD HH24:MI:SS') If you specify a new aggregation start date. You must enclose the date in single quotes. See below for details. If no start date is specified.Chapter 6 Install iConsole searches and reports 121 Aggregation parameters You can specify the following aggregation parameters: Purge existing data SQL Server: @purge_data=1 or 0 Oracle: purge_data=>1 or 0 This determines whether any existing aggregated data is purged from the database. That is. data is re-aggregated from the start of the current month. If no start date is specified. If this parameter is set to: 1 All existing aggregated data is purged. For example. But see the note below. such as 'DDMMYYYY' or 'YYYYMMDD HH24:MI:SS' This parameter specifies the event timestamp for the start date and time of the initial aggregation. set this to: @granularity=720 granularity=>720 i If you change the existing timeslot length. Timeslot length SQL Server: @granularity=<n> Oracle: granularity=><n> Defaults to 60. For example. Aggregated data for the period before the current aggregation is retained. the purge parameter defaults to 1. including any aggregated data that was created after the new start date. If the purge parameter is not specified at all.

you can set these parameters to any combination of supported values. Field 2 and Field 3. New Events. Support for dashboard drill down: The dashboard allows users to drill down into metrics and charts to see the actual underlying incidents. these parameters are set to NULL. if <n> is set to 3. ensure that your aggregation tables are purged before the corresponding records in your main event tables. @AF1_reviewed='esc' will match the audit status of 'Escalate'. i Reviewers viewing the iConsole dashboard need to be aware that snapshot data relates to a specific point in time. By default. in this situation a pie chart slice could potentially include some individual incidents that are no longer present in the CMS database.122 CA DLP Deployment guide Data age SQL Server: @data_age=<n> Oracle: data_age=<n> Specifies the maximum age (in months) for data in the aggregation tables. To avoid this problem. all records older than 16 September 02:00 AM will be purged from the aggregation tables. are calculated for the following metrics: Reviewed Events. Snapshot period SQL Server: @history=<n> Oracle: history=><n> Specifies the aggregation period in months for snapshot data. For example. AF2 and AF3 refer respectively to audit fields Field 1. any records older than <n> months are purged from the aggregation tables when an aggregation job next runs. snapshots refer to total incident counts for the whole snapshot period. drill down may fail if the main event tables in your CMS database (Wgn3Event and so on) have been purged but the aggregation tables have not. To narrow the metric definition. so regular purges will prevent them from consuming excessive DBMS storage. the time that the last aggregation job ran. namely. AF1. However. For example. Snapshots are not calculated in real time when the reviewer views or refreshes the dashboard. these are listed in the next section. These tables contain the aggregated incident data used to generate the dashboard charts and metrics. Unlike data aggregated for individual timeslots (see ‘Timeslot length’). and Escalated Events. meaning that the presence of any value in these audit fields will cause the event to be added to the 'Reviewed Events' metric. For example. i The aggregation uses a LIKE operator when querying the values in an event's audit fields. You must enclose the parameter values in single quotes. instead. For example. if <n> is 3 and the aggregation job runs on 16 December 02:00 AM. snapshot data is not broken down by timeslot. If you set this parameter. Reviewed Events metric SQL Server: @AF1_reviewed=NULL or <Audit value> @AF2_reviewed=NULL or <Audit value> @AF3_reviewed=NULL or <Audit value> Oracle: AF1_reviewed=>NULL or <Audit value> AF2_reviewed=>NULL or <Audit value> AF3_reviewed=>NULL or <Audit value> These parameters determine which events are included in the Reviewed Events metric. Snapshots . There are two main reasons for regularly purging the aggregation tables: Prevent excessive DBMS storage: The aggregation tables can grow very quickly. an aggregation that runs on 20 June will calculate snapshot totals based on all qualifying incidents with a capture timestamp of 20 March or later.

you can set these parameters to any combination of supported values. Under normal circumstances.Chapter 6 Install iConsole searches and reports 123 Escalated Events metric SQL Server: @AF1_escalated=NULL or <Audit value> @AF1_escalated=NULL or <Audit value> @AF1_escalated=NULL or <Audit value> Oracle: AF1_escalated=>NULL or <Audit value> AF1_escalated=>NULL or <Audit value> AF1_escalated=>NULL or <Audit value> These parameters determine which events are include in the Escalated Events metric. In general terms. i The aggregation uses a LIKE operator when querying the values in an incident's audit fields. You must enclose the parameter values in single quotes. the data aggregation to focus exclusively on incidents associated with specific policies. simply omitting this parameter from the aggregation job will not reinstate the default root policy nodes. then set this parameter to: @root_policy_node_list='3010400. see the 'Policy classification nodes' section under the description of the Wgn3ClassificationNode database table. to aggregate incidents associated only with Personally Identifiable Information (ClassUID 3010300) or Personal Health Information (ClassUID 3010400) policies. you must explicitly set this parameter to 3000000 and 400000. these are listed in the next section. By default. @AF2_escalated=Esc will match values in audit field <Field 2> of 'Escalate to Management' or 'Escalate to HR'. this parameter is set to 3000000 and 4000000. But if required.3010300' Note that if you specify a custom root policy node but then subsequently want to revert back to the default ClassUID values. you do not need to include this parameter. These ClassUID values represent the root nodes for predefined and custom policies respectively. i Details of all ClassUID values for policy classifications are listed in the Database Schema. For example. AF1 is set to 'escalate' while AF2 and AF3 are set to NULL.<n>]' Oracle: root_policy_node_list=>'<n>[. Root policy node SQL Server: @root_policy_node_list='<n>[. To narrow the metric definition. AF1. you can include this parameter and explicitly set it to different ClassUID values. it defines which incidents are included in the aggregation. if you want to aggregate incidents captured by Compliance policies only (ClassUID 3020000).<n>]' This parameter specifies a list of integer ClassUID values (in decimal) for policy classifications. Field 2 and Field 3. based on the type of policy associated with each incident. AF2 and AF3 refer respectively to audit fields Field 1. set this parameter to: @root_policy_node_list='3020000' root_policy_node_list='3020000' Alternatively.3010300' root_policy_node_list='3010400. as listed in the Wgn3Classification and Wgn3ClassificationNode database tables. meaning that the Escalated Events metric only includes events with an audit status of 'Escalate' (parameters are not case-sensitive). All policies in the subtree of any specified ClassUID node will be included in the aggregation. You only need to include it if you want . and so on. The Database Schema is available on request from CA Technical Support: see page 23. By default. For example.

To do this. run the following PL/SQL command.SET_ATTRIBUTE (name => 'DLP_AGGREGATION_<DBNAME>'. SUBSTR(REPEAT_INTERVAL. you set the aggregation frequency when you set up a scheduled task using the Windows Scheduled Tasks wizard (see page 125. Oracle You can specify a repeat interval for a specified aggregation job.40) AS REPEAT_INTERVAL.1. To do this. search the index for 'event auditing: customizing the audit features'. Note that if you do change the aggregation frequency. you can change the aggregation frequency: SQL server You must edit SQL Server job: DLP_Aggregation_<CMS database> Where <CMS database> is the name of CMS database. Field 2 and Field 3. This example sets the aggregation job to run at 2:00 AM every night: BEGIN DBMS_SCHEDULER. JOB_NAME. AF2 and AF3 aggregation parameters The AF1. you need to check the job name and confirm its next run time. NEXT_RUN_DATE FROM ALL_SCHEDULER_JOBS. BYHOUR=2' ). i Field 1. These field are available to your reviewers in the iConsole and Data Management console when they update audit details for captured incidents. First. Note that Field 1 is typically set to Audit Status. END. attribute => 'repeat_interval'. i i If using a SQL Server Express database. Change the aggregation frequency By default. aggregations run every hour. Where DLP_AGGREGATION_<DBNAME> is the JOB_NAME returned from the SQL query above . step 2). Now you can set the aggregation frequency. value => 'FREQ=DAILY.124 CA DLP Deployment guide AF1. But if required. run the following SQL query: SELECT OWNER. These audit fields are configurable in the Administration console (choose Tools > Audit Options and browse to the General tab). AF2 and AF3 aggregation parameters refer respectively to audit fields Field 1. Field 2 and Field 3 are fully described in the online help for the CA DLP Administration console. do not set a frequency shorter than the timeslot length (see page 121) as this will waste DBMS resources.

Open Scheduled Tasks in the Systems Tools folder. in this case: "EXEC rut_dlp_aggregation_process" 2. 2. -D WGN_<machine name> defines the database name. Where: -E specifies a trusted database connection. . i If you want to run aggregations more often than once every day. 1 Create a SQLCMD aggregation script First. -Q specifies a database query. 2.3 When the wizard prompts you for a user account. Save the following query to a batch file.Chapter 6 Install iConsole searches and reports 125 Manually schedule aggregation jobs for SQL Server Express If your base machine uses a SQL Server Express database. choose the batch file you created in step 1.2 Specify a scanning schedule as required. You must ensure the scheduled task runs as a Windows user (see step 2-4 below) who has a SQL Server login that has been granted the db_owner privilege on the WGN_<machine name> database. such as Dashboard_Agg. choose a Windows user that corresponds to the appropriate SQL Server login. do this in the final wizard screen.1 When the wizard prompts you for the program you want to run. you must schedule the aggregation jobs using the Windows Scheduled Tasks wizard. This database name incorporates the name of the CMS host server. you need to save the necessary SQL Server query to a script file.cmd: sqlcmd -E -D WGN_<machine name> -Q "EXEC rut_dlp_aggregation_process" 2 Set up a scheduled aggregation task You now need to schedule an aggregation task using the Windows Scheduled Tasks wizard. you will need to edit advanced properties for the scheduled task.

15 PM 15. The Search Results screen does indeed find 100 unreviewed events. If a reviewer were to drill down into the dashboard at this point. the number of results does not match the event total shown in the chart.16 PM 15. But this time.00 PM i Such potential disparities only affect snapshots of event counts based on audit status. The snapshot total and number of underlying events are back in sync. snapshots (such as 'total unreviewed events') reflect the total number of events at the specific time when the aggregation job ran. The manager refreshes their dashboard. The manager drills down into the dashboard again.00 PM An aggregation job runs and finds 100 unreviewed events. The same manager drills down into the dashboard to see the underlying events. the snapshot total for Unreviewed Events is still 100.126 CA DLP Deployment guide Event totals can appear incorrect when drilling into snapshot data In certain conditions. . they would see an apparent disparity in the number of events. Example: Consider this timeline: 15. Snapshot totals are recalculated each time a data aggregation job runs. then the snapshot total shown in the dashboard will no longer tally with the actual number of underlying events in the CMS database. Consequently. 15. the Search Results screen only finds 75 unreviewed events! The next aggregation job runs and finds 75 unreviewed events. By default. a manager reviews some previously unreviewed events). if a reviewer drills down into a chart to see the underlying events. A manager refreshes their dashboard. If the actual event counts rise or fall before the next aggregation job runs (for example.30 PM 15. They cannot occur with snapshots based on non-changing event attributes such as events counts by policy.45 PM 15. This apparent disparity can occur if further events have been captured or reviewed in the intervening period since the snapshot totals were last calculated. aggregation jobs run every hour.00. This is because there has been no new aggregation job since 15.46 PM 16. A reviewer audits 25 of the unreviewed events in the iConsole. the snapshot total for Unreviewed Events is 100.

Chapter 6 Install iConsole searches and reports 127 Report customizations Incident Rate By Policy Report Enable background color styles You can optionally configure the iConsole to color-code the results table of this report.MediumHighValue {background-color: #FF7777.css by adding the following styles: 3 .} .} . To do this. Edit the stylesheet branded.MediumValue {background-color: #FFCC99. you need to edit the branded.} 1 2 Log on to the iConsole front-end server.LowMediumValue {background-color: #FFFF99.css stylesheet: .LowValue {background-color: #FFFFFF.HighValue {background-color: #FF7777.} .} . Browse to the \web\styles subfolder of the CA DLP installation folder.

128 CA DLP Deployment guide .

The CA DLP quarantine feature enables your organization to enforce this requirement.7. Pre-deployment considerations are summarized on page 131. For example. After installation. For details see the following sections: A diagram summarizing the Quarantine Manager architecture is on page 130. the e-mail release procedure is described on page 140. you must configure the ‘QM domain user’. you need to edit the registry on the Quarantine Manager host machine and set up user policy control triggers to intercept e-mails that require urgent attention. See page 135. released e-mails are forwarded to the intended recipient. The deployment procedure is described on page 132. 4 Finally. 3 A reviewer determines whether to release the e-mail from quarantine (3a) or to reject it (3b). Finally. This chapter describes how to install and configure the Quarantine Manager. Before installation. . This component ensures that e-mails released from quarantine are sent on to their original recipients. you can install multiple Quarantine Managers. Quarantine Manager Quarantine Manager egulatory requirements require that certain categories of documents sent to multiple external recipients must be approved by an appropriate representative. 4 3a 3b chapter 7 R 1 2 3 CA DLP and quarantined e-mails 1 A user sends an e-mail containing a potential non-compliance issue. 2 CA DLP intercepts and quarantines the e-mail.

it can also operate in conjunction with Outlook and Notes client agents. The CMS (4) maintains a queue of quarantined emails (5). It then forwards these e-mails. The architecture is summarized below: 10 2 3 9a 9b 8 4 5 7 Q 6 Quarantine procedure: Example based on Exchange server integration This example shows how the Quarantine feature operates in conjunction with Exchange server integration. the Quarantine 1 Manager regularly queries the CMS for released or timedout e-mails and forwards these to their intended recipients. A reviewer (6) checks quarantined e-mails in the iConsole or Data Management console. . To achieve this. if so configured. The reviewer can either release or reject a quarantined e-mail.130 CA DLP Deployment guide Quarantine Manager architecture The role of the Quarantine Manager is to ensure that e-mails released from quarantine are sent on to their original recipients. An e-mail is sent (1) and monitored by CA DLP (2) as it transits through the Exchange server (3). though an alternative Exchange server (9b) to the intended recipient (10). i For simplicity. The Quarantine Manager (7) regularly checks the quarantine queue on the CMS. A control trigger quarantines the e-mail. checking for e-mails that have been released or which have timed out (8). However. this diagram omits the policy engine hub and policy engines. either via the original Exchange server (9a) or.

unlike Exchange and Domino integration. it is possible that a ‘quarantine action’ applied by the Milter MTA agent will only affect external recipients. be aware that the e-mail may already have been sent to some recipients if it was routed to them via an Exchange or Domino server without passing through the Sendmail or Postfix server. . By default the Exchange server agent does not reprocess e-mails that have already been processed by a CA DLP Outlook client agent. you must use the Exchange server agent. This situation typically applies to e-mails sent to both internal and external recipients. see page 210. However. you must explicitly configure the Exchange server agent to reprocess (and apply quarantine actions) to e-mails already processed by a client agent. add the following value: ReprocessClientEmails i For full details about this registry value. To overcome this. If a Quarantine Manager is installed on the CMS. the CMS simply selects a standby Quarantine Manager to be the ‘active’ one. if the Milter MTA agent quarantines an e-mail. an e-mail cannot normally be quarantined by the Exchange server agent if other policy triggers have already been applied by an Outlook client agent. you can install multiple Quarantine Managers. Go to this registry key: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Exchange Within this registry key. Each registers with the CMS. The CMS keeps in regular contact with the registered Quarantine Managers and if the active one fails for any reason. This has implications if your CA DLP deployment uses both Outlook client agents and the Exchange server agent. you must edit the ActiveOnStartup registry value (see page 136) on that Quarantine Manager’s host server then restart the CMS. typically located on the boundary of your corporate network. To do this you must edit the registry on the Exchange server. internal recipients may already have received the email. Depending on how your CA DLP server agents and user policies are configured. Multiple Quarantine Managers For maximum reliability. some e-mails may not be quarantined The Milter MTA agent captures e-mails transiting through a Sendmail or Postfix server (see page 260). which automatically selects one to be the ‘active’ Quarantine Manager. this will always default to be the ‘active’ one when the CMS starts up. To allow a different Quarantine Manager to be active on startup. Therefore.Chapter 7 Quarantine Manager 131 Pre-deployment considerations If using e-mail client agents and the Exchange server agent If you want to quarantine e-mails without notifying the sender. It is not possible to quarantine e-mails silently using an Outlook client agent. If using a Milter MTA agent.

the term ‘QM domain user’ refers to the logon account for the CA DLP infrastructure service on the Quarantine Manager host machine. You supply the QM domain user credentials when you install the Quarantine Manager (see step 6 on page 135). 1 Specify a QM domain user 2 Allow mailbox access 3 Install the Quarantine Manager 4 Configure the Quarantine Manager 5 Mark e-mails for quarantine: Set up policy control actions Quarantine events: Deployment procedure 1 The QM domain user is described on pages 132 to 133. The QM domain user must also be a local administrator on the Quarantine Manager host server and have the ‘Log on as a service’ security privilege. or choose an existing domain user. Because the Quarantine Manager runs as a process within the CA DLP infrastructure. On the target server. 2 3 4 . Both applets are available in Administrative Tools. The registry values for configuring the Quarantine Manager are listed on page 136. summarized below. It also needs to be able to log on to the specified Exchange. you must either create a new domain user in Active Directory. Expand the Local Policies branch and select User Rights Assignment. Specify a QM domain user The Quarantine Manager must be able to access the CMS directly to check for e-mails released from quarantine. See the following sections for details. if this server is a domain controller. open the Local Security Policy applet or. open the Domain Controller Security Policy applet. Therefore. Assign the Log on as a service privilege to the QM domain user account. This security area determines which users have logon privileges on the local computer.132 CA DLP Deployment guide Deploy the Quarantine Manager Setting up CA DLP to quarantine e-mails that require an urgent review is a multi-step procedure. you must also create or designate a corresponding CA DLP user account. Domino or Sendmail/Postfix server. you need to assign various rights and privileges to the logon account for the infrastructure service. Assign the ‘Log on as a service’ privilege You must manually assign the ‘Log on as a service’ security privilege to the QM domain user. Individual steps are described on the following pages. This is your ‘QM domain user’. 2 through 5 These steps are summarized on page 135. Finally. Throughout this chapter. To do this: 1 Ensure that you are logged on to the target server with local administrator rights.

create a new user. ` Admin: Disable management group filtering: This enables the Quarantine Manager to bypass inbuilt security measures and search for events without management group restrictions. you must include the domain prefix to ensure compatibility with the account name for the QM domain user (for example. UNIPRAXIS\QMUser). you must create a matching CA DLP user account. ` Events: Control quarantined events: This permits the Quarantine Manager to access e-mails released from quarantine. the new CA DLP user must have the same account name as the QM domain user. add the QM domain user to the Administrators group. i These privileges are granted automatically with the Administrator role in CA DLP. search the index for ‘new users’. In effect. We recommend that you set the management group for the Quarantine Manager to the top-level Users group. See the Administration console online help for details. That is.Chapter 7 Quarantine Manager 133 Add to local Administrators group On the Quarantine Manager host server. 2 Still in the Administration console. The Quarantine Manager will use this CA DLP account to log on to the CMS when checking for e-mails released from quarantine. When you specify the user name. even if the CMS machine policy setting ‘Allow single sign-on?’ is set to False. Create a corresponding CA DLP user After specifying your QM domain user. . 1 In the CA DLP Administration console. assigning this privilege guarantees each reviewer can retrieve all the quarantined events associated with users in their respective management groups. assign the following privileges to this CA DLP user: ` Admin: Use single sign-on: This enables the Quarantine Manager to log on to the CMS automatically (without needing to provide authentication).

you must configure wgncred. This ensures that the Quarantine Manager has access to the Notes mailbox specified in the NotesEmailID registry value. That is. you must also set the password for the Notes ‘Current User’ on the Quarantine Manager host server. or Sendmail or Postfix server specified by the SmtpEmailServerName registry value Set credentials for Notes servers When configuring the credentials for the Notes server and mailbox (using the NotesEmailServerName and NotesEmailID registry values—see page 137).exe are on page 518. Access to an Exchange mailbox When using Exchange. Use wgncred. . the QM domain user must be able to access the: Exchange server specified by the MapiEmailServerName registry value. In order that released e-mails appear (to the recipients) to have come directly from the original sender.134 CA DLP Deployment guide Allow access to the designated mailbox Before you install the Quarantine Manager.exe are on page 518. ! If the QM domain user does not have the ‘Send As’ permission for a particular user. This permits the Quarantine Manager to use the mailbox associated with the QM domain user account to send e-mails released from quarantine on to their intended recipients. see page 136. you must ensure that the QM domain user is a mailbox-enabled user. you must grant the ‘Send As’ Exchange permission to the QM domain user. or Notes server specified by the NotesEmailServerName registry value.exe to securely cache the password itself using the following component ID: Quarantine Manager for Lotus Notes: QMGRNOTES i Instructions for using wgncred. For details. the Quarantine Manager will be unable to forward that user’s e-mails when they are released from quarantine! Set credentials for SMTP servers When integrating with Sendmail or Postfix. the Quarantine Manager uses the mailbox on the SMTP server associated with the QM domain user account to send e-mails released from quarantine on to their intended recipients.exe to securely cache this password. the QM domain user must also have rights to access the mailbox specified by the MapiEmailID registry value. So that this password is not stored in a registry value (which would represent a security loophole). Access to this mailbox is specified by the SmtpEmailID and SmtpEmailServerName registry values (see page 137). The password SmtpEmailID user account is passed to the Sendmail or Postfix server with the account name. The required component ID is: Quarantine Manager for SMTP: QMGRSMTP i Instructions for using wgncred.

choose the Quarantine Manager feature—see page 31. search the index for ‘quarantined e-mails’. while the QM’s own log provides more diagnostic details. Configure the Quarantine Manager After installation. To do this. the location of the \Data folder. plus details about the local CA DLP database. you must edit the MapiEmailID or NotesEmailID registry value. The installation wizard now has all the information it needs. specify the QM domain user as the logon account used by the CA DLP infrastructure service. In the Customer Information screen. Click Install to start the file transfer. you must edit the registry on the Quarantine Manager host machine—see page 136: Specify the Quarantine mailboxes: To specify the mailbox used by the Quarantine Manager when forwarding released e-mails. you must restart the local infrastructure to enable the Quarantine Manager to start. Activity log messages generally record the outcome of quarantine operations. specify the parent server (typically the CMS). When the installation is complete. but utility machines are explicitly designed to host CA DLP addins such as the Quarantine Manager.Chapter 7 Quarantine Manager 135 Install the Quarantine Manager You install the Quarantine Manager using the CA DLP server installation wizard.exe. edit control triggers and actions in the relevant user or group policy. In the Service Accounts screen. you must configure how the Quarantine Manager handles quarantined e-mails. Domino or Sendmail/Postfix server the Quarantine Manager connects to when forwarding released e-mails. To do this. enter your user name and organization. when the Quarantine Manager first starts a warning message is added to the Activity log and the Quarantine Manager shuts down. you must manually configure the Quarantine Manager by editing the registry—see the next section. In the Custom Setup screen. you must edit these registry values: MapiEmailServerName NotesEmailServerName SmtpEmailServerName ! Because these registry values are not specified during installation. For details. In subsequent screens. 1 To launch the server installation wizard. . we recommend that you choose a utility machine. 2 3 4 5 6 7 8 Mark e-mails for Quarantine Now you need to set up the Quarantine feature to identify e-mails that need urgent reviewing. Log files The Quarantine Manager writes messages to the Activity log and also to its own log saved on the QM host machine. See also page 136. run setup. Find this in the \Server folder on your CA DLP distribution media. The Quarantine Manager can also run on a CMS or gateway. see the Administration console online help. The QM log is configured in the registry (see page 136). See page 132 for details. In the Server Type screen. Specify the e-mail Server: To specify which Exchange. After supplying the required registry values.

Type: REG_SZ Data: Set this value to the Exchange mailbox you want to use. See the following pages for details. The table below lists the registry values for the Quarantine Manager. The Quarantine Manager will use this mailbox to send e-mails released from quarantine on to their intended recipients. MapiEmailID MapiEmailID Quarantine Manager registry key You must edit values in the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Quarantine Manager . the registry values you need to edit are: MapiEmailServerName MapiEmailServerName Type: REG_SZ Data: Set this value to the name of the Exchange Server hosting the mailbox of the MapiEmailID user account (see below). Registry key and values Quarantine Manager registry key MapiEmailServerName MapiEmailID NotesEmailServerName NotesEmailID SmtpEmailServerName SmtpEmailID ActiveOnStartup MaxRetryAttempts ReleaseTime_Mins SleepTime_Secs SaveMessages LogLevel LogMaxNumFiles LogMaxSizeBytes LogFilePath SmtpAuthType Page 136 136 136 136 137 137 137 138 138 138 138 139 139 139 139 139 138 Type: REG_SZ Data: Set this value to the name of the Domino Server hosting the mailbox of the NotesEmailID user account (see below). you must edit the registry. You need only specify the mailbox. NotesEmailServerName NotesEmailServerName Within this registry key. do not include the domain prefix. set this value to ‘QMuser’ not ‘Unipraxis\QMuser’. For example.136 CA DLP Deployment guide Quarantine Manager registry values To configure how the Quarantine Manager processes e-mails released from quarantine and how it interacts with the CMS database.

The Quarantine Manager will use this user account to send e-mails released from quarantine on to their intended recipients. . SmtpEmailServerName SmtpEmailServerName Required for Sendmail and Postfix integration.exe. To specify a non-default port number. If omitted.com:25777 SmtpEmailID SmtpEmailID Required for Sendmail and Postfix integration only. For example: unipraxis. the port number defaults to 25. This registry value is only required if the Quarantine Manager authentication method is not ‘None’ (as specified by SmtpAuthType. For example. If you do need to specify an SmtpEmailID user account. this may be a Sendmail or Postfix server. Type: REG_SZ Data: Set this value to the user account that the Quarantine Manager will use to log on to the Sendmail or Postfix server. For example: mail\unipraxis\qmuser. you must cache this user’s password using wgncred.nsf suffix is optional. The Quarantine Manager will use this user account to send e-mails released from quarantine on to their intended recipients.Chapter 7 Quarantine Manager 137 NotesEmailID NotesEmailID Type: REG_SZ Data: Set this value to the Domino mailbox (that is. and the . append the number to the server name. see page 134. the NSF file) you want to use. separated by a colon. Use wgncred.exe to do this. Paths are not case-sensitive. You need to specify the path to the NSF file relative to the Data folder on the Domino server. see page 138 for details). Type: REG_SZ Data: Specifies the name of an SMTP server that you want to use for sending e-mails released from quarantine.nsf You must also cache the password for the Notes ‘Current User’ on the Quarantine Manager host server. This registry value can also specify the TCP port used for communication between the Quarantine Manager and the SMTP server. see page 134.

you must still ensure that these credentials are protected—see the next paragraph. set this value to zero. Type: REG_SZ Data: Defaults to None. If you use Plain. your Sendmail or Postfix server must be configured to accept connections from the Quarantine Manager host machine. This specifies which standard SMTP authentication type the Quarantine Manager uses to connect to the Sendmail or Postfix server. . you must set up the SmtpEmailID registry value to pass the logon account details to the SMTP server. This specifies how long an e-mail is held in quarantine before it is automatically released. To specify the active Quarantine Manager. The zero minute default means that e-mails are kept in quarantine indefinitely. The following values are supported: None Plain Login NTLM CRAM-MD5 We recommend you choose None for unauthenticated connections. This is how long the Quarantine Manager waits between querying the CMS for e-mails released from quarantine. although these protocols do not send unencrypted logon credentials. See page 137 for details. this value determines which Quarantine Manager is active on startup. MaxRetryAttempts MaxRetryAttempts Type: REG_DWORD Data: Defaults to 5 attempts. Increasing this interval reduces the impact that the Quarantine Manager has on database performance at the cost of a longer delay before a message can be sent on to its intended recipients. SleepTime_Secs SleepTime_Secs Type: REG_DWORD Data: Defaults to 30 seconds. In a multiple Quarantine Manager environment. You must also use Wgncred.138 CA DLP Deployment guide SmtpAuthType SmtpAuthType Available for Sendmail and Postfix integration only. NTLM or CRAM-MD5 authentication. NTLM and CRAM-MD5 authentication can be used to connect to Sendmail or Postfix servers on Windows and Unix machines respectively. Login. ReleaseTime_Mins ReleaseTime_Mins Type: REG_DWORD Data: Defaults to zero minutes. We do not normally recommend Plain or Login authentication because under these protocols the logon password is sent as unencrypted plain text across the network.exe to cache the password. This is the number of times the Quarantine Manager tries to resend a released e-mail. To specify a standby Quarantine Manager. However. set this value to 1. ActiveOnStartup ActiveOnStartup Type: REG_SZ Data: Defaults to 1. However.

The supported logging levels are: 1 Errors only 2 Errors and warnings 3 Errors and warnings. the oldest log file is deleted to enable a new one to be created. plus informational and status messages i Setting LogLevel=3 will cause the log file to grow extremely rapidly. When the maximum number of log files exists and the maximum size of the latest is reached (see below). where <date> is the date and time when the log file was created.Chapter 7 Quarantine Manager 139 SaveMessages SaveMessages Type: REG_DWORD Data: Defaults to 0. see page 499. where <date> is the date and time when the log file was created. it is deleted from the mailbox. LogLevel LogLevel Type: REG_DWORD Data: Defaults to 2. Log entries are written to a wgnqmgr_<date>. the log file is saved to CA's \data\log subfolder of the Windows All Users profile (see page 499) on the machine hosting the Quarantine Manager. it shows storage and retrieval on every resource item. This specifies the folder you want to write log files to. The QM domain user must have write access to the specified folder—see page 132. Log entries are written to the wgnqmgr_<date>. LogMaxNumFiles LogMaxNumFiles Type: REG_DWORD Data: Defaults to 10. for example.000. you can configure the Quarantine Manager to only log errors or important system messages. This setting determines the level of logging for the Quarantine Manager’s own log file (general operational details are recorded in the CA DLP Activity log). If the path is not defined.log file. Set this to 1 to retain the e-mail after it has been sent. the Quarantine Manager creates a new log file. This level of logging is provided for testing and diagnostic purposes. Log entries are written to a wgnqmgr_<date>. where <date> is the date and time when the log file was created LogMaxSizeBytes LogMaxSizeBytes Type: REG_SZ Data: Defaults to 1. LogFilePath LogFilePath Type: REG_SZ Data: Defaults to empty.000. This specifies the maximum size for each log file. For example. This specifies the maximum number of log files. the file is located in CA's \data\log subfolder of the Windows All Users profile. After the Quarantine Manager sends a released e-mail on to its intended recipients. .log file. When the current log file reaches its maximum size.log file.

The MaxRetryAttempts registry value determines the number of retries—see page 138. If the Quarantine Manager cannot access the specified e-mail server (for example. It will then try to resend the e-mail. or SmtpEmailID 3 Finally. If the number of failed attempts matches the limit specified by MaxRetryAttempts. it waits before attempting to send the e-mail again. . Encrypted e-mails See also the known issues for encrypted e-mails and the Quarantine Manager page 547. or NotesEmailID. the Quarantine Manager can automatically release an e-mail from quarantine after a specified period. gradually increasing the interval between attempts up to a maximum of 5 minutes. it sends the e-mail on to the intended recipient(s). By default. in turn specified by these registry values: MapiEmailID. The interval between queries from the Quarantine Manager to the CMS database is configurable by a registry value. Domino or Sendmail/ Postfix server specified by: MapiEmailServerName. because it is temporarily shut down for maintenance). or NotesEmailServerName. even if it has not been reviewed. Automatic release of timed-out e-mails To ensure that business critical messages are not delayed unnecessarily. the Quarantine Manager will never automatically release an e-mail event. Failure to forward released e-mails If the Quarantine Manager fails to send a released e-mail to its intended recipients. it adds an entry to the Activity Log. or SmtpEmailServerName 2 Then it connects to the mailbox associated with the Quarantine mailbox user.140 CA DLP Deployment guide E-mail release procedure After the Quarantine Manager has received a released e-mail event from the CMS: 1 It connects to the Exchange. i Quarantine Manager registry values are described on page 136. the Quarantine Manager quits trying to resend and the e-mail is blocked.

For example. To enable the data to pass across the Internet (6). Data can then reach the database (10) on the customer CMS or gateway (11). CA DLP provides support for two machines to communicate via a secure private tunnel. Routing gateway 1 2 Replication Module Server administered by customer 11 10 3 Virtual Socket 5 Firewall 6 7 Firewall RMI Server Socket 9 4 Tunnel Internet Tunnel 8 Secure private tunnel architecture Information leaves the Routing Gateway (1) via the Replication Module (2). message integrity and endpoint chapter 8 S authentication between any two machines in a CA DLP installation. Secure private tunnel Secure private tunnel ecurity is paramount when sending sensitive data across a public network. The Virtual Socket (3) intercepts requests for TCP sockets and relays data to and from the RMI Server Socket (9) via the secure private tunnel (4 and 8). .8. The customer firewall (7) must be configured with the mapped public address of the CMS. you can use the tunnel to connect a CMS with a remote gateway. the gateway firewall (5) must be configured with the mapped public address of the routing gateway. The tunnel is designed to provide confidentiality.

It also creates a key store file to hold the certificate. ! The information in this key store must be kept secure because it enables anyone to create valid signed certificates to allow communication over the secure private tunnel! Certificate management To eliminate man-in-the-middle attacks on the SSL link used for the secure private tunnel. ensuring that the connection stays open only for as long as is necessary and that all data is encrypted. This is your ‘certificate folder’. create and request certificates. Java. They also use the java.exe from this subfolder. 4 Run the MakeRootCertificateStore. certificates are used to provide endpoint authentication. Once identities are established. copy java. You can create the folder anywhere on the certificate management machine and you can give it any name.exe These instructions require that CA DLP is already installed on both the routing gateway and its parent server. See below for details on certificate management. Generating authentication certificates This section provides instructions for creating signed certificates for the routing gateway and its parent server. On the certificate management machine. CAcert. that will be used to sign the certificates for the routing gateway and its parent server. installed on an isolated. The connection is terminated if either machine cannot provide authentication. Find this file in the \Win32\Support\SPT folder on your CA DLP distribution media. secure encryption/decryption is performed on all data passing through the tunnel.cmd ` MakeMachineCertificateStore. create a folder to hold the authentication certificates and key store files.jks. This means that both the routing gateway and its remote parent server must verify the identity of the machine they are trying to connect to. But first note the following: Certificate scripts CA DLP provides two scripts to generate authentication certificates for the routing gateway and its parent server: ` MakeRootCertificateStore. 2 Copy java. The tunnel uses SSL (Secure Sockets Layer) and requires certificates at either end of the connection to verify the identity of each participant.exe utility.exe to create and request certificates. You will run java. 3 Create a folder to hold the certificates and key store files On the certificate management machine. to . CAStore.cmd Find these scripts in the \Win32\Support\SPT folder on your CA DLP distribution media.crt. To generate authentication certificates: 1 Designate a standalone computer as your secure certificate management machine You will generate the authentication certificates on this machine.142 CA DLP Deployment guide Configure the secure private tunnel All traffic is sent along the tunnel using TCP (Transmission Control Protocol) using a single server port number. standalone CA DLP installation.exe to the \System\jre160_07\Bin subfolder in the CA DLP installation folder.cmd script to generate a root certificate and key store file This script generates a self-signed certificate. you will run the certificate scripts from this folder.exe to the certificate management machine These instructions use java.

6 Run the MakeMachineCertificateStore.cmd script to generate a certificate and key store file for the routing gateway You now need to rerun this script to generate a signed certificate and key store file for the routing gateway. <CAKeyPW> is the password for the root certificate created in step 4. run this command: <MachinePW> is the password for the parent server’s key store file.jks file extension). 5.jks file extension). to generate a root certificate with the password CAKeyPwd. <MachineCN> is the common name of the certificate used by the routing gateway.jks with a password of CMSPword. but do not install this certificate.1 on page 143. As before. To do this.2 Check the contents of the certificate. i Note that the passwords must each contain at least six characters. <CAStorePW> is the password for the root key store created in step 4.1 Run this script from the certificate folder defined in step 3 on page 142. Right-click CAcert.crt in Windows Explorer and choose Open. to generate a certificate CustomerCMS in a file store CMSKeyStore. The command syntax is: MakeMachineCertificateStore <MachineStore> <MachineCN> <MachinePW> <CAStorePW> <CAKeyPW> Where: <MachineStore> is the key store file for the parent server (with no . <MachineCN> is the common name of the certificate used by the parent server. signed with the root certificate created in step 4.1 on page 143). the command syntax is: MakeMachineCertificateStore <MachineStore> <MachineCN> <MachinePW> <CAStorePW> <CAKeyPW> But this time the parameters take the following values: <MachineStore> is the key store file for the routing gateway (with no .1 on page 143. Check the output to confirm that the chain is correct and that the certificate CustomerCMS has been signed by the certificate authority (in this case. run this command: MakeMachineCertificateStore CMSKeyStore CustomerCMS CMSPword CAStorePwd CAKeyPwd MakeRootCertificateStore CAStorePwd CAKeyPwd 5.Chapter 8 Secure private tunnel 143 4. The name must not contain spaces. 4. browse to the certificate folder defined in step 3 on page 142. The command syntax is: MakeRootCertificateStore <CAStorePassword> <CAKeyPassword> Where: <CAStorePassword> is the password for the CAStore.2 The script automatically outputs the certificate chain.1 Run this script from the certificate folder defined in step 3 on page 142. 5 Run the MakeMachineCertificateStore. . i All passwords must each contain at least six characters. stored in a key store with the password CAStorePwd. For example. <CAKeyPassword> is the password for the root certificate.cmd script to generate a certificate and key store file for the parent server This script generates a signed certificate and key store file for the parent server.jks key store.1 Run this script from the certificate folder defined in step 3 on page 142. For example. The name must not contain spaces. 6.

Check the output to confirm that the chain is correct and that the certificate RoutingGW has been signed by the certificate authority (in this case.jks spt. .0. 199.clientCNlist=RoutingGW MakeMachineCertificateStore <GWKeyStore> <RoutingGW> <GWPword> <CAStorePW> <CAKeyPW> 8. 9.’ 7.hosts=CMS-HARDY:56097. Find this subfolder in the CA DLP installation folder.keystore=GWKeyStore. copy the routing gateway’s key store (GWKeyStore. 7 Transfer the key store files to the routing gateway and its parent server 7.10. Find this subfolder in the CA DLP installation folder.serverport=56097 spt.serverport=56096 spt.clientCNlist=CustomerCMS For details about the values in startup.0. run: wgninfra -exec wigan/infrastruct/ serviceutil/SocketRedir SetKeyStorePassword CMSPword Where: wigan/infrastruct/serviceutil/SocketRedir is the path and name of the Java class used by the secure private tunnel.17:56096 spt.1 You need to set the parent server’s key store password (defined in step 5.1 on page 143).1 From the certificate folder.jks key store created in step 4.hosts=XP-GW07:56096.1 Configure the startup.0.properties file on the parent server. copy the parent server’s key store (CMSKeyStore. 9 Save the key store passwords on the routing gateway and its parent server 6.jks in step 5. <CAKeyPW> is the password for the root certificate created in step 4. For example.jks with a password of GWPword.2 The script automatically outputs the certificate chain.properties file.properties file on the routing gateway. see page 146.properties.1 on page 143.1 on page 143) to the \system subfolder on the routing gateway.1:56097 spt.2 From the certificate folder.log file for the entry: ‘Successfully Set Secure Private Tunnel KeyStore password. for example: spt. i All passwords must each contain at least six characters. to generate a certificate RoutingGW in a file store GWKeyStore. <CAStorePW> is the password for the CAStore. go to the \data\log subfolder and check the CA DLP command_<date>.keystore=CMSKeyStore. From a command prompt in the \system subfolder in the CA DLP installation folder on the parent server.0. for example: spt.1 on page 143. signed with the root certificate created in step 4. To confirm that the password has been successfully set.jks in step 6. run this command: 8 Edit startup.144 CA DLP Deployment guide <MachinePW> is the password for the routing gateway’s key store file.1 on page 143) to the \system subfolder on the parent server.1 on page 143) into the encrypted database.2 Configure the startup.properties on the routing gateway and its parent server 8.jks spt.

This is because the tunnel is not resilient to changes to public IP addresses while the service is running. run: wgninfra -exec wigan/infrastruct/ serviceutil/SocketRedir SetKeyStorePassword GWPword As above.1 on page 143) into the database. . For an example startup. restart this service on both the routing gateway and its parent server. i You must restart the CA DLP infrastructure service. The firewalls must both be configured to only accept connections through the port assigned to the tunnel. you need to edit the startup.2 Now set the routing gateway’s key store password (defined in step 6.properties file. wgninfra. Find this file in the \system subfolder of the CA DLP installation folder. see page 146. From a command prompt in the \system subfolder in the CA DLP installation folder on the routing gateway.properties can take effect.properties file. Note the following: We recommend you use static IP addresses when assigning public addresses to the routing gateway and its parent server. on both the routing gateway and its parent server.log file for the entry: ‘Successfully Set Secure Private Tunnel KeyStore password. wgninfra. This causes tunnel configuration messages to be written to the CA DLP Activity log on each machine (viewable in the Administration console).exe. so that the data is not blocked by the firewall. Configuring the secure private tunnel To configure the secure private tunnel.exe. Go to the \data\log subfolder and check the CA DLP command_<date>. Each routing gateway needs to be configured to send data through the tunnel to a specific parent server.properties file on both the routing gateway and on its parent server. We also recommend that you check the System logs to confirm there are no problems. before changes to startup. confirm that the password has been successfully set. If an IP address is changed. Both the routing gateway and its parent server must have a mapped public address in the relevant Network Address Translator.Chapter 8 Secure private tunnel 145 9. you must restart the CA DLP infrastructure service.’ 10 Restart the CA DLP infrastructure service Finally.

keystore=GWKeyStore.0. Server administered by customer: ‘CMS-HARDY’ [Secure Private Tunnel] spt. If no port is specified.jks Specifies the name of the Java Keystore format file containing a trusted root certificate plus the certificate for the CMS. the IP address of the target CMS plus its serverport port. optionally. If no port numbers are specified.17:56096 spt.0. spt. the machine name of Startup.clientCNlist=RoutingGW Where: spt.10.hosts=XP-GW-07:56096. This is parented to CMS-HARDY.jks spt.serverport=56096 spt.keystore=CMSKeyStore. spt.199.clientCNlist=CustomerCMS Where: spt. a CMS administered by a customer.17:56096 Specifies the machine name and.hosts=CMS-HARDY:56097. the default is 56079.146 CA DLP Deployment guide Example startup.clientCNlist=CustomerCMS Specifies a list of common names of certificates whose infrastructure is permitted to communicate with this gateway using the tunnel.jks spt.serverport=56096 Specifies the port number used by the gateway to accept tunnel connections.clientCNlist=RoutingGW Specifies a list of common names of certificates whose infrastructure is permitted to communicate with this CMS using the tunnel.199. spt. you only need to list the machine names. In the two examples below.serverport=56097 spt.0.0.serverport=56097 Specifies the port number used by the CMS to accept tunnel connections. If required. i Normally.jks Specifies the name of the Java Keystore format file containing a trusted root certificate plus the certificate for the routing gateway. . the IP address of the routing gateway plus its serverport. you can specify multiple gateways.keystore=GWKeyStore.hosts=XP-GW-07:56096.0. the routing gateway is XP-GW-07. optionally.0. 10.keystore=CMSKeyStore.properties file on: Routing gateway: ‘XP-GW-07’ [Secure Private Tunnel] spt.0. the default is 56079.properties files on the routing gateway and CMS. spt. see page 142.1:56097 Specifies the machine name and.1:56097 spt.hosts=CMS-HARDY:56097.0. spt. i For details on certificate management.properties files The following settings need to be added to the startup. But if there is a risk that a remote machine’s IP address cannot be resolved from its name when the CA DLP infrastructure starts. we recommend you also list its IP address. spt.

chapter 9 T If a single synchronization operation is not practical. for example. Account Import can import new users and groups into the existing CA DLP user hierarchy. For example. or it can reorganize existing users to synchronize them with an external hierarchy. typically an LDAP directory such as Active Directory.9. be aware that non-matching e-mail addresses may be deleted during synchronization. Synchronizing e-mail addresses ! It is essential that your e-mail addresses on the CMS remain synchronized with. if you have manually added an e-mail address to a user in the CMS database. rather than several smaller operations. Synchronizing users When resynchronizing your CA DLP user hierarchy with your principal user directory. Account Import can bulk create new accounts and pre-assign them to parent servers. Mapping e-mail addresses to users. Such synchronization is essential for CA DLP features that rely on e-mail address mapping—see chapter 22. we strongly recommend that you run a single operation to synchronize all of your users in one go. Account Import Account Import o simplify mass deployments. It also provides full details about parameters files and command files.. For machines. see ‘Move unknown users to. During synchronization. It can also import user attributes such as email addresses and employee IDs. each synchronizing a specific set of users. it is possible to a run a separate operation for each network domain. This chapter describes how to run import operations from a command line and by using the Account Import wizard. One of the most important uses for Account Import is to synchronize users’ e-mail addresses in the CMS database with addresses in an external source. This approach eliminates the risk that a partial synchronization may inadvertently move unknown users (that is. However. Active Directory.’ on page 153. any addresses in the CMS database that are not present in the LDAP database are deleted from the CMS. users not present in the specified source LDAP directory) to an ‘exceptions’ group. That is. The ‘Synchronize users from this domain’ check box (see page 152) ensures that only users in the specified domain can be reorganized within the CA DLP user hierarchy. if your users are spread across multiple domains.. you may prefer to run a separate Account Import operation for each domain. or if an e-mail address has been removed from the LDAP source since the last synchronization. For details. It can also reparent existing client machines and gateways in advance of the CA DLP rollout. it will be deleted. Account Import enables administrators to import user details into CA DLP from an external Lightweight Directory Access Protocol (LDAP) directory or a source file. .

and supports two import methods: Import methods You can import user details by running: Account Import wizard: This is the simplest method for importing user details. For details.0. Account Import wizard LDAP Directory Data file XML format Spreadsheet format Command file Command line account import Parameter file LDAP directory Data file XML format Spreadsheet format Command file Import sources Account import can import user information directly from an LDAP directory. 7.x. see page 160.4. Parameter files: Only supported for command line import operations.148 CA DLP Deployment guide Import methods and sources Account Import can import user details from several sources. to ensure that your LDAP directory and CA DLP user hierarchy stay synchronized. or command file: LDAP directory: The Lightweight Directory Access Protocol (LDAP) enables directory services to manage directory objects. In a multiple-CMS environment. Command line import operations: These enable you to schedule regular import operations. CA DLP can import user details from the following LDAP directories: Account import methods and sources The supported import methods and sources are described below. From a command line. the wizard creates new users on the currently selected CMS. Account Import converts all source data to a command file before importing. . parameter file. These files contain import parameters similar to the configuration options provided by the Account Import wizard. You run the wizard from the Administration console. you can import data from any supported source—see the next section. 6. for details about command line operations.5. The wizard can import data from any supported source—see the next section. for example. Objects and attributes in an LDAP directory are exposed to any other application that uses the LDAP protocol. See page 158. see page 150. For details. data file. In all cases. ` Domino Server 6. or 8 ` Microsoft Active Directory ` Novell eDirectory (NDS) ` Netscape/Sun ONE Directory Server i You can import from an LDAP directory using SSL—see page 159.

! Spreadsheet-based data files cannot be used to import e-mail addresses! Account Import privileges Your administrators must have the necessary administrative privileges when running Account Import operations: To do this Assign roles to users (Command files only) Create new machines. Log files are saved in CA's \data\log subfolder of the Windows All Users profile. Users: Edit the user Hierarchy Account Import log files The results of each import operation are written to an individual Account Import log file. ‘create new user’ or ‘set user attribute’). This lists all changes or additions to CA DLP user or machine hierarchies and includes any errors that may have occurred. or re-create. this external hierarchy on the CMS. choose Manage > Log Files or click . this is recorded in the log file. Available import commands and syntax rules are described on pages 160 to 167.log. Data files contain encoded versions of all or part of an external user hierarchy and contain the user details necessary for CA DLP to create. reorganize the user hierarchy Machines: View Log files Machines: Edit the user Hierarchy You need this privilege Admin: Edit User Roles Command files: These are import configuration files containing CA DLP user and machine import commands (for example. If Account Import fails to recognize an import operation in a parameter file or command file. To view the log file in the Administration console. Account Import log files take the format: ldap_200201200945. in XML or spreadsheet-compatible format. page 499. reorganize the machine hierarchy (Command files only) View log files of user and machine import operations Create new user. Typically. For details about the XML schema. please contact Technical Support—see page 23. you import command files to make specific changes or additions to your existing CA DLP user hierarchy. if Account Import failed to find a specified parent group or parent server. Assign temporary passwords to Users: Reset Users user accounts Password (Command files only) .Chapter 9 Account Import 149 Data files: These are structured files of user data. For example. this is also recorded in the log file.

150 CA DLP Deployment guide Account Import wizard To import user details using the Account Import wizard. For example. By default. when you export any branch of the CA DLP user hierarchy to a command file. ` Input from Command File: Specify the command file containing the changes or additions to your existing CA DLP user hierarchy. ` LDAP Server: Identify the server hosting the source LDAP directory. i If the LDAP server permits anonymous access. i By default. 1b data file. you must specify the source for the imported user details. 1 1a 1b 1c 2 LDAP Logon screen Applicable if importing from an LDAP directory— see step 1. depending on which import options you choose. for example Domino Server. The wizard steps you through each stage of the import process. For example. this name will be the same as your domain user name. Also.com or dc=company. the target file name has an . may require you to leave this field empty. ` Base DN/Domain: Identify the LDAP server’s base DN or domain. the record in the data file is imported while the user record in the LDAP directory is ignored. if you import users from a Microsoft Exchange server. choose Tools > Account Import Wizard. Select Source screen 1 Synchronize existing users with: 1a Source LDAP directory. with your domain and name separated by a backslash: unipraxis\frankschaeffer On other LDAP databases. specify how Account Import handles duplicate records. configurations. 1c If you specify both 1a and 1b. . but you can override this default.acc extension. If you choose both check boxes (that is. you can specify how Account Import handles duplicate records (any user listed in both sources). 2 Command file. CA DLP uses this port to communicate with the LDAP server. Enter its name or an IP address. ` User: Enter your user name on the LDAP Server. The default is port 389. for example: cn=frankschaeffer. You must supply logon details for the source LDAP Directory. to specify an Active Directory domain. some 2 Account Import wizard. it is shown automatically. you want to simultaneously import from an LDAP directory and a data file).dc=com i If Account Import can detect the default DN. enter one of these formats: company. The name format depends on the type of LDAP database. ` Password: Enter the password for your LDAP user.o=unipraxis ` Synchronize to Data Source: Choose the LDAP Database or Data File check boxes to synchronize your existing CA DLP user hierarchy with these external sources—see page 148. leave both the User and Password fields blank. 1 Select source of account data screen In the first wizard screen. this name may be a fully qualified LDAP distinguished name. i Some wizard screens may not appear. ` Port number: Enter the TCP/IP port number used to connect to the LDAP server.

6 page 157 for details. Click the Browse button to select the root LDAP tree level. The Account Import wizard enables you to synchronize your CA DLP user hierarchy with an external source. select ‘ou=Unipraxis/ou=Sales’ to import all users from this level downwards: ou=Unipraxis ou=Sales ou=Asia ou=Europe ou=N America 1 Account Import wizard. Example LDAP directory structure .Chapter 9 Account Import 151 3 LDAP Search Filters screen Applicable if importing from an LDAP directory— see step 1. ` Group Search Filter: Specify the LDAP search filter needed by the wizard to extract the LDAP containers that correspond to CA DLP user groups. You can select any combination of the following synchronization options. you must ensure that the following fields contain correct values. Where possible. You must specify the root directory for user data extracted from the LDAP directory. The wizard provides ‘best guess’ default values. 5 Users Tree Root screen Specify the target parent group in the CA DLP user hierarchy. you can only choose one of your management groups as the parent group. Microsoft Active Directory) and key details about the LDAP directory structure. 4 LDAP Source Directory screen Applicable if importing from an LDAP directory— see step 1. Now define the synchronization scope. ` User Search Filter: Specify the LDAP search filter needed by the wizard to extract users from the LDAP database. Synchronization Scope screen Applicable if importing from an LDAP directory or data file—see step 1. the reorganization only affects CA DLP users within the target parent group. For example. Specifically. the wizard automatically detects the type of LDAP directory (for example. ensure that the new filter conforms to RFC 2254. but you can override these if necessary. See ` User Name Attribute: You must specify the LDAP attribute that holds the user names. i If you choose to reorganize existing CA DLP users to match the directory structure in LDAP or the structure specified the data file (you choose this in step 6). i If you override the default search filters and specify different object classes and categories. Synchronization Scope screen 1 CA DLP-to-LDAP synchronization options. All users and groups at and below this root directory will be copied into CA DLP. All users and groups imported from LDAP and or a data file will be added to this parent group.

and created below the CA DLP parent group specified by the User Tree Root in step 5. ` Copy user attributes: This option updates existing user accounts with e-mail addresses and attributes imported from corresponding users in the LDAP directory or data file. 1 ` Re-organize existing users: This option rearranges the existing hierarchy of CA DLP users to synchronize it with the hierarchical group structure specified in step 7. see step 8 on page 153. If you do not select this option. The new group structure is rooted at the source LDAP directory specified in step 4 on page 151. i If a user is created with a user name matching a user account that was previously deleted. ` Synchronize users from this domain: This option prefixes names for new user accounts with the specified domain (such as UNIPRAXIS\srimmel). the user name does not contain a backslash). and how new user names are composed. If the user names in the LDAP directory or data file do not have a domain prefix (that is. search the index for ‘users. `E-mail addresses can be deleted: This option specifies whether emaildelete commands are carried out by the synchronization—see page 171. CA DLP can automatically recreate the deleted user. Place all users in User Tree Root: This imports all users into a flat. all imported users are added to the parent group specified by the User Tree Root in step 4. whether you must confirm the changes. i The full name associated with each CA DLP user account is imported automatically from the LDAP directory. . ! We do not recommend that you use this parameter. These determine the target group structure for imported users. or attributes specified in a data file. ‘unknown users’ and import confirmations. 2 Account Import wizard. See the Administration console online help for details. it creates a new account for each imported user who has no corresponding account in CA DLP. as existing e-mail events may no longer be associated with the correct user— see page 163. 7 Import Options screen These options determine how to handle anomalous users and groups. See page 109. recreating’. i This option is essential if single sign-on is enabled on your CMS. See steps 9 and 10 for details. That is. non-hierarchical group structure. this setting will automatically add one. For details.152 CA DLP Deployment guide ` Create new users: This option creates new CA DLP accounts for unknown users. Import Options screen 1 Group Structure options. 2 Options for handling empty LDAP containers. That is. ` Group Structure: The available options determine how imported users are organized into parent groups in the CA DLP user hierarchy: Use LDAP hierarchy to group users: This option creates a new set of user groups that match the hierarchical structure of the source LDAP directory or data file. Use LDAP attributes to group users: This option derives a hierarchy of parent groups based on a concatenation of specified LDAP attributes. all existing CA DLP users stay in their current group.

For example.. These are containers that hold subcontainers or other items. i Note the following: 4 5 Account Import wizard. Use these to re-order the attribute list. you can move them to an ‘exceptions’ group. If your existing CA DLP user hierarchy contains users not present in the LDAP directory. This can be any existing group in the user hierarchy. the wizard ignores empty containers. ` This setting only affects CA DLP users within the specified target parent group. (Note that you cannot confirm or reject individual changes. the wizard creates empty user groups for each empty LDAP or data file container. These attributes are used to derive a group hierarchy in CA DLP for imported users. Account Import can derive a hierarchy of parent groups based on a concatenation of specified LDAP attributes. ` Users prepended with a domain name other than the one set on the Synchronization Scope screen (see page 152) are not moved.) 8 Create Group from LDAP attributes screen Available only if you selected ‘Use LDAP attributes to group users’ in step 7 on page 152. 3 Edit button. The source LDAP directory structure may contain empty containers.. See page 157 for details. If you do not select this option. When importing users. See step 13 for details. an LDAP directory may include the following branch: LDAP: ou=Unipraxis/ou=London/ou=Sales If the ‘Sales’ container is empty of users but the ‘London’ container is not empty. If you clear this option. 5 Move buttons. these nonLDAP users are preserved in the CA DLP user hierarchy. synchronization is automatic. 2 Save button.Chapter 9 Account Import 153 ` Create empty groups Available only if you selected ‘Create new users’ in step 6. you must confirm all of the resulting changes to the user hierarchy. you can set up Account Import wizard to ignore these empty containers or to create corresponding empty user groups in CA DLP. the wizard creates the following hierarchy in the Administration console: CA DLP: Unipraxis/London ` Manual confirmation If you select this option. Create Group from LDAP Attributes screen 1 Available LDAP attributes. If required. but no users. 4 Attribute list. If you do not select this option. Available only if you selected ‘Re-organize existing users’ in step 6. 1 2 3 ` Move unknown users to. . If you select this option.

Account Import can synchronize e-mail addresses in the CMS database with addresses in an external source. 3 Combined LDAP attributes. Account Import can copy user attributes from an LDAP directory or data file to the custom user attributes defined in CA DLP. you can append a conversion expression. an employee attribute custom created for your organization). For example. See page 178 for details. ` Modifying attribute values: If you need to modify the values of an LDAP attribute before using these values to derive a group hierarchy in CA DLP. For example. Choose from a drop-down list. Such synchronization is essential for CA DLP features that rely on e-mail address mapping! See page 489. select CA DLP attribute then choose an LDAP user attribute from the drop-down list. imported as a single value. you can create an Employee ID attribute and assign a unique ID to each user in your organization. . these LDAP attributes arranged in the following order: country office department Produce this group hierarchy in CA DLP: USA New York In this screen. enclosed in square brackets. 3 9 Email attributes screen Available only if importing from an LDAP directory (see step 1) and you selected ‘Copy user attributes’ in step 6. i If you use the ICAP agent to integrate with BlueCoat ProxySG servers. use the Edit and Save buttons to add this attribute to the list. typically an LDAP directory. To map an LDAP attribute to CA DLP attribute. you need to import the distinguishedName attribute—see page 384. Account Import wizard. If required. If you need to add an attribute not listed here (for example. User Attributes screen 1 CA DLP user attributes. Double-click to rename. to the attribute name. 10 User Attributes screen Available only if importing from an LDAP directory (see step 1) and if you selected ‘Copy user attributes’ in step 6 on. Each imported address is associated with a CA DLP user. 2 LDAP attributes. 1 2 Directors Sales Boston Legal Sales ` Adding custom attributes: Account Import only displays the most commonly used LDAP attributes in this screen. add the LDAP attributes that contain e-mail addresses. Account Import can select the default e-mail attributes. CA DLP lets you define custom attributes for user accounts. Use the Edit and Save buttons to add the attribute-plus-expression to the attribute list. In this screen.154 CA DLP Deployment guide Choose which LDAP attributes to use. and specify the order in which they are used to derive a group hierarchy. the CA DLP attributes are listed on the left.

When the import operation runs. For example: LDAP attributes: building. If you choose to anchor the user synchronization on: 12 Import Assessment screen Wait while Account Import identifies all the changes and additions that will be made to the CA DLP user hierarchy. ` Modifying attributes: If necessary. index 2 to UserAttribute2. enclosed in square brackets. double-click the LDAP attribute. you can rename any CA DLP or LDAP attribute. then append a conversion expression. Enter a value in the Attribute Index field. This anchor can be the user name. the Account Import will update the attributes for each CA DLP user with the corresponding attribute values in the LDAP directory. double-click the LDAP attribute. ` Full name: The LDAP attribute mapped to CA DLP user full names was specified in step 10 on page 154. to the attribute name (see page 178). e-mail addresses and other attributes). Having established a link between the target user account in CA DLP and the source user. ` Attribute index: The LDAP attributes mapped to CA DLP account attributes were specified in step 10 on page 154. the user full name. i This check box is automatically selected and disabled if you choose to anchor the user synchronization on the user name.deskNumber ` User name: The LDAP attribute mapped to CA DLP user names was specified in the User Name Attribute field in step 3 on page 151. where index 1 refers to UserAttribute1. you can modify the imported value for any LDAP attribute before writing them to an attribute of a CA DLP user account. To do this. Account Import can then update the account details in CA DLP with the imported information (the user’s parent group. doubleclick the attribute and type its new name. you need to ensure that this check box is not selected. 11 Anchor attribute screen Select which CA DLP account attribute maps CA DLP users to LDAP (or data file) users when synchronizing the CA DLP user hierarchy with that in LDAP (or the data file).Chapter 9 Account Import 155 ` Combining LDAP attributes: To combine multiple LDAP attributes and write them as a single value to CA DLP attribute (see page 168). This is because the synchronization will not match against a CA DLP user unless the user name is the same. . To do this. Account Import uses the specified CA DLP attribute to locate the corresponding user in the LDAP directory (or data file). ` Renaming attributes: If necessary. then manually type a comma separated list of the LDAP attributes you want to combine. or any of the defined user attributes. For example.floor. and so on. if a user has recently married. User renames allowed: It is possible that the user name in the CA DLP database is different to the value of the XML <user> tag or LDAP attribute used for the user name. To stop the user name in the CA DLP database being overwritten during a synchronization process.

then the value of the E-mail addresses can be deleted option in the Synchronization Scope screen (see step 6 on page 151) is matched in this disabled option. 14 Importing screen The wizard now has all the information it needs. Select this option to confirm any e-mail address deletions specified in the command file. 2 Account Import wizard. 2 E-mail addresses can be deleted. the wizard lets you confirm or reject the changes to the existing user hierarchy. When the list of changes appears. Wait while it imports the user data and updates the CA DLP user hierarchy. Note that these changes may take several minutes to appear if the import operation involves substantial additions or changes to the user hierarchy. as existing e-mail events may no longer be associated with the correct user—see page 163. click Next to accept the changes and proceed to the next screen. In the Confirm Changes screen: 15 Import Complete screen Details about the import operation are recorded in a log file. If you have carried out a synchronization. ` Display Changes: Click to view a list of the proposed changes to the CA DLP user hierarchy. ! We do not recommend that you use this parameter. i This option is only enabled if importing from a command file—see page 150. Confirm Changes screen 1 Display changes. 1 ` E-mail addresses can be deleted: Confirms that any emaildelete commands in the command file (see page 171) will be carried out during the import operation. .156 CA DLP Deployment guide 13 Confirm Changes screen If you selected the ‘Manual confirmation’ option in step 7. click Cancel to reject all of the changes and quit the wizard. See page 149 for details. Click to view proposed changes to CA DLP user hierarchy.

However. The following example specifies the Management group as the destination for imported users. This can be any existing group that falls within your management group. 1 The source LDAP directory is ‘ou=Sales’. 2 CA DLP user hierarchy: After importing 1 Parent group. The original LDAP directory structure is preserved in the CA DLP user hierarchy. It assumes that the Create New Users option is selected when you run the Account Import wizard.Chapter 9 Account Import 157 Example import operation The example below is based on the examples in steps 4 and 5. However. . any unknown users outside of this group or its subgroups are not reorganized. LDAP users imported into this group. Specifically. Unknown users outside of this branch of the user hierarchy are not reorganized. unknown users in the Sales group are not reorganized into the exceptions group. If required you can move any unknown users within this group or its subgroups to an exceptions group. For example. you can specify how CA DLP handles 'unknown' users or groups. ou=Unipraxis ou=Sales ou=Asia ou=Europe ou=N America Handling for unknown users When you import users from an LDAP directory. 2 Imported groups. you can move them to an 'exceptions' group. These are users and groups in your existing CA DLP user hierarchy that are not present in the LDAP directory. Users Management Marketing CA DLP user hierarchy: Before importing 3 The following changes are imported to the CA DLP user hierarchy: Users Management Marketing Asia Europe N America Sales 1 Example CA DLP user hierarchy The Management group is the target parent group for imported users. Unknown users in the Marketing and Sales groups are not reorganized. Users Management Marketing Example LDAP directory structure 2 The target CA DLP parent group is ‘Users’. be aware that this reorganization only affects CA DLP users within the specified parent group.

All subsequent LDAP import operations can use these cached credentials by invoking the /ec parameter—see page 162. We recommend that you use the syntax in the example above. You can import user details from an LDAP directory via a command line using Secure Sockets Layer (SSL)—see page 159. a command only includes the /op parameter—this specifies an import configuration file. Example command The command below specifies that import parameters are defined in the my_parameters. i Note the following: <parameters> defines one or more import parameters. wgninfra -run wigan/infrastruct/accounts/AccountImport my_logfile.158 CA DLP Deployment guide Command line import operations Account Import also supports command line operations for importing user details from an LDAP directory or other external source. for example. ` LDAPTrans has been deprecated. we recommend that you run a single ‘actionless’ import operation with the /cc parameter. . or XML file is: wgninfra -run wigan/infrastruct/accounts/AccountImport [<logfile>] <parameters> Where: wigan/infrastruct/accounts/AccountImport defines the required Java class for an LDAP import operation.log. solely to cache your LDAP credentials. Command line operations may import user details successfully from other LDAP compatible directories.log /op my_parameters. but is still available for use.opt ` Command line import operations have been tested against Microsoft Active Directory and iPlanet 5. to ensure that your LDAP directory and CA DLP user hierarchy stay synchronized. Cache the LDAP logon credentials Before you begin ‘real’ command line import operations from an LDAP directory. Typically. which contains all the other parameters required for the current import operation. Available parameters and parameter rules are described on pages 160 to 167. but these have not been tested. [<logfile>] optionally defines a non-default log file. For example: wgninfra -run wigan/infrastruct/accounts/AccountImport /cc /un UNIPRAXIS\srimmel /pw abc123 This command securely caches the LDAP logon credentials for the user UNIPRAXIS\srimmel (the password is abc123).2 LDAP. Command line operations enable you to schedule regular import operations. See the following sections for details. Command syntax The command line syntax for importing user details from an LDAP directory.opt parameter file (see page 160) and that import results are written to my_logfile.

CA DLP appends a timestamp and .log Set up Secure Sockets Layer (SSL) CA DLP supports SSL when importing user details from an LDAP directory via a command line.Chapter 9 Account Import 159 Log files If the command does not specify a log file. mylog_200201200945. the log file is saved in CA's \data\log subfolder of the Windows All Users profile. You do not specify a file name extension for the log file. Alternatively. page 499. you can specify a custom log file. run: keytool -import -keystore . you need to add the SSL support option to your command file: 1 Install the certificate on the CMS: From a command prompt in the \system\jre142_12\bin subfolder in the CA DLP installation folder on the CMS.log extension to the file name. i We recommend that you restart the CMS after installing the server authentication certificate.. You do not specify a path. 2 Configure the parameter file: Add the /us option to the command line import operation configuration file to enable support for SSL.\lib\security\jssecacerts -alias <alias> -file <cert file> where: <alias> is a relevant and descriptive name for the certificate and <cert file> is its file name. for example. . See page 149 for details. Then. the results of each import operation are written to a CA DLP log file. If: The log file already exists. To use SSL. you must first obtain a server authentication certificate that identifies your LDAP server and install it on your CMS to enable CA to recognize and trust the server. log entries for the new import operation are appended to it.

we strongly recommend that you use a parameter file to specify your import parameters—see the /op parameter on page 161.160 CA DLP Deployment guide Parameter files A range of parameters are available for configuring the import operation. For ease of maintenance. Parameters SLL support parameter /us Operation parameters /ca /re /at Data source parameters /op /df /lp LDAP logon parameters /sv <server> /un <ldap user> /pw <ldap password> /cc /ec Source container and target group parameters /dn <Root DN> /lr <context> Page 159 159 161 161 161 161 161 161 161 161 162 162 162 162 162 162 162 Parameters /wr <group> /ga <LDAP attribute list> /ft /ce /me /eg <exceptions group> /pd <domain> /ml <LDAP attribute list> /ed /al <LDAP attribute list> Error handling parameter /iw LDAP filter attributes /uf <LDAP filter> /nf <LDAP filter> Source and target file parameters /ou <filename> /in <filename> User mapping and identification parameters /ua <LDAP attribute> /fn <LDAP full name attribute> /an <CA DLP account attribute> /nu Page 162 162 163 163 163 163 163 163 163 164 164 164 165 165 165 165 165 165 165 165 165 166 166 162 162 . These are listed on the following pages. An example parameter file is shown on page 167.

For details. commas and backslashes (for example. you can enclose each list item in ‘single quotes’. the data file takes precedence. you must prefix the characters with a backslash to ensure they are interpreted correctly. it also creates new groups to hold these new users. in XML or spreadsheet-compatible format. For example: /al ‘proxyAddresses’. For example: /lr "o=\"Unipraxis PLC\"" Here.’Mail’ Here. if this parameter is absent. /df Specifies a data file. These are structured files of user data. where they are separated by commas.Chapter 9 Account Import 161 Parameter rules These rules apply to all relevant Account Import parameters: Single quotes: If a parameter is set to a comma separated list of values (this typically applies to the /al and /ga parameters). containing all or part of an external user hierarchy. it creates a new account for any user in the LDAP directory or data file who has no corresponding account in CA DLP. That is. If an import operation imports simultaneously from both an LDAP directory and a data file. /re Reorganizes the existing hierarchy of CA DLP users to synchronize it with the hierarchical structure of the LDAP directory or data file. /at Updates existing CA DLP user accounts with attributes imported from corresponding users in the LDAP directory or data file. In the example below. An example configuration file is shown on page 167. If a parameter value includes quotes. all values in the multiple-value LDAP attribute proxyAddressses are assigned to UserAttribute1. Double quotes: You must enclose the entire parameter value in "double quotes" if the value contains a space. the LDAP root container is o="Unipraxis PLC". this parameter specifies that the LDAP source takes precedence if duplicate users are detected. . Where necessary. Data source parameters /op Specifies a configuration file containing other parameters. based on the equivalent containers in the LDAP directory. the target group for imported users is ‘LDAP users’: /wr "LDAP Users" Operation parameters ! Each command must specify at least one of the following parameters: /ca Specifies that CA DLP creates new user accounts for unknown users. ! You must include the /at parameter if you want to specify attributes using the /al and /ml parameters. as part of a conversion expression—see page 178). Backslash prefixes are needed to ensure the double quotes are handled correctly. /lp This parameter takes no value. Prefix special characters with a backslash: Certain separator characters have a reserved meaning. while the Mail LDAP attribute is assigned to UserAttribute2. see page 149. This helps when the list item itself contains a comma—this typically happens when you need to specify a separator for multiple-value LDAP attributes.

For example.com or dc=unipraxis. set to a comma-separated list of LDAP attributes. See page 158. you can prefix it with a colon after the server name. Before you begin ‘real’ LDAP import operations. each set to a single LDAP attribute. we recommend that you run a single ‘actionless’ import operation with the /cc parameter. to specify an Active Directory domain you must enter one of these formats: unipraxis.team Or /ga division /ga department /ga team . for example: /sv UNI-HARDY-XP:319 /un <ldap user> Specifies the user account used by CA DLP to access the LDAP database. /pw <ldap password> Specifies the password for the LDAP user specified by the /un parameter.dc=com /lr <context> Specifies the base context for import operations in the LDAP directory.ou=room /wr <group> Specifies the target parent group in the CA DLP user hierarchy. If the LDAP port number is not 389. This eliminates the need to include sensitive account details in your import configuration file. The purpose of this parameter is to allow all subsequent import operations to log on to the LDAP database using these cached credentials. the instances are processed in the order in which they occur in the command or configuration file. You can specify the server name or IP address. solely to cache your LDAP credentials.162 CA DLP Deployment guide LDAP logon parameters /sv <server> Identifies the server hosting the LDAP directory.department. For example. /ec Enables CA DLP to log on to the LDAP database using the cached credentials previously specified by the / cc parameter. relative to the root-level ‘Users’ group. /cc Caches in a secure location the credentials used to access the LDAP database. the context might be: ou=dept. You can specify a single /ga parameter. For example: /ga division. /ga <LDAP attribute list> Derives a user's group from the LDAP attributes in this comma separated list. These are the credentials specified by /un and /pw. All imported users and groups will be added to this parent group. See the /ec parameter below for details. All users and groups at and below this level will be copied into CA DLP. This is the logon method we recommend. or you can specify multiple instances of the /ga parameter. Source container and target group parameters /dn <Root DN> Specifies the LDAP server’s base DN or domain. You must specify the path to this group.

or the structure specified in a data file. may contain empty containers. this setting will automatically add one. otherwise any /ml attributes you specify will not be written to CA DLP user accounts—see page 161. See page 178. To do this. i Users prepended with a domain name other than the one set in the /pd <domain> parameter (see below) are not moved. this specifies the Users/Non-LDAP users subgroup: /eg "Non-LDAP users" If this parameter is omitted and /me is set. You do not need to add a backslash. You must specify the full path to the group. If the user names in the LDAP directory or data file do not have a domain prefix (that is. The /ml parameter also enables you to modify e-mail addresses in the LDAP directory before writing them to the CMS database. This parameter creates corresponding empty user groups in CA DLP. you specify a conversion expression. we recommend that you use this parameter with extreme caution. immediately below the root-level ‘Users’ group. we strongly recommend you use multiple instances of /ml. That is. you must use the /ml parameter to import the distinguishedName attribute—see page 384. Account Import creates a default ‘Exceptions’ group. /eg <exceptions group> Used in association with /me. relative to the root-level ‘Users’ group. These may hold subcontainers or other items. new accounts for all imported users will be created in a single group. ! You must also include the /at parameter. the user name does not contain a backslash). /ce The LDAP directory structure. This can be any group in the CA DLP user hierarchy. If you specify this parameter for a: ` Synchronization process. i If you use the ICAP agent to integrate with BlueCoat ProxySG servers.proxyAddresses. but no users.Chapter 9 Account Import 163 /ft Specifies that users imported into CA DLP will have a flat hierarchy. /ml mail /ml proxyAddresses /ml legacyExchangeDN ! For ease of maintenance. For example: /ml mail. /ed Specifies that emaildelete commands (see page 171) are carried out during the import or synchronization process. ! If you do not specify this parameter (this is the default). However. each set to a single LDAP attribute. You can specify a single /ml parameter. /pd <domain> Prefixes new CA DLP user names with the specified domain name. any emaildelete commands in the file will be executed. /ml <LDAP attribute list> Specifies which LDAP attributes are written to the e-mail address table in CA DLP.legacyExchangeDN Or /me If your existing CA DLP hierarchy contains users not present in the LDAP directory or data file. then emaildelete commands are ignored. For example. . defined by the /eg parameter—see below. or you can specify multiple instances of the /ml parameter. i To use the /ce parameter. the /ca parameter must also be set—see page 161. The target group is the group specified by the /wr parameter— see above. ` Command file import. set to a comma-separated list of LDAP attributes. then any e-mail address present in the CA DLP database but not in the data source is deleted from its associated user. This parameter specifies the target ‘exceptions’ group. this parameter moves them to an ‘exceptions’ group.

or ` Combine multiple attribute values and write them to a single CA DLP user attribute (see page 168). You can choose which separator to use. This parameter enables Account Import to continue with the import operation under these circumstances by ignoring any warnings. Account Import will stop the import operation under these circumstances. /al division /al employeeID /al rank ! For ease of maintenance. each set to a single LDAP attribute. See page 178. the syntax is shown below. . set to a comma-separated list of LDAP attributes.Floor. That is. The /al parameter also enables you to: ` The Administration console. the LDAP directory may contain three attributes.DeskNumber You can specify a single /al parameter.employeeID. we strongly recommend you use multiple instances of /al. or you can specify multiple instances of the /al parameter. otherwise any /al attributes you specify will not be written to CA DLP user accounts—see page 161. and so on.164 CA DLP Deployment guide If an e-mail address is removed from a user’s address list. In both examples above. then any events associated with the deleted e-mail address are no longer associated with that user. be aware that valid e-mail addresses may also be removed. <attribute2><SV separator> <attribute3> Example: /al Building. To combine these attributes into a single value and write it to a single CA DLP user attribute. ! You must also include the /at parameter. If you do specify the /ed parameter in order to clean up a misconfigured import. Syntax: /al <attribute1><SV separator> ` A manually produced command file. Building. Floor and Desk number. the first LDAP attribute is assigned to UserAttribute1. because you are warned before confirming the deletion of an e-mail address. For example: /al division. i This parameter is ignored if either the /in or /ou parameter is specified—see page 165. the LDAP attribute Rank is assigned to UserAttribute3. Use individual emaildelete commands to specify the user and associated e-mail address that you want to remove. the instances are processed in the order in which they occur in the parameter file. the second to UserAttribute2. If this parameter is not set. To do this. For example. you specify a conversion expression. /al <LDAP attribute list> Specifies which LDAP attributes are written to account attributes of CA DLP users. Error handling parameter /iw When you use a command line to synchronize users’ e-mail addresses in the CMS with users in an XML file. It may be better to remove any problematic e-mail addresses using: LDAP attributes are assigned to CA DLP account attributes in the order in which they occur. Account Import will stop the import operation if a user’s management group in the XML file does not exist in the CA DLP hierarchy.rank Or ` Modify LDAP attribute values before writing them to an attribute of a CA DLP user account.

rem or Rem are equally acceptable as comment markers. User mapping and identification parameters /ua <LDAP attribute> Specifies the user name attribute. /in <filename> This parameter specifies a Command File to use. /uf <LDAP filter> Specifies which RFC 2254 filter to use when extracting users from the LDAP database. CA DLP automatically detects the type of LDAP directory (for example. For example. It provides a 'best guess' when selecting the LDAP user name attribute. Use this parameter if you need to specify a custom or non-standard LDAP attribute. Microsoft Active Directory) and provides a 'best guess' when selecting the LDAP full name attribute. /fn <LDAP full name attribute> Specifies the LDAP attribute that contains each user’s full name.Chapter 9 Account Import 165 LDAP filter attributes If necessary. DisplayName. search the index for ‘users. A list of commands can be found on pages 169 to 177. . for example. all other parameters are ignored. sAMAccountName. so REM. for example. you can filter your import operations to only extract the users you want from the LDAP database. ensure that the new filter conforms to RFC 2254. i If this parameter is specified. Microsoft Active Directory) and key details about the LDAP directory structure. This file can be created manually or by exporting in command file format—see the Administration console online help. CA DLP automatically detects the type of LDAP directory (for example. hierarchy exporting’. This parameter is typically used in association with the /in parameter (see below) to break import operations into two stages: ‘Extraction from LDAP or data file’ and ‘Import into CA DLP’. Comment markers These formats identify comments in a parameter file: # Your comment goes here REM Your comment goes here Note that REM is not case-sensitive. Source and target file parameters /ou <filename> This parameter diverts user details extracted from an LDAP directory or data file to a specified text file. /nf <LDAP filter> Specifies which RFC 2254 filter to use when extracting the LDAP containers (or nodes) that correspond to CA DLP user groups. If you do specify specific object classes and categories. you may want to keep a record of all changes to the CA DLP user hierarchy. If this parameter is omitted. If this parameter is omitted.

CA DLP uses the specified user attribute to locate the corresponding user in the LDAP directory. it must match exactly the corresponding attribute value in the LDAP database.166 CA DLP Deployment guide /an <CA DLP account attribute> Specifies which CA DLP account attribute to use as the anchor for mapping LDAP (or data file) users to CA DLP users. /nu When carrying out a synchronization process. use the keywords specified below: /an username Or Anchor requirements Note the requirements for the CA DLP attribute used to anchor user import operations: ` Each user in your CA DLP enterprise must have a unique attribute value. See page 168 for details. This can be the user name. In each case. ` The attribute cannot be a multiple value attribute. it is possible that the user name in the CA DLP database is different to the value of the XML <user> tag or LDAP attribute used for the user name. /an fullname Or /an attribute1 Or /an attribute2 And so on. But note the requirements below. if a user has recently married. ` The attribute values must not have been modified (using a conversion expression). the user display name. or any of the ten user attributes. That is. To stop the user name in the CA DLP database being overwritten. LDAP attribute specified by /ua /fn /al /al . For example. The specific mapping is shown below: /an username fullname attribute1 attribute2 And so on. add this parameter to the command line.

Existing CA DLP users not present in the LDAP directory will be moved to an exceptions group called ‘Non-LDAP users’. . Example parameters /ca /re /at /sv UNI-HARDY-XP /ec /dn unipraxis. reorganize the existing CA DLP user hierarchy. User names for new CA DLP accounts will be prefixed with ‘UNIPRAXIS\’.. i You cannot include ‘empty’ /al parameters. users in the LDAP directory are all stored in a single container. This example also imports e-mail addresses and various LDAP attributes. this contains unique employee IDs. Account Import derives their position within the LDAP hierarchy by concatenating these LDAP attributes: Division. These specify the LDAP root (or source container) for the import operation.) Defines the target group for imported users. based on hierarchy from this list of LDAP attributes. In this example. These /al instances write LDAP attributes to UserAttribute1 through UserAttribute3 and to UserAttribute5. to specify non-consecutive user attributes.Department.Chapter 9 Account Import 167 Example parameter file The following is an example parameter file for a command line import operation from an LDAP directory. (In the screenshot on page 168. Department and Team. This example specifies CA DLP user attribute 6. Note the use of double quotes. ou=employees.Rank Updates CA DLP user attributes. /al EmployeeID /al Department /al Team.Team /ml mail /ml proxyAddresses /ml legacyExchangeDN Updates CA DLP e-mail address attributes.com /lr ou=employees /me /eg "Non-LDAP users" /pu /pd UNIPRAXIS /ua attribute6 Resulting action These define the import actions: create new CA DLP user accounts. These specify the LDAP host server and use previously cached credentials to log on to LDAP. and update the account attributes for CA DLP users. /ga Division. The backslash is added automatically. you must use comma delimiters. Defines the ‘anchor’ LDAP attribute. Account Import writes these details to each CA DLP user account.

i In all cases. Combining multiple LDAP attributes in single CA DLP attributes If necessary. Building. see page 164. see step 10 on page 154 for an example. remember the parameter rules on page 160. you can combine these attributes into a single value and write this value to a single CA DLP user attribute renamed to Desk Location. This has implications for user import operations from an LDAP directory. . Importing a single LDAP attribute with multiple values Individual attributes in LDAP directories or data files can contain multiple values. To do this using the Account Import wizard.168 CA DLP Deployment guide Multiple attribute values Individual attributes in both CA DLP and LDAP directories can contain multiple values. For example. a MemberOf attribute can contain all the mail groups or e-mail distribution lists that a user belongs to. Floor and Desk number. For example. 2 Multiple values for a single LDAP attribute. the LDAP directory may contain three attributes. written to separate values for a single CA DLP attribute. when assigning lists of LDAP attributes to a single import parameter. Using Account Import. To do this using the /al parameter in a command line operation. For example. 1 2 User Properties dialog. Attributes tab 1 Multiple LDAP attributes combined into a single value for a single CA DLP attribute. you can import all the MemberOf distribution lists that a CA DLP user belongs to as separate values for an attribute renamed to Email Distribution Lists (example 2 in the screenshot below). Account Import automatically writes multiple LDAP values to multiple values of a specific CA DLP user attribute. See example 1 in the screenshot below. Account Import can write multiple LDAP attributes to a single attribute of a CA DLP user account.

Within the command file. The correct formats for individual records are shown in the tables below and on the following page. The parent group must already exist.<group name> Create a new group Specify the new group and any existing group to act as its parent.Chapter 9 Account Import 169 Command files to import users Account Import also lets you import user details from a command file (a tailored CSV file). The group name is not case-sensitive.<parent group> ! You need to be aware that moving groups can cause security issues and unintended changes to policy—see the Administration console online help. a record to move a group must precede any records to move users into the relocated group. The order of operations is important. Typical operations include adding new users or groups. Each user record begins on a new line with a variable that defines the type of operation. see page 176. Typically.<group name>. You can also include comments within the file. and example group paths. Set the default group Specify any existing group to act as the default group. you must ensure that each record in the file conforms to the format required by Account Import. i If required. to organize the file into sections.<group name>. you can even combine user import and machine import operations within a single command file. This operation will also move any subgroups. moving users’. Delete a group This command removes a specified group from the database.<parent group> Import a new user Specify the user name and a parent group. For machine import record formats. newuser. It is not case-sensitive.<parent group> Move a group to a new parent group Specify the current group and any existing group to act as its new parent. These are import configuration files containing CA DLP user import commands (for example. you import command files to make specific changes or additions to your existing CA DLP user hierarchy. movegroup. . If you plan to export your user details (say. The group name is not case-sensitive.<user name>. The format is: deletegroup. i For additional notes about the formats. moving a user or group to a new parent group. Likewise. records to create new groups must precede records to add new users to these groups.<current group>. from your mail server) to a command file. defaultgroup. you could write a script or macro to prefix each user record with the appropriate operation variable. 'create new user' or 'set user attribute'). see page 172. Example files are shown on page 174 and page 175. Note the groups are not case-sensitive. for example.<parent group> Command file format Before you can import a command file containing user details. and updating a user’s attributes. password or management group. newgroup. user and group name requirements. search the index for ‘groups. specifying a user's role.

The format is: addmgmtgroup.170 CA DLP Deployment guide Move a user to a new group Specify the user name and their new parent group."Unipraxis\srimmel".<user name>.<role> Specify a user’s full name Specify the user name (that is.<user name> Add a management group This command assigns a management group to a user. Delete a management group This command removes a specified management group from a user.<full user name> Specify a new management group This command assigns a single management group to a user. null.<user name>.<user name>.<user name>. which in turn defines their default administrative privileges.<user name>.<management group> Set a user password All users must a supply a password the first time they use the CA DLP consoles or certain CA DLP utilities. that is. null. then the user is assigned the group selected as the User Tree Root. It replaces any existing management groups with the new one. The parent group must already exist. To reset a user’s password. managegroup.<management group> Reset a user password This command allows you to reset a user’s password but does not force that user to change their password when they next log on to CA DLP."/" Delete a user This command removes a specified user. Account Import therefore lets you assign a temporary password to a new user.<user name>. the user name. then the user is assigned the group selected as the User Tree Root. It is not case-sensitive. setrole. managegroup. the new user is then forced to change this password to something more private when they first log on to CA DLP."Unipraxis\srimmel" managegroup. The format is: fullname. or not specified (see managegroup for examples). or not specified (see managegroup for examples). then the user is assigned the group selected as the User Tree Root.<user name>. the format is: password_noexpiry."Unipraxis\srimmel". . The format is: renameuser."" managegroup. The format is: managegroup.<password> i If the management group name is left blank."Unipraxis\srimmel". the name used by the user account) and the user’s full name. null.<user name>. The format is: delmgmtgroup.<new user name> i If the management group name is left blank. moveuser.<user name>.<password> i If the management group name is left blank.<parent group> Specify a user’s role This command specifies a user’s role. It does not replace any existing management groups already assigned. The format is: deleteuser. or not specified.<management group> Rename a user This command allows you to reset the name of the user account. To specify a temporary password for a new user. For security reasons. the format is: password.

Specify the attribute number. then this command will set one.<srimmel>. or its original attribute number when using this command.<Male> OR Attribute:Gender.<New York> OR delattr "location". .<attribute value> And so on If you have renamed a user attribute.<srimmel>.<srimmel>. user name and the attribute value you want to delete.<Male> OR Attribute Gender.<attribute value> setattribute2. You can use this command to add multiple values to any user attribute.<user name>.<address> Delete an e-mail address This command deletes an e-mail address associated with a user: emaildelete.<user name>.<Female> OR setattribute "gender". If no value is currently set.<lsteel>.<lsteel>. For example: setattribute2. or its original attribute number when using this command. Note that this command does not overwrite existing attribute values. and the attribute value you want to add.<srimmel>. If you have renamed a user attribute.<lsteel>.<lsteel>.<srimmel>. you can specify the attribute by its new name (in one of three ways).<attribute value> Attribute3.<attribute value> And so on This command overwrites all existing values for an attribute.<attribute value> And so on. setattribute1. user name and the attribute value you want to set.<user name>.<Female> OR setattribute:gender. For example.<user name>.<user name>.<New York> OR delattr location.<user name>.<attribute value> Attribute2.<New York> Add an e-mail address This command adds an e-mail address for a user: emailaddress.<Female> Delete a user attribute value This command deletes a specific value from a specified attribute.<Male> Set a user attribute to a single value This command removes the previous value of the attribute and replaces it with a new value. If you have renamed a user attribute.<user name>. user name.<user name>.<srimmel>.<New York> OR delattr:location.Chapter 9 Account Import 171 Add a user attribute value This command imports a new value for a specified attribute. Add comments These formats identify comments in a CSV file: # Your comment goes here // Your comment goes here REM Your comment goes here Note that REM is not case-sensitive. delattr1.<attribute value> delattr3.<attribute value> delattr2.<Male> OR Attribute "Gender".<user name>.<srimmel>. or its original attribute number when using this command. if Attribute2 is set to ‘Gender’: Attribute2.<user name>. Attribute1.<user name>. so REM.<Female> OR setattribute gender.<attribute value> setattribute3.<srimmel>. rem or Rem are equally acceptable as comment markers. For example: delattr3. Specify the attribute number. Specify the attribute number. you can specify the attribute by its new name (in one of three ways). you can specify the attribute by its new name (in one of three ways).<address> i See the warning on page 163.

for example. i The group must already exist. You can also reference an attribute using the following syntax: attribute:<attribute name> attribute <attribute name> i A single space character is used to separate the 'attribute' keyword from the attribute name. <role> See page 173 for details. <password> The new password assigned to the specified user. See the example group paths and group name requirements on page 173. <group name> This is the name of the new group. If you omit any numbered attributes from the CSV file. note the following: <address> A user’s e-mail address. So attribute1 updates the value for the first attribute listed.172 CA DLP Deployment guide Format notes When creating records in a command file. attribute2 updates the value for the second listed attribute. See also the group name requirements on page 173. <parent group> This is the path of the group into which you want to add or move a user or another group. attribute n These correspond to the CA DLP attributes listed in the User Properties dialog.com EX: /o=unipraxis/ou=uk/cn=spencer/cn=rimmel Domino: cn=spencer rimmel/o=unipraxis A command file can include multiple instances of this command for each user. Users can have multiple management groups. See the example group paths on page 173. <management group> This a management group assigned to the specified user. and so on. You cannot assign management groups that fall outside of your own management group. The path is delimited by forward slashes and is relative to the management group of the administrator running Account Import. Marketing. the corresponding attribute values remain unchanged for the CA DLP user. You need to be aware that moving groups can cause security issues and unintended changes to policy—see the Administration console online help. This can be any format. . <user name> See page 173 for details. move users between groups’. search the index for ‘groups. Enclose the name in double quotes if it includes spaces. Enclose the text in double quotes if it includes spaces. "Lynda Steel". The path is delimited by forward slashes and is relative to the current user’s management group. See the example group paths and group name requirements in the following sections. For example. for example. No path is needed. ! <full user name> The display name that appears in the Summary tab. <attribute value> This is the actual number or text associated with the current attribute. <current group> This is the path of the group you want to move. The path is delimited by forward slashes and is relative to the current user’s management group. for example: SMTP: srimmel@unipraxis. the value for an employee ID attribute might be rimspe01.

For example. then you must use the following paths to add the user lsteel to these groups: Target Use this group path newuser. In effect. the user running the wizard can only grant privileges which they hold themselves: 1 3 2 Group and user name requirements When specifying group and user names: If the user or group name contains spaces. You can specify the role name or number.lsteel. unipraxis\srimmel.Asia newuser. you must delete any trailing spaces after the group name! If any are present. The default roles are: Administrator or 1 Manager or 2 User or 3 "Policy Administrator" or 4 Reviewer or 5 UserRole1 or 6 UserRole2 or 7 Role names are not case-sensitive. you must enclose the name in "double quotes". Also.Chapter 9 Account Import 173 <role> This is the role assigned to the CA DLP user. 3 Privileges granted to the imported user. moveuser or movegroup variables. if the full path to locate the /North group in the group hierarchy is: Users/Sales/Asia/Hong Kong Administrative privileges 1 The default administrative privileges assigned to a role. the import operation will fail.lsteel.lsteel[. Example group path The correct path specification for a user group depends on the actual user hierarchy in the Administration Console and the management group for the user running Account Import. If you use double quotes. If any groups or users have names that contain Far Eastern characters.] No group is needed because the wizard defaults to the management group. Sales . the administrative privileges granted to each imported user comprise only those privileges common to both the specified role and the user running the wizard. If your CMS uses Microsoft Windows user authentication to automatically generate new user accounts. The trailing comma is optional. for example. newgroup. 2 Privileges currently granted to the user running the wizard."Asia/Hong Kong" <user name> The name used by the CA DLP user account. And your management group is /Sales. this user name must be prefixed with the domain and a backslash separator. ! If you use the newuser. defaultgroup. but you do need to enclose the role in double quotes if the role name contains spaces. make sure your CSV file is saved in a Unicode format to ensure that these characters are preserved during import. Asia Hong Kong newuser.

unipraxis\lyndasteel.Directors newuser. You do not specify the users’ current group."South Asia". Moves existing users into the Directors group. Adds two new users to the newly imported Directors group.Corporate movegroup.174 CA DLP Deployment guide Example Command file 1: new users and groups This command file creates four new groups and two new users. Example user hierarchy: Before importing Users Corporate Sales 2. Example user hierarchy: After importing Users Corporate Omar Abassi Frank Schaeffer Directors Legal Sales South Asia Omar Abassi Spencer Rimmel Frank Schaeffer Lynda Steel i In this example.unipraxis\spencerrimmel. the administrator running the Account Import wizard has a management group set to the top-level Users group.Directors. i Because no parent group is specified for the new Directors or South Asia groups.unipraxis\frankschaeffer. In this example. i Example command file 2 on page 175 shows how to modify the properties of individual users. It also reorganizes the group hierarchy.Sales newgroup. Adds a comment Moves the Directors group into the Corporate group. Example command file newgroup. and Asia into the Sales group.unipraxis\omarabassi. it defaults to the management group of the user running the wizard. The wizard interprets all group paths specified in the command file as being relative to this management group.Sales moveuser.Europe.Directors Resulting action Adds four new groups. the administrator running the wizard has a management group set to the top-level Europe . Import results for example command file 1 1.Directors # Move users and groups to a new parent group movegroup.Legal.Corporate newuser.Directors newgroup.Directors moveuser."South Asia" newgroup.

com attribute1. These correspond to the first three attributes listed in the Options dialog.unipraxis\spencerrimmel.rimmel password.Chapter 9 Account Import 175 Example Command file 2: user properties This command file sets various properties for the new users created in example command file 1 (page 174).unipraxis\lyndasteel.unipraxis\lyndasteel.unipraxis\lyndasteel. Example command file fullname.unipraxis\spencerrimmel. the administrator running Account Import has a management group set to the top-level Users group.unipraxis\spencerrimmel.Sales emailaddress.131026 attribute2.Phoebe Rimmel Resulting action Sets the full names for the two new users. Set the management groups for the named user.3 // Set the password and management group password."Spencer Rimmel" setrole.com Attribute 1 (Employee ID): 131026 Attribute 2 (Home telephone): 0182 3367 0832 Attribute 3 (Emergency contact): Phoebe Rimmel .unipraxis\spencerrimmel.unipraxis\spencerrimmel. Import results for example command file 2 New user: Role: Temporary password: Management groups E-mail address: User attributes: Lynda Steel Manager Steel Users\Corporate User\Sales Not specified Not specified User Rimmel None Spencer Rimmel srimmel@unipraxis.steel managegroup. Note that 3 corresponds to ‘user’. Adds an e-mail address Imports values for user attributes.0182 3367 0832 attribute3.unipraxis\lyndasteel. i This command file sets the properties for two new users. but command files can equally be used to set the properties of existing users. Adds a comment Sets temporary passwords for named users. As before.unipraxis\spencerrimmel."Lynda Steel" fullname. srimmel@unipraxis.manager setrole.unipraxis\spencerrimmel.unipraxis\lyndasteel. Sets the user roles.Corporate addmgmtgroup.

either the CMS or a gateway.<parent server> Where <client name> is the name of the new client machine and <parent server> is its parent server. you import the gateway and client or utility machine details from a command file. either the CMS or another gateway.<parent server> Command file format When you import a command file containing machine details. you can bulk create new machine accounts and pre-assign client machines to parent servers in advance of the CA DLP rollout.<gateway>. That is. Create a new client machine newclient. This enables you to deploy multiple client machines using a single source image (which identifies a single parent server) while ensuring that each client machine automatically connects to its 'correct' parent server immediately after installation.<parent server> Where <machine name> is the name of an existing client or utility machine. either the CMS or a gateway. Delete a machine This command deletes a specified machine. each record in the file must conform to the format required by the wizard. You can do this using the Account Import wizard.176 CA DLP Deployment guide Command files to import machines To simplify mass deployments. rem or Rem are equally acceptable as comment markers. Where <utility> is the name of the new utility machine and <parent server> is its parent server. or you can run a command line import operation (see page 158). or gateway and <parent server> is its new parent server. The supported formats are listed opposite. Each user record must begin on a new line with a variable that defines the type of operation.<client name>. Import from a command file To bulk create new accounts.<parent server> Where <gateway> is the name of the new gateway and <parent server> is its parent server. An example file is shown on page 177. Create a new gateway newgateway. or utility machine: deletemachine. so REM. either the CMS or a gateway. Create a new utility newutility.<utility name>.<machine name>. client. a gateway.<machine name> Move existing client machine or gateway movemachine. See step 1 on page 150. . Add comments These formats identify comments in a CSV file: # Your comment goes here // Your comment goes here REM Your comment goes here Note that REM is not case-sensitive.

parented to GW-MILAN.CMS-HARDY newgateway.GW-NAPOLI Add a comment.GW-MILAN newclient.UNI-TAYLOR. Add new GW-ROMA gateway.UNI-VENABLES.Chapter 9 Account Import 177 Example Command file Example CSV file REM Add new gateways newgateway. Add new clients.UNI-KEEGAN. Add a comment. Move existing client machine to a new parent gateway. parented to GW-ROMA.GW-NAPOLI. After CA DLP has been installed on these machines.UNI-HODDLE. parented to the CMS.GW-NAPOLI REM Add new secondary gateway newgateway.GW-ROMA movemachine.CMS-HARDY REM Add clients to new gateways newclient. Resulting action Add a comment. parented to the new gateways.GW-NAPOLI newclient. Import results for example command file 1. Add new clients. they will revert to ‘normal’ icons.GW-MILAN.GW-ROMA newclient.UNI-RAMSEY.UNI-REVIE.GW-MILAN newclient. Example machine hierarchy: Before importing Machine Administration CMS-HARDY UNI-ROBSON 2. Example machine hierarchy: After importing Machine Administration CMS-HARDY GW-MILAN GW-ROMA UNI-RAMSEY UNI-REVIE UNI-TAYLOR UNI-KEEGAN The newly imported gateways and client machines are initially represented by ‘disconnected’ icons. Add new GW-MILAN and GW-NAPOLI gateways.UNI-ROBSON.GW-MILAN newclient. GW-NAPOLI UNI-HODDLE UNI-ROBSON UNI-VENABLES .GW-ROMA.

e-mail addresses are typically prefixed with a format identifier (such as ‘smtp:’ or ‘x500:’).default=. and [section3] resolves to \cn=Lynda. The syntax for individual sections is described on page 179.] i This method relies on the specified search text (in this case "zzzz") not being found. a modification is needed. in an LDAP directory for Unipraxis. the sections may resolve like this for a CA DLP user. The example expression below inserts a single semicolon: ["zzzz". extract and (if necessary) remove or substitute any characters in the attribute value. This is because backslash characters have a special meaning in these conversion expressions.default=\\\\] . the expression then inserts the ‘default’ text (in this case. Lynda Steel: [section1] resolves to \o=Unipraxis. a semicolon). Conversion expressions can parse.178 CA DLP Deployment guide Modify LDAP values with conversion expressions A key feature of command line import operations from LDAP is the ability to modify user attribute values in the LDAP directory before writing them to an attribute of a CA DLP user account. you must add a custom ‘separator expression’ to insert the required character between sections. and [section2] resolves to \ou=Paris. For example: /al <attribute><[section1][section2] [section3]> Where each [section] represents an in the final CA DLP attribute value. if importing e-mail addresses from the proxyAddresses LDAP attribute. Account Import uses default conversion expressions to strip out these identifiers so that only the address is imported into CA DLP: ["smtp:{%untilEnd%}"] ["x400:{%untilEnd%}"] ["x500:{%untilEnd%}"] Example conversion expression For example. such as ‘UX-Boston’ and ‘UX-New York’. Conversion expression syntax Conversion expressions for imported LDAP values can comprise one or more sections. To insert a literal backslash.Steel To insert a backslash between sections. The example conversion expression below strips out the prefix in the resulting CA DLP user groups (that is. use this expression: ["zzzz". in the above expression. To modify imported LDAP values. ‘Boston and ‘New York’: /al office[if"UX-"["???{%untilEnd%}"] else["{?%untilEnd%}"]] Separators between sections You cannot add literal separators between sections. For example. Instead. you configure the /al or /ml parameter to use a conversion expression. values for the office attribute have a ‘UX-’ prefix. For example.

that is. modify the extracted text. for example. ? Matches any single character. srimmel@unipraxis.["@unipraxis"] subsection2:. Curly brackets { } delimit the text actually extracted from the e-mail address (the ‘extracted text’). substitute=<from>:<to>. Supported parameters repeat. %d% or %D% Matches any single digit. The supported <extract> variables and wildcards are: %word% Matches a whole word (that is. <extract> Is the ‘extracted text’. if necessary) into the resulting CA DLP attribute value. subsection. (after modification. substitute. %digits% Matches a sequence of digits. %alpha% Matches a sequence of letters. Supported variables <search> and <extract> jointly define which of an e-mail address supplies the extracted text.com. These can also be used to nest expressions. the actual text you want to detect within the LDAP attribute value. mandatory and default allow you to precisely locate and. this represents the text that you want to extract from the e-mail address and incorporate into the CA DLP user name. an unbroken sequence of alphanumeric characters). For each section. You must enclose this text in curly brackets { }. if necessary. .Chapter 9 Account Import 179 Section syntax Each [section] defines the text that you want to extract from a single.substitute =srimmel@unipraxis:spencer] "Double quotes" delimit the search expression. specified component of the Exchange address. mandatory. subsection=A:B. for example smtp: You use the search text to locate the start of the ‘extracted text’. This is the text extracted from the LDAP attribute value and incorporated Where: Square brackets [ ] delimit the section. default=<term>] Conversion expression variables Expression variables <search> Is the ‘search text’. %l% or %L% Matches any single letter or digit (but not other characters such as / or =). See page 179. The ‘extracted text’ is the text immediately after the 'search text' in an LDAP attribute value. for example. repeat=N. to create multiple search sections: [["srimmel"]. Variables are processed in the order they are specified in the expression. See the next section for details. You can use variables to represent any single component that you want to extract. ["<search>{<extract>}". %a% or %A% Matches any single letter.

. append=<term> Appends the specified <term> to the output string. or precedes. a null string is imported into the CA DLP attribute. For example: Expression variables (Continued) prepend=<term> Prepends. <from> is the text that you want to replace. (x)%untilEnd% Matches all extracted text starting from (and including) any character x specified in the brackets. For example. the attribute for that user has no value. <to> is your own text that you want to substitute into the CA DLP attribute value. %until(/)% matches all text until a / is detected. i You do not need to enclose the appended string in quotes. i mandatory overrides the default declaration. if the extracted text if UNIPRAXIS. i If the character is not detected. then Account Import quits trying to modify the imported attribute value. this: mandatory Specifies that if no matching 'search text' is found. i <from> can only match whole words. %until(pq)% matches all extracted text until p or q is detected. the specified <term> in front of the output string. substitute=<from>:<to> Is an optional argument for substituting text in the 'extracted text' with your own string.180 CA DLP Deployment guide Expression variables (Continued) %until(x)% Matches all extracted text up to (but not including) any character x specified in the brackets. Unless substitute text is specified. %untilstr(/ou. but removes this prefix from the extracted text (because only text within the curly brackets is extracted). i You do not need to enclose the prepended string in quotes. For example./cn)% Matches all extracted text until /ou or /cn is detected. the parameter matches all text up to the end of the LDAP attribute value. the parameter matches all text up to the end of the LDAP attribute value. %untilstr(str)% Matches all extracted text up to (but not including) any string specified in the brackets. For example: "smtp:{%untilEnd%}" Matches the entire input string if it begins with an ‘smtp:’ prefix. i If the string is not detected. That is. you cannot substitute "UNI" for "MULTI". up to the end of the input string.

Expression variables (Continued) pp"<search>":"<replace>" Performs a search and replace operation on the strings within the quotes.then.o":"/o" replaces .. if"<search>"[<then>]else[<else>] Specifies an "if..":"" removes all commas pp".unipraxis"["prepend<UK>"] else["{@%untilEnd%}"] prepends ‘Sales. For example: pp".{%a%}=":"/%1%=" Replaces . the <else> expression is performed.o= with /o= (works with any letter) And: if"Sales. If the <search> string is found. For example: i You do not need to enclose the default string in quotes. for example. then the parameter matches all text from ‘@’ to the end of the LDAP attribute value.unipraxis’ is not detected.unipraxis’ with ‘UK’.else" clause. That is. or if ‘Sales. If the <search> string is not found. then a default text string is returned as the 'extracted text' where <term> is the default string. You can also specify a section to extract and then use that extracted text in the replace expression.o with /o The supported variables and wildcards are the same as those supported by the <extract> variable—see page 179.. the first string is replaced with the second. pp"{?%untilEnd%}":"/%1%" Prepends the search string with a forward slash '/' Where %1% is the extracted string from the search text. the <then> expression is performed.. . unknown user.Chapter 9 Account Import 181 Expression variables (Continued) default=<term> Specifies that if no matching 'search text' is found. For example: pp".

182 CA DLP Deployment guide .

you can retain legacy object data in a Centera while storing all new data in a file system or in IBM DB2 Content Manager. It also provides an overview of the CMS temporary object store. that is. so new data is stored in this location. so CA DLP can continue to retrieve legacy data from the Centera. available from Technical Support—see page 23. A blob file contains the e-mail content and any attachments. chapter 10 T Temporary object store: The temporary object store is a subfolder of the object store and it contains cached blob files which are also stored on a third party storage device. written to the local CA DLP database. For example. you can separately configure which object store CA DLP uses to store and retrieve data. i If required. Concurrent use of multiple object stores There is considerable flexibility built into the CA DLP support for third party storage solutions. But you set the Data File Storage Location policy setting to ‘File System’ or ‘IBM DB2 Content Manager’ (see page 192). the object store can be a remote data folder. CA DLP enables you to continue retrieving both the legacy data and ‘new’ data when running event searches. IBM DB2 Content Manager and NetApp SnapLock. Overview The CMS acts as the central collector of ‘event data’ (captured or imported messages). Database: Full details about tables and indexes are in the CA DLP Database Schema. . as described in this chapter. migrated or written to a third party object store. and a blob (Binary Large Object) file. In both cases. for example UNC-specified network file share or a network-attached storage (NAS) device. you leave the Access Node Addresses policy setting unchanged (see page 187). saved on physical media. EMC Centera. stored in CA DLP format. event object store and temporary object store. See page 195 for details. In particular. Each CA DLP event comprises metadata. The blob file is written to disk and saved in the \Data folder or. The CMS is responsible for building the event database. Object storage Object storage his chapter describes the principal methods used for storing event data in CA DLP.10. For this example. These components are summarized below: Object store: The object store contains the blob files. It describes how to integrate CA DLP with third party object storage solutions.

3. Database server: The CMS can support a local or remote database. in this example a UNC-specified network file share. or a network-attached storage (NAS) device. For full details. see page 195. we recommend that you set up Centera integration as soon as possible after deploying CA DLP. The diagram below shows how a Centera integrates with CA DLP to work as an alternative object store. Only events captured after integration has been set up will be migrated to EMC Centera. Integration is recommended with CentraStar 3.1. Object store: The object store can be a remote data folder. The CMS stores an event record in its database and writes a blob file to its \data subfolder. . it comprises a permanent (3a) and temporary (3b) object store. i CA DLP uses version 3. 2. Events captured and replicated to the CMS before Centera integration has been set up will not be migrated to Centera. CMS: Event metadata is written to the database (2). the database containing metadata runs on a remote server. Integration may succeed with other versions but they may not have been tested. For this reason. it is replicated to the CMS. In both cases. Centera integration is configured through policy settings on the CMS. Integration between these two systems provides your enterprise with an end-to-end solution to your e-mail and Web risk management and storage needs. For information on migrating existing events to a Centera. please contact EMC Corporation. event content is saved to the object store or Centera device.1. CA DLP can integrate with EMC Centera. see page 185. 1 2 3 3a 3b 4 Centera architecture: Data flow 1.184 CA DLP Deployment guide Integrating with EMC Centera CA DLP can integrate with EMC Corporation's Centera content addressed storage (CAS) solution to ensure longterm content integrity and online access for large volumes of fixed data. This blob file is subsequently moved to the Centera and the CMS database entry for that event is updated to reflect the new location for the blob. Communications with the Centera device use EMC’s proprietary TCP/IP-based API. 4.544 of the Centera API Library to integrate with CentraStar. In this example. To find whether this version of the Centera API Library permits integration with other versions of CentraStar. Centera: As an alternative to a conventional object store. The blob files for captured or imported events are streamlined from the CMS to the Centera device and stored in clips. When a CA DLP event is captured or imported.

Generation 3 . By default. there is little advantage in increasing the clip size to achieve faster Centera storage rates. To contact Technical Support. i The blob file is not deleted immediately. blob files are compressed and encrypted when they are stored on the CMS. when an event is replicated to the CMS from a client machine or gateway. a very fast CMS (for example. How does the Centera integration work? Centera integration with CA DLP is controlled by the CMS. It groups them into clips. This list can build up if the Centera is offline or if the configuration settings are incorrectly optimized for the installation. The database entry on the CMS is subsequently updated to reflect the new location for the blob. Policy settings on the CMS determine the maximum number of blobs and Kbytes per clip—see page 188. It is then copied to Centera and the source blob file deleted from the CMS. Again. However. Tuning these clip settings for optimum performance also depends on network bandwidth. Blob offset and length details are stored in the clip to optimize data retrieval during event searches. however. i Any custom SQL procedure to migrate existing blobs must be carefully designed to ensure that the migration queue is properly managed. If multiple blobs are stored in Centera clips. There is less drop-off in the storage rate for larger Centera clip sizes if you have a Gigabit Ethernet NIC in the CMS. If this is so. Migrating existing blob files to a Centera: There is no inbuilt mechanism for migrating to Centera those blobs that were stored on the CMS before Centera integration was implemented. see page 23. replacing the blob file system location with the Centera content address code. For details on cache management. the blob file is first saved to the object store \Data folder. see page 196. If the Centera is temporarily unavailable: CA DLP maintains a database table containing a list of blobs that need to be stored to Centera. respectively. a multi CPU. it is necessary to understand how CA DLP events are stored on the CMS prior to migration. i CA DLP does not store blob files with differing trigger-defined Minimum Retention Periods (see page 186) in the same Centera clip. They are stored to Centera in the same format.048. you do not need to change these default values. CA DLP blob files are concatenated into a single Centera blob. Blob files are grouped into Centera clips CA DLP does not store each blob as a single Centera object. We recommend that you monitor the size of this database table as a health check. We strongly recommend that you contact Technical Support for guidance if you need to write a migration procedure. referenced from the Centera clip.Chapter 10 Object storage 185 About Centera integration This section summarizes the methods used to integrate CA DLP with Centera. you may need to experiment to find the optimum clip size. It is possible to do this. You will need to write a custom SQL procedure to add a blob queue record for each blob migrated to Centera. First. significantly reducing write times for event data migrated to Centera. so you may want to experiment adjusting the clip size in this situation. If Centera integration is enabled. you need to monitor the size of the blob queue table in the CMS database). enabling CA DLP events to be migrated to Centera. providing the Centera can keep pace with the CMS when storing data (to check this. As a general rule. it is cached in case it is needed again soon. Increasing the clip size The default values for the Maximum Number of blobs per Centera Clip and Maximum Number of KBytes per Centera Clip settings are 1 blob per clip and 1.576_KB (1GB) per Centera clip. In some circumstances the utilization of all the storage capacity on a Centera Node is limited by the maximum number of objects that can be stored. 2GHz machine) will get better Centera performance by putting more than 10MB in a single Centera clip.

if the CMS’s Minimum Retention Period is set to 365 days. manually overwritten by reviewers in the Data Management console or iConsole. Its purpose is solely to determine when events become eligible for purging from the local CA DLP machine. i When the timeout expires. data is not deleted immediately but is instead moved to a secondary folder within the cache and deleted after another elapsed timeout. when retrieving data during an event search. If the Centera blob size is less than the embedded data threshold. mirrored copies. you should ensure that at least 100KB is stored in each clip when using mirrored content protection and at least 500KB when using parity content protection. There is little advantage in enabling single instance storage. the cache is deleted. 100 events will occupy just four Centera objects. Centera blobs contain multiple CA DLP blobs according to the blobs per clip setting. During an event search.186 CA DLP Deployment guide Centera hardware can store 50M objects per node. two CDFs (Clip Definition Files) and two blob files. CA DLP ignores the Centera default retention period. CA DLP only retrieves the relevant portion of the Centera blob needed to rebuild the CA DLP blob. then four Centera objects are stored per clip. which means that only two Centera objects are used. This is the same cache used to retain events retrieved from other third party remote storage locations. CA DLP blob files contain capture timestamps. This count includes all types of Centera object. i The Minimum Retention Period on an Event Import machine (or any CA DLP server) does not determine how long blobs are retained on the Centera. when the timeout expires. making single-instance storage unlikely. CA DLP retrieves the event data from the Centera blob to a regular CA DLP blob that can be accessed by the Data Management console or iConsole. How do the minimum retention periods work? The Minimum Retention Period in the CMS machine policy determines how long events are retained on the local CA DLP machine (though the retention period can be . As a general rule. Also. then an event purge runs daily on the CMS. that is. and parity fragments. for example CDF. if you store 100 CA DLP blobs per clip. and its Event Purge Frequency set to 1 day. blobs. such as an e-mail archive. Retrieved blob files are retained in a temporary cache on the CMS. The cache timeout (see page 195) is controlled by the Remote Data Cache Timeout setting in the CMS machine policy. For example. For example. the Centera blob is stored in the CDF. This means data may persist in the cache for twice as long as specified. storing multiple blobs in a Centera clip or using the Embedded Data Threshold setting (see page 188) will effectively disable single instance storage. Single-instance storage Blob retrieval Blob offset and length details are stored in the Centera clip so that. or by a trigger-specific Minimum Retention Period in the user’s policy. If content is mirrored. deleting events more than one year old from both the CA DLP database and the Centera.

Now you need to configure Centera itself. In the Service Accounts screen. . specify the location of the \Data folder. you need to configure the integration of your Centera device. You do this by specifying settings in the EMC Centera Integration folder of the CMS machine policy. 2 3 4 5 6 7 8 Mandatory Centera policy settings As a minimum. If this setting is blank. The Centera configuration (the number and addresses of access nodes. This setting may also be used to specify additional Centera connection options—see your Centera documentation for details. Click Install to start the file transfer. you need to set the Data File Storage Location and Access Node Addresses settings in the CMS machine policy. By default. The average size of captured or imported events. The relevant policy settings are described below. Specifically. i These settings permit the concurrent use of multiple object stores. leaving the other settings to use their default values. In the Server Type screen. plus details about the local CA DLP database. Enter the addresses (separated by commas) of the Centera Access nodes here. captured data blob files (binary large objects) will not be stored to Centera. In the subsequent screens. Other optional Centera configuration settings are also available—see page 188. This setting controls where captured data files (blobs or Binary Large Objects) are stored. See the next section for details. enter your user name and organization. choose CMS. If you do want to customize the Centera integration by editing the other settings.Chapter 10 Object storage 187 Set up Centera integration You set up Centera integration by running the CA DLP Server Installation Wizard. In the Customer Information screen. and whether the Centera needs access credentials or multi-cluster failover options). the blob file is written to disk and saved in the \Data folder specified when the CMS was installed. After editing these policy settings. specify the logon accounts used by the local CA DLP infrastructure service and other services. See page 183. integration is complete and no further steps are required. 1 To launch the server installation wizard. we recommend that you consult your Centera documentation for guidance. Access Node Addresses Find this setting in the \Data Management\EMC Centera Integration subfolder of the machine policy. As a minimum.exe. The installation wizard now has all the information it needs. The optimum configuration for your organization will depend on: The CMS hardware (memory and processors). Configure Centera integration To ensure that captured data files are migrated to EMC Centera. Set this to ‘EMC Centera’. choose the CMS Storage Connector feature and then the EMC Centera Connector option—see page 31. run setup. you need to set the Data File Storage Location and Access Node Addresses settings (see below). In the Custom Setup screen. you need to set these policy settings: Data File Storage Location Find this setting in the \Data Management subfolder of the machine policy. Find this in the \Server folder on your CA DLP distribution media.

` Calculate Content Address During Write: Content Addresses are calculated on the CMS while streaming data to the Centera device. The maximum value is 100 KBytes. Maximum Number of KBytes per Centera Clip Defaults to 1. This setting controls the method used to calculate the Content Address from blob files. The default value is set to 1 as a precautionary measure. If you implement such a purge script and need to set this value to more than 1. Storing more clips at the same time may result in a faster storage rate. Embedded Data Threshold (KB) Defaults to zero. This is the maximum data size. we recommend that this value is set to 100. It ensures that data belonging to an event cannot be deleted early if a custom purge script is used to purge events based on criteria other than event expiry date. This specifies how long CA DLP waits before storing a clip if there are insufficient blob files to fill it. Possible values are: ` Calculate Content Address Before Write: Content Addresses are calculated on the CMS before data is streamed to the Centera device. This setting limits the number of blob files stored in a Centera clip by ensuring that the total number of KBytes stored in the clip does not exceed the value set here. CA DLP waits for the flush interval to elapse then stores the clip anyway.188 CA DLP Deployment guide Optional Centera policy settings These settings are optional. This is the size of the Centera internal clip buffer in KBytes. Maximum Number of blobs per Centera Clip Defaults to 1.576_KB (1GB). Flush Interval (Seconds) Defaults to 60. ` Calculate Content Address After Write: Content Addresses are calculated on the Centera device itself. This setting defines how many blob files are stored within one Centera clip. Clip Buffer Size (KB) Defaults to 64. Find them in the \Data Management\EMC Centera Integration subfolder of the machine policy. . It specifies the amount of memory to use for temporary storage when sending data to the Centera device. Content Address Calculation Defaults to ‘Calculate Content Address During Write’. i Blobs with different retention periods will not be stored in the same Centera clip. You may want to set this number to match the number of storage nodes in the Centera cluster (if there are more than 10 nodes). for data to be embedded in the Centera clip XML instead of being stored separately. but embedded data does not benefit from single-instance storage. Clip capacity is defined the Maximum Number of blobs per Centera Clip and Maximum Number of KBytes per Centera Clip settings. Embedding data in the clip can improve write performance. The default value of zero KBytes means that data is never embedded in the clip XML. This setting controls the number of Centera clips that can be stored to Centera simultaneously. in KBytes. contact Technical Support for further information.048. If there are not enough blobs to fill the clip according to these settings. If using the standard purge script. Maximum Number of Concurrent Storage Operations Defaults to 10.

see page 195. 3. The Content Manager can be hosted on more than one machine. Content Manager: As an alternative to a conventional object store. . IBM DB2 Content Manager integration is configured through policy settings on the CMS. but it may be compatible with other versions. the database containing metadata runs on a remote server. 4. archiving and retrieval of large volumes of captured data. CA DLP can integrate with IBM DB2 Content Manager. in this example a UNC-specified network file share. Please contact IBM Corporation for more information. 2.Chapter 10 Object storage 189 Integrating with IBM DB2 Content Manager CA DLP can integrate with IBM DB2 Content Manager to allow storage management. it comprises a permanent (3a) and temporary (3b) object store. 1 2 3 3a 3b 4 IBM Content Manager architecture: data flow 1. The integration has been tested with Version 8 Revision 3 of IBM DB2 Content Manager Enterprise Edition. CMS: Event metadata is written to the database (2). Communications with the IBM Content Manager use a proprietary TCP/IP-based scheme. Object store: The object store can be a remote data folder. This blob file is subsequently moved to the IBM Content Manager and the CMS database entry for that event is updated to reflect the new location for the blob. Database server: The CMS can support a local or remote database. When a CA DLP event is captured or imported. we recommend that you set up Content Manager integration as soon as possible after deploying CA DLP. event content is saved to the object store or Content Manager. For this reason. In this example. In both cases. Events captured and replicated to the CMS before the Content Manager integration has been set up will not be migrated. The blob files for captured or imported events are streamed from the CMS to the Content Manager and stored in resource items. The diagram below shows how IBM DB2 Content Manager integrates with CA DLP to work as an alternative object store. Only events captured after integration has been set up will be migrated to the Content Manager. The CMS stores an event record in its database and writes a blob file to its \data subfolder. For full details. i CA DLP is compatible with Version 8 Revision 3 of IBM DB2 Information Integrator for Content. or a network-attached storage (NAS) device. it is replicated to the CMS.

you do not need to change these default values. If this is so. They are stored to Content Manager in the same format. i Any custom SQL procedure to migrate existing blobs must be carefully designed to ensure that the migration queue is properly managed. This list can build up if the Content Manager is offline or if the configuration settings are incorrectly optimized for the installation. If the Content Manager is temporarily unavailable: CA DLP maintains a database table containing a list of blobs that need to be migrated to the Content Manager. it is cached in case it is needed again soon. How does the IBM Content Manager integration work? Content Manager integration with CA DLP is controlled by the CMS. First. the blob file is first saved to the object store \Data folder. however. enabling CA DLP events to be migrated to the Content Manager. We recommend that you monitor the size of this database table as a health check. Migrating existing blob files to a Content Manager: There is no inbuilt mechanism for migrating to Content Manager those blobs that were stored on the CMS before Content Manager integration was implemented. If the integration is enabled. replacing the blob file system location with the Content Manager resource identifier. Blob files are grouped into Content Manager resource items CA DLP does not store each blob as a single Content Manager resource item. By default. It groups them. i The blob file is not deleted immediately. significantly reducing write times for event data migrated to Content Manager. i CA DLP does not store blob files with differing trigger-defined Minimum Retention Periods (see page 191) in the same Content Manager resource item. . Increasing the resource item size The default values for the Maximum Number of blobs per Resource Item and Maximum Number of Bytes per Resource Item settings are 1 and 1GB respectively. Cache management is described on page 196. CA DLP blob files are concatenated into a single item and blob offset and length details are stored with the Content Manager resource ID in the CA DLP database to optimize data retrieval during event searches. it is necessary to understand how CA DLP events are stored on the CMS prior to migration.190 CA DLP Deployment guide About IBM Content Manager integration This section summarizes how CA DLP integrates with IBM DB2 Content Manager. there is little advantage in increasing the settings to achieve faster storage rates. providing the Content Manager can keep pace with the CMS when storing data (to check this. You will need to write a custom SQL procedure to add a blob queue record for each blob to be migrated. We strongly recommend that you contact Technical Support for guidance if you need to write a migration procedure. blob files are compressed and encrypted when they are stored on the CMS. If multiple blobs are stored in Content Manager resource items. To contact Technical Support. when an event is replicated to the CMS from a client machine or gateway. you need to monitor the size of the blob queue table in the CMS database). As a general rule. Policy settings on the CMS determine the maximum number of blobs and bytes per resource item— see page 190. It is possible to do this. see page 23. It is then copied to the Content Manager and the source blob file deleted from the CMS. The database entry on the CMS is subsequently updated to reflect the new location for the blob.

the cache is deleted. run setup. Find this in the \Server folder on your CA DLP distribution media. and its Event Purge Frequency set to 1 day. In the Custom Setup screen. or by a trigger-specific Minimum Retention Period in the user’s policy. i When the timeout expires. Click Install to start the file transfer. The installation wizard now has all the information it needs.Chapter 10 Object storage 191 Blob retrieval Blob offset and length details are stored in the CA DLP database so that. In the subsequent screens. choose the CMS Storage Connector feature and then the IBM Content Manager Connector option—see page 31. Run the server installation wizard. During an event search. For example. The cache timeout is controlled by the Remote Data Cache Timeout setting in the CMS machine policy. CA DLP only retrieves the relevant portion of the resource item needed to rebuild the CA DLP blob. enter your user name and organization. choose CMS. data is not deleted immediately but is instead moved to a secondary folder within the cache and deleted after another elapsed timeout. Set up IBM DB2 Content Manager integration The following steps describe how to integrate CA DLP with IBM DB2 Content Manager. when retrieving data during an event search. then an event purge runs daily on the CMS. deleting events more than one year old from both the CA DLP database and the Content Manager. specify the location of the \Data folder. 2 3 4 5 6 How do the minimum retention periods work? The Minimum Retention Period in the CMS machine policy determines how long events are retained on the local CA DLP machine (though the retention period can be manually overwritten by reviewers in the Data Management console or iConsole. such as an e-mail archive.exe. if the CMS’s Minimum Retention Period is set to 365 days. Its purpose is solely to determine when events become eligible for purging from the local CA DLP machine. 7 8 . This is the same cache used to retain events retrieved from other third party remote storage locations. CA DLP retrieves the event data from the resource item to a regular CA DLP blob that can be accessed by the Data Management console or iConsole. This means data may persist in the cache for twice as long as specified. Retrieved blob files are retained in a temporary cache (see page 195) on the CMS. In the Customer Information screen. In the Service Accounts screen. plus details about the local CA DLP database. 1 Install IBM DB2 Information Integrator for Content on the CMS. specify the logon accounts used by the local CA DLP infrastructure service and other services. In the Server Type screen. i The Minimum Retention Period on an Event Import machine (or any CA DLP server) does not determine how long blobs are retained on the Content Manager. when the timeout expires.

i You can use this setting to configure the concurrent use of multiple object stores. The default resource manager is automatically set up when Content Manager 8. By default. Set it to ‘IBM DB2 Content Manager’.1 on port number 56200 if the WgnIBMCM. i The IBM DB2 Information Integrator for Content component must be installed on the machine which hosts WgnIBMCM. Storing more items at the same time may result in a faster storage rate.0.exe service is installed on the CMS. Content Manager Connection Options This setting controls additional Content Manager connection options and should not normally be necessary. You do this by specifying settings in the CMS machine policy.192 CA DLP Deployment guide Configure Content Manager integration To ensure that captured data files are migrated to IBM Content Manager. icmnlsdb. Content Manager Database Name This mandatory setting must be set to the name of the IBM Content Manager database. which is set up by the CA DLP Content Manager Integration when it starts for the first time. Content Manager Password This mandatory setting must be set to the password of the Content Manager user permitted to read and write Resource Items. Maximum Number of Concurrent Storage Operations Defaults to 10. set that machine’s name or IP address here. Content Manager Interface Service Host Address This is the TCP connection information used to locate the service provided by WgnIBMCM. Content Manager Resource Database Name Defaults to rmdb. for example. Resources are stored as items of type S_wgnblob. find these settings in the \Data Management\IBM Content Manager Integration subfolder of the machine policy. This setting controls the number of resource items that can be stored to the Content Manager simultaneously. the CA DLP IBM Content Manager Interface Service). Find it in the \Data Management\ subfolder of the machine policy. Data File Storage Location This setting is mandatory.exe. you need to configure the integration. Content Manager integration policy settings Unless stated otherwise. This sets the name of the resource manager used to store the CA DLP resource items. Content Manager User Name This mandatory setting must be set to the user name of the IBM Content Manager user permitted to read and write Resource Items.exe (that is. The setting may be left at the default of 127. Content Manager Interface Service Port Number This setting along with the Content Manager Interface Service Host Address is the TCP connection information used to locate the CA DLP Content Manager Interface Service. Refer to your IBM DB2 Content Manager documentation for more information.0. the blob file is written to disk and saved in the \Data folder specified when the CMS was installed. See page 183. If the service needs to be installed on another machine.3 is installed. . This setting controls where captured data files (Binary Large Objects) are stored.

.576_KB (1GB). The default value is set to 1 as a precautionary measure. If you implement such a purge script and need to set this value to more than 1. i CA DLP blobs with different retention periods will not be stored in the same IBM Content Manager blob file. This setting defines how many CA DLP blob files are stored within one IBM Content Manager blob file. the file is located in CA's \data\log subfolder of the Windows All Users profile. you can configure the IBM Content Manager to only log errors or important system messages. plus informational and status messages i Setting LogLevel=3 will cause the log file to grow extremely rapidly. CA DLP waits for the flush interval to elapse then stores the resource item anyway. it shows storage and retrieval on every resource item. you need to modify a value in the following registry key: HKEY_LOCAL_MACHINE\Software \ComputerAssociates\CA DLP \CurrentVersion\IBM CM Interface Within this registry key. The supported logging levels are: 1 Errors only 2 Errors and warnings 3 Errors and warnings.Chapter 10 Object storage 193 Maximum Number of BLOBs per Resource Item Defaults to 1. For example. Log entries are written to the WgnIBMCM_<date>. Flush Interval (Seconds) Defaults to 60. where <date> is the date and time when the log file was created. It ensures that data belonging to an event cannot be deleted early if a custom purge script is used to purge events based on criteria other than event expiry date. see page 499. Resource item capacity is defined by the Maximum Number of BLOBs per Resource Item and Maximum Number of KBytes per Resource Item settings. This specifies how long CA DLP waits before storing a resource item if there are insufficient blob files to fill it.048. contact Technical Support for further information.log file. Maximum Number of KBytes per Resource Item Defaults to 1. If there are not enough blobs to fill the resource item according to these settings. This setting determines the level of logging for storage management. This level of logging is provided for testing and diagnostic purposes. we recommend that this value is set to 100. This setting limits the number of CA DLP blob files stored in an IBM Content Manager blob by ensuring that the total number of bytes stored in the blob does not exceed the value set here. for example. If using the standard purge script. IBM Content Manager logging To configure the level of logging used by the IBM Content Manager. edit the following value: LogLevel Type: REG_DWORD Data: Defaults to 2.

in the Data Location wizard screen (see step 6 on page 33). . This setting controls where captured data files (blobs or Binary Large Objects) are stored. Mandatory SnapLock policy setting Locate the following setting in the CMS machine policy: Data File Storage Location Find this setting in the \Data Management policy folder and set it to ‘NetApp SnapLock’. For SnapLock integration. 1 You must specify the location of the SnapLock volume when you install the CMS. These blobs contain the e-mail content and any attachments. See chapter 2. To do this.194 CA DLP Deployment guide Integrating with NetApp SnapLock CA DLP supports NetApp SnapLock volumes when NetApp is running Data ONTAP version 7. Integration with CA DLP is simple to set up. The CMS stores an event record in its database and writes a blob file to the specified SnapLock volume. the file’s ‘Last Accessed’ date is set to the event’s expiry date (that is. SnapLock integration is configured through a single policy setting on the CMS. while SnapLock volumes provide high performance and high security data permanence. 3 You now need to configure the CMS to write the minimum retention period (also known as the ‘expiry date’) for each event to the SnapLock volume. Data ONTAP is a unified storage software platform that dramatically simplifies data management. Events captured and replicated to the CMS before SnapLock integration has been set up will not. For this reason. we recommend that you set up SnapLock integration as soon as possible after deploying CA DLP. In addition. CA DLP automatically writes blob (Binary Large Object) files to the storage location specified in step 1. you specify either a UNC path or mapped drive to the target SnapLock volume. you edit the CMS machine policy—see the next section. and enabled through a single machine policy setting. blob files are written to the target SnapLock volume specified in step 1 above. for installation instructions. 2 After installing the CMS. when the event’s minimum retention period expires and the event becomes eligible for purging). stored in CA DLP format. When a CA DLP event is captured or imported. Only events captured after integration has been enabled will have their retention periods set on the NetApp SnapLock volume. But unlike a conventional CMS installation. CA DLP servers. it is replicated to the CMS. or the Web page plus any uploaded files.0 or later. This setting determines the data file storage location. Set up SnapLock integration The following steps describe how to integrate CA DLP with a NetApp SnapLock volume.

How are CA DLP events stored? Each CA DLP event comprises metadata. Configure the temporary object store Using settings in the CMS policy. data is not deleted immediately but is instead moved to a secondary folder within the cache and deleted after another elapsed timeout. This means data may persist in the cache for twice as long as specified. and the associated blob is cached in the temporary object store. After this period. 'envelope' details. what policy triggers were applied. . Retrieving events: When running a search to retrieve events archived in third party remote storage locations and display them in the Data Management console. and a blob file (binary large object). For details. we recommend that you set the Remote Data Cache Timeout to synchronize with the purge frequency to avoid blob files remaining on the CMS afterwards. After the configurable timeout (see below). you can configure how long events remain in the temporary object store and how long the RDM waits for a response from the CMS when attempting to retrieve events. database fields specify an e-mail’s delivery date. an error message is shown if the Data Management console is unable to display an archived e-mail because this timeout has expired. i To change this data location. the event metadata is written to the CMS database as normal. The default timeout is 1440 minutes. see page 197. the associated blob files remain in the temporary object store for a configurable length of time (see opposite page). CA DLP displays a error message. see the Administrator guide. To configure the temporary object store. the cache is deleted. for the following tasks: Imported events: When importing archived e-mails into the CA DLP system.Chapter 10 Object storage 195 Temporary object store The temporary object store is an event cache. stored in CA DLP format. The minimum timeout is 1 minute. Content Indexer: When performing a content search for Content Services. This allows fast event retrieval during event searches and content searches during the period immediately following the import operation. i The timeout represents a minimum retention period. i If you intend to schedule regular purges. the associated blob is moved to the temporary object store (see page 183). the associated blob files remain in the temporary object store for a configurable length of time (see opposite page). If this timeout expires before the RDM can retrieve an event. or the IBM DB2 Content Manager. and so on. or iConsole. use the following settings in the Infrastructure\Data Management folder in the CMS machine policy: Remote Data Cache Timeout (Minutes) Specify how long (in minutes) data retrieved from the Remote Data Manager (RDM) server is retained in a temporary local cache. saved on physical media: A database entry contains the event metadata. Any subsequent searches for these events must use the Remote Data Manager (see page 388). When the timeout expires. A blob file contains the e-mail content and any attachments. You may need to increase the default timeout for newly deployed CA DLP installations if you are using the Content Indexer to index large volumes of captured data. Remote Data Request Timeout (Seconds) Specify how long (in seconds) the CMS will wait for a response from the Remote Data Manager (RDM) server. the maximum timeout is 525600 minutes (365 days). blobs in the temporary objects store are deleted. For example. written to the local CA DLP database. used when CA DLP is integrated with third party e-mail archive solutions. The blob file is written to disk and saved in the \Data folder or migrated to EMC Centera. For example. This means the cache is deleted every 24 hours. After the CMS receives confirmation that the event has been successfully imported.

There is no wgninfra -exec command to clear a cache folder. 1 and 2. and no log file entries are written when a cache folder is cleared.196 CA DLP Deployment guide Managing the temporary object store If the disk or network share holding the cache becomes full. each folder cycles through to the next role in this sequence: Current cache Previous cache Deleted cache When the infrastructure restarts. i There is no mechanism to automatically delete items from the cache in this situation. we recommend that you reduce the cache timeout period. Blob added to cache Starting role Folder 0 Folder 1 Folder 2 Current cache Previous cache Deleted cache If the size of the cache is getting larger than anticipated. They are recreated automatically as required. the cache contents and cache timeout schedule is persisted securely in the database. When the cache timeout expires. 1st timeout expires Role changes to: Previous cache Deleted cache Current cache 2nd timeout expires Role changes to: Deleted cache Current cache Previous cache 3rd timeout expires Role changes to: Current cache Previous cache Deleted cache . the CMS infrastructure is automatically suspended (machine policy settings determine the critical levels of free disk space). You can also manually delete the cache folders if necessary.properties file. The cache is split into three folders: 0.

Find this file in the \system subfolder of the CA DLP installation folder. To do this: 1 Stop the 'CA DLP infrastructure' service. you must edit the startup.BlobLocation=C:\\Dec 07\\blobfiles i You need to prefix any backslash characters in the path with a backslash to ensure they are interpreted correctly. log: This stores log files. cache: This stores event log files.1 To specify a new location for database cache files. enabling you to separate database event cache files from system blob files. startup. add the following parameter: db.1 To specify a new location for system blob files. e: This stores database event blob files. For example.properties files (for example. From a command prompt.properties) and *. s: This stores system blob files.kdt data blob encryption keys. 3 Open this file and add the following line(s) to the [Database] section: 3. add the following parameter: db. You can specify a new location for both the \e and \cache folders. move the \e and \cache folders to their new locations. as logging can potentially fail if the drive becomes inaccessible. policy files and other system files. Within this folder are the following subfolders: data log e s log cache Data folder structure Data: This is the database blob location and contains *. run: net start wgninfra . run: net stop wgninfra 2 Edit the startup.Chapter 10 Object storage 197 Optional data location structure The CMS stores event blob files in CA's \data\log subfolder of the Windows All Users profile.CacheLocation=C:\\Dec 07\\cachefiles 3. To change the location of specific subfolders within the \data folder. 4 While the Infrastructure is still stopped.properties file. 5 Restart the CA DLP infrastructure service. This can be useful if the \data folder is on a remote drive. From a command prompt. see the .properties file.

198 CA DLP Deployment guide .

chapter 11 T FSA: The File Scanning Agent (FSA) can scan and analyze files saved in remote file systems and apply appropriate controls. E-mails and files are allocated to individual policy engines by a policy engine hub. apply policy to any files stored on their network. Import Policy provides organizations with a full compliance review capability that is not dependent on a preventative pre-review strategy for filtering e-mail communications at source. in order to apply policy to e-mails or files. ` For e-mails. It explains how and why policy engines are used. Policy engines enable CA DLP to integrate directly with: Exchange Server or Lotus Domino: The Exchange and Domino server agents allow CA DLP to monitor and control corporate e-mail activity that would otherwise be missed by Outlook and Notes client integration alone. In particular. See page 321. Third party archive solutions: Policy engines receive e-mails from an archive agent and apply smart tags (typically an e-mail category and a retention date) before the e-mails are archived. organizations can categorize or apply smart tags to important business documents or reports. For details. configuring and monitoring policy engines. . Import Policy enables organizations to Overview Policy engines can process e-mails or files arriving from an external source and apply capture and control triggers to these e-mails where necessary.11. This chapter also provides full instructions for installing. See page 275. Event Import: Policy engines can also be connected to Event Import as part of an Import Policy job. see page 227. See page 235. For example. ` For files. it describes how policy engines play a critical role when integrating CA DLP with third party e-mail and archiving solutions. Policy engines Policy engines his chapter introduces CA DLP policy engines.

The policy engine then analyzes the e-mail and applies policy triggers as necessary. In particular.200 CA DLP Deployment guide Policy engine architecture E-mails are allocated to individual policy engines by the policy engine hub. it allocates the e-mail to the least heavily loaded policy engine (that is. 2 E-mail interception. It can also handle hardware failures on remote policy engine machines seamlessly. whether sent from internal machines (2a) or external machines (2b). are detected by the e-mail server agent and passed to the policy engine hub. 3 Policy engines. the policy engine that can process the new e-mail most quickly). E-mails transiting through the server. Each policy engine replicates processed e-mails up to the CMS. redistributing events to other policy engines if necessary. When the policy engine hub receives a new e-mail from the e-mail server agent. 4 CMS. . 1 E-mail server. CA DLP can integrate with Microsoft Exchange or Lotus Domino (1a). The hub and policy engines are designed to handle each e-mail with minimal delay. The policy engine hub creates connections between the e-mail server agent and each policy engine host machine and also maintains performance and event processing statistics for each host machine. This server also hosts the CA DLP Exchange server agent or Domino server agent (1b) and policy engine hub (1c). 2a 2a 2b Internet 1 1a 1b 1c 3 Policy Engines 4 CMS Policy engines and e-mail server integration This example shows how policy engines can be used to integrate CA DLP with an e-mail server. the hub distributes processing across multiple policy machines in a manner that achieves optimum load-balancing and maximizes throughput.

2 Hub deployment is described in chapter 12. you must first set up the necessary user accounts. you need to configure the policy engine hub. 2 Deploy policy engine hub 3 Set up the event source Policy engine deployment procedure 1 These policy engine deployment tasks are described in this chapter. To set up ‘Active’ and ‘Standby’ policy engines. You can then install as many policy engines as you need. the hub only allocates e-mails to active policy engines. The diagram below summarizes the key deployment tasks: Active and standby policy engines When you configure the hub. it needs to map the sender’s e-mail address to a CA DLP user.Chapter 11 Policy engines 201 Deploy policy engines Deploying policy engines is the first step in the overall task of integrating CA DLP with third party e-mail or archiving solutions (Exchange. 1 Deploy policy engines Specify user accounts Install policy engines Configure local machine policy Configure registry values for user lookup operations E-mail address mapping Before a policy engine can apply policy triggers to an intercepted e-mail. During normal operations. This allows you to ensure that CA DLP continues monitoring and processing e-mails even during a contingency. . This mapping identifies the email owner and determines which policy to apply. You may also need to edit the registry on host machines to enable user lookup operations. you can designate individual policy engines as either ‘Active’ or ‘Standby’. Specifically. ‘Mapping e-mail addresses to users’. You must then edit the machine policy on the host machines. or Event Import—see page 199. you need to edit the ActivePolicyEngines and StandbyPolicyEngines registry values on the hub host machine. you may want to install active policy engines in your main office and standby policy engines off-site. For example. see page 487 for details. 3 The event source can be a e-mail or archive server agent. Domino or Enterprise Vault) or when setting up the Import Policy feature. The mapping method is described in chapter 22. See page 222 for details. When deploying policy engines. but if one or more active policy engines become unavailable it can automatically transfer processing to standby policy engines.

the total number of effective user policies is usually far smaller than the total number of users. When processing an e-mail. the policy for the top level ‘Users’ group. their effective policy is either their own individual policy (if it has been uniquely customized) or the policy inherited from their parent group. most groups) inherit their policy. from their parent group. it can retain multiple user policies in memory. to minimize processing delays. the local machine policy specifies the maximum number of policies that can be held in memory at one time. . direct and unchanged. then in effect all users are governed by the same policy. Because most CA DLP users (and indeed. a policy engine requires access to the sender’s user policy. For example. we recommend a gateway. policy engines can also run on a CA DLP standalone installation. i For evaluation purposes. For best performance. for your entire organization there is only one effective policy. In practice. Confirm this is so before installing the policy engine. Host machine memory ! We strongly recommend that the host machine has enough memory to cache all effective user policies for your organization simultaneously. For each user. direct and unchanged. Nevertheless. See page 205 for details. Host machine must be a gateway or CMS You must install a policy engine on a CA DLP server. Operating system See page 26 for supported operating systems. to prevent excessive memory allocation. this means the host machine must be able to simultaneously hold all the ‘effective’ user policies for your organization. you must ensure that the host machine has sufficient memory to simultaneously retain all the user policies that is likely to need.202 CA DLP Deployment guide Policy engine requirements PE domain user must be local administrator The PE domain user (see page 203) must belong to the local Administrators group on the policy engine host machine. Because each policy can take up a significant amount of memory. That is. The policy engine retrieves the necessary policy from the CMS and. if all users and subgroups in your organization inherit.

Chapter 11 Policy engines 203 Specify user accounts Before you can deploy your policy engines. This permits the new user account to access multiple CA DLP user accounts. The policy engines will use this CA DLP account to log on to the CMS when mapping e-mail addresses onto CA DLP users. you must create a matching CA DLP user account. assign the 'Events: Allow bulk session management' administrative privilege to this CA DLP user. the new CA DLP user must have the same account name as the PE domain user. or choose an existing domain user. 2 Still in the Administration console. .exe) must run as a domain user who can access the host machine running the policy engine hub. Specifically. you must include the domain prefix to ensure compatibility with the account name for the PE domain user (for example. That is. 1 In the CA DLP Administration console. step 6. the term ‘PE domain user’ refers to the domain user you are using to pilot your policy engines and the policy engine hub. the policy engine hub uses this same domain user to access the remote policy engine machines. you must specify a Windows domain user that allows the policy engines and hub to communicate. Likewise. This is your ‘PE domain user’. on page 204. Specify a PE domain user Your policy engines must be able to access the policy engine hub. When you specify the user name. UNIPRAXIS\PolicyEngineUser). This requirement is restated where appropriate in the following sections. Therefore. Throughout this chapter. search the index for ‘new accounts’. create a new user. you must either create a new domain user in Active Directory. i This new user account does not need a management group or any other administrative privileges. you will also need to modify the logon properties of this PE domain user on the policy engine host machine—see ‘Install policy engines’. The PE domain user must also be a member of the local Administrators group on the policy engine hub and all policy engines. the policy engine service (wgnpesv. See the Administration console online help for details about creating new users. You must also create a new CA DLP user account: Create a corresponding CA DLP user After specifying your PE domain user. i When you deploy your policy engines.

choose the Policy Engine and also choose whether to install the Socket API—see page 31. including from a non-Windows system.exe. In the subsequent screens. In the Customer Information screen. In the Custom Setup screen. run setup. 4 5 In the Server Type screen. When the installation is complete.0. For example the CA DLP Network Boundary Agent uses the Socket API to analyze traffic leaving or entering the corporate network from the internet. the location of the \Data folder. name and password of the PE domain user (see page 203). upgrading from CA DLP 3. 6 In the Service Accounts screen. 8 i Note the following: ` To uninstall a policy engine. 1 To launch the server installation wizard. Click Install to start the file transfer. specify the logon accounts used by the local CA DLP infrastructure service and the policy engine service. see page 374. plus details about the local CA DLP database. Using socket connections enables you to call the External Agent API from a remote location. Now you must manually configure the local machine policy—see the next section. enter your user name and organization. then enter the domain. i The PE domain user must belong to the local Administrators group—see page 202.204 CA DLP Deployment guide Install policy engines You install policy engines using the CA DLP server installation wizard. Click the Browse button for the Policy Engine service. The policy engine service must run as the PE domain user. choose Gateway . 2 3 7 The installation wizard now has all the information it needs. . the CA DLP Policy Engine service starts automatically. But note the host machine requirements on page 202. see page 210. For details on the Socket API. specify the parent server (typically the CMS). see the ` When known issue on page 540. The Socket API is automatically set up to listen on port number 8538. Find this in the \Server folder on your CA DLP distribution media.

such policy swaps can significantly slow the processing for an individual e-mail. For example. You need to modify these settings in the Policy Engine folder of the local machine policy: Policy setting Maximum Number of Loaded Policies Maximum Number of Concurrent Operations Page 205 205 Maximum Number of Concurrent Operations Defaults to 5. . it discards the least recently used policy before loading the new policy. This means that when an e-mail completes processing. so maintaining the number of e-mails at the maximum limit. If this maximum limit is reached. However. the policy engine delays accepting any further e-mails from the policy engine hub until the number of e-mails being processed falls below this maximum limit. In fact. You do not normally need to change the default value. we recommend that the host machine can hold all Perform LDAP directory lookups? * Embedded Message Identification Retention Period for Unused Policies Deadlock Detection Timeout Retention Period for Unused Policies Unknown Internal Sender External Sender Internal E-mail Address Pattern Default Policy for Files 206 206 206 206 206 206 206 207 207 the effective policies for your organization simultaneously. if five e-mails finish processing simultaneously. you need to edit both the registry values on the policy engine host machine and also the local machine policy. you may want to increase the maximum limit if the policy engine is running on a multiprocessor computer. Maximum Number of Loaded Policies Defaults to zero. see page 202. This setting defines the maximum number of e-mails that can be processed simultaneously by a policy engine. we strongly recommend that your policy engine host machine has sufficient memory so that you do not need to limit number of loaded policies. For details. For this reason. you edit the machine policy for the host machine. A zero value means an unlimited number of policies can be retained in memory. Note that if the policy engine is already holding its maximum number of policies when it needs to load a new policy (in order to process an e-mail from a sender whose policy is not already cached).Chapter 11 Policy engines 205 Configure policy engines To configure your policy engines. you need to configure some policy engine performance parameters and settings to determine how the policy engine applies policy to e-mails from unrecognized senders and to files when no other means are available to determine the policy participant. However. To do this. It enables the policy engine to make the most efficient use of system resources. another is accepted. Configure the local machine policy Before installing the policy engine and starting the service. the policy engine immediately accepts five new e-mails. this setting can prevent excessive memory usage. Because each policy requires a significant amount of memory. This setting defines the maximum number of user policies that the policy engine can hold in its memory at one time.

the policy is unloaded. For example. not a group account. Restart the policy engine for the changes to take effect. not a group account. That is. It defaults to UnknownInternalSender. The policy engine applies the Unknown Internal Sender’s policy if the sender’s address matches an address pattern listed in the Internal E-mail Address Pattern setting (see page 207) but no corresponding user exists. Bloomberg messages or other communications such as eFaxes).206 CA DLP Deployment guide Perform LDAP directory lookups? This setting is provided for diagnostic purposes only. It specifies whether the policy engine can retrieve e-mail address details and distribution list members from an LDAP directory. EML e-mails containing embedded IM conversations. this user account is created automatically when you install a new CMS— see page 38. It defaults to ExternalSender. the amount of time a policy engine retains a policy that has not been used. Policy engines use this setting to apply policy to external e-mails. this can happen if a new recruit has an account in Active Directory but no CA DLP account has been created for them yet. this setting can also be used to extract or set the IM network. this user account is created automatically when you install a new CMS—see page 38. ! You can specify a different account if necessary. the policy engine monitors all processing threads. Policy engines use this setting to apply policy to e-mails sent from someone within your organization. or ‘eFax’. The policy engine applies the External Sender’s policy if the sender’s address does not match an address pattern listed in the Internal E-mail Address Pattern setting (see page 207). ` Embedded Bloomberg messages in EML e-mails generated by BB2email. If it detects a deadlock. This setting enables policy engines to detect embedded content e-mails and set the event type as ‘embedded IM’. It specifies how long a thread must be inactive while processing an event before the policy engine considers the thread to have stalled. . but this setting must identify a user account. For IM conversations. you need to add additional values to this policy setting. That is. see page 467.exe utility. We strongly recommend that you do not change this setting! Retention Period for Unused Policies Defaults to 7 (days). External Sender This setting specifies the name of a CA DLP user. Restart the policy engine for the changes to take effect. e-mails sent from someone outside your organization. This setting defines the frequency of policy time-outs. After this period of time. Deadlock Detection Timeout Defaults to one hour. However. ‘Bloomberg’. This setting is designed to maintain processing capacity. This is accomplished through the Embedded Message Identification policy setting. it creates a new thread for each stalled thread. ` Embedded IM conversations in EML e-mails generated by the Cnv2email. ! You can specify a different account if necessary. but this setting must identify a user account.exe. Unknown Internal Sender Embedded Message Identification Policy engines need to distinguish between ‘genuine’ e-mails and ‘embedded content’ e-mails (that is. The default values for this setting enable policy engines to automatically detect: This setting specifies the name of a CA DLP user. To guard against any problems that might cause a policy engine to take an excessively long time to analyze an event. if you want policy engines to detect other forms of embedded content (such as eFaxes or IM conversations embedded in EML files that were generated by third party applications). For details.

i This setting was formerly the policy engine hub registry value UserSpecificAddrPattern. The policy engine only expands the sender’s e-mail address against the LDAP directory if it matches an address pattern in this list. ` Either the policy engine applies the External Sender policy (see page 206). it applies no policy. captured or imported files if no other means are available to determine the policy participant. ! You must restart the policy engine for changes to this setting to take effect. Exchange and SMTP addresses. Specifically. it applies no outgoing e-mail triggers. For example. If an address does match listed patterns but no matching CA DLP user exists If the sender does match an address pattern but no corresponding CA DLP user exists: ` Either the policy engine applies the Unknown Internal Sender policy (see page 206). ‘unipr*. you use this setting to detect e-mails sent by users within your organization. if the Unknown Internal Sender setting is not defined. if an Import Policy job for FSA scanning job omit to specify the policy participant. it applies no policy. you must enclose it in "double quotes".com’. Typically. for example. ` Or. it applies no outgoing e-mail triggers. When the policy engine processes an e-mail. the policy engine infers the sender is not a CA DLP user and: Default Policy for Files This setting specifies the name of a CA DLP user. ` Or. If an address does not match listed patterns If the sender does not match any of the listed address patterns. it first checks the sender’s e-mail address against these address patterns. you must ensure that the list is comprehensive enough to match against all addresses you expect to encounter. the policy engine applies the Default Policy for Files to the imported or scanned files. the policy engine attempts to map the sender onto an existing CA DLP user account. Special characters Address patterns can contain: ` Wildcards: Use * wildcards to match partially against e-mail addresses. If the sender’s address does match an internal address pattern. if you want to expand recipients’ full details (for example. ` Double quotes or semi-colons: If an address pattern contains a double quote or semi-colon. Specifically. for policy testing). it applies any relevant triggers for outgoing e-mails. The recipient details of an e-mail are only expanded against the LDAP directory if the recipient’s address matches an item in this list. Address Book (MAPI) lookup operations are only performed for recipient e-mail addresses matching an item in this list. Therefore. A policy engine will apply this user's policy to scanned. ` Spaces: If an address pattern contains spaces. you must prefix these characters with a forward slash: /" or /. For example.Chapter 11 Policy engines 207 Internal E-mail Address Pattern This setting specifies a semi-colon separated list of full or partial e-mail addresses. if the External Sender setting is not defined. .com’ and ‘unipraxis’ would both match against ‘lsteel@unipraxis. That is. or if the specified user account does not exist. it applies any relevant triggers for outgoing e-mails. That is.

Although anonymous access (not supplying a username and/or password) may conflict allow some attributes to be accessed. the policy engine needs to connect to an organization’s LDAP directory service. If the LDAP port number is not 389. the password is MyPassword. the registry values that you may need to add are: Registry values LookupLDAPServers LookupSearchFilter LookupDirectoryType LookupDirectoryBase Page 208 209 209 209 cn=Spencer Rimmel:MyPassword@unipraxis Where the username is Spencer Rimmel. the username must be the distinguished name of a user with read access to the relevant parts of the directory. You can also prefix the server name with the account credentials used to access the LDAP database. The syntax is: <username>:<password>@<server name> i When connecting to a non-Microsoft LDAP server (for example Domino). other attributes may be restricted and only accessible if you provide credentials. prefix the port number with a colon (UNI-EXCH:319). you can leave this registry value unspecified. These values enable the policy engine to apply the correct user policies when processing an e-mail addressed to a distribution list or an alias e-mail address. For example: User Process registry key Within the specified registry key. you can add it after the server name. If the policy engine is running in a domain. Server names can be ‘plain’ or include a domain suffix (UNI-EXCH or UNI-EXCH.208 CA DLP Deployment guide Configure the policy engine registry values After configuring the local machine policy. To perform such lookup operations. you modify values in the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\UserProcess LookupLDAPServers LookupLDAPServers Type: REG_MULTI_SZ Data: Specifies a list of servers hosting an LDAP directory. typically Active Directory. you may need to add registry values on the policy engine host machine.COM). . To configure access to an LDAP directory. the policy engine will automatically detect an Active Directory server. By default.UNIPRAXIS. and the server name is unipraxis. Specifying multiple host servers provides fault-tolerance and load-sharing to ensure that the policy engine processes events as quickly as possible.

If necessary. the value defaults to GC. for example. you can set this value to a specific base DN. Policy engines can automatically detect Active Directory. it defaults to LDAP. indicating that the policy engine searches the whole directory for objects. you can override these defaults. set this value to NDS for NetWare NDS or NWCOMPAT for NetWare 3. Policy engines can automatically detect Active Directory. in this case. For example.x. in this case. ensure that the new filter conforms to RFC 2254.Chapter 11 Policy engines 209 LookupSearchFilter LookupSearchFilter Type: REG_SZ Data: If necessary. the value defaults to: (|(objectCategory=group)(objectCategory=person)) For other LDAP directories. However. For other LDAP directories (including Lotus Domino). you can specify that lookup operations are filtered against specific LDAP containers or nodes. it defaults to: (objectClass=*) If you override the default filter. LookupDirectoryBase LookupDirectoryBase Type: REG_SZ Data: Specifies the LDAP server’s base DN or domain. set this registry value to the root domain of your organization. This value defaults to empty. for example: "o=unipraxis" . LookupDirectoryType LookupDirectoryType Type: REG_SZ Data: Specifies the type of LDAP directory. For Domino. to speed up lookup operations or because the account used to access the LDAP directory only has permission to search a specific subset of the directory.

the following performance object is available: DLP Policy Engine Available only as a single instance. Domino. Remove the name or IP address of the machine hosting the policy engine you want to shut down. edit the ActivePolicyEngines and StandbyPolicyEngines registry values on the hub host server. see pages 226 and 255 respectively. plus the number of policy engine instances and unique policies currently loaded. this removes all CA DLP components. items that have been successfully processed. Uninstall policy engines ! If a policy engine is installed on the same computer as a CA DLP server agent (Exchange. These are performance counters. items that have been successfully processed. available counters show the number of pending items (events waiting to be processed by all policy engines). This applet is part of the Control Panel. Log files Policy engines themselves do not generate log entries. 2 3 i Any events currently being processed are failed and logged accordingly. see page 222. To do this: 1 Locate the ActivePolicyEngines registry value on the policy engine hub. For example. 1 First. To do this. see page 225. . Shut down the policy engine. Stop the CA DLP Policy Engine service. For details on policy engine hub and e-mail server agent log entries. log files and diagnostic files. This performance object contains counters for the local policy engine. you must unregister the policy engine on the hub. Policy engine maintenance If you need to shut down a policy engine (for example. i For policy engine hub performance counters. Other counters relate to average processing rates per e-mail. i If you choose Remove in the Program Maintenance screen. For example. not just the policy engine. and failed items. For policy engines. go to the Program Maintenance screen and choose Modify to uninstall the policy engine. you must uninstall the server agent before uninstalling the policy engine. Either use the Services applet or run the following command from a command line: net stop wgnpesv 2 3 DLP Policy Engine Processing Core This performance object contains counters for the processes carried out by all policy engines. When the wizard starts.210 CA DLP Deployment guide Monitor policy engines There are various sources of diagnostic information when monitoring policy engines. Performance counters In the Performance applet (see page 225). you can add a range of useful performance objects. we recommend you first unregister it on the policy engine hub to avoid logging any unnecessary error messages. to carry out maintenance work). and failed items. or Enterprise Vault). Use Add/Remove Programs to manually uninstall a policy engine. For details. available counters show the number of pending items (events waiting to be processed by the policy engine).

details about integration with Enterprise Vault. seamlessly redistributing events to other policy engines if necessary. Policy engine hub deployment summary 1 Event sources. It also describes how the hub is installed in conjunction with an event source (that is. The hub distributes e-mails to individual policy engine (3) for processing. and also from Event Import. ` Exchange ` For and Domino server agents are covered in chapter 14 (see page 235). see page 329. This chapter shows how the hub uses multiple event queues to optimize e-mail processing. see chapter 11 (page 199). The hub is designed to handle each e-mail with minimal delay. Policy engine hubs Policy engine hubs his chapter introduces CA DLP policy engine hubs. including CA DLP Event Import (1a) and e-mail and archive server agents (1b) forward e-mails to the policy engine hub (2). Domino and Enterprise Vault). It can distribute e-mail processing across multiple remote policy machines in a manner that achieves optimum load-balancing and maximizes throughput. an e-mail or archive server agent or Event Import) and provides instructions for configuring the hub registry values and monitoring hub activity. Policy engine hubs can accept e-mails from e-mail and archive server agents (Exchange.12. . It can also handle hardware failures on remote policy engine machines. The resulting events are replicated up to the CMS (4). The role of the hub is to allocate e-mails to individual policy engines. i Note the following: chapter 12 T 1a 1b Event sources 2 Policy engine hub 3 Policy engines 4 CMS ` For details on installing and configuring policy engines.

with each queue serving multiple policy engines. The hub then assigns each e-mail to an event queue (4). Registry settings on the hub 2a host server define the queue size bands and specify which policy engines are assigned to each queue—see page 213 for details. if a queue is empty then idle policy engines assigned to that queue are also permitted to poach messages from other queues (6). configurable by e-mail size. 2b 1 3 Q 7 Q 4 Q 6 4 Q 6 4 Q 5 Policy engine hub architecture A policy engine hub (1) can accept e-mails from various sources. A hub can have multiple event queues (three in this example). Distributing e-mails across multiple queues in this way allows fast-track processing for e-mails of different sizes. Registry settings on the host machine (1) define the size band for each queue. Each queue can be served by multiple policy engines (5). configurable by e-mail size. but only from queues with a smaller maximum size limit. including Event Import (2a) and an e-mail server agent (2b). When a policy engine has finished processing an e-mail. E-mails arriving at the hub are added to the input queue (3). Registry settings on the host machine (1) specify the policy engines allocated to each queue. To minimize processing times.212 CA DLP Deployment guide Policy engine hub architecture A policy engine hub can have multiple event queues. the e-mail is passed back to the completion queue (7) on the hub before being finally returned to the source application (2a or 2b). . it is passed back to the hub before being returned to the source application. After a policy engine has successfully processed an e-mail.

it is immediately assigned to the default queue. However. any additional queues are represented by a dedicated registry key. You do this by editing the registry.Chapter 12 Policy engine hubs 213 Hub event queues For each hub. if a queue is empty then any idle policy engines assigned to that queue are also permitted to poach messages from other queues (but only from queues with a smaller maximum size limit). . by contrast. the hub automatically assigns the message to the next appropriate queue. Monitoring the queue status To monitor the status of individual event queues. To allow fast-track processing of small messages. see—page 217. you need to create one or more additional. two additional queues are defined: Small (for messages up to 10KB) and Medium (up to 100KB). i The default queue is not represented in the registry by a dedicated registry key and has no maximum size limit for queued messages. it is immediately assigned to the Medium queue. which handles messages of unlimited size. to minimize processing times. conversely. Dedicated policy engines available to process queued messages You can specify separate lists of policy engines available for processing each queue. size-restricted queues. For example. if a 2MB message arrives. check the relevant counters in the CA DLP Hub Queues performance object—see page 225 for details. Queue settings For each additional queue. you can specify: The maximum size of queued messages If a message exceeds this maximum size limit. If a 15KB message arrives at the hub. there is always a default queue that can hold messages of unlimited size.

see page 217 for the hub and page 241 for the Exchange and Domino server agents.214 CA DLP Deployment guide Registry flow chart: e-mail processing on the hub The diagram below shows how the crucial registry values for the policy engine hub and the Exchange or Domino server agent operate in a strict sequence. with the event finally passing to a policy engine. Global timeout starts OK E-mail waits in hub input queue GlobalEvent TimeoutSeconds LowWaterMark “Delete” “Allow” “Mark” E-mail deleted E-mail delivered E-mail delivered Expired Fails EventRetryAttempts Succeeds OK GlobalEvent TimeoutSeconds Hub assigns e-mail to event queue Expired 3 Policy engine processes e-mail Fails Succeeds Return e-mail to hub completion queue 1 E-mail server agent 2 Policy engine hub 3 Policy engine . 1 E-mail server agent passes e-mails to hub HighWaterMark Exceeded HubFailureMode E-mail failure EMailFailureMode “Fail” “Wait” Not exceeded 2 E-mails added to hub input queue. For details about all the available registry values.

0. ` Windows 2003 or XP. 7. Enterprise Vault integration For details on Enterprise Vault installation requirements.4. require: 1 Deploy policy engines 2 Deploy policy engine hub Automatic installation with server agents or Import Policy Configure policy engine hub Assign ‘log on as a batch job’ security privilege Configure hub registry values ` Windows 2003 or XP. however. It does. 6. note that this affects the location of the hubs installation folder. or 8 i CA DLP integration with Domino has been tested using the Domino versions listed above. Confirm that this is so before installing the policy engine hub. and ` Lotus Domino 6. or Event Import— see page 199. see page 230 (direct mode) and page 231 (hub mode).x. For details about the Import Policy deployment procedure. Import Policy For details about setting up Import Policy. require: Policy engine hub deployment procedure 1 For details on deploying policy engines. The diagram below summarizes the deployment procedure when integrating CA DLP with Exchange. . see page 227. It does. The Domino server agent may integrate successfully with other versions of Domino. Exchange server agent The Exchange server agent does not require any other CA DLP software to be installed on the same machine. but these have not been tested.Chapter 12 Policy engine hubs 215 Deploy the policy engine hub This section describes how to install and configure a policy engine hub. see page 203. however.5. Domino and Enterprise Vault server agent. Host machine requirements PE domain user must be local administrator The PE domain user must be a member of the local Administrators group on the machine hosting the policy engine hub. 3 The event source can be a e-mail or archive server agent. see page 331. log files and performance counters—see page 536 for details. registry keys. For details about the PE domain user. Domino server agent 3 Set up the event source The Domino server agent does not require any other CA DLP software to be installed on the same machine. see page 201 2 These hub deployment tasks are described in this chapter. and ` Microsoft Exchange Server 2003 or 2007 (but see the note below) i If the hub is deployed with the Exchange 2007 server agent on a 64-bit machine.

see page 227. while upgrading the server agent) are given on page 224. For server agent installation instructions. But note the host machine requirements on page 215. i Note that instructions for: Automatic installation with server agents When you install the Exchange. Domino server agent: See page 238. see: Exchange server agent: See page 238. ` ` Stopping the hub (for example. the policy engine hub is also installed automatically. Uninstalling the policy engine hub are provided on page 226.216 CA DLP Deployment guide Install the hub The section describes how to install a standard hub for integration with Exchange. ` Installing a policy engine for use with Import Policy are given in chapter 13. . Domino. You install these server agents using the CA DLP Integration Agents installation wizard. Symantec Enterprise Vault: See page 331. Domino or Enterprise Vault. or Enterprise Vault server agent.

HKEY_LOCAL_MACHINE\Software \ComputerAssociates\CA DLP \CurrentVersion\Policy Engine Hub ! If the hub is deployed with the Exchange 2007 server agent on a 64-bit machine. 2 User Rights Assignment node. see below. you need to modify values in the following registry key. the registry key is slightly different—see page 536 for details. Assign security privilege to the PE domain user The PE domain user (see page 203) requires the ‘Log on as a batch job’ security privilege. Expand the Local Policies branch and select User Rights Assignment. Assign the ‘Log on as a batch job’ privilege to the PE domain user. Below this registry key there are various subkeys. i The sequence in which the registry values operate is shown in the flow chart on page 214. 2 3 4 Changes to the Policy Engine Hubs key take immediate effect. 1 Modify the hub registry values To configure the policy engine hub. The key structure is shown below: My Computer HKEY_LOCAL_MACHINE Policy Engine Hub Policy Engines DefaultSettings Queues Small Medium Large Security 2 3 Local Security Policy applet 1 Local Policies branch. For details. This permits policy engines on remote machines to access the policy engine hub. you must: Assign the ‘Log on as a batch job’ security privilege to the PE domain user on the host machine for the policy engine hub—see below. To assign this privilege: 1 Ensure that you are logged on with local administrator rights on the host machine for the policy engine hub. The values are described on pages 218 to 223. 3 Log on a batch job privilege Policy engine hub registry keys Registry values in the Policy Engine Hub key and its subkeys are described in the following sections.Chapter 12 Policy engine hubs 217 Configure the hub After installing the policy engine hub. open the Domain Controller Security Policy applet. Both applets are available in Administrative Tools. This security area determines which users have logon privileges on the local computer. open the Local Security Policy applet or. . if this machine is a domain controller. Configure the policy engine hub by modifying the associated registry values on the host machine. On the host machine.

218 CA DLP Deployment guide Policy engine hub registry values The table below lists the available registry values for policy engine hubs. Registry keys and values Policy Engine Hub key EventLoggingLevel EventRetryAttempts GlobalEventTimeoutSeconds HighWaterMarkMB HighWaterMarkEventCount LogFilePath LogMaxNumFiles LogMaxSizeBytes LowWaterMarkMB LowWaterMarkEventCount NoPEFailTimeoutSeconds OperationalLoggingLevel PECallTimeoutMilliseconds Page 219 219 219 219 219 220 220 220 220 220 221 221 221 221 Registry keys and values DefaultSettings subkey HeartbeatPeriodMilliseconds MetricsPeriodMilliseconds ReconnectTimeoutSeconds Queues key ActivePolicyEngines AdditionalQueues StandbyPolicyEngines <Queue name> subkey ActivePolicyEngines MaxSizeBytes StandbyPolicyEngines Security key NTNetworkDomain NTNetworkUser Page 222 222 222 222 222 222 222 223 223 223 223 223 223 223 223 . The full path to these registry keys is shown on page 217.

If either threshold is exceeded. This only applies to e-mail failures caused by a problem with the policy engine (such as a host machine crash) or with the e-mail itself (that is. While normal operations are suspended. i Note the following: EventRetryAttempts EventRetryAttempts Type: REG_DWORD Data: Defaults to 4. For example. . ` For Import Policy jobs. 40MB) to ensure a steady stream of events.600 seconds (6 hours). How the server agent handles ‘e-mail failures’ depends on the EMailFailureMode registry value—see page 242. see HighWaterMarkEventCount on page 221). HighWaterMarkMB HighWaterMarkMB Type: REG_DWORD Data: Defaults to 400. A time-out (in seconds) that specifies how long an e-mail can stay in the event queue on the hub or policy engine before it is flagged as an ‘e-mail failure’ and passed back to the source component (typically the Exchange server agent or. Event Import). If any queue lengthens and causes the allocated memory to rise above this maximum level. the hub temporarily suspends normal operations until the queue shortens (see LowWaterMarkMB on page 220). Log entries are written to the wgnphub_<date>. some unexpected condition that prevents the policy engine from analyzing the e-mail). plus informational and status messages i Setting EventLoggingLevel=3 will cause the log file to grow extremely rapidly. How the Exchange server agent handles ‘e-mail failures’ depends on the EMailFailureMode registry value—see page 242.Chapter 12 Policy engine hubs 219 Policy Engine Hub key The Policy Engine Hub registry key contains the following registry values: EventLoggingLevel EventLoggingLevel Type: REG_DWORD Data: Defaults to 2. or it returns them to the server agent as ‘e-mail failures’. we recommend a low value (for example. the handling of import failures depends on the type of import operation—see page 406. How the e-mail server agent handles ‘e-mail failures’ depends on the EMailFailureMode registry value—see page 242. where <date> is the date and time when the log file was created. GlobalEventTimeoutSeconds GlobalEventTimeoutSeconds Type: REG_DWORD Data: Defaults to 300. The supported logging levels are: 1 Errors only 2 Errors and warnings 3 Errors and warnings. ` Memory-based throttling operates in parallel with event-based throttling (for details. This determines the level of logging for message processing. you can configure the hub to only log errors or important system messages. so that events are less likely to timeout. for Import Policy jobs. i For Import Policy jobs. i If Import Policy is installed. Either the hub delays new e-mails from the e-mail server agent.log file. the file location is set by the LogFilePath registry value—see page 220. the hub’s behavior depends on the HubFailureMode registry value—see page 243. we recommend a value of 0. This level of logging is provided for testing purposes only. hub operations are suspended. the default for this value changes to 21. It does not apply to e-mail failures resulting from the time-out GlobalEventTimeoutSeconds expiring or because the HighWaterMarkEventCount or HighWaterMarkMB thresholds have been exceeded. Determines how many times the hub attempts to pass an e-mail to a policy engine before it is flagged as an ‘e-mail failure’ and passed back to the Exchange or Domino server agent. For Event Import. to stop the policy engine retrying failed events. The maximum amount of memory (in MB) that can be allocated to the various hub event queues.

This specifies the maximum number of log files. the log file is saved to the \System\Data\Log subfolder in the CA DLP installation folder on the Exchange server. While normal operations are suspended. i For Import Policy jobs. 40) to ensure a steady stream of events. the policy engine hub creates a new log file.log file—for details see EventLoggingLevel on page 219. we recommend a low value (for example.000. i Note the following: LogMaxNumFiles LogMaxNumFiles Type: REG_DWORD Data: Defaults to 10. they only resume when the queues shorten and allocated memory falls back below the LowWaterMarkMB amount. . LowWaterMarkMB LowWaterMarkMB Type: REG_DWORD Data: Defaults to 200. When the maximum number of log files exists and the maximum size of the latest is reached (see below). hub operations are suspended. Log entries are written to a wgnphub_<date>. 20MB) to ensure a steady stream of events. This specifies the folder you want to write log files to. the hub temporarily suspends normal operations until the queue shortens (see LowWaterMarkEventCount below). If normal hub operations are suspended because the HighWaterMarkMB has been exceeded (see above). LogFilePath LogFilePath Type: REG_SZ Data: Defaults to empty. If any queue lengthens and causes the event count to rise above this maximum level. the hub’s behavior depends on HubFailureMode—see page 243. LogMaxSizeBytes LogMaxSizeBytes Type: REG_SZ Data: Defaults to 1. The total amount of memory allocated to the various hub queues (in MB) that triggers a resumption in hub operations. ` For Import Policy jobs. If the path is not defined. When the current log file reaches its maximum size. ` Event-based throttling operates in parallel with memory-based throttling (see HighWaterMarkMB on page 219). The PE domain user must have write access to the specified folder—see page 226. The maximum total number of events that can be allocated to the various hub event queues. the oldest log file is deleted to enable a new one to be created. Either the hub delays new e-mails from the Exchange or Domino server agent.000.220 CA DLP Deployment guide HighWaterMarkEventCount HighWaterMarkEventCount Type: REG_DWORD Data: Defaults to 400. we recommend a low value (for example. This specifies the maximum size (in bytes) for each log file. or it returns them to the server agent as ‘e-mail failures’ (whose handling is dependent on the EMailFailureMode— see page 242. If either threshold is exceeded.

i For Import Policy jobs. NoPEFailTimeoutSeconds NoPEFailTimeoutSeconds Type: REG_DWORD Data: Defaults to 60.Chapter 12 Policy engine hubs 221 LowWaterMarkEventCount LowWaterMarkEventCount Type: REG_DWORD Data: Defaults to 300. A time-out (in milliseconds) that specifies how long the hub will wait to connect to a policy engine for configuration purposes before it cancels the call and assumes that the policy engine is currently unavailable. they only resume when the queues shorten and the event count falls back below the LowWaterMarkEventCount amount. OperationalLoggingLevel OperationalLoggingLevel Type: REG_DWORD Data: Defaults to 3. we recommend a low value (for example. PECallTimeoutMilliseconds PECallTimeoutMilliseconds Type: REG_DWORD Data: Defaults to 10000. This determines the level of logging for hub operations. How the Exchange or Domino server agent handles ‘e-mail failures’ depends on the registry value EMailFailureMode—see page 242. typical log entries cover hub installation. . the failure or suspension of policy engines. When this timeout expires. where <date> is the date and time when the log file was created. For example. This overrides the GlobalEventTimeoutSeconds value—see page 219. file name and location details and supported logging levels are the same as for EventLoggingLevel—see page 219. flags them as e-mail failures). 20) to ensure a steady stream of events. If normal hub operations are suspended because the HighWaterMarkEventCount has been exceeded (see above). creating or deleting queues. Log entries are written to the wgnphub_<date>. i We recommend that you do not change the default timeout of 60 seconds.log file. This specifies how long (in seconds) the hub waits after it detects there is no active policy engine available for a specific queue before it times out events in that queue (that is. and so on. all events in the queue are immediately flagged as e-mail failures. The total number of events allocated to the various hub queues that triggers a resumption in hub operations.

you must manually create a subkey for each additional queue. It contains the following registry values. The example registry diagram on page 217 shows three additional queues: Small. a <Machine name> subkey (see page 222). If a policy engine does not restart immediately when the hub tries to connect to it. because the policy engine host machine is switched off). and you must also add and configure the necessary registry values to this new subkey. instead. one for each message queue supported by the hub. which is always available.000. <Machine name> subkey To override the default policy engine configuration. it contains the DefaultSettings subkey (see below) and. if you want to configure your hub in advance. This value must be an integer multiple of HeartbeatPeriodMilliseconds. Queues key Below the Policy Engine Hub registry key. DefaultSettings subkey Below the Policy Engines registry subkey (see the previous section). i If you edit this registry value while the hub service is running. The <Machine> subkey can contain customized versions of any registry value in the DefaultSettings subkey—see the previous section. This specifies how often (in milliseconds) the policy engine sends a heartbeat signal to the policy engine hub. MetricsPeriodMilliseconds MetricsPeriodMilliseconds Type: REG_DWORD Data: Defaults to 10. ActivePolicyEngines ActivePolicyEngines Type: REG_SZ Data: Defaults to <localhost>. you can create a <Machine> subkey below the Policy Engines registry subkey (where <Machine> is the host machine for the policy engine you want to customize). CA DLP automatically creates new registry subkeys for each additional queue. there is a DefaultSettings subkey. This subkey contains no values. This specifies a commaseparated list of additional message queues available to the policy engine hub. AdditionalQueues AdditionalQueues Type: REG_SZ Data: Defaults to null. optionally. there is a Policy Engines subkey. Medium and Large. this value specifies how long (in seconds) the hub waits between subsequent reconnection attempts. HeartbeatPeriodMilliseconds HeartbeatPeriodMilliseconds Type: REG_DWORD Data: Defaults to 5000. . plus various subkeys. i This timeout is only applicable if the hub fails in its initial attempts after startup to connect to a policy engine (for example. is the Queues subkey. ReconnectTimeoutSeconds ReconnectTimeoutSeconds Type: REG_DWORD Data: Defaults to 600. This specifies a comma-separated list of names or IP addresses of machines hosting policy engines available to the default queue. These queues are in addition to a default queue. If the hub does not receive three successive heartbeat signals. it infers there is a problem with the policy engine. However.222 CA DLP Deployment guide Policy Engines subkey Below the Policy Engine Hub registry subkey (see the previous section). Values in this subkey define the default configuration for all policy engines. This specifies how often (in milliseconds) the policy engine returns metrics to the policy engine hub.

Each of these manually added subkeys contains the following registry values. and which can be used by the hub if an ‘active’ policy engine is unavailable. available to the specified queue. it is assigned to the next size queue. NTNetworkUser NTNetworkUser Type: REG_SZ Data: User name. if the hub service is running when you edit the AdditionalQueues registry value. which is always available and does not have its own registry subkey. This value is created automatically when you configure the Windows credentials (see page 226). End of params . Do not modify this value directly. Medium and Large. There is a separate subkey for each of these queues. If a message is too large for this queue. and which can be used by the hub if an ‘active’ policy engine is unavailable. You must create these additional subkeys manually or. MaxSizeBytes MaxSizeBytes Type: REG_DWORD Data: Defaults to zero. You must change the default value of MaxSizeBytes. Security key Below the Policy Engine Hub registry key. this queue can never process any messages! <Queue name> subkey In the example registry diagram on page 217. the subkey is created automatically. This specifies the maximum size (in bytes) of message events that can be processed by the specified queue. the values are: NTNetworkDomain NTNetworkDomain Type: REG_SZ Data: Domain name. But for reference. the hub supports three additional queues: Small. there is a Security subkey. ActivePolicyEngines ActivePolicyEngines Type: REG_SZ Data: Defaults to <localhost>. Do not modify this value directly. Created automatically when you configure the Windows credentials (see page 226). StandbyPolicyEngines StandbyPolicyEngines Type: REG_SZ Data: Specifies a comma-separated list of names or IP addresses of machines. If it remains set to zero. This specifies a comma-separated list of names or IP addresses of machines hosting policy engines available to the specified queue. You do not need to modify the values in this subkey because they are managed by the policy engine hub. These queues are in addition to a default queue.Chapter 12 Policy engine hubs 223 StandbyPolicyEngines StandbyPolicyEngines Type: REG_SZ Data: Specifies a comma-separated list of names or IP addresses of machines. available to the default queue.

but we recommend that you stop Internet Information Services (IIS). When the e-mail server agent receives no response from the hub. it infers there has been an e-mail failure and uses the EMailFailureMode registry value to determine how to handle the e-mail: this value can be set to Delete. You can now perform any necessary maintenance or upgrades on the host machine. restart the CA DLP Policy Engine Hub service. Consequently. 2 Restarting the policy engine hub You must restart the services in the reverse order to which they were stopped. Alternatively. The policy engine successfully processes the e-mail but is unable to notify the hub. . Consequences if you stop the hub before IIS If you stop the policy engine hub before stopping IIS.224 CA DLP Deployment guide Hub maintenance Stop the policy engine hub If you need to shut down the policy engine hub (for example. the e-mail is resubmitted to a policy engine when the hub restarts. or Mark (see page 242). That is. there is a risk that e-mails may be deleted or transmitted without being monitored by CA DLP. Stopping the policy engine hub 1 You must suspend normal Exchange or Domino operations before you stop the policy engine hub service. Allow. This is because you cannot upgrade the e-mail server agent . the timing of the hub shutdown may be such that an e-mail is sent to a policy engine for processing immediately before the hub shuts down. while you upgrade the Exchange or Domino server agent). Stop the CA DLP Policy Engine Hub service. or that e-mails may be imported twice.DLL file while IIS is running. then restart IIS. These consequences can arise if the Exchange or Domino server agent passes e-mails to the hub while it is shutting down. There are several ways to do this. you must follow the recommended procedure to ensure that no e-mails are inadvertently deleted or transmitted without being monitored by CA DLP.

For each performance object.Chapter 12 Policy engine hubs 225 Monitor policy engine hub activity There are various sources of diagnostic information when monitoring policy engine hubs. one per policy engine. Available counters show statistics such as the number and rate at which events are being passed to the policy engine and the internal state of the policy engine. This performance object contains counters for hub connections to individual policy engines.exe—see page 536. and the number of items assigned to the queue. This displays counters for policy engines and the hub. the following performance objects are available: DLP Hub Available only as a single instance. 2 Performance object counters for policy engines 1 Performance applet. This contains counters for the policy engine hub itself. instances you want to view. for example. standby and connected policy engines. accessible from Administrative Tools. you must open the correct instance of perfmon. To view counters for a specific queue. the number of event failures. For example. Performance counters The policy engine hub includes three performance objects that are useful when diagnosing hub problems. you can see the number of active. specify which counters and. Available counters show statistics such as the queue size band (in bytes). In the Performance applet (see below). Technical Support may ask for details of its internal state). log files and diagnostic files. select its corresponding instance. For each instance. you can add a range of useful performance objects. the number of active and standby policy engines available to process the queue. These are performance counters. this performance object contains counters for individual policy engines. ‘inactive’. ‘processing’ and ‘dead’ (if you encounter a problem with a policy engine. Hub performance objects i If the hub is deployed with the Exchange 2007 server agent on a 64-bit machine. the number of pending events in the hub input queue. select its corresponding instance. 2 Add Counters dialog. one per event queue on the hub. To view counters for a connection to a specific policy engine. Policy engine performance object For policy engine performance object details. DLP Hub Queues Multiple instances available. and the total memory allocated to events in the queue. see page 210. where relevant. DLP Hub Connections Multiple instances available. 1 For policy engine hubs. .

exe. typically installed to the \System subfolder in the CA DLP installation folder on the Exchange or Domino server. These detail progress as each e-mail is processed.226 CA DLP Deployment guide Log files i If the hub is deployed with the Exchange 2007 server agent on a 64-bit machine. wgnphub. the wizard stops Internet Information Services (IIS) before uninstalling the Exchange server agent and hub components. wgnphub. This applet is part of the Control Panel. the hub is then uninstalled automatically. When the wizard starts. go to the Program Maintenance screen and choose Modify. 2 Exchange and Domino server agents For details about the Exchange and Domino server agent log files.log. This log file is in the same folder as the hub executable. i If you choose Remove. 4 Exchange server agent and ISS When uninstalling the Exchange server agent. In the final wizard screen. Uninstall policy engine hubs ! If a policy engine hub is installed on the same computer as an Exchange. you must uninstall the server agent before uninstalling the policy engine hub. It then restarts IIS automatically when the uninstall is complete. security for wgnphub. To uninstall a policy engine hub. select CA DLP Integration Agents and click Change. 1 In Add/Remove Programs. or Enterprise Vault server agent. this removes all CA DLP components. as required. 3 In the Custom Setup screen. . Policy engine hub The policy engine hub service writes entries to the log file. choose the Exchange Server Agent or Domino Server Agent. Use Add/Remove Programs to manually uninstall the Exchange or Domino server agents. The hub writes entries to this log file using the PE domain user account. note that the server agent and hub log files may be in different locations—see page 536 for details. To configure the policy engine hub log files by editing the relevant registry values—see page 220. see page 255. click Install to begin the uninstallation. Domino. you must uninstall its associated server agent.log has been configured to give the PE domain user Read and Write access to this file. not just the Exchange or Domino server agents. i IIS is installed automatically as part of an Exchange Server installation. By default (on NTFS file systems).

13. you would configure two versions of each policy trigger that you want to use: in the first trigger. a hub). And because Import Policy requires no integration with production e-mail systems. the e-mail is discarded and is not saved as a CA DLP event! The Which E-mail Source? setting in the user policy allows you to disable a trigger based on the e-mail source. For files. which in turn assigns e-mails to an available policy engine. This is the simplest way to deploy Import Policy. Event Import passes e-mails to a policy engine connector (that is. Direct mode and hub mode Import Policy can operate in two modes: Direct mode: In this mode. there is no risk of disruption to e-mail activity. In this mode. . chapter 13 T Which imported e-mails are converted into events? During Import Policy operations. you may want to generate events for all e-mails imported from an Exchange mailbox. as part of an Import Policy job. Import Policy connects Event Import to policy engines in order to apply triggers to e-mails or files as they are imported: For e-mails. For example. and to specify active and standby policy engines (see page 201). but only generate events for certain categories of e-mail imported from PST archive files. important business documents or reports. in the second trigger. Event Import passes events directly to a local policy engine. Import Policy provides organizations with a full compliance review capability that is not dependent on a preventative pre-review strategy for filtering e-mail communications at source. Import policy Import policy his chapter introduces the Import Policy utility. A deployment architecture diagram is shown on page 229. Which E-mail Source? specifies that the trigger can only fire when processing relevant e-mails imported from an archive file. Import Policy enables organizations to apply policy to any files stored on their network. To achieve this. imported e-mails are only saved as CA DLP events if they cause a policy trigger to activate. Which E-mail Source? is configured so that the trigger can only fire when processing e-mails imported from Exchange. Hub mode: This mode is more complex to deploy. If an e-mail does not cause a trigger to activate. Two of the available options in this setting are designed explicitly for use with Import Policy jobs: Microsoft Exchange Server (Mailbox) Archive File Importers For example. but allows you to use multiple policy engines to process imported e-mails. organizations can categorize. A deployment architecture diagram is shown on page 229. or apply smart tags to.

the policy engine connector and hub then allocates e-mails to a policy engine. But there is a key difference. or Data Management console. source data is extracted from Exchange journal mailboxes or e-mail archive files (1a) then converted into CA DLP events by Event Import (2a). Import Policy passes imported e-mails straight to a local policy engine (4a). passing e-mails to a local policy engine hub (3b). Conversely. and so on. a control event is generated and saved on the CMS (for example. events from an external source are passed to a policy engine. e-mails are not actually blocked. because Import Policy requires no integration with production e-mail systems. Conversely. imported or intercepted e-mails are passed to a policy engine for processing. In all cases. there is no risk of disruption to end-users’ e-mail activity. But crucially. these events can be searched for and reviewed in the normal way. This is identical to how e-mail server agents work. a warning or blocking). If your organization uses an earlier version of Microsoft Exchange. Also. the control action can never be invoked so warning dialogs are not actually shown. In both cases. Import Policy in hub mode passes e-mails to a local policy engine connector (3a). Under Import Policy. In direct mode. i The Exchange server agent requires Microsoft Exchange Server 2003 or 2007. e-mail server agents (2b) simply intercept e-mails transiting through Exchange or Domino servers (1b). when a control trigger activates. In both cases. typically on a remote server (4b). you may want to use Import Policy as a substitute mechanism for monitoring e-mail activity. Import Policy also eliminates the need for CA DLP client agents on the desktop and policy engines on the e-mail server.228 CA DLP Deployment guide Import policy versus server agents Import Policy has parallels with the Microsoft Exchange integration provided by the Exchange server agent (see page 201). the policy engine then applies capture and control triggers as needed. E-mail processing: In all cases. . because the e-mail has already been sent. Import Policy: Direct mode Import Policy: Hub mode E-mail server agent 1a 1a 1b 2a 2a 2b 3a 3b 4a 4b 4b Import Policy versus e-mail server agents E-mail ingestion: Under Import Policy. Using the iConsole.

Notes databases or e-mail archive files. while hub mode offers greater flexibility in terms of allocating e-mails across multiple policy engines. In hub mode. Direct mode 1 2 3 4 5 Hub mode 1 2 3 4a 4b 5 Import Policy data flow 1 Source data: In both modes. i The diagram below shows a hub mode deployment based on a single remote policy engine. 5 CMS: The policy engine analyzes the e-mails and applies policy triggers as necessary. Event Import passes these events to a policy engine (4). The connector then passes e-mails to a policy engine (4b).Chapter 13 Import policy 229 Architecture diagrams The diagrams below compare the deployment architecture for Import Policy in direct mode and hub mode. however. Direct mode offers a much simplified deployment. In direct mode. After processing. e-mails are extracted from Exchange journal mailboxes. which converts the source data into CA DLP e-mail events. If required. 2 Import Policy server: This server hosts Event Import (3). e-mail events are replicated to the CMS. you can configure the policy engine connector to allocate e-mails across multiple policy engines. it passes them to a local Policy Engine Connector (4a). . typically running on a remote server.

Deploying Import Policy in direct mode is a simple twostep process. Install Import Policy in direct mode 1 To launch the installation wizard. import. run setup. In the Custom Setup screen.230 CA DLP Deployment guide Direct mode This section describes how to install and deploy Import Policy in Direct mode. using the CA DLP server installation wizard—see below. This is the simplest way to run the Import Policy utility. and then replicates the events up to the CMS. choose the Policy Engine and Event Import features: CA DLP Server Enterprise Server Policy Engine Event Import Remote PE Connector Templates Server installation wizard: available features i For Event Import requirements. For details. The policy engine analyzes these events. Find this in the \Server folder on your CA DLP distribution media. .exe. 3 The installation wizard now has all the information it needs. you must install Event Import and a policy engine on the same server. 2 Configure the Event Import job To connect Event Import directly to a policy engine. and start the import job. First. with each instance importing and processing e-mails from a separate Exchange mailbox or Notes database. see page 234. you must configure parameters in the import configuration file. see page 399.ini. applying policy triggers as necessary. Then. Click Install to start the file transfer. you can deploy Import Policy on multiple servers. you must configure Event Import to pass imported e-mails directly to the policy engine. i If a single policy engine would be too slow to process the anticipated data volumes. as it enables Event Import to pass events directly to the local policy engine.

you must configure Event Import to pass imported e-mails to a policy engine. 4 You need to configure the PE Connector. 2 You then need to deploy one or more policy engines. a standby policy engine—see page 232. 5 . For details. Then. Finally. This can include standby policy engines. Second. 5 Finally. 3 Next. optionally. 3 1 Specify user accounts 2 Install policy engines Install Event Import and Policy Engine Connector 4 Configure PE Connector 2 5 Configure Event Import 3 4 Import Policy deployment procedure: Hub mode 1 Specify the necessary user accounts. To deploy Import Policy in hub mode is a five-step process: 1 Before you can connect a policy engine to Event Import. This involves a parameter change. you must manually configure the Policy Engine Connector to enable communication between it and the policy engine(s). For details. you must install Event Import and the Policy Engine Connector—see page 233.Chapter 13 Import policy 231 Hub mode In hub mode. Deploying import policy in hub mode is slightly more complex than direct mode (see page 230). you must install at least one active policy engine and. This involves registry changes and changes to the logon account for the hub service. you need to configure Event Import to work with your policy engine(s). and to specify active and standby policy engines. you must install Event Import and the Policy Engine Connector. see page 233. Next. Import Policy connects Event Import to policy engines via a policy engine connector (or hub). see page 232. see page 234. For details. but allows you to use multiple policy engines to process imported emails. you must specify a Windows domain user that allows the Policy Engine Connector and its policy engines to communicate. You must also create a corresponding CA DLP user account.

This can be a new or existing domain user. . Policy engines also use this account (or more accurately. Find this in the \Server folder on your CA DLP distribution media. For details. you can set up extra policy engines. see page 204. you need to edit the machine policy settings that determine how the PE applies policy to e-mails from unrecognized senders. See page 201 for details about specifying these accounts. a CA DLP account with the same name) to log on to the CMS. In particular. the Policy Engine Connector) use the same account to communicate with each other. choose Policy Engine. This account is the ‘PE domain user’. running Import Policy in Hub mode requires communication between the machines running the policy engines and the policy engine hub. In particular. 2 4 Set up additional policy engines If required. Policy engines use the PE domain user as their service logon account. set the logon account for the policy engine service to be the PE domain user—see the previous section. The Policy Engine Connector uses the PE domain user account to access remote policy engine machines. To implement this communication. to install a policy engine: 1 Launch the installation wizard. The policy engine uses this account to log on to the CMS when mapping e-mail addresses to CA DLP users. Import Policy operations can continue uninterrupted even if the active policy engine becomes unavailable. For policy engines. PE domain user: Policy engines and the policy engine hub (in this case. The installation wizard now has all the information it needs. In the Custom Setup screen. you must create a matching CA DLP user account. Click Install to start the file transfer. For the Policy Engine Connector. CA DLP user: After specifying the PE domain user. CA DLP Server Enterprise Server Policy Engine Event Import Remote PE Connector Templates Server installation wizard: available features 3 In the Service Accounts screen.exe. setup. If a standby policy engine is available. you need to edit both the registry values on the policy engine host machine and also the local machine policy. Briefly. you can specify the PE domain user as the service logon account when you run the installation wizard. Configure the policy engine To configure your policy engines. before installing the Policy Engine Connector. optionally. see page 205. you must specify a PE domain user and create a corresponding CA DLP user account. Full deployment instructions are in chapter 11 ‘Policy engines’. a standby policy engine. For details on installing and configuring policy engines. you may want to set up a remote standby policy engine.232 CA DLP Deployment guide Specify user accounts In contrast to Direct mode. you must manually provide the account credentials for the PE domain user after installation. Install a remote policy engine You must set up at least one policy engine and.

To do this: 1 On the Event Import host machine. The procedure for configuring the Remote PE Connector is the same as the standard hub configuration. In the Custom Setup screen. . 1 To launch the installation wizard. 2 4 i Even if the PE Connector and policy engine are on the same machine. you run the CA DLP server installation wizard.exe. That is. assign a logon privilege to this account. specify the logon accounts used by the local CA DLP infrastructure service and the policy engine service—see page 232. Configure the Remote PE Connector As stated earlier. For details on installing and configuring policy engine hubs. run: wgnphub -SetCredentials You must be logged on as an administrator to run this command. CA DLP Server Enterprise Server Policy Engine Event Import Remote PE Connector Templates Server installation wizard: available features 3 In the Service Accounts screen. Click Install to start the file transfer.Chapter 13 Import policy 233 Install Import Policy in hub mode To install Import Policy in hub mode. Enter the credentials of the PE domain user. 3 The command will prompt for a user name and password. your standby policy engine. for example. This completes the installation process. choose Event Import and the Remote Policy Engine Connector. you must configure the PE Connector service so it can log on to remote policy engine machines as the PE domain user. go to the \System subfolder in the CA DLP installation folder. Find this in the \Server folder on your CA DLP distribution media. as specified on page 232. and modify certain registry values. we still recommend that provide the connector service with the additional credentials of the PE domain user. This allows the PE Connector to communicate with any remote machines hosting. From a command prompt. The installation wizard now has all the information it needs. the Remote PE Connector functions as a policy engine hub. 2 Set the credentials for the PE domain user First. you must set the credentials for the PE domain user. The Remote Policy Engine (PE) Connector functions as a policy engine hub and connects Event Import to one or more policy engines. run setup. see chapter 12 (page 211). You must now configure the PE Connector—see the next section.

import. Engine. see page 217. These parameters must cover the usual areas (specifying the source data for the import job. you must assign this account privilege to the PE domain user on the host machine for the PE Connector.UsePolicyEngineConnector=Yes This parameter specifies whether imported events are sent directly to a local policy engine or to a remote policy engine via the policy engine connector. Not supported for Import Policy: You cannot use these parameters with Import Policy: Parameter EMail. and so on. Required parameter: In particular. you need to configure Event Import parameters in the import configuration file. For full details of this parameter. Hub to configure Import Policy to run in hub mode. For full registry details. see chapter 18 ‘Event Import’. how much memory is allocated to its event queue.EventRetentionPeriod EMail. open the Local Security Policy applet or.StoreMessageClass . see page 217. Event Import parameters When connecting a policy engine to Event Import. the Domain Controller Security Policy applet. if the host machine is a domain controller. see page 417. Import Policy jobs must include the following parameter: Engine. These registry values are located in the following registry key: HKEY_LOCAL_MACHINE\Software \ComputerAssociates\CA DLP \CurrentVersion\Policy Engine Hub In particular. see the next section. For details. For full information. To do this. These registry values determine how it handles e-mail addresses. Configure the hub registry You do this by modifying the associated registry values on the host machine.BulkImportUsername Engine.InternalAddrPattern Page 419 414 414 416 421 Configure the Event Import job The final step in connecting a policy engine to Event Import is to configure the import parameters and start the import job. Set this parameter to: Yes to configure Import Policy to use direct mode. Both applets are available in Administrative Tools. For instructions on assigning logon privileges to accounts on the local machine.234 CA DLP Deployment guide Assign the ‘Log on as a batch job’ privilege Next. you must edit the registry values ActivePolicyEngines and (if required) StandbyPolicyEngines to include the name or IP address of the policy engine host machines.BulkImportUserpasswd Engine. and so on).ini.

This includes e-mails sent using BlackBerry handhelds. the machine hosting the Hub Transport Server.4. see page 215. The term ‘Domino server’ (with a lower-case s) means the actual computer hosting Domino. ‘Exchange server’ (with a lower-case s) means the actual computer hosting Microsoft Exchange or. Microsoft Office Outlook Web Access or Notes Web Clients. It also briefly mentions the IIS SMTP agent.0. ` ’Domino’ means IBM Lotus Domino server (version 6. Conversely.5. These agents allow CA DLP to monitor and control corporate e-mail activity that would otherwise be missed by client integration alone. E-mail server agents E-mail server agents his chapter shows how to deploy e-mail server agents to integrate CA DLP with Exchange Server and Lotus Domino. it describes how to integrate CA DLP with Sendmail and Postfix. i Throughout this chapter: chapter 14 T 1 Deploy policy engines 2 Deploy policy engine hub 3 Set up the event source Install the e-mail server agent Configure the server agent Turn on e-mail integration ` ‘Exchange Server’ (with an upper-case S) always means Microsoft Exchange Server (version 2003 or 2007). see page 201. 3 This chapter covers installing. In addition. 6. using the Milter MTA agent. or 8).x. configuring and monitoring Exchange and Domino server agents and the Milter MTA agent.14. 7. . E-mail server agent deployment procedures 1 For details on deploying policy engines. 2 For details on deploying a policy engine hub. E-mail server agents must be deployed in conjunction with CA DLP policy engines and a policy engine hub (see chapters 11 and 12 respectively). This chapter focuses on how to configure the server agents and how to monitor agent activity. for Exchange Server 2007.

Depending on the needs of your organization. This approach avoids unnecessary duplication of analysis and processing. This is possible for e-mails that generated warning or inform events and requires specific configuration on the machine hosting the Exchange server agent. To enable integration with this version of Exchange Server. if the sender is not a recognized CA DLP user. the Exchange environment may be highly complex and can contain multiple Active Directory sites. each of which can contain multiple Mailbox Servers and one or more Hub Transport Servers. This section highlights the key differences between client-side and server-side e-mail integration. This enables CA DLP to monitor and control all communication sent via Microsoft Exchange Server 2007. see page 252. the range of available control interventions is slightly more limited under server-side integration. Second. it can simply send a notification message to the sender. Specifically. This contrasts with client-side integration where CA DLP can apply both incoming e-mail triggers (defined in the recipient’s policy) and outgoing e-mail triggers (defined in the sender’s policy). CA DLP can also intervene by sending an interactive warning email to the sender. For further details.236 CA DLP Deployment guide E-mail server integration The primary reason for deploying policy engines is to permit CA DLP integration with Exchange Server. Exchange Server 2007 is a modular system comprising five server ‘roles’. under server-side integration CA DLP always applies triggers from the sender’s perspective (that is. Sendmail and Postfix e-mail servers. For large organizations. CA DLP must therefore be deployed on each Hub Transport Server in the form of the Exchange 2007 server agent. ` CA DLP can intervene by blocking an e-mail and sending a notification message to the sender. E-mail integration: server-side versus client-side CA DLP supports both client-side and server-side e-mail integration. it applies triggers for outgoing e-mails). . Sendmail or Postfix. However. Domino. it cannot display warning dialogs that require user interaction (unlike under client-side integration. or in the case of e-mails that generate warning or inform events. Specifically: Exchange 2007 server agent CA DLP supports Microsoft Exchange Server 2007. you can install a Mailbox Server and a Hub Transport Server on the same or separate machines. when CA DLP can display dialogs that require user interaction). ` With Microsoft Exchange server agents. in the policies for the Unknown Internal Sender or External Sender (see page 205). or do nothing to automatically heed the warning and the Exchange server agent sends or does not send the e-mail accordingly. The user can then reply to the message to disregard the warning. But there are two key differences between these e-mail integration methods: First and most important. it can integrate with Microsoft Outlook or Lotus Notes on client machines and with Microsoft Exchange. These triggers are defined in the sender’s user policy or. Lotus Domino.

It does. 7. ‘Policy engines’.4. Exchange server agent Deploy policy engines 1 Deploy e-mail server agent and policy engine hub Install server agent and hub Configure policy engine hub Configure e-mail server agent The Exchange server agent does not require any other CA DLP software to be installed on the same machine. Exchange server agent and policy engine hub 1 You install the e-mail server agent and the policy engine hub together. Additional e-mail integration issues are discussed on page 271. . Domino server agent The Domino server agent does not require any other CA DLP software to be installed on the same machine. but these have not been tested. Turn on e-mail server integration i The Exchange 2007 server agent must be installed on each Hub Transport Server in the Active Directory site. The Domino server agent may integrate successfully with other versions of Domino. Host machine requirements PE domain user must be a local administrator The PE domain user must be a member of the local Administrators group on the machine hosting the policy engine hub. and ` Microsoft Exchange Server 2003 or 2007 but see below) Microsoft Exchange Server 2007 CA DLP integration with Exchange Server 2007 requires Windows 2003 64-bit and MAPI. See page 201 for details. or 8. however. require: ` Windows 2000 or 2003. i CA DLP integration with Domino has been tested using the Domino versions listed above.0. Deploy policy engines This is described in chapter 11. however. 6.5.Chapter 14 E-mail server agents 237 Deploy the Exchange or Domino server agent This section describes how to install and configure the Exchange server agent or Domino server agent and the policy engine hub. It does. and ` Lotus Domino 6.x. You must then separately configure these components. require: ` Windows 2000 or 2003. Confirm that this is so before installing the policy engine hub.

see page 241. i For Exchange Server 2007. To ensure that the ‘policy processed’ status is preserved when e-mails already processed by CA DLP are sent between Domino servers over SMTP links. The Exchange server agent can also be configured to send interactive warning messages.238 CA DLP Deployment guide Install a Exchange or Domino server agent You install the Exchange and Domino server agents using the CA DLP Integration Agents installation wizard. Other registry values determine how the server agent handles event failures and out-of-memory failures. you can tailor the e-mail server agent to only monitor e-mails sent from particular SMTP addresses (such as addresses ending with ‘@unipraxis. you need to change the MIME settings—see page 239. A policy engine hub is also installed automatically when you install the server agent. 2 In the Custom Setup screen. For Domino servers. you also need to configure their MIME settings. MIME configuration: For Domino servers only. For this reason. You now need to configure the e-mail server agent and policy engine hub (see the next sections). this is the \win64\Integration folder. ‘Policy engine hubs’. For example. or ` Domino Server Agent 3 In the Policy Engine Hub Configuration screen.exe. Find this in the \Integration folder on your CA DLP distribution media. see page 225. For full registry details. can be used for diagnostic purposes. Clearly.com’). expand the Server Agents branch and choose either: ` Exchange Server Agent. any changes to mission-critical systems such as an e-mail server must be thoroughly tested first. click Install to start the file transfer. 1 To launch the Integration Agents installation wizard. run setup. See page 217 for details. CA DLP also supports various registry values which. 4 In the final wizard screen. When this is done. you modify values in the registry keys shown below. although not installed automatically. Modify the registry: To configure the e-mail server agent. i If you subsequently need to change these credentials. you can turn on integration with Exchange or Domino (see page 250). provide the credentials for the PE domain user (as specified on page 203). ` Domino integration HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Domino . 5 ` Exchange integration HKEY_LOCAL_MACHINE\SOFTWARE\ \ComputerAssociates\CA DLP \CurrentVersion\Exchange Configure the hub This is described in chapter 12. Configure the Exchange or Domino agent You configure the Exchange server agent or Domino server agent by modifying the registry.

MIME Configuration In Domino Administrator. if you use such xheaders to flag e-mails that must be encrypted. you need to edit the MIME configuration settings on your Domino servers. if the recipient Domino server agent were parented to the same CMS as the originating CA DLP client or server agent. a duplicate event would be written to the CMS database. 2 ‘Always send the following Notes items in headers’.Chapter 14 E-mail server agents 239 MIME configuration for Domino servers Before enabling CA DLP integration with Domino. For example. Without this configuration change. if a Domino server agent were running on the recipient server this loss of status would mean that the e-mail was processed by CA DLP again and. potentially. This ensures that any e-mails which have already been processed by CA DLP: Do not lose their ‘policy processed’ status when they are sent between Domino servers that send messages using SMTP rather than the NRPC (Notes Remote Procedure Call) protocol. you need to edit one or both of these advanced MIME configuration settings: 1 ‘Internet Mail server sends Notes private items in messages. this information would be unavailable to the third party encryption solution. 1 2 Domino Administrator. . You can edit this list to ensure that CA DLP-generated x-headers and ‘policy-processed’ status details are retained for e-mails already processed by CA DLP. For MIME configuration instructions. these x-headers would be lost from the e-mail. see page 239. Retain any x-headers generated by CA DLP.’ You can enable this option to retain the ‘policy-processed’ status for e-mails already processed by CA DLP. Without this configuration change.

WiganSS . To do this.WiganSS. you must edit this list accordingly. ` Always send the following Notes items in headers: Add these items as a comma-separated list: WiganStatus. minus its x— prefix. edit the following option: 2 ` Always send the following Notes items in headers: Add the CA DLP-generated x-header. if you are reluctant to make this configuration change (for example. You need to edit one or both of these options: 3 To retainCA DLP-generated x-headers: CA DLP can insert x-headers into e-mails through the use of special smart tags in policy triggers. If appending the x-header to the items you added in step 2. To ensure these x-headers are retained when the e-mails transit through Domino servers.UNIPRAXIS-MsgSec If you subsequently change this x-header. navigate to the MIME tab. under Server Configuration you need to edit the advanced MIME configuration settings. ` Internet Mail server sends Notes private items in messages: Set this to ‘Enabled’. Alternatively. Note that this change alone will not retain CA DLP x-headers (see step 3).240 CA DLP Deployment guide Edit the Domino MIME options To edit the MIME configuration settings: 1 In Domino Administrator. You can configure Domino to send all private items or you can explicitly specify the CA DLP items. For example. then go to the Advanced > Advanced Outbound Message Options tab—see the screenshot on page 239. To retain the ‘policy processed’ status: This status is appended to e-mails as a Notes private item. we recommend you edit the following option instead. or start using additional x-headers. use a comma-separated list. if the x-header name generated by CA DLP smart tags is: X-UNIPRAXIS-MsgSec Then you need to add these Notes items to the list: WiganStatus. because it may consume excessive bandwidth or because there may be security implications). to this list (x-headers are temporarily stripped of this prefix when processed by Domino).

all registry values apply to both the Exchange and Domino server agents. Changes to these registry values take immediate effect.Chapter 14 E-mail server agents 241 E-mail server agent registry values The table below lists the available registry values for the e-mail server agent (the parent registry keys are listed on page 238). ! If you are using Exchange Server 2007. you must set the UpdateConfig registry value to 1 for any changes to take effect—see page 245. Others. Registry keys and values Automatic registry values Agent AttachOriginalEmail EMailFailureMode EnableIntegration HostProcesses HubFailureMode LogLevel LogMaxNumFiles LogMaxSizeBytes OperationMode ReprocessClientEmails SenderAddressInclusionFilter UpdateConfig Page 242 242 242 242 242 243 243 243 244 244 244 244 245 245 AllowedRecoveryHostProcesses CreateEML CreateEVF DiagnosticFolder EnterpriseDNSList IntercomPort NotificationFromAddress ProcessAPMStateValue SMTPDNSHostName . Some of the registry values supported in the Exchange or Domino keys are created automatically when you install the e-mail server agent. Registry keys and values Interactive warning registry values EnableInteractiveWarnings LocalMailboxSMTPAddress MaxPendingWarnings UnmatchedResponseTemplateFile UnmatchedResponseTitle WarningHeedTimeoutMins WarningTemplateFile Manually created registry values Page 246 246 246 246 246 246 246 246 247 247 247 247 247 248 248 248 248 249 i Unless explicitly stated otherwise in their individual descriptions. must be created manually. primarily the diagnostic values.

set this registry value to 1. but marks it as if it had been processed normally. This prevents a downstream server agent from re-processing the e-mail. ` Allow. This registry value is set to either Exchange or IIS.242 CA DLP Deployment guide Automatic registry values The following registry values are created automatically when you install the Exchange or Domino server agent or the IIS SMTP agent: Agent Agent Available for the Exchange server agent and IIS SMTP agent only. Allow. Determines whether or not the server agent processes e-mails. It defaults to Allow. If set to: ` Delete. the server agent allows the e-mail to transit through Exchange Server or Domino without intervention. If set to IIS. . this instructs the IIS SMTP agent to check the DomainMapping registry key. to enable e-mail processing). This specifies how the e-mail server agent handles event failures. AttachOriginalEmail AttachOriginalEmail Type: REG_DWORD Data: Specifies whether the original e-mail is included as an attachment in ‘Blocked’ notification messages. E-mail failures can occur when: ` Either of the hub’s HighWaterMarkEventCount or HighWaterMarkMB thresholds are exceeded (see page 219) and the HubFailureMode registry value flags all subsequent e-mails as failures. EMailFailureMode EMailFailureMode Type: REG_SZ Data: This value can be set to Delete. To turn on e-mail integration (that is. the server agent deletes the e-mail without notifying the sender. That is. or Mark. ` Mark. Type: REG_SZ Data: Defaults to Exchange. If this value is not present or is set to 1. i All e-mail attachments are removed from the original message when it is attached to a notification e-mail. Set this to zero to omit the original e-mail from these notification messages. This is only applicable if you are using the IIS SMTP agent to host a CA DLP service for use by other organizations—see page 258. the server agent allows the e-mail to transit through Exchange Server or Domino without intervention. the original e-mail is attached. the e-mail server agent reverts to its default behavior. EnableIntegration EnableIntegration Type: REG_DWORD Data: Defaults to 0 (zero). CA DLP uses this value to determine the context when processing e-mails. or ` The GlobalEventTimeoutSeconds hub timeout expires (see page 219). or ` There is a general failure when the policy engine analyzes the e-mail.

the hub flags all subsequent e-mails as failures as soon as a ‘high water mark’ threshold is exceeded.exe. Please contact Technical Support for details—see page 23. HubFailureMode HubFailureMode Type: REG_SZ Data: Defaults to Fail. This registry value enables the Domino server agent to process all Domino e-mails. . plus informational and status messages i Setting LogLevel=3 will cause the log file to grow extremely rapidly.exe. This level of logging is provided for testing purposes only. including those originating from BlackBerry handhelds. The supported logging levels are: 1 Errors only 2 Errors and warnings 3 As 2.Chapter 14 E-mail server agents 243 HostProcesses HostProcesses Available for the Domino server agent only.wgnimpsv.exe. If set to: Type: REG_SZ Data: Defaults to nserver. ` Fail.log ` Exchange 2007: WgnESA_<date>. ` Wait. the hub stops accepting e-mails from the e-mail server agent until the event queue shortens to reduce allocated memory amount below the relevant ‘low water mark’ threshold. i In technical terms. This value instructs the hub what to do if the HighWaterMarkEventCount or HighWaterMarkMB thresholds are exceeded. ! We strongly recommend that any changes to this registry value are made only under the guidance of CA technical staff.nhttp. this value specifies a list of hooked processes for which the Domino server agent will process Domino callbacks.nsmtp. this registry value (usually in conjunction with the ProcessAPMStateValue registry value) ensures that the Domino server agent only processes the mail after the specified processes have modified an e-mail for the final time. This determines the level of logging for message processing.wgnimp. you can configure the e-mail server agent to only log errors or important system messages. Log entries are written to the following files: ` Exchange 2003: WgnSmtpS_<date>.exe. LogLevel LogLevel Type: REG_DWORD Data: Defaults to 2. If third party e-mail processing applications (such as antivirus or archiving products) are also running on the Domino host machine. The Domino server agent will then use this amended process list to avoid contention with the third party application when processing individual e-mails.log ` Domino: WgnEMNO_<date>. For example.exe. E-mail failures are returned to the Exchange or Domino server agent. In effect. where their handling is controlled by the EMailFailureMode registry value (see above). Normal operations resume when the event queue shortens to reduce allocated memory amount below the relevant ‘low water mark’ threshold. nbes. This value can be set to Wait or Fail. you can use this registry value to specify a comma-separated list of process executables associated with these applications instead of the default processes listed above.exe.log Where <date> is the date and time when the log file was created.

When the current log file reaches its maximum size. OperationMode OperationMode Applies to Exchange 2003 only. This specifies the maximum size for each log file. the oldest log file is deleted to enable a new one to be created. the e-mail server agent creates a new log file. This option is designed to minimize the load on the e-mail server agent. even if this registry value is set to ‘Always’. ` Exchange 2003: WgnSmtpS_<date>. This specifies the maximum number of log files. automatic replies to blocked e-mails). ` Quarantine: E-mails marked as already processed by the Outlook or Notes client agent can be processed a second time by the Exchange or Domino server agent. If present and set to: LogMaxSizeBytes LogMaxSizeBytes Type: REG_SZ Data: Defaults to 1.log ` Exchange 2007: WgnESA_<date>. or both the Notes client agent and Domino server agent—see below for details.244 CA DLP Deployment guide LogMaxNumFiles LogMaxNumFiles Type: REG_DWORD Data: Defaults to 10. you must change it back to LocalHub and restart the IIS service. Type: REG_SZ Data: Currently only a value of LocalHub is supported. but only to apply a quarantine control action. ! This setting must not be changed! It currently only supports a value of LocalHub. Log entries are written to the following files: ` Never: E-mails marked as already processed by the Outlook or Notes client agent are never processed a second time by the Exchange or Domino server agent. When the maximum number of log files exists and the maximum size of the latest is reached (see above). If this value is changed. this registry value is not created automatically.log Where <date> is the date and time when the log file was created—for details see LogLevel opposite. ReprocessClientEmails ReprocessClientEmails Type: REG_SZ Data: You must create and edit this value if your CA DLP installation uses both the Outlook client agent and Exchange server agent.000.log ` Domino: WgnEMNO_<date>. ` Always: E-mails marked as already processed by the Outlook or Notes client agent are always processed a second time by the Exchange or Domino server agent. i If you are using Exchange Server 2007. If this value is present. i If you are using Exchange Server 2007.000. This specifies that the e-mail server agent passes all events to the policy engine hub on the local machine. . this registry value is not created automatically. i E-mails generated by CA DLP (for example. are not processed by the Exchange or Domino server agent. the default behavior for the server agent corresponds to ‘Never’.

If the sender’s e-mail address does not match any item in this list. Set to 1 to force the Exchange server agent to re-read the registry and the content of any template files. it automatically resets this registry value to 0. Type: REG_DWORD Data: Enables administrators to update the registry and the content of any template files while the Exchange server agent is running. A * wildcard will match any sequence of zero or more digits. By default. spen?er matches Spencer or Spenser. letters or punctuation characters. no other users will be affected. Note that * and ? wildcards are supported. This ensures that if there is problem with the integration. If the Exchange server agent fails to accept the changes. if you want to test that integration with Exchange Server or Domino is working correctly before you go live.com. you need only set this value to ‘unipraxis’. For example. When the Exchange server agent has accepted the changes. This value specifies a list of addresses for the e-mail server agent to filter against.Chapter 14 E-mail server agents 245 SenderAddressInclusionFilter SenderAddressInclusionFilter Type: REG_SZ Data: Defaults to *. ! You must update this registry value in order to update your Exchange Server 2007 server agent configuration. it automatically sets this registry value to 2. For example. UpdateConfig UpdateConfig Available for the Exchange Server 2007 server agent only. A ? wildcard will match any digit. you can specify the full address of a test user. . a *unipraxis* filter will match spencer@sales. the e-mail server agent monitors all e-mails passing through Exchange Server or Domino. for example. the e-mail server agent disregards the e-mail and allows the e-mail to transit through Exchange Server or Domino without intervention. letter or punctuation character.com domain. Similarly.unipraxis. if you only want to monitor e-mails sent from the unipraxis.

246

CA DLP Deployment guide

Interactive warning registry values
Available for the Exchange server agent and IIS SMTP agent only. The following registry values are created automatically when you install the Exchange server agent. They are used to enable and configure server-side interactive warnings—see page 251. EnableInteractiveWarnings EnableInteractiveWarnings Type: REG_DWORD Data: Default to (0) zero. Set this value to 1 to enable interactive warning messages. LocalMailboxSMTPAddress LocalMailboxSMTPAddress Type: REG_SZ Data: Defaults to empty. Set this value to the SMTP address of the Compliance Release mailbox. This is the Reply To address for interactive warning notifications. To create this mailbox, see page 253. MaxPendingWarnings MaxPendingWarnings Type: REG_WORD Data: Defaults to 5000. This value specifies the number of ‘pending warnings’ that can be held on the Exchange server. That is, the number of e-mails awaiting a response from a previously sent warning notification message. When the maximum number of pending warnings is reached, the oldest warning is automatically heeded to make room for a new ‘pending warning’. UnmatchedResponseTitle UnmatchedResponseTitle Type: REG_SZ Data: Defaults to %subject%. This value specifies the title text for the unmatched response message. It defaults to an insertion variable corresponding to the subject of the user’s reply to the warning message. i For details on supported insertion variables,
see the Administration console online help; search the index for ‘interactive warnings’.

UnmatchedResponseTemplateFile UnmatchedResponseTemplateFile Type: REG_SZ Data: This value references a text file containing the body text for the unmatched response message. Enter the full path to the relevant file. Defaults to: \ProgramFiles\CA\CA DLP\Client \UnmatchedResponseTemplate.txt i This text file can be in ANSI, UTF-8, Unicode,
or HTML format. It can also contain insertion variables that refer to the user’s reply to the warning message. For details on supported insertion variables, see the Administration console online help; search the index for ‘interactive warnings’.

WarningHeedTimeoutMins WarningHeedTimeoutMins Type: REG_DWORD Data: Defaults to 240 (four hours). This value specifies how long (in minutes) a pending warning remains on the Exchange server. After this timeout expires, the warning is automatically heeded. WarningTemplateFile WarningTemplateFile Type: REG_SZ Data: This value references a text file containing the body text for the warning message. Enter the full path to the relevant file. Defaults to: \ProgramFiles\CA\CA DLP \Client\WarningTemplate.txt i This text file can be in ANSI, UTF-8, Unicode, or
HTML format and can contain insertion variables.

Chapter 14 E-mail server agents

247

Manually created registry values
The following registry values are also supported. Most, but not all, are for diagnostic purposes. You may need to create these values, for example, to test the integration with Exchange Server before going live: AllowedRecoveryHostProcesses AllowedRecoveryHostProcesses Available for the Domino server agent only. Type: REG_SZ Data: Specifies a list of processes that can host the recovery thread. This list must be a subset of the processes listed in the HostProcesses registry value—see page 243. You can use this registry value to prevent a third party application process from hosting the recovery thread. i If AllowedRecoveryHostProcesses is not present then the entire list in HostProcesses is
used instead. There is only one instance of the recovery thread. That is, only the first process to start the recovery thread will actually run it.

CreateEVF CreateEVF Type: REG_DWORD Data: Specifies whether an EVF file is created for each e-mail in CA DLP EVF format processed by the policy engine hub. If this value is set to: 0 The server never creates EVF files. 1 The server always creates EVF files and saves them in the DiagnosticFolder—see page 247. 2 Exchange Server 2007 only. The server only creates EVF files on error. That is, when an event returns from the policy engine hub with an error. DiagnosticFolder DiagnosticFolder Type: REG_SZ Data: Specifies the path and folder where diagnostic files will be saved. The creation of these files is determined by the CreateEML registry value. i This folder is not created automatically.

CreateEML CreateEML Available for the Exchange server agent only. Type: REG_DWORD Data: Specifies whether to create diagnostic files containing the e-mails and associated data for e-mails transiting through the server. These files are:

` EML: Contains the ‘raw’ MIME e-mail data for each
e-mail processed.

` EMP: Contains additional data relating to the
e-mail, such as the actual recipient list and internal properties. i Any EML and EMP files created are saved in
the DiagnosticFolder.

! We strongly recommend that you do not
change this setting!

248

CA DLP Deployment guide

EnterpriseDNSList EnterpriseDNSList Type: REG_SZ Data: Defaults to empty, but see ‘Updating an empty list’ below. This registry value specifies a list of DNS domains that you want to be considered as a single enterprise. It is typically used in conjunction with SmtpDNSHostName (see page 249). Its purpose is to simplify the method for ensuring that e-mails are not reprocessed needlessly by consecutive Exchange or Domino server agents. i Values in this list can only contain ASCII
characters, without spaces or control characters (for example, tab spaces).

IntercomPort IntercomPort Available for the Exchange Server 2007 server agent only. Type: REG_DWORD Data: Specifies the inter-agent communications port number. Port numbers between 1 and 65535 are valid in this setting. Defaults to 8102. i If this parameter is changed, you must then
restart the Exchange server agent.

NotificationFromAddress NotificationFromAddress Type: REG_SZ Data: Specifies a text string representing the ‘notification sender’. This text appears in the From: box in all notification e-mails generated by Exchange or Domino server agents (such as when an e-mail is blocked). For example, you can specify that the From: field in notification e-mails is always set to ComplianceTeam@Unipraxis.com. This registry value is optional and overrides the default sender (typically ‘postmaster’). The text string must be a valid SMTP address.

How does this work? The local Exchange or Domino server agent assumes each of the domains listed in EnterpriseDNSList has its own Exchange or Domino server agent, and that any e-mail arriving from a listed domain has already been processed by CA DLP and does not need reprocessing. In technical terms, when a remote Exchange or Domino server agent processes an e-mail, it writes the DNS domain of the Exchange or Domino server to the e-mail’s MIME tag. Or, if the SmtpDNSHostName registry value has been configured, this value is written to the MIME tag instead. When the local Exchange or Domino server agent receives this e-mail, it checks the MIME tag. If the source domain matches a domain in EnterpriseDNSList, the server agent does not reprocess the e-mail. Updating an empty list: While this list is empty, the DNS domain of the local Exchange or Domino server is implied. That is, the local Exchange or Domino server agent does not reprocess e-mails arriving from this domain. i For examples of how this registry value is
used, see page 271.

Chapter 14 E-mail server agents

249

ProcessAPMStateValue ProcessAPMStateValue Available for the Domino server agent only. ! We strongly recommend that any changes to
this registry value are made only under the guidance of CA technical staff. Please contact Technical Support for details—see page 23.

SmtpDNSHostName SmtpDNSHostName Type: REG_SZ Data: Defaults to empty. This value is always used in conjunction with EnterpriseDNSList (see page 248). Its purpose is to simplify the method for ensuring that e-mails are not reprocessed needlessly by consecutive Exchange or Domino server agents. i This value must be a valid DNS name that
complies with RFC naming conventions.

Type: REG_SZ Data: This optional registry value specifies a value for the ‘APMState’ item that the Domino server agent will wait for before it processes a note. You can use this registry value to enable the Domino server agent to wait for a third party application to finish processing, before it applies policy. However, this is normally only be used in conjunction with the HostProcesses registry value. i If this registry value is used, it must be set to
the text string that the third party application sets as the value of the APMState item. For example, 3rdPartyComplete.

SMTPDNSHostName specifies a single DNS domain that is written to the e-mail’s MIME tag after it has been processed by the local Exchange or Domino server agent. If set, this registry value overrides the DNS domain of the Exchange or Domino Server in the MIME tag. To use this registry value as intended, you need to set SMTPDNSHostName to the same value (for example, UNIPRAXIS.COM) for all your e-mail server agents. You can optionally include this value in the EnterpriseDNSList domain list. Now, when any Exchange or Domino server agent receives an e-mail tagged as coming from UNIPRAXIS.COM, it knows that policy has already been applied to the e-mail and so does not reprocess it. i For examples of how this registry value is
used, see page 271.

250

CA DLP Deployment guide

Turn on Exchange or Domino integration
The Exchange and Domino server agents use a single registry value to turn on e-mail integration with Exchange Server or Domino. Because any changes to this value are effective immediately, we recommend that you make this the final step when setting up integration with Exchange Server or Domino. ! If you are using Exchange Server 2007, you must set the UpdateConfig registry value to 1 for
changes to this value to take effect—see page 245. You need to ensure that this final step is completed back-to-back on all CA DLP Exchange server agents in an Active Directory Site.

You can find the required value in these registry keys: Exchange and IIS SMTP integration HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Exchange Domino integration HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Domino

Deploy policy engines

X To turn on e-mail integration
You must modify this value: EnableIntegration Type: REG_DWORD Data: Defaults to 0 (zero). Determines whether or not the server agent processes e-mails. To turn on e-mail integration (that is, to enable e-mail processing), set this registry value to 1.

Deploy e-mail server agent(s) and policy engine hub

1

Enable server-side e-mail integration Edit registry value EnableIntegration

X To turn off e-mail integration
Turn on Exchange integration 1 After installing and configuring the policy engines, policy engine hub and e-mail server agent, edit the EnableIntegration registry value to turn on e-mail integration. Set EnableIntegration to 0. This disables e-mail processing. That is, the server agent allows all e-mails to transit through Exchange Server or Domino without intervention.

Chapter 14 E-mail server agents

251

Set up server-side interactive warning messages
i Interactive warnings are only available for the
Exchange server agent. If you are using Exchange 2007, you need to set up your integration slightly differently—see page 251.

Warnings and follow-up messages
The sender of an e-mail can receive a warning and, if necessary, a follow-up message from the Exchange server agent. The text content of these messages is configurable, by using template text files referenced in the registry—see page 254. Warning message: This is the first message the user receives. It is sent automatically when the Exchange server intercepts an e-mail which has generated a warning or inform event. By default, the message has the user’s original e-mail attached and states that it has triggered one or more warnings. It lists the warnings and advises the sender that if they want the e-mail to be sent, they must reply to the warning message. ‘Unmatched response message’: This message is automatically sent when the user does reply to the warning message, but the original e-mail is no longer on the Exchange server. In this situation, the user’s reply cannot be matched to the original e-mail and so the e-mail cannot be released and sent. Replies are matched to their corresponding e-mails by a unique ID in the Subject. The original e-mail may no longer be on the Exchange server for any of the following reasons:

If CA DLP intercepts an e-mail transiting through Exchange Server and the e-mail generates a warning or inform event, CA DLP can automatically send a notification or interactive warning e-mail to the sender. If the sender replies to this warning promptly (that is, before the warning timeout expires), then their e-mail is released and sent on to its intended recipients. If they do not reply (or reply too late), then CA DLP deems that they have heeded the warning and the e-mail is not sent. The process is summarized in the sequence diagram opposite. i The warning timeout defaults to 4 hours. That is,
a user has 4 hours to reply if they want to disregard the warning and send their e-mail anyway. But this timeout is configurable—see page 255.

If you are using Exchange 2007, you need to set up your integration slightly differently—see the deployment procedure on page 253. To enable interactive warning messages in Exchange, you need to create a ‘Compliance Release’ mailbox on each Exchange server where you want interactive warning e-mails to work. This section describes how to: Create the necessary Exchange mailboxes used by the Exchange server agent to send warnings and receive replies to these warnings. i For Exchange Server 2007, you only need to
create one mailbox account for each Active Directory site—see page 253.

` The user replied too late and the warning autoheed
timeout expired.

` The user replied to the warning more than once.
The first reply matches the original e-mail and allows it to be sent, which in turn, removes it from the Exchange server. Any subsequent replies therefore cannot be matched.

` The maximum number of pending warnings was
reached and the user was unable to reply to the warning message before it was autoheeded.

Configure the machine(s) hosting the Exchange server agent(s) to enable interactive warning messages. Define the content of the warning and ‘unmatched response’ messages seen by the sender.

` Exchange 2007 only. The agent holding the
pending e-mail and the agent holding the response e-mail cannot communicate. i If using Exchange 2007, you need to set up this
feature slightly differently than for Exchange 2003— see the two diagrams on page 252.

252

CA DLP Deployment guide

Exchange Server 2003
If using Exchange Server 2003, the CA DLP Exchange server agent must exist on the Exchange server to enable integration for interactive server-side warnings. E-mail sender Exchange server a b

Exchange Server 2007
Exchange Server 2007 is a modular system comprising five server ‘roles’. This may result in your Exchange ‘site’ including multiple Hub Transport Servers. To enable integration with Exchange Server 2007, the Exchange server agent must exist on each Hub Transport Server. E-mail sender Hub Transport Servers a b

1 Original e-mail a 2 Warning a b b

3 Reply

1 Original e-mail

4 No reply

2 Warning

Server-side interactive warnings 1. A user sends an e-mail. As it transits through Exchange (a), it is detected by the Exchange server agent (b) and triggers a warning. 2. The Exchange server agent sends a warning e-mail, with the offending original e-mail included as an attachment. 3. If the sender replies to the warning, their e-mail is released and sent on to its intended recipients. The event is saved on the CMS as a ‘disregarded warning’. 4. If the sender does not reply before the warning timeout expires, the e-mail is not sent. The event is saved on the CMS as a ‘heeded warning’.

3 Reply

4 No reply

Server-side interactive warnings 1. A user sends an e-mail. As it transits through Exchange (a), it is detected by the Exchange server agent (b) on one of the Hub Transport Servers and triggers a warning. 2. The Exchange server agent sends a warning e-mail, with the offending original e-mail included as an attachment. 3. If the sender replies to the warning, their e-mail is released and sent on to its intended recipients. The event is saved on the CMS as a ‘disregarded warning’. 4. If the sender does not reply before the warning timeout expires, the e-mail is not sent. The event is saved on the CMS as a ‘heeded warning’.

Chapter 14 E-mail server agents

253

Deployment procedure
To set up the Exchange server agent to send interactive warning e-mails, you need to do the following: Exchange Server 2007 only The first step to setting up interactive warnings on your Hub Transport Servers is to create a Compliance Release mailbox account for the Active Directory site. This account must then be associated with a mailbox hosted by that site. To enable CA DLP to identify e-mails destined for this mailbox, the mailbox must have ‘cadlp.’ as the first element of an SMTP address. For example: cadlp.<ExchangeSite>@<YourDomain> To create a Compliance Release mailbox 1 In Exchange, create a new user. i You must ensure that this user is a
mailbox-enabled user.

1

Create Compliance Release mailbox

2a

Exchange Server 2003 only: Configure Exchange server agent to use Compliance Release mailbox

2b

Exchange Server 2007 only: Configure Exchange server agent on Hub Transport Servers to use Compliance Release mailbox

2 3 Define message templates

We recommend you specify an Exchange mailbox alias that starts with cadlp.<servername>. i For Exchange Server 2007 machines, we recommend cadlp.<sitename>.

4

Enable interactive warnings

3

Interactive warnings deployment procedure These steps are described on the following pages.

We also recommend you change the mailbox Display Name (or Full Name), for example, to ‘Compliance Release’. This is the name displayed in the To: field in the user’s reply to a warning message. i
This name can be changed either while creating the user, or afterwards.

Create a Compliance Release mailbox
Exchange Server 2003 The first step to setting up interactive warnings on your Exchange server is to create a Compliance Release mailbox on every Exchange server you want to configure for interactive warnings. To enable CA DLP to identify e-mails destined for this mailbox, the mailbox must have ‘cadlp.’ as the first element of an SMTP address. For example: cadlp.<ExchangeServer>@<YourDomain>

4

You need to manually add to the mailbox user an SMTP address that conforms to the above recommendations if:

` Either the Exchange Server does

not have a

recipient policy that automatically creates an SMTP address based on the Exchange mailbox alias (that is, with %m in the userformat),

` Or you have
steps 2 and 3,

not followed the recommendation in

If neither conditions are true, you do not need to manually add an SMTP address.

254

CA DLP Deployment guide

Specify the Compliance Release mailbox
The Exchange server agent needs to know which mailbox to use for interactive warning e-mails and replies to these warnings. Exchange Server 2003 only To configure the Exchange server agent to use the Compliance Release mailbox, you must set the LocalMailboxSMTPAddress registry value on the Exchange server host machine to the SMTP address of the Compliance Release mailbox created in the previous section. For registry details, see page 241. Exchange Server 2007 only To configure an Exchange server agent to use the Compliance Release mailbox, you must set the LocalMailboxSMTPAddress registry value on its Hub Transport Server to the SMTP address of the Compliance Release mailbox created in the previous section. For registry details, see page 241. i You need to configure this registry value on all
Hub Transport Servers where you want to use interactive warnings.

Define the message templates
You now need to set up the templates for the warning message and ‘unmatched response’ follow-up message. The body text for the warning message and ‘unmatched response’ follow-up message is specified in two separate text files. These template files, WarningTemplate.txt and UnmatchedResponseTemplate.txt, are installed with the Exchange server agent into the following folder on the machine hosting the server agent: \Program Files\CA\CA DLP\Client i For Exchange Server 2007, the machine hosting the
Exchange server agent is the Hub Transport Server.

You can also specify the subject field for the ‘unmatched response’ follow-up message. For details about defining the text content of these templates, see the Administration console online help; search the index for ‘interactive warnings’. To enable the Exchange server agent to access these message templates, you need to configure the following registry values; see page 241 for full details. UnmatchedResponseTemplateFile WarningTemplateFile UnmatchedResponseTitle i For Exchange Server 2007, you need to configure
these registry values on the Exchange Server agent on each Hub Transport Server.

! You must then set the UpdateConfig registry
value to 1 for changes to this value to take effect— see page 245.

! You must then set the UpdateConfig registry
value to 1 for changes to this value to take effect— see page 245.

Chapter 14 E-mail server agents

255

Enable interactive warnings
Exchange 2003 only Finally, you need to turn on support for interactive warnings on the Exchange server. To allow the Exchange server agent to send interactive warning e-mails, you must configure the EnableInteractiveWarnings registry value on the Exchange server host machine. If required, you can also modify the default timeout for heeded warnings. To do this, you must modify the WarningHeedTimeoutMins registry value. i For full registry details, see page 241. Exchange Server 2007 only Finally, you need to turn on support for interactive warnings on each Exchange server. To allow an Exchange server agent to send interactive warning e-mails, you must configure the EnableInteractiveWarnings registry value on the Exchange server agent on each Hub Transport Server. If required, you can also modify the default timeout for heeded warnings. To do this, you must modify the WarningHeedTimeoutMins registry value. ! You must then set the UpdateConfig registry
value to 1 for changes to this value to take effect— see page 245.

Monitor the Exchange and Domino server agents
There are various sources of diagnostic information when monitoring the e-mail server agent, including log files and diagnostic files. Performance counters are also available for: Policy engine hubs—see page 225. Policy engines—see page 210.

Log files
The Exchange and Domino server agents write log entries to the following log files: Exchange 2003: WgnSmtpS_<date>.log Exchange 2007: WgnESA_<date>.log Domino: WgnEMNO_<date>.log You configure the log level by editing the registry—see page 243.

Diagnostic files for Exchange server agent
The Exchange server agent can be configured to generate ‘diagnostic’ files when extracting the contents of an e-mail. You can specify that diagnostic files are always created, only created if an error occurs, or never created at all. For details, see the following registry values on page 247: DiagnosticFolder CreateEML CreateEVF i Equivalent diagnostic files are not currently
supported for the Domino server agent.

i For full registry details, see page 241.

256

CA DLP Deployment guide

Uninstall Exchange or Domino server agents
! If a policy engine is installed on the same
computer as an Exchange, Domino, or Enterprise Vault server agent, you must uninstall the server agent before uninstalling the policy engine. To uninstall policy engines, see page 210.

Exchange 2003 server agent and IIS
When uninstalling the Exchange server agent, the wizard stops Internet Information Services (IIS) before uninstalling the Exchange server agent and hub components. It then restarts IIS automatically when the uninstall is complete. i IIS is stopped and started automatically as part of
an Exchange Server installation.

When you uninstall an e-mail server agent, the hub is also uninstalled automatically. Use Add/Remove Programs to manually uninstall the Exchange or Domino server agents. This applet is part of the Control Panel. 1 In Add/Remove Programs, select CA DLP Integration Agents and click Change. When the wizard starts, go to the Program Maintenance screen and choose Modify. i If you choose Remove, this removes all CA DLP
components, not just the Exchange or Domino server agents.

Exchange 2007 server agent and the Microsoft Exchange Transport Service
When uninstalling the Exchange server agent, the wizard stops the Microsoft Exchange Transport Service before uninstalling the Exchange server agent and hub components. It then restarts this service automatically when the uninstall is complete. i The Microsoft Exchange Transport Service is
stopped and started automatically as part of an Exchange Server 2007 installation.

2

3

In the Custom Setup screen, choose the Exchange Server Agent or Domino Server Agent, as required. In the final wizard screen, click Install to being the uninstallation.

4

run setup. These registry values are described on page 241. Find this in the \Integration folder on your CA DLP distribution media. see page 225. click Install to start the file transfer. Install the IIS SMTP agent You install the IIS SMTP agent using the CA DLP Integration Agents installation wizard. To configure the agent. . Other registry values determine how the agent handles event failures and out-of-memory failures. see page 250. A policy engine hub is also installed automatically when you install the server agent. enables CA DLP to monitor and control e-mails transiting through Microsoft IIS SMTP servers. Host machine requirements The SMTP server hosting the IIS SMTP agent must be running Microsoft Internet Information Services (IIS). The IIS SMTP agent can also be configured to send interactive warning messages. expand the Server Agents branch and choose IIS SMTP Agent. you edit the EnableIntegration registry value. you can turn on integration with IIS SMTP. For details about deploying the IIS SMTP agent. In the Custom Setup screen. 4 In the final wizard screen. and the IIS SMTP agent enables CA DLP to analyze e-mails leaving the company or arriving from an external source. 5 Configure the IIS SMTP agent Configuration for the IIS SMTP agent is very similar to that for the Exchange server agent. see page 258. When this is done. i This functionality was previously only available in OEM versions of CA DLP as the SMTP Relay Agent. see page 23.dll.com’). Further registry changes are needed if you are using the IIS SMTP agent to host a CA DLP service for use by other organizations. please contact Technical Support. you can tailor the IIS SMTP agent to only monitor e-mails sent from particular SMTP addresses (such as addresses ending with ‘@unipraxis. WgnSMTPS. i If you subsequently need to change these credentials. These servers typically operate at the Internet boundary. you modify values in this registry key: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Exchange For example. In the Policy Engine Hub Configuration screen.exe. 1 To launch the Integration Agents installation wizard.Chapter 14 E-mail server agents 257 IIS SMTP integration The IIS SMTP agent. provide the credentials for the PE domain user (as specified on page 203). You now need to configure the server agent and policy engine hub (see the next sections). Namely. 2 3 Turn on ISS SMTP integration The IIS SMTP agent uses the same mechanism as the Exchange server agent to turn on e-mail integration.

you need to edit the Agent registry value. further subkeys for each organization using the hosted CA DLP solution. see the next section. Give each a subkey a name that reflects the organization. In this situation. you can provide a hosted CA DLP solution for use by other organizations. each containing its own domain mapping registry values plus values for handling e-mails from unrecognized senders. Specifically. with each organization subkey. .258 CA DLP Deployment guide Hosting a CA DLP service for use by other organizations Using the IIS SMTP. This subkey will contain the subkeys for each organization using the hosted CA DLP service. you need to create a separate subkey for each organization using the hosted CA DLP service. It passes this information with the e-mail to a policy engine to ensure that policy specific to that organization gets applied to the e-mail. Next. the IIS SMTP is configured to identify which organization an e-mail sender belongs to. <Organization> subkeys Within the DomainMapping subkey. for Global Corp and Unipraxis. you need to create a DomainMapping registry subkey plus. See the example registry diagram opposite. To set this up. see the example diagram opposite. you need to create the following registry values: Domains InternalAddressPattern UnknownInternalSender ExternalSender SecurityID These values are described on the following page. see page 242. My Computer HKEY_LOCAL_MACHINE Exchange Agent DomainMapping Global Corp Domains InternalAddressPattern UnknownInternalSender ExternalSender SecurityID Unipraxis Domains InternalAddressPattern UnknownInternalSender ExternalSender SecurityID Agent registry value Before creating the DomainMapping subkey. The path to each organization subkey is as follows: HKEY_LOCAL_MACHINE\SOFTWARE\ \ComputerAssociates\CA DLP \CurrentVersion\Exchange \DomainMapping\<Organization> These organization subkeys each contain a registry value that associates specific domains with the organization. within this subkey. DomainMapping registry subkey First. IIS SMTP agent registry: Example domain mapping registry keys This example shows two organization subkeys. you need to manually add a DomainMapping subkey below the Exchange registry key referred to on page 257. plus registry values to determine which user policies get applied to e-mails from unrecognized senders. you need to edit the registry on the machine hosting the IIS SMTP agent.

If this value is not set. see page 207. policy engines apply this user’s policy to external e-mails. If set. ensuring that reviewers can only retrieve events for their organization. The policy engine applies the UnknownInternalSender policy if the sender’s address matches an address pattern listed in InternalAddressPattern (see above) but no corresponding user exists. as specified by the registry values below. When the IIS SMTP agent detects a sender address from a listed domain. This security ID is used to segregate events on the CMS. If set. When it passes the e-mail to a policy engine for processing. SecurityID SecurityID Type: REG_SZ Data: Specifies a security ID that is stored with all events associated with the current organization. policy engines revert to the Unknown Internal Sender setting to determine which policy apply. policy engines apply this user’s policy to e-mails sent from someone within the organization. policy engines revert to the Internal Address Pattern setting to determine which policy apply. e-mails sent from someone outside the organization. If this value is set. the policy engine attempts to map the sender onto an existing CA DLP user account. If this value is set. policy engines revert to the External Sender setting to determine which policy apply. If this value is not set. If this value is not set. If set. UnknownInternalSender UnknownInternalSender Type: REG_SZ Data: This registry value specifies the name of a CA DLP user. a policy engine checks the sender’s e-mail address against this address pattern when it first processes an e-mail. . this registry value overrides the corresponding Internal Address Pattern setting in the policy engine’s machine policy. That is. If the sender’s address does match this pattern.Chapter 14 E-mail server agents 259 Domains Domains Type: REG_MULTI_SZ Data: This registry value specifies a list of domain names associated with the current organization. this registry value overrides the corresponding External Sender setting in the policy engine’s machine policy. see page 206. see page 206. InternalAddressPattern InternalAddressPattern Type: REG_SZ Data: This registry value specifies a full or partial e-mail address. The policy engine applies the ExternalSender policy if the sender’s address does not match an address pattern listed in InternalAddressPattern (see above). it also passes that organization’s message handling details. If this value is set. this registry value overrides the corresponding Unknown Internal Sender setting in the policy engine’s machine policy. it associates that e-mail with the relevant organization. ExternalSender ExternalSender Type: REG_SZ Data: This registry value specifies the name of a CA DLP user.

The Milter MTA agent uses the Sendmail Mail Filter API (milter) to access e-mails as they transit through Sendmail or Postfix. to the Bcc field. Deployment process Before you can deploy the Milter MTA agent. you cannot differentiate between internal and external recipients when moving addresses the Bcc field. Moving e-mail recipients to Bcc list For e-mails detected by the Milter MTA agent. CA DLP can automatically send a warning e-mail to the sender. The diagram below summarizes the key deployment tasks: 1 Deploy policy engines 2 Deploy Socket API and PE hub 3 Deploy Milter MTA agent Specify Milter user account Configure Sendmail or Postfix Install Milter MTA agent Configure Milter MTA agent Applying policy triggers to Sendmail and Postfix e-mails When policy engines process e-mails captured by the Milter MTA agent. i Warning e-mails are sent if the Milter MTA agent blocks an e-mail. CA DLP integration with Sendmail and Postfix is implemented through its Milter MTA agent. You must also deploy the CA DLP Socket API. this agent can reside directly on the Sendmail and Postfix server or on a remote Linux machine. (Normally. connecting to the e-mail server via a socket. they apply Outgoing E-mail policy triggers. 2 Installing the Socket API and a remote PE connector (that is. Sendmail is a mail transfer agent (MTA) originating from the open source and Unix communities. Postfix is intended to be an easy-to-administer. That is. such server-side warnings are not supported for e-mails detected by the Milter MTA agent. secure alternative to the Sendmail MTA. The milter allows third-party applications access to e-mails as they are processed in order to filter meta-information and content. But be aware of the following limitations: Server-side warnings are not supported For e-mails detected by the Exchange server agent that generate a warning event. 4 Turn on Sendmail or Postfix integration MTA Milter agent deployment process 1 Policy engine deployment tasks are described in chapter 11. However. or only external recipients.) . you must first deploy your policy engines and. you can move all or none of the recipients. optionally. a PE hub) are described in chapter 17. see page 370. Configuring the hub is described in chapter 12. a policy engine hub. Both are used to route and deliver e-mail and provide additional services such as protecting organizations from unwanted messages (spam). Address Modification settings in outgoing e-mail control actions let you move all recipients. 3 and 4 These deployment tasks for the Milter MTA agent are described on the following pages in this chapter.260 CA DLP Deployment guide Sendmail and Postfix integration CA DLP can integrate with Sendmail and Postfix.

i The External Agent API enables third party applications to pass messages to CA DLP for policy processing. the Milter MTA agent uses the CA DLP Socket API to call the CA DLP External Agent. This agent can reside directly on the Sendmail or Postfix e-mail server or. For details. This integration is enabled through the CA DLP Milter MTA agent. Sendmail and Postfix integration In a typical Sendmail or Postfix deployment: 1 E-mails sent internally transit through an Exchange or Domino server (1a). 1 Exchange server 1a 1b 4 Socket API and Remote PE Connector 4a 4b 5 Policy Engines 2 Sendmail/Postfix server Postfix Sendmail 3 Milter MTA agent Internet 3 Hosted on a Linux machine. This example shows a local hub. and may be processed by a CA DLP server agent (1b). which in turn relays any resulting actions back to the Sendmail or Postfix server. 4 Hosted on a Windows machine. Alternatively. as in this example. the Socket API (4a) sends Sendmail or Postfix e-mails to a local policy engine or hub (4b). policy engine hubs are technically known as Remote PE Connectors). . (When installed with the Socket API.Chapter 14 E-mail server agents 261 Deployment architecture The diagram below summarizes the deployment architecture for CA DLP integration with Sendmail or Postfix. The hub then distributes the Sendmail or Postfix e-mails to policy engines for processing. on a separate Linux machine. These messages are forwarded to the CA DLP Milter MTA agent. To enable communication between Unix or Linux machines and the CA DLP policy engines running on Windows servers. the External Agent can pass e-mails directly to a local policy engine (not shown in the diagram below). 5 The hub then distributes e-mails to policy engines for processing. the Milter MTA agent uses the Socket API (4a) to pass e-mails to CA DLP. i Milters are e-mail filtering programs supported by Sendmail and Postfix. E-mails leaving the company or arriving from an external source are processed by Sendmail or Postfix. The results of any policy processing are returned via the hub to the Milter MTA agent. 2 The Sendmail or Postfix MTA operates at the Internet boundary. to block spam. for example. see page 369. The External Agent in turn establishes a connection with a local policy engine hub. They are widely used to filter incoming e-mails.

262 CA DLP Deployment guide Host machine requirements The Milter MTA agent has been tested using the Linux and Sendmail combinations listed below. this hub then distributes e-mails to remote policy engines for processing. ‘Policy engines’. You can either specify an existing user as your Milter user or you can create a new user. the Milter MTA agent uses a statically compiled libmilter (version 8. For example.0 or later (but see below). but this has not been tested. ‘Policy engine hubs’. However. the Milter MTA agent uses this library.conf (see page 266). Deploy the Socket API and a remote PE connector The Milter MTA agent uses the CA DLP Socket API to pass Sendmail or Postfix e-mails to: A local policy engine. the agent may not work with libmilter. Configure the hub This is described in chapter 12.13.0 onwards.13. If this library is not present.8).2 and later).13.14. We have also successfully connected a Milter MTA agent to Sendmail running on a remote Solaris server. But if libmilter. see page 370 for details. compatible with all versions of Sendmail from 8. The Milter MTA agent may work with other combinations. This is described in chapter 17. Sendmail: The Milter MTA agent supports Sendmail 8. we use the term ‘Milter user’ to describe the user account used by the Milter MTA agent. due to a known issue with the Milter API. You must specify this user when you install the Milter MTA agent.0 or 8. We recommend that you deploy your policy engines before you deploy the policy engine hub—see the next section. please contact Technical Support.so is already present. In particular. the Milter MTA agent checks for the presence of the Milter API shared library. you must do so before you install the Milter MTA agent—see page 264. Linux: The Milter MTA agent has been tested on the following systems: Ubuntu 6. Milter API Library requirements: During installation. See page 201 for details.04 and Red Hat Enterprise Linux 4 Server. see page 23. Configure Postfix For Postfix configuration instructions.so.so 8. You will reference this port number when you install the Milter MTA agent (see step 8 on page 265) or when you edit the port parameters in wgnmilter. libmilter. See page 217 for details. Throughout this chapter. . to create a new Milter user run this command as root: useradd miltuser Deploy policy engines This is described in chapter 11. Postfix: We expect the Milter MTA agent to integrate successfully with Postfix. Install the Socket API and a hub You can install the Socket API and a Remote PE Connector when you install the External Agent API. or A Remote PE Connector. but these have not been tested. This a policy engine hub running on the same machine as the External Agent. If you create a new user. when you install the Socket API you must specify which port number to use for the socket connection between the Milter MTA agent and the External Agent. This is your ‘Milter user’.14. Create user for Milter MTA agent The Milter MTA agent must run as a designated user (it will not run as root).1 (this issue is fixed in version 8.04 and 8.14.

Command syntax The command syntax is: INPUT_MAIL_FILTER ('WgnMilter'. It takes these formats: Either: local:<path>/wgnilter.<comm_fail>] [. <timeouts> is an optional parameter for changing the default time-outs associated with the Milter MTA agent. If set to F=T then Sendmail temporarily fails any e-mail arriving through the SMTP connection. This defaults to 10 seconds. This timeout defaults to 5 minutes. see page 266 for parameter details. <comm_fail> is an optional parameter that determines how Sendmail handles e-mails when the Milter MTA agent is not running or when there is a communication failure with the Milter MTA agent.S:<t>. See the example socket commands on page 264. This covers the period from when an e-mail is first submitted to the Milter MTA agent until the results of policy processing are returned to Sendmail or Postfix. It can take any combination of the following parameters. To ensure that Sendmail does not resubmit e-mails unnecessarily to the Milter MTA agent. it is processed by CA DLP as normal. For example. i The socket identifier in sendmail. This defaults to 5 minutes.R:<t> C The connection timeout from Sendmail to the Milter MTA agent. 90s is a 90 second timeout. Otherwise.sock Or: inet:<port>@<Agent host server> Use the local: format if the Milter MTA agent is installed directly on a Sendfix or Postmail server.mc file on the Sendmail server. . note that the specified <port> number must not be used by another application. The source e-mail server (Exchange or Domino) automatically resends the e-mails at predefined intervals. This defaults to 10 seconds. see page 264. 5m is a five minute timeout. R The timeout for receiving a reply from the Milter MTA agent. It can be set to F=R. if the Milter MTA agent has restarted when the e-mail is resent. you must add a line to the sendmail.conf (see page 268). suffixed with m or s to indicate minutes or seconds. This line identifies the socket used for communication between Sendmail and the Milter MTA. Sender of rejected e-mails eventually receives an ‘undeliverable message’ notification. this 'E' timeout must be longer than the max-time-per-mail timeout specified in wgnmilter. S The timeout for sending individual data packets to the Milter MTA agent. <t> is the timeout value. If set to F=R then Sendmail rejects all e-mails arriving through the SMTP connection from Exchange or Domino.<timeouts>] ')dnl Where <socket> locates the socket used to communicate with the Milter MTA agent. F=T or omitted entirely. use inet: to specify an Internet socket.Chapter 14 E-mail server agents 263 Configure Sendmail integration Before you install the Milter MTA agent. in any order: T=C:<t>. If the entire parameter is omitted. i You may need to lengthen the default timeouts to allow time for policy processing.E:<t>.'S=<socket> [. For example.mc file must match the socket parameter specified in wgnmilter.conf. E The overall timeout for an e-mail. e-mails transit through Sendmail without intervention.

my. you are prompted for details about the Milter user.com. If the Milter MTA agent is not running. Installation directory: Specify the directory where you want to install the Milter MTA agent.com. miltuser).sh Where <mount> is the mount point. e-mails arriving from an Exchange or Domino server are pass through Sendmail without intervention. INPUT_MAIL_FILTER ('WgnMilter'. and uses port 8600 to communicate with the Sendmail server. When this is complete. installation directory and socket connection: 1 As root. If the Milter MTA agent is not running. The Milter MTA agent runs as this user.E:10m' )dnl Install the Milter MTA agent When you install the Milter MTA agent. INPUT_MAIL_FILTER ('WgnMilter'. The time-outs are the same as for the ‘local socket’ example.R:10m. For example: <mount>/lin_i/WgnMilter/install. Sendmail rejects e-mails arriving from an Exchange or Domino server. run this shell command: <path>/install. For this example.sh prompts you for the following details. F=R.sh file. 2 Wait while the installation files are extracted.R:10m. the Send timeout is set to five minutes while the Receive and Overall time-outs are set to 10 minutes. T=S:5m. 'S=inet:8600@milter. T=S:5m.E:10m' )dnl 3 4 5 (Installation steps continue on page 265.sh Where <path> specifies the mount point of the CA DLP distribution media containing the install.) . Existing mail agent user: Specify the ‘Milter user’ you chose or created on page 262 (for example.sock. It also overrides the default time-outs. install.my. the Milter MTA agent is hosted on milter. Sendmail or Postfix: Specify whether you are installing an integration agent for Sendmail or Postfix (options 1 and 2 respectively).264 CA DLP Deployment guide Example socket commands Local socket: The following example command specifies a local socket in the /opt/milt directory. 'S=local:/opt/milt/wgnmilter. if there is a communication failure between Sendmail or Postfix and the Milter MTA agent. For example: /opt/milt Internet socket: You must specify an Internet socket if the Milter MTA agent runs on a different machine from the Sendmail server.

For example: inet:8600@milter. It is installed into the installation directory you specified in step 5. you can specify a secondary Socket API on a separate machine to ensure high availability. This is the Milter MTA agent configuration file. You will need to edit this file to configure the agent—see page 266.sh now lists a summary of the Milter MTA agent details. 9 Configure a secondary Socket agent: If required. If you type y.com 7 IP address of Socket agent host machine: Enter the IP address of the machine hosting the CA DLP Socket API. the install. See page 270 for details. Run this script to uninstall the Milter MTA agent. Otherwise.com).mc on page 263. Run this script to update the Milter MTA agent with changed configuration details. Specify a local socket if you are installing the Milter MTA agent directly onto the Sendmail or Postfix server.conf. Or you can accept the default port (8538). ` RunWgnMilter script. /opt/milt).my.sh script installs the following items to the installation directory you specified in step 5: ` Internet socket: The syntax takes this format: inet:<port>@<agent host server> For Internet sockets. the installation script prompts you for the IP address and port number on the machine hosting the secondary Socket API. You can identify the Milter MTA agent host server by IP address or name (such as milter.sock It defaults to the installation directory you specified in step 5 (in this case. 8 . you can do so now.Chapter 14 E-mail server agents 265 6 Socket identifier for Sendmail: Specify the socket that will be used for communication between Sendmail and the Milter MTA agent. Type y or n to indicate whether or not you want to configure a secondary Socket API. the specified <port> number must not be used by another application. ` Scripts to automatically start and stop the Milter MTA agent when the host machine starts up or shuts down. In particular. the Milter MTA agent will automatically switch to the secondary Socket API. confirm the details to begin the file transfer. Socket agent port number: Enter the port number for the listening port on the Socket API host server. but you can specify an alternative location if required. If your primary Socket API (step 7) becomes unavailable for any reason. i Press Enter to accept the default port number. ` uninstall script. If you need to amend any details. Specify an Internet socket if you are installing the Milter MTA agent on a separate Linux machine. see page 270 for details. Note that this socket is created and deleted when you start and stop the Milter MTA agent—see page 270. ` Local socket: The socket syntax takes this format: local:/opt/milt/wgnmilter. see page 270. ` wgnmilter. ! This identifier must match the socket specified in sendmail. 10 install.my.

Set this parameter to: 0 To turn off integration.my.com .mc on page 263. This disables the Milter MTA agent.my. the specified <port> number must not be used by another application. ` Local socket: The socket syntax takes this format: local:/opt/milt/wgnmilter. Specify a local socket if you are installing the Milter MTA agent directly onto the Sendmail or Postfix server. You can identify the Milter MTA agent host server by IP address or name (such as milter. i These parameters are not case-sensitive. 1 To turn on CA DLP integration with Sendmail or Postfix. This parameter turns integration on or off. But after installation.conf. this configuration file is created in the installation directory for the Milter MTA agent (see step 5 on page 264).conf parameters The table below lists the configuration parameters supported in wgnmilter. milter-socket=<socket> Parameter enable-integration milter-socket primary-policy-ipaddress primary-policy-port secondary-policy-ipaddress secondary-policy-port email-failure-mode max-time-per-mail sys-log-level diagnostic-folder create-eml max-time-per-mail=<number> enterprise-dns-list smtp-dns-hostname Page 267 266 267 267 267 267 267 268 267 268 268 268 269 269 Wgnmilter.sock ` Internet socket: The syntax takes this format: inet:<port>@<Agent host server> For Internet sockets.266 CA DLP Deployment guide Configure the Milter MTA agent You supply basic configuration details when you install the Milter MTA agent (see page 264). milter-socket=<socket> This mandatory parameter specifies the socket that the Milter MTA agent uses to communicate with the Sendmail or Postfix server.conf. Specify an Internet socket if you are installing the Milter MTA agent on a separate Linux machine. enable-integration=0 or 1 enable-integration=0 or 1 Defaults to 0 (zero). you can fine-tune the agent configuration by manually editing parameters in wgnmilter.com). For example: inet:8600@milter. This parameter can specify a local socket or an Internet socket. so that e-mails are allowed to transit through Sendmail or Postfix without intervention from CA DLP. ! This parameter must match the socket specified in sendmail. It corresponds to installation step 6 on page 265.

It corresponds to installation step 9 on page 265. This prevents a downstream CA DLP agent from re-processing the e-mail. The supported logging levels are: 0 Emergency 1 Alert 2 Critical 3 Errors 4 Warnings 5 Notices 6 Information 7 Debug i Logging levels are cumulative so. It corresponds to installation step 9 on page 265. It corresponds to installation step 8 on page 265. you can configure the Milter MTA agent to only log alerts and emergency messages—but see the note below. logging level 2 causes critical messages. . secondary-policy-port=<port number> secondary-policy-port=<port number> This optional parameter specifies the port number for the listening port on the machine hosting the secondary Socket API. E-mail failures can occur when: ` Either of the hub’s HighWaterMarkEventCount or HighWaterMarkMB thresholds are exceeded (see page 219) and the HubFailureMode registry value flags all subsequent e-mails as failures. It corresponds to installation step 7 on page 265. ` Mark. Allow. email-failure-mode=<action> email-failure-mode=<action> This parameter can be set to Delete. If set to: ` Delete. the Milter MTA agent allows the e-mail to transit through Sendmail or Postfix without intervention. It defaults to Allow. or Mark. ` Allow. Log messages are written to syslog. the Milter MTA agent allows the e-mail to transit through Sendmail or Postfix without intervention. It specifies how the Milter MTA agent handles event failures. for example. but marks it as if it had been processed normally.Chapter 14 E-mail server agents 267 primary-policy-ipaddress=<IP address> primary-policy-ipaddress=<IP address> This mandatory parameter specifies the IP address of the machine hosting the Socket API. secondary-policy-ipaddress=<IP address> secondary-policy-ipaddress=<IP address> This optional parameter specifies the IP address of the machine hosting the secondary Socket API. sys-log-level=0 through 7 sys-log-level=0 through 7 Defaults to 5. or ` The GlobalEventTimeoutSeconds hub timeout expires (see page 219). the Milter MTA agent deletes the e-mail without notifying the sender. primary-policy-port=<port number> primary-policy-port=<port number> This mandatory parameter specifies the port number for the listening port on the Socket API host machine. alerts and emergency messages to be written to syslog. For example. This parameter determines the logging level for e-mail processing. or ` There is a general failure when the policy engine analyzes the e-mail.

For example. 1 Diagnostic files are always created for each e-mail processed by the Milter MTA agent. the Milter MTA agent monitors all e-mails passing through Sendmail or Postfix. a *unipraxis* filter will match spencer@sales. no other users will be affected. spen?er matches Spencer or Spenser. no diagnostic files are created. if you only want to monitor e-mails sent from the unipraxis. This timeout covers the period from when an e-mail is first received by the Milter MTA agent until the results of policy processing are returned to Sendmail or Postfix.com. To ensure that Sendmail does not resubmit e-mails unnecessarily to the Milter MTA agent.unipraxis. For example. the minimum permitted value is 15. 1 or 2 create-eml=0. A ? wildcard will match any digit. if you want to test that integration with Sendmail or Postfix is working correctly before you go live. If the sender’s e-mail address does not match any item in this list. even if create-eml is set (see below). A * wildcard will match any sequence of zero or more digits. letter or punctuation character. and an SMTP file. set this parameter to: diagnostic-folder=/opt/WgnMilter/diag Be aware that if this parameter (diagnosticfolder) is not set.268 CA DLP Deployment guide diagnostic-folder=<path> diagnostic-folder=<path> This locates the folder where diagnostic files are written to. This parameter specifies the maximum processing time (in seconds) for each e-mail. This value specifies a comma separated list of SMTP addresses for the Milter MTA agent to filter against. you can specify the full address of a test user. you need only set this value to ‘unipraxis’. this can happen if an event times out while waiting to be processed by a policy engine. the Milter MTA agent disregards the e-mail and allows the e-mail to transit through Sendmail or Postfix without intervention. 1 or 2 Defaults to 0. For example. Similarly. By default. containing the ‘raw’ MIME content of the e-mail. If create-eml is set to: 0 Diagnostic files are never created. sender-address-inclusion-filters sender-address-inclusion-filters= <address list> Defaults to *. Any diagnostic files created are saved in the diagnostic-folder (see above). It specifies whether to create diagnostic files containing the e-mails and associated data for e-mails processed by the Milter MTA agent. Note that * and ? wildcards are supported. 2 Diagnostic files are only created on error. This parameter is provided for diagnostic purposes. containing the sender and recipient details. This ensures that if there is problem with the integration. . letters or punctuation characters.mc (see page 263). create-eml=0. For example. max-time-per-mail=<number> max-time-per-mail=<number> Defaults to 600. for example. These diagnostic files comprise an EML file. this parameter must specify a timeout shorter than the 'E' timeout specified in sendmail.com domain.

UNIPRAXIS. In technical terms. this DNS domain is written to the MIME tag instead. You can optionally include this domain in the enterprise-dns-list domain list. this parameter overrides the DNS domain of the Sendmail or Postfix server in the MIME tag. Its purpose is to simplify the method for ensuring that e-mails are not reprocessed needlessly by consecutive CA DLP server agents. see page 271. i This parameter must be set to a valid DNS name that complies with RFC naming conventions. If set. the local Milter MTA agent does not reprocess e-mails arriving from this domain. when any Milter MTA agent receives an e-mail tagged as coming from UNIPRAXIS. How does this work? The local Milter MTA agent assumes each of the domains listed in enterprise-dns-list has its own CA DLP agent (that is. If the source domain matches a domain in enterprise-dns-list. When the local Milter MTA agent receives this e-mail.COM. an Exchange or Domino server agent. To use this parameter as intended. This parameter is always used in conjunction with enterprise-dns-list (see above). when a remote Milter MTA agent processes an e-mail. it knows that policy has already been applied to the e-mail and so does not reprocess it. it checks the MIME tag. Updating an empty list While this list is empty. . smtp-dns-hostname=<dns host> smtp-dns-hostname=<dns host> Defaults to empty. and that any e-mail arriving from a listed domain has already been processed by CA DLP and does not need reprocessing. without spaces or control characters (for example. the DNS domain of the local Sendmail or Postfix server is implied. the server agent does not reprocess the e-mail.Chapter 14 E-mail server agents 269 enterprise-dns-list=<domain list> enterprise-dns-list=<domain list> Defaults to empty. tab spaces). but see ‘Updating an empty list’ below. i For examples of how the equivalent registry value is used for the Exchange or Domino server agent. It is typically used in conjunction with smtp-dns-hostname (see page 269). it writes the DNS domain of the Sendmail or Postfix server to the e-mail’s MIME tag. i Values in this list can only contain ASCII characters. Or. if the smtp-dns-hostname parameter (see page 269) has been configured. That is. Now. or a Milter MTA agent). This parameter specifies a list of DNS domains that you want to be considered as a single enterprise. see page 271.COM) for all your Milter MTA agents. Its purpose is to simplify the method for ensuring that e-mails are not reprocessed needlessly by consecutive Milter MTA agents. smtp-dns-hostname specifies a single DNS domain that is written to the e-mail’s MIME tag after it has been processed by the local Milter MTA agent. i For examples of how the equivalent registry value is used for the Exchange or Domino server agent. you need to set smtp-dns-hostname to the same DNS domain (for example.

d/wgnmilter stop /etc/init. X To turn on e-mail integration To turn on integration and enable e-mail processing. you can specify that Sendmail either rejects or temporarily fails e-mails arriving from an Exchange or Domino server. see step 5 on page 264).d folder. Find this script in the /init. run the wgnmilter script installed with the agent (see step 10 on page 265). enable-integration. That is. when you configure Sendmail by editing sendmail. but does not process the e-mails passed to it from Sendmail or Postfix (which still run as normal). Uninstall the Milter MTA agent Run this command as root (the uninstall script is in the installation directory. This parameter is in wgnmilter. or you can start or stop the Milter MTA agent. to disable or enable e-mail integration with Sendmail or Postfix. or restart. If you disable integration. set this line to: enable-integration=0 2 Run either of these commands: Configure how Sendmail handles e-mails when the Milter MTA agent is stopped You can also configure Sendmail or Postfix to stop processing e-mails when the Milter MTA agent is stopped. Disable or enable integration The Milter MTA agent uses a single configuration parameter. on Red Hat machines the commands to stop or start the agent take this format: /etc/init.mc. you can configure Sendmail and Postfix to only send e-mails when the Milter MTA agent is running.conf. Note that this will not delete wgnmilter. then not only does the agent stop processing e-mails. you add an F=R or F=T option to the line that specifies the socket connection. RunWgnMilter –u RunWgnMilter ––updateconfig In both cases. set this line to: enable-integration=1 2 Run either of the following commands to update the Milter MTA agent with the new configuration: RunWgnMilter –u RunWgnMilter ––updateconfig Stop or start the Milter MTA agent To stop or start the Milter MTA agent. To do this.270 CA DLP Deployment guide Turn on Sendmail and Postfix integration You can either enable or disable CA DLP integration with Sendmail or Postfix.d/wgnmilter start X To turn off e-mail integration To turn off integration and allows e-mails to transit through Sendmail or Postfix without intervention: 1 In wgnmilter. see page 263. For details. If you stop the Milter MTA agent completely. but you can optionally configure Sendmail or Postfix to stop processing e-mails.conf or the diagnostic folders and files: uninstall . e-mail processing.conf. find the RunWgnMilter script in the installation directory that you specified in step 5 on page 264. You can use either method to stop. find this file in the installation directory (see step 5 on page 264). For example. for example /opt/milt.conf. the Milter MTA agent continues running. 1 In wgnmilter. Specifically.

UNIPRAXIS. when any Exchange server agent receives an e-mail tagged as coming from UNIPRAXIS. They want e-mails sent between US offices to be processed once. or between European offices. i If the Unipraxis Exchange servers are all in the UNIPRAXIS.COM.Chapter 14 E-mail server agents 271 E-mail integration issues When you deploy the Exchange or Domino server agents. On each host machine: SMTPDNSHostName is set to UNIPRAXIS. Unipraxis Corporation have a single worldwide domain. You can also use them to enforce selective repeat processing. you need to be aware of the following issues. and a second policy applied.COM. Now. SMTPDNSHostName and EnterpriseDNSList are set to UX-US. these registry values are set to UX-EUROPE. On all their European Exchange servers. Prevent users receiving multiple notifications from single e-mail This is documented in the known issue on page 543. i Guidelines for diagnosing any problems with Exchange Server or Domino integration are available in the Known issues chapter—see page 542. Specifically. See the following examples. and European policy applied.COM. This ensures that e-mails sent between US offices. Example 2: Selective repeat processing Prevent repeat processing by server agents in multiple domains You can use the EnterpriseDNSList and SMTPDNSHostName registry values (see page 243) to ensure that e-mails are not reprocessed needlessly by consecutive Exchange server agents. Example 1: Prevent repeat processing Unipraxis Corporation has Exchange Servers in multiple domains. By default. and each one hosts an Exchange server agent. EnterpriseDNSList includes UNIPRAXIS.COM.COM domain.COM in its domain list. On all their US Exchange servers. are processed once only. for example. each Exchange server agent infers that e-mails arriving from this domain have already been processed and will exclude them from processing. and the European domain not recognized by the US server agents. but e-mails sent to a European office to be processed a second time. you do not need to edit these registry values to prevent repeat processing. to configure a logical e-mail enterprise that is not constrained by its physical topology. but a CMS in the US and Europe. . it knows that policy has already been applied and so does not reprocess the e-mail. but e-mails sent between the US and Europe are reprocessed on arrival. the US domain is not recognized by the Exchange server agents in Europe.COM.

If you open one of these messages. i The Domino server agent does not currently support the CA DLP quarantine feature. the message will either be allowed (that is. the failure reason is listed as ‘Held for CA DLP’. depending on the EMailFailureMode registry value— see page 242 for details.272 CA DLP Deployment guide Using e-mail client agents and e-mail server agents together By default. . Exchange or Domino server agents do not reprocess e-mails that have already been processed by an Outlook or Notes client agent. when the message has been processed by a policy engine and returned to the Domino server agent. however. the message is automatically removed from the mail. support the quarantine feature. you must explicitly configure the Exchange server agent to reprocess (and apply quarantine actions to) e-mails already processed by a client agent. Consequently. ! If you are using Exchange Server 2007.box mailbox in Domino Administrator. they are temporarily listed in the mail. you must edit the EnableIntegration registry value on the Exchange server—for details. if the connection failure persists. Do not manually release these messages. you must set the UpdateConfig registry value to 1 for changes to this value to take effect—see page 245. This is particularly important if the hub cannot connect to a policy engine for any reason. see page 250. delivered as normal) or deleted. To enable the Quarantine feature in CA DLP installations that use both the Outlook client agent and Exchange server agent. Note that eventually. the message will be sent on to its intended recipients without being processed by the Domino server agent and a CA DLP policy engine.box mailbox in Domino Administrator. Do not release ‘dead’ messages in Domino Administrator Domino administrators need to be aware that messages waiting to be processed by the Domino server agent have their routing state marked as ‘dead’. any dead e-mails will automatically flagged as ‘deleted’ or ‘allowed’. if you do. The Milter MTA agent does. Eventually. In either case. To do this.

each hub uses the same pool of active and standby policy engines. In effect. 4 . which may differ for diagnostic purposes. Configure all Exchange server agents Exchange Server 2007 only You must ensure that the configuration for all Exchange 2007 server agents on Hub Transport Servers in an Active Directory Site is identical. Registry values CreateEML CreateEVF DiagnosticFolder LogLevel LogMaxNumFiles LogMaxSizeBytes NotificationFromAddress Page 247 247 247 243 244 244 248 1 In a clustered Exchange environment. CA DLP is now integrated with a single Exchange virtual server. i CA DLP integration with Exchange clusters has been tested with Exchange Server 2003 on a two node cluster. and requires only that the server agent and policy agent hub are installed on each cluster node. After you are satisfied with this configuration. each Exchange server agent must have identical registry values. The deployment procedure is simple.Chapter 14 E-mail server agents 273 Integration with an Exchange Server cluster The CA DLP Exchange server agent can integrate with an Exchange cluster. Now if the primary Exchange node fails over. install the CA DLP Exchange server agent and policy engine hub on the primary node. For example. The server agent and hub must be configured exactly the same as on the primary node! 2 Specifically. e-mail processing switches automatically to the Exchange server agent and policy engine hub on the secondary cluster node. The installation and configuration procedures are exactly the same as for a standard deployment—see pages 237 to 247. This completes the deployment. Similarly. the hubs on each cluster node must use the same credentials to access remote policy engines (set with the wgnphub -SetCredentials command) and have identical registry values. you must set the UpdateConfig registry value to 1 on each Hub Transport Server for any changes to take effect. Now install the Exchange server agent and policy engine hub on the secondary (and any additional) nodes. 3 Ensure that each hub service is correctly configured and running—see page 216. Exceptions to this rule are the following registry values.

274 CA DLP Deployment guide .

plus an overview of Data At Rest policy triggers. The FSA can scan and analyze files saved in local and remote file systems and apply appropriate controls. optionally. if required. or journal entries) and Microsoft SharePoint items (such as tasks or discussion boards). a NIST database (3). New or changed files are passed to a policy engine (4) for processing. see page 281. Data At Rest triggers analyze the files and. Finally. i For the current release. File Scanning Agent (FSA) File Scanning Agent (FSA) his chapter describes how to deploy the File Scanning Agent (FSA). the FSA then implements any applicable control actions. The FSA must be deployed in conjunction with CA DLP policy engines and a policy engine hub (see chapters 11 and 12 respectively). and enables CA DLP administrators to manage files alongside e-mail. apply smart tags (5). . It can also scan Exchange Public Folder data (such as. the FSA only supports SQL Server 2005 for the scanned file database and NIST database. calendar events. It provides a summary of the FSA architecture. IM and Web events within a common policy framework. The FSA extends CA's Intelligent Control Layer to cover data at rest. This chapter focuses on how to configure the FSA. Finally. tasks. the FSA can scan the text content of Oracle and SQL Server database records. installation and configuration instructions. the policy engine calls back to the FSA with the processing results. When processing is complete.15. chapter 15 T 2 3 1 6 5 4 FSA: scanning procedure for files The FSA (1) scans target folders (2) and checks files against records in the Scanned File database and. such as deleting specific files or copying them to a new location (6).

Which files can be scanned? The FSA can monitor files in specified folders on specified machines and can manage multiple scanning jobs simultaneously. Scanning offline files and folders can take a long time because the third party archive application must first retrieve the original files. and optionally when and how often the file scan runs. Which file types can be excluded? When you define a scanning job. making the scans highly efficient. System files and folders: If required.276 CA DLP Deployment guide About the FSA The FSA integrates CA DLP with the file systems used by your organization. Offline files and folders: The offline attribute indicates that the text content of a file (or files within a folder) has been archived by a third party application and the original file replaced with a stub file. It also specifies which user’s policy is applied to scanned files and. Web and IM events using the iConsole or Data Management console. To omit specific system files or folders from your scans. see page 292. When a scanning job runs. which users are stored in the CMS database as event participants. i The FSA only extracts text content if it is required for policy processing. In addition. analyze and apply appropriate policy controls to: Files saved in local or remote file systems Items stored in Exchange Public Folder Items hosted on Microsoft SharePoint sites Text entries and documents stored in SQL Server or Oracle databases. Data At Rest control actions can be configured to delete scanned files or copy or move them to an alternative location. The FSA uses Data At Rest triggers to analyze and apply policy to scanned items. These triggers can detect specific file names. Scanning jobs are described on pages 294 to 298. You can therefore configure the FSA to ignore offline files and folders. optionally. You can also specify whether to scan subfolders. hidden and offline folders and files. we recommend you exclude them individually in the job definition. For details. folders and files are scanned. . All file events captured by the FSA can be viewed alongside existing e-mail. date last modified. Scanning jobs A scanning job definition defines which machines. and the document author. add smart tags. you can exclude system files and folders. an event is generated for each scanned item that causes a Data At Rest trigger to fire. File system scans These are identified in the FSA Job Definition wizard as ‘Drives and folders’ scans. It is designed to scan. analyze the text content. and (by using XML Attribute lookup commands) identify file attributes such as size. you can specify whether the scan includes system. But note that very few files and folders have this Windows attribute. Applying policy to scanned items The FSA uses Data At Rest triggers to analyze and apply policy to scanned items. It can scan all currently supported file types and apply policy to those files using Data At Rest triggers (see page 292).

However.' i To ensure that files of any size are scanned. To ensure that SharePoint users do not encounter potential problems from moved or deleted template files. That is. Unchanged files: The FSA ignores files that have not changed since the last scan. . Discussion Boards. pictures. The FSA can quickly identify these files by checking the file hashes in the scanned file database—see page 279. The FSA Remote Connector can scan the text content of all SharePoint items but it only applies policy to files or documents. SharePoint scans SharePoint sites can contain a variety of items. the job specifies a path to a removable drive). set Maximum Size of Files to a value of zero. Events. Excluded folders and files: When you set up a scanning job. and ‘generic items’. Issue Tracking. we recommend that you exclude such files when setting up SharePoint scans. Scanning generic items Generic items include Announcements. we recommend you exclude template files. tasks and discussion boards. USB flash drives. and Tasks. it is possible for generic items to have file attachments and the FSA Remote Connector can analyze and apply policy to these attachments. Alternatively. That is. But note that the FSA cannot perform Delete or Replace actions on read-only media such as CDs and DVDs.Chapter 15 File Scanning Agent (FSA) 277 Which files are not scanned? The FSA ignores the following files: Files on removable drives: If a scanning job is configured to scan all ‘local hard drives’. it does not scan unchanged files. SharePoint comes with its own set of template files. you can explicitly exclude files in specific folders and files. The FSA Remote Connector can scan the text content of generic items but cannot apply policy to them. be aware that this will not include removable disk drives. such as documents. To do this. the FSA will not scan files on DVDs or CDs. optical drives. This greatly speeds up regular file scans. CA DLP puts these items into two categories: files or documents. the FSA will scan a removable drive if it is specified explicitly in the job definition as a scan location (that is. File size: You can also specify that files over a certain size are not scanned. However. you edit the Maximum Size of Files setting in the user policy System Settings folder. you can configure jobs to only include specific folders and files. and so on. Do not scan template files When scanning SharePoint sites. particularly if only a small proportion of files have been modified since the previous scan.

the FSA attempts. for very large database tables. if a database table contains MS Word documents. this is not necessary when scanning file systems for. Supported database versions are listed on page 282. Instead. all scanned data in the table (each column for every row) is written to a single XML blob file and stored as a single event. more easily manageable events. The triggers can then test these extracted MAPI properties by using XMLATTR data lookup commands. Database scans You can set up FSA jobs to scan Oracle and SQL Server databases. You can also configure special handling for binary data. Binary data refers to documents (such as Microsoft Office files). calendar events. Specifically. for example. Attributes of these items (such as 'Last Author' or 'Sensitivity') are saved as MAPI properties and are too numerous for the FSA to routinely extract all available properties for each item. or journal entries). The reason lies in the method used to store item attributes in Exchange Public Folders. What are database events? When the FSA scans a database table. it can scan documents attached to the items. a database event is generated and stored on the CMS. But for items posted to Exchange Public Folders this approach is not possible. In particular. If a trigger fires. as far as possible. to extract all the relevant document properties and add them to the metadata of the resulting file event (the metadata is stored in XML format). you can configure the FSA to slice the scanned data into smaller. delete them or copy or move them to an alternative location. Note that Data At Rest control actions (such as deleting or replacing scanned items) are not applied to scanned database records. you need to configure the FSA scanning job to detect and extract the specific MAPI properties that are relevant to your policy triggers. the scanned data is written to XML blob files. this allows Data At Rest policy triggers to test these MAPI properties when applying policy. The FSA can then apply policy to these scanned items and. you may choose to move an attachment to a secure location if the ‘Last Author’ property does not match a list of approved authors. Policy engines then apply Data At Rest triggers to the blob files. Extracting MAPI properties The FSA can also extract MAPI properties from items scanned in Exchange Public Folders. the FSA can scan columns in database tables that contain text or binary data. For Microsoft Office documents stored in a file system. . For example. you can specify a maximum number of rows per event. say. tasks. Why must you specify the individual MAPI properties that you want to extract from scanned items? After all.278 CA DLP Deployment guide Exchange Public Folders scans The FSA can scan the text content of items in Microsoft Exchange Public Folders (for example. For example. if necessary. or a maximum size (in KB) per event. you can specify that these documents are stored as attachments to database events. However. Microsoft Office documents. Instead. this is clearly undesirable. It adds these MAPI properties to the metadata for the resulting file event. In turn. You can search for these events in the iConsole. How does the FSA create database events? By default. The FSA then passes these blob files to policy engines for processing.

You can use a DSN in an application to query the database. or hash value. including the host machine. the FSA checks the hashes in the database when the job next runs and skips any files which have not been modified since they were last scanned. i DoD deletions are not available for scanned items in Exchange Public Folders and SharePoint sites. The FSA installer uses DSNs to connect to the scanned file database and NIST database. the FSA compares a file’s newly-generated hash with the hash from the previous scan. the FSA can omit these files from the scan. other information. so called because the storage media are purged or ‘sanitized’ to guarantee that data cannot be recovered and used to obtain evidence in legal discovery. i Files (binary data) found during database scans are not stored in the scanned file database.” The FSA can use this database to identify files that do not need scanning. Unlike conventional delete operations where the file header is overwritten. file profiles. Each time a scanning job is repeated. Its purpose is to ease the burden of investigating computer files. host server. For scheduled scanning jobs. also sometimes referred to as a hash code. i Hashes are not generated for files (binary data) found during database scans. maintained by the National Institute of Standards and Technology (NIST). path.000 files. size and last modified date. this fingerprint is the file hash. a file with the same name. and date of a known file. DSN A Database Source Name (DSN) describes a connection to a specific database through an ODBC driver.Chapter 15 File Scanning Agent (FSA) 279 FSA terminology Scanned file database The FSA uses a scanned file database to track the status of each file in a scanning job. If these differ. so investigators need to eliminate as many known files as possible from having to be reviewed. DoD deletion This is forensic deletion. it infers the file is unchanged and ignores it. say. if any match known files in the NSRL database. Desktop computers can contain over 100. there is a network or system failure). Similarly. This allows the FSA to skip files which have not changed. if they are the same. the database contains a hash (see below) to uniquely identify that version of the file plus its ‘last scanned’ date. this database is a list of known benign and malicious files. NIST database Also known as the National Software Reference Library (NSRL). It checks scanned files for specific profiles and signatures. the FSA checks the hashes in the scanned file database to see whether a file has changed or moved since the last scan. In FSA terms. i To delete a scanned file database. ‘DoD’ is a reference to Department of Defense approved methods for purging storage media. the FSA applies a SHA-256 cryptographic hash function to the file based on the file name. the FSA infers the file has changed since and so scans it again. size. or for scanned database records. it generates a string that represents a digital fingerprint of that file. and file signatures for use by law enforcement and other organizations in computer forensics investigations. From the NIST Web site: “The NSRL provides a repository of known software. The NSRL also enables the FSA to identify files that are not what they claim to be (for example. File hashes are stored in the FSA scanned file database (see above). a DoD deletion overwrites the disk sector multiple times in a prescribed pattern to ensure that deleted files cannot be recovered. The DSN specifies all parameters of the connection. hash sum. File hashes Before scanning a file. port and database name. . i Files (binary data) found during database scans are not checked against the NIST database. but not the same content). From this. if a scanning job gets interrupted before it is finished (because. For each scanned file. see page 298.

it allocates the file to the least heavily loaded policy engine (that is. analyze and apply policy to files saved in file system. and database records. 7 CMS 4 Databases 4a 4b 3 6 Policy engine 5 1 FSA 2 3 Example FSA deployment: file scanning 1 FSA: The FSA runs scanning jobs to monitor files saved in remote file systems. An example FSA deployment architecture for scanning remote file systems is shown below. The hub then relays these actions to the FSA (1). 2 Scanning job file: An XML file containing the job definition. The FSA queries this database to check whether a file needs to scanned in the current job. The policy engine then analyzes the file and applies Data At Rest triggers as necessary. 3 Scanned folders: The job file defines which items you want to scan and the target host machine. 4 Database: The scanned files database (4a) contains records for each file already scanned. . The hub then allocates files to policy engines for processing (6). the policy engine that can process the new file most quickly). to delete a file or copy it to a new location). Any resulting control actions (for example. the FSA can then optionally query a NIST database (4b) to identify system files which can be omitted from the scanning job. For files that do need scanning. items in Exchange Public Folders and on SharePoint sites. Web and IM events using CA DLP consoles. with each job scanning separate folders or machines and. 6 Policy engines: When the policy engine hub receives a new file from the FSA.280 CA DLP Deployment guide FSA architecture The FSA can scan. using a separate ‘run as’ account to access remote machines. 5 Policy engine hub: Files that need to be analyzed are passed to the hub by the FSA. It can delete or copy specified files. When processing is complete. File events can be viewed alongside existing e-mail. the hub also passes back to the FSA details of any actions that must be taken (for example. if required. It can run multiple scanning jobs simultaneously. to delete or copy a file) are passed back to the hub (5). 7 CMS: Each policy engine replicates processed file events up to the CMS.

These can be used to test different aspects of data security on your network. See page 283 4 For FSA deployment instructions. The user account must be a local administrator on the FSA host machine. 5 To set up user policy triggers. For FSA Remote Connector details. See page 283. see page 201. 2 If you use a NIST database to filter file scans. see page 292. See page 284. FSA requirements continue on the next page. ensure the appropriate client tools are installed on the DBMS host server. 1 Deploy policy engines 2 Optional: Deploy NIST database User accounts The FSA requires the following user accounts: FSA job setup user: This is the Windows account that you use to log on to the Administration console. see page 215. FSA service user: The FSA service runs as this user. FSA Run As user: This is the account that a scanning job runs as. See page 285. See page 284. 6 For details about scanning jobs. see page 294. you must install it before deploying the FSA. see page 288 For hub configuration. This chapter identifies two types of Run As user: a limited access user and a full access user. PE domain user 3 Optional: Deploy database client tools 4 Deploy the FSA Specify the FSA users Install FSA Optional: Install FSA Remote Connector Optional: Configure PE hub Configure FSA 5 Set up CA DLP user policy 6 Configure scanning job FSA deployment procedure 1 For details on deploying policy engines. The Administration console uses this account to connect to the FSA server when you create or manage scanning jobs using the FSA job definition wizard. . See page 201 for details.Chapter 15 File Scanning Agent (FSA) 281 Deploy the FSA This section describes how to install and configure the the FSA and the policy engine hub. Confirm this is so before installing the hub. 3 For database scans. ‘Policy engines’. This user account must be a member of the local Administrators group on the FSA host server. FSA requirements Deploy policy engines This is described in chapter 11. the wizard prompts you for the credentials of the PE domain user (see page 203). see pages 286 to 294. As part of the policy engine hub installation.

282 CA DLP Deployment guide Scanned file and NIST databases For the current release. Therefore before installing the FSA. 2005. Database scans The FSA can scan records stored in the following databases: Microsoft SQL Server 2000. see step 5 on page 286. Exchange Public Folder scans The user account that the FSA runs as (such as the FSA full access user) requires a default e-mail application compatible with Microsoft Exchange. SharePoint scans The FSA can scan SharePoint sites that use Windows SharePoint Services 2. See page 279 for details. and 10g . The installation wizard prompts you for the database host server. see step 4 on page 286. see ‘Database scans’ below. SQL Server must already be installed and configured on the target server.0. Both databases use SQL Server. ! Do not confuse this DBMS requirement with the databases that can be scanned by the FSA. and 2008 Oracle 8i. 9i. see page 283 for details. the FSA only supports SQL Server 2005. such as Microsoft Outlook.0 and 3. The FSA uses a scanned file database to track the status of each file in a scanning job. Also: Scanned File database: The FSA installation wizard prompts you for the database host server and an existing SQL Server login. NIST database: You must manually attach this database before installing the FSA. It can optionally use a NIST database to identify files that do not need scanning.

To do this: 1 Run installNIST. Install database client tools Before you can use the FSA to scan databases.cmd. CA distributes a NIST database that has been pre-configured for use by the FSA. These client tools are available from your database vendor and include the drivers (that is.mdf WGN_NIST_log. To do this. it installs the following data and transaction log files: WGN_NIST. This database ships separately from the FSA installation package and you must manually install this database before installing the FSA. For example. therefore. This allows the FSA to identify what type of database it needs to connect to and. you must attach the WGN_NIST database to any instance of SQL Server 2005. Oracle Data Access Components (ODAC) include the necessary drivers for accessing Oracle databases. This command file prompts you for the path to the target folder for the NIST database. Specifically. you must choose from a list of SQL Server or Oracle OLE DB Providers. the FSA uses the specified OLE DB Provider type plus other details supplied by yourself (such as the database name and authentication details) to generate a connection string that it uses to connect to the target database. you must ensure that the FSA service user is authenticated as a valid SQL Server login on the server hosting the NIST database—see page 284. which drivers it must use.Chapter 15 File Scanning Agent (FSA) 283 Deploy a NIST database If you intend to use a NIST database (see page 279) to filter file scans. In technical terms. Find this file on the CA DLP NIST database distribution media.ldf 4 After successfully attaching the WGN_NIST database. You are now ready to install the FSA. the OLE DB Providers) that the FSA uses to access the target database. you must ensure that the Oracle or SQL Server client tools have been installed on the DBMS host server. When you create a new scanning job using the FSA Job Definition wizard in the Administration console. 2 3 5 . You must run this command file on the SQL Server host machine. It then attaches a WGN_NIST database to the target instance of SQL Server.

This is your FSA job setup user. Find this subfolder in CA's folder in the Windows All Users profile on the machine hosting the FSA. the NIST database. FSA service user: See below for details. The FSA service runs as this user. When you log on to Windows on the Administration console host machine. In both cases.284 CA DLP Deployment guide Specify FSA user accounts To create an FSA scanning job. But note these requirements: 1 The FSA service user must be a valid SQL Server login with permissions to read and write to the scanned file database and. these databasespecific users must have the db_owner role. Throughout this chapter. you need to provide credentials for the following Windows domain users: FSA job setup user: See below for details. The console therefore needs to connect to the FSA. the installation wizard will prompt you for the logon account used by the FSA service (see step 4 on page 286). the NIST database: ` If the FSA service user is a domain administrator. which typically runs on a remote server. Ensure the FSA service user is authenticated in SQL Server The FSA connects to SQL Server using Windows Authentication. FSA job setup user You use the FSA job definition wizard in the Administration console to create and manage scanning jobs stored on the FSA server. You do this using SQL Server Management Studio. 2 The FSA service user must be listed explicitly under the ‘Users’ for the scanned file database and if used. The FSA then creates or updates the actual scanning job definitions. you must do so as the FSA job setup user. it will automatically be a valid SQL Server login. This user must have write access to the \FSA\Jobs subfolder on the FSA host server. ` If the FSA service user is not a domain administrator. . FSA Run As user: See page 285 for details. passing the logon account for the FSA service user to SQL Server. the Administration console uses the Windows account that you used to log on to the Administration console host machine. if used. FSA service user When you install the FSA. The user account must be a local administrator on the FSA host machine. the term ‘FSA job setup user’ refers to the domain user that the Administration console uses to connect to the FSA. This is the your FSA service user. you will need to manually add it as a new login on the server(s) hosting the scanned file database and NIST database. To connect to the FSA.

However. we recommend that the FSA Run As user is a bespoke account created for exclusive use by the FSA. ` Read and Write access to Exchange Public Folders for the full access user. reflecting their different purposes: Limited Access FSA Run As User: You can use the FSA to test whether sensitive documents stored on your network are accessible to unauthorized users. the FSA Run As user requires: ` An Exchange mailbox. this is often regarded as the ‘classic’ use for the FSA. This permits the FSA to copy or delete Public Folder items.) ` Read access to Exchange Public Folders for the limited access user. In both cases. the FSA Run As user must be a domain user with local administrator rights on the SharePoint host machine and Read access to the SharePoint site being scanned. Specifically. . such as Microsoft Outlook. while running as this user. The FSA also requires a default e-mail application compatible with Microsoft Exchange. (You can typically create a mailbox at the same time as you create a new user account in Active Directory. This is because it is essential that nobody logs onto a scanned machine using the ‘Run As’ account while a scheduled scan is running! See page 296. This user is your ‘full access FSA Run As user’.Chapter 15 File Scanning Agent (FSA) 285 FSA Run As user The FSA Run As user is the user account that FSA scanning jobs run as. the full access user will need Read and Write access.) To do this. the FSA must be able to access remote file systems and delete files when instructed to do so as a result of policy processing. this indicates that your network security needs to be tightened. the FSA must run as a domain user with permission to delete and copy files on any machines that you want to scan. This is your ‘limited access FSA Run As user’. A Microsoft SharePoint site. Full Access FSA Run As User: You can use the FSA to scan the content of files stored on your network to determine if sensitive information is stored in the correct location or to identify files or documents with unauthorized content. See the account requirements below. you set up a scanning job to run as a user with limited access to sensitive network locations. To do this. This guide identifies two types of Run As user. If. Requirements for Run As user If you want to scan: Microsoft Exchange Public Folders. the FSA detects and scans documents that should not be accessible to ordinary users. (Indeed. This ‘limited access’ user is representative of your ordinary network users. You typically specify an FSA Run As user when you schedule a scanning job using the Job Definition wizard in the Administration console (see step 3 on page 296) or when you log on to Windows before running a scanning job from a command line (see page 295).

3 File Scanning Agent Account: In this screen. this screen prompts for the name or IP address of the server hosting your NIST database.286 CA DLP Deployment guide Install the FSA You install the FSA using the CA DLP Integration Agents installation wizard. choose: 4 Scan Database Location: In this screen. This dialog lists any servers found to be hosting SQL Server. name and password of the FSA service user (see page 284). run setup. 5 NIST Database Location: If you chose to install the NIST Database Connector in step 2. it must be installed before you install the FSA. If you choose not to install a hub. the FSA will automatically passed scanned items to a local policy engine for processing. you specify where you want to create your scanned file database. you can choose to install a policy engine hub when you install the FSA. Custom Setup: In this screen. This dialog lists any servers found to be hosting SQL Server. This feature is installed separately on the machine you want to scan—see page 288. In the case of multiple SQL Server instances running concurrently on the same computer. See page 283 for details. ` Username and Password: Specify the credentials for the SQL Server login that the FSA uses to access the scanned files database. This feature is optional. specify the logon accounts used by the FSA service. Install this feature if you want to use a policy engine hub to distribute scanned items to remote policy engines for processing. and <Instance name> is the name of the SQL Server instance.exe. . This service must run as the FSA service user. Do not choose the File Scanning Agent Remote Connector. Click the Browse button for the FSA service. you must ensure this policy engine is already installed before you run a scanning job. 1 To launch the Integration Agents installation wizard. ! If you want to use a NIST database. ` Server: Click the ‘Server’ button to select the DBMS host server in the Database Server dialog. this database tracks the status of each item in a scanning job. Where <machine name> is the name of the server on which SQL Server is running. Find this in the \Integration folder on your CA DLP distribution media. see page 279. Click the ‘Server’ button to select the host server in the Database Server dialog. MyDBServer\Instance_1 2 ` File Scanning Agent ` NIST Database Connector. This feature is optional. ` Remote Policy Engine Connector. then enter the domain. If required. the dialog identifies each instance as: <machine name>\<Instance name> For example.

In this screen. You may also need to install an FSA Remote Connector.exe to cache the password. click Install to start the file transfer.exe are on page 518.Chapter 15 File Scanning Agent (FSA) 287 6 Policy Engine Hub Configuration: This screen is displayed if you chose to install a Remote Policy Engine Connector in step 2. This is essential for SharePoint scans and may also be necessary for other scanning jobs for reasons for reasons of security or efficiency. see page 225. See page 217 for details. i If you subsequently need to change these credentials. ‘Policy engine hubs’. Configure the hub This is described in chapter 12. the FSA connects to the target database using the authentication method specified in the scanning job definition. the required component ID is: FSADBSCAN i Instructions for using wgncred. you can use wgncred. You now need to configure the policy engine hub and FSA (see below and page 289 respectively). 8 . see page 294. provide the credentials for the PE domain user (as specified on page 203). you may want to cache the logon credentials used by the FSA when scanning database records. When these tasks are complete. you can start a scanning job. This avoids the need to store these credentials in the actual job definition file on the FSA host server. Likewise. 7 In the final wizard screen. see page 288. Securely store logon credentials for database scans When scanning database records. As a secure alternative to storing a database user’s password in plain text in the XML job definition file. See page 287.

CA DLP Integration Agents Server Agents File Scanning Agent NIST Database Connector FSA Remote Connector Why deploy an FSA Remote Connector? If you want to scan Microsoft SharePoint items. You install the FSA Remote Connector using the CA DLP Integration Agents installation wizard: 1 To launch the Integration Agents installation wizard. Find this in the \Integration folder on your CA DLP distribution media. If a scanning job is configured to exclude a large proportion of files. it may be necessary for reasons of security or efficiency to run the scanning job on the remote machine. For example: If scanning a large database. It is needed for scanning SharePoint sites but may also be your preferred method for scanning databases or files and folders on remote machines. choose File Scanning Agent Remote Connector. In the Custom Setup screen. you must still install the FSA itself somewhere on your network as part of your CA DLP. When you configure a scanning job to run on a remote server (such as a DBMS or SharePoint host machine). it may be more efficient to install the FSA Remote Connector on the machine hosting the DBMS. If you need to scan sensitive folders on a remote machine that cannot be accessed by a UNC path you will need to deploy an FSA Remote Connector on that machine. rather than retrieving database records across the network to the FSA for analysis. this allows you to run a local scan on that machine. run setup. Install the FSA Remote Connector i If you install an FSA Remote Connector. you must deploy an FSA Remote Connector on the machine hosting the SharePoint site. rather than retrieving all files across the network to the FSA for analysis. then it is more efficient to identify these exclusions on the host machine. click Install to start the file transfer. Scanned items that require policy processing are sent back across the network to the FSA. In effect. In effect.288 CA DLP Deployment guide Deploy FSA Remote Connectors The FSA Remote Connector is a comparatively small utility that enables the FSA to run remote scans. 2 Integration Installation Wizard: Custom Setup screen 3 In the final wizard screen. you can specify the server hosting the FSA Remote Connector in the General Scan Options screen of the FSA job definition wizard—see page 295. 4 . it runs a local scan on the remote machine and passes scanned items back to the FSA for policy processing. For other scanning jobs.exe.

FileOverwritePassesFixedMedia FileOverwritePassesRemovableMedia ScanDatabaseDSN ScanDatabaseServer NISTDatabaseDSN NISTDatabaseServer UseLocalPolicyEngine .log file. the FSA creates a new log file. For example. LogMaxNumFiles LogMaxNumFiles Type: REG_DWORD Data: Defaults to 10. plus informational and status messages i Setting LogLevel=3 will cause the log file to grow extremely rapidly.Chapter 15 File Scanning Agent (FSA) 289 Configure the FSA You configure the FSA by modifying the registry. you can configure the FSA to only log errors or important system messages. This specifies the maximum size for each log file. Other registry values determine how to handle failed attempts to apply policy to files. LogMaxSizeBytes LogMaxSizeBytes Type: REG_SZ Data: Defaults to 1. you modify values in the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\FSA LogLevel LogLevel Type: REG_DWORD Data: Defaults to 2. This specifies the maximum number of log files. The supported logging levels are: Registry values LogLevel LogMaxNumFiles LogMaxSizeBytes ThrottlePercent WorkerThreadCount AnalysisRetryAttempts ActionRetryAttempts RetryPeriodSeconds AnalysisTimeoutSeconds The following registry values are created automatically in the FSA registry key when you install the FSA: Page 289 289 289 290 290 290 290 290 291 291 291 291 291 291 291 291 1 Errors only 2 Errors and warnings 3 Errors and warnings. the oldest log file is deleted to enable a new one to be created. you can specify a default scanning job run by the FSA service. When the maximum number of log files exists and the maximum size of the latest is reached (see below). The log file is saved in CA's \data\log subfolder of the Windows All Users profile on the machine hosting the FSA. Log entries are written to the wgnfsa_<date>.000. To configure the FSA. This determines the level of logging for file processing. When the current log file reaches its maximum size. see page 499. For example.000. This level of logging is provided for testing purposes only.

a file can be timed out by the hub and passed back to the FSA if no policy engines are available to process the file. the file is moved to a retry queue. If the first attempt to pass a file to the policy engine hub fails. AnalysisRetryAttempts AnalysisRetryAttempts Type: REG_DWORD Data: Defaults to 0. as part of a file move operation. These files include: ` Analysis failures: These are files that could not be passed to the hub for processing. this is recorded in the log file and the FSA only retries the delete operation. files waiting to be retried are moved to the retry queue. For example. the hub has suspended operations because it has exceeded its maximum memory allocation. First. This specifies how much time (as a percentage of total time) the FSA spends waiting. set this parameter to 30 (do not include a ‘%’ character). WorkerThreadCount WorkerThreadCount Type: REG_DWORD Data: Defaults to 10. ActionRetryAttempts ActionRetryAttempts Type: REG_DWORD Data: Defaults to 0. rather than reading file data from a disk. the FSA successfully copies a file but is then unable to delete the original version. see below). This parameter enables you to restrict how much time the FSA spends reading data from disk. when multiple jobs are running simultaneously or when multiple worker threads are scanning a single volume). More accurately. The FSA tries to delete the file again after the retry period expires (this defaults to five minutes. For example. this registry value determines how many times the FSA retries before writing a ‘file failure’ entry to the log. RetryPeriodSeconds RetryPeriodSeconds Type: REG_DWORD Data: Defaults to 300 (equivalent to five minutes). for example. For example. if you specify 30% waiting time. a file is copied to a new location. After a first failed attempt. If the FSA is unable to delete a file. ` File moves are actually consecutive ‘copy and delete’ operations. Data At Rest control actions can stipulate that a file is deleted or moved: ` File deletions are carried out by the FSA when it receives an instruction to do so from the policy engine via the hub. i If. to set waiting time to 30%. then the original version is deleted. they are files for which the FSA could not execute a control action. then the FSA can only spend 70% of its time reading data. the FSA may be unable to delete a file because the file is open. ` Action failures: These are typically files that could not be deleted. this registry value determines how many times the FSA retries before writing a file failure entry to the log. This specifies the number of concurrent ‘worker’ threads used by the FSA to analyze files. . Such failures can occur when. If the first attempt to execute a control action on a file (typically ‘delete’) fails. Likewise.290 CA DLP Deployment guide ThrottlePercent ThrottlePercent Type: REG_SZ Data: Defaults to zero. This can be useful to prevent network and system performance problems during intensive scanning operations (for example. This parameter defines how long (in seconds) the FSA waits before retrying failed files in the retry queue.

This registry value is set during installation. For a DSN definition.Chapter 15 File Scanning Agent (FSA) 291 AnalysisTimeoutSeconds AnalysisTimeoutSeconds Type: REG_DWORD Data: Defaults to 600 (equivalent to ten minutes). hard disks). NISTDatabaseServer NISTDatabaseServer Type: REG_SZ Type: REG_DWORD Data: Defaults to 3. it is set to zero if you install a Remote Policy Engine Connector. see page 279. UseLocalPolicyEngine UseLocalPolicyEngine Type: REG_DWORD Data: This specifies whether scanned items are passed to a local policy engine or a local policy engine hub. FileOverwritePassesRemovableMedia FileOverwritePassesFixedMedia ScanDatabaseDSN ScanDatabaseDSN Type: REG_SZ Data: This specifies a DSN used by the FSA to connect to the Scanned File database. This specifies the number of overwrite operations for DoD deletions (see page 279) of files saved on fixed storage media (that is. This value is set automatically when you install the FSA (see step 2 on page 286). Data: This specifies the name of the server hosting the NIST database. This defines how long (in seconds) the FSA waits for a file to be successfully analyzed by a policy engine. see page 279. . This specifies the number of overwrite operations for DoD deletions (see page 279) of files saved on removable storage media. Note that files are processed asynchronously. the FSA flags the file as a failure and writes an entry to the log. This deletion is performed by the FSA and is not governed by this analysis timeout. If the FSA does not receive an acknowledgment from the hub that a file has been successfully processed before this timeout expires. typically a USB portable hard drive. This registry value is set during installation. For a DSN definition. A default DSN is created when you install the FSA. A default DSN is created when you install the FSA. The hub acknowledgement may call for a file to be deleted. ScanDatabaseServer ScanDatabaseServer Type: REG_SZ Data: This specifies the name of the server hosting the Scanned File database. NISTDatabaseDSN NISTDatabaseDSN Type: REG_SZ Type: REG_DWORD Data: Defaults to 3. The timeout starts when a file is added to the hub input queue. FileOverwritePassesRemovableMedia FileOverwritePassesRemovableMedia Data This specifies a DSN used by the FSA to connect to the NIST database. otherwise it is set to 1.

Data At Rest triggers enable the FSA to: Detect specific file names or formats (for example. you can copy scanned files to alternative folders. Add smart tags to events generated by the FSA—see page 293. or to determine whether the item matches a particular document classification. See the Administration console online help for details. Categorize scanned items: If required. DLP automatically chooses the category with the highest score. and the document author. For full details about Data At Rest control actions. replace and categorize scanned items: Copy files to an alternative location: If required. Replace deleted or moved files: You can optionally replace deleted files or files that have been moved to a new location with an explanatory stub file to alleviate any user concerns. see page 279. To do this. Also. you can ensure that scanned items are automatically categorized. Delete files. the FSA can copy. search the index for ‘smart tags’. See the Administration console online help for details. delete. See the Administration console online help for details. See section for details. see the Administration console online help. you need to edit the Data At Rest triggers in the user policy. However. date created. or for scanned database records. including DoD deletions: You can delete scanned files if.292 CA DLP Deployment guide Set up CA DLP policy triggers This section describes how the FSA uses Data At Rest triggers to analyze and apply policy to scanned items. . search the index for ‘Intervention setting’. you configure the trigger to use XML Attribute data lookup commands. the FSA can apply control actions to those attachments (see page 277). the ‘Control action exceptions’ Using Data At Rest control actions. search the index for ‘XML Attribute lookup’. Analyze an item’s text content to detect the presence or absence of key phrases. When used in combination with a ‘delete file’ action. move. if SharePoint generic items have file or document attachments. search the index for ‘scanned files: copying’. Control action exceptions DoD deletions are not supported for scanned items in Exchange Public Folders or SharePoint sites. a copy action effectively becomes a ‘move file’ action. Data At Rest control actions ! Data At Rest control actions cannot be applied to certain items. Microsoft Word documents). If a scanned item causes multiple triggers to fire. It also describes which user policy gets applied and you can configure this policy to apply smart tags to scanned items. Data At Rest triggers To apply policy to items scanned by the FSA. for details. no Data At Rest control actions can be applied to scanned database records or generic items on SharePoint sites (such as Announcements and Discussion Boards). for example. policy processing determines them to be unauthorized. DoD deletions ensure deleted files cannot be recovered. date last modified. see the ‘Control action exceptions’ below. Analyze a file’s attributes such as its size. i DoD deletions are only supported for file system scans.

each smart tag is added as a MAPI property. you can apply smart tags either to the original document. When the trigger activates. i You cannot apply smart tags to original items when scanning SharePoint sites or when scanning database records. . Apply smart tags to CA DLP events generated by the FSA You can configure Data At Rest triggers to add smart tags to events generated by the FSA. For details. See the wizard’s online help for details. ‘scan events’ stored on the CMS). you must specify the policy participant. In the case of scanned Microsoft Office documents. In fact. search the index for: ‘smart tags: file events’. to apply smart tags to scanned Microsoft Office documents. or to a copy of the scanned document. to do this. For each scanning job. For details. These are the users that you want to associated with the scanned items. if applying smart tags to scanned items in Exchange Public Folders.Chapter 15 File Scanning Agent (FSA) 293 Which user policy gets applied? When you create a scanning job using the FSA Job Definition wizard. Apply smart tags to original Microsoft Office documents You can also configure Data At Rest control actions. i You also specify the event participants when you create a scanning job. Apply smart tags to scanned items CA DLP can apply smart tags to events generated by the FSA (that is. Each smart tag is then saved as a new property of the scanned document or. see the Administration console online help. For example. it can also apply smart tags to the original document. This is the CA DLP user account whose policy you want to apply to all scanned items. you specify the user’s e-mail address. see page 298. each smart tag is saved with the event metadata in the CMS database. you can choose to apply the Default Policy for Files (defined in policy engines’ machine policy—see page 207) or you can apply a specific user’s policy. you can use smart tags to classify scanned files for data classification purposes.

0. Select an FSA server and choose Edit > Import Job File. see page 295. You can then run these jobs as normal. expand the File Scanning Agents branch. To import 6. For details about the wizard. Log on to the Administration console host machine as the FSA job setup user (see page 284). expand the File Scanning Agents branch. You must also install a r12. In the Administration console. When you import 6. Although you do not need to create a schedule at this point. see page 289.0 job file is added to the FSA screen.294 CA DLP Deployment guide Scanning jobs This section describes how to add. you must first import these jobs onto the FSA before you can run them. CA DLP asks you if want to create a job schedule. Each individual job defined in the 6. Scanning job log files The FSA logs the outcome of scanning jobs. clone. you run the FSA Job Definition wizard. To run a scanning job. Define a new job To define new scanning jobs.0 job file. The fsa writes log entries to wgnfsa_<date>. Add a scanning job Scanning jobs are listed in the FSA screen of the Administration console. Right-click an FSA server and choose Create New Job. Briefly: 1 Log on to the Administration console host machine.0 job files: 1 Ensure you have upgraded your FSA to r12. see page 296. the underlying XML schema for scanning job definition files has been amended.0 scanning job For CA DLP r12.0 of the CA DLP product (previously called Orchestria APM). Find these files in CA's \data\log subfolder of the Windows All Users profile on the machine hosting the FSA. 5 The new scanning job is listed in the FSA screen of the Administration console. the FSA automatically updates them to use the new r12. be aware that a scanning job must have 2 3 4 2 5 3 6 4 . To add an old job (created using an earlier version of CA DLP). see page 295.0 Administration console. see the Administration console online help. run and schedule scanning jobs. You can now run.0 scanning jobs. connections to the scan database. as the FSA job setup user (see page 284). a schedule defined before it can run.0. see page 495. After you click Finish in the final wizard screen. copy or move the job as required. If you have scanning jobs defined using version 6. This launches the Import FSA Job Definitions dialog.0 job schema. you use the FSA Job Definition wizard in the Administration console. Note that the FSA creates a separate new job file for each individual job extracted from the 6.log files. In the Administration console. search the index for ‘FSA’. you must import the XML job definition file. and when jobs started and completed. For details. Use the Administration console to do this. such as details of replaced files. This launches the FSA Job Definition wizard. It also describes how to purge the scanned file database and how CA DLP users get associated with scanned items. To add a new job. You define the log level in the registry. Browse to the XML job file that you want to import. Import a version 6.

it does so as the Run As user. To run scanning job commands. use this syntax: <path>\wgnfstub /job <job name> [/console] [/server <FSA server>] [/user] [/password] . the only reason to run a scanning job from a command line is for security reasons when scanning a database (because this method allows you to avoid storing database logon credentials in the job definition). For example. you cannot choose the job’s Run As user (see page 285). they cause the FSA to prompt you for the logon credentials that it will use to access the target database objects. whether as a scheduled job or when you manually start it in the Administration console. For example. If you want to reschedule a job. Their purpose is to avoid the security risk of storing database credentials in a scanning job definition. This command also enables you to manually stop a scanning job. you must use this parameter if you run the command on a machine that has the FSA Remote Connector installed. /server <FSA server> is optional. see step 3 on page 296). unlike jobs defined using the FSA Job Definition wizard. It identifies the name or IP address of the FSA host machine. When the job runs. Be aware that when you run a scan from a command line. Or schedule a scanning job to run at regular intervals. When defining the schedule. /user and /password are optional parameters for database scans. i If a job name contains spaces. To do this use the keyboard shortcut Ctrl-C or Ctrl-Break during a scanning job. this command runs the ‘My Oracle Scan’ job and prompts for the database logon account: <path>\wgnfstub. You can either: Either run a job immediately. From the Administration console When you create a scanning job using the FSA Job Definition wizard in the Administration console.Chapter 15 File Scanning Agent (FSA) 295 Run a scanning job You can run scanning jobs using the FSA Job Definition wizard or from a command line. Scanning jobs are listed in the right-hand pane of the FSA screen in the Administration console. If these parameters are used. /console is optional. Where: /job <job name> is the name of an existing scanning job. right-click the job and choose Schedule. you must choose the Run As user. You specify job names when you run the job definition wizard in the Administration console. it must be enclosed in quotes. ensuring first that any events still being processed are completed.exe /console /job "My Oracle Scan" /user /password From a command line In practice. you must define a job schedule. You must therefore ensure that you are logged on to Windows using an account with appropriate permissions. Right-click the job you want and choose Run Job Now. That is. It communicate any errors encountered during the scanning job (for example. You must use this parameter if you are running the wgnfstub command on a machine that is not hosting the FSA. if a job cannot be run). the job runs under your Windows logon account.

` Settings tab: This tab includes optional settings to further configure when the scanning job runs. You can either: Choosing the Run As user This section only applies to scanning jobs created using the FSA Job Definition wizard in the Administration console. choose Yes. Do not choose a Run As user that corresponds to a real user account if there is any possibility that this user will be logged on to the target machine while a scheduled scanning job runs. Specifically. they subsequently log on to a target machine while the scan is in progress. you want the job to run as the FSA Run As user (see page 285) or an account with equivalent permissions on the machine you want to scan. if required). and using the same Windows user account.296 CA DLP Deployment guide Schedule a scanning job Each scanning job must have a schedule defined before it can run. Avoid this situation! The classic mistake is when a network administrator schedules a scanning job and enters their own domain account as the Run As user (because they know that they have access to all the required scan locations). so causing the scan to fail. you must be careful when choosing the Run As user for a scheduled scanning job. ` Create or modify a schedule for an existing job. you do not need to edit these fields. it is essential that nobody logs onto the target machine using the same account as the FSA! 2 ` Define a schedule for a new job. as the FSA job setup user (see page 284). This allows the job to run repeatedly at regular intervals (although you can override the schedule and run a job immediately. For example. ` Run and Start In: These fields are set automatically. edit the remaining tabs as required: ` Schedule tab: Specify when and how often the scanning job runs. go to the Task tab and edit the job schedule as required. After you click Finish in the final wizard screen. you stop the job if it overruns. or you can set it to only run if the target computer is idle. you define the schedule in the Schedule FSA Job dialog: 1 Log on to the Administration console host machine. Scanning jobs are listed in the right-hand pane of the FSA screen. we recommend that these users are bespoke accounts created for exclusive use by the FSA. this can adversely affect the scanning job. But see the Run As warning in the next section! 4 Still in the Schedule FSA Job dialog. ! When a scheduled scanning job is running. CA DLP asks you if want to create a job schedule. Right-click the job you want and choose Schedule. In all cases. if you want jobs to run as your FSA limited access user or FSA full access user. Create a new job (see page 294). You typically set up a scan schedule immediately after creating a new job. at the same time. . 3 In the resulting Schedule FSA Job dialog. Typically. In the Administration console. though you can do so at a later time. For this reason. The job may terminate prematurely or it may even fail to respond to attempts to terminate it manually. ` Run As: You do need to edit the Run As field. While performing an unrelated task. The issues below do not apply to scanning jobs run from a command line. If a user and the FSA are logged on to the same machine. This defaults to your Windows logon account. expand the File Scanning Agents branch.

the database contains a hash to uniquely identify that version of the file plus its ‘last scanned’ date—see page 279 for details. To do this. When the job restarts. it ignores items that have already been scanned in the current job. the FSA performs hash checks to identify those files that can be excluded from the scan when it restarts. right-click: An FSA server and choose ‘Purge Scan Database’ to purge the entire scanned file database. Purge the scanned file database You can purge the scanned file database (see page 279) from the Administration console or from a command line.Chapter 15 File Scanning Agent (FSA) 297 Stop and restart a scanning jobs If necessary. An individual scanning job and choose ‘Purge Scan Database’. From a command line Use the following command syntax to purge: The entire scanned file database: <path>\wgnfstub /purge A specific scanning job: <path>\wgnfstub /purge <job name> Where <job name> specifies a specific job. If the job name contains spaces. From the Administration console In the FSA screen of the Administration console. i For each scanned item. you can stop and restart jobs. This purges file records associated with a specific scanning job. But be aware that these hash checks can take a long time for very large scanning jobs. use quotes: <path>\wgnfstub /purge "Asia Sales" .

available hardware and so on. search the index for ‘shared database’. For example. However. Right-click on the database name and select delete. Then. You can have a single FSA running many scanning jobs or multiple FSAs each running a few jobs. according to the type of database you are running. This allows you apply different policies to same folder. see the next section. Multiple FSAs permit load balancing and can share a SQL Server database server. Which deployment is appropriate for you depends on the volume of data you need to scan. How do I delete a scanned file database? A scanned file database can only be deleted manually. use SQL Server Management Studio for SQL Server 2005. When a reviewer subsequently searches for scanning events in the iConsole or Data Management console. there are some practical considerations that can inform your decision: A single FSA running multiple scanning jobs is easier to deploy. i For details about what happens if no event participants are specified. you must enter the e-mail address of any CA DLP user that you want to associate with the files or items being scanned. But all scanned files that need policy processing are channeled through the same hub. For each event. each running local scans. one scanning job may apply DoD deletions to files matching a particular classification. Or each FSA can use a separate instance of SQL Server. available from Technical Support—see page 23. Each FSA can use a separate database hosted in the same instance of a SQL Server database engine. For further guidance. while another job saves copies of specific files to a new location. In the Object Explorer. see ‘Can jobs overlap?’ on page 299.298 CA DLP Deployment guide Scanning job FAQs How are scanned items associated with CA DLP users? When you create a scanning job using the FSA Job Definition wizard. Do I use multiple scanning jobs or multiple FSAs? The FSA is highly flexible. Can jobs overlap? Yes. select the Database Engine that contains the database you want to delete. Further information about mapping file events to CA DLP users is available in the ‘Event Participants’ technical note. If you deploy multiple FSAs. Browse to the actual database object location within the Databases folder structure. Hub capacity is therefore a key determinant. That is. by configuring the machine it is hosted on: 1 Open the relevant application. these addresses get stored as event participants in the CMS database. 2 3 4 . and connect to it. when a scan runs and events are generated. see the Database guide. both are configured to scan a common folder. i We recommend you accept the default setting to delete the database backup. these addresses are mapped onto CA DLP user accounts. with all instances hosted on the same machine. You can have two overlapping scanning jobs. your network configuration. For example. the FSA assigns the event participants specified in the scanning job definition. then all scanned files are automatically associated with the source machine when the file event is stored in the CMS database—for details.

In the final wizard screen. choose the File Scanning Agent. In this situation (based on the example above). You add new addresses in the User Properties dialog in the Administration console. When the wizard starts. you must uninstall the FSA before uninstalling the policy engine. go to the Program Maintenance screen and choose Modify. This applet is part of the Control Panel.Chapter 15 File Scanning Agent (FSA) 299 What happens if no event participant is specified? Typically.cn=computers This means that even if the job file does not specify a file event participant. you specify one or more event participants when you run the job definition wizard in the Administration console. each scanned file is still associated with a ‘host machine’ address. Uninstall the FSA ! If a policy engine is installed on the same computer as the FSA. However. 4 . to ensure that files scanned on machine UX-MILAN-W2K3 can be retrieved during an iConsole event search. you do not need to associate scanned files with a CA DLP user. not just the Exchange or Domino server agents. click Install to begin the uninstallation. 1 In Add/Remove Programs. You specify the e-mail addresses for these participants and CA DLP maps those addresses to CA DLP user accounts. 2 3 In the Custom Setup screen.cn=computers For example: cn=UX-MILAN-W2K3. see page 210. select CA DLP Integration Agents and click Change. an address matching the machine’s domain name in Active Directory is associated with each scanned file and stored in the CMS database. i If you choose Remove. This machine ‘address’ takes the form: cn=<computer name>. This is because each scanned file is automatically associated with the machine hosting the source folder. Specifically. you would need to add the above machine address to the list of addresses specified for an appropriate CA DLP user account. To uninstall policy engines. Use Add/Remove Programs to manually uninstall the FSA. this removes all CA DLP components.

300 CA DLP Deployment guide .

It can also disable the Print Screen button on a user’s keyboard. CD or DVD. It also describes the required changes to user policy and machine policy to enable these agents. the CPSA applies policy to either allow or block the print job (2). or network location (3a. and attempts to burn files onto writable CDs and DVDs. i For the current release. applying policy in real time to the documents being printed. CFSA and CPSA If a user tries to print a file (1). targeted files on the local hard drive (5) are scanned at regular intervals by the CFSA (6) and policy applied as necessary (for example. apply control triggers based on a file’s text content or properties. For details. It provides an overview of both agents and their respective deployment procedures.16. See pages 302 to 311. to assign smart tags to files). Client Agents: File and Print Client Agents: File and Print his chapter describes how to deploy the Client File System Agent (CFSA) and Client Print System Agent (CPSA). The CFSA can also scan the local hard disk and apply policy triggers based on a file’s content or properties. if the user tries to copy or save a file to a removable drive. It can selectively block or allow copying for specified devices or network locations and. chapter 16 T 1 2 4 3a 3b 3c 6 5 Client Print System Agent (CPSA) The CPSA can control attempts by users to print documents on local or network printers. 3c). 3b. . Client File System Agent (CFSA) The CFSA can control attempts to copy or save files to removable storage devices (such as USB flash drives) and network locations. if required. the CFSA is not supported on 64-bit machines. the CFSA applies policy to allow or block the operation (4). In addition. see pages 314 to 318. Likewise.

3 Policy-enabled Application filter: These are applications that the CFSA can integrate with to apply user policy. ! The only policy-enabled applications recognized by the CFSA in the current release are Windows Explorer (including drag and drop copying) and DOS commands such as copy and xcopy. the user is allowed to copy or save the file. copies or burns a file using a policy-enabled application and the device or location handling is set to ‘apply user policy’. These triggers analyze the files and apply appropriate control actions. ` Any other application. You can configure default handling for unrecognized devices or network locations and custom handling for ‘special’ devices and locations (see page 305). ` Apply user policy: If the user is using a policy-enabled application to copy. save or burn a file. User policy filter: When the scan runs. CD drive or network location. and can even apply a further device filter. It can also run scheduled scans of the local hard disk. No further policy is applied. If a user copies or burns a file using a policy-enabled application and the device or location handling is set to ‘apply user policy’. the CFSA blocks the file operation. the CFSA applies Data In Motion triggers to the file. writable CD drives or network folders This process is summarized below and in the flow chart on page 303. 1 File and folder filter: First. the CFSA applies Data in Motion triggers to the file or document being copied. If the application is not policy-enabled. users can always save files to this device. which also apply to writable CD and DVD drives. The available handling options are defined in the local machine policy: User policy filter: If a user saves. are defined by the handling (see page 305) for removable devices and network locations. ` Allow write access: That is. ` Set to read only: Users are blocked from saving files to this device. You can also choose to only scan files modified since the previous scan. These triggers analyze the file’s properties and text content. you can specify local files or folders that you want to explicitly include or exclude from the scan.302 CA DLP Deployment guide About the Client File System Agent What filters does the CFSA use? The CFSA supports various levels of filtering to determine whether or not a user is allowed to save a file to a removable device or network location. For example. The results of this policy processing determine whether the CFSA blocks or allows the file operation. and delete. replace or move unauthorized files. If this is: 4 ` A ‘trusted application’ as defined in the local machine policy (see page 305). the CFSA checks which application the user is using. 2 Device filter or Network filter: These filters. the CFSA applies Data In Motion triggers to the file or document (see step 3). Saving files to removable devices. Scanning files on the local hard disk This process is summarized below and in the flow chart on page 304. CFSA applies Data At Rest triggers to the scanned files. the CFSA applies file and folder filters defined in the machine policy. 2 . For example. 1 Trusted Application filter: First. the CFSA checks the policy handling for the target device or network location and applies the device filter or network filter. they can categorize files based on their text content. CD drive or network location.

the file is blocked. Alternatively. this determines whether to block the file operation. File cannot be copied or burnt Removable device. First. CD drive or network location is writable. If no control trigger fires. if it set to ‘read only’. or burn file to CD Machine Policy 2. User tries to copy file to removable device or network location. If the user is not using a trusted application. a user tries to copy a file to a removable device or network location. Handling for removable device (including CD drive) or network location Allow write access Apply user policy to file Set to Read Only Non-configurable application filter User Policy 4. or burn it to a CD (1). file copying or burning is allowed. the file is blocked. If a control trigger fires (6).Chapter 16 Client Agents: File and Print 303 CFSA flow chart: Removable devices. the CFSA checks the device. Is the user using a trusted application to save. it permits the file to be copied or burnt. CD drive or location handling (3). 1. the CFSA applies policy triggers to the file (5). Does a control trigger fire? No No Other No Yes Yes Warn Block File can be copied or burnt Removable device. Apply Data In Motion triggers to file 6. . network folders In the diagram below. CD drive or network location is read only. CD drives. if the handling is set to ‘apply user policy’. the file can be copied or burnt. If set to ‘allow write access’. If they are. copy or burn the file? Yes No 3. the CFSA checks whether a policy-enabled application is being used to copy or burn the file (4): If so. Is the user copying or burning the file via a policy-enabled application? Yes 5. If the user is not using a policy-enabled application. the CFSA checks whether the user is using a trusted application (2).

or to categorize the file being copied. CFSA applies Data At Rest triggers to the scanned files (5). and delete. and delete. or to burn files to CD or DVD. Data At Rest trigger settings are described on page 311. It then applies machine policy in real time to block unauthorized saving or copying. For example. Is file included in next scan? Yes 3. File is saved on local hard disk Machine Policy 2. they can categorize files based on their text content.304 CA DLP Deployment guide CFSA flow chart: scanned files on local hard disk In the diagram below. File is not scanned How does the CFSA apply policy to protect files? The CFSA applies machine policy and user policy to protect your data in the following ways: Apply machine policy when files copied to removable devices or network locations: The CFSA detects attempts to copy files onto removable devices. Apply which user policy? No 4. a user saves a file to the local hard disk (1). it channels users into using policy-enabled applications (Windows Explorer or DOS commands) to copy or burn their files by blocking other applications. the CFSA applies an action to the scanned file (6). see page 306. It can then apply Data In Motion triggers based on a file’s properties or text content. or simply to warn the user. it can run scheduled scans of the local hard disk and apply Data At Rest policy to targeted files. 1. To do this. It uses the results of policy processing to allow or block the copy operation. When the scan runs. primarily USB flash drives. replace or move unauthorized files. it can categorize files based on their text content. or the target network folder. If a control trigger fires. It can also apply Data In Motion triggers to analyze files being copied—see below. Apply Data In Motion triggers to copied files: The CFSA can apply Data In Motion triggers in real time to files being copied to removable devices or network locations or burnt to CD or DVD. Files implicitly or explicitly excluded are not scanned (4). based on the device or application being used. the CFSA checks machine policy to determine which files and folders to include (2) and which user policy to apply (3). When the next scheduled file scan runs. User Policy 5. Apply Data At Rest triggers to scanned files 6. Machine policy settings are described on page 307. Apply Data At Rest triggers to scanned local files: Finally. For details about which user or machine policy is applied. or to network locations such as shared folders. Data In Motion trigger settings are described on page 312. For example. Does a control trigger fire? No No action Yes File deleted File replaced File moved File copied File categorized . replace or move unauthorized files.

The CFSA is designed to prevent unauthorized file copying to such devices. The CFSA uses a hard-coded list of policyenabled applications. For example. Special devices or special locations: These are removable devices or network locations explicitly identified in machine policy. If a user uses a policy-enabled application to copy a file to a removable device or network location. i By default. Do not remove this application from the machine policy! This is the Local Security Authority System Service and is needed by Windows to perform security-related functions. ` Allow write access: The user is allowed to copy or save files to removable devices or network locations. Prohibited devices: These are any removable devices to which write access is denied. Write access can be denied by settings in the local machine policy or by Data In Motion triggers in the user's policy. you can configure default handling for unrecognized devices or network locations.Chapter 16 Client Agents: File and Print 305 Terminology File system scan: You can optionally configure the CFSA to run scheduled scans of all targeted files and folders on the local hard disk. You can configure custom handling for these devices and locations. Trusted applications: These are applications that are always exempt from CFSA control. they are always permitted to do so. Removable devices: These refer to any removable storage device. If a user is using a trusted application to copy or save a file to a removable device or network location. lsass. you may want to allow write access to authorized network folders but make other network locations read only. You can specify when and how often the scan runs. the CFSA applies Data In Motion triggers to the file. Machine policy settings allow you to target specific file types or folders. ` Read only: The user is not allowed to copy or save files to removable devices or network locations unless they are using a trusted application. and external hard disks. They can also include specified writable CD and DVD drives. the CFSA applies Data In Motion triggers to the file. ! The only policy-enabled applications recognized by the CFSA in the current release are Windows Explorer and DOS commands such as copy or xcopy. Handling: This term refers to settings in machine policy that determine how the CFSA handles user attempts to copy or save files to removable devices or network locations. Policy handling: See handling above.exe is included in the Trusted Application List machine policy settings for the CFSA. The available options are: Prohibited network locations: A prohibited network location is any network folder to which write access is denied by settings in the local machine policy. Policy-enabled applications: These are applications that the CFSA can integrate with to apply user policy. writable CD and DVD drives. including USB flash drives. ` Apply User Policy To File: If the user copies or saves a file using a policy-enabled application. Conversely. you cannot edit this list. .

the CFSA always applies the user policy specified by the Default Policy for Data At Rest setting. you need to edit the common client policy and the default user policy (or the policy for an appropriate user group).306 CA DLP Deployment guide Deploy the CFSA You install the CFSA with the client installation wizard (see step 4 on page 55). To quickly roll out the agent across multiple client machines. Note also the minimum service pack requirement when installing on Windows XP machines (see page 25). This will ensure that the relevant policy settings replicate down to your end-users and their respective client machines as soon as possible. These policy changes are described in the following section and on pages 307 . though you can customize policy for individual client machines. you can still customize the policies for individual machines and users as necessary. Which policies are applied? The CFSA applies both machine policy and user policy when assessing whether to allow files to be copied to removable devices or network locations. itself defined in the machine policy (see page 310). When applying Data In Motion triggers to files being copied to removable devices or network locations. The deployment procedure is summarized below. search the index for ‘common client policy’). you need to edit the machine policy for the host machine and an appropriate user policy. Of course. The machine policy is always the policy for the machine hosting the CFSA. The host machine inherits this policy from the common client policy (see the Administration console online help. When applying Data At Rest triggers during a file scan. the CFSA always applies the user policy for the CA DLP user currently logged onto the agent machine.to 313 respectively. . 2 To configure the Client File System Agent. 1 Install the CFSA 2 Configure the CFSA Machine policy changes User policy changes: Data In Motion triggers Data At Rest triggers Access Denied message Client File System Agent deployment procedure 1 Installation instructions for the Client File System Agent are on page 53. You then need to configure the CFSA by editing the machine policy and user policy.

We recommend that you edit the common client machine policy. Start Day. Excluded Files Default Policy for Data At Rest Enable File System Scan 310 310 310 310 Client machine policy: Client File System Agent folder To do this. Machine Policy [CMS-HARDY] Infrastructure Policy Engine Client File System Agent Data In Use Protection Removable Devices Network Locations Data At Rest Protection File System Scan Configuration Machine policy folder and setting Data In Use Protection: Network Locations Trusted Application List Default Handling Special Locations List Handling of Special Locations Page 309 309 309 309 Data At Rest Protection Included Folders. Excluded Folders Included Files.Chapter 16 Client Agents: File and Print 307 Configure the local machine policy To configure the CFSA. You may also need to adjust settings in the Policy Engine folder. Frequency (Days) 310 Page Policy Engine Maximum Number of Concurrent Operations Deadlock Detection Timeout (seconds) 310 310 . you need to configure the following machine policy settings: Machine policy folder and setting Data In Use Protection: Removable Devices Treat These Drives As Removable Trusted Application List Default Handling Special Device List Handling for Special Devices 308 308 308 308 308 Data At Rest Protection: File System Scan Configuration Start Time. you need to edit settings in the Client File System Agent folder of the machine policy on each client machine.

The available actions are: Allow write access: The user is allowed to copy files to listed devices.exe is always included in this list—see the ‘trusted application’ definition on page 305. You can also see them in Windows Explorer. In the Trusted Application List setting. For example. when you view the properties of a removable drive. Ordinarily. Drive letters must include a colon (such as D:). i Trusted applications override any device filters. Apply User Policy To File: If the user attempts to copy a file to a listed device using: Trusted Application List These are applications that are exempted from CFSA control. i The CFSA automatically treats writable CD and DVD drives as removable drives. you can use ? and * wildcards. Read only: The user is not allowed to copy files to listed devices (unless they are using a trusted application). That is. you identify the devices you want the CFSA to control or the ones you want it to ignore. Handling for Special Devices This setting determines how the CFSA handles attempts by a user to copy files to any removable device included in the Special Device List. For example. In the Special Device List setting. the CFSA would not apply policy to files being saved to these drives. such as Winword. That is.exe. For example. the device name is listed in the Hardware tab of the Properties dialog. then they are always allowed to save or copy files to network locations or removable devices. Disk drive names are shown in Windows Device Manager (such as IC25N020ATC504). i If a device name contains spaces. you may not need to monitor an in-house system application that always encrypts files when saving. you do not need to enclose it in quotes. lsass. To close this loophole. some external hard disks declare themselves as being a fixed drive when in fact they are easily removable. Policy is not applied. If required. ` A trusted application. i If no special devices are listed. you can explicitly identify these drives as removable. or burn files to CD or DVD. This setting controls attempts to copy files to unlisted devices (that is. Removable Devices folder This contains the following policy settings: Treat These Drives As Removable This setting instructs the CFSA to handle a fixed drive as if it were a removable drive. any device not in the Special Device List). the copy operation is blocked. you can define a list of trusted applications. Device names are shown in the Windows Device Manager applet. Default Handling The handling determines whether a device is writable or read only. ` Any other application. type the names of the devices that require special handling. Policy is not applied. In the Treat These Drives As Removable setting. By default. ` A policy-enabled application. the device is set to read only. You must supply the executable or process name. users are permitted to copy files to removable devices using these applications. The available actions are exactly the same as the handling for special devices (see below). add the applications you want to exempt from the CFSA. a user can copy a file directly from a trusted application to a removable device. even if the handling for that device blocks such copy operations or applies policy to the file content.308 CA DLP Deployment guide Data In Use Protection folder Settings in this folder determine whether a user is allowed to save or copy files to removable devices or network locations. if the user is using a trusted application. that is. Policy is not applied to the file. copy operations are always permitted. . policy is applied to the file using Data In Motion triggers. Special Device List This is a list of removable devices that require specific handling by the CFSA. In both cases. you can add the drive letter or the disk drive name (also called the ‘volume identifier’) set by the manufacturer. the default handling is applied to all devices.

any not listed in Special Locations List). . In the Special Locations List setting. ` Any other application. Policy is not applied. Policy is not applied to the file. policy is applied to the file using Data In Motion triggers. You must supply the UNC path. Apply User Policy To File: If the user attempts to copy a file to a special location using: Default Handling This setting determines how the agent handles attempts to copy files to unlisted network locations (that is. the copy operation is blocked. The available actions are: Allow write access: The user is allowed to copy files to special locations. Special Locations List This is a list of network locations that require specific handling by the CFSA. that is. you do not need to enclose it in quotes. Users can save files to any network location if they are using a trusted application. i If no special locations are listed. Handling of Special Locations This setting determines how the CFSA handles attempts to copy files to a network location listed in Special Locations. ` A policy-enabled application. copy operations are always permitted. for example: \\UX-FILESVR-01\New Project\Reports i If a path contains spaces. The available actions are exactly the same as for special locations (see below). You can either list the locations you want the CFSA to control or the ones you want it to ignore. the default handling is applied to all network locations. Read only: The user is not allowed to copy files to special network locations (unless they are using a trusted application). Users can save files directly from a trusted application to any network location. the location is set to read only.Chapter 16 Client Agents: File and Print 309 Network Locations folder This contains the following policy settings: Trusted Application List This works the same way as the Trusted Application List setting in the Removable Devices folder (see page 308). specify the network locations that you want to detect. ` A trusted application. i Trusted applications override any network location filters.

Frequency (days) specifies how often the scan runs.doc’ and ‘*. Start Time is specified as ‘minutes after midnight’. not the full name). By default. the scan starts at the next occurrence of the Start Time. the next scan will not run until the next occurrence of the Start Day. the CFSA scans all local folders except the \Windows and \Program Files folders. so enter 60 to specify a 1am start time. Enable File System Scan Set this to True to set up regular scans of all included files on the local machine. but if required you can use the Excluded list to omit specific file types such as .mp3 or . you may need to amend the these settings in the Policy Engines folder. settings in the File System Scan Configuration folder allow you to set the scan frequency. Or you can specify a different CA DLP user account (enter the user name. If you choose Next. Do not set the Start Day to a specific day of the week. set the Start Date to Sunday and the Frequency to 7. this could be later today or tomorrow.ppt’. This specifies when the scan first runs. but you can change these. They also determine which drives. Setting up daily file scans To do this. A CA DLP user account with this name is created automatically when you install a CMS. Then set the Start Day to ‘Next’ and the Frequency to 1. Note that by default the Excluded Folders setting uses %SystemRoot% and %ProgramFiles% variables to exclude the \Windows and \Program Files folders. For example. you can the Included list to specify the main folders you want to scan. By default.310 CA DLP Deployment guide Data At Rest Protection folder Settings in this folder control how often the CFSA runs scheduled scans of the local hard disk. It defaults to ‘DefaultClientFileUser’. if the client machine is restarted. when it next runs depends on the Frequency.log files. Start Day can be any day of the week or ‘Next’. Included Files. File System Scan Configuration folder These settings determine when and how often the CFSA scans the local hard disk.xls’. You must only edit these settings if instructed to do so by CA technical staff: Maximum Number of Concurrent Operations Defines the maximum number of files that can be processed simultaneously by a policy engine. folders and files are scanned. the Included setting lists all the common document types such as ‘*. This account is created specifically to apply policy to scanned files across all workstations. to run a scan every Sunday. Included Folders. For example. Note that the Excluded list takes precedence if there is a conflict. plus the number of days between each scan. but then use the Excluded list to omit specific subfolders. No files are excluded by default. you can include all spreadsheets (‘*. They specify the time and day when the full scan begins. Excluded Files These settings determine which files to scan within the included folders. Policy Engine folder For performance reasons. and which user policy is applied to scanned files. If you do enable full scans. Default Policy for Data At Rest This setting determines which user policy gets applied to scanned files. .xls’) but exclude specific files such as ‘Holiday_Form. For example. set the Start Time as required. Deadlock Detection Timeout (seconds) Specifies how long a worker thread must be inactive while processing an event before the policy engine considers the thread to have stalled. Excluded Folders These settings determine which folders to scan.

to do this.Chapter 16 Client Agents: File and Print 311 Configure the user policy To complete the configuration of the CFSA. you edit settings in the \Extensions\CFSA folder. For each trigger. or to determine whether the file matches a particular document classification. Which File Sources? In each Data At Rest trigger. this setting instructs the trigger to process files or documents captured or scanned by any of the following: Page ` Client File System Agent ` File Scanning Agent ` File Importer ` External Agent API for File You must ensure that the Client File System Agent check box is selected! This enables the trigger to analyze local files scanned by the CFSA. For information about these general trigger settings.docx files ` A list of specific .zip files to analyze. Individual/Embedded File List If required. Data At Rest triggers can look for files contained within a zip file or embedded in a master file. You also need to set up the Access Denied message shown to users when a removable device or network location is prohibited. Title. To do this.docx to analyze all . you need to edit your user policies. User policy settings Data At Rest triggers Which File Sources? Top Level File Lists Individual/Embedded File List Copy File To Location Intervention See opposite See opposite See opposite 312 312 Data At Rest triggers The general trigger settings let you specify which types of document you want the CFSA to scan. Message 313 . To control attempts to copy files to removable devices or network locations. For example. edit the Individual/Embedded File Lists. Edit these lists to identify the names of files that you want to apply policy to when a scan runs. Top Level File Lists All Data At Rest triggers include Top Level File Lists refer to detect normal files or zip files. For example. Access Denied Message folder Frequency. For each trigger. you need to edit Data In Motion triggers and control actions. you can specify: Data In Motion triggers Which File Sources? Removable Device or Printer Lists Top Level File Lists Individual/Embedded File List Intervention 312 312 312 312 312 ` * to analyze all files ` *. you can edit the triggers to detect specific file formats (such as Microsoft Word documents). To configure scheduled scans of the local hard disk. you can choose whether to use an Included. you can choose to use an Included or Excluded file list. Excluded or Ignored file list. see the Administration console online help. They can also analyze a file’s text content to detect the presence or absence of key phrases. you need to edit Data At Rest triggers and control actions.

Copy File to Location Data At Rest control actions also support ‘copy’ action. see the Administration console online help. You can specify lists of included or excluded devices. Individual/Embedded File List Use these lists to detect files contained within a zip file or embedded in a master file. For information about these general settings. You can also replace deleted files with an explanatory stub file to alleviate any user concerns or categorize the resulting file event.zip and Included Individual/Embedded File Names to *. the Intervention setting determines how the CFSA handles files being copied to removable devices or network locations. i DoD deletion is forensic deletion. Removable Device or Printer Lists These settings define a further device filter for the CFSA. The available options include Block. permitting you to copy scanned files to an alternative location.zip files. these lists are similar to the Special Device List in machine policy (see page 308). If you set up the trigger to use: ` Included Removable devices. these ensure that deleted files cannot be recovered (see below). Top Level File Lists Use these lists to detect normal files or zip files. the trigger only fires if a user tries to copy a file to a listed device using a policy-enabled application (see page 305). these devices are exempted from control by the CFSA. Inform and Categorize. If set to Block.zip files for a specific file. you need to edit the following settings in the Data In Motion capture and control triggers. via a policy-enabled application. you can feasibly search all . Specifically. When used in combination with a ‘delete’ actions (see below). Data In Motion triggers The general trigger settings let you specify which types of document you want the CFSA to detect. You configure them in the same way as Data At Rest triggers—see page 311. The available options allow you to categorize delete scanned files. the copy operation is denied. . If necessary. Which File Sources? In each Data In Motion trigger.doc files contained within . ‘DoD’ is a reference to Department of Defense approved methods for purging storage media. Warn. a copy action effectively becomes a ‘move file’ action.doc to search for all . will fire the trigger.312 CA DLP Deployment guide Using these lists in conjunction with the Top Level File Lists. Intervention In each Data At Rest control action. the Intervention setting determines how the CFSA handles scanned files. This section focuses on the key Data In Motion settings for the CFSA. so called because the storage media are purged to guarantee that a file cannot be recovered and used to obtain evidence in legal discovery. set Included Top Level Names to *. you can specify DoD deletions. Intervention In each Data In Motion control action. ` Excluded Removable devices. But attempts to copy files to any other (unlisted) removable devices. You configure them in the same way as Data At Rest triggers—see page 311. this setting instructs the trigger to analyze files or documents captured by any of the following agents: ` Client File System Agent ` Client Print System Agent ` Network Boundary Agent You must ensure that the Client File System Agent check box is selected! This enables the trigger to analyze files being copied or saved to removable devices or network locations. For example.

If they then restart Word and open the document again.Chapter 16 Client Agents: File and Print 313 Access Denied Message subfolder Find this subfolder in the \Extensions\Client File System Agent folder. This happens the first time they open a file from a prohibited device or network location. For example. The message is only shown once per application per Windows session. or to display: ` Once per application: A user sees the message when they open a file from a prohibited source. ` Once per login: A user only sees the message once in a Windows session. the message is shown if they open a Microsoft Word document stored on a prohibited USB device. i A prohibited source is any removable device or network location to which write access is denied. Message Use Title and Message settings to provide a notification message for users. You can set the message to never display. the message is shown if they open a Microsoft Word document stored on a prohibited USB device. But now if they restart Word and open the document once more. It contains settings that define the message seen by users when they open files from a prohibited device or network location. ` Once per application instance: A user sees the message each time they open a file from a prohibited source. Write access may be denied by settings in the local machine policy or by Data In Motion triggers in the user's policy. ` Once per volume mount: A user sees the message if they plug in a prohibited device such as a USB drive and then open a file from that device. This message typically warns users that they are barred from saving file changes to removable devices or certain network folders. The message is only shown the first time they open a file from that device. explaining that they will be unable to save changes to the current file. The Frequency setting determines how often this message is shown. Frequency. the message is not shown. Title. . the message is shown again. As above.

314 CA DLP Deployment guide About the Client Print System Agent The Client Print System Agent (CPSA). If the printer is excluded from policy control. 4 File filter: Finally. To determine whether or not a user is allowed to send a document to a specific printer. the CPSA applies printer and file filters defined within the user policy—see step 3. The actual policy is always that of the user currently logged onto the client machine hosting the CPSA. . sometimes also referred to as ‘Policy on Print’. the CPSA checks which application the user is using. you must close down all applications that support printing (see page 55). policy control. the CPSA only applies user policy when assessing whether to allow a print job. the CPSA checks the user policy to determine whether the button is disabled. Specifically. the Data in Motion triggers examine the file’s properties and analyze its text content. the CPSA permits the user to send the document to the printer. Policy is not applied. 2 Application filter: Alternatively if a user attempts to print a file or document from an application (for example. After installing the CPSA (see step 4 on page 55). the CPSA blocks the print job and optionally displays a notification dialog with an explanatory message. by choosing File > Print in Microsoft Word). it uses Data in Motion triggers. i The CPSA is not supported on 64-bit machines. the print request is allowed to continue. The CPSA also provides the ability to disable the Print Screen button on a user’s keyboard. This filtering procedure is summarized in the flow chart on page 303. the triggers apply a file filter. the agent applies the following filters: 1 Print Screen filter: When a user presses the Print Screen button. The results of this policy processing determine whether the CPSA blocks or allows the print operation. What filters does the CPSA use? The CPSA is highly flexible and supports various levels of filtering. Otherwise. 3 Printer filter: When the CPSA applies user policy. Before installing the CPSA. is designed to detect and control user attempts to send documents to local or network printers. i No print event is generated when the CPSA blocks a Print Screen operation. First. If the button is disabled. Which user policy is applied? Unlike the CFSA. It can then apply policy to the documents being printed and use the results of policy processing to either allow or block the print operation. or excluded from. If this is: ` Listed in the IgnoredApplicationList registry setting (see page 318). you need to configure it by editing CA DLP registry settings on the host machine and the Data In Motion triggers in your user policies. CA DLP does not save details of these blockings in the CMS database. ` Any other application. allowing you to closely control the use of printers in your organization. these triggers check whether the printer itself is subject to. the CPSA applies the Disable Print Screen? setting in the \System Settings folder.

First. If so. the CPSA checks whether the user is printing from an application or is using the Print Screen button. the CPSA checks the registry to see whether the application is exempt from policy control (5). Printing from an application Check local registry 5. If not. If the file is authorized. These triggers first check if an authorized printer is being used.Chapter 16 Client Agents: File and Print 315 CPSA flow chart In the diagram below. the file’s properties and text content are analyzed. the CFSA allows the file to be printed. If the file is not authorized. If printing from an application (4). If so. If the user is simply using the Print Screen button to send the screen contents to a printer (2). the print operation is allowed. a user tries to print a file (1). Apply DIM triggers: Using excluded printer? No Is file authorized? No Apply DIM control action Yes Yes Block Other Document cannot be printed Document can be printed . If not. Is Print Screen disabled? No Yes 6. CPSA detects user trying to print a document 2. it applies Data In Motion policy triggers (6). the CPSA applies user policy to the print request to determine whether or not the Print Screen button is disabled (2). 1. a control action determines whether to allow the print operation. Is the user using an ‘ignored application’ to print the document? No Yes Registry User Policy Apply user policy to document 3. the CFSA allows the file to be printed. Using the Print Screen button 4.

The general trigger settings let you specify which types of document you want the agent to detect. To quickly roll out the agent across multiple client machines. \Extensions\CPSA policy folder Frequency. you need to edit these registry values on each host machine and also edit the default user policy (or the policy for an appropriate user group). This section focuses on the key settings for the CPSA. In addition. to disable the Print Screen button. The deployment procedure is summarized below. Specifically. For information about these settings. you can still customize the policies for individual users as necessary. you need to edit an appropriate user policy. The deployment procedure is summarized below.316 CA DLP Deployment guide Deploy the CPSA You install the CPSA with the client installation wizard (see step 4 on page 55). you need to configure the Data In Motion triggers and control actions in your user policies. You then need to configure the CPSA by editing the user policy and registry values on the host machine. 2 To configure the CPSA. see the online help. User policy setting Data In Motion control triggers Page 1 Install the CPSA Configure the CPSA 2 User policy changes: Data In Motion triggers Print Screen settings Registry changes: IgnoredApplicationList Which File Sources? Which Removable Device or Printer List? Included Removable Devices or Printers Excluded Removable Devices or Printers Intervention 317 317 317 317 317 3 \System Settings policy folder Client Print System Agent deployment procedure 1 Installation instructions for the CPSA are on page 53. Message 317 Disable Print Screen? 317 . 3 You also need to edit the list of ‘ignored applications’ in the registry. These policy changes are described on page 316. Of course. you also need to edit settings in the \System Settings and \Extensions\CPSA folders. CPSA user policy changes To complete the configuration of the Client Print System Agent. you need to edit these settings in the Data In Motion capture triggers (if you want to capture details about the document being printed) and control triggers (if you want to block or warn users). Title. This will ensure that the relevant policy settings replicate down to your end users and their respective client machines as soon as possible. See page 318.

or to only display once per session when the user first tries to use the Print Screen button. System Settings folder This contains the following CFPSA setting: Disable Print Screen? If this setting is set to True. It contains settings that define the message seen by users when they press the Print Screen button (if it is disabled). You can specify lists of included or excluded printers. ` Included printers. in particular. No policy triggers activate and CA DLP does not save details of these blockings in the CMS database. i No print event is generated when the CPSA blocks a Print Screen operation. Block. Message The Frequency setting determines how often the message is shown. Specifically. this setting instructs the trigger to analyze documents captured by any of the following agents: Intervention In each Data In Motion control action. For information about these general settings. or you can use ? and * wildcards.Chapter 16 Client Agents: File and Print 317 Data In Motion folders The general trigger settings let you specify which types of document you want the agent to detect. You can specify the exact printer name. If you set up the trigger to use: Print Screen Denied Message subfolder Find this subfolder in the \Extensions\Client Print System Agent folder. You can set the message to never display. these printers are exempted from control by the CPSA. You can also check printer names in Windows Explorer. the CPSA blocks the print job when the Print Screen button is pressed. It can optionally display a notification dialog with an explanatory message—see below. CA DLP allows the user to choose whether to continue and send their document to the printer. ` Client File System Agent ` Client Print System Agent ` Network Boundary Agent You must ensure that the Client Print System Agent check box is selected! This enables the trigger to analyze documents being printed. Which Removable Device or Printer List? Included Removable Devices or Printers Excluded Removable Devices or Printers These settings jointly define a further printer filter for the CPSA. . But attempts to send documents to any other (unlisted) printer will cause the trigger to fire. The message typically informs the user that using Print Screen is not allowed. the Intervention setting determines how the trigger handles attempts to print documents. its name is listed in the General tab of the Properties dialog. to always display. the trigger only fires if a user tries to send a document to a listed printer. If set to Warn. Frequency. as shown in the Windows Printers and Faxes applet. this setting determines which documents are analyzed. Warn and. the print operation via the selected printer is denied. This section focuses on the key Data In Motion settings for the CPSA. Title. see the Administration console online help. The available options include Inform. when you view the properties of a printer. ` Excluded printers. Specifically. if set to block. you need to edit the following settings in the Data In Motion capture triggers (if you want to capture details about the files being printed) and control triggers (if you want to block or warn users): Which File Sources? In each Data In Motion trigger.

For details. Users are permitted to print documents using these applications. you may not want to monitor the printing of documents from graphics packages. IgnoredApplicationList IgnoredApplicationList Type: REG_SZ Data: Defaults to empty. plus informational and status messages i Setting LogLevel=3 will cause the log file to grow extremely rapidly. For example. This level of logging is provided for testing and diagnostic purposes. For example. . you can define a list of applications you want the agent to ignore (if required) and set the log level. you can configure the agent to only log errors or important system messages. Briefly. you can edit the following automatic registry values on each host machine. This specifies a semicolonseparated list of applications that are exempted from CPSA control. for example. see the Administration console online help. The supported logging levels are: 1 Errors only 2 Errors and warnings 3 As 2. Log entries are written to the Activity log (viewable in the Administration console). you must restart any relevant application. it shows storage and retrieval on every resource item. search the index for ‘logfiles’.318 CA DLP Deployment guide CPSA optional registry changes To configure the CPSA. This determines the level of logging for the Client File Print System Agent. LogLevel LogLevel Type: REG_DWORD Data: Defaults to 2. i For changes to this registry setting to take effect.

Third party integration Third party integration his chapter focuses on CA DLP integration with third party solutions such as e-mail archiving applications. See page 327. Message Manager passes e-mails and IM conversations to policy engines for processing before they are archived. it describes how e-mails stored in a third party archive are still searchable using the iConsole or Data Management console and how. chapter 17 T ZANTAZ Digital Safe integration: CA DLP can intercept e-mails extracted from a journal mailbox in Microsoft Exchange (using the CA Universal Adapter) and forward these to a Digital Safe archive. IBM DB2 CommonStore: CA DLP can intercept e-mails extracted from a journal mailbox in Microsoft Exchange (using the CA Universal Adapter). In particular. See page 325. See page 329. The various integration components are summarized below. EMC SourceOne integration: CA DLP can intercept e mails extracted from an Exchange journal mailbox and apply smart tags to these e-mails before they are archived in SourceOne. For details. EMC EmailXtender integration: CA DLP can extract e-mails from the EMC EmailXtender archive (using the External Agent API) and import them into the CMS. See page 366. or a Notes Mail Database on a Domino Server and forward these to IBM DB2 CommonStore. For details. ZANTAZ EAS integration: CA DLP can extract e-mails from the EAS archive (using the External Agent API) and import them into the CMS.17. see page 364. e-mails can be categorized (using smart tags) before they are archived. List continues on next page. . For details. for Enterprise Vault integration. Integration components CA Message Manager: Using the External Agent API. see page 357. see page 339 and page 348 respectively. Symantec Enterprise Vault integration: CA DLP can intercept e-mails extracted from an Exchange journal mailbox and apply smart tags to these e-mails before they are archived in Enterprise Vault.

Remote Data Manager (RDM): The RDM retrieves e-mail data that has been archived in third party remote storage locations. See page 369.Suite in a parking database. enables external applications and CA DLP components such as the NBA and Milter MTA agent to use socket connections to call the External Agent API from a remote location. see page 382. Socket API: The Socket API.0 with SP 03+ 6.1. say.3 Zantaz EAS Symantec Enterprise Vault Zantaz Digital Safe IBM DB2 CommonStore for Exchange or Domino EMC EmailXtender EMC SourceOne Email Management for Exchange 4. It enables reviewers to retrieve and view archived e-mails when running event searches in.1 Service Pack r12.1 Service Pack r12.7. ICAP Agent: The ICAP Agent enables CA DLP to integrate with Internet Content Adaptation Protocol (ICAP) clients running on proxy servers (such as Blue Coat ProxySG).320 CA DLP Deployment guide External Agent API: The External Agent API connects to third party applications and extracts archived e-mails as EVF files to a cache folder that can be accessed by Event Import. available as an External Agent subfeature. See page 374.6 4. including from a non-Windows system. This provides CA DLP with a further method for controlling HTTP activity such as file uploads and downloads.Suite integration’. For details. v5 SP1 6.5 SP1 . Details are in the technical note ‘iQ. the iConsole and Data Management console.x. Supported archive versions CA DLP supports the following versions of these third party integration components. see page 388.0.5. iQ. Archive CA Message Manager Supported versions r12. available from Technical Support—see page 23. For details.8 SR1 Build 263 6.3 8.Suite integration: The CA DLP Domino server agent can process e-mails deposited by iQ.

Chapter 17 Third party integration 321 Integration models CA DLP uses various methods to integrate with third party e-mail archiving products. The resulting events are replicated to the CMS (5). Note also that each integration model can use one of three methods for ingesting events into CA DLP. This is necessary to accommodate the diverse processes used by different archiving products. 4d: Agent outputs to EVFs to be ingested by Import Policy job: The archive solution uses the External Agent API (3) to convert the archived e-mails to event (EVF) files. Model 1: Push from archive Archive passes e-mails to CA DLP In this model. EMC EmailXtender—see page 364. there are four methods for ingesting the e-mails into the CMS: 4a: Agent outputs to local policy engine: The archive solution notifies a CA DLP integration agent (3) that e-mails are available for processing. except that the CA DLP agent passes the e-mails to remote policy engines via a PE hub (4b). ZANTAZ EAS—see page 327. These EVFs are saved in a cache (4d). These EVFs are saved in a cache (4c). At this point in the integration model. In all cases. For details about the operational benefits associated with each ingestion method. summarized below and on the following pages. The resulting e-mail events are then replicated up to the CMS (5). Archive integrations currently using this model are: CA Message Manager—see page 325. instead. from where they are retrieved by Event Import and passed to a local policy engine for processing. 4c: Agent outputs to EVFs for direct import into the CMS: The archive solution uses the External Agent API (3) to convert the archived e-mails to event (EVF) files. 4a 4b 4c 4d 1 Mailbox 2 Archive 3 Agent EVF 5 CMS EVF 4 Ingestion methods Integration model 1: Push from archive . a third party application (step 2 in the diagram below) passes archived e-mails from a journal mailbox (1) to CA DLP. from where they are subsequently imported directly onto the CMS (5). see page 324. 4b: Agent outputs to policy engines via hub: As for 4a. These integration methods can be grouped into three basic models. a database record for each e-mail references the associated entry in the archive. only the event metadata is saved on the CMS. Symantec Enterprise Vault—see page 329. EMC SourceOne—see page 366. The actual message data is not stored on the CMS. The agent then passes the e-mails to a local policy engine (4a).

4b: UA outputs to EVFs to be ingested by Import Policy job: The UA converts the e-mails to EVF file. the Universal Adapter (UA) then outputs the same e-mails again. These EVFs are saved in a cache (4b). The archive integration currently using this model is ZANTAZ Digital Safe—see page 357.322 CA DLP Deployment guide Model 2: Push to archive (direct) UA imports e-mails from mailbox and outputs to archive In this model. After confirmation that the e-mails have been successfully archived. from where they are subsequently imported onto the CMS (5). These EVFs are saved in a cache (4c). see page 324. The archive adapter then outputs them to the archive. The actual message data is not stored on the CMS. At this point in the integration model. adds a unique ID to each e-mail and outputs them to an archive adapter (3). from where they are retrieved by Event Import and passed to a local policy engine for processing. As in model 1. 4c: UA outputs to EVFs for direct import into CMS: The UA converts the e-mails to EVF files. there are three methods for ingesting the e-mails into the CMS: 4a: UA outputs to policy engines: The UA commits the e-mails directly to a policy engine (4a). instead. 1 Mailbox 2 Universal Adapter 3 Archive 4a 4b 4c 5 CMS EVF EVF 4 Ingestion methods Integration model 2: Push to archive (direct) . For details about the operational benefits associated with each ingestion method. only the event metadata is saved on the CMS. CA’s Universal Adapter (step 2 in the diagrams below) imports e-mails from journal mailboxes (1). The resulting e-mail events are then replicated up to the CMS (5). a database record for each e-mail references the associated entry in the archive. The resulting e-mail events are then replicated up to the CMS (5).

CA’s Universal Adapter (step 2 in the diagram below) imports e-mails from journal mailboxes (1). Archive integrations currently using this model are: IBM DB2 CommonStore for Exchange—see page 339. 3 Output mailboxes 4 Archive 1 Mailbox 2 Universal Adapter 5a 5b 5c 6 CMS EVF EVF 5 Ingestion methods Integration model 3: Push to archive (via mailbox) . For details about the operational benefits associated with each ingestion method. this method allows smart tags to be assigned to the ingested e-mails. Unlike ingestion methods 5b and 5c. adds a unique ID to each e-mail and outputs them to mailboxes (3). from where they are subsequently imported onto the CMS (6). These EVFs are saved in a cache (5b). see page 324. The resulting e-mail events are then replicated up to the CMS (6). but also permits ingestion to be scheduled for periods of low network activity. 5b: UA outputs to EVFs to be ingested by Import Policy job: The UA converts the e-mails to EVF file. this method has no additional storage overhead. Like method 5a. a database record for each e-mail references the associated entry in the archive. the Universal Adapter also outputs the same e-mails (5) either to a policy engine or to EVF files. After confirmation that the e-mails have been successfully archived. These EVFs are saved in a cache (5c). The actual message data is not stored on the CMS. from where they are retrieved by Event Import and passed to a local policy engine for processing. As in models 1 and 2. only the event metadata is saved on the CMS. instead. IBM DB2 CommonStore for Lotus Domino—see page 339. 5c: UA outputs to EVFs for direct import into CMS: The UA converts the e-mails to EVF files.Chapter 17 Third party integration 323 Model 3: Push to archive (via mailbox) UA imports e-mails from mailbox and outputs to pickup mailboxes for archiving In this model. As with models 1 and 2. from where they are picked up by the archive solution (4). The resulting e-mail events are then replicated up to the CMS (6). there are three methods for ingesting the e-mails into the CMS: 5a: UA outputs to policy engines: The UA commits the e-mails directly to a policy engine (5a).

This lets you archive e-mails as soon as possible while scheduling ingestion for periods of low network activity. then imported directly The integration agent or UA converts archived e-mails to event (EVF) files. this method has no additional storage overhead. from where they are retrieved by Event Import and passed to a policy engine for processing. saving them as properties of the e-mails before they are archived. This method has these benefits: High ingestion rates: Because no policy processing is required. c. this ingestion method is potentially the fastest. c. This is particularly useful if complex policy processing is required. Output to policy engines The integration agent or UA outputs e-mails via a policy engine hub to a policy engine. to add smart tags to e-mails before they are stored in your archive. These EVFs are saved in a cache. However. b and c). Output to EVFs. This allows rapid and efficient filtering when using CA DLP consoles to search for archived events. Output to EVFs. . And like method b. archiving and ingestion into CA DLP are two separate processes. Decouples archiving from ingestion: As with method b. Note that the UA can automatically assign smart tags to e-mails before they are archived. Ingestion method Operational benefit Smart tags stored with e-mails in archive Smart tags stored with e-mail events in CMS Decouples archiving from ingestion Potentially high ingestion rates b. This allows you to schedule ingestion for periods of low network activity. However. you must add fault-tolerance to the cache by implementing regular backups. Unlike the EVF-based ingestion methods. This method has the following benefits: Smart tags stored with e-mail events in CMS: As with method a. your own integration software must handle any smart tags returned from the External Agent. In each case. This method has the following benefits: Smart tags stored with e-mails in archive: It allows you. you can store smart tags with e-mail events when they are saved on the CMS. Decouples archiving from ingestion: Saving e-mails in your archive and ingesting the corresponding events into CA DLP are performed as two separate processes. because this ingestion method relies on an interim EVF cache you must add fault-tolerance to the cache by implementing regular backups. see below for details. Each method has its own benefits. CA DLP (either an integration agent or the Universal Adapter) processes the e-mails to be ingested and outputs them to EVF files or to policy engines. using policy engines. a. and you must choose the method most appropriate for your organization. this ingestion method does not allow smart tags to be assigned to the ingested e-mails.324 CA DLP Deployment guide Comparison of ingestion methods into CA DLP Each archive integration model supports three methods for ingesting e-mails into the CMS (methods a. These EVFs are saved in a cache. then ingested by Import Policy job The integration agent or UA converts archived e-mails to event (EVF) files. b. a. from where they are subsequently imported directly onto the CMS by Event Import. But if your archive integration uses the External Agent API. Smart tags stored with e-mail events in CMS: You can also store smart tags with the corresponding e-mail events on the CMS.

plus any smart tags generated by policy triggers. Note that the actual e-mail or IM content is not saved on the CMS. This analyzes the messages received from Message Manager and applies policy triggers as necessary. is then replicated to the CMS. including its metadata. This is an enterprise message archival and management suite of products that enables organizations to manage and archive huge volumes of messages (e-mails and IM conversations). In this example. The unique message identifier. including metadata that incorporates the unique message identifiers. Each message passed to the policy engine includes a unique identifier. Using the CA DLP External Agent API. . the Remote Data Manager uses the message identifiers to retrieve the associated e-mails or IM conversations from the Message Manager archive during subsequent iConsole event searches. The policy engine then processes these messages. 2 External Agent API: This provides the interface that the Mail Processor (1a) uses to pass messages to the local policy engine (3). These include a Mail Processor server (1a) and an Archive server (1b). are replicated to the CMS and stored in the database (4a). This section summarizes how to set up CA DLP to integrate with Message Manager.Chapter 17 Third party integration 325 CA Message Manager integration CA DLP can integrate with CA Message Manager. The diagram below shows an example deployment with. the Remote Data Manager (4b) retrieves data for archived e-mails and IM conversations from the archive (1b). instead. 5 iConsole: When displaying captured e-mails in the iConsole. the CMS also hosts the Remote Data Manager (4b). a CA DLP event is generated. CA DLP integration with CA Message Manager 1 CA Message Manager servers. Finally. for simplicity. Included with each message is a unique identifier. 4 CMS: Events generated as a result of policy processing. the event record in the CMS database includes the unique identifier that references the associated message in the archive. i For details about supported versions of Message Manager. a single Mail Processor server for Message Manager. The event. Message Manager passes messages to a local CA DLP policy engine. see page 320. If a message causes a policy trigger to activate. are saved with the event’s metadata. 3 Policy engine.

especially step 6. . 3 Install the RDM: You can install the RDM on any CA DLP server.2 In the same wizard screen. select CA Message Manager from the archive list. If. see pages 369 to 381. In particular. Remote Data Manager (RDM): This allows CA DLP users to retrieve messages from the Message Manager archive and display them in the iConsole or Data Management console. this component imports messages into CA DLP and applies policy triggers to them. edit the following registry value: CAMM_Server Type: REG_SZ Data: Set this to the name or IP address of the Message Manager machine now hosting the Archive server. 2 Install policy engines: We recommend that you install a policy engine (PE) on the same machines as the External Agent API (that is. Import Policy: As the name suggests. To do this. see chapter 11 (page 199). For details. 3. see pages 388 to 389. run the CA DLP server installation wizard: 3. you can specify the new host server by modifying a value in the following registry key on the RDM host machine: HKEY_LOCAL_MACHINE\Software\ \ComputerAssociates\CA DLP \CurrentVersion\Remote Data Manager Within this key. To do this. you need to install the External Agent API on each CA Message Manager machine hosting a Mail Processor server. run the CA DLP integration agent installation wizard. when you run the installation wizard. this host machine changes after you install the RDM. The RDM uses the unique message identifier included in each event’s metadata to retrieve that message from the archive. Set up integration To integrate CA DLP with Message Manager: 1 Deploy the External Agent API: First. specify the name or IP address of the CA Message Manager machine hosting the Archive server. For full External Agent API deployment details.326 CA DLP Deployment guide Set up CA Message Manager integration Required CA DLP components The CA DLP components required for integration with Message Manager are: External Agent API: This allows external applications such as CA Message Manager to pass messages to CA DLP for policy processing. Specifying a different Message Manager host server The RDM needs to be able to identify the CA Message Manager machine hosting the Archive server. on each Message Manager machine hosting a Mail Processor server). The architecture diagram on page 325 shows the RDM installed on the CMS server. be aware that you do not need to install a Remote Policy Engine Connector or the Socket API (see step 3 on page 370).1 In the Remote Data Manager Configuration wizard screen. at any point. To install the RDM. run the CA DLP server installation wizard. The RDM is described on page 388. For full PE instructions.

The diagram below summarizes the key components and processes involved. The actual message data is not saved on the CMS. instead. which in turn passes data to the External Agent API (1c). feeding data into a single EVF file cache.exe (1b). For simplicity. For very large e-mail archives. This cache provides the source data for the CA DLP Event Import utility (4). a record in the CMS database for each imported e-mail references the associated entry in the e-mail store (9). 2 E-mail server 9 E-mail store 6 iConsole 1 E-mail archive server 1a 8 7 RDM machine Searching for archived e-mails 1b Archive indexer process Internet 1c External Agent API 5 CMS 3 EVF file cache 4 Event Import machines Importing e-mails into CA DLP CA DLP integration with ZANTAZ EAS 1 This server hosts the e-mail archive solution. In practice. This section summarizes how e-mails are extracted from the EAS archive and imported into CA DLP.Chapter 17 Third party integration 327 ZANTAZ EAS integration CA DLP can integrate with the ZANTAZ EAS solution. these data requests are sent via Microsoft IIS (Internet Information Services) (8). EAS IndexerService. a large organization may have many such servers feeding data into multiple caches. The External Agent API extracts archived e-mails and saves them as EVF files in a cache (3). The EAS archive solution uses an indexer process. This connects to an e-mail server such as Microsoft Exchange (2) and archives messages in the e-mail store (9). When displaying captured e-mails in the iConsole (6). . ZANTAZ EAS (1a). Each Event Import utility imports archived e-mails into the CMS (5). the diagram shows a single e-mail archive server. you may need to run multiple Event Import utilities simultaneously to avoid import bottlenecks. In the case of EAS. the Remote Data Manager utility (7) retrieves data for e-mails archived in the e-mail store (9). This utility requires the CA DLP infrastructure.

For details. Retrieve archived events with RDM When the External Agent API receives data from the EAS indexer process. See step 6 on page 371 for details. see page 414 for details. To install the RDM. For full details. The RDM is described on page 388. see page 548. you need to configure an import job. It converts archived e-mails into CA DLP event files and saves them to a shared network folder where they can be accessed by the Event Import utility. RDM: Finally. After installing your Event Import machines. select ZANTAZ EAS from the archive list and specify the EAS server and port number—see step 6 on page 389. 3 . see page 369. you need to install the External Agent API on the EAS server. you run the CA DLP server installation wizard. The RDM then uses this identifier to retrieve the e-mail from the EAS archive during subsequent event searches. In the Remote Data Manager Configuration screen. see page 393 for details. The RDM enables CA DLP to retrieve events that are archived in third party remote storage locations and display them in the iConsole or Data Management console—see RDM section opposite. you need to install the Remote Data Manager (RDM).328 CA DLP Deployment guide Set up EAS integration Three CA DLP components are required to integrate with ZANTAZ EAS: 1 External Agent API: First. i ZANTAZ EAS users will need to pay particular attention to step 7 on page 371. This identifier is added to the event metadata and replicated to the CMS. See also the EVF file cache guidelines on page 372. Full parameter details are given in chapter 18 ‘Event Import’. You can test whether CA DLP console users are able to retrieve e-mails archived in EAS. Configure EAS integration After installing the External Agent API. it converts the archived e-mail into a CA DLP event file along with a unique event identifier. 2 Event Import: The Event Import utility retrieves the extracted e-mails from the shared folder specified in step 1 and imports them into the CMS. The External Agent API enables CA DLP to integrate with third party e-mail archives such as EAS. you may need to edit certain values in the External Agent API registry key. Full instructions for installing Event Import machines are given in chapter 18 ‘Event Import’.

From the Symantec Web site: “Enterprise Vault software provides a flexible archiving framework to enable the discovery of content held within email. Processed events are then replicated (3a) from the policy engine up to the CMS (4). Finally. The hub allocates the e-mail to a policy engine. when displaying archived e-mails in a console (5). Enterprise Vault notifies the EV archive agent when it extracts an e-mail from a Microsoft Exchange journal mailbox.” Integration is provided through a CA DLP custom filter for Enterprise Vault. When integration is enabled. which then applies the appropriate smart tags to the e-mail (typically an e-mail category and a retention date—see page 330) and passes this data back to the EV archive agent and then to Enterprise Vault. 2d 6 4 Internet 1 2 3a 3 5 2a 2b 2c CA DLP integration with Enterprise Vault Enterprise Vault extracts an e-mail from the journal mailbox in Microsoft Exchange (1). file system and collaborative environments. while helping to reduce storage costs and simplifying management.Chapter 17 Third party integration 329 Symantec Enterprise Vault integration CA DLP can integrate with the Symantec Enterprise Vault archive solution. the Remote Data Manager (6) retrieves data for e-mails stored in the Enterprise Vault archive (2d). . the Enterprise Vault (2a) notifies the EV archive agent (2b) that an e-mail is available for processing. The EV archive agent passes the e-mail to the hub (2c). wgnsev. These are saved as event metadata.dll. In this chapter. Finally. The EV archive agent passes a copy of the e-mail to the policy engine hub. Enterprise Vault archives the e-mail along with its smart tag details. This applies triggers as necessary and applies smart tags to the e-mail. the term ‘EV archive agent’ refers to this custom filter. The hub allocates the e-mail to a policy engine for processing (3). On this host server (2).

configure the RetentionSmartTag registry value. then the default registry settings will apply.2 Set up a retention smart tag: On the machine hosting the Enterprise Vault server agent. involves the following main tasks: 1 Filter multiple smart tag values Create subkey for smart tag Configure registry on EV archive agent 1. This retention date specifies when Enterprise Vault will purge the archived e-mail event.2 Configure the ResolveMultipleValues registry value—see page 337. For details.1 On the EV archive agent. To do this: 1. By default. create a subkey for the smart tag you want to configure specifically. 1 Filter multiple smart tag values: In CA DLP. configure the RetentionSmartTag registry value (see page 336) to match that of one of the following: ` RetentionSmartTagDiscardValue ` RetentionSmartTagForceDiscardValue i Details of all the Enterprise Vault server agent registry keys can be found on pages 333 to 337. When the trigger activates. you can assign multiple values to a smart tag. Public and Uncategorized. i The value of the retention smart tag must match the corresponding retention category in Enterprise Vault. as described on page 336. The Smart Tags setting in each policy trigger defines the tag associated with that trigger. see page 337. For example. you can assign to any trigger a tag such as Document Type with values of Privileged Content and Employment Solicitation. you can set up a smart tag rule. this tag is saved with the event metadata in the CMS database. Set up retention smart tag Configure registry on EV archive agent 2. The name of this subkey must match the smart tag name. 2.3 Use retention categories to delete: On the Smart Tagging tasks for use with Enterprise Vault These steps are described opposite. as created in step 2. If only one smart tag value is required. 2 Set up a ‘retention smart tag’: CA DLP and Enterprise Vault can be used together to produce a smart tag with a retention date. i If you do not create a bespoke registry subkey for a smart tag. configure the retention categories and their retention periods as required. Using Smart Tagging with Enterprise Vault Preparing your smart tags for use within Enterprise Vault. Personal.330 CA DLP Deployment guide About Smart Tagging Smart Tagging is an innovative feature that enables CA DLP to accurately categorize events at the time of processing.1 Create Enterprise Vault retention categories: In Enterprise Vault. machine hosting the Enterprise Vault server agent. these categories are Business. 2 Set up ‘retention smart tag’ Create Enterprise Vault retention categories 2.1. .

RDM: You must install the RDM either on the Enterprise Vault host server itself. Microsoft Exchange: The EV archive agent can only process e-mails extracted from journal mailboxes in Microsoft Exchange Server 2003. . You also need to deploy one or more policy engines and the RDM.exe. run setup. 5 Finally.dll) must be installed on the Enterprise Vault host server. 4 Retrieving archived e-mails Install and configure RDM 2 5 Turn on EV integration 3 Enterprise Vault integration procedure 1 Install the EV archive agent and a policy engine hub.4 To search for events archived in Enterprise Vault. In the Policy Engine Hub Configuration screen. The policy engine hub is installed automatically with this feature. to turn on integration you must restart all Exchange journaling tasks on the Enterprise 4 5 Install policy engines This is described in chapter 11. In the Custom Setup screen. Find this in the \Integration folder on your CA DLP distribution media. To launch the Integration Agents installation wizard. 2 You must manually register the EV archive agent with Enterprise Vault. provide the credentials for the PE domain user (as specified on page 203). You can find this user name in the Directory Properties of the Enterprise Vault Administration Console. 1 2 Register the EV archive agent 3 Configuration EV archive agent Policy engine hub Policy engines Install the EV archive agent and PE hub You install the EV archive agent and hub using the CA DLP Integration Agents installation wizard. or on an EV Administration Console—see page 338. Logon account for hub service: You must provide the policy engine hub service with the PE domain user credentials—see step 4 below. you must install and configure the Remote Data Manager (RDM). 3 You then need to configure the EV archive agent and hub and your policy engines. select Enterprise Vault from the archive list—see step 6 on page 389. The installation wizard now has all the information it needs. Click Install to start the file transfer. When you run the installation wizard. choose the Symantec Enterprise Vault feature. ‘Policy engines’. 1 Log on to your Enterprise Vault host server using the Enterprise Vault service account. See page 201 for details.Chapter 17 Third party integration 331 Deployment procedure Integrating CA DLP with Symantec Enterprise Vault involves the following tasks: Installation EV archive agent and policy engine hub Policy engines Set up Enterprise Vault integration Requirements Enterprise Vault: The EV archive agent (wgnsev.

if Exchange Journaling tasks use multiple filters. But see the warning below. To identify which numeric registry value is associated with the Journaling Connector. if the Journaling Connector is already assigned to registry value ‘1’. you must rename this value to ‘2’ and create a new value ‘1’ for the EV archive agent. and the policy engines—see page 333.Plugin. you must edit the registry on the Agent machine. the filter for the EV archive agent is assigned to registry value ‘1’. Its data is set to: WgnEVFilter. For example. But first. Type: REG_SZ Data: Set this to: WgnEVFilter. Likewise. you must manually register this filter with Enterprise Vault. To do this. add a new string value with these details: Name: Set this to be an integer such as 1. with registry value 1 processed first. look for a value whose data is set to KVS. This means that when defining numeric registry values. you need to modify values in this registry key: HKEY_LOCAL_MACHINE\SOFTWARE \KVS\Enterprise Vault \External Filtering\Journaling If the \Journaling registry key does not already exist.WgnEnterpriseVaultFilter ! It is essential that the EV archive agent is processed before the Compliance Accelerator Journaling Connector.Filter. The number determines the filter processing order.WgnEnterpriseVaultFilter archive agent is processed—but see the warning above. you must decide in which order the EV . My Computer HKEY_LOCAL _MACHINE Enterprise Vault External Filtering Journaling (Default) 1 2 3 See below Enterprise Vault registry: Filter registry values In this example. the EV archive agent must have a lower number than the Journaling Connector. 2 Within this registry key. 1 On the Enterprise Vault server. you must create it. 3 Note that registration is not complete until you restart all Exchange Journaling tasks on the Enterprise Vault server. the hub. you must configure the EV archive agent. After installing the EV archive agent.332 CA DLP Deployment guide Register the EV archive agent The EV archive agent is a custom filter for an Exchange Journaling task that works with Enterprise Vault.Accelerator. restarting these tasks will turn on CA DLP integration with Enterprise Vault—see page 338. 2 or 3.

see page 205. or the allocated memory amount falls below the relevant ‘low water mark’ threshold. to configure the hub. In particular.Chapter 17 Third party integration 333 Configure Enterprise Vault integration You configure the EV archive agent and policy engine hub by editing the registry on the host server. To enable integration. see page 218. ` Fail: The hub flags all subsequent e-mails as failures as soon as a ‘high water mark’ threshold is exceeded. . This specifies what happens if the HighWaterMarkEventCount or HighWaterMarkMB thresholds are exceeded. Configure the EV archive agent To configure CA DLP integration with Enterprise Vault. E-mail failures are returned to the EV archive agent. If set to: SymantecEnterpriseVault SmartTags Employment Solicitation Personal Communication Privileged Content SEV. This ensures that the EV archive agent processes all e-mails received from Enterprise Vault. Normal operations resume when the event queue shortens. Set this registry value to 0 to disable integration with Enterprise Vault. HubFailureMode Type: REG_SZ Data: Defaults to Fail. Enterprise Vault integration: registry key structure Registry values in these keys and subkeys are described in the following sections. For details about configuring policy engines. set this registry value to 1.RetentionCategory ` Wait: The hub stops accepting e-mails from the EV archive agent until the event queue shortens. you need to specify how the EV archive agent handles event failures and out-of-memory failures. The following registry settings are available: OperationMode Type: REG_SZ Data: Currently only a value of LocalHub is supported. This specifies that the EV archive agent passes all events to the policy engine hub on the local machine. you need to modify registry values in the following registry key: HKEY_LOCAL_MACHINE\Software\ \ComputerAssociates\CA DLP \CurrentVersion\ExternalIntegration \SymantecEnterpriseVault The key structure is shown below: My Computer HKEY_LOCAL_MACHINE EnableIntegration Type: REG_DWORD Data: Defaults to 0. ‘Policy engines’. or the allocated memory amount falls below the relevant ‘low water mark’ threshold. Configure the hub and policy engines Instructions for configuring hubs and policy engines are provided in chapter 11.

CreateEVF Type: REG_DWORD Data: Specifies whether an EVF file (containing event and archive identifiers) is created for each e-mail processed. DiagnosticFolder Type: REG_SZ Data: Specifies the path and folder where diagnostic files will be saved. where <date> is the date and time when the log file was created. plus informational and status messages LogMaxNumFiles Type: REG_DWORD Data: Defaults to 10. The creation of these files is determined by the CreateEVF registry value described below. 1 The EV archive agent always creates EVF files. When the current log file reaches its maximum size. you can configure the EV archive agent to only log errors or important system messages.334 CA DLP Deployment guide LogLevel Type: REG_DWORD Data: Defaults to 1. the EV archive agent creates a new log file. . If the path is not defined. This determines the level of logging for message processing. This specifies the maximum size (in bytes) for each log file. LogFilePath Type: REG_SZ Data: Defaults to empty. DiagnosticFolder—see above. For example. When the maximum number of log files exists and the latest file reaches its maximum permitted size (see previous setting). i Any EVF files created are saved in the LogMaxSizeBytes Type: REG_SZ Data: Defaults to 1.log file—for details see LogLevel above. Log entries are written to the wgnsev_<date>.log file.000. Log entries are written to a wgnsev_<date>. If this value is set to: 0 The EV archive agent never creates EVF files. the file location is set by the LogFilePath registry value— see below. 2 It only creates EVF files if an error occurs when extracting the contents of an e-mail. This specifies the folder you want to write log files to. The supported logging levels are: 1 Errors only 2 Errors and warnings 3 Errors and warnings.000. the log file is saved to the \System\Data\Log subfolder in the CA DLP installation folder. the oldest log file is deleted to enable a new one to be created. i This folder is not created automatically. This specifies the maximum number of log files.

RetentionCategory FailureCodeSmartTag Type: REG_SZ Data: Defaults to WgnFailureCode. If you set this to zero. ` Raw: This is the default option. ResolveMultipleValuesDefault determines how multiple tag values are handled. In effect. SymantecEnterpriseVault SmartTags employment_solicitation personal_communication privileged_content SEV. but go on to be processed by Enterprise Vault. ResolveMultipleValuesDefault determines which values are archived with the e-mail.Chapter 17 Third party integration 335 SmartTags key The SmartTags subkey contains the following optional registry values. plus a <Smart tag> subkey for each smart tag specified in user policy (see page 337). Allows the filter to pass smart tags with multiple values directly. If set to 1. we recommend you set this registry value to Concatenate. Available options include: Enterprise Vault integration: Smart tag registry keys The following registry settings are available: ConcatenateSeparatorDefault Type: REG_SZ Data: Defaults to a comma. as Raw is not supported. This registry value provides the default handling for all smart tags. only smart tags with their own designated subkey are archived in Enterprise Vault. . ResolveMultipleValuesDefault ResolveMultipleValuesDefault Type: REG_SZ Data: Specifies how policy engines handle multiple smart tag values. if an e-mail activates multiple triggers that all apply the same smart tag name but different smart tag values. this registry value allows you to disregard specific smart tags without needing to add an associated smart tag subkey with the registry value SuppressAttribute set to 1 (see page 337). That is. The attribute value contains the error code and string. Specifies the separator character between multiple smart tag values if ResolveMultipleValuesDefault is set to Concatenate. If the ResolveMultipleValues registry value is not specified in a <Smart tag> subkey. all smart tags are archived with the event in Enterprise Vault. even if a smart tag has no subkey defined. This value provides the name of the Enterprise Vault attribute applied to events that are failed by CA DLP. SmartTagIgnoreList Type: REG_SZ Data: Specifies a list of smart tags that are ignored when archiving the e-mail into Enterprise Vault. Registry values in these keys determine how a smart tag is stored in the Enterprise Vault archive and how CA DLP resolves multiple values for a single smart tag type. i If using Enterprise Vault version 6. My Computer HKEY_CLASSES_ROOT IgnoreUnlistedSmartTags Type: REG_DWORD Data: Defaults to 0.

You must also ensure that this name is added to the Smart Tags setting for all triggers in the user policy that are configured to apply retention smart tags. ` The retention date specifies when the event becomes eligible for purging. Enterprise Vault ignores ‘Discard’ and does archive the e-mail. a ‘Discard’ tag plus one or more additional tags). . but will not store a smart tag with an empty value. i Two other options are supported: ‘Highest’ and ‘Lowest’. To configure Enterprise Vault to delete e-mails rather than archive them. For example. But if the e-mail triggers multiple rules and has: ` Priority: The policy engine only saves the smart tag value listed first in PriorityOrder. you need to set this to the same value as RetentionSmartTagDiscardValue or RetentionSmartTagForceDiscardValue—see opposite. If an e-mail has any additional retention categories assigned. Enterprise Vault will process the events. two or more retention tags (that is. these are ignored. RetentionSmartTagForceDiscardValue Type: REG_SZ Data: This is set to Force Discard when CA DLP integration with Enterprise Vault is installed. assigning the default retention category. the filter automatically selects the value with the longest retention period. If you are expecting events with an empty smart tag value and want Enterprise Vault to store those events with the smart tag. i If you do not set this registry value. using the specified ConcatenateSeparator. a ‘Discard’ tag plus an unrecognized retention tag (for example. Other values are ignored. but delete any email with only this retention tag. respectively. Enterprise Vault applies a default retention period to all e-mails in the archive. because no matching retention category exists). It specifies that instead of archiving.336 CA DLP Deployment guide ` Concatenate: Multiple smart tag values are concatenated. RetentionSmartTag RetentionSmartTag Type: REG_SZ Data: Specifies the smart tag name used by policy engines to save an event’s minimum retention period. Enterprise Vault will delete any e-mail with this retention tag. ` Either. use this registry value to specify a replacement value for the empty smart tag value. ` If multiple retention smart tag values are returned. All values are ignored if the PriorityOrder registry value is not defined. RetentionSmartTagDiscardValue Type: REG_SZ Data: This is set to Discard when CA DLP integration with Enterprise Vault is installed. assigning the retention category with the longest retention date. EmptySmartTagReplacementValue Type: REG_SZ Data: Enterprise Vault does not store custom attributes with no value. These options save only the highest or lowest value. set this registry value to sev_retention_category. i Note the following: ` Or. then Enterprise Vault ignores ‘Discard’ and does archive the e-mail. It specifies that Enterprise Vault will not archive. If you do not configure a ‘retention period’ smart tag for use by CA DLP policy engines. These can only be used if a smart tag only returns numeric values.

` Concatenate: Multiple smart tag values are PriorityOrder Type: REG_SZ Data: Specifies a comma separated list of smart tag values in decreasing priority.RetentionCategory You must create smart tag subkeys manually. if an e-mail activates multiple triggers that all apply the same smart tag name but different smart tag values. . as Raw is not supported. These options save only the highest or lowest value. That is. and so on. using the specified ConcatenateSeparator. CA DLP saves the first tag value in this list with the email when archiving. ConcatenateSeparator Type: REG_SZ Data: Defaults to a comma. The full range of registry values are described below: SuppressAttribute SuppressAttribute Type: REG_SZ Data: Defaults to 0. if ResolveMultipleValues is set to Priority. If set to 1. Specifies the separator character between multiple smart tag values if ResolveMultipleValues is set to Concatenate. That is. the corresponding smart tag is not stored as an Enterprise Vault custom attribute. we recommend you set this registry value to Concatenate. Available options include: ` Raw: This is the default option. as specified by PriorityOrder. This specifies how policy engines handle multiple smart tag values. If they are not specified. ` Priority: The policy engine only saves the smart tag value with the highest priority. i Two other options are supported: ‘Highest’ and ‘Lowest’. In the example registry diagram on page 335. All values are ignored if the PriorityOrder registry value is not defined. ResolveMultipleValues ResolveMultipleValues Type: REG_SZ Data: Defaults to Raw. Allows the filter to pass smart tags with multiple values directly. These can only be used if a smart tag only returns numeric values. Other values are ignored. CA DLP uses the corresponding default registry values in the parent SmartTags key (page 335). if required. if the highest priority tag value is not detected (because no trigger applied this value). i If using Enterprise Vault version 6. Each subkey must contain the ResolveMultipleValues registry value. If set to 0. respectively. concatenated. Enterprise Vault integration supports four smart tag subkeys: employment_solicitation personal_communication privileged_content SEV. ResolveMultipleValues determines which values are archived with the e-mail.Chapter 17 Third party integration 337 <Smart tag> subkeys These subkeys allow default settings to be superseded. other registry values are optional. CA DLP saves the second tag value in the list with the e-mail when archiving. the corresponding smart tag is stored as an Enterprise Vault custom attribute.

Note that the filter for the EV archive agent will be applied to all Exchange Journaling tasks on the Enterprise Vault server. To do this: 1 Go to the \Program Files\Enterprise Vault folder on the Enterprise Vault host server. Copy AutoStorageOnlineOpns. and configuring the various components.dll i If you are running Enterprise Vault version 7.338 CA DLP Deployment guide Install and configure RDM CA DLP uses the RDM to retrieve archived events. hub and policy engines 2 3 Register the EV archive agent Configure EV archive agent. Turn on Enterprise Vault integration 1 After installing. hub and PEs Regsvr32 AutoStorageOnlineOpnsps. Before you can install the RDM on an EV Administration Console (also referred to as a VAC machine). Install and configure RDM 1 Turn on EV integration Restart journaling tasks 4 Install and configure the RDM—see page 388. must be the same. This will complete the registration of the EV archive agent. you must restart all Exchange Journaling tasks on the Enterprise Vault server. the EV archive agent passes e-mails extracted from the Exchange journal mailbox and passes them to the policy engine hub. from the \Program Files\Enterprise Vault folder.0 or later.dll Turn on Enterprise Vault integration To turn on CA DLP integration with Enterprise Vault. Install EV archive agent. . The event identifier allows the Remote Data Manager (RDM) to retrieve the e-mail from the Enterprise Vault archive during subsequent event searches. the event metadata and an event identifier are replicated to the CMS.dll from this folder to the equivalent folder on the VAC machine. As soon as registration is complete. you do not need to run the second command. you must copy a DLL onto the VAC machine. registering. When the policy engine has processed an e-mail event and policy has caused it to be saved. the final task is to restart the Exchange journaling tasks on the Enterprise Vault server to turn on integration with CA DLP. run the following commands: Regsvr32 AutoStorageOnlineOpns. i Note the following: ` The CA DLP infrastructure must be run using the Enterprise Vault service account—see page 331. ` The version of the RDM installed on an EV Administration Console and the Enterprise Vault server. On the VAC machine.

The UA outputs the e-mails to one or more MS Exchange mailboxes (1b). CA DLP can integrate with IBM DB2 CommonStore for Exchange. Import Policy processes the events corresponding to the e-mails (3b. the Universal Adapter ingests e-mails from one or more Exchange Journals and outputs them. stored as a property of the e-mail. The UA (2) also outputs the same e-mails to an EVF cache for Event Import (3a) on the Import Policy host server (3). to one or more Exchange mailboxes. Exchange Server 1 1a 1b 4 IBM CS EXCH 5 IBM CMgr 5a 2 UA 3 3a EVFs 6 6c IBM CM Interface 7 iConsole 3b Event Import 3c PE 6b RDM 6a CMS Internet CA DLP integration with IBM DB2 CommonStore for Exchange E-mails from one or more MS Exchange Journals (1a) are ingested into the Universal Adapter (2) where they are each given a unique ID. If e-mail content is not currently held on the CMS (6a). RDM (6b) can retrieve it from the IBM archive (5a) via the CA DLP IBM Content Manager Interface (6c). IBM DB2 CommonStore for Exchange can then archive the e-mails. . retrieving e-mail content from the IBM DB2 Content Manager if the CMS remote data cache does not contain a copy. The UA also outputs the same e-mails to an event cache for subsequent import into the CMS. Integration with IBM DB2 CommonStore is provided through the Universal Adapter (UA). The diagram below shows a typical deployment of IBM DB2 CommonStore for Exchange. via Import Policy. 3c) and replicates them up to the CMS (6). For the purposes of this type of integration. where they are then extracted by IBM DB2 CommonStore for Exchange (4) and subsequently archived by IBM DB2 Content Manager (5). The archived e-mails can be subsequently retrieved by reviewers using CA DLP consoles. Note that an Outlook client is also installed on the UA machine (2). Reviewers can use the iConsole (7) to request events. each with a unique ID.Chapter 17 Third party integration 339 IBM DB2 CommonStore for Exchange i Integration with DB2 CommonStore for Domino is described on page 348. The import operation ensures that policy is applied to events corresponding to e-mails in the archive.

see the Universal Adapter guide. 2 Specify the UA domain user: The Universal Adapter service must be able to access the relevant mailboxes hosted on the Exchange server. Import Policy: This utility retrieves e-mail events extracted from the UA. 2 You then need to configure IBM DB2 CommonStore for Exchange. the Universal Adapter service must run as a domain user who can access these mailboxes. RDM and CA DLP IBM Content Manager Interface: You now need to install the Remote Data Manager (RDM). Universal Adapter: The UA needs to be installed on a separate machine and configured to retrieve e-mails from the Exchange Journal. the CA DLP Universal Adapter and the Remote Data Manager (RDM).340 CA DLP Deployment guide Deployment procedure Integrating CA DLP with IBM DB2 CommonStore for Exchange involves the following tasks (it is assumed that IBM DB2 Content Manager and IBM DB2 CommonStore have already been installed): Install CommonStore for Exchange Requirements Oracle 9i client or IBM DB2 Run-Time Client: You need to install the database client that corresponds with your installation of IBM DB2 Content Manager. IBM Information Integrator for Content: This IBM component must be installed on the RDM server before you install RDM. only version 9i is compatible. You cannot use an Exchange Server Management Pack IBM DB2 CommonStore for Exchange integration procedure 1 Install each of the IBM and CA DLP components listed above. 1 Installation Oracle 9i client / IBM DB2 Run-Time Client IBM Information Integrator for Content Universal Adapter RDM and CA DLP IBM Content Manager Interface Import Policy 2 Configuration IBM DB2 Content Manager IBM DB2 CommonStore for Exchange Universal Adapter Remote Data Manager (RDM) Import Policy Install the Universal Adapter This is a three (or possibly two) step procedure. and forward them on an Exchange mailbox—see page 340. using the CA DLP server installation wizard—see page 341. In particular. If using Oracle. applies policy to them and then imports them into the CMS—see page 341. or choose an existing domain user. 1 Outlook e-mail client: Ensure that Microsoft Outlook is installed on the target UA server. These steps are summarized below. For full instructions. i You must use Outlook as your MAPI client. instead of Outlook. contact Technical Support for details—see page 23. and the CA DLP IBM Content Manager Interface component. you must either create a new domain user for the Universal Adapter server. . Therefore.

2 Server installation wizard: Remote Data Manager Configuration screen Select the IBM CommonStore check box to enable RDM to retrieve events from the IBM DB2 CommonStore archive. select the IBM CommonStore check box: 4 4 Install the Remote Data Manager i You must install the Remote Data Manager on a machine hosting IBM DB2 Information Integrator for Content. the Universal Adapter will continue to process e-mails. you run the UA installation wizard provided by CA. 3 When installing the RDM on the same machine as the IBM DB2 Information Integrator for Content. If you do not install a de-duplication database. 1 Ensure that Microsoft Outlook is installed on the target RDM server—see the RDM requirements on page 388. see page 227 for details. Server installation wizard: Custom Setup screen Select Remote Data Manager to install RDM. From the Remote Data Manager Configuration screen. . the CA DLP server installation wizard displays an additional screen. This installs the UA service onto the local machine. Install Import Policy Instructions for installing Import Policy machines are in chapter 13 ‘Import policy’. Install the Universal Adapter: To do this. Install the RDM using the CA DLP server installation wizard—see page 388.Chapter 17 Third party integration 341 3 Install a de-duplication database: This step is optional. but will be unable to remove duplicate e-mails.

Before configuring the Archive Objects. you need to configure: 5 6 7 ` The Universal Adapter—see page 343. Create a new Archiving Policy for the archive CSXAPMARCHIVE. To do this: 1 When configuring the IBM DB2 CommonStore Server (archpro).ini and add a property mapping for X-Orch-UniqueID to APMUAUID. use the archive name you specified in archint. setting the Deletion Type to ‘Message’. 1 Use the System Administration Client to add the following attribute: Name: Type: 2 In the System Manager for IBM DB2 CommonStore for Exchange. select Message Properties and add a new property: X-Orch-UniqueID Add this as a Named Property with these settings: Kind: MNID_STRING X-Orch-UniqueID PUBLIC 3 APMUAUID Character 64 Alphanumeric: 2 Add the new APMUAUID attribute to the e-mail ITEM_TYPE (for example. For further details on IBM DB2 CommonStore for Exchange configuration. That is. . see step 1 below). Finally. selecting the appropriate Exchange Server. you need to model the archint. i The only supported archive type is 'BUNDLED'. CSXAPMMail. see your IBM administrator. Set the ITEM_TYPE Classification to 'Resource Item' with Media Object (XDO) Class set to 'DKLobICM'. ID: Property Set: 4 3 Configure IBM DB2 CommonStore for Exchange IBM DB2 CommonStore for Exchange needs to be configured to treat the unique ID generated by the UA as an indexed property. ` RDM to retrieve e-mail data from the IBM DB2 Content Manager—see page 346. configure the Task Administration Data as normal. the server the Universal Adapter is using for its mailbox output.ini settings on the example below: ARCHIVE STORAGETYPE LIBSERVER ITEM_TYPE CMUSER ARCHIVETYPE CSXAPMARCHIVE CM ICMNLSDB CSXAPMMail CSXUSER BUNDLED When configuring the Archive Objects.342 CA DLP Deployment guide Configure integration with CommonStore for Exchange Configure IBM DB2 Content Manager You need to configure IBM DB2 Content Manager to recognize the unique ID added to each e-mail by the Universal Adapter. Set the archiving policy on the output mailbox used by the Universal Adapter by editing the mailbox properties in the Policies for Mailboxes section.

This entry must match the subkey name listed under the Output registry key. UniversalAdapter DeDuplicationDatabase Input Output CSXMailSource MailSource1 IBM DB2 CommonStore integration: Input registry keys Registry values in these keys and subkeys are described below. contact Technical Support for details—see page 23. each mailbox must have a separate subkey in the Input\Mailboxes registry key. i This mailbox must be in a non-journaled Mailbox Store. see the Universal Adapter guide. CSXMailSource.Chapter 17 Third party integration 343 Configure the Universal Adapter i For general configuration instructions. you need to modify input and output values in the following registry key on the UA host machine: HKEY_LOCAL_MACHINE\Software\ \ComputerAssociates\CA DLP \CurrentVersion\UniversalAdapter Outputs Input mailbox registry key The key structure is shown below: Type: REG_SZ UniversalAdapter DeDuplicationDatabase Input Mailboxes Journal1 Outputs Data: This must list a single output that the Universal Adapter will output e-mails to. Input mailbox subkey Within the mailbox subkey (Journal1 in the example above). you need only specify this last component value to identify the mailbox. you need to enable the Universal Adapter (UA) to intercept e-mails from an Exchange Journal and pass them on to an Exchange mailbox. you need to configure the UA to output to an Exchange mailbox accessible by IBM DB2 CommonStore. MailboxName MailboxName Type: REG_SZ Data: This setting specifies the name of the Exchange mailbox you want to import from. You must supply the full Exchange mailbox name unless the last CN= component is known to be unique. IBM DB2 CommonStore integration: Output registry subkeys Registry values in these keys and subkeys are described in the following section. To do this. . configure the following registry settings to enable the UA to ingest e-mails from the correct Exchange source: ServerName ServerName Type: REG_SZ Data: This setting specifies the name or IP address of the Exchange server hosting the mailbox you want to import from. For example. i To import from more than one mailbox. To configure CA DLP integration with IBM DB2 CommonStore for Exchange. Output mailbox registry key Next. If this is so.

If set to Yes. Outputs. EVFPool1. it enables the RDM to retrieve events from a third party archive during a subsequent event search. set this to MailSource1. For IBM DB2 CommonStore configuration. . this ID is stored as a specific MAPI property in the output e-mail. MailboxName MailboxName Type: REG_SZ Data: This setting specifies the name of the Exchange mailbox you want to output the processed e-mails to. configure the following registry settings: ServerName ServerName Type: REG_SZ Data: This setting specifies the name or IP address of the Exchange server hosting the mailbox you want to output to. For IBM DB2 CommonStore configuration. It must be set to the name of an existing EVF output pool. Together with the event identifier. it specifies the data type stored within the EVF file created as the secondary output. SecondaryOutputDataTypee SecondaryOutputDataType Type: REG_DWORD Data: This is the archive identifier. You also need to specify here which MAPI property you want to use to store the ID. this must be set to EXCH in order to output e-mails to an Exchange mailbox. NAME=X-Orch-UniqueID The example above stores the unique ID in a MIME transmittable property called 'X-Orch-UniqueID'. for example. For IBM DB2 CommonStore integration. configure these registry values: Type Type Type: REG_SZ Data: This is the type of the single output specified in the Input registry value. for example. SecondaryOutputs SecondaryOutputs Type: REG_SZ Data: This is the name of the secondary output pool. Within the output mailbox subkey (MailSource1 in the example above). this must be set to 6. StoreUniqueID StoreUniqueID Type: REG_SZ Data: Defaults to No. PS_PUBLIC_STRINGS. Output mailbox location subkey UniversalAdapter DeDuplicationDatabase Input Output CSXMailSource MailSource1 IBM DB2 CommonStore integration: Output registry subkeys Registry values in these keys and subkeys are described below. Each e-mail processed by the Universal Adapter can be given a unique ID.344 CA DLP Deployment guide Output mailbox subkey Within the output mailbox subkey (CSXMailSource in the previous example). for example: Yes. That is.

EVF files.Chapter 17 Third party integration 345 Secondary output subkey You then you need to configure your secondary output. IBM DB2 CommonStore integration: Output registry subkeys Registry values in these keys and subkeys are described below. UniversalAdapter DeDuplicationDatabase Input Output CSXMailSource EVFPool1 Secondary output location subkeys Finally. configure the following registry setting: Type Type Type: REG_SZ Data: This must be set to EVF to output e-mails to individual . MinDiskSpaceMbMb MinDiskSpaceMb Type: REG_DWORD Data: This specifies the amount of free disk space (in Mb) required on the drive containing the output folder to enable the Universal Adapter to write to it. Within the secondary output subkey (EVFPool1 in the example above). If the free space drops below this threshold. . configure the following registry setting: EVFPath EVFPath Type: REG_SZ Data: This specifies the path to where you want to output the .EVF files. Within the secondary output source location subkey (EVFLocation1 in the example above). configure the secondary output location: UniversalAdapter DeDuplicationDatabase Input Output CSXMailSource EVFPool1 EVFLocation1 IBM DB2 CommonStore integration: Output registry subkeys Registry values in these keys and subkeys are described below. the Universal Adapter will pause its processing of input mailboxes using this output until the free space recovers.

This is the maximum time that the RDM will wait for CA DLP IBM Content Manager Interface Service (WgnIBMCM. CSXServicePortNumber CSXServicePortNumber Type: REG_DWORD Data: Defaults to 56200. This is not normally set.exe). This is the port number that the CA DLP IBM Content Manager Interface Service (WgnIBMCM. Type: REG_DWORD Data: Defaults to 120000 (two minutes). CSXTimeoutMilliseconds CSXTimeoutMilliseconds . This is the name of the IBM DB2 Content Manager login account. This is the name of the IBM DB2 Content Manager Library Server database.exe) is listening on.1.0. This is the machine name or IP address of the machine hosting the CA DLP IBM Content Manager Interface Service (WgnIBMCM. CSXUserName CSXUserName Type: REG_SZ Data: Defaults to icmadmin.346 CA DLP Deployment guide Configure the Remote Data Manager The CA DLP server installation wizard creates various registry values to allow the RDM to communicate with IBM DB2 CommonStore for Exchange. CSXOptions CSXOptions Type: REG_SZ Data: These are extended options for IBM DB2 Content Manager login.exe) to respond to a request for a login or a request for event data. This enables IBM DB2 CommonStore for Exchange Remote Data Retrieval.0. CSXHostName CSXHostName Type: REG_SZ Data: Defaults to 127. These values are stored in the following registry key: HKEY_LOCAL_MACHINE\Software\ \ComputerAssociates\CA DLP \CurrentVersion\Remote Data Manager The following registry settings are available: AllowCSX AllowCSX Type: REG_DWORD Data: Defaults to 1. CSXDatabaseName CSXDatabaseName Type: REG_SZ Data: Defaults to icmnlsdb. This enables RDM to retrieve e-mails from the IBM DB2 Content Manager during an event search.

This is the IBM DB2 Content Manager Attribute Name used by IBM DB2 CommonStore to store the unique identifier assigned by the CA DLP Universal Adapter.Chapter 17 Third party integration 347 CSXItemName CSXItemName Type: REG_SZ Data: Defaults to CSXAPMMail. and to delete the e-mails afterwards. you need to configure wgncred.exe are on page 518.exe using the following component ID: IBM DB2 CommonStore for Exchange Server: RDMCSX i Instructions for using wgncred. To do this. see page 410. you need to configure Event Import to take the EVF files and create CA DLP events from them. i We recommend that you configure your import operations to run in continuous mode. . you need to set the following event import parameter: import. CSXAttributeName CSXAttributeName Type: REG_SZ Data: Defaults to APMUAUID. Set credentials for IBM DB2 Content Manager When integrating with IBM DB2 CommonStore for Exchange. the RDM requires credentials for the Content Manager archive.type=EVF For details. To do this. This is the IBM DB2 Content Manager Item Name used by IBM DB2 CommonStore to store e-mail data. Configure Import Policy Finally.

to one or more Notes mailboxes. IBM DB2 CommonStore for Domino can then archive the e-mails. RDM (6b) can retrieve it from the IBM archive (5a) via the CA DLP IBM Content Manager Interface (6c). it sends that e-mail to a local temporary database (6d) where it is converted from its IBM proprietary format. The UA also outputs the same e-mails to an EVF cache (3a) on the Import Policy host server (3). The archived e-mails can be subsequently retrieved by reviewers using CA DLP consoles. CA DLP can integrate with IBM DB2 CommonStore for Domino. the Universal Adapter ingests e-mails from one or more Notes journal databases and outputs them. When the Remote Data Manager retrieves an e-mail from the IBM archive. stored as a property of the e-mail. The UA outputs the e-mails to one or more Notes mailboxes (1b). The diagram below shows a typical deployment of IBM DB2 CommonStore for Domino. Integration with IBM DB2 CommonStore is provided through the Universal Adapter (UA). Reviewers can use the iConsole (7) to request events. where they are then extracted by IBM DB2 CommonStore for Domino (4) and subsequently archived by IBM DB2 Content Manager (5).348 CA DLP Deployment guide IBM DB2 CommonStore for Lotus Domino i Integration with DB2 CommonStore for Exchange is described on page 339. If e-mail content is not currently held on the CMS (6a). each with a unique ID. . Event Import (3b) imports the EVFs and passes them to a policy engine (3c) for processing. For the purposes of this type of integration. The resulting events are then replicated up to the CMS (6). The import operation ensures that policy is applied to events corresponding to e-mails in the archive. via Import Policy. retrieving e-mail content from the IBM DB2 Content Manager if the CMS remote data cache does not contain a copy. Lotus Domino Server 1 1a 1b 4 IBM CS Domino The UA also outputs the same e-mails to an event cache for subsequent import into the CMS. Note that a Notes client is also installed on the UA machine (2). 5 IBM CMgr 5a 2 UA 3 3a EVFs 6 6c IBM CM Interface 6d Temp DB 3b Event Import 6b RDM 7 iConsole 3c PE 6a CMS Internet CA DLP integration with IBM DB2 CommonStore for Domino E-mails from one or more Notes journal databases (1a) are ingested into the Universal Adapter (2) where they are each given a unique ID. The RDM then converts the e-mail into a CA DLP event and deletes it from the temporary database.

If using Oracle. Universal Adapter Remote Data Manager (RDM) Import Policy 2 IBM DB2 CommonStore for Domino integration procedure 1 Install each of the IBM and CA DLP components listed above.Chapter 17 Third party integration 349 Deployment procedure Integrating CA DLP with IBM DB2 CommonStore for Domino involves the following tasks (it is assumed that IBM DB2 Content Manager and IBM DB2 CommonStore have already been installed): Install CommonStore for Domino Requirements Oracle 9i client or IBM DB2 Run-Time Client: You need to install the database client that corresponds with your installation of IBM DB2 Content Manager. you must either create a new domain user for the Universal Adapter server. . These steps are summarized below. IBM Information Integrator for Content: This IBM component must be installed on the RDM server before you install RDM. RDM and CA DLP IBM Content Manager Interface: You now need to install the Remote Data Manager (RDM). Therefore. only version 9i is compatible. Import Policy: This utility retrieves e-mail events extracted from the UA. and the CA DLP IBM Content Manager Interface component. see the Universal Adapter guide. For full instructions. the CA DLP Universal Adapter and the Remote Data Manager (RDM). using the CA DLP server installation wizard—see page 341. and forward them to a Notes mailbox—see page 340. 1 Notes e-mail client: Ensure that Lotus Notes is installed on the target UA server. applies policy to them and then imports them into the CMS—see page 341. Specifically. 2 You then need to configure IBM DB2 CommonStore for Domino. Universal Adapter: The UA needs to be installed on a separate machine and configured to retrieve e-mails from the Notes journal database. or choose an existing domain user. 1 Installation Oracle 9i client / IBM DB2 Run-Time Client IBM Information Integrator for Content Universal Adapter RDM and CA DLP IBM Content Manager Interface Import Policy 2 Configuration IBM DB2 Content Manager IBM DB2 CommonStore for Domino Install the Universal Adapter This is a three (or possibly two) step procedure. contact Technical Support for details—see page 23. Specify the UA domain user: The Universal Adapter service must be able to access the relevant Notes journal databases hosted on the Domino server. the Universal Adapter service must run as a domain user who can access these journal databases.

you run the UA installation wizard provided by CA. select the IBM CommonStore check box: 4 4 Install the Remote Data Manager i You must install the Remote Data Manager on a machine hosting IBM DB2 Information Integrator for Content. This installs the UA service onto the local machine. Server installation wizard: Custom Setup screen Select Remote Data Manager to install RDM. 3 When installing the RDM on the same machine as the IBM DB2 Information Integrator for Content. 2 Install Import Policy Instructions for installing Import Policy machines are in chapter 13 ‘Import policy’. but will be unable to remove duplicate e-mails. see page 227 for details. Install the Universal Adapter: To do this.350 CA DLP Deployment guide 3 Install a de-duplication database: This step is optional. 1 Ensure that Lotus Notes is installed on the target RDM server—see the RDM requirements on page 388. . Install the RDM using the CA DLP server installation wizard—see page 388. the CA DLP server installation wizard displays an additional screen. From the Remote Data Manager Configuration screen. Server installation wizard: Remote Data Manager Configuration screen Select the IBM CommonStore check box to enable RDM to retrieve events from the IBM DB2 CommonStore archive. the Universal Adapter will continue to process e-mails. If you do not install a de-duplication database.

you now need to configure Automated Archiving. see step 1 below).2 In the Configuration tab. 1 Use the System Administration Client to add the following attribute: Name: Type: 2 In Domino Administrator. .1 In the Form tab. set 'Create stub text as retrieve hotspot' to No. go to the Request Parameters tab and set: Archiving Type: Archiving format: Delete attachments: Create document stub: Delete original document: Entire Document Notes native format No No Yes CSLDAPMARCHIVE CM ICMNLSDB CSLDAPMMail CSLDUSER BUNDLED 4 Finally. you need to create and edit an archiving policy.3 In the Attributes tab. To do this: 1 When configuring the IBM DB2 CommonStore Server (archpro). open the CSLDConf Configuration Profile and edit the Document Mappings: 2. Specifically. CSLDAPMMail. ` RDM to retrieve e-mail data from the IBM DB2 Content Manager—see page 355. so ensure that the IBM DB2 Content Manager ITEM_TYPE CSLDAPMMail is set to be a ‘Resource Item’ of class DKLobICM. you need to model the archint. see your IBM administrator. Set the ITEM_TYPE Classification to 'Resource Item' with Media Object (XDO) Class set to 'DKLobICM'. Then. It is specified by UA registry value StoreUniqueID (see page 353). For further details on IBM DB2 CommonStore for Domino configuration. APMUAUID Character 64 2. set: Subject: From: Ported Date: OrchUniqueID: CSLDMailSubject CSLDMailFrom CSLDPostedDate APMUAUID Alphanumeric: 2 Add the new APMUAUID attribute to the e-mail ITEM_TYPE (for example.ini settings on the example below: ARCHIVE STORAGETYPE LIBSERVER ITEM_TYPE CMUSER ARCHIVETYPE Still editing the CSLDConf Configuration Profile in Domino Administrator. 2. 3 3 You must manually add attribute OrchUniqueID.Chapter 17 Third party integration 351 Configure integration with CommonStore for Domino Configure IBM DB2 Content Manager You need to configure IBM DB2 Content Manager to recognize the unique ID added to each e-mail by the Universal Adapter. i The only supported archive type is 'BUNDLED'. set the CommonStore Archive ID to CSLDAPMMail. in the Archiving Policy screen. Configure IBM DB2 CommonStore for Domino IBM DB2 CommonStore for Domino needs to be configured to treat the unique ID generated by the UA as an indexed property. you need to configure: ` The Universal Adapter—see page 352.

Output mailbox registry key Next. To do this. To configure CA DLP integration with IBM DB2 CommonStore for Domino. Input mailbox subkey Within the mailbox subkey (Journal1 in the example above). . contact Technical Support for details—see page 23. IBM DB2 CommonStore integration: Input registry keys Registry values in these keys and subkeys are described below. UniversalAdapter DeDuplicationDatabase Input Output CSLDMailSource MailSource1 IBM DB2 CommonStore integration: Output registry keys Registry values in these keys and subkeys are described in the following section. For example. i This mailbox must be in a non-journaled Mailbox Store. For example. configure the following registry settings to enable the UA to ingest e-mails from the correct Domino source: ServerName ServerName Type: REG_SZ Data: This setting specifies the name or IP address of the Domino server hosting the Notes journal database you want to import from.352 CA DLP Deployment guide Configure the Universal Adapter i For general configuration instructions. CSLDMailSource. MailboxName MailboxName Type: REG_SZ Data: This mandatory setting specifies the Notes journal database you want to import from. This entry must match the subkey name listed under the Output registry key. you need to configure the UA to output to a Notes mailbox accessible by IBM DB2 CommonStore. You must supply the database name and username. Mail\srimmel. see the Universal Adapter guide. each must have its own separate subkey in the Input\Mailboxes registry key. you need to enable the Universal Adapter (UA) to intercept e-mails from an Notes journal database and pass them on to a Notes mailbox. i To import from more than one Notes database. you need to modify input and output values in the following registry key on the UA host machine: HKEY_LOCAL_MACHINE\Software \ComputerAssociates\CA DLP \CurrentVersion\UniversalAdapter Outputs Outputs Input mailbox registry key The key structure is shown below: UniversalAdapter DeDuplicationDatabase Input Mailboxes Journal1 Type: REG_SZ Data: This must list a single output that the Universal Adapter will output e-mails to.

If this registry value is set to Yes. it specifies the data type stored within the EVF file created as the secondary output. . EVFPool1. Each e-mail processed by the Universal Adapter can be given a unique ID. For IBM DB2 CommonStore configuration. for example: Yes. this must be set to 8.Chapter 17 Third party integration 353 Output mailbox subkey Within the output mailbox subkey (CSLDMailSource in the previous example). for example mail/ journal. it enables the RDM to retrieve events from a third party archive during subsequent event searches. the unique ID is stored in a property called OrchUniqueID.nsf. That is. For IBM DB2 CommonStore integration. this ID is stored as a property in the output e-mail. NAME=OrchUniqueID Here. You must supply the location of the mailbox on the Domino server. SecondaryOutputs SecondaryOutputs Type: REG_SZ Data: This is the name of the secondary output pool. You also need to specify which property is used to store the ID. this must be set to Notes in order to output e-mails to a Notes mailbox. It must be set to the name of an existing EVF output pool. for example. Together with the event identifier. MailboxName MailboxName Type: REG_SZ Data: This registry value specifies the name of the Domino mailbox you want to output the processed e-mails to. configure these registry values: Type Type Type: REG_SZ Data: This is the type of the single output specified in the Input registry value. Output mailbox location subkey UniversalAdapter DeDuplicationDatabase Input Output CSLDMailSource MailSource1 IBM DB2 CommonStore integration: Output registry keys Registry values in these keys and subkeys are described below. Outputs. StoreUniqueID StoreUniqueID Type: REG_SZ Data: Defaults to No. configure the following registry values: ServerName ServerName Type: REG_SZ Data: This registry value specifies the name or IP address of the Domino server hosting the mailbox you want to output to. Within the output location subkey (MailSource1 in the example above). SecondaryOutputDataType SecondaryOutputDataType Type: REG_DWORD Data: This is the archive identifier.

Within the secondary output subkey (EVFPool1 in the example above).354 CA DLP Deployment guide Secondary output subkey The UA secondary outputs are to EVF files.EVF files. Within the secondary output location subkey (EVFLocation1 in the example above). IBM DB2 CommonStore integration: Output registry subkeys Registry values in these keys and subkeys are described below. You now need to configure your secondary output. configure the following registry values: EVFPath EVFPath Type: REG_SZ Data: This specifies the path to where you want to output the . . MinDiskSpaceMb MinDiskSpaceMb Type: REG_DWORD Data: This specifies the amount of free disk space (in Mb) required on the drive containing the output folder to enable the Universal Adapter to write to it. configure the secondary output location: UniversalAdapter UniversalAdapter DeDuplicationDatabase Input Output CSLDMailSource EVFPool1 DeDuplicationDatabase Input Output CSLDMailSource EVFPool1 EVFLocation1 IBM DB2 CommonStore integration: Output registry subkeys Registry values in these keys and subkeys are described below. configure the following registry value: Type Type Type: REG_SZ Data: This must be set to EVF to output e-mails to individual . Secondary output location subkey Finally.EVF files. the Universal Adapter will pause its processing of input Notes databases using this output until the free space recovers. If the free space drops below this threshold.

CSLDTimeoutMilliseconds CSLDTimeoutMilliseconds Type: REG_DWORD Data: Defaults to 120000 seconds (two minutes). This is the IBM DB2 Content Manager Attribute Name assigned by IBM DB2 CommonStore for Domino. This enables IBM DB2 CommonStore for Domino Remote Data Retrieval.0. This is the name of the IBM DB2 Content Manager Library Server database. This is the maximum time that the RDM will wait for CA DLP IBM Content Manager Interface Service (WgnIBMCM. CSLDDatabaseName CSLDDatabaseName Type: REG_SZ Data: Defaults to icmnlsdb. CSLDServicePortNumber CSLDServicePortNumber Type: REG_DWORD Data: Defaults to 56200. This is the IBM DB2 Content Manager Item Name used by IBM DB2 CommonStore for Domino to store e-mail data. CSLDAttributeName CSLDAttributeName Type: REG_SZ Data: Set this to APMUAID. . These values are stored in the following registry key: HKEY_LOCAL_MACHINE\Software \ComputerAssociates\CA DLP \CurrentVersion\Remote Data Manager The following registry values are available: AllowCSLD AllowCSLD Type: REG_DWORD Data: Defaults to 1.0.exe). This is not normally set.exe) is listening on. This is the machine name or IP address of the machine hosting the CA DLP IBM Content Manager Interface Service (WgnIBMCM. This is the name of the IBM DB2 Content Manager account used for login.Chapter 17 Third party integration 355 Configure the Remote Data Manager The CA DLP server installation wizard creates various registry values to allow RDM to communicate with IBM DB2 CommonStore for Domino. CSLDItemName CSLDItemName Type: REG_SZ Data: Defaults to CSLDAPMMail. This enables RDM to retrieve e-mails from the IBM DB2 Content Manager during an event search. This is the port number that the CA DLP IBM Content Manager Interface Service (WgnIBMCM.1.exe) to respond to a request for a login or a request for event data. CSLDHostName CSLDHostName Type: REG_SZ Data: Defaults to 127. CSLDOptions CSLDOptions Type: REG_SZ Data: These are extended options for Content Manager login. CSLDUserName CSLDUserName Type: REG_SZ Data: Defaults to icmadmin.

type=EVF For details. which opens the folder where the database is stored by default. For example. and to delete the e-mails afterwards. then this temporary database is stored in the Lotus Notes default data directory. i We recommend that you configure your import operations to run in continuous mode. which is located in the Lotus Notes \Data folder.356 CA DLP Deployment guide CSLDTempDatabase CSLDTempDatabase Type: REG_SZ Data: Defaults to WgnCSLD. No data is stored permanently in this database.exe using the following component IDs: IBM DB2 CommonStore for Lotus Domino: RDMCSLD Notes Client: RDMCSLDClient i The Notes user that RDM runs under must be the same as the CommonStore Notes user. This setting is used for debugging purposes only. i Instructions for using wgncred. This is the name of the temporary Notes database. This persists the data retrieved from IBM DB2 CommonStore for Domino. To do this. DataPath registry data is stored in the HKLM\Software\Lotus\Notes\6. you need to configure Event Import to take the EVF files and create CA DLP events from them. If you are not familiar with this location. If no path is specified. i The path to this folder is also in the DataPath string value of the Lotus Notes registry key. you need to set the following event import parameter: import. see page 410. Configure Import Policy Finally.0 key. You can then use the Browse button. Set to zero if you do not want to persist the data. you need to configure wgncred. the RDM requires credentials for the Content Manager archive and the Notes Client.exe are on page 518. Set this to 1 to save the data in files in the CA DLP \System folder. for Lotus Notes 6. the Set credentials for IBM DB2 Content Manager When integrating with IBM DB2 CommonStore for Domino. . we recommend that you open the temporary database via the Lotus Notes Client application.0. PersistData PersistData Type: REG_DWORD Data: Defaults to 0. To do this.

The import operation ensures that e-mails in the archive can be subsequently retrieved by reviewers using CA DLP consoles. From the ZANTAZ Web site: “ZANTAZ Digital Safe is an on-demand. 3 Digital Safe archive: This archive contains the actual message data for e-mails imported from Exchange mailboxes. This server also hosts the Remote Data Manager (5b) and a second Digital Safe Adapter to drive the retrieval service (5c). CA DLP can integrate with ZANTAZ Digital Safe.Chapter 17 Third party integration 357 ZANTAZ Digital Safe integration i CA DLP integration with ZANTAZ Digital Safe does not currently support Domino e-mails. 6 iConsole: When displaying archived e-mails in the iConsole. with two instances of the Digital Safe Adapter (see the next page for a description). This Digital Safe Adapter receives imported e-mails from the Universal Adapter and. 1 Exchange 2 2a UA 2b ZDSAi 3 ZANTAZ Digital Safe 4 4a EVFs 5 5c ZDSAr 6 iConsole 4b Event Import 5b RDM 5a CMS Internet Digital Safe integration: Distributed deployment 1 Exchange server: E-mails waiting to be archived are stored in journal mailboxes in Microsoft Exchange. 5 CMS: A record in the CMS database (5a) for each imported EVF file references the associated e-mail in the Digital Safe archive. using the Digital Safe ingestion service. . the Remote Data Manager (5b) connects to the Digital Safe Adapter retrieval service (5c) to retrieve data for e-mails stored in the Digital Safe archive (3). The Universal Adapter then outputs the same emails to EVF files for subsequent importing into the CMS. 4 Event Import host server: Event Import (4b) imports the e-mails in the EVF files (4a) into the CMS. When these e-mails have been successfully archived. secure and scalable digital archiving service for all email (with attachments” Integration with Digital Safe is provided through two CA components: the Digital Safe Adapter and the Universal Adapter. which then outputs them to the Digital Safe archive. 2 Universal Adapter host server: This server hosts the Universal Adapter (2a) and the Digital Safe Adapter (2b). the Universal Adapter outputs them to EVF files (4a). outputs them to the digital archive (3). The diagram below shows a typical deployment. The Universal Adapter imports e-mails from Exchange mailboxes and outputs them to the Digital Safe Adapter.

About the Digital Safe Adapter The CA DLP Digital Safe Adapter (wgnzds. After confirmation that an e-mail has been successfully archived. then you need to: 1 View the certificate. the alert may identify a problem with the ZANTAZ site’s security certificate). For installation and configuration instructions. This enables reviewers using the iConsole to retrieve and view e-mails stored in the Digital Safe archive. 2 3 . Secure communication based on SSL authentication The Digital Safe archive provides a Web service for communication with third party applications such as the CA DLP Digital Safe Adapter. Specifically. if Windows displays a Security Alert dialog when you first enable CA DLP integration with a Digital Safe archive (for example. this Digital Safe Adapter outputs e-mails to the Digital Safe archive and then sends identifiers for each archived e-mails back to the Universal Adapter. the Digital Safe Adapter reformats the data sent back from the archive into EVF files and passes them back to the RDM. place the certificate in the ‘Trusted Root Certification Authorities’ store. you may need to manually add this certificate to the ‘Trusted Root Certification Authorities’ store. the RDM submits a request for any archived e-mails to the Digital Safe Adapter. The Digital Safe Adapter translates this request into a Web service request that can be processed by the Digital Safe retrieval service. Event ingestion: The Universal Adapter extracts e-mails from specified Exchange mailboxes and passes them to the Digital Safe Adapter. Finally. to the ZANTAZ Digital Safe web service. secure encryption/decryption is performed on all data passing between the Digital Safe Adapter and the Digital Safe archive. In the resulting dialog. This launches the Certificate Import Wizard. This file includes the metadata (event and archive identifiers) that allows the RDM to retrieve the archived e-mails during subsequent event searches.358 CA DLP Deployment guide The first Digital Safe Adapter runs on the same machine as the Universal Adapter. Depending on the type of certificate used to verify the identity of the Digital Safe archive server. Event retrieval: When a reviewer runs an event search in the iConsole or Data Management console.dll) provides an interface between the CA Universal Adapter or Remote Data Manager (RDM) and a Digital Safe archive. certificates are used to verify the identity of the Digital Safe archive server. In turn. the server sends it a certificate which the adapter uses to verify the server’s identity. It has dual roles: enabling event ingestion and event retrieval. the Universal Adapter outputs a copy of the e-mail to an EVF file. the Digital Safe Adapter outputs these e-mails to a digital archive and then sends event and archive identifiers back to the Universal Adapter. as the client. In the Certificate Store wizard screen. Once its identity is established. see pages 359 to 363. Manually installing the certificate When the Digital Safe adapter connects. You can do this directly from the Security Alert dialog. Data requests and responses sent between Digital Safe and the Digital Safe Adapter use SSL. The second Digital Safe Adapter typically runs on the CMS (along with the Remote Data Manager) and uses the Digital Safe retrieval service. Using the Digital Safe ingestion service. choose to install the certificate. SSL certificates To eliminate man-in-the-middle attacks on the SSL link.

For details. you install two instances of the Digital Safe Adapter. then you must install it onto the same server as the RDM.0 2 Configuration Universal Adapter Digital Safe Adapter To check the installed version of ASP. Remote Data Manager: You need to edit the RDM registry to allow it to communicate with Digital Safe. wgncheck. ` Microsoft Web Services Enhancements (WSE) version 3 Retrieving archived e-mails Install and configure RDM 2.Net Framework. see page 388. run the CA DLP Version Check utility. Where do I install the Digital Safe Adapter? Which server you install the Digital Safe Adapter on depends on its intended role: Event ingestion: If you will use this Digital Safe Adapter to output e-mails to a digital archive.dll must be running: 1 Installation Universal Adapter Digital Safe Adapter ` .x is not supported by the Digital Safe Adapter. i WSE 3. .exe is described on page 78. 3 To search for events in an Digital Safe archive. Outlook and SQL Server requirements. then you must install it onto the same server as the Universal Adapter. Digital Safe Adapter: The host server for wgnzds.exe. For a typical distributed deployment.Net Framework 2. WSE is an add-on for the Microsoft . Wgncheck. you must install and configure the Remote Data Manager.x SP3.Chapter 17 Third party integration 359 Deployment procedure Integrating CA DLP with Digital Safe involves the following tasks: Set up Digital Safe integration Requirements Universal Adapter: For minimum Microsoft Exchange.NET Framework section. Digital Safe integration procedure 1 Install the Universal Adapter and the Digital Safe Adapter. see the Universal Adapter guide.NET. Event retrieval: If you will use this Digital Safe Adapter to submit data requests to a digital archive during an event search. contact Technical Support for details—see page 23. Search the output for the Microsoft . one on the CMS and one on the same machine as the Universal Adapter. 2 You then need to configure both adapters by editing the registry.

Install the Universal Adapter This is a three (or possibly two) step procedure. 1 On the RDM or Universal Adapter host server (see page 359). run setup. Therefore. choose the Digital Safe Integration feature. see the Universal Adapter guide. For full instructions. you must either create a new domain user for the Universal Adapter server.360 CA DLP Deployment guide Install the Digital Safe Adapter You install the Digital Safe Adapter using the CA DLP Integration Agents installation wizard. the event metadata is saved on the CMS along with an event identifier. Specifically. launch the installation wizard. This identifier allows the Remote Data Manager (RDM) to retrieve the e-mail from the Digital Safe archive during subsequent event searches. . Find this in the \Integration folder on your CA DLP distribution media. If you do not install a de-duplication database. or choose an existing domain user. 2 Install a de-duplication database: This step is optional. 1 Specify the UA domain user: The Universal Adapter service must be able to access the relevant mailboxes hosted on the Exchange server. The installation wizard now has all the information it needs.exe. the Universal Adapter service must run as a domain user who can access these mailboxes. Install the Universal Adapter: To do this. Click Install to start the file transfer. The RDM is described on page 388. you run the UA installation wizard provided by CA. In the Custom Setup screen. but will be unable to remove duplicate e-mails. contact Technical Support for details—see page 23. 3 2 3 Retrieve archived events with RDM After the Digital Safe Adapter has processed an e-mail and Event Import has imported it. These steps are summarized below. This installs the UA service onto the local machine. the Universal Adapter will continue to process e-mails.

You must set this to: WgnZDS. If set to Yes. StoreUniqueID This value specifies whether e-mails processed by the UA are given a unique ID. Type Set this to DLL. These identifiers enable the Remote Data Manager to retrieve events from the Digital Safe archive during subsequent event searches. within this ‘pool’ subkey you must create a further ‘location’ subkey to hold the registry values that specify the location of the target DLL (in this case. you need to modify input and output values in the following registry key on the host machine: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\UniversalAdapter Pool subkey: Within the pool subkey (DLLOutputPool in the previous example). In the example below. see the Universal Adapter guide. For full configuration details. wgnzds. The resulting EVF files will contain event and archive metadata by wgnzds. This instructs the UA to output e-mails to a third party DLL.dll). Location subkey: Within the location subkey (DLLLocation1 in the previous example). DLLOutputPool and DLLLocation1. Note that the EVF file is only written after confirmation that the Digital Safe Adapter has successfully archived the associated e-mail. the pool and location subkeys are called.Chapter 17 Third party integration 361 Configure Digital Safe integration Configure the Universal Adapter registry The following sections provide summary information only. including instructions for setting up input templates. the Digital Safe Adapter). Then.dll. contact Technical Support for details— see page 23. To configure the Universal Adapter (UA).WgnZDSIngester Universal Adapter registry keys UA output registry keys and values Specifically. within the Output registry subkey you must create two further subkeys for outputs to a DLL. respectively. you need to add the following registry value: ComProgID This specifies a COM class name or GUID that contains an interface to a the Digital Safe archive. My Computer HKEY_LOCAL_MACHINE UniversalAdapter DeDuplicationDatabase Input Output DLLOutputPool DLLLocation1 EVFPool1 MailboxPool1 UniqueIDPropList .<MAPI> the ID is stored as a MAPI property in the output e-mail. Type in the name of the EVF output pool you want the Universal Adapter to write the e-mail to.dll. The first subkey represents a ‘pool’ for UA outputs to DLLs. add the following registry values: SecondaryOutputs This enables the Universal Adapter to write an e-mail to an EVF file after outputting to the Digital Safe Adapter (wgnzds.

You also need to configure both the ingestion and retrieval services to allow secure communication with the Digital Safe archive. contact Technical Support—see page 23. For example. You must set this registry value to the name of the pool subkey described in the previous section (in this example. Log entries are written to a ZDSIngestion_<date>. you need to create a registry subkey for each journal mailbox that the UA is importing from. i These instructions describe the simplest method for configuring the Outputs registry value. the Digital Safe adapter creates a new log file.log file. you could create a subkey called New York. you must add an Outputs registry value. When the current log file reaches its maximum size. The key structure is shown below: My Computer HKEY_LOCAL_MACHINE LogMaxSizeBytes Type: REG_SZ Data: Defaults to 1. See the LogFilePath registry value above for details about the log file names and location. LogMaxNumFiles Type: REG_DWORD Data: Defaults to 10. if the source mailbox is called ‘New York’. This specifies the maximum number of log files. See the Universal Adapter guide for details. See the LogFilePath registry value above for details about the log file names and location.log or ZDSRetrieval_<date>. To configure the Digital Safe Adapter. you need to configure the ingestion service to write e-mails to EVF files.000. ZDSadapter registry key The ZDSadapter registry key contains the following registry values: LogFilePath Type: REG_SZ Data: Defaults to empty. you need to modify the following registry key on the host server: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\ZDSadapter Below the ZDSadapter registry key there are two subkeys.000. Within this subkey. Within the Input subkey. If no path is defined. . Configure the Digital Safe Adapter registry After installing the Digital Safe Adapter. This specifies the maximum size for each log file. You can also use the common value in the Input subkey or you can add an Outputs value to an input template. This registry value specifies which folder these log files are written to. Note also that the Universal Adapter service runs as a domain user. DLLOutputPool). the log file is saved to \System\Data\Log in the CA DLP installation folder on the server hosting the Digital Safe adapter. See the Universal Adapter guide for details about this domain user. ZDSadapter WebService Digital Safe adapter registry keys Registry values in the ZDSadapter key and its subkey are described in the following sections. you need to set up the input source structure. this user must have write access to the specified log folder.362 CA DLP Deployment guide UA input registry keys and values Next. the oldest log file is deleted to enable a new one to be created. When the maximum number of log files exists and the maximum size of the latest is reached (see above).

com:8080/unipraxis/servs/WSR ClientDomain Type: REG_SZ Data: This mandatory registry value specifies the domain identifier issued by Digital Safe to your organization. If this registry value is does not exist. . See the LogFilePath registry value above for details about the log file names and location. the registry values that you need to add/change are: UrlIngestionService Type: REG_SZ Data: This mandatory registry value specifies the URL of the Digital Safe ingestion Web service.Chapter 17 Third party integration 363 LogLevel Type: REG_DWORD Data: Defaults to 2. you can configure the Digital Safe Adapter to log only errors. For example. WebService registry subkey Within the specified registry key.com:8080/unipraxis/servs/WSI UrlRetrievalService UrlRetrievalService Type: REG_SZ Data: This registry value specifies the URL of the Digital Safe retrieval Web service. This determines the level of logging for e-mail processing. If this registry value is does not exist. This identifier enables Digital Safe to identify your organization when the Digital Safe Adapter ingests or retrieves data from the Digital Safe archive. no log file created. For example. the Digital Safe Adapter cannot be instantiated. This level of logging is provided for testing purposes only. the Digital Safe Adapter cannot be instantiated. The supported logging levels are: 1 Errors only 2 Errors and warnings 3 Errors and warnings. For example. the URL could be: https://zantazds. if the organization is called Unipraxis. plus informational and status messages i Setting LogLevel to 3 will cause the log file to grow extremely rapidly. if the organization is called Unipraxis. If this registry value does not exist. the URL could be: https://zantazds.

When displaying captured e-mails in the iConsole (6). For very large e-mail archives. you may need to run multiple Event Import utilities simultaneously to avoid import bottlenecks. This connects to an e-mail server (2. a large organization may have many such servers feeding data into multiple caches. which must be installed on the same machine as the EmailXtender. This section summarizes how e-mails are extracted from the archive and imported into CA DLP. Each Event Import utility imports archived e-mails into the CMS (5). For simplicity. feeding data into a single EVF file cache.364 CA DLP Deployment guide EMC EmailXtender integration CA DLP can integrate with the EMC EmailXtender solution. This cache provides the source data for the CA DLP Event Import utility (4). 2 E-mail server: Exchange or Domino 6 iConsole 1 EmailXtender host server 1a 5 CMS 7 RDM 1b External Agent API Searching for archived e-mails 3 EVF file cache 4 Event Import machines Importing e-mails into CA DLP CA DLP integration with e-mail archive 1 This server hosts the e-mail archive solution. Microsoft Exchange or Lotus Domino) and archives messages. The archive solution passes data to the CA DLP External Agent API (1b). In practice. The actual message data is not saved on the CMS. This utility requires the CA DLP infrastructure. the diagram shows a single e-mail archive server. EmailXtender (1a). The External Agent API extracts archived e-mails and saves them as EVF files in a cache (3). a record in the CMS database for each imported e-mail references the associated entry in the e-mail archive (1a). the Remote Data Manager utility (7) retrieves data for archived e-mails. . instead. The diagram below summarizes the key components and processes involved.

To install the External Agent API. ! You also need to restart the ‘EmailXtender Email Data Source’ service on the EmailXtender host server. The RDM is described on page 388. i This connector is supplied by EMC and has not been rebranded to reflect the product name change in r12. consider the registry edit in step 8 on page 371. especially step 6. Full instructions for installing Event Import machines are given in chapter 18 ‘Event Import’. on the RDM host machine.Chapter 17 Third party integration 365 Set up EmailXtender integration i CA DLP can only integrate with EMC EmailXtender version 4. RDM: Next.exe. The RDM then uses this identifier to retrieve the e-mail from EmailXtender during subsequent event searches. you can find the connector on your EMC distribution media in the \Setup\Windows folder. In the Remote Data Manager Configuration screen. see pages 388 to 389.8. The example diagram page 364 on shows the RDM installed on the CMS. For full External Agent API deployment details. Configure EmailXtender integration After installing the External Agent API. see pages 369 to 381. For integration with EmailXtender. run the CA DLP integration agent installation wizard. In particular. 2 Event Import: This retrieves the extracted e-mails from the shared folder specified in step 1 and imports them into the CMS. select EMC EmailXtender for Exchange or EMC EmailXtender for Domino from the archive list. The External Agent API enables CA DLP to integrate with third party e-mail archives. 3 . you need to install the Remote Data Manager (RDM). as the machine name forms part of the unique event identifier. See also the EVF file cache guidelines on page 372. This enables the RDM to connect to the EmailExtender server. The following CA DLP components are required to integrate with EMC EmailXtender. you need to install this connector. see the post-installation task on page 390. From version 4. ! If you select EMC EmailXtender for Domino. the External Agent API converts archived e-mails into CA DLP event files and saves them to a shared network folder where they can be accessed by Event Import. run the CA DLP server installation wizard. ExOConnSetup. This means that although the CMS will keep a summary of event data for such events. you need to install the External Agent API on the EMC EmailXtender server. The RDM enables CA DLP to retrieve events that are archived in third party remote storage locations and display them in the iConsole or Data Management console. 4 EmailXtender Connector for Orchestria: Finally.0 from ‘Orchestria APM’ to ‘CA DLP’. their mail content will no longer be retrievable. See step 6 on page 371 for details. To install the RDM. you may need to edit certain values in the External Agent API registry key. Retrieve archived events with RDM When the External Agent API receives data from EmailXtender. any references within CA DLP to e-mails archived to that server will no longer be valid.8 SP1 onwards.263 or later. see page 393 for details. This identifier is added to the event metadata and replicated to the CMS. it converts the archived e-mail into a CA DLP event file along with a unique event identifier. 1 External Agent API: First. ! If you rename the EMC EmailXtender host server.

When a user searches for archived e-mails in the iConsole (6). How does the integration work? E-mails are extracted from an Exchange journal by SourceOne and passed to CA DLP policy engines for analysis and processing.366 CA DLP Deployment guide EMC SourceOne for Exchange integration CA DLP can integrate with the EMC SourceOne for Exchange archiving solution (see page 320 for supported versions). 5 CMS. . the term ‘SourceOne archive agent’ refers to this BCE. you can use smart tags to indicate archive retention periods. For example. 3 Policy engine. The key components are illustrated in the diagram below. Reviewers can searching for archived e-mails. 7 Remote Data Manager. For simplicity. The policy engines analyzes e-mails. Processed e-mails plus any resulting smart tags are returned to SourceOne for archiving. wgnemcs1.dll. are returned to SourceOne for storage in the archive. Events generated as a result of policy processing. In turn. 2 EMC SourceOne management server. E-mails are extracted from the journal mailbox by SourceOne. the Remote Data Manager retrieves data for these e-mails from the archive (4). In practice. When processing is complete. and the SourceOne archive agent passing e-mails to a single CA DLP policy engine. applies policy triggers. e-mails. In this example. the archive agent passes e-mails to a policy engine hub (2c). 6 iConsole. plus any resulting smart tags. one for storing e-mails with short retention periods (4a) and the other used for storing e-mails with longer retention periods (4b). large organizations may have a distributed SourceOne deployment and use multiple policy engines. this shows SourceOne installed on a single server. In this chapter. 4 EMC SourceOne archive. the CMS machine also hosts the Remote Data Manager (7). This example shows two archives. SourceOne (2a) extracts e-mails from the journal mailbox (1) and passes them to the SourceOne archive agent (2b). including metadata that incorporates the unique message identifiers. are replicated to the CMS and stored in the database. SourceOne can then use these smart tags to distribute e-mails across different archives based on criteria indicated by the smart tags. The hub then distributes e-mails to policy engines (3). Integration is provided through a business component extension (BCE) for SourceOne. and attaches smart tags as necessary. CA DLP integration with e-mail archive 1 Microsoft Exchange journal mailbox.

In addition to the usual requirements for the PE domain user. you can configure the archive agent to only log errors or important system messages. LogLevel LogLevel Type: REG_DWORD Machine: Edit this registry value on the machine hosting the SourceOne archive agent (this is the SourceOne management server). For example. Data: Set this to the name or IP address of the SourceOne host machine (that is. First. In fact. ‘Policy engines’. The policy engine hub is installed automatically with this feature. you need to configure SourceOne to enable integration with CA DLP. Finally. edit the following registry value: DMSServer DMSServer Type: REG_SZ Machine: Edit this registry value on the RDM server. we recommend that you use the SourceOne service account as your PE domain user. this user account must also be able to access the SourceOne server. In the Policy Engine Hub Configuration screen. Data: Defaults to 2. you need to deploy the Remote Data Manager to allow users to search for archived e-mails and review them in the iConsole or Data Management console. If your SourceOne solution is deployed across multiple servers. plus informational and status messages Set up SourceOne integration You need to install the SourceOne archive agent and a policy engine hub on your SourceOne management server. The RDM needs to be able to identify the SourceOne host machine.exe. you must deploy the SourceOne archive agent on each of those server. choose the EMC SourceOne archive agent. Second. This determines the level of logging for message processing. You also need to install one or more policy engines. If. 2 3 Install policy engines This is described in chapter 11. no further configuration is necessary. Find this in the \Integration folder on your CA DLP distribution media. run setup. you can do so by modifying values in this registry key on the RDM server and SourceOne management server respectively: HKEY_LOCAL_MACHINE\Software\ \ComputerAssociates\CA DLP \CurrentVersion\EMCSourceOneAdapter Within this key. provide the credentials for the PE domain user (as specified on page 203). Configure the SourceOne archive agent After installing the SourceOne archive agent. at any point. But if subsequently you need to designate a different SourceOne server (for use by the RDM) or you want to change the logging level. See page 201 for details. 4 The installation wizard now has all the information it needs. though you can customize the logging level if required. Install the SourceOne archive agent and PE hub You install the archive agent and hub using the CA DLP Integration Agents installation wizard.log where <date> is the date and time when the log file was created. . 1 To launch the installation wizard. edit this registry value to specify the new host machine. In the Custom Setup screen.Chapter 17 Third party integration 367 Deployment procedure This is a three-step procedure. this machine changes after you install the RDM. No additional configuration is necessary. Log entries are written to wgnemcs1_<date>. The supported logging levels are: 1 Errors only 2 Errors and warnings 3 As 2. the DMS server). Click Install to start the file transfer. you need to install the SourceOne archive agent.

1. each e-mail includes a unique identifier.1 In the Service Accounts screen. In turn. specify the SourceOne Server. i The EmailXtender feature enables RDM integration with both EmailXtender and SourceOne! For SourceOne integration. if the RDM is running remotely and not installed on your SourceOne management server. 2 Retrieve archived events with the RDM When SourceOne passes e-mails to the SourceOne archive agent. You can install the RDM on any CA DLP server. In the console: 1 Expand the Organizational Policies branch and locate the required policy. The RDM will use this identifier to retrieve the e-mail from the SourceOne archive during subsequent event searches. This enables the RDM to connect to SourceOne. Now you need to edit the required activity for this policy. the DMS server). especially step 6. .2 In the Remote Data Manager Configuration wizard screen. In the Edit Activity wizard. to enable integration with CA DLP you must select the CA DLP SourceOne Extension on the Business Components page. you must also identify the SourceOne server in step 1. the archive agent passes this identifier to a policy engine. You do this in the EMC SourceOne console. When the policy engine processes the e-mail from SourceOne. you must set the the logon account used by the local CA DLP infrastructure service to be the same as the SourceOne service account. The architecture diagram on page 366 shows the RDM installed on the CMS server. i You can obtain the SRE Initialization package from EMC. see pages 388 to 389.exe). select EMC EmailXtender for Exchange from the archive list.368 CA DLP Deployment guide Configure SourceOne business components You now need to configure SourceOne to allow integration with CA DLP. The event and its identifier are then replicated to the CMS. 2 Install EMC SourceOne SRE Initialization: Finally. 1.3. Note that if the SourceOne host machine changes subsequently after installing the RDM. T 1 Install the RDM: To do this. see page 390. 1. it generates a CA DLP e-mail event and adds the unique identifier to the event’s metadata.3 Still in the same wizard screen. run the CA DLP server installation wizard: For full details about installing the RDM. you must install EMC SourceOne SRE Initialization package (ES1_SRESetup. Enter the name or IP address of the machine hosting SourceOne (that is. you must edit the registry to specify the new host—see page 367.

Full details for configuring the External Agent API are in the API specification—see the next section. Events corresponding to these policy-processed messages can also be stored on a CMS. if Event Import 5. These instructions assume you are familiar with the configuration and operation of both EMC EmailXtender and EAS. It enables third party applications to pass messages to CA DLP for policy processing and. (Requirements continue on next page. this must be the default e-mail application on the target machine.0 is installed. E-mail solution: The External Agent host machine must have either an Exchange compatible application or Lotus Notes installed: ` Microsoft Exchange: For example. Outlook 2003.5. Furthermore. a folder). The output destination is specified using interfaces obtained when you CoCreate the relevant COM object. if required. 7 or 8. File system: Applicable to the WgnImportConnector interfaces only.3 file names on the External Agent API host machine. to store the resulting smart tag metadata with the archived message. For details.Chapter 17 Third party integration 369 External Agent API The External Agent API facilitates third party integration with CA DLP and smart tag metadata. methods and parameters used by the External Agent API to integrate with third party applications are described in the ‘External Agent API specification’.0 of the External Agent API. available by different COM objects: WgnActiveImportConnector: Use these interfaces to apply policy to messages passed to the External Agent API by a third party application. Also. performance may be adversely affected.3 file creation remains enabled. It can also convert archived emails to CA DLP event (EVF) files and save them to a shared network folder where they can be accessed by the Event Import utility (see page 393) and imported onto a CMS. WgnImportConnector: Use these interfaces to generate EVFs from messages passed to the External Agent API by a third party archive. you must use version 5. see page 30. The External Agent API includes two sets of interfaces. 6.) . we recommend that you disable creation of 8. Event Import must be configured to import EVFs. For NTFS file systems. the External Agent API currently supports ZANTAZ Exchange Archive Solution (EAS) and EMC EmailXtender. ` Lotus Notes: Versions 6. Output destinations The External Agent API can directly generate EVF files and output them to a file cache (that is. Requirements Operating system: The External Agent is not supported on Windows 98 or ME machines. This is available from Technical Support— see page 23. i When generating EVF files. Or it can send e-mails for policy processing directly to a local policy engine or to a local policy engine hub. For example. If 8. Compatibility with Event Import: The version of the External Agent API must match that of Event Import. Integrating programmatically with the External Agent API The interfaces.

By default. version 3. ` EMC EmailXtender: The EA API requires EMC EmailXtender version 4. you can use socket connections to call the External Agent API from a remote location. If you install the: ` EAS: The EA API requires the EAS indexer process. a policy engine hub) and the Socket API. Full details are in the ‘External Agent API specification’. In the Custom Setup screen. 1 To launch the Integration Agents installation wizard.exe.263 or later and the EnableOrchestriaIntegration registry value— see step 8 on page 371. the Socket API automatically listens on port numbers 8538 and 8359. you must repair the remaining CA DLP installation to ensure it operates correctly after removing the External Agent API.3. choose whether to install a Remote Policy Engine Connector (that is. run setup. Uninstallation: If the External Agent API and CA DLP (whether a server or client machine) are installed on the same machine but you subsequently uninstall the External Agent API.992. you must programmatically configure the External Agent API output destination to be a local hub.1624. see page 548. In the External Agent API Configuration screen. choose the External Agent API feature. see page 374.8.1962. For full details. Integration Agents installation wizard: External Agent API Configuration screen . IndexerService.1.1. For example the CA Network Boundary Agent (NBA) uses the Socket API to analyze traffic leaving or entering the corporate network from the internet. You can test whether CA DLP console users are able to retrieve e-mails archived in EAS. For details on the Socket API. 4.2. Find this in the \Integration folder on your CA DLP distribution media. see page 369.2.exe.370 CA DLP Deployment guide Archive integration: If you use the External Agent API to convert e-mails from an archive into EVF files: Installing the External Agent API You install the External Agent API with the CA DLP Integration Agents installation wizard. ` Socket API. including from a non-Windows system. 2 3 ` Remote Policy Engine Connector. or 4.0.

you must now enable integration with CA DLP by adding a registry value to the following registry key: HKEY_LOCAL_MACHINE\Software\OTG \EmailXtender Add the EnableOrchestriaIntegration registry value to this key and set it to 1. 7 EAS integration: If you are integrating with an EAS archive.dll to the \client subfolder of this CA DLP folder. installed in step 2. 6. for details about this domain account. 8 EmailXtender integration: If you are integrating with EMC EmailXtender. you must specify the PE domain user in the Policy Engine Hub Configuration screen. containing Event Import). You may need to edit registry values in this key—see See page 372 for configuration details. When the file transfer is complete. Find this in the Windows (‘systemroot’) folder of the EAS machine and add the following line to the [FULLTEXT] section: ComplianceDLL=<path>\wgnrdi. 5 6 6.2 Run the EAS indexer process.1 It creates a new CA DLP installation folder (unless this folder exists already. 9 This completes the External Agent API installation. the wizard installs the necessary DLLs and registry values to the External Agent API machine. The installation wizard now has all the information it needs.2 It creates the following registry key.dll. HKEY_LOCAL_MACHINE\Software \ComputerAssociates\CA DLP \CurrentVersion\External Agent API . Click Install to start the file transfer.1.INI file. It then installs Wgnrdi. This causes the External Agent API to start converting messages from the e-mail archive and saving them in the EVF file cache.1 Edit the EAS.dll Where <path> is the full path to Wgnrdi. you must now: 7. see page 203. 7.Chapter 17 Third party integration 371 4 If you chose to install a Remote Policy Engine Connector in step 3.

see page 372. for example. This folder is automatically granted the necessary Write permissions. HandledCategory HandledCategory Type: REG_SZ Data: Used for EAS integration only. the volume of e-mail data removed from your e-mail archive and converted to event files each time you start up the External Agent API (see the previous section). If you do specify an alternative location. . that is. and the file-deletion strategy configured for Event Import. the installation batch file sets the EVF file cache to be the \client\RDIcache subfolder of the CA DLP installation folder on the External Agent API machine. the folder into which the e-mails will be written—see the diagram on page 327. You can edit the registry to rename the default ‘WGNHandled’ category. you must ensure that the target folder has Write permissions assigned to the user running the e-mail archive indexer process. Each message in the e-mail archive is assigned to various categories. i For guidelines on specifying an alternative location for the EVF file cache.372 CA DLP Deployment guide EVF file cache guidelines By default. on a machine with more free disk space. the registry values that you may need are: EventFilePath EventFilePath Type: REG_SZ Data: This specifies the full path to the EVF file cache. This is to prevent duplicate messages being moved into the EVF file cache. you must specify a UNC path. If the target folder is on a remote machine. you need to edit values in the following registry key: HKEY_LOCAL_MACHINE\Software \ComputerAssociates\CA DLP \CurrentVersion\External Agent API Within this registry key. This registry value appends a category to this list for each message. This path defaults to the \client\RDIcache folder on the External Agent API machine. You can edit the registry to specify an alternative file cache location. For example: \\MyMachine\share_name\target_folder Configuring the External Agent API To configure the External Agent API. on a machine with more free disk space—see the EventFilePath registry value on page 372. How much free disk space is required? This depends on: the size of your organization’s e-mail archive. marking as ‘WGNHandled’. for example. You can edit the registry to specify an alternative location.

They are then removed from the archive. set this to zero to revert to the previous behavior (the External Agent API converts audit e-mails to CA DLP events). Messages still awaiting conversion to event files and subsequent saving to the file cache are flagged accordingly. EventDateFromSource Type: REG_DWORD Data: Defaults to 1. It is based on the delivery time or time sent. these flagged messages are picked up when the e-mail archive indexer process (in the case of EAS. 0 (Zero) The timestamp is set to the date and time when the e-mail was processed by the External Agent. If free disk space falls below this level. you need to create them manually in the External Agent API registry key. To use these registry values. no further messages are moved from the e-mail archive to the EVF file cache until free disk space increases. . IgnoreAPMAuditMails Type: REG_DWORD Data: Defaults to 0. This threshold defaults to 10MB. this is IndexerService.Chapter 17 Third party integration 373 MinFreeDiskMb MinFreeDiskMb Type: REG_DWORD Data: This specifies a minimum level of free disk space on the machine hosting the EVF file cache—see above. the following values are also supported. Manually created registry values In addition to registry values created automatically on installation. Set this to a non-zero value to filter out audit e-mails. converted to event files and saved to the EVF file cache as normal. This specifies whether audit e-mails are processed by the External Agent API. You can edit the registry to set a different threshold. This specifies where the capture date assigned to imported events is set from.exe) next runs. If this value is set to: 1 The timestamp is set to the date and time in the e-mail. As soon as free disk space does increase. No messages are lost from this process because of insufficient free disk space.

See step 3 on page 370.1’ component can be downloaded from the Microsoft Web site. See the following pages for details. AgentPort AgentPortInterlaced CreateEAReq. without requiring any post-installation configuration. the Socket API cannot process e-mails received from the NBA or Milter MTA agent.1 Note that the ‘MAPI client and CDO 1. CreateEARsp DiagnosticFolder DiskSpaceMinimum DiskSpaceThrottlingThreshold HostInHub HostInPE ImportQueueLimit List continues on next page. you need to edit values in the following registry key: HKEY_LOCAL_MACHINE\Software \ComputerAssociates\CA DLP \CurrentVersion\External Agent API \Socket API Installation methods You can install the Socket API either with a remote policy engine connector (that is. Registry keys and values Socket API registry key Page 375 375 375 375 376 376 376 376 376 376 377 Requirements In order to pass necessary e-mail data to a policy engine or PE hub. This key contains the following registry values for the Socket API. It also includes sections on Socket API throttling and monitoring the Socket API (both on page 381). including from non-Windows systems. Before you install it. or Microsoft Exchange Server MAPI Client and Collaboration Data Objects (CDO) 1. Or you can install it directly on a policy engine. If this functionality is not available. if it is. But if you do need to configure the Socket API (for example.374 CA DLP Deployment guide Socket API The Socket API (also known as the Socket agent) enables external applications to use socket connections to call the External Agent API from remote locations. a hub) on a machine hosting the External Agent.2. you must remove it. to change the default behavior or settings). the Socket API requires the Messaging API (MAPI) client libraries. Configure the Socket API The Socket API is designed to work automatically.2. . The Socket API host machine therefore needs: Microsoft Outlook (and Outlook must be the default e-mail application). ensure that Microsoft Outlook is not also installed. This section focuses on configuring the Socket API. The Milter MTA agent and the Network Boundary Agent (NBA) both use the Socket API to pass e-mails and (in the NBA’s case) files to policy engines for analysis.

The Network Boundary Agent uses this port and hence this port. If set to: 0 Messages are never generated. CreateEAReq. If this port is not used. This registry value specifies which port number the Socket API listens on for data sent by applications using the Contiguous protocol. This registry value specifies which port number the Socket API listens on for data sent by applications using the Interlaced protocol. .Chapter 17 Third party integration 375 Registry keys and values Socket API registry key continued LogLevel LogMaxNumFiles LogMaxSizeBytes MemoryThrottlingThreshold MsgTimeout MsgTimeout UpdateConfig Notifications registry subkey AttachOriginalEmail NotificationFromAddress AuthType SmtpDNSHostName SmtpServer UserID Page Socket API registry key The Socket API registry key contains these values: AgentPort 377 377 377 377 378 378 378 379 379 379 379 380 380 380 AgentPort Type: REG_DWORD Data: Defaults to 8538. If this port is not used. The Milter MTA agent uses this protocol and hence this port. CreateEAReq Type: REG_DWORD Data: Specifies whether to generate External Agent Request diagnostic messages in the folder specified by DiagnosticFolder (see below). you can set this value to zero to conserve machine resources. 1 Messages are always generated. you can set this value to zero to conserve machine resources. AgentPortInterlaced AgentPortInterlaced Type: REG_DWORD Data: Defaults to 8539. 2 Messages are only generated on error.

i This folder is not created automatically. 1 Messages are always generated. Socket API and a Remote Policy Engine Connector (that is. depending on whether messages were captured by a Milter MTA agent or the NBA. see page 381. If set to: 0 Messages are never generated. the Socket API applies ‘wait throttling’ or ‘fail throttling’. For details. This registry value specifies the level of free disk space (in MB) on the Socket API host machine that triggers a change in how messages are processed. If free disk space falls below this threshold. The creation of these messages is determined by the CreateEARsp and CreateEAReq registry values. If free disk space falls to this level. DiskSpaceMinimum DiskSpaceMinimum DiskSpaceThrottlingThreshold DiskSpaceThrottlingThreshold Type: REG_DWORD Data: Defaults to 1024. DiagnosticFolder DiagnosticFolder Type: REG_SZ Data: Specifies the path and folder where External Agent Request and Response diagnostic messages will be saved. . a hub). indicating the Socket API is connecting to a local PE hub. 2 Messages are only generated on error. indicating the Socket API is connecting to a local policy engine. and while it remains below this level. HostInPE HostInPE Type: REG_DWORD Data: Defaults to 800. This registry value is only created on machines hosting a policy engine and the Socket API. This registry value specifies the minimum level of free disk space (in MB) on the on the Socket API host machine. i This registry value refers to free disk space on the drive hosting Windows temporary files. i This registry value refers to free disk space on the drive hosting Windows temporary files. HostInHub HostInHub Type: REG_DWORD Data: Defaults to 1. Type: REG_DWORD Data: Defaults to 1. You do not need to change this registry value. This registry value is only created on machines hosting the External Agent.376 CA DLP Deployment guide CreateEARsp CreateEARsp Type: REG_DWORD Data: Specifies whether to generate External Agent Response diagnostic messages in the folder specified by DiagnosticFolder (see below). the Socket API rejects all further messages passed to it. You do not need to change this registry value.

If memory usage rises above this threshold. This registry value specifies the level of memory usage (in MB) on the Socket API host machine that triggers a change in how messages are processed.log where <date> is the date and time when the log file was created. This specifies the maximum number of log files. This level of logging is provided for testing purposes only. the Socket API applies ‘wait throttling’ or ‘fail throttling’. This specifies the maximum size (in bytes) for each log file. see above.Chapter 17 Third party integration 377 ImportQueueLimit ImportQueueLimit Type: REG_DWORD Data: Defaults to 60. MemoryThrottlingThreshold MemoryThrottlingThreshold Type: REG_DWORD Data: Defaults to 300. This policy setting sets the maximum number of events that can be processed simultaneously by a policy engine. LogMaxNumFiles LogMaxNumFiles Type: REG_DWORD Data: Defaults to 10. When the maximum number of log files exists and the maximum size of the latest is reached (see below). Log entries are written to WgnSAgent_<date>.000. The supported logging levels are: 1 Errors only 2 Errors and warnings 3 As 2. LogMaxSizeBytes LogMaxSizeBytes Type: REG_DWORD Data: Defaults to 1. see page 381. This determines the level of logging for message processing. It prevents a performance slowdown if a policy engine is heavily loaded. . the e-mail server agent creates a new log file. We recommend that you set this value to 12 times the total concurrency for all policy engines (if using a hub) or simply 12 times the concurrency of the local policy engine. For details. you can configure the Socket API to only log errors or important system messages. LogLevel LogLevel Type: REG_DWORD Data: Defaults to 2.000.log. plus informational and status messages i Setting LogLevel=3 will cause the log file to grow extremely rapidly. Log entries are written to WgnSAgent_<date>. depending on whether messages were captured by a Milter MTA agent or the NBA. Policy engine concurrency is defined by the Maximum Number of Concurrent Operations setting in each PE’s machine policy. the oldest log file is deleted to enable a new one to be created. For example. Specifies the maximum number of items that can be queued by the Socket API while they await processing by a policy engine. When the current log file reaches its maximum size.

the Socket API rejects the e-mail. This registry value specifies the maximum level of memory usage (in MB) on the Socket API host machine. the new value is discarded and an entry written to the log (see page 381). Set to 1 to force the Socket API to re-read the registry. When it has accepted the changes. the Socket API rejects the e-mail. and while it remains above this level. Type: REG_DWORD Data: Defaults to 0. If memory usage rises to this level. If the interval between the Socket API submitting an e-mail for policy processing and the policy engine’s response exceeds the specified timeout. These are e-mails that have been subdivided into smaller parts before being sent across the network. Enables administrators to update the Socket API configuration. If the interval between these parts exceeds the specified timeout. This registry value specifies how long the Socket API waits (in seconds) before rejecting an e-mail. UpdateConfig is set to 2. i The Socket API checks an e-mail’s progress (in terms of policy processing or the arrival of its constituent parts) every 10 seconds. This timeout applies to: Type: REG_DWORD Data: Defaults to 400.378 CA DLP Deployment guide MsgTimeout MsgTimeout MemoryUsageLimit MemoryUsageLimit Type: REG_DWORD Data: Defaults to 180. . We recommend that you do not shorten this timeout (for example. If a registry value has been updated with invalid data. the Socket API rejects all further messages passed to it. UpdateConfig UpdateConfig ` ‘Multipart messages’ passed sent to the Socket API. do not reduce it to less than three minutes) because this may adversely affect performance. ` E-mails being processed by a policy engine. it automatically resets this value to 0.

For example. the original e-mail is attached. if set to zero. you can set this to: ComplianceTeam@unipraxis. To do this. then it is not attached. If you use Plain. AuthType AuthType Type: REG_SZ Data: Defaults to None. However. However. your SMTP server must be configured to accept connections from the Socket API host machine. This specifies which standard SMTP authentication type the Socket API uses to connect to the SMTP server. NTLM and CRAM-MD5 authentication can be used to connect to SMTP servers on Windows and Unix machines respectively. you must still ensure that these credentials are protected—see the next paragraph. NotificationFromAddress NotificationFromAddress Type: REG_SZ Data: Specifies the sender’s address that is shown in the From: field of an e-mail notification. Specifies whether to attach the original e-mail address to the notification e-mail. If set to 1.com . The following values are supported: None Plain Login NTLM CRAM-MD5 We recommend you choose None for unauthenticated connections. although these protocols do not send unencrypted logon credentials. Login. you can set up the Socket API to allow policy engines to send e-mail notifications to users when their e-mails are blocked or trigger a warning. For e-mails captured by the NBA or Milter MTA agent.Chapter 17 Third party integration 379 Registry values to enable e-mail notifications i Applicable only to e-mails captured by the NBA and Milter MTA agent. you need to edit values in the following registry key: HKEY_LOCAL_MACHINE\Software \ComputerAssociates\CA DLP \CurrentVersion\External Agent API \Notifications This registry key contains the following registry values: AttachOriginalEmail AttachOriginalEmail Type: REG_DWORD Data: Defaults to 1. NTLM or CRAM-MD5 authentication. We do not normally recommend Plain or Login authentication because under these protocols the logon password is sent as unencrypted plain text across the network. you must also set up the UserID registry value—see page 380—to pass the logon account details to the SMTP server.

exe command to set the full credentials. 2 You can then include this value in the EnterpriseDNSList domain list for Exchange or Domino server agents (see page 248) or the enterprise-dns-list parameter for the Milter MTA agent (see page 269). the SMTP port number. This registry value is only required if the Socket API authentication method is not ‘None’ (this is specified by AuthType. If omitted. you run the WgnCred. 3 Now. For examples of how the equivalent registry value is used to prevent ‘repeat processing’ for the Exchange or Domino server agent. For example. SmtpServer SmtpServer Type: REG_SZ Data: Specifies the name of the server hosting the SMTP service and. For full details about WgnCred. it knows that policy does not need to applied to this notification e-mail and so does not process it. SmtpDNSHostName specifies a single DNS domain that is written to the e-mail when it is generated by the Socket API. append the number to the server name. This registry value can also specify the TCP port used for communication between the Socket API and the SMTP server. To cache the password. If you need to specify the UserID registry value.com:25777 UserID UserID Type: REG_SZ Data: Specifies a valid user account that the Socket API will use to log on to the SMTP server.exe utility on the Socket API host machine.380 CA DLP Deployment guide SmtpDNSHostName SmtpDNSHostName Type: REG_SZ Data: This registry value is used to ensure that Socket API notification e-mails are not reprocessed needlessly by consecutive CA DLP e-mail agents. you can set this value to your Exchange server (if it is configured to relay SMTP messages). To use this registry value as intended: 1 You need to set it to the same value (for example.COM) for all your e-mail server agents. separated by a colon. you must also securely cache the password for this account. see page 518. see page 271.COM. if required by the authentication type. To specify a non-default port number. see below for details). where the component ID is: EANotifications You will need to supply this component ID as the <component identifier> if you run a WgnCred.exe. when any CA DLP server agent receives an e-mail from the Socket API tagged as coming from UNIPRAXIS. For example: unipraxis. optionally. the port number defaults to 25. UNIPRAXIS. . This password will be passed to the SMTP server with the user account name.

plus messages and data received and sent. Socket API performance counters The Socket API includes various the following performance objects that are useful when diagnosing socket connection problems: DLP External Socket Agent Summary: Contains counters summarizing overall performance. Diagnostic files External Agent Request and Response diagnostic messages can be saved in a diagnostic file. the Socket API queues messages arriving from a Milter MTA agent and processes them one at a time. and various throttling counters. see page 499. unprocessed. in effect. such as average processing time. ‘Wait throttling’ For data sent by the NBA For messages and files captured by the NBA as they enter or leave the corporate network. For full details about the NBA. see page 260. or if memory usage rises above the maximum level. such as the items successfully analyzed.log ‘Wait throttling’ For data sent by Milter MTA agents For messages captured as they transit through Sendmail or Postfix. the NBA then permits them to continue. see the DiagnosticFolder registry value on page 376. i The NBA connects to the Socket API on the Agent Port Interlaced using the Interlaced protocol. This means that. Monitoring the Socket API There are various sources of diagnostic information when monitoring the Socket API. available from Technical Support. the Socket API applies ‘wait throttling’ if free disk space or memory usage exceed their respective throttling thresholds. see the Network Boundary Agent guide. DLP External Socket Agent Communications: Contains counters for active connections. Socket API log files take the format: WgnSAgent_200808150945. multipart messages.Chapter 17 Third party integration 381 Socket API throttling Socket API registry values specify throttling thresholds based on free disk space and memory usage on the host machine. the Socket API applies ‘fail throttling’. this triggers a change in how the Socket API processes messages or files. The log files are saved on the Socket API host machine in the CA DLP \data\log subfolder of the Windows All Users profile. See below for details. log files and diagnostic files. . Log files Socket API log files record the results of message processing. For full details about the Milter MTA agent and Sendmail integration. see the Performance Counters technical note. i The Milter MTA agent connects to the Socket API on the Agent Port using the Contiguous protocol. see page 23. available from Technical Support—see page 23. This means the Socket API immediately rejects any items currently being processed and all subsequent items. DLP External Socket Agent Data: Contains detailed counters for data being processed. items currently being processed and failed items. for messages captured by the NBA. the Socket API applies ‘wait throttling’. These are performance counters. i For full deployment details. For messages captured by an Milter MTA agent. items queued for processing. For details. the Socket API applies ‘fail throttling’ if free disk space or memory usage exceed their respective throttling thresholds. If free disk space falls below the minimum level.

Organizations run ICAP clients on proxy servers such as Blue Coat ProxySG and Squid to intercept and offload requests initiated from a browser and the corresponding responses from a Web site.382 CA DLP Deployment guide ICAP Agent The ICAP Agent enables CA DLP to integrate with Internet Content Adaptation Protocol (ICAP) clients. it routes them to CA DLP policy engines which can then apply Data In Motion triggers. The ICAP client (2b) on the proxy server intercepts the request and routes the file to the ICAP agent (3a). For example. 3 ICAP agent and hub: The ICAP agent (3a) passes the file to a Remote PE Connector (3b). If the result is: ‘Allow’ (5a). When the ICAP Agent (technically an ICAP server) receives requests from an ICAP clients. the user attaches a file to the Webmail. the upload is permitted and the request is processed by the ICAP client. 4 Policy engines: A PE analyzes the file. 2 Proxy server and ICAP client: The email is sent using HTTP or HTTPS to the proxy server (2a). the upload is blocked and the ICAP client routes a notification message to the user's browser. 6 CMS: Any resulting events are replicated up to the CMS and stored for subsequent retrieval and reviewing (7). for example. The outcome of any policy processing (‘block’ or ‘allow’) is routed back via the ICAP agent to the ICAP client. . The diagram below shows an example deployment architecture for the ICAP agent and the information flow for an HTTP request. to block inappropriate uploads. which in turn allocates it a policy engine (4). ICAP agent example deployment architecture 1 A user attempts to upload a file using HTTP. This provides CA DLP with a further method for controlling HTTP activity such as file uploads and downloads. while using a Webmail application. 5 Result of policy processing: These results are routed back to the ICAP client. ‘Block’ (5b).

1 2 Optional: Import user DN details 3 Installation ICAP agent and policy engine hub Policy engines 4 Configure CA DLP components ICAP agent Policy engine hub Policy engines 5 Turn on integration ICAP agent deployment procedure These tasks are described on the following pages. ICAP clients can process both requests and responses. Specify the ICAP agent host machine: You need this to allow the ICAP client to route requests and responses to the ICAP agent. an HTTP request or HTTP response. you need to: ` Enable the ICAP v1 options Client Address and Authenticated User. If it is enabled. ICAP agent port number: Specify the port assigned to the ICAP agent.Chapter 17 Third party integration 383 Deployment procedure Integrating CA DLP with an ICAP client involves the following tasks: Configure your proxy server and ICAP client Configuring the proxy server and ICAP client The proxy server must have an ICAP client installed. <port> specifies the port number used for communication between the ICAP client and ICAP agent. for Blue Coat ProxySG servers you must provide a service URL. formatted as shown below: icap://<ipaddress>:<port>/<reqmod>|<respmod> Where: <ipaddress> is the IP address of the ICAP agent host machine. If authentication is not enabled. This must match the port specified by the AgentPort registry value (see page 385). If you use the default port (1344). See the documentation for your proxy server and ICAP client for full configuration details. you need to: Ensure authentication is enabled on the proxy server: The authentication method encrypts the user's IP address and user name. ` Disable Preview Size for HTTP responses. this is 1344. the ICAP agent may not work correctly. In addition. . For example. This option is not supported by the CA DLP ICAP agent. you can omit the port number from the URL. user credentials cannot be passed from the ICAP client to the ICAP agent. For integration with CA DLP. <reqmod>|<respmod> identifies the type of event. By default.

384 CA DLP Deployment guide Install the ICAP agent and PE hub You install the ICAP Agent using the CA DLP Integration Agents installation wizard. but in the Email Attributes screen (step 9): 1 Clear the ‘Use default attributes’ check box. For details of supported parameters. Import DN details to CA DLP user address lists The following recommendation applies specifically to integration with BlueCoat ProxySG servers. choose the ICAP Agent feature. Click Install to start the file transfer. From a command line: Define your wgninfra account import command as normal. This enables policy engines to apply the correct user policy to HTTP activity without needing to perform an LDAP directory lookup. To add DN details to user address lists. 2 3 4 Install policy engines This is described in chapter 11. ‘Policy engines’. you must run an Account Import job: Using the Account Import wizard: Set up your account import job as normal. but add the following parameter: /ml distinguishedName For instructions on command line Account Import operations. See page 199 for details. see page 160 . see page 158. In the Policy Engine Hub Configuration screen. Find this in the \Integration folder on your CA DLP distribution media. we recommend that you import user DN details (‘distinguished names’) from your LDAP directory and add them to the e-mail address lists for your CA DLP users. type distinguishedName and click Add. including /ml. provide the credentials for the PE domain user (as specified on page 203). The installation wizard now has all the information it needs. For instructions on using the Account Import wizard. see page 150. Details for individual wizard screens are also available in the online help. A policy engine hub is installed automatically with this feature. run setup. .exe. In the Custom Setup screen. 3 In the resulting Edit Selection dialog. 2 Select any available attribute and click ‘Add’. To prevent potential policy processing delays. 1 To launch the wizard.

But if you are using a different proxy server or if you use an alternate configuration. This is the default for Blue Coat ProxySG servers that use LDAP authentication. AuthenticatedUserType AuthenticatedUserType Type: REG_DZ Data: Defaults to DN. . which in turn allows them to map the user to a CA DLP user account. Do not specify a value if you are not using base64 encoding on the proxy server.Chapter 17 Third party integration 385 Configuring the ICAP agent The ICAP agent is configured to work automatically with Blue Coat ProxySG ICAP clients. you may need to modify this value to indicate the type of user information included in the ICAP message. you must restart the PE hub. Policy engines use this information to perform LDAP lookups based on the user’s DN entry in order to retrieve that user’s e-mail address. Policy engines use these credentials to map the user to a CA DLP user account. i If you change the port value. this registry value indicates that AuthenicatedUserHeader is populated with the user’s DN entry in the LDAP directory. you must edit values in this registry key: HKEY_LOCAL_MACHINE\Software \ComputerAssociates\CA DLP \CurrentVersion\ICAP This registry key contains the following registry values: AgentPort AgentPort Type: REG_DWORD Data: Defaults to 1344. i Only LDAP authentication is supported in the current release. For Blue Coat ProxySG servers. To do this. AuthenticatedUserEncoding AuthenticatedUserEncoding Type: REG_DZ Data: Defaults to ‘base64’ for base64 encoding. you must set this value to identify the ‘user credentials’ header used by that proxy server. Policy engines can then use this ‘user type’ information to retrieve an e-mail address for the specified user. the ICAP agent) to communicate ICAP requests and responses. This specifies the port used by the ICAP client and server (that is. AuthenticatedUserHeader AuthenticatedUserHeader Type: REG_DZ Data: Defaults to X-Authenticated-User. This specifies the encoding scheme for the user name in the ICAP message. This is the default for Blue Coat ProxySG servers. you need to configure the ICAP agent. This specifies the ICAP x-header that contains the user credentials. This specifies what type of user information is included in the AuthenicatedUserHeader header. If you use a different proxy server. If using a different proxy server.

the default value for Blue Coat ProxySG servers. 3 Errors and warnings. Only use this value if directed to do so by CA Technical Support—see page 23.log file. If no diagnostic folder is specified (that is. You may be asked to modify this value by CA Technical Support—see page 23. This specifies the folder into which ICAP messages passed to the ICAP agent are saved for diagnostic purposes. This registry key value specifies the portion of the HTTP header that contains the IP address of the user system. plus informational and status messages i Setting LogLevel=3 will cause the log file to grow extremely rapidly. DiagnosticFolder DiagnosticFolder Type: REG_DZ Data: No default value.386 CA DLP Deployment guide CreateICAPMsg CreateICAPMsg Type: REG_DWORD Data: Defaults to 2. This level of logging is provided for testing and diagnostic purposes only. see page 499. if DiagnosticFolder is blank). . Do not change this value. For example. If using a different proxy server. Supported values are: 0 Do not write any messages to the diagnostic folder. LogLevel LogLevel Type: REG_DWORD Data: Defaults to 2. regardless of what value CreateICAPMsg is set to. you may need to modify this value. This determines whether the ICAP agent connects to a local policy engine hub. For example. you can configure the ICAP server to only log errors or important system messages. This specifies how ICAP messages passed to the ICAP agent are stored in the specified DiagnosticFolder (see below). The supported logging levels are: 1 Errors only 2 Errors and warnings written. it shows storage and retrieval on every resource item. 2 Only write messages to the diagnostic folder if a processing error occurs. 1 Dump every message to the diagnostic folder. the file is located in CA DLP's \data\log subfolder of the Windows All Users profile. Log entries are written to the WgnICAP_<date>. This determines the level of logging for the ICAP server. no ICAP messages are HostInHub HostInHub Type: REG_DWORD Data: Defaults to 1. ClientIPHeader ClientIPHeader Type: REG_DZ Data: Defaults to X-Client-IP. The level of saved messages is set by CreateICAPMsg (see above). where <date> is the date and time when the log file was created.

. UpdateConfig UpdateConfig Type: REG_DWORD Data: Defaults to 0. RequestTemplateFile RequestTemplateFile Type: REG_DZ Data: Specifies the HTML template file that contains the notification message shown to users for HTTP requests as a result of policy processing. It contains variables for the message text issued by the policy engine. ResponseTemplateFile ResponseTemplateFile Type: REG_DZ Data: Specifies the name and path to the HTML template file that contains the notification message shown to users for HTTP responses from Web sites as a result of policy processing. ensure that this maximum file size threshold matches or is less than the Maximum Size of Files (KB) setting in the user policy (which also defaults to 50 MB).html This default template is very generic. it automatically resets this value to 0. This specifies the maximum size (in MB) of message to be processed by the ICAP agent. This registry value defaults to: C:\Program Files\CA\CA DLP\client \RequestTemplate. you can modify the template content and the file name and location to meet your organization’s needs. If required. an entry is written to the log file indicating that a message exceeded the maximum size and was allowed. To avoid unnecessary delays. It contains variables for the message text issued by the policy engine. you can modify the template content and the file name and location to meet your organization’s needs. Messages larger than this are allowed. only to be rejected if they exceed the user policy-defined threshold.html This default template is very generic. Set to 1 to force the ICAP agent to re-read the registry. This registry value defaults to: C:\Program Files\CA\CA DLP\client \ResponseTemplate. When the ICAP agent has accepted the changes. This prevents very large files being sent for policy processing by the ICAP agent.Chapter 17 Third party integration 387 MaxMessageSizeMB MaxMessageSizeMB Type: REG_DWORD Data: Defaults to 50. If required. Enables administrators to update the ICAP agent configuration. but not processed.

The CA DLP infrastructure cannot handle these paths. Wgnrdm. For details. click the Change button. see ‘Install the RDM’. IBM DB2 CommonStore. In the Service Accounts screen. For full details. CA DLP infrastructure: You must change the logon account for the infrastructure service to a named user. step 5. Install the RDM You install the RDM using the CA DLP server installation wizard. enables CA DLP to retrieve events that are archived in third party remote storage locations and display them in the iConsole or Data Management console.1 Installation folders: To install the RDM to a non-default location. Symantec Enterprise Vault.2 Free disk space: To check whether the target volumes have sufficient free disk space for the selected features. run setup.dll. i RDM configuration for Enterprise Vault requires the RDM to be installed on the SEV server or EV Administration Console—see page 331.exe. ` For EAS integration: When retrieving e-mails from an EAS archive. choose the Remote Data Manager feature—see page 31. RDM requirements Archive solutions: For the current release. ! If you install to a non-default location. this named user account must also . Click the Browse button for the Infrastructure service. ! This must be the default e-mail application on the host machine. 3. the infrastructure logs on as a LocalSystem account but you must change the service’s logon account to a named user! ` Lotus Notes 6. But note the following requirements for this logon account: ` This account requires the ‘Log on as a service’ security privilege. Find this in the \Server folder on your CA DLP distribution media. then enter the domain. the RDM utility supports CA Message Manager. IIS server: RDM requests are serviced by an IIS server. not by IP address. click the Disk Space button. see ‘Install the RDM’. 2 3 3. choose Utility Machine. the target path must not include folders whose names contain Far Eastern characters. For integrations with EAS.5 or later if retrieving Domino e-mails from a third party archive. you must specify the IIS server by name. EV and SourceOne. In the Customer Information screen. The RDM submits data requests through a Microsoft Internet Information Services (IIS) server—see the diagram on page 327.388 CA DLP Deployment guide Remote Data Manager The Remote Data Manager (RDM). 1 To launch the server installation wizard. specify the logon account used by the local CA DLP infrastructure service. E-mail solution: The host machine must have an e-mail client installed: ` Outlook 2003 or later if retrieving Exchange e-mails from a third party archive. 4 5 In the Server Type screen. wgninfra. and EMC EmailXtender and SourceOne. there are additional requirements. In the Custom Setup screen. enter your user name and organization. For details. But note the requirements above. ZANTAZ EAS and Digital Safe. see page 390. ! By default. step 6.exe. name and password for the account you want to use.

see page 391 ` ZANTAZ Digital Safe. must be listed in the Account Administrator dialog and must have the IIS Content Retrieval for Indexing\Restore permission. Specify the name or IP address of the CA Message Manager machine hosting the Archive server. This prevents authentication errors when the IIS server connects to the e-mail archive server. not by its IP address. You must also set the port number on which IIS listens for data requests from the RDM. In EAS. this account. remember to: ` For EV integration: When retrieving e-mails from the Enterprise Vault.exe before these settings will take effect. see page 390 ` EAS. 6 In the Remote Data Manager Configuration screen. Click Install to start the file transfer. Specify the name or IP address of the machine hosting SourceOne (that is. the IIS server will not be able to authenticate the RDM. Before you do so.Chapter 17 Third party integration 389 have EAS permissions to retrieve archived data. ` CA Message Manager. The supported types are listed on page 388. 8 ` For SourceOne integration: To enable the RDM to retrieve e-mails from a SourceOne archive. see page 391 ` EAS Server and Port: Only applicable to EAS integration. ` Assign the ‘Log on as a service’ security privilege’ to the infrastructure logon account—see page 390. see page 390 ` IBM DB2 CommonStore. This defaults to port 80. ` SourceOne Server: Only applicable to SourceOne integration. If you specify its IP address. this named user must be the same as the EV ‘Service User’. ` For EmailXtender integration: To enable the RDM to retrieve e-mails from an EmailXtender archive. 7 The installation wizard now has all the information it needs. Also. ! You must specify the IIS server by name. the DMS server). specify the target archive. so you must restart Wgninfra. When installed. ` Message Manager: Only applicable to CA Message Manager integration. further post-installation tasks are required to enable the RDM to retrieve events from: ` Archive type: Choose the archive that you want to integrate with. see page 390 ` EMC EmailXtender. ` Include the EAS server as a trusted intranet site— see page 390. Specify the name of the IIS server that will service RDM requests. this named user must be the same as the EmailXtender service account. this named user must be the same as the SourceOne service account. For details. refer to your Enterprise Vault documentation. see page 390 ` EMC SourceOne. . the RDM is activated by the local CA DLP infrastructure service. even if the IIS server and RDM are on separate subnets.

This enables the RDM to connect to the EmailExtender server. You may need to extend the time if very large files need to be retrieved. On the host machine. Add the URL for the EAS server to the list of sites specified for the local intranet zone. the file retrieval process is abandoned.exe. you need to configure the following registry value: GlobalFileRetrieveTimeoutMilliseconds Type: REG_DWORD Data: Defaults to 300. ExOConnSetup. edit the Internet Explorer Security options for the local intranet. or if a data source has limited bandwidth. EMC EmailXtender integration To complete the integration setup: Install the EmailXtender Connector for Orchestria: After installing the RDM. If the RDM does not respond within this period. This specifies the file retrieval timeout in milliseconds. it is not on the SourceOne management server). EAS integration To ensure that the RDM data requests can be authenticated by the IIS. This account requires the ‘Log on as a service’ security privilege. i The SRE Initialization package is supplied by EMC. 1 2 Ensure that you are logged on with local administrator rights on the RDM host machine.exe. open the Local Security Policy applet or. Expand the Local Policies branch and select User Rights Assignment. open the Domain Controller Security Policy applet. on the RDM host machine. This must be the same name that you specified in step 6 of installing RDM. Assign the ‘Log on as a service’ privilege to the CA DLP infrastructure logon account. you changed the logon account used by the local CA DLP infrastructure service. For example: http://<UX-MAIL-ARCHIVE-NY> i You must be logged into Windows using the same account as the named user the RDM uses on the infrastructure—see step 5 on page 388.390 CA DLP Deployment guide Post-installation tasks Assign the ‘Log on as a service’ privilege to the infrastructure logon account In step 5 on page 388. if this machine is a domain controller. This security area determines which users have logon privileges on the local computer. you need to add the EAS server to the local intranet’s list of trusted sites. If you have not already done so. you must install the EMC SourceOne SRE Initialization package (ES1_SRESetup. . EMC SourceOne integration If your RDM is installed on a remote server (that is. you must assign this privilege manually. To do this: 1 On the machine hosting the RDM server. 2 3 4 Configure the file retrieval timeout You can configure the maximum period of time that CA DLP will allow for the RDM to fetch a file from the relevant data source. CA Message Manager integration You need to edit the RDM registry to enable it to communicate with CAMM—see page 325. See step 4 on page 365.000 (equivalent to 5 minutes). Wgninfra. See step 2 on page 368.exe) on the RDM host server. Both applets are available in Administrative Tools. Locate this registry key: HKEY_LOCAL_MACHINE\SOFTWARE \ComputerAssociates\CA DLP \CurrentVersion\Remote Data Manager Within this registry key. This enables the RDM to connect to SourceOne. from LocalSystem to a named user. you need to install this connector.

Support for multiple RDM servers It is possible to have multiple RDMs connected to the same CMS. future requests for archived files are directed to any remaining RDM servers. 2 Now create a password for the Notes client account and store it in the registry. you selected EMC EmailXtender for Lotus Domino. run: net start wgninfra i For full details.0. From a command prompt in the \system subfolder in the CA DLP installation folder. run: net stop wgninfra 2 Edit the startup. The CMS will try to reconnect to the failed RDM after 15 minutes. .retrydelaysecs=600 The retry interval is specified in seconds.properties file: 1 Stop the 'CA DLP infrastructure' service. 4 Restart the CA DLP infrastructure service. 3 ZANTAZ Digital Safe integration You need to edit the RDM registry to enable it to communicate with Digital Safe—see page 361. From a command prompt. you must install a Notes client. Find this file in the \system subfolder of the CA DLP installation folder. IBM DB2 CommonStore for Domino: see page 348. It has not been rebranded to reflect the product name change from ‘Orchestria APM’ to ‘CA DLP’ in r12. If an RDM stops responding. This enables CA DLP to retrieve events from third party remote storage locations more efficiently by sharing requests across all installed RDMs. as the machine name forms part of the unique event identifier.Chapter 17 Third party integration 391 i This connector is supplied by EMC. To configure this retry interval. This example sets the retry interval to 10 minutes. 4 When prompted. This component also requires a Notes client with specific rights and a suitable password: 1 First. enter the ID number for RDMEELDClient. any references within CA DLP to e-mails archived on that server will no longer be valid. Do not rename archive servers ! If you rename an archive host server. This means that although the CMS will keep a summary of event data for such events. enter and confirm your chosen password for the Notes client account. run: wgncred -set This displays a list of components for which passwords are stored plus their corresponding ID numbers and component identifiers.properties file. From a command prompt. If you rename an archive host server. 3 When prompted. IBM DB2 CommonStore integration You need to edit the RDM registry to enable it to communicate with IBM DB2 CommonStore: IBM DB2 CommonStore for Exchange: see page 342. CA DLP cannot retrieve messages stored in the archive! Install a Notes client: Only required for integration with EMC EmailXtender for Lotus Domino. you must edit the startup. see page 23. The default user for this client must have sufficient rights to create a Notes database on the RDM server. please contact Technical Support. their content will no longer be retrievable. In step 5 on page 388. Open this file and add the following line: service.

392

CA DLP Deployment guide

18. Event Import

Event Import
his chapter introduces the Event Import utility. Event Import enables CA DLP to integrate with email archives and file storage locations. In particular, Event Import can import: E-mails: Typically, these are e-mails that have been extracted from an archive. Event Import can also import e-mails saved in archive files (for example, PST and MSG files). Files: For example, you can import Microsoft Word documents or PDF reports. Typically, files are imported as part of an Import Policy operation (see page 227) in order to categorize, or apply smart tags to, important business documents. This chapter explains how to install and configure Event Import and includes instructions for all of the Event Import parameters (see page 410).

chapter 18

T

E-mail 1

Files

Job mode

2

EA API

3

Event Import 5 4 CMS 6

Importing e-mail and file events 1 The event source (a folder or Exchange mailbox) is defined in a configuration file. 2 The External Agent (EA) receives archived e-mails and saves them as CA DLP event files. 3 Event Import imports the archived e-mails or files into the CMS (4). Imported events are replicated to the CMS. Import operations can run in batch mode (5) or continuously (6).

394

CA DLP Deployment guide

Software components
CA DLP e-mail archive integration comprises the following components: Event Import utility The CA DLP Event Import utility can import e-mails from a third party e-mail archive, from Microsoft Exchange mailboxes, or from e-mail archive files (for example, PST and MSG files). Event Import can also import files from designated folders. It automatically associates these imported events with their correct 'owners'. If required, it can even create new users to 'own' imported events. CA DLP provides tools to allow Event Import to run in batch mode or to run continuously. For further details, see page 401. Event Import is dependent on various parameters to configure the import operation. These parameters are described on page 410. External Agent The External Agent connects to the e-mail archive indexer process and extracts archived e-mails as EVF files to a cache folder that can be accessed by the Event Import utility. Installing and running the External Agent is described on page 369. i In previous CA DLP releases, the External
Agent was called the Remote Data Import (RDI) utility. Its name has been changed to reflect its extended capabilities.

Remote Data Manager server The Remote Data Manager server retrieves e-mail data that has been archived in third party remote storage locations. It enables administrators to view archived e-mails in the iConsole or Data Management console. For details, see page 388.

Chapter 18 Event Import

395

Importing from e-mail archives
The principal purpose of the Event Import utility is to enable CA DLP to integrate with e-mail archiving products and extracted e-mails from an archive into your CMS. The diagram below summarizes the key components and processes involved when integrating CA DLP with an e-mail archive solution. This example is 2 E-mail server 9 E-mail store based on the Zantaz EAS solution. For simplicity, the diagram shows a single e-mail archive server, feeding data into a single EVF file cache. In practice, a large organization may have many such servers feeding data into multiple caches.

6 iConsole

1 E-mail archive server

1a

8

7 RDM machine

1b Archive indexer process

Searching for archived e-mails

1c External Agent API

5 CMS

3 EVF file cache

4 Event Import machines

Importing e-mails into CA DLP CA DLP integration with e-mail archive 1 This server hosts the e-mail archive solution, Zantaz EAS (1a). This connects to an e-mail server such as Microsoft Exchange (2) and archives messages in the e-mail store (9). The e-mail archive solution uses an indexer process such as the EAS IndexerService.exe (1b) which in turn passes data to the External Agent API (1c). The External Agent API extracts archived e-mails and saves them as EVF files in a cache (3). This cache provides the source data for the CA DLP Event Import utility (4). This utility requires the CA DLP infrastructure. For very large e-mail archives, you may need to run multiple Event Import utilities simultaneously to avoid import bottlenecks. Each Event Import utility imports archived e-mails into the CMS (5). The actual message data is not saved on the CMS; instead, a record in the CMS database for each imported e-mail references the associated entry in the e-mail store (9). When displaying captured e-mails in the iConsole (6), the Remote Data Manager utility (7) retrieves data for e-mails archived in the e-mail store (9). In the case of EAS, these data requests are sent via Microsoft IIS (Internet Information Services) (8).

396

CA DLP Deployment guide

Identifying the owners of imported e-mail events
Unlike in previous versions of CA DLP, Event Import does not assign imported e-mails directly to owners. Instead, it identifies ‘event participants’ and associates an e-mail address with each participant. Under normal conditions, these participants are only mapped to CA DLP users during event searches, not while an import job is running. Of course, this mapping mechanism requires that users’ e-mail accounts are kept synchronized with their CA DLP accounts—for details, see ‘Synchronizing email accounts and CA DLP user accounts’ below. However, address mapping is used during an import job if an ‘attribute-based’ import filter is specified. This enables import jobs to exclude or only include e-mails associated with CA DLP users who have specific account attributes. See page 397 for details.

E-mails ignored by Event Import
Certain categories of e-mail are ignored by Event Import. That is, they are not imported into the CMS. These include: ‘Non-mail’ messages: These include e-mails that are neither incoming nor outgoing. For example, this includes the Outlook welcome message and draft messages. They also include other mailbox items such as appointments. Out of date e-mails: If an import job is set up to use the parameters EMail.EventDateFromEMail and Engine.EventRetentionPeriod, then Event Import ignores e-mails where the retention period has expired—see page 416. Filtered e-mail: You can set up import jobs to only include or to exclude certain categories of e-mail. See page 397 for details.

Synchronize e-mail accounts and CA DLP users
! To successfully integrate CA DLP with your e-mail
archive solution, good synchronization is critical between your e-mail user accounts and your CA DLP user accounts! For details, see page 147.

Events abandoned by Event Import
Events can be abandoned when the importer is carrying out an import operation and: Event Import is on a standalone mode machine (see page 516), the infrastructure is suspended, and then the importer is shut down, or Import Policy is configured to Direct or Hub mode, the import engine is requested to shut down, but the policy engine and the hub do not complete message processing in a timely fashion. Event Import abandons the e-mail events it was processing, leaving the source data unchanged in its directory. For example, if an event is associated with: An MSG file, the source MSG file is left intact in the directory it was being imported from. A PST file, the source PST file (including its contents) is left intact in the directory it was being imported from.

To ensure that each imported event is associated with its correct owners in the CA DLP user hierarchy, each e-mail processed by Event Import needs to map directly to a CA DLP user. However, the continual changes to your workforce mean that new e-mail accounts are created, redundant accounts are deleted and existing accounts are modified. You therefore need a strategy to maximize account synchronization with CA DLP and to minimize anomalous accounts (existing in one system but not the other). The principal way to achieve this is by making regular use of the Account Import utility—see page 147.

Chapter 18 Event Import

397

Filtering e-mail import operations
If required, you can filter import jobs to exclude or only include certain categories of e-mail. The expression syntax is: <uservar><operator><text>

Filtering by sender address
If required, you can filter import jobs to exclude or only include e-mails based on the sender’s e-mail address. To do this, you use these parameters: EMail.SenderAddrIncludeFilter (see page 420) EMail.SenderAddrExcludeFilter (see page 420) You typically use these parameters to only import internal e-mails, or to only import internal e-mails but exclude e-mails sent by specific users or groups of users.

Where: <uservar> specifies the name of the user attribute you want to test against. <operator> determines whether the value specified by <text> must be present or absent. <text> represents the attribute value whose presence or absence you want to test. Values are not case-sensitive; use double-quotes if the value includes spaces. Filter expressions leverage the existing User Attribute data lookup functionality. For full details about <uservar>, <operator> and <text>, see the Administration console online help; search the index for ‘userattr commands, data lookup’. For example, to exclude all e-mails associated with users based in your organization's UK office: 1 Customize the CA DLP user attributes for your organization so that the ‘Country’ attribute specifies where the user is based. In the machine policy for the host machine, specify this expression in the User Filter setting: country is not uk 3 Any user whose ‘Country’ attribute is not ‘UK’ will fail the test (the expression evaluates to False).

Filtering by user attributes
If required, you can configure import jobs to exclude or only include e-mails associated with CA DLP users who have specific account attributes. For example, if your CA DLP user accounts include a ‘Country’ attribute, you can configure import jobs to only import e-mails sent by or to users in a specific country. The import filter is defined in the machine policy of the Event Import host machine, where the User Filter policy setting defines a lookup expression containing one or more True or False tests that relate to a single CA DLP user attribute (for example, a user's team or country). Find this setting in the E-mail User Identification folder. Event Import uses address mapping (see page 488) to associate each event participant, via an e-mail address, with a CA DLP user. It then evaluates the lookup expression for that user. If all the users fail the test (in each case, the command evaluates to False), the e-mail is not imported. i If the relevant user attribute is blank or not
defined for any user, that user is deemed to have failed the test.

2

Support for Exchange envelope journaling
Event Import can import e-mails from Exchange servers that have envelope journaling enabled. The envelope journaling feature in Exchange enables organizations to archive transport envelope data. This includes the actual recipient information that the transport system used to route and to deliver the e-mail.

If any user passes the test (the command evaluates to True), or any participant cannot be mapped to a CA DLP user (because no corresponding CA DLP user exists), the event is imported.

398

CA DLP Deployment guide

In particular, it identifies the recipients who actually received the message, including recipients from distribution lists and blind carbon-copy (Bcc) recipients. Unlike message-only journaling, which copies e-mails to be archived into a designated mailbox, envelope journaling copies into the designated mailbox an envelope message (a ‘wrapper’ e-mail) that contains a journal report plus an attachment containing the original e-mail. The journal report (the body text of the envelope message) contains the transport envelope data of the original e-mail. However, when an e-mail is imported from a mailbox on an Exchange server that has envelope journaling enabled, CA DLP extracts the journal report and the attachment containing the original e-mail and discards the envelope message. This process is referred to as ‘deenveloping’. CA DLP then creates a new event based on the original e-mail and the actual recipient details. When a reviewer searches for this imported e-mail in the iConsole or Data Management console, the console displays the original e-mail. i Recipients extracted from the journal report are
searchable in the iConsole or Data Management console. That is, reviewers can specify a recipient when searching for e-mails imported from an Exchange server that has envelope journaling enabled.

Single import operations only from each Exchange mailbox
We strongly recommend that you only run one import operation at a time from a single Exchange mailbox. This is to avoid the risk of generating duplicate imported events on the CMS. For example, if two Event Import operations (running on separate machines) are simultaneously importing e-mails from the ‘Frank Schaeffer’ mailbox, there is a risk that individual e-mails sent to or from Frank Schaeffer are imported twice, generating duplicate events on the CMS. There is also a lesser risk that some e-mails are not imported at all. i You can, however, run multiple import operations simultaneously from separate Exchange mailboxes. Note also the MAPI and CDO requirement for mail box import operations—see page 544.

E-mails sent from Outlook 2003 in Cached Exchange mode
E-mails sent from Outlook 2003 when using Cached Exchange mode have truncated timestamps. That is, the timestamps for these e-mail events are rounded down to the nearest minute. This can cause problems as CA DLP uses this timestamp to record when the event was captured (see page 544).

Chapter 18 Event Import

399

Event Import operations
The CA DLP Event Import utility is a command line utility for importing e-mails or files into the CMS. It is also the second CA DLP component (after the External Agent API—see page 369) in the process of extracting archived e-mails and importing them into a CMS. i To optimize data storage when importing from an
e-mail archive, the actual message data is not saved on the CMS. Instead, a record in the CMS database for each imported e-mail references the associated entry in the e-mail archive.

Exchange and Outlook import operations
Before running an import operation to import e-mails directly from an Exchange server or e-mails in .MSG or .PST files, note the requirements for each Event Import host machine: For PST and MSG type operations: The Event Import target machine must have a Microsoft Exchangecompatible e-mail application installed, such as Outlook 2003. This must be the default e-mail application on that machine. Note also the Outlook requirement on page 405. ! You cannot use an Exchange Server
Management Pack in place of Outlook on the target server! You must use Outlook as your MAPI client.

Import parameters Event Import supports a wide range of parameters for configuring the import operation. For example, you can specify input queue thresholds to prevent performance bottlenecks. You can specify these parameters in a command line or, more commonly, in a configuration file. For full details, see page 410. Running import operations Event Import can be run in batch mode from a command line, using the wgnimp.exe utility. Or you can set up continuous import operations, using the Event Import service, wgnimpsv.exe. For details, see page 401.

` MSG only: To import .MSG message files saved in
Microsoft Outlook 2003, you must have Microsoft Outlook 2003 installed. If an earlier version of Outlook is installed, the import operation will fail.

` PST only: If you are using Microsoft Outlook 2003,
you can create two types of .PST archive file, a ‘Personal Folders file’, or a ‘Personal Folders file (97-2002)’. The ‘Personal Folders file’ is not compatible with earlier versions of Microsoft Outlook. To import a ‘Personal Folders file’ into CA DLP, you must have Microsoft Outlook 2003 installed. If you have an earlier version of Outlook installed, the import operation will fail. For EXCH type operations: When importing e-mails directly from mailboxes on an Exchange server:

Event Import requirements
Operating system
For supported operating systems, see page 26.

Logon requirements
For the logon requirements for the CMS and Event Import, see page 400.

` The Event Import host machine requires MAPI and
CDO 1.2.1; see page 544

` The user associated with the mailbox being
imported from must be in the Exchange Global Address List at the time of the import operation. i For summary details about EXCH, PST and MSG
import operations, see page 405.

400

CA DLP Deployment guide

Notes import operations
Before running a Notes import operation, note the requirements for each Event Import host machine: Notes must be installed on the host machine. The Notes user on the host machine must have access to all Notes databases that you want to import e-mails from. If you intend to use the NSF.DeleteAfterImport parameter, the Notes user must have sufficient rights to delete e-mails after a successful import operation (see page 433). CA DLP needs to access the Notes user on the Event Import host. That is, you need to set the password for this user. To avoid a security loophole, you need to configure wgncred.exe to securely cache this password (see page 519). The corresponding parameter for setting this password in import.ini is: NSF.ImportPassword (see page 431). i When importing e-mails from a Notes database,
be aware that you cannot import directly from the Trash and Junk Mail folders.

Logon requirements for Event Import
Before you run Event Import, you may need to change your logon details or the logon details of the Event Import service, depending on the source location of the imported files. ! The logon account for the Event Import service
must have the administrative rights to access the source location.

Wgnimp.exe and batch importing
Before you run wgnimp.exe, depending on the source location of the imported files, you may need to log on to the Event Import machine using an account with administrative rights to access the source location. Importing from a shared network folder You must run wgnimp.exe using a logon account that has permission to change the source folder. Importing from Microsoft Exchange mailboxes You must run wgnimp.exe using a logon account that has permission to access the source mailboxes.

Logon requirements for the CMS
When you run Event Import, you must log on to the CMS as a CA DLP administrator. You can do this using import parameters, though typically you cache the credentials (see step 1.3 on page 402). But note the requirements for this account: Management group: This account must have a management group that encompasses all the users against which you are importing e-mails. If the management group is too restricted, Event Import will be unable to create new users and will fail to import e-mails whose owners are CA DLP users in groups outside of the management group. Administrative privileges: This account must have the ‘Events: Allow event import’ and ‘Events: Allow bulk session management’ privileges. i For details about administrative privileges and
management groups, see the Administration console online help; search the index for ‘privileges’.

Wgnimpsv.exe and continuous importing
By default, wgnimpsv.exe logs on as LocalSystem. Depending on the type of import operation, you may need to change this to a user account with administrative rights to access the source location. Importing from a shared network folder Wgnimpsv.exe must log on using an account that has permission to change (write to) the source folder. Importing from Microsoft Exchange mailboxes Wgnimpsv.exe must log on using an account that has permission to access the source mailboxes. ! If you change the logon account for
wgnimpsv.exe from LocalSystem to a named user account, this account must be a member of the local Administrators group. This ensures that the import service has access to the registry and, if CA DLP is installed to its default location in the Program Files folder, that it can write progress messages to logfiles.

Chapter 18 Event Import

401

Installing Event Import
To install Event Import, you run the CA DLP server installation wizard. We recommend that you install the Event Import feature on a gateway server. Gateways inherit the common gateway machine policy; confirm that the Infrastructure settings in this policy are appropriate for your network. See the requirements on page 399. i If you are upgrading Event Import, we recommend that you upgrade all CA DLP servers at
the same time, beginning with the CMS—see page 28.

Individual import operations
To import archived events in batch mode, you run wgnimp.exe in batch mode from a command line. 1 For ease of maintenance, we strongly recommend that you use a configuration file to specify your import parameters. You need to define your configuration file before running wgnimp.exe.

` See page 409 for an example import.ini file. ` See page 410 for parameter details.
2 Note the logon requirements for wgnimp.exe. See page 400 for details. Note the requirements for the account that you use to log on to the CMS. See page 400 for details. The parameters to define the CMS logon account are:

Running an Event Import operation
For individual import operations, importing messages or files in batch mode, you run the Event Import utility, wgnimp.exe, from a command line; see the next section. To set up continuous import operations, you run the Event Import service (wgnimpsv.exe); see page 400. In both cases, you configure the import operation with command line parameters or parameters in a configuration file. You must also ensure that the account you use to logon to the CMS has appropriate administrative privileges. Finally, some types of import operation, particularly when importing from Microsoft Exchange mailboxes, have specific logon requirements. i If you run a continuous import operation using
wgnimpsv.exe, note that wgnimp.exe remains available for concurrent individual import operations.

3

` Engine.BulkImportUserName ` Engine.BulkImportUserPasswd
4 Run wgnimp.exe. The command syntax is: Wgnimp [options] Where [options] can be: -h This displays the usage information. -f <file> This specifies the name of file containing import parameters. For ease of maintenance, we strongly recommend that you specify your parameters in a configuration file. -p <parameter> This specifies a single import parameter. Parameters listed on the command line take precedence over those in the configuration file. A single command can include multiple -p options. This example imports e-mails from MSG files. Other import parameters are contained in the file params.ini. wgnimp -f params.ini -p import.type=MSG

402

CA DLP Deployment guide

Continuous import operations
When you install Event Import, the wgnimpsv.exe service is installed automatically. You can use this service for continuous import operations. But first you must configure the service by creating and editing a configuration file, import.ini. In detail: 1 Create a configuration file Wgnimpsv.exe requires a configuration file containing the import parameters. i The corresponding parameters for setting
these credentials in import.ini are:

credentials itself. To do this, use the following command line syntax to open a new command window where you can enter a valid username and password: wgnimpsv -setcredentials

1.1 Create an import.ini file: You must name this
configuration file ‘import.ini’ and save it in the same folder as wgnimpsv.exe. It can contain any of the import parameters available for wgnimp.exe.

` Engine.BulkImportUsername ` Engine.BulkImportUserpasswd
If you subsequently need to reset the CMS logon credentials, you can do so by running the following command: wgnimpsv -clearcredentials

` See page 409 for an example import.ini file. ` See page 410 for parameter details.
1.2 Specify the continuous import parameter: In
addition to the usual parameters, import.ini must also include a parameter to specify continual importing. Add the line: File.ContinuousInput=yes i Even if you have changed wgnimpsv.exe from
a ‘Manual’ to an ‘Automatic’ startup service, you must still add this line to import.ini to prevent the service stopping prematurely.

2

Configure the wgnimpsv.exe service

2.1 By default, the Event Import service installs as
a ‘Manual’ startup type. You must change this to ‘Automatic’ startup type as soon as you have created your import.ini configuration file.

2.2 If necessary, change the service logon properties
to reflect the requirements on page 400. 3

1.3 Securely cache the CMS logon credentials
When you run Event Import, you must log on to the CMS as a CA DLP administrator. So that you do not need to store the CMS credentials in import.ini (which would represent a security loophole), you can configure wgnimpsv.exe to securely cache the

Begin the import operation To do this, simply restart wgnimpsv.exe.

i After wgnimpsv.exe has started, any subsequent
changes to import.ini will only take effect after you restart the service.

When the wizard prompts you for the program you want to run. Available parameters are described on pages 414 to 445. having been specified in step 3. This allows you to schedule import jobs to run at regular intervals during periods of low CMS activity. 4 5 . you must edit the Run field: Run: The Event Import executable. you must specify an account that is a member of the local Administrators group. 2 3 Open Scheduled Tasks in the Systems Tools folder. Specify a scanning schedule as required. you must edit the advanced properties for the scheduled task. This parameter enables the import job to resume (during the next scheduled time slot) from the point at which it was stopped. 6 In the final wizard screen. This ensures that Event Import can access the registry and that it can write progress messages to logfiles. is already included in the Run command. WgnImp.exe. see page 444. browse to the \Import subfolder in the CA DLP installation folder and choose WgnImp. -i <instance> This specifies the name of an import instance. 1 In the import configuration file. When the wizard prompts you for a Windows user account.exe. You must now append the import configuration file and a named instance to this command. ensure that SQL. You must specify an instance even if you are only running one instance of Event Import.Chapter 18 Event Import 403 Scheduling remote CMS import jobs If required. Specifically. i Credentials for accessing the remote CMS are defined by the primary CMS import parameters. you can schedule remote CMS import jobs using the Windows Scheduled Tasks wizard.RunViaScheduledTask parameter is set to Yes. Note that the Run command uses the same syntax as command line scanning jobs: Wgnimp -f <file> -i <instance> Where: -f <file> This specifies the name of file containing import parameters. But see also the warning on on page 442.

404 CA DLP Deployment guide Multiple import operations You can run different types of import operations concurrently on the same host machine by running wgnimpsv. Each configuration file can specify a separate set of import parameters that apply only to that service instance. . this approach causes misleading 'import failure' messages to be written to the logfile. You must ensure all instances have been manually deleted before uninstalling Event Import.exe from a command line. Indeed. Each instance must import from a separate source ! We strongly recommend that each service instance imports from a separate source! You cannot improve import performance by using multiple service instances to import data from a single Exchange mailbox or a single source folder. See the warning opposite. so you do not need to rerun the wgnimpsv -setcredentials command. Wgnimpsv -instance lsteel -service i The -instance parameter must come before the -service parameter The new service looks for a configuration file called import_lsteel. Each instance must import from a separate source. Note also: All service instances share the same set of CMS logon credentials.ini. provided it is not set as the default. wgnimpsv -instance lsteel -unregserver i The -instance parameter must come before the unregserver parameter. otherwise orphaned services will remain on the host machine. net start wgnimpsv_lsteel or net stop wgnimpsv_lsteel X Delete a non-default service instance This example command deletes the new service. The command syntax for configuring multiple service instances is as follows: X Start or stop a service instance These example commands start and stop the new service. X Create a non-default service instance This example command creates a new service called wgnimpsv_lsteel.

you must specify the type of import operation. see the import.PST Microsoft Outlook archive files. To import .1’ and mailbox user requirements on page 399. you may want to import . NSF: Use to import .x. 7. CA DLP supports Lotus Notes 6. 6. MSG: Use to import . EXCH: Use to import events from mailboxes on a Microsoft Exchange server. These are Microsoft representations of Internet Mail messages. i Note also the version requirements for PST archive files on page 399. . but note that the EML file extension also has other uses / can also be used by other e-mail clients.5. or 8. PST: Use to import . i Note also the Outlook version requirements on page 399. or 8 and Domino Server 6. EML: Use to import .2. i Note also the ‘MAPI and CDO 1. To import . For details. 7.PST files.NSF Lotus Notes database files. These are e-mails saved as Microsoft Outlook message files.MSG message files. File: Use to import files from designated folders.4.Chapter 18 Event Import 405 Event Import types When setting up an event import operation. The supported versions of Microsoft Exchange Server are Exchange Server 2003 and 2007.type parameter on page 413.EVF files generated by the Data Replay utility in order to test an Import Policy configuration (see page 227). These are e-mails sent using Bloomberg terminals and archived in an XML dump file. EVF: Use to import . The supported import types are listed below: BBMAIL: Use to import Bloomberg e-mails from XML dump files. 6. To import . These are typically text-based files such as Microsoft Word or PDF documents. For example.MSG files. SQL: Use to import CA DLP events (e-mails and files) from a remote CMS. i EML files usually contain data for Internet e-mails.EML Internet e-mail files.NSF files.EVF CA DLP event files.0. the supported versions of Microsoft Outlook are 2003 and 2007. the supported versions of Microsoft Outlook are 2003 and 2007.5.

For these import jobs.exe and importing from message files (for example. import failures are logged (see the section above). PST or MSG files). but then cannot be replicated successfully to a parent server. As before. Continuous jobs importing from PST or MSG files These are continuous jobs running wgnimpsv.ContinuousInput=Yes. Batch jobs importing from files These are batch jobs running wgnimp. PST or MSG files). or the import operation will fail to start. Exchange mailbox import jobs These jobs import e-mails from specified Exchange mailboxes. any file that fails to be imported is either moved into a \Failed subfolder or deleted. Event Import follows a predefined sequence of parameter tests to determine what failure handling is required: 1 E-mail is deleted This happens if an import job uses this parameter: MSExch. it is not included in the import job configuration file). Imported events cached if replication fails If events are imported successfully. If this mailbox parameter is not specified (that is. import failures are logged—see the logging parameters above for details. then File.406 CA DLP Deployment guide Import failures How Event Import handles individual import failures (events that cannot be imported and assigned to a CA DLP user) depends on the type of import job. .ContinuousInput File. then: In both cases. If an individual e-mail fails to be imported.DeleteAfterImport page 424 page 424 i If File. For these import jobs. The following parameters determine how such files are handled: File. even if some messages can be successfully imported.FailedMailboxFolder For details. see page 428. see page 534. e-mails are always deleted from the mailbox.exe and importing from message files (for example. they are stored in replication holding cache on the Event Import machine. whether the e-mail was imported successfully or not—see page 427. Note that a PST file will be flagged as an import failure if one or more messages within it cannot be successfully extracted and assigned to an owner. For further details.DeleteEMailAfterImport=Always In this case. each individual import failure is logged in the CA DLP Event Import log—see above.DeleteAfterImport must also be set to Yes. This prevents Event Import from repeatedly trying to import the same failed file. If this parameter is not set: 2 E-mail is moved to an ‘import failure’ mailbox folder This happens if an import job uses: MSExch.

Import failures are covered on page 406. this could potentially happen if the primary CMS stores its event data in a third party object storage solution (such as EMC Centera or NetApp SnapLock) and that object store is temporarily unavailable at the time the import job runs.FailedEVFDirectory on page 442). This allows you to identify which event failed to be imported and diagnose the reason for the import failure. where <date> is the date and time when the log file was created.log. see the Data Management console online help. because a policy engine fails to process an imported event). . the event is saved as an EVF files (see SQL. error messages. and important system messages are logged in the CA DLP Event Import log. For example. search the index for EVL files. it will instead save the failed event as an EVL file. Log file names take the format: evtimport_<date>.Chapter 18 Event Import 407 Remote CMS import failures If Event Import is unable to import an event (for example. But if Event Import is then unable to generate an EVF file. You can open EVLs on any machine running the Data Management console to see the associated event. EVLs are ‘event link’ files that point to the associated e-mail events on the primary CMS. import failure. i For details about EVL files. Find this logfile in CA's \data\log subfolder of the Windows All Users profile.LogLevel parameter determines how much detail is logged—see page 416. Event Import log files During event import operations. The Engine.

Tar files are collections of individual files collated into a single archive file.DirAttachment (see page 436). Bloomberg message attachments Archive types There are two types of Bloomberg-supplied archive for e-mail attachments: the first is for attachments sent using ‘short format’ Bloomberg messages.061109. Each import template file contains the minimum parameters needed for a specific type of import operation (for example. Before starting the import operations.exe (by default. set the relevant parameters to the correct values.inet.xml. i An example configuration file is shown on page 409. the second is for attachments sent using ‘long format’ Bloomberg Internet messaging.408 CA DLP Deployment guide Template configuration files CA DLP provides two types of template configuration files in the server installation wizard—see page 31. you must first extract the attachments from the attachment archive.type=BBMail parameter). These archive files typically follow these filename patterns: ‘Short format’ Bloomberg messaging: firm1234. The archive file containing the attachments associated with a dump file of Bloomberg e-mails is a compressed tar format file. CNV or PST files. for example. this is the \import folder).061109. you must first decompress and unpack the attachments from the archive.ini. and move the template file into the same folder as wgnimp.xml. you need to rename the configuration file to Import. . importing from Exchange mailboxes or PST files. Decompress attachment archive before importing Bloomberg e-mails ! Before you can import Bloomberg e-mails (using an import.gz Import template files These template files are used to import a range of file types into CA DLP.tar. Before running an import