DriveLock Database Guide - DriveLock Database Guide.pdf · DriveLock Database Guide 2 1...

Technical Article

DriveLock Database Guide

Database Maintenance and Configuration

DriveLock SE 2017


1

Contents

1 INTRODUCTION ................................................................................................................................................... 2

1.1 PURPOSE OF THIS DOCUMENT .................................................................................................................................... 2

1.2 DOCUMENT CONVENTIONS ....................................................................................................................................... 3

2 DRIVELOCK DATABASE STRUCTURE ..................................................................................................................... 4

2.1 WHY TWO DRIVELOCK DATABASES? ............................................................................................................................ 4

2.2 DATABASE SECURITY ................................................................................................................................................ 5

2.2.1 Microsoft SQL Server ...................................................................................................................................... 5

2.2.2 Oracle ............................................................................................................................................................. 6

2.3 TENANT DATABASES ................................................................................................................................................. 7

2.4 CONSIDERATIONS REGARDING AGENT CONFIGURATION ................................................................................................... 8

3 DATABASE INSTALLATION AND UPDATE ............................................................................................................. 9

3.1 DATABASE INSTALL WIZARD ...................................................................................................................................... 9

3.2 MANUAL DATABASE INSTALLATION ........................................................................................................................... 10

3.3 MANUAL DATABASE UPDATE.................................................................................................................................... 13

3.4 MANUAL SETTING OF CONNECTION PARAMETERS .......................................................................................... 14

4 DATABASE MAINTENANCE ................................................................................................................................ 15

4.1 MAINTENANCE ON MS SQL (FULL VERSION): ............................................................................................................. 17

4.2 MAINTENANCE ON MSSQL (EXPRESS VERSION): ...................................................................................................... 19

4.3 MAINTENANCE ON ORACLE: .................................................................................................................................... 21

4.4 STORED PROCEDURES FOR MAINTENANCE................................................................................................................... 22

4.4.1 ctsp_maintenance ........................................................................................................................................ 22

4.4.2 ctsp_groomevents .................................................................................................................................... 23

4.4.3 ctsp_groomeventsbysize .......................................................................................................................... 24

4.4.4 ctsp_shrink ................................................................................................................................................ 26

4.5 RECOMMENDED STORED PROCEDURE EXECUTION ORDER ............................................................................................... 26

5 APPENDIX .......................................................................................................................................................... 27

5.1 EXAMPLE OF CONFIGURING A MAINTENANCE JOB (MS SQL SERVER) ............................................................................... 27

5.1.1 Creating a new job........................................................................................................................................ 28


2

1 Introduction

1.1 Purpose of this document

This documentation is a guide to the DriveLock database and is intended to be a knowledgebase source to DriveLock

and database administrators.


3

1.2 Document Conventions

Throughout this document the following conventions and symbols are used to emphasis important issues that you

should read carefully or menus, items or buttons you have to click on or select.

Caution: This symbol means that you should be careful to avoid unwanted results, such as potential damage to operating system functionality or loss of data

Hint: Useful additional information that might help you save time.

Information: Additional information about the current topic

italic

Italics represent fields, menu commands, and cross-references.

C:\>command

A fixed-width typeface represents messages or commands typed at a command prompt.

Next

Bold type represents a button that you need to click.

ALT + R

A plus sign between two keyboard keys means that you must press those keys at the same time. For example, ALT+R means that you must hold down the ALT key while you press R.

ALT, R, U

A comma between two or more keys means that you must press them consecutively. For example ‘ALT, R, U’ means that you must first press the Alt key, then the R key, and finally the U key.


4

2 DriveLock Database structure

2.1 Why two DriveLock databases?

The DriveLock Enterprise Service requires two DriveLock databases to run. The main database, usually called

“DriveLock” contains configuration and metadata as well as persistent data. In detail these are:

DriveLock Enterprise Service configuration data

Hard- and software inventory data

Recovery data for encryption (FDE, DLV, DFP)

Centrally managed DFP folder data

Accounts and permissions for DCC and MMC

DriveLock Control Center stored reports and statistics

Helpdesk data (current state of client computers)

License data

