1C:ENTERPRISE8.

3
Client/server
mode
Administrator
guide

Moscow
1C Company
2019
 THE COPYRIGHT FOR
SOFTWARE AND DOCUMENTATION REPLICATION
BELONGS TO "1C" COMPANY
By purchasing "1C: Entreprise" system you agree to
avoid software and documentation copying
without "1C" company written approval.
© 1C-Soft LLC, 1996 - 2018
1C Company, Moscow, 123056, P.O. box 64, Russia
Sales department: Seleznevskaya st., 21
Phone: +7 (495) 737-92-57
Fax: +7 (495) 681-44-07,
Email: [email protected]
URL: https://1c-dn.com
Product development group- A. Abasov, A. Akimov, R. Aleynikov, A. Alekseev, V.
Andryuschenko, Ya. Batura, M. Begletsov, A. Bezborodov, A. Belyak, D.
Beskorovainov, E. Bobrova, A. Bushnev, P. Vasilets, A. Vinogradov, Ya.
Virkovsky, A. Volkov, I. Golshtein, E. Gornostaev, N. Grebnev, A. Gudnev, S.
Guriev, I. Gusarov, G. Damie, A. Darovskikh, O. Derut, M. Dzjuba, I. Dju-
plischev, N. Evgrafov, B. Evtifeev, A. Zabelinsky, D. Zadorin, I. Zapletnev, D.
Zaretsky, D. Ivashov, A. Kaganovich, M. Kamnev, K. Karmakulov, E. Kirya-
kov, A. Kovalev, Ya. Kovalev, I. Kovalenko, A. Kozhevnikov, S. Kopienko, N.
Korsakov, S. Kravchenko, V. Kudryavtsev, P. Kukushkin, A. Kulinich, A. Kun-
chenko, V. Kupriyanov, R. Kuskov, A. Lakutin, M. Leibovich, G. Leontiev, A.
Lekhan, A. Makeev, S. Malachiev, A. Malyshenok, S. Martynenko, A. Matveev,
A. Machnev, A. Medvedev, D. Mezhuev, S. Melnikov, E. Mitroshkin, A. Moi-
seev, S. Murzin, M. Mukhin, A. Nasibullin, A. Nuraliev, S. Nuraliev, S. Olen-
chuk, L. Onuchin, I. Orlov, M. Otstavnov, D. Pavlenko, I. Pivkin, V. Piskarev,
A. Plyakin, P. Romanov, A. Rukin, D. Rusanov, M. Sablin, E. Silin, S. Sitnikov,
D. Sluzhbin, A. Smirnov, E. Smirnov, Y. Smirnov, A. Sobolev, V. Sokolov, P.
Solodky, A. Solyanik, V. Sosnovsky, E. Storozhenko, G. Suaridze, S. Suvorov,
D. Sysoenkov, S. Sychev, D. Tishkov, A. Toporkov, A. Tretyakevich, A. Tro-
fimchuk, A. Trubkin, V. Tunegov, A. Tyushkin, V. Filippov, A. Khasanov, T.
Khusaenov, A. Tsilyabin, V. Cheskis, V. Cheremisinov, P. Chikov, A.
Chicherin, A. Chkadua, P. Churbanov, S. Shvets, A. Shevchenko, M. Shirokov,
V. Shulga, A. Scherbinin, A. Edemsky.

QA group: D. Askandarova, A. Akhramenko, S. Batalin, A. Belyakov, D. Borschev,

A. Galochkin, B. Ziatdinov, A. Lapin, E. Medvedev, I. Mikheichev, S. Mustae-
va, S. Potapkin, A. Sanarov.

Book title: 1C:Enterprise 8.3. Client/server mode Administrator

guide.
Edition number: 83.005.16.03
Publication date: 05 November 2019
 TECHNICAL SUPPORT LINE

When you dial the hot line, ensure that you are not far from your computer and you
have this guide and your registration card with you. Be prepared to provide the sup-
port representative with the brand and technical specifications of your computer and
printer.
When you dial the hot line, you will be connected with a technical specialist. Be
ready to provide the name of your company, your software version number (it can be
found on the software distribution CD and on your registration card) and other regis-
tration information. The information that you provide will be verified against the
registration form that you sent to 1C Company.
The technical support specialist might attempt to reproduce your situation on their
computer. They might provide the solution immediately or consult software devel-
opers. Do not worry about contacting a specific expert: we guarantee that all our
support specialists are highly trained. The log of all support calls is maintained, so
when calling about a previous issue you can refer to the date and time of your previ-
ous call.
WE ARE ALWAYS HERE TO HELP YOU!
Contents
Introduction 1
Overview ........................................................................................................... 1
What you need to know ................................................................................. 1
Books included in the documentation........................................................... 1
Update and migration notes delivered with1C:Enterprise ....................... 2
Agreed notations ............................................................................................. 2

Chapter 1. System and hardware requirements............. 5

1.1. Server x32 ............................................................................................. 5
1.2. Server x64 ............................................................................................. 6
1.2.1. Requirements to servers designed for servers cluster
operation............................................................................................ 6
1.2.2. Requirements for Data accelerator operation............................... 7
1.3. Client/server mode common requirements ...................................... 8
1.3.1. General requirements ...................................................................... 8
1.3.2. User rights ......................................................................................... 8
1.3.3. Linux OS mandatory libraries .......................................................... 9
1.4. Power-saving modes.......................................................................... 10
1.5. Supported DBMS ................................................................................ 10

Chapter 2. Client/server mode ........................................ 16

2.1. Overview .............................................................................................. 16
2.2. Server cluster structure ..................................................................... 18
2.2.1. General concepts ............................................................................ 18
2.2.2. Interaction between client application and server
cluster............................................................................................... 21
2.2.3. Cluster services ............................................................................... 24
2.2.4. Sessions and connections .............................................................. 27
2.2.5. Failover cluster ................................................................................ 36
2.2.6. Server cluster scalability ................................................................ 44
2.2.7. Cluster load balancing .................................................................... 44
2.2.8. Security profiles .............................................................................. 57
2.2.9. Server cluster security ................................................................... 68
2.2.10. Infobase locks ................................................................................. 76
2.2.11. Working process load statistics..................................................... 78
2.2.12. Cluster monitoring system............................................................. 79
2.2.13. Location of cluster manager service files .................................... 80
2.3. Running under Linux .......................................................................... 81

Chapter 3. Installing system components ..................... 83

3.1. Installing 1C:Enterprise server ......................................................... 83
3.1.1. General information on installation procedure ........................... 83
 3.1.2. Windows Installer ........................................................................... 84
3.1.3. Typical 1C:Enterprise installation scenarios ................................ 93
3.1.4. Data accelerator settings ............................................................... 97
3.1.5. Installing and configuring additional software ............................ 98
3.2. Installing database servers.............................................................. 105
3.2.1. Installing IBM DB2 ........................................................................ 105
3.2.2. Installing Microsoft SQL Server ................................................... 106
3.2.3. Installing Oracle Database ........................................................... 107
3.2.4. Install PostgreSQL......................................................................... 109

Chapter 4. Running system components .................... 111

4.1. General information .......................................................................... 111
4.2. Running the server agent ................................................................ 112
4.2.1. General information ...................................................................... 112
4.2.2. On Windows................................................................................... 113
4.2.3. On Linux ......................................................................................... 118
4.3. Collaboration between server processes ....................................... 123
4.3.1. General information ...................................................................... 123
4.3.2. On Windows................................................................................... 124
4.3.3. On Linux ......................................................................................... 129

Chapter 5. Administration .............................................. 131

5.1. Infobase administration ................................................................... 131
5.1.1. Backup in Client/Server Mode ..................................................... 131
5.1.2. Converting infobases for use in client/server mode ................. 133
5.2. Server cluster administration .......................................................... 134
5.2.1. General information ...................................................................... 134
5.2.2. Running the administration utility............................................... 134
5.2.3. Registering an instance of a working server ............................. 136
5.2.4. Operations with list of central server administrators ............... 139
5.2.5. Operations with list of clusters .................................................... 143
5.2.6. Operations with list of working servers in cluster .................... 148
5.2.7. Operations with list of infobases ................................................. 157
5.2.8. Operations with list of cluster administrators ........................... 162
5.2.9. Viewing list of cluster managers ................................................. 166
5.2.10. Viewing a list of working processes ............................................ 167
5.2.11. Operations with list of sessions ................................................... 171
5.2.12. Operations with list of connections ............................................ 179
5.2.13. Operations with list of locks ........................................................ 189
5.2.14. Operations with list of security profiles ...................................... 193
5.2.15. Operations with resource management mechanism ................ 198
5.3. Server cluster administration software .......................................... 204
5.3.1. Using 1C:Enterprise language to access server
clusters ........................................................................................... 204
5.3.2. External session management .................................................... 207
5.3.3. Server cluster administration server ........................................... 219
5.4. Database administration .................................................................. 224
Chapter 6. Deleting the application .............................. 229
6.1. Deleting a cluster of servers under Windows ............................... 229
6.2. Uninstalling a server cluster for Linux ........................................... 229

Appendix 1. License description string format .............. 231

Appendix 2. New and modified sections ........................ 235
Introduction

This manual is intended for 1C:Enterprise administrators. It describes how

to manage 1C:Enterprise 8 in the client/server mode.

Overview
Chapter 1 contains system requirements for 1C:Enterprise 8 server deploy-
ment and operation
Chapter 2 client/server mode features
Chapter 3 1C:Enterprise 8 server deployment
Chapter 4 1C:Enterprise 8 server startup
Chapter 5 1C:Enterprise 8 client/server mode administration features
Chapter 6 1C:Enterprise 8 removal
IMPORTANT! https://its.1c.ru/db/v83doc - bookmark:adm

What you need to know

It is assumed that you are familiar with the operating system of the comput-
er where 1C:Enterprise is installed (Microsoft Windows or Linux),
https://1c-dn.com/library/system_requirements), and possess basic skills of
work in it.
You also need basic operating system administration skills.
Some administration processes might require administrative access rights
and operation system distribution package.

Books included in the

documentation
The documentation package includes the following books:
• 1C:Enterprise 8.3. User Manual (https://1c-
dn.com/library/user_manual/).https://its.1c.ru/db/v83doc - book-
mark:usr Describes the basic concepts and features that are common
for all 1C:Enterprise applications.
• 1C:Enterprise 8.3. Developer Guide (https://1c-
dn.com/library/developer_guide/).https://its.1c.ru/db/v83doc - book-
 mark:dev Describes how to customize applications to automate ac-
counting procedures in a specific company, as well as how to develop
new applications.
• 1C:Enterprise 8.3. Administrator Guide (https://1c-
dn.com/library/administrator_guide_full/).https://its.1c.ru/db/v83doc -
bookmark:adm Describes 1C:Enterprise administration, including the
deployment of client/server systems.
• 1C:Enterprise 8.3. Client/server mode Administrator Guide
(https://1c-
dn.com/library/administrator_guide/).https://its.1c.ru/db/v83doc -
bookmark:cs Describes how to deploy and operate 1C:Enterprise 8 in-
fobases in client/server mode.
• The object model is described in the online help (Designer help and
Syntax Assistant).
IMPORTANT! Some software distribution packages might not include
some of these books.

Update and migration

notes delivered
with1C:Enterprise
The 1C:Enterprise installer copies several text files that list the changes
implemented in the platform version and instructions for migration to this
platform version to the hard disk.
These files are located in the 1C:Enterprise installation directory, in the
\docs\en subdirectory. If you do not change the default installation path,
they will be located in C:\Program Files\1cv8\<version num-
ber>\docs\en. For example, the path for version 8.3.3.100 is as follows:
C:\Program Files\1cv8\8.3.3.100\docs\en.
• The file V8Update.htm - contains the list of changes and migration
instructions.

Agreed notations

Keys. Keys Enter, Esc, Del and others are given without quotation marks.
 The Arrow keys phrase is used to specify all arrow keys at once. They are
referred individually as Up Arrow, Down Arrow, Right Arrow, and Left
Arrow.
Keyboard shortcuts. When a command requires a keyboard shortcut it will
be stated as Ctrl + F3.
Buttons. Form buttons are given without quotation marks, like OK, Cancel,
Delete and others.
1C:Enterprise language keywords. 1C:Enterprise language keywords are
highlighted by specific font and are given as in modules, for example:
WorkingDate. This manual contains references to some parts of
1C:Enterprise language description (sections, methods, attributes and oth-
ers). For these descriptions, see the application help (1C:Enterprise lan-
guage section).
Menu actions. The menu actions are described as follows: Menu - Sub-
menu - Submenu - … - Menu item. Example: "Use Table - View -
Scope to change the scope of the picture" means: "Use the Scope item of
the View submenu of the Table menu of the application's main menu". If
any menu, other than the main menu, is referred, it is specified explicitly.
1C:Enterprise modes. 1C:Enterprise can run in two modes: configuration
setup and verification (hereinafter - Designer), and configuration execution
(hereinafter - 1C:Enterprise mode).
In the context of this manual, "user" means an expert participating in appli-
cation development or maintenance.
The %SYSTEMROOT% expression means the operating system envi-
ronment variable with the operating system installation directory. If the op-
erating system was installed using default settings, this expression equals to
C:\Windows

The %USERPROFILE% expression means the Windows environment

variable with the current user profile directory. If the operating system was
installed using default settings and the user name is Ivanov, this expression
equals to
C:\Documents and Settings\Ivanov

For Windows Vista and higher:

C:\Users\Ivanov

The %APPDATA% expression means the Windows environment variable

with the current directory containing application data. If the operating sys-
tem was installed using default settings and the user name is Ivanov, this
expression equals to
C:\Documents and Settings\Ivanov\Application Data

For Windows Vista and higher:

C:\Users\Ivanov\AppData\Roaming

The %LOCALAPPDATA% expression means the Windows Vista envi-

ronment variable with the current directory for user-specific application
data. If the operating system was installed using default settings and the
user name is Ivanov, this expression equals to
C:\Users\Ivanov\AppData\Local

The %ALLUSERSPROFILE% expression means the Windows envi-

ronment variable with the directory, available for every user. When the op-
erating system was installed using default settings, this expression equals to:
C:\Documents and Settings\All Users

For Windows Vista and higher:

C:\ProgramData

The %PROGRAMFILES% expression means the Windows environment

variable with the directory containing data files of applications whose bit-
ness equals to operating system bitness. If the operating system was in-
stalled using default settings, this expression equals to
C:\Program Files

The %PROGRAMFILES(x86)% expression means the Windows envi-

ronment variable with the directory containing data files of applications
whose bitness is not eaual to operating system bitness. In other words, this
environment variable contains a link to the directory where x32 applications
are stored in the x64 operating system. If the operating system was installed
using default settings, this expression equals to
C:\Program Files (x86)

All files that have the same name in Windows and Linux will also have the
same name in this manual. For example the 1cestart.cfg file will be stated
as is, however in Windows it has the 1CEStart.cfg name, and in Linux -
1cestart.cfg.
Extensions of executable files are not specified (if any). This means that
1cv8.exe is mentioned as 1cv8in this manual. In Windows you should add
an .exe extension, whereas in Linux you should leave it as is.
Also, Linux is case-sensitive, and Windows is not.
Chapter 1.
System and hardware
requirements

For list of currently supported server operating systems and DBMS visit
https://1c-
dn.com/library/system_requirements/.http://www.v8.1c.ru/requirements/
NOTE. The 1C:Enterprise bitness does not depend on DBMS bitness.
1C:Enterprise server and DBMS server with different bitnesses can operate
together.

1.1. Server x32

Requirements for working servers included in 1C:Enterprise 8 server clus-
ter:
• Operating systems:
 Windows OS:
 Supported versions:
 Windows XP Service Pack 3, Vista Service Pack 2,
7 Service Pack 1, 8.0, 8.1 versions.
 Windows Server 2003, 2008 Service Pack 2 versions.
 Ensure that the latest operating system updates are downloaded
and installed.
 Linux:
 Supported versions:
 Astra Linux:
 Common Edition 1.11, 2.12.
 Special Edition 1.4, 1.5, 1.6.
 CentOS: versions 6, 7.
 Debian 8, 9.
 Mint 18, 19.
 Red Hat Enterprise Linux: versions 6, 7.
 Ubuntu 14.04 LTS, 16.04 LTS, 18.04 LTS.
  ALT Linux 6.0 SPT, 7.0 CPT, Workstation 7, Workstation
8, Workstation K 8, Server 7, Server 8, Education 8, ALT 8
SP.
• CPU: Pentium/Xeon 2,4 GHz. Multiple cores or processors are rec-
ommended because they affect the 1C:Enterprise 8 server cluster
throughput especially having many concurrent users.
• RAM: 2 GB. 1C:Enterprise 8 server cluster working processes might
require significant RAM capacity at the peak.
• USB port is required for 1C:Enterprise server cluster hardware key.
1C:Enterprise supports the following database management systems
(DBMS):
• IBM DB2.
• Microsoft SQL Server
• Oracle Database
• PostgreSQL
If you have a 32-bit operating system, use 32-bit DBMS versions (if any).
Make sure that a computer running a DBMS server - is in compliance with
requirements applicable to any relevant DBMS version described in more
detail in DBMS documentation. Bitness of DBMS server can differ from
that of 1C:Enterprise server.

1.2. Server x64

1.2.1. Requirements to servers
designed for servers
cluster operation
Requirements for working servers included in 1C:Enterprise 8 server clus-
ter:
• Operating systems:
 Windows OS:
 Supported versions:
 Windows XP Service Pack 3, Vista Service Pack 2,
7 Service Pack 1, 8.0, 8.1, 10.
 Windows Server 2003, 2008 Service Pack 2,
2008 R2 Service Pack 1, 2012, 2012 R2, 2016 versions.
 Ensure that the latest operating system updates are downloaded
and installed.
 Linux:
  Supported versions:
 Astra Linux:
 Common Edition 1.11, 2.12.
 Special Edition 1.4, 1.5, 1.6.
 CentOS: versions 6, 7.
 Debian 8, 9.
 Mint 18, 19.
 Red Hat Enterprise Linux: versions 6, 7.
 Ubuntu 14.04 LTS, 16.04 LTS, 18.04 LTS.
 ALT Linux 6.0 SPT, 7.0 CPT, Workstation 7, Workstation
8, Workstation K 8, Server 7, Server 8, Education 8, ALT 8
SP.
• CPU: x86-64 processor (Intel with Intel 64 supported, AMD with
AMD64 supported). Multiple cores or processors are recommended
because they affect the 1C:Enterprise 8 server cluster throughput es-
pecially having many concurrent users.
• RAM: 2GB (4 GB or more recommended) 1C:Enterprise 8 server
cluster working processes might require significant RAM capacity at
the peak.
• USB port is required for 1C:Enterprise server cluster hardware key.
• CD-ROM
1C:Enterprise supports the following database management systems
(DBMS):
• IBM DB2.
• Microsoft SQL Server
• Oracle Database
• PostgreSQL
If you have a 64-bit operating system, use 64-bit DBMS versions (if any).
Make sure that a computer running a DBMS server - is in compliance with
requirements applicable to any relevant DBMS version described in more
detail in DBMS documentation. Bitness of DBMS server can differ from
that of 1C:Enterprise server.

1.2.2. Requirements for Data

accelerator operation
NOTE. Available only for CORP licenses.
The computer used for Data accelerator service operation must meet specif-
ic requirements:
 • 64-bit operational system
 Microsoft Windows family: versions 7, 8, 8.1, 10 (with all in-
stalled updates).
 Microsoft Windows Server family: 2012, 2012 R2, 2016.
 OS Linux family: CentOS 6 and upper, Red Hat Enterprise Linux
7 and upper, Fedora 20 and upper, Debian GNU/Linux 8 and up-
per, Ubuntu 14.04 and upper.
• Internal storage:
 at least -64 Gb.
 recommended - 512 Gb.

1.3. Client/server mode

common requirements
1.3.1. General requirements
The network connection throughput may be crucial in case when
1C:Enterprise server cluster and database server are deployed on different
computers. Network cards with throughput of at least 1Gbit are recom-
mended to implement the following connections:
• Server cluster and computer running DBMS of the main database.
• Server cluster and computer running DBMS of a database copy -,
whenever a database copying mechanism is used.
• Server cluster computer running Data Accelerator and other comput-
ers being part of a server cluster -, whenever Data Accelerator is used.
The client application will not run on a virtual machine if the network
adapter connection is set to NAT and the 1C:Enterprise server cluster is
located on a host computer of the client virtual machine.
Recent Java 1.8-bytes version, which corresponds to "1C:Enterprise" server
bites is recommended in case of necessity to use optimized mechanism of
informational base restructuring ( in case of DBMS Microsoft SQL Server
or PostgreSQL) on the PC with "1C: Enterprise" server.
IMPORTANT! You should turn off the power-saving modes Sleep,
Standby, and Hibernate on client computers. Otherwise the 1C:Enterprise
operation in client server mode might be unstable.

1.3.2. User rights

User running server cluster processes (USR1CV8 by default):
 • General requirements:
 A user must have full rights to a directory specified in the cluster
data directory field.
• Windows OS:
 List folder contents right to a directory with temporary
files.
• Log on as a service right.
• Log on as a batch job right.
• It's part of Performance Log Users group.
• Linux:
 Read right with respect to a directory with temporary files.
Whenever swpuser.ini is used in a system, details of access rights to be
granted to users are available in the details of the said configuration file.

1.3.3. Linux OS mandatory

libraries
To use some of the features of a server running Linux, you may need to
have the following libraries:
• FreeType:
 Library name: libfreetype.
 Version: 2.1.9 or later.
 Purpose:
 For the managed mode of the 1C:Enterprise server
 When Chart, GraphicalSchema, or
SpreadsheetDocument objects are used on server
 When GetPicture() method of Chart, GanttChart,
Dendrogram, or PivotChart is used.
 When saving to PDF
• Libgsf:
 Library name: libgsf-1
 Version: 1.10.1 or later
 Purpose: Document export from and import to XLS
• Glib:
 Library name: libglib-2.0
 Version: 2.12.4 or later
 Purpose: Document export from and import to XLS
• unixOdbc:
 Library name: libodbc
  Version: 2.2.11 or later
 Purpose: operations with external data sources.
• Kerberos:
 Library name: libkrb5
 Version: 1.4.2 or later
 Purpose: OS authentication
• GSS-API Kerberos:
 Library name: libgssapi_krb5.
 Version: 1.4.2 or later
 Purpose: OS authentication
• Microsoft Core Fonts
1C:Enterprise loads the library with name specified as Li-
braryName.so.X.Y, where:
• LibraryName - one of the values listed above.
• so - library file flag.
• X.Y - current library suffix digits.
Only libraries registered in runtime dynamic linker cache can be loaded.
(You can read this information by running the ldconfig -p command). If
several versions of the library are available, the latest one will be loaded.

1.4. Power-saving modes.

Power-saving mode can be enabled with running 1C:Enterprise under the
following rules:
• You use the local dongle,
• the infobase is in the file mode,
• database file is located on the local drive.
Otherwise power-saving modes are prohibited.

1.5. Supported DBMS

1C:Enterprise supports the following DBMS:

Database management system (DBMS) x32 x64

IBM DB2
version 9.1.301.537 WL WL
version 9.5.200.353 WL WL
version 9.7.100.177 WL WL
Database management system (DBMS) x32 x64
Documentation:
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/i
ndex.jsp
version 10.1.0.872 WL WL
Documentation:
http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/
index.jsp
Version 11.1 WL WL
Documentation:
http://www.ibm.com/support/knowledgecenter/SSEPGG
_11.1.0/com.ibm.db2.luw.kc.doc/welcome.html

Microsoft SQL Server

2000 Service Pack 2 (Service Pack 4 recommended) W W
Documentation: http://msdn.microsoft.com/ru-
ru/library/aa257103
2005 Service Pack 3 W W
Documentation: http://msdn.microsoft.com/ru-
ru/library/bb418498.aspx
2008 Service Pack 1 W W
Documentation: http://msdn.microsoft.com/ru-
ru/library/bb418491.aspx
2008 R2 W W
Documentation: https://msdn.microsoft.com/ru-
ru/library/hh994726.aspx
Version 2012 W W
Documentation: http://msdn.microsoft.com/ru-
ru/library/bb418433.aspx
Version 2014 W W
Documentation: http://msdn.microsoft.com/ru-
ru/library/dd631854.aspx
Version 2016 WL
Documentation: https://msdn.microsoft.com/ru-
ru/library/ff928358.aspx
Version 2017 WL
Documentation: https://docs.microsoft.com/ru-
ru/sql/?view=sql-server-2017

