Technical Article
DriveLock Database Guide
Database Maintenance and Configuration
DriveLock SE 2017
DriveLock Database Guide
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
DriveLock Database Guide
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.
DriveLock Database Guide
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.
DriveLock Database Guide
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.
DriveLock Database Guide
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
DriveLock Database Guide
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.
DriveLock Database Guide
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
DriveLock Database Guide
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.
DriveLock Database Guide
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.
DriveLock Database Guide
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:
01_CreateDatabase.sql
02_CreateSchema.sql
03_CreateSchemaRelationships.sql
04_CreateStoredProcs.sql
MS SQL database (event database). Please note the tenant and event database naming conventions:
01_CreateDatabase.sql
02_CreateSchema.sql
03_CreateSchemaRelationships.sql
04_CreateStoredProcs.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:
Ora_01_CreateUser.sql
DriveLock Database Guide
11
Ora_02_CreateSchema.sql
Ora_04_CreateStoredProcedures.sql
Oracle database (event database user). Please note the tenant and event database naming conventions:
Ora_01_CreateUser.sql
Ora_02_CreateSchema.sql
Ora_04_CreateStoredProcedures.sql
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).
DriveLock Database Guide
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.
DriveLock Database Guide
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.
DriveLock Database Guide
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.
DriveLock Database Guide
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
DriveLock Database Guide
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.
DriveLock Database Guide
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.
DriveLock Database Guide
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
DriveLock Database Guide
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.
DriveLock Database Guide
20
C database
DriveLock DriveLock-DATA
Tenant database (DriveLock_Tenant1)
Tenant event database (DriveLock_Tenant1-DATA)
ctsp_groomevents x x
ctsp_groomeventsbysize x x
ctsp_maintenance x x x x
ctsp_backup x x x x
ctsp_shrink x x x x
DriveLock Database Guide
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
)
ctsp_groomevents x x
ctsp_maintenance x x x x
DriveLock Database Guide
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.
DriveLock Database Guide
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).
DriveLock Database Guide
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).
DriveLock Database Guide
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.
DriveLock Database Guide
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
DriveLock Database Guide
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.
DriveLock Database Guide
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.
DriveLock Database Guide
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:
DriveLock Database Guide
30
Job Step for maintenance:
Click “OK” to save the Job Steps.
DriveLock Database Guide
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.
DriveLock Database Guide
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.