Antivirus metadata

Software package distribution metadata

Schedules

The event database, usually called “DriveLock-DATA”, only contains event data. The event data may be anonymized

or encrypted depending on the DriveLock client configuration. In order to have no link to the helpdesk data to

backtrack anonymized data, the DriveLock event data was separated into a second database. For easier

maintainability, the database schema was cloned.

The database schema and the DriveLock database version are identical for both databases. The version

can be looked up in the “Info” table in either database.


5

2.2 Database Security

2.2.1 Microsoft SQL Server

DriveLock uses Windows Authentication to connect to the databases. SQL authentication is not supported.

The DriveLock Enterprise Service runs under the Windows account that was selected during installation. This account

requires a login to the SQL Server, which is linked to a user to the DriveLock database. There are two typical security

configurations:

2.2.1.1 The DriveLock Enterprise Service is installed by an administrator account

In this case, the administrator will become the database owner of both DriveLock databases. The installation will

create a login for the DriveLock Enterprise Service windows account and link it to a new database user

“DriveLockUser” on the DriveLock database.

The following permissions will be set for this user:

db_backupoperator – in order to execute backups if desired (mostly on SQL Express)

db_datareader – to read data

db_datawriter – to write data

db_ddladmin – to make schema changes if needed

db_securityadmin – to make security changes if needed

srcsystem – role created by DriveLock to handle permissions on stored procedure execution


6

The DriveLock Enterprise Service is installed by the windows account that will also run the service

In this case, the DriveLock Enterprise Service account becomes dbo of the DriveLock databases, hence has all

permissions on the database.

The DriveLock Enterprise Service account needs to be dbo of the database if the “shrink database” feature is

used (mostly used on SQL Express).

2.2.2 Oracle

On Oracle SQL server, the DriveLock Enterprise Service uses the database users DRIVELOCK and DRIVELOCK_DATA

to access the tablespaces. The users each require connect and resource role membership.

During the installation the selected Oracle user will be used to perform the installation steps. You can choose to

either:

Create users, tablespaces and database schema

In this case the Installation has to be made by an Oracle administrator account (for example SYSTEM or an account that has permissions to create tablespaces, users and schema)

Create schema only for designated users

This will skip the user and tablespace creation and only install the schema. In this case a user who can access the tablespaces of both the DRIVELOCK and the DRIVELOCK_DATA user is sufficient to perform the installation.


7

2.3 Tenant databases

Tenant databases are added for each new tenant in order to strictly separate the data of each tenant. By default,

the DriveLock Database Service runs under a “root” tenant. All tenants have the same database schema and version

as the base DriveLock database.

For each additional tenant, a new DriveLock and DriveLock-DATA database will be created. The naming convention

for this is:

<DriveLock database name>_<tenant name>

For example DriveLock_tenant1

Each tenant also has an event database, the naming convention for it is:

<DriveLock database name>_<tenant name>_<event database postfix>

For example: DriveLock_tenant1-DATA


8

2.4 Considerations regarding agent configuration

The database size and growth depends a lot on the DriveLock agent configuration.

Event reporting

Event reporting is the most important configuration to consider, as it hard to estimate the number of incoming events. There are some features in DriveLock that can generate a huge amount of events, for example file auditing (reporting of file filter events). Please refer to the DriveLock DB Sizing document for more details. Consider which events need to be collected and reported.

Hard & Software inventory

This depending on the number and configuration of the computers. Once the inventory has been generated, the size will only change marginally, as the hardware and the software of the computers change.

Centrally stored policies

These are stored directly in the database. A lot of different large policies with many version can use up some space, however this is foreseeable. For example when a complex policy uses up 5MB of space, then a new version of it will require roughly additional 5MB of space in the database.


9

3 Database installation and update

The database installation is done by the Database Install Wizard, which will be installed with the DriveLock Enterprise

Service.

Before performing any operation on the DriveLock databases, please create backups.

3.1 Database Install Wizard

Please refer to the DriveLock installation guide document.

The SQL scripts that were used for the database installation and upgrades are located in the following directory:

%PROGRAMFILES%\CenterTools\DriveLock Enterprise Service\Database\<Database type>\Install_<database