Oracle Database (for a list of patches required to run these versions, see
Database management system (DBMS) x32 x64
http://v8.1c.ru/requirements/)
Version 10g R2 - 10.2.0.4 WL WL
Documentation:
http://www.oracle.com/pls/db102/homepage
Download:
http://download.oracle.com/docs/cds/B19306_01.zip
Version 11g R1 - 11.1.0.7.0 WL WL
Documentation:
http://www.oracle.com/pls/db111/homepage
Download:
http://download.oracle.com/docs/cds/B28359_01.zip
Version 11g R2 - 11.2.0.4.0 WL WL
Documentation:
http://www.oracle.com/pls/db112/homepage
Download:
http://download.oracle.com/docs/cds/E11882_01.zip
Version 12c R1 - 12.1.0.2 L L
Documentation:
http://www.oracle.com/pls/db121/homepage
Download:
http://download.oracle.com/docs/cds/database/121.zip

PostgreSQL by 1С
version 8.1.5 WL WL
Documentation:
http://www.postgresql.org/docs/8.1/static/index.html
version 8.2.4 WL WL
Documentation:
http://www.postgresql.org/docs/8.2/static/index.html
version 8.3.8 WL WL
Documentation:
http://www.postgresql.org/docs/8.3/static/index.html
version 8.4.3 WL WL
Documentation:
http://www.postgresql.org/docs/8.4/static/index.html
version 9.0.3 WL WL
Documentation:
http://www.postgresql.org/docs/9.0/static/index.html
version 9.1.2 WL WL
Database management system (DBMS) x32 x64
Documentation:
http://www.postgresql.org/docs/9.1/static/index.html
version 9.1.9 WL WL
version 9.2.4 WL WL
Documentation:
http://www.postgresql.org/docs/9.2/static/index.html
version 9.3.4 WL WL
Documentation:
http://www.postgresql.org/docs/9.3/static/index.html
version 9.4.2 WL WL
Documentation:
https://www.postgresql.org/docs/9.4/index.html
Version 9.4.5 distributed with AstraLinux Special Edition 1.5 L
version 9.4.19 WL
version 9.6.1 WL WL
Documentation:
https://www.postgresql.org/docs/9.6/index.html
Version 9.6.6 distributed with AstraLinux Special Edition 1.6
version 9.6.3 WL WL
version 9.6.5 WL WL
version 9.6.6 WL WL
version 9.6.7 WL WL
Version 10.3 WL WL
Documentation:
https://www.postgresql.org/docs/10/index.html
Version 10.5 WL WL
Version 10.8 WL WL
Version 10.9 WL WL

PostgreSQL by PostgrePro
version 9.4.19 WL
Documentation:
https://postgrespro.ru/docs/postgresql/9.4/index
version 9.6.11 WL
Documentation:
https://postgrespro.ru/docs/postgresql/9.6/index
Version 10.6 WL
Documentation:
https://postgrespro.ru/docs/postgresql/10/index
 Database management system (DBMS) x32 x64
version 10.9.1 WL
version 11.4.1 WL
Documentation:
https://postgrespro.ru/docs/postgresql/11/index

PostgresPro Standard
version 9.6.14.1 WL
Documentation:
https://postgrespro.ru/docs/postgrespro/9.6/index
Version 10.6 WL
Documentation:
https://postgrespro.ru/docs/postgrespro/10/index
version 10.9.1 WL
version 11.4.1 WL
Documentation:
https://postgrespro.ru/docs/postgrespro/11/index

PostgresPro Enterprise
version 9.6.3.1 WL
Documentation:
https://postgrespro.ru/docs/enterprise/9.6/index
version 9.6.11 WL
version 9.6.14.1 WL
version 10.3.3 WL
Documentation:
https://postgrespro.ru/docs/enterprise/10/index
Version 10.6 WL
version 10.9.1 WL
version 11.4.1 WL
Documentation:
https://postgrespro.ru/docs/enterprise/11/index
version 11.4.2 WL
The following abbreviations are used in this table:
• x32 - 32-bit product version (i386, x86).
• x64 - 64-bit product version (x86-64, x64).
• W - product supports OS Windows.
• L - product supports OS Linux.
When the Compatibility mode property is set higher than Version 8.3.7:
 • The minimal required Microsoft SQL Server DBMS version is Mi-
crosoft SQL Server 2005.
• Also an installed SQL Server Native Client for SQL Server 2005 (and
earlier Microsoft SQL Server versions) is required. Following opera-
tions check, whether the SQL Server Native Client is installed or not:
 infobase creation;
 restoring Infobase;
 database configuration update;
The SQL Server Native Client version must not be lower than the Mi-
crosoft SQL Server version.
Install Oracle Instant Client to use 1C:Enterprise. Otherwise, server cluster
cannot connect to Oracle Database DBMS.
• Oracle Instant Client version: 10.2.0.5.
• Distribution package location:
https://www.oracle.com/database/technologies/instant-
client/downloads.html (make sure that a distribution package you
download is supported by OS installed on your computer which runs
1C:Enterprise server cluster).
• During installation it is recommended to follow all installation instruc-
tions included in Oracle Instant Client package.
You can download PostgreSQL DBMS by following the below mentioned
links:
• Builds by 1C: https://1c-
dn.com/user/updates/postgresql/.https://releases.1c.ru/project/AddCo
mpPostgre
• Builds by PostgresPro: https://postgrespro.ru/products/1c.
You can download IDM DB2 DBMS distribution package supported by
your system at: https://1c-
dn.com/user/updates/ibm_db2_express_c/.https://releases.1c.ru/project/Add
CompDB2
For more information about supported DBMS (server bitness, operating
system, version numbers) visit https://1c-
dn.com/library/system_requirements/.http://v8.1c.ru/requirements/
Chapter 2.
Client/server mode

2.1. Overview
1C:Enterprise supports infobase operations in client-server mode.
1C:Enterprise client-server architecture is comprised of these software lay-
ers:
• A 1C:Enterprise client application (standard client, thin client, or web
client);
• Web server (only for web client and for thin client connected over
web server);
• 1C:Enterprise server cluster;
• database server.
See fig. 1 for the chart of interactions between system components.

Fig. 1. Interactions between system components

Client applications, thin clients and web clients -are "1C:Enterprise" (in
various launch modes), with which the end user works. To run
1C:Enterprise web client, only a web browser is required.
1C:Enterprise server cluster is a logical entity comprised of working
servers running on one or several computers, and a list of infobases stored
in the cluster.
1C:Enterprise server cluster serves as a middle software layer between the
client application and the database server. Client applications have no direct
access to the database server. To access the database, client applications
must interact with 1C:Enterprise server cluster.
The system architecture is intended to shift as much load as possible to the
server cluster while keeping the essential functionality on the client side. All
operations with applied objects, preparations before displaying command
interface and forms (reading item data from infobase, filling in the form
data, placing the items, saving the form data after change), and report gen-
eration are performed in the server cluster. The client is only responsible for
displaying information prepared in the server cluster, interacting with user,
and calling server methods required for user operations.
Files containing event logs for infobases registered on the 1C:Enterprise
server, as well as other internal-use files, are also stored on servers belong-
ing to the 1C:Enterprise server cluster. This data is not vital for routine in-
fobase operations and its loss will not result in infobase failure. Background
jobs run on the clustered servers as well.
To deploy the 1C:Enterprise server cluster, use 1C:Enterprise installer ap-
plication. To configure the server cluster, use server cluster administration
utility included in the distribution package.
1C:Enterprise server cluster hardware protection key is not network-
enabled, so you need to set it up individually on each computer running the
working processes of the cluster.
Web server is required to run web client and one of thin client variants.
When web server is used, it serves as an intermediary in data exchange be-
tween server cluster and thin or web client.
NOTE. Unless explicitly stated otherwise, "client application" means ordi-
nary client, thin client, or web client.
Database server. Database server is used to store vital 1C:Enterprise in-
fobase data in client-server mode. A variety of DBMS can serve as
1C:Enterprise database servers. Each infobase is stored in a separate data-
base of the selected DBMS.

2.2. Server cluster structure

2.2.1. General concepts
A working server is the basic unit of server cluster structure. A production
server -is a computer that is running a server agent (ragent). Server agent
represents a working server in the server cluster. Generally, one computer
hosts one working server; however, multiple working servers can run on a
single computer if required (for example, for debugging purposes). Working
servers running on the same computer must use different network ports and
different cluster data directories.
TIP. For systems in commercial operations, it is not recommended to run
multiple working servers on a single computer.
Server cluster includes one or several working servers. However, infor-
mation about how many working servers are running on a single physical
computer is not important for the purpose of describing and running the
cluster. Server agent maintains a cluster list specifying which working
server serves as central server for which cluster. The cluster list (stored in
file 1cv8wsrv.lst) contains information on server clusters that include a
specific working server, and a list of administrators of the working server.
The file is stored in the cluster data directory. Technically, the server agent
is not a component of the working server; it is rather an external utility that
ensures the working server operates normally (including representation of
the working server in the server cluster).

Fig. 2. Structure of 1C:Enterprise server

A cluster must contain at least one working server that has property Central
server enabled. An unlimited number of central servers per server cluster
can be used. All working servers in a server cluster can be marked as Cen-
tral server if necessary. A production server can be a central server in one
cluster and a normal (non-Central) -server in another cluster. Moreover, a
working server with property Central server enabled can serve as a con-
nection point for the server cluster it belongs to.
The working part of the working server includes the cluster manager
(rmngr) and the working process(rphost). Cluster manager ensures normal
operation of the working server and its interaction with other working serv-
ers within a cluster. Working process directly serves client applications,
interacts with the database server, and executes the code marked in the ap-
plication as "running on server side". Maximum number of working pro-
cesses is limited by working server settings, server cluster settings, and
hardware configuration of the computer hosting the working server.
A working server must contain at least one cluster manager. A cluster man-
ager running on the central server is called main cluster manager. Maxi-
mum number of cluster managers is equal to the number of cluster services.
However, if a working server belongs to multiple clusters at the same time,
at least one cluster manager per cluster will be created.
The main cluster manager maintains the cluster registry. The cluster regis-
try (stored in file 1cv8clst.lst) contains:
• List of infobases registered in the cluster
• List of working servers in the cluster
• List of working processes in the cluster
• List of cluster managers
• List of cluster services
• List of cluster administrators
If a cluster contains multiple central servers, each main cluster manager
maintains its cluster registry. To avoid data discrepancies, these copies of
the cluster registry are constantly synchronized between the main cluster
managers of central servers within the server cluster.
In the basic case, the working server and server cluster are hosted on the
same computer (see fig. 3).

Fig. 3. Simple cluster

2.2.2. Interaction between client
application and server
cluster
Interactions between 1C:Enterprise server cluster processes and the client
application are performed over TCP/IP. Each cluster process is addressed
using the name of a working server where it runs, and the network port
number.
While configuring a server cluster, the following default network port num-
bers are used:
• Server agent - port1540;
• Cluster manager - port 1541.
• Ports for working processes are assigned dynamically from the al-
lowed range of network ports (1560:1591 by default.)
The port numbers and range can be changed if necessary.

Fig. 4. Simple cluster

In the figure below, the name of the Central server -is 1C_Serv. Therefore,
the central server is addressed as 1С_Serv:1540. The cluster located on this
server is addressed as 1С_Serv:1541, and the working process as
-1С_Serv:1561.
Whenever the client application attempts to establish connection to the in-
fobase in client-server mode, the server cluster address is used:
1C_Serv:1541.

Fig. 5. Connecting to simple cluster

Cluster manager assigns a working process that will handle the client appli-
cation and sends its address to the client application. In this case, only one
working process is available, therefore the 1C_Serv:1561 address will be
used.

Fig. 6. Connection established

The client applications opens a connection to the working process assigned
to it, which is responsible for infobase user authentication and any further
interactions between the client application and the infobase.
IMPORTANT! For normal operation, client application version must ex-
actly match the server version. The operation of the system will be impossi-
ble if, for example, the server has version 8.3.3.100 and the client applica-
tion -version 8.3.3.150.

2.2.3. Cluster services

Functionality of server cluster manager is broken down into autonomous
services. Each service is described by specific characteristics. See below for
the list of services including brief descriptions and characteristics:

Service Description Characteristics

Object Stores pessimistic (not transac- Memory
locks tion-based) object locks. Replication
Migration+
Instancing by in-
fobases
Cluster Stores infobase lock data, infor- Replication
locks mation on active processes, and No migration
other dynamic information relat-
ed to cluster operations.
Time Supports getting timestamps in Replication
real time, as well as some auxil- Migration+
iary functions. Instancing by in-
fobases
Event Supports access to event logs. Disk
logs Migration-
Instancing by in-
fobases
Jobs Starts and monitors lifetime of Replication
background and scheduled jobs. Migration+
Cluster configura- Stores all cluster settings. No migration
tion Replication
Numbering Provides generation of unique Replication
object numbers and codes. Migration+
Instancing by in-
fobases
Full-text search Performs full-text search and Disk
indexing. Migration-
Instancing by in-
fobases
Custom settings Provides access to files storing Migration-
Service Description Characteristics
custom settings. Instancing by in-
fobases
Session Provides storage and caching of Disk
data session information, for example, Replication
information in managed applica- Migration+
tion forms. Provides client li- Instancing by in-
cense acquisition. fobases
Transaction locks Contains transaction locks for Memory
managed mode. Migration+
Instancing by in-
fobases
Debug Controls connection of debugger No migration
object to the server debug objects.
management
ODBC data source Provides interaction with exter- Memory
management nal databases over ODBC inter- Migration+
face. Instancing by in-
fobases
Licensing service Provides software license distri- Migration+
bution.
If the cluster licensing service
that had issued licenses earlier is
temporarily unavailable, this
service issues duplicate licenses
for no longer than 20 seconds.
To ensure uninterrupted license
acquisition from the licensing
service, processes rphost
and rmngr at 1C:Enterprise
server must be granted rights to
create, read, and modify data in
file 1cv8conn.pfl
OpenID provider Stores OpenID-authentification Migration-
service contexts. Instancing by in-
fobases
Database configu- Performs background database Replication
ration background restructuring. Migration+
update service Before migrating this service Instancing by in-
between cluster managers, stop fobases
all working process. The system
 Service Description Characteristics
background job must be stopped
as well. Therefore, the back-
ground update will be paused
immediately after migration.
External session Controls creation of sessions that Migration+
management ser- require client licenses. Instancing by in-
vice fobases
XMLA data source Provides interaction with OLAP Migration-
management ser- sources over XMLA interface. Instancing by in-
vice fobases
Testing service Simulates user operations at Migration-
1C:Enterprise cluster
Auxiliary cluster Manages cluster lock infor- No migration
function service mation collection.
Session reuse ser- Provides automatic pool of re- Migration+
vice. used session for Web services,
HTTP services, and OData.
Database ta- Provides unified numbering for Migration+
ble/field number- database tables and fields. Used Instancing by in-
ing service during database configuration fobases
updates that involve changes in
database structure.
Resource con- Calculates values of resource Disk
sumption counter consumption indicators. Memory
monitoring service Migration-
Data Accelerator Allows creating the copy of data Memory
service for high-speed preparation of Disk
analytical reports. Service works Migration-
together with data base copies
mechanism.
Terms used in the table:
• Disk - a resource-intensive service generating high load for disk sub-
system.
• Memory - a resource-intensive service generating high load for CPU
and RAM.
• Replication - replication between the main and extra service instances
is supported. Replication is activated whenever the fault-tolerance
level of the cluster is not zero. For cluster configuration services and
cluster locks, replication is activated whenever multiple working serv-
ers with property Central server enabled are registered in the cluster.
 • Instancing by infobases - a separate service instance is used for each
infobase.
• Migration between working servers:
 Migration+ - service can migrate between working servers with-
out any data loss.
 Migration– - service can migrate between working servers with
some data loss.
 No migration - service cannot migrate between working servers; it
only runs on the central server of the cluster. Functionality as-
signment rules cannot be created for such services.
Cluster services by service types, infobases and sessions are evenly distrib-
uted between the working servers in the cluster.

2.2.4. Sessions and connections

2.2.4.1. General information
Session defines the active infobase user and the processing thread assigned
to the user. Any of these entities may become an active user:
• An instance of 1C:Enterprise client application;
• An instance of web application running the web client;
• An external connection instance (acquired from the
V83.COMConnector object);
• A background job instance;
• A web service call.
Sessions can be active or hibernating. One of the purposes of a sleep ses-
sion -is to maintain the health of the client application after the client com-
puter enters different power saving modes. A session hibernates when:
• Session connection terminates abnormally (applicable for thick client,
external connection, thin client with direct server connection). If the
network link is physically terminated, server requires 2–3 minutes to
detect loss of connection to the client application;
• Session client application times out due to inactivity (applicable for
web client and thin client connected over web server). If the client
computer is in power-saving mode and the client application performs
no user operations, it calls the 1C:Enterprise server every 5–10
minutes to keep the session from hibernating. Therefore, it is not rec-
ommended to set session hibernation time below 10 minutes.
Any activity of the client application wakes the session. A hibernating ses-
sion is terminated when:
• The hibernating session times out;
 • Locks set by the hibernating session conflict with the locks an active
session attempts to set.
When an active session hibernates, its client license is revoked and becomes
available. When a hibernating session wakes, it attempts to acquire a client
license (provided that it has a client license prior to hibernation). If a license
cannot be acquired, the session terminates with fatal exception.
Timeout values for inactive session hibernation and hibernating session
termination are set in the infobase parameter settings in Designer.
All data stored in a cluster and related to an active user and becoming obso-
lete once the user session ends is referred to as session data. The session
data includes:
• Infobase
• Session number
• Authenticated infobase user
• Interface language
• Session parameter values
• Temporary storages
• Session statistics
• Managed application form data
• Internal data of the platform
Session data is saved using the cluster manager. Session data service is
used for this purpose. Session data is retained when the service cluster re-
starts. If the active user makes no calls to the cluster during the timeout pe-
riod and the session is not assigned to a connection, the session hibernates.
The inactivity timeout period is set in the infobase parameter settings in
Designer. The default value is 1200 s. To keep the session from hibernating,
thin client and web client call the cluster every 10 minutes or less. For
quicker access, session data is cached both in the working processes and
thick clients. The list of active sessions is displayed in the list of active us-
ers.
Session data changes made during a server call are stored in the working
process and passed to cluster manager only when control is returned to the
client (normally, or after a software exception).
Session data changes are not saved in the cluster manager if:
• a working process was abnormally terminated during a server call
• A data transfer error has occurred when control was returned to the
client.
Connection is used by sessions to access 1C:Enterprise server cluster; con-
tains a finite set of connection data; not associated with the active user.
Connections are also used in interactions between cluster processes.
To access the cluster from client, you need to assign the session to a con-
nection. While the client does not attempt to access the cluster, no assign-
ment is required.
Sessions and connections are utilized in different ways across 1C:Enterprise
modes.
• Designer, thick client:
 on start: Establishes connection, creates a session, assigns the ses-
sion to the connection
 on finish: Cancels session assignment, terminates the session,
closes the connection
• One web service call, one background or scheduled job run:
 when call starts: Selects a connection from the pool, creates a ses-
sion, assigns the session to the connection
 when call ends: Cancels session assignment, terminates the ses-
sion, returns the connection to the pool
• The thin client and web client start the session at startup and end the
session at shutdown:
 At the beginning of a cluster call, a connection from the pool is
selected, and a session of this client is assigned to it.
 At the end of the call, the session assignment to the connection is
canceled and the connection is returned to the pool.
Session information can be viewed in:
• Event log
• Cluster console
• Software administration tools
• Technological log
• Global context
Cluster administrator can retrieve a list of open sessions for a specific in-
fobase or for the whole cluster, using the cluster administration utility or
software administration tools.
Cluster administrator can end a session using the cluster administration
utility or software administration tools. This will terminate the active user's
session. Ending a session assigned to a connection will also close this con-
nection.
Cluster administrator can set a session creation lock, using the cluster ad-
ministration utility or software administration tools. This prohibits creation
of new sessions but does not affect any existing sessions.

2.2.4.2. Connection types

Connections are classified into two general types:
• Infobase connections
 • Internal connections with working processes in the cluster

2.2.4.2.1. Infobase connections

The infobase connections:
• Are intended to access a specific infobase in the cluster
• Run code in 1C:Enterprise language
• Can be reestablished
• Can be terminated using a cluster console command or 1C:Enterprise
language expression
• When connected to an infobase in a cluster working process, prevent
the process from stopping or starting
The following infobase connection types are available:
• Thick client
• Thin client
• Designer
• Web server extension module
• COM connection
• Background job

Thick client
This connection is established between thick client and an infobase. The
connection is used to modify infobase data and perform other functions
supported by infobase configuration.
The Thick client connection is established when thick client is started inter-
actively in 1C:Enteprise mode, or when Automation Client/Server technol-
ogy is used to connect to an infobase, for example:
// Create 1C:Enterprise Automation server
AutomationServer= New COMObject("V83.Application");

// Establish infobase connection

// TestBase in cluster 1541 of central server TestSrv
AutomationServer.Connect("Srvr="TestSrv";Ref="TestBase");

Thin client
This connection is established between thin client and an infobase. The
connection is used to modify infobase data and perform other functions
supported by infobase configuration.
The Thin client connection is established when thin client is started interac-
tively, or when Automation Client/Server technology is used to connect to
an infobase, for example:
// Create 1C:Enterprise Automation server
AutomationServer = New COMObject("V83C.Application");

// Establish infobase connection

// TestBase in cluster 1541 of central server TestSrv
AutomationServer.Connect("Srvr="TestSrv";Ref="TestBase");

Designer
This connection is established between Designer and an infobase. The con-
nection is used to create or modify infobase configurations, and perform
administrative or scheduled activities.

Web server extension module

This connection is established between web server and the server working
process. The connection is used by web client, Internet services, thin client
over HTTP, and the mobile client.
The connection is established when an Internet service is called, or when
web client, thin client over HTTP, or mobile client calls the 1C:Enterprise
server. The connection exists until the web server is restarted or the connec-
tion is removed from web server extension module connection pool (due to
expiration of its pool lifetime, or to being displaced by other connections).

COM connection
This connection is established between a process utilizing external
1C:Enterprise connection and an infobase. The connection is used to modify
infobase data and perform other functions supported by infobase configura-
tion.
COM connection is established when COM technology is used to connect to
an infobase, for example:
// Create 1C:Enterprise Automation server
COMConnector = New COMObject("V83.COMConnector");

// Establish infobase connection

// TestBase in cluster 1541 of central server TestSrv
ConnectInfobase =
COMConnector.Connect("Srvr="TestSrv";Ref="TestBase");

Background job
This connection is established between a cluster working process and an
infobase. The connection is intended for executing the background job pro-
cedure code.
The background job connection is created when:
• A list of scheduled jobs registered in the infobase is received
• A scheduled job registered in the infobase is started
 • A background job is started using 1C:Enterprise language commands
• A report is started in background
• A background search by substring is performed
• A background list query is executed
• Background restructuring is started
Among others, developers can start background jobs using 1C:Enterprise
language expressions. Example:
// Run the background job described in the procedure
// UpdateFullTextSearchIndex
// of common module ScheduledProcedures
BackgroundJob =
BackgroundJobs.Execute("ScheduledProcedures.UpdateFullTextSearchInd
ex");

Background job connection is maintained while context of the background

job procedure exists. Once the procedure is finished or the report is generat-
ed, the background job connection closes.

2.2.4.2.2. Service connections

The service connections:
• Are intended to access a working process rather than a specific in-
fobase
• Do not run code in 1C:Enterprise language
• Cannot be terminated by user
• Do not prevent the working processes of server cluster from stopping
or starting
The following service connection types are available:
• Job scheduler
• Debugger
• Cluster console
• Administration server
• COM administrator
• System background job

Job scheduler
This connection is established between job scheduler and a working pro-
cess. The connection is intended for management of background jobs (for
example, starting scheduled jobs at specified moments of time). This con-
nection is also used in other situations when cluster manager (rmngr) calls
the working process (rphost), for example, when getting lists of sessions.
 The job scheduler connection is established during the first start of a back-
ground job. It can generate connections between the background job and
infobase within the same working process of server cluster. After the back-
ground job connection closes, the job scheduler connection stays active un-
til the cluster working process is terminated or deleted.

Debugger
This connection is established between debugger and a cluster working pro-
cess currently in debug mode. The connection is intended for debugging
management and searching for currently available debug items.
The debugger connection is established when a debug item is registered or a
search for debug items is initiated. The connection closes when the debug
item is unregistered or the search is completed.

Cluster console
This connection is established between the server cluster console (mmc)
and a working process. The connection is intended for administration of
server cluster infobases.
The cluster console connection is established when working process data is
accessed (for example, when getting infobase parameters or getting the de-
tailed list of infobase connections).

Administration server
This connection is established between server cluster remote administration
server and a working process. The connection is intended for administration
of server cluster infobases.
The remote administration connection is established when working process
data is accessed (for example, when getting infobase parameters or getting
the detailed list of infobase connections).

COM administrator
This connection is established with a server working process using COM
technology. The connection is intended for administration of server cluster
infobases.
The COM administrator connection is established when a working process
is accessed using COM technology, for example:
// Create 1C:Enterprise COMConnector
COMConnector = New COMObject("V83.COMConnector");

// Establish connection with working process 1562

// in cluster 1541 of central server TestSrv
ConnectWorkingProcess =
COMConnector.ConnectWorkingProcess("tcp://TestSrv:1562");

System background job

This connection is established between a cluster working process and an
infobase. The connection is intended for background updates of database
configurations.
The background job connection closes when the background restructuring is
completed.

2.2.4.3. Session types

The following session types are available:
• Thick client
• Thin client
• Web client,
• Mobile client,
• Designer
• COM connection
• WS connection,
• Background job,
• Cluster console
• Administration server
• COM administrator
Descriptions of sessions are generally similar to the above descriptions of
corresponding connections. Descriptions of other sessions are provided be-
low.

Web client
This session is a presentation of web client instance in the server cluster.
The session is intended for infobase data modification and other functionali-
ty available in the infobase configuration. Web client accesses the server
over connection Web server extension module.
The Web client session is created when web client is started in interactive
mode. It is closed when the interactive infobase session is terminated (the
last web browser window is closed).
Mobile client
This session is a presentation of mobile client instance in the server cluster.
The session is intended for infobase data modification and other functionali-
ty available in the infobase configuration. Web client accesses the server
over connection Web server extension module.
The Mobile client session is created when mobile client is started on a mo-
bile device. It is closed when the infobase session is terminated (the mobile
application is closed on the mobile device).

2.2.4.4. External session management

In client/server systems, you often need to manage the creation of sessions
with infobases, which implies the ability to:
• Restrict the number of concurrent infobase users
• Ensure a guaranteed reserve of licenses when working with an in-
fobase (example: with 100 licenses available, to provide guaranteed
access to the infobase for two users with particular names)
• Other similar tasks.
The external session management feature is designed to address these
problems. The feature requires a dedicated web service that allows or pro-
hibits session creation.
The feature operates as follows:
• When the system attempts to start a session, server cluster notifies the
web service that a session needs to be created and provides the web
service with a set of parameters that define all characteristics of the
session to be created (infobase name, user name, server cluster, etc).
• The web service decides whether to allow creation of the session, and
returns control to the server cluster. If required, the web service keeps
records for the created sessions.
• At the end of the session, the server cluster notifies the web service
that the session is ending.
• If the session enters or leaves the Hibernating state, the server cluster
notifies the web service of this event. This feature requires version 2
of the external session management service.
The external session management service possesses exact information on
the current number of open sessions in infobases under its control, and can
make appropriate decisions.
The external session management service is only called for the sessions that
require a client license:
• Designer
• Thick client
 • Thin client
• External connection
• Web client.
When sessions of other types are started, yhe external session management
service is not called.

2.2.5. Failover cluster

A failover cluster ensures uninterrupted user experience in the following
situations:
• Working processes and cluster managers are restarted (inlcuding both
scheduled and emergency restarts)
• A cluster server fails.
This section covers the mechanisms ensuring uninterrupted operation.

2.2.5.1. Transactional nature of session data

Upon a failure, sessions are saved and can be restored after reconnection.
However the system ends a session instead and asks to restart the client ap-
plication in certain situations, such as:
• A working process has failed during a server call, after the first trans-
action of this call has been committed.
• A data transfer error has occurred when control was returned to the
client.

2.2.5.2. Last call retry

If a data transfer error occurs during a server call, it might mean that:
• A communication channel was broken
• A server working process has failed
If a client application calls the server outside of a transaction and the client
receives the data transfer error prior to commitment of the first transaction
within the server call, the client automatically reconnects to the server and
retries the call. Then, the client continues normal operation.
If the client receives the data transfer error after commitment of the first
transaction within the server call, the session of this client terminates and
restart of the client is required to proceed.

2.2.5.3. Interactive action retry

If a client application calls the server within a transaction (in standard mode
instead of the managed application mode), the data transfer error is consid-
ered to be a recoverable error and results in failure of the interactive action
but does not result in failure of the client application itself.
Please note that application data integrity is not ensured by the platform if
the interactive action contains multiple transactions or modifies application
data status (except for the data with caching logic supported).

2.2.5.4. Workflow backup

If a working process fails, server cluster starts another working process.
Further, an attempt to move all client sessions serviced by a working pro-
cess which failed to another working process so started will be made. As a
result, users can experience material delays: client applications can cease to
respond to user commands and it seems that they hang up.
To mitigate manifestations of this problem which arises when you try to
move existing sessions to another working process, server cluster enables
you to create dedicated backup working process. Working processes are
backed up for each infobase individually. Infobases with working process
backup function switched on are called 'redundant'. Administrator can spec-
ify infobases for which backup working processes have to be created.
As such, the operation logic is as follows.
• Working servers storing redundant infobases run backup working pro-
cesses.
• The said working processes load metadata from redundant infobases.
• Whenever necessary, client sessions switch to backup working pro-
cesses with all proper data already loaded. The foregoing process is
performed without delay.
• As soon as a backup working process becomes a standard working
process, it is no more deemed a redundant process, and server cluster
creates further backup working processes to get the required number
thereof by way of starting new backup working processes.
The number of backup working processes is calculated on the basis of
Number of Infobases per Process working server property. If you need
to back up a working process, check Working Process Backup check box
in the infobase properties (cluster console). If a working process is a backup
process, check Backup check box in its properties. It is cleared, as soon as a
working process becomes an active process.

2.2.5.5. Resilience level

The level of resilience defines the maximum number of working servers in
the cluster whose concurrent failure would not result in abnormal termina-
tion of any user sessions. It should be understood that "failure" implies situ-
ations such as: computer power-off, network cable break, operating system
problems preventing the process from running, and more.
Therefore, if the server cluster contains only one working server, its resili-
ence level is 0 as the failure of the single server will result in abnormal ter-
mination of all user sessions. If the server cluster contains 4 working serv-
ers, its resilience level may vary from 0 to 3, where 0 means that failure of
any working server results in cluster failure, and 3 means that the cluster
will remain in operation even after 3 out of 4 working servers have failed.
Please note that any increase in resilience level is achieved at the expense of
cluster performance degradation, as some cluster resources are spent for
synchronizing data between working servers.
The resilience level depends on the number of central servers in the cluster.
The number of central servers determines whether new connections can be
created. If for example the cluster contains two center servers in case of 3
working severs the users are able to connect to informational bases in case
of abnormal end of one of the central servers. In this case, two servers are
still operable: one central server and one working server. But if only 1 serv-
er out of total 3 is a central server, the cluster becomes unavailable for users
after the central server has failed (even though both working servers are still
operable).
If the cluster contains 1 central server and 2 working servers (3 in total) and
the resilience level is set to 1, this may lead to a variety of scenarios. Let’s
have a closer look at these now.
Failure of one working server
An ordinary working server fails. This is within the resilience level and the
cluster keeps running user sessions. New users can be connected as the cen-
tral server is functioning properly.

Fig. 7. Failure of one working server

Failure of the central server
The central server fails. This is within the resilience level but the cluster
stops serving users because the only central server is down.

Fig. 8. Failure of the central server

Failure of two working servers
Two working servers fail while the central server keeps functioning. The
resilience level is exceeded, terminating all user sessions that were run by
the working servers that failed. Users who are served by the Central server
-remain healthy. New users still can be connected.

Fig. 9. Failure of two working servers

Therefore, the formula of correlation between the number of central servers
in the cluster and the resilience level is as follows: Number of central
servers = Resilience level + 1. Keep in mind that following
this formula literally may result in degradation of cluster performance be-
cause some of the system resources will be used to synchronize data be-
tween the working servers. When determining the number of central servers
and the resilience level, you should find a balance between the resilience
and the acceptable level of cluster performance, taking into consideration
hardware specifications of the cluster computers.

2.2.5.6. Connection break monitoring

Load balancing and failover cluster systems use TCP connections (network
connections) between cluster components. TCP connections are also used
when a client application (thin or thick) connects directly (without using a
web server) to the 1C:Enterprise server. If the availability of cluster compo-
nents is determined incorrectly, the mechanisms that rely on the availability
of components will not work adequately or correctly. To determine the cor-
rect availability of the cluster components, a system is introduced for track-
ing loss of connections between the cluster components.
This system monitors network connections between server cluster processes
(both on the same computer and on different computers), between a server
cluster and a web server extension, and between a client application and a
server cluster to achieve the following goals:
• Rapid detection of loss of connection between components
• Economical monitoring of the integrity of connections between cluster
components
For verification purposes, the concept of validation areas is used. The val-
idation direction is- a group of connections between server cluster compo-
nents that are joined by the following rules:
• Outgoing connections -to the target address (computer name and port
that uniquely identify a specific component of the server cluster).
• Incoming connections from the web server extension -by a unique
identifier that uniquely determines the publication of the information
base on the web server;
• Other incoming connections -are identified by a unique identifier that
uniquely identifies the source process.
A small data packet is sent periodically to each area. Validation is carried
out at both connection sides. The validation parameters are passed from the
connection source.
Packets are sent and expected over UDP and TCP. Initially, the packets are
sent via UDP protocol and, if no response has been received for the entire
lifetime of the area, a TCP connection is established on timeout and valida-
tion is attempted through the new connection. The direction is still consid-
ered as available. TCP inspection mode is less accurate and can cause false
positives when setting small timeouts. When setting up a server cluster and
publishing infobases on a web server, it is recommended to ensure that all
cluster computers are accessible to each other, and that cluster computers
and web server computers are accessible to each other as well both via TCP
and UDP (with the same port numbers). The operation of the tracking sys-
tem can be controlled by two parameters:
1. Check period- the time interval that elapses between sending a test
batch.
2. Check timeout - the period of time during which the sender of the
message should receive at least one response packet in the selected di-
 rection. The time interval is measured from the previous receipt of the
response packet (or the start of the system).
If no packets are received from the opposite side during the scan timeout
period, the scan direction is considered unavailable, except when switching
from UDP to TCP. Once a scan direction is found to be unavailable, all
connections in that direction are marked as unusable and will be terminated
the first time they are accessed. At the same time, all available components
of the server cluster are notified of the disconnection of a certain direction
so that the cluster can respond quickly to the upcoming disconnection (in-
cluding the removal of locks corresponding to the unavailable process).
The server cluster administrator can monitor the quality of the connection
between the cluster components. To do this, the connection check statistics
for the past 10 seconds are recorded in the process log every 10 seconds. In
particular, it displays information about the average response time and the
maximum response time. This information allows you to set the optimal
values of the check timeouts, which will not lead to false positives of the
check system, but, at the same time, will ensure the reliable operation of the
system. In the technology log, the information is commited in the CONN
event.
If any of the settings of the tracking system broken connections set to 0,
then the tracking system disconnects starts to work on other algorithm. In
this case, the test is performed only by the party that initiated the network
connection, and the test packets are sent every 5 seconds. The process that
receives the test packets determines that the connection is lost if it does not
receive any packets within 200 seconds. The source process will only know
about the disconnection after the TCP connection timeout occurs, which is
determined by the operating system settings. With this configuration of the
connection break tracking system, the period of sending messages and the
timeout are not configured, and the connection statistics information is not
displayed in the technology log. Such variant of configuration (validation
period or a timeout check is set to 0) system tracking of broken connections
are not recommended for use.
When tracking the connection between the client application and the server
cluster are other settings of the validation period and time-out TCP connec-
tion:
• for thick customer:
 message sending period -12 seconds;
 TCP connection timeout -60 seconds.
• for thin customer:
 message sending period -3 seconds;
 TCP connection timeout -15 seconds.
The setting values are fixed and cannot be changed.

2.2.6. Server cluster scalability

Cluster server scalability can be achieved by:
• Increasing the computing power of the computer where a single work-
ing server is deployed
• Adding one or several working servers to the server cluster
The server cluster automatically executes all scalability activities. The clus-
ter administrator can affect these activities by modifying the working server
properties.
New servers can be added to the cluster list of working servers and the
properties of existing servers can be modified. Modified properties do not
take effect until a new session or connection is created. When removing a
working server from the cluster, take efforts to ensure that user sessions
being run by this server will not be terminated. The last working server with
the Central server property enabled cannot be removed from the cluster.
When a default cluster is created, the working server of the computer used
to create the server cluster is automatically added to the list of working
servers and the Central server property is enabled for it.
The server cluster automatically distributes the load between working serv-
ers to achieve the quickest possible response time for client applications.
Cluster services are evenly distributed between cluster servers according to
the type of service, the infobases, and the sessions.
When establishing an infobase connection, the server cluster selects work-
ing servers with maximum capacity available at the moment. Existing con-
nections can be moved to other working servers.

2.2.7. Cluster load balancing

2.2.7.1. Available performance of a working
process
Each working process has the Available performance property. This
property determines how quickly a working process is able to process a ref-
erence server call as compared with other working processes. A reference
call includes the following operations:
• Memory operations: array allocation, population, and deallocation
• FIle operations: creation, writing, deletion
 • Assessment of processor load for the computer running the working
process, and the number of threads to run. This value increases execu-
tion time of the reference call.
Under Windows, the user on whose behalf the server is started must
belong to the Performance Log Users group. Otherwise, the proces-
sor load assessment is not performed.
Value of the Available performance property is calculated by dividing 10
000 by average time (during 5-minute period) required by the current work-
ing process to process a reference call. The reference call is executed every
5 seconds if the cluster contains multiple working servers. If a server cluster
consists of a single production server, -all workflows are considered equal.
Client applications are allocated to the working processes so as to ensure a
roughly equivalent available performance for each working process. The
25% difference in available performance levels is considered to be substan-
tial.
When balance between the available performance of working processes
changes, the clients are dynamically reallocated to working processes within
10 minutes.
When a working process is disabled, clients allocated to it are dynamically
reallocated to the working processes that are still enabled.

2.2.7.2. Establishing a new connection

2.2.7.2.1. Direct server connection

NOTE. Available only for CORP licenses.

When establishing a new connection to the 1C:Enterprise server, you can
specify how the working process will be selected (the Load balancing
mode server cluster property):
• By performance
• By available memory
Selection by performance
Select the list of suitable working servers with the productivity not less than
75% of the one of the most efficient server. The server productivity suppos-
es the level of productivity of the most efficient operational process on this
server. Be sure to select on each suitable server the suitable operational pro-
cesses the efficiency of which is equal to at least 75% of productivity of the
most efficient working server. Per each working server select the most suit-
able working process from available working processes based on one of the
following criteria:
 • A working process has the greatest number of connections with sup-
ported infobase.
• A working process has the greatest number of connections with any
infobase, whenever there are no working processes supporting an in-
fobase for which connection is established.
Be sure to select a random working process from the best working processes
of all servers, so that even distribution is ensured upon mass load, if any.
Exactly this operational process will be used during new connection instal-
lation.
An existing 1C:Enterprise server connection may be established to another
working process in the following situations:
• Current working process is disconnected.
• Available efficiency of current operational process makes less than
75% of available productivity of the most efficient working server.
The connection re-installation is possible only on the observance of the fol-
lowing conditions:
• the clients flow is not performed on the server;
• no open transaction;
• No temporary tables were created
Selection by available memory
Be sure to select the operational servers with the efficiency not less than
25% from the one of the most efficient operational server. The server
productivity supposes the level of productivity of the most efficient opera-
tional process on this server. Be sure to select on each working server the
operational processes, the efficiency of which is not less than 25% from the
one of the most efficient working server. Browse the operational processes
maintaining the required informational base from the list of suitable opera-
tional processes. Selected working process depends on search results:
• One operational process found. Use this operational process for con-
nection setting.
• Several operational processes had been found. Be sure to select the
operational process with maximum amount of free operative memory
from search results.
• No operational process selected. Use the operational process from the
list of suitable operational processes having maximum amount of free
operative memory for connection setting.
An existing 1C:Enterprise server connection may be established to another
working process in the following situations:
• Currect operational process is disconnected;
 • Available efficiency of current operational process makes less than
25% of available productivity of the most efficient working server.
Connection can be reestablished if all conditions are met:
• Client thread is not executed on the server
• No open transactions exist
• No temporary tables were created

2.2.7.2.2. Connection via web server extension

When calling the server on behalf of a new session, the system:
• Selects any connection from the connection pool available in the web
server extension
• If no connections are available, a new connection is created according
to the Load balancing mode cluster parameter.
When calling the server on behalf of a new session, the system:
• Searches the connection pool for a connection to the working process
that was used during the previous call. If -successful, the found con-
nection is used.
• The system attempts to select a working process based on the Load
balancing mode cluster parameter, giving higher priority to the
working process that was last used to call the server. A new working
process will be selected if it significantly exceeds the current working
process in terms of performance or available memory. If there are free
connections -to the resulting workflow, one of them will be used.
• Otherwise, a new connection is created based on the Load balancing
mode cluster parameter.

2.2.7.3. Functionality assignment rules

2.2.7.3.1. General information

NOTE. Full functionality is only available for CORP licenses. The PROF
server license allows using the demands of functionality setting in case if
these rules do not contain additional parameters such as the name of infor-
mational base, application name or type of background task. Moving specif-
ic cluster services (for example, the licensing service) to separate working
servers is allowed.
The server cluster provides a set of features called requirement objects.
You can manage their allocation to working servers within the cluster. For
example, you can specify a working server to run all background jobs in the
cluster.
To assign a connection or cluster service to a working server, you need to
create a functionality assignment rule for this working server. This rule de-
termines whether the server is allowed to execute a particular job. Let us
examine the functionality assignment rules in detail.
A functionality assignment rule determines:
• An object for which the rule is created. Some cluster services, client
connections, or arbitrary requirement objects can be used as require-
ment objects. The cluster services with the marked option of transfer
can act as the option of demand.
• Rule type. The rule type determines how the working server is used:
 Do not assign- means that the production server for which the re-
quirement is created will not be assigned to service the require-
ment object that matches the conditions specified in the require-
ment.
 Assign means -that the production server for which this require-
ment is created will be one of the candidates for servicing this re-
quirement object (if there are several production servers).
 Auto- means that the production server can be used to service the
requirement object if there is no production server with an explicit
indication of the need for use.
TIP. It is a good idea to use the Auto rule type when the list of working
server rules includes a rule with a broad set of conditions and you need a
rule for a more focused set of conditions. For example, a server might be
prohibited from processing client application connections for all infobases
except for a single allowed infobase.
• Additional parameters the server cluster sometimes needs in order to
make decisions:
 Infobase name This is used to adjust the requirement for generat-
ing rules for client connections and all cluster services that can act
as requirement objects except for the licensing service. Please keep
in mind that infobase name is not case-sensitive.
 Additional parameters. These are used to adjust the requirements
when allocating a client connection or the session data service. The
additional parameters are checked for matching the beginning of
the corresponding parameter of the requirement object. The addi-
tional parameters can take on the following values:
 To specify a background job:
BackgroundJob.ScheduledJob.<Configuration
object name>.
 To specify a background job that was started using
1C:Enterprise language command:
BackgroundJob.CommonModule.<Module
name>.<Method name>.
 To specify all background jobs that were started using
1C:Enterprise language commands:
BackgroundJob.CommonModule.
 To specify a full-text search indexing background job:
BackgroundJob.FullTextSearchIndexUpdate.
 To specify a report (including external reports):
BackgroundJob.GenerateReport.<Full name of
configuration object>.
 Input by string:
BackgroundJob.InputByString.<Full name of
configuration object>.
 Search in list:
BackgroundJob.DynamicListSearch.<Full name
of form>.<Table name for form associated
with list>.
 To specify background restructuring:
SystemBackgroundJob.DBConfigUpdate.
 To specify a background job for totals recalculation:
SystemBackgroundJob.RecalcTotals.
 For setting background task of initial filling of data base copy:
BackgroundJob.DBCopiesFilling.
 Mention background task for renewing data base copy:
BackgroundJob.DBCopiesNotification.
 For mentioning background task, performing data history up-
date right after registering versioned object:
BackgroundJob.UpdateDataHistoryImmediately
AfterWrite.
 For mentioning background task performing the processing af-
ter versions registration:
BackgroundJob.AfterWriteDataHistoryVersion
sProcessing.
 For mentioning background task, used by the global search
mechanism for the search on:
 functions menu:
BackgroundJob.GlobalSearchFunctionsMenu.
  data:
Back-
groundJob.GlobalSearchFullTextSearch.
 memo: BackgroundJob.GlobalSearchHelp.
 meta data:
BackgroundJob.GlobalSearchAllFunctions.
 For mentioning background task calling the search procedure,
implemented in built-in language and mentioned in global
search plan in background mode:
BackgroundJob.GlobalSearch.<module
name>.<method name>.
 For a client application:
 1CV8 - thick client
 1CV8CDirect - thin client in case of a direct connection
to 1C:Enterprise server
 Designer - Designer
 COMConnection - COM connection
 WebServerExtension - infobase connection over a
web server: web client, thin client in case of connection
over a web server, mobile client, web service.
Once you created the functionality assignment rules, you need to apply
them through the cluster administration console.
Let us examine how the server cluster processes the assignment rules. If a
requirement object needs to be allocated, the following actions are per-
formed by the cluster:
• All cluster servers process functionality assignment rules specified for
these servers. The rules are processed in order specified in the cluster
console.
• In every list of rules, the system selects the first rule that satisfies the
object to be assigned: based on the object itself, the infobase, and the
additional parameter.
• Then the list of working servers is sorted by the rule type so that
working servers explicitly assigned for use are placed at the top of the
list. Production servers for which the appropriate requirement explicit-
ly prohibits use are -excluded from the list of available production
servers. The servers are assigned as follows:
 If any working servers are explicitly assigned for use, the require-
ment object will be processed by one of these servers.
 If no working servers are explicitly assigned for use, the system at-
tempts to use working servers with rule type Auto or working
servers with no rule type specified.
 • When allocating a client connection, the server running a working
process with the highest available performance will be selected from
the list of available servers.

The client application that initiates allocation of the requirement object will
be terminated in these cases:
• If the list of production servers for the request object is empty, there is
-no production server that can service the object. In this case, the re-
quirement object is not assigned and an exception is called.
• The requirement object cannot be assigned to the selected working
server (for example, when the server has failed and no alternate serv-
ers are available).

2.2.7.3.2. Assigning requirement objects

Let us examine the algorithm used to assign a working server for processing
a cluster service.
Cluster services can have the following requirement objects:
• Service of one type, provided that the service is not divided by in-
fobases
• Service of one type for one infobase, provided that the service is di-
vided by infobases
• Session data service
• Licensing service
The services are allocated to the working servers as follows:
• Servers that are currently operable are selected from the list of work-
ing servers available for the assignment. From the remaining working
servers, servers with highest Priority are selected.
• Services are distributed evenly among the selected working servers.
• Services supporting replication can be assigned to multiple working
servers. Number of working servers used for replication-enabled ser-
vices is equal to the cluster resilience level plus 1. In this case, one
service is set as active and its internal data is replicated to other
(backup) services. The replication is performed asynchronously. Data
is synchronized every second.
• Services that do not support data migration (No migration character-
istic) are assigned to all working servers with the Central server flag
enabled.
• A separate instance of the session data service is created for each ses-
sion processed by the server cluster. When selecting working servers
that can process a specific service instance, additional parameters of
 the rule are considered. Servers processing the lowest number of clus-
ter services are selected from the list of available servers. Number of
working servers used for replication-enabled services is equal to the
cluster resilience level plus 1.
• If you need to use licensing service, select a working server to which
the software license will be attached and assign the service to this
server in the rules explicitly.
• Other services are assigned as a single instance.
Cluster services can be reassigned between working servers in the following
cases:
• When a working server is added, services are partially reassigned. The
reassignment is performed automatically.
• When a working server is removed from the cluster or becomes una-
vailable, requirement objects processed by the unavailable server are
reassigned. The reassignment is performed automatically.
• When an infobase is added or deleted from the cluster, services are
partially reassigned. The reassignment is performed automatically.
• Services are reassigned when the cluster administrator applies all or
some rules from the cluster console.

2.2.7.3.3. Assigning working processes

At cluster startup, one working process is started on each working server,
and the available performance of each working server is computed.
The client application connects to the 1C:Enterprise server cluster according
to these rules:
• A working server is selected in accordance with the assignment rules
and the RAM usage restrictions.
RAM usage restrictions are considered when connecting to an in-
fobase with no established connections on the selected working server.
If the RAM usage limit is exceeded, the working server is excluded
from the list (provided that another working server that has not ex-
ceeded the limit is available). Working servers that cannot process the
requested connection according to the assignment rules are also ex-
cluded.
• A list of working processes that are available and can process the con-
nection is created for the selected server. A working process is added
to the list of available working processes when:
 The maximum number of connected infobases (see the Number of
infobases per process property of the working server) is not
reached for the working process.
  The maximum number of processed connections (see the Number
of connections per process property of the working server) is
not reached for the working process.
 The working process is not preparing for automatic restart.
• The system prefers working processes that already process connec-
tions to the required infobase. If there is no such workflow, -the work-
flow with the maximum number of connections served is selected.
• If the system fails to select any working process, a new working pro-
cess is started on the working server to process the requested connec-
tion.
When establishing connection from an existing session (if the previous
server call failed to reconnect) the working process that processed the pre-
vious connection of this session will be selected. Another working process
can be also selected if its available performance exceeds the available per-
formance of the current working process by 25% or more.
When two working processes concurrently run for 20 minutes on the same
working server and the number of connections and infobases processed by
these processes together is less than the values specified in the working
server properties (Number of connections per process and Number of
infobases per process correspondingly), the process that serves fewer
connections will be marked as obsolete and stopped after closing the last
connection. Existing connections with the obsolete working process will be
required to stop using the working server during the next server call through
the connection. The obsolete working process is ignored when requests for
processing new requirement objects are allocated.
When calculating the number of processed connections, all connections
created by the debugger to check the access rights for debugging purposes
are included.
2.2.7.4. Cluster management examples

2.2.7.4.1. General information

A server cluster described below will be used to examine the sample func-
tionality assignment rules.

Fig. 10. Server cluster used for sample rules

Cluster specifications:
• Number of working servers: 3.
• Resilience level: 1.
• Number of central servers: 2 (SRV1, SRV2).
• Operating systems on working servers:
 SRV1 server, Windows.
 SRV2 server, Linux.
 SRV3 server, Windows.
Cluster infobases:
• DemoDB,
• WorkDB.
IMPORTANT! The examples below are not complete solutions that can be
used in a real-life case. They are provided only to demonstrate how to as-
sign requirement objects to working servers in the cluster.
IMPORTANT! The functionality assignment rules do not take effect until
they are explicitly applied. To apply the rules, use the cluster console.
2.2.7.4.2. Assigning all background jobs to a single
working server
To assign all background jobs to the SRV1 working server, use the func-
tionality assignment rules for SRV1 as described below:
• Requirement object: Client infobase connection.
• Rule type: Assign.
• Infobase name: do not specify.
• Additional parameter value: BackgroundJob.CommonModule.

2.2.7.4.3. Assigning the licensing service to a

dedicated working server
To activate a multi-user client license for the computer running the SRV2
working server, assign the licensing service to this computer, and make sure
no other service are assigned to this computer, use the functionality assign-
ment rules for SRV2 as described below:
• Rule 1:
 Requirement object: Licensing service.
 Rule type: Assign.
 Infobase name: do not specify.
 Additional parameter value: do not specify.
• Rule 2:
 Requirement object: Any requirement object.
 Rule type: Do not assign.
 Infobase name: do not specify.
 Additional parameter value: do not specify.
Requirement 1 will ensure that the licensing service is running on the
SRV2 server, and Requirement 2 will ensure that only the licensing service
is running on the SRV2 server (no other cluster services will be running on
the SRV2 server).
When activating the software license via the 1C:Enterprise server, specify
SRV2 as the server name; otherwise the server cluster will not be able to use
the license as it will be activated for another computer.

2.2.7.4.4. Prohibit assigning the external data

source access service to a working server
You must allow the service to work with external data sources on produc-
tion servers SRV1 and SRV3, and deny -SRV2 on the production server.
use the functionality assignment rules for SRV2 as described below:
 • Requirement object: External data source access service.
• Rule type: Do not assign.
• Infobase name: do not specify.
• Additional parameter value: do not specify.

2.2.7.4.5. One working process serving a single

infobase
To configure the server cluster so that each infobase is processed by one
working process, set the Number of infobases per process property for
each working server to 1.
As a result, two workflows will be created on each server (-6 in total, 2
workflows for each of the 3 production servers). In this case, one infobase
will be processed by 3 working processes on 3 working servers.

2.2.7.4.6. Assigning working servers to specific

infobases
To configure the server cluster so that the DemoDB infobase is processed
only by the SRV3 working server and the WorkDB infobase is processed by
two working servers (SRV1 and SRV2), use the following rules:
• For working server SRV3:
 Requirement object: Any requirement object.
 Rule type: Assign.
 Infobase name: DemoDB.
 Additional parameter value: do not specify.
• For working servers SRV1 and SRV2:
 Requirement object: Any requirement object.
 Rule type: Assign.
 Infobase name: WorkDB.
 Additional parameter value: do not specify.
These rules will assign all server cluster mechanisms – connections, back-
ground jobs, session data services, and more – to the specific working serv-
ers. $$$remove it$$

2.2.7.4.7. Assigning specific background jobs to a

specific working server
To configure the server cluster so that the SRV1 working server only runs
reports, SRV2 is dedicated to running FullTextSearchUpdateIndex
and SalesAggregateUpdate scheduled jobs, and SRV3 runs any other
background jobs, use the following rules:
• For working server SRV1:
 Rule:
 Requirement object: Client infobase connection.
 Rule type: Assign.
 Infobase name: do not specify.
 Additional parameter value:
BackgroundJob.GenerateReport.
• For working server SRV2:
 Rule:
 Requirement object: Client infobase connection.
 Rule type: Assign.
 Infobase name: do not specify.
 Additional parameter value:
BackgroundJob.CommonModule.FullTextSearchO
perations.UpdateFullTextSearchIndex.
 Rule:
 Requirement object: Client infobase connection.
 Rule type: Assign.
 Infobase name: do not specify.
 Additional parameter value:
BackgroundJob.CommonModule.AggregateSchedu
ledJobs.UpdateSalesAggregates.

2.2.8. Security profiles

2.2.8.1. General information
NOTE. Available only for CORP licenses.
Applied solutions can utilize a variety of external resources for their pur-
poses: file system directories, COM objects (under Windows), add-ins, OS
applications, and more. However, for security reasons, applied solutions
might be restricted from accessing certain external resources. You may need
to create a separate temporary files directory for each area of the partitioned
infobase or specify a white list of Internet resources that the applied solution
can access.
To enable such restrictions, security profiles can be set up for the server
cluster. A security profile -is a set of explicitly defined permissions for the
use of certain external resources (with a list of such resources) that can be
assigned to information databases registered in the cluster. Security profiles
are created by the cluster administrator. They allow you to set up the fol-
lowing permissions:
• Permission to use this profile as a security profile in safe mode - If this
permission is enabled (see the Can be used as a safe mode securi-
ty profile profile property), the name of this security profile can be
specified in the 1C:Enterprise language when enabling safe mode and
attaching external reports and processors.
• Access to resources in the server file system.
• Access to COM objects (only for Windows servers).
• Access to add-ins.
• Access to external modules (external reports, data processors, and ex-
tensions) and access to the Execute() operator and the Eval()
function.
• Access to OS applications.
• Access to Internet resources.
• Permission to access the privileged mode - if this permission is ena-
bled (see the Full access allowed: privileged mode profile proper-
ty), the privileged mode can be enabled when this profile is used.
• Permission to access cryptographic functions.
• Permission to expand access rights.
• Permission to expand all configuration modules.
To allow the infobase to use the security profile you created, you need to
specify the name of that profile in the infobase properties using cluster serv-
er administration tools. The name of the profile that will be used in safe
mode can also be specified in the infobase properties.
Some permissions allow to specify a list of permitted resources. These per-
missions are:
• Access to resources in the server file system
• Access to COM objects (only for Windows servers)
• Access to add-ins
• Access to external modules
• Access to OS applications
• Access to Internet resources
• Permission to expand access rights
• Permission to expand all configuration modules.
In this case, the following considerations apply:
• If a check box (for example, "Access to Internet resources") is cleared
in the security profile, Internet resources cannot be accessed from the
infobase this security profile is applied to.
 • If this check box is selected in the security profile, the applied solution
has full access to Internet resources.
• If only a limited white-list access is required, clear the check box and
instead specify a list of resources you allow access to. For some per-
missions, both white-list and black-list can be specified. Restriction
lists for permissions are created in a number of different ways.
For detailed descriptions of specific permissions, see below.

2.2.8.2. Server file system resources

Virtual directories are used to access server file resources. This implies
that each security profile has a virtual file system where directories are cre-
ated. Each virtual directory reflects the real file system according to certain
rules. When the applied solution needs to execute a file operation, path to
the file located in the virtual file system is specified in the relevant function
parameter. 1C:Enterprise translates the virtual directory to a physical one
and generates a physical path to the file specified in the operation. The ap-
plied solution cannot obtain any information on which physical path will be
used to reflect the virtual directory.
If multiple virtual directories are specified in the security profile, the ap-
plied solution can only access those resources. Attempting to access any
other directory (both real and virtual) is not -possible.
Virtual directories are used when calling the 1C:Enterprise language meth-
ods:
• Global context:
 BinDir()
 TempFilesDir()
 ValueToFile()
 ValueFromFile()
 FileCopy()
 MoveFile()
 DeleteFiles()
 FindFiles()
 CreateDirectory()
 SplitFile()
 MergeFiles()
 GetTempFileName()
• Picture object:
 File name-based constructor
 Write()
• BinaryData object:
  File name-based constructor
 Write()
• TextExtraction object:
 File name-based constructor
 Change of FileName property
 Write()
• TextDocument object:
 Write()
 Read()
• SpreadsheetDocument object:
 Write()
 Read()
• FormattedDocument object:
 Write()
• GraphicalSchema object:
 Write()
 Read()
• GeographicalSchema object:
 Write()
 Read()
• File object:
 File name-based constructor
• xBase object:
 File name-based constructor
 OpenFile()
 CreateIndex()
 CreateFile()
• XMLReader object:
 OpenFile()
• XMLWriter object:
 OpenFile()
• XMLCanonicalizingWriter object:
 OpenFile()
• XSLTransform object:
 LoadFromFile()
 TransformFromFile()
• FastInfosetReader object:
 OpenFile()
• FastInfosetWriter object:
  OpenFile()
• ZipFileWriter object:
 File name-based constructor
 Add()
 Open()
• ZipFileReader object:
 File name-based constructor
 Extract()
 ExtractAll()
 Open()
• ClientCertificateFile object:
 Default constructor
• CertificationAuthorityCertificatesFile object:
 Default constructor
• HTMLWriter object:
 OpenFile()
• HTMLReader object:
 OpenFile()
• TextReader object:
 File name-based constructor
 Open()
• TextWriter object:
 File name-based constructor
 Open()
• CryptoCertificate object:
 File name-based constructor
• CryptoManager object:
 Sign()
 VerifySignature()
 Encrypt()
 Decrypt()
 GetCertificatesFromSignature()
• DataHashing object:
 AddFile()
The following parameters describe a virtual directory:
• The logical URL- that will be used by the application solution. This
parameter must look like a beginning of an actual path in the relevant
file system (for Windows and Linux). Applications can only use paths
 that begin with the value stored in this property. It is unique per pro-
file.
System methods use two predefined logical URLs:
 /bin - catalog of boot modules of the current "1C: Enterprise"
version. This virtual directory is used by the BinDir() method.
 /temp - temporary files directory. This virtual directory is used
by the TempFilesDir() method.
• A physical URL -that specifies the physical location of a logical URL
in the file system of the server. It can include special placeholder
characters. When executing file operations, 1C:Enterprise converts the
logical URL into the actual file system address by replacing all place-
holders. Next, every sequence of characters that cannot be used in the
URL is replaced with the underscore ("_").
IMPORTANT! In most cases, the application autonomously monitors how
virtual directories are mapped to the actual file system.
The following placeholders are allowed in the address:
 %r - infobase reference name
 %i - infobase ID
 %z - string presentation of current values of current session sepa-
rators in the /Z command string parameter format
 %s - session number
 %c - connection number
 %p - application safe mode ID
 %e - 1C:Enterprise runtime module directory
 %t - current directory with the temporary OS files
 %u - directory with application data of the current user
 %a - directory with application data of all users
 %n - name of the current infobase user
 %% - % (percentage) character
• Can read data - this check box determines whether data can be read
from files in the virtual directory
• Can write data - this check box determines whether data can be writ-
ten to files in the virtual directory
The physical URL can point to directories located on the 1C:Enterprise
computer or the network resources. Therefore, you should pay attention to
the OS-specific aspects of server file system organization and network op-
erations.
When the session is terminated, any physical directories specified using the
%s placeholder are deleted. Similarly, when the connection ends, any physi-
cal directories specified using the %c placeholder are deleted. Enabling safe
mode for execution of code in 1C:Enterprise language has its own unique
ID. When safe mode is disabled, any physical directories specified using the
%p placeholder are deleted.

2.2.8.3. Server COM objects

The cluster security profile can contain a list of COM object classes permit-
ted for the application.
IMPORTANT! This option is only supported for Windows servers.
If the infobase references a security profile that restricts usage of COM ob-
jects, only COM object classes included in the list of COM object classes
permitted for this profile can be used. The COM object used by the configu-
ration corresponds to the item on the security profile list of permitted COM
objects, provided that the value of the COM object computer property
matches and the non-null values of the File (moniker) and COM class ID
properties also match. Any attempt to create an instance of any COM object
not included in the list raises an exception.
The following parameters describe a permitted COM object class:
• Name - a unique name of COM object class. It is unique per profile.
• File (moniker) - a file moniker name. Used when calling the
GetCOMObject() method with undefined value of the
COMClassName parameter. For more details on file monikers, see:
http://msdn.Microsoft.com/ru-
RU/library/windows/desktop/ms688670(v=vs.85).aspx
• COM class ID- a string containing a COM object class identifier in the
Windows registry format, without curly brackets. This value is used
by the new COM object constructor and the GetCOMObject()
method.
• COM object computer - a name of the computer that can be used to
create a COM object. Used by the new COM object constructor. To
specify the current computer, use the localhost string; if COM ob-
ject can be created on any computer, use empty string.

2.2.8.4. Add-ins
The cluster security profile can contain a list of add-ins permitted for the
application. If the infobase references a security profile that restricts usage
of add-ins, only the add-ins included in the list of add-ins permitted for this
profile can be used. Any attempt to execute the AttachAddIn() method
for an add-in not included in the list raises an exception. An empty list
means that this profile does not permit any add-in usage.
The following parameters describe a permitted add-in:
• Name - a unique add-in name. It is unique per profile.
• Checksum - a SHA1 checksum of the permitted add-in converted to
the base64 format.
To generate the checksum, you can conveniently use the DataHashing
object and the Base64String() global context method.
To prepare permissions for a Native API add-in, you need to specify a sepa-
rate permission for each platform type supported by the add-in. Therefore,
to provide support for all platforms, you need to specify 4 add-in permis-
sions: for 32-bit- and 64-bit Windows, and for 32-but- and 64-bit Linux.

2.2.8.5. External modules

The cluster security profile can contain a list of external reports and proces-
sors that can be accessed from the application without enabling the safe
mode. The external modules include: external reports, external data proces-
sors, and configuration extensions. If the infobase references a security pro-
file that restricts usage of add-ins, only those external modules included in
the list of permitted modules can be used without enabling the safe mode.
Any attempt to use an external module not included in the list without ena-
bling the safe mode raises an exception. An empty list means that this pro-
file does not permit any usage of external modules without enabling the safe
mode. This profile item also controls whether the Execute() operator
and the Evaluate() function can be used in safe mode only. If the Full
access allowed: external modules check box is cleared in the security
profile, the Execute() operator and the Evaluate() function can be
used in safe mode only (you need to enable the safe mode prior to every use
of this operator or function). If the Execute() operator and the
Evaluate() function are used in the application for internal purposes
(outside of the safe mode), do not use any security profiles that have the Full
access allowed: external modules check box cleared.
The following parameters describe a permitted external report or data pro-
cessor:
• Name - a unique external module name. It is unique per profile.
• Checksum - a SHA1 checksum of the permitted external report or data
processor converted to the base64 format.
To generate the checksum, you can conveniently use the DataHashing
object and the Base64String() global context method. To generate the
checksum for a configuration extension, use the application interface or
Designer (main menu - Configuration - Configuration extensions -
Actions - Show checksum).

2.2.8.6. Third-party applications

The cluster security profile can contain a list of third-party applications that
can be accessed from the 1C:Enterprise application. If the infobase refer-
ences a security profile that restricts usage of third-party applications, only
those third-party applications included in the list of applications permitted
for this profile can be used. Any attempt to execute the RunApp() method
for a third-party application or with parameters not included in the list raises
an exception. An empty list means that this profile does not permit any us-
age of third-party applications.
The following parameters describe a permitted third-party application:
• Name - application name. It is unique per security profile.
• Command line mask - a mask for the application command line. It is a
sequence of mask words separated by space characters. A mask word
is a sequence of any characters and placeholders. If a mask word con-
tains spaces, it should be enclosed in quotation marks.
The following placeholders are allowed:
 % - a sequence of one or more characters
 _ - a single character
 * - file name If a mask word starts with *, the parameter is a virtu-
al directory path. Before the command line is executed, the virtual
directory name is replaced with the physical one.
 \ - a character prefix. Place this character in front of a mask work
to make it a common non-mask word.
The name of the application to be started, as well as each of its command-
line parameters, are checked against the list of allowed applications. If a
matching mask word is not found, the mask does not match the command
line.
Example: the xcopy */temp/% */userdata/% mask is used to copy
a file from virtual directory /temp to virtual directory /userdata.
The command-line parameters are separated by one or more space charac-
ters.
A string enclosed in quotes (") is treated as a single parameter. A sequence
of words where the first and the last words contain an odd number of single
quotation marks is treated as a single parameter. If only one word with quo-
tation marks is found, everything from this word to the end of the string is
treated as a single parameter. To put a quotation mark in a parameter not
enclosed in quotation marks, use this pair of characters instead: \". To put a
quotation mark in a parameter enclosed in quotation marks, use either of
these pairs of characters: \" or "".

2.2.8.7. Internet resources

The cluster security profile can contain a list of Internet resources that can
be accessed from the application. If the infobase references a security pro-
file that restricts access to Internet resources, the InternetConnection
object is prohibited and the InternetMail, HTTPConnection,
FTPConnection, WSDefinitions objects are only allowed to access
the resources included in the list of Internet resources permitted for this pro-
file. Any attempt to access any resource not included in the list raises an
exception. An empty list means that this profile does not permit any access
to Internet resources.
The following parameters describe a permitted Internet resource:
• Name - name of the Internet resource. It is unique per security profile.
• Address - address of the resource (protocol name not included)
• Port - number of the port used to access the resource
• Resource type (protocol) - name of the protocol used to access the re-
source The following protocols are allowed (case-insensitive):
 imap - IMAP email server
 pop3 - POP3 email server
 smtp - SMTP email server
 http - web server
 https - secure web server connection
 ftp - FTP server
 ftps - secure FTP server connection

2.2.8.8. Privileged mode

If a session is managed by a security profile, operation in a privileged mode
depends on the following two security profile parameters: check box for
privileged mode in Full Access Allowed group and Privileged Mode
Roles property.
If a check box for privileged mode is checked, as soon as privileged mode
is started - full access is allowed, when rights control is switched off and all
data access restrictions are removed.
If a check box for privileged mode is cleared, system behavior depends on
Privileged Mode Roles property as follows:
• The property has predefined roles. As such, as soon as privileged
mode is switched on, in the current session access rights and data ac-
cess restrictions are specified for roles selected in Privileged Mode
 Roles property. Whenever privileged mode is switched off (irrespec-
tive of the method), roles and data access restrictions existing before
privileged mode is switched on continue to apply.
• The property has no predefined roles. In this scenario roles and data
access restrictions continue to apply in a session, which were used be-
fore privileged mode is switched on. Moreover, all rights controls and
data access restrictions will be applied.
Other parameters of the security profile determine which external resources
are available.

2.2.8.9. Cryptographic functions

To use the cryptographic functions on server side, you need a specific per-
mission enabled in the security profile. If the permission is enabled, you can
use any methods of the CryptoManager object. Otherwise, any attempt
to use these methods raises an exception.
The security profile permission affects the following methods of the
CryptoManager object:
• Encrypt()
• Sign()
• GetCryptoModuleInformation()
• GetCertificatesFromSignature()
• GetCertificateStore()
• VerifySignature()
• CheckCertificate()
• Decrypt()

2.2.8.10.
2.2.8.11. Extending all configuration modules
When applied solution works in client-server mode and in case of extension
connection the specific level of security is mentioned or informational base
contains the profiles of casual and safe mode, the "server" part of extension
will be extended in the way as it has been mentioned in appropriate profile.
The following security profile properties affect extending the server part of
an extension:
• Extend all modules check box (in the Full access allowed group) -
when selected, all common server modules can be extended for all ex-
tensions applied using this security profile.
• Modules available for extension property - contains a comma-
separated list of the modules that can be extended.
 • Modules not available for extension property - contains a comma-
separated list of the modules that cannot be extended.
The server part of extension includes:
• Extensions of server methods of managed forms that were created us-
ing annotations (rather than property panel constructor)
• Non-global server common modules

2.2.9. Server cluster security

2.2.9.1. General information
When 1C:Enterprise runs in client/server mode, data security is achieved by
ensuring that 1C:Enterprise data is only accessed using 1C:Enterprise tools.
In this context, a number of major security areas can be defined.

Fig. 11. General data security structure

All client applications and external connections access the 1C:Enterprise
data only through the 1C:Enterprise server cluster. A valid 1C:Enterprise
user name and password is required for access.
The 1C:Enterprise server cluster data is comprised of the infobase and the
internal data. The server cluster is therefore responsible for data security of
the following areas (for area numbering explanation, see fig. 11):
• data exchange between the client and server cluster (1)
• data exchange between the server cluster console and server cluster
(2)
• data exchange between the server cluster and web server (7)
• internal data storage in the server cluster (3)
• data exchange within the server cluster (4)
The infobase is stored in a database. Infobase security, as well as data secu-
rity during exchange between the server cluster and the database server, is
provided by the DBMS (5).
When connection to an infobase through a web server, data security during
exchange between the client application and web server is provided by the
web server (6).

2.2.9.2. Security of data exchanged between

client and server cluster

2.2.9.2.1. General information

Security of data exchanged between the client and server cluster is achieved
due to data encryption. Three security levels are available:
• Never
• Connection only
• Always
The level off is the lowest, the level is constantly the highest-. Secure
TCP/IP connection with RSA and Triple DES encryption is used.

2.2.9.2.2. "Always" security level

The Always security level provides full-range protection for data (including
passwords) being exchanged between the client and the server cluster.
IMPORTANT! This security level is resource-intensive and may result in
significatly decreased performance.
The client and server cluster interaction protocol is outlined below.

Fig. 12. "Always" security level

The same interaction protocol is used for the cluster manager (rmngr) and
for the working process (rphost): once the connection is established, the
first data exchange procedure is RSA encrypted while all subsequent data
exchange uses Triple DES encryption.
The security level is specified when an infobase is created. This information
is stored both on the client (in the infobase list) and in the server cluster (in
the server registry). You cannot change the security level of an infobase
after it has been created. The client application can, however, request that
the security level be increased.
It is for this reason that when a connection is established, the client gener-
ates a private and a public RSA keys, and sends the public key and security
level specified on the client for this infobase to the server cluster. This is
the target security level.
The server cluster selects the higher security level from the one sent by the
client and one specified for this infobase in the cluster registry. This is the
actual security level. Then, the server cluster generates a Triple DES session
key and sends it (together with the actual security level) to the client, after
encrypting it with the client's public key.
All subsequent data exchange is performed at the actual security level. Both
the client and the server encrypt the transferred data using the Triple DES
session key.
2.2.9.2.3. "Connection only" security level
The Connection only security level provides partial protection for data
(passwords only) being exchanged between the client and the server cluster.
This security level offers good balance between safety and performance.
The infobase data is sent without encryption. This constitutes a negligible
performance impact.
However, the crucial information (passwords) are sent in encrypted form.
Therefore, any malicious user that intercepts the data stream will not be able
to read any significant amount of the infobase data. Password encryption
prevents the malicious users to pass infobase authentication in order to gain
full data access or perform any infobase operations.
The client and server cluster interaction protocol is outlined on fig. 13.

Fig. 13. "Connection only" security level

Once the connection is established, the first data exchange procedure is RSA
encrypted while all subsequent data exchange uses Triple DES encryption
until the authentication is completed. All data exchange after that moment is
not encrypted.

2.2.9.2.4. "Never" security level

The Never security level offers the weakest protection at the lowest perfor-
mance cost. Absolute majority of the data is sent without encryption.
The client and server cluster interaction protocol is outlined below.

Fig. 14. "Never" security level

Once the connection is established, the first data exchange procedure is RSA
encrypted. All data exchange after that moment is not encrypted.
If the client application and the server cluster are located on the same com-
puter and the security level is set to Never, all data is sent without encryp-
tion.

2.2.9.3. Security of data exchanged between

server cluster console and server
cluster
Security of data exchanged between the server cluster console and server
cluster is achieved due to data encryption. The above security levels are
used: Never, Connection only, and Always.
The server cluster console interacts with the server agent (ragent process).
The target security level is specified on server agent startup. The server
agent selects the highest security level from the security level specified on
startup and security levels of all clusters located on the central server. This
is the actual security level. The cluster security level is specified when the
cluster is created (manually or programmatically).
2.2.9.4. Security of data stored in server cluster

2.2.9.4.1. General information

A server cluster uses internal data, such as a list of server clusters, cluster
registries, and more. All internal data is stored in files in two directories:
• Application data directory
• Temporary files directory
The general policy of handling the internal data is that only the cluster man-
ager (rmngr) and the server agent (ragent) can access internal data of the
server cluster. Working processes (rphost) only access internal data
through the cluster manager, because these processes can run fragments of
configuration code making them potentially hazardous.

2.2.9.4.2. Security of application data directory

During the 1C:Enterprise server cluster installation procedure, a directory
dedicated to storage of 1C:Enterprise server cluster files is created in the
application data directory.

Fig. 15. Application data directory

Full rights for this directory are granted to the user account USR1CV8 that
runs the server agent by default. No other users are allowed to access this
directory. The server agent starts the cluster manager under the same user
account that was used to start the server agent.
The server agent also starts working processes. By default, a working pro-
cess is started under the same user account that was used to start the server
agent. However, an additional operating system user account can be created
that will start working processes only. This technique is used to prevent the
configuration code from directly accessing the internal data.
To start a working process under a different user account (not the user ac-
count that was used to start the server agent), you need to place swpuser.ini
file in the application data directory for the server agent user.

2.2.9.4.3. Security of temporary files directory

Temporary files data is protected in a different manner. As the system tem-
porary files directory is a shared directory, the access rights for each tempo-
rary file are granted separately.
When a temporary file is created by the 1C:Enterprise server cluster, the
USR1CV8 user is granted full rights to the created file. No other users are
allowed to access this file. This means that all the data stored in temporary
files is protected from unauthorized access.

Fig. 16. Access restriction

2.2.9.4.4. Encryption of passwords stored in internal

data of server cluster
Server cluster administrator passwords and infobase access passwords are
encrypted and stored in the server cluster. SHA1 and AES128 algorithms are
used for password encryption.
 • SHA1 - is used to store passwords that the 1C:Enterprise system
checks (for example, the password of the cluster administrator, the
administrator of the Central server). The passwords themselves are not
stored and therefore cannot be recovered. Only their checksums are
stored for comparison against the checksums of the entered pass-
words.
• AES128 - is used to store passwords, which should recover the origi-
nal text (for example, passwords of access to the database).

2.2.9.5. Security of data exchanged within

server cluster
The security of data exchanged within a server cluster (for example, be-
tween working processes and the cluster manager) is achieved due to data
encryption. The above security levels are used: Never, Connection only,
and Always.
The cluster security level is applied to interactions between a working pro-
cess and the cluster manager. The security level applied for interaction be-
tween the server agent and cluster manager is the highest security level se-
lected from the security level used for server agent startup and the security
level of the cluster served by this manager.

2.2.9.6. Security of data exchanged between

server cluster and DBMS
Security of the data channel between a server cluster and the DBMS is pro-
vided by the DBMS functionality. All the supported database management
systems allow for their client components located in a cluster to encrypt the
traffic between the components and the DBMS itself. All the supported da-
tabase management systems can exchange data over SSL.

2.2.9.7. Security of data exchanged between

client and web server
SSL or TLS encryption protocols are used to secure the channel between a
web client (or a thin client) and the web server.
These protocols are supported by web server HTTPS connection. This re-
quires that a valid server certificate is available on the server, guaranteeing
authenticity of the server public key used for data encryption. Client certifi-
cates guaranteeing the client authenticity can be also used.
It is important to remember the restrictions related to the operating system
used to run the application: for example, the Linux client does not support
client certificates from the Windows certificate store.
2.2.9.8. Security of data exchanged between
web server and server cluster
Security of the data channels between the server cluster and web server is
provided by data encryption algorithms available in 1C:Enterprise: RSA
and Triple DES.
Connection between a cluster and a web server is only secured by the clus-
ter in accordance with the properties of the connected infobase.

2.2.9.9. Central server and cluster

administrators
1C:Enterprise server cluster is administrated either with or without adminis-
trator authentication.
If authentication is disabled, any user connected to the central server of the
cluster can perform any administrative tasks both on the central server and
on any cluster on this server. By default, administrator authentication is
disabled when a 1C:Enterprise server cluster is installed.
To restrict the number of users allowed to perform administrative tasks, you
can create separate administrator lists for the central server and for each
cluster on this server. The areas of authority of central server administrators
and cluster administrators do not overlap.
Users authenticated as central server administrators can perform administra-
tive tasks on the central server. However, to perform any administrative
tasks on a specific cluster, the user must be authenticated as administrator of
this cluster. Authentication as the server administrator is not required for
this purpose.
The central server/cluster administrator authentication is enabled automati-
cally as soon as at least one administrator is added to the central serv-
er/cluster administrator list.
If authentication is enabled, users not authenticated as central server admin-
istrators can only view or modify the central server connection parameters
in the server cluster administration console.
User not authenticated as cluster administrators can only view cluster prop-
erties. These users can also create objects in a cluster, infobase, etc. using
the 1C:Enterprise language expressions, but they cannot register these ob-
jects in the cluster.

2.2.10. Infobase locks

To ensure consistent interaction with infobases, 1C:Enterprise relies on a
locking mechanism for concurrent work with these components:
• Configuration
 • Infobase
• Database
The mechanism principle is described in the section covering the server
cluster administration utility.
Two types of locks are implemented: shared and exclusive. Shared locks
support multiple concurrent sessions. Exclusive locks are used when you
need to prevent data from being changed by other sessions.
System administrators need to clearly understand in which events the exclu-
sive locks (exclusive mode) are required. In some situations, the exclusive
locks for configuration and infobase are enabled and disabled automatically
(see below). The exclusive database lock may be enabled or disabled both
automatically and manually by calling the SetExclusiveMode() meth-
od.
Please note that these locks are intended for database access control in
1C:Enterprise. For example, enabling the exclusive lock for a database will
not prevent third-party applications from accessing the database because
their access methods do not rely on 1C:Enterprise mechanisms.
More on exclusive locks:
• The - on the configuration is set by the system at the start of Designer
and ensures the inability to connect to the same information base of
several designers.
• On an information base -means that there can only be one session of
any kind. The lock is enabled when:
 The database configuration is updated
 The infobase is restored from files
 The infobase is dumped to files
 An initial infobase image is created
 The infobase is converted for a new platform version
 Test or repair procedures are started
• Database lock - only allows one Designer session and one arbitrary
session The lock is enabled when:
 When you run the method InstallExclusiveMode () -is
required when you want to make consistent changes to the data-
base, but the changes you make cannot be made in a single trans-
action. (for example, when mass deleting objects from a large in-
fobase).
 Documents are posted in batch (only for the thick client)
any internal infobase connections are open, these connections will not pre-
vent you from enabling the exclusive mode (both for the infobase and the
database).
If you enable the exclusive mode while any sessions (with the exception of
cluster console sessions) are open, these will prevent you from enabling the
exclusive mode since each session specifies an active user. Moreover, when
you enable the exclusive mode, all infobase connections with no sessions
assigned will be terminated implicitly. If the exclusive mode is enabled for
infobase or database access, no new sessions can be opened.
If any web servers are connected to this infobase, enabling the exclusive
access will result in requests sent to these servers to clear the connections
pool.

2.2.11. Working process load

statistics
For each working process, the server cluster calculates a set of parameters
that describe the load of this working process. All these parameters are cal-
culated for an approximate 10-minute period:
• Average server cluster response time
• Average time spent by server cluster
• Average time spent by DBMS
• Average time spent by client
• Average time spent by lock manager
• Average number of client threads
The average server cluster response time is the time spent by the server
cluster to process one client connection. It is comprised of 4 components:
• The time spent by the working process
• The time spent by DBMS
• The time spent by the client (provided that control was returned to the
client)
• The time spent by lock manager
A working process handles each client connection in a separate thread. So, a
working process can run multiple client threads at the same time. Generally,
the number of such concurrent threads is less than the number of connec-
tions (because not all the connections are permanently active). The average
number of client threads indicates the 24-hour average number of threads
processed by the server simultaneously.
2.2.12. Cluster monitoring
system
To ensure uninterrupted server cluster operation, all cluster components
must be monitored and the arising problems must be fixed without delay.
To address this issues, cluster monitoring subsystem is implemented in the
server cluster. The subsystem collects cluster process status information on
a regular basis. Generally, "process" means any server cluster component:
server agent (ragent), server manager (rmngr), or working process
(rphost). The term "process" will be clarified in the context where neces-
sary. The list of collected and analyzed parameters includes:
• Server connection check
• Calculation of available performance level for a working process
• Calculation of memory amount used by the process (applicable to
cluster manager and working process)
• Monitoring of working processes removed from the cluster registry
Some operations (such as process memory check) are performed through
the server agents, which also tests operability of these agents.
Checks are made every 10 seconds. The connection check timeout is 20
seconds. The checks are performed consecutively, meaning that a check
does not start until the previous check has completed. Negative check re-
sults are written to the technological log using the ATTN event.
If the results of collected data analysis (excluding the available performance
level) indicate that the process has problems, the process may be terminat-
ed. In this event, a termination dump will be generated. To have the prob-
lem processes terminated and the termination dumps generated, enable the-
Kill problem processes option in the cluster properties. Processes running
on additional servers are terminated by sending requests to the correspond-
ing cluster agents.
Termination dumps are generated in accordance with the general
1C:Enterprise dump generation rules.
• Under Windows, settings stored in logcfg.xml are used.
• Undex Linux, common OS settings are used. Dump generation starts
when SIGSEGV signal is sent to the process.

Only the central server agent can send requests to the cluster processes. The
additional server agents are used to send requests to the processes running
on additional working servers. If a server agent connection error occurs, the
error messages are recorded to the technological log of the central server
agent.
Server calls (recorded in the technological log as CALL events) occur on a
regular basis during normal operation of the server cluster. Errors of various
nature (recorded in the technological log as EXCP events) can occur during
these calls. However, an EXCP event recorded in the technological log does
not automatically mean an actual server error. For example, when selecting
a working port from the available port range, each occupied port generates
an EXCP message although no actual error has occurred.
When monitoring working processes removed from the cluster registry, a
process is considered to have problems if it does not close for 20 minutes
after removal from the cluster registry.
The described system of monitoring of servers clusters might help when
solving the following problems:
• "Hangup" of server process in computer memory both during the pro-
cess of operation and attempt to complete the process.
• Obsolete information on memory used by a working process displayed
in the cluster console
• Increased memory consumption by cluster processes.

2.2.13. Location of cluster

manager service files
If the option to run the 1C:Enterprise server as a service was selected during
1C:Enterprise installation, the server agent will start running during the in-
stallation. The service will run under the user account selected during the
installation but the internal files of the server cluster will be located in di-
rectory <1C:Enterprise installation directory>\srvinfo (command-line
parameter /d will be explicitly specified in the service parameters).
If the option to run the 1C:Enterprise server as an application was selected
during 1C:Enterprise installation, the server will not run during the installa-
tion. You will need to start the server agent manually after the installation is
completed. If you do not use the command-line parameter /d, the internal
files of the server cluster will be located in default directory:
%USERPROFILE%\Local Settings\Application Data\1C\1cv8
(%LOCALAPPDATA%\1C\1cv8 for Windows Vista or later).
IMPORTANT! If a cluster is already created on the central server, you
should always verify that the specified path to the directory with server
cluster internal files is correct when you change server agent start method
(as a service, or as an application) or when you change the user account
used to run the server agent. If the server agent cannot find the list of clus-
ters during startup, it creates a new cluster on the server.
Under Linux, the internal files of the server cluster are stored in
/home/usr1cv8/.1cv8/1C/1cv8 (short name, - ~/.1cv8/1C/1cv8).

2.3. Running under Linux

When 1C:Enterprise server cluster runs on Linux computers, the following
limitations apply:
• Working processes of the 1C:Enterprise server cluster cannot interact
with Microsoft SQL Server database management system
• Working processes of the 1C:Enterprise server cluster cannot interact
with COM objects Server modules interacting with COM objects can
be compiled but an attempt to run such a module will result in an error
message
• Kerberos authentication (the Windows version supports the NTLM
protocol that includes authentication without PDC) and/or authentica-
tion with user name and password is supported
• The InternetConnection object functionality is not available
To be able to use certain features, the 1C:Enterprise server running under
Linux requires specific libraries.
Chapter 3.
Installing system
components

3.1. Installing 1C:Enterprise

server
1C:Enterprise is a collection of software modules intended for development
and usage of enterprise business accounting and automation solutions (con-
figurations), as well as configurations or collections of configurations.
1C:Enterprise software modules are universal and compatible with any con-
figuration (within the scope of the corresponding License Agreement).
A security driver preventing unauthorized access is installed together with
1C:Enterprise.
The installer makes it possible to install multiple 1C:Enterprise versions on
a single computer, select components to install, and choose a version of
1C:Enterprise server installation.

3.1.1. General information on

installation procedure
1C:Enterprise installation procedures for Microsoft Windows operating
systems (hereinafter, Windows) and Linux operating systems (hereinafter,
Linux) are significantly different.
For Windows-based installations, a standalone installer is used.
No such installer is available for Linux. For detailed installation instruc-
tions, see the respective sections. When the 1C:Enterprise server is installed
under Linux, the server will not be started after installation.
Before installation, please make sure that your computer is virus-free, the
hard drive does not contain any errors, and enough disk space is available
for the installation.
NOTE. During the installation, you may need the distribution package of
the operating system running on the computer. You may also need the local
or network administrator rights.
3.1.2. Windows Installer
3.1.2.1. Available installers
The following installers are available:
• 1C: Enterprise 8 -allows you to install any component of the system,
except for the 64-bit server of "1C: Enterprise" .
• 1C: Enterprise 8 The thin client -allows you to install only the
components required to access the 1C: Enterprise server and the thin
client itself.
• 1C: Enterprise 8 (x86-64) -allows you to install a 64-bit 1C: Enter-
prise server.
All the installers offer similar user experience; therefore, only general in-
formation for 1C Enterprise 8 installation is provided below.

3.1.2.2. General information on installer

An installation wizard carries out the installation procedure. You can pro-
ceed through the wizard pages by clicking Next >>. To start the wizard,
run setup.exe from the directory containing the distribution package you
have selected. On every page of the wizard, you will be prompted to pro-
vide some information required for 1C:Enterprise installation.
Every wizard step is briefly described below.
NOTE. If you run setup.exe using /S option, 1C:Enterprise will be in-
stalled in silent mode based on the settings stored in 1CEStart.cfg. If this
file is not available, the default installation settings will be applied instead.
3.1.2.2.1. Welcome screen
This is the starting window of the 1C:Enterprise installation wizard.

Fig. 17. Welcome screen

3.1.2.2.2. Selecting components

On this page, you need to select the components to install. The component
list depends on what exactly you need to have installed. Some standard
installation scenarios are described below.

Fig. 18. Selecting components

If a component needs to be installed, select it in the list. If a component is
not required, do not select it. To select a component, click an icon to the left
of its name (or press spacebar). Select the item you need (see fig. 19).

Fig. 19. Component installation menu

The components to be installed or skipped are marked with different icons;
see fig. 20 for example.

Fig. 20. Components to be installed or skipped

A brief explanation of the components is provided below:

Component Brief description

1C:Enterprise Basic 1C:Enterprise components, in-
cluding administration components,
configuration development compo-
nents, thick and thin clients
1C:Enterprise - Thin client Only the thin client components in-
tended for client/server mode
1C:Enterprise - Thin client, file Thin client components, including
mode components for file infobase opera-
Component Brief description
tions
1C:Enterprise server Components of "1C:Enterprise" server,
including administration server, utility
of administration, data accelerator
Web server extension modules Web server extension modules re-
quired for web client and web services
1C:Enterprise 8 server admin- Additional components for adminis-
istration trating 1C:Enterprise server cluster
Additional interfaces User interfaces in various languages
1C: Enterprise 8 configuration Components of the 1C: Enterprise con-
storage server figuration storage server, including the
administration server and the admin-
istration utility
Additional administration func- Administrative Console Utility
tions
1C: Enterprise 7.7 infobase Converter of 1C:Enterprise 7.7 in-
converter fobases
Integrity monitoring Data Integrity Utility
3.1.2.2.3. Selecting default interface language
At the next step, the installer prompts you to select the default interface lan-
guage.

Fig. 21. Selecting interface language

You need to specify one of the interface languages as a default interface
language.
After the installation procedure is completed, the conf.cfg file describing
the default interface language will be created in the C:\Program
Files\1cv8\conf directory.
If you need to use 1C:Enterprise with a non-default interface language,
specify the language at startup using the /L command line parameter.

Interface language Language code

Azerbaijani az
English en
Bulgarian bg
Hungarian hu
Vietnamese vi
Greek el
Georgian ka
Spanish es
Italian it
Kazakh kk
Chinese zh
Latvian lv
 Interface language Language code
Lithuanian lt
German de
Polish pl
Romanian ro
Russian ru
Turkish tr
Ukrainian uk
French fr

3.1.2.2.4. Installing 1C:Enterprise server

If the 1C:Enterprise 8 Server component is selected for installation, a wiz-
ard page will be available. On this page, you can select the 1C:Enterprise
server installation mode and the user to run the server if it is installed as a
Windows service.

Fig. 22. 1C:Enterprise server installation mode

NOTE. If you choose to install the server as a service, you need to specify a
password for the selected user, otherwise the installer will not be able to
start the server.
If 1C:Enterprise is already installed as a Windows service on the computer,
the installer will reinstall the service.

3.1.2.2.5. Installation start

Click Install to start the installation procedure that:
 • Generating the required folders
• Copies files for the selected components
• Creates configuration files
• Registers server software components
• Creates 1C:Enterprise startup shortcut on the desktop
• Starts 1C:Enterprise server if you chose to install the server as a Win-
dows service

Fig. 23. Starting installation

In addition, a separate entry will be created in the Add or Remove Pro-
grams component of the Windows Control Panel for each 1C: Enterprise
version. Example: 1C: Enterprise 8.3 (8.3.3.100).
3.1.2.2.6. Installing a protection driver
After the installation process is completed, the installation wizard prompts
you to install HASP Device Driver to protect you from unauthorized soft-
ware use.-

Fig. 24. Install protection driver

Driver installation is required if a hardware protection key is attached to the
USB port of this computer and:
• The user has a License Agreement for the use of 1C:Enterprise at one
workplace
• The user has an additional License Agreement for the use of
1C:Enterprise at one additional workplace
• The user has a License Agreement for the use of 1C:Enterprise server
NOTE. It is recommended to install the protection driver before the securi-
ty key is attached to the USB port of the computer.
Also, installation of the driver can be performed using the Start menu item
-All Programs -1C Enterprise 8 Advanced --Installing the protection
driver.
When installing the protection driver, a web-based driver management in-
terface is installed automatically. To minimize risks and increase safety for
1C:Enterprise servers and user workstations, it is recommended that you
disable the web-based protection driver interface when installing the driver.
To do this, select the Disable 1C:Enterprise 8 hardware license key fea-
tures that are not used (recommended) check box.
https://its.1c.ru/db/metod8dev%23content:5936:hdoc
3.1.2.2.7. Installation completion
If the installation is successful, the final page of the installation wizard
opens. After clicking the Finish button on this page, the installation is com-
plete.
If the Open Readme file box is checked, a file with information that is
recommended to be read before using this version of the system will be
opened.

Fig. 25. Installation completion

3.1.2.3. Recommendations for component

registration
The installation program performs the registration of certain components
(cluster console, COM connection, etc.). In this case, registration is per-
formed as follows:
• Cluster console The installer performs the registration "for the com-
puter." Registration using the Start menu -item All programs- 1C
Enterprise 8 -Additionally-<Version number> -Registration of
the administration utility of the 1C Enterprise servers
(RegMSC.cmd command file) is performed “for the user”.
• COM connection. The installer register the components for the com-
puter. To register the components for a specific user, use the com-
mand:
regsvr32 -n -i:user comcntr.dll

3.1.3. Typical 1C:Enterprise

installation scenarios
3.1.3.1. On Windows

3.1.3.1.1. General information

This section contains typical examples of 1C:Enterprise components instal-
lation on Windows.
For each installation option, a list of installed components and specific in-
stallation instructions (if any) is provided.

3.1.3.1.2. Cluster core server installation

The installation program copies the necessary files to the computer and can
configure the launch of the central server agent as an application or as a
Windows OS service. To install a server cluster, you need to select the fol-
lowing components: 1C: Enterprise server, 1C: Enterprise server ad-
ministration 8.
If you have chosen to install the 1C: Enterprise server as a Windows service
(recommended installation method), then you should select a user and enter
a password for it. By default, USER1CV8 is specified. The said user can be
created upon initial installation of 1C:Enterprise server cluster. Make sure
that the user specified to start the service is assigned all access rights de-
scribed. If the user is created by the installation program-, the said access
rights are assigned by default. If the password is empty, the installation pro-
gram will not be able to start the server. Moreover, the selected user is any-
way assigned all rights required to access a directory of server internal files.
The server cluster will be launched during the installation process. After the
installation is complete, the cluster will be fully operational.
If you chose the option of installing the server as an application, then after
the installation is complete, you must start the server cluster yourself.
IMPORTANT! Depending on the server installation option (service or
application), different directories will be selected to host the server files.

3.1.3.1.3. Add server to server cluster

This scenario is used if you need to add another physical server to the exist-
ing server cluster (for example, to improve performance). Suppose that an
expandable server cluster is located on COMP1, and an additional working
server needs to be installed on COMP2. Then to add a working server you
need to do the following:
• install the 1C: Enterprise server on the COMP2 computer.
• Then connect via the server console to the server cluster (COMP1) to
which you want to add the server.
• Add a new working server (on the COMP2 computer) to the cluster lo-
cated on the COMP1 computer.
• Specify the functionality assignment rules for COMP2 working server,
if necessary.
After the completion of the adding process, it is advisable to remove the
registration of the main server of the cluster on the computer that was added
as an additional server of the cluster (COMP2).
Cluster management actions can be performed using the cluster console
(links to work with which are given above), or using the server and admin-
istration utility.

3.1.3.2. On Linux

3.1.3.2.1. General information

This section contains typical examples of installing 1C:Enterprise compo-
nents on Linux. Installation is carried out using the package manager avail-
able in your operating system.
The 1C:Enterprise distribution package for Linux consists of several pack-
ages. These packages are used both to install client applications and to in-
stall a server. The package file name consists of several parts: <prefix>-
<component>-<version>-<architecture>.<extension>. Values of the
name parts reflect the processor architecture (i386 or x86-64) or the version
of the package manager (RPM or DEB):
• <prefix>:
 RPM version: 1C_Enteprise83-
 DEB version: 1c_enteprise83-
• <component>:
 client- 1C:Enterprise client applications (thick client and thin cli-
ent)
 thin-client -1C:Enterprise thin client (file mode of the infobase is
not supported)
 common - 1C:Enterprise common components
 server -components of the "1C: Enterprise" server and integrity
monitoring utility;
  ws- adapter for publishing 1C: Enterprise Web services on an
Apache HTTP Server 2.0, 2.2 or 2.4 web server;
 crs- configuration storage server
 Component name may end with the -nls suffix. This means that
the package with this name contains additional locale resources
(except for Russian and English) for the corresponding package.
The server component is located in two files: server (the server it-
self) and server-nls (additional locale resources).
• <version>- the full version number of the 1C: Enterprise system to
which the package belongs. So, for “1C: Enterprise” version
8.3.12.1440 in the package name there will be a line of the form
8.3.13-1440.
• <architecture>:
 32-bit architecture: i386
 64-bit architecture, RPM version -x86-64
 64-bit architecture, DEB version - amd
• <extension>:
 RPM version: rpm
 DEB version: deb
If necessary, the package file name is generated according to the above
rules. If you need to specify the name of the package being used (installed),
it will be specified using the component name. For example, the name of
the common package for RPM option, x86 architecture and 8.3.12.1440
version is: 1C_Enterprise83-common-8.3.12-1440.i386.rpm.
During installation, consider the following package dependencies:
• common has no dependencies.
• server depends on common.
• ws depends on common.
• crs depends on common, server, and ws.
• client - depends on server;
• thin-client - has no dependencies. Thin-client does not require instal-
lation of other packages from 1C: Enterprise. Conflicts with thecom-
mon component. Can be installed or component thin-client or other
components.
• Locale resource packages depend on their components.
Therefore, in order to successfully install a package, you must first install
all the packages on which it depends. For example, to install the 1C: Enter-
prise server, you must first install the common component and then -the
server.
3.1.3.2.2. Installation of a working server a
In order for a working cluster server to be deployed on a computer, the fol-
lowing packages must be installed:
• common (and common-nls resources if necessary)
• server (and server-nls resources if necessary)
If it is assumed that the computer should be used to publish the 1C: Enter-
prise Web services, then the ws component should be installed. The server
and ws components are interdependent. Accordingly, they can be installed
on the same computer both together and separately.
During the installation of the 1C: Enterprise server components, an operat-
ing system user is created with the name usr1cv8, under which account
server 1C: Enterprise server processes will be executed. Immediately after
installing the server component, the “1C: Enterprise” server is ready for
launch.
Installation must be performed on behalf of the root user.

3.1.3.2.3. Add server to server cluster

This scenario is used if you need to add another physical server to the exist-
ing server cluster (for example, to improve performance). Suppose that an
expandable server cluster is located on COMP1, and an additional working
server needs to be installed on COMP2. Then to add a working server, fol-
low these steps:
• Install the 1C: Enterprise server on the COMP2 computer.
• Connect via the server console to the server cluster (COMP1) to which
you need to add a server.
• Add a new working server (on the COMP2 computer) to the cluster lo-
cated on the COMP1 computer.
• Specify the functionality assignment rules for COMP2 working server,
if necessary.
After the completion of the adding process, it is advisable to remove the
registration of the main server of the cluster on the computer that was added
as an additional server of the cluster (COMP2).
Cluster management actions can be performed using the cluster console
(links to work with which are given above), or using the server and admin-
istration utility.

3.1.3.2.4. Web client

If you need to use the web client to access the database, you need to install
the following packages on the computer with the web server:
 • common, and, if necessary, common-nls resources;
• server (and server-nls resources if necessary)
• ws, and if necessary, and resources ws-nls.
Installation must be performed on behalf of the root user.
Publishing the web client should be done using the webinst command line
utility.

3.1.4. Data accelerator settings

NOTE. Available only for CORP licenses.
They suppose two main options of Data accelerator deployment:
1. If servers cluster contains one operational server, the service of Data
accelerator will be launched on this server by default. If case of such
deployment option usage it is necessary to take into account that over-
all amount of available operative memory on working server should
be calculated taking into account the information on the usage of
memory by "1C:Enterprise" servers cluster and requirements to Data
accelerator memory. In this case the overall amount of operative
memory set at operational server should be not less than the sum of
these indexes ( requirements of servers cluster and Data accelerator).
If for example the cluster of "1:CEnterprise" servers uses 5 gygabites
of memory in casual mode, the adding to this servers the data acceler-
ator makes minimum requirements for this server equal 69 gygabites
of memory in case of recommended - 520 gygabites.
2. If "1C:Enterprise" servers clusters operate at several working servers
it is recommended to launch Data accelerator at dedicated working
servers with the amount of operative memory, which corresponds to
system requirements. The placement of data accelerator service at se-
lected working service is done taking into account the requirements of
functionality value and will be reviewed further in this section.
Bear in mind that physical operative memory is formed by standard
memory modules and should be not less than calculation value for selected
deployment option.
Besides setting required amount of operative memory and setting the re-
quirements of functionality value be sure to make some settings of opera-
tional system at working server:
• On Windows OS: it is necessary to make forced setting of swap file.
Minimum swap file size should be not less than the amount of opera-
tive memory settled at working server. The recommended swap file
size should be - 512 gygabites and more.
 • On Linux: change memory control strategy. For this, be sure to settle
systemic parameter vm.overcommit_memory to 1 value. It can be
done using the following command (user needs to have superuser
password): sudo sysctl -w vm.overcommit_memory=1.
In case if the configuration of several working servers is being used, the
placement of Data accelerator service at required working server is done
with the help of functionality requirements value. One requirement (Re-
quirement 1) directly controls the Data accelerator service. Another re-
quirement (Requirement 2) is needed only in case if selected working server
supposes the operation of Data accelerator service without the operation of
other services of servers cluster. After these requirements creation, they
must be applied.
The requirements of functionality value:
• Rule 1:
 Requirement object: Data accelerator service.
 Rule type: Assign.
 Infobase name: do not specify.
 Additional parameter value: do not specify.
• Rule 2:
 Requirement object: Any requirement object.
 Rule type: Do not assign.
 Infobase name: do not specify.
 Additional parameter value: do not specify.

3.1.5. Installing and configuring

additional software
3.1.5.1. On Linux

3.1.5.1.1. Configuring Kerberos Authentication

This section describes how to configure Kerberos authentication of the 1C:
Enterprise server for a basic system consisting of three computers: domain
controller, central server of the 1C: Enterprise cluster, workstation.

Base system description

The base system contains the following computers:
• Active Directory Domain Controller:
 computer name (hostname) -main;
  IP address -192.168.29.150;
 domain name- krb.local;
• Central server cluster "1C: Enterprise":
 Operating system: Fedora 7;
 hostname - srv1c;
 IP address - 192.168.29.151;
 the MIT Kerberos implementation is installed, supporting the
RC4-HMAC algorithm (krb5-workstation package);
• Work station.

Setting up a domain controller

This section assumes that the Active Directory domain controller is config-
ured and running. Based on this, to configure Kerberos authentication, you
need to perform the following steps:
3. In the DNS server, you must "manually" register all Linux computers
Registration of Windows computers occurs automatically when they
are included in the domain. In our case, “manually”, you need to reg-
ister the central server of the 1C: Enterprise cluster (since it runs the
Linux version of the server), and include the workstation in the do-
main (it will be registered automatically).
4. After that, create a domain user account with which authorization re-
quests to the 1C: Enterprise server will be associated. In our example,
this will be user usr1cv8 with password pass1cv8. In the proper-
ties of this account, uncheck Use DES encryption types with this
account. If your implementation of Kerberos does not support the
RC4-HMAC encryption algorithm, then the checkbox must be
checked.
5. Then, for the user of the domain usr1cv8, you should generate a file
with a secret key. To do this, use the ktpass utility, which is part of
the Windows Support Tools (it can be found in the SUPPORT subdi-
rectory of the Microsoft Windows installation disc).
At the command prompt, you must run the ktpass utility. For the ex-
ample used, the command line should look like this:
C:\>ktpass -princ usr1cv8/[email protected] -mapuser
usr1cv8 -pass pass1cv8 -out usr1cv8.keytab
C:\>

If the RC4-HMAC algorithm is not supported, the command line

should look like this:
C:\>ktpass -crypto DES-CBC-CRC -princ
usr1cv8/[email protected] -mapuser usr1cv8 -pass pass1cv8 -
out usr1cv8.keytab
C:\>

As a result, the file usr1cv8.keytab will be created in the current di-

rectory (in the example -it is the root of the C drive :), and the user
name usr1cv8 / srv1c.krb.local will be associated with the user
usr1cv8.
NOTE 1. It should be noted that in case the “1C: Enterprise” version 8.3
server will work on behalf of the user usr1cv82, then you should use the
name of the service member usr1cv82 / srv1c.krb.local. In this case, the
domain user name may remain unchanged (usr1cv8 in this example).
NOTE 2. When generating a file with a secret key (using the ktpass utili-
ty), the full name of the computer (on which the 1C: Enterprise server is
installed) in the name of the service member (the -princ parameter) should
be in lower case. Otherwise, the operation of the authentication mechanism
is not guaranteed.
In the pass parameter, the password of the user account of the domain
usr1cv8- pass1cv8 is passed.
The out parameter specifies the name of the file with the key. In our
case, this is usr1cv8.keytab. However, if the 1C: Enterprise version
8.3 server is running on behalf of the user usr1cv82, then you should
specify usr1cv82.keytab as the file name with the key.

Configuring the central server of the 1C:

Enterprise cluster
In this section, it is assumed that the 1C: Enterprise server cluster is already
installed and running on the central server of the cluster.
First of all, you should specify the DNS server for the central cluster server.
This should be a DNS domain controller.
NOTE. The configuration process depends on the specific Linux distribu-
tion. Now you should open /etc/resolv.conf for editing and manually spec-
ify the domain controller IP address in this file.
As a result, the file should contain the following lines:
nameServer 192.168.29.150
search krb.local

Then you should check the DNS operation. To do this, run the ping com-
mand:
srv1c:~#ping main -c 1
PING main.krb.local (192.168.29.150)56(84)bytesofdata.
64 bytes from 192.168.29.150: icmp_seq=1 ttl=128 time=0.177 ms

--- main.krb.localpingstatistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.177/0.177/0.177/0.000 ms
srv1c:~#

IMPORTANT! For computers participating in the authentication process, a

large discrepancy between system clocks is not allowed, since authentica-
tion packets (tickets) have a limited duration.
Accordingly, it is necessary to synchronize the time of the central server of
the cluster with the domain controller. To do this, use the ntpdate com-
mand:
srv1c:~#ntpdate main
4 Jun 11:51:53 ntpdate[2527]: step time Server 192.168.29.150
offset -56.766439 sec
srv1c:~#

Now you need to configure Kerberos. To do this, edit the file

/etc/krb5.conf. In this case, we need the NETBIOS name of the domain
controller. It is usually an uppercase domain name. Therefore, in our case,
the NETBIOS name will be KRB.LOCAL. As a result, the /etc/krb5.conf
file should look like this:
srv1c:~#cat/etc/krb5.conf
[logging]
Default = FILE:/var/log/krb5libs.log
Kdc = FILE:/var/log/krb5kdc.log
admin_Server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = KRB.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = false
default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac

[realms]
KRB.LOCAL = {
kdc=main.krb.local:88
default_domain=krb.local
}

[domain_realm]
krb.local = KRB.LOCAL
.krb.local = KRB.LOCAL
KRB.LOCAL = KRB.LOCAL
.KRB.LOCAL = KRB.LOCAL

[kdc]
Profile = /var/kerberos/krb5kdc/kdc.conf

[appdefaults]
Pam = {
Debug = true
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = false
krb4_convert = false
}

srv1c:~#

If the RC4-HMAC algorithm is not supported, then the de-

fault_tkt_enctypes and default_tgs_enctypes parameters should be as
follows:
...
default_tkt_enctypes = des-cbc-crc des-cbc-md5
default_tgs_enctypes = des-cbc-crc des-cbc-md5
...

Now you need to check the operation of the authentication system. To do

this, run the command kinit <name>, where name- is the name of an arbi-
trary user registered in the krb.local domain. In the example, this will be
 the user name. Then the password of this user is entered, and the com-
mand is completed by pressing the Enter button. If after this the program
does not display any messages, then everything is done correctly.
You can verify this with the klist command. As you can see, we received a
so-called ticket-granting ticket from the KDC (Key Distribution Center-,
key distribution center, this function is performed by the domain controller).
After that, use the kdestroy command to clear the local ticket cache to re-
turn to its original state.
srv1c:~#kinit user
Password for [email protected]:
srv1c:~#klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]

Valid starting Expires Service principal

06/04/08 11:29:21 06/04/08 21:28:28 krbtgt/[email protected]
renew until 06/05/08 11:29:21

Kerberos 4 ticket cache: /tmp/tkt0

Klist : You have no tickets cached
srv1c:~#kdestroy
srv1c:~#

Then, in any way, you should transfer the file with the secret key
usr1cv8.keytab, obtained during the configuration of the domain control-
ler, to the central server of the 1C: Enterprise cluster. This file should be
copied to the directory where the 1C: Enterprise server is installed (by de-
fault it is /opt/1C/v8.3/i386 or /opt/1C/v8.3/x86_64 for the 64-bit serv-
er version) and install rights and owner of the file, as shown below:
srv1c:~#cd /opt/1C/v8.3/i386
srv1c:i386# chown usr1cv8:grp1cv8 usr1cv8.keytab
srv1c:i386# chmod 600 usr1cv8.keytab
srv1c:i386#

If desired, the file can be placed in any other place; you only need to change
the variable SRV1CV8_KEYTAB in the configuration file to point to the new
location of the file with the secret key.
After that, using the klist command, you must verify that all settings are
correct. To do this, run the command:
srv1c:~#klist -e -k -t /opt/1C/v8.3/i386/usr1cv8.keytab

For the example used, the result of the command should look like this:
Keytab name: FILE:/opt/1C/v8.3/i386/usr1cv8.keytab
KVNO Principal
---- -------------------------------------------------------------
13 usr1cv8/[email protected] (ArcFour with HMAC/md5)

If the RC4-HMAC algorithm is not supported, the result of the command

execution will be as follows:
Keytab name:FILE:/opt/1C/v8.3/i386/usr1cv8.keytab
KVNO Principal
---- -------------------------------------------------------------
13 usr1cv8/[email protected] (DES cbc mode with RSA-MD5)

It can be seen that the file with the secret key contains exactly what we need
(the Principal column indicates the service name that we specified when
creating the file with the secret key, and the correct encryption algorithm (
ArcFour with HMAC / md5 for RC4-HMAC or DES cbc mode with
RSA-MD5 for DES)).
Next, you should verify that Kerberos can work without a password using a
secret key. Using the kinit command, we specify that the authentication
information from the file should be used (in our case
/opt/1C/v8.3/i386/usr1cv8.keytab or
/opt/1C/v8.3/x86_64/usr1cv8.keytab for 64-bit server version) and read
the key for the service usr1cv8/[email protected] from there.
As a result, the kinit program should work without any messages, do not ask
for any passwords and return control to the command line:
srv1c:~#kinit -k -t /opt/1C/v8.3/i386/usr1cv8.keytab
usr1cv8/[email protected]
srv1c:~#

Now consider the results of the work with the command klist. If successful,
information similar to the following should be displayed:
srv1c:~#klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: usr1cv8/[email protected]

Valid starting Expires Service principal

06/04/08 11:44:54 06/04/08 21:43:58 krbtgt/[email protected]
renew until 06/05/08 11:44:54

Kerberos 4 ticket cache: /tmp/tkt0

klist: You have no tickets cached
srv1c:~#

If any invalid settings are found, this command will display:

srv1c:~#klist
klist: No credentials cache found (ticket cache
FILE:/tmp/krb5cc_1000)
Kerberos 4 ticket cache: /tmp/tkt1000

klist: You have no tickets cached

srv1c:~#

If the health check was successful, it means that, from now on, the 1C: En-
terprise cluster server is able to process authentication requests. In this case,
the server restart is not required, except in the case when the location of the
file with the secret key was changed in the configuration file.

3.2. Installing database servers

As a database server "1C: Enterprise" can be used:
• IBM DB2 (for Windows and Linux);
• Microsoft SQL Server (only for Windows);
• Oracle Database (for Windows and Linux);
• PostgreSQL (for Windows and Linux).

3.2.1. Installing IBM DB2

The installation of the database server is made from IBM DB2 distributives.
The IBM DB2 versions supported by the 1C: Enterprise system are pub-
lished on the website: https://1c-
dn.com/library/system_requirements/.http://v8.1c.ru/requirements/
To facilitate the configuration of IBM DB2 for working with the 1C: Enter-
prise platform, IBM DB2 introduced the value 1C for the group registry
variable DB2_WORKLOAD
If you specify DB2_WORKLOAD = 1C, IBM DB2 automatically config-
ures all the necessary registry variable values to optimize the work of DB2
with the 1C: Enterprise platform.
The value of the registry variable is set using the command:
db2set DB2_WORKLOAD=1C

After setting the 1C value for the DB2_WORKLOAD group registry variable,
you must restart the database server.
NOTE 1. For more details on the purpose of the IBM DB2 profile registry
variables, see the IBM DB2 documentation at:
http://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/c
om.ibm.db2.luw.admin.regvars.doc/doc/c0012181.html.
 NOTE 2. For a more detailed description of the syntax of the db2set com-
mand, see the IBM DB2 documentation at:
http://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/c
om.ibm.db2.luw.admin.cmd.doc/doc/r0002025.html.
To find out which values of registry variables will be used when setting the
value of DB2_WORKLOAD = 1C, you can use the command:
db2set -gd DB2_WORKLOAD=1C

This command will display a list of IBM DB2 registry variables and their
values corresponding to the group registry variable DB2_WORKLOAD =
1C.
If the 1C: Enterprise server is running as a service, you must perform the
following steps:
• include the user, on behalf of which the 1C: Enterprise server is start-
ed (by default, USR1CV8) in the DB2ADMNS group;
• for the DB2 copy in use, set the SYSADM_GROUP parameter to
DB2ADMNS.
Installation information is available in the server documentation:
• IBM DB2 v9.7:
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/co
m.ibm.db2.luw.qb.server.doc/doc/r0025127.html.
• IBM DB2 v10.1:
http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/c
om.ibm.db2.luw.qb.server.doc/doc/r0025127.html.
• IBM DB2 v11.1:
http://www.ibm.com/support/knowledgecenter/SSEPGG_11.1.0
/com.ibm.db2.luw.qb.server.doc/doc/r0025127.html.

3.2.2. Installing Microsoft SQL

Server
The installation of the database server is performed from Microsoft SQL
Server distribution media.
NOTE. If Microsoft SQL Server 2000 is selected, then 1C: Enterprise for
error-free operation requires Service Pack 2 installed for Microsoft SQL
Server 2000 (Service Pack 4 is recommended).
The user on whose behalf the 1C: Enterprise server accesses MS SQL Serv-
er must be a member of the fixed server role processadmin or
sysadmin.
Installation information is available in the server documentation:
• Microsoft SQL Server 2005 version: http://msdn.Microsoft.com/en-
US/library/ms143516(SQL.90).aspxhttp://msdn.microsoft.com/ru-
ru/library/ms143516(SQL.90).aspx
• Microsoft SQL Server 2008 version: http://msdn.Microsoft.com/en-
US/library/bb500469(v=sql.100).aspxhttp://msdn.microsoft.com/ru-
ru/library/bb500469(v=sql.100).aspx
• Microsoft SQL Server 2008 R2 version:
http://msdn.Microsoft.com/en-
US/library/bb500469(v=sql.105).aspxhttp://msdn.microsoft.com/ru-
ru/library/bb500469(v=sql.105).aspx
• Microsoft SQL Server 2012 version: http://msdn.microsoft.com/en-
US/library/bb500469(v=sql.110).aspxhttp://msdn.microsoft.com/ru-
ru/library/bb500469(v=sql.110).aspx
• Microsoft SQL Server 2014 version: http://msdn.Microsoft.com/en-
US/library/bb500469(v=sql.120).aspxhttp://msdn.microsoft.com/ru-
ru/library/bb500469(v=sql.120).aspx
• Microsoft SQL Server 2016 version:
http://msdn.microsoft.com/en-
US/library/bb500469(v=sql.130).aspx

3.2.3. Installing Oracle Database

The installation of the database server is made from the Oracle Database
distributions.
The Oracle Database versions supported by the “1C: Enterprise” system are
published on the website: https://1c-
dn.com/library/system_requirements/.http://v8.1c.ru/requirements/
Installation information is available in the server documentation:
• Oracle Database 10g Release 2:
http://download.oracle.com/docs/cd/B19306_01/em.102/b1622
7/toc.htm.
• Oracle Database 11g Release 1:
http://download.oracle.com/docs/cd/B28359_01/em.111/b3120
7/toc.htm.
• Oracle Database 11g Release 2:
http://docs.oracle.com/cd/E11882_01/em.112/e12255/toc.htm.
 • Oracle Database 12c Release 1:
http://docs.oracle.com/database/121/nav/portal_11.htm.
The database server in terms of "1C: Enterprise" corresponds to the concept
of DATABASE in terms of Oracle Database database in 1C:Enterprise cor-
responds to data schema in Oracle Database. When creating a
1C:Enterprise infobase in the Oracle Database, an infobase user and data
schema are created.
1C: Enterprise 8 uses the following tablespaces for working with Oracle
Database:
• for data -V81C_DATA;
• for indexes -V81C_INDEX;
• for -LOB V81C_LOB;
• for temporary files -V81C_TEMP.
If tablespaces with such names exist, they will be used; if not, they will be
created when creating the information base, while the datafiles will have
default paths.
Table space V81_INDEX_BIG is used to work with indexes and is created
when creating an index resulted in error ORA-01450. In the event that such
a tablespace already exists-, it will be used.
When creating DATABASE it is necessary for this DATABASE to set the
parameter CHARACTER SET to AL32UTF8.
Before using Oracle Database server with 1C: Enterprise, you need to con-
figure multilingual collation for the database server. To do this, follow these
steps:
• Copy the lx327c6.nlt file from the Additional\OracleDatabase di-
rectory of the 1C:Enterprise distribution disk to an empty directory on
the hard disk of the computer where Oracle Database is installed.
• Run Oracle Locale Builder (lbuilder).
• Start the generation of nlb files (Tools -Generate NLB), specifying
the folder with the file lx327c6.nlt.
• Stop all Oracle Database services running from the Oracle Database
home directory (ORACLE_HOME).
• Create a backup of the lx0boot.nlb and lx1boot.nlb files from the
ORACLE_HOME / nls / data folder.
• Copy the lx1boot.nlb and lx327c6.nlb files from the folder where
they were created by the Oracle Locale Builder utility in
ORACLE_HOME / nls / data. While copying, agree to overwrite file
lx1boot.nlb.
• Launch Oracle Database services.
 3.2.4. Install PostgreSQL
3.2.4.1. General information
The installation of the database server is made from 1C: Enterprise distribu-
tion media. PostgreSQL DBMS can function both under the control of the
Windows operating system and under the control of the Linux operating
system.
When initializing a database cluster, the encoding should be UTF-8.
"1C: Enterprise 8" supports the use of the following table spaces (table-
space) when working with PostrgeSQL:
• for data -v81c_data;
• for indexes- v81c_index.
If a tablespace with such names exists, they will be used; if not, it is rec-
ommended to create them:
create tablespace v81c_index location <Folder name>
create tablespace v81c_data location <Folder name>;

Where <Folder name>- is the full path to the directory in which the files
of the created table space will be located. In the absence of the specified
tablespaces, a tablespace with the name pg_default will be used.
To work together with the 1C: Enterprise system, a modified version of
PostgreSQL is required. You can get this version on the ITS disk or at:
https://1c-
dn.com/user/updates/postgresql/.https://releases.1c.ru/project/AddCompPost
gre
"1C: Enterprise" can work with a cluster created using the following ver-
sions of the PostgreSQL DBMS:
• PostgreSQL 8.1.5-X.1C - 9.1.2-1.1C;
• PostgreSQL 9.2.1-2.1C;
• The standard version of PostgreSQL (provided that locale settings of
the cluster and the infobase are identical)
1C:Enterprise can be used with a cluster created by a standard version of
PostgreSQL, only if PostgreSQL distribution package by 1C is used.
You can switch to an earlier or later version of 1C:Enterprise without hav-
ing to change PostgreSQL version or perform other actions.
Infobases created using PostgreSQL 9.2.1-2.1C or later cannot be used with
the earlier versions of 1C:Enterprise (8.3.2 or earlier). Do not create in-
fobases using PostgreSQL version 9.2.1-2.1C if you expect to access these
infobases from earlier 1C:Enterprise versions.
 3.2.4.2. Installing PostgreSQL for Windows
To install the version you need:
1. unpack the zip-archive with the PostgreSQL distribution kit,
2. Run the postgresql- <Version> -1.1C.msi file, where <Version>- is
the version of the PostgreSQL system being installed,
3. follow the instructions of the installer.

3.2.4.3. Installing PostgreSQL for Linux

The distribution kit of a modified PostgreSQL version consists of 11 pack-
ages. You must install the packages in the following order:
• postgresql-libs-8.3.<X>-<Y>.1C.i386.rpm
• postgresql-8.3.<X>-<Y>.1C.i386.rpm
• postgresql-Server-8.3.<X>-<Y>.1C.i386.rpm
• postgresql-contrib-8.3.<X>-<Y>.1C.i386.rpm.
Where <X> and <Y> -are the corresponding positions in the PostgreSQL
version.
After that, the postgres user will appear in the system, the
/etc/init.d/postgresql script will be created to start and stop the DBMS.
Next, you need to set the desired value of the LANG variable and run
/etc/init.d/postgresql for the initial creation of the database. This can be
done with the command:
LANG=ru_RU.utf-8 /etc/init.d/postgresql start

This will create a database located in the /var/lib/pgsql/data directory. All

the above actions should be performed on behalf of the root user.
 Chapter 4.
Running system
components

4.1. General information

When installing 1C:Enterprise , the following structure will be created in
the Start - Programs menu (see example for Windows 10):
1C:Enterprise
1C:Enterprise 8 (folder)
1C:Enterprise (A.B.C.D)
ReadMe – Additional Information
Register server administration utility (A.B.C.D)
1C:Enterprise server administration
Start server (A.B.C.D)
Install protection driver
Remove protection driver

In the above list:

Item Purpose
Install protection driver Starts installation of the protection driver
Remove protection driver Starts removal of the protection driver
ReadMe -Additional Infor- Additional information not included in the
mation documentation
1C:Enterprise server admin- Server cluster administration utility (if any
istration 1C:Enterprise server cluster access com-
ponents are installed)
Start server (A.B.C.D) Starts the 1C:Enterprise server as a service
(if the Install 1C:Enterprise 8 server as
Windows service check box was selected
during server installation) or as an appli-
cation (if the Install 1C:Enterprise 8
server as Windows service check box
was cleared during server installation). In
this case, server shutdown is identical to
closing a regular application.
 Item Purpose
Register server administra- Registers the 1C:Enterprise server admin-
tion utility (A.B.C.D) istration utility (radmin.dll) for a specific
version, so that you can connect to the
servers of this version using the admin-
istration utility.
In this table:
• Specifying the name of an application without specifying a version
means the application or file from the version that was installed latest.
• Specifying (A.B.C.D) next to an application name means that a sepa-
rate menu item is created for each installed version, where A.B.C.D
means the full number of the installed version. For example, if two
versions are installed – 8.3.12.100 and 8.3.12 150, then the menu will
have two lines: Starting the server (8.3.12.100) and Starting the
server(8.3.12.150).
• If the 64-bit version of the 1C:Enterprise is installed, the name of the
menu folder and names of items in this folder will contain x86-64.
When launching the 1C: Enterprise server components, the system com-
mand line interface is actively used.

4.2. Running the server agent

4.2.1. General information
In order to launch the 1C: Enterprise server cluster, you must start the server
agent (ragent). All further actions will be executed by the system automati-
cally. At startup, the server agent searches for a list of clusters registered on
this computer.
If the cluster list is found, the server agent starts the specified cluster man-
agers. Through these, it obtains information about the working processes
that must be run in each cluster and starts these processes, with or without
the help of agents of other working servers of the cluster.
If no list of clusters is found, the server agent creates a default cluster. If no
list of clusters is found, the server agent creates a default cluster.
• network port number is -1541;
• network port range -1560: 1591;
• when running in debug mode using the HTTP protocol, the debug
server uses port 1550;
• One working process is used; its port number is picked from the speci-
fied range
 4.2.2. On Windows
4.2.2.1. Run as an application
The server agent can be run as an application. To do this, run the following
command:
ragent /port <port> /regport <port> /range <range>
/seclev <level> /d <directory>
/pingPeriod <time> /pingTimeout <time>
/debug -<mode> /debugServerAddr <address> /debugServerPort
<port> /debugServerPwd <password>

IMPORTANT! The name and value of the parameter must be separated by

a space character.
The start command can use the following commands:
/port <port>
The network port number of the server agent (ragent). This port is used by
the cluster console to access the central server. The cluster agent port is also
specified as the network port of the working server. Default value: 1540.
/regport <port>
The network port number of the main cluster manager (rmngr) created by
default on the first run of ragent. Default value: 1541.
/range <range>
Network port ranges for dynamic selection. Used as the initial value of the
IP port ranges property of the working cluster server created by default
when the server agent is first started (ragent). Default value: 1560:1591.
Examples of range values: 4549:4567, 7072:7790.
/seclev <level>
The security level of the cluster agent process. Specifies the security level
of connections established with the ragent process. Level can take values:
• 0 (default)- unprotected connections;
• 1 -secure connections only for the duration of user authentication;
• 2- permanently protected connections.
/d <directory>
The directory where the server cluster internal files are, or will be, stored
(including the list of clusters and the list of cluster infobases). If the parame-
ter is not specified, the default directory is used:
 %USERPROFILE%\Local Settings\Application Data\1C\1cv8
(%LOCALAPPDATA%\1C\1cv8 for Windows Vista or later). If the directo-
ry path contains spaces, the path must be enclosed in quotes, for example:
/d "c:\Server data\cluster 2"

NOTE. A directory name must not be terminated with a "\" if it is enclosed

in quotes. Correct: "c:\my path", incorrect: "c:\my path\".

/pingPeriod <time>
The period of checking the connection tracking system, milliseconds.
Default value: 1 000.
/pingTimeout <time>
Timeout checking the connection tracking system, milliseconds.
Default value: 5 000.
/debug -<mode>
Running a server cluster in configuration debugging mode. The <mode>
parameter specifies which protocol will use the debugger on this server
cluster:
• -tcp - TCP/IP protocol;
• -http - HTTP protocol.
Default value: -tcp.
TIP. Due to the fact that server performance drops in debug mode, it is rec-
ommended to use debug mode only for those servers that are being de-
bugged.

/debugServerAddr <address>
Specifies the address of the computer on which the debug server is running.
It is recommended to use this key in the case when several network cards
are installed on the computer.
If the key is not specified, then an arbitrary network address will be used
that belongs to the computer where the debug server is running.
/debugServerPort <port>
Specifies which port should be used by the debug server. The default port is
1550.
 /debugServerPwd <password>
Specifies the password that the client application will need to use when es-
tablishing a connection with the debugging server of this server cluster.
By default, no password is set.

Stop the server agent running as an application by pressing the Ctrl + C

keys.

4.2.2.2. Run as a service

If during installation of the server cluster the option of starting the central
server agent as a service was chosen, then this service will be started auto-
matically during the installation process and will also be started at the start
of the operating system.
If the agent of the central server was installed as an application, then it is
possible to register the service manually and then launch it.
The service name differs in 32- and 64-bit versions of 1C: Enterprise:

Version of "1C: Enter-

Service name
prise"
32-bit version 1C:Enterprise 8.3 Server Agent
64-bit version 1C:Enterprise 8.3 Server Agent (x86-64)

Service registration is performed by the following command:

ragent /instsrvc|/rmsrvc /usr <name> /pwd <password>
/start|/stop
/port <port> /regport <port> /range <range>
/seclev <level> /d <directory>
/pingPeriod <time> /pingTimeout <time>
/debug -<mode> /debugServerAddr <address> /debugServerPort
<port> /debugServerPwd <password>

IMPORTANT! The name and value of the parameter must be separated by

a space character.
NOTE. Performing registration, unregistering, starting and stopping ser-
vices of a cluster agent (ragent) must be performed as an administrator. In
the course of work, checks for the availability of privileges necessary for
the operation, and in the case of their absence, a request for elevation of
privileges is executed.

/instsrvc
Register a cluster agent as a Windows service. If ragent is running with this
key, it will register in the list of Windows services and exit.
The / instsrvc switch is incompatible with the / rmsrvc switch.
/rmsrvc
Unregistering the cluster agent as a Windows service. If ragent is started
with this key, it will cancel its registration in the list of Windows services
and end.
The / rmsrvc switch is incompatible with the / instsrvc switch.
/start
Run ragent registered as a Windows service. Runs ragent, previously reg-
istered as a Windows service, and then terminates.
/stop
Stop ragent registered and running as a Windows service. Stops ragent,
previously registered and running as a Windows service, and then termi-
nates.
/usr <name>, /pwd <password>
The name and password of the Windows user on whose behalf ragent
should be launched as a Windows service. Can only be used with the / in-
stsrvc switch when registering ragent as a Windows service.
/port <port>
The network port number of the server agent (ragent). This port is used by
the cluster console to access the central server. The cluster agent port is also
specified as the network port of the working server. Default value: 1540.
/regport <port>
The network port number of the main cluster manager (rmngr) created by
default on the first run of ragent. Default value: 1541.
/range <range>
Network port ranges for dynamic selection. Used as the initial value of the
IP port ranges property of the working cluster server created by default
when the server agent is first started (ragent). Default value: 1560:1591.
Examples of range values: 4549:4567, 7072:7790.
/seclev <level>
The security level of the cluster agent process. Specifies the security level
of connections established with the ragent process. Level can take values:
• 0 (default)- unprotected connections;
• 1 -secure connections only for the duration of user authentication;
 • 2- permanently protected connections.
/d <directory>
The directory where the server cluster internal files are, or will be, stored
(including the list of clusters and the list of cluster infobases). If the parame-
ter is not specified, the default directory is used:
%USERPROFILE%\Local Settings\Application Data\1C\1cv8
(%LOCALAPPDATA%\1C\1cv8 for Windows Vista or later).
NOTE. A directory name must not be terminated with a "\" if it is enclosed
in quotes. Correct: "c:\my path", incorrect: "c:\my path\".

/pingPeriod <time>
The period of checking the connection tracking system, milliseconds.
Default value: 1 000.
/pingTimeout <time>
Timeout checking the connection tracking system, milliseconds.
Default value: 5 000.
/debug -<mode>
Running a server cluster in configuration debugging mode. The <mode>
parameter specifies which protocol will use the debugger on this server
cluster:
• -tcp - TCP/IP protocol;
• -http - HTTP protocol.
Default value: -tcp.
TIP. Due to the fact that server performance drops in debug mode, it is rec-
ommended to use debug mode only for those servers that are being de-
bugged.

/debugServerAddr <address>
Specifies the address of the computer on which the debug server is running.
It is recommended to use this key in the case when several network cards
are installed on the computer.
If the key is not specified, then an arbitrary network address will be used
that belongs to the computer where the debug server is running.
/debugServerPort <port>
Specifies which port should be used by the debug server. The default port is
1550.
 /debugServerPwd <password>
Specifies the password that the client application will need to use when es-
tablishing a connection with the debugging server of this server cluster.
By default, no password is set.

The default service is started automatically when you turn on the computer.
You can also manually start the service from Windows: My Computer -
Management - Services and applications - Services- Agent of
1:CEnterprise 8 server (My computer - Manage - Computer Manage-
ment - Services and Applications - Services - 1C:Enterprise 8 Server
Agent). You can also manually stop the service from Windows.
To stop the service, run this command:
ragent /rmsrvc

4.2.3. On Linux
4.2.3.1. General information
The installer sets up the server processes so that they are started in daemon
mode, that is, without binding them to any specific control terminal. If nec-
essary, the server agent can be started with command-line parameters.
NOTE. When the 1C:Enterprise server runs in the daemon mode, debug-
ging over HTTP protocol is not supported.

4.2.3.2. Running the server agent

To start the server agent, use the following command-line parameters:
./ragent /daemon
/port <port> /regport <port> /range <range>
/seclev <level> /d <directory>
/pingPeriod <time> /pingTimeout <time>
/debug -<mode> /debugServerAddr <address> /debugServerPort <port>
/debugServerPwd <password>

IMPORTANT! The name and value of the parameter must be separated by

a space character.

/daemon
This parameter allows you to start the server agent in daemon mode, that is,
as a background application that does not interact with the terminal used to
start it. Running a server agent with this parameter does not auto start the
server agent after a system reboot.
 /port <port>
The network port number of the server agent (ragent). This port is used by
the cluster console to access the central server. The cluster agent port is also
specified as the network port of the working server. Default value: 1540.
/regport <port>
The network port number of the main cluster manager (rmngr) created by
default on the first run of ragent. Default value: 1541.
/range <range>
Network port ranges for dynamic selection. Used as the initial value of the
IP port ranges property of the working cluster server created by default
when the server agent is first started (ragent). Default value: 1560:1591.
Examples of range values: 4549:4567, 7072:7790.
/seclevel <level>
Optional. The security level of the cluster agent process. Specifies the secu-
rity level of connections established with the ragent process. Level can take
values:
• 0 (default)- unprotected connections;
• 1 -secure connections only for the duration of user authentication;
• 2- permanently protected connections.
/d <directory>
The directory where the server cluster internal files are, or will be, stored
(including the list of clusters and the list of cluster infobases). If the parame-
ter is not specified, the default directory is used: ~/.1cv8. If the directory
path contains spaces, the path must be enclosed in quotes, for example:
/d "~/cluster data"

/pingPeriod <time>
The period of checking the connection tracking system, milliseconds.
Default value: 1 000.
/pingTimeout <time>
Timeout checking the connection tracking system, milliseconds.
Default value: 5 000.
/debug -<mode>
Running a server cluster in configuration debugging mode. The <mode>
parameter specifies which protocol will use the debugger on this server
cluster:
 • -tcp - TCP/IP protocol;
• -http - HTTP protocol.
Default value: -tcp.
TIP. Due to the fact that server performance drops in debug mode, it is rec-
ommended to use debug mode only for those servers that are being de-
bugged.

/debugServerAddr <address>
Specifies the address of the computer on which the debug server is running.
It is recommended to use this key in the case when several network cards
are installed on the computer.
If the key is not specified, then an arbitrary network address will be used
that belongs to the computer where the debug server is running.
/debugServerPort <port>
Specifies which port should be used by the debug server. The default port is
1550.
/debugServerPwd <password>
Specifies the password that the client application will need to use when es-
tablishing a connection with the debugging server of this server cluster.
By default, no password is set.

Stop the server agent running as an application by pressing the Ctrl + C

keys.

4.2.3.3. Running the server agent using a script

A dedicated script /etc/init.d/srv1cv83 is intended to manage the
1C:Enterprise server agent. The script always starts the server in daemon
mode. The script uses the following command-line parameters:
/etc/init.d/srv1cv83 start|stop|restart|info|status

start
Starts the server. The script runs a single instance of 1C:Enterprise server.
stop
Stops the server. The script only stops the server that was previously started
by this script (see the start command above).
restart
Restarts the server. Same as the sequence of commands stop and start.
info
Displays server settings: ports specified at startup, cluster directory, config-
uration debug mode status, connection security level.
status
Displays server status information (enabled or disabled, running or
stopped).

Configuration file /etc/sysconfig/srv1cv83 (if the installation was per-

formed for RPM system) or /etc/init.d/srv1cv83 (if the installation was
performed for DEB system) is used to set the startup parameters for the 1C:
Enterprise server agent.
An example of configuration file:
#------------------------------------------------------------
# 1C:Enterprise Server configuration parameters
#------------------------------------------------------------
# 1C:Enterprise Server keytab file.
# default - usr1cv8.keytab file in 1C:Enterprise Server
# installation directory
#SRV1CV8_KEYTAB=
# Number of the cluster port created by default during first
# launch of ragent
# default - 1540
SRV1CV8_PORT=1540
# Number of cluster agent main port. This port is used by the
# cluster console to address the central Server. Cluster agent
# port is also specified as the IP port of the working Server.
# default - 1541
SRV1CV8_REGPORT=1541
# Port range for connection pool
# example values:
# 4549:4567,7072:7790
# default - 1560:1691
SRV1CV8_RANGE=1560:1691
# 1C:Enterprise Server configuration debug mode
# 0 - default - off
# 1 - on
SRV1CV8_DEBUG=0
# Path to directory with claster data
# default - $HOMEDIR/.1cv8/1C/1cv8
SRV1CV8_DATA=$HOMEDIR/.1cv8/1C/1cv8
# Security level:
# 0 - default - unprotected connections
# 1 - protected connections only for the time of user
# authentication
# 2 - permanently protected connections
SRV1CV8_SECLEV=0
#------------------------------------------------------------
# end of config
#------------------------------------------------------------

4.2.3.4. Enabling auto start for 1C:Enterprise

server
In order for the 1C:Enterprise server to automatically start at OS startup, run
the following command:
For RPM systems:
chkconfig -add srv1cv83

For DEB systems:

update-rc.d srv1cv83 defaults

These commands add the 1C:Enterprise server start script to the list of ser-
vices auto started on OS startup. The server parameters will be obtained
from configuration file /etc/sysconfig/srv1cv83 (if the installation was
performed for RPM system) or /etc/init.d/srv1cv83 (if the installation was
performed for DEB system).

4.3. Collaboration between

server processes
4.3.1. General information
In the total majority of use cases, one server agent runs per working server.
When multiple clusters are created under the control of a single server
agent, the server agent ensures that their network ports do not conflict. If
clusters are created under the control of different server agents, you need to
take additional efforts to ensure there are no conflicts between the network
ports of the cluster managers.
You should always take efforts to ensure there are no conflicts between the
network ports of working processes on the server (provided that the server
is used in different clusters), even when such clusters run under the control
of the same server agent.
The situation when two or more server agents run on a computer at the same
time, each agent managing a set of clusters, is rare but not abnormal. For
example, this may be necessary when you need to use multiple versions of
the 1C:Enterprise server on the same computer.
To ensure the parallel operation of two server agents processing different
clusters, you need to meet the following conditions:
• Server agents must have different network ports
• Server agents must have different internal file directories
• Server clusters created for each server agent must have different net-
work ports
• Network port ranges used by working processes on this server must
not overlap (if this server is used in different clusters)
 4.3.2. On Windows
This section explains how to start a second instance of the 1C:Enterprise
server on a computer.
TIP. It is recommended that you install the second instance of the
1C:Enterprise server as an application, and not a Windows service. If neces-
sary, you can register the server as a service later.
NOTE. The services of cluster agent (ragent) are registered, unregistered,
started, and stopped on behalf of the administrator. This includes a privileg-
es check; if the required privileges are not found, a request for elevation of
privileges is created.
Please note that the installer does not allow changing the network ports of
the server, so a new instance of the server will not be able to function direct-
ly after installation.
The following examples assume that the 1C:Enterprise server runs on an OS
of the same bitness (a 32-bit server on a 32-bit OS, or a 64-bit server on a
64-bit OS). If you run 32-bit 1C:Enterprise server on 64-bit Windows, re-
place path C:\Program Files with C:\Program Files (x86) in all examples
in the following sections.

4.3.2.1. Running multiple servers with different

1C:Enterprise versions

4.3.2.1.1. As a service
To start a 1C:Enterprise 8.3 server as a Windows service when a
1C:Enterprise 8.1 server is already running:
1. Go to the bin directory of the installed 1C: Enterprise 8.3 server. In
this example, 1C:Enterprise 8.3.3.150 is used.
c:
cd "c:\Program Files\1cv8\8.3.3.150\bin"

2. Delete registration of the 1C:Enterprise 8.3 server.

ragent /rmsrvc

3. Delete contents of the cluster registry directory. The directory location

depends on how the installation of the 1C:Enterprise 8.3 server was
performed.
rmdir /s /q "c:\Program Files\1cv8\srvinfo"

4. Register the service with different network port values.

ragent /instsrvc /port 2540 /regport 2541 /range 2560:2590 /usr
.\usr1cv8 /pwd UsrPwd8 /d "d:\DbData\srvinfo"

In this example, the following port values are used:

 serial port number of server agent - 2540;
 serial port number of cluster manager- 2541;
 diapason of ports for dynamic selection- 2560:2590;
 Cluster registry data is located in directory D:\DbData\srvinfo
 the user on the behalf of which the service of "1C:Enterprise", -
usr1cv8 is performed;
 the password on the behalf of which the service of "1C:Enterprise"
server, - UsrPwd8 is performed;
 if you need to enable debugging mode for the registered service,
add the /debug parameter to the command line.
5. Start the 1C:Enterprise server.
ragent /start

4.3.2.1.2. As an application
To change network ports for a 1C:Enterprise server started as an applica-
tion:
1. Shut down the running server instance by pressing Ctrl + C in the
console window of the server.
2. Go to the bin directory of the installed 1C: Enterprise 8.3 server. In
this example, 1C:Enterprise 8.3.3.150 is used.
c:
cd "c:\Program Files\1cv8\8.3.3.150\bin"

3. Delete contents of the cluster registry directory. The directory location

depends on how the installation of the 1C:Enterprise 8.3 server was
performed.
rmdir /s /q "%USERPROFILE%\Local Settings\Application Data\1C\1cv8"

4. Start the “1C: Enterprise” server with new values of network ports and
other data.
ragent /port 3540 /regport 3541 /range 3560:3590 /d
"d:\DbData\srvinfo"

In this example, the following port values are used:

 number of network port of server agent - 3540;
 number of network port of cluster manager - 3541;
 diapason of ports for dynamic selection- 3560:3590;
 Cluster registry data is located in directory D:\DbData\srvinfo
  if you need to enable debugging mode for the registered service,
add the /debug parameter to the command line.
 On subsequent starts, use exactly the same startup command
string. For convenience, you can save it to a Windows batch file.

4.3.2.2. Running multiple servers with identical

1C:Enterprise versions

4.3.2.2.1. As a service
1C:Enterprise has no standard functionality for registering multiple instanc-
es of the 1C:Enterprise server service with the same version. You should
use the sc utility instead. Service names, network port numbers and cluster
directory addresses used by the service instances must be different.
Let us review an example of the batch file that performs the registration of
the server service.
Register-service.bat:
@echo off
rem %1 – 1C:Enterprise full version
rem%2 – first two digits of the port numbers. For ports
1540,1541,1560:1591, use 15.
rem %3 – directory with cluster registry data

set SrvUserName=<user name>

set SrvUserPwd=<user password>
set RangePort=%260:%291
set BasePort=%241
set CtrlPort=%240

set SrvcName="1C:Enterprise 8.3 Server Agent %CtrlPort% %1"

set BinPath="\"C:\Program Files\1cv8\%1\bin\ragent.exe\" /srvc
/agent /regport %BasePort% /port %CtrlPort% /range %RangePort% /d
\"%~3\" /debug"
set Description="1C:Enterprise 8.3 Server Agent" Parameters: %1,
%CtrlPort%, %BasePort%, %RangePort%"

if not exist "%~3" mkdir "%~3"

sc stop %SrvcName%
sc delete %SrvcName%
sc create %SrvcName% binPath= %BinPath% start= auto obj=
%SrvUserName% password= %SrvUserPwd% displayname= %Desctiption%
depend= Dnscache/Tcpip/Tcpip6/lanmanworkstation/lanmanserver

Before using this batch file, make sure it contains actual user data (name
and password) you want to use for starting the server cluster service(see
 lines set SrvUserName = and set SrvUserPwd =). This batch file regis-
ters the specified version of 1C:Enterprise server. The service name is a
string containing the following information:
• 1C:Enterprise 8.3 Server Agent
• Network port number of the main cluster manager
• Full version number of 1C:Enterprise
When registering server version 8.3.3.100 with main cluster manager port
2540, the service name will look like this: 1C:Enterprise 8.3 Server
Agent 2540 8.3.3.100.
Example:
register-service 8.3.3.100 25 "c:\cluster_data\cluster 1"
register-service 8.3.3.100 35 "c:\cluster_data\cluster 2"

In this example, the first line registers the server service with the following
parameters:
• Service Name: 1C:Enterprise 8.3 Server Agent 2540 8.3.3.100
• Server ports: 2540, 2541, 2560:2591
• Directory with cluster registry data: C:\cluster_data\cluster 1
• Service description: 1C:Enterprise 8.3 server agent Parameters:
8.3.3.100, 2540, 2541, 2560:2591
The second line registers the server service with the following parameters:
• Service Name: 1C:Enterprise 8.3 Server Agent 3540 8.3.3.100;
• Server ports: 3540, 3541, 3560:3591;
• Directory with cluster registry data: C:\cluster_data\cluster 2;
• Service description: 1C:Enterprise 8.3 server agent Parameters:
8.3.3.100, 3540, 3541, 3560:3591.
To unregister the server service, you can use the following example batch
file.
Unregister-service.bat:
@echo off
rem %1 – 1C:Enterprise full version
rem%2 – first two digits of the port numbers. For ports
1540,1541,1560:1591, use 15.

set SrvcName="1C:Enterprise 8.3 Server Agent %240 %1"

sc stop %SrvcName%
sc delete %SrvcName%

Example:
unregister-service 8.3.3.100 25

This batch file stops the service and deletes its registration. The service
name is formed according to the same rules as when registering a new (non-
standard) 1C: Enterprise server service.

4.3.2.2.2. As an application
You can start multiple server instances of the same version, working as an
application, from the command line. In this case, the command line parame-
ters should differ not only in the numbers of network ports, but also in the
addresses of the cluster directories.
start "Server 1" "C:\Program Files\1cv8\8.3.3.100\bin\ragent.exe"
/port 2540 /regport 2541 /range 2560:2590 /d d:\ClusterData\Srv1
start "Server 2" "C:\Program Files\1cv8\8.3.3.100\bin\ragent.exe"
/port 3540 /regport 3541 /range 3560:3590 /d d:\ClusterData\Srv2

In the example, two instances of the 1C:Enterprise server are started with
the following parameters:
• The first server has Server 1 window title, uses network ports 25xx
and stores cluster data at D:\ClusterData\Srv1.
• The second server has Server 2 window title, uses network ports
35xx and stores cluster data at D:\ClusterData\Srv2.

4.3.2.3. Changing the network ports used by a

running 1C:Enterprise server instance
You cannot change network ports used by an already running instance of
the 1C:Enterprise server. If such a need arises, you should:
• Create a new server instance with the required network port values
and other parameters
• Register existing infobases on the new server
• Transfer users to the new server
 • Stop and delete the old instance of the 1C:Enterprise server (along
with the cluster data)

4.3.3. On Linux
This section explains how to start a second instance of the 1C:Enterprise
server on a computer.
Please note that the installer does not allow changing the network ports of
the server, so a new instance of the server will not be able to function direct-
ly after installation.
NOTE. 1C: Enterprise server installation for Linux is always performed in
daemon mode.
Under Linux, you only can start multiple 1C: Enterprise server instances if
they have different versions.

4.3.3.1. As daemon
To change the network ports of a running server instance:
• Stop the 1C:Enterprise server.
/etc/init.d/srv1cv83 stop

• Delete the cluster directory.

rm -rf /home/usr1cv8/.1cv8

• Change the startup parameters of the 1C:Enterprise server by specify-

ing the required for network ports values and other parameters (in-
cluding the cluster registry directory).
• Start the 1C:Enterprise server.
/etc/init.d/srv1cv83 start

4.3.3.2. As an application
To change the network ports for a 1C:Enterprise server running as an appli-
cation:
• Shut down the running server instance by pressing Ctrl + C in the
console window of the server.
• Delete contents of the cluster registry directory. Typically, this is the
.1cv8 directory located in the home directory of the user on whose
behalf the server is running.
rm -rf /home/<ServerUser>/.1cv8

• Go to the directory with 1C:Enterprise binary files.

For the 32-bit version:
cd /opt/1C/v8.3/i386

For the 64-bit version:

cd /opt/1C/v8.3/x86_64

• Start the “1C: Enterprise” server with new values of network ports and
other data.
./ragent /port 2040 /regport 2041 /range 2060:2090 /d
/home/usr1cv8/dbinfo/.1cv8

In the example, server is started with the following port values:

 number of network port of server agent - 2040;
 number of network of cluster manager- 2041;
 diapason of ports for dynamic selection- 2060:2090;
 Cluster registry data is located in the
/home/usr1cv8/dbinfo/.1cv8 directory
 if you need to enable debugging for the registered service, add the
-debug parameter to the command line
 On subsequent starts, use exactly the same startup command
string. For convenience, you can save it to a Linux command file.
Chapter 5.
Administration

This section contains a description of 1C:Enterprise administration methods

for client/server mode.

5.1. Infobase administration

5.1.1. Backup in Client/Server
Mode
IMPORTANT! You should create a backup before performing any opera-
tion that may damage the infobase data.
Creating a backup with DBMS utilities allows you to get a perfectly accu-
rate copy of the database so that you can revert exactly to the pre-backup
state. For the backup purposes, it is assumed that the data in the database is
valid. If the database contains any abnormal data, restoring the backup may
fail.
To improve usability of the infobase backup, it is recommended to include
log files in it. However, you cannot add the log files to the backup using the
standard DBMS functionality. You need a convenient tool of your choice
instead. When restoring a backup, it is also recommended to restore the log.
In this case, activity history will be available in the infobase along with the
recovered data.
To create a backup, it is recommended to use these methods:
• For file option - the4 copying of file 1Cv8.1CD, while there should be
no connection to informational base ( in case with the help of configu-
rator).
• For client server option - by means of reserve backup of appropriate
DBMS.
ATTENTION! When you restore an infobase using DBMS tools, no con-
nections to the infobase (including Designer) are allowed.
Materials on creating backups for specific SQL servers:
• Microsoft SQL Server 2000: http://msdn.Microsoft.com/en-
US/library/aa196685http://msdn.microsoft.com/ru-
ru/library/aa196685
• Microsoft SQL Server 2005: http://msdn.Microsoft.com/en-
US/library/ms187048(v=sql.90).aspxhttp://msdn.microsoft.com/ru-
ru/library/ms187048(v=sql.90).aspx
• Microsoft SQL Server 2008: http://msdn.Microsoft.com/en-
US/library/ms187048(v=sql.100).aspxhttp://msdn.microsoft.com/ru-
ru/library/ms187048(v=sql.100).aspx
• Microsoft SQL Server 2008 R2: http://msdn.Microsoft.com/en-
US/library/ms187048(v=sql.105).aspxhttp://msdn.microsoft.com/ru-
ru/library/ms187048(v=sql.105).aspx
• Microsoft SQL Server 2012: http://msdn.Microsoft.com/en-
US/library/ms187048(v=sql.110).aspxhttp://msdn.microsoft.com/ru-
ru/library/ms187048(v=sql.110).aspx
• Microsoft SQL Server 2014: http://msdn.Microsoft.com/en-
US/library/ms187048(v=sql.120).aspxhttp://msdn.microsoft.com/ru-
ru/library/ms187048(v=sql.120).aspx
• Microsoft SQL Server 2016: http://msdn.microsoft.com/en-
US/library/ms187048(v=sql.130).aspxhttp://msdn.microsoft.com/ru-
ru/library/ms187048(v=sql.130).aspx
• PostgreSQL 8.1:
http://www.postgresql.org/docs/8.1/static/backup.html.
• PostgreSQL 8.2:
http://www.postgresql.org/docs/8.2/interactive/backup.html.
• PostgreSQL 8.3:
http://www.postgresql.org/docs/8.3/interactive/backup.html.
• PostgreSQL 8.4:
http://www.postgresql.org/docs/8.4/interactive/backup.html.
• PostgreSQL 9.0 :
http://www.postgresql.org/docs/9.0/interactive/backup.html.
• PostgreSQL 9.1:
http://www.postgresql.org/docs/9.1/interactive/backup.html.
• PostgreSQL 9.2:
http://www.postgresql.org/docs/9.2/interactive/backup.html.
• PostgreSQL 9.3:
http://www.postgresql.org/docs/9.3/interactive/backup.html.
• PostgreSQL 9.4:
https://postgrespro.com/docs/postgresql/9.4/backup.html.https://postgr
espro.ru/docs/postgresql/9.4/backup.html
 • PostgreSQL 9.6:
https://postgrespro.com/docs/postgresql/9.6/backup.html.https://postgr
espro.ru/docs/postgresql/9.6/backup.html
• PostgreSQL 10:
https://postgrespro.com/docs/postgresql/10/backup.https://postgrespro.
ru/docs/postgresql/10/backup
• Postgres Pro Standard 9.6:
https://postgrespro.ru/docs/postgrespro/10/backup.html.
• Postgres Pro Enterprise 9.6:
https://postgrespro.com/docs/postgresproee/9.6/backup.html.https://po
stgrespro.ru/docs/postgresproee/9.6/backup.html
• Postgres Pro Enterprise 10:
https://postgrespro.ru/docs/postgresproee/10/backup.html.
• IBM DB2 v9.7:
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/co
m.ibm.db2.luw.admin.ha.doc/doc/c0052073.html.
• IBM DB2 v10.1:
http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/c
om.ibm.db2.luw.admin.ha.doc/doc/c0052073.html.
• IBM DB2 v11.1:
http://www.ibm.com/support/knowledgecenter/SSEPGG_11.1.0
/com.ibm.db2.luw.admin.ha.doc/doc/c0052073.html.
• Oracle Database 10g Release 2:
http://download.oracle.com/docs/cd/B19306_01/backup.102/b1
4192/toc.htm.
• Oracle Database 11g Release 1:
http://download.oracle.com/docs/cd/B28359_01/backup.111/b2
8270/toc.htm.
• Oracle Database 11g Release 2:
http://docs.oracle.com/cd/E11882_01/backup.112/e10642/toc.
htm.
• Oracle Database 12c Release 1:
http://docs.oracle.com/database/121/BRADV/toc.htm.

5.1.2. Converting infobases for

use in client/server mode
To convert an infobase from file to client/server mode, export/import it to a
file.
IMPORTANT! Before performing the import and export procedures, make
sure all sessions using this infobase are closed.
It is necessary to export infobase (pointAdministration- Export infobase).
Create an empty infobase in the client/server mode. Open base in the De-
signer mode and make loading of the infobase (point Administration -
Load infobase).

5.2. Server cluster

administration
5.2.1. General information
This utility is a snap-in MMC module that can be used on computers with
Microsoft Management Console installed. Microsoft Management Con-
sole is a standard tool in the Microsoft Windows operating systems. When
installing 1C:Enterprise for infobase operations in client/server mode for
these operating systems, the utility start shortcut will be in the Start menu,
in section 1C:Enterprise 8.
Functionality of the server cluster administration utility is similar to the
software administration capabilities of the server cluster.
Please note that the information displayed by the administration console is
not refreshed automatically. For getting uptodate information be sure to use
console command Actions - Renew ( or command Renew from context
menu).

5.2.2. Running the administration

utility
The utility can only be run on a computer that has Microsoft Management
Console installed. The launching of utility can be performed with the help
of the following menu commands Launch - Programs - 1C:Enterprise 8 -
More details - 1C:Enterprise servers administration for 32-bites version
of utility or Launch - Programs - 1C:Enterprise 8 (x86-64) - More de-
tails - 1C:Enterprise servers administration for 64-version of utility.
Alternately, start the Microsoft Management Console (MMC) using the
command line:
mmc

After management console is started remember to select menu item Con-

sole- Add or Remove Snap-in...

Fig. 26. Adding snap-in

The Add / Remove Snap-in dialog box appears. Click the Add button.
The Add Isolated Snap-In dialog box appears. Select 1C:Enterprise 8.3
Servers from the list, click Add, and close the dialog box using the Close
button.

Fig. 27. Snap-in selection

In the Add / Remove Snap-in dialog box, click OK. This will connect the
administration utility to the Microsoft management console.

5.2.3. Registering an instance of

a working server
When you first start the administration utility, the tree of central servers
includes only the working server installed on the computer running the ad-
ministration utility (provided that the server agent is running on this com-
puter).
To display the full list of central servers, select and expand the
1C:Enterprise 8.3 Central Servers branch in the central server tree.

Fig. 28. Central server tree

The tree of central servers contains a list of central servers to which the util-
ity is connected. Each central server is identified by the name of the com-
puter on which it is running. The properties field displays a list of central
servers, containing the network address of each central server and its de-
scription.

5.2.3.1. Connecting the utility to central server

For the utility connection to new central server it is necessary to perform
the command of context menu Create - Central server of 1C:Enterprise
8.3 or similar command of utility main menu.
The central server properties dialog box will be displayed.

Fig. 29. New central server

You need to enter the following data in the dialog box fields:
Protocol
Protocol used by the central server connection. Selected from the list. By
default value - tcp. This field specifies the protocol the administration utili-
ty will use to connect to the central server agent. The only value is support-
ed- tcp.
Name
Network address of the central server on which the server agent is running.
IP port
Network port of the server agent that is running on the central server. By
default value- 1540. The server agent port is specified on start.
Description
Arbitrary description of the central server.
NOTE. When setting up a server cluster and a central server, make sure that
identical addresses are specified for the same servers in both cases. No au-
tomated address match check is performed. For example, if the central serv-
er in the cluster console has address Server, it must also be named Server
in the list of working servers, not 54.34.86.12 (even if Server DNS re-
solves to 54.34.86.12) or localhost.

5.2.3.2. Viewing and editing central server

properties
To view or edit properties of a central server, select the server in the list of
central servers and execute the Properties context menu command, or the
corresponding command in main menu of the utility.
The central server properties dialog box described in the previous section
will be displayed.

5.2.3.3. Removing central server from utility

To remove a central server from the list of central servers in the utility, se-
lect the server in the list and execute the Delete context menu command, or
the corresponding command in main menu of the utility.

5.2.3.4. Disconnecting utility from central

server
The 1C:Enterprise server cluster administration utility can be disconnected
from the central server, while connection settings to the central server will
not be deleted.
To disconnect the utility from the central server, select the server in the list
of central servers and execute the Disconnect context menu command, or
the corresponding command in main menu of the utility.

5.2.4. Operations with list of

central server
administrators
The server cluster allows to create a list of central server administrators so
that administrative operations (for example, adding a new cluster, or view-
ing the list of central server administrators) can be performed by authenti-
cated users only.
The list of central server administrators is empty by default. This means that
the central server administrator authentication is not required to perform the
above actions.
To display the list of central server administrators, select a server in the cen-
tral server tree, and then select and expand the Administrators branch.

Fig. 30. List of server cluster administrators

The central server tree contains the list of administrators of the selected cen-
tral server. Each administrator is identified by name. The properties field
displays a list of administrators of the selected central server, containing the
name and description of each administrator.
For each working server that is not assigned as a central server of a cluster
and that has a non-empty list of central server administrators, the adminis-
trators list must include an administrator with OS authentication of the user
on whose behalf ragent is running on the central server of the cluster, or an
administrator with name and password that matches the name and password
for one of the administrators of the central server of the cluster.

5.2.4.1. Creating a central server administrator

For adding new administrator of central server be sure to select in central
servers tree the required server, select tree Administrators and perform
context menu command Create - Administrator or the similar command
of utility main menu.
The central server administrator properties dialog box will be displayed.

Fig. 31. Creating a central server administrator

You need to enter the following data in the dialog box fields:
Name
Name of the central server administrator.
Description
Arbitrary description of the central server administrator.
Password authentication
Flag indicating that password authentication is enabled. It is set by default.
Password
Password of the central server administrator.
Password confirmation
Password confirmation.
OS authentication
Flag indicating that OS authentication is enabled.
User
OS user. Allowed format: \\domain name\user name Example:
\\domainname\username. You can directly specify a user by entering
their name, or select a user from the OS user list available on a computer
running the infobase administration utility. To select a user from the list,
click the "..." button and select a OS user.
IMPORTANT! Names of the central server administrators must be unique
for each central server.
Two methods of central server administrator authentication are supported:
• using a password
• using OS functionality
When authenticating with a password, a central server administrator authen-
tication dialog box is displayed. You are required to enter a username and
password.
When authenticating using the OS functionality, you are not required to
enter a username or password. The authentication dialog box is not dis-
played. The central server administrator is selected depending on the OS
user on whose behalf the connection was established.
IMPORTANT! If no authentication type is specified for an administrator,
this administrator can perform only those actions that do not require authen-
tication.

5.2.4.2. Viewing and editing central server

administrator's properties
To view or edit a central server administrator's properties, select the admin-
istrator in the list of central server administrators and execute the Proper-
ties context menu command, or the corresponding command in main menu
of the utility.
The central server administrator properties dialog box will be displayed.

Fig. 32. Central server administrator's properties

All properties, except for the administrator name, are editable. Values of
Password and Password Confirmation fields are hidden.

5.2.4.3. Deleting a central server administrator

To delete a central server administrator, select the administrator in the list of
central server administrators and execute the Delete context menu com-
mand, or the corresponding command in main menu of the utility.

5.2.4.4. Central server administrator

authentication
Authentication is automatically requested from a central server administra-
tor when they attempt to perform an action requiring authentication (provid-
ed that the list of central server administrators is not empty). The central
server administrator authentication dialog box is displayed.

Fig. 33. Administrator authentication

You need to enter the following data in the dialog box fields:
Name
Name of the central server administrator.
Password
Password of the central server administrator.

5.2.5. Operations with list of

clusters
To display the list of clusters registered on the central server, select a server
in the central server tree, and then select and expand the Clusters branch.

Fig. 34. List of clusters

The central server tree contains a list of clusters for the selected central
server. Each cluster is identified by a network port number. The properties
field displays a list of clusters of the selected central server, containing port
number and description of each cluster.

5.2.5.1. Adding clusters

For adding new cluster to central server be sure to select in central servers
tree the required server, select tree Clusters and perform context menu
command Create - Cluster or utility main menu similar command.
The cluster properties dialog box will be displayed.

Fig. 35. New cluster

You need to enter the following data in the dialog box fields:
Cluster name
Arbitrary description of the cluster.
Computer
Name of the central server hosting the cluster. Not editable.
IP port
Network port number of the cluster manager. By default - 1541.
IMPORTANT! Network port numbers of the cluster managers must be
unique for each central server.

Secure connection
Cluster security level. Selected from the list (allowed values: Never, Con-
nection only, Always). By default value - is disconnected.
Restart period __ seconds
Number of seconds counted since the process start. Once this period ex-
pires, the working process will be restarted. A zero value means that work-
ing processes will not restart automatically.
The reloading of working process is done in the following way:
• The existing working process ( let's call it the "old" one) is discon-
nected. The working process in disconnected mode:
 Continues serving old connections with infobases.
 Accepts new connections with infobases, which are maintained by
current working process.
 Does not accept new connections to infobases, which are not main-
tained by working process.
• New working process ( let's call it the "new" one) is launched and reg-
istered in servers cluster.
• In new working process the contexts of infobases, which maintain
stopped working process are created. The infobases applications are
downloaded to created contexts. The creation of contexts is performed
by system background tasks with some specific traits:
 The list of connections displays the title of application System
background tasks and application identifier
SystemBackgroundJob.
 In case of background system task launching the requirements of
functionality value are not taken into account.
 The background system task operated without session creation and
its operation is not displayed in logs register.
 The background system tasks can be aborted by means of servers
cluster administration.
• On the completion of infobases contexts forming in new working
process, the old working process:
 Stops the acceptance of all new connections.
 "Transfers" existing connections to new working process.
• The old working process is completed on the fulfillment of one of the
following conditions ( conditions " by OR"):
 After successful transfer of all existing connections.
 On the time expiration Problematic processes should be abort-
ed via.
• The registration of old working process in servers cluster is aborted.
Force close of corrupted processes
If the cluster monitoring mechanism approves the process to be the corrupt-
ed one, this flag defines the option of such processes forced abortion. This
flag does not influence the operation of monitoring itself.
Write process dump when critical memory amount is
exceeded
Defines the necessity of working process forced abortion dump forming in
case if servers cluster performs working process forced abortion. This situa-
tion might occur in case if during monitoring of cluster condition the value
set in working server parameter Processor memory amount crucial
amount is violated.
Dump is being formed in accordance with current settings of formation of
force closure dumps.
Stop corrupted processes in _ seconds
Time frame on the completion of which the corrupted working process is
forcedly aborted irrespectively of the amount of connections. All connec-
tions to this process fail. Value of this property can be changed while the
cluster is running. A zero value means that processes will not be terminated.
A cluster manager that exceeds the limit of the virtual address space is al-
ways restarted without waiting period.
Resilience level
The level of resilience defines the maximum number of working servers in
the cluster whose concurrent failure would not result in abnormal termina-
tion of any user sessions.
Load balancing mode
This parameter determines how a working process is selected when estab-
lishing a new connection.

5.2.5.2. Viewing and editing cluster properties

To view or edit cluster properties, select a cluster in the list of clusters of the
central server and execute the Properties context menu command, or the
corresponding command in main menu of the utility.
The cluster properties dialog box will be displayed.

Fig. 36. Server cluster properties

When the Secure connection property is changed for a running server
cluster, you need to restart the cluster in order for the new value of this
property to be applied for the server cluster.

5.2.5.3. Calling operation to apply functionality

assignment rules
The functionality assignment rules do not take effect until they are explicit-
ly applied. The list of rules edited in the cluster console does not affect the
operation of the server cluster until the rules are applied. The application
may be full or partial.
In the case of partial application, services that support migration between
working servers without data loss are reassigned. Other services are reas-
signed only if the new functionality assignment rules do not allow these
services to remain at their previous locations or the working servers on
which these services functioned at the time of the partial application opera-
tion are not available. Full application affects all services regardless of for-
mal characteristics of the services.
When performing full application, any client applications connected to the
server cluster on which the operation is performed may be terminated. This
situation is also possible in the case of partial application, if a decision has
been made to reassign all services, and not only those that allow migration
without data loss.
To apply the rules, select menu item Apply functionality assignment
rules (partial) or Apply functionality assignment rules (full) in the con-
text menu of the server cluster.

5.2.5.4. Deleting clusters

To delete a cluster, select a cluster in the list of clusters of the central server
and execute the Delete context menu command, or the corresponding
command in main menu of the utility.
IMPORTANT! Deleting a server cluster will cause all connections to the
cluster to be terminated abnormally.

5.2.6. Operations with list of

working servers in cluster
To display the list of cluster working servers, select a server in the central
server tree, select a cluster registered on this server, and then select and ex-
pand the Working servers branch.

Fig. 37. List of working servers

The central server tree contains a list of working servers of the cluster. Each
working server is identified by a network name. The properties field dis-
plays a list of working servers of the selected cluster, containing the name
of each server, the network port number of the server agent running on this
server, and a description of the server.
When you create a default cluster, the working server where it was created
is added to the cluster automatically. The Central server check box is au-
tomatically selected for this working server.

5.2.6.1. Adding a working server to cluster

For adding new working server to cluster it is necessary to select in central
servers tree required central server, select required cluster, registered on this
server, select tree Working servers and perform context menu command
Create - Working server or similar command of utility main menu.
The working server properties dialog box will be displayed.

Fig. 38. New working server

You need to enter the following data in the dialog box fields:
Description
Arbitrary description of the cluster server.
Computer
Network address of the working server on which the server agent is run-
ning.
COMMENT. If the IP address in dot notation is specified as the network
address of the 1C:Enterprise working server (Computer property), it is not
necessary to add it to DNS records (hosts file) as well.

IP port
Network port number of the server agent that is running on the specified
computer. By default - 1540.
IP port range
The range of network ports that will be used to assign addresses to working
processes created on this server. By default - 1560:1591.
Safe memory usage per call
NOTE. Available only for CORP licenses.
The amount of memory, in bytes, that can be safely used during a server
call.
It can take values from -1 to 9 223 372 036 854 775 807:
• -1 - any server call is deemed dangerous, if during the same a work-
ing process memory capacity becomes equal to a value specified in
Temporary allowed amount of process memory property;
• 0 - capacity is determined by default as a 10% share of a value speci-
fied in Temporary allowed amount of process memory.
Critical amount of process memory:
Defines the amount of cluster (working processes and cluster managers)
processes memory critical amount. The total amount of the virtual address
space occupied by working processes of the cluster running on the working
server, the increase of which can cause significant decrease of working
server efficiency.
If the amount of process memory exceeds the value of this parameter it will
cause the abortion of the required amount of processes in order total amount
of consumed memory of remaining cluster processes does not exceed this
parameter value. If cluster settings contain flag Register dump process in
case of memory critical amount increase, in case of each working pro-
cess force termination the attempt of dump formation will be performed
taking into account the settings of force closure of dumps formation.
At each iteration of cluster monitoring of cluster condition in case if critical
amount of processes memory is increased, the technological register fixes
ATTN event with the specification of identifiers of all cluster processes and
their memory amount.
This parameter can be assigned a value from -1 to
9 223 372 036 854 775 807, while:
• -1- memory available for cluster working processes on the current
working server is unlimited;
• 0 -memory available for cluster working processes on the current
working server is limited to 95% of server RAM.
The default value is 0.
Temporary allowed amount of processes memory
Defines the size of temporary allowed amount of operative memory occu-
pied with working processes and cluster managers (cluster processes) at
installed working server in bites. If the amount of memory consumed by
cluster processes exceeds the value of parameter, the system thinks that the
aforementioned working server has low efficiency level and it should not
have new connections with infobases.
This value is designed to monitor memory capacity used by working pro-
cesses in general or any specific server call in particular:
• Working process memory monitoring.
If the value of Temporary allowed processes memory size ex-
ceeds the time stipulated in Interval of growth of temporary al-
lowed processes memory (it cannot be 0), reloading of this working
server processes starts. The reload is performed starting from working
process, which consumes maximum amount of memory in order to
decrease the consumed operative memory size. If the reload process
had been terminated the time when the sum of consumed memory by
remaining cluster processes is less or equal to Temporary allowed
processes memory amount.
During reloading sessions serviced by working processes selected for
completion are reassigned to other working processes. A working pro-
cesses is completed, only if it ceases to service sessions of client con-
nections.
• Server call memory monitoring. Parameter values in this mechanism
depend on a server license used.
Each cluster working process determines the amount of memory oc-
cupied by cluster processes on this working server (hereinafter
ProcessMemory). ProcessMemory is updated every two sec-
onds.
 When you make a server call, ProcessMemory current value is reg-
istered (hereinafter CurrentProcessMemory) and a difference
between Temporarily allowed amount of process memory and
CurrentProcessMemory is calculated (hereinafter
MemoryLimitPerCall). If MemoryLimitPerCall is less than
Safe Memory Consumption Limit, MemoryLimitPerCall is
deemed equal to Safe Memory Consumption Limit.
During the call, the amount of memory consumed by the call (herein-
after, CallMemory) is calculated.
If upon memory allocation MemoryPerCall is in excess of
MemoryLimitPerCall in a single server call, the said call is inter-
rupted by an exception and terminated as failed. In this case, an EXCP
event is written to the technology log, containing the following infor-
mation:
 Exception text
 Exception context
Temporarily allowed amount of process memory value (see the
above algorithm) depends on a server license used by a server cluster:
 PROF server license: always equal to 80% of computer physical
memory (irrespective of a value you enter for this parameter).
 CORP server license: a value entered by a user in server cluster
settings is used.
It can take values from -1 to 9 223 372 036 854 775 807:
• -1 - temporary allowed memory size available for cluster processes at
the aforementione working server is unlimited;
• 0 - a default value is used as a temporary allowed memory size avail-
able for cluster processes on this working server:
 To monitor working process memory, - 70% of server RAM.
 To monitor server call memory, - 80% of server RAM.
The default value is 0.
Period of exceeding the process memory threshold:
Defines the time the size of operative memory consumed by cluster pro-
cesses can exceed the value of Temporary allowed processes memory
amount. Find the details in the working server parameter description
Temporary allowed processes memory amount. This parameter will be
used only in case if its value is not equal to 0 and the value of Temporary
allowed processes memory amount differs from -1.
The default value is 300 seconds.
Number of infobases per process
NOTE. Available only for CORP licenses.
Maximum number of infobases whose connections can be processed by a
single working process on this server. A zero value means that no limit is
set.
If the amount of infobases exceeds this amount - the servers cluster will
create at this working server an additional working process.
Number of connections per process
Maximum number of infobase connections that a single working process of
this server can process. A zero value means that no limit is set.
If the amount of connections maintained by working process exceeds tis
amount- the servers cluster will create on this server an additional working
process.
Main cluster manager port
Number of network port of the main cluster manager running on this work-
ing server. This network port is used when generating the server cluster
address for client application. The address is as follows: <Computer prop-
erty>: <Main cluster manager port>. If the Computer property is set to
COMP1 and the Main cluster manager port property is set to 2541, the
server cluster address is COMP1:2541.
The value of this parameter is ignored if the Central server check box is
not selected.
Dedicated manager for each service
Enables allocating a separate cluster manager for each type of service. If
this check box is selected, a dedicated cluster manager will be created for
each cluster service type. Otherwise, all cluster services are assigned to the
same cluster manager of the working server.
TIP. This property can be set during trial operation.

Central server
If this check box is selected, the cluster registry will be synchronized with
this working server and the client applications will use the address of this
working server to connect to the cluster.
5.2.6.2. Viewing and editing cluster server
properties
To view or edit the properties of a cluster server, select a server in the list of
cluster servers and execute the Properties context menu command, or the
corresponding command in main menu of the utility.
The working server properties dialog box will be displayed.

Fig. 39. Properties of a working server

In addition to the properties that are displayed in the dialog box when creat-
ing a new server, the properties dialog box of the existing server also dis-
plays the internal network port of the server agent that was automatically
assigned on the server agent startup and is used for interaction between the
server cluster processes.
In the properties of an existing server, only the network port range is edita-
ble.

5.2.6.3. Removing servers from cluster

Removing a working server can cause client connections to terminate ab-
normally. To avoid this, add this functionality assignment rule (with the
highest priority) before removing the server:
• Object type: Any requirement object.
 • Rule type: Do not assign.
• Infobase name: do not specify.
• Additional parameter value: do not specify.
Then, apply a new set of rules and wait until the existing connections termi-
nate. Then, remove the working server using the Delete context menu
command, or the corresponding main menu command.
You cannot delete the last working server with property Central server
enabled.

5.2.6.4. Functionality assignment rules

To view the list of functionality assignment rules for a specific working
server, select the server in the central server tree. Then, select a cluster and
a working server. Then, select the Functionality assignment rules branch.

Fig. 40. Functionality assignment rules

To create a new rule be sure to select Create - Functionality assignment
rule in context menu or in menu Activity of main menu.

Fig. 41. New functionality assignment rule

The rules are processed in the order they are placed in the rules list for the
server. The processing order (rule priority) is determined by the column
Number of the functionality assignment rule list. The smaller the number,
the higher the priority and the earlier the request will be processed. To
change the priority of a rule, place the cursor over the rule, open the context
menu (or the Action submenu of the main menu), and select the Increase
rule priority or Reduce rule priority command, depending on whether you
need to increase or decrease the rule priority.

Fig. 42. Chaning a rule priority

The functionality assignment rules do not take effect until they are explicit-
ly applied.
5.2.7. Operations with list of
infobases
To display the list of infobases registered in a cluster, select a server in the
central server tree, select a cluster registered on this server, and then select
and expand the Infobases branch.

Fig. 43. List of infobases

The central server tree contains a list of infobases in the cluster. Each in-
fobase is identified by name. The properties field displays a list of infobases
of the selected cluster, containing the name and description of each in-
fobase.

5.2.7.1. Registering a new infobase

Registration of a new infobase in a server cluster can be performed:
• from the client application
• directly in the server cluster
When a new infobase is added in the client application, it is automatically
registered in the server cluster.
To register a new infobase using the server cluster administration utility,
select a central server in the central server tree, select a cluster registered on
this server, select the Infobases branch and execute context menu com-
mand New - Infobases or the corresponding command in main menu of
the utility.
The infobase properties dialog box will be displayed.

Fig. 44. New infobase

Parameters of the infobase are identical to the parameters of the new in-
fobase created using the 1C:Enterprise launcher.
Please pay attention to the Allow 1C:Enterprise server to issue licenses
parameter. This parameter controls whether 1C:Enterprise server can issue
client licenses. If the parameter is set to Yes, the 1C:Enterprise server will
issue client licenses whenever the client application fails to get a client li-
cense. If the parameter is set to No, the 1C:Enterprise server will not issue
client licenses. In this case, the client application that fails to get a client
license will display message: License not found. No protection key or
software license found.
IMPORTANT! Infobases names must be unique within each cluster.
When registering a new infobase, a check is made whether an infobase with
the same name exists on the specified database server. If the infobase exists,
a connection with it will be established. If the existing database already con-
tains 1C:Enterprise infobase data, a connection will be established with the
existing infobase. If the database does not contain infobase data, a new
1C:Enterprise infobase will be created in it.
5.2.7.2. Viewing infobase properties
To view and change the properties of an infobase, select the infobase in the
infobase list and execute the Properties context menu command, or the
corresponding command in main menu of the utility.

Fig. 45. Infobase properties

In the infobase parameter properties window, you can edit the names of the
database server and the database, change the type of DMBS used, the data-
base user name and password.
Properties related to locks of user sessions with this database are also edita-
ble.
Session start lock enabled
If the check box is selected, session start lock is enabled for the infobase.
Further:
 • Existing sessions can continue
• Existing sessions can start background jobs
• Existing sessions can establish connections
• Opening new sessions is not allowed
• Establishing new connections is not allowed, except by existing ses-
sions
Start (lock start date/time)
The lock takes effect if the current time exceeds the value of this property.
End (lock end date/time)
The lock ends if the value of this property is non-zero and less than or equal
to the current time.
Message
Text that will be included in the error message when trying to establish a
connection to a blocked infobase.
Permission code
This string is added to the /UC command-line parameter or to the UC con-
nection string parameter to establish a connection to the infobase regardless
of connection lock.
Lock parameter
Arbitrary text. It can be used in configurations for various purposes.
Scheduled job lock enabled
If this check box is selected, scheduled job lock is enabled for this infobase.
External session management
A string describing the parameters of the external session management web
service. The web service parameter string has the following format:
Parameter = Value;. The parameter string contains 4 mandatory pa-
rameters (wsdl, ns, srvc, port) and two optional parameters (tout,
wsver):
• wsdl - is the URL used to get WSDL description of the web service.
• ns - is the web service namespace.
• srvc - is the name of the web service that will be used for external
session management.
• port - port is the name of the web service port.
 • tout - is the maximum timeout for external session management web
service, in seconds. The default value is - 5 seconds.
• wsver - is the version number of the external session management
web service. The default value is 2.
An example of web service description string:
wsdl=http://server/sm/ws/manager?wsdl;ns=http://v8.1c.ru/SessionMan
ager;srvc=manager;port=managerSoap;tout=10;wsver=1;

External management required

If the check box is selected, an error occurs when the external session man-
agement web service is unavailable and connection to the infobase cannot
be established. If the check box is cleared and the web service is unavaila-
ble - the connection can be established and no restrictions are applied on the
number of concurrent sessions.
Security profile
If you specify the name of a security profile in this field, the security profile
applies its restrictions to the server-side application.
Safe mode security profile
If you specify the name of a security profile in this field, the security profile
applies its restrictions to the application segments running in safe mode.
Workflow backup
If you check this check box, a server cluster starts to create backup working
processes for this infobase.

5.2.7.3. Deleting infobases

To delete an infobase, select an infobase in the list and execute the Delete
context menu command, or the corresponding command in main menu of
the utility.
A warning will be displayed: Do you want to delete the infobase? If you
confirm, you will be offered a choice of three options for deleting the in-
fobase.

Fig. 46. Infobase deletion mode

• Delete database - If you select this option, registration of the in-
fobase in the server cluster will be deleted, and the corresponding da-
tabase on the database server will also be deleted.
• Clear database - If you select this option, registration of the in-
fobase in the server cluster will be deleted, and all data will be deleted
from the corresponding database on the database server. The database
itself will not be deleted from the database server.
• Make no changes -If you select this option, only registration of the
infobase in the server cluster will be deleted. No changes will be made
to the database.
If you select the Delete database option while the database has active user
connections, registration of the infobase in the server cluster will be deleted
but the database will not be deleted and the database server will display an
error message, such as:

Fig. 47. Error deleting infobase

5.2.8. Operations with list of

cluster administrators
You can create a separate list of administrators for each cluster registered on
the central server, so that only authenticated users can perform administra-
tive actions with the cluster.
By default, the list of cluster administrators is empty. This means that clus-
ter administrator authentication is not required.
To display the list of cluster administrators, select a server in the central
server tree, select a cluster registered on this server, and then select and ex-
pand the Administrators branch.

Fig. 48. List of cluster administrators

The central server tree contains the list of administrators of the selected
cluster. Each administrator is identified by name. The properties field dis-
plays a list of administrators of the selected cluster, containing the name and
description of each administrator.

5.2.8.1. Adding cluster administrators

To add a cluster administrator, select a server in the central server tree, se-
lect a cluster registered on this server, select the Administrators branch and
execute context menu command New-Administrator or the corresponding
command in main menu of the utility.
The cluster administrator properties dialog box will be displayed.

Fig. 49. New cluster administrator

You need to enter the following data in the dialog box fields:
Name
Name of the cluster administrator.
Description
Arbitrary description of the cluster administrator.
Password authentication
Flag indicating that password authentication is enabled. It is set by default.
Password
Password of the cluster administrator.
Password confirmation
Password confirmation.
OS authentication
Flag indicating that OS authentication is enabled.
User
OS user. The user name must follow this format: \\domain name\user
name Example: \\domainname\username. You can directly specify a
user by entering their name, or select a user from the OS user list available
on a computer running the infobase administration utility. To select a user
from the list, click the "..." button and select a OS user.
IMPORTANT! Names of the cluster administrators must be unique within
each cluster.
Two methods of cluster administrator authentication are supported:
• using a password
• using OS functionality
When authenticating with a password, a cluster administrator authentication
dialog box is displayed. You are required to enter a username and password.
When authenticating using the OS functionality, you are not required to
enter a username or password. The authentication dialog box is not dis-
played. The cluster administrator is selected depending on the OS user on
whose behalf the connection was established.
If no authentication type is specified for an administrator, this administrator
can perform only those actions that do not require authentication.

5.2.8.2. Viewing and editing cluster

administrator properties
To view or edit the properties of a cluster administrator, select an adminis-
trator in the list of cluster administrators and execute the Properties context
menu command, or the corresponding command in main menu of the utility.
The cluster administrator properties dialog box will be displayed.

Fig. 50. Cluster administrator properties

All properties, with the exception of the administrator's name, are editable.
The values of the Password and Confirm Password fields are hidden.

5.2.8.3. Deleting cluster administrators

To delete a cluster administrator, select the administrator in the list of clus-
ter administrators and execute the Delete context menu command, or the
corresponding command in main menu of the utility.
5.2.8.4. Cluster administrator authentication
Authentication is automatically requested from a cluster administrator when
they attempt to perform an action requiring authentication (provided that the
list of cluster administrators is not empty). The cluster administrator authen-
tication dialog box is displayed.
You need to enter the following data in the dialog box fields:
Name
Name of the cluster administrator.
Password
Password of the cluster administrator.

5.2.9. Viewing list of cluster

managers
You can view and edit the list of cluster managers. By default, one cluster
manager is set as the primary cluster manager. It is defined in all clusters.

Fig. 51. Cluster managers

The cluster determines the number and location of cluster managers. The
number and location of cluster managers is affected by the functionality
assignment rules and the working server properties Dedicated manager
for each service and Central server. The administrators cannot manually
add or delete cluster managers.
To view description of a cluster manager, use the Properties command in
the context menu of the cluster manager.
A window will be displayed where you can edit the description of the clus-
ter manager.

Fig. 52. Cluster manager properties

5.2.10. Viewing a list of working

processes
The list of working processes can be displayed:
• For the entire cluster
• For a cluster server
To display a list of working processes for the entire cluster, select a server
in the central server tree, select a cluster that is registered on this server, and
then select and expand the Working processes branch.

Fig. 53. Working process list

To display the list of working processes for the selected cluster server only,
select a server in the central server tree, select a cluster, select a cluster
server, and then select and expand the Workflows branch.

Fig. 54. List of working processes on a specific working server

The central server tree contains a list of working processes. Each working
process is identified by a server name and a sequence number in that work-
ing server. The property field displays technical information that describes a
particular working process. The description of the displayed parameters is
given below.
To view the properties of a working process, select a working process in the
list of working processes and execute the Properties context menu com-
mand, or the corresponding command in main menu of the utility. The ad-
ministrators cannot manually add or delete working processes.
The working process properties dialog box will be displayed.

Fig. 55. Working process properties

The working process properties dialog box contains the following fields that
are not editable:
Computer
Name of the working server where the working process runs.
Enabled
The working process is currently enabled and can be used.
Active
The working process is currently in use.
Backup
Currently, this is a backup working process.
Start time
Last start time of the working process .
IP port
Network port of the working process dynamically selected on working pro-
cess startup from the range of network ports specified for the server.
Connections
Current number of connections processed by the working process.
OS process PID
The process number (in terms of the OS running the working process).
Occupied memory
The amount of memory occupied by the working process.
Available performance
Current available performance.
Server response
The average time spent on processing a connection. Equal to the sum of the
values of the following fields:
• Spent by server
• Spent by DBMS
• Spent by client
• Spent by lock manager
Spent by server
The average time consumed by a working process for processing a connec-
tion.
Spent by DBMS
The average time consumed by a DBMS for processing a connection.
Spent by client
The average time spent by a client for processing a connection.
Spent by lock manager
The average time spent by a working process for processing a connection.
Client threads
The average number of client threads processed by the working process.
Used to calculate working process performance.
Server license
This field displays information about a server license used by this working
process and a description of this license.
5.2.11. Operations with list of
sessions
5.2.11.1. General information
The list of sessions can be displayed:
• For the entire cluster
• For an infobase
To display a list of sessions for the entire cluster, select a central server in
the central server tree, select a cluster registered on this server, select and
expand the Sessions branch.

Fig. 56. List of server cluster sessions

To display the list of connections for a specific database, select a central
server in the central server tree, select a cluster, select an infobase, and then
select and expand the Sessions branch.

Fig. 57. List of infobase sessions

The properties field displays a list of sessions containing the following in-
formation:
Infobase
Name of the connected infobase.
Session number
Session number.
Start time
Time of session creation.
Last activity
Time of the last activity of the session.
Computer
Network name of the computer running the client application that initiated
creation of the session. The computer name will be empty if the session is
created by web client, thin client connected via a web server, or a web ser-
vice.
User
Name of the infobase user.
Application
Client application startup mode.
Language
Application localization language.
Server
Name of the connected cluster server.
Port
Number of the network port of the working process servicing this connec-
tion.
OS process
Process number of the working server (in terms of the operating system)
that is processing this session.
Join
Number of the connection established to this session.
Database connection
ID of the database server process. Displayed if the connection to the data-
base is currently captured by the session: either a database call is in pro-
gress, or the transaction is open, or the TempTablesManager object con-
taining at least one temporary table is captured.
Database capture time
Duration of the capture of the connection to the database by the current ses-
sion, from the moment of capture to the current moment. It is only dis-
played if the database connection is captured by the session.
Database locked
ID of the process that locked the process.
Control locked
User name (session number) in the event that a process is waiting for a
transaction lock to be released.
Database call time (current)
Time since the start of the current database call (in seconds).
Database call time (5 min)
Total duration of database calls in the last five minutes (in seconds).
Database call time (total)
Total duration of database calls since the beginning of the first call (in sec-
onds).
Database data (5 minutes)
Amount of data sent over this client connection between the 1C:Enterprise
server and the database server in the last 5 minutes (in bytes).
Database data (total)
Amount of data sent over this client connection between the 1C:Enterprise
server and the database server since the beginning of this session (in bytes).
Call time (current)
Current execution time of the latest incomplete server call.
Call time (5 min)
Total duration of server calls by this connection in the last five minutes (in
seconds).
Call time (total)
Total duration of server calls since the client connection was established (in
seconds).
Number of calls (5 min)
Number of times this connection called the server in the last five minutes.
Number of calls (total)
Number of times this connection called the server since the client connec-
tion was established.
Amount of data (5 min)
Amount of data sent and received in the last five minutes (in bytes).
Amount of data (total)
Amount of data sent and received since the client connection was estab-
lished (in bytes).
Memory (current)
Difference between the amounts of memory occupied and released by the
thread making the current call, since the beginning of the call (in bytes).
Memory (5 min)
Difference between the amounts of memory occupied and released by the
threads making calls for this session, in the last five minutes (in bytes).
Memory (total)
Difference between the amounts of memory occupied and released by the
threads making calls for this session, since the session was opened (in
bytes).
Read (current)
Amount of data read from disk since the current call was initiated (in bytes).
Read (5 min)
Amount of data read by this session from disk in the last five minutes (in
bytes).
Read (total)
Amount of data read by this session from disk since the session was opened
(in bytes).
Write (current)
Amount of data written to disk since the beginning of the current call (in
bytes).
Write (5 min)
Amount of data written by this session to disk in the last 5 minutes (in
bytes).
Write (total)
Amount of data written by this session to disk since the session was opened
(in bytes).
License
Summary of the client license used by this session.
Hibernating
Indicates that the session is hibernating.
Hibernate in
Time period (in seconds) after which an inactive session enters hibernation
mode.
Complete in
Time period (in seconds) after which a hibernating session is terminated.
Call time (current)
Current running time of the cluster service. Name of the service is specified
in the Current service property.
Current service
Name of the service that is currently running. If the column is empty, it
means that no cluster services are running currently.
Service call time (5 min)
Total running time of all cluster services in the last 5 minutes.
Service call time (total)
Total running time of all cluster services since the beginning of the session.
NOTE. Information on the processor time used (the parameters described
below) is displayed in seconds, with an accuracy of 3 decimal places (a mil-
lisecond accuracy).

CPU usage time (current)

Information on the consumption of CPU time by the current server call,
with millisecond accuracy.
CPU usage time (5 min)
Information on the consumption of CPU time by server calls in the last 5
minutes, with millisecond accuracy.
CPU usage time (total)
Information on the consumption of CPU time by server calls during the en-
tire session, with millisecond accuracy.

5.2.11.2. Viewing session properties

To view the session properties, select a session in the session list and exe-
cute the Properties context menu command, or the corresponding com-
mand in main menu of the utility.
The session properties dialog box will be displayed.

Fig. 58. Session properties

The session properties dialog box contains the following information (all
session properties are not editable):
Infobase
Name of the infobase used to open the session.
Session number
Session number.
Session start
Time of session creation.
Last call
Time of the last activity of the session.
Computer
Network name of the computer running the client application that initiated
creation of the session. The computer name will be empty if the session is
created by web client, thin client connected via a web server, or a web ser-
vice.
User
Name of the infobase user.
Application
Client application startup mode.
Interface language
Localization language of the client application.
Working server
Name of the connected cluster server.
Port
Number of the network port of the working process servicing this connec-
tion.
OS process
Process number of the working server (in terms of the operating system)
that is processing this session.
Connection number
Number of the connection established to this session.
Client license
This field displays information about a client license used by this session
and a description of this license.
5.2.11.3. Terminating sessions
To terminate a session, select a session in the list of sessions and execute
the Delete context menu command, or the corresponding command in main
menu of the utility. If the session is assigned to a connection at the time of
termination, an attempt is made to break the connection.

Fig. 59. Terminating sessions

Before termination, you will be asked to provide an error message that will
be displayed to the user who started the session to be terminated.
IMPORTANT! Take care when using this feature, since termination of an
active user session may result in a massive data loss.
To terminate a session, you need server cluster administrator privileges.

5.2.12. Operations with list of

connections
5.2.12.1. General information
The list of connections can be displayed:
• For the entire cluster
• For a cluster working process
• For an infobase
• For a cluster server working process
To display the list of connections for the entire cluster, select a central serv-
er in the central server tree, select a cluster registered on this server, and
then select and expand the Connections branch.

Fig. 60. Cluster connections

To display a list of connections for a cluster working process, select a cen-
tral server, select a cluster, select Working processes branch, select a
working process, and then select and expand the Connections branch.

Fig. 61. Working process connections

To display the list of connections for an infobase, select a central server in
the central server tree, select a cluster, select an infobase, and then select
and expand the Connections branch.

Fig. 62. Infobase connections

To display the list of connections for a cluster server working process, se-
lect a central server in the central server tree, select a cluster, select a cluster
server, select a working process, and then select and expand the Connec-
tions branch.

Fig. 63. Working process connections

Connections are not displayed in the central server tree. The property field
displays a list of connections containing the following information:
Infobase
Name of the connected infobase. This field is empty when using technical
connections.
Join
Connection number. Number of each new infobase connection is incre-
mented by 1. A new connection can only have number 1 assigned if no con-
nections were established to the infobase previously. Number 0 is only as-
signed to technical connections that are not associated with any infobase.
Thus, both in the file and in the client/server version, the numbering of con-
nections starts from 1, only after all clients, including the scheduled and
background jobs, disconnect from the infobase.
Session
Session number associated with the connection.
Computer
Network name of the computer establishing the connection.
Application
Identifier of the application using this connection.
Server
Name of the connected cluster server.
Server port
Number of the network port of the working process servicing this connec-
tion.
Getting started
Time when this connection was established.
If the list of connections is open for an infobase, additional columns are
displayed in the properties field, allowing you to quickly analyze database
locks. A list of these properties is given in the next section.
5.2.12.2. Viewing connection properties
To view the connection properties, select a connection in the list of connec-
tions and execute the Properties context menu command, or the corre-
sponding command in main menu of the utility.

Fig. 64. Infobase connection list

The connection properties dialog box will be displayed.

Fig. 65. Connection properties

The connection properties dialog box contains the following information
(all connection properties are not editable):
User
User on whose behalf this connection is established.
Computer
Name of the computer that established the connection.
Application
Name of the application that established the connection to the infobase.
Exclusive infobase lock
Indicates that an exclusive infobase lock has been established.
Database
Indicates that database connection was established.
Exclusively
Indicates that an exclusive infobase mode was set.
Server
Name of the server to which you are connected.
Server port
Network port of the server used for the connection.
Getting started
Time when the connection was established.
Join
Identifier of the connection.
Database connection
ID of the database server process. It is displayed if the connection currently
performs a database call.
Database capture time
Duration of database server access at the moment of opening the properties
dialog box. It is displayed if the connection currently performs a database
call.
Database call time (total)
Total duration of database calls since the beginning of the first call (in sec-
onds).
Database call time (5 min)
Total duration of database calls in the last 5 minutes (in seconds).
Database call time (current)
Time since the start of the current database call (in seconds).
Database data volume (total)
Amount of data sent over this client connection between the 1C:Enterprise
server and the database server since the beginning of this session (in bytes).
Database data volume (5 min)
Amount of data sent over this client connection between the 1C:Enterprise
server and the database server in the last 5 minutes (in bytes).
Database locked
ID of the process that locked the process.
Locked
User name (connection number); displayed if a process is waiting for a
transaction lock to be released.
Call time (total)
Total duration of server calls since the client connection was established (in
seconds).
Call time (5 min)
Duration of server calls by this connection in the last 5 minutes.
Call time (current)
Current execution time of the latest incomplete server call.
Number of calls (total)
Total number of server calls made by this connection since it was estab-
lished.
Number of calls (5 min)
Number of times this connection called the server in the last five minutes.
Amount of data (total)
Amount of data transmitted and received since this connection was estab-
lished (in bytes).
Amount of data (5 min)
Amount of data transmitted and received in the last 5 minutes (in bytes).
Memory (total)
Amount of RAM used for calls since this connection was established (in
bytes).
Memory (5 min)
Amount of RAM used for calls in the last 5 minutes (in bytes).
Memory (current)
Amount of RAM used since the current call was initiated (in bytes).
Read from disk (current)
Amount of data read from disk since the current call was initiated (in bytes).
Read from disk (total)
Amount of data read from the disk by this session since the connection was
established (in bytes).
Read from disk (5 min)
Amount of data read from disk by this connection in the last 5 minutes (in
bytes).
Write to disk (total)
Amount of data written to disk by this connection since the session was
opened (in bytes).
Write to disk (5 min)
Amount of data written by this session to disk in the last 5 minutes (in
bytes).
Write to disk (current)
Amount of data written to disk since the beginning of the current call (in
bytes).
The following properties are available only in the connection list of an in-
fobase and are not displayed in the connection properties.
Call time (current)
Current running time of the cluster service. Name of the service is specified
in the Current service property.
Current service
Name of the service that is currently running. If the column is empty, it
means that no cluster services are running currently.
Service call time (5 min)
Total running time of all cluster services in the last 5 minutes.
Service call time (total)
Total running time of all cluster services since the beginning of the session.
5.2.12.3. Terminating a connection
To terminate a connection, select the connection in the list of connections
and execute the Delete context menu command, or the corresponding
command in main menu of the utility.

Fig. 66. Deleting a connection

IMPORTANT! Take care when using this feature, since termination of an

active user connection may result in a massive data loss.
If a large query to a Microsoft SQL Server database, IBM DB2, or Oracle
Database is in progress, 1C:Enterprise server attempts to terminate the con-
nection. The attempt succeeds if the connecting user has the appropriate
permissions (for more information about the required database user rights,
see the documentation for the database you are using). If the connection is
completed successfully, the user will receive message: The session is
terminated by the administrator. PostgreSQL database connections can-
not be terminated. If you try to execute a delete command, no action will be
performed.
If the client runs code on the 1C:Enterprise server, the 1C:Enterprise server
will attempt to disconnect the client application from the server. To termi-
nate a connection, you need the rights of a server cluster administrator and
infobase administrator. If the connection is completed successfully, the user
will receive message: The session is terminated by the administrator.
A connection cannot be terminated while the 1C:Enterprise server performs
a client call and only one 1C:Enterprise language code line is being execut-
ed (except for database calls). For example, a connection cannot be termi-
nated when a long call to a COM object method or an HTTP call is made
from code in 1C:Enterprise language.
5.2.13. Operations with list of
locks
The list of locks can be displayed:
• For the entire cluster (all locks, or by connections)
• For an infobase (all locks, or by connections)
To display a list of locks for the entire cluster, select a central server in the
central server tree, select a cluster registered on this server, and then select
and expand the Locks branch.

Fig. 67. List of cluster locks

If you then select the All branch, a list of all cluster locks will be displayed.
You can also expand the By sessions branch and select a session. The list
of locks for the selected session will be displayed.

Fig. 68. List of cluster locks by session

To display the list of locks for an infobase, select a central server in the cen-
tral server tree, select a cluster, select an infobase, and then select and ex-
pand the Locks branch.
If you then select the All branch, a list of all locks for this infobase will be
displayed.

Fig. 69. List of all locks

You can also expand the By sessions branch and select a session. The list
of locks for the selected session will be displayed.

Fig. 70. List of locks by session

If you choose to view the list of locks for a connection, the central server
tree will contain a list of connections. Each connection is identified by the
number and name of the user's computer.
The property field displays a list of locks containing the following infor-
mation:
Lock
Contains a view of the lock type and their basic parameters. There are the
following types of locks:
• Infobase locks:
 DB - blocking data base of "1C:Enterprise". Parameters:
 Lock source (session or connection)
 Infobase name
 Shared or exclusive
 If the infobase is shared, this parameter contains information
about the parameters of the locked area in the format of the / Z
parameter of the client startup command line. If a background
job reacquires the exclusive lock from the parent session, this
parameter contains the parent session's ID number in >> Ses-
sionNumber format, and the parameters of the locked area are
listed in the next parameter.
 IB - infobase lock. Parameters:
 Lock source (session or connection)
 Infobase name
 Shared or exclusive
 Designer - exclusive blocking of designer. Parameters:
 infobase name.
• DB object - exclusive blocking of "1C:Enterprise" object. Parameters:
 infobase name
• Cluster locks:
 Manager of cluster - activity of cluster manager process. Parame-
ters:
 Server name
 Ports of the cluster manager process
 Working process - activity of "1C:Enterpise" working process.
Parameters:
 Server name
 Ports used by cluster working process
 Connection - connection to working process of cluster by TCP or
a scheduled job. Parameters:
 Name of the server context (may be identical to the infobase
name)
 Computer name and identifier of the application from which
the connection is established
 infobase names and connection numbers if the connection is
associated with any infobases
Infobase
Name of the infobase the lock applies to. Empty if the lock is not applied to
an infobase.
Join
Number of infobase connection. May be empty if:
• Lock does not apply to an infobase
• Lock source is a session not assigned to any connection
Session
Number of session that applied the lock. May be empty if:
• Lock does not apply to an infobase
• Lock source is a connection with no sessions assigned to it
Computer
Name of the client computer used to set the lock. Empty if the lock source is
a server-side process.
Application
Name of the client application that set the lock. Empty if the lock source is a
server-side process.
Server
Name of the server of the working process responsible for the lock. Empty
if the lock source is a server-side process or a session not assigned to any
connection.
Server port
Network port of the working process responsible for the lock. Empty if the
lock source is a server-side process or a session not assigned to any connec-
tion.
Locked on
Time when the lock was set.
5.2.14. Operations with list of
security profiles
To display a list of infobases registered in a cluster, select a server in the
central server tree, select a cluster registered on this server, and then select
and expand the Security profiles branch.

Fig. 71. Security profile list

The central server tree contains a list of cluster security profiles. Each secu-
rity profile is identified by a name. The properties field displays a list of
security profiles of the selected cluster, containing the name and description
of each profile.

5.2.14.1. Adding profiles

To add a security profile to the cluster, select a central server in the central
server tree, select a cluster registered on this server, select the Security
profiles branch and execute context menu command Create - Security
profileor the corresponding command in main menu of the utility.
The security profile properties dialog box will be displayed.

Fig. 72. New security profile

You need to enter the following data in the dialog box fields:
Name
Name of the security profile. The name must be unique within the cluster.
Description
Arbitrary description of the security profile.
Can be used as a safe mode security profile.
Indicates that the name of this profile can be specified as the value of the
SafeMode parameter of the SetSafeMode() global context method, the
Create () and Connect () methods of the external data processor
manager, the Create () and Connect() methods of the external report
manager, and also that it can be passed as the result of the SafeMode()
global context function.
Privileged mode roles
You can assign roles (separated by ;) to be used when privileged mode is
switched on, while to privileged mode check box is not checked.
Roles that restrict the extension of access rights:
Allows you to specify the roles (using the separator ";") that prevent the
extension of the rights of the extensible configuration from the extension.
Modules available for extension:
Contains a list of modules that can be extended with extensions.
Modules not available for extension:
Contains a list of modules that cannot be extended with extensions.
to server file system:
Indicates whether the application can access the file resources of the com-
puter on which the 1C:Enterprise server is running.
to COM objects:
Indicates whether the application can interact with the COM objects of the
computer on which the 1C:Enterprise server is running. This option does
not apply for servers running Linux.
to add-ins:
Indicates whether the application can interact with add-ins on the
1C:Enterprise server.
to external modules:
Indicates whether the application can use external modules (external re-
ports, data processors, and configuration extensions), as well as the
Execute() operator and the Calculate() function.
to OS applications:
Indicates whether the application can access OS applications on the
1C:Enterprise server. The list of applications depends on the operating sys-
tem used to run the 1C:Enterprise server.
to Internet resources:
Indicates whether the application running on the 1C:Enterprise server can
access Internet resources.
to privileged mode:
Defines the mode of verification of access rights (and applicable data access
restrictions), when the current session is managed by a security profile.
to cryptographic functions:
Indicates whether the application running on the 1C:Enterprise server can
access Internet resources.
to extension of access rights:
Indicates whether access permissions of the main configuration for any ob-
ject of the extendable configuration can be extended.
to extension of all modules:
Indicates whether all server configuration modules can be extended with
any extension.

5.2.14.2. Viewing and editing profile settings

To view or edit the security profile settings, select a profile in the list of
cluster security profiles and execute the Properties context menu com-
mand, or the corresponding command in main menu of the utility.
The security profile properties editing dialog box will be displayed.

Fig. 73. Security profile properties

Some profile parameters allow you to create exceptions from general re-
strictions. For example, you can deny access to all directories in the server
file system, except for specific directories included in the list of exceptions.
In order to create an exception from any security profile restriction, select
an item subordinate to the selected virtual directory and select the command
Create - Name of the item to be created, for example, Create-Virtual
Directory.
This will open a window that displays the Description property describing
the item being created, and other parameters as described in the correspond-
ing section of the general description of the security profile.

5.2.14.3. Deleting profiles

To delete a security profile, select the profile in the list of security profiles
and execute the Delete context menu command, or the corresponding
command in main menu of the utility.
5.2.15. Operations with resource
management mechanism
5.2.15.1. Resource consumption counters

5.2.15.1.1. General information

NOTE. Available only for CORP licenses.

Resource consumption counters are designed to collect and accumulate sys-
tem performance information. Each counter has a name, a description, and a
set of properties that describe the accumulated information.
The information accumulated by the counters can be displayed in the cluster
console, and can be used by the resource consumption limiting mechanism.
The resource consumption limiting mechanism uses the data from the coun-
ters as a basis for making decisions to restrict user actions.
The counter accumulates information for a single server call or for a speci-
fied time period. The counter operation mode is set using the Collection
duration property:
• Server call - The counter accumulates all data from the current server
call
• Other value -The counter accumulates data for the time period speci-
fied in the property Collection duration time frame. A sliding win-
dow of the specified size is used to accumulate data.
The counter accumulates the following information:
• Time spent on the following actions:
 Server calls - time from the start to the end of the server call, in
milliseconds. Based on the Call time value in the session proper-
ties.
 CPU time - processor time used for a server call, in milliseconds.
Based on the CPU time value in the session properties.
 DBMS call time -time used for a DBMS call, in milliseconds.
Based on the Database call time value in the session properties.
 Service call time -time used for cluster service operations, in
milliseconds. Based on the Service call time value in the session
properties.
• Amount of data processed during the measurement:
  Memory -amount of RAM currently used by the session, in bytes.
This indicator always shows the current value. Based on the
Memory (total) value in the session properties.
 Read - data volume read from disk, in bytes. Based on the Read
value in the session properties.
 Write- amount of data written to disk, in bytes. Based on the Write
value in the session properties.
 DBMS data- amount of data volume that was sent and received
during DBMS operations, in bytes. Based on the Database data
value in the session properties.
• Quantitative indicators:
 Number of calls -number of server calls. Based on the Number
of calls value in the session properties.
 Number of active sessions- current number of active sessions.
 Number of sessions- total number of sessions per measurement
period. It includes both active sessions and completed sessions.
Depending on the data collection duration, different session properties may
be used to calculate the indicators:
• When calculating data per server call, a session property with the
(current) suffix is used as the initial information. For example, to cal-
culate the duration of a server call, the Call time (current) property is
used.
• When calculating data per time period, the difference between the to-
tal value of the indicator at the end and at the beginning of the period
is used. Thus, to calculate the Server calls value for the period, Call
Time (total) value at the end of period is subtracted from Call Time
(total) value at the beginning of period.

5.2.15.1.2. Viewing and editing counter settings

To create a resource consumption counter, open the branchResource con-
sumption countersand select Create-Resource consumption counter in
the context menu. To edit the counter parameters, select a counter in the list
and execute the Properties command in the context menu.
In both cases, a window with counter parameters will open. When editing
an existing counter, the Name property is not editable.

Fig. 74. Resource consumption counter

The Name and Description properties are used to identify and describe the
counter. The Collection duration property describes how long the counter
will collect data. Each counter can be created in the context of a certain
property, meaning that the number of counter instances created is equal to
the number of unique values for this property. The Grouping property al-
lows you to specify the counter property that will be used when creating a
new instance:
• Users - the counter separately accumulates data for sessions running
on behalf of different 1C:Enterprise users.
• Data separation- the counter separately accumulates data for ses-
sions working with different data areas.
When changing the valueGroupthe counter is cleared (all fields are delet-
ed). Next the counter starts accumulating new values in accordance with
new group data. The change of other counter properties does not cause the
countere clearing.
The Filter and Filter type fields allow you to specify how the sessions used
by the counter will be filtered. In the Filter field, the filter values are indi-
cated. You can set filters:
• By infobase (infobase parameter).
 • By values of the separators that describe the data area (data-
separation parameter). Values of the separators that describe the
data area are set in the same way as /Z client startup command line
parameter.
• By user name (user parameter).
• By ID of the application using the session (appID parameter). Value
of this parameter is equal to the value of the
InfobaseConnectionApplicationName property.
• By security profile (parametersafe-mode-profile-name). For
the selection based on by default security profile leave the fields titles
blank, for example: safe-mode-profile-name=;.
• By means of secure mode installation (parametersafe-mode). The
property value can have two meanings: on (security mode is connect-
ed) and off (security mode is disconnected).
The parameter value can be compared for equality (operator =) or for ine-
quality (operator <>). Some filter conditions can be combined "by AND".
"|" operator is used to group conditions "by OR". For example, see below:
infobase=IB; user<>Admin; user<>Руководитель; safe-mode-profile-
name=profile | infobase<>IB; safe-mode=on

which will be interpreted as follows:

• This filter has the following two conditions:
 First condition: infobase is equal to IB AND user is not equal to
Admin AND user is not equal to Manager ANDsecurity profile
is equal to profile.
 Second condition: infobase is not equal to IB AND a safe mode is
selected.
• The first and second conditions are combined "by OR".
The property Filter type allows you to specify the filter mode in general:
equality or inequality.

5.2.15.1.3. Deletion of one or all items of counter

You can delete both counter or specific detail of selected counter. Both op-
erations are performed in the similar manner: select unit, which needs to be
deleted and select Delete command in this item context menu.
For deleting counter in whole be sure to select required counter in the clus-
ter units tree or in the counters list (having selected the point Resources
consumption counters in units tree).
The counter specific item is selected in the following way: first select re-
quired counter and next select required item from the list of this counter
item.

5.2.15.2. Resource consumption limits

5.2.15.2.1. General information

Different client applications create different load on the server cluster. This
load may adversely affect the overall performance of the cluster. For exam-
ple, if a user decides to get all records for all goods for the entire lifetime of
the infobase, such a report most likely will completely paralyze the entire
system for a long period of time. In addition, such a report may cause a
crash due to the exhaustion of available RAM or other similar reasons.
In order to detect such actions, you can create resource consumption coun-
ters in server cluster. You can also automatically restrict operations per-
formed by the users and data areas (depending on the counter grouping) that
exceed the resource consumption threshold. For this purpose, a resource
consumption limiting mechanism is used. The mechanism works in con-
junction with resource consumption counters.
Using the restriction mechanism, you can choose what to do with a session
that exceeded a specified threshold for one or several counter parameters.
The following options are available:
• End session - interrupt the server call and terminate the session.
• Interrupt server call -interrupt the server call but do not terminate
the session.
• Decrease thread priority-decrease the priority of a thread that is per-
forming the current server call.
• None-record the threshold violation in the technological log, but do
not restrict execution of the server call.
Regardless of the selected option, a record is added to the technological log.
The restriction mechanism operates as follows:
1. One or more counters with the desired characteristics are created.
2. For each counter, you can create a rule that specifies the threshold
values for any counter parameters; once the threshold is exceeded, the
restrictive action is performed. The restrictive action is only per-
formed when all thresholds are exceeded at the same time. However,
only the first threshold violation is recorded in the technology log.
3. The counter and rules take effect.
Please keep in mind that for counters set up to analyze indicators for a peri-
od of time, executing restrictions of End session and Interrupt server call
types will prohibit any new server calls until the counter indicators fall be-
low their thresholds.

5.2.15.2.2. Viewing and editing restriction settings

To create a resource consumption counter, open the branch Resources
consumption counters and select in context menu the pointCreate - Re-
sources consumption limitation. In order to edit the restriction parame-
ters, select a restriction in the list and execute the Properties command in
the context menu.
In both cases, a window with restriction options will open. When editing an
existing restriction, the Name property is not editable.

Fig. 75. Resource consumption limit parameters

The Name and Description properties are used to identify and describe
each resource consumption restriction. The Resource consumption coun-
ter property contains the name of the counter on the basis of which this re-
striction will work. This property is mandatory. Using the Action when
exceeded property sets the action that will be performed if the current
counter value exceeds the thresholds specified in this window.
The Threshold value... groups are used to specify the threshold values for
triggering the actions specified in the Action on exceeding property. The
values are described with the parameters of the resource consumption coun-
ter.
Text in the Error message property will be displayed to the user if the
server call or session is terminated.

5.2.15.2.3. Deleting restrictions

To delete a resource consumption restriction, select the restriction in the list
and execute the Delete context menu command, or the corresponding
command in main menu of the utility.

5.3. Server cluster

administration software
5.3.1. Using 1C:Enterprise
language to access server
clusters
5.3.1.1. Via COM-connection
The 1C: Enterprise server cluster administration software interface is de-
scribed in the syntax assistant in the sectionIntegration and administra-
tion means -COM-connections manager - Servers cluster administra-
tion.
The usage of such mechanism is possible in case if "1C:Enterprise" applica-
tion from which the cluster administration is performed:
• Works under Windows OS control.
• Has the same number of version as the administered servers cluster.
Two objects are used for server cluster administration: ConnectServer-
Agent and ConnectWorkingProcess.
To get ConnectServerAgent, use the ConnectAgent() method of the
COM connector object:
COMConnector = New COMObject("V83.COMConnector");
ConnectServerAgent = COMConnector.ConnectAgent ("TestSrv");

Server agent connection is used to:

• Authenticate, add, delete, get a list of central server administrators and
cluster administrators
• Create, delete, get a list of clusters
• Create, delete, get a list of servers
• Create, delete, get a list of cluster working processes
• Get a list of cluster services
• Get a list of infobase sessions
• Get a list of cluster connections
• Get a list of infobase connections
• Get a list of infobases registered in the cluster
• Get a list of cluster locks
• Get other information
To get ConnectWorkingProcess, use the ConnectWorkingProcess()
method of the COM connector object:
COMConnector = New COMObject("V83.COMConnector");
ConnectWorkingProcess = COMConnect.ConnectWorkingProcess ("TestSrv:
1562");

Working process connection is used to:

• Authenticate infobase users
• Create, delete, get a list of infobases registered in the cluster
• Get a list of infobase connections
• Disconnect an infobase
• Connect to an infobase (COM connection)
• Get other information

5.3.1.2. With the help of servers cluster

administration
Software interface of "1C:Enterprise" servers cluster administration with the
help of server administration is described in syntax assistant in the section
Intergation and administration means-"1C:Enterprise" server admin-
istration.
"1C:Enterprise" system provides the possibility of administration of random
amount of clusters of "1C:Enterprise" system servers cluster with the help
of "1C:Enterprise" servers cluster administration (ras).
As it can be seen from the picture the overall administration scheme looks
like that:
 • Clients application is connected to any administration server.
• With the help of selected administration server the connection to re-
quired servers clusters is performed.
One can say that object model designed for the work via administration
server is the analogue of command line utility (rac), designed for the work
with the usage of administration server.
Taking into account the aforementioned information, the administration is
possible on the following conditions:
• The "1C:Enterprise", from which the administration is performed can
work under control of the following operational systems: Linux, ma-
cOS,Windows.
• It does not require the correspondence of "1C:Enterprise" application
version, from which the administration is performed and administra-
tion server versions and servers cluster ( taking into account admin-
istration servers).
• Control can be done both from client application and server applica-
tion side.
• "1C:Enterprise" client application, from which the administration
functions are performed can work in file option of infobase and is in
no way connected to the administered servers cluster by data.
In general case the scheme of operation looks the following:
• Connection to the required administration server.
• Authentication of administrator of cluster central server (in case of
any).
• Users gets the list of clusters available at selected central server.
• User performs authentication of specific cluster administrator (in case
of any).
• The following administration actions are being performed.
In the most simple case the example of software interface usage looks in the
following way:
Agent = New Serveradministration("localhost", 1545);
Agent.Authenticate();
Clusters = Agent.GetClusters();
For each cluster From clusters Cycle
Cluster.Authenticate();
Infobases = Cluster.GetInformationalBases();
For each InfoBase From InfoBase Cycle
Inform(InfoBase.Name + ", " + InfoBase.Description);
EndDo;
EndDo;

5.3.2. External session

management
5.3.2.1. General information
NOTE. Available only for CORP licenses.
For external session management, you need to implement a web service that
will provide a specific set of methods and control logic. This web service
can be implemented through 1C: Enterprise functionality or third-party
tools.
This chapter contains a description of the web service and an example of
implementation using 1C: Enterprise functionality.

5.3.2.2. Web service description

The web service name is not specified. The default timeout for method exe-
cution is 5 seconds. To change the default timeout value, use the tout pa-
rameter when calling the web service.

5.3.2.2.1. Version 1
onStartSession
Description:
The method is called by the server cluster on session start (except for back-
ground job sessions and WS connection sessions). The method determines
whether a new session with the specified parameters can be created. The
return code is passed to the server cluster.
Parameters:
CallNo input
Type: Number. Sequence number of the call. Each time the cluster calls the
web service, the sequence number of the call is incremented by 1. Based on
the CallNo value, the web service may request synchronization of session
data.
The call number is unique per infobase.
ClusterID input
Type: String. Server cluster ID. Contains a string presentation of the
unique identifier (UUID).
ClusterName input
Type: String. Name of the server cluster where the infobase is located.
InfobaseName input
Type: String. Name of the infobase used by the session.
SessionID input
Type: String. Session ID. Contains a string presentation of the unique
identifier (UUID).
UserID input
Type: String. User ID. Contains a string presentation of the unique iden-
tifier (UUID).
UserName input
Type: String. User name.
AppID input
Type: String. Name of the application attempting to access the infobase.
For detailed information on the values of this parameter, see description of
the global context function ApplicationPresentation().
Zone input
Type: String. Contains the initial separator values for the session being
created. The string is passed in the format specified for the /Z startup
command line parameter.
LanguageCode input
Type: String. The message language code for the session being created.
ErrorDescription output
Type: String. It contains a description of the reason for prohibiting ses-
sion creation in a human-readable format. Filled in when the web service
method returns 1.
Returns:
Type: Number. Return values:
• 0 - session can be created.
• 1 - session can't be created. The user that attempts to create the session
is presented with an error message containing the exception text from
the ErrorDescription parameter, or text string Starting session
is prohibited by the external session management service if the
value of the ErrorDescription parameter is empty.
• 2 - synchronizing is required. In this case, the server cluster calls the
synchronize method with a list of sessions not including this ses-
sion, and then calls the onStartSession method again. External
session management calls are not synchronized; the external session
management service determines whether synchronization of the ses-
sion list is required. Sequence number of the call (CallNo parameter)
can be used for this purpose. Skipping some call numbers after
timeout may be considered a condition requiring synchronization.

onFinishSession
Description:
The method is called at the end of the session.
Parameters:
CallNo input
Type: Number. Sequence number of the call.
The call number is unique per infobase.
ClusterID input
Type: String. Server cluster ID. Contains a string presentation of the
unique identifier (UUID).
SessionID input
Type: String. Session ID. Contains a string presentation of the unique
identifier (UUID).
Returns:
None.
synchronize
Description:
It is intended to synchronize data on created sessions between a server clus-
ter and a web service that implements an external session management
mechanism. The server cluster calls this method if onStartSession()
returns 2.
Parameters:
CallNo input
Type: Number. Sequence number of the call.
The call number is unique per infobase.
ClusterID input
Type: String. Server cluster ID. Contains a string presentation of the
unique identifier (UUID).
ClusterName input
Type: String. Name of the server cluster where the infobase is located.
InfobaseName input
Type: String. Name of the infobase for which you are synchronizing in-
formation about the number of sessions.
CurrentSessions input
Type: Sessions. The object contains data about all sessions created for a
specific infobase using the external session management mechanism. The
object contains the Content property, which is a collection of Session
objects that describe a single session each. The collection may be empty.
Returns:
None.

5.3.2.2.2. Version 2
Besides the functionality provided by version 1, version 2 includes two
methods that allow you to take actions when a session enters or leaves Hi-
bernating state.
onHibernateSession
Description:
The method is called by the server cluster when a session hibernates. When
a session enters hibernating state, its license is revoked and becomes availa-
ble, which must be reflected in the web service data. At the beginning of the
session that enters Hibernating state, the server cluster called the
onStartSession method of this web service.
Parameters:
CallNo input
Type: Number. Sequence number of the call.
The call number is unique per infobase.
ClusterID input
Type: String. Server cluster ID. Contains a string presentation of the
unique identifier (UUID).
SessionID input
Type: String. Session ID. Contains a string presentation of the unique
identifier (UUID).
Returns:
None.

onWakeupSession
Description:
Parameters:
CallNo input
Type: Number. Sequence number of the call. Each time the cluster calls the
web service, the sequence number of the call is incremented by 1. Based on
the CallNo value, the web service may request synchronization of session
data.
The call number is unique per infobase.
ClusterID input
Type: String. Server cluster ID. Contains a string presentation of the
unique identifier (UUID).
 SessionID input
Type: String. Session ID. Contains a string presentation of the unique
identifier (UUID).
ErrorDescription output
Type: String. It contains a description of the reason for prohibiting ses-
sion wakeup in a human-readable format. Filled in when the web service
method returns 1.
Returns:
Type: Number. Return values:
• 0 - session can be transferred to working mode.
• 1 - session can't be transferred to working mode. The user whose ses-
sion attempts to wake up is presented with an error message contain-
ing the exception text from the ErrorDescription parameter, or
text string Session wakeup is prohibited by the external session
management service if the value of the ErrorDescription pa-
rameter is empty.
• 2 - synchronizing is required. In this case, the server cluster calls the
synchronize method with a list of sessions not including this ses-
sion, and then calls the onWakeupSession method again. External
session management calls are not synchronized; the external session
management service determines whether synchronization of the ses-
sion list is required. Sequence number of the call (CallNo parameter)
can be used for this purpose. Skipping some call numbers after
timeout may be considered a condition requiring synchronization.

5.3.2.2.3. Sessions type description

Description of the Sessions object (in XSD format):
<xs:schema xmlns:ns1="http://v8.1c.ru/8.1/data/core"
xmlns:tns="http://v8.1c.ru/SessionManagement"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://v8.1c.ru/SessionManagement"
attributeFormDefault="unqualified" elementFormDefault="qualified">
<xs:import namespace="http://v8.1c.ru/8.1/data/core"/>
<xs:complexType name="Session">
<xs:sequence>
<xs:element name="SessionID" type="xs:string"/>
<xs:element name="UserID" type="xs:string"/>
<xs:element name="UserName" type="xs:string"/>
<xs:element name="AppID" type="xs:string"/>
<xs:element name="Zone" type="xs:string"/>
<xs:element name="LanguageCode" type="xs:string"/>
<xs:element name="Hibernate" type="xs:boolean"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="Sessions">
<xs:sequence>
<xs:element name="Content" type="tns:Session" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>

5.3.2.3. Implementation example

Let us review an example of an external session management web service.
NOTE. The example given in this section is not complete. It is intended for
the general functionality demonstration.
This example will implement the following algorithm:
• The administrator can restrict the number of concurrent sessions for an
infobase. To do this, the infobase name and the maximum number of
concurrent sessions are specified.
• If the infobase is not in the list- the amount of sessions with it is lim-
ited.
• You can see the list of sessions for each infobase in the list.
A simple configuration including one catalog and one web service is used as
a web service. The catalog contains a list of infobases, the limit on the num-
ber of sessions, and the sequence number of the last call. The web service
performs session registration activities.
The catalog is organized as follows:
• Name: AvailableSessions.
• Code length: 0.
• Name length: 50.
• Attributes:
  Name: Quantity, Number (2), non-negative.
 Name: LastCallNumber,Number (10), non-negative.
• Tabular section:
 Name: CurrentSessions.
 Attributes:
 Name: SessionID, String (40) of variable length.
 Name: UserID, String of unlimited length.
 Name: UserName, String of unlimited length.
 Name: AppID, String of unlimited length.
 Name: Zone, String of unlimited length.
 Name: LanguageCode, String of unlimited length.
 Name: Hibernate, Boolean.
This catalog will store the infobase name (standard attribute Name), the
maximum number of concurrent sessions for this infobase (attribute
Quantity), and the sequence number of the last web service call (attribute
LastCallNumber). LastCallNumber is used to determine whether
data synchronization between the 1C:Enterprise server cluster and the web
service is required. The tabular section stores information on the sessions
that the web service allowed to start. The session record is created in the
onStartSession () method, and deleted in the
onFinishSession() method. By comparing the maximum number of
sessions allowed for this infobase and the number of remembered sessions,
you can determine whether a session can be created. If the second version of
the interface is used, session hibernations and wakeups are also recorded.
When you hibernate a session, the session record is not deleted but is
marked accordingly.
You also need to create the web service described above and add the fol-
lowing code in the web service module. The web service must contain a link
to the XDTO package http://v8.1c.ru/SessionManagement describing
the Sessions object.
Text of the web service operations:
Function onStartSession(CallNo, ClusterID, ClusterName,
InfoBaseName, SessionID, UserID, UserName, AppID, Zone,
LanguageCode, ErrorDescription)
ErrorDescription = "";
Result = Catalogs.AvailableSessions.FindByName(InfoBaseName,
True);
If Result.Empty() Then
// If infobase with this name is not listed in the catalog, the
infobase has no restrictions
Return 0;
EndIf;

Object = Result.GetObject();
Object.LastCallNumber = Object.LastCallNumber + 1;

// If the call sequence is broken, synchronization will be

required
If Object.LastCallNumber <> CallNo Then
Return 2;
EndIf;

Sessions = Result.CurrentSessions.FindRows(New
Structure("Hibernate", False));
If Sessions.Quantity()+1 > Result.Quantity Then
// Maximum number of sessions reached, cannot create any more
sessions
Object.Write();
ErrorDescription = "Exceeded the maximum number of sessions
allowed by the external session management service";
Return 1;
Else
// Can create sessions
String = Object.CurrentSessions.Add();
String.SessionID = SessionID;
String.UserID = UserID;
String.UserName = UserName;
String.AppID = AppID;
String.Zone = Zone;
String.LanguageCode = LanguageCode;
String.Hibernate = False;
Object.Write();
Return 0;
EndIf;
EndFunction

Function onFinishSession(CallNo, ClusterID, SessionID)

Query = New Query;
Query.Text =
"SELECT
| AvailableSessions.Ref
|FROM
 | Catalog.AvailableSessions AS AvailableSessions
| WHERE
| AvailableSessions.CurrentSessions.SessionID = &SessionID";

Query.SetParameter("SessionID", SessionID);
QueryResult = Query.Execute();
SelectionDetailedRecords = QueryResult.Select();
While SelectionDetailedRecords.Next() Do
// Deleting the session from the service database
Object = SelectionDetailedRecords.Ref.GetObject();
Result = Object.CurrentSessions.FindRows(New
Structure("SessionID", SessionID));
For Each Row In Result Do

Object.CurrentSessions.Delete(Object.CurrentSessions.Index(Row));
EndDo;
Object.LastCallNumber = CallNo;
Object.Write();
EndDo;
Return Undefined;
EndFunction

Function Synchronize(CallNo, ClusterID, ClusterName, InfoBaseName,

CurrentSessions)
Result = Catalogs.AvailableSessions.FindByName(InfoBaseName,
True);
If Result.Empty() Then
// If infobase with this name is not listed in the catalog, the
infobase has no restrictions
Return Undefined;
EndIf;
// Can create sessions
Object = Result.GetObject();
Object.CurrentSessions.Clear();
For Each Session In CurrentSessions.Content Do
String = Object.CurrentSessions.Add();
String.SessionID = Session.SessionID;
String.UserID = Session.UserID;
String.UserName = Session.UserName;
String.AppID = Session.AppID;
String.Zone = Session.Zone;
String.LanguageCode = Session.LanguageCode;
EndDo;
Object.LastCallNumber = CallNo;
Object.Write();
Return Undefined;
EndFunction

Function onHibernateSession(CallNo, ClusterID, SessionID)

Query = New Query;
Query.Text =
"SELECT
| AvailableSessions.Ref
 |FROM
| Catalog.AvailableSessions AS AvailableSessions
| WHERE
| AvailableSessions.CurrentSessions.SessionID = &SessionID";

Query.SetParameter("SessionID", SessionID);
QueryResult = Query.Execute();
SelectionDetailedRecords = QueryResult.Select();
While SelectionDetailedRecords.Next() Do
// Marking the session as hibernating in the service database
Object = SelectionDetailedRecords.Ref.GetObject();
Result = Object.CurrentSessions.FindRows(New
Structure("SessionID", SessionID));
For Each Row In Result Do
Row.Hibernate = True;
EndDo;
Object.LastCallNumber = CallNo;
Object.Write();
EndDo;
Return Undefined;
EndFunction

Function onWakeupSession(CallNo, ClusterID, SessionID,

ErrorDescription)
Query = New Query;
Query.Text =
"SELECT
| AvailableSessions.Ref
|FROM
| Catalog.AvailableSessions AS AvailableSessions
| WHERE
| AvailableSessions.CurrentSessions.SessionID = &SessionID";

Query.SetParameter("SessionID", SessionID);
QueryResult = Query.Execute();
If QueryResult.Empty () Then
ErrorDescription = "Cannot wake up the session. Start of the
session # "+ SessionID +" was not registered";
Return 1;
EndIf;
SelectionDetailedRecords = QueryResult.Select();
While SelectionDetailedRecords.Next() Do
// If the call sequence is broken, synchronization will be
required
If SelectionDetailedRecords.Ref.LastCallNumber + 1 <> CallNo
Then
Return 2;
EndIf;
// Marking the session as hibernating in the service database
Object = SelectionDetailedRecords.Ref.GetObject();
// Getting the number of non-hibernating sessions
NotHibernating = Object.CurrentSessions.FindRows(New
Structure("Hibernate", Truth)). Number ();
 // Starting wakeup
Result = Object.CurrentSessions.FindRows(New
Structure("SessionID", SessionID));
For Each Row In Result Do
If NotHybernating > Object.Quantity Then
ErrorDescription = "Cannot wake up the session. Exceeded the
maximum number of sessions allowed by the external session
management service";
Return 1;
EndIf;
NotHibernating = NotHibernating + 1;
String.Hibernate = False;
EndDo;
Object.LastCallNumber = CallNo;
Object.Write();
EndDo;
Return 0;
EndFunction

After creating the configuration, publish the web service on the web server.
Let us assume that the publication is called sc, the web service is called
SessionControl, the namespace of this web service is called
http://v8.1c.ru/SessionManagement, and the XDTO package must in-
clude the http://v8.1c.ru/SessionManagement package. The publication
is performed on the localhost computer.
After publishing and verifying the web service publication, you need to cre-
ate a string pointing the server cluster to the created web service.
The string will look like:
wsdl=http://localhost/sc/ws/SessionControl?wsdl;ns=http://v8.1c.ru/
SessionManagement;srvc=SessionControl;port=SessionControlSoap;

You also need to create a client/server infobase whose sessions will be

managed by the web service. Let us call this infobase TestDB. Any infobase
(including empty) can be used. After creating the infobase, use the cluster
console to specify the string generated above (wsdl = ...) as the value of
the External session management property, and select the check box for
the Mandatory use of external control property.
Then, run the session management infobase in 1C:Enterprise mode and
create one element in the director Available sessions where one
standard requisite Title should accept the valueTestDB, and the unit
Quantity - the 2 value. This sets a maximum limit of 2 concurrent ses-
sions for TestDB.
Now, only two users can access TestDB at the same time.
5.3.3. Server cluster
administration server
5.3.3.1. General information
To administer a server cluster, you can use a cluster administration server. It
includes the server (ras) and the command line utility (rac) used for server
cluster management.

Fig. 76. Administration server

The server cluster and the administration server (ras) must have the same
version. When using the command line utility (rac), the following limita-
tions should be considered:
• The command line utility (rac) version 8.3.1 or 8.3.2 can only be used
with the administration server (ras) version 8.3.1 or 8.3.2.
• The command line utility (rac) version 8.3.3 or 8.3.4 can only be used
with the administration server (ras) version 8.3.3 or 8.3.4.
• The command line utility (rac) version 8.3.5 through 8.3.8 can only be
used with the administration server (ras) version 8.3.5 through 8.3.8.
 • The command line utility (rac) version 8.3.9 and later can only be
used with the administration server (ras) version 8.3.9 and later.
When using the command line utility of earlier version than the ver-
sion of the administration server, only the functionality implemented
in the platform corresponding to the command line utility version is
available. If you need a specific feature, make sure to use the com-
mand line utility of version in which the feature is implemented (sub-
ject to the above limitations).
Both the administration server and the command line utility can work in any
supported OS. Multiple administration servers can be connected to the serv-
er cluster at the same time. An administration server can be connected to
one server agent only.
An administration server (ras) can run as an application, as a Windows ser-
vice, or as a Linux daemon. The general procedure is as follows:
• The administration server is started (as an application, or as a ser-
vice/daemon).
• The command line utility connects to the administration server to per-
form the necessary actions.
• For the duration of the operations, the administration server connects
to the server cluster and, after performing the operations-disconnects
from the cluster. Therefore, there is no need to shut down the admin-
istration server during scheduled operations on a cluster of servers as-
sociated with cluster shutdown or restart. Changing the server cluster
version is an exception. In this case, you need to set administration
server version identical to the server cluster version.
The administration server and the administration utility are installed togeth-
er with the 1C:Enterprise server.
For interaction between the administration server and the administration
utility, network port 1545 is used. This can be redefined using the --port
parameter of the administration server startup command line (ras).
The administration utility allows you to perform all operations required to
administer a cluster of servers. However, the following features are not sup-
ported:
• OS authentication for server cluster administrators, working server
administrators, and infobase administrators.
The administration utility (rac) gets all necessary parameters from the
command line and sends information to the standard output stream
(stdout). If successful, the return code of the utility is equal to 0. Other-
wise, the return code is non-zero and an error message is sent to the stand-
ard error stream (stderr).
 The result of the utility operation is a description of one or several data ob-
jects (for example, a list of infobase servers registered in a cluster) in the
form of a table:
<Parameter name> : <Parameter value>
Where each parameter is displayed on a new line and contains an empty line
indicating the end of the object description. <Parameter name> match-
es the names of the utility command line parameters. If the parameter can-
not be set from the command line (or it is read-only), then the parameter
name is converted from the property name of the corresponding COM ob-
ject. Conversion is performed according to the following rule: All words
and abbreviations in the name of a property are converted to lowercase and
separated by "-". For example, theMemoryExcessTime working process
property will be converted to memory-excess-time.
Cluster item creation commands (with the exception of administrators),
send the ID of the created item to the stream in the above format when suc-
cessful.
Strings that allow arbitrary characters are put in double quotes, with double
quotes in the strings themselves being duplicated.
Dates are in XML format (https://www.w3.org/TR/2012/REC-
xmlschema11-2-20120405/#dateTime).
For more information about parameters of the administration server (ras) or
the administration utility (rac), run the corresponding executable file with
the help command-line parameter:
ras help
rac help

The ITS disk also comes with a package of Java archives, which allows you
to interact with the administration server from a Java-language program
without the help of a console administration utility (https://1c-
dn.com/library/1c_enterprise_8_administrative_service_api/).http://its.1c.ru/
db/metod8dev - content:4985:hdoc

5.3.3.2. Starting the administration server

5.3.3.2.1. On Windows
In application mode
To start the administration server in application mode, use the following
command line:
ras cluster --port=<port> <host[:port]>

The command can have the following keys:

cluster
Starts the administration server in server cluster administration mode.
--port or -p
Specifies the network port on which the administration utility will com-
municate with the administration server. The default value is 1545.
<host[:port]>
Specifies the address of the service agent of the server cluster administrated
by the administration server.
If the address of the cluster agent is not explicitly specified, the default val-
ue is localhost:1540.

In service mode
To start the administration server in service mode, you need to register the
administration server as a service. This operation can be performed using
the sc utility. Administrator rights are required to complete the registration.
Let us review an example of the batch file that performs the registration of
the server service.
Register-ras.bat:
@echo off
rem %1 – 1C:Enterprise full version

set SrvUserName=<user name>

set SrvUserPwd=<user password>
set CtrlPort=1540
set AgentName=localhost
set RASPort=1545

set SrvcName="1C:Enterprise 8.3 Remote Server"

set BinPath="\"C:\Program Files\1cv8\%1\bin\ras.exe\" cluster --
service --port=%RASPort% %AgentName%:%CtrlPort%"
set Description="1C:Enterprise 8.3 Administration Server"

sc stop %SrvcName%
sc delete %SrvcName%
sc create %SrvcName% binPath= %BinPath% start= auto obj=
%SrvUserName% password= %SrvUserPwd% displayname= %Desctiption%

Before using this batch file, you need to edit it with user name and pass-
word of the user on whose behalf the administration server service will run
(set SrvUserName = and set SrvUserPwd = lines). This batch file per-
 forms registration of the administration server with the following parame-
ters:
• Service Name: 1C:Enterprise 8.3 Remote Server
• Displayed Name: 1C: Enterprise 8.3 administration server
• Administration server port: 1545
• Address of the 1C:Enterprise server cluster: localhost:1540
• Service start mode: Auto.
Example:
register-ras 8.3.3.100

5.3.3.2.2. On Linux
In application mode
To start the administration server in application mode, use the following
command line:
./ras cluster --port=<port> <host[:port]>

The command can have the following keys:

cluster
Starts the administration server in server cluster administration mode.
--port or -p
Specifies the network port on which the administration utility will com-
municate with the administration server. The default value is 1545.
<host[:port]>
Specifies the address of the service agent of the server cluster administrated
by the administration server.
If the address of the cluster agent is not explicitly specified, the default val-
ue is localhost:1540.

In daemon mode
To start the administration server (ras) in daemon mode, you need to start
the administration server using a special command-line key:
./ras cluster --daemon --port=<port> <host[:port]>

The command line keys for starting the administration server (ras) on Win-
dows and Linux are identical.
5.4. Database administration
In 1C:Enterprise applications, you can perform actions that do not affect the
operability of the application or presentation of the data structures used by
1C:Enterprise (including infobase restructuring and saving the changes
made after the restructuring):
1. Using encryption at the database level
 Available for database:
 Microsoft SQL Server 2008 or later
 Oracle Database
 Mechanism documentation:
 Microsoft SQL Server 2008: http://msdn.Microsoft.com/en-
US/library/bb510663(v=sql.100).aspxhttp://msdn.microsoft
.com/ru-ru/library/bb510663(v=sql.100).aspx
 Microsoft SQL Server 2008 R2:
http://msdn.Microsoft.com/en-
US/library/bb510663(v=sql.105).aspxhttp://msdn.microsoft
.com/ru-ru/library/bb510663(v=sql.105).aspx
 Microsoft SQL Server 2012: http://msdn.Microsoft.com/en-
US/library/bb510663(v=sql.110).aspxhttp://msdn.microsoft
.com/ru-ru/library/bb510663(v=sql.110).aspx
 Microsoft SQL Server 2014: http://msdn.Microsoft.com/en-
US/library/bb510663(v=sql.120).aspxhttp://msdn.microsoft
.com/ru-ru/library/bb510663(v=sql.120).aspx
 Microsoft SQL Server 2016: http://msdn.microsoft.com/en-
US/library/bb510663(v=sql.130).aspxhttp://msdn.microsoft
.com/ru-ru/library/bb510663(v=sql.130).aspx
 Oracle Database 10g R2:
http://docs.oracle.com/cd/B19306_01/network.102/b
14268/asotrans.htm
 Oracle Database 11g R1:
http://docs.oracle.com/cd/B28359_01/network.111/b
28530/asotrans.htm
 Oracle Database 11g R2:
http://docs.oracle.com/cd/E25178_01/network.1111/e
10746/asotrans.htm
 Oracle Database 12c R1:
http://docs.oracle.com/database/121/ASOAG/GUID-
F2F6CF9A-8F59-49AE-B378-556DCDACC856.htm;
2. Using server clusters -groups of computers united by high-speed
communication channels and representing a single hardware resource
from the user's point of view.
 Available for database:
 IBM DB2
 Microsoft SQL Server
 Oracle Database
 PostgreSQL
 Mechanism documentation:
 IBM DB2 v9.1:
http://publib.boulder.ibm.com/infocenter/db2luw/v9/topi
c/com.ibm.db2.udb.admin.doc/doc/c0006354.htm;
 IBM DB2 v9.5:
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/to
pic/com.ibm.db2.luw.admin.ha.doc/doc/t0051382.html;
 IBM DB2 v9.7:
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/to
pic/com.ibm.db2.luw.admin.ha.doc/doc/t0051382.html;
 IBM DB2 v10.1:
http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/t
opic/com.ibm.db2.luw.admin.ha.doc/doc/t0051382.html;
 IBM DB2 v11.1:
http://www.ibm.com/support/knowledgecenter/SSEPGG_
11.1.0/com.ibm.db2.luw.admin.ha.doc/doc/t0051382.htm
l;
 Microsoft SQL Server 2000: http://msdn.Microsoft.com/en-
US/library/aa196694(v=sql.80).aspxhttp://msdn.microsoft.com
/ru-ru/library/aa196694(v=sql.80).aspx
 Microsoft SQL Server 2005: http://msdn.Microsoft.com/en-
US/library/ms189134(v=sql.90).aspxhttp://msdn.microsoft.co
m/ru-ru/library/ms189134(v=sql.90).aspx
 Microsoft SQL Server 2008: http://msdn.Microsoft.com/en-
US/library/ms189134(v=sql.100).aspxhttp://msdn.microsoft.co
m/ru-ru/library/ms189134(v=sql.100).aspx
 Microsoft SQL Server 2008 R2:
http://msdn.Microsoft.com/en-
US/library/ms189134(v=sql.105).aspxhttp://msdn.microsoft.
com/ru-ru/library/ms189134(v=sql.105).aspx
 Microsoft SQL Server 2012: http://msdn.Microsoft.com/en-
US/library/ms189134(v=sql.110).aspxhttp://msdn.microsoft.co
m/ru-ru/library/ms189134(v=sql.110).aspx
 Microsoft SQL Server 2014: http://msdn.Microsoft.com/en-
US/library/ms189134(v=sql.120).aspxhttp://msdn.microsoft.co
m/ru-ru/library/ms189134(v=sql.120).aspx
 Microsoft SQL Server 2016: http://msdn.microsoft.com/en-
US/library/ms189134(v=sql.130).aspxhttp://msdn.microsoft.co
m/ru-ru/library/ms189134(v=sql.130).aspx
 Oracle Database 10g R2:
http://docs.oracle.com/cd/B19306_01/server.102/b14210
/hafeatures.htm#CJACEEIA ;
 Oracle Database 11g R1:
http://docs.oracle.com/cd/B28359_01/server.111/b28281
/architectures.htm;
 Oracle Database 11g R2:
http://docs.oracle.com/cd/E15586_01/server.1111/e1715
7/architectures.htm ;
 Oracle Database 12c R1:
http://docs.oracle.com/database/121/HAOVW/toc.htm.
 PostgreSQL 8.2:
http://www.postgresql.org/docs/8.2/interactive/high-
availability.html ;
 PostgreSQL 8.3:
http://www.postgresql.org/docs/8.3/interactive/high-
availability.html;
 PostgreSQL 8.4:
http://www.postgresql.org/docs/8.4/interactive/high-
availability.html;
 PostgreSQL 9.0:
http://www.postgresql.org/docs/9.0/interactive/high-
availability.html;
 PostgreSQL 9.1:
http://www.postgresql.org/docs/9.1/interactive/high-
availability.html;
 PostgreSQL 9.2:
http://www.postgresql.org/docs/9.2/interactive/high-
availability.html.
 PostgreSQL 9.3:
http://www.postgresql.org/docs/9.3/interactive/high-
availability.html.
 PostgreSQL 9.4:
https://postgrespro.com/docs/postgresql/9.4/high-
 availability.html.https://postgrespro.ru/docs/postgresql/9.4/high
-availability.html
 PostgreSQL 9.6:
https://postgrespro.com/docs/postgresql/9.6/high-
availability.html.https://postgrespro.ru/docs/postgresql/9.6/high
-availability.html
 PostgreSQL 10:
https://postgrespro.com/docs/postgresql/10/high-
availability.html.https://postgrespro.ru/docs/postgresql/10/high
-availability.html
 Postgres Pro Standard 9.6:
https://postgrespro.ru/docs/postgrespro/10/high-
availability.html.
 Postgres Pro Enterprise 9.6:
https://postgrespro.ru/docs/postgresproee/9.6/high-
availability.html.
 Postgres Pro Enterprise 10:
https://postgrespro.ru/docs/postgresproee/10/high-
availability.html.
3. Using data compression at database level
 Available for database:
 Oracle Database (only through compressed tablespace)
 Mechanism documentation:
 Oracle Database 11g R2:
http://docs.oracle.com/cd/E11882_01/server.112/e25494
/tables.htm#CJAGFBFG.
 Oracle Database 12c R1:
http://docs.oracle.com/database/121/ADMIN/tables.htm
#ADMIN13948.
4. Changing location of predefined tablespaces
 Available for database:
 IBM DB2
 Oracle Database
 PostgreSQL
 Predefined tablespaces:
 IBM DB2:
 for indexes - V81C_INDEXSPACE;
 for data - V81C_LARGESPACE;
 for LOB - V81C_LOBSPACE;
 user temporary table space - V81C_USERTEMP;
 system temporary table space - V81C_SYSTEMPBP.
  Oracle Database:
 for indexes -V81C_INDEX;
 for data -V81C_DATA;
 for -LOB V81C_LOB;
 temporary table space - V81C_TEMP.
 PostgreSQL:
 for indexes -V81C_INDEX;
 for data -V81C_DATA;
 temporary table space - free title set via configuration file
postgresql.conf.
5. Changing location of the database file
 Available for database:
 Microsoft SQL Server
6. Changing location of transaction log
 Available for database:
 IBM DB2
 Microsoft SQL Server
 Oracle Database
 PostgreSQL
7. Performing administrative tasks that do not alter database structures
but ensure adequate performance
 Tasks:
 Integrity check
 Reindexing
 Defragmentation
 Reorganization
 Backup creation
 Cleaning procedure cache
 Collecting statistics data
 Available for database:
 IBM DB2
 Microsoft SQL Server
 Oracle Database
 PostgreSQL
 Chapter 6.
Deleting the application

6.1. Deleting a cluster of

servers under Windows
The 1C:Enterprise server is deleted by a special utility that removes system
components from the hard disk of a computer, makes changes to the Start
menu and Windows system information.
It is necessary to shut down the 1C:Enterprise server before deleting it.
To delete the 1C:Enterprise, follow these steps:
1. Open Windows control panel and click the Add or Remove Pro-
grams (Programs and features for Windows Vista and later) icon.
2. If necessary, click the Replace or delete icon in the dialog box that is
displayed.
3. In the list of installed programs, select 1C Enterprise 8.3
(8.3.X.YYY) and click Delete.
You will be asked if you want to perform the uninstallation. If you confirm,
Windows will start removing the selected 1C:Enterprise version from the
computer and making the necessary changes to the system information.

6.2. Uninstalling a server

cluster for Linux
To remove the 1C: Enterprise server from a computer, use the package
manager software of the operating system in use. This section provides an
example of using the RPM package manager.
IMPORTANT! Like installation, removal is performed under root.
Before deleting, you need to shut down the server cluster using the com-
mand:
/etc/init.d/srv1cv83 stop

To delete, execute the following command:

rpm -e <rpm_package_name>

<Package_name_rpm> in this case - means the name of installed rpm-

package of "1C:Enterprise". The name of the installed RPM package corre-
sponds to the name of the package file, without the “.i386.rpm” suffix, for
example, 1C_Enterprise83-common-8.3.3-100 Thus, to remove the
1C_Enterprise83-common-8.3.3-100.i386.rpm package, enter the com-
mand:
rpm -e 1C_Enterprise83-common-8.3.3-100

RPM packages must be deleted in the reverse order of installation so that

the dependent packages are deleted before the packages they depend on. In
1C:Enterprise terms, this means that the RPM package 1C_Enterprise83-
common must be deleted last.
You can also delete RPM packages using the command:
rpm -e`rpm -qa|grep 1C_`

This command deletes all installed packages that begin with the prefix
“1C_”. Dependencies will be tracked automatically.
Similar commands are available for other package managers.
 Appendix 1.
License description
string format

Full or brief version of the license information can be displayed. Brief li-
cense information is used to display working processes or sessions in a col-
umn. Full license information is displayed in the working process properties
window or session properties window.
License information has the following format:
Received by, PID, Server, Port, License description, License file
name

Depending on the license type (HASP or software one), brief and complete
information about license - the specific set of fields will be present.
Received by
Indicates the license owner:
• Client - license had been obtained by client application.
• Server - the license had been obtained by "1C:Enterprise" server.
PID
Identifier of the OS process that obtained the client license.
Not used in brief license presentation.
Server
Name of the 1C:Enterprise server that obtained the client license.
Not used in brief license presentation.
Not used if the license is obtained by the client application.
Port
Network port number of the server process (rphost or rmngr) that obtained
the license.
Not used in brief license presentation.
Not used if the license is obtained by the client application.
License description
Contains a description of the license source.
If the license is obtained from the hardware protection key, the license de-
scription is as follows:
<Key series> <Key type> <Number of licenses>

Where:
• Key series - series of hardware security key.
• Type of key - specifies software key type:
 Local - key is connected to the PC, which performed license ob-
taining.
 Network - key is available via network by means of
HASP License Manager.
• Amount of licenses - maximum amount of licenses, available in this
key.
If the client license is obtained through the software licensing system, the
license description is as follows:
<Package Number> <License Type> <Number of Licenses>

Where:
• Number of set - registration number of set with software license.
• License type - specifies activated license type. For combination
packages, this can be 1 or a value equal to the Number of licenses.
For single-user, multi-user, or server licenses, the value is always 1.
• Amount of licenses - maximum amount of licences, available in the
aforementioned set of licenses.
License file name
Full name of the software license file whose license was obtained by the
working process or session.
Not used in brief license presentation.
Not used for licenses obtained from a hardware protection key.
Examples of client license presentation strings:
Customer, 4648, ORGL8 Local 1

The license is obtained by a client application that has an OS process ID of

4648. The license is obtained from the local hardware protection key.
Client, 3840, ORG8A Network 300

The license is obtained by a client application that has an OS process ID of

3840. The license is obtained from the hardware protection key available
on the network.
Server, 1648, SERVER-1C, 1560, ORG8B Network 500

The client license is obtained through the server SERVER-1C, working

through port 1560. The process that obtained the license has an OS process
ID of 1648, and the license is obtained from a 500-user hardware protection
key available over the network.
Server, 1648, SERVER-1C, 1560, ORGL8 Local 1

The client license is obtained through the server SERVER-1C, working

through port 1560. The process that obtained the license has an OS process
ID of 1648, and the license is obtained from a local, single-user, hardware
protection key.
Server 1970, ENSR8 Local 1

The server license (for a 32-bit server) is obtained by a working process

with an OS process ID of 1970. The key is located on the computer running
the working process.
Server, 4524, SERVER-1C, 1560, 8000314159 1 1,
file://C:/Users/USR1CV8/AppData/Local/1C/1cv8/conf/20100521112156.l
ic

The server license is obtained by the server working process of the

SERVER-1C server operating on port 1560. The process that obtained the
license has an OS process ID of 4524. A software server license has been
obtained, with the package number 8000314159. The license file is
20100521112156.lic and is located in the
C:/Users/USR1CV8/AppData/Local/1C/1cv8/conf directory.
Server, 896, SERVER-1C, 1564, 8000453822 20 20, file://C:/Documents
and Settings/USR1CV8/Local Settings/Application
Data/1C/1cv8/conf/20110812100013.lic

The client license is obtained through the server SERVER-1C, working

through port 1564. The process that obtained the license has an OS process
ID of 896. The software license is obtained from a 20-user combo package,
which is activated as a multi-user license. Package number 8000453822.
The license file is 20110812100013.lic and is located in the
C:/Documents and Settings/USR1CV8/Local Settings/Application Da-
ta/1C/1cv8/conf directory.
Appendix 2. New and modified
sections

Deleted section:
• Article 1.6. Other requirements. See 1.3.Client/server mode common
requirements.
Added section:
• Section 2.2.5.4. Workflow backup.
• .
Modified section:
• Section 1.1. Server x32.
• Section 1.2.1. Requirements to servers designed for servers cluster op-
eration.
• Section 1.3. Client/server mode common requirements.
• Section 1.5. Supported DBMS.
• Section 2.2.7.3.1. General information.
• Section 2.2.8.8. Privileged mode.
• Section 5.1.1. Backup in Client/Server Mode.
• Section 5.2.6.1. Adding a working server to cluster.
• Section 5.2.7.2. Viewing infobase properties.
• Section 5.2.10. Viewing a list of working processes.
• Section 5.2.14.1. Adding profiles.
• .