name>

The name of the DriveLock database, as well as the postfix for the event database can be set with the Database

Install Wizard.


10

3.2 Manual database installation

If, for any reasons, it is not possible to use the Database Install Wizard, then the database can still be installed

manually.

The installation script templates can be found in the directory (MSSQL/Oracle respectively):

%PROGRAMFILES%\CenterTools\DriveLock Enterprise Service\Database

In general, each of the scripts will need to be edited to replace placeholders like for example database name or the

DriveLock Enterprise Service account name. The placeholders are listed at the top of each script and are enclosed in

“%”. Please use find/replace to edit the scripts and replace all placeholders in the script, for example %DRIVELOCK%

would be replaced with DriveLock (or the desired database name). All placeholders need to be replaced.

The scripts need to be executed in the following order:

MS SQL database (main database)

01_CreateDatabase.sql

02_CreateSchema.sql

03_CreateSchemaRelationships.sql

04_CreateStoredProcs.sql

05_CreateDccAdmin.sql (main database only)

MS SQL database (tenant database). Please note the tenant database naming conventions:


02_CreateSchema.sql



MS SQL database (event database). Please note the tenant and event database naming conventions:


02_CreateSchema.sql



06_MigrateEventDatabase.sql

Oracle database main database user):

Ora_01_CreateUser.sql

Ora_02_CreateSchema.sql

Ora_04_CreateStoredProcedures.sql

Ora_05_CreateDccAdmin.sql (main database only)

Oracle database (tenant database user). Please note the tenant database naming conventions:



11



Oracle database (event database user). Please note the tenant and event database naming conventions:




Ora_06_MigrateEventDatabase.sql (event database only)

Please note that the scripts will only install one database at once. Make sure to execute the correct scripts for each

database (main or event database, with or without tenant).


12

After installing all databases, the event databases need the following marked entries in the Info table. This needs to

be edited for each event database. Oracle databases also need these entries respectively.

The client entry will identify the tenant (default root).

The EventDb entry will mark this database as event database.


13

3.3 Manual database update

Similar to the manual database installation, the database can be updated manually as well.

The script templates are located in the directory (MSSQL/Oracle respectively):

%PROGRAMFILES%\CenterTools\DriveLock Enterprise Service\Database

To determine the version of the actually installed DriveLock database, please view the content of the “Info” table in

the DriveLock (and DriveLock-DATA) database.

After determining the version of the database, all update scripts starting from that version need to be edited,

placeholders replaced and executed in order.

The update scripts are named Update_<source version>_<target version>.sql

Example: In order to update from DriveLock 7.0 (database Version 7.0.0.18) to DriveLock 7.2 (database

Version 7.2.0.11) you would need to execute all scripts from

Update_7.0.0.18-7.1.0.1.sql

Update_7.1.0.1-7.1.0.2.sql

… to …

Update_7.1.0.11-7.1.0.12.sql

Caution: The version of all DriveLock databases, this includes event and tenant databases, need to be

identical. In the case of a manual update, all databases must be updated.


14

3.4 Manual setting of connection parameters

The DriveLock Enterprise Service uses registry keys to specify the connection parameters to the database. The keys

are located in the windows registry at Computer\HKEY_LOCAL_MACHINE\SOFTWARE\CenterTools\DES

dbServer: the Instance name of the SQL Server or the TNS name of the Oracle server

dbName: the name of the main DriveLock database (or username in case of Oracle), default: DriveLock

dbPostFix: the postfix used for the name of the DriveLock event database. The resulting name for the database is <dbName><dbPostfix>. Default: -DATA (and _DATA for Oracle)

dbType: MSSQL or ORACLE

dbPwdOracle: encrypted password (AES) of the Oracle DriveLock user. This can be set by the Database Install Wizard.

The DriveLock Enterprise Service will create registry keys if they are missing.


15

4 Database Maintenance

The maintenance of the database has two main tasks:

Ensure performance despite of growth The performance of searching and reading data highly depends on indexes. Database indexes should be defragmented at regular intervals.

Limit database growth To limit database growth, event data must be deleted at regular intervals. This is referred to as database grooming. Events meeting the specified condition and references to these events in corresponding entity tables are removed during this operation.

Maintenance of the DriveLock database is performed by stored procedures that are installed with each DriveLock

database:

ctsp_maintenance This handles the rebuilding/defragmenting of the database indexes and should run on all DriveLock databases

ctsp_backup Optional for local SQL Express databases to perform automated backups

ctsp_shrink Optional for SQL Express databases to shrink the database after backup

ctsp_groomevents Default groom events job: deletes events older than specified age in days

ctsp_groomeventsbysize Optional groom events job to keep the database size under the specified MB. This is meant to be used with SQL Express


16

These stored procedures are either directly started by the DriveLock Enterprise Service, or can be configured to run

directly on the SQL server in a scheduled job. If possible, it is always recommended to run these tasks directly on the

SQL server.

Maintenance schedules should be configured to run at times of low database activity. During maintenance, the

database is still functional and accessible, but query performance may decrease and timeouts are more likely to

occur.


17

4.1 Maintenance on MS SQL (full version):

On a full MS SQL server, it is recommended to run the maintenance tasks as jobs directly on the server. In this case,

the tasks running from the DriveLock Enterprise Service have to be deactivated:

Backups should be implemented for all databases, just like for all existing other databases on the server.

Shrinking is usually not necessary on a full MS SQL server.

Once the DriveLock Enterprise Service is running in production mode for a while, and the grooming of old event data

starts showing effect, the database sizes should be stable.

The following table shows the recommended setup of the stored procedures, and on which databases they should

run.


18

Stored procedure database

DriveLock DriveLock-DATA

Tenant database (DriveLock_Tenant1)

Tenant event database (DriveLock_Tenant1-DATA)

ctsp_groomevents x x

ctsp_groomeventsbysize

ctsp_maintenance x x x x

ctsp_backup

ctsp_shrink


19

4.2 Maintenance on MSSQL (EXPRESS version):

As the SQL Agent is not available on MS SQL EXPRESS editions, it is necessary that the tasks are executed by the

DriveLock Enterprise Service.

It is your choice if you want to delete old event data depending of the age of the events or by the size of the

database, both are valid configurations for SQL EXPRESS.

Note that the backup path has to be accessible by both the SQL Server and the DriveLock Enterprise Service.

The DriveLock Enterprise Service will manage the number of backups kept. Old backups will be deleted.


20

C database

DriveLock DriveLock-DATA

Tenant database (DriveLock_Tenant1)

Tenant event database (DriveLock_Tenant1-DATA)


ctsp_groomeventsbysize x x


ctsp_backup x x x x

ctsp_shrink x x x x


21

4.3 Maintenance on Oracle:

On Oracle databases, only the event grooming (by age of events) and the database maintenance is supported.

Just like with full MS SQL servers, it is recommended to turn off the maintenance tasks in the DriveLock Enterprise

Service and set up jobs to manually trigger these on database level.

Please contact your Oracle administrator to set up jobs for event grooming, database maintenance and regular

backups.

Stored procedure database

DRIVELOCK DRIVELOCK_DATA

Tenant database (DRIVELOCK _Tenant1)

Tenant event database (DRIVELOCK _Tenant1_DATA

)




22

4.4 Stored procedures for maintenance

4.4.1 ctsp_maintenance

This stored procedure handles the maintenance of indexes in the DriveLock database. Example: To start the

ctsp_maintenance stored procedure, use the following command in T-SQL:

EXEC ctsp_maintenance

This stored procedure has no parameters and works for all DriveLock databases.


23

4.4.2 ctsp_groomevents

This stored procedure deletes events that are older than a specified number of days. During this operation, events

meeting the specified condition and references to these events in corresponding entity tables are removed.

Example To start the ctsp_groomevents stored procedure and delete all events older than 30 days, use the following

command in T-SQL:

EXEC ctsp_groomevents 30

This stored procedure works for all DriveLock event databases.

The only parameter is an INT that specifies the maximum age of events in days.

Only use this stored procedure on the event database (for example DriveLock-DATA).


24

4.4.3 ctsp_groomeventsbysize

This stored procedure estimates the amount of events in the database related to the database size, determines a

maximum age of events depending on the calculated values and deletes events that are older than the calculated

age. The amount of events that will be deleted depends on how much the target database size was exceeded. In

the long run, this should lead to a stable database size that will oscillate around the target database size.

Note that this is no guarantee that the size will not be exceeded and be aware of the SQL Server EXPRESS edition

database size limits.

During this operation, events meeting the specified condition and references to these events in corresponding entity

tables are removed.

Example: to start the ctsp_groomeventsbysize stored procedure, use the following command in T-SQL:

EXEC ctsp_groomeventsbytime 2048

In this case, the target database size would be 2048MB = 2GB.

This stored procedure works only for MS SQL databases.

The only parameter is an INT that specifies the target size of the database in MB.

Only use this stored procedure on the event database (for example DriveLock-DATA).


25

ctsp_backup

This stored procedure creates a full backup of the database. The backup will be stored in the designated folder, the

backup file name contains the database name and a timestamp.

This stored procedure is not meant to be called manually or by a job, but by the DriveLock Enterprise

Service, which will also manage the maximum number of available backups. It is intended for use on local

SQL Express servers, where the SQL Agent is not available. On full SQL Servers, please contact your database

administrator to create a backup job.

This stored procedure works only for MS SQL databases.

The only parameter is an NVARCHAR that specifies the backup path. The filename will be automatically appended

by the stored procedure.


26

4.4.4 ctsp_shrink

This stored procedure will shrink the database and release the free space from the database files, hence reducing

the database file size.

This stored procedure is not meant to be called manually or by a job, but by the DriveLock Enterprise

Service, It is intended for use on local SQL Express servers, where the SQL Agent is not available.

Database shrinking can only be started by a database sysadmin or the database owner. The DriveLock Enterprise

Service account must be the owner of the database, otherwise this stored procedure will fail.

This stored procedure has no parameters and works only for MS SQL databases.

4.5 Recommended stored procedure execution order

It is recommended to execute the maintenance stored procedures in the following order:

Event grooming (either by age of events or database size) This should always be the first step in the maintenance jobs.

Database index maintenance Execute this after event grooming.

Database backup This will also free up unused space in the database logs

Database shrinking


27

5 Appendix

5.1 Example of configuring a maintenance job (MS SQL Server)

This is an example on how to set up a maintenance job using Microsoft SQL Server Management Studio. Maintenance

jobs in SQL Server can have many additional features (for example, e-mail notification if a job fails), but these are

beyond the scope of this document. For additional information about these features, refer to the Microsoft SQL

Server and Microsoft SQL Server Management Studio documentation. Maintenance jobs can also be implemented

using the SQL Server maintenance plans feature.

The following example describes how to configure a maintenance job using the Microsoft SQL Server Agent.

Database maintenance jobs require that the SQL Server Agent service is running.


28

5.1.1 Creating a new job

Right-click Jobs and then click New Job.

Type the job name and then select Database Maintenance as the category. The owner of the job needs to have

permission to read/write data and to defragment indexes.


29

Creating job steps

On the Steps page, add a new Job Step. Type a name for the step, select “Transact-SQL script (T-SQL)” as the type,

select the DriveLock database and type the command that will be executed each time the step is executed. Create

one job step for “event grooming” and second one for “database maintenance”.

Job Step for event grooming:


30

Job Step for maintenance:

Click “OK” to save the Job Steps.


31

Creating a schedule

On the Schedules page, add a new schedule. Type a name for the schedule and then configure the frequency,

execution time and start date of the job.

Click “OK” to create the schedule and again “OK” to finalize the creation of the job.


32

Copyright

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user.

© 2017 DriveLock SE. All rights reserved.

DriveLock and others are either registered trademarks or trademarks of DriveLock SE or its subsidiaries in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

DriveLock Database Guide - DriveLock Database Guide.pdf · DriveLock Database Guide 2 1...

Documents

Transcript of DriveLock Database Guide - DriveLock Database Guide.pdf · DriveLock Database Guide 2 1...