1C:ENTERPRISE8.

3
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. Administrator guide.

Edition number: 83.003.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 15
Overview ......................................................................................................... 15
What you need to know ............................................................................... 16
Books included in the documentation......................................................... 16
Update and migration notes delivered with1C:Enterprise ..................... 17
Agreed notations ........................................................................................... 17

Chapter 1. System and hardware requirements........... 21

1.1. Thin client ............................................................................................ 21
1.2. Thick client .......................................................................................... 22
1.3. Web client............................................................................................ 23
1.4. Mobile client ........................................................................................ 24
1.5. Power-saving modes.......................................................................... 25
1.6. Supported web servers ...................................................................... 25
1.7. Other requirements ............................................................................ 26
1.7.1. On Windows .................................................................................... 26
1.7.2. On Linux........................................................................................... 27
1.8. Restrictions .......................................................................................... 28
1.9. Platform and licensing options ......................................................... 28
1.9.1. General information........................................................................ 28
1.9.2. Distribution package options ......................................................... 28
1.9.3. License types ................................................................................... 29
1.9.4. CORP license applicability .............................................................. 31

Chapter 2. Installing 1C:Enterprise ................................ 33

2.1. General information ........................................................................... 33
2.2. General information on installation procedure ............................... 33
2.3. Windows Installer ............................................................................... 34
2.3.1. Available installers .......................................................................... 34
2.3.2. About installer ................................................................................. 34
2.4. macOS Installer .................................................................................. 43
2.5. Typical 1C:Enterprise installation scenarios.................................... 44
2.5.1. On Windows .................................................................................... 44
2.5.2. On Linux........................................................................................... 48
2.5.3. On macOS........................................................................................ 51
2.6. Recommendations for system deployment ..................................... 51
2.7. Installing and configuring additional software ............................... 55
2.7.1. On Windows .................................................................................... 55
2.7.2. On Linux........................................................................................... 55
2.8. Recommendations for component registration .............................. 58
Chapter 3. Installing configurations ............................... 61
3.1. General information on template directories .................................. 61
3.2. Installing configuration templates .................................................... 62
3.3. Creating an infobase from template ................................................ 64

Chapter 4. Running system components ...................... 67

4.1. General information ............................................................................ 67
4.1.1. On Windows..................................................................................... 67
4.1.2. On macOS ........................................................................................ 69
4.2. Operating modes ................................................................................ 69
4.3. Starting a client application or Designer.......................................... 70
4.3.1. General information ........................................................................ 70
4.3.2. Launcher........................................................................................... 70
4.3.3. Interactive launcher ........................................................................ 72
4.3.4. Client for a specific 1C:Enterprise version ................................... 74
4.3.5. Determining application bitness .................................................... 75
4.3.6. Web client ........................................................................................ 76
4.3.7. Special startup parameters ............................................................ 79
4.3.8. Infobase connection methods ....................................................... 82
4.3.9. Selecting an infobase ..................................................................... 83
4.3.10. Client/server version mismatch ..................................................... 84
4.3.11. FIle mode version mismatch ......................................................... 85
4.3.12. User authentication ......................................................................... 86
4.3.13. Using certificates ............................................................................. 86
4.4. Restarting 1C:Enterprise .................................................................... 89

Chapter 5. Maintaining the infobase list........................ 91

5.1. General information ............................................................................ 91
5.2. Adding infobases................................................................................. 92
5.2.1. Adding a new infobase ................................................................... 92
5.2.2. Adding existing infobases ............................................................ 102
5.2.3. Infobase startup parameters ....................................................... 108
5.2.4. Certificate settings ........................................................................ 110
5.3. Editing infobases ............................................................................... 111
5.4. Deleting infobases from list ............................................................. 111
5.5. Order of infobases in the list ........................................................... 112
5.6. Maintaining the hierarchical infobase list ...................................... 112
5.6.1. Adding an infobase folder ............................................................ 112
5.6.2. Editing infobase folders ................................................................ 114
5.6.3. Deleting infobase folders ............................................................. 114
5.7. Startup window settings .................................................................. 115
5.8. Shared infobase lists ........................................................................ 117

Chapter 6. Infobase administration ............................. 119

6.1. General information .......................................................................... 119
6.2. Maintaining user list ......................................................................... 120
 6.2.1. General information...................................................................... 120
6.2.2. Adding new users ......................................................................... 120
6.2.3. Cloning users ................................................................................. 124
6.2.4. Setting password .......................................................................... 124
6.2.5. Deleting users ............................................................................... 124
6.2.6. Editing user properties ................................................................. 125
6.2.7. Applying filters .............................................................................. 125
6.2.8. Authentication types .................................................................... 126
6.2.9. Users and extensions ................................................................... 136
6.3. Active users list ................................................................................. 137
6.4. Session start lock.............................................................................. 138
6.4.1. Manually, for all ............................................................................ 138
6.4.2. By default, when password is under attack .............................. 139
6.5. Regional infobase settings .............................................................. 141
6.6. Infobase parameters ........................................................................ 144
6.7. Exporting infobases to file............................................................... 147
6.8. Importing infobases from file ......................................................... 148
6.9. Infobase backup ............................................................................... 149
6.9.1. Infobase file mode........................................................................ 149
6.9.2. Client/server mode of infobase ................................................... 149
6.9.3. Mobile devices ............................................................................... 149
6.10. Verifying and repairing an infobase ............................................... 150
6.10.1. General information...................................................................... 150
6.10.2. On a personal computer .............................................................. 151
6.10.3. On a mobile device ....................................................................... 152
6.11. Cancelling the distributed infobase master node
assignment ........................................................................................ 153
6.12. Deleting data areas or infobases.................................................... 153
6.13. Event log............................................................................................ 154
6.13.1. General information...................................................................... 154
6.13.2. Event log in .lgd format ............................................................... 154
6.13.3. Event log in .lgf format ................................................................ 155
6.13.4. Saving event log ........................................................................... 155
6.13.5. Viewing event log archive ........................................................... 155
6.13.6. Event log settings ......................................................................... 156
6.14. Technological log .............................................................................. 159
6.14.1. General information...................................................................... 159
6.14.2. Technological log configuration file............................................ 160
6.14.3. Default technological log ............................................................. 161
6.14.4. Technological log structure ......................................................... 162
6.14.5. Setting up memory dump generation ........................................ 163
6.14.6. Sample technology log files......................................................... 165
6.15. Referential integrity monitoring...................................................... 169
6.15.1. Basic concepts............................................................................... 169
6.15.2. Enabling referential integrity monitoring ................................... 170
6.15.3. Direct deletion of objects............................................................. 171
6.15.4. Setting and clearing deletion marks........................................... 171
6.15.5. Using objects marked for deletion ............................................. 172
6.16. Standard functions ........................................................................... 172
6.16.1. General information...................................................................... 172
 6.16.2. Active users list ............................................................................. 173
6.16.3. Event log ........................................................................................ 174
6.16.4. Delete marked objects ................................................................. 180
6.16.5. Find references to objects ........................................................... 182
6.16.6. Document posting ......................................................................... 183
6.16.7. Totals management ...................................................................... 186
6.16.8. Full-text search management ...................................................... 191
6.16.9. Configuration extensions management ..................................... 193
6.16.10. Collaboration system management .................................... 196
6.16.11. Database copy management............................................... 201
6.16.12. Data change history ............................................................. 205

Chapter 7. Standalone server ....................................... 209

7.1. General information .......................................................................... 209
7.2. Specifics and limitations ................................................................... 209
7.3. Mechanism usage ............................................................................. 210
7.3.1. System requirements .................................................................... 210
7.3.2. Setting ............................................................................................ 210
7.3.3. Start and management of a standalone server ........................ 210
7.3.4. Debugging using the standalone server .................................... 214
7.4. Examples of managing and starting the standalone
server ................................................................................................. 215
7.4.1. General information ...................................................................... 215
7.4.2. Create a configuration file using command line
parameters ..................................................................................... 216
7.4.3. Create a configuration file by the parameters of the
server infobase .............................................................................. 216
7.4.4. Create infobase from (* .cf) configuration file .......................... 217
7.4.5. Load configuration from (*.cf) file .............................................. 219
7.4.6. Create infobase from the export file (*.dt) ............................... 219
7.4.7. Import data from the export file (* .dt) to the
infobase .......................................................................................... 220
7.4.8. Starting the stand-alone server in debug mode ....................... 220
7.4.9. Request a DBMS user password over the standard
input stream .................................................................................. 222
7.4.10. Specify the location of the standalone server service
directories ...................................................................................... 222
7.4.11. Infobase publication ..................................................................... 223
7.4.12. Operations with separators.......................................................... 225
7.4.13. Export and import of configuration to files................................ 226

Chapter 8. Setting up web services for

1C:Enterprise .................................................................. 227
8.1. General information .......................................................................... 227
8.2. General requirements ....................................................................... 228
8.3. Publication types ............................................................................... 229
8.3.1. General publication procedure .................................................... 229
8.3.2. Publishing dialog box .................................................................... 231
8.3.3. Webinst utility ................................................................................ 240
8.4. Web client support settings ............................................................. 243
 8.4.1. General information...................................................................... 243
8.4.2. On Windows .................................................................................. 243
8.4.3. On Linux......................................................................................... 246
8.5. Web service support settings ......................................................... 248
8.5.1. General information...................................................................... 248
8.5.2. On Windows .................................................................................. 248
8.5.3. On Linux......................................................................................... 252
8.6. Standard OData interface support ................................................. 254
8.6.1. General information...................................................................... 254
8.6.2. On Windows .................................................................................. 254
8.6.3. On Linux......................................................................................... 258
8.7. HTTP services support settings ...................................................... 260
8.7.1. General information...................................................................... 260
8.7.2. On Windows .................................................................................. 260
8.7.3. On Linux......................................................................................... 263
8.8. OpenID authentication support settings ....................................... 266
8.8.1. Settings for OpenID ..................................................................... 266
8.8.2. Configuring an infobase to act as an OpenID provider ........... 266
8.8.3. Additional interface for use by external resources................... 267
8.8.4. Requirements for external OpenID providers ........................... 272
8.9. Safety while using Internet services .............................................. 273
8.9.1. Authentication ............................................................................... 273
8.9.2. Operations over a secure channel .............................................. 275
8.10. Configuring a web server ................................................................ 277
8.10.1. Internet Information Services ..................................................... 277
8.10.2. Apache ........................................................................................... 279
8.10.3. Reverse Proxy ............................................................................... 283

Chapter 9. Configuring web browsers to

operate in the web client .............................................. 285
9.1. General settings ................................................................................ 285
9.2. Mozilla Firefox ................................................................................... 285
9.2.1. Connection settings ...................................................................... 285
9.2.2. Automatic authentication............................................................. 286
9.3. Microsoft Internet Explorer ............................................................. 287
9.3.1. Connection settings ...................................................................... 287
9.3.2. Using add-ins, file system extensions, cryptography
extensions, and client application agent extensions ................ 287
9.4. Google Chrome ................................................................................. 288
9.5. Safari .................................................................................................. 288
9.6. Using the web client ........................................................................ 289

Chapter 10. Protection against unauthorized use:

specifics and configuration ........................................... 291
10.1. General information ......................................................................... 291
 10.2. HASP security system ..................................................................... 292
10.2.1. General information ...................................................................... 292
10.2.2. USB key marking ........................................................................... 293
10.2.3. Specifications ................................................................................. 294
10.2.4. Protection against unauthorized use .......................................... 294
10.2.5. Monitoring the client licenses ...................................................... 295
10.2.6. Obtaining a server license ........................................................... 300
10.2.7. Install protection driver ................................................................ 300
10.2.8. Installing HASP License Manager................................................ 302
10.2.9. Setting up the 1C:Enterprise application for operation
with the HASP License Manager ................................................. 311
10.3. Software Licensing System .............................................................. 312
10.3.1. General information ...................................................................... 312
10.3.2. License types ................................................................................. 316
10.3.3. Protection against unauthorized use .......................................... 318
10.3.4. Monitoring the client licenses ...................................................... 318
10.3.5. Activating and obtaining a server license .................................. 323
10.3.6. Software license activation .......................................................... 324
10.3.7. Location of software licenses files .............................................. 328
10.4. Determining if 1C:Enterprise can run ............................................ 330
10.4.1. When you start the client application......................................... 330
10.4.2. When you start the server ........................................................... 331
10.4.3. Actions when a license is not found ........................................... 331
10.5. Protection against misuse of applications ..................................... 332
10.5.1. General information ...................................................................... 332
10.5.2. Mechanism structure .................................................................... 333

Chapter 11. Application updates..................................... 335

11.1. Update ................................................................................................ 335
11.2. 1C:Enterprise application update by Microsoft Windows
users without administrator rights ................................................. 335

Chapter 12. Uninstalling................................................... 337

12.1. Deleting infobases ............................................................................ 337
12.2. Uninstalling the platform ................................................................. 337
12.2.1. On Windows................................................................................... 337
12.2.2. For macOS ..................................................................................... 337

Chapter 13. Mobile platform administration ................. 339

13.1. Starting and using the list of applications for iOS ........................ 339
13.1.1. Starting mobile application .......................................................... 339
13.1.2. Using the list of applications........................................................ 339
13.2. Starting and using the list of applications for Android
OS ....................................................................................................... 340
13.2.1. Starting mobile application .......................................................... 340
13.2.2. Using the list of applications........................................................ 341
 13.3. Preparing the infrastructure to perform the exchange ............... 342
13.4. Backup ............................................................................................... 342

Appendix 1. Structure of the installation directory

and assigning directories and files .............................. 345
1.1. On Windows ...................................................................................... 345
1.2. On Linux ............................................................................................ 347
1.3. On macOS ......................................................................................... 347
1.4. Directories and files functions ........................................................ 348
1.5. Configuration files: location and search ........................................ 352
1.5.1. General information...................................................................... 352
1.5.2. On Windows .................................................................................. 352
1.5.3. On Linux......................................................................................... 353
1.5.4. On macOS...................................................................................... 353

Appendix 2. Description of the event log items ............ 355

Appendix 3. Description and location of internal
files 359
3.1. *.1ccr ................................................................................................. 359
3.2. *.mft................................................................................................... 359
3.3. *.v8i ................................................................................................... 360
3.4. 1cescmn.cfg ...................................................................................... 369
3.5. 1cestart.cfg ....................................................................................... 369
3.6. 1CV8Clst.lst ....................................................................................... 375
3.7. 1cv8conn.pfl ...................................................................................... 375
3.8. 1cv8wsrv.lst ...................................................................................... 375
3.9. adminstall.cfg .................................................................................... 376
3.10. agentbasedir.json ............................................................................. 379
3.11. appsrvrs.lst ........................................................................................ 380
3.12. cfgrepo.conf ...................................................................................... 380
3.13. comcntrcfg.xml ................................................................................. 381
3.14. conf.cfg .............................................................................................. 382
3.15. ConfigDumpInfo.xml ........................................................................ 388
3.16. debugcfg.xml .................................................................................... 389
3.17. def.usr ................................................................................................ 389
3.18. default.vrd ......................................................................................... 389
3.18.1. General information...................................................................... 389
3.18.2. <point> (root element) ............................................................... 390
3.18.3. <ws>.............................................................................................. 394
3.18.4. <httpServices> ............................................................................. 397
3.18.5. <pool> ........................................................................................... 398
3.18.6. <debug> ....................................................................................... 399
3.18.7. <zones> ........................................................................................ 400
3.18.8. <openid> ....................................................................................... 403
3.18.9. <openidconnect> ......................................................................... 405
3.18.10. <exitURL> ............................................................................. 410
3.18.11. <standardOData> ................................................................ 410
 3.19. inetcfg.xml ......................................................................................... 411
3.20. location.cfg ........................................................................................ 413
3.21. logcfg.xml .......................................................................................... 414
3.21.1. General description ....................................................................... 414
3.21.2. Configuration file structure .......................................................... 415
3.21.3. Writing exception contexts .......................................................... 472
3.21.4. Writing information about mutual locks ..................................... 473
3.21.5. Writing information about circular references .......................... 474
3.22. logui.txt .............................................................................................. 476
3.23. nethasp.ini ......................................................................................... 479
3.23.1. General description ....................................................................... 479
3.23.2. [NH_COMMON] section ................................................................ 480
3.23.3. [NH_IPX] section........................................................................... 481
3.23.4. [NH_NETBIOS] section................................................................. 482
3.23.5. [NH_TCPIP] section ...................................................................... 482
3.24. nhsrv.ini ............................................................................................. 483
3.25. rescntsrv.lst ....................................................................................... 484
3.26. ring-commands.cfg ........................................................................... 484
3.27. srv1cv83 ............................................................................................. 485
3.28. swpuser.ini ......................................................................................... 486
3.29. testcfg.xml ......................................................................................... 489
3.30. Object list file .................................................................................... 489
3.30.1. General description ....................................................................... 489
3.30.2. <Objects> ...................................................................................... 490
3.30.3. <Configuration> ........................................................................... 490
3.30.4. <Object> ....................................................................................... 490
3.30.5. Examples ........................................................................................ 491
3.31. A file of merge settings .................................................................... 492
3.31.1. General information ...................................................................... 492
3.31.2. <Settings> ..................................................................................... 494
3.31.3. Auxiliary items ............................................................................... 502
3.32. File of differences in configuration uploads .................................. 508
3.33. Standalone server configuration file .............................................. 509
3.33.1. General information ...................................................................... 509
3.33.2. server .............................................................................................. 509
3.33.3. database ......................................................................................... 510
3.33.4. infobase .......................................................................................... 511
3.33.5. http ................................................................................................. 511

Appendix 4. Supplementary utilities ............................... 519

4.1. Verification utility chdbfl .................................................................. 519
4.2. The integrity monitoring utility ci .................................................. 520
4.2.1. General information ...................................................................... 520
4.2.2. List of information source templates .......................................... 521
4.2.3. A universal descriptor of the source of information ................. 522
4.2.4. File of the template base ............................................................. 524
4.2.5. Report file....................................................................................... 525
4.2.6. Using the utility ............................................................................. 526
4.2.7. Recommendations for installation and use................................ 527
 4.3. Conversion utility cnvdbfl ................................................................ 529
4.4. Ring utility ......................................................................................... 530
4.4.1. General information...................................................................... 530
4.4.2. System requirements ................................................................... 531
4.4.3. Installing the utility....................................................................... 531
4.4.4. Use recommendations ................................................................. 531
4.5. Licensing utility ................................................................................. 533
4.5.1. General information...................................................................... 533
4.5.2. System requirements ................................................................... 533
4.5.3. Installing the module ................................................................... 534
4.5.4. Module commands ....................................................................... 535
4.6. Administrative console utility 1cv8a............................................... 546
4.7. Running Designer in agent mode................................................... 548
4.7.1. General information...................................................................... 548
4.7.2. List of commands ......................................................................... 549
4.7.3. help ................................................................................................. 549
4.7.4. Common group commands ......................................................... 552
4.7.5. Options group commands ........................................................... 552
4.7.6. The commands of a group config .............................................. 554
4.7.7. Infobase-tools group commands ................................................ 560
4.7.8. Format of the JSON messages.................................................... 561
4.7.9. Notification about the progress of time-consuming
operation execution ...................................................................... 562
4.7.10. Recommendations for configuring the SSH clients .................. 563
4.8. Client application agent 1cecla ...................................................... 563
4.8.1. General information...................................................................... 563
4.8.2. Agent installation .......................................................................... 564
4.8.3. Agent interface.............................................................................. 565

Appendix 5. Error handling............................................... 567

Appendix 6. Internet services for retrieving
shared infobase list and client distribution
package 569
6.1. Retrieving the shared infobase list................................................. 569
6.1.1. General information...................................................................... 569
6.1.2. Using web services ....................................................................... 569
6.2. Getting the client application distribution package ...................... 576
6.2.1. General information...................................................................... 576
6.2.2. Using web services ....................................................................... 576

Appendix 7. The parameters of the command

line to launch 1C:Enterprise ......................................... 580
7.1. General information about the system command line
interface ............................................................................................. 580
7.2. Selecting run mode .......................................................................... 583
7.2.1. Launch in 1C:Enterprise mode.................................................... 583
 7.2.2. Launch in designer mode ............................................................. 583
7.2.3. Launch in the infobase creation mode ....................................... 583
7.3. General startup commands ............................................................. 584
7.3.1. Connection parameters ................................................................ 584
7.3.2. Authentication ............................................................................... 586
7.3.3. Specifying run mode ..................................................................... 587
7.3.4. Managing certificates .................................................................... 588
7.3.5. Interface settings .......................................................................... 591
7.3.6. Locale settings ............................................................................... 591
7.3.7. Debug settings .............................................................................. 591
7.3.8. Testing settings ............................................................................. 592
7.3.9. Client application checks .............................................................. 593
7.3.10. Auxiliary parameters ..................................................................... 593
7.3.11. Other parameters .......................................................................... 594
7.4. Running Designer in batch mode ................................................... 596
7.4.1. General information ...................................................................... 596
7.4.2. Upload/download infobase .......................................................... 596
7.4.3. Restoring infobase structure ....................................................... 597
7.4.4. Configurations and extensions .................................................... 597
7.4.5. Checking configurations and extensions .................................... 608
7.4.6. Configuration support ................................................................... 612
7.4.7. Commands for creating distribution and update files .............. 614
7.4.8. External reports and data processors ........................................ 617
7.4.9. Mobile application ......................................................................... 618
7.4.10. Mobile client ................................................................................... 618
7.4.11. Event log ........................................................................................ 618
7.4.12. Deleting data ................................................................................. 619
7.4.13. Predefined data ............................................................................. 619
7.4.14. Distributed infobase ...................................................................... 619
7.4.15. Configuration repository operations ........................................... 619
7.4.16. Agent mode commands ............................................................... 627
7.4.17. Other parameters .......................................................................... 628
7.5. Batch client application start mode ................................................ 628
7.6. Registering 1C:Enterprise as OLE Automation server.................. 630
7.7. Infobase connection string .............................................................. 630
7.7.1. General information ...................................................................... 630
7.7.2. Common parameter set ............................................................... 631
7.7.3. File-based infobase parameters .................................................. 631
7.7.4. Client-server infobase parameters .............................................. 632
7.8. Webclient command line.................................................................. 634
7.9. Mobile version command line .......................................................... 636

Appendix 8. Components and resources used ............. 638

Appendix 9. New and modified sections........................ 642
Introduction

This book is a guide for the administrators of 1C: Enterprise.

Overview
Chapter 1 contains system requirements for 1C:Enterprise deployment and
operation.
Chapter 2 describes installation of 1C:Enterprise.
Chapter 3 describes installation of 1C configurations.
Chapter 4 describes system startup and customization of the startup win-
dow.
Chapter 5 contains information on managing the list of infobases.
Chapter 6 explains 1C:Enterprise administration capabilities.
Chapter 7 describes standalone server starting and managing.
Chapter 8 describes how to configure web servers to work with 1C: Enter-
prise.
Chapter 9 describes how to configure web browsers to run the web client.
Chapter 10 describes the unauthorized use protection system and its set-
tings.
Chapter 11 describes the process of updating the system.
Chapter 12 describes the uninstallation process.
Chapter 13 describes administration of the mobile application.
The appendices contain various auxiliary information:
• Description of the directory structure that will be created after the in-
stallation, and descriptions of some files and directories.
• Description and location of internal files.
• Description of utilities for: infobase testing and correcting, integrity
monitoring, infobase conversion, and ring utility.
• Description of the command line for starting the 1C:Enterprise client
applications and Designer.
• Components and licenses used.
IMPORTANT! Information on administration of the client/server mode of
1C:Enterprise is provided in the 1C: Enterprise 8.3. Client/server mode
Administrator Guide. This book is part of the delivery of 1C:Enterprise
server software.
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, for more
information on compatibility see: 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.
• 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)

The $HOME expression means the Linux environment variable containing

the path to the current user profile directory. Instead of this environment
variable, the ~ / expression can be used in a file or directory path.
All files of the same name that are used simultaneously for Windows OS,
Linux OS and macOS, will be mentioned under the same name in this
guide, regardless of the OS being used. For example the 1cestart.cfg file
will be stated as is, however in Windows it has the 1CEStart.cfg name,
while in Linux and macOS- it is 1cestart.cfg.
Extensions of executable files are not specified. This means that 1cv8.exe
is mentioned as 1cv8in this manual. In Windows you must add .exe exten-
sion to the name, whereas in Linux and macOS you should leave it as is.
Also, Linux and macOS are case-sensitive, and Windows is not.
Chapter 1.
System and hardware
requirements

The latest 1C:Enterprise system requirements are published at: https://1c-

dn.com/library/system_requirements/http://www.v8.1c.ru/requirements/.

1.1. Thin client

End user computer:
• 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.
 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 7.
 Debian 8, 9.
 Mint 18, 19.
 Red Hat Enterprise Linux 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.
 macOS:
 Supported versions: 10.12 or later.
• Processor: Intel Pentium/Celeron 1800 MHz or better.
• RAM: 1 GB or more.
• Hard drive (about 70 MB required for installation).
• CD-ROM.
 • USB port.
• SVGA display.

1.2. Thick client

End user computer:
• 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.
 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 7.
 Debian 8, 9.
 Mint 18, 19.
 Red Hat Enterprise Linux 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.
 macOS:
 Supported versions: 10.12 or later.
• Processor: Intel Pentium/Celeron 1800 MHz or better.
• RAM: 1 GB or more.
• Hard drive (about 300 MB required for installation).
• CD-ROM.
• USB port.
• SVGA display.
Computer used for configuration development:
• 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.
 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 7.
 Debian 8, 9.
 Mint 18, 19.
 Red Hat Enterprise Linux 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.
 macOS:
 Supported versions: 10.12 or later.
• Processor: Intel Pentium/Celeron 2400 MHz or better.
• RAM: 2 GB or more (4 GB recommended).
• Hard drive (about 300 MB required for installation).
• CD-ROM.
• USB port.
• SVGA display.
The RAM requirements for thick client and configuration development may
vary between configurations.

1.3. Web client

End user computer:
• The web client requirements are generally defined by the web browser
used. The web client features are described in the book}.
Compatible web browsers:
 On Windows OS:
 Mozilla Firefox 52 and later
 Microsoft Internet Explorer 10.0 - 11.0
 Microsoft Edge
 Google Chrome 49 and later (x32- and x64 versions). The x64
version uses x32 versions of extensions and add-ins.
 Ensure that the latest operating system updates are downloaded
and installed.
 On Linux:
  Mozilla Firefox 52 and later
 On macOS:
 Safari 4.0.5 and later (for macOS 10.5 and later)
 Google Chrome 49 and later.
 Mozilla Firefox 52 and later
• Processor: Intel Pentium/Celeron 1800 MHz or better.
• RAM: 1 GB or more.
• Hard disk (about 250 MB required for installation).
• SVGA display.
TIP. For computers with low RAM and processor power, Google Chrome
is recommended.

1.4. Mobile client

• iOS devices:
 iOS - 7 or later;
 iPhone - 4 or newer;
 iPod Touch - 5th generation or newer;
 iPad - version 2 or newer;
 all versions of - iPad mini
• Android devices:
 Android - 4.0 and later
 Processor:
 ARMv7, ARMv8;
 Intel x86, x86_64.
 RAM: - at least 256 MB
 Touch screen
 The mobile platform does not work on devices with Android 4.0
(and later) that have Force GPU Rendering option enabled.
• Windows devices:
 Windows 10;
 Processor:
 Intel x86 architecture
 Intel x86-64 architecture
 ARM architecture.
 Touch screen
 Mouse support is limited
TIP. We recommend that you install the latest mobile OS updates.
1.5. Power-saving modes.
Power-saving modes are disabled on computers running 1C:Enterprise if:
• An online dongle is used
• The database file is located on a network drive (while the infobase is
in file mode)

1.6. Supported web servers

1C:Enterprise supports the following web servers:
• Microsoft Internet Information Services (IIS) 5.1, 6.0, 7.0, 7.5, 8.0,
8.5, 10.0
Web server documentation:
 IIS 6.0:
http://technet.microsoft.com/en-
US/library/cc785089.aspxhttp://technet.microsoft.com/ru-
ru/library/cc785089.aspx
 IIS 7.0:
http://technet.microsoft.com/en-
US/library/cc732976.aspxhttp://technet.microsoft.com/ru-
ru/library/cc732976.aspx
 IIS 7.5:
http://technet.microsoft.com/en-
US/library/cc754281.aspxhttp://technet.microsoft.com/ru-
ru/library/cc754281.aspx
 IIS 8.0, 8.5:
http://technet.microsoft.com/en-
US/library/hh831725.aspxhttp://technet.microsoft.com/ru-
ru/library/hh831725.aspx
• Apache HTTP Server 2.0, 2.2, 2.4.
You can download the latest web server version at:
http://httpd.apache.org/download.cgi. Web server documentation:
 Apache 2.0:
http://httpd.apache.org/docs/2.0/
 Apache 2.2:
http://httpd.apache.org/docs/2.2/
 Apache 2.4:
http://httpd.apache.org/docs/2.4/
NOTE. The list of currently supported web servers is published at
https://1c-
dn.com/library/system_requirements/.http://www.v8.1c.ru/requirements/
To use external data sources in infobase file mode that uses a Linux web
server, unixOdbc 2.2.11 or above must be available on the web server.
If the web server is used to access the file mode of the infobase, the com-
puter running the web server and web server extension must meet the fol-
lowing requirements:
• Intel Pentium/Celeron processor at 1800 MHz or higher
• 1 GB RAM or more (2 GB recommended)
• Hard disk (about 300 MB required for installation)
• CD-ROM
• USB port
• SVGA display.

1.7. Other requirements

1.7.1. On Windows
The Windows user that starts the client application must have List
folder contents right for the temporary files directory.
To use the software licensing system, a WMI service must be enabled
(Windows Management Instrumentation, http://msdn.microsoft.com/en-
us/library/aa394582.aspx).
Some fonts require the computer to be restarted after installation. If the font
is used by the client application, the client computer needs restarting. If the
font is used by the server, the server needs restarting.--
When working in Windows 10 via Remote desktop connection, it is rec-
ommended that you disable Visual effects of menus and windows in
connection settings. This check box is available in additional parameters of
the Interaction tab.
Nonvisual 1C:Enterprise access is supported in Windows XP and above.
Nonvisual access requires:
• Microsoft UI Automation. For Windows Server 2008 or older, Mi-
crosoft .NET Framework 3.0 is required.
• NVDA (http://www.nvaccess.org/) screen reader is recommended.
Depending on the OS used, different versions of NVDA are recom-
mended:
 For Windows XP SP3, using NVDA 2011.1 is recommended. You
can download this version from
https://sourceforge.net/projects/nvda/files/releases/2011.1/
nvda_2011.1_installer.exe/download.
 For Windows 7 and above, you can use any version of NVDA.
• For Russian speech, install RHVoice speech synthesizer
(https://github.com/Olga-Yakovleva/RHVoice/wiki).
Nonvisual access is available:
• When working with the managed forms
• When using Taxi interface with any form item placement mechanism
• In thin and thick clients

1.7.2. On Linux
For Linux, the following libraries must be installed:
• webkitgtk-3.0.0 1.4.3 and later
To use other functions, the following libraries might be required:
• fontconfig:
 Library name: libfontconfig
 Version: 2.3.0 or later
 Purpose:
 For the managed mode of the 1C:Enterprise server
 When Chart, GraphicalSchema, or
SpreadsheetDocument objects are used on server
 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.8. Restrictions
For file infobase collaboration, all client applications must have the same
version. At the same time, the client applications may use any architecture
(32- or 64-bit application) and any operating system (Windows or Linux).
Maximum number of concurrent connections per infobase is 1,024.
Online collaboration using file infobases is only supported for network re-
sources that are accessed via SMB protocol (CIFS). These resources can be
located on both Windows and Linux computers.
Client application running on macOS does not support network infobases.
Please remember that bitness of add-ins and COM objects (on Windows)
must match bitness of the 1C:Enterprise application used (thin or thick cli-
ent, server, or web server). In other words, if a COM object only has 32-bit
version, it cannot be used in the 64-bit version of 1C:Enterprise.

1.9. Platform and licensing

options
1.9.1. General information
1C:Enterprise platform is available in several distribution packages, and
several license types that enable some platform features and restrict others.
Below, you can find distribution package options and license types.

1.9.2. Distribution package

options
1C:Enterprise distribution packages:
• Standard version of 1C:Enterprise. Requires a license. Functionali-
ty might be restricted by the licenses.
• Training version of 1C:Enterprise (https://1c-
dn.com/developer_tools/1c_enterprise_8_platform_training_version/).
http://v8.1c.ru/edu/ Does not require a license. The training version
has the following restrictions:
 It cannot be used for actual enterprise accounting purposes.
  It cannot be used to build distribution packages of mobile applica-
tions intended for publication and replication.
 Data volume is restricted:
 maximum number of records in account tables is - 2,000;
 maximum number of records in main object tables is - 2,000;
 number of records in tabular sections of objects is - 1,000;
 number of records in record sets is - 2,000;
 Number of records from external data sources - 200
 Client/server mode is not supported.
 Infobases are not supported.
 COM connections are not supported.
 Passwords and OS authentication are not supported.
 Printing and saving spreadsheet documents is only supported in
Designer mode.
 Copying multiple spreadsheet document cells is not supported in
1C:Enterprise mode.
 Training version is slower than the commercial version of
1C:Enterprise.
 Configuration repository is not supported.
 Configuration delivery functions are not available.
 Only one connection can be established per infobase.
 Separator values are set to separator type defaults.
• 1C:Enterprise - File operations
(http://v8.1c.ru/metod/fileworkshop.htm). Does not require a li-
cense. This distribution package has the following features and re-
strictions:
 1C:Enterprise infobases are not supported
 The following 1C:Enterprise files can be opened and viewed:
 Spreadsheet documents
 Text documents
 Graphical diagrams
 Geographical schemas
 HTML documents

1.9.3. License types

To use 1C:Enterprise (except the training version), a license is required.
Licenses fall into client and server categories:
• Client license:
 Purpose: Required for using client application in file or cli-
ent/server mode.
 Types:
 CORP client license. Enables all system functionality.
  PROF client license. Allows you to use the system features in
accordance with the limitations of the PROF server license.
 Basic license. Restricts the system functionality as follows:
 Only one user can work with the system at the same time.
 Configurations cannot be edited in Designer.
 Client/server mode is not supported.
 Distributed infobases are not supported.
 Internet services cannot be provided.
 Web client mode is not supported.
 External connection mode is not supported.
 Extensions are not supported.
• Server license:
 Purpose: Required for 1C:Enterprise servers This license is re-
quired to use client/server mode of 1C:Enterprise. Besides this li-
cense, client/server mode also requires client licenses.
 Types:
 CORP-level server license. The license is only available for
64-bit 1C:Enterprise server. This license enables full function-
ality of 1C:Enterprise server.
 PROF server license. The license is available for 32-bit- and
64-bit 1C:Enterprise servers.
The 32-bit license allows to run any number of 32-bit working
processes on a physical computer. The 64-bit license allows to
run any number of 32-bit and 64-bit working processes on a
physical computer.
Any PROF server license provides the use of all the
1C:Enterprise server features, except for the following:
 Background updates of database configuration.
 Additional management of allocating the following entities
to working servers in a cluster by infobases, client applica-
tion types, and background tasks:
 Cluster services.
 Infobase connections.
 Flexible load management in a cluster:
 Safe memory usage per call. The default value is 0.
 Number of infobases per process. The default value is 8.
 Set the load balancing mode to Memory Priority.
 External session management.
 Security profiles.
 Getting thin client updates from the server.
 Publishing infobase list and thin client updates over HTTP.
 Using the database copy feature.
 Using Data accelerator.
 Use of resource consumption management mechanism.
  500+ concurrent user sessions (Designer instances, external
connections, any client applications) per infobase.
 More than 12 CPU cores usable by 1C:Enterprise server
cluster processes. 1C:Enterprise server cluster with PROF
license can use up to 12 cores even if more cores are avail-
able. The “core” refers to the physical core of a computer
CPU or any core of a virtual machine that runs a server
cluster.
 Deployment of dedicated collaboration server.
 MINI server license (https://1c-
dn.com/news/1c_enterprise_8_server_mini_is_available_at_1c
_dn_com_online_store/).http://www.1c.ru/news/info.jsp?id=17
577 The license is available for 32-bit- and 64-bit
1C:Enterprise servers. Besides the regular server license re-
strictions, the MINI server license has the following re-
strictions:
 No more than one working server can exist in a cluster
 No more than 5 concurrent client sessions and 1 Designer
session can be connected to the server
• Feature testing license (http://1c.ru/news/info.jsp?id=25182).
 Purpose: required to test features in beta testing. A feature testing
license is an addition to a server license of any type.
 Features of the feature testing license:
 The license is activated on the 1C:Enterprise server computer.
 A license may be granted by the server cluster licensing ser-
vice.
 The number of feature testing licenses must be equal to or
greater than the number of server cluster licenses for the server
cluster that runs the beta testing.
 The license does not provide for using the server cluster with-
out a server license.
 The list of features that requires a feature testing license is de-
termined at 1C:Enterprise version release.
 The final licensing requirements of the tested features are de-
termined at the time these features are withdrawn from beta
testing.
 To obtain a feature testing license, email a request at be-
[email protected].

1.9.4. CORP license applicability

All 1C:Enterprise features (available under the CORP license) are available,
if not more than 10 client sessions are connected to each infobase of
1C:Enterprise server cluster at the same time. In this case, both server and
all the client licenses can be of PROF level. If a further session is connected
to any of the server cluster infobases, an error is returned, whenever a server
cluster supports features provided by CORP license, and the number of
CORP licenses is insufficient.
If 1C:Enterprise uses the features provided by the CORP license, and the
number of user sessions in one infobase exceeds 10, then starting a new user
session in this infobase is only possible if there is a sufficient number of
CORP client and server licenses.
Number of CORP licenses is considered to be sufficient if all the server
licenses used by the cluster are CORP level and one of the two conditions is
additionally met:
1. The client application has been granted a CORP client license.
2. The client application has been granted a PROF license and at the time
of establishing a new client connection, the ratio of licenses used is as
follows: UU <= 1.1 * CL. Where:
 UU - the number of unique users (uniqueness is tracked by
username) of the cluster client sessions with any license type, in-
cluding the starting session;
 CL - the number of CORP client licenses available for granting by
the 1C:Enterprise server (regardless of the actual status of the
1C:Enterprise server license granting flag).
Consider an example. A CORP server license and a CORP client license for
50 users are installed on 1C:Enterprise server computer. Such configuration
provides for:
• An arbitrary number of client connections if each client connection
has a CORP level license.
• Connection of client application with the PROF license to the server
will be possible if after connecting the server will maintain sessions of
no more than 1.1*50 = 55 unique infobase users. Therefore, a user
with PROF license can access an infobase, only if upon connection the
number of unique server cluster users (including the session which is
started) fails to exceed 55.
Chapter 2.
Installing 1C:Enterprise

2.1. General information

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.
The 1C:Enterprise launcher maintains the unified infobase list for all plat-
form versions (8.0, 8.1, 8.2, and 8.3).

2.2. 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.
For macOS-based installations, a standalone installer is used. It does not
allow you choose the components installed and is similar to Linux installer.
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.
2.3. Windows Installer
2.3.1. Available installers
The following installers are available:
• 1C:Enterprise 8 - allows installing any components. 32-bit- and 64-
bit versions of this installer are available.
• 1C: Enterprise 8 Thin client -allows you to install only the thin cli-
ent and the components required to access the 1C:Enterprise server.
32-bit- and 64-bit versions of this installer are available.
• 1C:Enterprise 8 (x86-64) -allows you to install 64-bit 1C:Enterprise
server. Only 64-bit version of this installer is available.
All installers offer similar user experience; therefore, only general infor-
mation for 1C Enterprise 8 installation is provided below.

2.3.2. About installer

2.3.2.1. General information
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.
Installation can be performed if:
• The user running the installer is a local administrator
• The user running the installer is not a local administrator but is permit-
ted to install applications (AlwaysInstallElevated registry key)
Whenever setup.exe is started using /S, installation is made in silent mode.
Moreover, installation parameters are received from 1cestart.cfg file. If no
file exists, installation is made by default.
In an installation program, you can specify, whether a program dongle is to
be searched, as soon as you start a client application so installed. Specifical-
ly, an installation program writes UseHwLicenses parameter in
1cestart.cfg file of a user running 1C:Enterprise installation program. For
an installation program to be able to modify the configuration file, use any
of the following methods:
• Specify USEHWLICENSES command line option to start setup.exe:
setup.exe USEHWLICENSES=0

• Specify USEHWLICENSES parameter in setup.ini file, in CmdLine

parameter of Startup group.
When you install 1C:Enterprise on a computer running Windows XP, instal-
lation program interface in Vietnamese is unavailable.
Every wizard step is briefly described below. The examples describe instal-
lation of full 32-bit 1C:Enterprise distribution package.

2.3.2.2. Welcome screen

This is the starting window of the 1C:Enterprise installation wizard.

Fig. 1. Welcome screen

2.3.2.3. Selecting components
On this page, you need to choose components to be installed and installation
directory. The component list depends on what exactly you need to have
installed. Some standard installation scenarios are described below.

Fig. 2. 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. 3).

Fig. 3. Component installation menu

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

Fig. 4. 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-
tions
1C:Enterprise server Components of the 1C: Enterprise
server, including the administration
server and the administration utility
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 1C:Enterprise configuration repository
storage server server components
Additional administration func- Administrative console utility
 Component Brief description
tions
1C: Enterprise 7.7 infobase 1C:Enterprise 7.7 infobase converter
converter
Integrity monitoring Data integrity monitoring utility

Regardless of the 1C:Enterprise installation directory (Folder: field and

Edit button), some directories of the installed system will be have prede-
fined locations.
After installation, the local configuration file will be generated (for more
information, see 369) for all users. The file will have two parameters speci-
fied: InstalledLocation and InstallComponents. The values of
these parameters will be set according to settings specified during installa-
tion.
Integrity monitoring utility is installed by default in the same directory as
1C:Enterprise. Installation directory can be changed, if needed. To change
the installation directory, select Integrity monitoring component and click
Edit… button to change the installation directory.

Fig. 5. Installing integrity monitoring utility

The installation directory of integrity monitoring utility cannot be changed
if the component is skipped.
Installation of the integrity monitoring utility is not recorded in the local
configuration file. When installing any version of 1C:Enterprise, you need
to manually mark this utility for installation.
2.3.2.4. Selecting default interface language
At the next step, the installer prompts you to select the default interface lan-
guage.

Fig. 6. 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 is created in the C:\Program
Files\1cv8\conf directory.
To use 1C:Enterprise with a non-default interface language, specify the lan-
guage 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
 Interface language Language code
Latvian lv
Lithuanian lt
German de
Polish pl
Romanian ro
Russian ru
Turkish tr
Ukrainian uk
French fr

2.3.2.5. 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. 7. 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.
2.3.2.6. Installation start
Click Install to start the installation procedure that:
• Creates the required directories
• 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. 8. 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 (8.3.3.100).
2.3.2.7. Install 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. 9. 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 License Agreement for the use of the 1C:Enterprise main
distribution kit
• The user has a 1C:Enterprise client license for at least one workplace
• The user has a 1C:Enterprise server license
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 - 1C En-
terprise 8 - Install protection driver menu.
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. Installation comple-
tion
If the installation is successful, the final page of the installation wizard
opens. Click Done to complete the installation.
If the Open Readme file check box was selected, a file containing infor-
mation recommended for reading before using this version will be opened.

Fig. 10. Installation completion

2.4. macOS Installer

Client application distribution package is stored in the disk image file for
macOS (*.dmg files). The installer itself is “inside” the disk image. You
cannot choose which components to install. Two distribution delivery op-
tions are available:
1. To install thin and thick client applications, and 1C:Enterprise server
cluster access components. Disk image has a name clien-
tosx_A_B_C_D.dmg.
2. To install thin client application and 1C:Enterprise server cluster ac-
cess components. Disk image has a name
thin.clientosx_A_B_C_D.dmg.
The A_B_C_D text in the image file name (and further, in the installer
names) means the full version of the platform, the installer of which is lo-
cated on the disk image file. The file with the installer distribution image for
the thin client version 8.3.13.100 will be named
thin.clientosx_8_3_13_100.dmg.
You need to know the name of the user with administrative privileges and
the password to complete the installation. To start installation:
• Double-click the image file. A new window with contents of the im-
age file will open.
 • To install the client application itself, double-click the file named as
follows
 1cv8-client-A.B.C.D.pkg - thin and thick client application in-
staller.
 1cv8-thin-client-A.B.C.D.pkg - thin client application installer.
• The client application installation wizard will open. On the first page,
click Next; on the second page, click Install. After you enter creden-
tials of a user with administrative rights, the 1C:Enterprise client ap-
plication will be installed.

2.5. Typical 1C:Enterprise

installation scenarios
2.5.1. On Windows
2.5.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.

2.5.1.2. Thin and thick client

To install this version of 1C:Enterprise, mark the following components for
installation:
• 1C:Enterprise
• 1C:Enterprise - Thin client, file mode
If the local client key is used, install HASP Device Driver. The driver must
be installed before the protection key is inserted into the USB port of a
computer. If the network protection key is used, there is no need to install
the HASP Device Driver.
The following applications can be started:
• Designer
• Thin client
• Thick client
The following infobases can be used:
• File infobase (local version)
• File infobase (network version)
• Client/server mode
• Any infobase with access via web server
2.5.1.3. Thin client
To install this version of 1C:Enterprise, mark 1C:Enterprise- Thin client,
file mode component for installation.
If the local client key is used, install HASP Device Driver. The driver must
be installed before the protection key is inserted into the USB port of a
computer. If the network protection key is used, there is no need to install
the HASP Device Driver.
Thin client can be started.
The following infobases can be used:
• File infobase (local version)
• File infobase (network version)
• Client/server mode
• Any infobase with access via web server
NOTE. This installation does not support configuration development.

2.5.1.4. Thin client - client/server mode

To install this version of 1C:Enterprise, mark 1C:Enterprise -Thin client
component for installation.
If the local client key is used, install HASP Device Driver. The driver must
be installed before the protection key is inserted into the USB port of a
computer. If the network protection key is used, there is no need to install
the HASP Device Driver.
Thin client can be started.
The following infobases can be used:
• Client/server mode
• Any infobase with access via web server
NOTE. This installation does not support configuration development.

2.5.1.5. Thick client

To install this version of 1C:Enterprise, mark 1C:Enterprise component for
installation.
If the local client key is used, install HASP Device Driver. The driver must
be installed before the protection key is inserted into the USB port of a
computer. If the network protection key is used, there is no need to install
the HASP Device Driver.
The following applications can be started:
• Designer
• Thick client
The following infobases can be used:
 • File infobase (local version)
• File infobase (network version)
• client/server mode

2.5.1.6. Configuration repository server (TCP

protocol)
To install 1C:Enterprise configuration repository server on a computer and
use it via TCP, mark 1C:Enterprise configuration repository server
component for installation.

2.5.1.7. Configuration repository server (HTTP

protocol)
To install 1C:Enterprise configuration repository server on a computer and
use it via HTTP, mark the following components for installation:
• Web server extension modules
• 1C:Enterprise configuration repository server

2.5.1.8. Enabling web client or web service

publication
To enable publication of web client on the computer used for installation,
mark Web server extensions modules component for installation.
To publish web client or web service, use web server publication dialog box
or webinst utility (for web client only).

2.5.1.9. Enabling Designer usage

To enable Designer usage, mark 1C:Enterprise component for installation.

2.5.1.10. Installation with Windows

administrative tools

2.5.1.10.1. Installation with group policies

When installing with group policies, specify the language transformation
file to select the installation language. File names correspond to Microsoft
Windows LCID in decimal format (with .mst extension). Transformation
file for the Russian language is called 1049.mst.
Besides, select adminstallrestart.mst transformation file. In this case,
1C:Enterprise will offer to restart the computer and install the newer version
in case of client and server version mismatch. Administrators need to make
sure that distribution package is added to group policies prior to the installa-
tion.
Several 1C:Enterprise versions can be installed using group policies. To
install a new version, create a new installation in group policies.

2.5.1.10.2. Installation with logon script

The system can be installed using the script that is executed during user
authorization in the domain. The domain administrator starts the script job.
If the user does not have software installation rights, the administrator needs
to specify that the installation script is started on behalf of the user that has
such rights.
This script can be used to install or uninstall several versions of
1C:Enterprise. To do this, call installOrUninstall procedure with
the required parameters.
To install the new version, the administrator only needs to edit the shared
network resource paths and specify the product code that can be found in
setup.ini file.
Additionally, adminstallrelogon.mst transformation file must be specified.
In this case, 1C:Enterprise will offer to finish the current session and install
the newer version in case of client and server version mismatch. The admin-
istrator needs to ensure that the script is updated and the distribution pack-
age with the new version is available on the network resource.

2.5.1.10.3. Version update

When installing the 1C:Enterprise platform using administrative tools, the
adminstall.cfg file is created in the configuration files directory.
If the required 1C:Enterprise version is not found on the computer when
you start an infobase and the user does not have sufficient rights to install
this version, the user will be offered to take action specified in the admin-
stall.cfg file: restart the computer, or log out and log on again.

2.5.1.11. Integrity monitoring utility

To install this version of 1C:Enterprise , mark Integrity monitoring com-
ponent for installation. Edit the installation directory if needed.

2.5.1.12. Administrative console utility

To install this version of 1C:Enterprise, mark Additional administration
functions component for installation.
2.5.2. On Linux
2.5.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 - 1C:Enterprise server components and integrity control
utility
 ws- adapter for publishing 1C:Enterprise web services on a web
server based on Apache HTTP Server 2.0, 2.2 or 2.4
 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>- full number of 1C:Enterprise version the package belongs
to For example, for 1C:Enterprise 8.3.12.1440, the package name con-
tains a numerical string: 8.3.12-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 any other 1C:Enterprise packages. Conflicts with common
package. You cannot have both thin-client and other packages in-
stalled at the same time.
• Locale resource packages depend on the respective main packages.
Therefore, in order to successfully install a package, you must first install
all the packages it depends on. For example, to install the 1C:Enterprise
server, first install the common package, and then install the- server pack-
age.
After installation of the client applications, shortcuts for the launcher
(1cestart), thin client (1cv8c), and thick client (1cv8) are added to the ap-
plication menu of the desktop environment. The shortcuts are only created
for installed applications. The shortcuts are created in the Finance subcate-
gory of the Office category of the menu.
The installation is performed on behalf of a user that has administrative
privileges (for example, root).

2.5.2.2. Thin and thick client

To install this version of 1C:Enterprise, the following packages must be
installed:
• common (and common-nls resources if necessary)
• server (and server-nls resources if necessary)
• client (and client-nls resources if necessary)
If the local client key is used, install HASP Device Driver. The driver must
be installed before the protection key is inserted into the USB port of a
computer. If the network protection key is used, there is no need to install
the HASP Device Driver.
The following applications can be started:
• Designer
• Thin client
• Thick client
The following infobases can be used:
• File infobase (local version)
• File infobase (network version)
• Client/server mode
• Any infobase with access via web server

2.5.2.3. Thin client

To install this version of 1C:Enterprise, the following packages must be
installed:
• thin-client (and client-nls resources if necessary)
If the local client key is used, install HASP Device Driver. The driver must
be installed before the protection key is inserted into the USB port of a
computer. If the network protection key is used, there is no need to install
the HASP Device Driver.
Thin client can be started.
The following infobases can be used:
• File infobase (local version)
• File infobase (network version)
• Client/server mode
• Any infobase with access via web server
NOTE. This installation does not support configuration development.

2.5.2.4. Configuration repository server (TCP

protocol)
To install 1C:Enterprise configuration repository server and use it over
TCP, install the following packages:
• common (and common-nls resources if necessary)
• server (and server-nls resources if necessary)
• crs (and crs-nls resources if necessary)

2.5.2.5. Configuration repository server (HTTP

protocol)
To install 1C:Enterprise configuration repository server and use it over
HTTP, install the following packages:
• common (and common-nls resources if necessary)
 • server (and server-nls resources if necessary)
• ws (and ws-nls resources if necessary)
• crs (and crs-nls resources if necessary)

2.5.2.6. Web client

To use the web client, install the following packages on the computer with
the web server:
• common (and common-nls resources if necessary)
• server (and server-nls resources if necessary)
• ws (and ws-nls resources if necessary)
• crs (and crs-nls resources if necessary)
Publish web client using webinst command line utility.

2.5.2.7. Integrity monitoring utility

To install this version of 1C:Enterprise, the following packages must be
installed:
• server (and server-nls resources if necessary)
To install the utility in a non-default directory, use the package manager for
your version of Linux.

2.5.2.8. Administrative console utility

To install this version of 1C:Enterprise, the following packages must be
installed:
• client (and client-nls resources if necessary)
• server (and server-nls resources if necessary)

2.5.3. On macOS
Client application installer for macOS does not support configurable instal-
lation options. All available components are installed.

2.6. Recommendations for

system deployment
NOTE. This recommendation is only applicable to client computers run-
ning Windows or macOS.
To simplify automated installation of new 1C:Enterprise versions on the
user computer (including the initial installation), the following file structure
is recommended:

Fig. 11. Directory structure

On the figure above:
• \\Server\1CEDistr -is a directory with system deployment files locat-
ed on Server. On a computer running macOS, the \\Server\1CEDistr
directory must be mounted on the computer. Using UNC paths on ma-
cOS is not supported.
• 1cestart - is the launcher. For initial installation, start the launcher
from this network directory. It is recommended that you obtain the
latest available version of the launcher. Use 1cestart.app for macOS.
• ibcommon.v8i - is the shared infobase list (the name can be changed).
• 1cescmn.cfg - is the common configuration file. It is recommended
that you specify the following parameters:
 CommonInfoBases=FileNameWithTheListOfCommonI
nfobases.v8i - set this parameter to display the list of infobas-
es in the launcher.
 InstallComponents - use this parameter to specify the com-
ponents you need to install on user computers.
  DistributiveLocation - use this parameter to specify
1C:Enterprise distribution package directory.
• 8.3.14.100 - directory with 1C:Enterprise distributions:
 Setup - is a distribution package for 32-bit version of
1C:Enterprise.
 Setup64full - is a distribution package for 64-bit version of
1C:Enterprise.
 Setup.exe - is a 1C:Enterprise installation launcher.
 clientosx_8_3_14_100.dmg - thin and thick client installer disk
image for macOS.
 thin.clientosx_8_3_14_100.dmg - thin client installer disk im-
age for macOS.
• 8.3.14.150 - directory with 1C:Enterprise distributions. The directory
structure is similar to the directory with version 8.3.14.100 (see item
above).
In this example, the following common configuration file is used to install
all components and two languages, Russian and English:
Content of 1cescmn.cfg file:
CommonInfoBases=ibcommon.v8i
DistributiveLocation=\\Server\1CEDistr
DistributiveLocation=/Volumes/Server/1CEDistr
InstallComponents=DESIGNERALLCLIENTS=1 SERVER=1 WEBSERVEREXT=1
CONFREPOSSERVER=1 SERVERCLIENT=1 CONVERTER77=1 LANGUAGES=ru

IMPORTANT! Common configuration file 1cescmn.cfg must not be

stored on the user computer.
After the release of the new 1C:Enterprise version (for example,
8.3.14.200), it will only be necessary to copy the distribution files, preserv-
ing the structure of the version directory given above:
• \\Server\1CDistr\8.3.14.200\Setup - directory for Windows 32-bit
application distribution files.
• \\Server\1CDistr\8.3.14.200\Setup64full - directory for Windows
64-bit application distribution files.
• \\Server\1CDistr\8.3.14.200\clientosx_8_3_14_200.dmg - ma-
cOS client application distribution image (thin and thick client appli-
cations).
• \\Server\1CDistr\8.3.14.200\thin.clientosx_8_3_14_200.dmg -
macOS client application distribution image (thin client only).
1C:Enterprise will automatically complete the installation on startup.
Remember the following features when using such a deployment scheme:
 • On Windows OS:
 The launcher always installs 1C:Enterprise into the default folder.
To change the installation directory, run the installer for the re-
quired version (setup.exe) manually.
 Only InstallComponents parameter from the common con-
figuration file is used during installation. Other parameters do not
affect the installation process and are not copied from the common
configuration file to the local configuration file. In the example
above, the following components are used:
InstallComponents=DESIGNERALLCLIENTS=1 SERVER=1 WEBSERVEREXT=1
CONFREPOSSERVER=1 SERVERCLIENT=1 CONVERTER77=1 LANGUAGES=ru

During installation, the CommonCfgLocation parameter is

written to the local configuration file. Its value is the path to the
common configuration file, which is located in the deployment di-
rectory. In the example above, the path to this file is:
\\server\1cdistr\1cescmn.cfg. Parameters specified in this file
will be used both by the launcher and in the startup dialog box of
the client application.
 Whenever Windows XP is unavailable in a list of client operating
systems, there is no need to copy files with _xp name suffix to di-
rectories with distribution packages for OS Windows. Examples of
the said files: 1CEnterprise 8_xp.msi, 1026_xp.mst,
1031_xp.mst etc.
• On macOS:
 The server directory where the installation files are located must
be mounted on the client computer in any way possible. On all
Apple client computers, this directory must be mounted at the
mount point with the same name. In above example
\\Server\1CDistr directory is mounted to
/Volumes/Server/1CDistr mounting point. Use forward slashes
(“/”) to specify the path.
 The common configuration file InstallComponents parameter is
ignored.
2.7. Installing and configuring
additional software
2.7.1. On Windows
2.7.1.1. Nonvisual access for visually impaired
users
3. To install the NVDA screen reader that enables nonvisual access to
1C:Enterprise interface, download the software from
http://www.nvaccess.org/ and install it on a client
computer.http://nvda.ru/
4. For interface voice-over, a variety of speech synthesizers can be used.
You can download them at
https://github.com/nvaccess/nvda/wiki/ExtraVoices. For the Rus-
sian language, using RHVoice speech synthesizer is recommended.
You can download it from https://github.com/Olga-
Yakovleva/RHVoice/wiki.

2.7.2. On Linux
2.7.2.1. Recommendations for using file
infobases
When using infobases in file mode on a Linux-based computer, please con-
sider the following:
• When connecting a network resource on Linux using mount.cifs
command, do not use nobrl key
(http://www.samba.org/samba/docs/man/manpages-
3/mount.cifs.8.html).
• When granting access to the infobase directory using Samba, do not
specify the locking=no parameter for the published resource in
smb.conf file
(http://www.samba.org/samba/docs/man/manpages-
3/smb.conf.5.html).
• If multiple users are expected to access a file infobase on the same
computer, consider the following:
 On Linux, the user that started the file creation process is specified
as the owner of the created file. Files created in 1C:Enterprise have
permission to be read and written only by their owner or the owner
 group. As a result, when several concurrent users access a file in-
fobase, only the first user can access the created files. To work
with the infobase concurrently, all users need to be in the same
group and this group needs to be set as the owner of the infobase
directory. After this, you also need to set the set-group-ID
flag for this directory using chmod g+s ib_dir command, where
ib_dir - is the name of the infobase directory. Now, the group that
owns the main infobase directory will be assigned as the owner of
any files to be created in this directory, instead of the main group
of a user that creates the files.
 On Linux, 1C:Enterprise creates files with explicit 0660 permis-
sions (read/write privileges for the file owner and owner group).
Manually setting a value for file creation mode mask (umask) in
the environment can only result in clearing some of the permis-
sions, making for stricter file creation rules. Because access per-
mission flags for other users are not set for the platform-created
files, you cannot modify them with umask.
 If the infobase is accessed using a Linux-based web server, add the
user on whose behalf Designer is started to www-data group.
Then, make www-data the owner of infobase directory and set
set-group-ID flag for this directory. Next, add umask 002
string to the /etc/apache2/envvars file. Adding this string pre-
vents users from clearing a flag that allows the owning group to
write (g-w) to the files created by Apache web server.
This procedure is also used to configure Linux for shared access to configu-
ration repository; however, the configuration repository directory is used
instead of the infobase directory.

2.7.2.2. Installing fonts

To ensure correct 1C:Enterprise behavior on Linux, install the fonts from
the Microsoft Core Fonts set. These fonts can be installed using any of
these methods:
• Use the fonts package that is included in general distribution package
(checked in each distribution package).
• For RPM version of Linux, installation instructions are available at:
http://corefonts.sourceforge.net/.
• Manual installation is available as well. To do this:
 Download all font files from:
http://sourceforge.net/projects/corefonts/files/the%20fonts/
final/.
  Unpack the files.
 Place the font files into ~/.fonts directory of the home directory
of the user(s) on whose behalf 1C:Enterprise is started. Here, ~ is
a user's home directory-.

2.7.2.3. Operating system authentication when

using Apache web server
When using Apache web server, operating system authentication can be
configured for thin client and web client. This section assumes that Apache
web server is already installed on the computer and configured for web cli-
ent access.
IMPORTANT! To configure operating system authentication, the network
needs a deployed PDC under Windows 2000 or later.
Follow these steps:
• Install mod_auth_kerb authentication module. It is included in most
distribution packages. You only need to install the package. For Fedo-
ra, this package is called mod_auth_kerb, and for Debian, it is - li-
bapache2-mod-auth-kerb. If your operating system does not include
this module, download the source code from the project's homepage:
http://modauthkerb.sourceforge.net/.
• The following installation options are available:
 Install the module from the OS distribution package. In this case,
you only need to restart the web server to activate the module.
 Compile and install the module separately (the installation manual
is available at
http://modauthkerb.sourceforge.net/install.html). To activate
the module, add the string below into the Apache web server con-
figuration file (httpd.conf) and restart Apache:
LoadModule auth_kerb_module /path_to_the_file/mod_auth_kerb.so

To authenticate, the module needs a private Kerberos key for

HTTP/Server.domain@DOMAIN. You need to generate this key according
to Kerberos authentication manual. Please note that for the account associ-
ated with HTTP/Server.domain@DOMAIN name, you need to select Ac-
count is trusted for delegation check box.
For example, let us assume that the file with the key is called HTTP.keytab
and it is located in the home directory of usr1cv8 user.
In this example, you need to add the following strings to the file section
describing the web server virtual directory:
<Directory "/home/usr1cv8/www/MyApp">
AllowOverride None
Options None
Order allow,deny
Allow from all
SetHandler 1c-application

ManagedApplicationDescriptor /home/usr1cv8/www/MyApp/default.vrd

AuthName "1C:Enterprise web client"

AuthType Kerberos
Krb5Keytab /home/usr1cv8/HTTP.keytab
KrbVerifyKDC off
KrbDelegateBasic off
KrbServiceName HTTP/Server.domain@DOMAIN
KrbSaveCredentials on
KrbMethodK5Passwd off
KrbMethodNegotiate on
Require valid-user
</Directory>

Make sure you specify a valid path to key file. The user on whose behalf
Apache is started must be able to access this file.
IMPORTANT! In a domain with both Windows 2000 and Windows 2003
controllers, Linux-based web servers and Windows-based 1C:Enterprise
servers, Kerberos authentication might not work due to the specifics of Ker-
beros implementation for Windows 2000.

2.8. Recommendations for

component registration
NOTE. This recommendation is only applicable for computers that have
Windows installed.
The installer performs registration of some components (COM connection,
etc.) In this case, registration is performed as follows:
• 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

• Client application (V83.Application COM object). The installer

performs component registration for the computer (starting the client
 application with the RegServer command does the same). If the user
has insufficient privileges, registration for the user is offered instead.
• Version of 1C:Enterprise to establish COM connection (using
V83.COMConnector) and version of 1C:Enterprise targeted by the
COM connection must either be identical or have different two first
digits. In other words, 1C:Enterprise 8.3 can establish a COM connec-
tion with 1C:Enterprise 8.2, 8.1, and so on, but 1C:Enterprise 8.3.6
cannot establish COM connection to 8.3.5. At the same time,
1C:Enterprise 8.3.6.2100 can establish COM connection with
8.3.6.2100.
If The module ... was loaded but the call to DllRegisterServer failed
with error code 0x80070005 error message is displayed during compo-
nent registration using regsvr32, it means that the current user does not
have sufficient rights to edit the system registry or files in System32 direc-
tory. In this case, you need to register the components on behalf of the user
that has administrative rights. When starting regsvr32, use Run as admin-
istrator context menu command.
Chapter 3.
Installing configurations

3.1. General information on

template directories
Infobases are created from the templates. The templates are installed using a
dedicated installer created during distribution package generation in De-
signer. A template is a collection of distribution files, manifest file and ac-
companying files used to create the infobase.
To use configurations and/or infobases as templates, they must be installed
on the user computer in a particular way.-All templates must be stored in
subdirectories of a predefined directory, together with manifest files that
describe the installed templates.
The system supports multiple template directories that can be located on
local disks or on network drives. This allows to create a unified list of tem-
plate directories the users can access to install or update configurations.
By default, the template directory is called tmplts. The template directory
location depends on the operating system used:
• Windows OS: %APPDATA%\1C\1cv8\tmplts.
• Linux: ~/.1cv8/1C/1cv8/tmplts.
• macOS: ~/.1cv8/1C/1cv8/tmplts.
Users can change location of the template directory and specify links to
other directories (with arbitrary names). The documents describe operations
with the default template directory; however, the descriptions are also fully
applicable to any other template directories.
A template directory is divided into provider subdirectories- each solution
provider chooses a subdirectory based on their company name (for example,
solutions by 1C are stored in "1C" directory). Names of solution subdirecto-
ries within a provider subdirectory are not regulated. However, it is recom-
mended to choose subdirectory names based on the corresponding solution
names.
Each solution directory contains subdirectories according to versions of the
solution. For example, tmplts\1C\Accounting\1.5.7.5.
It is recommended to maintain the naming arrangement to avoid confusion
between providers.
The examples of configuration template installation are based provided for
Windows-based computers.

3.2. Installing configuration

templates
To install a configuration, you need to install its template. Download (or
otherwise obtain) an archive with the installation files. Then, uncompress
the archive on the computer where you plan to install the template. Then,
start the executable file located in a directory with the uncompressed files:
• Windows: setup.exe
• Linux: setup
• macOS: setup.app distribution package
After starting the template installer, the installation wizard will be dis-
played.

Fig. 12. Installing configurations

Select a directory to install the configuration template. The default path to
the template directory is specified as follows:
• ConfigurationTemplatesLocation parameters in file
1cestart.cfg are searched for the local template directory that the user
has a permission to write. If 1cestart.cfg contains more than one pa-
rameter with such directories, the first directory will be chosen.
• If no local directories are found, a directory will be created at the de-
fault location. This directory will be used as the default template di-
rectory. Besides, the record about this directory will be specified as
 the first ConfigurationTemplatesLocation parameter in
1cestart.cfg.
The user can change the proposed default path and choose another directo-
ry. Then, installation of the configuration template into the specified direc-
tory is attempted. If successful, the directory is specified as the first
ConfigurationTemplatesLocation parameter in 1cestart.cfg.

Fig. 13. Choosing the template directory

Then, the installer copies the configuration template file into the specified
directory.
To skip some steps of configuration template installation, run setup.exe
with /s parameter. In this case, only the startup dialog box and configura-
tion template copying progress bar will be displayed. The configuration
template directory from 1cestart.cfg file will be used. If the file does not
contain information on template directory location, the default directory will
be created. The path to the created directory will be set as default. Besides,
the record about this directory will be specified as the first
ConfigurationTemplatesLocation parameter in 1cestart.cfg.
3.3. Creating an infobase from
template
To create a specific infobase using the template installed, run 1C:Enterprise
and click Add….

Fig. 14. Adding an infobase

Then, choose an installed template and click Next > to proceed with the
installation. Creating a template tree might take a significant time.
If you choose to create the infobase from the launcher, you can use any
template version (i.e. 1C:Enterprise 8.0, 8.1, 8.2, or 8.3). If you choose to
create the infobase from the thick client, you can only use templates of the
same 1C:Enterprise version as the executable client file.

Fig. 15. Choosing a template

Then, select the infobase name and parameters. After this, the infobase will
be created.
If you are planning to restore an infobase from dump file (*.dt) or develop a
new configuration, choose Create an infobase without a configuration…
in Add infobase or folder window (see fig. 15).
 Chapter 4.
Running system
components

4.1. General information

4.1.1. On Windows
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)
Thin client (A.B.C.D)
Thick client (A.B.C.D)
Designer (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 Description
1C:Enterprise Starts the 1C:Enterprise launcher
(1cestart)
1C:Enterprise (A.B.C.D) Starts the interactive launcher (1cv8s)
Thin client (A.B.C.D) Starts 1C:Enterprise in thin client mode
Thick client (A.B.C.D) Starts 1C:Enterprise in thick client mode
Designer (A.B.C.D) Starts 1C:Enterprise in Designer mode
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 7.7 infobase Converts infobases from 1C:Enterprise 7.7
converter (A.B.C.D) format
 Item Description
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.
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 – two menu items
will be created, Thin client (8.3.12.100) and Thin client
(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.
 4.1.2. On macOS
When installing 1C: Enterprise, the following structure will be created in
the Programs menu:
1C:Enterprise 8 (folder)
1C:Enterprise
A.B.C.D (folder)
1C:Enterprise
1C:Enterprise – Thin client
1C:Enterprise – Thick client
Remove 1C:Enterprise

In the above list:

Item Purpose
1C:Enterprise Starts the 1C:Enterprise launcher
(1cestart)
A.B.C.D Version application directory with full
number A.B.C.D
1C:Enterprise Starts the interactive launcher (1cv8s)
1C:Enterprise - Thin client Starts 1C:Enterprise in thin client mode
1C:Enterprise - Thick client Starts 1C:Enterprise in thick client mode
Remove 1C:Enterprise Removes 1C:Enterprise of the version
number which is the name of the folder to
contain this menu item.
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.

4.2. Operating modes

1C:Enterprise supports the following operating modes:

Operating mode Description

Designer System configuration mode. In this mode, you can
edit data structures, update configurations, create
user lists, assign access rights to users, import and
export data.
1C:Enterprise Standard mode. You can enter and process data
(perform operations with catalogs, documents,
reports, and so on) based on the data structures
 Operating mode Description
created and configured in Designer.
Three options are available for this mode:
• Thin client - 1cv8c executable file
• Web client - no executable file (web brows-
er is used instead)
• Thick client - 1cv8 executable file
Thick client can run configurations created for
earlier 1C:Enterprise versions, as well as configu-
rations created in managed application mode.
Thin client and web client can only run configura-
tions created in managed application mode.

4.3. Starting a client application

or Designer
4.3.1. General information
There are several ways to start 1C:Enterprise:
• Launcher (1cestart) - recommended
• Interactive launcher (1cv8s)
• Executable file for the thick (1cv8) or thin (1cv8c) client of a specific
version
• Web browser (web client only)
To start 1C:Enterprise, the following configuration files are used:
• Local configuration file,- 1cestart.cfg
• Local configuration file for all users, - 1cestart.cfg
• Common configuration file - 1cescmn.cfg (except Linux).
Each method is described below in more details.

4.3.2. Launcher
4.3.2.1. General information
Location of 1cestart file:
• On Windows OS:
 32-bit application in the 64-bit OS:
%PROGRAMFILES(x86)%\1cv8\common
 Otherwise: %PROGRAMFILES%\1cv8\common
• On Linux:
  32-bit OS: /opt/1C/v8.3/i386
 64-bit OS: /opt/1C/v8.3/i386
• On macOS:
 64-bit OS: /opt/1cv8/A.B.C.D Where A.B.C.D - is the full number
of client application version. For example, for 1C:Enterprise
8.3.7.1000, 1cestart is located in /opt/1cv8/8.3.7.1000.
The launcher starts all types of client applications (thick client, thin client,
web client), as well as Designer.
The launcher can be started without parameters or with a reference to a spe-
cific infobase.
If the client computer is Windows-based:
• The launcher can also be located on a network resource (no additional
software components required). It can be used both for initial installa-
tion of 1C:Enterprise and installation of new versions. If the launcher
finds a shared configuration file in its directory, a link to this configu-
ration file is saved as a value of CommonCfgLocation parameter
of the local configuration file.
• When installing 1C:Enterprise from the launcher, you might be
prompted to restart the operating system.

4.3.2.2. Starting without parameters

If you start the launcher without parameters, the startup procedure is as fol-
lows:
• If the launcher is started from a network disk, the launcher searches
for a shared configuration file in the launcher directory. If the file is
found, the launcher reads the parameters from the file.
• The launcher searches for a local configuration file. If the file is
found, the launcher reads the parameters from the file.
• The launcher searches for installed 1C:Enterprise versions using the
data read from InstalledLocation parameters of the configura-
tion files. If this parameter is not specified in configuration files, the
launcher closes and an error message is displayed.
• The latest installed 1C:Enterprise version is determined.
• The launcher determines the latest version available for installation in
directories read from DistributiveLocation parameters of the
configuration files.
• If a later version available for installation is found, the new version is
automatically installed with parameters read from
InstallComponents parameters of the configuration files. If this
 parameter is undefined, thin client, thick client, and 1C:Enterprise
server access components are installed.
Installation can be performed if:
 User who starts the launcher is a local administrator
 User who starts the launcher is not a local administrator but has
sufficient rights to install applications (AlwaysInstallElevated
registry key)
• The interactive launcher is started from the directory of the specified
1C:Enterprise version. The /AppAutoCheckVersion parameter is
specified for the startup.

4.3.2.3. Starting with an infobase specified

If you start the launcher with an infobase name specified in/IBName pa-
rameter, the startup procedure is as follows:
• Data is read from local (1cestart.cfg) and shared (1cescmn.cfg) con-
figuration files.
• A common list of infobases is created from the local infobase list and
CommonInfoBases parameter of the configuration files.
• If the specified infobase name is not found in this list, the launcher
closes and an error message is displayed.
• If the infobase name is found, the client is started with startup parame-
ters determined by infobase properties. The following parameters are
determined by the infobase properties:
 Client type
 Version number required
 Other parameters stored in infobase properties
• The /AppAutoCheckVersion parameter is specified for the startup.

4.3.3. Interactive launcher

4.3.3.1. General information
Location of 1cv8s file:
• On Windows OS:
 32-bit application in the 64-bit OS:
%PROGRAMFILES(x86)%\1cv8\A.B.C.D\bin
 Otherwise: %PROGRAMFILES%\1cv8\A.B.C.D\bin
• On Linux:
 32-bit OS: /opt/1C/v8.3/i386
 64-bit OS: /opt/1C/v8.3/i386
• On macOS:
  64-bit OS: /opt/1cv8/A.B.C.D
Where A.B.C.D - is the full number of client application version.
The launcher starts all types of client applications (thick client, thin client,
web client), as well as Designer.
The interactive launcher uses some 1C:Enterprise components, so starting a
client application that matches version of the interactive launcher is faster
than starting an arbitrary client application. The interactive launcher can be
started both interactively and through the launcher.
After the first startup, the interactive launcher generates a common list of
infobases and writes it to ibases.v8i file. This list includes infobases for all
1C:Enterprise versions. When transferring lists of infobases for
1C:Enterprise 8.0 and 8.1, user confirmation is required. Further automatic
updates of infobase lists are not supported. During the first startup, paths to
configuration template directories from previous versions are determined
and written in ConfigurationTemplatesLocation parameter of
1cestart.cfg file.
The interactive launcher can be started without parameters or with a refer-
ence to a specific infobase.

4.3.3.2. Starting without parameters

If you start the interactive launcher without parameters, you are prompted to
select an infobase.
After the infobase is selected, the interactive launcher follows this proce-
dure:
• If the interactive launcher is started from launcher or from program
menu (with or without /AppAutoCheckVersion+ parameter):
 The 1C:Enterprise version required to start the infobase is deter-
mined and the executable files of this version are found.
 If the required 1C:Enterprise version is not installed and cannot be
installed on the computer, the launcher closes and an error mes-
sage is displayed.
 Then, the name of client to be started and other startup parameters
are determined. The client is started with the specified parameters
(including /AppAutoCheckVersion parameter) from the directory
of the required 1C:Enterprise version.
 If the version directory does not contain the required client, the
launcher closes and an error message is displayed.
• If the interactive launcher is started from the directory of a specific
version with /AppAutoCheckVersion- parameter specified:
 The executable files of the client must match 1C:Enterprise ver-
sion whose interactive launcher was started.
  If the auto client type selection is enabled for the infobase, thin cli-
ent is started and /AppAutoCheckMode parameter is passed to it.

4.3.3.3. Starting with parameters

Starting the interactive launcher with an infobase specified (using /IBName
parameter) is identical to starting the regular launcher.

4.3.4. Client for a specific

1C:Enterprise version
A specific client (thin or thick) can be started in two ways:
• By selecting the respective menu item (depends on the client operating
system used). The client application type will determine the presence
of the words “thin client” or “thick client” in the menu item name.
• By running the executable file of the required client (depends on the
client operating system used). Thus, to start the thin client of a specific
version, you must run the following file:
 On Windows OS:
 32-bit application in the 64-bit OS:
%PROGRAMFILES(x86)%\1cv8\A.B.C.D\bin\1cv8c.
 Otherwise: %PROGRAMFILES%\1cv8\A.B.C.D\bin\1cv8c.
 On Linux:
 32-bit OS: /opt/1C/v8.3/i386/1cv8c.
 64-bit OS: /opt/1C/v8.3/x86_64/1cv8c.
 On macOS:
 64-bit OS: /opt/1cv8/A.B.C.D/1cv8c.
Where A.B.C.D - is the full number of client application version.
Starting a client application with a version selection (from the list of
the installed applications) is supported when running Windows and
macOS only.
When starting a file infobase, installation of the latest version of a client
application is attempted first (using DistributiveLocation parame-
ter of the configuration files), and then the infobase is opened using the lat-
est version installed on the computer. To disable installation of new ver-
sions, use /AppAutoCheckVersion- parameter of the client application
startup command line. To enable or disable installation of the new version,
use Automated installation of the new version check box in a settings
dialog box of a launcher window or /AppAutoInstallLastVersion parame-
ter of the client application startup command line.
If the client is started without the /AppAutoCheckMode parameter, the
infobase is opened using the selected client version without picking the cli-
ent application view.

4.3.5. Determining application

bitness
NOTE. This recommendation is only applicable for computers that have
64-bit Windows installed.
Several versions of the client application with different bitness may be in-
stalled on the client computer. In some situations, you may need to specify
bitness of the client application for a specific infobase. You can specify
client bitness for each infobase if necessary.
To specify bitness of a client application, you can use (in descending priori-
ty order):
1. /AppArch startup command line parameter
2. Infobase property
3. Interactive launcher property
Use any of these methods to select one of 4 client bitness options:
1. 32 (x86) - always starts the 32-bit version of a client application. The
64-bit versions will be ignored regardless of their release date.
2. 64 (x86-64) -always starts the 64-bit version of a client application.
The 32-bit versions will be ignored regardless of their release date.
3. 32 (x86) priority - gives priority to the 32-bit version of a client ap-
plication. However, if a 64-bit version has a later release date, it will
be used instead.-
4. 64 (x64) priority - gives priority to the 64-bit version of a client ap-
plication. However, if a 32-bit version has a later release date, it will
be used instead.-
If bitness of a client application is not explicitly specified, the 32 (x86)
priority option is used by default.
See also:
• Startup window settings
• Command line parameters
• 1cestart.cfg
• 1cescmn.cfg
• *.v8i
4.3.6. Web client
4.3.6.1. General information
To run the web client, start the browser and type in an infobase URL. Make
sure the browser is set up properly. You can have an infobase opened in
several tabs of one web browser at the same time.

4.3.6.2. Language and regional settings

You can select the language of web client interface using one of the follow-
ing methods (in ascending priority):
• Preferred language settings in your web browser
• Command-line parameter L
When you choose an interface language:
• The locale language is chosen while processing the query to a re-
source that corresponds to the infobase (for example,
http://localhost/demo):
 If URL contains the L parameter, the value of this parameter is
read. If the language is not chosen after reading the parameter, the
Accept-Language header is read.
 If URL does not have any parameters, the standard HTTP header -
Accept-Language containing information on the browser's pre-
ferred languages is read.
• The language is chosen based on the locales available on the server:
 If an exact match is not found (for example, the option specifies
en_US language, which is not available), the language name is
truncated and a new search is performed (the search for en in this
example).
• If no matching language is found, the default English (en) language is
used.
 The selected language is added to the base application URL (in the
example, the result is http://localhost/demo/en), and the web
browser is automatically redirected to the new URL.
Regional settings of a web client session affecting how certain values are
displayed (for example, Day and Date) can be specified using the follow-
ing methods (in ascending priority):
• Preferred language settings in your web browser
• Command-line parameter VL
The regional settings of a session are configured in the following way:
• If the URL contains VL parameter, the regional settings matching the
locale code in this parameter are used. If the parameter contains an in-
 valid locale code, the web client closes and an error message is dis-
played.
• If URL does not have any parameters, the standard HTTP header -
Accept-Language containing information on the browser's preferred
languages is read.
NOTE. Safari web browser does not support the preferred language set-
tings. Instead, the operating system interface language is used.

4.3.6.3. Authentication with a POST request

In some situations, you may need to run 1C:Enterprise without the standard
user authentication window. This option might come in handy when you
need to performed authentication in 1C:Enterprise using a specialized form
(for example, integrated into a website), or when infobase user credentials
are stored in a separate database.
To meet these requirements, you can authenticate a web client session using
POST request to infobase resource: e1cib/start. In this case, the startup
process follows this procedure:
1. POST request is made to authenticate the client.
2. If the authentication is successful the session is created on behalf of
the user specified in the POST request.
3. The web client is started and the following parameters from POST re-
quest are passed to web client's command line:
LowClientConnectionSpeed, LaunchParameter,
LocaleCode, Zone.
4. Web client connects to the session authenticated in step 2.
TIP. Use HTTPS for authentication.
The request contains the following parameters:
Usr mandatory
User name.
Pwd optional
User Password.
Default value - empty string.
LowClientConnectionSpeed optional
Connection speed.
Values:
• on - low connection speed
 • off - normal connection speed (default)
LaunchParameter optional
Parameters that must be passed to the application (similar to C parameter of
a web client command line).
Default value - empty string.
SystemLanguage optional
Interface language.
LocaleCode optional
Interface locale.
Zone optional
Separator values.
AuthFailHandling optional
Determines the system behavior in case of authentication error. Values:
• error - returns error code - 402 and error message
• start - runs web client with 1C:Enterprise authentication request
• redirect - redirects to URL passed in AuthFailRedirectURL
parameter
The default value is- error.
AuthFailRedirectURL optional
Contains the URL to follow in case of authentication error, if the
AuthFailHandling parameter is set to redirect. This URL must be
absolute.
NOTE. The parameters passed in the request body have priority over pa-
rameters of the web client startup command line.

Example:
This HTML page illustrates a native authentication form of an infobase lo-
cated at http://localhost/demoapp.
<HTML xmlns="http://www.w3.org/1999/xhtml"><HEAD>
<META http-equiv="Content-Type" content="text/html; charset=utf-8"
/>
<BODY>
<FORM action="http://localhost/demoapp/e1cib/start" method="post">
User: <INPUT id="usr" name="usr" /><BR />
Password: <INPUT id="pwd" type="password" value="" name="pwd" />
<BR />Low speed: <INPUT id="lowclientconnectionspeed"
type="checkbox" name="lowclientconnectionspeed" /><BR />
Startup parameter: <INPUT id="launchparameter"
name="launchparameter" /><BR />
Interface language: <SELECT id="systemlanguage"
name="systemlanguage">
<OPTION value="ru" selected="">Russian</OPTION>
<OPTION value="en">English</OPTION>
</SELECT><BR />
Session locale code: <SELECT id="localecode" name="localecode">
<OPTION value="ru" selected="">Russian</OPTION>
<OPTION value="en">English</OPTION>
</SELECT><BR />
Data area: <INPUT id="zone" name="zone" />
<INPUT id="authfailhandling" type="hidden" value="error"
name="authfailhandling" />
<P><INPUT type="submit" value="OK" /> </P>
</FORM>
</BODY>
</HTML>

The following authentication form is displayed:

Fig. 16. POST request form

4.3.7. Special startup parameters

4.3.7.1. /IBName parameter
The /IBName parameter specifies the name of infobase to open. The
launcher (or the client executable file) will search for the specified infobase
in the infobase list.
If multiple infobases with this name are found, the launcher closes and an
error message is displayed.
If the infobase is found, it is opened using the specified parameters from the
launcher (or from client executable file).
NOTE. If the infobase name contains quotation marks, they must be dou-
bled when specifying the infobase name in a parameter: ""BuildItAll"" in-
fobase.

4.3.7.2. /AppAutoCheckVersion parameter

This parameter automatically selects the 1C:Enterprise version that can
open the selected infobase.
If the startup line contains /AppAutoCheckVersion parameter, the follow-
ing procedure is followed:
• The infobase version is determined. This information is obtained from
Version parameter of *.v8i file (when in file infobase mode), or from
response of the 1C:Enterprise server (when in client/server mode).
• If the version is 8.1 or 8.0, the executable files for the version are
found and started. For 1C:Enterprise 8.0, DESIGNER command-line
parameter is changed to CONFIG (for compatibility purposes).
• When using 8.2 and newer versions:
 If the full version number is specified, a search for the required
version is performed using InstalledLocation parameters of
configuration files. If the required version is not installed on the
computer, a search for the distribution package of the required ver-
sion is performed using DistributiveLocation parameters
of configuration files. If the distribution package was found, it is
installed. If not, the application closes and an error message is dis-
played.
 If partial version number is specified , the full version number is
determined from DefaultVersion parameter of configuration
files. If the full version number cannot be determined, a search for
the latest installed version (InstalledLocation parameters of
configuration files) and the latest version available for installation
(DistributiveLocation parameters of configuration files) is
performed. If the latest version available for installation is newer
than the latest installed version, it is installed.

4.3.7.3. /AppAutoCheckMode parameter

This parameter allows to automatically select and run the client application.
When the application startup line contains /AppAutoCheckMode parame-
ter, the procedure is as follows:
• The run mode for the specific user is defined.
• The default run mode of the infobase is defined.
• If a run mode does not match the client and the current user has the
right to start client applications, the client application of the same ver-
sion is restarted. Otherwise, the startup of the client application con-
tinues.

4.3.7.4. /url parameter

This parameter allows to open URL in the client application (with several
preconditions). It is available for both thin and thick client applications.
The parameter functions as follows:
• If the parameter value contains an external URL (address of an in-
fobase), a search for a running client application using this infobase
will be performed on the computer, and the client application will
open the object referenced by the URL. If the infobase is not opened
in any client application, a client application is started with the /url
command-line parameter specified.
• If the parameter value is an internal link, it is ignored and the client
application is started as usual.
Let's examine in more details how the search for a client application is per-
formed. The search procedure is as follows:
• The search for a running client application that uses the infobase with
the connection string specified in the parameter is performed. The
search is not case-sensitive regarding host computer name and in-
fobase name. DNS names are not converted into IP addresses or back.
Therefore, if the client application contains a DNS address in the con-
nection string and the external link contains an IP address, the search
will fail.
• If the client application is found and it does not have a modal or
blocking window opened, the client application is activated and the
URL received from the /url command-line parameter value is passed
to it.
• If the found client application has a modal or blocking window
opened, the client application is ignored and the search continues.
• If no client application is found, a client application is started and the
URL received from the /url command-line parameter value is passed
to it.
 • If the URL passed to the launcher or the client application only con-
tains an infobase address (for example, e1c://host/ib-name), the cli-
ent application is started and no other actions are performed.
When following an internal link, the procedure is as follows:
• The link is opened after calling the AtSystemStartup handler.
• If the client application runs in Forms in separate windows mode
and the internal link target is a navigation point, the link is opened in-
stead of opening the desktop. Otherwise, the desktop is opened and
then the target form is opened.
• In case of error, a diagnostic message is displayed and application
continues to run.
If several parameters are specified in startup command line:
• If /Execute parameter is specified, /url parameter is ignored.
• If /url parameter containing an absolute URL is specified, any in-
fobase connection parameters specified elsewhere are ignored. The
following command line parameters are ignored: /F, /S, /WS,
/IBName. For /IBConnection parameter, parts of the connection
string describing the infobase are ignored.
To follow the links, you can use external URLs in the following formats:
• e1c: - for thick and thin client
• http: or https: - for thin client only
You can use the following methods for the same effect as using /url param-
eter:
• FollowTheURL() 1C:Enterprise language method
• Dialog box accessible from the infobase list window
• Standard full-text search form (only for e1c: format)

4.3.8. Infobase connection

methods
There are several ways to locate an infobase and connect to it. To specify a
method for a specific infobase, go to the infobase adding dialog box:
• The infobase is located on a local computer or a computer in a local
network.
It is used by the thin and thick client in file mode.
When the thin client runs in file mode on the computer where the thin
client was started, a specialized environment is set. In this specialized
environment:
 Server components required for the system operation are loaded
  Application configuration is loaded
 Other actions needed for normal infobase operation are performed
Interaction between the thin client and the specialized environment is
organized over the same protocols that are used when working in cli-
ent/server mode or via the web server. Thus, the specialized environ-
ment operates as a server for the thin client. The environment is not a
separate OS process; instead, it runs as a part of the thin client pro-
cess.
• The infobase is located on the 1C:Enterprise server.
It is used by the thin and thick clients in client/server mode.
• The infobase is located on a web server.
It is used by the thin client and web client in file mode and cli-
ent/server mode.
To connect to the infobase via the web server, install and configure
the web server properly.
When connecting to the infobase via the web server, specify the URL
as an infobase connection string. For example,
http://MyServer/DemoBase.

4.3.9. Selecting an infobase

The next step of 1C:Enterprise startup is infobase selection.- Infobase se-
lection is performed in 1C:Enterprise startup window.

Fig. 17. Starting 1C:Enterprise

The Infobases list contains the list of infobases. Each item in this list
points to a directory where 1C:Enterprise infobase files (for file mode) or a
server with a server infobase (for client/server mode) are stored.
Select any infobase from this list. To select the infobase, double-click its
name.
Change, Add, and Remove buttons are used to manage the 1C:Enterprise
infobase list (or you can use shortcuts: F2, Ins, and Del).
The window is resizable. Size and location of the window are memorized
after the session ends.
When all 1C:Enterprise startup parameters are specified, click
1C:Enterprise to run 1C:Enterprise, or Designer to run Designer. Or, click
Exit to cancel the 1C:Enterprise startup.
The Go to link command is used to run the client application when the ex-
ternal URL of the application object is available. After clicking this hyper-
link, a dialog box opens where you can type in the URL and click Go to.
As an alternative to selecting an infobase from the list, you can run
1C:Enterprise by using a .v8i file and specifying the infobase parameters in
the client application startup command line. In this mode, you can use in-
fobases that are not included in the infobase list. When accessing an in-
fobase not included in the local infobase list, please remember that the con-
figuration data will not be cached for this infobase resulting in much slower
operations. To avoid this slowdown, add the infobase to the infobase list.

4.3.10. Client/server version

mismatch
When in client/server mode, the client application version might differ from
the server version. In this case, 1C:Enterprise cannot run - The client and
server versions must match exactly.

Fig. 18. Client/server version mismatch

In case of client and server version mismatch, the client application (thin or
thick client) searches for and installs the version that matches the server
version. The search for distribution packages of the client application is
performed in the following order:
• 1C:Enterprise installation directory (specified in
InstalledLocation property of 1cestart.cfg and 1cescmn.cfg
files)
• Directories specified as locations of distribution packages of new ver-
sions (DistributiveLocation property of 1cestart.cfg
and 1cescmn.cfg files, as well as CommonCfgLocation property
of 1cestart.cfg file)
• URL that is returned in the server version mismatch exception
(PublishDistributiveLocation parameter of conf.cfg file
and pubdst attribute of ws element in default.vrd file)
• Internet services used to obtain client application distribution packag-
es
Please keep in mind that:
• Thin client is only used to search for and get the distribution package
using the Internet services if you choose to connect to the infobase
over HTTP.
• If you use a client/server connection, getting the distribution package
from the URL specified in the client and server version mismatch ex-
ception is performed by the thin client.
• If the infobase list (*.v8i file) includes a version that is not available
for installation, the latest version available on the computer is used to
open the infobase. In this case, the path to distribution package of the
required client version can be received from the 1C:Enterprise server.

4.3.11. FIle mode version

mismatch
When in file mode, all client applications working with an infobase at the
same time must have the same version. The required version is determined
by the version of the client application that established first connection to
1Cv8.1CD file of the infobase. First connection is a connection that was
established when no other client applications were connected to the in-
fobase.
4.3.12. User authentication
If a list of users allowed to access the infobase (to create or edit this list, use
Designer) is available, the 1C:Enterprise. Infobase access dialog box is
displayed.

Fig. 19. User authentication

Specify a username in this dialog box:
• Click the User field and choose a name from a list, or
• Type the username in User field, if the list is very long or Show in
list option is not enabled in the user settings
If a password is set for the user, enter the password in the Password field.
Then, click OK to complete the user authentication and proceed. To close
1C:Enterprise instead, click Cancel.

4.3.13. Using certificates

4.3.13.1. General information
When sending information over public communication channels (Internet),
protecting this information from interception and spoofing is particularly
important. This chapter examines the issue of establishing secure connec-
tions in a 1C:Enterprise-based system.
Let us review the general procedure of establishing a secure connection. It
is based upon Public Key Infrastructure (PKI) that associates public keys
with respective user identities using a certification authority.
A simple example illustrates how PKI operates. Let us assume that any per-
son can contact a certificate issuer to check validity of any certificate issued
by it.
Let us further assume that Policeman meets Stranger and wants to verify
that the person he just met is indeed Stranger.- To do this, Policeman
asks Stranger to show her ID. Before showing the ID, Stranger wants to
make sure that the person in front of him is indeed Policeman. She asks
Policeman for his badge, calls the Police HQ, and asks them to check the
badge number to verify that the person in front of her - is Policeman. After
the authentication, Stranger shows her ID to Policeman. The ID has a
unique number; it also says it is issued by the Ministry of Documents. Po-
liceman contacts the Ministry of Documents and asks them to check the ID
number to verify that the person in front of him is Stranger.-
However, if Stranger travels to another country, the above authentication
algorithm will not work, because Policeman in another country knows
nothing about the Ministry of Documents. Therefore, Stranger will be
detained until another method to determine her identity is found.
Now, let us translate this into terms of PKI objects and network infrastruc-
ture. 1C:Enterprise client application acts the role of Stranger. Web serv-
er used by the client application to access the infobase acts the role of Po-
liceman. Ministry of Documents and Police HQ are Certification author-
ities. Stranger's ID and Policeman's badge are Certificates used to estab-
lish the HTTPS connection.
Let us go through the procedure once again, now in the correct terms. When
a client application attempts to connect to the web server, the client applica-
tion verifies the server's certificate. The verification is performed via certifi-
cation authority specified in the web server's certificate (provided that the
certification authority is in the list of root certification authorities on the
computer with the client application). If verification is successful, the client
application provides its client certificate to web server for verification. The
server verifies the certificate using its list of root certification authorities. If
the verification is successful, - the client application and the web server
establish a secure HTTPS connection. The client application then encrypts
data sent to the server (and decrypts data received from the server) using the
server's public key, while the server - encrypts and decrypts data using its
private key. The client application and the web server - use different private
keys, unknown to the other party.
This is a general description of establishing a secure connection. The next
section contains a more detailed description.
4.3.13.2. Methods for establishing a secure
connection
A secure connection can be established between a thin client (or a web cli-
ent) and a web server used to access the infobase. Several methods can be
used to establish a secure connection (depending on certificate availability
at client or server). These methods are described below. Please keep in mind
that all HTTPS connections are encrypted.

Server Client Description

Certificate+ Certificate- Server and client certif-
Root- Root- icates are not verified.
This is the only mode
available in versions
prior to 8.3.3.
Certificate+ Certificate- Server certificate is
Root- Root+ verified. Client certifi-
cate is not verified.
Certificate+ Certificate- Not supported.
Root+ Root-
or
Certificate-
Root+
Certificate+ Certificate+ Server certificate is not
Root+ Root- verified. Client certifi-
cate is verified.
Certificate+ Certificate+ Both client and server
Root+ Root+ certificates are verified.
Terms used in the table:
• Certificate - indicates that a certificate is available (Certificate+) or
unavailable (Certificate-):
 Server certificate for server-
 Client certificate for client-
• Root - indicates that a certificate authority (CA) list to verify the pre-
sented certificate is available (Root+) or unavailable (Root-). CA list
must allow verification of certificates presented by the client applica-
tion or web server.
When using a web client, availability of a certificate or a root certificate list
is determined by certificates installed in the certificate storage used by the
web browser.
For the thin client, the certificate (and lists of root certificates) can be speci-
fied using the startup command line parameters or infobase startup parame-
ters.

4.3.13.3. Certificate sources and formats

The following storages can be used as sources of certificates:
• System certificate storage - for macOS and Windows.
• Certificate storage in Linux is located in /etc/ssl/certs directory. All
certificates located in this directory are considered as trusted.
Some Linux distribution packages also support the following directo-
ries for root certificate storages:
 Debian, Mint, Ubuntu - /etc/ssl/certs/ca-certificates.crt
 CentOS, Fedora, RedHat - /etc/ssl/certs/ca-bundle.trusted.crt
or /etc/pki/tls/certs/ca-bundle.crt
 Alt Linux - /etc/share/ca-certificates/ca-bundle.crt
• File certificates - are for Linux, macOS, and Windows.
The following file certificate formats are supported:
• PEM (base-64 encoded X.509) - encrypted keys and certificates under
the X.509 standard in a text format. Certificate and key data is encod-
ed using base-64 encoding. Private certificate keys are protected with
passwords. This certificate file format is used by default by Apache
web server, among others. If the private key of the client certificate is
stored in a separate file, the content of this file must be added to the
client certificate file.
• P12/PFX (PKCS#12) - encrypted keys and certificates under the
PKCS#12 standard. File can be protected with a password. This is the
primary format for exporting and importing the system certificate
storages in Windows. It is used, for example, by Microsoft Internet In-
formation Services web server. Client certificate file contains its pri-
vate key.
File extension determines format of the file:
• *.p12, *.pfx - P12 file format
• *.pem - PEM file format
• The default file format is PEM

4.4. Restarting 1C:Enterprise

In some situations, the infobase cannot be opened. 1C:Enterprise notifies
the user and prompts to retry infobase connection in 60 seconds.
Typically, the infobase cannot be opened when:
 • The configuration is already opened in Designer (when started in De-
signer mode)
• Exclusive mode is enabled for the infobase
• Versions of 1C:Enterprise client and server do not match
• 1C:Enterprise server is not found
• Database server is not found
• Connections to the infobase are prohibited by the administrator
In such situations, a window with related information is displayed, and the
user is prompted to retry starting 1C:Enterprise in 1 minute or close the
1C:Enterprise launcher.

Fig. 20. Waiting for restart

After the infobase is loaded or dynamic update of the infobase in cli-
ent/server mode is performed, the user is also prompted to restart Designer.
When a critical error occurs while in 1C:Enterprise mode, the user is
prompted to restart 1C:Enterprise with the same user parameters.
Chapter 5.
Maintaining the infobase
list

5.1. General information

The 1C:Enterprise startup window includes controls for infobase list
management: adding new infobases and infobase folders, moving infobases
between folders, editing infobase properties, deleting infobases.
The list of infobases is presented as a list (by default) or a tree. You can
change the list presentation mode in 1C:Enterprise startup settings dialog
box.

Fig. 21. Starting 1C:Enterprise

5.2. Adding infobases
5.2.1. Adding a new infobase
5.2.1.1. General information
To add a new infobase to the list, click Add…. A dialog box will be dis-
played.

Fig. 22. Choosing the infobase adding mode

Select Create infobase to create an infobase based on the template, or cre-
ate an empty infobase.
Click Next>. A dialog box will be displayed.

Fig. 23. Selecting the configuration to add

If you choose to create an infobase from a template, select the source tem-
plate from the list.
Click Next> to specify the infobase name and location type.
Type in the infobase name (this name will be displayed in your infobase
list). Maximum infobase name length is 255 characters; you are free to pro-
vide a long descriptive name for your infobase. The infobase name must be
unique in the infobase list.
NOTE. Creating multiple infobases with the same database connection
string is allowed. This might be required when you need to access an in-
fobase using different clients without changing properties of the infobase.
Creating an infobase in file mode is described in the next section.

5.2.1.2. Creating an infobase in file mode

To create an infobase in file mode, select the infobase location type as
shown on fig. 24.

Fig. 24. Selecting file mode for an infobase

Specify the directory where the infobase will be located. If a non-existent
directory is specified, it will be created automatically when 1C:Enterprise
starts.

Fig. 25. Specifying infobase directory and language

Click Select button to open the standard dialog box for selecting an existing
directory.
NOTE. The directory name must meet the RFC 2396 requirements de-
scribed in section 2.4.3 Excluded US-ASCII Characters
(http://tools.ietf.org/html/rfc2396.html). The following characters are
not allowed in the directory name: <, >, #, %, ", {, }, [, ], |, \, ^, `, as
well as characters with codes 0–31 and 127.
If you choose to create an empty infobase, select the infobase language in
the Language field. Language rules will regulate storing and sorting of data
in the infobase. If you have selected a template, the language field might not
be displayed.
Click Next > to display the startup settings page.
If an empty infobase was created and configuration files are not found in the
specified directory, the window for selecting the infobase creation mode
will also be displayed when you select 1C:Enterprise run mode. If you
choose to create an infobase from a template, the infobase is created accord-
ing to the template.
The database can be created in two formats: 8.2.14 and 8.3.8. By default,
the database is created in 8.3.8 version format. To change the default for-
mat, edit the conf.cfg file. To convert the 1Cv8.1CD file between formats,
use cnvdbfl utility.
5.2.1.3. Creating an infobase in client/server
mode

5.2.1.3.1. General information

To create an infobase in client/server mode, select the type of infobase loca-
tion as shown on fig. 26.

Fig. 26. Creating an infobase on server

An infobase in client/server mode is described by two parameters:
• Address of 1C:Enterprise server cluster
• Infobase name
As noted above, address of 1C:Enterprise server cluster consists of the main
server name and number of the network port used by the cluster manager
(for example, Test_Server:1541). If the cluster manager uses the default
network port (1541), you can skip it and specify server name only. The
infobase name is unique within the 1C:Enterprise server cluster.
Fig. 27. Creating a new infobase
The infobase name in a cluster is not case-sensitive (it is also true for all
technical operations, including functionality assignment rules).
NOTE 1. If a cluster with several main servers is used, the list of the main
servers can be specified directly in the 1C:Enterprise server cluster: field
in Server1,Server2:Port,Server3 format (no spaces are allowed). This
format is convenient, for example, when creating a shared infobase list.
NOTE 2. The database name must meet the RFC 2396 requirements de-
scribed in section 2.4.3 Excluded US-ASCII Characters
(http://tools.ietf.org/html/rfc2396.html). The following characters are
not allowed in the database name: <, >, #, %, ", {, }, [, ], |, \, ^, `, as
well as characters with codes 0–31 and 127. Additional requirements may
be set by the database.
The content of data entered in this window for infobase creation purposes
depends on the DBMS used. Requirements by DBMS are provided in the
following sections.

5.2.1.3.2. Microsoft SQL Server

• DBMS type: Microsoft SQL Server.
• Database server: server name. May be based on a computer name (if
a single instance of the server is installed on the computer), or on the
name of the specific instance (if multiple server instances are installed
on the computer). For example, Server/instance.
If 1C:Enterprise server and Microsoft SQL Server are installed on one
computer and Native Client is installed for the Microsoft SQL Server,
you can use the SHARED MEMORY protocol to establish connection
between the servers. To do this, add lpc: prefix before the Microsoft
 SQL Server name. The DBMS server name will look as follows:
lpc:Server/instance.
• Database name: the database name starts with a Latin letter or the
underscore (_) character. The database name may contain Latin let-
ters, digits, as well as _ and $ characters. Maximum length of the
name is 63 characters. No spaces are allowed in the name. The data-
base name cannot match any reserved word of server database query
language.
• Database user: name of the database server user on whose behalf
1C:Enterprise accesses the database. To be able to edit structure of the
selected database, the user must be the database server administrator
(sa) or database owner. In the latter case, the user must have permis-
sion to read master database as well as full access to tempdb data-
base. Moreover, the user must have a fixed server role assigned
(processadmin or sysadmin).
IMPORTANT! When using Microsoft SQL Server 2014, you need to set
TRACE FLAG 4199 for the database in use. If TRACE FLAG is not set for
the entire database, an attempt to set it with each connection to the DBMS
on behalf of Database user. If the user does not have sufficient rights for
this action, an error will be displayed. In this case, specify a user with data-
base administrator rights (sa) as the database user or manually set TRACE
FLAG 4199 for the database.
• User password: password of the user on whose behalf the database is
accessed.
• Date offset - 0 or 2000. Determines the number of years that is add-
ed to dates when storing them to Microsoft SQL Server database and
subtracted when retrieving the dates. This parameter depends on the
specifics of date storing procedure implemented
in Microsoft SQL Server. DATETIME type used
in Microsoft SQL Server allows to store dates from January 1, 1753,
to December 31, 9999. If you need to store the dates that are earlier
than that, set Date offset to 2000. If you do not expect to store such
dates, set Date offset to 0. This value cannot be changed after the in-
fobase is created.
IMPORTANT! If an application uses accumulation registers or accounting
registers, set Date offset to 2000. If you have already set Date offset to
2000 when creating the infobase, export it into a file, create another in-
fobase with Date offset set to 2000, and import the content of the exported
infobase into it.
5.2.1.3.3. PostgreSQL
• DBMS type: PostgreSQL.
• Database server: server instance name. If specifying an IP port dif-
ferent from the default port, you need to do this using the port key-
word: <instance_name> port=<port_number>;. Example:
localhost port=6432;.
• Database name: the database name starts with a Unicode 3.2 letter, _
or @. The database name may contain Unicode 3.2 characters, as well
as _, @, and $. Maximum length of the name is 128 characters. No
spaces are allowed in the name. The database name cannot match any
reserved word of server database query language.
• Database user: name of the database server user on whose behalf
1C:Enterprise accesses the database. The user must have the
SUPERUSER privileges.

5.2.1.3.4. IBM DB2

• DBMS type: IBM DB2.
• Database server: server instance name. If any non-default database
server instances are installed on the computer, specify the name of the
installed IBM DB2 instance after a slash. Example:
computer/db2name.
• Database name: the database name must be unique within its loca-
tion. In Linux implementation of DB2 database manager, this location
is a directory, and in Windows, this is a logical drive.- The database
name starts with the Latin character. The database name may contain
Latin letters and digits. Maximum length of the name is 8 characters.
• Database user: name of the database server user on whose behalf
1C:Enterprise accesses the database. The user needs to have the
CREATEDB or SUPERUSER privileges, or to be the database owner.
Maximum length of the user name is 8 characters.
After creating a new infobase, we recommend that you configure the data-
base settings using Configuration Advisor:
• IBM DB2 v9.5:
https://www.ibm.com/support/knowledgecenter/ru/SSEPGG_9.
5.0/com.ibm.db2.luw.admin.dbobj.doc/doc/r0021350.html
• IBM DB2 v9.7:
https://www.ibm.com/support/knowledgecenter/ru/SSEPGG_9.
7.0/com.ibm.db2.luw.admin.dbobj.doc/doc/r0021350.html
• IBM DB2 v10.1:
https://www.ibm.com/support/knowledgecenter/ru/SSEPGG_10
.1.0/com.ibm.db2.luw.admin.dbobj.doc/doc/r0021350.html
 • IBM DB2 v11.1:
https://www.ibm.com/support/knowledgecenter/ru/SSEPGG_11
.1.0/com.ibm.db2.luw.admin.dbobj.doc/doc/r0021350.html

5.2.1.3.5. Oracle Database

• DBMS type: Oracle Database.
• Database server: server instance name. When creating an infobase,
specify TNS name as the database server name. Enter the database
server name in format //DB_server_name/service_name (or
similar).
• Database name: database in 1C:Enterprise corresponds to data
schema in Oracle Database. When creating a 1C:Enterprise infobase
in the Oracle Database, an infobase user and data schema are created.
Name of the data schema must only contain the Latin letters, digits,
and _ character. Name of the database starts with a Latin character.
Maximum name length is 30 characters.
• Database user: when creating a 1C:Enterprise infobase, you need to
specify the user on whose behalf the database will be accessed. Speci-
fy the user that has DBA rights (for example, SYSTEM) if the data
schema will be created automatically, or specify another user if the da-
ta schema is already created by the Oracle Database administrator.
This can be the user whose data schema is used for 1C:Enterprise,
meaning the Database name and Database user can be identical.
Notes on rights required
If an existing data schema is used, the user on whose behalf the database
will be accessed does not need the DBA right. The user may have the fol-
lowing rights instead of DBA:
• CREATE SESSION
• CREATE PROCEDURE
• CREATE TRIGGER
• CREATE SEQUENCE
• CREATE TABLE
Instead of granting each right to the user, you can assign the following roles
to them:
• CONNECT
• RESOURCE
If you plan to terminate sessions from the management console of the
1C:Enterprise server cluster, the user on whose behalf the database is ac-
cessed needs the ALTER SYSTEM access right.
 Besides, the following tablespace quotas must be granted to the user:
V81C_DATA, V81C_INDEX, V81C_LOB, V81C_INDEX_BIG (if availa-
ble).
To grant access rights, you can use the following example:
create user <username> identified "<password>";
grant create session to <username>;
grant create table to <username>;
grant create trigger to <username>;
grant create sequence to <username>;
grant create procedure to <username>;
grant alter system to <username>;

alter user <username> quota UNLIMITED on v81c_data;

alter user <username> quota UNLIMITED on v81c_index;
alter user <username> quota UNLIMITED on v81c_lob;

Notes on password expiration

When using Oracle Database 11 with the default settings, the password ex-
pires in 180 days. After the 180 day period is over, the following error
might be displayed: No database server is found. DBMS error: ORA-
28002: password will expire in 7 days. In this case, change the password
using DBMS functionality:
• Run the SQL*Plus utility
• Connect to the database
• Execute ALTER USER <UserName> IDENTIFIED BY
<Password> command
Remember that 1C:Enterprise server stores passwords in the settings file
and the next authentication attempt will use the old password. To avoid this,
you can specify the old password when executing ALTER USER command,
meaning the password will not be changed but only prolonged.
To disable password expiration, refer to documentation for the relevant ver-
sion of Oracle Database.

5.2.1.3.6. General parameters

• User password: password of the user on whose behalf the database is
accessed.
• If the Create database if none present check box is selected, the
database will be created (provided that the specified database server
does not contain the database with the specified name). If this check
box is not selected, the database will not be created.
• The value of Language (Country) parameter is selected from the list
and determines the set of regional settings that will be applied to the
infobase. Later, it can be changed in Designer. If an infobase is creat-
ed based on a template that includes the infobase dump file (*.dt), the
 Language parameter is not displayed because the language infor-
mation is already present in the infobase dump file.
• If the Disable execution of scheduled jobs check box is selected,
execution of scheduled jobs will be disabled in the created infobase. If
this check box is not selected, any scheduled jobs will be started im-
mediately upon establishing server connection.

5.2.1.3.7. Creating a database

If all parameters are specified correctly, the following actions are per-
formed:
• An attempt to connect to the specified database on the specified data-
base server using the specified user parameters is made.
• If the database is not available and Create database if none present
check box is selected, an attempt to create the database is made. When
creating an infobase in Oracle Database, the user is created with the
same username and password. When the user is created, their account
is locked. When connecting to the Oracle Database, the 1C:Enterprise
server uses username and password specified during creation of the in-
fobase.
• If an existing 1C:Enterprise infobase is found in the database, an at-
tempt to connect to this infobase is made. If no such infobase is de-
tected, a new infobase is created. If a template was specified in the
new infobase creation parameters, the template will be applied during
initialization.

5.2.1.3.8. Simultaneous use of a database by several

infobases
When creating an infobase on the 1C:Enterprise server, the same database
can be assigned for several infobases. However, the cluster internal data
structure implies that one set of internal data corresponds to one database.
Simultaneous use of several internal data instances breaks their logical in-
tegrity.
When several infobases use the same database simultaneously, the follow-
ing is disabled:
• Infobase locks (in particular, running two instances of Designer may
lead to irreparable configuration damage)
• Object locks
• Lock manager
• Getting timestamps in real time
• Other mechanisms that use separated data stored by the cluster man-
ager
Simultaneous data modification in such conditions might lead to irreparable
data damage. Data read from the database might also be unreliable.
That is why it is not recommended that you use one database with several
infobases.
At the same time, simultaneous connection of several infobases to one data-
base might be useful for configuration debugging and error analysis in con-
figuration and platform. That is why connecting several infobases to one
database is not directly prohibited in 1C:Enterprise. However, when you use
this feature, use the following precautions:
• Parallel editing of a database from several infobases might lead to ir-
reparable database damage.
• When several infobase read the same data simultaneously, results
might be unreliable for all infobases if at least one infobase modifies
or locks the data in any way.

5.2.2. Adding existing infobases

5.2.2.1. General information
If you choose to add an existing infobase, any infobase located on a local
computer, in local network, on 1C:Enterprise server, or web server can be
added to the list (only for thin client and web client).

Fig. 28. Adding existing infobases

After clicking Next > the dialog box for selecting a name, a location type
and infobase parameters will be displayed.
Type in the infobase name (this name will be displayed in your infobase
list). Maximum infobase name length is 255 characters; you are free to pro-
vide a long descriptive name for your infobase.

Fig. 29. Configuring infobase parameters

Besides specifying the infobase name, you need to select and specify pa-
rameters for accessing the infobase.
You can select the infobase type manually or have it automatically detected
from your clipboard content. If the clipboard contains a path to infobase
directory (paths to infobases in file mode must not include quotation marks)
or URL for web server access, 1C:Enterprise attempts to automatically
identify the infobase location type as soon as the infobase adding dialog box
is opened. If the attempt is successful, the Select infobase location type
radio button will be set and the infobase parameters will be filled. The same
applies if you paste the content of the clipboard to the infobase name field
and press Tab.
5.2.2.2. File mode
In the dialog box, choose This computer or LAN computer infobase loca-
tion type. Then, choose the directory where the infobase is located. If a non-
existent directory is specified, it will be created automatically when
1C:Enterprise starts.

Fig. 30. File infobase

Click Select button to open the standard dialog box for choosing the in-
fobase directory.
NOTE. The directory name must meet the RFC 2396 requirements de-
scribed in section 2.4.3 Excluded US-ASCII Characters
(http://tools.ietf.org/html/rfc2396.html). The following characters are
not allowed in the directory name: <, >, #, %, ", {, }, [, ], |, \, ^, `, as
well as characters with codes 0–31 and 127.
5.2.2.3. Client/server mode
In the infobase adding dialog box, choose 1C:Enterprise server infobase
location type.

Fig. 31. Adding existing infobases

Fill the following data in the fields:
• Address of the 1C: Enterprise server cluster. The cluster address is the
cluster's main server address with the number of cluster manager pro-
cess network port (by default, 1541) specified.
• Infobase name
NOTE 1. If the 1C:Enterprise main server address is specified as an IP ad-
dress in dot notation, adding it to the DNS (hosts) list is not required.
NOTE 2. If a cluster with several main servers is used, the list of the main
servers can be specified directly in the 1C:Enterprise server cluster: field
as Server1,Server2:Port,Server3 (no spaces are allowed). This format is
convenient, for example, when creating a shared infobase list.
NOTE 3. The database name must meet the RFC 2396 requirements de-
scribed in section 2.4.3 Excluded US-ASCII Characters
(http://tools.ietf.org/html/rfc2396.html). The following characters are
not allowed in the database name: <, >, #, %, ", {, }, [, ], |, \, ^, `, as well
as characters with codes 0–31 and 127. Additional requirements may be set
by the database.
No checks on whether the infobase with the specified parameters exists are
made.
If the infobase with the specified parameters is not found during Designer
startup, the user will be prompted to create a new infobase. If the user con-
firms, Designer displays the Create an infobase or folder form.

Fig. 32. Infobase parameters

In this form, you need to enter the parameters for creating new infobase.

5.2.2.4. Web server-based infobase

To add an existing infobase located on web server, run the 1C:Enterprise
thin client (1cv8c file).
In a dialog box for adding the infobase, choose Web server infobase loca-
tion type.

Fig. 33. Adding an infobase to web server

If you need to specify additional parameters for web server connection
(proxy server parameters and web server authentication method), click Ad-
ditional… hyperlink under the Infobase address line.

Fig. 34. Parameters for web server connection

Select web server authentication method parameter allows you to select
the authentication method:
• Select automatically - attempts to log on using operating system au-
thentication. If the attempt is not successful, prompts for username
and password.
• Prompt for username and password - always prompts for
username/password for web server authentication.
5.2.3. Infobase startup
parameters
On this page, you can specify the infobase startup parameters.

Fig. 35. Infobase startup parameters

Authentication method can take the following values:
• Select automatically - attempts to log on using operating system au-
thentication. - If the attempt is not successful, prompts for username
and password.
• Prompt for username and password - always prompts for
username and password for authentication.
The Connection speed parameter determines the expected speed of the
infobase connection or 1C:Enterprise server connection. The parameter can
take values:
• Select on startup - select connection speed manually every time you
start the infobase using the Slow connection check box in
the 1C:Enterprise startup window. If you select another op-
tion (Normal or Low), the state of the Slow connection check box in
the 1C:Enterprise startup window cannot be changed and it displays
the option selected in infobase properties.
• Normal - the default mode. Normal operation.
• Low - low connection speed. For more information on using
1C:Enterprise 8.3 in this mode, see 1C:Enterprise 8.3 Developer
Guide.
The state of Slow connection check box in 1C:Enterprise startup dialog
box of the thin client can be changed if the infobase list has at least one in-
fobase with 1C:Enterprise version 8.2 and above and Connection speed
parameter set to Select on startup. In other situations, the check box dis-
plays the connection speed specified in infobase properties and its state
cannot be changed.
In the Additional startup options field, specify command-line options for
the executable file. For more information about command-line parameters,
see 1C:Enterprise help (1C:Enterprise 8 startup and startup parameters
section). The L and VL parameters specified in this field will only be effec-
tive if the infobase was started using the interactive launcher.
The Default run mode determines the client type used for infobase access.
Select one of the following:
• Select automatically - in this mode the client application view is de-
fined based on the properties of Default run mode and Run mode
user properties.
• Thin client - the thin client will be used for startup.
• Web client - the web client will be used for startup. This client type is
only available if the infobase is accessed via web server.
• Thick client - the thick client will be used for startup. This type of cli-
ent is unavailable if the infobase is accessed via web server.
Field 1C:Enterprise version: allows to specify the
1C:Enterprise version that you want to use for infobase access. Moreover,
you can set it to 8.1 or 8.0. In this case, 1C:Enterprise 8.1 or 8.0 installed
on the computer will be used to access the infobase. There's no need to
specify the version then.
The Bitness field specifies bitness of client application to use with this in-
fobase. This field is only available on the 64-bit version of Windows.
5.2.4. Certificate settings
If you choose to add an infobase to web server and HTTPS protocol is spec-
ified in the Infobase address field (for example, instead of
http://localhost/DemoMA, the address is https://localhost/DemoMA),
then when clicking Additional…, the page with certificate settings will be-
come available together with additional web server access parameters.

Fig. 36. Certificate settings (Windows)

On this page, you can specify the source location for client certificates and
verification method for server certificates. Let us review these parameter
groups in detail:
• Select client certificate - chooses the location of a client certificate:
 Do not provide certificate - only connects to web servers that do
not require a client certificate.
 Certificate file - allows to choose the file with client certificate
and its private key. If the file is password-protected, the user will
be prompted to enter the password when connecting.
 Windows certificate/Linux certificate/macOS certificate - client
certificate is received from the system certificate storage in the
operating system used (Windows or macOS) or dedicated Linux
directory. If multiple client certificates are available for connec-
tion, you can choose to:
 Select last used certificate - the user is prompted to select a
certificate using the system certificate selection dialog box.
Further, this certificate will be selected automatically.
 Always prompt to select certificate - the user is prompted to
select a certificate using the system certificate selection dialog
box regardless of whether any certificates were selected earlier.
 Further, the selected certificate can be used automatically with
the Select last used certificate option.
 Select certificate automatically - a suitable certificate is se-
lected and used automatically. The certificate selection dialog
box is not displayed.
• Select server certificate validation method - indicates how to veri-
fy the certificates provided by the server:
 Do not validate server certificates - the web server certificate is
not verified and the certification authority's (CA) certificates are
not used.
 CA certificate file - allows to choose a file where CA certificates
are stored. If the file is password-protected, the user will be
prompted to enter the password when connecting.
 Windows certificate storage/Linux certificate storage/macOS
certificate storage - specifies that CA certificates need to be re-
ceived from the certificate storage in the operating system used
(Windows or macOS) or dedicated Linux directory.

5.3. Editing infobases

To change the name or directory of an infobase from the list, select the in-
fobase name and click Edit. The infobase properties are edited in a dialog
box similar to the dialog box used to add an existing infobase.

5.4. Deleting infobases from list

To delete an infobase from the infobase list, select its name in the list and
click Delete. The selected infobase will be deleted from the list.
NOTE. This only deletes the infobase entry from the list; the infobase itself
is not deleted from hard drive or 1C:Enterprise server. This is done manual-
ly.
When removing the infobase from the list, the infobase service directories
located in the following directories are also deleted:
• Windows: %APPDATA%\1C\1cv8
and %LOCALAPPDATA%\1C\1cv8.
• Linux: ~/.1cv8/1C/1cv8.
• macOS: ~/.1cv8/1C/1cv8.
5.5. Order of infobases in the
list
If sorting by name is not enabled in the startup dialog box settings (see sec-
tion below), you can change the order of infobases in the list using the
mouse or context menu commands.
To move an infobase up or down in the list, click and drag it up or down. As
you drag the infobase, an outline of its new position is displayed.
Then, release the mouse button.
Alternately, you can change the infobase list order using the context menu
commands: Move up (Ctrl + Shift + Up arrow) and Move down
(Ctrl + Shift + Down arrow). When you attempts to move up an infobase
at the top of the list, it is moved to the bottom of the list; and vice versa.
You can also use the Sort ascending and Sort descending commands to
order the infobase list.
If tree view is enabled in startup dialog box settings, please be informed that
while dragging an infobase:
• If the outline is on a folder, the dragged infobase will be placed at the
end of that folder.
• To place an infobase (or folder) to a specific position within a folder,
the folder must be expanded first.

5.6. Maintaining the

hierarchical infobase list
This section describes operations for creating and reorganizing the infobase
list with tree view.

5.6.1. Adding an infobase folder

It is recommended to create an infobase list when you work with multiple
infobases of the same type or when you work with so many infobases it is
hard to find the one you need.
Folders can be created if the Display as a tree mode is enabled in startup
dialog box settings.
When this mode is enabled, the infobase list is displayed as a tree with the
Infobases root folder. This folder cannot be changed or deleted.
To add an infobase folder, select the folder in which you would like to cre-
ate the new folder, and click Add. This opens the adding mode selection
dialog box.

Fig. 37. Creating a new folder

Select the Create a new folder mode and click Next >.

Fig. 38. New folder name

Specify the folder name (the / character is not allowed) and click Finish.
The created folder is placed in the specified infobase folder (at the end of
the folder if sorting by name is not enabled).
5.6.2. Editing infobase folders
To change the infobase folder name, select the folder in the tree and click
Change. The Edit folder window will be displayed that contains the select-
ed infobase folder name.

Fig. 39. Editing a folder

Enter the new folder name (the / character is not allowed) and click Finish.

5.6.3. Deleting infobase folders

To delete an infobase folder from the list, select it in the list and click Re-
move. The selected folder will be deleted from the infobase list.
IMPORTANT! All infobases in the folder will be also deleted from the
list.
5.7. Startup window settings
Click Settings in the startup dialog box. This opens the startup settings dia-
log box.

Fig. 40. Startup settings

This dialog box is used to change settings from the interactive launcher.
When changing settings from the thick client (1cv8), the settings window
will not include the Versions used field; when changing settings from the
thin client (1cv8c), the Configuration and update templates directories
field will also be excluded.
If the Display as a tree check box is selected, the infobase list will be dis-
played as a tree.
If the Sort by name check box is selected, the infobase list is sorted by
name.
If the Show recently selected infobases check box is infobase, you can
specify the number of recently used infobases in the Remember recently
selected infobases field.
The list of recently used infobases is displayed at the top of the infobase list.
Names of the recently used infobases are highlighted in bold font. This list
is displayed in historical order, meaning that the infobase used most recent-
ly is at the top of the list.- List sorting by name does not affect the order of
recently used infobases. You cannot move these infobases up or down. To
edit or deleting an infobase, click it in the infobase list.
The list of directories with configuration and update templates is specified
in the Configuration template and update directories field. For exam-
ple, this list might include a directory containing templates for the entire
company, or a local template directory.
NOTE. The Configuration template and update directories field is una-
vailable in the thin client.
The Lists of shared infobases field contains editable lists of shared in-
fobases. When starting 1C:Enterprise, infobases from the shared infobase
lists are automatically added to the general infobase list. If the local config-
uration file has the CommonCfgLocation parameter set, the infobases
specified in CommonInfoBases (if any) parameter of the shared configu-
ration file (1cescmn.cfg) will be added to the main infobase list. Infobases
obtained from Internet services are also added to the list.
Paths to the template directory or shared infobase list are displayed in set-
tings window only when these paths are specified in 1cestart.cfg local con-
figuration file parameters. If these paths are specified in the shared configu-
ration file (1cescmn.cfg, for description see 369), they are not displayed in
the settings dialog box.
The Used versions field contains the detailed list of 1C:Enterprise versions
available. This list is used when the user needs to work with the infobases
using a 1C:Enterprise version that is different from the latest version in-
stalled on a computer. For example, when matching string 8.3=8.3.3.100
is specified, the infobase properties will display 8.3 version, and 8.3.3.100
version will be used to open the infobase instead of the latest version. The
Bitness column specifies bitness of a client application that will be started.
The Use a hardware license (dongle) parameter is used when searching
for the hardware license during the client application startup. Changes made
to this parameter take effect at the beginning of the next session, changing
the value of UseHwLicenses parameter in 1cestart.cfg file.
NOTE. When you modify the startup settings, the CommonInfoBases,
ConfigurationTemplatesLocation, DefaultVersion, and
UseHwLicenses parameters only change in local configuration file for
the user on whose behalf the startup settings are modified.
The Automated installation of the new version parameter controls auto
installation of new versions. Changing this check box affects
AppAutoInstallLastVersion parameter in the 1cestart.cfg file.
5.8. Shared infobase lists
Shared infobases lists stored in files with v8i extension. They contain links
to shared infobases.
Location of shared infobase lists is specified in the CommonInfoBases
parameter of configuration files. Shared infobase lists have the same format
as the main infobase list.
Shared infobase list can be generated manually or by saving existing in-
fobase links to a file. To save an infobase link, execute the Save reference
into file context menu command in the infobase list.
Shared infobase list can be used to start the 1C:Enterprise. When opening a
file with the v8i extension, 1C:Enterprise will be started and the startup dia-
log box will contain the links from this shared infobase list.
TIP. We recommend to specify Normal connection speed in shared in-
fobase lists (provided there are no remote users and the infobase is not lo-
cated on a remote server) to ensure that Slow connection check box will
not be displayed.
You can also specify an Internet service address that will provide a shared
infobase list when the shared infobase list from the local network is una-
vailable. For example, an infobase can be used over the Internet (connection
via web server).
When the shared infobase list is obtained for the first time, this list is placed
at the root of the list or within a folder in this list. When the list is reob-
tained: Information about the infobase is updated but location of the shared
infobase list in the general list does not change. If the user moves the shared
infobase to another folder in the list and reobtains the shared infobase list,
position of the shared infobase in the list will not change.
Chapter 6.
Infobase administration

6.1. General information

When working with 1C:Enterprise, you may need to perform system admin-
istration duties, such as:
• Maintaining the user list
• Assigning user rights
• Creating backups
• Generating technological log for error analysis
Designer includes a variety of administrative tools designed to perform the
above tasks.
1C:Enterprise can create lists of users that are allowed to log on. This list is
used for user authorization upon logon. It should be noted that
1C:Enterprise user list is not a part of configuration: each company where
1C:Enterprise is being used needs to create it manually.
Logon password can be set for any user. The password is used to verify user
rights to operate 1C:Enterprise.
Creating backups is another example of a crucial administrative task. To
ensure data recovery with minimum losses in case of database damage, the
backup procedure must be performed on a regular basis. The greater
amount of data changed daily, the more frequent backup required.
This chapter covers the 1C:Enterprise administration activities that can be
performed in Designer.
6.2. Maintaining user list
6.2.1. General information
To display the list of users, click Administration- Users.

Fig. 41. User list

The window with the user list includes a toolbar and a field with two col-
umns:
• The Name column contains the list of users allowed to log on to
1C:Enterprise 8.
• The Full name column contains full names of the users.
Users with access passwords are marked with the lock icons (for example,
Seller in fig. 41).
Users with no role or authentication defined are marked with question mark
icons (for example, Sales manager in fig. 41).
In the Actions menu, you can add or delete users, configure the list appear-
ance (filters, column content and order, sorting), or export the list to a
spreadsheet or text document.

6.2.2. Adding new users

To add a new user, click Actions - Add in User list window. The window
with user parameters will be displayed.
On the Main tab, the name and full name of the user are displayed.

Fig. 42. New user

We do not recommend using the : character in user names. Uniqueness of
infobase users is determined by a combination of three fields: name, full
name, and OS username (if OS authentication is enabled). Uniqueness is
determined by the first 64 characters of the Name field, the first 128 charac-
ters of the Full name field, and the first 128 characters of the User field
(provided that OS authentication is enabled). -- It is recommended not to
exceed the 64 characters limit for the Name field.

TIP. It is recommended to give meaningful names to users, based on their

last names, job positions, professional functions, and so on. Later, these
names will be used by the employers to log on to 1C:Enterprise.
The authentication method must be set for the user.
NOTE. Client applications for Linux and macOS do not support OS authen-
tication. A thick client running under any supported operating system does
not support OpenID authentication (in any case).
Each Authentication… check box (1C:Enterprise authentication, OS
authentication, OpenID authentication) indicates whether a correspond-
ing authentication method is enabled. These check boxes do not affect the
order of authentication attempts. The OpenID authentication means any of
the following authentication types supported by the 1C:Enterprise: OpenID
itself, OpenID Connect, Unified System for Identification and Authentica-
tion (USIA). When assigning authentication types, please remember:
• When no Authentication… check boxes are selected, the user will not
be able to log on to the application.
 • To attempt authentication using the OpenID protocol, the infobase
publication on a web server must be configured in a specific way.
• The user will not be able to log on to the application if the user per-
forms OS or OpenID authentication but the check box allowing this
type of authentication is cleared.
• To disable OS or OpenID authentication, you can also use the client
application startup command-line parameters.
IMPORTANT! There must be at least one user in the system that has ad-
ministrative rights and allows 1C:Enterprise authentication.
If the User cannot change password check box is selected, the user can-
not change their password (this option only applies to 1C:Enterprise authen-
tication).
If the Show in list check box is selected, the user is displayed in the user
selection list when connecting to the 1C:Enterprise infobase. If
1C:Enterprise authentication is disabled for the user, the Show in list check
box becomes unavailable and the user is not displayed in the user selection
list when connecting to the infobase.
TIP. If the infobase is published on a web server accessible from the Inter-
net or the infobase has a large number of users, it is recommended that you
clear the Show in list check box for all users. This recommendation is par-
ticularly important for users that have infobase administration rights.
The Unsafe operation protection check box specifies whether protection
from unsafe operations is enabled for this user.
On the Other tab, available roles and language are displayed. If multiple
roles are defined in the configuration, you can assign several roles to the
user. Besides, you can select the 1C:Enterprise run mode for the user. When
using Auto value, the run mode specified in the Main run mode configura-
tion property is used. When a user requires a special run mode, you can as-
sign it here. For example, when a user works in managed application mode,
You need to set the Run mode field to Managed application.

Fig. 43. Other parameters of a new user

You are not required to fill in all fields In user properties editing field- this
can be done later.
If the system has user separation enabled), the data separation tab is also
displayed in the user parameters.

Fig. 44. Data separation

All available separators (not all common attributes) are displayed on this
tab. A value and usage during authentication can be specified for each sepa-
rator. If the check box to the left of the separator name is selected, the value
of the selected separator applies to the current user. The value itself is speci-
fied in the field to the right of the separator name. If the value is set for the
user (not only value but a usage flag as well), changing the User separa-
tion and Authentication separation separator properties affects visibility
and availability of this user for selection and authentication purposes.

6.2.3. Cloning users

Cloning an existing user is a fast and easy method of creating a new user.
When you clone a user you do not have to create a user from scratch - you
simply copy a user and then edit their properties.
To clone a user, select the user from the user list and click Actions - Clone.
Name of the user might be transformed during cloning, for uniqueness rea-
sons. All other properties of the cloned user are identical to the source user
(except the password).

6.2.4. Setting password

To avoid logging on to 1C:Enterprise under another user's name, a personal
password can be created for each user allowed to log on. Just like username,
the password confirms user's right to access 1C:Enterprise.
Enter the password in the password entry field. A password can contain
alphanumeric characters. Password length must not exceed 255 characters.
The password you enter is displayed as a string of asterisks.
In the Confirm password field, enter the password again. If the passwords
do not match, the following warning is displayed once you click OK: Pass-
word and password confirmation do not match. The password is not
changed.
To cancel the password change, click Cancel. Please understand that click-
ing Cancel cancels both the password change and any other changes you
might have made in this dialog box.
IMPORTANT! The assigned password is not viewable, so you need to pay
attention and memorize the entered password.
If a user forgets a password, you need to assign a new password to them.
Users with passwords are marked with the lock icon in the user list (for lock
icon example, - see Seller in fig. 41).

6.2.5. Deleting users

To delete a user, select them in the user list and click Actions- Delete in
User list window.
To confirm user deletion, click Yes when prompted.

6.2.6. Editing user properties

To edit user parameters, click Administration - Users in the Designer
menu. Select the user in the list and click Actions - Change in the User list
window.
In the User window, you can change parameters of the selected user.

6.2.7. Applying filters

To streamline viewing of the user list, you can use filters. In the user list,
click Actions - Set filter…

Fig. 45. Applying filters

The list can be filtered based on the role, language, run mode, or user au-
thentication type. If separators (common attributes with Data separation
property set to Separate) are enabled, you can also filter users by separa-
tors.
6.2.8. Authentication types
6.2.8.1. General information
Authentication - is a procedure that verifies whether the provided ID
(name) belongs to the user. 1C:Enterprise supports multiple authentication
types, which are described in further sections.

6.2.8.2. 1C:Enterprise authentication

The user can be authenticated by 1C:Enterprise by providing their username
and password (typed in authentication dialog box, passed as command-line
parameters, or passed in the infobase connection string for an external con-
nection or automation server). In this case, user name and password verifi-
cation is performed by 1C:Enterprise.

6.2.8.3. OS authentication
The user can be authenticated implicitly through the operating system func-
tionality. To enable this authentication type, you need to match the
1C:Enterprise user to an operating system user. On startup, 1C:Enterprise
prompts the operating system for information on the currently authenticated
OS user. For this purpose, Windows uses SSPI interface and Linux uses
GSS-API.- Then the match between the operating system user and
1C:Enterprise user is verified. If the matching user is found - 1C:Enterprise
user is authenticated and the authentication dialog box is not displayed.
NOTE 1. Client applications for Linux or macOS do not support operating
system authentication.
NOTE 2. Operating system authentication is not supported if the client ap-
plication connects to the infobase using the Apache web server on Win-
dows.
NOTE 3. To ensure stable OS authentication in Windows for web client or
thin client connection via web server, add the infobase address to the list of
reliable websites using the web browser properties dialog box.
The operating system user is described in the following format:
\\domain_name\ username. The username contains Latin letters on-
ly. The format of domain name and username may depend on domain con-
troller settings and its account settings. Correct name of the operating sys-
tem user can be found in the records of CONN event in the technological log.
Look for Txt property that starts with Srvr: DstUserName2:. For exam-
ple, 30:30.551013-
0,CONN,2,process=rmngr,OSThread=24204,t:clientID=3,Txt=Srvr:
DstUserName2: d1.d2\user1(d1.d2\user1) event means that the OS user
name in the infobase user description must be as follows: \\d1.d2\user1.
When forced 1C:Enterprise authentication is required, specify /WA- com-
mand-line parameter in the startup command line of the client application.
The /WA+ command-line parameter forces OS authentication (enabled by
default).

6.2.8.4. OpenID authentication

OpenID (http://openid.net/) -protocol allows the user to authenticate in
many unrelated resources, systems, and so on, using the single account.
1C:Enterprise uses a protocol based on OpenID 2.0 under a Direct Identity
model.
NOTE. This authentication method cannot be applied to web services pub-
lished from 1C:Enterprise.
The general procedure is as follows:
• The user attempts to log on to 1C:Enterprise.
• 1C:Enterprise identifies that OpenID authentication is enabled for the
infobase (using the default.vrd publication file).
• An authentication request is sent to OpenID provider. The OpenID
provider must be able to receive requests from the address of the in-
fobase publication.
• If an interactive action is needed (for example, the first authentication
for this user ID is performed, or the user authentication data has ex-
pired), the provider informs 1C:Enterprise that username and pass-
word are required. 1C:Enterprise performs the interactive action and
returns the requested data to the OpenID provider.
User authentication data is stored in cookie files located in web
browser storage. Thin client uses own storage.
• If the provider authenticates the user, a flag is returned to
1C:Enterprise indicating that the user is authenticated.
OpenID authentication only works when the infobase is accessed over
HTTP or HTTPS. This means that OpenID authentication is only available
for web client, mobile client, and thin client connected to the infobase via
the web server. During OpenID authentication, cross-domain requests may
occur when using the thin client or Mozilla Firefox, Google Chrome, Safari,
Microsoft Internet Explorer 8 and 9 browsers. In Mi-
crosoft Internet Explorer 6.0 and 7, the user is prompted for confirmation
after entering username and password. If the user confirms operation, the
authentication procedure continues.- Otherwise, the user is prompted to
enter username and password again.
An OpenID provider can be a 1C:Enterprise infobase published on a server
in a special way, or an information system that has OpenID Authentication
2.0 and extension of this protocol implemented on the 1C:Enterprise plat-
form. The address of the OpenID provider is specified in default.vrd file
(<rely> element) when publishing an infobase that is an OpenID provid-
er's client.
It is important to understand that the key field used to match the
1C:Enterprise infobase user and OpenID provider user is a value specified
in the Name property of the infobase user. In other words, a user is only
able to log on to the infobase if the Name property in the infobase contains
an ID returned by the OpenID provider. For description of the returned cer-
tificate, refer to documentation of the OpenID provider used.
User password is set at the OpenID provider. If the OpenID provider is an
1C:Enterprise infobase, the password is set in this infobase. The password
set in the infobase that operates as the OpenID provider's client is ignored
during OpenID authentication. If a third-party OpenID provider is used, the
password is set by this provider. After the OpenID provider's user password
is changed in the user storage, the 1C:Enterprise follows the following
rules:
• The user is considered authenticated in any currently running sessions
until these sessions are terminated
• When creating a new session, the user is prompted for the password
even if the user authentication data has not expired yet.
When forced OpenID authentication is required, specify /OIDA+ com-
mand-line parameter (enabled by default) in the startup command line of the
client application. The /OIDA- command-line parameter is intended to
force disable OpenID authentication.
See also:
• OpenID Authentication 2.0 (see http://openid.net/specs/openid-
authentication-2_0.html).

6.2.8.5. OpenID Connect authentication

OpenID Connect (http://openid.net/connect/) -protocol is an expansion
of the OAuth 2.0 authorization protocol. OpenID Connect allows
1C:Enterprise to verify user identities based on the authentication by the
third-party provider. This protocol is applicable when using thin, mobile or
web client. 1C:Enterprise cannot be the OpenID Connect provider. Third-
party providers are used for this purpose. OpenID Connect protocol support
also means the potion to use the Unified System for Identification and Au-
thentication (USIA).
To match 1C:Enterprise users and authentication provider users, email mes-
sages are used. The OpenID Connect provider provides email services for
1C:Enterprise. The user email address must be specified in the Name prop-
erty of the infobase user.
So far as a mobile client is concerned, authentication is provided using a
web browser supported by a mobile device:
• OS Android: Google Chrome.
 • OS iOS: 9.0 or later.
If your mobile device is not in compliance with the aforesaid requirements,
repeated authentication is required on the side of OpenID Connect provider
in a mobile client. To start forced authentication when you log in next time,
run Log out command in the mobile client.

6.2.8.6. Second factor authentication

6.2.8.6.1. General information

The platform can perform user authentication independently, or it can use
the results of authentication performed by another resource that it trusts
(operating system or OpenID provider). In any case, the user enters a
username and a password. If the correct username/password pair is entered,
the platform considers that the user is identified and grants them access to
the application.
This conventional scheme is simple and convenient, but has one significant
drawback. You need to remember the password, and it must be short and
simple for that. But such password is easy to hack. For a password to be
difficult to hack, it must be long and complex. But such password is not
easy to remember. For this reason, in reality it all comes down to people
using simple and the same passwords for different resources.
Two-factor authentication - is a method that allows, on the one hand, to
complicate hackers' access to other people's data, and on the other hand, - it
is a solution that allows mitigating the disadvantages of classical password
protection to some extent.
Two-factor authentication requires the user to have two of the three possible
types of authentication data:
• Something they know and remember: This is the username and pass-
word.
• Something they own. This can be a user cell phone or email.
• Something inherent to them. In this case, some physical feature of the
user may be used: a fingerprint, a portrait, an iris pattern.
The point of two-factor authentication is that the user must double confirm
their identity - in order to gain access to the application solution. Moreover,
they need to do that in different ways. For example, entering the
username/password (and this will be the first authentication factor), and
then enter the code sent to their cell phone (and this will be the second au-
thentication factor).
The verification of the first authentication factor is performed by
1C:Enterprise platform itself, and a third-party service, which is called the
second factor provider, is used to process the second authentication factor.
Second factor provider (we may use "provider" term in this section) - is an
HTTP service that provides a software interface for performing certain ac-
tions. The provider of the second factor can be, for example, the
1C:Enterprise infobase, where a set of HTTP services that allow forwarding
messages or performing authentication, is implemented. It can be a third-
party service that sends SMS or e-mail messages, it can be a service that
generates codes of the second authentication factor or a service that inter-
acts with the user through its own mobile application, etc. All that matters is
that the provider can be accessed via HTTP requests.
Two-factor authentication can be used in any 1C: Enterprise infobase ver-
sion and for any client application.

6.2.8.6.2. Options for using the second factor

So, the standard 1C:Enterprise authentication (the first factor) is as follows:
1. The user starts the client application. The client application prompts
the user to input the first authentication factor - i.e. login and pass-
word. The user inputs these, and the client application sends these to
the server.
2. The server checks the username and password for correctness.
3. If the data entered is correct, the server checks that the user needs only
one authentication factor to use the application. If the second factor is
not used, it is considered that the user is fully identified and can start
operations. This is a common authentication scenario that exists in the
platform now.
If two-factor authentication is set for the user, then the first two steps are
performed, as before - i.e. entering the login/password and checking these
data for 1C:Enterprise servers.
The use of the second factor can be performed in two ways:
1. The 1C:Enterprise server itself generates a second factor and checks if
the user correctly entered the value of this factor. The provider only
performs the transport function - i.e. transmitting of the second factor
value to the user. In this case both the 1C:Enterprise server and the us-
er know using which channel the value of the second factor will be
transmitted.
The procedure is as follows:
 The 1C:Enterprise server informs the application that the user
needs to specify a second authentication factor.
 The application displays the second factor input form.
 The 1C:Enterprise server generates and sends the value of the sec-
ond factor (for example, a certain number) to the user, which the
user must enter in the form opened by the application. The second
factor value can be sent to the user by e-mail or SMS.
 The user receives the second factor data and enters them in the dia-
log opened by the application. The application sends the second
factor data to 1C:Enterprise server.
  The 1C: Enterprise server verifies that the entered data matches the
data generated and sent to the user be the server.
 If the values of the second factor transmitted by the application
and generated by the 1C: Enterprise server match - the user is
identified and is granted access to the application.
2. 1C:Enterprise server uses a third-party service that sends the result of
the second factor application by the user to the 1C:Enterprise server.
In this case, the 1C:Enterprise server has no information of the second
factor type used. A method for transmitting the second factor is also
determined by the user selected second factor provider. 1C:Enterprise
server only has information that there is a trusted service, which, in
response to the requirement to use a second authentication factor, in-
forms - where the second factor application was successful or not.
The procedure is as follows:
 The 1C:Enterprise server informs the client application that the us-
er must authenticate the second factor on the provider side.
 The client application shows the form to the user, in which the user
must execute a certain action after the user is authenticated by the
provider of the second factor.
 The server sends an HTTP request to the provider with a request to
authenticate the user.
 The provider begins the authentication procedure. The authentica-
tion method is at the discretion of the provider.
 After the authentication procedure is completed, the user reports
this to the client application.
 The client application passes this information to the 1C:Enterprise
server, which is requested by the provider of the second factor
about the authentication results.
 The provider informs the authentication result to the server. If it is
successful, then the user is considered identified and he is granted
access to the application.
Each of the methods reviewed in this section has a certain support from the
1C:Enterprise system. Setting of application of the second authentication
factor is reviewed in the next section.

6.2.8.6.3. Second factor setting

Setting of application of the second factor in the 1C:Enterprise system is
divided into several parts:
• Setting of request templates that are sent to providers.
• Binding a request template to an infobase user.
• Requests parameterization.
Let's take a closer look at each part.
To describe the HTTP request that should be sent to the provider, the
TemplateOfSettingsOfTheSecondAuthenticationFactor
object is used. Choice of one of the options for the second authentication
factor is carried out in the process of setting the template parameters. In
case when it is necessary to implement the first option of the second authen-
tication factor (1C:Enterprise server itself generates, sends and checks the
value of the second factor), the HTTPRequestToAuthentication and
the HTTPRequestToAuthenticationMethod properties are used.
The first property contains description of the HTTP request (an object of the
HTTPRequest type), and the second parameter allows you to specify
which HTTP method will be used to request the second authentication fac-
tor to the provider.
In case when it is necessary to implement the second authentication option
(1C:Enterprise server only initiates authentication in the provider of the
second factor and receives its result), the parameters reviewed above remain
and are used for their intended purpose -to start using the second authentica-
tion factor. To check the authentication result, two additional properties are
used: HTTPRequestForChekingTheAuthenticationResult and
MethodOfHTTPRequestForCheckingTheAuthentication
Result.
Each template has its own name (property of the same name), which will
allow you to identify the template when executing further actions.
When forming an HTTP request (for setting any property), one should keep
in mind the following features:
1. The HTTP method is specified as a string. This is because the HTTP
specification allows the use of custom verbs (methods).
2. The request text may contain parameters. Parameters - is some text
starting with the "&" character. For example, you can use the &
user_name parameter to specify a user name. These parameters will
be replaced with real values at the time of sending the request (will be
reviewed below). The reason for this decision is the assumption that
the HTTP requests of the second authentication factor for different us-
ers will be almost the same. Differences will be observed only in some
information that is specific to a particular user. For example, a condi-
tional request to send an SMS message with the code of the second
factor will look like this:
http://provider.hostname/sendsms/&phone_number.
When sending a request, the & phone_number parameter will need
to be replaced with the user's actual phone number.
The platform provides a predefined & secret variable, which con-
tains the value of the second factor generated by the platform.
 Having all the information, let's look at an example of creating a template
for working with the second factor according to the first option (the plat-
form generates, sends, provides input and verification of the second factor):
Request = New HTTPRequest;
Request.Resource Address = "&addr";
Request: SetBodyFromString ("Enter the & secret value. Do not tell
this value to anyone!", "Utf-8");
Provider =
TemplatesOfSettingsOfTheSecondFactorOfAuthentication.CreateTemplate
();
Provider.HTTPRequestForAuthentication = Request;
Provider.HTTPRequestMethodForAuthentication = "POST";
Provider.Name = "Request - response";
Provider.Record();

The first three strings form the HTTP request that will be used by the plat-
form. The remaining strings create the template of the second factor provid-
er, which will send the request using the POST method and have the name
Request- response.
As probably it has already become clear if it is necessary to create a tem-
plate for the provider of the second factor working according to the second
option (all actions are executed by the provider itself, the platform only ini-
tiates the operation start and requests the authentication result), then the
above example should be processed in such a way that:
1. The authentication request met the requirements of the provider used.
2. A request was generated (and set in the template) to check the authen-
tication results. This request will be executed after the user "inform"
the client application that he had passed authentication with the pro-
vider.
After we saved one or several templates for providers, it became possible to
assign one of the templates to the user. Keep in mind that you can assign
multiple templates to one user and specify how they will be processed.
To set up user settings, two properties of the InfobaseUser object are
used:
• SettingSecondAuthenticationFactor- here you need to
assign an array of objects of the
SettingSecondAuthenticationFactor type.
• ProcessingSettingsForTheSecondAuthenticationFac
tor - describes what the platform will do if several providers of the
second factor are specified, and the first (in the traversal order) pro-
vider returned an error.
After specifying the above properties, the object describing the infobase
user should be recorded.
We need to consider the last moment: where will the platform get the values
that will be substituted for the variables in HTTP requests? To do this, we’ll
 take a closer look at the SettingSecondAuthenticationFactor
object. This object contains two fields:
• SettingsTemplateName - here you should specify the name of
the template of the setting of the second factor provider, which was
specified in the Name property when setting the provider template.
• Parameters - you need to assign a match to this property. The
match should contain as many elements as the parameters are con-
tained in the setting template of the second factor provider (with the
exception of the &secret parameter). The key of the correspondence
element is the name of the parameter (without the "&" character), and
the value -is the value of the variable.
Now we have all the information in order to indicate to the infobase user the
necessity to execute two-factor authentication when entering the infobase.
ProviderParameters = New Map;
ProviderParameters.Insert("addr", "http://hostname/resource");
UserSettings = New SettingSecondFactorOfAuthentication;
UserSetting.SettingTemplateName = "Question - answer";
UserSetting.Parameters = ProviderParameters;

UserSettings = New Array;

UserSettings.Add(UserSetting);

User = InfobaseUsers.SearchByName("Seller");
User.SettingsOfSecondFactorOfAuthentication = UserSettings;
User.ProcessingOfSettingOfTheSecondFactorOfAuthentication =
TypeOfProcessingOfSettingsOfTheSecondFactorOf
Authentication.UseNextInCaseOfError;
User.Record();

The platform will replace parameter names with the actual values in the
following properties:
• property HTTPRequest.ResourceAddress;
• property HTTPRequest.Headings;
• body of object request HTTPRequest (the method of specifying the
request body does not affect the substitution work);
• property
TemplateOfSettingOfTheSecondFactorOfAuthenticat
ion.HTTPRequestMethodForAuthentication;
• property
TemplateOfSettingOfTheSecondFactorOfAuthenticat
ion.HTTPRequestMethodForCheckingAuthenticationR
esult.
It remains to mention that if the provider of the second factor selected for
the user is "broken",- the user can not get an access to the infobase. In this
case, the term "broken" means any event that does not allow the provider to
complete its task: there is no Internet for access from the server to the pro-
vider, there is no Internet for access from the provider to the user, an error
has occurred on the provider’s side, etc.
It is also necessary to understand that if you plan to use a third-party pro-
vider of the second factor, then the services of this provider may be paid
and the provider may put forward additional conditions and restrictions that
lie outside the 1C:Enterprise system and are not considered in this docu-
mentation.

6.2.8.6.4. OpenID Authentication and two-factor

authentication
The 1C:Enterprise program system supports authentication using the
OpenID protocol. If the information system uses OpenID authentication,
then the second factor should be requested by the OpenID provider. This is
true, including if the 1C:Enterprise system infobase is specified as an
OpenID provider. In other words, two-factor authentication must be config-
ured in the infobase that is the OpenID provider.

6.2.8.7. Use of biometrics to log in through a

mobile client
So far as devices which support biometric authentication (i.e. they have a
fingerprint sensor, face or iris scanner etc) are concerned, Use biometrics
check box is available in a mobile client infobase setting and authentication
(on a mobile device) dialog boxes. Whenever this check box is checked, the
following mechanism is activated:
• When you log in for the first time, user names and passwords you en-
ter for the infobase and authentication using OpenID and web server
are stored in a secure storage.
• When you further log in again, the following logic is implemented:
 First, log in is ensured without using data available in a secure
storage to verify that authentication is not currently required or
there is relevant authentication data disclosed by OpenID provider.
If a mobile device stores relevant authentication data, a query to
provide biometric data for authentication purposes is made only
when authentication data life cycle expires.
 If the previous step failed, a user is prompted to undergo biometric
authentication using a mobile operating system interface. Kind of
authentication specified in the user's mobile device settings is
used.
 If biometric authentication is abandoned by a user, - a standard au-
thentication dialog box is displayed (you must enter your user
name and password).
  As soon as biometric data is accepted by a mobile device, data
saved during prior successful authentication is recovered from the
secure storage. The said data is used for authentication purposes.
 If this data is not accepted by a mobile device, data saved during
prior successful authentication is deleted from the secure storage.
Subsequently, a standard authentication dialog box is displayed
(you must enter your user name and password).
• No biometric data is used, if authentication is made through OpenID
Connect, as in this scenario a protected web page of OpenID Connect
provider is used to perform authentication. So far as this kind of au-
thentication is concerned, you cannot insert provider's user name and
password previously saved by default. Moreover, OpenID Connect
supports repeated authentication on this device without any time limit,
while there is no need to enter user name and password.
If your mobile device supports authentication through OpenID Con-
nect -, this method is used for authentication purposes. Whenever au-
thentication through OpenID Connect is abandoned, - you can log in
fast using biometric data. To repeatedly authenticate through OpenID
Connect, an attempt to log in must fail first.

6.2.9. Users and extensions

If the infobase user is assigned native roles from extension, the user is
marked in the list with a special icon.

Fig. 46. Extension role assigned to user

Roles that are present in the extensions connected to the infobase, and are
present in the list of roles available for assignment to the user. Extension
roles place at the end of the extensible configuration role list. There is an
option to set or unmark extension roles.

Fig. 47. Displaying roles from extension

6.3. Active users list

Sometimes you need to determine which users are connected to the infobase
at the moment.
To get the list of active users, click Administration - Active users. A list
of users currently working with the database will be displayed.

Fig. 48. Active users list

The current line displays data of the user who opened the form (current ses-
sion). The current user is marked in the list with an icon. Data separation
column specifies details of separators which are specified for a user in De-
signer (see Data separation tab in user properties). There are no values
disclosed in this column for separators which apply to a specific session
when a form is opened.
 Using the Actions menu you can customize appearance of the list or export
it to a spreadsheet or text document. The list of active users can be sorted by
any column.

6.4. Session start lock

6.4.1. Manually, for all
1C:Enterprise allows to prohibit users from creating new sessions with the
infobase. You can prohibit user sessions with the infobase so that any users
attempting to access the infobase will get a custom error message instead.
This capability can be useful when, for example, you need all current users
to close their sessions and make sure that no new users can connect to the
infobase.
When working in client/server mode, you can enable this lock with
1C:Enterprise server cluster administration utility.
To connect to the infobase regardless of the lock, use the /UC<permission
code> command-line parameter and UC=<permission code> connection
string parameter. If a permission code is specified for the lock, you need to
enter the code in the /UC parameter to bypass the lock and connect to the
infobase. If a permission code contains spaces, you need to enclose it in
quotes.
When using the web client or thin client working via the web server, you
can specify the permission code in UC parameter of the connection string of
descriptor file. In this case, additional publication of the infobase on a web
server is recommended.
When the session start lock is set and permission code is set to 123, you
need to enter /UC123 in the client application startup command line in or-
der to bypass the lock.

Software method
In any run mode, session locks can be enabled using the 1C:Enterprise lan-
guage. The SessionsLock object of the 1C:Enterprise language is used
for this purpose. You can create it in constructor and configure the required
properties for locking new connections.
The global context method SetSessionLock() enables the lock and
GetSessionsLlock() method - gets enabled lock.
6.4.2. By default, when password
is under attack
Password attack is one of the methods which can be used to be granted un-
authorized access to infobase data. In this scenario, a malicious user tries to
hack a password using a pre-defined algorithm, until it is cracked and a
password for a selected user becomes available thereto. To avoid the said
manipulations, 1C:Enterprise supports a dedicated mechanism available in
the infobase client/server mode only.
An administrator manages this mechanism by way of entering the following
infobase parameters (this dialog box is displayed, when you run Main
menu - Administration- Infobase parameters command):
• Max number of failed authentication attempts - defines the num-
ber of attempts allowed to be made by a user to enter their password,
before access is blocked. Access is blocked, as soon as the aggregate
number of successive attempts to authenticate which failed becomes
equal to N+1, where N- is a parameter value. In other words, if this
parameter is equal to 2, a user will be blocked as soon as their third at-
tempt to authenticate fails.
If this parameter is equal to 0, this mechanism is disabled, and the ag-
gregate number of failed attempts to authenticate is not monitored by
the platform.
• Blocking duration when the aggregate number of failed at-
tempts to authenticate is exceeded (in seconds) - defines the
time period when a user is unable to authenticate, if they attempt to
enter a wrong password in excess of the number of attempts specified
in Max number of failed authentication attempts.
• User name add-on codes when authentication is blocked - al-
lows it to block authentication attempts made by already blocked user.
Add-on codes are separated by ";". As such, a user name is generated
on the basis of the name of an existing user who have been already
blocked using one of the add-on codes. So far as a user with their
name generated using add-on codes is concerned, the aggregate num-
ber of authentication attempts is equal to that specified for an ordinary
user. As soon as all available attempts to authenticate are made, the
said "extra" user is as well blocked.
The mechanism works as follows:
• A malicious user enters a user name and attempts to hack a password
by way of entering a password expected to be a valid password of a
user. As soon as the aggregate number of failed attempts to authenti-
cate is exceeded, - the user name entered by a malicious user is
blocked.
 • If a blocked user attempts to log in using their name and password, - a
warning is displayed specifying that the user has been blocked.
• Whenever add-on codes are specified in an infobase, these can be used
by a user. As such, a user needs to enter their name with an add-on
code. When you use add-on codes, mind the following: an add-on
code is analyzed, only if the user name you enter is not already in-
cluded in the list of infobase users. User name add-on codes specified
in the settings are successively subtracted from a user name. Further,
it is verified whether an infobase user with such name already exists,
or not. The following things should be noted in this description: avoid
using add-on codes which are similar to the end of the name of an ex-
isting user. If such a user is blocked by the mechanism under review,
they will not be able to log in using add-on codes. Moreover, start
each add-on code using the so-called "technical" symbols, which are
unavailable in the user name, for instance "!", "^" etc.
To view a list of blocked users, use a form available in Designer and run
Main menu - Administration - Blocked authentication command. This
form is available to each user with Administration or
DataAdministration rights assigned thereto. For information having
regard to blocked users, see the event log.
Details of blocked users are stored by the server cluster auxiliary function
service. It means that:
1. If a single administrator is blocked, to log in using their user name -,
the server cluster has to be reloaded.
2. Failed log-in attempts are counted from the recent successful log-in
without any time limitation. However, when you reload the server
cluster, all counters for all infobase users are reset.
To manage a blocking mechanism, use AuthenticationBlock global
context object. This object is designed as well to modify mechanism set-
tings (use GetSettings()/SetSettings() methods for that pur-
pose). Moreover, a list of current blocks can be displayed using
GetBlocks() method.
In 1C:Enterprise language you can forcefully unblock all or certain blocked
users. For that purpose, get a list of current blocks displayed as
UserAndInfobaseAuthenticationBlock object array. Further,
you need to make up a list of users to unblock (based on
UserAndInfobaseAuthenticationBlock object properties). Final-
ly, call Unblock() method for this object in relation to blocked users so
selected.
6.5. Regional infobase settings
Regional infobase settings affect the format of date, time, numbers, logical
constants, as well as string order in infobase lists. To start this mode, click
Administration - Regional infobase settings.

Fig. 49. Regional settings

If a property is not set, the default 1C:Enterprise settings for numbers, dates,
and time for the specified language (country) will be used. Language (coun-
try) is specified during infobase creation.
Language (Country). Choosing the language (country) for this infobase.
IMPORTANT! If PostgreSQL DBMS is used, you cannot select an arbi-
trary language (country) for the existing infobase. You can only select a
language (country) that uses the same database collation order as the current
language (country). For example, Russian (Russia) can be changed to Be-
lorussian (Belarus) but cannot be changed to Ukrainian (Ukraine).
If IBM DB2 is used, you cannot change the language (country).
First weekday property is used to specify what day of the week is consid-
ered the first day of the week in the country. If you set this property to Au-
to, the first day of the week is chosen based on the country specified in
Language (Country) property. For example, if you choose English lan-
guage, Sunday will be set as the first day of the week, and if you choose
Arabic, Saturday will be the first day. Any day of the week can be chosen
as the first day of the week.
In infobases created with 1C:Enterprise 8.3.6 or older, the value of the first
day of the week is not stored in the infobase. If compatibility with 8.3.6 and
earlier versions is enabled for an application deployed in this infobase,
Monday will be used as the first day of the week (and you will not be able
to change this value). If the compatibility mode is set to Not used for this
infobase (or compatibility version is earlier than 8.3.6), the first day of the
week will be selected according to Language (Country) property. The
First weekday property is assumed to be set to Auto.
In infobases created with 1C:Enterprise 8.3.7 or later, the value of the first
weekday is stored in the infobase. When creating an infobase, the First
weekday property is set to Auto. The value of this property can be
changed; the changed value is stored in the infobase. Setting the mode for
compatibility with 8.3.6 and later will make Monday the first day of the
week and First weekday property will be uneditable. However, the actual
settings will be saved and will become effective after setting the compatibil-
ity mode to Do not use (or if the compatibility version is later than 8.3.6).
If you edit regional settings in 1C:Enterprise 8.3.6 and later, the value of
First day of the week property will be cleared.
If the Use regional setting of the current session property is set, the
values similar to Number and Date are displayed (including input fields,
calendar, and calculator) according to regional settings of a current session.
These settings are determined based on the regional settings of a client
computer, but can be re-configured using the /VL command-line parameter.
In the lower part of the dialog box, examples of number, date and time for-
mats for the selected regional settings are displayed.
Values of Boolean type are displayed in accordance with the interface
language. This can be set using the/L parameter.
Decimal separator. You can choose a separator between integer and frac-
tional parts of a number from the drop-down list, or type it in the input field.
An example is displayed to the left of the input field.
Digit group separator. You can choose a separator of digit groups in a
number from the drop-down list, or type it in the input field. An example is
displayed to the left of the input field.
Grouping. This property sets the format for digit grouping in the integer
part of a number. You can choose the format string from the drop-down list,
or enter it manually.
The grouping format is: <number of digits per group><separator>…
…<0>.
Any character can be used as a separator, except digits.
For example, 3,2,0 means that digits will be grouped in the following way
(digits are counted left to right, applies to integer part only):
• The first group includes the first 3 digits
 • It is followed by the group separator (specified in OS settings or in
Group separator property)
• All other digits are grouped by twos
The 0 character at the end of a format string means "the same applies until
the end of the number."- So, if you remove 0 from the above string and en-
ter 3,2, the grouping will change:
• The first group includes the first 3 digits
• It is followed by the group separator
• The second group includes the next 2 digits
• It is followed by the group separator
• The last group includes all remaining digits
If you enter 0 in this field, digits in the integer part of numbers will not be
grouped.
Negative number format. You can choose the negative numbers format
from the drop-down list. If you choose Auto, negative numbers format is
governed by the OS settings.
Date format. Specifies the date format. You can use the following charac-
ters in different combinations:

Characters Description
D Day of month. Numbers below 10 are displayed without a
leading zero
Dd Day of month. Numbers below 10 are displayed with a lead-
ing zero
M Month number. Month numbers below 10 are displayed
without a leading zero
MM Month number. Month numbers below 10 are displayed with
a leading zero
MMMM Month name (in words)
Y The last two digits of the year. Years below 10 are displayed
without a leading zero
Yy The last two digits of the year. Years below 10 are displayed
with a leading zero
Yyyy All four digits of the year
The above mentioned characters and groups of characters can be entered in
any sequence. You can specify the separators for day, month, and year.
Time format. Specifies the time format. You can use the following charac-
ters in different combinations:

Characters Description
h, H hours, in 12-hour (h) or 24-hour (H) format. Hours below 10
are displayed without a leading zero
 Characters Description
hh, HH hours, in 12-hour (hh) or 24-hour (HH) format. Hours below
10 are displayed with a leading zero
m minutes. Minutes below 10 are displayed without a leading
zero
mm minutes. Minutes below 10 are displayed with a leading zero
s seconds. Seconds below 10 are displayed without a leading
zero
ss seconds. Seconds below 10 are displayed with a leading zero
The above mentioned characters and groups of characters can be entered in
any sequence. You can specify the separator characters to separate hours,
minutes, and seconds.
IMPORTANT! When using regional settings to specify format of date in
input field, only choose settings supported by the input field.
False, True. Specifies logical constants. You can choose these from the
drop-down list, or enter manually.

6.6. Infobase parameters

Infobase parameter settings affect data lock timeout and determine whether
restrictions need to apply for user passwords.

Fig. 50. Infobase parameters

You can configure the following parameters:
Data lock timeout (sec.)
Determines the maximum waiting time before the transaction lock is set by
the database server. For example, when the current transaction needs to set
lock on a database record but the record is already locked by another trans-
action, the current transaction will wait until the lock is released or the
number of seconds specified in this parameter passed. The parameter also
determines transaction lock timeout in 1C:Enterprise managed lock mode.
Changing this parameter (using this dialog box or 1C:Enterprise language)
requires administrative rights and enables exclusive mode for infobase ac-
cess.
Changes of the data lock timeout value become effective immediately for
all databases except IBM DB2. In IBM DB2, you need to restart the data-
base after the data lock timeout value is changed.
Minimum password length
Defines the minimum length of user password. If Password complexity
validation is enabled, the minimum length of the user password is 7 charac-
ters.
Password complexity validation
When this parameter is enabled, user passwords must meet the following
requirements:
• The password length must not be less than value of Password mini-
mal length parameter
• The password must include characters from at least three of the fol-
lowing groups:
 Uppercase letters
 Lowercase letters
 Digits
 Special characters
• The password must not match the username
• The password must not be an alphabetical sequence of characters.
Enabling these restrictions for infobase user passwords does not affect the
existing passwords. Restrictions will be applied only after the current pass-
word is changed or a new infobase user is added. However, password veri-
fication is performed according to the current infobase settings. In particu-
lar, this means case-sensitivity check is enabled for passwords when Pass-
word complexity validation is enabled.
For example, if the user password is PaSs and Password complexity vali-
dation is disabled, the user can enter their password as: pass or PASS or
PasS, and still be able to log on. After enabling Password complexity val-
idation, the user cannot log on until they enter the case-sensitive password:
PaSs.
Passive session hibernation timeout (sec.)
A session that has no activity for the specified time becomes Hibernating.
Hibernating session termination timeout (sec.)
The hibernating session is terminated after the specified time has passed.
Number of totals recalculation jobs
Defines the number of system background jobs used to recalculate register
totals upon infobase restructuring or testing and introducing respective
patches. The default value is 4, i.e. to recalculate totals 4 background jobs
are started in a row. This parameter is applicable in infobase client/server
mode only.
Maximum number of failed authentication attempts
For detailed description of this parameter, see By default, when password is
under attack.
Block duration when the maximum number of failed
authentication attempts is exceeded (in seconds)
For detailed description of this parameter, see By default, when password is
under attack.
Username add-on codes used when authentication is
blocked
For detailed description of this parameter, see By default, when password is
under attack.

The infobase parameters can be changed or received from the 1C:Enterprise

language using the following methods:
• Infobase lock timeout-
SetDataLockTimeout()/GetDataLockTimeout().
• User password minimal length -
SetUserPasswordMinimalLength()/GetUserPasswordM
inimalLength().
• User password strength check flag -
SetUserPasswordStrengthCheck()/GetUserPasswordS
trengthCheck().
• Passive session sleep timeout -
SetPassiveSessionSleepTimeout()/GetPassiveSessi
onSleepTimeout().
• Passive session termination timeout -
SetPassiveSessionTerminationTimeout()/GetPassiv
eSessionTerminationTimeout().
• Number of totals recalculation jobs-
SetNumberOfTotalsRecalculationJobs()/GetNumberO
fTotalsRecalculationJobs().
• Infobase time zone -
SetInfobaseTimeZone()/GetInfobaseTimeZone().
 • Full-text data search mode-
SetFullTextSearch()/GetFullTextSearch().
• The first year of the century-
SetBeginningOfTheCenturyOfInfobase()/ReceiveBegi
nningOfTheCenturyOfInfobase()/BeginningOfCentur
yOfSession().
The parameter is used in cases where it is necessary to define the
whole year of the date from the last two digits. When the first year of
the century is set to "1950" (the default value), then the numbers of
the year "49" will correspond to the year "2049", and the numbers of
the year "50" will correspond to the year "1950".
When the infobase parameters are set in transaction using the 1C:Enterprise
language (using the methods listed above), the corresponding "GET" meth-
od returns:
• In current session:
 Before transaction end - the latest value
 After transaction commit - the latest value
 After transaction rollback - the value at transaction start
• In another session:
 Outside of transaction in record-locking databases (Microsoft
SQL Server, IBM DB2) - the latest value, not later than 20 seconds
after the value is set After transaction rollback - the value at trans-
action start, not later than 20 seconds after the rollback
 In transaction and for versioned databases (file mode, PostgreSQL,
Oracle Database) - the latest value, no later than 20 seconds after
committing the transaction in which the value was set
In the client/server mode, when the parameter value is set from the thick
client side, the change is immediately visible at the server side, and vice
versa.

6.7. Exporting infobases to file

An infobase can be saved to a file on hard disk. To save the infobase data to
a file, click Administration - Dump infobase. This will open the standard
file selection dialog box. Select a directory and specify the name of infobase
data dump file.
The export functionality allows to:
• Obtain an infobase image regardless of the data storage method
• Transfer an infobase between DBMS's or file modes
Before exporting the infobase, it is recommended to test it using Designer
or a third-party utility, and fix all the problems found.
It is not recommended to use this method to create infobase backups, for the
following reasons:
 • The export file may be impossible to load if the exported infobase
contains errors
• The export procedure takes a long time
• The export procedure requires exclusive mode
• The export procedure has high RAM requirements
NOTE. Switching the infobase to exclusive mode does not automatically
switch the MS SQL database to single-user mode.

6.8. Importing infobases from

file
To restore an infobase from a file, click Administration - Restore in-
fobase.
This will open the standard file selection dialog box. Select a directory and
specify the name of the infobase data dump file.
When restoring the infobase from a file, you need to ensure that free disk
space (for temporary files) approximately equal to the expanded size of the
infobase is available:
• For file mode - on the computer where the infobase import is per-
formed
• For client/server mode - on the computer hosting 1C:Enterprise server
The size of the resulting database may be several times larger than the size
of the .dt data dump file.
IMPORTANT! Restoring destroys the current infobase irrevocably.
To speed up the infobase import when using Microsoft SQL Server, it is
recommended to set the recovery mode to Simple or With incomplete log-
ging for the database. You can temporarily change the mode before import,
or permanently if you do not need to restore the database often. Before
changing the database restoring mode, you should backup the data-
base.
An infobase dump file (.dt) created by 1C:Enterprise 8.1 and 8.2 can be
imported to 1C:Enterprise 8.3. If you try to import a configuration with un-
known compatibility mode, an error is displayed indicating the required
version. Importing 1cv8.dt files generated in version 8.3.1 and later into
1C:Enterprise versions prior to 8.3.1 is not allowed. The only exception is
when the configuration property Compatibility Mode is set to Version
8.2.16 in 1C:Enterprise 8.3.1 and later.
6.9. Infobase backup
6.9.1. Infobase file mode
IMPORTANT! You should create a backup before performing any opera-
tion that may damage the infobase data.
IMPORTANT! When creating an infobase backup (including restoration)
in file mode, no connections to the infobase (including Designer) are al-
lowed.
You can create infobase backups in any file management application. Open
the infobase directory in the file manager of your choice. To create a backup
copy of the infobase, simply copy file 1Cv8.1CD to another directory. To
restore the infobase from backup (in case of data loss, damage, etc), just
copy the backup file to the original infobase directory.
You can use specialized data backup and recovery software instead.
To make a backup more informative, we recommend to include log files
stored in the 1Cv8Log subdirectory of the infobase directory. We also rec-
ommend to restore the infobase along with the logs (1Cv8Log directory).
This provides you with history of infobase operations performed before the
backup.

6.9.2. Client/server mode of

infobase
IMPORTANT! You should create a backup before performing any opera-
tion that may damage the infobase data.
IMPORTANT! When you restore an infobase using DBMS tools, no con-
nections to the infobase (including Designer) are allowed.
It is recommended to perform infobase backup in client/server mode using
available DBMS tools.

6.9.3. Mobile devices

On iOS, use the standard system functionality to create infobase backups.
On Android OS, use specialized utilities.
You can set up backup creation procedure directly on the mobile device.
Two backup options are available:
1. Before application update
2. Before application start
To set up backup options, open the dialog box of the application properties
and click Administration. Select Backup from the menu.
Specify the following backup settings:
• Backup location (on this device) field indicates the path in the local
file system of the device where the backups are created. By default,
this property indicates backup directory located in the document di-
rectory on the mobile device.
• Create backup on application update radio button enables backup
creation on application update.
• Auto backup frequency (days) property specifies the backup fre-
quency. If this property is set to 0, the automatic backups are not per-
formed. Otherwise, the backup is performed before the application
start if the number of days since the previous backup is greater than
the value of this property.
• Number of backups property determines capacity of the backup stor-
age. If this property is set to 0, the number of backup copies is only
limited by the free space available on the selected drive. Backups cre-
ated before mobile application updates are also considered when cal-
culating the number of backup copies.
The form also contains buttons that create (Create backup) and restore a
backup (Restore...). When you choose to restore a database, you are
prompted to select the backup from which the database will be restored. The
list is retrieved automatically from the contents of the directory specified in
the Backup location (on this device) property.

6.10. Verifying and repairing an

infobase
6.10.1. General information
A variety of abnormal situations can occur while 1C:Enterprise is running:
computer or mobile device power loss, operating system stops responding,
hardware failures, etc.- If such an emergency occurs while writing data to
1C:Enterprise infobases (especially when in file mode), it can damage an
infobase. External signs of infobase damage can vary; in more severe cases,
the damaged infobase cannot be opened.
Verify and repair procedure is designed to diagnose and eliminate damage
in infobases in file or client/server mode. This procedure can be used both
for infobases used on personal computers and for infobases used on mobile
devices.
6.10.2. On a personal computer
To start the repair procedure, click Administration- Verify and repair in
Designer. The following dialog box opens:

Fig. 51. Verifying and repairing an infobase

In the list of checks and verification modes, select the actions you need per-
formed. Multiple checks can be performed independently. In both modes
(file and client/server), you can check the logical and referential data integ-
rity, recalculate totals, restructure and re-index the database tables. In the
file mode, you also can compress database tables.
For some distributed infobases that can provide data containing references
to objects not located in the tested infobase, clearing the Check referential
infobase integrity check box allows to disable creation of "non-existent"
data and, as a consequence, prevents copying such data to other nodes of the
distributed infobase.
While verifying and repairing the infobase, the main table of each corre-
sponding object (dictionary, chart of characteristic types, chart of calcula-
tion types, chart of accounts) is checked for containing no more than one
record per predefined item per data area. If any duplicates are found, the
predetermined data flag is cleared from them and the deletion flag is set
instead.
Several groups of settings are located below the list of verification modes:
• In the first group, you select the action to perform: Verify only, or ver-
ify and repair. In the first case, the infobase is checked but no changes
are made to it. In the second case, the infobase is checked and actions
 specified in the second group of settings are performed. The names of
radio buttons are self-explaining.
• In the second group, you select actions to perform if any references to
non-existent objects are found or a partial loss of data in existing ob-
jects is detected.
• In the third group of controls, you control how lengthy verification
and repair procedures run in multiple sessions.
The Pause verification in check box specifies the time interval after which
verification will be interrupted and the verification and repair parameters
will be saved for the next Designer session.
The Resume verification check box allows to continue the verification
procedure paused in the previous verification and repair session.
Verification and repair events are displayed in the event log.
Click Execute to start verification. Verification can be interrupted by press-
ing CTRL + Break.
Verification determines whether exclusive mode can be set and sets exclu-
sive mode if possible. If exclusive mode cannot be set, a warning is dis-
played: Cannot enable exclusive mode. Active users are detected. To
get information about active users, open the list of active users (click Ad-
ministration- Active users).
If exclusive mode is set, execution of the selected actions starts and verifi-
cation progress information is displayed.
NOTE. Switching the infobase to exclusive mode does not automatically
switch the MS SQL database to single-user mode.
When verification is complete, the exclusive mode is disabled.
When Compress infobase tables is selected for file mode, the infobase
file is additionally optimized by moving all data required to open the in-
fobase to a continuous data block in the beginning of 1Cv8.1CD file. This
optimization accelerates the opening of the infobase, especially for configu-
rations with a large number of infobase tables and configurations located on
the network resources. After restructuring the infobase tables, the effect of
table compression is lost and it is recommended to compress the infobase
tables again. You can also perform infobase table compression by using a
Designer batch run command line.
1C:Enterprise distribution package includes a file mode database recovery
utility (chdbfl.exe).

6.10.3. On a mobile device

To start the repair procedure, open the application properties for editing and
click Administration. Click Verify and repair in the menu.
In the verification settings form, specify:
 • What actions to perform
• Verify only, or verify and repair (Repair automatically check box)
• What to do if references to non-existent objects are found
• What to do if partial loss of the infobase object data is detected
Then, click Execute button in the upper right corner.
Execution of the selected actions starts and verification progress infor-
mation is displayed. To interrupt verification and repair procedure, click
Cancel.

6.11. Cancelling the distributed

infobase master node
assignment
To cancel assignment of the distributed infobase master node, use the
/ResetMasterNode command in Designer batch run command line.
This operation is equivalent to calling the SetMainNode(Undefined)
method of the ExchangePlansManager object.
This may be necessary, for example, when you need to separate a subtree of
the distributed infobase into an independent infobase or to reassign a dis-
tributed infobase node.

6.12. Deleting data areas or

infobases
To delete a data area or the entire infobase, use the /EraseData com-
mand in Designer batch run command line. The area to delete is determined
by using the /Z parameter of the startup command line.
To delete data, the user on whose behalf the deletion is performed needs the
Administration right and exclusive access to the infobase.
IMPORTANT! If no separators are used in the session or data deletion is
performed in a shared infobase, all infobase data will be deleted.
6.13. Event log
6.13.1. General information
To perform administrative duties, it is often required to find out which
events occurred at a particular point in time or what actions a particular user
performed.
Event log is intended for these purposes. Events are registered in this log.
The administrator can get the history of user activities from the event log.
The event log is not a part of a database and is not saved when export-
ing/importing an infobase.
1C:Enterprise logs the major actions by users who modify infobases, per-
form routine operations, log on, log off, etc.
Event log is supported both in Designer mode and 1C:Enterprise mode.
Event log can be generated in either of two formats:
• Sequential format (.lgf).
• SQLite format (.lgd).
Depending on 1C:Enterprise version, different default log formats are used:
• In 1C:Enterprise version 8.3.12 and later, the default format is sequen-
tial.
• In 1C:Enterprise versions 8.3.5 to 8.3.11, the default format is
SQLite.-
• In 1C:Enterprise version 8.3.4 and earlier, only sequential format is
supported.
Changing the event log format while 1C:Enterprise is running is supported.
The selected format of the event log is saved in the infobase. As a result,
when you restore the infobase from a backup or a dump file (.dt), the event
log format is also restored.
Each event in the event log is identified by a string. The system events use a
combination of _$ and $_ characters (for example,
_$InfoBase$_.MasterNodeUpdate or
_$PerformError$_)._$InfoBase$_.MasterNodeUpdate will be displayed
as a string Infobase. Update master node. Using these character combi-
nations in names of events written by the WriteLogEvent() method is
prohibited. The events generated by this method are displayed as is.

6.13.2. Event log in .lgd format

Event log in .lgd format is stored in a SQLite database file. Log location:
• For file mode: in the 1Cv8Log subdirectory of the infobase directory.-
• For client/server mode: in the 1Cv8Log subdirectory of the infobase
directory of internal files directory of the cluster.- The directory name
can be determined from the data registry file of the cluster.
 6.13.3. Event log in .lgf format
Event log in .lgf format is stored in text files with .lgf extension (general
information of the event log) and .lgp (event log fragment). Log location:
• For file mode: in the 1Cv8Log subdirectory of the infobase directory.-
• For client/server mode: in the 1Cv8Log subdirectory of the infobase
directory of internal files directory of the cluster.- The directory name
can be determined from the data registry file of the cluster.

6.13.4. Saving event log

To save the event log, open it and click File - Save copy. Specify the direc-
tory, the file name, path, and type (the default event log file format is *.lgf).
Export in XML format is also supported.
Example of exported event log:
<v8e:EventLog
xmlns:v8e = "http://v8.1c.ru/eventLog"
xmlns:xsd = "http://www.w3.org/2001/XMLSchema"
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance">
<v8e:Event>
<v8e:Level>Warning</v8e:Level>
<v8e:Date>Event date</v8e:Date>
<v8e:Application>Enterprise</v8e:Application>
<v8e:ApplicationPresentation>
1C:Enterprise</v8e:ApplicationPresentation>
<v8e:EventName>event name</v8e:EventName>
<v8e:EventPresentation>
event presentation</v8e:EventPresentation>
<v8e:UserID>00000000-0000-0000-0000-000000000001</v8e:UserID>
<v8e:UserName>Johnson</v8e:UserName>
<v8e:Computer>JohnsonPC</v8e:Computer>
<v8e:MetadataName>Catalogs.Products</v8e:MetadataName>
<v8e:MetadataPresentation>
Catalogs Products</v8e:MetadataPresentation>
<v8e:Comment>Comment</v8e:Comment>
<v8e:Data xsi:type="xsd:string">Some data</v8e:Data>
<v8e:DataPresentation>Data description</v8e:DataPresentation>
</v8e:Event>
</v8e:EventLog>

6.13.5. Viewing event log archive

To view the archive entries of the event log:
• In Designer: Select Main menu - File - Open to open the standard
file selection dialog box, and specify the Event log (*.lgd, *.lgf) file
type. Select an archive file and click Open.
 • In the standard event log viewer: Select More - View from file to
open the standard file selection dialog box, select an archive file, and
click Open.
The automatic update settings and update interval settings are generated by
the standard list setting mechanism for the tabular field.

6.13.6. Event log settings

6.13.6.1. General information
By using the menu item Administration - Event log setting you can speci-
fy the detail level of event logging. In case of remote network access, you
can only save your settings when no other users are logged on to the config-
uration (except the administrator).

Fig. 52. Event log settings

When you create a new infobase, events of all levels of importance are
logged and a new log file is created daily.-
If the event log is in a sequential (.lgf) format, you can specify log splitting
into periods. This is because the log records are stored in files. Each file
contains records for a specific period. The period length is specified in the
Split event log storage by periods field. A new file is opened each (as
specified in the settings):
• Hour
• Day
• Week
• Month
• Year
If the event log is in SQLite format, all records are stored in a single file and
period splitting is not available.
6.13.6.2. Reducing size of event log
A large number of records may accumulate in the event log eventually. To
reduce the number of records, open the event log settings and click Reduce
size. This opens the following window:

Fig. 53. Reducing size of event log

All records preceding the date specified in the Delete events older than
field are deleted. Pay attention that all records will be deleted in the event
log splitting period (see above for the description of the Split event log
storage by periods field) that includes the specified date. For example, if
the log is split by months and the deletion date is May 14, 2009, the log
records up to May 31, 2009 (inclusive) will be deleted. Also remember that
the event log splitting period may change with time, so that the period to be
deleted will be determined not by the current split period, but by the period
that was set during the date specified in the Delete events older than
field.
If you need to save the event data before deleting the records, select the
Write deleted events to file check box and specify the name of the ar-
chive file.
If the event log is stored in a sequential (.lgf) format, this allows you to re-
duce the log on a regular basis and still be able to view the log events that
have already been deleted. To do this, if you reduce the log by writing the
deleted entries to a file, select the Keep log storage split by period and
merge with the previously saved log check box.
TIP. You can also use the /ReduceEventLogSize KeepSplitting command
to keep splitting by periods when you start Designer in command line mode.

6.13.6.3. Changing event log format

You can change the format of the event log. Depending on the infobase ver-
sion, different types of access to the infobase file are required to change the
log format:
• File mode - exclusive access to the infobase file is required.
• Client/server mode - format can be changed while users are logged on.
Further:
  When you change the log format, no log events can be lost, even
those that were written during and after the format change.
 If an error occurs during event log conversion from sequential to
SQLite format, the log retains the sequential format.
 If an error occurs during event log conversion from SQLite to se-
quential format, the log retains SQLite format if the error occurs
while writing the sequential log; or the log retains sequential for-
mat if the error occurs while reading from the SQLite log.
The event log format change is an event written in the event log as In-
fobase. Update event log settings
(_$InfoBase$_.EventLogSettingsUpdate). The comment indi-
cates to which format the event log was converted.
To change the event log format, click the Change format hyperlink.

Fig. 54. Changing event log format

This will open the format change confirmation dialog box, which depends
on the current event log format.
When converting from sequential format, the dialog box is as follows:

Fig. 55. Converting to SQLite format

When converting from SQLite format, the dialog box is as follows:

Fig. 56. Converting to sequential format

During conversion, you can also enable the event log splitting by periods.
 IMPORTANT! Changing the format of the event log takes a significant
amount of time.
After you change the format from sequential to SQLite, the event log files
in sequential format are saved. If necessary, you can delete these files using
the operating system functionality. After you successfully change the log
format from SQLite to sequential, the event log file in SQLite format is de-
leted.

6.14. Technological log

6.14.1. General information
1C:Enterprise supports maintenance of technological log storing infor-
mation from all 1C:Enterprise applications.
The technology log is intended as an assistance tool for 1C technical sup-
port service to diagnose and detect errors in 1C:Enterprise applications, and
to analyze the technological characteristics of application performance.
The components and properties of the technological log may change when
the platform updates are released.
Since the technological log is a set of text files stored in different directo-
ries, it can be used by application developers to analyze operating modes of
the 1C:Enterprise and applications.
The technological log can be stored on any computer where 1C:Enterprise
is installed. The technological log settings are stored in a configuration file
that describes:
• Directory where the technological log files are kept
• Types of data written to the technological log
• Retention time of technological log files
• Parameters of dump files generated on application crash
By default, no configuration file is available. This means that the technolog-
ical log is enabled and configured to keep the minimum dumps into the fol-
lowing directory on application crash:
%USERPROFILE%\Local Settings\Application Data\1C\1cv8\dumps

For Windows Vista and later, the directory is:

%LOCALAPPDATA%\1C\1cv8\dumps

If necessary, you can configure the event log by using a separate configura-
tion file. This file must have logcfg.xml name and be located in the
1C:Enterprise configuration files directory.
 NOTE. To enable a technological log on Windows, make sure the user of
the process writing to the technological log has full rights to access the
technological log directory and to read the technological log owner directo-
ry.
Every 60 seconds, 1C:Enterprise automatically polls the configuration files
directories for logcfg.xml file and, if found, analyzes its content. Thus, you
can modify the parameters of the technological log immediately, without
having to restart the 1C:Enterprise applications.
Volume of the technological log can be significant, so it is advisable to
specify retention time for the log file storage. After the retention time ex-
pires, 1C:Enterprise will delete the outdated log files. If the directory in
which these files were located becomes empty after deleting the outdated
files, the directory is also deleted. This ensures that the entire technological
log directory tree does not contain outdated files and directories.
IMPORTANT! If 1C:Enterprise is running on Linux or macOS, the OS
controls the crash dump generation. In this case, the information about the
fact of an emergency termination of the process and the number of the sig-
nal that caused the termination are placed in the technological log.
IMPORTANT! Please take note that the directory of the technological log
is not intended to store any files unrelated to the technological log. Do not
keep dumps in this directory, and do not keep 1C:Enterprise technological
log in a directory with any unrelated files. If any unrelated files are found in
the technological log directory, the directory is considered invalid and the
log is not created.

6.14.2. Technological log

configuration file
A basic configuration file looks like this:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="c:\1c\logs" history="1">
<event>
<eq property="name" value="conn"/>
</event>
</log>
<dump location="c:\1c\dumps" create="1" type="2"/>
</config>

This configuration file specifies that:

• All events of establishing or losing connection to the server are writ-
ten to the technological log
• Technological log files are located in C:\1c\logs directory
• Technological log files are stored for 1 hour
 • Dump files are placed in the C:\1c\dumps directory
• Dump files contain all available information (the entire process
memory)
In the absence of a configuration passport of the following parameters
• Technology log -is off.
• Technology journal is enabled by default.
• Dumps of the minimum size
• Dumps are saved to the%USERPROFILE% \ Local Settings \ Appli-
cation Data \ 1C \ 1cv8 \ dumps directory of the current user pro-
file (or %LOCALAPPDATA%\ 1C \ 1cv8 \ dumps for Windows
Vista and later).
The configuration files in Linux and macOS are almost identical to Win-
dows, with the following exceptions:
• The configuration file must be located in the 1C:Enterprise configura-
tion files directory.
• The directory in which the technological log will be generated must be
writable for the user on whose behalf the application works (server,
client applications, web server extensions, etc.), which writes data to
the technological log.

6.14.3. Default technological log

The default technological journal is intended to record events that occur in
emergencies (as determined by 1C:Enterprise). A fixed event filter is auto-
matically created for this log; this filter cannot be changed.
The default technological log has the following settings:
• The default directory with technological log files:
 Windows:
%USERPROFILE%\Local Settings\Application Data\1C\1cv8
(or%LOCALAPPDATA%\1C\1cv8\logs for Windows Vista or
later).
 Linux: ~/.1cv8/1C/1cv8/logs.
 macOS: ~/.1cv8/1C/1cv8/logs.
• Records are deleted from the default technological log after 24 hours.
• SYSTEM events with Error level are written to the default techno-
logical log.
These settings can be changed using the <defaultlog> element. The
event generation rules for the default technological log are configured using
the <system> element.
 6.14.4. Technological log
structure
The technological log is a directory with subdirectories containing files with
accumulated technological data. The log directory has the following struc-
ture:
<log directory>
<OS process ID>
<single process log files>

Each log file contains events for 1 hour and is named yymmddhh.log,
where:
• yy- the last two digits of the year
• mm- month number
• dd- day number
• hh- hour number
Log files are in text format. Information about completion of each event is
recorded on a new line.
Example:
16:08.8750-
9060,CALL,0,process=rphost,p:processName=DebugControlCenter,t:clien
tID=221,t:applicationName=Debugger,t:computerName=COMP1,Interface=5
cf29e71-ec34-4f01-b7d1-3529a3da6a21,Method=0
16:08.8911-
1,DBPOSTGRS,2,process=rphost,p:processName=Database,t:clientID=216,
t:applicationName=1CV8,t:computerName= COMP1,t:connectID=125,Usr=
User2,Trans=1,dbpid=58152,Sql="SELECT 1::INT8 FROM PG_CLASS WHERE
pg_catalog.pg_table_is_visible(OID) AND RELKIND='r' AND
RELNAME='params' LIMIT 1",Result=PGRES_TUPLES_OK
16:08.8913-
1,DBPOSTGRS,2,process=rphost,p:processName=Database,t:clientID=216,
t:applicationName=1CV8,t:computerName=
COMP1,t:connectID=125,Usr=User2,Trans=1,dbpid=58152,Sql="SELECT
Creation,Modified,Attributes,DataSize,BinaryData FROM Params WHERE
FileName = 'ibparams.inf'",Result=PGRES_TUPLES_OK

The event end string is recorded in format: mm: ss.tttttt-d, <name>,

<level>, <key properties>, where:
• mm- minute in the current hour
• ss- second in the current minute
• tttttt- microsecond in the current second
• d- event duration in microseconds
• <name>- event name
• <level>- event level in the current thread stack
• <key properties>- <key property>, <key property>, ...
 • <Key property>- <name> = <value>; <name>, <name>,
<value>- arbitrary text. If it contains “end of line” or “comma” char-
acters, the text is enclosed in quotation marks or apostrophes, depend-
ing on which characters are less common in the string, and quotation
marks or apostrophes in the text are doubled.

6.14.5. Setting up memory dump

generation
6.14.5.1. On Windows
This section contains an example of the technological log configuration file
(logcfg.xml) that enables crash dump creation.
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump location="C:\Program Files\1cv8\dumps" create="1"
type="3"/>
</config>

The memory dumps will be saved to the C:\Program Files\1cv8\dumps

directory and will include the entire process memory contents plus an addi-
tional data segment.
The user on whose behalf the client application is running or the server
must have full rights to the directories:
• Temporary files directory
• Technological log directory
• Dumps directory
The user on whose behalf the client application is running or the server
must have the right to read the directories:
• Configuration files directory
• Directory that owns the dumps directory
If in the logcfg.xml file you have configured to receive query plans, then
such a file should be located in the configuration file directory of the corre-
sponding application:
• for the client-server option- in the directory of configuration files
available to the 1C: Enterprise server;
• for the file variant with direct connection in the directory of configura-
tion- files available to the required version of the client application;
• for the file version with a connection via a web server in the directory-
of configuration files available to the extension of the web server serv-
ing this information base.

6.14.5.2. On Linux
This section describes the steps to configure Linux to enable generation of
crash memory dumps.
 NOTE. The recommendations in this section are fully applicable to Fedora
Core 4 and similar versions. For other Linux versions, the name and syntax
of the commands described here may be different. For details, refer to the
help system of your Linux version.
By default, crash dumps are disabled. Suppliers of Linux distributions rec-
ommend to include the creation of dumps only on computers intended for
development, but not on production computers.

6.14.5.2.1. Enabling automatic generation of

dumps
Generation of crash dumps is configured for all processes executed on be-
half of a specific user. In order to enable automatic generation of dumps,
add the following lines to the /etc/security/limits.conf file:
<username> soft core unlimited
<username> hard core unlimited

Where <username>- is the name of the user on whose behalf the applica-
tion of the “1C: Enterprise” system is running.

6.14.5.2.2. Determining the name and location of

the dumps
To ensure clear understanding which crash dump is related to which pro-
cess, and to keep the dumps in a specific directory, it is recommended to set
a dump name generation template. The template can be specified for a sin-
gle session, or permanently.
IMPORTANT! Applying settings described in this section affects all pro-
cesses of all OS users. This means that crash dumps by other users (if ena-
bled) will be given the selected name template and saved under the speci-
fied path .
IMPORTANT! The steps described below must be performed on behalf of
root.
To set a name template and location for the crash dumps, use the command:
sysctl -w kernel.core_pattern=/tmp/core.%e.%p

This setting will be valid until the computer is restarted. In the above exam-
ple, the dumps will be placed in the /tmp directory and the names of the
dumps will be generated from:
• core prefix
• Name of the executable file
• ID of the process that initiated crash dump generation
 To apply the name template and the path on the permanent basis, you must
add the following line to the /etc/sysctl.conf file:
kernel.core_pattern=/tmp/core.%e.%p

In order for the changes to take effect, run the command:

sysctl -p

The path specified in the settings must be allowed for writing for the users
on whose behalf the applications that generate crash dumps are running.

6.14.5.3. On macOS

6.14.5.3.1. General information

This section describes the steps to configure macOS to enable generation of
crash memory dumps.
By default, crash dumps are disabled.

6.14.5.3.2. Enabling automatic generation of

dumps
Generation of crash dumps is configured for all processes. To enable auto-
matic generation of dumps, run the following command on behalf of a user
with administrative rights:
sudo launchctl limit core unlimited

The command is valid until the computer is restarted.

6.14.5.3.3. Determining dump names and location

The crash dumps are placed in the /cores/ directory. Files will have names
like core. <Pid process>. The <pid of the process>- is the identifier of
the operating system process that terminated abnormally.

6.14.6. Sample technology log

files
In the examples below, it is assumed that 1C:Enterprise is installed in the
default directory C:\Program Files\1cv8.
Please take note that volume of the technological log can be significant.
Therefore, you need to ensure there is enough free space on the disk where
the technological log files will be stored.
Below are some examples of logcfg.xml files containing some of the most
common technological log configurations.
 6.14.6.1. No technological log
If the logcfg.xml file is not in the 1C:Enterprise configuration files directo-
ry, the technological log is not created. If the logcfg.xml file is required to
configure dump generation properly, it should contain no log elements. The
following example is for generating a complete dump on application crash.
Dumps are placed in C:\v8\dumps directory.
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump location="C:\v8\dumps" create="1" type="3"/>
</config>

6.14.6.2. Full technological log

The configuration file below is for writing all events, together with all prop-
erties, to the technological log. The log will be retained for 1 week (168
hours). The volume of the technological log files will be very large; howev-
er, it can be useful for analyzing complicated emergencies. This configura-
tion is recommended for use during the testing phase and during error inves-
tigation.
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\v8\logs" history="168">
<event>
<ne property="name" value=""/>
</event>
<property name="all">
</property>
</log>
</config>

6.14.6.3. Database calls

The following configuration file specifies that the technological log will
contain only 1C:Enterprise database calls and error information. The vol-
ume of the technological log files is less than for the full technological log,
but it still can be significant.
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\v8\logs" history="168">
<event>
<eq property="name" value="dbmssql"/>
</event>
<event>
<eq property="name" value="dbpostgrs"/>
</event>
<event>
<eq property="name" value="db2"/>
</event>
<event>
<eq property="name" value="dboracle"/>
</event>
<event>
<eq property="name" value="excp"/>
</event>
<property name="all">
</property>
</log>
</config>

6.14.6.4. Administrator actions and errors

This configuration file creates a compact technological log that contains
information about starting and closing applications, establishing and closing
connections with the 1C:Enterprise server cluster, cluster administrator ac-
tions, and 1C:Enterprise errors. This detail level is generally sufficient for
investigating errors both in the configuration and in the 1C:Enterprise plat-
form.
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\v8\logs" history="168">
<event>
<eq property="name" value="admin"/>
</event>
<event>
<eq property="name" value="conn"/>
</event>
<event>
<eq property="name" value="excp"/>
</event>
<event>
<eq property="name" value="proc"/>
</event>
<event>
<eq property="name" value="qerr"/>
</event>
<event>
<eq property="name" value="scom"/>
</event>
<property name="all"/>
</log>
</config>
Errors and long operations

This configuration file generates a technological log that includes all infor-
mation from the previous example, and information on all operations that
take longer than 10 seconds. This can be useful for detecting user actions
that required a long time to complete, for optimization purposes. The dura-
tion of events is expressed in hundreds of microseconds.
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump create="false"/>
<log location="C:\v8\logs" history="168">
<event>
<eq property="name" value="admin"/>
<gt property="duration" value="100000"/>
</event>
<event>
<eq property="name" value="conn"/>
<gt property="duration" value="100000"/>
</event>
<event>
<eq property="name" value="excp"/>
<gt property="duration" value="100000"/>
</event>
<event>
<eq property="name" value="proc"/>
<gt property="duration" value="100000"/>
</event>
<event>
<eq property="name" value="qerr"/>
<gt property="duration" value="100000"/>
</event>
<event>
<eq property="name" value="scom"/>
<gt property="duration" value="100000"/>
</event>
<property name="all"/>
</log>
</config>

6.15. Referential integrity

monitoring
6.15.1. Basic concepts
A large portion of 1C:Enterprise data is stored in reference form. For ex-
ample, when adding documents, many attributes of a document can be filled
in by choosing a value from a value list or a document from a document list.
Such attributes are references to the items of the respective lists.
Using references allows you to avoid storing multiple copies of the same
data in different places. For example, after entering and printing a number
of documents, it turned out that the name of the organization of the counter-
party to which these documents were written out was indicated incorrectly.
Since the name of the counterparty was entered into the documents by
choosing from the list- of counterparties, it is enough to edit the name of the
counterparty only in the list, the changed name will be reflected in the doc-
uments automatically, and it will be enough just to rebuild the printed
forms.
However, if you remove the contracting organization from the list, then in
all the documents in which it was used, so-called -“unresolved references”
will remain references to a non-existent object.
To avoid such situations, 1C:Enterprise includes a mechanism for referen-
tial integrity monitoring, which will be discussed further in this section.
The referential integrity monitoring mechanism implements a two-stage
procedure for deleting data objects referenced in lists or documents.
During the first stage, the user marks the objects for deletion. At the same
time, an object marked for deletion is practically no different in use from an
ordinary object.
At the second stage, the system administrator or another person for whom
the corresponding rights are defined (the Interactive
Deletion of the Labeled for the respective types of lists and doc-
uments is set) performs a special procedure -for deleting marked objects,
which is implemented as the standard function Delete the Marked
Objects. In the course of this procedure, a full analysis of all references
to tagged objects takes place, and only those objects to which references are
either missing or located in objects that are also marked for deletion can be
deleted.
In fact, the procedure for deleting objects marked for deletion is a scheduled
procedure. It is recommended to be performed on a regular basis as the
marked objects accumulate over time.

6.15.2. Enabling referential

integrity monitoring
The 1C: Enterprise system allows you to delete unnecessary or outdated
information in two modes:
• Direct removal of objects -does not analyze the use of the deleted ob-
ject in other database objects.
• Using the control of referential integrity- objects are first marked
for deletion, and then the presence of references to these objects in
other objects is checked.
IMPORTANT! Deletion rights (direct deletion or referential integrity mon-
itoring) are set up for each role assigned to users, for each type of object
(lists and documents) at the application design stage.
If the user works in direct deletion mode, additional responsibility is put on
the user and on the system administrator that assigns user rights and deter-
mines system response to unresolved links. Referential integrity monitoring
may be disabled, for example, for application debugging purposes. If refer-
ential integrity monitoring is not used, the objects are deleted directly
(without marking them for deletion), and unresolved references can occur.
The most radical method to enforce referential integrity monitoring is to
disable the rights to directly delete objects for the entire configuration. This
ensures that users cannot directly delete any objects in the application. The
users will only be able to mark objects for deletion.
Rights for direct deletion, marking for deletion, and clearing deletion mark,
are granted for each type of configuration objects separately. If this type of
rights for the selected set of rights (roles) is set to
InteractiveDeletion, users with this role can directly delete objects
of this type. Rights are granted during application development stage.
The right to mark objects for deletion and clear deletion mark is granted in a
similar way.
Of course, only disabling the InteractiveDeletion option in the con-
figuration ensures that all users use the referential integrity monitoring
mechanism consistently.
IMPORTANT! Note that it is also possible to directly delete objects using
the 1C:Enterprise language. Therefore, parts of a configuration can perform
direct deletion regardless of the referential integrity monitoring mechanism.
In this case, the responsibility for data integrity lies with the developers of a
specific system mechanism.

6.15.3. Direct deletion of objects

If the referential integrity monitoring mode is not used
(InteractiveDeletion right is granted for a specific user for a specif-
ic type of configuration objects), the user can use the Delete directly menu
item (Shift + Del key combination, or the corresponding toolbar button) to
delete objects from lists of lists or document journals. The objects will be
deleted without checking whether they are referenced by other objects.

6.15.4. Setting and clearing

deletion marks
When using the referential integrity monitoring mechanism in the lists of
lists or document journals, Mark for deletion/Unmark for deletion item is
available in More (All actions) menu. Select this menu item to mark an
object for deletion. Objects marked for deletion are marked with a crossed-
out object icon on the left.
IMPORTANT! When marked for deletion of a posted document, it be-
comes undelivered.
Selecting the menu item More -Mark for deletion / Uncheck deletion
(All actions -Mark for deletion / Uncheck deletion) marks an object for
deletion, and for an object marked for deletion, removes the deletion mark
from it.
IMPORTANT! When removing deletion mark from a document, it does
not become posted. You need to post the document manually.
Ability to set or clear deletion marks is also regulated by access rights of a
user (separate rights are required for setting and clearing deletion marks).

6.15.5. Using objects marked for

deletion
Mostly objects marked for deletion are used in the same way as regular ob-
jects. They are displayed in lists, they can be searched for, and so on. Ob-
jects marked for deletion can be opened and modified normally.
Documents marked for deletion cannot be posted. If you attempt to post a
document marked for deletion, an error message is displayed and the docu-
ment is not posted.

6.16. Standard functions

6.16.1. General information
Standard functions- are a set of system tools designed to perform various
service operations that may be required when performing actions to admin-
ister an information base.
Access to standard functions is possible only in 1C: Enterprise mode. To
gain access to standard functions, you must enable the corresponding pa-
rameter in the settings window (Service - Parameters - Display "All func-
tions" command).
NOTE. The standard function windows do not support navigation links and
cannot be added to the user's favorites list.
Below is a complete list of standard features with brief descriptions.

Name Brief description

Active users Displays a list of users currently logged on
to 1C:Enterprise.
Availability of this function is determined
by the ActiveUsers right
Event log Views the event log.
 Name Brief description
Availability of this function is determined
by the EventLog right
Find references to objects Find objects with references to a selected
object.
Document posting Posts and re-posts documents for the select-
ed period, or restores the posting sequences
in the configuration
Delete marked objects Deletes objects marked for deletion.
Totals management Performs scheduled operations with regis-
ters
Full-text search management Manages full-text search feature
Configuration extensions Manages configuration extensions
management
Collaboration system man- Registers infobases with 1C:Dialog
agement
Database copy management Designed for creating copies of the database
and forming the structure of created copies
To run a standard function, open the All functions window, select the
Standard branch, and select a standard function from the list.
For detailed description of all standard features, see below.

6.16.2. Active users list

A list of users currently working with the database will be displayed.

Fig. 57. Active users list

Information about the user that opened the window (established the current
connection) is displayed in bold.
The lower part of the window displays the total number of users working
with this information base.
Open event log- opens the log.
The user's work -opens the log with the selected selection for the selected
user. This action can also be performed by clicking on the hyperlink with
the user name (User column).
6.16.3. Event log
6.16.3.1. General information
To perform administrative duties, it is often required to find out which
events occurred at a particular point in time or what actions a particular user
performed.
Event log is intended for these purposes. Events of all types are stored in it.
The administrator can get the history of user activities from the event log.
1C:Enterprise logs the major actions by users who modify infobases, per-
form routine operations, log on, log off, etc.

6.16.3.2. Viewing event log

The event log is viewed in the event log form.

Fig. 58. Event log

Each event is logged on a separate line. In the left column Date, time, the
icon displays the type of event (see fig. 59). To view the event, select More
View- the current event in a separate window (All actions- View the
current event in a separate window).
When working with the system, the following types of events may occur:

Fig. 59. Types of log events

If an event is associated with data, then the View- More Open Data for
Viewing option becomes available (All Actions View the current event-
in a separate window). With it, you can view the data associated with the
event.
An event can be either transactional or independent (determined from
1C:Enterprise language). The default is independent event recording.
Note that there is a set of predefined events that are generated at the system
level. For such events, transactionalities are also set at the system level.
Thus, data change events, document postings are transactional, and the start
and end of a session are- independent. Below is a complete list of prede-
fined events.
• Independent:
 Session:
 Start.
 Completion.
 Authentication.
 Authentication error
 Open ID provider:
 Confirmed.
 Rejected.
 Infobase:
 Configuration change.
 Modify database configuration.
 Update master node.
 Change event log settings.
 Infobase parameters change.
 Modify regional settings.
 Delete infobase data.
 Run background database configuration update.
 Complete background database configuration update
 Cancel background database configuration update.
 Pause background database configuration update.
  Continue background database configuration update.
 Install predefined data update.
 Update predefined data.
 Reducing size of event log.
 Cannot truncate the event log.
 Cannot modify the event log parameters.
 Cannot modify the infobase parameters.
 Start dumping to file.
 End dumping to file.
 Cannot dump to file.
 Start restoring from file.
 End restoring from file.
 Cannot restore from file.
 Error of changing the database configuration.
 Cannot modify the database configuration extension.
 Verify and repair:
 Warning.
 Error.
 Message
 Background job:
 Start.
 Successful completion.
 Force termination.
 Runtime error,
 Cancel.
 Access:
 Access denied.
 Access granted.
 Users:
 Add.
 Modify.
 Delete.
 Adding error.
 Modifying error.
 Deleting error.
 Authentication lock.
 Authentication unlock.
 Authentication unblock error
 Runtime error
• Transactional:
 Data:
 Edit maximum period of calculated totals
 Edit minimum period of calculated totals
 Add
  Edit
 Delete
 Post
 Undo posting
 Change standard OData interface content
 Set predefined data initialization
 Initialize predefined data
 Initialize predefined data, data not found
 Add predefined data
 Edit predefined data
 Delete predefined data
 Transaction:
 Start
 Commit
 Cancel.
When a transaction is started, the transaction start event, Transaction.Start,
is written to the log and assigned a transaction ID. When a transaction is
completed and committed, Transaction.Commit event is written to the log
and transaction status for Transaction.Start record is set to Committed.
When a transaction is canceled, Transaction.Cancel event is written to the
log and transaction status for Transaction.Start record is set to Canceled.
When a transaction is terminated, Not completed transaction status re-
mains.
IMPORTANT! When you open the event log, the default event filter (ex-
cluding transaction-related events) is set.
Log records corresponding to canceled transactions and transactions with an
undefined status are displayed in a light-grey font.
In addition to viewing the logbook of the current information database, it is
possible to view a fragment of the logbook previously saved in the LGD or
LGF format. To do this, use the command View -More from file (All ac-
tions- View from file).
6.16.3.3. Interval setting
Using the More menu item -Set the date interval for viewing (All ac-
tions -Set the date interval for viewing) you can control the display in-
terval of log events.

Fig. 60. Period settings

In the settings, specify the period and click OK.
You can also open period settings by double clicking the contents of the
Date, Time column.
6.16.3.4. Enabling filters
Using the Select button or the More- Select menu item (All Selection
-actions) you can manage the selection of log events. The screen displays
the selection settings.

Fig. 61. Event log filter settings

You can set filters by period, user, event, computer name, connection num-
ber, event importance level, or comment. When setting a filter by period,
note the following:
• The filter is set for specific time
• When manually editing the starting or ending date, you need to speci-
fy the time as well
• When choosing the starting or ending date from the calendar, the time
is set automatically: for the field from: time is set to 0:00:00; for the
field to: time is set to 23:59:50
• When selecting a period using ... button, the time is set to the begin-
ning of the first day of the period and to the end of the last day of the
period.
If multiple types of applications were running, you can indicate in the list of
applications which events of which applications are filtered.
The event list indicates which types of events are filtered.
The Data group contains data for event filtering. Information on events is
presented in the Metadata, Data, and Data presentation columns.
The Metadata field contains a list of metadata presented in the configura-
tion. Select check boxes for the metadata items to use in filters.
In the Data field, an infobase object to use for event filters is selected.
The Data presentation field contains the string presentation.
In the Other group, additional selection parameters are indicated:
• Transaction status- The transaction statuses are selected.
• A transaction- indicates a specific transaction.
• Sessions- indicate session numbers (separated by commas).
• The working servers -are selected by the central servers of the clus-
ters (for the client-server version of the work).
• The main IP ports- are the IP ports of the cluster managers (for the
client-server operation).
• Auxiliary IP ports- select the auxiliary ports of the cluster managers
(for the client-server version of the work).
Click OK to set the filters.
The filter preview is displayed to the right of the Filter button. The filter
preview is preceded by Disable: hyperlink. Clicking on this hyperlink disa-
bles filter.

6.16.4. Delete marked objects

Deletion of marked objects is a multi-stage procedure. The stages are strict-
ly consequential. Before each stage, you can interrupt the procedure by
closing the window. The following describes in detail the actions of the
system and the user at each stage.

6.16.4.1. Selecting deletion option

At the first stage, you choose the deletion option: full or selective deletion.

Fig. 62. Delete marked objects

6.16.4.2. Full deletion
If you choose Full deletion, all marked objects will be deleted. Referential
integrity monitoring is enabled for deletion. Deletion may fail for some of
the objects, since some of them can be referenced by other objects.
The list of objects that were not deleted (if any) is displayed after the dele-
tion procedure is completed.

6.16.4.3. Selective deletion

If you choose Selective deletion, a list of objects marked for deletion will
be generated. The list of infobase objects marked for deletion will be dis-
played.
Select check boxes for any objects you want to delete.
If a check box is selected for an object in the list, this means that the object
will be deleted.

Fig. 63. List of objects marked for deletion

Selecting a check box in this list does not set a deletion mark for an object.
Likewise, clearing a check box in this list does not remove a deletion mark
from an object.
Double-click on an object to open the form of this object. This allows you
to view objects and decide whether they need to be deleted.
At this stage, you can switch to other windows and modes, or make any
corrections, without closing the object deletion list.
To delete the objects, click Delete. Referential integrity monitoring is ena-
bled for deletion. Deletion may fail for some of the objects, since some of
them can be referenced by other objects.

6.16.4.4. List of not deleted objects

If the infobase contains references to objects selected in the deletion list, a
warning is displayed: Cannot delete objects: <number>, because they
are referred by other infobase objects. These objects will not be deleted.
Click Next to display a list of not deleted objects, containing a list of de-
tected references. References are displayed for the selected object.

Fig. 64. List of not deleted objects

When you select a reference from the list, you can open it for viewing and
editing. This allows you to make changes to the object (apply another refer-
ence) so that the marked object can be deleted.
To exit the marked object deletion mode, click Close.

6.16.5. Find references to objects

This mode allows the system administrator to find objects that refer to the
selected object.
In this mode, the user can select an object and get a list of references to it
from other infobase objects.

Fig. 65. Searching for references to the object

Select an object in the Object field and click Find references. All infobase
objects are searched for references to the specified object (determined by
application). After completing the search, you can analyze the found refer-
ences. To open a reference form, click Open (if allowed) or click the hyper-
link. To search for references to an item of Found references list, open the
context menu for the selected line and select the Find references com-
mand. This opens an object reference search window and starts the search
for references to the objects.
At this stage, you can switch to other windows and modes, without closing
the search window.

6.16.6. Document posting

This service performs batch document posting or reposting, or restoration of
sequences.

6.16.6.1. Document posting

Document posting function is used to post documents of selected types
within the specified period.

Fig. 66. Document posting

In the upper part of the window, in the Period field, a document posting
period is specified. To set the posting period, select a standard period or
click Custom period and set the period manually. If you clear both bounda-
ries of the custom period, the posting will performed without any period
restrictions (indicated by a message to the right of the period selection
field).
The document posting window contains a list of the types of documents that
can be posted. The list of documents includes only those types of docu-
ments for which the current user has the InteractivePosting right.
The list of selected documents to be posted is edited by double-clicking a
document or by click the Add >, Add all >>, < Remove, and << Re-
move all buttons (multiple selection is available).
Above the list of document types there are check boxes determining which
documents will be posted: posted documents (will be reposted), unposted
documents, or both.
After setting all the necessary parameters, click Post. Before posting the
document, the date of the first and last posted document is determined,
based on the posting mode and the list of posted documents.
When posting a batch of documents, the documents marked for deletion are
not posted, even if they satisfy the posting conditions. If an error occurs
during document posting, the system behavior depends on the value of the
Stop posting if an error occurs check box. If the check box is selected,
posting will be aborted. If the check box is cleared (default value), posting
will proceed and the documents that were posted with errors will be saved.
Once the posting is complete, the number of posted documents is displayed.
If any errors were detected during the procedure, a form containing a list of
documents with errors is opened.

Fig. 67. Documents with posting errors

If the error list contains nothing but Document posting error message, this
means that an error occurred during document posting but the document did
not generate any error messages.
Double-clicking the line with the document name opens it for viewing.
During the posting, the status pane displays information about the actual
document posting period, the current posting date, and the total number of
posted documents.
You can abort the document posting procedure by pressing Ctrl + Break.
6.16.6.2. Restoring sequences
All documents in the 1C: Enterprise form a single chronological sequence.
Each document has a date and time. Even if two documents have the same
date and the same time, they are still arranged in a sequence, determined by
the order of their entry into the system. Document date and time are subject
to change. Thus, regardless of the order of entry, documents can be ar-
ranged in a sequence that reflects the actual order of events that occurred in
the economic life of the company.
During posting, a 1C:Enterprise document is registered in several account-
ing systems supported by 1C:Enterprise.
The algorithm of document posting, as a rule, reflects data recorded in the
document attributes. However, in some situations, the document posting
algorithm also analyzes and uses the current totals. For example, if a docu-
ment writes off goods or materials at average cost, the posting algorithm
will analyze the balances of goods (materials) at the time of the document in
order to determine the write-off amount. If the write-off is performed using
LIFO or FIFO method, the posting algorithm will analyze the existing bal-
ances of goods (materials) by lots at the time (position) of the document.
Obviously, documents that use these totals (for example, totals by batches)
should be posted in strict sequential order. However, in practice, it is often
necessary to back-enter or back-correct the documents due to data input
errors and late receipt of documents. Back-entering or back-correcting a
document invalidates all register records generated by the documents fol-
lowing this one. For example, if it became clear that the quantity of goods
was incorrectly indicated in one of the incoming invoices at the beginning
of the month, then in all subsequent expenditure invoices writing off exist-
ing lots, it is necessary to re-analyze the balances considering the changes
made and re-record movements of the registers. Therefore, all documents
that analyze the balances following the corrected document must be re-
posted.
For automatic control of document reposting, document sequences are used.
Each sequence of entered documents provides control over the posting order
of the documents of the specified types. Thus, there may be several inde-
pendent sequences in 1C:Enterprise.
The sequence recovery mode allows you to automatically repost all docu-
ments related to the sequence, from the current position of the sequence
border to the specified moment. The current position of the sequence
boundary is determined by the date from which the document posting se-
quence must be restored.

Fig. 68. Restoring document sequence

The table displays a list of existing sequences for which the current user has
the Edit right. In the Border column, the current position of the sequence
boundary is displayed for each sequence. To restore all sequences, click
Restore all.
To restore one or several sequences, click Restore. All documents related
to the selected sequences will be reposted, starting from the earliest border
of the selected sequences and up to the specified position . If multiple se-
quences are selected, the selected sequences will be restored in the listed
order. If a single sequence is selected, it will be restored.
The Stop restoring sequences if an error occurs check box determines
the system behavior if an error is detected during the sequence recovery. If
the check box is cleared (default value), sequence recovery will proceed
regardless of the errors. Otherwise, the process will be stopped if any error
is detected.
You can abort the sequence recovery procedure by pressing Ctrl + Break.

6.16.7. Totals management

6.16.7.1. General information
This service performs regulatory actions with registers available in the ap-
plication. The list of actions includes enabling and disabling totals, recalcu-
lating totals, working with aggregates, and more.
All work with the results is divided into two sets of possibilities:
 • Frequently used features (opened by default)- This mode provides
simple means for performing the most frequently used actions with
register totals.
• Full capabilities- provides full access to the management capabilities
of the totals and aggregates of the application solution.
The list includes only those accumulation and accounting registers for
which the current user has the right to Manage the Results, and for
which all separators are used in the current session, which they are part of
(if separators exist in the application solution). Both totals modes work with
this list.
To switch between the modes, use the hyperlink in the lower right part of
the window. The current mode is memorized so that you automatically
switch to this mode the next time you use the totals management.
Further we will describe both modes in more detail.

6.16.7.2. Frequently used features

Frequently used features include setting a period of calculated totals, ena-
bling totals, restructuring and filling of aggregates, and obtaining optimal
aggregates.

Fig. 69. Outcome management- frequently used features

6.16.7.2.1. Set the period of calculated totals

This operation sets a period of calculated totals for all accumulation and
accounting registers that have totals enabled. For accumulation registers, the
period is set to the end date of the previous month, since the most typical
scenario of using the accumulation register is to get current balances. For
the accounting registers, the period will be set at the end date of the cur-
rent month, since the most typical scenario of using the accounting register
is to get turnovers for the current month.
TIP. You can run this operation at the beginning of each month to improve
the performance of the registers.

6.16.7.2.2. Enable totals usage

This operation enables using totals for all registers that have totals disabled,
except for current accumulation registers that are in aggregate mode.
TIP. This may be necessary, for example, when a massive register data ed-
iting operation is aborted, disabling the usage of totals to speed up work.

6.16.7.2.3. Rebuild and fill

This operation rebuilds and fills all current accumulation registers that have
the aggregate mode enabled and their usage is allowed.
TIP. This operation can be scheduled when using aggregates.

6.16.7.2.4. Get optimal aggregates

Calculates optimal aggregates for all current accumulation registers that
have aggregates specified in Designer.
TIP. You can run this operation both before enabling the aggregates usage
and during 1C:Enterprise operation.

6.16.7.3. All available features

All features mode allows you to get full access to all tools for working with
totals (Totals tab) and aggregates (Aggregates tab) of accumulation regis-
ters and accounting registers.
6.16.7.3.1. Operations with totals
The Totals tab shows the list of accumulation, accounting and information
registers (that have totals enabled) available to the user.

Fig. 70. All available features of totals management

The list shows the current state of the system registers. The checkboxes
indicate those modes that are currently enabled for each register:
• Totals- of the use of totals;
• Current totals- state of use of current totals;
• Minimum period of totals- minimum stored period of totals of the
register of accumulation;
• The period of the totals- is the maximum stored period of the totals
of the accumulation register;
• Split totals-; state split totals;
• Units / totals-current mode of using aggregates or totals for current
accumulation registers for which aggregates are specified in the con-
figurator.
Units / totals current mode of using aggregates or totals for current accumu-
lation registers for which aggregates are specified in the configurator. So,
for example, the gray color in the Totals splitting column means that the
totals splitting for the selected register is prohibited in Designer.
You can enable or disable modes or calculate totals here.
Multiple selection is available for all commands. Each command you run
will be executed for all selected registers. If an error is detected during the
execution of the command, the system behavior depends on the state of the
Stop data processor on the first error check box. If the check box is
cleared (default value), the data processor will continue to run regardless of
the error and all selected registers will be processed; otherwise, the data
processor will be aborted.
If the register supports the aggregate mode, double-clicking the contents of
the Aggregates / Totals column will open the Aggregates tab and put the
mouse pointer on the register with the same name as on the Totals tab.

6.16.7.3.2. Operations with aggregates

The tools on the Aggregates tab are intended for managing aggregates of
current accumulation registers.

Fig. 71. All available features of aggregates management

The top list contains current accumulation registers of the current configura-
tion that have aggregates specified in Designer. The bottom list (Register
aggregates... :) contains aggregates specified for the register, aggregate
usage indicators, and statistics on aggregates.
You can switch the register usage mode, enable or disable aggregates usage,
or perform basic operations with aggregates.
When calculating the optimal aggregates, a directory will be requested in
which the file with the list of optimal aggregates for the selected register
will be placed. The register will be marked in bold if it is recommended to
replace the existing aggregates with a calculated list of optimal aggregates.
When saving the optimal aggregates, the file name is generated as follows:
AggregateName.xml. So, for the Sales register of fig. 71, the optimal ag-
gregates file name will be Sales.xml.
6.16.8. Full-text search
management
1C:Enterprise supports full-text data search capabilities. Forms for entering
the search conditions are designed during configuration development.

Fig. 72. Full-text search management mode

To enable or disable the full-text search, use tumbler Full-text search:. To
perform this operation, exclusive access to the infobase is required. It means
that you cannot enable or disable the full-text search while any other users
are logged on to the infobase.
The search index is generated after clicking Update index. To optimize the
index generation procedure, main and additional indexes are used. Addi-
tional index is generated when users enter data. It contains information on
the data entered after the last update of the main index.
Index clearing (click Clear index to start) is used to delete an index, for
example, to free the disk space occupied by the index files. You may need
to rebuild the index after clearing.
These buttons are only available for users with the
AdministrativeFunctions right.
The last indexing date is indicated in the Index created on field.

Fig. 73. Additional parameters

Clicking the Additional parameters button opens the management of the
following parameters:
• Maximum size of the data indexed - enables to set the maximum size
of the data (indexed by the full-text search and) stored in one attribute
of the configuration object.
 Default value:
 for compatibility mode for version 8.3.7 or earlier. Equal to 0.
Meaning there are no size limits of the objects indexed.
 for compatibility mode for version 8.3.8 or later. Equal to 1 MB.
Means that the full-text search will not index the objects that are
larger than 1 Megabyte.
• Maximum number of the indexing jobs - enables to set the number of
the concurrently running background jobs that refresh the index of the
full-text search.
Behavior of the software during installation of the default mode de-
pends on the compatibility mode of the configuration:
 version 8.3.11 or earlier - indexation is carried out by one back-
ground job.
 version 8.3.12 or later - background jobs number for index refresh-
ing is chosen automatically. At that their number cannot exceed 4.
This setting is relevant only for client/server mode.
• If the compound words break down mode - is enabled, the full-text
search will search for the meaningful parts of the compound words.
Works only for the Russian language by default. Other languages re-
quire formation of the custom full-text search dictionary. After chang-
ing the parameter value, you need to rebuild the full-text search index.
For example, when searching for the word "bread":
 Breakdown of compound words is enabled - the "MosBread" word
will be found.
 Breakdown of compound words is turned off - the word
"MosBread" will not be found.
The changes apply after clicking Set. The values are only applied for the
parameters whose new values differ from the values set currently. The but-
ton is only available for users with Administration right and with the
full-text search activated.
6.16.9. Configuration extensions
management
This dialog box manages the configuration extensions in 1C:Enterprise
mode.

Fig. 74. Configuration extension management

Dialog box for configuration extensions management is available for users
with the ConfigurationExtensionsManagement right. Users may
need the Administration right to specify the security profile for the
extensions activated.
Standard actions with the extensions can be performed here:
• Add a new configuration extension from file (Add). When adding the
extension, the unsafe actions protection system displays a warning
message.

Fig. 75. Warning when adding an extension

After adding the extension, you can select Protect from unsafe ac-
tions check box for it. If the check box is cleared, the unsafe actions
protection system will not prompt the user while adding the extension.
• Delete an attached extension (Delete). When deleting remember that
the data extension deletion is done in two steps. First step is to deacti-
 vate the extension - check box removed Active. Second step — the ex-
tension can be removed from the infobase.
When deleting an inactive data extension, you will be prompted to
confirm the deletion.
• Deactivate the extension without deleting it from the infobase. The
Active check box is designed for this purpose. The extensions with
this check box cleated will not load when the session starts. Deactivat-
ed extension (from the point of view of the internal components) is
equal to the deleted extension, with the difference for the deactivated
extension that stored data (for data extension) structures are not delet-
ed.
• Replace the existing extension version with a new version (Import).
• Save configuration extension to file (Save).
• Update the list of extensions.
• Restart the client application to apply the changes made to the exten-
sions (Restart). A restart is executed without additional warnings.
Using the Manage main roles button, you can manage the assignment of
the main roles of permissions to users.
Не удается отобразить связанный рисунок. Возможно, этот файл был перемещен, переименован или удален. Убедитесь, что ссылка указывает на правильный файл и верное размещение.

Fig. 76. Default role management

This dialog displays information that a user has been assigned all the main
roles of a particular extension. Further:
 Enabled check box - The user has all the main roles of the selected ex-
tension installed.
 Disabled check box - the user does not have any of the main roles of the
selected extension.
 Check box in the third state (grey) - Some of the main roles of the ex-
tension are shown to the user.
All extensions column is designed to display (and install) the main roles of
all extensions for the specific user. All users string is designed to display
(and install) the main roles of the specific extension for all users.
Assigning main roles to users can be done in the following ways:
• In the extension management dialog, using the Use main roles for all
users check box. This check box leads to assignment of all the main
roles of selected extension to all the users. Exactly the same action
can be executed in the Management of the main roles dialog by setting
the check box in the Use main roles for all users string in the col-
umn with the desired extension.
• Manually indicate to a specific user that he is assigned all the main
roles of the extension. So, in the example on fig. 76, all the main roles
from Extension1 and Extension2 are assigned to the Adminis-
trator user. At the same time, one of the main roles Extension1
was assigned to the Seller user, and this was done in the configurator.
Therefore, for the Seller user, the check box in the Extension1
column is displayed in the third state (gray square).
• Specify that all infobase users need to establish the main roles of any
extension by setting the check box at the intersection of the All users
string and the column of the desired extension. In this case, the main
roles will be assigned to all current users of the infobase. This action
will not apply to new users. In order for the extension main roles to be
distributed to all users (including those that do not currently exist), se-
lect the Use main roles for all users check box in the column with
the desired extension.
• Indicate that a specific user needs all the main roles of all extensions
connected to the configuration. This can be done by setting the check
box at the intersection of the string with the username and the All ex-
tensions column. For example, as indicated by the Administrator us-
er in the figure above.
• You can set to all current users the main roles of all extensions using
the check box located at the intersection of the All users string and the
All extensions column.
• Set to all users (including those that are not already existing) the main
roles of all extensions using the check box located at the intersection
of the Use main roles for all users string and the All extensions
column. Or manually set the check box in the Use main roles for all
users column (in the extension list) for all extensions.
In case when the security profiles are to be setup (on 1C:Enterprise server),
the Details group should be used, which contains the value of the checksum
(field Checksum), necessary for filling the property of the same name in
the description of the available external module.
You can check whether an extension (or all extensions) is compatible with
the current infobase. Use commands Check applicability and Check ap-
plicability for all in menu More for this. You also can check the applicabil-
ity when adding and loading the extensions. The same-named check box in
the extensions list form is used for this purpose.
Configuration extension can be added for the whole infobase as well as for
a particular data area. The extension applicability scope is indicated in the
lower part of the form (field Scope when adding the configuration ex-
tension). Value of this property is defined as follows:
• Configuration has no separators that can separate the extensions. In
this case, the extension can be only attached with scope Infobase.
• In the current session, all separators that can separate extensions are
conditionally disabled. In this case, the extension can be only attached
with scope Infobase.
• In the current session, separators that can separate configuration ex-
tensions are used. In this case, the extension can be only attached with
scope Data separation.
• In the current session, separators that can separate configuration ex-
tensions are not used. In this case, the extension can be attached with
scope Infobase or Data separation. In this case, the extension scope
can be changed, excluding the case when the extension extends data.
For data extensions, the scope cannot be changed.
• Besides, one infobase cannot contain the extension that is attached
with the scope Infobase and with the scope Data separation at the
same time.
See also:
• Separation of configuration extensions.

6.16.10. Collaboration system

management
This standard function performs administrative actions to interact with col-
laboration system:
1. Register the current infobase in 1C:Dialog service to be able to use
collaboration system.
2. Cancel application registration in the service.
3. Perform/cancel merging of the collaboration system applications.
4. Lock/unlock users of the collaboration system.
To be able to register the infobase, the user needs
CollaborationSystemInfobaseRegistration right.
The computers running the collaboration system need access to
wss://1cdialog.com using IP port 443.
If the application is not yet registered in 1C:Dialog, you are immediately
prompted to register.

Fig. 77. Registering an application

The email of the subscriber owner and representation of the application reg-
istered are entered. After clicking Get code, an email message containing
the registration code issued by the service will be sent to the provided email.
Email message with the registration code will be sent from the email ad-
dress [email protected]. Enter the code into the Registration code field
and click Register.

Fig. 78. Entering registration code

A successful registration message will be displayed.
After registration completion and in the case if the application is already
registered in the collaboration system, a form opens that offers the follow-
ing actions: set up shared access to the application, manage user blocking
and unregister this application.

Fig. 79. Starting form

If you click Application shared use hyperlink, a shared usage settings
form opens.
Не удается отобразить связанный рисунок. Возможно, этот файл был перемещен, переименован или удален. Убедитесь, что ссылка указывает на правильный файл и верное размещение.

Fig. 80. Shared use of applications

This form lists all applications pairs and rules of matching the users and the
discussion contexts.
If you need to join the applications, click Add.
Не удается отобразить связанный рисунок. Возможно, этот файл был перемещен, переименован или удален. Убедитесь, что ссылка указывает на правильный файл и верное размещение.

Fig. 81. Choosing applications for shared use

This dialog box shows the list of all applications of the current subscriber
owner. First, select two or more applications to be joined. Then, indicate the
method of users matching and necessity to match the conversation contexts.
Clicking Ok will initiate the operation and will update the list of shared
applications.
Clicking Cancel will cancel the shared use of two applications.
Clicking the Users hyperlink opens a form with a list of infobase users.
Не удается отобразить связанный рисунок. Возможно, этот файл был перемещен, переименован или удален. Убедитесь, что ссылка указывает на правильный файл и верное размещение.

Fig. 82. Collaboration system users

Users are allocated according to their status in the opened list:
 • The current user is highlighted in bold. In this fig. 82, the user is the
Administrator.
• Those users who cannot be blocked are marked in gray font. Such us-
ers are present only in the infobase. In the fig. 82, Anonymous is an
example of such a user.
• Locked users are indicated by the crossed-out font, and the Purchas-
ing manager is an example of such a user.
• Normal font shows users who are present in the collaboration system
and who can be locked. In fig. 82, an example of such a user is For-
mer employee.
Infobase and Collaboration system columns, respectively, show the pres-
ence of the user in the infobase itself and in the collaboration system.
Locked column displays the user’s locked status. Lock and Unlock buttons
allow you to perform homonym operations with the current user or with
selected users.
When clicking the hyperlink Cancel registration the user is prompted to
confirm this action.

Fig. 83. Confirmation of registration cancelling

After clicking Cancel registration, you cannot use the collaboration system
in the infobase any more. To re-enable the collaboration system, you need
to repeat the registration procedure. After the re-registration, your access to
the discussions and messages will be restored.
6.16.11. Database copy
management
This standard function is designed to work with database copies. Database
copies are used to operate the data accelerator mechanism. Detailed descrip-
tion of the database copy mechanism and Data accelerator.
Не удается отобразить связанный рисунок. Возможно, этот файл был перемещен, переименован или удален. Убедитесь, что ссылка указывает на правильный файл и верное размещение.

Fig. 84. Database copy management

On the left side of the form there is a list of copies of the current database.
On the right side -, a list of objects whose tables will be copied to the copy
is indicated for each copy.
When you create another copy, a form to edit database copy is displayed.
Не удается отобразить связанный рисунок. Возможно, этот файл был перемещен, переименован или удален. Убедитесь, что ссылка указывает на правильный файл и верное размещение.

Fig. 85. Another database copy

When creating a new copy, you should specify the following parameters:
• A database copy name. Used to simplify the identification of the cre-
ated copy by maintenance personnel. To access in 1C:Enterprise lan-
guage, this copy property is needed.
• Built-in Data accelerator. Check this check box, if the created base
will be used for the Data accelerator.
• Replication type. This parameter indicates who will be responsible
for data replication (including creating tables of the desired structure
in the copy).
• Database server, DBMS type and Database allow you to specify
the address and type of DBMS where the created copy will be placed,
as well as the name of the database with the copy.
IMPORTANT! It is not recommended to specify the parameters of the
working database as the parameters of the database used as a copy. This will
cause the working database to become unusable. In other words, the name
of the database that acts as a copy must not match with the name of the
working database.
• User and Password properties are used to specify the parameters of
the user on behalf of whom the connection in the DBMS copy will be
made. The specified user must have rights to create and delete tables
in the DBMS copy, as well as to execute all actions with created tables
(read, create, modify, delete).
 • Create database check box shows necessity to the system on creat-
ing a database in the event when there is no database with specified
name (Databaseproperty) in the DBMS copy.
As soon as an entry is made with database copy details, the following prop-
erties can no longer be modified: Name, Built-In Data Accelerator
and Replication Kind. To change these parameters of the copy, delete and
re-create information about the database copy. The remaining parameters
can be modified in a conventional manner.
As soon as shared parameters are specified for a copy, you can as well spec-
ify data stored in this copy. Data stored in a copy can be modified any time.
For that purpose, open a database copy for editing. Parameters can be modi-
fied in a dialog box which is similar to that used to create a database copy.
Не удается отобразить связанный рисунок. Возможно, этот файл был перемещен, переименован или удален. Убедитесь, что ссылка указывает на правильный файл и верное размещение.

Fig. 86. Editing copy content

When you edit a database copy content, specify objects you need to store
therein. As such, check the check box to the right (configuration object
tree). To define attributes of selected objects to be saved in a copy, use
check boxes in a group with number 1 (see the above figure). Group 1
check boxes are designed to define location of attributes in a copy in gen-
eral.
Similarly, location of attributes per configuration object can be defined. For
this purpose, use a dialog box which is displayed as soon as you press but-
ton 2.
Не удается отобразить связанный рисунок. Возможно, этот файл был перемещен, переименован или удален. Убедитесь, что ссылка указывает на правильный файл и верное размещение.

Fig. 87. Filter and group properties

In this dialog box, properties with number 1 assigned thereto are similar to
those available in property group 1 on fig. 86. Group 2 (see fig. 87) contains
filter parameters intended to set a filter by period for configuration objects
which support this action. If filter by period is not supported by a configura-
tion object, - no fields from group 2 are available in configuration object
group properties filter and setting dialog boxes (fig. 87).
If use parameters are specified for a configuration object which are dissimi-
lar to default values, image 4 is displayed in the metadata tree for the said
configuration object (see fig. 86). If filter by period is specified for a con-
figuration object, image 3 is displayed in the metadata tree for the said con-
figuration object (see fig. 86).
Press OK in the editing tree of a database copy to save modified parameters
in the main database and delete disabled objects tables from a database
copy. To physically create tables (and fill in the same with initial data),
-press Update Copy, as soon as editing of a database copy is over.
6.16.12. Data change history
Data change history standard function allows you to view the data change
history. In terms of features to view the history, this standard function is
similar to the form that opens by the History of changes command in the
form of the object element for which the data history is included. In terms
of features to filter and functions executed -, the standard function provides
more options.
Не удается отобразить связанный рисунок. Возможно, этот файл был перемещен, переименован или удален. Убедитесь, что ссылка указывает на правильный файл и верное размещение.

Fig. 88. Data change history

Before you start viewing the data history, you need to set the filter. A
minimum filter that will allow you to continue viewing the history -filter by
metadata type. This is due to the fact that the platform does not allow you to
get a data history without filter by metadata type or data object. Reading the
data history is executed after the filter has been set. In addition to filter, the
size of the read portion of data is defined by the contents of the Number of
displayed history elements field. This field will help in the case when too
much records fall under the conditions of a given filter, but you need to see
only a limited number. Specified number of records in sorting order will be
filtered to the list. In standard processing, when receiving a history, the sort
is used by default:
• When filter by metadata type: Date field in descending order,
VersionNumber field in descending order.
• When filter by metadata object: VersionNumber field in descend-
ing order.
Special focus should be paid to the Fields and the Extended filter by fields
tabs. The table on the Fields tab contains the current structure of the
selected type of metadata. The table fills in after selecting a value in the
Metadata field. Thus, this table allows you to set the filter for the current
structure of the configuration object. In the event that you want to use
already deleted attributes in the filter or the old names of the renamed
attributes -, use the Extended filter by fields tab. In general, the purpose of
the tab corresponds to the purpose of the Fields tab, but the data paths can
be specified manually and these paths can be arbitrary.
After the filer has been set, the data history will be received and displayed.
In the list received, there is a feature to execute some operations:
• Open version - allows you to open a report that displays information
about the version on which the cursor is in the list.
• Compare with previous - opens a comparison report of the version
on which the cursor is in the list and the version with the previous
number.
• Compare with current - opens a comparison report of the version on
which the cursor is in the list and the current version of the object.
• Compare version - allows you to compare two arbitrary versions of
the object.
• Switch to version - opens the form of the object, which is filled with
the data of the selected version. To complete the switching to the se-
lected version, you need to save the changes.
You can change the version comment directly in the list. To do this, just go
to the Comment column and edit the value. To change the version com-
ment, the user who edits the comment, must have the necessary access
rights.
Reports that are opened from the standard function take into account the
fact that the Main data form of the data history version and the Main
form of differences in the data history versions configuration properties
can be filled in the configuration. Standard processing will call those forms
that are specified in a particular application.
Another feature of the standard function of viewing data history is the abil-
ity to update the data history itself. For a separate history update, use the
Update history command. Executing a command from the menu will up-
date the data history for all configuration objects. It also provides the option
to update the data history each time the version list is updated. First, the
history will be updated, and then - the list of versions in the form. To man-
age this behavior, the Update history when updating the list check box
is designed. When setting this check box, the history is updated in accord-
ance with the filter set as follows:
• If a specific data object is specified in the filter, -the history will be
updated only for this object.
• If only the type of metadata is specified in the filter, - the history will
be updated across the entire type of metadata (only in the compatibil-
ity mode of the application of Version 8.3.14 and later).
Use a standard data processor to perform service operations. As such, use
Data History Management dialog box which is available in More menu in
the main form of a standard data processor.
Не удается отобразить связанный рисунок. Возможно, этот файл был перемещен, переименован или удален. Убедитесь, что ссылка указывает на правильный файл и верное размещение.

Fig. 89. Data history management

Let's take a closer look at features supported by this dialog box. At the top
of this dialog box, you can see description of data which will be processed
when you run any proper command. It is displayed after Will Be Pro-
cessed:. Further, you can see three commands (with respective parameters)
which can be run in this dialog box:
• Refresh data history. Technically, this command is intended to call
DataHistory.UpdateHistory() method. However, method
parameters are defined using check boxes to the right of this button.
Essentially, data history is updated (similar to More- Update History
command). Additionally, a user is able to manage method parameters,
while no command affords the said opportunity. Method parameters
will be assigned default values.
• Process after writing versions. This command is intended to force-
fully call a data processor, as soon as data history version is written.
Whenever you run this command, postprocessing sequence is handled
for data defined by the existing filter of a standard data processor.
• Delete from data processor after versions are written. This
command allows it to restrict the queue size for processed objects af-
ter writing a version which is processed by a prior command. All ver-
sions created before the date specified as a command parameter will
be deleted from the queue.
If any of the aforesaid commands is unavailable due to the existing filter, -
command button is disabled.
Chapter 7.
Standalone server

7.1. General information

Standalone server - This is a special server application that is designed to
provide work with the infobase of client applications: thin client, web client,
mobile client. The interaction of the client application and the standalone
server occurs via the HTTP protocol. At each moment of time, a standalone
server allows you to work with one database. A standalone server provides
the same list of features as a server cluster of the same version, with the
exception of administration and management tools. A standalone server
contains a built-in web server. Therefore, the publication of an infobase
does not require the presence of an external (relative to the 1C:Enterprise
system) web server. A special command line utility is designed to adminis-
ter a standalone server (ibcmd). The standalone server supports working
with the database, which is located both in the DBMS (from the list of sup-
ported ones) and in the 1Cv8.1CD file. In other words, a standalone server
allows you to work with the file version of the infobase.
A standalone server is an application (ibsrv), which implements everything
necessary for the operation of the 1C:Enterprise server. During its opera-
tion, the standalone server uses the components of the installed version
"1C:Enterprise" of its own version.
The simultaneous operation of multiple instances of the standalone server is
supported.

7.2. Specifics and limitations

A standalone server does not support the following features:
• Serving multiple infobases with one standalone server.
• Operation of several standalone servers with one infobase.
• Changing the parameters of a standalone server during its (standalone
server) operation.
• Operation with the infobase using a thick client.
• Operation with the infobase in the Configurator mode.
• Operation with the infobase using an external connection (COM con-
nection).
• Management of a standalone server using a ras server.
 • For a standalone server, there are no graphical management tools
(analogous to the cluster console).
• Dynamic update of database configuration.
• Using background restructuring.
• Server management using the V83.ComConnector COM object.
• Work on the HTTPS protocol. You can use the HTTPS protocol when
using an intermediate web server between a standalone server and a
client application.
• Debugging over TCP/IP protocol.
• Using operating system authentication.

7.3. Mechanism usage

7.3.1. System requirements
The system requirements of a standalone server are similar to the system
requirements of 1C:Enterprise server cluster (including when operating with
a file version of the infobase).

7.3.2. Setting
A standalone server is installed at the same time as the 1C:Enterprise server
cluster. Separate actions to install a standalone server are not required.

7.3.3. Start and management of a

standalone server
7.3.3.1. General information
The standalone server and the server management utility are started from
the command line. All necessary parameters must be specified in the com-
mand line. Information about the execution of a given action is outputed to
a standard output stream (stdout). If successful, the return code is equal to
0. Otherwise, the return code is non-zero and an error message will be sent
to the standard error stream (stderr).
Both the standalone server (ibsrv) and the server management utility (ib-
cmd) contain a built-in help system. The documentation does not contain a
detailed description of all commands of start command line, but only typical
cases of use.
To get a reference information, you should use the following option for
running utilities:
ibsrv help
ibcmd help

When a standalone server (ibsrv) is running, connection to the database is

implemented in a shared mode.

7.3.3.2. Standalone server start

A standalone server can be started as a regular operating system application,
as well as an operating system service (for Windows OS) or in daemon
mode (for Linux OS).
A standalone server does not provide built-in tools for registering itself as a
service of the operating system. Also, management tools (start and stop) are
not provided by the service. For these operations, you should use the operat-
ing system tools (sc utility).
When starting a standalone server, do not forget about following features:
• When starting a stand-alone server, the parameters necessary for its
(server) operation are defined as follows:
 The values of all parameters specified on the start command line
are got.
 An attempt to get the values of the remaining parameters using the
server configuration file is made.
 If using the server configuration file it was not possible to get the
values of the remaining parameters, -the default values will be
used.
 The parameter values specified in the start command line have pri-
ority over the values from the configuration file.
• The server configuration file is created by a specific command (or
completely manually). This file does not have a default location.
Therefore, in order to use parameters of the configuration file for
standalone server, - the path to it should be specified explicitly.
• No more than one instance of a standalone server can work with one
data directory. For simultaneous use of multiple copies of standalone
server, you must explicitly specify the --data parameter for each
server instance.
When describing the start command line, it is assumed that the start is exe-
cuted from the bin directory of the required version of the 1C:Enterprise
system.
Application start, file option
Start of the standalone server to work with the file version of the infobase
located in the c:\db\standalone-server\demo directory is executed. All
parameters of the standalone server in this case will be set to the default
values.
ibsrv --db-path="c:\db\standalone-server\demo"

If you start the standalone server with absolutely no parameters, the

standalone server will attempt to start with the file version of the infobase,
which is located in the data directory by default.
Application start, client-server mode
The standalone server is started to work with the client-server mode of the
infobase, which has the following parameters:
• Microsoft SQL Server DBMS is used.
• To access the DBMS, the dbUser user with the dbUserPassword
password will be used.
• The database has a name in the dbName DBMS.
• It is assumed that the database exists and is truly a 1C:Enterprise data-
base.
ibsrv --dbms=mssqlserver --db-server=dbServerName --db-user=dbUser
--db-pwd=dbUserPassword --db-name=dbName

If both parameters (--db-path and --dbms) are not specified when

starting the standalone server, then the standalone server will be started with
the file infobase, which is located in the following directory:
 Windows OS: %LOCALAPPDATA%\1C\1cv8\standalone-
server\db-data.
 Linux: ~/.1cv8/standalone-server/db-data.
Server registration service (Windows OS)
In order to register a standalone server as a Windows OS service, you can
use the following command file (or take it as a basis for further upgrades).
Register-ss.bat file:
@echo off
rem %1 – 1C:Enterprise full version
rem %2 - instance number of the registered service
rem %3 - server configuration file location
set SrvcUserName=<standalone server user>
set SrvcUserPwd=<password of the standalone server user >
set SrvcName="Standalone server %2"
set BinPath="\"C:\Program Files\1cv8\%1\bin\ibsrv.exe\" --service -
-config=\"%~3\""
set Desctiption="1C:Enterprise 8.3 standalone server. Copy #%2"
sc stop %SrvcName%
sc delete %SrvcName%
sc create %SrvcName% binPath= %BinPath% start= auto obj=
%SrvcUserName% password= %SrvcUserPwd% displayname= %Desctiption%

When starting this command file, the following parameters are used:
1. The full version number of the 1C:Enterprise system from which a
standalone server will be used.
 2. The instance number of the service to register. In the above example,
the existence of a service with the given number is not checked. Due
to the fact that the standalone server serves one database, with this pa-
rameter you can register your OS service for each served infobase.
3. The full path to the configuration file for this instance of the
standalone server (must be enclosed in double quotes). In this configu-
ration file, all parameters with which the standalone server is to be
started (including database parameters) should be placed. Different
service instances must have their own configuration files.
Example of start of the command file (administrator rights are required):
register-ss.bat 8.3.14.1000 2 "d:\1C DB\standalone-
server\demo\demoma.yml"

After starting the command file with these parameters, the following actions
will be executed:
• Service Name: Standalone server 2;
• Displayed Name: 1C:Enterprise 8.3 standalone server. Copy #2;
• Version of 1C:Enterprise: 8.3.14.1000;
• Service start command line: "C:\Program
Files\1cv8\8.3.14.1000\bin\ibsrv.exe" --service --config="d:\1C
DB\standalone-server\demo\demoma.yml";
• Service start mode: Auto.
In this case, the following operating system commands should be used to
manage the service:
• Service start: sc start "Standalone server 2"
• Service stop: sc stop "Standalone server 2"
• Service deletion: sc delete "Standalone server 2"
By the time the service starts, the configuration file must contain all the
necessary parameters for starting the standalone server.
Server start in daemon mode (Linux OS)
To start a standalone server in daemon mode on Linux OS, execute the fol-
lowing command:
ibsrv --daemon --config="configuration file path"

By the time the standalone server starts in daemon mode, the configuration
file should contain all the necessary parameters for starting the standalone
server.

7.3.3.3. Standalone server management

The standalone server does not support changing its parameters during op-
eration. This means that the server settings that are changed in the
standalone server configuration file will be applied only after the server is
restarted. Thus, the contents of the configuration file of the standalone serv-
er instance can be changed at any time. But in order for the instance of the
standalone server working with this configuration file to apply the updated
settings, this instance of the standalone server must be restarted.
IMPORTANT! The standalone server during its operation does not inter-
fere with the management utility (ibcmd). Among other things, this means
that the operations of the ibcmd infobase command group can be exe-
cuted without interrupting the standalone server operation. Therefore, it is
recommended to stop the work of the standalone server before executing
various operations that can lead to negative consequences. Practically all
commands of the ibcmd infobase group can be referred to such com-
mands. create, restore, clear, config load, config apply.

7.3.4. Debugging using the

standalone server
The standalone server only supports debugging using the HTTP protocol.
To debug an application using the standalone server, you need to start the
debug server. The configurator is used as a "graphical console for manage-
ment" for debugging. The scheme of debugging is as follows:
• The debug server starts.
• The standalone server starts. For this server an option of using the de-
bug server, started in the previous step is indicated.
• The configurator is started for the infobase into which the configura-
tion is imported, exactly equal to the configuration that is imported in-
to the infobase that the standalone server serves.
• The configurator infobase will be used only to get the configuration
structure and source texts, the data during debugging will be got from
the debugged database.
When starting the standalone server, you must specify the location of the
debug server. This is done using the --debug=<dbgs-address>
command. The debug server address is formed from the name of the com-
puter on which the debug server is running, and the port number specified at
startup. To start by default, use the http://localhost:1550 address.
The standalone server can be started with the address of the debug server
when the debug server is not physically started. The debug server itself can
be started later, if necessary.
In the configurator, you need to configure the debug server use:
• Dialog open Main menu - Service - Parameters - Debugg.
• Debug protocol property is set to the HTTP protocol debugging
value.
 • In the Debug server group, specify Use remote debug server. The
debug server address is specified in the Remote debug server ad-
dress property.
• In the Infobase name group, Use specified infobase name is indi-
cated. The Infobase name property specifies the infobase name,
which is indicated in the infobase.name property of the
standalone server configuration file (or using the --name command
of the command line of the standalone server start.)
• If necessary, the configurator is restarted.
• The debugging process is no different from when you are not using a
standalone server. As an exception, it should be noted only that the
changed configuration (based on debugging results) must not only be
saved in the configurator, but also update the standalone server data-
base with this configuration to continue working or debugging.

7.4. Examples of managing and

starting the standalone
server
7.4.1. General information
This section contains examples of managing and starting the standalone
server. It should be understood that the examples given in this section are
not complete. They are intended to demonstrate some features of working
with the standalone server.
When configuring the standalone server operation parameters, it is always
recommended to explicitly set the name of the infobase with which the
standalone server works. This should be done with:
• Parameter of the --name command line.
• Parameters infobase.name of the file of the standalone server
configuration.
In the examples, there may be no explicit indication of the name of the in-
fobase, which was done in order to reduce the size of the examples. When
execute real actions, is strongly recommended to specify the infobase name.
 7.4.2. Create a configuration file
using command line
parameters
ibcmd server config init --dbms=postgresql --db-server=dbServerName
--db-user=dbUser --db-pwd=dbUserPassword --db-name=dbName --
name=docsIB --base=webAccess

As a result of execution of this command, the following configuration file

will be outputed to the standard output stream (stdout):
server:
address: localhost
port:
database:
dbms: PostgreSQL
server: dbServerName
name: dbName
user: dbUser
password: dbUserPassword
infobase:
id: 7b88938e-5aa8-4933-afea-8a9ec121724f
name: docsIB
distribute-licenses: yes
schedule-jobs: allow
http:
base: webAccess

This information can be recorded to the file or with the help of the --out
parameter of the ibcmd utility or using the stdout redirection to the file: >
file.ext.
It is also worth noting that the stand-alone server running with such a con-
figuration file will start the web client when accessing the
http://localhost:8314/webAccess address.

7.4.3. Create a configuration file

by the parameters of the
server infobase
ibcmd server config import --cluster-data="d:\1C srvinfo" --
name=demoma --out=d:\ss-cfgs\demoma.yml

As a result of this command, the following configuration will be placed in

the d:\ss-cfgs\demoma.yml configuration file:
server:
address: localhost
port: 8314
database:
dbms: MSSQLServer
server: <server name>
name: <database name>
user: sa
password: <user password>
infobase:
id: 1a39d42c-4da6-4f1c-bd78-98884d27578b
name: demoma
distribute-licenses: yes

This command imported information about the demoma infobase from a

cluster whose data directory is located at d:\1C srvinfo address. Thus, if
you need to start several infobases that are already registered in the working
cluster using the standalone server, the parameters of these databases do not
have to be manually transferred to the configuration file.
At the same time as importing information about the infobase, you can im-
port publication data. To do this, specify the path to the default.vrd file in
the import command line (--publication parameter):
ibcmd server config import --cluster-data="d:\1C srvinfo" --
name=demoma --publication=c:\inetpub\wwwroot\demoma\default.vrd --
out=d:\ss-cfgs\demoma.yml

In this example, the demoma infobase and publication parameters specified

in the c:\inetpub\wwwroot\demoma\default.vrd file will be imported.
The import result will be a single configuration file of the standalone server.
It should be remembered that the import mechanism of the publication file
ignores the command line for access to the infobase, which is specified in
the ib attribute of the point element of the default.vrd file. The user
executing import should carefully indicate the parameters of the imported
database and publication file.

7.4.4. Create infobase from (*

.cf) configuration file
ibcmd server config init --db-path="D:\1C DB\standalone-
server\file-db" --name=docsIB --base=webAccess --out="D:\1C
DB\standalone-server\file-db\file-db.yml"
ibcmd infobase create --config="D:\1C DB\standalone-server\file-
db\file-db.yml" --load="D:\Cfgs\MyApp\1Cv8.cf"

This example consists of two steps:

4. The first line forms a standalone server configuration file (ibcmd
server config init).
 5. The second line creates the infobase (and database file) based on the
configuration file(ibcmd infobase create).
In general, the creation of the infobase based on the configuration file can
be executed with one command. In this case, the choice of the solution
method depends on several parameters, for example, the database parame-
ters are set in one place of the information system, and the database is creat-
ed in another, but using the configuration file created in the previous step. If
you only need to create the infobase from the command line based on the
configuration file, this action can be performed as follows:
ibcmd infobase create --db-path="D:\1C DB\standalone-server\file-
db" --load="D:\Cfgs\MyApp\1Cv8.cf"

As a result of executing any of the above examples, an infobase will be cre-

ated in the D:\1C DB\standalone-server\file-db directory, and the system
will be accompanied by the following output to the standard output stream
(stdout):
[ INFO] Creating infobase...
[ INFO] Infobase created
[ INFO] Loading configuration...
[ INFO] Configuration loaded

If by the time of command execution, a database file (1Cv8.1CD) is created,

-the command execution will fail.
Creation of the client-server version of the infobase does not fundamentally
differ from creating the file version. Obviously, in case of the client-server
version, a larger number of parameters will be required:
ibcmd infobase create --dbms=mssqlserver --db-server=dbServerName -
-db-user=dbUser --db-pwd=dbUserPassword --db-name=my-db --
name=docsIB --create-database --load="D:\Cfgs\MyApp\1Cv8.cf"

As a result, my-db database will be created in Microsoft SQL Server, into

which the configuration from the D:\Cfgs\MyApp\1Cv8.cf file will be im-
ported. Repeated execution of the command will result in an error, since the
database will already exist.
It should also be remembered that the command to create the infobase from
the configuration file does not lead to the creation of the database configura-
tion. In order for the database structure to correspond to the configuration
used (to create the information database), you should use a specific parame-
ter that is responsible for updating the database configuration:
ibcmd infobase create --dbms=mssqlserver --db-server=dbServerName -
-db-user=dbUser --db-pwd=dbUserPassword --db-name=my-db --
name=docsIB --create-database --load="D:\Cfgs\MyApp\1Cv8.cf" --
apply

In this case, the output will contain information about updating the database
configuration:
[ INFO] Creating infobase...
[ INFO] Infobase created
[ INFO] Loading configuration...
[ INFO] Configuration loaded
[ INFO] Database configuration update...
[ INFO] Checking the correctness of the metadata...
[ INFO] Database structure processing...
[ INFO] Service Information Collection...
… information on changes in the infobase structure …
[ INFO] The structure of database tables was changed
[ INFO] Acceptance of changes...
[ INFO] Database configuration update is completed successfully

7.4.5. Load configuration from

(*.cf) file
ibcmd infobase config load --dbms=mssqlserver --db-
server=dbServerName --db-user=dbUser --db-pwd=dbUserPassword --db-
name=docs-db --name=docsIB 1Cv8.cf
ibcmd infobase config apply --dbms=mssqlserver --db-
server=dbServerName --db-user=dbUser --db-pwd=dbUserPassword --db-
name=docs-db --name=docsIB

The first command will actually import the configuration into the infor-
mation database, and the second - will update the database configuration
(with implementation of the database restructuring, if necessary).
Commands execution result:
ibcmd infobase config load …
[ INFO] Importing configuration...
[ INFO] Configuration import is completed successfully
ibcmd infobase config apply …
[ INFO] Database configuration update...
[ INFO] Checking the correctness of the metadata...
[ INFO] Acceptance of changes...
[ INFO] Database configuration update is completed successfully

It should be noted that the export file in this command is indicated without
any named parameter, the last value in the command line. All commands
that require a file as an input parameter will have the same feature.

7.4.6. Create infobase from the

export file (*.dt)
ibcmd infobase create --dbms=mssqlserver --db-server=dbServerName -
-db-user=dbUser --db-pwd=dbUserPassword --db-name=docs-db --create-
database --restore=1cv8.dt

Command execution result:

[ INFO] Creating infobase...
[ INFO] Infobase created
[ INFO] Infobase import...
[ INFO] Infobase import is completed successfully

As a result of this command, the following actions will be executed:

• A docs-db database will be created in the Microsoft SQL Server
DBMS with the dbServerName name.
• To access the DBMS, the dbUser user is used, for which the
dbUserPassword password is set.
• In case of absence, you should create a database.
• After creating the database, you should import information from the
1cv8.dt file in it, which is located in the directory where the above
command is started from.

7.4.7. Import data from the

export file (* .dt) to the
infobase
ibcmd infobase restore --dbms=mssqlserver --db-server=dbServerName
--db-user=dbUser --db-pwd=dbUserPassword --db-name=docs-db 1cv8.dt

Command execution result:

[ INFO] Infobase import...
[ INFO] Infobase imported

It should be noted that the export file in this command is indicated without
any named parameter, the last value in the command line.

7.4.8. Starting the stand-alone

server in debug mode
To debug using the standalone server, execute the following steps (it is as-
sumed that all components of the system run on the same computer):
1. Start the debug server:
dbgs --port=1970

2. Start the standalone server that will work with the necessary debug
server:
ibsrv --dbms=mssqlserver --db-server=dbServerName --db-user=dbUser
--db-pwd=dbUserPassword --db-name=docs-db --name=docs-db --
debug=http://localhost:1970

Specifying the --name parameter is critical.

 IMPORTANT! Specifying a different value for the name of the infobase
in the command line for starting the standalone server and in the configura-
tor settings (in the next step) will not allow debugging.
3. Configure the configurator to work with the desired debug server and
infobase. It is important to set the HTTP debug protocol, specify the
address of a separate debug server, which is started in step 1. And
specify as the name of the infobase, the name that is specified in the -
-name parameter when starting the standalone server.
Не удается отобразить связанный рисунок. Возможно, этот файл был перемещен, переименован или удален. Убедитесь, что ссылка указывает на правильный файл и верное размещение.

Fig. 90. Configuring debugging in the configurator

4. Start the client application (thin client -in the example), instructing
this application to use the desired debug server:
1cv8c /DEBUG -http -attach /DEBUGGERURL"http://localhost:1970"

The value of the -DebuggerURL parameter should be the address

(and port) of the debug server started in step 1.
5. As a last step, you should ensure that debug items are automatically
connected in the configurator or manually connect debug items.
If all the actions are executed correctly, - it will become possible to debug
the application running on the standalone server (both the client and server
parts) in the configurator.
 7.4.9. Request a DBMS user
password over the
standard input stream
The password for the DBMS user on behalf of which the standalone server
operates is placed in the configuration or command file in the open form.
This situation may be unacceptable.
In this case, a particular parameter (--request-db-pwd or -W) which
allows you to get the password from the standard input stream (stdin) can
help.
ibsrv --dbms=mssqlserver --db-server=dbServerName --db-user=dbUser
--name=docsIB -W --db-name=docs-db

If this command is specified, the standalone server will wait for the DBMS
user password (dbUser in the example above) from the standard input
stream. It should be remembered that the server will not invite the user to
execute input in any way.
Another option for specifying a password would be to redirect to stdin
some file or output of another program of the stand-alone server:
ibsrv --dbms=mssqlserver --db-server=dbServerName --db-user=dbUser
--name=docsIB -W --db-name=docs-db < sqlpwd.txt

7.4.10. Specify the location of the

standalone server service
directories
Various services of the standalone server use a disk drive to host service
data while the standalone server is running. Different services use different
directories for their work. The base directory for hosting service data is the
standalone server data directory: service directories are located in the
standalone server data directory by default. By changing the location of the
data directory, -the location of all other directories whose location is not
specified explicitly changes. At the same time, the standalone server allows
you to specify the individual location of various service directories:
• Standalone server data directory. In fact, it is a data directory of the
infobase. Set using the --dataparameter of the standalone server.
This directory contains the rest of the service directories by default.
Default location:
 Windows OS: %LOCALAPPDATA%\1C\1cv8\standalone-
server\.
 Linux: ~/.1cv8/standalone-server.
 • Directory of temporary infobase files. Set using the --temp parame-
ter of the standalone server. Temp directory of the server data directo-
ry is used by default. It should also be noted that temporary files used
by the standalone server itself are created in the temporary files direc-
tory of the user on whose behalf the server is running. This directory
can be redefined using the TEMP operating system environment varia-
ble.
• Session data directory. Set using the --session-data parameter
of the standalone server. the session-data directory of the server data
directory is used by default.
• Event log directory. Set using the --log-data parameter of the
standalone server. the log-data directory of the server data directory
is used by default.
• Full text index directory. It is set using the --ftext-data parame-
ter of the standalone server. the ftext-data directory of the server data
directory is used by default.
• Directory for storing OpenID- authentication contexts. Set using the -
-openid-data parameter of the standalone server. the openid-
data directory of the server data directory is used by default.

7.4.11. Infobase publication

"Publication" of the infobase for working through the web server is execut-
ed automatically when the standalone server starts. The standalone server
acts as the web server. At the same time, the standalone server provides all
the access features through the web server, as the regular publication: web
client, thin client via web server, Internet services, standard OData inter-
face. The ability to use one or another access method is controlled by the
configuration file parameters, with the help of which it is possible to man-
age the publication parameters.
Some of the publishing parameters can be changed using the standalone
server command line:
• --base. Allows you to specify the path that will be used to access
the application. The default path is /. This means that you can log in
to the web client at http://localhost:8314 address (for default set-
tings). If you specify a value for this parameter, for example --base
=/standalone/example, then to access the application you will
need to use the http://localhost:8314/standalone/example address.
• --port. The TCP port which will be used to access the application.
The default value is 8314.
 • --address. This parameter describes which network interface of
the computer will be used to access the publication. The default value
is localhost. Other values may include:
 any - use all available network interfaces.
 the IPv4 address - for access will use the network interface that is
assigned the specified IPv4 address.
 the IPv6 address - for access will use the network interface that is
assigned the specified IPv6 address.
Consider a simple example. Suppose we have the standalone server working
with the infobase file version. This standalone server is started by a com-
mand line of the form:
ibsrv --db-path="c:\db\standalone-server\demo"

In this case, the infobase of this server will be accessible at the

http://localhost:8341 address when accessing from the computer on
which the standalone server is running.
Suppose you want to provide web access to this infobase at the http://<pc-
addr>:8080/standalone/demo address. To achieve the result, it will be
necessary to start the standalone server with the following command line:
ibsrv --db-path="c:\db\standalone-server\demo" --
base=/standalone/demo --port=8080 --address=<pc-addrt>

In this example, the <pc-addr> text means specifying one of the network
interfaces of the computer, on which the standalone server is running.
It should also be remembered that the standalone server provides the feature
to serve several publications of the same infobase. This feature is available
only by specifying the appropriate parameters in the standalone server con-
figuration file.
An example of configuration file:
server:
address: localhost
database:
dbms: PostgreSQL
server: dbServerName
name: dbBase
user: postgres
password: postgres
infobase:
name: clusterDbName
distribute-licenses: yes
schedule-jobs: deny
http:
- base: /lk
OData:
publish: true
reuse-sessions:
mode: dontuse
- base: /partner
web-services:
service:
- name: RemoteManagement
alias: RemoteManagment.1cws
publish: true
reuse-sessions:
mode: autouse
OData:
publish: true
reuse-sessions:
mode: dontuse

7.4.12. Operations with

separators
Separators are configured using the standalone server configuration file. To
configure, use the http.zones section of the configuration file.
Example:
http:
- base: /clients
zones:
- specify: false
safe: false
- specify: true
safe: false

In this example, arrangement of web access to the infobase is considered

with the following parameters:
• Home directory for access: /clients.
• Information about separators:
  Two separators are used in the application.
 The first separator should not be specified in the access URL (the
specify parameter is equal to the false value) and it cannot be
changed from the built-in language (the safe parameter is equal
to the false value).
 The second separator must be specified in the access URL (the
specify parameter is equal to the true value) and it cannot be
changed from the built-in language (the safe parameter is equal
to the false value).

7.4.13. Export and import of

configuration to files
The standalone server allows you to export the configuration to files. Un-
loading is always executed in a hierarchical format. Only full export is sup-
ported. To do this, apply the following command:
ibcmd infobase config export -c config.yml d:\cfg_xml

When importing, it automatically determines the format of the importable

export. To fully import the configuration from the files, use the following
command:
ibcmd infobase config import -c config.yml d:\cfg_xml

It should be understood that this command will completely replace the

configuration in the infobase, which is described by the config.yml con-
figuration file.
Chapter 8.
Setting up web services for
1C:Enterprise

8.1. General information

This chapter describes the functionality settings of the web servers for oper-
ation with web client and web services, and the OpenID authentication sup-
port settings. After publishing, access to the published components is as
follows:
• Access to web client. To start the web client, use the address generat-
ed according to the following rules: <Web server host
name>/<Virtual directory name>. If the name of virtual directory
is DemoCfg, type the following URL to start the web client (to get ac-
cess from a local computer): http://localhost/DemoCfg.
• Access to web service. To access the Web service use the address that
generates as follows: <Web server host name>/<Virtual directory
name>/ws/<Web service name> or <Web server host
name>/<Virtual directory name>/ws/<Web service address>.
For example, if the virtual directory has the name DemoWS, the name
of web service in Designer is shown as OperationDemoWS and the
address is DemoWorkWS, the access to the web service can be per-
formed via either address (to get access from a local computer):
http://localhost/DemoWS/ws/OperationDemoWS or
http://localhost/DemoWS/ws/DemoWorkWS.
• Access to HTTP service. To get access to HTTP service, use the ad-
dress generated as follows: <Web server host name>/<Virtual di-
rectory name>/hs/<path to resource>.
• OpenID authentication performed automatically.
Web servers of Internet Information Services (hereinafter referred to as IIS)
family are delivered with an operating system. To make it easier for under-
standing which server you are using, refer to the lookup table of OS and
web server versions:

IIS version OS version

IIS 5.1 Windows XP Professional
IIS 6.0 Windows Server 2003 or
Windows XP Professional x64 Edition
 IIS version OS version
IIS 7.0 Windows Vista or Windows Server 2008
IIS 7.5 Windows 7 or Windows Server 2008 R2
IIS 8.0 Windows 8 or Windows Server 2012
IIS 8.5 Windows 8.1 or Windows Server 2012 R2
IIS 10.0 Windows 10 or Windows Server 2016
Distribution package of Apache web server (for Windows or Linux) can be
downloaded from the project website:
http://httpd.apache.org/download.

8.2. General requirements

On a computer where the publication is done, a supported web server must
be installed and configured. To install the Internet Information Services web
server, you may need a distribution package of the operating system used.
When installing the web server you must install support for ISAPI exten-
sions. To install the web server you need the administrative privileges on
the computer.
Publication can be performed in two ways:
• Using the publication dialog box on the web server if Designer of re-
quired bitness can be started on the computer with the web server.
• Using webinst utility.
To perform a publication on the web server you need the administrative
rights on the computer:
• For Windows Vista OS or later, in order to perform the publication,
you need to start Designer using Run as Administrator context menu
command. If the publication is performed with the webinst utility, the
administrator starts either the utility itself or the Windows command
line interpreter.
• For Linux, to perform the publication, you need the superuser rights
(root) using the su command or start the application that performs the
publication using the sudo command.
When you try to perform the publication, the software checks for the neces-
sary privileges to perform the operation. If the privileges of the current user
are not sufficient to perform the publication:
• When publishing from Designer, the user is prompted to continue
publishing. The dialog box displays the reason of the prompt and rec-
ommendations on how to obtain the necessary privileges.
• When publishing using the webinst utility, the user gets a diagnostic
message but the publication continues.
Publication is possible only if 1C:Enterprise is located on a computer with a
web server. To work with the configuration via web server, the configura-
tion needs to be blank.
Operation through a web server is characterized by certain features of both
the actual work and settings of the web servers:
• When working with the file version of the infobase through a web
server, the actual work with the database file is executed by the web
server extension. If several client applications work with the publica-
tion, then requests from these client applications are executed sequen-
tially, in the order of request arrival to the web server extension. Each
web server working process provides an operation of the web server
extension single instance.
• Due to the features of getting the results of the background jobs in the
file version of work, it is recommended to configure the web server so
that each publication of the 1C:Enterprise infobase serves no more
than one web server working process.
• When using the IIS web server:
 For IIS 7.x and later web servers, publishing is not supported if the
Directory property (dir parameter of webinst utility) points to the
directory %SYSTEMDRIVE%\Inetpub\wwwroot.
 Publishing is always done for the default web site (Default Web
Site) and the default application pool (DefaultAppPool).
 For the application pool used for 1C:Enterprise, the .NET envi-
ronment support must be disabled. To do this, set the application
pool property Versions of the .NET Framework to Non-
managed code.
• When using Apache server:
 When working under Linux OS, it is recommended to use the
worker multiprocessing module. Other available modules are not
recommended.

8.3. Publication types

8.3.1. General publication
procedure
The general publication procedure is as follows:
• The request processing module (web server extension module) corre-
sponding to the web server is registered.
• A virtual application is registered on the web server.
• The virtual application directory is created and the default.vrd file is
placed in it and configured.
• Users are granted permissions to access the directory with the data-
base file (for file mode only).
To publish the web client, use the 1C:Enterprise version that is used with
the infobase to be accessed using the web client. If two versions are in-
stalled on the computer (for example, 8.3.3.100 and 8.3.3.150) and the
1C:Enterprise server of version 8.3.3.150 is running, use Designer or
webinst utility of exactly the same version for publishing.
When publishing, remember that the bitness of the registered web server
extension must match the bitness of the web server. To determine the pub-
lishing method, use the following table:

32-bit 64-bit
web server web server
32-bit 1C:Enterprise Fully Partially
64-bit 1C:Enterprise Not supported. Fully
Publication is fully - supported both using the configurator and the
webinst utility.
Partially-, it is possible to publish a 32-bit 1C:Enterprise application
for use with a 64-bit IIS web server. The webinst utility is called from
the bin directory of the 32-bit version of 1C:Enterprise. Under Linux,
this publication is not supported.
To publish from the Designer, you should use the publish dialog (Admin-
istration - Publishing on web server ...).

Fig. 91. Publishing on web server

Then follow these steps:
• Enter the name of the virtual directory in the Name field. The name of
the virtual directory only contains Latin letters.
• In the Web server field, specify the type of web server for which you
are publishing.
• In the Directory field, specify the physical location of the directory in
which the files describing the virtual directory will be located. For
Apache web server, the directory name contains only Latin letters.
• Depending on whether Publish access for client applications and
Publish Web-services check boxes are checked, or not.
 • For IIS web server, you can specify OS authentication on the web
server.
• If necessary, select the Web services to be published. The Address
column can be edited. This column defines a Web service synonym.
Accessing the Web service is possible both by name and by synonym.
• If necessary, -customize the rest of the publishing parameters.
• Clicking the Publish button starts the publishing process. Clicking
Disable deletes the publication from the selected web server.
After the publication has been completed, you will be prompted to restart
the web server in the following cases:
 1C:Enterprise version has changed
 Path to the web server extension module has changed
 A new publication has been made for the Apache web server
 Publication was disabled
When using anonymous authentication and file infobase, when publishing is
performed, the user is checked for access rights to the infobase directory on
whose behalf anonymous access is performed. If the user does not have the
necessary rights, a warning is displayed that this infobase cannot be ac-
cessed via a web server. It is recommended to either grant access rights for
the directory with the infobase, or select the Use OS authentication on a
web server check box.
The publishing dialog box and the command line parameters of the webinst
utility will be described in other subsections of this section.

8.3.2. Publishing dialog box

The publication dialog box is used to create a publication or to prepare a
template file for publication using the webinst utility (using the -descriptor
command line parameter).
All parameters that can be edited when creating a publication are located in
two tabs. For more details, see below.

8.3.2.1. Dialog buttons

The Publish button submits a publication to the web server. When publish-
ing, a directory is created on the hard drive and the web server is configured
to operate with 1C:Enterprise. Please note that publishing to the IIS web
server is always performed for the default web site (Default Web Site) and
for the default application pool (DefaultAppPool).
Under Linux, the following actions are performed:
• For the directory in which the default.vrd file is located, the group of
the user on whose behalf the web server was started is set as the owner
group.
 • The default.vrd file is set to read access for the group that includes
the user on whose behalf the web server was started.
In the case of publishing a file infobase, for a directory with an infobase file
the user group is set as the owner group on behalf of which the web server
is running, and the owner group inheritance is configured to operate with
the infobase.

Fig. 92. Publishing on web server

The Disable button removes the application from the web server and from
the publication directory, if necessary.
The Save button saves the parameters specified in the publishing dialog on
the web server to a file. When saving, you are prompted for the name and
location of the file to be saved. Saving will be performed in the default.vrd
file format. Using this command, you can create template files that will be
used as the -descriptor parameter of the webinst utility. The parameters of
the source infobase are written to the values of the ib and base attributes
of the point element.
The Download button opens file default.vrd for editing. At loading, the ib
andbase attributes of the point element of the loaded file are ignored.
The Close button closes the dialog box.
The Help button opens a window with reference information about the pub-
lication dialog.

8.3.2.2. Main tab

8.3.2.2.1. General parameters

In this tab, you can set the general parameters of the publication.

Fig. 93. Publishing on web server. Main tab.

Name. Specifies the publication name. When published using the webinst
utility, it is described by the -wsdir parameter. In the default.vrd file, it
corresponds to the base attribute of the point element.
Web server. Specifies web server used for publishing. Apache web servers
are added to the list if they are found on the computer. When publishing
using the webinst utility, the web server used is indicated by one of the iis,
apache2, apache22 or apache24 parameters. When operating in Linux,
publishing is only possible for the Apache web server.
If the version of the Apache web server installed on the computer (2.2 or
2.4) cannot be determined, both versions of the web server will be listed.
Please consider that for the Apache web server version 2.2 and 2.4 there are
differences between the changes made in the configuration file of the web
server. Therefore, the incorrectly specified version of the web server will
result in the unavailability of the publication.
Directory. Specifies the physical directory on the hard drive in which the
default.vrd file will be located and where the virtual directory of the web
server will be displayed. The directory must already exist. When published
using the webinst utility, it is described by the -dir parameter.
Publish access for client applications. Responsible for accessing the pub-
lished infobase using a thin, mobile and a web client. If the check box is
selected, the published infobase can be accessed using a thin, mobile or a
web client. In the default.vrd file, corresponds to the enable attribute of
the point element.
Publish standard OData interface. Responsible for accessing the standard
OData interface of the application. In the default.vrd file, corresponds to
the enableStandardOData attribute of the point element.
Publish thin client distribution package. Determines whether the client
application (thin client) can be obtained and installed if the versions of the
client application and the server do not match. A zip archive is used as a
distribution package, the full name of which is indicated as one of the value
of the Location of the published distribution package property.
• Windows x86 - distribution package of the 32-bit client application
for Windows OS.
• Windows x86_64 - distribution package of the 64-bit client applica-
tion for Windows OS.
• MacOS x86_64 - distribution package of the 64-bit client application
for macOS OS.
In the default.vrd file, this properties correspond to the pubdstwin32,
pubdstwin64, pubdsmac64 attributes of the point element. The ar-
chive must contain the distribution package of the client application. The
installation will use the parameters specified in the 1cestart.cfg file (simi-
lar to the regular installation of the client application).
Use OS authentication. Allows OS authentication on IIS web server.
The address of the transition at the end of the web client allows to
specify the transition URL to open after the web client is closed. In the de-
fault.vrd file, corresponds to the exitURL element.

8.3.2.2.2. Web services tab

Publish Web services. Selecting this check box will result in the publica-
tion of Web services created in the configuration and listed in the table be-
low the check box. In the default.vrd file, it corresponds to the enable
attribute of the wselement. If the check box is cleared, this is equivalent to
the absence of the ws element in the default.vrd file or the presence of the
ws element with the enable attribute set to true value.

Fig. 94. Publishing web services

Publish Web services by default. Responsible for using Web services that
are published without explicit permission to use. In the default.vrd file, it
corresponds to the pointEnableCommon attribute of the ws element.
The table below the Publish web services check box contains a list of pub-
lished Web services and allows managing publication of each Web service.
The first column controls publication of each Web service. If the check box
is cleared, the Web service will be disabled (it cannot be called). In the de-
fault.vrd file, corresponds to the enable attribute of the point element.
The second column (Name) contains the name of the Web service as de-
fined when it was created. In the default.vrd file, it corresponds to the
name attribute of the point element.
The last column of the table (Address) contains the alias of the name of the
published Web service. The Web service can be accessed both by name and
by alias. You can edit the Web service alias in the publish window. In the
default.vrd file, it corresponds to the aliasattribute of the point ele-
ment.
Web services that are located in the connected extensions are not displayed
in this table and can be published only by editing the default.vrd file manu-
ally.
Publish extensions Web services by default. Responsible for using Web
services supplied in configuration extensions. In the default.vrd file, it cor-
responds to the publishExtensionsByDefault attribute of the ws
element.

8.3.2.2.3. HTTP services tab

The HTTP services tab is designed to control the application access over
HTTP services.

Fig. 95. Publishing HTTP services

Publish HTTP services by default. Selecting this check box will result in
the publication of HTTP services created in the configuration and listed in
the table below the check box. In the default.vrd file, it corresponds to the
publishByDefault attribute of the httpServices element. If the
check box is cleared, this is equivalent to the absence of the
httpServices element in the default.vrd file or the presence of the
httpServices element with the publishByDefault attribute set to
false value.
The table below the Publish HTTP services by default check box contains
a list of published HTTP services and allows to manage the publication of
each HTTP service. The first column controls publication of each HTTP
service. If the check box is cleared, the HTTP service will be disabled (it
cannot be called). In the default.vrd file, it corresponds to the enable
attribute of the service element.
The second column (Name) contains the name of the HTTP service as de-
fined when it was created. In the default.vrd file, it corresponds to the
name attribute of the service element.
HTTP services that are located in the connected extensions are not dis-
played in this table and can be published only by editing the default.vrd file
manually.
Publish extensions HTTP services by default. Responsible for using
HTTP services supplied in configuration extensions. In the default.vrd file,
it corresponds to the publishExtensionsByDefault attribute of the
httpServices element.
8.3.2.3. OpenID tab
On this tab, you can configure the OpenID authentication settings for the
publication to be performed.

Fig. 96. OpenID authentication settings

The Use OpenID authentication check box enables OpenID authentica-
tion for this infobase. In this case, the OpenID Provider Address property
contains the address of the infobase that acts as OpenID provider. Access to
this infobase is performed only over HTTPS protocol.
If the published infobase acts as an OpenID provider, it is necessary to se-
lect the Use as an OpenID provider check box.
In fact, this tab is used to configure the openid element of the default.vrd
file.
8.3.2.4. Additional tab
In this tab, you can set the auxiliary parameters of the publication.

Fig. 97. Auxiliary parameters of the publication on the web server

Temporary files directory. Specifies a temporary files directory for the
web server extension or the infobase file mode. In the default.vrd file, it
corresponds to the tempattribute of the point element.
Connection pool group. Describes the pool element of the default.vrd
file. Also, the parameters of this group control the operation of the connec-
tion interruption tracking system.
Debugging tab. Describes the debug element of the default.vrd file.
Data separation. Describes the zones element of the default.vrd file.
More detail on the structure of the separators table is provided below.
The table contains all independent separators that exist in a configuration or
in a downloaded file. The first column (without a name) determined wheth-
er a zone element needs to be created for the selected separator. Remember
that the element is mapped not by the name of the separator, but by its ordi-
nal position in the list. If the first separator is disabled, it makes sense to
disable all others, since the parameters of the zones element will be ap-
plied automatically to other separators.
 The Name column contains the name of the separator as defined in the
properties of the general attribute. The check box in the next column deter-
mines whether the separator value will be specified in the zone element. If
the check box is selected, the value from the Value column will be used as
the Value attribute.
The check boxes in the Safe and Specify columns are responsible for the
safe and specify attributes of the zone element of the default.vrd file.
The parameter Background jobs in the file mode determines whether
background jobs can be used in the file mode of the infobase (attribute
allowexecutescheduledjobs of the root point element).

8.3.3. Webinst utility

8.3.3.1. General description
The utility is designed to configure web servers to support the web client
operation. The utility works in Windows or Linux environment, and is part
of the 1C:Enterprise distribution package.
webinst [-publish] | -delete <web server>
-wsdir <virtual directory>
-dir <physical directory>
-connstr <connection string>
-confpath <path to httpd.conf>
-descriptor <path to default.vrd>
[-osauth]

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

a space character. If the parameter contains spaces, it must be enclosed in
quotation marks ("). If inside the parameter there is a quotation mark, then
the internal quotation marks must be doubled.
IMPORTANT! When running the utility, only one of these parameters can
be specified: iis, apache2, apache22 or apache24.
IMPORTANT! To perform the publication, the utility must be run as an
administrator. When running on Windows, a request for elevation of privi-
leges will appear.

-publish by default
The web client is published to the web server.
-delete
Execution of deletion from the specified directory.
NOTE. When deleting a publication, it is sufficient to specify only the -
wsdir parameter. The remaining parameters can be specified to control the
operation.
<web server>
Specifies for which web server the action will be performed (publish or de-
lete publication):
• -iis -is a web server of Microsoft Internet Information Services ver-
sions 5.1, 6.0, 7.x, 8.x, 10.0 (only when used with Windows OS).
• -apache2 - is Apache 2.0 web server.
• -apache22 - is Apache 2.2 web server.
• -apache24 - is Apache 2.4 web server.
When using the Apache 2.4 web server, you can omit the path to the con-
figuration file using the -confpath parameter.
It should be considered that for the Apache web server version 2.2 and 2.4
there are differences between the changes made in the configuration file of
the web server. Therefore, the incorrectly specified version of the web serv-
er will result in the unavailability of the publication.
-wsdir
Name of the virtual directory.
-dir
Name of the physical directory to which the virtual directory of the web
server will be mapped. The directory must already exist.
For IIS 7.x and later web servers, publishing is not supported if the value of
this parameter points to the %SYSTEMDRIVE%\Inetpub\wwwroot direc-
tory.
NOTE. A directory name must not end with a "\" symbol if it is enclosed in
quotes. Correct: "c:\my path", incorrect: "c:\my path\".

-connstr
Infobase connection string.
-confpath only for Apache
The full path to the configuration file (httpd.conf) of the Apache web serv-
er. This parameter is applicable only when using Apache web servers.
-descriptor
Allows to publish according to the template specified by the existing file,
which is specified in this parameter (including the file path). The name of
the template file does not have to be default.vrd. When publishing, the ex-
isting default.vrd file is completely replaced with the template file. If the -
wsdir or -connstr parameters are specified simultaneously with this param-
eter, then the values of these parameters replace the values of the base and
ib (respectively) attributes of the point element.
 If the -descriptor parameter is specified simultaneously with the -delete
parameter, then the virtual directory name (the base attribute of the
point element) and the infobase connection string (the ib attribute of the
point element) are used from the template file. The publication will be
deleted only if both values of the deleted publication and the template file
match.
-osauth only for IIS
When publishing, it configures the use of OS authentication on a web serv-
er. This parameter is applicable only when using IIS web servers.

8.3.3.2. Publication examples

Example of publish command for IIS 7.0 and later:
webinst -publish -iis -wsdir demo -dir "c:\inetpub\demo" -connstr
"Srvr=server:1741;Ref=demo;"

In this example, a web client with the following parameters is published:

• Virtual directory: demo (-wsdir demo parameter)
• The physical directory to which the virtual directory is mapped:
C:\inetpub\demo (-dir "c:\inetpub\demo" parameter)
• Infobase connection string: Srvr=server:1741;Ref=demo; (-
connstr "Srvr=server:1741;Ref=demo;" parameter, client/server
mode of the infobase)
Example of publish command for Apache 2.2:
webinst -publish -apache22 -wsdir DemoWS -dir
"c:\apache.www\demows" -connstr "File=""c:\my db\demows"";" -
confpath "C:\Program Files\Apache Software
Foundation\Apache2.2\conf\httpd.conf"

In this example, a web client with the following parameters is published:

• Virtual directory: DemoWS (-wsdir demoWS parameter)
• The physical directory to which the virtual directory is mapped:
C:\apache.www\demows (-dir "c:\apache.www\demows" pa-
rameter)
• Infobase connection string: File="c:\my db\demows"; (-connstr
"File=""c:\my db\demows"";" parameter, file mode of the infobase)
• Apache web server configuration file: C:\Program Files\Apache
Software Foundation\Apache2.2\conf\httpd.conf (-confpath
"C:\Program Files\Apache Software Founda-
tion\Apache2.2\conf\httpd.conf" parameter).
Example of publishing using a template file:
webinst -publish -iis -wsdir demoMA -dir
"c:\inetpub\wwwroot\demoMA" -connstr "Srvr=server:1741;Ref=demo;" -
descriptor template.vrd

In this example:
• Publication to IIS web server (-publish -iis parameters) is performed.
• Virtual directory: demoMA (-wsdir demoMA parameter)
• The physical directory to which the virtual directory is mapped:
c:\inetpub\wwwroot\demoMA (-dir
"c:\inetpub\wwwroot\demoMA" parameter)
• Infobase connection string Srvr=server:1741;Ref=demo; (-connstr
"Srvr=server:1741;Ref=demo;")
• The remaining publication parameters will be obtained from the tem-
plate.vrd template file (-descriptor template.vrd parameter).
Example of a command for deleting a publication for IIS:
webinst -delete -iis -wsdir DemoWS

Example of deletion of a publication made in the virtual directory:

• Virtual directory: DemoWS (–wsdir DemoWS parameter). The re-
maining parameters are automatically determined from this name.

8.4. Web client support settings

8.4.1. General information
This section contains instructions for setting up various web servers to op-
erate using the web client. It describes both the actions necessary for pub-
lishing from the Designer, and the actions necessary for publishing using
the webinst utility.
When describing a publication, the values that are key to the publishing will
be described. The remaining parameters must be configured if necessary.

8.4.2. On Windows
8.4.2.1. General information
This section describes how to configure the Windows-based web servers for
the web client operation.
To publish a web client, select the Publish thin client and web client
check box.
 8.4.2.2. Internet Information Services

8.4.2.2.1. General description

Besides specifying the parameters of the publication (described below), you
must additionally make the following settings:
• Grant read rights for the user on whose behalf the requests are execut-
ed (IUSR_ <PC_NAME> user for IIS versions 5.1 and 6.0 or
IIS_IUSRS group for IIS versions 7.x and later) to the bin directory of
files of a specific 1C:Enterprise version
• Grant edit rights to the user on whose behalf the queries are executed
(IUSR_ <PC_NAME> user for IIS versions 5.1 and 6.0 or IIS_IUSRS
group for IIS versions 7.x and later) on the infobase directory (only in
the case of the file mode).
NOTE. Substring <PC_NAME> in the username IUSR_ <PC_NAME>
indicates the name of the computer on which the IIS is installed. So, for a
computer with the name IIS-COMP, the username will look like this:
IUSR_IIS-COMP.

8.4.2.2.2. Publishing dialog box

In the Web server field, specify Internet Information Services. If you
need the operating system authentication on a web server, select the corre-
sponding check box (Use operating system authentication on a web
server).
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.4.2.2.3. Webinst utility

To configure the IIS web server using the webinst utility, run the following
command (the parameters are given for example, they should be replaced
with the real values).
Example:
webinst -publish -iis -wsdir demo -dir "c:\inetpub\demo" -connstr
"Srvr=server:1741;Ref=demo;" -osauth

8.4.2.3. Apache 2.0

8.4.2.3.1. General description

Besides specifying the parameters of the publication (described below), you
must additionally make the following settings:
 • Grant read rights for the user on whose behalf the web server operates
to the bin directory of files of a specific version of the 1C:Enterprise
application;
• Grant edit rights for the user on whose behalf the web server operates
to the infobase directory (only when in file mode).

8.4.2.3.2. Publishing dialog box

In the Web server field, specify Apache 2.0.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.4.2.3.3. Webinst utility

To configure the Apache 2.0 web server using the webinst utility, run the
following command (the parameters are for reference only, they should be
replaced with actual values before using).
Example:
webinst -publish -apache2 -wsdir demo -connstr
"Srvr=server:1741;Ref=demo;" -dir "c:\apache.www\demows" -confpath
"C:\Program Files\Apache Software
Foundation\Apache2.2\conf\httpd.conf"

8.4.2.4. Apache 2.2

8.4.2.4.1. General description

Besides specifying the parameters of the publication (described below), you
must additionally make the following settings:
• Grant read rights for the user on whose behalf the web server operates
to the bin directory of files of a specific version of the 1C:Enterprise
application;
• Grant edit rights for the user on whose behalf the web server operates
to the infobase directory (only when in file mode).

8.4.2.4.2. Publishing dialog box

In the Web server field, specify Apache 2.2.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.
 8.4.2.4.3. Webinst utility
To configure the Apache 2.2 web server using the webinst utility, run the
following command (the parameters are for reference only, they should be
replaced with actual values before using).
Example:
webinst -publish -apache22 -wsdir demo -connstr
"Srvr=server:1741;Ref=demo;" -dir "c:\apache.www\demows" -confpath
"C:\Program Files\Apache Software
Foundation\Apache2.2\conf\httpd.conf"

8.4.2.5. Apache 2.4

8.4.2.5.1. General description

Besides specifying the parameters of the publication (described below), you
must additionally make the following settings:
• Grant read rights for the user on whose behalf the web server operates
to the bin directory of files of a specific version of the 1C:Enterprise
application;
• Grant edit rights for the user on whose behalf the web server operates
to the infobase directory (only when in file mode).

8.4.2.5.2. Publishing dialog box

In the Web server field, specify Apache 2.4.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.4.2.5.3. Webinst utility

To configure the Apache 2.4 web server using the webinst utility, run the
following command (the parameters are for reference only, they should be
replaced with actual values before using).
Example:
webinst -publish -apache24 -wsdir demo -connstr
"Srvr=server:1741;Ref=demo;" -dir "c:\apache.www\demows"

8.4.3. On Linux
8.4.3.1. General information
This section describes how to configure the Linux-based web servers for the
web client operation. After the publication is performed, you must provide
the user, on behalf of which Apache operates, the rights to the executable
 files directory (/opt/1C/v8.3/i386/ for the 32-bit version or
/opt/1C/v8.3/x86_64/ for 64- bit version) of a specific version of the
1C:Enterprise application (read and execute). In the case of the file mode of
the infobase, you must give the rights to modify the infobase catalog to the
user, on whose behalf the web server was started.

8.4.3.2. Apache 2.0

8.4.3.2.1. Publishing dialog box

In the Web server field, specify Apache 2.0.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.4.3.2.2. Webinst utility

To configure the Apache 2.0 web server using the webinst utility, run the
following command (the parameters are for reference only, they should be
replaced with actual values before using).
Example:
webinst -apache2 -wsdir DemoWS -dir /var/www/DemoWS -connstr
"Srvr=server:1741;Ref=demo;" -confpath /etc/apache2/httd.conf

8.4.3.3. Apache 2.2

8.4.3.3.1. Publishing dialog box

In the Web server field, specify Apache 2.2.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.4.3.3.2. Webinst utility

To configure the Apache 2.2 web server using the webinst utility, run the
following command (the parameters are for reference only, they should be
replaced with actual values before using).
Example:
webinst -apache22 -wsdir DemoWS -dir /var/www/DemoWS -connstr
"Srvr=server:1741;Ref=demo;" -confpath /etc/apache2/apache.conf

8.4.3.4. Apache 2.4

8.4.3.4.1. Publishing dialog box

In the Web server field, specify Apache 2.4.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.4.3.4.2. Webinst utility

To configure the Apache 2.4 web server using the webinst utility, run the
following command (the parameters are for reference only, they should be
replaced with actual values before using).
Example:
webinst -apache24 -wsdir DemoWS -dir /var/www/DemoWS -connstr
"Srvr=server:1741;Ref=demo;"

8.5. Web service support

settings
8.5.1. General information
Setting support for Web services is to configure your web server for opera-
tion with Web services and to set the access rights to the directories of exe-
cutable files and the database (for the file mode of operation).
To publish Web services, select the Publish Web services check box on
the Web services tab, and select the services to be published in the table
below the check box.

8.5.2. On Windows
8.5.2.1. General information
This section describes the publication of Web services for Windows-based
web servers. It is assumed that the web server is already installed.
NOTE. To install the IIS web server, you may need a distribution package
of the operating system used.
8.5.2.2. Internet Information Services

8.5.2.2.1. General description

Besides specifying the parameters of the publication (described below), you
must additionally make the following settings:
• Grant read rights for the user on whose behalf the requests are execut-
ed (IUSR_<PC_NAME> user for IIS versions 5.1 or 6.0 or
IIS_IUSRS group for IIS versions 7.x and later) to the bin directory of
files of a specific 1C:Enterprise version
• Grant edit rights to the user on whose behalf the queries are executed
(IUSR_<PC_NAME> user for IIS versions 5.1 or 6.0 or IIS_IUSRS
group for IIS versions 7.x and later) on the infobase directory (only in
the case of the file mode)
NOTE. Substring <PC_NAME> in the username IUSR_ <PC_NAME>
indicates the name of the computer on which the IIS is installed. So, for a
computer with the name IIS-COMP, the username will look like this:
IUSR_IIS-COMP.

8.5.2.2.2. Publishing dialog box

In the Web server field, enter Internet Information Services.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.5.2.2.3. Webinst utility

Before publishing, you need to create a template file:
• In the Web server field, enter Internet Information Services.
• Select the Publish Web Services check box.
• Select the parameters of web services to publish.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as iis-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -iis -wsdir demo-ws -dir "c:\inetpub\demo-ws" -
connstr "Srvr=server:1741;Ref=demo;" -descriptor iis-template.vrd

8.5.2.3. Apache 2.0

8.5.2.3.1. General description

It is necessary to give rights to the user on whose behalf Apache runs for the
bin directory of files of a specific version of the 1C:Enterprise application
(read and execute) and for the directory of the infobase (read and write, in
the case of the file mode).

8.5.2.3.2. Publishing dialog box

In the Web server field, specify Apache 2.0.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.5.2.3.3. Webinst utility

Before publishing, you need to create a template file:
• In the Web server field, specify Apache 2.2.
• Select the Publish Web Services check box.
• Select the parameters of web services to publish.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as apache-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -apache2 -wsdir demo-ws -dir "c:\inetpub\demo-ws"
-connstr "Srvr=server:1741;Ref=demo;" -descriptor apache-
template.vrd

8.5.2.4. Apache 2.2

8.5.2.4.1. General description

It is necessary to give rights to the user on whose behalf Apache runs for the
bin directory of files of a specific version of the 1C:Enterprise application
(read and execute) and for the directory of the infobase (read and write, in
the case of the file mode).
 8.5.2.4.2. Publishing dialog box
In the Web server field, specify Apache 2.2.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.5.2.4.3. Webinst utility

Before publishing, you need to create a template file:
• In the Web server field, specify Apache 2.2.
• Select the Publish Web Services check box.
• Select the parameters of web services to publish.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as apache-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -apache22 -wsdir demo-ws -dir "c:\inetpub\demo-ws"
-connstr "Srvr=server:1741;Ref=demo;" -descriptor apache-
template.vrd

8.5.2.5. Apache 2.4

8.5.2.5.1. General description

It is necessary to give rights to the user on whose behalf Apache runs for the
bin directory of files of a specific version of the 1C:Enterprise application
(read and execute) and for the directory of the infobase (read and write, in
the case of the file mode).

8.5.2.5.2. Publishing dialog box

In the Web server field, specify Apache 2.4.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.5.2.5.3. Webinst utility

Before publishing, you need to create a template file:
• In the Web server field, specify Apache 2.4.
• Select the Publish Web Services check box.
• Select the parameters of web services to publish.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
 • To save the template file, click Save. Enter the name of template file
as apache-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -apache24 -wsdir demo-ws -dir "c:\inetpub\demo-ws"
-connstr "Srvr=server:1741;Ref=demo;" -descriptor apache-
template.vrd

8.5.3. On Linux
8.5.3.1. General information
This section describes the publication of Web services for Linux-based web
servers. It is assumed that the web server is already installed.
To publish Web services, select the Publish Web services check box on
the Web services tab, and select the services to be published in the table
below the check box.
After the publication is performed, you must provide the user, on behalf of
which Apache operates, the rights to the executable files directory
(/opt/1C/v8.3/i386/ for the 32-bit version or /opt/1C/v8.3/x86_64/ for
64- bit version) of a specific version of the 1C:Enterprise application (read
and execute). In the case of the file mode of the infobase, you must give the
rights to modify the infobase catalog to the user, on whose behalf the web
server was started.

8.5.3.2. Apache 2.0

8.5.3.2.1. Publishing dialog box

In the Web server field, specify Apache 2.0.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.5.3.2.2. Webinst utility

Before publishing, you need to create a template file (in Designer):
• In the Web server field, specify Apache 2.2.
• Select the Publish Web Services check box.
• Select the parameters of web services to publish.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as apache-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -apache2 -wsdir demo-ws -dir /var/www/demo-ws -
connstr "Srvr=server:1741;Ref=demo;" -confpath
/etc/apache2/httd.conf -descriptor apache-template.vrd

8.5.3.3. Apache 2.2

8.5.3.3.1. Publishing dialog box

In the Web server field, specify Apache 2.2.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.5.3.3.2. Webinst utility

Before publishing, you need to create a template file (in Designer):
• In the Web server field, specify Apache 2.2.
• Select the Publish Web Services check box.
• Select the parameters of web services to publish.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as apache-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -apache22 -wsdir demo-ws -dir /var/www/demo-ws -
connstr "Srvr=server:1741;Ref=demo;" -confpath
/etc/apache2/httd.conf -descriptor apache-template.vrd

8.5.3.4. Apache 2.4

8.5.3.4.1. Publishing dialog box

In the Web server field, specify Apache 2.4.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.5.3.4.2. Webinst utility

Before publishing, you need to create a template file (in Designer):
• In the Web server field, specify Apache 2.4.
• Select the Publish Web Services check box.
• Select the parameters of web services to publish.
 • If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as apache-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -apache24 -wsdir demo-ws -dir /var/www/demo-ws -
connstr "Srvr=server:1741;Ref=demo;" -descriptor apache-
template.vrd

8.6. Standard OData interface

support
8.6.1. General information
Setting support for Standard OData Interface is to configure your web serv-
er used and to set the access rights to the directories of executable files and
the database (for the file mode of operation).
To publish a standard OData interface, select the Publish standard OData
interface check box on the Main tab.

8.6.2. On Windows
8.6.2.1. General information
This section describes the publication of standard OData Interface for Win-
dows-based web servers. It is assumed that the web server is already in-
stalled.
NOTE. To install the IIS web server you may need a distribution package
of the operating system used.

8.6.2.2. Internet Information Services

8.6.2.2.1. General description

Besides specifying the parameters of the publication (described below), you
must additionally make the following settings:
• Grant read rights for the user on whose behalf the requests are execut-
ed (IUSR_<PC_NAME> user for IIS versions 5.1 or 6.0 or
IIS_IUSRS group for IIS versions 7.x and later) to the bin directory of
files of a specific 1C:Enterprise version
 • Grant edit rights to the user on whose behalf the queries are executed
(IUSR_<PC_NAME> user for IIS versions 5.1 or 6.0 or IIS_IUSRS
group for IIS versions 7.x and later) on the infobase directory (only in
the case of the file mode)
NOTE. Substring <PC_NAME> in the username IUSR_ <PC_NAME>
indicates the name of the computer on which the IIS is installed. So, for a
computer with the name IIS-COMP, the username will look like this:
IUSR_IIS-COMP.

8.6.2.2.2. Publishing dialog box

In the Web server field, specify Internet Information Services. If you
need the operating system authentication on a web server, select the corre-
sponding check box (Use operating system authentication on a web
server).
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.6.2.2.3. Webinst utility

Before publishing, you need to create a template file:
• In the Web server field, enter Internet Information Services.
• Select check box Publish standard OData interface.
• If necessary, specify the option to Use operating system authenti-
cation on a web server;
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as iis-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -iis -wsdir demo-ws -dir "c:\inetpub\demo-ws" -
connstr "Srvr=server:1741;Ref=demo;" -descriptor iis-template.vrd

8.6.2.3. Apache 2.0

8.6.2.3.1. General description

Besides specifying the parameters of the publication (described below), you
must additionally make the following settings:
 • Grant read rights for the user on whose behalf the web server operates
to the bin directory of files of a specific version of the 1C:Enterprise
application;
• Grant edit rights for the user on whose behalf the web server operates
to the infobase directory (only when in file mode).

8.6.2.3.2. Publishing dialog box

In the Web server field, specify Apache 2.0.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.6.2.3.3. Webinst utility

Before publishing, you need to create a template file:
• In the Web server field, specify Apache 2.2.
• Select check box Publish standard OData interface.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as apache-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -apache2 -wsdir demo-ws -dir "c:\inetpub\demo-ws"
-connstr "Srvr=server:1741;Ref=demo;" -descriptor apache-
template.vrd

8.6.2.4. Apache 2.2

8.6.2.4.1. General description

Besides specifying the parameters of the publication (described below), you
must additionally make the following settings:
• Grant read rights for the user on whose behalf the web server operates
to the bin directory of files of a specific version of the 1C:Enterprise
application;
• Grant edit rights for the user on whose behalf the web server operates
to the infobase directory (only when in file mode).

8.6.2.4.2. Publishing dialog box

In the Web server field, specify Apache 2.2.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.
 8.6.2.4.3. Webinst utility
Before publishing, you need to create a template file:
• In the Web server field, specify Apache 2.2.
• Select check box Publish standard OData interface.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as apache-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -apache22 -wsdir demo-ws -dir "c:\inetpub\demo-ws"
-connstr "Srvr=server:1741;Ref=demo;" -descriptor apache-
template.vrd

8.6.2.5. Apache 2.4

8.6.2.5.1. General description

Besides specifying the parameters of the publication (described below), you
must additionally make the following settings:
• Grant read rights for the user on whose behalf the web server operates
to the bin directory of files of a specific version of the 1C:Enterprise
application;
• Grant edit rights for the user on whose behalf the web server operates
to the infobase directory (only when in file mode).

8.6.2.5.2. Publishing dialog box

In the Web server field, specify Apache 2.4.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.6.2.5.3. Webinst utility

Before publishing, you need to create a template file:
• In the Web server field, specify Apache 2.4.
• Select check box Publish standard OData interface.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as apache-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -apache24 -wsdir demo-ws -dir "c:\inetpub\demo-ws"
-connstr "Srvr=server:1741;Ref=demo;" -descriptor apache-
template.vrd

8.6.3. On Linux
8.6.3.1. General information
This section describes the publication of Standard OData Interface for
Linux-based web servers. It is assumed that the web server is already in-
stalled.
After the publication is performed, you must provide the user, on behalf of
which Apache operates, the rights to the executable files directory
(/opt/1C/v8.3/i386/ for the 32-bit version or /opt/1C/v8.3/x86_64/ for
64- bit version) of a specific version of the 1C:Enterprise application (read
and execute). In the case of the file mode of the infobase, you must give the
rights to modify the infobase catalog to the user, on whose behalf the web
server was started.

8.6.3.2. Apache 2.0

8.6.3.2.1. Publishing dialog box

In the Web server field, specify Apache 2.0.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.6.3.2.2. Webinst utility

Before publishing, you need to create a template file:
• In the Web server field, specify Apache 2.2.
• Select check box Publish standard OData interface.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as apache-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -apache2 -wsdir demo-ws -dir /var/www/demo-ws -
connstr "Srvr=server:1741;Ref=demo;" -confpath
/etc/apache2/httd.conf -descriptor apache-template.vrd

8.6.3.3. Apache 2.2

8.6.3.3.1. Publishing dialog box

In the Web server field, specify Apache 2.2.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.6.3.3.2. Webinst utility

Before publishing, you need to create a template file:
• In the Web server field, specify Apache 2.2.
• Select check box Publish standard OData interface.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as apache-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -apache22 -wsdir demo-ws -dir /var/www/demo-ws -
connstr "Srvr=server:1741;Ref=demo;" -confpath
/etc/apache2/httd.conf -descriptor apache-template.vrd

8.6.3.4. Apache 2.4

8.6.3.4.1. Publishing dialog box

In the Web server field, specify Apache 2.4.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.6.3.4.2. Webinst utility

Before publishing, you need to create a template file:
• In the Web server field, specify Apache 2.4.
• Select check box Publish standard OData interface.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
 • To save the template file, click Save. Enter the name of template file
as apache-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -apache24 -wsdir demo-ws -dir /var/www/demo-ws -
connstr "Srvr=server:1741;Ref=demo;" -descriptor apache-
template.vrd

8.7. HTTP services support

settings
8.7.1. General information
Setting support for HTTP services is to configure your web server for op-
eration with HTTP services and to set the access rights to the directories of
executable files and the database (for the file mode of operation).
To publish HTTP services, select the Publish HTTP services by default
check box on the HTTP services tab, and select the services to be published
in the table below the check box.

8.7.2. On Windows
8.7.2.1. General information
This section describes the publication of HTTP services for Windows-based
web servers. It is assumed that the web server is already installed.
NOTE. To install the IIS web server, you may need a distribution package
of the operating system used.

8.7.2.2. Internet Information Services

8.7.2.2.1. General description

Besides specifying the parameters of the publication (described below), you
must additionally make the following settings:
• Grant read rights for the user on whose behalf the requests are execut-
ed (IUSR_<PC_NAME> user for IIS versions 5.1 or 6.0 or
IIS_IUSRS group for IIS versions 7.x and later) to the bin directory of
files of a specific 1C:Enterprise version
• Grant edit rights to the user on whose behalf the queries are executed
(IUSR_<PC_NAME> user for IIS versions 5.1 or 6.0 or IIS_IUSRS
 group for IIS versions 7.x and later) on the infobase directory (only in
the case of the file mode)
NOTE. Substring <PC_NAME> in the username IUSR_ <PC_NAME>
indicates the name of the computer on which the IIS is installed. So, for a
computer with the name IIS-COMP, the username will look like this:
IUSR_IIS-COMP.

8.7.2.2.2. Publishing dialog box

In the Web server field, enter Internet Information Services.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.7.2.2.3. Webinst utility

Before publishing, you need to create a template file:
• In the Web server field, enter Internet Information Services.
• Select check box Publish HTTP services.
• Select parameters of HTTP services to be published.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as iis-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -iis -wsdir demo-hs -dir "c:\inetpub\demo-ws" -
connstr "Srvr=server:1741;Ref=demo;" -descriptor iis-template.vrd

8.7.2.3. Apache 2.0

8.7.2.3.1. General description

It is necessary to give rights to the user on whose behalf Apache runs for the
bin directory of files of a specific version of the 1C:Enterprise application
(read and execute) and for the directory of the infobase (read and write, in
the case of the file mode).

8.7.2.3.2. Publishing dialog box

In the Web server field, specify Apache 2.0.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.
 8.7.2.3.3. Webinst utility
Before publishing, you need to create a template file:
• In the Web server field, specify Apache 2.2.
• Select check box Publish HTTP services.
• Select parameters of HTTP services to be published.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as apache-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -apache2 -wsdir demo-ws -dir "c:\inetpub\demo-ws"
-connstr "Srvr=server:1741;Ref=demo;" -descriptor apache-
template.vrd

8.7.2.4. Apache 2.2

8.7.2.4.1. General description

It is necessary to give rights to the user on whose behalf Apache runs for the
bin directory of files of a specific version of the 1C:Enterprise application
(read and execute) and for the directory of the infobase (read and write, in
the case of the file mode).

8.7.2.4.2. Publishing dialog box

In the Web server field, specify Apache 2.2.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.7.2.4.3. Webinst utility

Before publishing, you need to create a template file:
• In the Web server field, specify Apache 2.2.
• Select check box Publish HTTP services.
• Select parameters of HTTP services to be published.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as apache-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -apache22 -wsdir demo-ws -dir "c:\inetpub\demo-ws"
-connstr "Srvr=server:1741;Ref=demo;" -descriptor apache-
template.vrd

8.7.2.5. Apache 2.4

8.7.2.5.1. General description

It is necessary to give rights to the user on whose behalf Apache runs for the
bin directory of files of a specific version of the 1C:Enterprise application
(read and execute) and for the directory of the infobase (read and write, in
the case of the file mode).

8.7.2.5.2. Publishing dialog box

In the Web server field, specify Apache 2.4.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.7.2.5.3. Webinst utility

Before publishing, you need to create a template file:
• In the Web server field, specify Apache 2.4.
• Select check box Publish HTTP services.
• Select parameters of HTTP services to be published.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as apache-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -apache24 -wsdir demo-ws -dir "c:\inetpub\demo-ws"
-connstr "Srvr=server:1741;Ref=demo;" -descriptor apache-
template.vrd

8.7.3. On Linux
8.7.3.1. General information
This section describes the publication of Web services for Linux-based web
servers. It is assumed that the web server is already installed.
To publish HTTP services, select the Publish HTTP services by default
check box on the HTTP services tab, and select the services to be published
in the table below the check box.
 After the publication is performed, you must provide the user, on behalf of
which Apache operates, the rights to the executable files directory
(/opt/1C/v8.3/i386/ for the 32-bit version or /opt/1C/v8.3/x86_64/ for
64- bit version) of a specific version of the 1C:Enterprise application (read
and execute). In the case of the file mode of the infobase, you must give the
rights to modify the infobase catalog to the user, on whose behalf the web
server was started.

8.7.3.2. Apache 2.0

8.7.3.2.1. Publishing dialog box

In the Web server field, specify Apache 2.0.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.7.3.2.2. Webinst utility

Before publishing, you need to create a template file (in Designer):
• In the Web server field, specify Apache 2.2.
• Select check box Publish HTTP services.
• Select parameters of HTTP services to be published.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as apache-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -apache2 -wsdir demo-ws -dir /var/www/demo-ws -
connstr "Srvr=server:1741;Ref=demo;" -confpath
/etc/apache2/httd.conf -descriptor apache-template.vrd

8.7.3.3. Apache 2.2

8.7.3.3.1. Publishing dialog box

In the Web server field, specify Apache 2.2.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.7.3.3.2. Webinst utility

Before publishing, you need to create a template file (in Designer):
• In the Web server field, specify Apache 2.2.
 • Select check box Publish HTTP services.
• Select parameters of HTTP services to be published.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as apache-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -apache22 -wsdir demo-ws -dir /var/www/demo-ws -
connstr "Srvr=server:1741;Ref=demo;" -confpath
/etc/apache2/httd.conf -descriptor apache-template.vrd

8.7.3.4. Apache 2.4

8.7.3.4.1. Publishing dialog box

In the Web server field, specify Apache 2.4.
If necessary, specify the remaining publishing parameters on the Additional
tab of the publishing dialog box on the web server.

8.7.3.4.2. Webinst utility

Before publishing, you need to create a template file (in Designer):
• In the Web server field, specify Apache 2.4.
• Select check box Publish HTTP services.
• Select parameters of HTTP services to be published.
• If necessary, specify the remaining publishing parameters on the Addi-
tional tab of the publishing dialog box on the web server.
• To save the template file, click Save. Enter the name of template file
as apache-template.vrd.
Perform publication using the template file.
Example:
webinst -publish -apache24 -wsdir demo-ws -dir /var/www/demo-ws -
connstr "Srvr=server:1741;Ref=demo;" -descriptor apache-
template.vrd

8.8. OpenID authentication

support settings
8.8.1. Settings for OpenID
If the infobase uses OpenID authentication, you must specify the address of
the OpenID provider used for authentication in the default.vrd file (with
which the infobase was published on the web server). The <openid> and
<rely> elements are intended for this.
Example:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns=http://v8.1c.ru/8.2/virtual-resource-system
xmlns:xs=http://www.w3.org/2001/XMLSchema
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/demo"
ib="Srvr=&quot;tcp://Server&quot;;Ref=&quot;demo&quot;;"
enable="false">
<openid>
<rely url="https://myserver.org/users-ib/e1cib/oid2op"/>
</openid>
</point>

These elements describe the URL to the OpenID provider that authenticates
the user to the infobase with OpenID authentication. In this example, the
1C:Enterprise infobase, published at https://myserver.org/users-ib, acts
as the OpenID provider.
This parameter can be configured using the publication dialog on the web
server (OpenID tab).

8.8.2. Configuring an infobase to

act as an OpenID provider
If the infobase acts as an OpenID provider, you must specify this in the de-
fault.vrd file (with which the infobase was published on the web server).
The <openid> and <provider> elements are intended for this.
Example:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns=http://v8.1c.ru/8.2/virtual-resource-system
xmlns:xs=http://www.w3.org/2001/XMLSchema
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/users-ib"
ib="Srvr=&quot;tcp://Server&quot;;Ref=&quot;oidusers&quot;;"
enable="false">
<openid>
<provider>
<lifetime>432000</lifetime>
</provider>
</openid>
</point>

These elements indicate that:

• Infobase acts as an OpenID provider
• Lifetime of the authentication data is 432 000 seconds (or 5 days)
• The URL to be specified in the <rely> element of the default.vrd
file (the address of the OpenID provider) may look like this:
https://myserver.org/users-ib/e1cib/oid2op. The URL will look
like this if the name of the host on which the infobase is published is
myserver.org.
This parameter can be configured using the publication dialog on the web
server (OpenID tab).

8.8.3. Additional interface for use

by external resources
The OpenID provider implemented by 1C:Enterprise can be accessed using
the standard OpenID 2.0 protocol considering some features:
• In requests for interactive and non-interactive authentication (the
openid.mode parameter is equal to checkid_immediate or
checkid_setup), the openid.claimed_id and
openid.identity parameters must be set to
http://specs.openid.net/auth/2.0/identifier_select value. Setting
this value means that the user ID is determined by the provider.
• Requests for non-interactive authentication with other values of
theopenid.claimed_id and openid.identity parameters
result in a request for interactive authentication, during which the pro-
vider determines the values of openid.claimed_id and
openid.identity.
The OpenID provider implements a form for entering a username and pass-
word for interactive authentication.
 The application also provides a number of commands that simplify the use
of an OpenID provider by third-party systems, which are described below.
When describing commands, the following abbreviations are used:
• ProviderIB -infobase of an OpenID provider;
• RPID - infobase of OpenID dependent party
Request parameters are transmitted in UTF-8 encoding.

Request for OpenID Provider XRDS Document

Description:
Gets an XRDS document describing the properties of an OpenID provider.
Syntax:
https://hostname/ProviderIB/e1cib/oid2op
Returns:
XRDS document describing the properties of an OpenID provider.

Request for OpenID dependent party XRDS Document

Description:
Gets an XRDS document describing the properties of an OpenID dependent
party.
Syntax:
https://hostname/RPIB/e1cib/oid2rp
Returns:
XRDS document describing the properties of an OpenID dependent party.

Authentication request
Description:
Performs authentication request.
Syntax:
https://hostname/ProviderIB/e1cib/oid2op?cmd=auth
Parameters:
openid.auth.user mandatory
Username as specified in the OpenID provider's database.
openid.auth.pwd mandatory
User password.
openid.auth.2FCode optional
Second authentication factor code
 opeind.auth.short optional
If the parameters is set to true, the authentication is performed within the
session of the web browser, but not more than the lifetime parameter
value of the default.vrd file, which describes the publication of the in-
fobase of the OpenID provider.
openid.auth.check optional
Response to this request must be checked (the parameter is set to true). It
makes sense only if the openid.return_to parameter is specified.
openid.return_to optional
Contains the target URL that is opened after processing the request.
Returns:
If the openid.return_to parameter is not specified, then an empty
document with the HTTP status code is returned:
• 200 - authentication successful
• 400 - authentication failure
• 402 - login and password authentication is completed successfully.
The second factor code is required. The response should have a header
named 2FAType, which can contain one of the following values:
 secretCode - for authentication, enter the secret code;
 external - the second factor is executed at the provider side.
At the time of receipt of such a response code, a request to execute the
second authentication factor has already been sent by the OpenID-
provider to the provider of the second authentication factor.
It is understood that the OpenID provider will check the username and
the password, but will not create a user session when it detects the
need to execute the second authentication factor. The session will be
created at the next access, checking the login, the password and the
second factor again.
After receiving a response 402, do the following:
 In case of authentication using a code (secretCode), - add the
secret code with additional parameter to the request.
 In case of authentication on the provider side (external), - add
nothing. The server will send for check the authentication request
and will check the second factor.
If the openid.return_to parameter is specified, then it is redirected to
the address specified in the parameter. If authentication is successful, the
following parameters are added to the URL:
• openid.auth.user with username as value
• openid.auth.uid with a one-time identifier as a value to validate
this response This parameter is specified if the
 openid.auth.check parameter is specified in the authentication
request.
In case of unsuccessful authentication, go to the specified URL without add-
ing any parameters.

Request of the OpenID- provider for authentication check

Description:
Executes authentication request.
Syntax:
https://hostname/ProviderIB/e1cib/oid2op/2FACheck?u
ser=xxx
Parameters:
user mandatory
The username (xxx) whose authentication should be checked.
Returns:
An empty document with an HTTP status code is returned:
• 200 - authentication is successful, the user is authenticated using the
second factor;
• 400 - Authentication failed for one of the following reasons:
 The user parameter is not specified;
 There was no regular authentication request before this request;
 Authentication failure;
 Authentication timed out.

OpenID provider request to verify the active authentication

Description:
Authentication check is performed.
Syntax:
https://hostname/ProviderIB/e1cib/oid2op?cmd=lookup
Parameters:
openid.return_to mandatory
Contains the target URL that is opened after processing the request.
openid.auth.check optional
Response to this request must be checked (the parameter is set to true). It
makes sense only if the openid.return_to parameter is specified.
Returns:
Redirecting to the URL specified in the openid.return_to parameter.
If authentication is successful, the following parameters are added to the
URL:
• openid.auth.user with username as value
• openid.auth.uid with a one-time identifier as a value to validate
this response This parameter is specified if the
openid.auth.check parameter is specified in the authentication
request.
In case of unsuccessful authentication, go to the specified URL without add-
ing any parameters.

Check an OpenID provider response

Description:
Checks an OpenID Provider response for cmd=auth and cmd=lookup
requests if the openid.auth.check parameter is set to true in the
request.
Syntax:
https://hostname/ProviderIB/e1cib/oid2op?cmd=check
Parameters:
openid.auth.user mandatory
The username that is obtained from the query parameter of the same name.
openid.auth.uid mandatory
The value of the one-time response identifier of the OpenID provider, ob-
tained from the query parameter of the same name.
Returns:
A document of text/plain type with the following contents is returned:
• is_valid:true - the response is indeed generated by the OpenID pro-
vider used. In this case, the HTTP status code is 200.
• is_valid:false - The used OpenID provider did not generate a valid re-
sponse. In this case, the HTTP status code will be equal to 400.

Request to cancel authentication for a dependent party

Description:
Performs the cancellation of authentication if the OpenID provider URL is
unknown. Finishes the current session, cancels authentication on the
OpenID provider, restarts the web client. The web client will issue a cancel-
lation request for the OpenID provider.
Syntax:
https://hostname/RPIB/e1cib/oid2op?cmd=logout

Request to cancel authentication for an OpenID provider

Description:
Performs the cancellation of authentication on the indicated OpenID pro-
vider.
Syntax:
https://hostname/ProviderIB/e1cib/oid2op?cmd=logout
Parameters:
openid.return_to optional
Contains the target URL that is opened after processing the request.
Returns:
If the openid.return_to parameter is specified, the user is redirected
to the specified URL, otherwise an empty response is returned with the
HTTP status code equal to 200.

8.8.4. Requirements for external

OpenID providers
If it is necessary to use external (in relation to the 1C:Enterprise application)
OpenID providers that are supposed to be used to authenticate users of the
1C:Enterprise infobases, the following should be considered:
1. The OpenID provider must support the OpenID Authentication 2.0
protocol specifications and the extension of this protocol implemented
in the 1C:Enterprise platform.
2. To be able to use the 1C:Enterprise with thin client, the OpenID pro-
vider must use a cookie named vrs_oid2op_auth.
3. When receiving a request with an Accept HTTP header that prohib-
its the use of HTML content in the response, the OpenID provider
should not use redirection with HTML forms (section 5.2.2 of the
OpenID Authentication 2.0 protocol specification).
4. When returning the openid.claimed_id and
openid.identity parameters to the 1C:Enterprise infobases, the
OpenID provider should set the values of these parameters in the for-
mat <address of the OpenID provider>?lid = <user login>, for
example https://myserver.org/users-ib/e1cib/oid2op?lid=user1.
It may also be helpful to consider the following:
• In the case when the 1C:Enterprise infobase calls the OpenID provid-
er, the openid.claimed_id and openid.identity request
 parameters always pass the value
http://specs.openid.net/auth/2.0/identifier_sel
ect.
• 1C:Enterprise infobase does not use a shared secret key (Diffie-
Hellman’s algorithm) to authenticate the provider's messages. Authen-
tication is performed using a direct request to the OpenID provider, in
accordance with the requirements of section 11.4.2 of the OpenID Au-
thentication 2.0 protocol specification.
See also:
• OpenID Authentication 2.0 (see http://openid.net/specs/openid-
authentication-2_0.html).
• OpenID Authentication 2.0, section 5.2.2
(see http://openid.net/specs/openid-authentication-
2_0.html#indirect_comm).
• OpenID Authentication 2.0, section 11.4.2
(see http://openid.net/specs/openid-authentication-
2_0.html#indirect_comm).
• Additional requirements for an OpenID provider.

8.9. Safety while using Internet

services
8.9.1. Authentication
In general, the procedure of client accessing an Internet service is as fol-
lows:

Fig. 98. Internet service connections

There are three different types of authentication:
• On a proxy server-, this authentication is not directly related to the use
of a web server, but you should remember about it if you need to use
an Internet service from a network behind a proxy server.
• In this case, the following types of authentication can be used on the
web server-:
  Anonymous authentication - in this case, all requests coming
from the web server are performed under a special user, which im-
personates the "anonymous" connection.
In this case, the authentication in 1C:Enterprise is performed using
the username and password passed in the HTTP request.
 Basic authentication - in this case, the client of the Internet ser-
vice passes for authentication to the web server the username and
password in an HTTP request that is generated when accessing the
web server.
In order to successfully perform this type of authentication, the
username and password used to access 1C:Enterprise must also be
used to access the web server. If a user, whose parameters are
passed in an HTTP request, cannot access the web server, it means
that he/she will not be able to use the Internet service.
 OS authentication - in this case, the web server determines on
which behalf of the OS user the Internet service performs the ac-
cess to 1C:Enterprise and further this particular data is used.
In this case, the web server determines the OS user who is trying
to access the web server, and then transfers to 1C:Enterprise both
the parameters of the OS user and the data passed in the HTTP re-
quest to the Internet service. If the HTTP request contains the
username and password, then it is they who are used for authenti-
cation, and the OS user data are not used. If the username and
password in the HTTP request are not specified -, the data of a
specific OS user is used.
For a thin client connecting to the infobase via HTTP protocol (via
a web server), and for a web client, the OS authentication opera-
tion is based on the possibility of impersonalizing a web browser
user or a thin client user in a web server thread that executes HTTP
requests. The impersonation of users by a web server depends on
the type and setting of the web browser used, the type and setting
of the web server, the settings of individual user rights, domain se-
curity policies, etc. Impersonation is not always possible.
The corresponding settings are the subject of the administration of
the network environment and are beyond the scope of the
1C:Enterprise documentation.
• 1C:Enterprise authentication. To perform this authentication, the
web server extension uses the username and password that are trans-
mitted by the web server (when using Basic authentication or OS au-
thentication on the web server). If you use anonymous authentication
on a web server, 1C:Enterprise will request Basic authentication from
the caller. 1C:Enterprise expects that the username and password of
the user will be passed in UTF-8 encoding.
 If the Internet service is accessed from the Microsoft Internet Explorer
web browser, it is not recommended to use non-Latin characters in the
username and password.
When interacting with a web server, it is possible to organize operation via
a secure channel.
When using the file mode of the infobase, the users on whose behalf access
is performed must have access to the execution of the files of the required
version of 1C:Enterprise and the rights to read and modify data in the in-
fobase directory.

8.9.2. Operations over a secure

channel
When a client interacts with an Internet services server, data can be ex-
changed over a secure channel. Secure communication channels prevent
unauthorized viewing and alteration of data. The secure channel is TLS-
based (version 1.2). TLS connections support cryptographic algorithms that
comply with GOST R 34.10-94, R 34.10-2001, R 34.10-2012, R 34.11-94,
R 34.11-2012, and 28147-89. The obsolete SSL 3.0 protocol can be enabled
using the command line to start a client connection.
The TLS (Transport Layer Security) - protocol is used to provide secure
communication between a client and a server. TLS is based on:
• Mutual authentication of the client and the server, so that both the cli-
ent and the server are certain of each other's identities
• Digital signatures to ensure data integrity (protecting data from unau-
thorized alteration)
• Encryption to ensure the confidentiality of data (protecting data from
unauthorized viewing)
TLS protocol supports various encryption options, digital signatures, certifi-
cates, etc., in order to provide a secure channel with the required robustness.
TLS protocol uses a TLS session to establish a secure connection between
the a and a server. Session is established by exchanging a sequence of mes-
sages between a client and a server. When establishing a session, the fol-
lowing actions can be performed:
• Determining cryptography algorithms that will be used to encrypt and
digitally sign the transmitted data
• Setting the session key
• Performing server authentication on the client side
• Performing client authentication on the server side
To authenticate client on the server side and server on the client side, TLS
uses certificates. A certificate is a document that describes a set of parame-
ters of the party being authenticated. For example, the certificate may con-
tain the username or the name of the server web site. The certificate also
contains a digital signature, which is used to verify its validity. Chains of
certificates are used to prevent the possibility of uncontrolled issuance of
certificates. The beginning of the chain of certificates is the Certificate Au-
thority- an organization issuing certificates. If a particular user needs a cer-
tificate, he/she sends a request to the Certificate Authority to issue a certifi-
cate. Certificate Authority issues a certificate that is signed with its own
private key. The user to whom the certificate is issued may, in turn, act as a
Certificate Authority for other users. Thus, a chain of certificates is formed,
the root of which is the Root Certificate Authority, which is, as a rule, a
well-known organization. For a client to accept this certificate, it must be on
the list of the certificates that this client trusts. The list can include both this
certificate and any other certificates from the certificate chain of this certifi-
cate. As a rule, this is a certificate from the Root Certificate Authority.
Please remember that 1C:Enterprise operates correctly with certificates only
if the certificate fields contain data in US ASCII or characters encoded with
Punycode. Certificate fields must not contain data in Unicode.
One of the most common uses of the TLS protocol is its use for sending
HTTP requests (the HTTPS protocol). In this case, the URL is the address-
ing scheme for such -HTTPS resources, and the default port is -443.
The client part of the Web services engine automatically, using the URL
scheme (HTTPS) of the location of the Web service, determines that the
interaction with the Web service should be performed over a secure com-
munication channel. The client also requires that a valid certificate be linked
to the server issued by a Certificate Authority known to the client.
A server certificate is valid if its digital signature matches the content of the
certificate, its validity date is not expired, and the website, for which the
certificate was issued, corresponds to the server website. If the certificate is
not valid, for example, the certificate website does not match the server
website, then the client will not be able to communicate via TLS with the
Web services of this website.
In order to enable the operation via TLS protocol, you need to:
• Obtain a server certificate for the website, for which you plan to use
TLS. The certificate is issued by a Certificate Authority and is linked
to this website.
• TLS support must be enabled for the web server.
• In order for an application using a Web service to use a secure con-
nection, you must explicitly specify this when connecting to the Web
service. To do this, when creating WS Determinations and WS
Proxy objects, you must specify the SecureConnection parame-
ter. When using a secure connection, you must specify the
SecureConnectionOpenSSL object as the value of this parame-
ter.
 8.10. Configuring a web server
8.10.1. Internet Information
Services
8.10.1.1. 32-bit web server extension version on
a IIS 64-bit version
If you are using the 32-bit version of a web server extension on a 64-bit
version of the operating system, you must indicate to the web server that it
can run 32-bit applications. To do this, you must perform the following op-
erations:
• For IIS 5.1, IIS 6.0 -, you must start the command interpreter and start
the following command in it:
cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET
W3SVC/AppPools/Enable32bitAppOnWin64 1

• For IIS 7.0 and older -, open the application pool's main settings dia-
log: IIS configuration manager - <Specific server> - Application
pools - <Desired application pool> - Advanced parameters. Set
parameter Allow 32-bit applications to True .

8.10.1.2. Application pool settings

When configuring IIS, remember that within one application pool, more
than one web server extension module cannot be executed which differ only
in the third and fourth digits of the version. To organize such operation, you
should number if the application pools equal to the number of different ver-
sions of expansion modules, and manually tie each virtual application of the
web client to the desired application pool.
If the publication serves a file version of the infobase, it is not recommend-
ed that you allow the web server to create several working processes in the
same application pool. If in the infobase file mode background jobs are
used, for correct operation purposes the number of working processes in the
pool you use must be equal to 1. Working process numbers is managed by
the parameter IIS configuration manager - <Specific server> - Applica-
tion pools - <Desired application pool> - Advanced parameters -
Working processes maximum number (in the parameter group Process
model).

8.10.1.3. Error presentation setup

In cases where the "1C: Enterprise" errors (when working with the IIS web
server of version 7.x and later) are displayed with text of the type 500-, an
internal server error. Problem with requested resource; the resource
cannot be displayed, you must change the parameter that controls the
presentation of errors. To do this, open the dialog to configure the
parameters of the error pages: IIS configuration manager - <Specific
Server> - Web sites - <Default Web Site> - <Virtual application
name> - Error pages - Change parameters… In the opened dialog box,
set the If the server detects an error, return to the value Detailed error
messages parameter. Then, click OK button.

8.10.1.4. Setup of the URL permissible length

When accessing the standard OData interface, the URL can be of significant
length. By default, IIS restricts URL length to 260 characters. To change
this restriction, it is necessary (with administrator rights) in the system
registry, in the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service
s\HTTP\Parameters section, create a UrlSegmentMaxLength
parameter of DWORD type. Set this parameter to a required value or to 0 for
unlimited URL length. Then, restart the computer on which the IIS is
installed.

8.10.1.5. HTTPS-connection setup

In some cases, when downloading large amounts of data over an HTTPS
connection (when using the IIS web server) errors may occur. In these
cases, try to use TLS 1.2 or TLS 1.1 protocol. For IIS 7.5 and later
(Windows Server 2008 R2, Windows 7 and later), it is possible to enable
the use of TLS 1.1 and later protocols. To do this, follow these steps:
1. in the system registry, in the section
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Con
trol\SecurityProviders\SCHANNEL\Protocols\TLS
1.1\Server create DisableByDefault parameter of DWORD
type and set its value to 0.
2. in the system registry, in the section
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Con
trol\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Server create DisableByDefault parameter of DWORD
type and set its value to 0.
3. These actions should be performed on behalf of a user with the admin-
istrative rights.
Then, restart the computer on which the IIS is installed.

8.10.1.6. Embedding Web Client

If you need to embed a web client in a web site, it is recommended to use
the following settings for X-Frame-Origin response header in a web
client application:
 • If an external web site and web client are published on a single web
server, the header accepts sameorigin.
• If an external web site and web client are published on different web
servers, the header accepts allow-from %WebSite%. In this ex-
pression %WebSite% refers to URL (protocol, domain and port) of
an external web site, where an embedded web client is expected to be
used.
• If a web client cannot be integrated with an external web site, the
header accepts deny.
If there is no need to fine-tune the response header, make sure that in the
web client application settings no X-Frame-Origin response header is
available which accepts deny.

8.10.2. Apache
8.10.2.1. General features
In the case of publishing a file mode of the infobase to the Apache 2.2 web
server (running under Windows), it is recommended to add the following
fragment to the Apache web server configuration file (httpd.conf):
<IfModule mpm_winnt_module>
ThreadStackSize 8388608
</IfModule>

If problems occur during the operation of the infobase associated with the
exhaustion of the stack on the web server side, it is recommended to in-
crease the value of the ThreadStackSize parameter. A detailed descrip-
tion of the ThreadStackSize parameter:
http://httpd.apache.org/docs/2.2/mod/mpm_common.html#ThreadS
tackSize.
When using the Apache web server version 2.2 and later, running the Linux
operating system, please use the multi-process worker module. A detailed
description of this module is available at:
http://httpd.apache.org/docs/2.2/mod/worker.html or
http://httpd.apache.org/docs/2.4/mod/worker.html. If the publication
serves a file version of the infobase, it is not recommended that you allow
the web server to create several working processes that serve one publica-
tion. If in the infobase file mode background jobs are used, for correct oper-
ation purposes the number of working processes in the pool you use must be
equal to 1. To manage the number of working processes, set
ServerLimit 1 parameter in the worker module setup section
(<IfModule worker.c> </IfModule> section) of the web server
configuration file. If a multiprocess processing module is different from the
recommended one, for settings of the number of working processes see
documentation for the module you use.

8.10.2.2. Search algorithm for an installed web

server

8.10.2.2.1. Apache 2.0

On Windows
• Service detection:
 An attempt is made to read registry parameter value
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\Apache2\ImagePath.
 In the resulting value, the Apache2.exe fragment is replaced with
conf\\httpd.conf.
 If there is a file in the path received, then the Apache web server
version 2.0 is considered to be detected.
• Detecting the installation directory in the registry:
 An attempt is made to access the registry key
HKEY_LOCAL_MACHINE\Software\Apache Software
Foundation\Apache.
 If the attempt fails, then an attempt is made to gain access to the
registry key HKEY_CURRENT_USER\Software\Apache
Software Foundation\Apache.
 The open section reads the value of the 2.0\ServerRoot pa-
rameter.
 The parameter conf\httpd.conf is added to the parameter value.
 If there is a file in the path received, then the Apache web server
version 2.0 is considered to be detected.
• Detection by default installation directory:
 The configuration file (httpd.conf) in the default installation di-
rectory is being searched for: C:\Program Files\Apache Soft-
ware Foundation\Apache2\conf.
 If the file is found, then the Apache web server version 2.0 is con-
sidered to be detected.
On Linux
The configuration file (httpd.conf) is searched for in the directory:
/etc/httpd/conf/.
8.10.2.2.2. Apache 2.2
On Windows
• Service detection:
 An attempt is made to read registry parameter value
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\Apache2.2\ImagePath.
 In the resulting value, the Apache2.exe fragment is replaced with
conf\\httpd.conf.
 If there is a file in the path received, then the Apache web server
version 2.2 is considered to be detected.
• Detecting the installation directory in the registry:
 An attempt is made to access the registry key
HKEY_LOCAL_MACHINE\Software\Apache Software
Foundation\Apache.
 If the attempt fails, then an attempt is made to gain access to the
registry key HKEY_CURRENT_USER\Software\Apache
Software Foundation\Apache.
 The open section reads the value of the 2.2\ServerRoot pa-
rameter.
 The parameter conf\httpd.conf is added to the parameter value.
 If there is a file in the path received, then the Apache web server
version 2.2 is considered to be detected.
• Detection by default installation directory:
 The configuration file (httpd.conf) in the default installation di-
rectory is being searched for: C:\Program Files\Apache Soft-
ware Foundation\Apache2.2\conf.
 If the file is found, the Apache web server version 2.2 is consid-
ered to be detected.
On Linux
The configuration file (apache2.conf) is searched for in the following di-
rectory: /etc/apache2/.

8.10.2.2.3. Apache 2.4

On Windows
• Service detection:
 An attempt is made to read registry parameter value
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\Apache2.4\ImagePath.
 In the resulting value, the Apache2.exe fragment is replaced with
conf\\httpd.conf.
 If there is a file in the path received, then the Apache web server
version 2.4 is considered to be detected.
• Detecting the installation directory in the registry:
 An attempt is made to access the registry key
HKEY_LOCAL_MACHINE\Software\Apache Software
Foundation\Apache.
 If the attempt fails, then an attempt is made to gain access to the
registry key HKEY_CURRENT_USER\Software\Apache
Software Foundation\Apache.
 The open section reads the value of the 2.4\ServerRoot pa-
rameter.
 The parameter conf\httpd.conf is added to the parameter value.
 If there is a file in the path received, then the Apache web server
version 2.4 is considered to be detected.
• Detection by default installation directory:
 The configuration file (httpd.conf) in the default installation di-
rectory is being searched for: C:\Program Files\Apache Soft-
ware Foundation\Apache2.4\conf.
 If the file is found, the Apache web server version 2.4 is consid-
ered to be detected.
On Linux
The configuration file (apache2.conf) is searched for in the following di-
rectory: /etc/apache2/.

8.10.2.3. Embedding Web Client

If you need to embed a web client in a web site, it is recommended to use
the following settings for X-Frame-Origin response header in the re-
quired publication section of a web server configuration file (httpd.conf):
• If an external web site and web client are published on a single web
server, make sure that a configuration file has the following strings:
LoadModule headers_module modules/mod_headers.so
Header set X-Frame-Options "sameorigin"

• If an external web site and web client are published on different web
servers, make sure that a configuration file has the following strings:
LoadModule headers_module modules/mod_headers.so
Header set X-Frame-Options "allow-from %WebSite%"

In this expression %WebSite% refers to URL (protocol, domain and

port) of an external web site, where an embedded web client is ex-
pected to be used.
• If a web client cannot be integrated with an external web site, make
sure that a configuration file has the following strings:
LoadModule headers_module modules/mod_headers.so
Header set X-Frame-Options "deny"

If there is not need to fine-tune the response header, make sure that none of
the following exist in the configuration file:
LoadModule headers_module modules/mod_headers.so
Header set X-Frame-Options "deny"

8.10.3. Reverse Proxy

Reverse proxy (reverse proxy server) - is a proxy server that relays client
requests from an external network to one or more servers located on the
internal network. Can be used for load balancing and increased safety.
If the access to the web servers on which the 1C:Enterprise infobases are
published is carried out via reverse proxy, then if the reverse proxy is not
properly configured, this may lead to the inoperability of some components.
This may be due to the fact that the request received by the 1C:Enterprise
web server does not come from an external client, but from the computer,
on which the reverse proxy is installed.
To avoid these problems, you should configure reverse proxy so that when
you redirect an HTTP request, the X-Forwarded-Port, X-
Forwarded-Host and X-Forwarded-Proto request headers are ap-
propriately configured. In this case, 1C:Enterprise will be able to correctly
recover the external HTTP request.
A detailed description of the reverse proxy settings should be found in the
documentation for the web server used for this purpose.
Chapter 9.
Configuring web browsers
to operate in the web
client

This chapter describes the settings for web browsers that you need to do to
operate in a web client.

9.1. General settings

If the software that blocks the opening of windows of web browsers or
sending HTTP requests is installed on the computer, on which the web cli-
ent is used, then the necessary websites (addresses of the infobases) should
be included in the list of exceptions.
To ensure stable operation of OS authentication when a thin client connects
via a web server, you need to enter the address of the infobase used in the
trusted zone of the Microsoft Internet Explorer web browser.

9.2. Mozilla Firefox

9.2.1. Connection settings
To get started, apply the following settings:
• Start a web browser.
• In the menu, click Settings.
• Go to the Privacy and Security section and apply the following set-
tings:
 In the Cookies and site data section, select Accept cookies and
site data or add infobase addresses to the exceptions list (to open
the dialog box, click Exceptions…).
You should include the request of the location of the file being saved. To do
this:
• Start a web browser.
• In the menu, click Settings.
• Go to the Main section and perform the following settings:
 In the group Downloads, set the switch to Always ask to save
files.
9.2.2. Automatic authentication
For Mozilla Firefox, you may configure the web browser to use OS auto-
matic authentication.
You can also apply these settings manually:
• Start a web browser.
• In the address bar of the browser, type about:config.
• On the settings page, enter the name of the parameter in the search
bar.
This setting can be performed for three parameters:
 network.automatic-ntlm-auth.trusted-uris.
 In a specific network and web server configuration, you may need
to set values for the network.negotiate-auth.trusted-uris and
network.negotiate-auth.delegation-uris parameters.
• Next, specify a list of web servers used to work with 1C:Enterprise in-
fobase.
Read more about this feature in the article:
https://developer.mozilla.org/En/Integrated_Authentication.
The following is a description of what the above parameters are responsible
for with different authentication methods:
• The web server supports NTLM authentication.
If the name of the web server that is being accessed is listed in the list
of names contained in the network.automatic-ntlm-auth.trusted-
uris parameter, an automatic authentication will be attempted. If the
name of the web server is not found, the browser will show a dialog,
in which you must specify the username and password of the user to
access the web server.
• The web server supports Kerberos authentication.
In order to access the web server with this type of authentication, add
the name of this web server to the network.negotiate-auth.trusted-
uris parameter. For a file infobase, this is enough. If it is necessary to
provide automatic authentication of web client users when using the
1C:Enterprise client/server mode, add the DNS name of this web
server to the network.negotiate-auth.delegation-uris parameter.
If the name of the web server being accessed is not found in the net-
work.negotiate-auth.trusted-uris parameter, no authentication will
be performed and the user will see the Unauthorized 401 error mes-
sage. To inform the user about the actions required from them, the
administrator can modify the error message 401 page (see the docu-
mentation for the web server used).
9.3. Microsoft Internet Explorer
9.3.1. Connection settings
To get started, apply the following settings:
• Start a web browser.
• In the Tools menu, select Browser properties.
• In the window opened, click the Security tab.
• Click Other.
• In the window opened:
 In the Scripts section, set Active Scripts parameter to Allow or
Enable.
 Click OK.
• Go to the Privacy tab. In the Settings section, click Advanced and
specify the following parameters: First-party cookies - select Accept,
Third-party cookies - select Accept. You can also click Sites button
(in the Parameters section) and specify the required parameters for
infobase addresses.
• Click on Advanced. In the Multimedia section, select the Show pic-
tures check box.

9.3.2. Using add-ins, file system

extensions, cryptography
extensions, and client
application agent
extensions
If you intend to use add-ins (barcode scanner, electronic scales, etc.), file
system extensions, cryptography extensions and more, select the appropriate
zone on the Security tab: Trusted sites or Local intranet, and then per-
form the following actions:
• On the Security tab, click Other.
• In the Parameters window, go to the group of the ActiveX controls
and plug-ins parameters. Under the group, Allow the following pa-
rameters by selecting Enable:
 Automatic queries of ActiveX controls
 Script ActiveX controls marked safe for scripting;
 Run ActiveX controls and plug-ins;
 Download signed ActiveX controls.
 • In the same window (Security Settings), set Download signed Ac-
tiveX objects with user permission or Download signed ActiveX con-
trols to Prompt.
You can also configure ActiveX using the ActiveX Installation Service (for
Windows Vista, Windows 7, Windows Server 2008, Windows Server 2008
R2). A detailed description of settings can be obtained:
• for Windows Vista, Windows Server 2008:
http://technet.microsoft.com/en-
US/library/cc721964(WS.10).aspxhttp://technet.microsoft.com/ru-
ru/library/cc721964(WS.10).aspx
• for Windows 7, Windows Server 2008 R2:
http://technet.microsoft.com/en-
US/library/dd631688(WS.10).aspxhttp://technet.microsoft.com/ru-
ru/library/dd631688(WS.10).aspx

9.4. Google Chrome

To get started, apply the following settings:
• Start a web browser.
• In the menu, click Settings.
• Click Additional hyperlink.
• Click Content settings.
• In the Cookies section, select the Allow sites to save and read
cookies (recommended) check box or add infobase addresses to the
exception list.
• In the JavaScript section, check the Allowed (recommended) box or
add the addresses of infobases to the exception list.
You should include the request of the location of the file being saved. To do
this:
• Start a web browser.
• In the menu, click Settings.
• Click Additional hyperlink.
• In the Downloaded files section, select the Always specify a loca-
tion to download check box.

9.5. Safari
To get started, apply the following settings:
• Start a web browser.
• In the menu, click Safari - Settings....
• On the Security tab, select the Enable JavaScript check box.
 • On the Privacy tab, in the Cookies and web site data section, clear
the Block all cookies check box.
You should include the request of the location of the file being saved. To do
this:
• Start a web browser.
• In the menu, click Safari - Settings....
• On the Main tab, set the Folder for downloading files to Ask for
each download.

9.6. Using the web client

The web client features are described in a separate book.
Chapter 10.
Protection against
unauthorized use: specifics
and configuration

10.1. General information

Protection against unauthorized use of the 1C:Enterprise application can be
built on the use of the HASP4 Net network protection system or the soft-
ware licensing system (hereinafter SLS). Any of these systems provides
simultaneous operation of a certain number of users (sessions) with the
1C:Enterprise application. The users can be located both within the local
network and outside it (when using web clients or thin clients connected via
a web server). The choice of a security system is determined by the delivery
of the software product. For comparison of features and application areas of
1C:Enterprise licenses, see the table below.

Feature Software Hardware

Can be stored on user computer Yes Yes
Can be stored on 1C:Enterprise Yes Yes
server
Can be stored on another computer No Yes
in a local network
Licenses stored on the same com- Yes No,
puter can be combined only keys of
different series
Can share over networks for any No Yes
infobase types (license manager)
Can use licensing service Yes, No
both client and
server licenses
License consumption options:

License consumption option Software Hardware

License is acquired by client applica- Per computer Per computer
 License consumption option Software Hardware
tion on a local computer
License is acquired by client applica- Not supported. Per computer
tion from license manager over net-
work
License is acquired by client applica- Per session Per session
tion from 1C:Enterprise server
Web client Per session Per session
Mobile client Per session Per session
"Per computer" license allows to run any number of client applications us-
ing any number of infobases on the computer that has the license. "Per ses-
sion" license is acquired for one session only. Each infobase connection
requires a separate "per session" license.
In addition, you can verify the licensed use of a particular application. Dur-
ing this check, information is used about the application itself and the user,
to whom this application is registered.
IMPORTANT! This chapter only describes the technical aspects of licens-
ing 1C:Enterprise 8. For legitimate use of 1C:Enterprise 8, a different num-
ber of licenses may be required. Read the answers to typical questions on
licensing here: https://1c-
dn.com/library/1c_enterprise_license_acquisition_guide.http://v8.1c.ru/pred
priyatie/questions_licence.htm

10.2. HASP security system

10.2.1. General information
To protect against unauthorized use of the 1C:Enterprise application, the
network security system HASP4 Net can be used. This security system
helps to ensure the simultaneous operation of a certain number of users
(sessions) with the 1C:Enterprise application. At the same time, users can
be located both within the local network and outside it - web clients and thin
clients connected to the infobase via a web server. In this case, users are
counted either by the special - HASP License Manager program, or by the
server part of 1C:Enterprise.
IMPORTANT! Interacting with the HASP License Manager is only possi-
ble over IPv4.
With any method of counting users, one or several computers should be
located on the network, to the USB ports of which the client HASP4 Net
USB keys are connected. The total number of users, who can work with the
application, is defined as the amount of the licenses available in each of the
connected client keys.
IMPORTANT! It does not make sense to attach several HASP4 Net don-
gles of the same series to USB ports of one computer, designed to protect
1C:Enterprise, since these dongles are indistinguishable and only one of
them will be actually used (chosen arbitrarily).
HASP License Manager can be started as a regular Windows application, as
a service (only in Windows 2000 and later), or as a Linux application.
When using a multi-user protection system, there is no need to install the
HASP Device Driver on user computers, on which 1C:Enterprise is running
and to the USB port of which the 1C:Enterprise client dongle is not con-
nected.
You can download the latest versions of the HASP Device Driver and the
HASP License Manager from:
•
 https://releases.1c.ru/project/AddCompDriverHASP
 https://sentinelcustomer.gemalto.com/sentineldownloads
 https://safenet-sentinel.ru/helpdesk/download-space/
•
 https://releases.1c.ru/project/AddCompNetHASP
 https://safenet-sentinel.ru/helpdesk/download-space/
• Aladdin Monitor (Windows only):
https://sentinelcustomer.gemalto.com/DownloadNotice.aspx?dI
D=8589943618.

10.2.2. USB key marking

USB key function Marking
Local client USB key ORGL8
Multi-user client key (the number of users is indi- NET5 ORGL8
cated after “NET”: 5, 10, 20, 50, 100) NET10 ORGL8
NET20 ORGL8
NET50 ORGL8
NET100 ORGL8
Multi-user client key for 300 users NET250+ ORG8A
Multi-user client key for 500 users NET250+ ORG8B
Local key for 32-bit server ENSR8
Local key for 64-bit server EN8SA
A multi-user license for 1 000 users is supplied as a set of two multi-user
licenses for 500 users (two NET250 + ORG8B keys are included in the
package).

10.2.3. Specifications
One key of series ORGL8, ORGL8A and ORGL8B can simultaneously
work on the same computer. The licenses are searched in the following or-
der:
• In the ORGL8 key
• In the ORG8A key
• In the ORG8B key
The 32-bit server USB security key enables to run an arbitrary number of
32-bit working processes on a single physical computer. The 64-bit server
USB security key enables to run an arbitrary number of 32-bit and 64-bit
working processes on a single physical computer.
There is a function of storing the protection key, which license was obtained
by the user during the last connection. During the next access attempt, a
license will be obtained from this key. If a license cannot be obtained from
the stored key, the search for an available license will be performed as de-
scribed above.

10.2.4. Protection against

unauthorized use
To prevent the unauthorized use, the 1C:Enterprise application is provided
to users in a protected form.
The possibility to use the software at one or several workplaces, as well as
the ability to use the 1C:Enterprise server are determined by the existing
license agreements.
One of the components of the security system used is the USB key that pro-
tects against unauthorized use.
For the operation of the product, the use of which is governed by the Li-
cense Agreement for one workplace or for one additional workplace, a USB
key must be connected to the USB port of the computer (for details on in-
stalling the protection driver. If the use of the product is regulated by an
additional multi-user license, insert the USB key to the USB port of the
computer, on which the HASP License Manager is running.
Information about the latest changes in the security system is placed in the
readme.htm file.
10.2.5. Monitoring the client
licenses
10.2.5.1. General information
Depending on the type of client and the location of the key (local or net-
work) with client licenses, several options for license monitoring are availa-
ble. They are reviewed in detail below.

10.2.5.2. File mode

In this case, there are the following options for obtaining licenses.

10.2.5.2.1. Local USB key

Allows running any number of instances of the application in 1C:Enterprise
or Designer mode on a computer with the USB key.

10.2.5.2.2. Multi-user client USB key accessible

over the network through the HASP
License Manager
Provides simultaneous operation of the computers depending on the number
of users in the key. Allows running any number of instances of the applica-
tion in 1C:Enterprise or Designer mode.
The number of licenses is limited by the total number of available licenses
from all computers on the network, on which the HASP License Manager is
installed and configured.

10.2.5.3. Client/server mode

In this case, there are the following options for obtaining licenses.

10.2.5.3.1. Local USB key

Allows running any number of instances of the application in 1C:Enterprise
or Designer mode on a computer with the USB key.
10.2.5.3.2. Multi-user client USB key accessible
over the network through the HASP
License Manager
Provides simultaneous operation of the computers depending on the number
of users in the key. Allows running any number of instances of the applica-
tion in 1C:Enterprise or Designer mode.
The number of licenses is limited by the total number of available licenses
from all computers on the network, on which the HASP License Manager is
installed and configured.

10.2.5.3.3. A local multi-user client key without an

installed HASP License Manager and a
multi-user client key accessible via the
network through the HASP License
Manager
In this case, the key can be located both on the computer where the
1C:Enterprise server is installed (local multi-user client key) and on the
network. The licenses number is counted by the cluster manager to which
the session data service is assigned. In this case, licenses are consumed at
the rate of “one session - one license”. Thus, if two instances of
1C:Enterprise are running on the same computer (in any wake-up mode and
with any kind of client), then two licenses will be spent on it.

10.2.5.4. Web client

Depending on the version of the infobase (file or client/server), licenses are
counted by either the web server extension module (in the file mode) or
1C:Enterprise server (in the client/server mode).
In this case, the key can be located both on the computer where the web
server expansion module is installed (or the 1C:Enterprise server), and on
the network. The web server extension module (or 1C:Enterprise server)
directly counts the licenses. In this case, licenses are consumed at the rate of
“one session - one license”. Thus, if two windows of a web browser are
open on the same computer with access to the same infobase, then two li-
censes will be spent on it.

10.2.5.5. Thin client running via web server

To obtain licenses the thin client may use:
• Local USB key
 • Multi-user USB key accessible for the thin client over the network
through the HASP License Manager
• Web server extension module or 1C:Enterprise server
If the license is obtained directly by a thin client, then on one computer you
may start an arbitrary number of instances of the application in
1C:Enterprise mode.
A license can also be issued by a web server extension module (in the case
of the file mode) or by 1C:Enterprise server (in the case of the client/server
mode). In this case, the web server extension module or the 1C:Enterprise
server directly counts the licenses number. In this case, licenses are con-
sumed at the rate of “one session - one license”. Thus, if two copies of
1C:Enterprise are running on one computer, then two licenses will be spent
for this. In this case, the key can be located both on the computer where the
web server expansion module is installed (or the 1C:Enterprise server), and
on the network.

10.2.5.6. Local key and web client

If a local key is installed on a computer with a 1C:Enterprise server or a
web server (in the case of the infobase file mode), then you can run:
• Any number of Designer instances on a computer with the key
• Any number of client applications (except for the web client) on other
computers if client licenses are available to them
• In case of the infobase file mode:
 One client application (including the web client) on any computer
if the client key is not available to it
 Any number of client applications (except the web client) on a
computer with the USB key
• In case of the infobase client/server mode:
 One client application (including the web client) on any computer
if the client key is not available to it
 Any number of client applications (except the web client) on a
computer with the USB key
In other words, you may perform developing and debugging with a web
client using just the local key.
NOTE. When using a local key, only one web client can be started.

10.2.5.7. COM connection

When using a 32-bit COM connection, the available licenses are searched
for in the following order:
• Local client licenses
 • Local server licenses (both 32-bit and 64-bit)
• Network client licenses
• Client licenses on the 1C:Enterprise server (when in client/server
mode) or on the web server (when in file mode, connected via the web
server)
When using a 64-bit COM connection, the available licenses are searched
for in the following order:
• Local client licenses
• Local server license (64-bit only)
• Network client licenses
• Client licenses on the 1C:Enterprise server (when in client/server
mode) or on the web server (when in file mode, connected via the web
server)

10.2.5.8. Internet services, background jobs

Internet services (web services, HTTP services, and requests to OData) and
background jobs do not require client licenses. However, if the infobase that
provides Internet services operates in a client/server version, you must have
a server license for the operation of the 1C:Enterprise server.

10.2.5.9. Terminal server

In this case, there are the following options for obtaining licenses.

10.2.5.9.1. Local USB key

Using a local key in the terminal session is not possible on the following
operating systems:
• Client operating systems: Microsoft Windows 7 and earlier
• Server operating systems: Microsoft Windows Server 2008 and earlier
If the OS used is later than the above, then using a local key allows only one
user to operate, who has connected to the terminal session with the identifi-
er 0. Allows running any number of instances of the application in
1C:Enterprise or Designer mode. For terminal sessions with a non-zero ses-
sion identifier, local keys are not available.

10.2.5.9.2. Multi-user client key

Licenses from a multi-user client key installed on the terminal server are
available for use only if the HASP License Manager is installed and config-
ured on the terminal server. Client licenses are counted for in a manner sim-
ilar to a multi-user client key available on the network through the HASP
License Manager. In this case, one terminal session is considered as one
workstation.

10.2.5.10. Mobile client

Depending on the version of the infobase, the license is counted by:
• file mode - web server extension module;
• client/server mode - 1C:Enterprise server.
The key can be located both on the computer, where the web server exten-
sion module is installed (or the 1C:Enterprise server), and on the network.
Licenses are consumed at the rate of “one session - one license”. Thus, if
two copies of an application that are connected to the same infobase are
running on the same mobile device, then two licenses will be spent on it.
Also remember: Mobile client always requires a separate client license
(from a multi-user bundle) for its operation. It means that the full develop-
ment of an application running on a mobile client using only a local protec-
tion key is impossible.

10.2.5.11. Shared use of security keys

When 1C:Enterprise server (or web server extension) counts the client li-
censes, then the client licenses, which in Aladdin Monitor have the
Timeout column value equal to 0, will be considered busy. In this regard, it
is not recommended to use the same multi-user HASP keys to simultane-
ously obtain client licenses using the HASP License Manager and the
1C:Enterprise server (or web server extensions).
Also consider: if several ORGL8 series multi-user client keys are detected
on the network, the server will select one random key. After all licenses are
used up for this key, you may use one multi-user ORG8A key, and then you
may use one multi-user ORG8B key. When a client application selects the
same network client key, which is selected by the server, the client applica-
tion can also stop searching for a license in other keys of the same series
available on the network.

10.2.5.12. Standalone server

In case of using the standalone server, a license can be obtained using:
• Local key (thin client only).
• Multi-user USB key accessible for the thin client over the network
through the HASP License Manager
• Standalone 1C:Enterprise server.
If the license is obtained directly by a thin client, then on one computer you
may start an arbitrary number of instances of the application in
1C:Enterprise mode.
If the license is issued by the standalone server, then the licenses are spent
"per session". In this case, the key should be available to the instance of the
standalone server, which serves the used infobase. For the standalone serv-
er, the option to issue licenses must be enabled
(infobase.distribute-licenses parameter of the standalone
server configuration file).

10.2.6. Obtaining a server license

10.2.6.1. Server clusters
The USB security key must be installed on the computer running (one or
more) working process (rphost) of the server cluster. Working processes
may belong to different server clusters. Checking for a server license is per-
formed at the moment when the client application connects to the working
process.
The server USB security key is local and unavailable over the network.

10.2.6.2. Standalone server

The hardware dongle must be installed on the computer on which the
standalone server instance is running. Checking for a server license is per-
formed at the moment when the client application connects to the
standalone server.
When working with a file infobase, there is an option to work simultaneous-
ly up to 3 (three) client sessions (including three sessions) without using the
hardware dongle. At the same time, sessions of background jobs and Inter-
net services are not technically taken into account when calculating the
number of simultaneously used sessions.
The server USB security key is local and unavailable over the network.

10.2.7. Install protection driver

10.2.7.1. On Windows
The HASP Device Driver installation program (haspdinst.exe) is included
in the delivery package and installed on the computer when you install the
1C:Enterprise server cluster.
To install HASP Device Driver, select the menu item Start - Programs -
1C:Enterprise 8 - Additionally- Protection driver installation.
You can also install the HASP Device Driver "manually". To do this, from
the command line, run the haspdinst.exe program located in the
 \Program Files\1cv8\common\ directory with the -i command. Thus, the
command line for installing the HASP Device Driver is as follows:
haspdinst -i

TIP. It is recommended that you first install the HASP Device Driver, and
then attach the key to the USB port.
IMPORTANT! Disconnecting the USB protection key from the USB port
during operation is prohibited!
In case of uselessness the HASP Device Driver can be removed from the
system. To remove HASP Device Driver, select the menu item Start - Pro-
grams - 1C:Enterprise 8 -Additionally - Protection driver removal.
To remove the HASP Device Driver, you can also use the following com-
mand line:
haspdinst -r

10.2.7.2. On Linux
HASP Device Driver for Linux OS is available for download from the man-
ufacturer's website.
To install the HASP Device Driver, perform the following steps (actions
must be performed as administrator):
• Unpack the archive by executing the command:
tar xzf HASP_SRM_LINUX_3.50_Run-time_Installer_script.tar.gz

• Go to the directory with the unpacked driver by executing the com-

mand:
cd HASP_SRM_LINUX_3.50_Run-time_Installer_script

• Install the driver by executing the command (make sure that you enter
the dot at the end of the command line):
./dinst .

TIP. It is recommended that you first install the HASP Device Driver, and
then attach the key to the USB port.
IMPORTANT! Disconnecting the USB protection key from the USB port
during operation is prohibited!
To remove the driver key, go to the directory with the unpacked driver and
execute the command:
./dunst

10.2.7.3. On macOS
The distribution of the protection driver during installation is copied to the
installation root directory and has the name Sentinel_Runtime- <driver
version>.dmg, where <driver version> - is the version of the protection
driver.
To install the driver, open this archive using the Finder and run the Install
Sentinel Runtime Environment file and follow the instructions of the in-
stallation program.
TIP. It is recommended that you first install the HASP Device Driver, and
then attach the key to the USB port.
NOTE. Disconnecting the USB protection key from the USB port during
operation is prohibited!
To delete the driver, open this archive using the Finder and run the Unin-
stall Sentinel Runtime Environment file and follow the instructions of the
uninstall program.

10.2.8. Installing HASP License

Manager
10.2.8.1. On Windows
The 1C:Enterprise application includes the lmsetup.exe utility used to in-
stall the HASP License Manager. The utility is located on the installation
disk of the 1C:Enterprise application and can be started either directly from
the command line or through the 1C:Enterprise installation program menu.
HASP License Manager can be installed on any computer on a local net-
work running Microsoft Windows operating systems. At the same time, in
any of these systems, HASP License Manager can be installed as a normal
application, and in Windows 2000 and later it can also be installed as a
Windows service.
IMPORTANT! Unstable operation of the License Manager is possible if it
is installed on a computer used as a terminal server. Installing the License
Manager on a computer that is used as a terminal server is not recommend-
ed.
To install the HASP License Manager, start the lmsetup.exe installation
program (the following is an example of installing the HASP License Man-
ager version 8.32).

Fig. 99. Language selection

Then select English for the installation (see fig. 99).
Next you need to confirm that you accept the proposed license.

Fig. 100. License Acceptance

In the case of installing HASP License Manager on a computer running
Windows 2000 and later, you will be offered two options for installing
HASP License Manager as an -application (Application) or as a service
(Service). If the HASP License Manager is installed on a computer running
Windows 98/Me, this dialog will be skipped, since only the application can
be installed on these operating systems.

Fig. 101. Selecting installation mode

Next, you be offered to choose the directory where the HASP License Man-
ager executable files and the help file will be placed. If you install HASP
License Manager as a Windows service, the executable files will be placed
in the Windows system directory, and only the help file will be installed in
the selected directory.

Fig. 102. Choosing the installation path for HASP License Manager
At the next step of installation, you are prompted to select a group in which
the shortcuts for starting the HASP License Manager and the help file will
be placed. By default, a new group is created with the name HASP License
Manager, but you can select an existing group or change the name of the
group being created.

Fig. 103. Specifying a group name

When installing the HASP License Manager as a Windows application, you
will be prompted to place the HASP License Manager shortcut in the
Startup directory). In this case, the HASP License Manager will start au-
tomatically when the operating system boots. If you choose the other op-
tion, you will have to start the HASP License Manager manually.

Fig. 104. Selecting run mode

At the next step, it is proposed to install the HASP Device Driver, which is
necessary for the normal operation of the HASP License Manager. Using
this driver, the HASP License Manager interacts with the HASP4 Net USB
dongle. If the HASP Device Driver has already been installed on the com-
puter, then reinstalling the HASP License Manager is not required.

Fig. 105. Install protection driver

After the installation process is complete, you will be prompted to start the
HASP License Manager. If you refuse, you can start it later manually. Pro-
cedures for starting the HASP License Manager for various installation op-
tions are described below.

Fig. 106. HASP License Manager starting dialog

 10.2.8.1.1. Starting HASP License Manager as
Microsoft Windows application
If the HASP License Manager was installed as a Microsoft Windows appli-
cation, it is started by running the program file nhsrvw32.exe, which is
placed on the hard disk of the computer by the HASP License Manager Set-
up program.
When you run nhsrvw32.exe from a command line, you can set the param-
eters, by which HASP License Manager can be more “instructed” about
using a particular network protocol for interaction with the protected pro-
grams.
It should be noted that configuring network protocols makes sense only
when the default mode of using the network protocols causes unstable oper-
ation or there are serious delays in running protected programs.
Each parameter is preceded with "-" or "/". Example:
nsrvw32 -tcpip

Or:
nsrvw32 /tcpip

When you start the nhsrvw32.exe program, the following parameters can
be used.
-addrpath=<path>
Specifies where to save the haspaddr.dat file. By default, the file is saved
in the directory where the HASP License Manager was downloaded.
-ipx
Instructs the HASP4 Net application to use the IPX protocol with SAP.
-ipxnosap
Instructs the HASP4 Net application to use the IPX protocol without SAP.
When using the HASP License Manager for Win32, other protocols can be
loaded using the-tcpip or -netbios commands. In this case, the HASP Li-
cense Manager creates a newaddr.dat file that contains the address of the
station where the HASP License Manager is running. When you download
the HASP License Manager with one of these keys, only those protected
applications that have access to the newaddr.dat file will be able to ex-
change data with it.
-ipxsocket num=<number>
Use this parameter if you want to change the socket that is used to exchange
data with HASP License Manager. The default socket is 7483 (hex value).-
-localnet
This parameter should only be used if you want the HASP License Manager
to serve the stations exclusively on the local network. If the HASP License
Manager receives requests from workstations that are not on the local net-
work, they get error code 140.
-nbname=<name>
Assigns a NetBIOS name to the HASP License Manager. The parameter
action is identical to -nethaspnb name.
-netbios
This parameter allows you to use the HASP4 Net application only with
NetBIOS protocol. When using the HASP License Manager for Win32,
other protocols can be loaded using the -tcpip or -ipxnosap commands.
-portnum=<number>
If you use TCP/IP, this parameter allows you to specify a network port that
will use the HASP License Manager. The default port is 475.-
-srvname=<name> [,name]
Assigns one or more IPX, TCP/IP, or NetBIOS names to the HASP License
Manager. A maximum of 6 names can be assigned.
-tcpip
This parameter allows you to use the HASP4 Net application only with
TCP/IP protocol. When using the HASP License Manager for Win32, other
protocols can be loaded using the -ipx or -netbios parameters.
-use lananum=<x> [,x]
Instructs HASP License Manager to operate with specific communication
channel numbers.
-userlist
Limits the number of users serviced by the HASP License Manager. The
default value is 250.-
 10.2.8.1.2. Running HASP License Manager as a
Microsoft Windows service
HASP License Manager can be started as a Microsoft Windows service
only if it was installed to operate as a service. And this, as noted above, is
possible only in the Microsoft Windows 2000 and earlier versions of operat-
ing systems.
When you install HASP License Manager as a Microsoft Windows service,
it is installed as a startup, i. e. the HASP License Manager will start every
time you start Microsoft Windows.
If necessary, you can change the startup settings of the service and start and
stop it manually.
To start, stop, and configure the HAPS License Manager service manually,
you should refer to the control menu Start- Setup- Control Panel- Admin-
istrative Tools - Service (Start- Control Panel- Administrative Tools -
Services). In the list of services that appears, you need to find the HASP
Loader service and right-click it. Through the context menu that appears,
you can perform all the necessary actions with the service.

10.2.8.2. On Linux
Download HASP License Manager for Linux before proceeding with the
installation. HASP License Manager also requires you to install HASP De-
vice Driver.
To install the HASP License Manager, perform the following steps (actions
must be performed as administrator):
• Copy the downloaded file to the directory where the HASP License
Manager will be located (for example,/opt/hasplm).
• Unpack the archive by executing the command:
tar xzf hasplm_linux_8.30.tgz

• Add the HASP License Manager starting command (before exit 0

command) to the /etc/rc.local file from the directory where it was
unpacked:
/opt/hasplm/hasplm

Adding a command to the rc.local file will cause the HASP License
Manager to start automatically when the system restarts.
• Start HASP License Manager by executing the command:
hasplm

If you want to configure the HASP License Manager using the nhsrv. ini
configuration file, the path to the configuration file should be specified in
the HASP License Manager command line:
/opt/hasplm/hasplm -c /etc/nhsrv.ini

10.2.8.3. Configuring the HASP License Manager

with a configuration file
Some HASP License Manager settings can be set using the nhsrv.ini con-
figuration file.
If you are using keys with a lot of user licenses (for 300, 500, and 500 us-
ers), please pay attention to the NHS_USERLIST parameter when configur-
ing HASP License Manager.

10.2.9. Setting up the

1C:Enterprise application
for operation with the
HASP License Manager
The 1C:Enterprise application is capable of using IPX, TCP/IP, or NetBIOS
network protocols to communicate with the HASP License Manager. By
default, the network protocol definition is automatically defined. This mode
is always recommended, except when the automatic network protocol detec-
tion and communication setup mode is unstable or causes significant delays.
NOTE. Accessing the HASP License Manager is always made via UDP.
Specifying the TCP/IP protocol in the nethasp. ini file is ignored.
To configure the parameters of the interaction of the 1C:Enterprise applica-
tion with the HASP License Manager, the configuration file nethasp.ini is
used.
Example of nethasp.ini file:
[NH_COMMON]
NH_TCPIP=Enabled

[NH_TCPIP]
NH_SERVER_ADDR=192.168.0.12
NH_PORT_NUMBER=475
NH_TCPIP_METHOD=UDP
NH_USE_BROADCAST=Disabled

In this example, the protection server is located on the network at

192.168.0.12, the network port 475 is used, UDP packets are used, and the
TCP/IP broadcast mechanism is denied.
When installing the 1C:Enterprise application, the sample file nethasp.ini
is copied to the directory of the configuration files of the 1C:Enterprise ap-
plication. This file is almost entirely composed of commented lines and
does not override the default settings in any way but it contains at the same
time the most complete list of parameters that can be used to configure the
interaction of the 1C:Enterprise system with the HASP License Manager.

10.3. Software Licensing System

10.3.1. General information
10.3.1.1. Overview and terms
The Software Licensing System ensures that users interact without using
any additional physical devices. For operation you need to use a special-
platform software license file. This file, in encrypted form, contains the
information required for the operation of the application, - the parameters of
the license itself and the characteristics of the object, for which the license
is activated. Activation (binding) - is the procedure of acquiring a soft-
ware license file in accordance with its (license) characteristics: serial num-
ber of the kit, and PIN code. When activated, a software license becomes
associated either with the computer's hardware, or with a HASP dongle
available locally or in the network. Several PIN-codes are supplied in the
package. The number of PIN codes in the package and the number of simul-
taneously active PIN codes are determined by the license type.
Application 1C:Enterprise (client or server), if required to obtain a license,
searches for license files for all available paths. Next, the parameters of the
license and the characteristics of the object, for which the software license
was obtained, are received from the files. If the parameters of the current
object received from the license file match the actual object parameters, -
checks are performed related to the number of users and the license type
(client or server), otherwise the license is rejected. Access to the file is de-
termined by the access rights of the operating system. If the user on whose
behalf the application is running, does not have access to the license file (or
the directory where the file is located), then the license will not be obtained.

10.3.1.2. Types of software licenses:

Software licenses can be:
• Single-user client. Allow you to run any number of client applications
on the same computer.
• Multi-user client. Allow you to run a certain number of client applica-
tions from arbitrary computers. The number of client applications run-
ning simultaneously is determined by the license value.
• Combined client. They are a combination of a single-user group and a
one multi-user license. If any single-user license is activated first, - the
multi-user license will not be activated and only single-user licenses
can be used. If a multi-user license is activated first, - single-user li-
censes cannot be activated.
• Server license for a 32-bit server. Allows the use of an arbitrary num-
ber of 32-bit working processes (rphost) on one computer.
• Server license for a 64-bit server. Allows the use of an arbitrary num-
ber of 32-bit or 64-bit working processes (rphost) on one computer.
• A server license with a limited number of concurrent sessions. Allows
the use of one working server of any bit capacity (32 or 64) on one
computer.

10.3.1.3. License location and combined use

Multi-user licenses can be located on a 1C:Enterprise server computer, a
Web server extension module, or a terminal server. Only single-user licens-
es can reside on the client computer. Software licenses located on the server
(1C:Enterprise or terminal), are added without restrictions. Software licens-
es can be used together with HASP dongles (in this event, the available li-
censes are combined). In the case of shared use, the software licenses will
be used first and then - the licenses from the HASP keys.

10.3.1.4. Key parameters

A software license is associated either with the computer's hardware, or
with a HASP dongle available locally or in the network (using license man-
ager). If a software license is associated with a computer, key parameters of
the computer's hardware are collected and analyzed. A software license can
be associated with any HASP dongle in use by 1C:Enterprise.
Depending on association type, the following key parameters are analyzed:
• Association with computer:
 Key parameters:
 Operating system name
 Operating system version (for Windows, only the first two dig-
its of the version number are analyzed)
 OS serial number (Windows only, excluding Windows 10)
 OS installation date (Windows only, excluding Windows 10)
 Network name of the computer
 Motherboard model
 RAM memory
 BIOS type and version
 List of processors and their parameters
 list of network adapters and their MAC addresses, however, the
key parameter comparison procedure the following is exclud-
ed:
 Bluetooth network adapters
 Network adapters connected to IEEE 1394 or USB
 WAN and RAS software adapters
 Adapters that do not have MAC addresses or VEN_ and
DEV_ data from the PNP ID
 List of hard disks and their parameters
 Usage:
 If at least one of the key parameters is changed during the op-
eration, it will be necessary to reactivate the software license
(using a new PIN code). Computer parameters are polled not
more than once a day.
 USB and IEEE 1394 storage devices are ignored.
 When verifying that the software license is compliant with the
settings of the current computer, the operating system name
and version are not parsed if the scan is running on Linux.
• Association with HASP dongle:
 Key parameters:
 Dongle series
 Dongle type
 Dongle ID
 Usage:
 Each PIN code can be used to associate a software license with
one HASP dongle only. However, the PIN code can be used
any number of times to reactivate the software license for the
same owner and the same HASP dongle.
  You cannot use the software license with any HASP dongles
except the one associated with this license.
 When HASP dongle is used with license manager, activation
check occupies 1 free license for 1 second. Activation check is
performed once every 20 seconds or more.
 If multiple keys of the same series are used across the network,
it is recommended that you specify the correct license manager
in file nethasp.ini located on the computer where the activated
software license is stored.

10.3.1.5. Available software licenses

The software license file is considered available for use if:
• It is not in the blacklist.
• It has a correct format.
• It is associated with the current computer, or the associated HASP
dongle is in use on this computer.
• Contains an available license.
• The network does not use other license files obtained for the same
PIN-code and serial number of the program. If such a situation is de-
tected, the license file is rendered unusable and blacklisted. If several
license files obtained for one serial number are detected on one com-
puter, then such files are not blacklisted, and only one file that was
created or used most recently is used.
Hereinafter in this section, terms "software license file" and "software li-
cense" will refer to an available software license as defined above.

10.3.1.6. Software licenses and virtual machines

If you use 1C:Enterprise on virtual computers, you must activate the soft-
ware license on each virtual machine. When using virtual machines, the
software license is attached to the virtual machine settings (the virtual ma-
chine parameters are equivalent to the real computer parameters and are
listed above). If any of these parameters are changed (this might happen
during virtual machine migration or load redistribution, among others), you
will need to reactivate the license using a new PIN code.
To avoid reactivating software licenses on virtual machines:
• Use a licensing service installed on a physical computer or a virtual
machine with fixed parameters (supported in client/server mode only).
• Associate the software license with a HASP dongle. In this event, the
dongle must be available on the virtual machine both before and after
migration.
• Use both methods described above, whenever possible.
10.3.1.7. Activation and usage
When planning to use software licenses, keep in mind the following peculi-
arities:
• no more than 256 processes from one operating system session can
simultaneously access to a one software license file;
• on one computer, you can access one software license file from up to
256 operating system sessions.
If the software license is activated on per-computer basis, please keep in
mind the following:
• When checking computer information, only the removal of devices is
analyzed, not the addition of devices. For example, when you activate
the software license, one network adapter was installed on your com-
puter. You can add another network adapter without having to reacti-
vate the software license, but you cannot replace one network adapter
with another.
• You can increase the RAM on your computer, but you should not re-
duce it. For example, license activation was performed with 2 GB
RAM. Without the need to reactivate the software license, you can in-
crease the memory to 6GB and then reduce it to 4GB. However, re-
ducing the amount of RAM below 2GB will require reactivation of the
software license.
• Changes are analyzed by the current state of the computer relative to
the state when the license was activated.
A Licensing Center web page http://users.v8.1c.ru/lc/en is for receiving
software licenses on electronic media. You have to submit a license request
file (generated using this window) to the Licensing Center and get the li-
cense data file in return from the Licensing Center. A web service
http://users.v8.1c.ru/LicenseCenter/ws/lm.1cws is for automatic re-
ceiving of software license.

10.3.2. License types

Client software license types:

Set of PIN codes

License
Type
Qty Users Active Supplied

Single-user, 1 user 1 1 1 3
 License
Type Set of PIN codes
Qty
Combined, 5 users 5 1 5 8

5 1 3

Combined, 10 users 10 1 10 14

10 1 3

Combined, 20 users 20 1 20 25

20 1 3

Multi-user, 50 users 50 50 1 3

Multi-user, 100 users 100 100 1 3

Multi-user, 300 users 300 300 1 3

Multi-user, 500 users 500 500 1 3

Multi-user, 1,000 1000 2*500 2*1 2*3

users
Multi-user license for 1,000 users is delivered as a set of two multi-user
licenses for 500 users.
For combined licenses, you can determine which type of license is most
suitable for your needs. If a single-user license is activated first when oper-
ating with a combined license, it is considered that a set of stand-alone li-
censes is selected and the Multi-user license becomes impossible. If a Mul-
ti-user license is activated first, it is considered that a multi-user license has
been selected and further activation of single-user licenses becomes impos-
sible.
NOTE. PIN codes additionally included in the delivery, can be used if the
key license parameters are changed.
Server Software License options:

Set of PIN codes

Type Description
Active Supplied
 Type Description Set of PIN codes
Server, Allows the use of an arbi- 1 3
32-bit trary number of 32-bit
working processes on one
physical computer
Server, Allows the use of an arbi- 1 3
64-bit trary number of 32-bit or
64-bit working processes
on one physical computer
A server license Allows the use of one 1 3
with a limited working server of any
number of con- bitness on one physical
current sessions computer
Server license with a limited number of concurrent sessions allows to run
one working server of arbitrary bitness (32- or 64-bit) on one computer,
while maintaining a maximum of 5 client sessions and 1 Designer session.
The following sessions are understood as client sessions: thick client, thin
client, web client, external connection. Client applications use client licens-
es that are obtained in the usual way.

10.3.3. Protection against

unauthorized use
To prevent the illegal use of 1C:Enterprise, it is provided to users in a pro-
tected form.
The possibility to use the software at one or several workplaces, as well as
the ability to use the 1C:Enterprise server are determined by the existing
license agreements.

10.3.4. Monitoring the client

licenses
10.3.4.1. General information
Depending on the type of client and the location of file with software li-
censes, several options for accounting licenses are possible. Subsections
below contain detailed information on client software license accounting
methods.
10.3.4.2. File mode
In this case, you may use only single-user licenses that ensures that the
computer that contains the software license file will run an arbitrary number
of application instances in 1C:Enterprise mode or in Designer.
The exception is the terminal mode of 1C:Enterprise. In this case, it is pos-
sible to use multi-user license infobase with file mode.

10.3.4.3. Client/server mode

In this case, there are the following options for obtaining licenses.

10.3.4.3.1. Single-user software license

Allows running any number of instances of the application in 1C:Enterprise
mode or Designer on a computer with a software license file.

10.3.4.3.2. Multi-user software license

1C:Enterprise server counts the licenses.
In this case, the software license files are located on the computer where the
1C:Enterprise server is installed. The server directly counts the licenses. In
this case, licenses are consumed at the rate of “one session - one license”.
Thus, if two instances of 1C:Enterprise are running on the same computer
(in any wake-up mode and with any kind of client), then two licenses will
be spent on it.

10.3.4.4. Web client

Depending on the version of the infobase (file or client/server), licenses are
counted by either the web server extension module (in the file mode) or
1C:Enterprise server (in the client/server mode).
In this case, the software license file can be located on the computer where
the web server extension module is installed, or on the computer where the
1C:Enterprise server is installed. The web server extension module (or the
server) directly counts the licenses. In this case, licenses are consumed at
the rate of “one session - one license”. Thus, if two instances of
1C:Enterprise are running on the same computer (in any wake-up mode and
with any kind of client), then two licenses will be spent on it.

10.3.4.5. Thin client running via web server

To obtain licenses the thin client may use:
• Single-user software license
• Web server extension module or 1C:Enterprise server
In this case of single-user license that ensures that the computer with a
software license file will run an arbitrary number of application instances in
1C:Enterprise mode.
If you use a web server extension module or 1C:Enterprise server to obtain
a license, then the web server extension module counts the licenses for file
mode, and 1C:Enterprise server - for client/server mode. In this case, licens-
es are consumed at the rate of “one session - one license”. Thus, if two in-
stances of 1C:Enterprise are running on the same computer (in any wake-up
mode and with any kind of client), then two licenses will be spent on it.
The software license file can be located on the computer where the web
server extension module is installed, or on the computer where the
1C:Enterprise server is installed.

10.3.4.6. Single-user software license and web

client
If a single-user software license is installed on a computer with a
1C:Enterprise server or a web server (in the case of the infobase file mode),
you can run:
• Any number of Designer instances on a computer with a single-user
software license file.
• Any number of client applications (except for the web client) on other
computers if they have access to client licenses.
• One of the following startup options is also available:
 One client application (including the web client) on any computer
if the client license is not available to it.
 Any number of client applications (except the web client) on a
computer with the software license file.
In other words, you may perform developing and debugging with a web
client using just the single-user software license. However, when you use
the web client on the local computer, you still have the option to run only
the Designer, other types of clients cannot be started.

10.3.4.7. COM connection

When using a 32-bit COM connection, the available licenses are searched
for in the following order:
• Single-user software licenses
• Multi-user software licenses
• Client licenses on the 1C:Enterprise server (when in client/server
mode) or on the web server (when in file mode, connected via the web
server)
When using a 64-bit COM connection, the available licenses are searched
for in the following order:
• Single-user software licenses
• Multi-user software licenses
• Client licenses on the 1C:Enterprise server (when in client/server
mode) or on the web server (when in file mode, connected via the web
server)
If COM connection is started from the code executed on the 1C:Enterprise
server as the in-process COM server, and the server uses the server software
license, then the COM connection uses the server software license. Other-
wise, the COM connection searches for the client software license as de-
scribed above in this section.

10.3.4.8. Internet services, background jobs

Internet services (web services, HTTP services, and requests to OData) and
background jobs do not require client licenses. However, if the infobase that
provides Internet services operates in a client/server version, you must have
a server license for the operation of the 1C:Enterprise server.

10.3.4.9. Terminal server

10.3.4.9.1. General information

When using Windows applications, consider the following feature: in the
software licensing system, the workplace is determined by the session ID
number. All license requests made from the same computer and with the
same session ID are considered to have been received from one workplace.
For example, if there is a computer that has a single-user software license
installed, the license can be used by an arbitrary number of client applica-
tions running interactively. However, if on this computer the client applica-
tion (in any mode) will be started from any Windows- service, it will be
considered as analogue of the terminal server, and an additional license will
be required. This feature concerns any software licenses (not necessarily
single-user).
You can also consider the following features of client license registration:

10.3.4.9.2. Single-user software license

Allows running any number of application instances in 1C:Enterprise mode
or in Designer on behalf of one terminal session.
Software licenses (both single-user and multi-user) stored on the terminal
server are added if the license files are available to all users of the terminal
server.

10.3.4.9.3. Multi-user software license

Multi-user software license can be stored on a terminal server and used for
both file and client/server modes of the application. In this case, you can run
any number of application instances in 1C:Enterprise mode or Designer for
the number of concurrent connections to the terminal server (terminal ses-
sions) equal to the number of users a multi-user software license covers.
Software licenses (both single-user and multi-user) stored on the terminal
server are added if the license files are available to all users of the terminal
server.

10.3.4.10. Mobile client

Depending on the version of the infobase (file or client/server), licenses are
counted by either the web server extension module (in the file mode) or
1C:Enterprise server (in the client/server mode).
In this case, the software license file can be located on the computer where
the web server extension module is installed, or on the computer where the
1C:Enterprise server is installed. The web server extension module (or the
server) directly counts the licenses. In this case, licenses are consumed at
the rate of “one session - one license”. Thus, if two instancies of mobile
client are running on one mobile device, then two licenses will be spent for
this. If Designer is running on the computer where the web server is located,
and a mobile client is running on the mobile device that uses the web server
to access the infobase, two licenses will also be required for such access.

10.3.4.11. Standalone server

In case of using the standalone server, a license can be obtained using:
• Local software license (thin client only).
• Standalone 1C:Enterprise server.
If the license is obtained directly by a thin client, then on one computer you
may start an arbitrary number of instances of the application in
1C:Enterprise mode.
If the license is issued by the standalone server, then the licenses are spent
"per session". The file with the activated software license must be accessi-
ble to the instance of the standalone server, which serves the infobase used.
When defining availability, consider the user on behalf of whom the
standalone server instance is running. For the standalone server, the option
to issue licenses must be enabled (infobase.distribute-licenses
parameter of the standalone server configuration file).

10.3.5. Activating and obtaining

a server license
10.3.5.1. Server clusters
The software license must be activated for the computer that is running (one
or more) of the server cluster working process (rphost) or the Cluster Man-
ager (rmngr), to which the Licensing Service is assigned.
Checking for a server license is performed at the moment when the client
application connects to the working process (rphost).
If the server license is issued by the cluster licensing service, you should
keep in mind the following feature of the service: if the licensing service is
simultaneously available software licenses for the 32- and 64-bit
1C:Enterprise server, then when requesting the license for the 32-bit server
a license for the 64-bit server can be issued instead. This happens if, at the
time of the license request, the 64-bit server license is the first available
license (in the order of the files in the activated licenses directory). Thus, it
is not advisable that one licensing service distributes software licenses for
1C:Enterprise 32- and 64-bit servers.

10.3.5.2. Standalone server

The software license must be activated for the computer running the
standalone server.
Checking for a server license is performed at the moment when the client
application connects to the standalone server.
When working with a file infobase, there is an option to work simultaneous-
ly up to 3 (three) client sessions (including three sessions) without using an
activated server license. At the same time, sessions of background jobs and
Internet services are not technically taken into account when calculating the
number of simultaneously used sessions.
10.3.6. Software license
activation
10.3.6.1. General rules
One of the protection system components is the software license for the use
of 1C:Enterprise. Software licenses can be activated by either of these utili-
ties:
1. License activation wizard, which is available in the Configurator using
the Service - Obtaining License ... command.
2. ring utility.
When activating a license:
• Select an action:
 Acquire a license (choose the Acquire a license option)
 Upload license details file to acquire the license using an external
storage device (choose the Specify license details file option)
• If you want to get the license, specify the distribution package number
and PIN code.
• Click Advanced settings to specify additional parameters related to
license activation:
 To associate the license with 1C:Enterprise server, select the In-
stall the license on the server check box and enter the
1C:Enterprise server access parameters into Server and Port
fields. You should choose this option when you associate the soft-
ware license with 1C:Enterprise server using Designer on another
computer. In this case, the file with the activated software license
will always be placed in the profile directory of the user, on behalf
of which the 1C:Enterprise server (by default- usr1cv83) is oper-
ating on the computer where this 1C:Enterprise server is running.
 The Automatic acquisition check box determines the software li-
cense activation method. If the check box is selected, - the license
will be activated automatically. If the check box is cleared, you
will be prompted to choose one of 3 license activation methods:
automatically, on an external storage device, or by phone.
• Select an operation with license:
 First-time registration - initial license acquisition,
 Recovery - license reacquisition or update.
• For first-time registration, you need to enter the license owner's pa-
rameters. Then, choose whether you want to associate the software li-
cense with a computer (description of this computer will be specified),
 or with an available HASP dongle (a list of available HASP dongles
will be displayed).
• For license recovery:
 If key parameters of the computer associated with the license did
not change, select the I am sure the key computer parameters
have not been changed check box.
 If key parameters of the computer associated with the license did
change, clear the I am sure the key computer parameters
have not been changed check box. Then, enter the extra (un-
used) kit PIN code in the Extra PIN field.
 Check registration data of the license owner and select association
with a computer or a HASP dongle.
• The license is activated for all users on the computer. If the user on
whose behalf the license is being activated cannot write to a directory
that is available to all users, the application will notify you and prompt
you to activate the license only for the current user.
• To acquire a license on an external storage device:
 Create the license request file
 Obtain a license from the Licensing Center
• When you obtain a license manually please:
 Read to the Licensing Center operator the digits that are displayed
in the wizard window (48 digits).
 Enter the software license data read by the Licensing Center opera-
tor into the special field (120 digits).
NOTE. Remember that when you download a file from the Licensing Cen-
ter, the settings (information about the software product and the license
owner) specified in the License Activation dialog should be exactly the
same as when you created License request file.
When activating licenses, remember:
• If the initial activation of the software license was carried out via the
Internet or on an electronic media, the reactivation and renewal of the
license is possible only via the Internet or on the electronic media.
• If the initial activation of the software license was performed manual-
ly by phone, then reactivation and renewal of the license is possible
only manually by phone.
• If you want to activate an additional client software license on a com-
puter, on which the software license is already activated, do so exactly
as you did with the first software license on the this computer.
• When you re-obtain or update a license, move the file with the current
license (for this PIN-code and serial number) to a directory that is not
 used by the 1C:Enterprise application for software licenses search.
Otherwise, the new (and already existing) license will be blacklisted
and cannot be used.
• If you are activating a server and a multi-user software license and it
is possible to run Designer on a computer with the 1C:Enterprise serv-
er installed, then complete the activation of both licenses from the
computer, on which the 1C:Enterprise server is located.
• Network devices and external storage devices that are connected
through the USB and IEEE 1394 interfaces are not considered during
verifying the license file binding to this computer.
However, while you obtain a media license, when requesting the Li-
censing Center to obtain a license and creating the license file by us-
ing a Licensing Center response, the computer settings must coincide
with devices settings connected by USB and IEEE 1394. If this re-
quirement is not met, you will receive an error message when down-
loading the response file from the Licensing Center in the license ob-
taining dialog: Licensing Center response does not match the li-
cense or owner data you entered. Check the kit registration
number, PIN code and license owner information. To complete
license activation in this case, you must return the computer configu-
ration to the state when the license request file was generated, fro ex-
ample, insert the same external drive into the USB port, and then re-
peat loading of the same License Center response file. After that, the
external drive can be removed.
If you cannot restore your computer settings, you will need to re-
obtain the license using an additional PIN code.
• Before re-activating the license for the previously used PIN code, or
for a new PIN code from the same kit, you need to ensure that there
are no 1C:Enterprise applications in the local network using the previ-
ously obtained license file with PIN code from the same kit.
The activated software license file consists of two sections. The starting
section stores parameters of the activated license and parameters of the as-
sociated object. This information is encrypted. The final section stores the
same information in human-readable format. Parameters of the associated
object can be displayed in shortened form. The human-readable information
does not affect the license validity in any way. It can be edited freely.
You should not store one software license file at the same time in several
different directories available to 1C:Enterprise applications. This may cause
the license file to become unusable due to violation of the license agree-
ment. In this event, a text description of license invalidation reason might be
written to the beginning of the license file.
When you automatically receive a software license file, this file is located:
• For a computer with 1C:Enterprise server:
 On Windows OS: in
the%ALLUSERSPROFILE%\Application Data\1C\licenses
(%ALLUSERSPROFILE%\1C\licenses for Windows Vista and
later) directory of the user on whose behalf the 1C:Enterprise serv-
er runs.
 On Linux: In the /var/1C/licenses directory.
• The current computer- will be asked, to whom the obtained license
can be available:
 If the current user is selected, the file will be placed in the directo-
ry:
 On Windows OS:
%USERPROFILE%\Local Settings\Application Data\1C\1c
v8\conf (%LOCALAPPDATA%\1C\1cv8\conf for Windows
Vista and later) of the user on whose behalf the license is being
obtained.
 On Linux: ~/.1cv8/conf (~ - home directory of the user, on
whose behalf the Designer is running).
 If all users are selected, the file will be placed in the directory:
 On Windows OS:
%ALLUSERSPROFILE%\Application Data\1C\licenses
(%ALLUSERSPROFILE%\1C\licenses for Windows Vista
and later) data directory for all users of the computer.
 On Linux: This option is not supported.
%ALLUSERSPROFILE%\Application Data\1C\licenses
(%ALLUSERSPROFILE%\1C\licenses for Windows Vista and later)
and /var/1C/licenses directories are created during the application installa-
tion to the computer (in the corresponding operating system). Consider the
following features related to these directories:
• On Windows OS: write and read rights to the created directory are
given to the user on whose behalf the 1C:Enterprise server runs. If you
do not select the Install 1C:Enterprise Server as a Windows ser-
vice check box, the rights to the created directory are not assigned to
anyone and they remain in the default option.
• On Linux: during the installation, a group grp1cv8 is created, which
must include all user accounts on whose behalf the 1C:Enterprise
servers run in daemon mode. In this case, rights are assigned to the
created directory as follows:
 Directory owner: root. Access rights: read and write (rwx).
  Owner group: grp1cv8. Access rights: read and write (rwx).
 Access rights of other users: read only (r-x).

10.3.6.2. Activation guidelines

It does not make sense to activate a multi-user software license on a client
computer (in any type of the infobase).
NOTE. A client application running on Linux allows you to activate a li-
cense that is available to all users only if the activation is performed on be-
half of the root user.

10.3.7. Location of software

licenses files
A software license is a file with a .lic extension that can locate in different
locations of the file system.
TIP. You should not store one software license file at the same time in sev-
eral different directories available to 1C:Enterprise applications. This may
cause the license file to become unusable due to violation of the license
agreement.
The software license is obtained as follows:
• A list of software license files is generated for all directories where
software licenses may locate.
• For each file in the list, the required license (client or server) is ob-
tained before the license is successfully received or before the list of
software license files is prepared.

10.3.7.1. On Windows
In Windows, software license files can be located in the following directo-
ries (directories are listed in the search order):
• Directory of configuration files for a specific platform version. By de-
fault- C:\Program Files\1cv8\8.3.xx. Yyy\bin\conf.
• %USERPROFILE%\Local Settings\1C\1cv8\conf
(%LOCALAPPDATA%\1C\1cv8\conf for Windows Vista and later)
directory of the user, on behalf of which the application operates.
• The directory specified in the Conf.cfg file that is located in the
bin\conf directory of the specific version.
 • %ALLUSERSPROFILE%\Application Data\1C\1cv8\conf
(%ALLUSERSPROFILE%\1C\1cv8\conf for Windows Vista and lat-
er) data directory for all users of the computer.
• %ALLUSERSPROFILE%\Application Data\1C\licenses
(%ALLUSERSPROFILE%\1C\licenses for Windows Vista and later)
data directory for all users of the computer.
• %ALLUSERSPROFILE%\1C\licenses (%ProgramDa-
ta%\1C\licenses for Windows Vista and later) data directory for all
users of the computer.
If no license was found in any of these directories, the
%APPDATA%\1C\1cv8\ directory is used for search. If there is a loca-
tion.cfg file in this directory, the directory specified in the location parame-
ter will be used for the search.

10.3.7.2. On Linux
In Linux, software license files can be located in the following directories
(directories are listed in the search order):
• conf directory of the installed version. For the 32-bit version of
1C:Enterprise, the path to this directory will be as follows:
/opt/1c/v8.3/i386/conf, and for the 64-bit version:
/opt/1C/v8.3/x86_64/conf.
• Directory ~/.1cv8/conf (~- home directory of the user, on behalf of
which 1C:Enterprise operates).
• The directory specified in the conf.cfg file that is located in the conf
directory of the specific version.
• Directory /var/1C/licenses.
If no license was found in all of these directories, the ~/.1cv8/1C/1cv8/
directory is used for search. If there is a location.cfg file in this directory,
the directory specified in the location parameter will be used for the search.

10.3.7.3. On macOS
In macOS, software license files can be located in the following directories
(directories are listed in the search order):
• conf directory of the installed version. The path to this directory will
be as follows: /opt/1cv8/a.b.c.d/conf, where A. B. C. D - the full
version number of the 1C:Enterprise application.
• Directory ~/.1cv8/conf (~ - home directory of the user, on behalf of
which 1C:Enterprise operates).
• The directory specified in the conf.cfg file that is located in the conf
directory of the specific version.
 • Directory /var/1C/licenses.
If no license was found in all of these directories, the ~/.1cv8/1C/1cv8/
directory is used for search. If there is a location.cfg file in this directory,
the directory specified in the location parameter will be used for the search.

10.4. Determining if
1C:Enterprise can run
10.4.1. When you start the client
application
When starting 1C:Enterprise checks the possibility of running by the fol-
lowing algorithm (if at any step the necessary license is found, further
search stops):
1. On computer with the client application:
 An attempt is made to obtain a license from the same type of soft-
ware license file or HASP protection key (series, network, or lo-
cal), from which the license was obtained during the last success-
ful connection
 Search for software licenses is performed on the local computer
 Search for local HASP key is performed
 Search for multi-user HASP key available with the HASP License
Manager is performed.
 If the configuration is basic, the client application searches for the
base version license on the local computer.
2. On the cluster manager computer to which the session data service is
assigned:
 An attempt is made to obtain a license from the same type of soft-
ware license file or multi-user HASP protection key (series, net-
work, or local), from which the license was obtained during the
last successful connection
 Search for software licenses on the computer of the 1C:Enterprise
server cluster manager is performed
 Search for multi-user HASP keys installed on the computer of the
1C:Enterprise server cluster manager is performed
 Search for multi-user HASP key available with the HASP License
Manager is performed.
3. On the cluster manager computer to which the Licensing Service is
assigned:
  An attempt is made to obtain a license from the software license
file, from which the license was obtained during the last successful
connection
 Search for software licenses on the computer of the 1C:Enterprise
server cluster manager is performed
If the search for the HASP protection key is disabled
(UseHwLicenses=0) using the 1cestart.cfg configuration file, it does
not search for available licenses in the HASP protection keys located on the
client computer (both local and network) and does not attempt to obtain a
license from the saved key.

10.4.2. When you start the server

When connecting a client application with the 1C:Enterprise server, the
server license is checked (if the necessary license is found at any step, fur-
ther search stops):
• Search for a license on the working process computer that supports a
connection to the infobase is performed:
 An attempt is made to obtain a license from software license file or
HASP protection key, from which the license was obtained during
the last successful connection
 Search for a 32-bit server software license (only for a 32-bit
1C:Enterprise server) is performed
 Search for the 64-bit server software license is performed;
 Search for the 32-bit server local key (only for a 32-bit
1C:Enterprise server) is performed
 Search for the 64-bit server local key is performed
• Search for license on the cluster manager to which the Licensing Ser-
vice is assigned is performed:
 An attempt is made to obtain a license from the software license
file, from which the license was obtained during the last successful
connection
 Search for a 32-bit server software license (only for a 32-bit
1C:Enterprise server) is performed
 Search for a 64-bit server software license is performed.

10.4.3. Actions when a license is

not found
If no licenses are found during the search (described above), the following
steps are to be performed:
 • Designer, thin and thick clients run the software license acquisition
wizard.
• The web client generates an error message:
 License not found. No software protection key or electronic
license found!
 License on 1C:Enterprise server is not found. No software
protection key or electronic license found!
• If you refuse to acquire a software license, Designer, thin and thick
clients also generate the above error messages.
• If you click Details in the error window, the Key search history win-
dow opens. This window provides information about where the li-
cense search was performed, the status of the search (successful or
failed), and the reasons for the failed search. This log can make it eas-
ier to diagnose license issues.

10.5. Protection against misuse

of applications
10.5.1. General information
When purchasing a license for the main delivery of any application, the user
receives the distribution packages of the platform and of the configuration
specified in the license of the current (at the time of purchase) versions.
For later versions of this configuration, as well as for other configurations
with different names, rights are generally not granted automatically. This
means that the user must ensure the proper registration of the acquisition of
rights for the updated configurations.
The purpose of this mechanism is to inform the user in a timely manner
about the actual use of certain versions or releases of the configuration that
he/she does not have rights to, and related with these potential legal risks.
The situations when certain versions of the configuration may be used in
violation of the rules established by the copyright holder are:
1. The user does not have a license for the main delivery of this configu-
ration type.
2. The user obtained a license for the main delivery of the configuration
of this type, but later updated the configuration in violation of the
rules established by the copyright holder (for example, the user tries to
use versions/releases issued after the expiry of the ITS (information &
technology servicing) service period). For information on the condi-
 tions of servicing, visit 1C:ITS Portal
(https://portal.1c.ru/app/update).
Verification of use is performed for the applications deployed in a file mode
or client/server mode using the MINI server (more information about the
MINI is available at https://1c-
dn.com/news/1c_enterprise_8_server_mini_is_available_at_1c_dn_com_on
line_store).http://www.1c.ru/news/info.jsp?id=17577 If you operate an ap-
plication that uses a basic license, no verification is performed. The verifi-
cation uses the information about the application and the account infor-
mation created during the registration of the application and servicing
agreement on the 1C:ITC Portal (hereinafter the license client term will be
used). If the application is used incorrectly, it periodically forms a dialog
containing information on the reasons for the misuse of the application. In-
formation about the results of the check is also displayed in the About ap-
plication dialog box.
When loading the infobase from the *.dt file, verification of application is
not performed.

10.5.2. Mechanism structure

After the database configuration update is complete, the 1C:Enterprise ap-
plication submits a request to the Licensing Center (hereinafter referred to
as the LC), specifying information about the application. License client data
is used to personalize the request.
In case of successful completion of the request, the LC restores the legal
status of use of this application for the specified license client. If the LC
does not confirm the legal use of the application, the 1C:Enterprise applica-
tion starts informing all infobase users that the application is used illegally,
and the information obtained from the LC is displayed.
About dialog box contains information on the results of the request to LC:
• License usage verification was not performed. This means that the
1C:Enterprise application was not yet able to connect to LC to verify
whether the configuration is legitimate.
• License usage verification completed successfully. This means
that the 1C:Enterprise application contacted the LC to verify the legit-
imacy of use and received confirmation that the application is being
used legally.
• Unlicensed use of the configuration. Illegal use of application.
• Licensing Center unavailable. 1C:Enterprise application cannot ac-
cess the LC.
License client data (used to contact LC) must be included in the infobase of
the application used. You can set the settings from the Designer by using
the Main menu-Administration- Set the licensing client settings com-
mand. When accessing the LC, in the 1C:Enterprise mode, a similar dialog
box will be displayed in case the license client data is not defined for the
infobase by the time of the request.
The application developer can implement its native licensing client data
installation mechanism (using the SetSettingsofLicenseClient()
method), for example, by getting them during the initial application setting.
At the same time, the developer can implement a response of the platform to
the license client data request and provide the user with a more convenient
dialog box for entering the license client settings (using the
ConnectHandlerofRequestforLicenseClientSettings (),
in which the dialog box opens).
Chapter 11.
Application updates

11.1. Update
If setup.exe is started from the distribution package directory of the ver-
sion that is already installed on the user's computer, the installed version
will be automatically updated according to the settings specified by
Installcomponents parameter of the configuration files.
Starting setup.exe from a distribution package directory that is not in-
stalled on your computer will install this version, and will not update any of
the previously installed versions.

11.2. 1C:Enterprise application

update by Microsoft
Windows users without
administrator rights
To allow Microsoft Windows users who do not have OS administrative
rights to perform a 1C:Enterprise installation from a shared directory, set
the AlwaysInstallElevated policy for the computer and user. You can set
the policy either locally, in the Group Policy Control Panel (by starting
gpedit.msc), or through Active Directory Policy Management.
The above steps can be taken not for specific users, but for the Authenti-
cated users group.
Chapter 12.
Uninstalling

12.1. Deleting infobases

1C:Enterprise uninstall tool does not automatically delete directories con-
taining infobases on the hard drive. You should delete these directories
manually.
If there are links in the list of infobases for the directories with infobases to
be deleted, you should delete both the rows from the list of infobases and
the directories themselves.

12.2. Uninstalling the platform

12.2.1. On Windows
Uninstalling 1C:Enterprise is performed by a special program that deletes
system components from the computer's hard drive, makes changes to the
Start menu and system information of Microsoft Windows.
Before uninstalling, complete all 1C:Enterprise operations (including shut-
down of the 1C:Enterprise server).
To uninstall 1C:Enterprise, follow these steps:
• Open Windows control panel and click the Add or Remove Pro-
grams (Programs and features for Windows Vista and later) icon.
• If necessary, click the Replace or delete icon in the dialog box that is
displayed.
• In the list of installed programs, select 1C:Enterprise 8 (8.3.3.100)
and click Remove.
You will be asked if you want to perform the uninstallation. If you confirm,
Windows will start uninstalling the selected 1C:Enterprise version from the
computer and making the necessary changes to the system information.

12.2.2. For macOS

To delete the required version of the platform, it is necessary to execute the
Delete 1C:Enterprise command located in the menu with the required ver-
sion number in the 1C Enterprise 8 -Program menu.
The uninstallation must be made on behalf of the user which has administra-
tive privileges.
Chapter 13.
Mobile platform
administration

13.1. Starting and using the list

of applications for iOS
13.1.1. Starting mobile
application
To start a mobile application, find the application in the list and click on its
image. In most cases, the main window of the mobile application opens.
However, if more than one application is associated with this program, a list
of these applications will open. In this case, to start the application, click on
an application in the list.

13.1.2. Using the list of

applications
Most of the steps listed below are performed from the application list. To
get there, select Application list from the application menu. The application
list is also available immediately when the mobile application is started, if
more than one application is registered.

13.1.2.1. Creating an application

In order to create an application for a mobile platform:
• Select the Add Application command
• Specify the name of the application and click Finish
• After the window closes, the application will be created.

13.1.2.2. Starting the application

When starting the mobile application, in most cases, the application main
window opens. However, if more than one application is associated with
this program, a list of these applications will open. In this case, to start the
application, click on an application in the list.
13.1.2.3. Modifying application properties
Application properties are modified in a special window. To open the Ap-
plication Properties window, click > button to the right of the name of the
application.
In the window that opens, you can change the name of the application, start
it (Open button) or uninstall it (Delete button).
IMPORTANT! After the application is uninstalled, the infobase cannot be
recovered.

13.1.2.4. Uninstalling the application

To uninstall an application, click Edit, then click the picture to the left of the
name of the application. After that, click Delete button to the right.
IMPORTANT! After the application is uninstalled, the infobase cannot be
recovered.

13.1.2.5. Updating application

The mobile application is updated through the App Store. After you suc-
cessfully update the mobile application, you need to update your previously
created applications. Just start the application.
If the update process detects that the database requires restructuring, you
will be asked to confirm this operation. If you decline, the update will be
deferred until the next application start.
It also makes sense to discard the update to make a backup copy of the da-
tabase.

13.2. Starting and using the list

of applications for Android
OS
13.2.1. Starting mobile
application
To start a mobile application, find the application in the list and click on its
image. In most cases, the main window of the mobile application opens.
However, if more than one application is associated with this program, a list
of these applications will open. In this case, to start the application, click on
an application in the list.
13.2.2. Using the list of
applications
Most of the steps listed below are performed from the application list. To
get there, select Application list from the application menu. The application
list is also available immediately when the mobile application is started, if
more than one application is registered.

13.2.2.1. Creating an application

In order to create an application for a mobile platform:
• Select the Add Application command
• Specify the name of the application and click Finish
• After the window closes, the application will be created.

13.2.2.2. Starting the application

When starting the mobile application, in most cases, the application main
window opens. However, if more than one application is associated with
this program, a list of these applications will open. In this case, to start the
application, click on an application in the list.

13.2.2.3. Modifying application properties

Application properties are modified in a special window. To open the Ap-
plication Properties window, long press an application icon. In the context
menu that appears, click Edit.
In the window that opens, you can change the name of the application, start
it (Open button) or uninstall it (Delete button).
IMPORTANT! After the application is uninstalled, the infobase cannot be
recovered.

13.2.2.4. Uninstalling the application

To uninstall an application, follow these steps:
• Long press on the application to be deleted.
• In the context menu that appears, select Delete.
• To confirm the uninstallation, select Yes.
IMPORTANT! After the application is uninstalled, the infobase cannot be
recovered.
13.2.2.5. Updating application
The mobile application is updated through the App Store. After you suc-
cessfully update the mobile application, you need to update your previously
created applications. Just start the application.
If the update process detects that the database requires restructuring, you
will be asked to confirm this operation. If you decline, the update will be
deferred until the next application start.
It also makes sense to discard the update to make a backup copy of the da-
tabase.

13.3. Preparing the

infrastructure to perform
the exchange
If the mobile application is part of a distributed information application,
then typically the interaction within that infrastructure is done through Web
services. A specific OS may have its own requirements for the organization
of interaction (this is determined at the stage of application development).
In any case, refer to the application documentation for information on which
mechanisms are used to organize interaction.
Accordingly, the task of the administrator is to organize communication
channels and create a software and hardware environment that meets the
requirements of the application.

13.4. Backup
Data backup is performed depending on the mobile application.
If you use a mobile application that is not associated with the remote sys-
tem, you can use the standard tools of your mobile device operating system
for backup. Keep in mind the following features of the behavior of the sys-
tem running iOS: immediately after the infobase created from the template,
it is excluded from the backup process. After the infobase is written using
extensions of object and register forms, the infobase is included in the
backup process.
If the application synchronizes data with a remote system, perform a data
synchronization session. The need to use the built-in backup tools after the
synchronization is performed depends on the presence of data in the mobile
application that are not synchronized with the remote system. If there is no
such data, in case of issues, the application can be recreated, and the initial
data initialization can be performed from the remote system.
You can configure backup to a mobile device.
Appendix 1.
Structure of the
installation directory
and assigning
directories and files

After installation, a directory structure will be organized on the drive, where

application executable and configuration files are located. This section de-
scribes the directory structure and the purpose of some executable and con-
figuration files.

1.1. On Windows
By default, the application will be installed in the
%PROGRAMFILES%\1cv8 directory (we will refer to this directory as the
root installation directory). If you are installing the 32-bit version of the
1C:Enterprise application on a 64-bit version of Windows, the root installa-
tion directory will have the name %PROGRAMFILES(x86)%\1cv8.
The other directories and configuration files are created in the root installa-
tion directory:
• common - this directory contains the common files of 1C:Enterprise.
These include the 1cestart launcher, the security key driver installer,
the Management Console snap-in to administer the 1C:Enterprise
server cluster (1CV8 Servers.msc), the 1C:Enterprise files icon li-
brary for the needs of the operating system.
• conf - this directory contains the configuration files necessary for the
operation of 1C:Enterprise.
• srvinfo - the working directory of the main server. Contains server
cluster data if the 1C:Enterprise server is installed as a Windows ser-
vice.
• A.B.C.D - this directory contains files of a specific 1C:Enterprise ver-
sion. Hereinafter this directory will be called the version directory. In
this name, A.B.C.D - is the full number of the particular version in-
stalled. Installer allows to install simultaneously several versions of
the 1C:Enterprise applications. In this case, multiple version directo-
ries will be located in the root installation directory. So, in case of in-
 stallation of versions 8.3.3.100 and 8.3.3.150 (version numbers - con-
ditional) there will be two directories with names 8.3.3.100 and
8.3.3.150. Each version directory contains all the files (except the
1cestart file) specific to this version, namely: executable files, ac-
companying files, software products licenses, etc. The version directo-
ry structure:
 bin - contains the executable files of the version (directory of exe-
cutable files).
 bin\conf - contains the configuration files of a specific version or
the conf. cfg file, which contains the path to the shared directory
of configuration files (by default, the conf directory of the root in-
stallation directory).
 bin\dmf - contains the files necessary for the functioning of the
optimized database configuration update mechanism.
 docs - this directory contains the accompanying files in the Rus-
sian and English languages. The components of files may vary
from version to version.
 licenses- contains the license agreement for 1C:Enterprise in Rus-
sian (1CEnterpise_ru.htm file) and English
(1CEnterpise_en.htm file), as well as license agreements for
third-party software components used (this list may vary from ver-
sion to version).
 readme - this directory contains readme files in the localization
languages of the platform.
Some directories in the installation are always in a fixed place of the file
system, regardless of which directory is selected during the application in-
stallation:
• If you use a version that matches the operating system bitness, the
common and conf directories are located in the
%PROGRAMFILES%\1cv8 directory.
• When using the 32-bit version of the application on the 64-bit OS, the
common and conf directories are located in the
%PROGRAMFILES(x86)%\1cv8 directory.
• srvinfo directory (in addition to the common and conf directories)
will be located:
 If the bitness of 1C:Enterprise and operating system match- in
the%PROGRAMFILES%\1cv8 directory.
 When using the 32-bit version of the application on the 64-bit OS-
in the %PROGRAMFILES(x86)%\1cv8 directory.
1.2. On Linux
The application will be installed in the root installation directory. Depend-
ing on the bitness of the operating system used, this directory is located:
• In the 32-bit version of Linux: /opt/1C/v8.3/i386
• In the 64-bit version of Linux: /opt/1C/v8.3/i386
The other directories and configuration files are created in this directory:
• conf - this directory contains the configuration files necessary for the
operation of 1C:Enterprise.
• docs - this directory contains the accompanying files in the Russian
and English languages. The components of files may vary from ver-
sion to version.
• dmf - contains the files necessary for the functioning of the optimized
database configuration update mechanism.
• licenses- contains the license agreement for 1C:Enterprise in Russian
(1CEnterpise_ru.htm file) and English (1CEnterpise_en.htm file),
as well as license agreements for third-party software components
used (this list may vary from version to version).
• readme - this directory contains readme files in the localization lan-
guages of the platform.
• ExtDst - contains additional utilities designed for use in conjunction
with the 1C:Enterprise application.

1.3. On macOS
The system will be installed in the /opt/1cv8 directory (hereinafter we will
call this directory as the root installation directory). The other directories
and configuration files are created in the root installation directory:
• common - this directory contains the common files of 1C:Enterprise.
These include the security key driver installer and the 1cescmn.cfg
configuration file.
• conf - this directory contains the configuration files necessary for the
operation of 1C:Enterprise.
• A.B.C.D - this directory contains files of a specific 1C:Enterprise ver-
sion. Hereinafter this directory will be called the version directory. In
this name, A.B.C.D - is the full number of the particular version in-
stalled. Installer allows to install simultaneously several versions of
the 1C:Enterprise applications. In this case, multiple version directo-
ries will be located in the root installation directory. So, in case of in-
stallation of versions 8.3.3.100 and 8.3.3.150 (version numbers - con-
ditional) there will be two directories with names 8.3.3.100 and
8.3.3.150. Each version directory contains all the files (except the
 1cestart file) specific to this version, namely: executable files, ac-
companying files, software products licenses, etc. The version directo-
ry structure:
 conf - this directory contains the configuration files necessary for
the operation of 1C:Enterprise.
 docs - this directory contains the accompanying files in the Rus-
sian and English languages. The components of files may vary
from version to version.
 licenses- contains the license agreement for 1C:Enterprise in Rus-
sian (1CEnterpise_ru.htm file) and English
(1CEnterpise_en.htm file), as well as license agreements for
third-party software components used (this list may vary from ver-
sion to version).
 readme - this directory contains readme files in the localization
languages of the platform.

1.4. Directories and files

functions
This section describes some of the directories and files that are part of the
1C:Enterprise application.
1cestart
1C:Enterprise application launcher.
Using the launcher, you can start all types of clients (thick client, thin client,
Web client), Designer.
TIP. If the launcher is located in a network directory, it is recommended
that you use this program from the latest version, which you plan to install
from that network directory.
File location:
• On Windows OS: in the common directory of the root installation di-
rectory.
• On Linux: in the root installation directory.
• On macOS: in the directory with executable files of the specific ver-
sion.
1cv8s
Interactive launcher of the specific version of 1C:Enterprise application.
The launcher can start all types of clients (thick client, thin client, Web cli-
ent), Designer.
File location:
 • On Windows OS: in the directory with executable files of the specific
version.
• On Linux: in the root installation directory.
• On macOS: in the directory with executable files of the specific ver-
sion.
1cv8
Executable file of thick client or Designer.
Cannot start thin client or web client.
File location:
• On Windows OS: in the directory with executable files of the specific
version.
• On Linux: in the root installation directory.
• On macOS: in the directory with executable files of the specific ver-
sion.
1cv8c
Executable file of thin client.
File location:
• On Windows OS: in the directory with executable files of the specific
version.
• On Linux: in the root installation directory.
• On macOS: in the directory with executable files of the specific ver-
sion.
1cv8a
Administrative console utility.
File location:
• On Windows OS: in the directory with executable files of the specific
version.
• On Linux: in the root installation directory.
• On macOS: in the directory with executable files of the specific ver-
sion.
ragent, rmngr, rphost
Executable files of 1C:Enterprise server 1C:Enterprise server structure.
File location:
• On Windows OS: in the directory with executable files of the specific
version.
• On Linux: in the root installation directory.
• On macOS: none.
dbgs
1C:Enterprise debug server Application debugging.
File location:
• On Windows OS: in the directory with executable files of the specific
version.
• On Linux: in the root installation directory.
• On macOS: in the directory with executable files of the specific ver-
sion.
dbda
Data accelerator. Works only as part of the 1-bit: 1C:Enterprise server clus-
ter. Designed to speed up the execution of complex analytical reports.
File location:
• On Windows OS: in the directory with executable files of the specific
version.
• On Linux: in the root installation directory.
• On macOS: none.
webinst
Web Client Publishing Configuration Utility on Web server.
File location:
• On Windows OS: in the directory with executable files of the specific
version.
• On Linux: in the root installation directory.
• On macOS: none.
<Version number>\bin\conf except Linux
Configuration files of the specific 1C:Enterprise application version.
\conf Linux
1C:Enterprise configuration files.
chdbfl
The file mode database testing utility.
File location:
• On Windows OS: in the directory with executable files of the specific
version.
• On Linux: in the root installation directory.
• On macOS: none.
chvbfl
File mode database conversion utility.
File location:
• On Windows OS: in the directory with executable files of the specific
version.
• On Linux: in the root installation directory.
 • On macOS: in the directory with executable files of the specific ver-
sion.
v7cnv.exe Windows
Converter of infobases from 1C:Enterprise 7.7 to the current version.
File location:
• On Windows OS: in the directory with executable files of the specific
version.
• On Linux: none.
• On macOS: none.
RegMSC.cmd Windows
Command file for registration of the administration utility for 1C:Enterprise
server cluster of a specific version (located in the directory of executable
files of a specific version).
File location:
• On Windows OS: in the directory with executable files of the specific
version.
• On Linux: none.
• On macOS: none.
1ceunt.dll Windows
Library of icons used by OS to display 1C:Enterprise file types. This library
is common to all versions of the application. Registration of this library
(and associating icons with file types) is performed on the first installation
of 1C:Enterprise on the computer. Canceling the library registration (and
removing icons association with file types) is performed when the latest
version of 1C:Enterprise is removed from the computer.
File location:
• On Windows OS: in the common directory of the root installation di-
rectory.
• On Linux: none.
• On macOS: none.
ci
Integrity monitoring utility.
File location:
• On Windows OS: in the directory with executable files of the specific
version.
• On Linux: in the root installation directory.
• On macOS: in the directory with executable files of the specific ver-
sion.
crserver
Configuration repository server.
File location:
• On Windows OS: in the directory with executable files of the specific
version.
• On Linux: in the root installation directory.
• On macOS: none.
dumper Windows
Utility to generate crash dumps. This utility is used when specifying the
externaldump="true" attribute in the logcfg.xml file.
File location:
• On Windows OS: in the directory with executable files of the specific
version.
• On Linux: none.
• On macOS: none.

1.5. Configuration files:

location and search
1.5.1. General information
Configuration files used for 1C:Enterprise (logcfg.xml, nethasp.ini, and so
on) can be stored at different locations in the file system.

1.5.2. On Windows
In Windows, files can be stored in the following locations (in the search
order):
• bin\conf directory of a specific version. For example, the path for the
8.3.3.100 version will look as follows: C:\Program
Files\1cv8\8.3.3.100\bin\conf.
• %USERPROFILE%\Local Settings\Application Data\1C\1cv8\con
f (%LOCALAPPDATA%\1C\1cv8\conf for Windows Vista and later)
directory of the user on whose behalf the application runs.
• The directory specified in the Conf.cfg file that is located in the
bin\conf directory of the specific version.
• %ALLUSERSPROFILE%\Application Data\1C\1cv8\conf
(%ALLUSERSPROFILE%\1C\1cv8\conf for Windows Vista and lat-
er) data directory for all users of the computer.
NOTE. When the application is being installed, the configuration files are
written to the C:\Program Files\1cv8\conf directory, and this path is writ-
ten to the bin\conf\conf.cfg file of the installed version.
This search order of configuration files allows to:
• Generate unified configuration files for all versions and components
installed on the computer. To do this, the configuration files should be
located only in the C:\Program Files\1cv8\conf directory.
• Generate configuration files separately for each version installed on
the computer. To do this, the configuration files should be located on-
ly in the bin\conf directory.
• Generate different configuration files for different components (for the
1C:Enterprise client application and server, operating under another
user of the system) of any version running on the computer. For this
purpose the configuration files should be located only in
the%USERPROFILE%\Local Settings\Application Data\1C\1cv8\c
onf (%LOCALAPPDATA%\1C\1cv8\conf for Windows Vista and
later) directories of the appropriate users.
• Use combinations of these methods for different configuration files.

1.5.3. On Linux
On Linux, files can be located in the following places (in the search order):
• conf directory of the version installed. For example, for the 32-bit
version of 1C:Enterprise, the path to this directory will be as follows:
/opt/1c/v8.3/i386/conf, and for the 64-bit version:
/opt/1C/v8.3/x86_64/conf.
• Directory ~/.1cv8/1C/1cv8/conf (~ - home directory of the user, on
behalf of which the 1C:Enterprise server operates).
• The directory specified in the conf.cfg file that is located in the conf
directory of the specific version.

1.5.4. On macOS
On macOS, files can be located in the following places (in the search order):
• conf directory of the installed version, for example:
/opt/1cv8/A.B.C.D/conf, where A.B.C.D - the full version number of
the 1C:Enterprise application.
• conf directory of the root installation directory: /opt/1cv8/conf.
• Directory ~/.1cv8/1C/1cv8/conf (~ - home directory of the user, on
behalf of which the 1C:Enterprise client application operates).
• The directory specified in the conf.cfg file that is located in the conf
directory of the specific version.
Appendix 2.
Description of the event
log items

This appendix describes the structure of the event log when it is exported in
XML format.
XML document format after event log export:
• Namespace: http://v8.1c.ru/eventLog
• Namespace prefix (default): v8e.

EventLog
The root element of the document. Contains the events of the log (Event
elements).
Event
Contains elements that describe the log event.
Level
Type: Event level enumeration. Event level value.
Date
Type: DateTime. Event date and time value.
Application
Type: String. Name of the application in which the event occurred.
ApplicationPresentation
Type: String. Presentation of the application in which the event occurred.
EventName
Type: String. Name of the event.
EventPresentation
Type: String. Presentation of the event.
UserID
Type: UUID. ID of the user who initiated the event.
UserName
Type: String. Name of the user who initiated the event.
MetadataName
Type: String. Compound name in the English version of the term and
with the metadata names. For events that include a list of metadata (data
access events), it contains a list of Item items, each of which contains the
name of the metadata object.
MetadataPresentation
Type: String. Representation of the metadata object in the language of
user (synonyms). For events that include a list of metadata (data access
events), it contains a list of Item items, each of which contains the presen-
tation of the metadata object.
Comment
Type: String. Comment to the event.
Data
Type: Any. Event data. If the data type cannot be represented as XML, the
Undefined value is written (a blank item with the xsi:nil = "true" attribute).
It may contain structures, arrays, and tables (for data access events, authen-
tication and operation with infobase users).
DataPresentation
Type: String. Presentation of the event data.
TransactionStatus
Type: Transaction status for the event. The transaction status can take the
following values:
• InProgress - transaction not finished;
• Committed - transaction not finished;
• RolledBack - transaction cancelled;
• NotApplicable - record is performed outside the transaction.
TransactionID
Type: String. Transaction ID.
Connection
Type: Number. Connection number.
Session
Type: Number. Session number.
ServerName
Type: String. Working server name.
Port
Type: Number. Main IP port.
SyncPort
Type: Number. Auxiliary IP port.
SessionDataSeparation
Contains a collection of elements that describe the separators used in the
session during the event logging. The element name corresponds to the sep-
arator name, the element value contains the separator value.
SessionDataSeparationPresentation
Contains a collection of Item elements with values of the String type,
which contain the separator presentations in the same order as in the
SessionDataSeparation item.
 Appendix 3.
Description and
location of internal files

This appendix contains a description and location of internal files that can
be used when operating 1C:Enterprise.

3.1. *.1ccr
The Web service configuration file for Remote Repository can have an arbi-
trary name (1ccr extension required), an XML format, and contains a single
node with a random name and connectString attribute - this attribute
specifies the repository server address in the TCP diagram.
For example, such a configuration file may have the name repository.1ccr
and the following content:
<?xml version="1.0" encoding="UTF-8"?>
<repository connectString="tcp://RepServ"/>

In this case, therepository name is selected as the arbitrary node name

and the address of the repository server configuration - tcp://RepServ.

3.2. *.mft
The file with the mft extension is a manifest file - a special file that de-
scribes the configuration template. The file may have an arbitrary name.
The file is located in the directory of the installed configuration template.
The manifest file has an arbitrary name and mft extension. The internal
format of the manifest file is close to the .ini file format. The manifest file
uses UTF-8 encoding to support multiple languages. The following parame-
ters are specified at the beginning of the manifest file.
Vendor
Solution provider. Matches the one specified in the configuration.
Name
Name of the solution. Matches the one specified in the configuration.
Version
Version of the solution. Matches the one specified in the configuration.
 AppVersion
1C:Enterprise version used to build the distribution package.
The following parameters refer to parts of the solution and are separated by
sections names. Sections names are arbitrary and enclosed in square brack-
ets.
Source
The relative path to the configuration file (cf), the update file (cfu), or the
database dump file (dt).
Catalog_<language suffix>
The name of the solution in the solution catalog. There may be several
Catalog_<language suffix> parameters in the manifest file. The
suffix defines the user interface language in 1C:Enterprise 8 (for example,
ru to specify the Russian language). If the language suffix is not specified
(the parameter name is set to Catalog), the value of this parameter is used
for all user interfaces except those, for which the Catalog parameter with
the desired language suffix is specified in this section.
Destination
Recommended directory for infobase creation. This parameter is used when
creating an infobase from a template. The directory represents a partial path.
As one of its parts the directory must include a vendor directory (to avoid a
coincidence of directories names for different solutions).
Multiple cfu files are allowed in the configuration template directory.
Vendor=1C Company
Name=Trade Management
Version=8.10.0.2
[Main]
Source=Main\1cv8.cf
Catalog_en=Trade management/Trade management
Destination=1C\Trade
[Demo]
Source=Demo\1cv8.dt
Catalog_en=Trade management/Trade management (Demo)
Destination=1C\DemoTrd

3.3. *.v8i
This appendix describes the registered infobases description file format.
This list is used by all clients. By default, the file name is ibases.v8i.
File location:
• On Windows: %APPDATA%\1C\1CEStart\ on the local computer.
• On Linux: ~\.1C\1cestart.
• On macOS: ~\.1C\1cestart.
 The file is a text document encoded in UTF-8 and consists of sections. Each
section describes one infobase.
Each section describes one infobase.
Infobase description section:
[Section name]
Connect=
ID=
OrderInList=
Folder=
OrderInTree=
External=
ClientConnectionSpeed=
App=
AppArch=
DefaultApp=
WA=
WSA=
Version=
DefaultVersion=
AdditionalParameters=
WebCommonInfoBaseURL=
HttpsCA=
HttpsCert=
HttpsCAFile=
HttpsCertFile=
HttpsCertSelect=
ShowInList=
MobilePublicKey=
WebCommonInfoBases=
DisplayAuthDialog
DisableUseBiometrics
UseBiometrics=
DisableRememberMe
RememberMe=

A section consists of a section name and parameters.

The name and each section parameter are written to a separate line in the
description file.
Section name
The name of the section coincides with the name of the infobase and is a
mandatory parameter. The name is enclosed in square brackets.
The parameter can be edited in the infobase properties window.
Example:
[Демонстрационнаяверсия8.2]

ID
Infobase internal ID. Generates automatically. Must be unique within a sin-
gle v8i file.
 Manually generating the ID is not advised.
Example:
ID=cf9f0d4b-b4a3-11d8-861e-0050baaa2f3f

Connect optional
Infobase connection string. There may be several descriptions of infobases
that have the same start string (but different name). This may be necessary
when you need to start a single infobase in multiple startup modes (such as
thin and thick clients) without changing the properties of the infobase.
Example:
File mode is specified as:
Connect=File=<Path>;

Client/server mode is specified as:

Connect=Srvr=<1CEnterpriseServerName>;Ref=<InfobaseNameOnServer>;

Web server connection is specified as:

Connect=ws="http://web-server/resource/";

Folder optional
Folder name in the infobases tree.
NOTE. If the folder name is not specified or the parameter is omitted, this
infobase is located in the root of the list of infobases.

Example:
Folder=/CommercialInfobases

OrderInList
The order in the list when presented in the list view. Specified as a number,
which is the sequence count of the infobase in the infobase list (sorting by
name is not set).
Example:
OrderInList=5

OrderInTree
The order in the branch when presented in the tree view.
Example:
OrderInTree=16358

UseProxy optional
Indicates the use of a proxy server for the ws-connection option.
 • 0 - proxy server is not used;
• 1 - automatic detection of proxy server settings;
• 2 - explicitly specify proxy server settings.
If the UseProxy parameter is not specified, the proxy server settings are
automatically defined. For file and client/server modes, it is meaningless.
Example:
UseProxy=1

PSrv
String containing the proxy address (required only if the UseProxy pa-
rameter is set to 2).
Example:
PSrv=192.168.0.1

PPort
Port number of the proxy server (required only if the UseProxy parameter
is set to 2).
Example:
PPort=123

PUser optional
Proxy server username.
Example:
PUser=userName

PPasswd optional
Encrypted password for the proxy server.
Example:
PPasswd=XNKxbVEqnXUCwwk1Urovbo7bZFpG/Zpf6cQ10qVtzpk=

ClientConnectionSpeed
Client connection speed (only makes sense for thin and web clients). Can
take values:
• Normal- standard connection speed
• Low - low connection speed
If the parameter is not specified, the client connection speed will be deter-
mined by the Low connection speed check box value of the startup win-
dow (which is equivalent to Select when starting value of the Connection
 speed parameter of the window, which contains the infobase startup pa-
rameters).
Example:
ClientConnectionSpeed=Low

WA
Specifies user authentication mode. Can take values:
• 1 - try to authenticate by means of OS. If unsuccessful, the log-
in/password is requested.
• 0 - always use login/password authentication.
Example:
WA=1

WSA
Determines a user authentication mode on a web server if the web server is
used as an intermediate link (a thin client that is connected through a web
server and a web client). Can take values:
• 1 - try to authenticate on the web server by means of OS. If unsuc-
cessful, the login/password is requested.
• 0 - always request login/password.
Example:
WSA=1

App
Specifies the type of client application:
• Auto - client application type selected automatically
• ThinClient - thin client
• ThickClient - thick client
• WebClient - web client
The parameter can be edited in the infobase properties window.
Example:
App=Auto

DefaultApp
The type of client that is defined and placed in this file by the launcher
when the client application type is automatically determined
(/AppAutoCheckMode key):
• ThinClient - thin client
• ThickClient - thick client
 If the value of the App parameter equals Auto and the DefaultApp pa-
rameter is not specified, the thin client starts with the/AppAutoCheckMode
command-line parameter.
If the DefaultApp parameter is set, the client specified in it starts with
the /AppAutoCheckMode parameter.
Example:
DefaultApp=ThinClient

Version
1C:Enterprise version, which should be used to start the infobase.
The parameter can be edited in the infobase properties window.
Example:
Version=8.3.3

DefaultVersion
1C:Enterprise version, which was actually used to for the previous start of
the infobase. Automatically detected and placed in this file by the launcher
if the start is performed with /AppAutoCheckVersion parameter.
During the next startups, this version will be used, not the one specified in
the Version parameter.
Example:
DefaultVersion=8.3.3.100

AdditionalParameters
Contains additional startup options that can be entered in the infobase prop-
erties window in the Advanced startup options item.
Example:
AdditionalParameters=/DisplayAllFunctions /LogUI

WebCommonInfoBaseURL
If the infobase is added to the current list using the Internet service for ob-
taining a list of shared infobases, this parameter will contain the address of
the service, which provided the information about the infobase.
If during the interactive start of the launcher (1cv8s) it is detected that the
list of the shared infobases, received by the Internet service, does not re-
quire an update, then the descriptions of all infobases (web service call
WebCommonInfoBases.CheckInfoBases() returned the
InfoBaseChanged parameter equal to False), which are retrieved
from this source, remain in the list until the next start.
 If InternetService or WebCommonInfoBases parameters are re-
moved from the 1cestart.cfg file, information about infobases, received
from remote sources, will be removed from the infobases list.
Example:
WebCommonInfoBaseURL=http://info-server/listservice

HttpsCA optional
Type of the certificate source from the certification authorities used to vali-
date the server certificate. Can take values:
• None - certification authorities certificates are used, the server certifi-
cate validation is not performed.
• File - certification authorities certificates are located in the file.
• Windows - certification authorities certificates are located in the
Windows Certificate store.
• Linux - certification authorities certificates are located in the Linux
certificates directory.
• macOS - certification authorities certificates are located in the macOS
Certificate store.
HttpsCert optional
Type of client certificate source and its private key. Can take values:
• None - the client certificate is not used;
• File - the client certificate is in the file;
• Windows - the client certificate is in the Windows Certificate store;
• Linux - the client certificate is in the Linux certificates directory.
• macOS - the client certificate is in the macOS Certificate store.
HttpsCAFile optional
The path to the file that contains the certification authorities certificates. If
the HttpsCA parameter is set to File, and this parameter is missing or
equal to an blank string, then the HttpsCA parameter is considered to be
set to None.
HttpsCertFile optional
The path to the file that contains the client certificate and its private key. If
the HttpsCert parameter is set to File, and this parameter is missing or
equal to an blank string, then the HttpsCert parameter is considered to
be set to None.
 HttpsCertSelect optional
How to select a Windows client certificate if more than one certificate is
installed and these certificates are suitable for this connection. Can take
values:
• Recent - use the selected one if there is a remembered one- used it,
if there is no a remembered one - picker dialog box opens and the se-
lected certificate is memorized for later use;
• Choose - always select a certificate. The selected certificate is re-
membered and can be used later if this parameter is set to Recent
value;
• Auto - automatically select the appropriate certificate for this connec-
tion. The picker dialog box does not open.
AppArch optional
Specifies the bitness of the client application that will be used to operate
with this infobase. The bitness value is the same as the /AppArch command
parameters of the client application starting command-line string.
ShowInList mobile client only
Use this parameter to specify that the infobase will be in the main list of
infobases on the mobile device. The parameter can take values:
• 1 - infobase is located in the main list of mobile device bases.
• 0 - infobase is not located in the main list of mobile device bases. To
access this database, use a special menu.
The default value is 0.
Example:
ShowInList=1

MobilePublicKey mobile client only

The MD5 hash (Base64 format) of the public key that is used to verify the
signature of the configuration that the mobile client tries to use. The hash
value (in the required format) is available in the Mobile Client Signature
Designer dialog box.
Example:
MobilePublicKey=322B116E58FA1B7EC6961A8FE53389EE

InternetService mobile client only

This parameter contains the Internet service address of the shared infobases
list. The infobase from the list will be in the list of mobile client (on mobile
device) in case if for configuration from the shared infobases list the value
of MobilePublicKey parameter coincides with the value of this parame-
 ter for any configuration specified during the assembly stage of the mobile
application.
This parameter for a mobile client is similar to the InternetService
parameter of the 1cestart.cfg file.
In the case of a mobile client, this parameter can be nested, that is, the list of
shared infobases, which returns the Internet service, may contain a reference
to another Internet service.
Example:
InternetService=http:\\server\addr

DisplayAuthDialog mobile client only

This parameter defines, whether a user authentication dialog box has to be
displayed, or not.
DisableUseBiometrics mobile client only
This parameter disables Use Biometrics check box in the mobile client user
authentication dialog box.
UseBiometrics mobile client only
This parameter manages Use Biometrics check box set by default in the
mobile client user authentication dialog box. If
DisableUseBiometrics is available in the infobase details, this pa-
rameter has no sense. The parameter can take values:
• 1 - Use Biometrics check box is checked.
• 0 - Use Biometrics check box is cleared.
The default value is 1.
DisableRememberMe mobile client only
This parameter disables RememberMe check box in the mobile client user
authentication dialog box.
RememberMe mobile client only
This parameter manages RememberMe check box set by default in the
mobile client user authentication dialog box. If DisableRememberMe is
available in the infobase details, this parameter has no sense. The parameter
can take values:
• 1 - RememberMe check box is checked.
• 0 - RememberMe check box is cleared.
The default value is 1.
 3.4. 1cescmn.cfg
The 1cescmn.cfg file contains the general settings of the launchers
(1cestart and 1cv8s).
The file is located in the directory from where the application is being in-
stalled in the case if the distribution packages are located in the network
directory.
NOTE. Applies only to the 1C:Enterprise application under Windows OS.
The file is a text document encoded in UTF-8 or UTF-16LE and contains
the strings of <Parameter>=<Value> format.
The file description is equivalent to the description of the1cestart.cfg file,
except that the shared configuration file cannot contain a string with the
CommonCfgLocation parameter.
Example:
CommonInfoBases=ibcommon.v8i
DistributiveLocation=\\server\v8dst

This example sets the name of a file with shared infobases list (Ibcom-
mon.v8i), which should be in the same directory as the file with the interac-
tive launcher (1cestart). The directory of distribution packages of applica-
tion versions is also specified: \\server\v8dst.

3.5. 1cestart.cfg
The 1cestart.cfg file contains settings that launchers use (1cestart and
1cv8s), client applications (1cv8 and 1cv8c), and external connections.
File location:
• On Windows OS: .
 %APPDATA%\1C\1CEStart - for a specific user. The file changes
when configuring the startup window.
 %ALLUSERSPROFILE%\Application Data\1C\1CEStart
(%ALLUSERSPROFILE%\1C\1CEStart for Windows Vista and
later) - for all users of the computer. The file changes only during
the installation of the 1C:Enterprise application.
• On Linux: ~/.1C/1cestart.
• On macOS: ~/.1C/1cestart.
The file is a text document encoded in UTF-16LE and contains the strings
of <Parameter>=<Value> format. The descriptions of the parameters
that can be contained in this file are described below.
Example:
DefaultVersion=8.2-8.2.16
DefaultVersion=8.3-8.3.3
CommonCfgLocation=\\Server\v8\1cescmn.cfg
CommonInfoBases=\\Server\common\common_dblist.v8i
InstalledLocation=C:\Program Files\1cv8
DistributiveLocation=\\server\dst1C\v8
ConfigurationTemplatesLocation=\\server\tmplts
ConfigurationTemplatesLocation=C:\Documents and
Settings\User\Application Data\1C\1cv8\tmplts
InstallComponents=DESIGNERALLCLIENTS=1 THINCLIENT=1 WEBSERVEREXT=1
SERVER=1 CONFREPOSSERVER=0 CONVERTER77=1 SERVERCLIENT=1
LANGUAGES=RU
UseHwLicenses=0
AppAutoInstallLastVersion=0

DefaultVersion
This parameter specifies the default version. Multiple lines with this param-
eter are allowed.
The bitness of the client application to be started can specified in this pa-
rameter. The ";" character is used to separate the version and the bitness of
the client application. The bitness value is the same as the /AppArch com-
mand parameters of the client application starting command-line string.
Values from all configuration files are used.
Example 1:
DefaultVersion=8.3-8.3.3.100

This line means that the 8.3.3.100 version will be used when attempting to
start the infobase with the version 8.3.
Example 2:
DefaultVersion=8.2.15-8.2.15.315

This line means that the 8.2.15.315 version will be used when attempting to
start the infobase with the version 8.2.15.
Example 3:
DefaultVersion=8.3;x86_64_prt

This line means that if you try to start any infobase, you will use the client
application version 8.3 with a priority of 64-bit version.
CommonInfoBases
The parameter specifies the path and name of the file with the shared in-
fobases list.
Values from all configuration files are used.
InstalledLocation
The parameter contains a reference to the directory, in which the installation
of 1C:Enterprise was performed. The default value is C:\Program
Files\1cv8.
The values from all configuration files are used in the following order:
• From the common configuration file
• From the local configuration file for all users
• From the local configuration file
NOTE. It is not recommended to use this parameter in a common configu-
ration file (1cescmn.cfg).

DistributiveLocation
The parameter contains a reference to the directory, in which a new version
will be searched for auto-installing.
Values from all configuration files are used.
The directory with distribution packages of new versions will also be
searched in the directory where the common configuration file
(1cescmn.cfg) is located.
CommonCfgLocation
The parameter specifies the path and name of the common configuration
file. Multiple lines with this parameter are allowed.
Values from all configuration files are used.
NOTE. It is not recommended to use this parameter in a common configu-
ration file (1cescmn.cfg).

InstallComponents
The local configuration file and the local configuration file for all users
(1cestart.cfg) contains a list of installed components.
The common configuration file (1cescmn.cfg) contains a list of compo-
nents to be installed (generated by the system administrator).
The parameter value from one configuration file is used according to the
following priority:
• Local configuration file for all users
• Local configuration file
• Common configuration file
The parameter contains a string of components to be installed, separated by
a space:
• 0 - do not install
• 1 - install
The following components are available:
 • DESIGNERALLCLIENTS - all clients and Designer.
• THINCLIENT - thin client for client/server mode operation.
• THINCLIENTFILE - thin client with the ability to operate with file
infobases.
• SERVER - 1C:Enterprise server If Setup starts from a launcher, the
server will be installed as an application.
• WEBSERVEREXT - extension components for web server.
• CONFREPOSSERVER - 1C:Enterprise configuration repository server.
• SERVERCLIENT - components for administrating 1C:Enterprise
servers cluster.
• CONVERTER77 - converter of infobases from 1C:Enterprise version
7.7.
• LANGUAGES - list of installation interface languages. If multiple lan-
guages are specified, they are listed separated by “,”.
NOTE. The language with the EN code will be installed even if it is not
specified in the LANGUAGES parameter or the LANGUAGES parameter is
not specified.

Example:
LANGUAGES=RU,UK,BG

Example parameter:
InstallComponents=DESIGNERALLCLIENTS=0 THINCLIENT=1 WEBSERVEREXT=0
SERVER=0 CONFREPOSSERVER=0 CONVERTER77=0 SERVERCLIENT=1
LANGUAGES=RU,EN

ConfigurationTemplatesLocation
This parameter specifies the path to the configuration templates directory. It
may contain more than one record.
Values from all configuration files are used.
UseHwLicenses
The parameter controls the search for the security key when starting
1C:Enterprise:
• 1 - the protection key is being searched (the default value);
• 0 - the protection key is not being searched.
The parameter value from one configuration file is used according to the
following priority:
• Local configuration file
• Local configuration file for all users
• Common configuration file
This parameter allows to disable the search for a security key when obtain-
ing client licenses is implemented using the Web server extension, the
1C:Enterprise server, or in the case of the base version.
The value of the parameter can be changed by the application in the follow-
ing cases:
• If the search for the security key is enabled, the client application
starts analyzing the security key search time. If the security key was
not found, the start was successful and the search time exceeded 3
seconds, the user is prompted to disable the search for the security key
to speed up subsequent starts. If the user agrees, the
UseHwLicenses=0 parameter is written to the 1cestart.cfg file of
that user.
• If the search for the security key is disabled and at startup it is detect-
ed that the license is not obtained from the 1C:Enterprise server or
from the Web server extension, the user is prompted to enable the
search for the security key. If the user agrees, the
UseHwLicenses=1 parameter is written to the 1cestart.cfg file of
that user, and the client application restarts.
If an external connection is started, an attempt is made to parse the parame-
ter from the 1cestart.cfg file located in the user profile, on behalf of which
the external connection is started. If the user does not have a profile (for
example, a LocalSystem user in Windows), the search for the key is always
performed.
InternetService
URL of the Internet service, which provides a list of shared infobases and
distribution package of the client application.
Initially, an attempt is made to retrieve the required file (with a list of
shared infobases or a distribution package of the client application) by using
an HTTP request, if this attempt fails -an attempt is made to retrieve the file
using a Web service.
The full service URL is generated for the HTTP request as follows: <Ad-
dress obtained from the InternetService parameter>/<Service
name>/<Method name>/?<Method parameters>
For a request using the Web service, the description address (in WSDL
format) is generated as follows: <Address obtained from the Inter-
netService parameter>/<Service name>/?wsdl
WebCommonInfoBases
URL of the Internet service, which provides a shared infobases list.
Initially, an attempt is made to retrieve the shared infobases list by using an
HTTP request, if this attempt fails - an attempt is made to retrieve the file
using a Web service.
The full service URL is generated for the HTTP request as follows: <Ad-
dress obtained from the WebCommonInfoBases parame-
ter>/<Service name>/<Method name>/?<Method parameters>
For a request using the Web service, the description address (in WSDL
format) is generated as follows: <Address obtained from the WebCom-
monInfoBases parameter>/<Service name>/?wsdl
If both the InternetService parameter and the
WebCommonInfoBases parameter are specified, the address specified in
the WebCommonInfoBases parameter is used first, and in case of failure
- the address specified in the InternetService parameter.
WebDistributiveLocation
The URL of the Internet service that provides the distribution package of
the client application.
Initially, an attempt is made to retrieve the client application distribution
package by using an HTTP request, if this attempt fails - an attempt is made
to retrieve the file using a Web service.
The full service URL is generated for the HTTP request as follows: <Ad-
dress obtained from the WebDistributiveLocation parame-
ter>/<Service name>/<Method name>/?<Method parameters>.
For a request using the Web service, the description address (in WSDL
format) is generated as follows: <Address obtained from the WebDis-
tributiveLocation parameter>/<Service name>/?wsdl
If both the InternetService parameter and the
WebDistributiveLocation parameter are specified, the address
specified in the WebDistributiveLocation parameter is used first,
and in case of failure - the address specified in the InternetService
parameter.
AppAutoInstallLastVersion
Specifies the need to automatically install the new version of 1C:Enterprise:
• 0 - disable the automatic installation of the new version;
• 1 - enable the automatic installation of the new version (default val-
ue).
The parameter value from one configuration file is used according to the
following priority:
• Local configuration file
• Local configuration file for all users
• Common configuration file
If no version is installed on the local computer that is required by the server
in the client/server mode or is explicitly specified for the infobase, the value
of the parameter (from the configuration files or command line)
 AppAutoInstallLastVersion is ignored and an attempt is made to
install the new version.

3.6. 1CV8Clst.lst
The file is located in the data directory of each working server marked as
central server.
The file contains the cluster registry and stores the following information:
• 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
Example:
C:\Program Files\1cv8\srvinfo\reg_1541\1CV8Clst.lst

3.7. 1cv8conn.pfl
The file contains a list of cluster main servers in the context of infobases, as
well as other information used by client and server applications of the
1C:Enterprise.
It is required for reliable operation that users, on behalf of which
1C:Enterprise applications are started, have rights to create, read, and modi-
fy data in the directory where the file is located. If 1C:Enterprise is used on
a computer running Windows by different users, it is recommended that all
users, who use the 1C:Enterprise application or the USERS group, have full
access to directory of the file location (listed below), and the CREATOR-
OWNER user (CREATOR OWNER) is removed from the security list of this
directory.
File location:
• On Windows: %ALLUSERSPROFILE%\1C\1cv8.
• On Linux: ~/.1cv8/1C/1cv8.
• On macOS: ~/.1cv8/1C/1cv8.

3.8. 1cv8wsrv.lst
The file is stored on the computer of the working server marked as main, in
the cluster service files directory, and contains a list of the clusters regis-
tered on this computer of the 1C:Enterprise Server. The data it contains is
 necessary for the normal operation of applications that use this
1C:Enterprise server.
Example:
C:\Program Files\1cv8\srvinfo\1cv8wsrv.lst

3.9. adminstall.cfg
The adminstall.cfg file indicates that the 1C:Enterprise application was
installed using Windows administration tools.
NOTE. Applies only to the 1C:Enterprise application under Windows OS.
The file is located in the directory of 1C:Enterprise configuration files. It is
a text document encoded in UTF-8.
The file can contain a single line defining the installation mode:
AdmInstall=<Mode>

<Mode>
Describes the installation mode:
• Logon - the installation is done using a logon script during user logon
on to the domain.
• Restart - installation is done using group policies.
The following is an example of an installation script that can be used to in-
stall the 1C:Enterprise application using Windows Administrative Tools.
Option Explicit

' Change user interface

Const msiUILevelNoChange = 0
' Use the default user interface
Const msiUILevelDefault = 1
' Do not display user interface (silent installation)
Const msiUILevelNone = 2
' Display only progress indicator and errors
Const msiUILevelBasic = 3
' User interface without dialog messages
Const msiUILevelReduced = 4
' Full user interface
Const msiUILevelFull = 5
' For msiUILevelBasic, progress indicator
' is displayed without the Cancel button.
Const msiUILevelHideCancel = 32
' For msiUILevelBasic, progress indicator
' is displayed without any messages, including error messages.
Const msiUILevelProgressOnly = 64
' If used with any of the listed values, the installer
' displays a message about the final result at the end of the
installation.
Const msiUILevelEndDialog = 128

'***** Must be changed to the actual installation directory

Const DistrFolder="\\Server\1CDistr\"

Const shortcutName = "1C:Enterprise startup"

Dim shortcutTarget : shortcutTarget = DistrFolder & "1cestart.exe"

' Constants for defining the action

' installation required
Const requiredInstall = 1
' uninstallation required
Const requiredUninstall = 0

' Value of ProductCode parameter from the setup.ini file ...

'... of the version to uninstall
Const unInstallUID="{9173B91C-FF56-4F25-82D1-7F68244044CD}"
'... of the version to install
Const InstallUID="{0BC98727-04AD-470F-9EEE-0162C543833F}"

' procedure for installing or uninstalling the specified version of

the product
Sub installOrUninstall (ByVal productCode, ByVal msiPackage, ByVal
mstTransform, ByVal requiredAction)
' productCode - Product code information. Located in the file
' setup.ini, ProductCode key
' msiPackage - 1C:Enterprise distribution package
'mstTransform - language conversion file for installer
' requiredAction - required action, either requiredInstall or
' requiredUninstall

' Variable to generate additional

' parameters for installer
 Dim cmdLine

On Error Resume Next

Dim installer, session

Set installer = Nothing

Set session = Nothing
Set installer =
Wscript.CreateObject("WindowsInstaller.Installer") : processError
installer.UILevel = msiUILevelBasic 'msiUILevelNone 'or specify
another user interface option
' product installation checking
Set session = installer.OpenProduct(productCode)

If session Is Nothing AND requiredAction = requiredInstall Then

' product is not installed, installation required
cmdLine = "TRANSFORMS=adminstallrelogon.mst;"
If Not mstTransform Is Empty Then
' adding an instruction to the installer to use the specified
language
cmdLine = cmdLine & mstTransform
' you may additionally specify which components to install
'cmdLine = cmdLine & " DESIGNERALLCLIENTS=1 THINCLIENT=1
WEBSERVEREXT=0 SERVER=0 CONFREPOSSERVER=0 CONVERTER77=0
SERVERCLIENT=1 LANGUAGES=RU"
End If
' installing the platform
Set session = installer.InstallProduct(msiPackage, cmdLine) :
processError
' creating a shortcut on the desktop
createShurtcut()

ElseIf Not session Is Nothing AND requiredAction =

requiredUninstall Then
' platform is already installed, uninstallation required
' only one session object is allowed
Set session = Nothing
' specifying that this version should be removed from the user's
computer
cmdLine = "REMOVE=ALL"
' uninstalling
Set session = installer.InstallProduct(msiPackage, cmdLine) :
processError
End If

Set session = Nothing

Set installer = Nothing

End Sub

'processing errors
Sub processError
Dim msg
If Err = 0 Then Exit Sub
 msg = Err.Source & " " & Hex(Err) & ": " & Err.Description
Wscript.Echo msg
Wscript.Quit 2
End Sub

'creating a shortcut
Sub createShurtcut
Dim WshShell, oShellLink
Set WshShell = WScript.CreateObject("WScript.Shell")
Dim strDesktop : strDesktop = WshShell.SpecialFolders("Desktop")
Set oShellLink = WshShell.CreateShortcut(strDesktop & "\" &
shortcutName & ".lnk")
oShellLink.TargetPath = shortcutTarget
oShellLink.WindowStyle = 1
oShellLink.Description = shortcutName
oShellLink.Save
Set oShellLink = Nothing
Set WshShell = Nothing
End Sub

' uninstalling version 260

installOrUninstall unInstallUID, DistrFolder +
"8.2.9.260\setup\1CEnterprise 8.2.msi", "1049.mst",
requiredUninstall
' installing version 356
installOrUninstall InstallUID, DistrFolder +
"8.2.9.356\setup\1CEnterprise 8.2.msi", "1049.mst", requiredInstall

3.10. agentbasedir.json
Contains the correspondence of the user name and his (user) working direc-
tory when the configuration agent is running.
The file is located in the working directory of the configurator running in
agent mode. The working directory is set using the /AgentBaseDir
command of the command line for start the configurator in agent mode.
The file has the following structure:
{
"usersInfo": [
{
"name": "username",
"dir": "directory_name"
},
…
]
}

In this file, user_name - is the name of the user working with the agent,
and directory_name - is the name of the service directory of this user.
If several users work with the agent, - the agentbasedir.json file will con-
tain several sections for matching the user name and directory.
 3.11. appsrvrs.lst
Contains a list of 1C:Enterprise servers registered in the administration utili-
ty infobases in the client/server mode.
NOTE. Applies only to the 1C:Enterprise application under Windows OS.
Located in the %APPDATA%\1C\1cv8 directory.
Example:
C:/Documents and Settings/User/Local Settings/Application
Data/1C/1cv8/appsrvrs.lst
C:/Users/User/AppData/Roaming/1C/1cv8/appsrvrs.lst

3.12. cfgrepo.conf
The cfgrepo.conf file is used to adjust the location and size of the versions
cache when operating with the configuration repository.
Local cache configuration file location:
• On Windows: %LOCALAPPDATA%\1C\1cv8\<Unique infobase
ID>\cfgrepo.
• On Linux: ~/.1cv8/1C/1cv8/<Unique infobase ID>/cfgrepo.
• On macOS: ~/.1cv8/1C/1cv8/<Unique infobase ID>/cfgrepo.
Global cache configuration file location: in the configuration repository
directory.
The file may contain the following parameters:
cfgrepo.cache.path
Local cache: specifies the path to the directory where the versions cache is
located.
Global cache: specifies the path to the directory where the versions cache is
located, in terms of the file system of the computer where the repository
directory is located or the repository server is installed. In other words, this
is the local path to the versions global cache.
cfgrepo.cache.network.path
Global cache: specifies the UNC path to the directory describing the loca-
tion of the versions global cache. The path specified in this parameter must
be in the same directory as the path specified in the cfgrepo.cache.path
parameter.
cfgrepo.cache.limit
This parameter describes the maximum size of configuration versions
cache.
 3.13. comcntrcfg.xml
The comcntrcfg.xml file is used to indicate that the external connection
needs to start in debug mode.
NOTE. Applies only to the 1C:Enterprise application under Windows OS.
The file is located in the directory with the 1C:Enterprise configuration
files. It is optional.
If the file not found, the external connection opens in normal mode.
Example:
<config xmlns="http://v8.1c.ru/v8/comcntrcfg">
<debugconfig debug="true" protocol="tcp"
debuggerURL="tcp://localhost:1560"/>
</config>

The attributes of the debugconfig item are described below.

debug
Type: Boolean. Indicates the need to start in debug mode:
• debug="true" - debug mode enabled
• debug="false" - debug mode disabled
debug="true"

protocol
Specifies which debug protocol will be used when operating with this pub-
lication if debugging is enabled:
• protocol="tcp" - TCP/IP protocol is used (default)
• protocol="http" - HTTP protocol is used
debuggerURL
Specifies the address of the debugger, to which you need to automatically
connect for debugging, where localhost specifies the search on the local
computer, "1560" - the network port number. If no port is specified, all
ports in the 1560–1591 port range will be scanned. Specifying tcp:// is
equivalent to tcp://localhost. If debugger address is not specified, the de-
bugging is not performed during 1C:Enterprise language code execution.
If HTTP protocol is used, debugger address must include a port number to
be used: http://pc-name:1561.
If the debugging protocol specified using protocol attribute does not
match the arrangement specified in url attribute, connection to the debug-
ger will not be established and the operation is continued without debug-
ging.
Example:
debuggerURL="http://pc-name:1561"

3.14. conf.cfg
The conf.cfg file specifies the location of the common configuration file
directory and the default application interface language.
File location:
• On Windows:
 In the bin\conf directory of a specific version directory of
1C:Enterprise of the appropriate bitness.
 32-bit application in the 64-bit OS:
%PROGRAMFILES(x86)%\1cv8\conf.
 Otherwise: %PROGRAMFILES%\1cv8\conf.
• On Linux:
 In conf directory of the version installed. For example, for the 32-
bit version of 1C:Enterprise, the path to this directory will be as
follows: /opt/1c/v8.3/i386/conf, and for the 64-bit version:
/opt/1C/v8.3/x86_64/conf.
 Directory ~/.1cv8/1C/1cv8/conf (~ - home directory of the user,
on behalf of which the 1C:Enterprise server operates).
• On macOS:
 conf directory of the installed version, for example:
/opt/1cv8/A.B.C.D/conf, where A.B.C.D - the full version num-
ber of the 1C:Enterprise application.
 Directory ~/.1cv8/1C/1cv8/conf (~ - home directory of the user,
on behalf of which the 1C:Enterprise server operates).
The file is a text document encoded in UTF-8.
The file may contain the following parameters:
ConfLocation
The parameter specifies the directory the application will search for config-
uration files (logcfg.xml, nethasp.ini, and so on) if they are not found in
the standard search paths. This parameter makes sense if the file is located
in the conf directory of a particular version.
By default, the parameter value is equal to:
• On Windows:
 32-bit application in the 64-bit OS:
%PROGRAMFILES(x86)%\1cv8\conf.
 Otherwise: %PROGRAMFILES%\1cv8\conf.
• On Linux:
 For the 32-bit version: /opt/1C/v8.3/i386/conf.
  For the 64-bit version: /opt/1C/v8.3/x86_64/conf.
• On macOS: /opt/1cv8/A.B.C.D, where A.B.C.D is the full version
number of 1C:Enterprise.-
Example:
ConfLocation=C:\MySettings\v8\conf

SystemLanguage
This parameter specifies the application interface language. The parameter
value can be specified by the interface language codes or the System val-
ue. If a language value is specified, this language will be used. If System
is specified, the interface language will be determined by the localization of
the operating system.
If you specify a language that does not exist, an attempt will be made to use
the localization language according to the operating system regional set-
tings. If the user interface is not installed in the specified language, the Eng-
lish interface will be used.
When using a client application running under Windows, consider the fol-
lowing feature: if the conf.cfg file with the interface language indication is
located in the conf directory of a specific version, the specified interface
language will be used for a specific version, and if this file is located in the
C:\Program Files\1cv8\conf directory, the specified interface language
will be used for all versions installed on this computer.
If the SystemLanguage parameter is not specified in the configuration
file, the mechanism of defining the interface language using the *.res file
will be used. If there is no file with *.res extension, the interface corre-
sponding to the regional operating system settings will be selected at operat-
ing system startup. Specifying an unknown or nonexistent interface lan-
guage code is equivalent to no file specified.
Example:
SystemLanguage=System

Use the interface language according to the regional operating system set-
tings.
SystemLanguage=RU

Use Russian (RU) language for the interface.

PublishDistributiveLocationWindows32
PublishDistributiveLocationWindows64
PublishDistributiveLocationMacOS64
The parameter specifies the location of the client application distribution
package of the corresponding bitness. This parameter is similar in behavior
and content to the pubdst32, pubdst64 and pubdstmac64 attributes
of the pointelement of the default.vrd file.
NOTE. It is used for the "1C:Enterprise" system, running on macOS and
Windows.

LicConfigDebugTimeouts
This parameter enables shortened verification periods for interactions with
the licensing center. Depending on the parameter value, the following veri-
fication periods can be used:
• This parameter is set to true value (shortened verification periods):
 License verification by server - every 60 seconds;
 License verification by clients- every 30 seconds;
 License re-verification by clients (if the LC is unavailable or after
entering the license client data) - 15 seconds.
• This parameter is set to false value (standard verification periods):
 License verification by server - every 1 hour;
 License verification by clients- every 1 hour;
 License re-verification by clients (if the LC is unavailable or after
entering the license client data) - 10 minutes.
Default value: false.
DBFormatVersion
This parameter specifies the format used to create new databases while in
the infobase file mode.
Values: 8.2.14 and 8.3.8.
Default value: 8.2.14.
ForceTLS1_0
Controls the use of the TLS 1.0 protocol. Depending on the parameter val-
ue, the following protocols are used:
• The parameter set to true - only the version 1.0 of the TLS protocol
is used.
• The parameter is set to false(or any value other than true) - the
protocol used depends on the settings of the web server, with which
the 1C:Enterprise application communicates. Any TLS protocol ver-
sion may be used, up to version 1.2.
 Default value: false.
FileNamesEncodingInZipFile
The parameter controls the encoding used for the names of files in zip ar-
chives generated by 1C:Enterprise.
If the parameter value is set to UTF8, the names of the files containing the
national characters will be displayed incorrectly by the integrated archiving
utility in Windows XP/2003/2008/7 and by the ReadingofZipFile
object in 1C:Enterprise 8.3.6 and earlier. These file names will be displayed
correctly in macOS.
If the parameter value is set to OSEncodingWithUTF8, the file names
containing national characters will be displayed incorrectly by the integrat-
ed macOS archiving utility, but in other cases there will be no issues.
Values: UTF8, OSEncodingWithUTF8.
Default value: UTF8.
DisableUnsafeActionProtection
This option allows to disable protection against unsafe actions for specific
infobases. Infobases are defined by a set of templates (regular expressions)
separated by the semicolon character ";". If the infobase connection string
satisfies any of the regular expressions listed in this parameter, protection
against unsafe actions will be disabled for this infobase.
When editing regular expressions, you should use POSIX Basic Regular
Expressions
(http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_ch
ap09.html#tag_09_03).
This parameter is used by the process that actually performs a potentially
dangerous action:
• Downloading external processings/reports or configuration extensions
- only server (rphost process).
• Downloading external components - client application or server
(rphost process).
• Start an external application - client application or server (rphost pro-
cess).
Example:
DisableUnsafeActionProtection=test_.*;stage_.*;

ExternalResourcesMode
This parameter specifies the components of Internet service resources used
and some details of application behavior.
The parameter can take values:
• D - the default value, and the application functions as follows:
  the platform and configuration software licensing system uses
servers located in Russia;
 when you use the menu commands Help - Information on the
Internet the access is performed to resources in Russia;
 registration in the collaboration system is supported;
 use of 1C Company special service for sending PUSH-
notifications is supported.
• A -alternative list of service resources. In this case, the application
functions as follows:
 the platform and configuration software licensing system uses
servers located in Europe;
 when you use the menu commands Help - Information on the
Internet the access is performed to resources in Europe;
 registration in the collaboration system is not supported;
 Dedicated 1C service for sending PUSH notifications is not sup-
ported
EnableCheckScriptCircularRefs
Controls detection of circular references during the script execution:
• The parameter is set to true value - search for circular references
during the script execution.
• The parameter is set to false - search for circular references during
the script execution is not performed.
Default value: false.
UpdateDBCfg
Specifies which version of the infobase restructuring component will be
used if this is not explicitly specified. Used in the configuration file on the
computer where Designer runs.
The parameter can take values:
• v1 - usual restructuring mechanism. The only option of restructuring
in 1C:Enterprise version 8.3.10 and later.
• v2 - optimized restructuring mechanism. It is true only for the cli-
ent/server mode of the infobase if Microsoft SQL Server or Post-
greSQL is used as a DBMS. If you plan to use the optimized restruc-
turing mechanism in conjunction with the Microsoft SQL Server data-
base management system, the 1C:Enterprise server must use the
TCP/IP network protocol (in terms of the database management sys-
tem) to connect to the database management system. The work of the
optimized restructuring mechanism is not supported if the
1C:Enterprise server is connected to the Microsoft SQL Server DBMS
using Shared memory or Named pipes network protocols.
Default value: v1.
 JavaHome
Specifies the path to the JAVA installation directory. If this parameter is not
specified, the path to the JAVA installation directory is defined in the
JAVA_HOME environment variable. It is used in the configuration file on
the computer where the 1C:Enterprise server cluster is located.
On Windows, if this parameter is not specified in the file conf.cfg and the
JAVA_HOME variable is not set, the path to the Java installation directory
will be defined by the information written into the system registry during
the JRE installation.
JavaOpts
Specifies additional parameters for starting a Java Virtual Machine. The
value of this property must not contain quotation marks. It is used in the
configuration file on the computer where the 1C:Enterprise server cluster
is located.
This property can be used, for example, to set the maximum amount of
RAM available for the Java machine.
Example:
#Setting the maximum amount of available memory for a Java process
JavaOpts=-Xmx2048m

Example:
#Starting JAVA processes with debugger support
JavaOpts=-
agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005

IgnoreServerCertificatesChainRevocationSoftFail
Controls the behavior of the application when the platform cannot explicitly
check the revocation of the certificate:
• Parameter is set to true value - ignore errors that are associated with
the revocation checking of the server certificate.
• Parameter is set to false value- do not ignore errors that are associ-
ated with the revocation checking of the server certificate.
Default value: false.
This parameter affects the following situation: the server has provided the
certificate, the certificate chain is correct, but revocation of the provided
certificate cannot be checked. In this case, the application behaves as fol-
lows, depending on the parameter value:
• The parameter is set to true- the connection will be established.
• The parameter is set to false - the connection will not be estab-
lished, an exception will be generated.
3.15. ConfigDumpInfo.xml
The ConfigDumpInfo.xml version file stores versions of objects that were
contained in the configuration at the moment of dumping. The file is located
in the directory that stores the dumped configuration files.
The version file is an xml-encoded UTF-8 file.
The ConfigDumpInfo root element has a single ConfigVersions
subordinate element. Metadata elements are subordinate to the
ConfigVersions element. The version file contains a Metadata ele-
ment for each object in the dumped configuration. One or more nested
Metadata elements are allowed for each Metadata element. The nested
elements describe subordinate configuration objects that cannot exist sepa-
rately from the parent object. A typical example is object attributes.
This ConfigDumpInfo element contains the following attributes:
format
This attribute specifies the format used for dumping the configuration
whose object versions are specified in this file.
This attribute can take the following values:
• Plain - linear format;
• Hierarchical - hierarchical structure.
version
This attribute contains version number of the configuration dumping format.
The ConfigVersions element does not contain any attributes.
The Metadata element contains the following attributes:
name
The attribute contains the full name of the exported configuration object.
id
The attribute contains the internal ID of the configuration object.
configVersion
The attribute contains the version of the configuration object. This attribute
is used to check whether the configuration object has been modified and
needs to be dumped again.
The values specified in the id and configVersion attributes should be
considered as "magic numbers". These numbers are used exclusively by the
internal components of the platform and are not intended for human users.
 3.16. debugcfg.xml
The debugcfg.xml file is designed to configure the additional port range
used when debugging the configurations.
The file is located in the directory with the 1C:Enterprise configuration
files. It is optional.
The file is used only if debugging is performed over TCP/IP.
If the file is not found, ports from the standard range (1560-1591) are used
for communication. Debugging items on the server use the same ports as the
server processes: rmngr and rphost. Additional port ranges for debug items
on the server are not required.
Example:
<config xmlns="http://v8.1c.ru/v8/debugcfg">
<debugports range="1540:1550"/>
</config>

The attributes of debugports are described below.

range
Type: String. Contains an additional range of ports used for debugging.

3.17. def.usr
The file contains the name of the user who recently opened this infobase.
File location:
• On Windows: %APPDATA%\1C\1cv8\<Unique infobase ID>.
• On Linux: ~/.1cv8/1C/1cv8/<Unique infobase ID>.
• On macOS: ~/.1cv8/1C/1cv8/<Unique infobase ID>.
Example:
C:\Documents and Settings\User\Application Data\1C\1cv8\4129dbdb-
b495-41cb-99ea-ef315060a03e\def.usr
~/.1cv8/1C/1cv8/4129dbdb-b495-41cb-99ea-ef315060a03e/def.usr

3.18. default.vrd
3.18.1. General information
This file is used to configure the web client and to use Internet services. It is
located in the virtual application directory.
NOTE. The hyperlinks in this file must conform to RFC 1738
(http://tools.ietf.org/html/rfc1738.html), RFC 2396
(http://tools.ietf.org/html/rfc2396.html).

3.18.2. <point> (root element)

<point> is the root element of the configuration file. It defines the virtual
resource settings. It may contain one element of <zones>, <ws>,
<pool>, <debug>, <openid>, <openidconnect>, <exitURL>,
and <standardOData>. In this case, several nested <point> elements
are allowed in the <ws> element, and several nested <zone> elements are
allowed for the <zones> element:
<point...>
<ws...>
<point>...</point>
<zones>
<zone>...</zone>
<zone>...</zone>
</zones>
<point>...</point>
</ws>
<httpServices>
<service>...<service/>
</httpServices>
<pool.../>
<debug.../>
<openid>
<rely... />
<provider>
<lifetime>...</lifetime>
</provider>
</openid>
<openidconnect.../>
<exitURL>
...
</exitURL>
<standardOData.../>
</point>

Example:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns=http://v8.1c.ru/8.2/virtual-resource-system
xmlns:xs=http://www.w3.org/2001/XMLSchema
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/demo"
ib="Srvr=&quot;tcp://Server&quot;;Ref=&quot;demo&quot;;"
enable="false"
allowexecutescheduledjobs="force"
<ws>
<point name="OperationalData" alias="OperData"/>
<point name="AnalyticalData" alias="AnalytData"/>
</ws>
<httpServices>
<service name="OperationExample" enable="true"/>
</httpServices>
<pool size="50" maxAge="10" attempts="2"/>
<debug enable="true" protocol="tcp" url="tcp://localhost"/>
<zones>
<zone value="8214" safe="true"/>
<zone value="last" specify="true" />
</zones>
</point>

The root element of the default.vrd file may contain the following attrib-
utes:
 base
The base element points to a relative path (relative to the website root di-
rectory) to the virtual application directory.
TIP. It is recommended to specify the virtual application directory name
using only US ASCII characters.

Example:
base="/demoMA"

ib
Contains the connection string to 1C:Enterprise infobase. Remember that
different connection strings are used for the file and client/server modes.
NOTE. If there are characters in the connection string that are not valid in
terms of the XML standard (http://www.w3.org/TR/xml11/), the charac-
ters must be replaced accordingly.

File infobase example:

ib="File=c:/bases/demo;"

Client/server infobase example:

ib="Srvr=&quot;tcp://myServer&quot;;Ref=&quot;mybase&quot;;"

In the connection string you can specify user login and password. In this
case, the connection to the infobase will be performed on behalf of the spec-
ified user. In the following example, the connection will be established on
behalf of the Seller user:
ib="Srvr=&quot;tcp://myServer&quot;;Ref=&quot;mybase&quot;;Usr=Sell
er;Pwd=123;"

However, if you specify a login and password at the command line for the
client application, the connection will be performed with the parameters
specified in the command line.
enable
Responsible for operations with the published infobase using a thin and a
web client. If the attribute is true, operations with the published infobase
using thin clients and web clients are allowed. The connection string will
look like this (for example at the beginning of the section):
http://host/demo

Otherwise (the attribute is set to false), operations using the thin client
and the web client are not allowed.
Default value: true (operations using the thin client and the web client are
allowed).
temp
Allows to specify a temporary files directory for the web server extension
(wsisapi.dll, wsap22.dll, wsapch2.dll) or for the infobase file mode. If the
attribute is not specified:
• the file infobase uses the 1Cv8Tmp subdirectory of the directory that
contains the infobase file.
• in other cases, the temporary file directory of the user on whose behalf
the request is performed is used.
If the attribute contains a reference to a directory used as a temporary file
directory for the web server extension operation, the user on whose behalf
the web server extension is started must have full access to that directory
and its contents.
pubdstwin32, pubdstwin64, pubdstmac64
NOTE 1. Available only for CORP licenses.
NOTE 2. Applies to 1C:Enterprise under Windows OS and macOS.
The attribute value specifies the full URL of the client application distribu-
tion package file to be downloaded and installed in the event of a mismatch
between the client application and server versions. With this URL, the dis-
tribution package must be accessible from outside the computer, on which it
is located. Attributes contain paths to distribution packages of the corre-
sponding client applications:
• pubdstwin32 - 32-bit client application for Windows OS;
• pubdstwin64 - 64-bit client application for Windows OS;
• pubdstmac64 - macOS client application. The macOS client appli-
cation exists only as a 64-bit application.
If the client application distribution package is obtained over HTTPS con-
nection, the computer that receives the distribution package will check the
certificate of the server from which the distribution package is received us-
ing the root certification authorities certificates obtained from the Windows
root certificate store of the operating system in use.
Archive type: zip. Archive requirements:
• Archive file structure:
 On Windows OS: no hierarchy or directories, only the distribution
package files of the client application.
 On macOS: .dmg file.
• Features of the distribution package files:
 Distribution package for Windows OS: all files with .msi, .cab,
.mst extensions located in the archive must be digitally signed. If
 OS Windows XP is unavailable in a list of client operating systems
(managing installation of 1C:Enterprise), there is no need to ar-
chive a file with _xp name suffix, such as 1CEnterprise8_xp.msi
and 1049_xp.mst etc.
 Distribution package for macOS: All files with .pkg extension
must be digitally signed.
• Digital signatures of the files included in the distribution package
should be checked on the computer where the installation will be exe-
cuted.
Example:
pubdstwin32="http://www.myhost.ru/files/client-win-32.zip"
pubdstmac64="http://www.myhost.ru/files/client-mac-64.zip"

If the server version is changed, you only need to replace the client applica-
tion archive file.
allowexecutescheduledjobs
The attribute controls the ability to execute scheduled jobs by the web serv-
er extension for the infobase file mode.
The attribute can take the following values:
• off- in this case, the web server extension will not perform scheduled
jobs. In this case, the client application (if there is any) that connects
to the infobase directly, without the use of a web server, will perform
scheduled jobs.
• force - in this case, the web server extension will perform scheduled
jobs.
Default value: undefined. In this case, the scheduled jobs will be run by the
application that established the first connection to the infobase.

3.18.3. <ws>
3.18.3.1. Item attributes
The item contains the Web services publishing settings, and is subordinate
to the <point> item. No more than one <ws> item is allowed. This item
can contain any number of <point> items.
The item may contain the following attributes.
enable
Allows or prohibits Web services in the infobase. If the attribute is set to
true (or the attribute is missing), Web services are allowed. Otherwise (i.
e. the attribute is set to false), Web services are not allowed.
Default value: true (Web services are allowed).
 pointEnableCommon
Allows or prohibits Web services published without explicit usage permis-
sion (enable attribute of the point item). If the attribute is set to true,
all Web services that have no explicitly specified value of the enable at-
tribute of the point item are allowed. Otherwise, the use of such Web ser-
vices is prohibited.
Default value: true (Web services are allowed).
publishExtensionsByDefault
Allows or prohibits using Web services from extensions.
If the attribute is set to true, all Web services that are located in attached
extensions are allowed. If the attribute is set to false, Web services in
extensions are not allowed.
Default value: false (Web services in extensions are prohibited).

3.18.3.2. <point>
The item contains a description of the published Web service. The item is
subordinate to <ws> item. There may more than one <point> item. In
this list, you can also manually specify parameters for Web services in ex-
tensions.
If a Web service is not explicitly specified in the default.vrd file and the
use of the application Web services is allowed, the Web service can only be
accessed by name (Web service property name). Access by synonym (alias)
will not be available even if the synonym is specified in the Web service
property Publication file name. In order for the Web service to be accessed
both by name and by synonym (alias)-, you should explicitly specify the
required Web services in the default.vrd file (including the synonym).
The item may contain the following attributes.
name
The name of the published Web service. The service can be accessed both
by a link that includes the name of the Web service, and by a link that in-
cludes a synonym of the Web service.
For the Web service described by the string:
…
base="/demo"
…
<point name="OperationalData" alias="OperData"/>

The following access methods are available:

http://host/demo/ws/OperationalData
http://host/demo/ws/OperData

TIP. It is recommended to specify the Web service name using only US

ASCII characters.

alias
The synonym of the published Web service. The service can be accessed
both by a link that includes the name of the Web service, and by a link that
includes a synonym of the Web service (if the synonym is specified in the
default.vrd file).
For a Web service that is published as follows:
…
base="/demo"
…
<point name="OperationalData" alias="OperData"/>

The following access methods are available:

http://host/demo/ws/OperationalData
http://host/demo/ws/OperData

TIP. It is recommended to specify the Web service synonym using only US

ASCII characters.

enable
Allows or prohibits the use of a web service.
Default value: true (publishing allowed).
reuseSessions
Session Reuse Mode:
• dontuse - sessions are not reused.
• use - session reuse is defined by the client and governed by parame-
ters of HTTP request to the Web service;
• autouse - sessions are reused automatically.
Default value: autouse.
sessionMaxAge
The session idle time after which the session is terminated (in seconds).
Default value: 20 (idle time allowed for a session is 20 seconds).
poolSize
The maximum number of sessions that can be generated during automatic
session management.
Default value: 10 (10 sessions in pool).
poolTimeout
Time to wait for an available session after the session pool is filled (in sec-
onds). If the application cannot create a new session during this time, the
client will receive an error message.
Default value: 5 (session timeout is 5 seconds).
NOTE. Changed values of reuseSessions, sessionMaxAge,
poolSize, poolTimeout attributes will be valid only after the
1C:Enterprise server is restarted.

3.18.4. <httpServices>
3.18.4.1. Item attributes
The item contains the HTTP services publishing settings, and is subordinate
to the <point> item. No more than one <httpServices> item is al-
lowed. This item can contain any number of <service> items.
The item may contain the following attributes.
publishByDefault
If this attribute is not set or set to true, all HTTP services that are added to
the configuration will be automatically available for use, unless explicitly
prohibited by the <service> item.
Default value: true (HTTP services are allowed to operate).
publishExtensionsByDefault
Responsible for the ability to use HTTP services from extensions.
If the attribute is set to true, all HTTP services that are located in connect-
ed extensions will be available for use. If the attribute is set to false, the
HTTP services from the extensions will not be available for use.
Default value: false (extensions HTTP services are prohibited from oper-
ating).

3.18.4.2. <service>
The item contains a description of the published HTTP service. The item is
subordinate to <httpServices> item. There may more than one
<service> item. In this list, you can also manually specify HTTP ser-
vices parameters from extensions.
The item may contain the following attributes.
name
Contains the HTTP service name as it is specified in Designer. This name is
not used to access the service.
rootUrl
Contains the value of the Root URL property of the HTTP service property.
The property is used to determine the HTTP service that should process the
received request.
enable
Allow or prohibits the use of a HTTP service.
Default value: false (use is prohibited).
reuseSessions
Session Reuse Mode:
• dontuse - sessions are not reused.
• use - session reuse is defined by the client and governed by parame-
ters of HTTP request to the HTTP service;
• autouse - sessions are reused automatically.
Default value: autouse.
sessionMaxAge
The session idle time after which the session is terminated (in seconds).
Default value: 20 (idle time allowed for a session is 20 seconds).
poolSize
The maximum number of sessions that can be generated during automatic
session management.
poolTimeout
Time to wait for an available session after the session pool is filled (in sec-
onds). If the application cannot create a new session during this time, the
client will receive an error message.

3.18.5. <pool>
The item contains the settings of the pool of connections with the infobase.
No more than one <pool> item is allowed.
The item may contain the following attributes:
size
Pool size - the maximum number of connections in the pool.
The default value is 10 000.
maxAge
The connection lifetime in the pool - the maximum connection lifetime in
the pool, in seconds. If the connection is not requested within the specified
time, it will be removed from the pool.
 The default value is 20 minutes.
attempts
Maximum number of attempts to establish a connection with the
1C:Enterprise server.
The default value is 5.
attemptTimeout
Waiting time (in milliseconds) to establish a connection with the
1C:Enterprise server.
The default value is 500 ms.
waitTimeout attribute
Waiting time (in milliseconds) between attempts to establish a connection
with the 1C:Enterprise server.
The default value is 500 ms.
serverPingPeriod
Connection interruption check frequency (in milliseconds).
The default value is 1,000 ms.
The maximum value is 65,535 ms.
serverPingTimeout
The time (in milliseconds), during which the connection interruption moni-
toring system is expecting at least one message from the monitored process.
The default value is 5,000 ms.
The maximum value is 2,147,483,647 ms.
Example:
<pool size="50" maxAge="10" attempts="2" attemptTimeout="1"
waitTimeout="1"/>

3.18.6. <debug>
enable
Indicates the need to start in debug mode:
• enable="true" - debug enabled;
• enable="false" - debug disabled.
protocol
Specifies which debug protocol will be used when operating with this pub-
lication if debugging is enabled:
• protocol="tcp" - TCP/IP protocol is used (default)
• protocol="http" - HTTP protocol is used
 url
Specifies the address of the debugger, to which you need to automatically
connect for debugging, where localhost specifies the search on the local
computer, "1560" - the network port number. If no port is specified, all
ports in the 1560–1591 port range will be scanned. Specifying tcp:// is
equivalent to tcp://localhost. If debugger address is not specified, the de-
bugging is not performed during 1C:Enterprise language code execution.
If HTTP protocol is used, debugger address must include a port number to
be used: http://pc-name:1561.
If the debugging protocol specified using protocol attribute does not
match the arrangement specified in url attribute, connection to the debug-
ger will not be established and the operation is continued without debug-
ging.
Example:
<debug enable="true" protocol="http" url="http://pc-name:1561"/>

3.18.7. <zones>
13.4.1.1. Item description
<zones> item is subordinate to <point> item. No more than one is al-
lowed. <zones> item may have one or several subordinate <zone> items.
This item does not have any attributes.

3.18.7.1. <zone>
Each <zone> item describes one separator. The sequence of <zone>
items in <zones> item matches the sequence of separators in Designer. If
the sequence of separators changes, default.vrd file must be edited accord-
ingly. Number of <zone> items must not exceed the number of separators.
If the number of items exceeds the number of separators, an exception will
be generated when connecting to the infobase. If the number of items is less
than the number of separators, the default value for separator type will be
used as a value of non-specified separators and the separator use will be
disabled.
<zone> item may contain the following attributes.
safe
Allows or prohibits changing the values of objects related to data separation
functionality, if the infobase is accessed by a web client or by a thin client
via web server (data separation safe mode). This attribute must be used
when the user needs to ensure that no other data regions can be accessed
when accessing the infobase over the Internet.
Default value: false (changes allowed).
If the attribute value is true, the following actions are prohibited in the
session using this infobase publication:
• Disabling the use of separator, unless the separation is conditionally
disabled.
• Changing the used separator value, unless the separation is condition-
ally disabled.
• Modifying the objects managing the conditional separation:
 Specified for the separator itself
 Specified for the objects included in the separator
specify
Determines whether the published infobase address must contain this sepa-
rator value.
Default value: false (separator is not used in address).
value
Explicitly specifies the value of separator placed in this position.
If value of value attribute is not specified and specify attribute is set to
false, this is equivalent to absence of separator value (corresponds "-"
value in connection string Zn parameter value).
If specify attribute is true and value of value attribute is specified,
this value (case-insensitive) must be explicitly specified in the infobase ad-
dress string in the respective position. Otherwise error code 404 (web page
not found) will be returned when attempting to access the infobase.
Symbols prohibited in URLs (RFC 1738,
http://tools.ietf.org/html/rfc1738.html) are converted to UTF-8 and en-
coded in accordance with section 2.2. URL Character Encoding Issues of
RFC 1738 standard (using "%" and two hex characters).
Default.vrd file example:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns=http://v8.1c.ru/8.2/virtual-resource-system
xmlns:xs=http://www.w3.org/2001/XMLSchema
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/test"
ib="File=&quot;c:\base&quot;;">
<ws enable="false"/>
<zones>
<zone value="8214" safe="true"/>
<zone specify="true" />
<zone />
<zone specify="true" />
<zone value="last" specify="true" />
</zones>
</point>

5 separators are defined in the application in this example. The infobase

address will be as follows:
http://hostname/test/01/20101231235959/last

Which will be treated as follows:

• http://hostname/test - infobase address itself.
• The first separator must not be specified in the address (default
specify attribute value is false), its value is 8214, and it is not
possible to control this separator programmatically (safe attribute
value is true). The other separators can be controlled programmati-
cally, as the safe attribute value for zone items is not specified and
the default value (false) permits program control.
• The second separator must be specified in the address (specify at-
tribute value is true), and its value is 01.
• The third separator is disabled.
• The fourth separator must be specified in the address (specify at-
tribute value is true), and its value is 31-12-2010 23:59:59.
• The last separator must be specified in the address and its value must
be last.
Such separator specification may be used for the thin client running via web
server, for the web client, and for web services.
If different method of specifying the separator values to be applied during
the session are used at the same time, these are determined as follows:
• If default.vrd file contains the specified <zones> item, the separator
values specified in the infobase address have the highest priority. Fur-
ther:
 Values specified in the startup parameter (Z parameters) are ig-
nored.
  Values specified in the infobase connection string are ignored (Zn
parameter in ib attribute of <point> item).
• If <zones> item is not specified in default.vrd file:
 The attempt to define separator values from address string Z pa-
rameter is made.
 If parameter is not specified, the attempt is made to use the values,
specified in infobase connection string (Zn parameter in ib attrib-
ute of <point> item).
• As a general rule, the separator value position priority is as follows
(the priority decreases from top to bottom):
 Infobase address (if default.vrd file contains <zones> item).
 Startup command line (Z parameter).
 Infobase connection string (Zn parameter in ib attribute of
<point> item).

3.18.8. <openid>
3.18.8.1. Item description
This item describes the settings related to OpenID authentication.
<openid> item is subordinate to <point> item. No more than one is
allowed. <rely> and <provider> items are subordinate to <openid>
item. No more than one subordinate element is allowed.
This item does not have any attributes.

3.18.8.2. <rely>
The item contains the address of infobase used as OpenID provider.
url
Specifies the URL of 1C:Enterprise infobase used as OpenID provider. The
infobase must be published in a special way.
IMPORTANT! Interaction with OpenID provider is only performed over
HTTPS connection.
NOTE. OpenID provider URL must not end with "/". Correct:
https://myserver.org/users-ib/e1cib/oid2op, incorrect:
https://myserver.org/users-ib/e1cib/oid2op/.
Example:
<rely url="https://myserver.org/users-ib/e1cib/oid2op"/>

3.18.8.3. <provider>

3.18.8.3.1. Item description

The item specifies that this infobase is used as OpenID provider.
<lifetime> item (no more than one is allowed) is subordinate to this
item.
Example:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns=http://v8.1c.ru/8.2/virtual-resource-system
xmlns:xs=http://www.w3.org/2001/XMLSchema
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/demo"
ib="Srvr=&quot;tcp://Server&quot;;Ref=&quot;demo&quot;;"
enable="false">
<openid>
<provider/>
</openid>
</point>

3.18.8.3.2. <lifetime>
The item specifies the lifetime of the authentication data flag. If the item is
not specified, the default value is 86 400 seconds (24 hours). Maximum
authentication data lifetime is 604 800 seconds (7 days). If greater value is
specified for lifetime item, the maximum value is used.
Example:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns=http://v8.1c.ru/8.2/virtual-resource-system
xmlns:xs=http://www.w3.org/2001/XMLSchema
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/demo"
ib="Srvr=&quot;tcp://Server&quot;;Ref=&quot;demo&quot;;"
enable="false">
<openid>
<provider>
<lifetime>432000</lifetime>
</provider>
</openid>
</point>

3.18.8.3.3. <returnto>
<returnto> item is subordinate to <provider> item and may be used
any number of times or skipped.
<returnto>mysite\.org</returnto>
<returnto>.*\.1c\.ru</returnto>

The item contains a regular expression that defines the mask for permitted
names of websites that can be used to redirect the user's web browser (see
openid.return_to request parameter) after OpenID provider com-
mand is executed.
If no <returnto> item is specified during OpenID provider publishing,
any request to OpenID provider containing openid.return_to parame-
ter will result in HTTP 400 error.

3.18.9. <openidconnect>
3.18.9.1. Item description
This item describes the settings related to authentication over OpenID Con-
nect protocol. Applicable when using thin client and web client.
<openidconnect> item is subordinate to <point> item. No more than
one is allowed. <providers> and
<allowStandardAuthentication> items are subordinate to
<openidconnect> item. No more than one subordinate element is al-
lowed.
This item does not have any attributes.
<openidconnect>
<providers><![CDATA[[
<json-data>
]]]>
</providers>
<allowStandardAuthentication>true</allowStandardAuthentication>
<openidconnect>

3.18.9.2. <providers>
This item contains description of external OpenID providers supporting
OpenID Connect v1.0 authentication protocol
(http://openid.net/connect/). The description is an array of objects,
where each object describes one OpenID provider. The array is represented
by JSON serialization.
Each provider is described with the object with the following properties:
• name - provider ID. Must be unique within the array. If the array con-
tains several providers with the same ID, the last one will be used.
• title - provider text representation. Will be displayed on the pro-
vider button in the authentication page unless the image (image) is
specified.
• image - provider graphical representation. Will be displayed on the
provider button in the authentication page. The image is specified as
data:image in base64 format.
• discovery - describes provider URL (if supported), which allow to
retrieve all its settings (discovery endpoint URL) when accessed.
• provideconfig - provider settings description as JSON file (un-
less the provider supports the request to retrieve settings). The data
must be in OpenID Provider Metadata format
(http://openid.net/specs/openid-connect-discovery-
1_0.html#ProviderMetadata).
• clientconfig - client configuration as JSON file. This data format
matches OAuth 2.0 Authorization Request format
(http://openid.net/specs/openid-connect-core-
1_0.html#AuthRequest), to which the authority that must con-
tain authentication provider URL is added. Contents of this property
depend on the provider used.
redirect_uri property in clientconfig structure has URL
which is used to enter an authentication data processor in an applica-
tion which requests such authentication. As a rule, the said URL is as
follows: https://IBhost/IBname/authform.html, где:
 IBhost - name of a host, where an infobase is published.
 IBname - name of an infobase which has been published ("name"
means information entered in Name field in the infobase publica-
tion dialog box or any similar value, if any other publication meth-
od is used.
• dialect - defines the protocol that will be used to interact with the
provider. If ru-esia value is specified, then the protocol of the Uni-
fied system for identification and authentication will be used to inter-
act with the provider (USIA,
http://minsvyaz.ru/ru/activity/directions/13/). If this attribute is
not specified or its value differs from ru-esia, then OpenID Con-
nect v1.0 protocol will be used to interact with the provider.
• crypto - contains a structure that describes the cryptography module
that is used to sign requests. Signing requests is necessary if the USIA
protocol is used to interact with the provider (dialect property is
equal to the ru-esia value). The structure contains the following
properties:
 module_name - cryptography module name;
 module_path - path to the cryptography module;
 module_type - cryptography module type;
 cert_thumbprint - certificate thumbprint that will be used to
sign requests. Certificate search will be executed by thumbprint.
 The certificate must be previously stored in the personal certificate
store.
The fields of the structure located in the crypto property are similar
to the parameters of the constructor of the
CryptographyManager object.
Provider description example:
<openidconnect>
<providers><![CDATA[[
{
"name": "google",
"title": "Google",
"discovery": "https://accounts.google.com/.well-known/openid-
configuration",
"clientconfig": {
"authority": "https://accounts.google.com/",
"client_id": "<client ID>",
"redirect_uri": "https://localhost/openidc/authform.html",
"response_type": "id_token token",
"scope": "openid email",
"filterProtocolClaims": true,
"loadUserInfo": false
}
},
{
"name": "microsoft",
"title": "Microsoft",
"image": "data:image/png;base64,………",
"discovery": "https://login.microsoftonline.com/<client
ID>/.well-known/openid-configuration",
"clientconfig": {
"authority": "https://login.microsoftonline.com/<client
ID>/",
"client_id": "<client ID>",
"redirect_uri": "https://localhost/openidc/authform.html",
"response_type": "id_token token",
"scope": "openid email"
}
},
{
"name": "googleII",
"title": "Another Google",
"providerconfig": {
"issuer": "https://accounts.google.com",
"authorization_endpoint":
"https://accounts.google.com/o/oauth2/v2/auth",
"token_endpoint":
"https://www.googleapis.com/oauth2/v4/token",
"response_types_supported": ["code","token"],
"scopes_supported": ["openid","email","profile"]
},
"clientconfig": {
"authority": "https://accounts.google.com/",
"client_id": "<client ID>",
"redirect_uri": "https://localhost/openidc/authform.html",
"response_type": "id_token token",
"scope": "openid email"
}
}
]]]>
</providers>
 <allowStandardAuthentication>true</allowStandardAuthentication>
</openidconnect>

3.18.9.3. <allowStandardAuthentication>
The item allows or prohibits 1C:Enterprise authentication. If this item is
false, authentication using the providers described in default.vrd file will
be available in the authentication form on web client startup.
The item can take the following values:
• true - 1C:Enterprise authentication is permitted. Default value.
• false - 1C:Enterprise authentication is forbidden.

3.18.9.4. Operation scenario

Authentication using the OpenID Connect provider is available only if the
parameters of one or more providers are specified in the default.vrd file.
When trying to use a client application (thin or web client) to access the
infobase, the following actions are executed:
• If the provider is explicitly specified in the client application com-
mand line, the jump is executed in accordance with the parameters,
specified in default.vrd file for this provider.
• Otherwise, the platform forms a start form (depending on the client
application), on which all configured OpenID Connect providers are
located (in the default.vrd file). Depending on the settings, this web
page may contain the access button using the standard 1C:Enterprise
authentication.
• After selecting the provider, the user is redirected to the provider's au-
thentication page. On this page, the user authenticates with selected
provider in any possible method (for this provider).
• Then the provider redirects the user to a special page of the
1C:Enterprise system, passing a JSON file as a "parameter" (JSON
Web Token, JWT) with the authentication results. URL of this page is
specified in redirect_uri property in clientconfig structure
of provider element.
• Using the authentication results passed by the provider, 1C:Enterprise
retrieves the user email from the provider.
• Retrieved e-mail address is used to search for the user in the
1C:Enterprise infobase. Search is executed by the user property Name.
• After that the authentication is deemed to be successful and the appli-
cation startup continues.
If authentication on the provider side fails, the provider's actions are not
defined.
 3.18.10. <exitURL>
Specifies the URL to open after exiting the web client.
Example:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/demo"
ib="Srvr=&quot;tcp://Server&quot;;Ref=&quot;demo&quot;;"
enable="false">
<exitURL>http://www.1c.ru</exitURL>
</point>

3.18.11. <standardOData>
This item determines whether OData standard interface is available for the
published infobase. The item is subordinate to <point> item.
<standardOData> item can be just one or none. If default.vrd contains
no such item, -the standard OData interface is not available for the pulished
application.
The item may contain the following attributes.
enable
The attribute controls availability of the OData standard interface via the
specified publication. The attribute can take the following values:
• true - data operations using the OData standard interface are possi-
ble via the current publication;
• false - data operations using the OData standard interface are not
possible via the current publication.
reuseSessions
Session reuse mode when using the OData standard interface:
• dontuse - sessions are not reused.
• use - session reuse is defined by the client and governed by parame-
ters of HTTP request to the Web service;
• autouse - sessions are reused automatically.
Default value: dontuse (sessions are not reused).
sessionMaxAge
The session idle time after which the session is terminated (in seconds).
Default value: 20 (idle time allowed for a session is 20 seconds).
poolSize
The maximum number of sessions that can be generated during automatic
session management.
poolTimeout
Time to wait for an available session after the session pool is filled (in sec-
onds). If the application cannot create a new session during this time, the
client will receive an error message.

3.19. inetcfg.xml
inetcfg.xml file allows to specify the default proxy settings and has a great-
er priority over the default proxy settings in Windows OS or parameters,
specified in the environment variables in Linux and macOS.
The file is located in the directory with the 1C:Enterprise configuration
files. It is optional.
• On Windows:
• If there is a file, - the settings are taken from the file.
• If the file is absent- the settings are taken from Microsoft Internet
Explorer settings. The use of an automatic configuration scenario
is not supported.
• On Linux:
 If there is a file, - the settings are taken from the file.
 If the file is absent -, the attempt is made to retrieve the settings
from environment variables http_proxy, https_proxy,
ftp_proxy, ftps_proxy (in accordance with the protocol
used). If the environment variables are not specified, the attempt is
made to retrieve the proxy settings from all_proxy environ-
ment variable. If the environment variables contain invalid param-
eters -, these are ignored.
• On macOS:
 If there is a file, - the settings are taken from the file.
 If the file is absent -, the attempt is made to retrieve the settings
from environment variables http_proxy, https_proxy,
ftp_proxy, ftps_proxy (in accordance with the protocol
used). If the environment variables are not specified, the attempt is
made to retrieve the proxy settings from all_proxy environ-
ment variable. If the environment variables contain invalid param-
eters -, these are ignored.
During proxy setup the User-Agent data from the HTTP request may be
used:
• thin client - 1CV8C;
• Web service- 1C+Enterprise/8.3;
 • web client - this parameter is generated by web browser.
Example:
<InternetProxy
protocols="http=10.1.0.8:8080 10.1.0.9:8080"
user="proxyUser"
password="proxyPassword"
bypassOnLocal="true"
bypassOnAddresses="127.0.0.1 *.master"
/>

InternetProxy root item, containing the default proxy settings, has the
structure (attributes) as specified below.
ntlm optional
Type: Boolean. NTLM authentication use flag:
• true - NTLM authentication is enabled;
• false - NTLM authentication is disabled.
NTLM authentication is enabled by default.
protocols optional
Type: String. Specifies the host name and port for the protocols. The
format is as follows:
ProtocolProxyParameters1ProtocolProxyParameters2
…ProtocolProxyParametersN
ProtocolProxyParameters:=[Протокол]"="host":"port

The proxy-protocols parameter list is separated by spaces. Each parameter

contains the optional protocol name, “=” sign, and proxy server host name
and port separated by colon. If the protocol name is not specified, the proxy
parameters are used for all the protocols, for which these are not explicitly
specified. The protocols can have the following names:
• HTTP,
• HTTPS,
• FTP.
It is case-sensitive, other protocol names are not supported, e.g.:
protocols="http=10.1.0.8:8080 10.1.0.9:8080"

Where:
• for HTTP the following proxy parameters are defined: host - 10.1.0.8,
port - 8080;
• for other protocols (HTTPS, FTP): host - 10.1.0.9, port - 8080.
user optional
Type: String. Username for authentication on proxy server, e.g.:
user="proxyUser"

password optional
Type: String. User password for authentication on the proxy server. Ex-
ample:
password="proxyPassword"

bypassOnLocal optional
Type: Boolean. Flag, specifying the use of proxy servers for the local
addresses:
• true - not used;
• false - used.
Whether the address is local is determined by the presence of dot in address
DNS name (i. e. all the IP addresses are not local). In some situations, a
local address is not recognized correctly.
For example, <user>.<domain> is a local address in Windows XP, but
is not recognized as such. In order to restrict using proxy for the addresses
recognized as local, the following parameter is used:
bypassOnLocal="true"

For all other addresses, bypassOnAddresses parameter must be used.

bypassOnAddresses optional
Type: String. List of addresses the proxy is not used for. The format is
as follows:
host1 host2 … hostN

Host names are separated with spaces. Host name may contain the follow-
ing mask special characters: * - any number of characters, ? - any character.
For example, in order to block proxy for all the domain hosts, use:
*.<domain name>, such as:
bypassOnAddresses="127.0.0.1 *.master"

In this example, the proxy is not used for 127.0.0.1 (localhost) address and
all the master domain addresses.

3.20. location.cfg
location.cfg file is used to specify the directory containing the user settings
files and software license file location. location parameter is used to specify
the directory location.
location
Directory path.
Example:
location=C:\Users\UserName\AppData\Roaming\1C\1cv82

3.21. logcfg.xml
3.21.1. General description
logcfg.xml file is used to configure the parameters of technological log and
memory dumps generation function in case of unexpected 1C:Enterprise
shutdown.
The file is located in the directory with the 1C:Enterprise configuration
files. It is optional.
If the file is not found, the default technological log settings are applied:
• Technological log (<log> element) - is disabled.
• Technological log by default (<defaultlog> element):
 Generation is - enabled.
 Life time - 24 hours.
 The level of event generation <system> for all system compo-
nents is defined as Error.
 Stores in directories:
 Windows OS:
%USERPROFILE%\Local Settings\1C\1cv8\logs
(%LOCALAPPDATA%\1C\1cv8\logs for Windows Vista and
later).
 Linux: ~/.1cv8/logs.
• Forced abortion dumps (relevant only for Windows OS):
 Minimum forced abortion dumps of system work is saved
(type="1").
 Dumps are saved to %USERPROFILE%\Local Set-
tings\Application Data\1C\1cv8\dumps
(%LOCALAPPDATA%\1C\1cv8\dumps directory for Win-
dows Vista and later).
Example:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="c:\v8\logs" history="1">
<event>
<eq property="name" value="conn"/>
</event>
</log>
<dump location="c:\v8\dumps" create="1" type="2"/>
</config>

This configuration file specifies that:

 • All events of establishing or losing connection to the server are writ-
ten to the technological log
• Technological log files are located in C:\v8\logs directory
• Technological log files are stored for 1 hour
• Dump files are saved to C:\v8\dumps directory
• Dump files contain all available information (the entire process
memory)
TIP. To edit technological log configuration file it is convenient to use the
special tool, located on the ITC disk: Engineering support of-
1C:Enterprise 8 - Universal reports and data processors - Configuring
technological log (http://its.1c.ru/db/metod8dev/content/3474/hdoc).

3.21.2. Configuration file

structure
3.21.2.1. General description
Configuration file root item is the <config> item that defines the techno-
logical log settings. It may contain several <log> items, one <dump>
item, one <leaks> item, one <plansql> item, one <defaultlog>
item, one or several <system> items:
<config…>
<log…>…</log>
<log…>…</log>
<log…>…</log>
<dump … />
<leaks>…</leaks>
<mem/>
<plansql/>
<dbmslocks/>
<ftextupd …/>
<query …/>
<inputbystring …/>
<scriptcircrefs/>
<system … />
<system … />
<system … />
<defaultlog … />
</config>

These items have the following functions:

• <log> item defines the technological log directory and its composi-
tion.
• <dump> item defines unexpected shutdown dumps saving directory.
 • <leaks> item sets tracking for memory leaks that may be caused by
the configuration code errors. Memory leak tracking decreases the
performance slightly.
• <mem> item is intended to control memory usage.
• <plansql> item is intended to manage collection of the query plans
generated during DMBS operations. The query plans themselves are
contained in <planSQLText> property of DBMS-related events.
• <dbmslocks> item is intended to manage collection of the DBMS
lock data.
• <ftextupd> item is intended to manage collection of data on the
full-text search index update processes.
• <query> item manages writing technological log entries on the
fields that illegally contain NULL when executing external data
source queries.
• <inputbystring> item is intended to manage collection of data
on the usage of input by string functionality.
• <scriptcircrefs> item manages the functionality of circular
references data tracking during 1C:Enterprise language command ex-
ecution.
• <defaultlog> item defines the default technological log directory
and lifetime.
• <system> item defines system event generation settings.
Items are divided into several groups:
1. Items that control generation of a specific event. Such items include
<dump>, <leaks>, <mem>, <plansql>, <ftextupd>,
<system>, <query>, <scriptcircrefs>,
<inputbystring>. However, if the technological log configura-
tion file does not contain the required item, the system does not gener-
ate the respective event. In other words, if, for example, recording of
the memory used is not enabled by <mem> item, filtering by MEM
event will not affect the technological log contents, as this event is
simply not generated.
2. Items that control filtering of the existing technological log data. Such
items include <event> and <property>. You can use these items
to filter the events generated by the system. These items can only re-
duce the amount of data recorded to technological log files.
3. Items that control placement of data files for technological log and
dumps. Such items include <log>, <defaultlog>, <dump>.

3.21.2.2. <log>
<log> item defines the technological log directory and the filtering criteria
used to store the previously generated events in the technological log.
IMPORTANT! Allowing a large amount (over 20) of technological logs
(<log> items) in logcfg.xml is not recommended. Large amount of con-
figured logs may cause a significant system performance decrease.
The item attributes:
location
Name of the directory to save the technological log to.
IMPORTANT! Please take note that the directory of the technological log
is not intended to store any files unrelated to the technological log. Do not
keep dumps in this directory, and do not keep 1C:Enterprise technological
log in a directory with any unrelated files. If any unrelated files are found in
the technological log directory, the directory is considered invalid and the
log is not created.
NOTE. Different directories must be specified in the location attributes
of the <log>, <dump> and <defaultlog> items.

history
Retention time of technological log records.

The <log> item may contain<event> and <property> items that de-
termine the conditions for recording each event and event property to the
log.
If this item contains no <event> items, no events are recorded to the log.

3.21.2.3. <event>
Sequence of <event> items defines the condition for saving the event to
the log. Only the events meeting the condition are saved to the log. In other
words, if the condition defined by the <event> items sequence is True,
the event is written to the log. The event is added to the log if it meets all
the conditions within at least one of the <event> items. The conditions
within the <event> item are combined using logical AND, and the
<event> items are combined using logical OR.
Conditions are set by the below items:
• eq - equals;
• ne - does not equal;
• gt - is greater;
• ge - is greater or equals;
• lt - is less;
• le - is less or equal;
• like - matches the mask.
 Each of these items, except like item, defines a simple comparison of the
event parameter value (property attribute defines the parameter name) to
the value attribute value.
Example:
<event>
<eq property="name" value="proc"/>
</event>

In this case, events referred to the group named PROC will be recorded to
the technological log.
The following event names are available:

Event name Description

ADMIN Control actions of 1C:Enterprise server clus-
ter administrator.
ATTN Records of 1C:Enterprise cluster status mon-
itoring subsystem.
CALL Incoming remote calls (call target side re-
mote calls).
CLSTR Execution of actions changing the server
cluster operation.
CONFLOADFROMFILES Execution of configuration restoring from
the files.
CONN Establishment or termination of client con-
nection to a server.
DB2 Execution of DB2 SQL operators.
DBCOPIES Operations with database copies.
DBMSSQL Execution of Microsoft SQL Server SQL
operators.
DBMSSQLCONN The event is generated when the
1C:Enterprise server connects Microsoft
SQL Server DBMS for the first time when
the provider for database is selected.
DBORACLE Execution of Oracle Database SQL opera-
tors.
DBPOSTGRS Execution of PostgreSQL SQL operators.
DBV8DBENG Execution of file-based DBMS SQL opera-
tors.
DHIST Execution of data history update.
EDS Operations with external data sources.
EXCP 1C:Enterprise applications exceptions,
which are not handled in standard way and
may cause the unexpected shutdown of the
Event name Description
server process or client process connected to
it.
EXCPCNTX Events that have started but have not fin-
ished, when the abnormal situation occurred.
FTEXTCheck Occurs when verifying the full-text search
index files.
FTEXTUpd Occurs during the full-text search index files
update.
HASP The event logs a single dongle access.
InputByString Occurs when the platform processes the in-
put by string.
LEAKS Events related to the memory leak, which
may be caused by the configuration code
errors.
LIC Events related to retrieval and release of the
licenses (both software and HASP), retrieval
of licenses for the base versions, regular
monitoring of matching the actual hardware
and list of hardware, recorded in the license.
MAILPARSEERR Event generated if an error occurred when
parsing the mail message.
MEM Events related to the increase of memory,
used by the server processes (ragent,
rmngr, rphost).
PROC Events related to the entire process and af-
fecting the process performance. Example:
startup, shutdown, unexpected shutdown,
etc.
QERR Events related to detection of query compi-
lation errors or database records or fields
level restrictions.
SCALL Outgoing remote calls (call source side out-
going calls).
SCOM Events of creation or deletion of server con-
tents, usually related to the infobase.
SDBL Events related to querying the 1C:Enterprise
database model.
SDGC The event occurs when a session data clear-
ing mechanism is triggered.
SESN Actions related to the session. Example:
session start, session end, etc.
SRVC Events related to startup, stopping and noti-
 Event name Description
fications of the server cluster services.
SYSTEM Platform component-related system events
intended for analysis by 1C technical ex-
perts. Configuration of such events must be
performed based on the explicit instructions
from the technical support and only for the
period to reproduce some investigated prob-
lem. Otherwise, such configuration may
cause the significant increase of log file size
and decrease the application performance.
TDEADLOCK Deadlock in the managed mode is detected.
TLOCK Transaction lock control in managed mode.
TTIMEOUT Transaction lock timeout.
VRSCACHE Server call cache operations.
VRSREQUEST Request to server for a resource.
VRSRESPONSE Server response.
WINCERT Errors related to certificate verification using
Windows functionality. Such events may
help the specialists to investigate the causes
of incorrect certificate verification.
It is also worth noting that events from PROC, SCOM, EXCP, CONN
and ADMIN groups are relatively rare and contain small amount of data,
while logging of events from SDBL, DB2, DBMSSQL, DBPOSTGRS,
DBORACLE groups may cause the significant increase of technological log.
like item determines whether the technological log property matches a
mask. The mask is a sequence of characters, some of which represent them-
selves, and some are templates intended to describe a group of characters.
For example, <like property="SDBL"
value="%reference%"/> item means checking if the SDBL property
value of the technological log event matches the mask %reference%.
Templates include the following:
• % - 0 or more arbitrary characters.
• _ - 1 arbitrary character.
• [...] - one of the listed characters, where [...] may contain any
characters and ranges similar to c-C, where c - is the range starting
character, C - is the range ending character.
• [^...] - any single character, except the characters specified in
square brackets [].
• \ - prefix character. It is ignored and means, that the next character -
is just a character, representing itself (not a template).
 • All the other characters - are just simple characters repre-
senting themselves. Simple characters comparison is case-insensitive.
Sample templates:
• template - string with specific text. In this case comparison using
like does not differ from comparison using eq. Case-insensitive.
• %reference% - string, containing reference context in arbitrary
position. Case-insensitive.
• reference% - string, containing reference context in the begin-
ning. Case-insensitive.
• %reference - string, containing reference context in the end.
Case-insensitive.
• %[a-z] - string with lowercase English letter from a to z in the end.
• %[^a-z]% - string, containing at least one character, different from
the lowercase English letter.
NOTE. Event filtering using templates is slower than when using other
comparison items. Using complex technological log events and properties
filtering may somewhat reduce 1C:Enterprise performance.

Example:
<log location="c:\logs" history="1">
<event>
<eq property="name" value="proc"/>
</event>
<event>
<eq property="name" value="scom"/>
</event>
<event>
<eq property="name" value="conn"/>
</event>
<event>
<eq property="name" value="excp"/>
</event>
<event>
<eq property="name" value="dbmssql"/>
</event>
</log>

This example illustrates how the events from PROC, SCOM, CONN, EXCP
and DBMSSQL groups are recorded in the technological log.

3.21.2.4. <property>

3.21.2.4.1. General information

<property> item defines the conditions for an event whose name is the
name attribute value to be recorded in a log, provided that the event itself is
 recorded in the technological log. The conditions are set by the nested
<event> items following the event rules.
If there is no <property> item with a specific name, the respective prop-
erty is not recorded. If <property> item contains no nested <event>
items, the property defined by it is recorded for all the events containing this
property and recorded in the log. If <property> items contains nested
<event> items, the property will be recorded for the events meeting the
condition (if the event itself is recorded in the log and has this property).
<property name="all"> </property> item includes the records
of all the event properties to the log.
The below <log> item defines the following events to be recorded in the
log: process, server context, connection, exceptions and execution of SQL
operators. However, the SQL operator text will only be saved to the log if
its execution took longer than a second. The log is located in C:\logs direc-
tory and is stored for 1 hour.
Example:
<log location="c:\logs" history="1">
<event>
<eq property="name" value="proc"/>
</event>
<event>
<eq property="name" value="scom"/>
</event>
<event>
<eq property="name" value="conn"/>
</event>
<event>
<eq property="name" value="excp"/>
</event>
<event>
<eq property="name" value="dbmssql"/>
</event>
<property name="sql">
<event>
<eq property="name" value="mssql"/>
<gt property="duration" value="10000"/>
</event>
</property>
</log>

Each event has a set of properties. Each property has a name. Several prop-
erties with the same names are allowed per event. Property names may be
used for events and properties filtering. Comparison of names is case-
insensitive. Empty condition in <property> item means that the property
is always displayed.
NOTE. Event property is only displayed if <property> item exists for it.
3.21.2.4.2. List of properties
The basic event properties, which may be required for configuration file
setup and technological log browsing, are given below:

Property name Description

Action Text description of the operation per-
formed while restoring the configura-
tion from files (for
CONFLOADFROMFILES event).
Admin Cluster or central server administrator
name.
agentURL URL of the current process of
1C:Enterprise server agent.
All Enables recording of all the log
events.
ApplicationExt Specification of the functionality as-
signment rule (for CLSTR event).
Attempts Number of attempts to establish con-
nection with the process that resulted
in an error (for ATTN event).
AvgExceptions Average number of exceptions for the
last 5 minutes in other processes (for
ATTN event).
AvMem Value of Available memory indica-
tor when writing to technological log
(for FTEXTUPD event).
BackgroundJobCreated Determines whether full-text search
index generation was performed as a
background process (true) or not
(false) (for FTEXTUpd event).
Body Size of request/response body in
bytes (for VRSREQUEST,
VRSRESPONSE events).
Calls Number of client application calls to
server application made over TCP.
Certificate Verified certificate description (for
WINCERT event). Incudes the follow-
ing certificate fields: subject (sub-
ject), issuer (issuer), serial number
(sn).
Class Name of class that generated the
event (for SYSTEM event).
Property name Description
Cluster Server cluster main port.
Component Name of the platform component that
generated the event (for SYSTEM
event).
Connection Number of infobase connection.
ConnLimit Maximum number of connections per
working process (for CLSTR event).
Context Execution context.
CopyBytes The overall size of copied values ap-
plicable to garbage collection (for
SDGC event).
CurExceptions Number of exceptions in the process
over the last 5 minutes (for ATTN
event).
сn Number of dynamic memory frag-
ments occupied by the process when
writing MEM event.
сnd Change in the number of dynamic
memory fragments occupied by the
process since the last MEM event.
Database Used database path (for DB2,
DBMSSQL, DBORACLE,
DBPOSTGRS, DBDA, EXCP, SDBL
events). For the client-server version,
the database name is generated as a
NameServer\BaseName, for the
file version, the full path to the
1Cv8.1CD file is displayed.
DBCopy Name of the database copy used (for
DB2, DBMSSQL, DBORACLE,
DBPOSTGRS, DBDA, EXCP, SDBL
events). If access to the copy does not
occur, -this property is not written.
Dbms Dbms the name of the DBMS used to
execute the operation that led to the
generation of this technological log
(for EDS, DB2, DBMSSQL,
DBORACLE, DBPOSTGRS, DBDA,
EXCP, SDBL events). Can take the
following values:
• DB2 - IBM DB2 (except DBDA
Property name Description
event);
• DBMSSQL - Microsoft SQL
Server;
• DBOracle - Oracle Database;
• DBPOSTGRS - PostgreSQL;
• DBV8DBEng - file-based
DBMS (for EXCP, SDBL events
only);
• DBMySQL - MySQL (for EDS
event only);
• DBMSSQLServerAnalysis
Services - SQL Server
Analysis Services (only for EDS
event);
• DBOracleEssbase - Oracle
Essbase (only for EDS event);
• DBIBMInfosphereWareho
use - IBM Infosphere Ware-
house (only for EDS event);
• DBDA - Data Accelerator (for
DB2, DBMSSQL, DBORACLE,
DBPOSTGRS, DBDA, EXCP,
SDBL events);
• DBUnkn - other DBMS (only
for EDS event).
DBConnID External data source DBMS connec-
tion ID (for EDS event).
DBConnStr External data source connection
string (for EDS event).
dbpid String representing the ID of
1C:Enterprise server connection to
the database server in database terms
(for DBMSSQL, DBPOSTGRS, DB2,
DBORACLE events).
DBUsr External data source DBMS
username (for EDS event).
DeadlockConnectionInte List of transaction pairs forming the
rsections deadlock (for TDEADLOCK event).
Descr Software exception description.
description Text explaining the action being per-
Property name Description
formed (for DHIST event).
dumpError Description of an error occurred dur-
ing the process of dumping.
DumpFile Name of the dump file.
Duration Duration of an event in hundreds of
microseconds.
Durationus Duration of an event in microseconds.
Err Console message type: 0 - infor-
mational; 1- about an error.
errorCode Error code returned by the handling
method of working with the Windows
API certificates (for the WINCERT
event).
Event Contains a name of the action per-
formed by a cluster of servers (for
CLSTR event) and determines the
presence of other properties in current
event.
Exception Name of the software exception.
FailedJobsCount Number of the background indexing
processes that finished with errors
(for FTEXTUpd event).
File Name of a file in which an event was
generated (for SYSTEM event) or in
which a problem was detected in the
course of checking the index of a full-
text search (for FTEXTCHECK
event).
Files List of files formatted as "file name ...
file size" in the directory in which an
action is occurring (for FTEXTUPD
event). A property is generated only
if the logfiles attribute of the
ftextupd element is set to value
True.
FilesCount Number of files in the directory in
which an action is occurring (for
FTEXTUPD event). A property is
generated only if the logfiles
attribute of the ftextupd element is
set to value True.
Property name Description
FilesSize The overall size of storage in bytes
(for SDGC event).
FilesTotalSize Number of files in the directory in
which an action is occurring (for
FTEXTUPD event). A property is
generated only if the logfiles
attribute of the ftextupd element is
set to value True.
FillRefsPresent If a property does exist, it means that
the cache of links from the user list of
values is used instead of a full-text
data search (for the
INPUTBYSTRING event).
FindByString Name of a configuration object for
which input by string is performed.
findTicks Time spent while searching the data-
base, in ms (for INPUTBYSTRING
event).
Finish Reason for ending the process.
Folder Directory in which the action is oc-
curring (for FTEXTUPD event).
Could be a temporary directory or a
directory for files with an index of a
full-text search. A property is gener-
ated only if the logfiles attribute
of the ftextupd element is set to
value True.
ftextResultCount Number of links found in the course
of a full-text search (for
INPUTBYSTRING event).
ftextSearchCount Number of calls to the full-text search
(for INPUTBYSTRING event).
ftextTicks Time spent on full-text search, in ms
(for INPUTBYSTRING event).
Func Name of the action.
Headers HTTP request / response headers (for
VRSREQUEST, VRSRESPONSE
events).
Host Computer name.
hResultOLEDB, Contains a hexadecimal return code
hResultNC2005, when trying to connect through a one
Property name Description
hResultNC2008, or another provider (OLE DB, SQL
hResult2012 Server Native Client versions 2005,
2008, 2012). If the attempt to connect
through provider was not performed,
a property -will be unavailable. At-
tempts to connect begin with the pro-
vider corresponding to the most cur-
rent version of Microsoft SQL Server
and then all providers are to be sorted
out in order to lower the version. Af-
ter a successful connection is com-
pleted, all further attempts to estab-
lish a connection through other pro-
viders are stopped.
IB Name of an infobase in the cli-
ent/server mode.
IBLimit A determined maximum number of
infobases per each working process
(for CLSTR event).
IName Name of the interface being transmit-
ted, whose method is called remotely
(for SCALL and CALL events).
InBytes Amount of data read from hard drive
during a call (in bytes).
Info Crash info (for FTEXTCheck event).
InstanceID Unique storage identifier (for SDGC
event). Integer.
JobCanceledByLoadLimit Flag indicating that the background
indexing process has been canceled
because a load limit for the working
process has been reached (for
FTEXTUpd event).
Level Event severity level (for SYSTEM and
CONFLOADFROMFILES events).
Possible event values are provided in
the description of element
<system> from the file logcfg.xml
containing configuration of technolo-
gy log.
Line String number in the file where
SYSTEM event was generated.
LockDuration Duration of storage lock in the period
Property name Description
when garbage collector is in opera-
tion, in milliseconds (for SDGC
event).
Locks A list of managed transaction locks
(for TLOCK event).
MDX Text of MDX request to OLAP sys-
tem.
Memory Amount of memory in bytes used but
not released, per server call.
MemoryPeak A peak value of memory in bytes
used but not released, per server call.
MemoryUsed The maximum size of dynamic
memory used during the call (for
FTEXTUpd event).
MessageUid A unique ID of mail message, a pars-
ing of which resulted in an error.
Value is equal to the property ID of
the object
InternetMailMessage.
Method HTTP method of accessing the re-
source (for VRSREQUEST,
VRSRESPONSE events) or a method
of InternetMail object during
which an error in parsing the mail
message (for MAILPARSEERR
event) occurred, or a name of the
method being called which is differ-
ent from call method (for CALL
event or current action of garbage
collector (for SDGC event).
For the event MAILPARSEERR can
take the values:
• GET - A problem detect-
ed during execution of the
Select () method.
• GETHEADERS - A problem was
detected during execution of the
GetHeaders () method.
• SETRAW - A problem was
detected during execution of the
SetInitialData ()meth-
Property name Description
od.
For the CALL event, this property
contains a number of the called meth-
od of the interface; wherein the ID of
the called interface is specified in the
Interface property.
For SDGC event can accept the fol-
lowing values:
• Compact - compaction of
stored data.
• Analyze - storage state analy-
sis. No compaction required.
MaxMemSize Maximum amount of memory in
bytes that can be taken up by the pro-
cess specified in the cluster settings
(for ATTN event).
MDX Text of the executed request to OLAP
system (only for EDS event).
MemSize Amount of memory in bytes that can
be taken up by the process (for ATTN
event).
MinDataId Minimum ID of the indexed data in
the chunk passed from the cluster
manager into working process and
back (for FTEXTUpd event).
MName Name of the remotely called method
(for SCALL and CALL events).
MyVer Current server state version (for
CLSTR event).
Name Event name.
NeedResync The server data synchronization is
required (for CLSTR event whose
Event property is equal to current
version older).
Nmb A session number (for SESN event).
NParams Number of parameters of SQL opera-
tor for the file version of infobase (for
DBV8DBENG event). Parameters
whose amount has been specified in a
given property, are being used to
transfer long binary data.
Property name Description
OSException Description of the operating system
exception.
OutBytes Amount of data (in bytes) recorded
on hard drive during a call.
p:processName Name of server context which usually
matches the name of infobase.
Phrase A text phrase corresponding to the
status code (for VRSRESPONSE
events).
PID Process ID of the operating system.
planSQLText A query plan contained in Sql prop-
erty (for DBV8DBENG, DBMSSQL,
DBPOSTGRS, DB2, DBORACLE,
EDS events).
Port Number of the main network port of a
process.
Process Name of an application module, as
interpreted by the operating system
(the file name of the booting applica-
tion's module).
ProcessName Name of a process.
procURL A server process address of 1C: En-
terprise system to which the event
relates.
Query Text of query in the 1C:Enterprise
language during the execution of
which NULL value was detected in
the field for which such a value is
invalid (for QERR event).
QueryFileds List of query fields in which NULL
values have been detected (for QERR
event).
Reason The reason for a non-availability of
working process (for CLSTR event).
Ref Infobase name
Regions Names of spaces of the controlled
transactional locks (for TLOCK
event).
Report Name of the metadata object of the
report being executed (being per-
formed in the background job).
Property name Description
res Describes the action performed by the
licensing system (for LIC event).
Result A check result of the index files relat-
ed to full-text search: 1 - No errors,
0 - There are errors (for the
FTEXTCheckevent).
RetExcp An exception occurred during execu-
tion of the server call and transmitted
to client as a result of call (for CALL
events).
Rows A number of database records re-
trieved.
RowsAffected A number of the modified database
records.
RunAs A process start mode (application or
service).
Sdbl A query text in the 1C:Enterprise
language of the database model.
SearchByMask If set to TRUE or "1", a database
search without the full-text search
results is performed (for
INPUTBYSTRING event).
Separation A division (for FTEXTCHECKevent)
is enabled or not.
SepId An index of the split area if split is
enabled (for FTEXTCHECK event).
ServerComputerName Working server name.
ServiceName The name of a server cluster (for
CLSTR event).
SessionID A session number assigned to the
current thread. If no session has been
assigned to the current thread, a prop-
erty is not added.
Sql SQL statement text.
srcProcessName It is recorded when the overall data
from infobase is retrieved by working
process. A value of the property
ProcessName is the name of the
overall data at the time of its retrieval.
A value of the property
srcProcessName is the name of
Property name Description
the overall data from infobase at the
time of its formation.
SrcURL A preferred address of production
server (for CLSTR event).
SrcVer A version of server cluster status (for
CLSTR event) received.
State A start or end of the update operation
on the full-text search index (for
FTEXTUPD event) has been commit-
ted.
Status HTTP status code (for
VRSRESPONSE events).
SyncPort An auxiliary network port number of
a process.
sz An amount of dynamic memory (in
bytes) taken up by process at the time
MEM event is executed.
szd Change in the amount of dynamic
memory (in bytes) taken up by pro-
cess since the previous MEM event
execution.
t:applicationName ID of a client program.
t:clientID ID of TCP connection with a custom-
er.
t:computerName Name of a client computer.
t:connectID ID of connection with infobase.
Text Text entered when entering by string
(for INPUTBYSTRING event).
Time Time of writing to the technology log
(for FTEXTUPD event).
For the ATTN event, contains the
name of the server process: rmngr or
rphost.
Timeout Depending on the purpose of ATTN
event (Descr property), can describe
the following:
• Period of activity (in seconds)
of the working process deleted
from the cluster registry.
• The timeout (in milliseconds)
for setting up a TCP connection
 Property name Description
with working process.
tooManyResults If set to TRUE or "1", there are too
many links in the index matching the
request; a full-text search is not used
(for INPUTBYSTRING event).
TotalJobsCount A number of background processes
generated during indexing (for
FTEXTUpd event).
Trans ID of the transaction activity at the
start of an event:
• 0 - A transaction has not been
opened;
• 1 - A transaction has been
opened.
Txt Text of informational message.
URI A resource being accessed (for
VRSREQUEST, VRSRESPONSE
events).
UsedSize Size of used storage space in bytes
(for SDGC events).
Usr The infobase user name (if no users
have been defined in the infobase,
this property will be set to DefUs-
er). A property value is taken from
the assigned session.
Val A value, the meaning of which de-
pends on a value of Func.
WaitConnections A list of the connections being collid-
ed with on the managed transactional
locks (for TLOCK and TTIMEOUT
events).
Word A word, if defined (for
FTEXTCheck event).
By using the properties of the item <property>, the execution context
can be recorded in the technology log. The execution context can be: the
embedded 1C:Enterprise language context or the interface context. The em-
bedded 1C:Enterprise language context is a list of the embedded language
statements. It contains:
• The name of a module
• A line number of a module
 • A text presentation of an item from the 1C:Enterprise language call
list of the corresponding module line
The interface context includes:
• The full name of a form
• Type of the active form item
• Name of the active form item
• Name of the command bar button (if pressed)
• Action performed by the form item
For example, a context of the embedded 1C:Enterprise language in the
technological log might look like this:
Document.GoodsReceipt:23: Records.ProductAccounting.Write();
ApplicationModule:18:CheckIdleHandlerConnection(True);
ApplicationModule:230:IfnpGetDefaultValue(mainCurrentUser,"UseRemin
ders");
GeneralModule.npUserSettings:481:Selection=Query.Execute().Select()
;

The interface context in the technological log file might look like this:
{Document.Document1.ListForm}/{TabularField:
ДокументСписок}/{ОбновлениеОтображения}
{Document.Document1.Form.DocumentForm}/{CommandBar:
ОсновныеДействияФормы}/{ОсновныеДействияФормыОК}
{Document.Document1.Form.DocumentForm}/{Button:
Кнопка1}/{Нажатие}

To enable a context record, it is needed to record the item <property

name = "Context"> or the item <property name = "all">
among the property filters.
If you need to record the events SDBL (SDBL-queries) and DBMSSQL
(SQL statements to the MS SQL Server DBMS) with the execution context,
the content of the technological log configuration file will look like this:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="c:\v8\logs" history="1">
<event>
<eq property="name" value="sdbl"/>
</event>
<event>
<eq property="name" value="dbmssql"/>
</event>
<property name="context">
</property>
</log>
</config>

To record the SDBL (SDBL queries) and DBMSSQL events (SQL statements
to the MS SQL Server DBMS) without the execution context, the techno-
logical log configuration file must be filled in, as follows:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="c:\v8\logs" history="1">
<event>
<eq property="name" value="sdbl"/>
</event>
<event>
<eq property="name" value="dbmssql"/>
</event>
</log>
</config>

To record the SDBL (SDBL queries) and DBMSSQL events (SQL statements
to the MS SQL Server DBMS) without execution context but with all other
properties, the configuration file should contain:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="c:\v8\logs" history="1">
<event>
<eq property="name" value="sdbl"/>
</event>
<event>
<eq property="name" value="dbmssql"/>
</event>
<property name="all">
</property>
<property name="context">
<eq property="name" value=""/>
</property>
</log>
</config>

In order to record the SDBL events (SDBL queries) with the execution con-
text and DBMSSQL (SQL statements to the MS SQL Server DBMS) without
the execution context, the content of the configuration file should look like
this:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="c:\v8\logs" history="1">
<event>
<eq property="name" value="sdbl "/>
</event>
<event>
<eq property="name" value="dbmssql"/>
</event>
<property name="context">
<event>
<eq property="name" value="sdbl"/>
</event>
</property>
</log>
</config>

If item <property name = "Context"> is present, it means that

context information will be recorded for the technological log events if the
 conditions specified in this item are met. After that, information about exe-
cution context in current process will be added to each technological log
event, and after the event, an instant event carrying information about the
execution context of client process will be added.
Technological log may contain messages related to the exceptions linked to
the lock manager. For that, a configuration file should look like this:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="c:\v8\logs" history="7">
<event>
<eq property="name" value="excp"/>
</event>
<event>
<eq property="name" value="tlock"/>
<gt property="duration" value="100000"/>
</event>
<property name="all"/>
<property name="context">
<event>
<eq property="name" value=""/>
</event>
</property>
</log>
<dump location="c:\v8\dumps" create="1" type="2"/>
</config>

In the above example, all the exceptions associated with locks will be rec-
orded (in particular, DEADLOCK- interlocks of connections and TIMEOUT-
of a predetermined time, wherein in both cases a number of the connection
that caused this exception) and the periods of waiting exceeding 10 seconds
will be included in the message text about the exception. Wherein infor-
mation about all properties except Context will be recorded.

3.21.2.4.3. The property values of Func

The property Func can take the following values:

Value Description
AcceptPartialIndex Accept partial indexes.
addCopy Adding the database copy (for
DBCOPIES event).
agentAuthenticate Central server administrator au-
thentication.
applyServiceAssociationR Application of the requirements
ules related to functionality assign-
ment.
attach An assignment of the session to a
connection (an event of SESN
Value Description
kind is being output at the moment
of unassignment to a connection of
the session). A duration indicates
how long the session was assigned
to a connection.
authenticateInfoBaseAdmi Authentication of the infobase
n administrator.
authenticateSrvrUser Authentication of a cluster admin-
istrator in working process.
authenticateSrvrUser Authentication of a cluster user in
working server.
authenticateStarter Authentication of a remote central
server.
beginTransaction A transaction starts (an event of
SDBL kind is displayed in the log
at the moment when the said
transaction starts and has no dura-
tion).
busy A session has already been as-
signed to a connection (SESN
event is being output when an at-
tempt is made to assign a session
that has already been assigned to
the connection). Has no duration.
changeInfoBaseParams Infobase parameters change. Serv-
er licensing, external session man-
agement, mandatory external ses-
sion management, security profile,
security profile of the secure
mode.
changeLocale Change in the national database
settings.
CheckIndexes Verification of the full-text search
indexes is being executed.
commitTransaction Transaction commitment.
connect Connection to an external data
source.
continueFillTable Resumption of initial filling in
database copy table (for
DBCOPIES event).
copyMoveFile Copying / moving a fragment of
an application between database
Value Description
table entries.
createFile Create a file.
createInfoBase Create an infobase.
deleteFile Delete a file.
deserializeTable Recovery of data pertained to the
database table from a file.
disconnect Disconnection from the external
data source.
dropInfoBase Delete an infobase.
erase<X> Delete an entry from the security
profile where <X> is:
• Virtual directory -
SecurityProfileVirt
ualDirectory
• External module -
SecurityProfileExte
rnalModule
• Add-in -
SecurityProfileAddI
n
• Internet resource -
SecurityProfileInte
rnetResource
• Application -
SecurityProfileAppl
ication
eraseAgentUser Delete a central server administra-
tor.
eraseIBRegistry Delete a central server cluster.
eraseIBRegistry Delete a cluster.
eraseRegServer Delete a working server.
eraseRegServer Delete a working server.
eraseRegUser Delete cluster administrators.
eraseRegUser Delete a cluster user.
eraseSeance Delete a session.
eraseSecurityProfile Delete a security profile.
eraseServerProcess Delete a working process.
eraseServiceAssociationR Delete a functionality assignment
ule requirement.
fillTable Execution of initial filling in data-
base copy table (for DBCOPIES
event).
Value Description
fillTableBlocksKeyFields Fill in the database copy table by
key values (for DBCOPIES
event).
fillTableBlocksKeyFields Fill in the database copy table con-
TableParts taining reference data (for
DBCOPIES event).
fillTableOne Fill in the database copy table with
one query (for DBCOPIES event).
finish The end of session (an event of
SESN kind is logged at the time of
a session being ended and the
event duration is equal to a dura-
tion of the entire session).
FtextMngrIndexChanges A full-text search index is being
updated in the file mode of in-
fobase.
FtextMngrRHostIndexChang A full-text search index is being
es updated in the client-server mode
of infobase.
get<X> Reading of the full list of security
profiles or their entries where <X>
is:
• Virtual directory -
SecurityProfileVirt
ualDirectory
• External module -
SecurityProfileExte
rnalModule
• Add-in -
SecurityProfileAddI
n
• Internet resource -
SecurityProfileInte
rnetResource
• Application -
SecurityProfileAppl
ication
getAgentUsers Read data on the agent administra-
tors.
getClusterManagers Read the list and parameters of
cluster managers.
getConnections Read the list of connections.
Value Description
GetDataForIndexing Get the list of modified objects to
be included in the full-text search
index
getIBRegistry Read the list and parameters of
clusters.
getInfoBaseParams Read the infobase parameters.
getInfoBases Read a list of infobases.
getObjectLocks Read a list of cluster object locks.
getRegUsers Read data on the cluster adminis-
trators.
getSeances Read a list of sessions.
getServerProcesses Read a list and parameters of
working processes.
getServiceAssociationRul Read a list of functionality as-
es signment rules.
getServicesDistribution Read data on the distribution of
services between cluster manag-
ers.
getServicesInfo Read information about available
cluster services
getTransactionSplitter Get a totals separator.
holdConnection Hold connection.
IndexObjects Perform indexing of a portion of
objects.
initialize Initialize a licensing subsystem
(for LIC events only).
insertAgentUser Creating a central server adminis-
trator.
insertAgentUser Add a central server user.
insertIBRegistry Add a cluster to the central server.
insertIBRegistry Create a cluster.
insertRecords Add a record to the database table.
insertRegServer Add a working server.
insertRegServer Add a working server.
insertRegUser Add a cluster administrator.
insertRegUser Add a cluster user.
insertServerProcess Add a working process.
insertServerProcess Add a working process.
isProperLocale Validate database local settings.
killClient Disconnect a client from
1C:Enterprise cluster server.
lockRecord Locked record.
Value Description
lookupTmpTable Get/create a temporary database
table.
MergeSynchro Merge files with full-text search
indexes.
modifyFile Update a file.
moveFile Move a file.
quickInsert Quick insert of data into a data-
base table.
readFile Read a file.
reFillTable Refill and resume filling in of the
database copy table (for
DBCOPIES event).
regAuthenticate Cluster administrator authentica-
tion.
regAuthenticate Perform cluster authentication.
removeCopy Delete a database copy (for
DBCOPIES event).
restoreObject Restore an object.
resumeIndexing Resume database table indexing.
returnTmpTable Release a temporary database ta-
ble.
rollbackTransaction Cancel a transaction.
saveObject Save an object.
searchFile Search a file.
securedInsert Insert records with restrictions on
data access.
selectFileName Select a file name.
serializeTable Save table data to a file.
setClusterRecycling Change settings for restarting the
cluster working processes (except
for fault tolerance level).
setFaultToleranceLevel Change the cluster fault tolerance
level.
setInfoBaseConnectingDen Change infobase session start
y blocking parameters.
setInfoBaseConnectingDen Set locking mode for establishing
y connections with infobase.
setInfoBaseDescr Change description of an infobase.
setInfoBaseDescr Set description of an infobase.
setInfoBaseScheduledJobs Change infobase scheduled job
Deny locks.
setRegDescr Change description of a cluster.
Value Description
setRegDescr Set description of a cluster.
setRegMultiProcEnable Enable support of multiple work-
ing processes for a cluster.
setRegSecLevel Change level of the secure cluster
connection.
setRegSecLevel Set level of the secure cluster con-
nection.
setRollbackOnly Set a flag indicating errors in
transaction (such transaction can
only be rolled back).
setSecurityProfile Create or modify a security pro-
file.
setSecurityProfileAddIn Create/modify an entry in the se-
curity profile (add-in).
setSecurityProfileApplic Create/modify an ntry in the secu-
ation rity profile (application).
setSecurityProfileComCla Create/modify an entry in the se-
ss curity profile (COM class).
setSecurityProfileExtern Create/modify an entry in the se-
alModule curity profile (external module).
setSecurityProfileIntern Create/modify an entry in the se-
etResource curity profile (Internet resource).
setSecurityProfileVirtua Create/modify an entry in the se-
lDirectory curity profile (virtual directory).
setServerProcessCapacity Set throughput capacity of a work-
ing process.
setServerProcessCapacity Set performance capacity of a
working process.
setServerProcessEnable Set flag indicating that a working
process is allowed to start.
setServerProcessEnable Set status of a working process.
setServiceAssociationRul Create or modify a functionality
e assignment rule.
setSingleUser Set exclusive mode.
setSrcProcessName Create common infobase data in a
working process and assign a
common name to this data. An
event is recorded when the first
user connects to infobase through
this working process or when per-
forming a dynamic update of the
infobase configuration.
Value Description
setTableState Change the state of the database
copy table (for DBCOPIES
event).
start Start a session (an event of SESN
type is logged at the time when a
session starts and has no duration).
suspendIndexing Cancel indexing of database ta-
bles.
takeKeyVal Get a value of a tabular section
record key.
transaction Start a transaction (an event of
SDBL type starts at the beginning
of a transaction, ends when it is
finished).
transferChangesTable Transfer changed objects to the
database copy (for DBCOPIES
event).
transferTrLogs Transfer transaction logs to the
database copy (for DBCOPIES
event).
updateCopyContent Change content of the database
copy tables (for DBCOPIES
event).
updateCopyProperties Change parameters of a database
copy (for DBCOPIES event).
updateRegServer Modify parameters of a working
server.
updateTimeIsOver Completion of the database copy
update (for DBCOPIES event).
wait Wait for an assignment (an event
of SESN type is output when wait-
ing period of assigning a session
to a connection is finished). Dura-
tion of an event is equal to the
time spent while waiting for a
connection. If a connection is as-
signed with a session which has
already been assigned, then the
current thread of the current con-
nection is waiting for cancellation
of the session assignment to an-
other connection.
 Value Description
xlockTables Set an exclusive lock on a table.
xlockTablesShared Set a shared lock on a table.

3.21.2.4.4. Description of the res property for

the LIC event
Can take values:
• seize - New license is booked.
• reuse - A license that had previously been taken is reused. If the
res property is set to seize or reuse, then the txt property con-
tains the following information:
 An array with the numbers of received licenses.
 License recipient:
 local Designer
 local application
 A unique ID for a session or server receiving license.
 An ID of license if it has been received.
 A kind of a license requested:
 local Designer - Designer
 local application - Client application
 local COM connector 32 - 32-bit COM connection
 local COM connector 64 - 64-bit COM connection
 local server 32 - 32-bit 1C:Enterprise server
 local server 64 - 64-bit 1C:Enterprise server
 remote application - Any 1C:Enterprise application on
a remote computer
 Information on the viewed license keys or license files:
 For the hardware licenses:
 hard
 A local or network key used
 Key series: client, client 300, client 500,
server 32, server 64.
 Why a license has not been received:
 not available - does not exist (en error detected in the
program interface of working with the keys HASP);
 no licenses left - All licenses have run out;
 no slots left - All licenses have run out;
 absent - A work with a key that is no longer available, is
attempted. For example, it has already been removed from a
computer.
  local and single key is already used - An
attempt to obtain an already occupied license from a local
single-user key has been made.
 A number of licenses (if information is available);
 How many licenses have already been received (if this infor-
mation is available)
 For the software licenses:
 soft
 Name of the activated license file
 Reason for a denial of a license:
 stop list- A license file is blacklisted;
 bad format - Incorrect file format;
 bad signature - The Licensing Center signature is in-
valid;
 second server lite - Re-license for MINI server;
 binding error - Binding error;
 incorrect license type - A license of incorrect
kind;
 no licenses left - All licenses have run out;
 exception (exception text) - Other exception.
 An option of the Licensing Center Signature
 Short - For a license received by phone;
 Long - For licenses received on media or via Internet.
 License registration number
 License activation PIN code
 License type
 Maximum number of users
 Supporting information
 Differences in the list of equipment:
 For the software licenses activated for version 8.2.14 and
earlier:
 Added in current computer configuration- List of
equipment that is currently available but was not availa-
ble at the moment of obtaining the license.
 Available at license acquisition time - List of equip-
ment that was available at the moment of obtaining the
license.
 For the software licenses activated for version 8.2.15 and
later:
 Removed after license acquisition - List of equip-
ment that is currently not available but was available at
the moment of obtaining the license.
  Available in current computer configuration - List of
equipment that is currently available but was not availa-
ble at the moment of obtaining the license. Only if such
equipment does exist
 If a license is acquired, the following data about a key or the soft-
ware license is provided:
 For the hardware licenses:
 Dongle series
 Key type
 Number of licenses
 Number of licenses taken after acquiring the current license
 For the software licenses:
 Name of the activated license file
 License type
 Number of licenses
 A number of licenses taken after receiving the current one.
• release - A release of license. In this case, the txt property con-
tains the following information:
 for the software licenses:
 The internal unique ID of the object of the license being re-
leased
 Creation time of the object of the license being released
 Recipient of the license
 License being released client, server32, server64,
server lite
 Supporting information
 for the hardware licenses:
 The internal unique ID of the object of the license being re-
leased
 Creation time of the object of the license being released
 Recipient of the license
 Supporting information about a key.
• binding - Verification of compliance of the current list of equip-
ment to the list that was used when activating a soft license. When a
mismatch found is critical for a license binding, the txt property
contains the following information:
 Computer binding parameter changed
 For each license file that stops working because of the current
computer parameters, the following information is displayed:
 name of the activated license file
 license registration number
 license activation pin code
 license type
  maximum number of users
 differences in the list of equipment:
 For the software licenses activated for version 8.2.14 and
earlier:
 Added in current computer configuration- List of
equipment that is currently available but was not availa-
ble at the moment of obtaining the license.
 Available at license acquisition time - List of equip-
ment that was available at the moment of obtaining the
license.
 For the software licenses activated for version 8.2.15 and
later:
 Removed after license acquisition - List of equip-
ment that is currently not available but was available at
the moment of obtaining the license.
 Available in current computer configuration - List of
equipment that is currently available but was not availa-
ble at the moment of obtaining the license.
• error - An error occurred while accessing the licensing mechanism.
• must be removed - the file with license is not used and must be
deleted.

3.21.2.4.5. Descr property description

Descr property content depends on the event accommodating the said
property:
• Contains the event description for ATTN event. Depending on the
event the technological log records contains different set of properties:
 Abandoned process was alive too long time - process stopped
responding. The following properties are available: agentURL,
procURL, PID, Name, Timeout.
 Process excess memory limit - process exceeded the memory
limits. The following properties are available: agentURL,
procURL, PID, Name, MemSize, MaxMemSize.
 Process has generated too big amount of exceptions - the
number of errors or exceptions generated by the process is too big.
The following properties are available: agentURL, procURL,
PID, Name, CurExceptions, AvgExceptions.
 Process not respond - process does not respond. The following
properties are available: agentURL, procURL, PID, Name,
Timeout, Attempts.
  Process will be killed - process will be forcefully terminated. The
following properties are available: agentURL, procURL, PID,
Name.
• Contains performed operation description for SRVC event. The prop-
erty text for this event has the following format: <ServiceName>[,
<InfobaseName>[, <SessionID>]]: <Action>, where:
 <ServiceName> - the service, which the operation is performed
on,
 <IBName> - infobase name,
 <SessionID> - unique session ID,
 <Action> - description of the action, performed on the cluster ser-
vice:
 service notified <notification name> <parameters> - the
service receives notification of cluster event,
 service started - service instance creation,
 service finished - service instance release.
• Contains the operation description (in English) for WINCERT event.
This description allows for identifying a call to the Windows API
function and restoring the state of environment at the time of a call.
The following message options are possible:
 CertGetCertificateChain failed- Error in building the certificate
chain. If such an error occurs, you need to analyze the error code
(the errorCode property ). It is possible that the default crypto-
provider does not support the algorithm of certificate encryption.
To search for information about errors, the Microsoft Internet re-
sources are recommended.
 CertVerifyCertificateChainPolicy failed-Error in the certification
chain verification involving policies. If such an error occurs, you
need to analyze the error code (the errorCode property ). A cer-
tificate might have been revoked, certain certificates in the chain
might be missing, etc. To search for information about errors, the
Microsoft Internet resources are recommended.

3.21.2.4.6. Event property description

Event property values and an array of properties to be additionally set in
this event are listed in this section:
• distrib obsolete- Cache of assignments of the cluster functionality in
the current working process has been obsoleted.
• current version older- An active instance of service re-
ceived replication with the new version of service state which should
become a backup;
• current version newer- An active instance of service re-
ceived replication with the obsolete version of service state and reject-
ed it.
For a CLSTR event with the Event property is equal to one of the
above mentioned values, the following event properties make sense:
 MyVer - A current version of service status;
 NeedResync - A synchronization of service data (for the current
version older event) is required.
 Ref - The name of infobase;
 ServiceName - The name of a cluster service;
 SessionID - A session number;
 SrcVer - The acquired version of service status;
• service assign require - Service is unavailable, reassignment
is required. For a CLSTR event for which the Event property is equal
to this value, the following event properties make sense:
 Ref - The name of infobase.
 ServiceName - The name of a cluster service;
• working process not found - No working process was found for a
connection to infobase. For a CLSTR event for which the Event
property is equal to this value, the following event properties make
sense:
 ApplicationExt - clarification of the functionality assignment
rule.
 Ref - The name of infobase;
 SrcURL - preferred address of a working process;
• process unavailable - A working process cannot be used for connec-
tion to infobase. For a CLSTR event for which the Event property is
equal to this value, the following event properties make sense:
 ConnLimit - Determined maximum number of connections per
working process.
 IBLimit - Determined maximum number of infobases per
working process;
 Reason - describes the reason of unavailability of a working pro-
cess:
 ConnLimit - A maximum number of connections per working
process has been reached.
 IBLimit - a maximum number of infobases per working process
has been reached.
• data replication start - Start replicating data from the current active
instance of service to a backup instance. For a CLSTR event for which
the Event property is equal to this value, the following event proper-
ties make sense:
  Ref - The name of infobase;
 ServiceName - the name of a server cluster service;
 SessionID - A number of session
• destination version older - Replication was moved to the active in-
stance of service with the obsolete version of service state;
• destination version newer - Replication was moved to the active in-
stance of service with the new version of service state, replication
was rejected and the current service should become backup.
For a CLSTR event with the Event property is equal to one of the
above mentioned values, the following event properties make sense:
 Ref - The name of infobase;
 ServiceName - the name of a server cluster service;
 SessionID - A number of session
• finish replication - A replication is finished. For a CLSTR event for
which the Event property is equal to this value, the following event
properties make sense:
 Ref - The name of infobase;
 ServiceName - the name of a server cluster service;
 SessionID - A number of session
• register rphost - A registration of the cluster working processes.
• register rmngr - A registration of cluster managers.
• unregister rphost - Unregistering of the cluster working processes.
• unregister rmng - Unregistering of the cluster managers.
main rmngr is down - Error in calling the cluster service on the main
manager. The working process is to be finished. For a CLSTR event
for which the Event property is equal to this value, the following
event properties make sense:
 ServiceName - The name of the service upon calling on which
it was discovered that the main cluster manager is unavailable.

3.21.2.4.7. Txt property description

Textproperty content depends on the event accommodating the said prop-
erty:
• For the HASP event, this property contains a source data and the result
of accessing the key in the following format: <Operation>(<List of
input parameters>)-><List of output parameters>. Further:
 <Operation> - An operation performed in this key reference.
 <List of input parameters>- A list of the input parameters and
their values separated by commas.
 <List of output parameters> - A list of the output parameters
and their values separated by commas.
 A full list of operations, their parameters, and results is contained in
the book HASP developer guide
http://sentineldiscussion.safenet-
inc.com/viewFile.do?fileId=43161000000036014&forumGroupId
=43161000000003001).
• For the event CLSTR, this property contains the values of the parame-
ters involved in calculating the available performance of working pro-
cess: Parameter:Value, separated by a space.
• For the event CONN, this property contains a description of this or an-
other event within the borders of the system of monitoring disconnec-
tion. A property value looks like: ‘EventName: Parame-
ter1=Value1,Parameter2=Value2,…’. The following system events
have been defined:
 Ping direction opened -A new direction of verification in the cli-
ent process has been emerging.
Parameters:
 address: String. Direction address.
 pingTimeout: Number. Verification timeout.
 pingPeriod: Number. Verification period.
 directionID: UUID. The direction ID.
 Ping direction closed - Completion of verification in the direction
of the client process.
Parameters:
 address: String. Direction address.
 pingTimeout: Number. Verification timeout.
 pingPeriod: Number. Verification period.
 Connection established for ping direction - The TCP connec-
tion has been established to verify the client process.
Parameters:
 address: String. Direction address.
 pingTimeout: Number. Verification timeout.
 pingPeriod: Number. Verification period.
 Ping direction switched to TCP mode - A verifying stream on
the client process has been switched to the TCP-based verification
mode.
Parameters:
 address: String. Direction address.
 pingTimeout: Number. Verification timeout.
 pingPeriod: Number. Verification period.
 Ping direction not available - A timeout occurred in the direction
of verification on the client process.
Parameters:
  address: String. Direction address.
 pingTimeout: Number. Verification timeout.
 pingPeriod: Number. Verification period.
 Ping direction available - A verification direction on the client
process has become available again.
Parameters:
 address: String. Direction address.
 pingTimeout: Number. Verification timeout.
 pingPeriod: Number. Verification period.
 Connection added to ping direction - Another connection has
become associated with this verification direction.
Parameters:
 address: String. Direction address.
 pingTimeout: Number. Verification timeout.
 pingPeriod: Number. Verification period.
 clientID: Number. A connection number associated with a
verification direction.
 Connection removed from ping direction - A connection has
ceased to be associated with this verification direction.
Parameters:
 address: String. Direction address.
 pingTimeout: Number. Verification timeout.
 pingPeriod: Number. Verification period.
 clientID: Number. A connection number associated with a
verification direction.
 Ping direction statistics - Statistics on the verification direction.
It is displayed in each direction every 10 seconds and before com-
pleting a directional verification.
Parameters:
 address: String. Direction address.
 pingTimeout: Number. Verification timeout.
 pingPeriod: Number. Verification period.
 period: Number. Time in milliseconds spent to collect sta-
tistical data.
 packetsSent: Number. A number of packets sent.
 avgResponseTime: Number. An average response time.
 maxResponseTime: Number. A maximum response time.
 packetsTimedOut: Number. Packets not responded to be-
fore timeout.
 packetsLost: Number. Number of packets not responded
to but not yet timed out.
  packetsLostAndFound: Number. A number of responses
received on packets sent but not taken into account.
 Connection added to ping direction on server - One more
connection has become corresponding to a verification direction
on server process.
Parameters:
 directionID: UUID. The direction ID.
 clientID: Number. A connection number associated with a
verification direction.
 address: String. Direction address.
 Connection removed from ping direction on server - One con-
nection has ceased to correspond to a verification direction on
server process.
Parameters:
 directionID: UUID. The direction ID.
 clientID: Number. A connection number associated with a
verification direction.
 Ping direction opened on server - A new verification direction
appeared on server process.
Parameters:
 directionID: UUID. The direction ID.
 Ping direction closed on server - A verification direction has
ceased to exist on server process
Parameters:
 directionID: UUID. The direction ID.
 Ping direction not available on server - Timeout has been de-
tected in a verification direction on server process.
Parameters:
 directionID: UUID. The direction ID.
 Ping direction settings changed on server - A verification pe-
riod and verification timeout have been transferred to a verification
direction on server process.
Parameters:
 directionID: UUID. The direction ID.
 pingTimeout: Number. Verification timeout.
 pingPeriod: Number. Verification period.

3.21.2.5. <dump>
The item <dump> defines the parameters of dump created when an applica-
tion crashes. To disable dump recording, set create = "0" or create
= "false" in the item <dump>. If <dump> is absent, the directory
%USERPROFILE%\Local Settings\Application Data\1C \ 1cv8\dumps
(for Windows) will be used to record the dumps.
IMPORTANT! For Linux and macOS, dumps generation settings are gov-
erned by OS. Therefore, the item <dump> is ignored.
The item attributes:
location Windows
The name of a directory in which the dump files will be placed.
NOTE. Different directories must be specified in the location attributes
of the <log>, <dump> and <defaultlog> items.

create Windows
Create or not create a dump file.
• 0 (false) - do not create
• 1 (true) - create
type Windows
Dump type – an arbitrary combination of the following check boxes, repre-
sented in decimal or hexadecimal system (addition of check box values). A
hexadecimal representation must begin with a ‘x’ character; for example,
x0002.
The following values are available:
• 0 (x0000)- Minimum;
• 1 (x0001) -Additional data segment;
• 2 (x0002) -A content of the entire memory of a process;
• 4 (x0004) - Data handles;
• 8 (x0008) - Leave in dump only information needed to restore the
server call stacks;
• 16 (x0010) - If stack contains references to the modules' memory, then
add the check box 64 (0x0040);
• 32 (x0020) - To include memory from under the unloaded modules
into dump;
• 64 (0x0040) - To include memory to which there are links to dump;
• 128 (x0080) - To add detailed information about the module files to
dump;
• 256 (0x0100) - To add local stream data to dump;
• 512 (0x0200) - Inclusion of memory from the entire available virtual
address space in dump.
TIP. For most cases, it is sufficient to use 3 as the value of type attribute,
for example, type = "3".
prntscrn Windows
Indicates whether to save a screenshot when 1C:Enterprise client crashes.
The file name is the same as the dump name but has extension png. The
screen copy files are created in the same directory as dumps (see the
location attribute).
• 0 (false) - Do not create
• 1 (true) - Create
In case of emergency termination of the “1C: Enterprise” program, the sys-
tem issues a dialog with information about the dump recording process
which is automatically closed after the dump recording is completed.
externaldump Windows
Controls generation of a crash dump if 1C:Enterprise is running on Win-
dows. The attribute can take the following values:
• 0 (false) - A dump is generated by a process that crashes (a default
value).
• 1 (true) - A dump is generated by the external application dump-
er.exe which is included in the 1C: Enterprise delivery package.
When an external program is being used, a possibility of hanging in
the process of creating dump is excluded.
If an external program is not detected or some problems are detected during
its launch, standard mode for creating dumps (using a crashing process) will
be used.
It is recommended to use an external program of generating dumps for
1C:Enterprise servers that work without daily maintenance.

3.21.2.6. <leaks>
The <leaks> item establishes tracking of memory leaks caused by issues
in configuration code. By default, leak tracking is disabled and it does not
affect the system performance.
In order to enable the leakage data collection, add the item <leaks> to the
logcfg.xml file: <leaks collect="1"> or <leaks
collect="true">.
To disable memory leak tracking, the <leaks> item should be changed:
<leaks collect="0"> or <leaks collect="false">.
If a leak tracking is enabled, then creation and deletion of the following
objects is controlled by user:
• Form
• ManagedForm
• FixedStructure
• FixedMap
• StructureFormData
• CollectionFormData
• StructureWithCollectionFormData
• CollectionItemFormData
• TreeFormData
• TreeItemCollectionFormData
• TreeItemFormData
• AccountingRegisterManager
• AccountingRegisterRecordSet
• ChartOfAccountsManager
• ChartOfAccountsObject
• ExchangePlanManager
• ExchangePlanObject
• SettingsStorageManager
• AccumulationRegisterManager
• AccumulationRegisterRecordSet
• ChartOfCharacteristicTypesManager
• ChartOfCharacteristicTypesObject
• ConstantManager
• DocumentManager
• DocumentObject
• EnumerationManager
• ExternalDataProcessor
• ExternalReport
• InformationRegisterManager
• InformationRegisterRecordSet
• DataProcessorManager
• DataProcessor
• CatalogManager
• CatalogObject
• ReportManager,
• Report
• SequenceRecordSet
• BusinessProcessManager
• BusinessProcessObject
• TaskManager
• TaskObject
• ChartOfCalculationTypesManager
• ChartOfCalculationTypesObject
• CalculationRegisterManager
 • CalculationRegisterRecordSet
• RecalculationRecordSet
• COMSafeArray
• KeyAndValue
• Array
• FixedArray
• Map
• Structure
• ValueListItem
• ValueList
• ValueTable
• ValueTableRow
• ValueTree
• ValueTreeRow
Leaks are tracked between the start and end checkpoints in the code. The
start checkpoint clears leak data for a current user. At the end checkpoint,
the LEAKS event is generated and written to the technological log in which
for each unreleased object instance the stack of the embedded 1C:Enterprise
language will be indicated at the time of its creation.
The following can be used as checkpoints:
• The beginning and end of the execution of 1C:Enterprise language
commands on the client or server
• Calling a procedure or function of the 1C:Enterprise language and re-
turning from the procedure or function
• Starting execution of one line of 1C:Enterprise language and finishing
execution of another line of 1C:Enterprise language
The starting and ending checkpoint is defined by the item <point>. In this
case, the embedding of checkpoints into each other is allowed but being
ignored-; a counting of leaks is carried out only on the external checkpoints.
For example, if during the execution of the configuration code the check-
points of Starting1, Starting2, Ending1, Ending2 were passed, then the
leaks will be tracked between the points Starting1 and Ending2.
The item <point> can have one of the following formats:
<point call=«client»/>, <point call=«server»/>
Defines checkpoint at the beginning/end of the execution of the embedded
1C:Enterprise language on client or on server, i.e .: The starting point will
be set at the beginning of the embedded 1C:Enterprise language execution
on server/client; the ending point - at the end of the embedded
1C:Enterprise language execution on server/client.
 <proc="<ModuleName>/<MethodName>"/>
Defines checkpoints when calling and returning a specific embedded
1C:Enterprise language method. <ModuleName> -contains the full name
of the metadata object to which the module belongs (without a configura-
tion name). In the same format, the debugger shows the module names.
<MethodName> contains the name of method. If the <MethodName>
argument is not set, then the checkpoints will be defined at the begin-
ning/ending of the module body execution. Examples of module names:
• SessionModule.Module - session module
• ApplicationModule.Module- application module
• ManagedApplicationModule.Module - Module of managed
application
• ExternalConnectionModule.Module - Module of external
connection
• CommonModule.Global.Module - Common module Global
• Catalog.Contractors.ObjectModule - Module of Counter-
parties catalog item
• Processing.Processing1.Form. Form1.Form -Form
module Form1 of processing Processing1 ;
• Processing.Processing2.Form. MainForm.Form -
module form . Processing Mainform . Processing2.
<point on="<ModuleName>/<LineNumber>" Off="<ModuleN
ame>/<LineNumber>"/>
Defines the starting and ending checkpoints by explicitly specifying the
lines of code. The starting checkpoint corresponds to the beginning of exe-
cution of code for the string specified in the attribute On. The ending
checkpoint corresponds to the end of the execution of code for the string
specified in the attribute Off. Line numbering starts with 1. If the starting
checkpoint is reached on server, then the ending checkpoint must be
reached on server, as well. The ending checkpoint cannot be the last string
of the procedure code, function or module body.
An example of item <leaks>:
<leaks collect="1">
<point call="client"/>
<point call="server"/>
<point proc="ApplicationModule/"/>
<point
proc="CommonModule.ConnectionProcessing.Module/AtServerNoLeaks"/>
<point on="CommonModule.Services.Module/9"
off="CommonModule.Services.Module/11"/>
</leaks>

In this case, leak data collection is enabled. The checkpoints are set:
 • At the beginning and at the end of execution of 1C:Enterprise lan-
guage on client
• At the beginning and at the end of execution of 1C:Enterprise lan-
guage on server
• At the beginning and at the end of execution of the application module
body
• When calling and returning method AtServerNoLeaks() from the
common module ConnectionProcessing
• On lines 9 and 11 of the common module Services
Suppose a procedure with the following text causes a memory leak:
Procedure AtServerWithLeak() Export
M=NewArray;
M.Add(NewArray);
M[0].Add (NewArray);
M[0][0].Add(M);
EndProcedure

To detect it, leak tracing in the technological log can be enabled using the
following settings:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\ProgramFiles\1cv8\logs" history="24">
<event>
<eq property="name" value="call"/>
</event>
<event>
<eq property="name" value="leaks"/>
</event>
<property name="all">
</property>
</log>
<leaks collect="1">
<point call="server"/>
</leaks>
</config>

When server is called or a routine tasks is performed, if there is no leak, a

fragment of the technological log will look like this:
59:44.4562-
2840,CALL,5,process=rphost,p:processName=t76346,t:clientID=428,t:ap
plicationName=JobScheduler,Func=Execute,Module=CommonModule2,Meth=S
cheduledTaskNoLeak

59:49.4581-
2700,CALL,5,process=rphost,p:processName=t76346,t:clientID=430,t:ap
plicationName=JobScheduler,Func=Execute,Module=CommonModule2,Meth=S
cheduledTaskNoLeak

And if a leak occurs, the log will look like this:

59:48.4768-
2885,CALL,5,process=rphost,p:processName=t76346,t:clientID=429,t:ap
plicationName=JobScheduler,Func=Execute,Module=CommonModule2,Meth=S
cheduledTaskWithLeak

59:48.4769-0,LEAKS,5,process=rphost,Descr='

Array:

CommonModule.CommonModule2:2:AtServerWithLeaks();

CommonModule.CommonModule1:4:M[0].Add(NewArray);

Array:

CommonModule.CommonModule2:2:AtServerWithLeaks();

CommonModule.CommonModule1:2:M=NewArray;

Array:

CommonModule.CommonModule2:2:AtServerWithLeaks();

CommonModule.CommonModule1:3:M.Add(NewArray);

In the above fragment, when method ScheduledJobWithLeak() of

module CommonModule2 is executed as a scheduled job (t:
applicationName = JobScheduler, Func = Execute) , the
three Array objects were created and not released. In
this case, 1C:Enterprise language call stacks at the time of creation of each
object are indicated.

3.21.2.7. <mem>
If the item <mem> is present, 1C:Enterprise server processes monitor:
• Number of allocated and not released fragments of memory
• Total size of allocated and not released memory fragments
If between the moments when the server process was not performing either
any calls and any routine task, the number of allocated but not released
memory fragments increased, then a MEM event is generated with the fol-
lowing properties:
• sz - A total number of memory fragments allocated but not released
by process;
• szd - its modification since the previous output of the MEM event;
• cn - An overall number of the memory fragments, allocated but not
released by process;
 • cnd - its modification since the previous output of the MEM event.
A duration of the MEM event is equal to the period between the last and pe-
nultimate moments when the server process was not performing any calls
and any routine tasks. It was during this time that the number of memory
fragments used by process increased.
IMPORTANT! Specifying the item <mem> in the configuration file of the
technology log does somewhat reduce performance of 1C:Enterprise, espe-
cially when several users work concurrently.
For example, with the following configuration, a volume of distributed
memory is not collected and the MEM events are not being output:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\ProgramFiles\1cv8\logs" history="24">
<event>
<eq property="name" value="mem"/>
</event>
<property name="all"/>
</log>
</config>

The following configuration of the technological log collects the volume of

distributed memory and, as it grows, displays the MEM events:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\ProgramFiles\1cv8\logs" history="24">
<event>
<eq property="name" value="mem"/>
</event>
<property name="all"/>
</log>
<mem/>
</config>

3.21.2.8. <ftextupd>
The <ftextupd> item includes generation of the extended information
about the process of updating the full-text search indexes (the event
FTETXUpd). If the item is not in file, then the extended information is not
included in the technological log.
The item attributes:
logfiles
A presence of extended information in the FTEXTUpdevent:
• 0 (false) - do not include
• 1 (true) - include
 3.21.2.9. <query>
The <query> item controls placing information to the technological log
about fields that contain NULL when executing a request to an external data
source but for which such a value is not allowed (the QERR event). The en-
abling of such tracking can significantly reduce the execution of requests.
The item attributes:
checkActualNullable:
Manages a collection of information:
• 1 (true) - a field information will be collected.
• 0 (false) or the item query is missing in the file-no field infor-
mation is collected.

3.21.2.10. <plansql>

3.21.2.10.1. General description

If <plansql> is present, a collection of the query plans will be included
that generate the DBMS when performing 1C:Enterprise queries. The query
plans are located in the planSQLText property of the events related to
execution of the requests of a specific DBMS.
TIP. It is recommended along with the <planSQLText> property to in-
clude in a list of the registered properties the <SQL> property containing a
query whose plan will be registered.

<?xml version="1.0"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="c:\log" history="2
<event>
<eq property="name" value="dbmssql"/>
</event>
<property name="sql"/>
<property name="plansqltext"/>
</log>
<plansql />
</config>

In the example above, for Microsoft SQL Server (expression <eq

property = "name" value = "dbmssql"/> ), a collection of
query plans (<plansql/> item) is enabled and they are written into the
technology log (expression <property name = "plans-
qltext"/>) together with the texts of queries themselves (expression
<property name ="sql"/>) in the query language of 1C:Enterprise.
IMPORTANT! Receiving query plans slows down execution of database
queries. For some databases, this slowdown can be significant. Query plans
in the normal 1C:Enterprise operating mode should not be retrieved. Query
plans should be collected only when analyzing query performance.
NOTE. Retrieving query plans for external data sources (the event
<EDS>) is possible only if IBM DB2, Microsoft SQL Server, Oracle Data-
base, PostgreSQL act as DBMS of an external data source. For other
DBMS, query plans are not retrieved; only the query text is recorded in the
technology log.

3.21.2.10.2. Information on the DBMS query

plans
Information on working with specific DBMS query plans is provided in the
documentation for these DBMS:
• Microsoft SQL Server 2000:
 http://msdn.microsoft.com/en-
us/library/aa178417(v=SQL.80).aspx
 http://msdn.microsoft.com/en-
us/library/aa259207(v=SQL.80).aspx
 http://msdn.microsoft.com/en-us/library/Aa259203.aspx
• Microsoft SQL Server 2005:
 http://msdn.microsoft.com/en-
US/library/ms176005(v=SQL.90).aspx
 http://msdn.microsoft.com/en-
us/library/ms187735(SQL.90).aspx
• Microsoft SQL Server 2008:
 http://msdn.microsoft.com/en-
us/library/ms176005(v=SQL.100).aspx
 http://msdn.microsoft.com/en-
us/library/ms187735(v=SQL.100).aspx
• Microsoft SQL Server 2008 R2:
 http://msdn.microsoft.com/en-
us/library/ms176005(v=SQL.105).aspx
 http://msdn.microsoft.com/en-
us/library/ms187735(v=SQL.105).aspx
• Microsoft SQL Server 2012:
 http://msdn.microsoft.com/en-
us/library/ms187735(v=SQL.11).aspx
• PostgreSQL 8.1 Windows/Linux:
 http://www.postgresql.org/docs/8.1/static/performance-
tips.html
• PostgreSQL 8.2 Windows/Linux:
  http://www.postgresql.org/docs/8.2/static/using-
explain.html
• PostgreSQL 8.3 Windows/Linux:
 http://www.postgresql.org/docs/8.3/static/using-
explain.html
• PostgreSQL 8.4 Windows/Linux:
 http://www.postgresql.org/docs/8.4/static/using-
explain.html
• PostgreSQL 9.0 Windows/Linux:
 http://www.postgresql.org/docs/9.0/static/using-
explain.html
• PostgreSQL 9.1 Windows/Linux:
 http://www.postgresql.org/docs/9.1/static/using-
explain.html
• PostgreSQL 9.2 Windows/Linux:
 http://www.postgresql.org/docs/9.2/static/using-
explain.html
• PostgreSQL 9.3 Windows/Linux:
 http://www.postgresql.org/docs/9.3/static/using-
explain.html
• PostgreSQL 9.4 Windows/Linux:
 https://postgrespro.com/docs/postgresql/9.4/using-
explain.htmlhttps://postgrespro.ru/docs/postgresql/9.4/using-
explain.html
• PostgreSQL 9.6 Windows/Linux:
 https://postgrespro.com/docs/postgresql/9.6/using-
explain.htmlhttps://postgrespro.ru/docs/postgresql/9.6/using-
explain.html
• PostgreSQL 10 Windows/Linux:
 https://postgrespro.com/docs/postgresql/10/using-
explainhttps://postgrespro.ru/docs/postgresql/10/using-explain
• Postgres Pro Standard 10 Windows/Linux:
 https://postgrespro.ru/docs/postgrespro/10/using-explain.
• Postgres Pro Enterprise 9.6 Windows/Linux:
 https://postgrespro.com/docs/postgresproee/9.6/using-
explainhttps://postgrespro.ru/docs/postgresproee/9.6/using-explain
• Postgres Pro Enterprise 10 Windows/Linux:
 https://postgrespro.ru/docs/postgresproee/10/using-explain.
• IBM DB2 9.1 Windows/Linux:
 http://publib.boulder.ibm.com/infocenter/db2luw/v9/topic/c
om.ibm.db2.udb.admin.doc/doc/c0005739.htm
  http://publib.boulder.ibm.com/infocenter/db2luw/v9/topic/c
om.ibm.db2.udb.admin.doc/doc/r0008441.htm
• IBM DB2 9.5 Windows/Linux:
 http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/
com.ibm.db2.luw.admin.explain.doc/doc/r0052023.html
 http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/
com.ibm.db2.luw.admin.perf.doc/doc/c0005739.html
 http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/
com.ibm.db2.luw.sql.ref.doc/doc/r0008441.html
• IBM DB2 9.7 Windows/Linux:
 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index
.jsp?topic=/com.ibm.db2.luw.admin.explain.doc/doc/r00520
23.html
 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index
.jsp?topic=/com.ibm.db2.luw.admin.perf.doc/doc/c0005739.
html
 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/
com.ibm.db2.luw.sql.ref.doc/doc/r0008441.html
• Oracle DB2 10g R2:
 http://download.oracle.com/docs/cd/B19306_01/server.102/
b14211/optimops.htm
• Oracle DB2 11g R1:
 http://download.oracle.com/docs/cd/B28359_01/server.111/
b28274/optimops.htm
• Oracle DB2 12c R1:
 http://docs.oracle.com/database/121/TGSQL/tgsql_optcncpt.
htm.
For PostgreSQL and Oracle Database, the format of a query plan exactly
matches the format described in the documentation for a respective DBMS.
The format of query plans for Microsoft SQL Server and IBM DB2 is sim-
plified relative to original format. The original field names are saved. In-
formation in these fields is interpreted in accordance with the information
on a specific DBMS. These changes are reflected in the following sections.

3.21.2.10.3. The MS SQL Server query plan

format
A field planSQLText for Microsoft SQL Server consists of several rec-
ords (lines), each of which consists of the following fields (in DBMS terms)
going in the order of description:
• Rows
• Executes
 • EstimateRows
• EstimateIO
• EstimateCPU
• AvgRowSize
• TotalSubtreeCost
• EstimateExecutions
• StmtText
The fields are separated by commas. The last field describing a query plan
(StmtText) should be read to the end of the line ignoring the possible
characters ",". The lines are separated by line breaks.

3.21.2.10.4. IBM DB2 query plan format

The field planSQLText for IBM DB2 consists of several records (lines),
each of which consists of the following fields exposed in descending order.
The field names correspond exactly to the fields from the explain tables, i.e.
the text IO_COST (EXPLAIN_OPERATOR) means that the IO_COST field
from the explain table EXPLAIN_OPERATOR will be placed in the query
plan:
• OPERATOR_TYPE (EXPLAIN_OPERATOR)
• TOTAL_COST (EXPLAIN_OPERATOR)
• STREAM_COUNT (EXPLAIN_STREAM)
• IO_COST (EXPLAIN_OPERATOR)
• CPU_COST (EXPLAIN_OPERATOR)
• COMM_COST (EXPLAIN_OPERATOR)
• BUFFERS (EXPLAIN_OPERATOR)
• PREDICATE_TEXT (EXPLAIN_PREDICATE)
The fields are separated by commas. The last field describing a query plan
(PREDICATE_TEXT) should be read to the end of line ignoring any com-
mas. The lines are separated by line breaks.
At the end of a query plan description, a line is added that starts with the
text Optimized query:; it contains a query text generated by the
DBMS optimizer. The original query text is given in the SQL event of the
technological log. A query ends with the end-of-line character. IDs from the
optimized query variant are used in data located in the PREDICATE_TEXT
column.

3.21.2.10.5. Query plan format for the file mode

A query plan for the file mode has the following format:
<Query plan>
[CONST <Conditions>]
<Fields of a selection list>
[<Source description> [<Relation description> […]]]
[WITHOUT DUPLICATES]
[GROUPING]
[SORTING [CUTTING TOP]]
[UNION [ALL] <Query plan>]

In this description:
• WITHOUT DUPLICATES -indicates that data without duplicates
needs to be retrieved.
• GROUPING - indicates that a grouping of a result needs to be per-
formed.
• SORTING - indicates that sorting of a result needs to be performed.
• CUTTING TOP - indicates that after sorting a part of records will be
retrieved only.
<Conditions>
WHERE [(POST) | (END)] <Condition> [AND <Condition> […]]

In this description:
• (POST) - indicates that conditions are checked after a connection is
made.
• (END) - indicates that conditions are checked after the joins between
all the tables are completed.
<Fields of a selection list>
Fields: (<Expression from selection list> [, <Expression from
selection list>])

<Scan description>
{{NOT SCAN} | {FULL SCAN} | {DISTINCT SCAN} | {RANGE SCAN}} [UNTIL
FIRST NOT NULL] [USING [REVERSE] INDEX (<Index name>) [(<Number of
index fields used> fields)]]

In this description:
• NOT SCAN - indicates that the contents of the table will not be
scanned.
• FULL SCAN - indicates that the contents of the table will be scanned
completely.
• DISTINCT SCAN - means that different index values will be by-
passed.
• RANGE SCAN - indicates that a section of the table will be scanned
by index.
 • UNTIL FIRST NOT NULL - indicates that records will be scanned
until the first record with a value not NULL is received .
• USING INDEX - indicates that an index will be used for bypassing.
• REVERSE -indicates that an index will be used in reverse order.
<Source description>
{<Table name> [(TWICE)] <Scan description>} |
{NESTED SELECT <Scan description> (<Query plan>)}
<Conditions>

<Relation description>
{{ NESTED [OUTER] LOOP <Table name> [(TWICE)] <Scan description>} |
{ NESTED [OUTER] LOOP BY SELECT <Scan description> (<Query plan>)}}
<Conditions> [<Conditions>]

In this description:
• (TWICE) - indicates that the table is used in query several times.
• NESTED LOOP - indicates that for each table entry on the left, a loop
will be performed to bypass the table entries on the right.
• OUTER - indicates that if a record in the right table suitable by the
linking condition is not found, the entire record will not be lost.

3.21.2.11. <defaultlog>
The item <defaultlog> defines the default technological log settings.
This log has a fixed event filter defined by 1C:Enterprise. This filter cannot
be changed and can be represented by the following configuration file:
<log location="C:\Users\<UserName>\AppData\Local\1C\1cv8\logs"
history="24" >
<event>
<eq property="name" value="system"/>
<eq property="level" value="error"/>
</event>
<property name="all"/>
</log>

This log records events that are critical for system operability. Composition
of the events is not documented. Event generation is configured using the
item <system>.
The item attributes:
location
The name of the directory in which the default technological log will be
placed. If the attribute is not specified, then the default technological log is
saved to the following directories:
• Windows OS:
 Windows XP: %USERPROFILE%\Local Settings\1C\1cv8\logs
  Windows Vista (and later versions):
%LOCALAPPDATA%\1C\1cv8\logs
• Linux: ~/.1cv8/logs.
IMPORTANT! It must be taken into consideration that the directory of
technological log is not intended to store the files that do not belong to the
technological log. Do not keep dumps in this directory, and do not keep
1C:Enterprise technological log in a directory with any unrelated files. If
any unrelated files are found in the technological log directory, the directory
is considered invalid and the log is not created.
NOTE. Different directories must be specified in the location attributes
of the <log>, <dump> and <defaultlog> items.

history
A number of hours at which information stored the technology log will be
removed. If a value of this attribute is set to 0 -, then the technology logging
will be disabled by default.
Default value: 24.
Unlike the technological log files, the default technological log files are
generated only when the corresponding event occurs.

3.21.2.12. <system>
The item <system> manages generation of the SYSTEM events in the
technological log. The technology log configuration file (logcfg.xml) may
not contain such an item and may also contain one or more such items.
If the item <system> is not in the file logcfg.xml , then the default tech-
nology log is configured as follows: -a level of generation of the system
events for all system components is defined as Error.
The events SYSTEM will be simultaneously placed in all configured tech-
nology logs (including the default technology log).
The item attributes:
level
Sets the minimum level value for system-generated events. Possible values
(in order of increasing importance):
• Trace - The most detailed level.
• Debug - A level of debug information. Intended for the events that
are necessary to debug platform mechanisms or to investigate the most
difficult problems to be identified.
• Info - A level of information. Intended for the events indicating
normal functioning of a one or another platform mechanism.
 • Warning - A level of warnings. Intended for the events informing
about the occurrence of abnormal, but not critical (in terms of mecha-
nism of a platform) situations.
• Error - A level of errors. Designed for the events informing about
the occurrence of erroneous (in terms of mechanism of a platform)
situations.
• None - Disabling of fixation of the system events.
Setting this attribute will result in the “1C: Enterprise” system not generat-
ing the events not corresponding to the specified level.
So, if logcfg.xml contains fragment <system level = "info" />,
1C:Enterprise will register events with the Info, Warning and Error
levels.
component
Specifies the name of the component for which generation of system events
is configured. The component name is case-sensitive.
class
Specifies the name of the class for which generation of system events is
configured. The class name is case-sensitive.

As an example, let's consider the situation where the logcfg.xml file con-
tains the following fragment:
<system level="info"/>
<system level="debug" class="core::FileSystem" />
<system level="warning" component="core82" />

This means:
• SYSTEM events with the Info level (and above) are generated for all
system objects.
• However, for the core::FileSystem class, events with Debug
level are generated.
• For all classes of the core82 component, events with Warning lev-
el and higher are generated.

3.21.2.13. <dbmslocks>
The item <dbmslocks> enabled collection of information about database
locks in the technological log. If the item is not in the file, information
about database locks is not added to the technological log.
Information on database locks is displayed in the technological log using
special properties.
 3.21.2.14. <scriptcircrefs>
The item <scriptcircrefs> enables collection of information about
circular references in the technological log. If the item is not in the file, in-
formation about circular references is not added to the technological log.
<?xml version="1.0"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="D:\V82\logs" history="96">
<event>
<eq property="name" value="SCRIPTCIRCREFS"/>
</event>
<event>
<eq property="name" value="excp"/>
</event>
<property name="all"/>
</log>
<scriptcircrefs/>
</config>

The example implements these settings:

• Collection of information about cyclical links is enabled (item
<scriptcircrefs />)
• Events added to the technological log contain all properties (item
<property name = "all" />)
• Only the SCRIPTCIRCREFS and EXCP events are recorded in the
technological log (items <event>)
See also:
• Writing information about circular references

3.21.3. Writing exception

contexts
An exception context is a sequence of the technological log events of
EXCPCNTX type. Each EXCPCNTX event is a long event that had started
but did not yet finish at the moment of a 1C:Enterprise emergency. In this
case, the events are displayed in descending order of the nesting level. Type
of the event that originated the EXCPCNTX event becomes a value of the
SrcName property of the EXCPCNTX event.
An exception context is written to the technological log if it is enabled (at
least one log item is in the logcfg.xml file) and one of the following
abnormal situations has occurred:
• An OS exception occurred during 1C:Enterprise operation, the process
(client or server) was terminated abnormally, a crash dump was gen-
erated.
• A database exception occurred, an error message was displayed,
1C:Enterprise closed.
If a database error occurs, an event of EXCP type is written to the techno-
logical log if it meets the conditions defined in the technological log config-
uration file (logcfg.xml).

3.21.4. Writing information

about mutual locks
Whenever a database query is performed (but not more often than once per
second), an additional database query is sent in order to find out which
thread was locked by which thread. A result of such a query is a table of
pairs (“blocking victim”, “blocking source”) where:
• A Blocking victim -The ID of a connection to DBMS waiting for a
lock.
• A Blocking source- The ID of a connection to DBMS that had estab-
lished the lock.
If there are several working processes in a cluster, then the query is execut-
ed by one of them. Mutual lock queries are numbered. Lock information is
collected only if the <dbmslocks> item is present in the technological log
configuration file.
The data from a resulting table is added to the context of each thread to
which the received connections IDs from the DBMS correspond and will be
displayed as the locking property values of the next technology log event.
After the next event of the technological log is completed in the thread to
the context of which information about locks is completed, the locking
properties will be added to this event. Herewith, if a thread has been a lock
target, the locking events will be cleared after the output. If a thread was a
lock source, a cleanup is performed when a transaction is closed or rolled
back.
Information about locks is added to threads in the following order:
• If a target thread has no information about lock, it is passed a query
number and source thread ID.
• A query number is added to a lock source thread only if it has targets
that have no information about their locks.
Information on locks:
• If the thread is a source, time of detection
• If the thread is a target, time of detection
• Query number (if the thread is a target)
• List of query numbers (if the thread is a source)
• Source connection number (if the thread is a target)
Event blocking properties:
• lka=‘1’ -A thread is a source of blocking.
• lkp=‘1’ - A thread is a victim of blocking.
 • lkpid - A number of the request to DBMS of the “who blocked
whom" kind (only for a victim thread of blocking). For example,
‘423’.
• lkaid - A list of request numbers to DBMS of the “who blocked
whom to whom” kind (only for a source thread of blocking). For ex-
ample, ‘271,273,274’
• lksrc - Is a blocking source connection number if the stream is a
victim; for example, ‘23’.
• lkpto - Time (in seconds) elapsed since detection of the thread being
a victim. Example: ‘15’.
• lkato - Time (in seconds) elapsed since detection of the thread being
a source of blocking. For example, ‘21’.
Thus, to analyze locks, it is necessary to find the first event with lka and
lkp properties in the technological logs of rphost processes, read the
values of lkaid and lkpid properties, and find all the events with these
property values in the logs of all the working processes of a cluster. The
group of found events can be analyzed to find out "who locked whom", for
how long, and what occurred during that time.
Also, in the Txt property of the TLOCK event in the technological log, a
namespace where lock occurred can be displayed.

3.21.5. Writing information

about circular
references
When developing complex application solutions it is possible to commit
various errors that would lead to circular references. Circular references -
are such a construction of data in a program when any data directly or indi-
rectly refers to itself. A simplest example of such a circular reference is:
Structure1 = New Structure("Structure2Ref");
Structure2 = New Structure("Structure1Ref");
Structure1.Structure2Ref = Structure2;
Structure2.Structure1Ref = Structure1;

The memory used by such data cannot be released by the system upon work
completion, for example, a form that contains such a program code in the
built-in language. As a result, each opening of a form containing such code
leads to the application session process taking up more RAM and not releas-
ing it after use. Finally, the application is either terminated abnormally or
starts using excessive RAM. The increased RAM usage by an application
could, among others, lead to the general computer slowdown, up to the ina-
bility to open external data processors after the changes have been made,
etc.
Obviously, the circular references need to be eliminated. In order to locate
errors in configurations that lead to circular references, several tools are
available:
1. Modifying a configuration file of the technological log
2. using the command line to start a client or server application;
3. Using a parameter of the conf.cfg file
4. Using a 1C:Enterprise language method
IMPORTANT! Using any of these tools leads to a significant drop in
1C:Enterprise performance. The circular reference detection tools should
not be used during normal 1C:Enterprise operation. Use these tools only
when a targeted search for circular references is required in order to correct
the corresponding fragments of an application.
Depending on the selected mode, a behavior of the system upon detecting
circular references will be different:
• When using the technological log , - the SCRIPTCIRCREFS events
will be placed in there. Herewith, execution of an application solution
will not be interrupted.
• Using the other tools - would result in interruption of the operation of
an application solution, which would trigger a corresponding message.
It would be impossible to continue work after such message is issued.
The circular references are checked in the following cases:
• When completing a 1C:Enterprise language method: All local varia-
bles and parameters of a method are analyzed
• When setting a session parameter: A value set as a value of session
parameter is analyzed
• When calling a special method of 1C:Enterprise language.
In order to include information about circular references in the technologi-
cal log, it is necessary to specify the <scriptcircrefs> element in the
technological log configuration file logcfg.xml. In this case, 1C:Enterprise
will start analyzing circular references. Whether the SCRIPTCIRCREFS
events are written to the technological log depends on other settings of the
technological log.
If the parameter EnableCheckScriptCircularRefs of the startup
command has been used at starting a thin or thick client application, that
means that the system will search for circular references in the client code
of an application solution. This parameter also gets into into the command
line at launching the client application if the check box Check of circular
references of the embedded 1C:Enterprise language is checked in the
Designer settings (Main menu - Service -Parameters- Launch of the
1C: Enterprise -Addditional).
In order to enable search for circular references on the server side of the 1C:
Enterprise system, it is necessary to start server with the /
enableCheckScriptCircularRefs parameter. In this case, a search
for circular references will be performed in all sessions serviced by server
that has been launched with the referenced parameter.
If the EnableCheckScriptCircularRefs parameter of the file conf.cfg is
set to true, this means that a search for circular references while executing
the code in the embedded 1C:Enterprise language will be performed by all
instances of the 1C: Enterprise system that use the conf.cfg file with the
referenced parameter.
It is possible to initiate a search for circular references using the global con-
text method CheckCircularReferencesOf1CLanguage(). When
this method is called either the variable specified as a parameter of a meth-
od or all local variables available at the time the method is executed are
checked.
See also:
• <scriptcircrefs>.
• File conf.cfg.
• General startup commands.

3.22. logui.txt
The logui.txt file contains a list of interactive user actions that were per-
formed during logging.
File location:
• On Windows:
%APPDATA%\1C\1cv8\<Infobase UUID>.
• On Linux:
~/.1cv8/1C/1cv8/<Unique infobase ID>.
• On macOS:
~/.1cv8/1C/1cv8/<Unique infobase ID>.
One file entry contains a description of a single user action. An overall for-
mat of a string is, as follows:
• Date and time of an event;
• Description of an event (Event);
• The name of an object with which an event occurred;
• Time (in milliseconds) from the start of a program (t);
• Prefixes beg or end (similar to the opening and closing parenthesis)
identifying a beginning and end of an event;
• Adding more specifics (Detail).
In order to collect statistics on the duration of actions taken, a beginning and
end of the action are recorded in the protocol. A beginning of the action is
 contained in the record marked as beg; an end of the action - is marked in
the record as end (these evidences are displayed at the very end of the log
line).
Also, the duration of the action marked as t is recorded. Time count (in mil-
liseconds) starts at the moment of the application startup.
Between the log lines containing beg and end, there can be located both
nested actions containing beg and end and the lines reflecting any actions
to be recorded in the log.
Logging is performed for all items of the form and items of the global
command interface available in 1C: Enterprise mode.
The following actions are logged:
• Pressing a key on the keyboard. Data entered by user is replaced with
asterisks in the protocol (Event Key_<key> or Event key_*).
• Clicking the left (Event_LClick), right (Event_RClick), and middle
mouse buttons (Event_MBtnDn).
• Double clicking the left mouse button (Event_ LBtnDbl).
• Scrolling the mouse wheel (Event_Wheel).
Unique events are used for some items:
• Form:
 Activation of the form window:
"Event FormActivate","Name <form name>"

• Subsystem Panel (PartitionPanel):

 Selecting a subsystem or desktop using the mouse:
"Event LClick","Name PartitionPanel"

 Using a keyboard shortcut:

"Event PanelActivate","Name SubsystemsPanel"

• Navigation panel (FormNavigationPanel):

 Executing command:
"Event LClick","Name FormNavigationPanel","Detail Execute <command
name>"

 Expanding/collapsing a group of commands:

"Event LClick","Name FormNavigationPanel","Detail Close <command
group name>"

 Using a keyboard shortcut:

"Event PanelActivate","Name FormNavigationPanel"

• Window caption (WindowCaptionText):

 Clicking on the caption:
"Event LClick","Type WindowCaptionText","Detail DataProcessor"

• Actions panel (ActionsPanel):

 Executing command:
"Event LClick","Name ActionsPanel","Detail <command name>"

 Using a keyboard shortcut:

"Event PanelActivate","Name ActionsPanel"

• An area of the information panel which displays a list of the latest

alerts (NotificationHistoryPanel):
 Executing command:
"Event Key_SPACE","Name NotificationHistoryPanel","Detail<name>"

 Using a keyboard shortcut:

"Event PanelActivate","Name NotificationHistoryPanel"

• Status window (StatusWindow):

 Closing:
"Event CloseWindow"

 Moving:
"Event MoveWindow offset=<dx,dy> pos=<x,y,w,h>"

• Notification window (NotificationWindow):

 Closing:
"Event CloseWindow"

 Clicking on hyperlink:
"Event LClick","Name NotificationWindow","Detail Hyperlink"

 Moving:
"Event MoveWindow offset=<dx,dy> pos=<x,y,w,h>"

• Check window (input error prompt) (CheckWindow):

 Click Next message:
"Event LClick","Name CheckWindow","Detail NextButton"

 Click Previous message:

"Event LClick","Name CheckWindow","Detail PrevButton"

 Click Close:
"Event LClick","Name CheckWindow","Detail CloseButton"

Examples of log entries:

"17.12.200816:41:55","Event Key_SPACE",
"Name HistoryPanel", "t=465562", "beg"
"17.12.200816:41:55","Event FormActivate",
"Name Catalog.Goods.ListForm", "t=465562"
"17.12.200816:41:56","Event Key_SPACE","Name HistoryPanel",
"Detail Bold","t=466281", "end"
"17.12.200816:07:05","Event PanelActivate",
"Name HistoryPanel", "t=918188"

3.23. nethasp.ini
3.23.1. General description
To configure the parameters of the interaction of the “1C: Enterprise” sys-
tem with the HASP License Manager, the configuration file nethasp.ini is
used.
The file is located in the directory with the 1C:Enterprise configuration
files. It is optional. If this file is not in the directories of configuration files,
then it is searched in the following directories:
• On Windows OS:
 Directory with the executable files representing the running ver-
sion of 1C: Enterprise
 Current directory
 Directory%SYSTEMROOT%\Windows\System32 (for the 32-bit
OS Windows) or%SYSTEMROOT%\Windows\SysWOW64 (for
the 64-bit OS Windows)
 Directory%SYSTEMROOT%\Windows\System
 Directory %SYSTEMROOT%\Windows
 Directories listed in the environment variable PATH
• On Linux:
 Current directory
 User home directory
 Directory/etc
• On macOS:
 Current directory
 User home directory
 Directory/etc
The nethasp.ini file contains four sections:
• [NH_COMMON] - For general settings;
• [NH_IPX] - For IPX protocol;
• [NH_NETBIOS] - For NetBIOS protocol;
 • [NH_TCPIP] - For TCP/IP protocol.
The [NH_COMMON] section contains global settings for all sections of the
configuration file. All other sections contain settings affecting the perfor-
mance of operations with a specific protocol.
In each section, the parameters specific to this section or overall to all sec-
tions can be used. Specifying a parameter overall to all sections in a section
for one of the three protocols has a higher priority than setting in the
[NH_COMMON] section (relative to this protocol).
To define additional settings for a specific protocol, the parameters specific
to a particular section should be used.
Configuration files may contain comments. A comment begins with a “;”
(semicolon) and continues to the end of the line.
A case of letters in parameter names does not matter.
Below is a list of parameters and their valid values which may be given in
various sections of the nethasp.ini file.
When installing 1C:Enterprise, a sample of the nethasp.ini file is copied to
the conf subdirectory of the 1C:Enterprise installation directory. This file is
almost entirely composed of commented lines and does not override the
default settings in any way but it contains at the same time the most com-
plete list of parameters that can be used to configure the interaction of the
1C:Enterprise system with the HASP License Manager.
The parameters of each section of the configuration file are described in
detail below.

3.23.2. [NH_COMMON] section

NH_IPX
Values: Enabled, Disabled. Specifies whether to use the IPX protocol
to communicate with the HASP License Manager.
Default value: Enabled.
NH_NETBIOS
Values: Enabled, Disabled. Specifies whether to use the NetBIOS pro-
tocol to communicate with the HASP License Manager.
Default value: Enabled.
NH_TCPIP
Values: Enabled, Disabled. Specifies whether to use the TCP/IP proto-
col to communicate with the HASP License Manager.
Default value: Enabled.
NH_SESSION
Values: <Number>. Sets the interval (in seconds) during which the pro-
gram tries to establish a connection with the HASP License Manager.
Default value: 2 seconds.
NH_SEND_RCV
Values: <Number>. Sets the interval (in seconds) during which the pro-
gram tries to establish a connection with the HASP License Manager.
Default value: 1 second.

3.23.3. [NH_IPX] section

NH_USE_SAP
Values: Enabled, Disabled. Specifies whether to use the SAP service
to search for the HASP License Manager in network.
Default value: Enabled.
NH_USE_BROADCAST
Values: Enabled, Disabled. Use the Broadcast mechanism only to
search for the HASP License Manager in network. It makes sense to use this
feature when working with the IPX protocol in networks other than Novell
NetWare. Default value: Enabled.
NH_BC_SOCKET_NUM
Values: <Number>. Specifies the socket number for the broadcast mecha-
nism. The number is specified in hexadecimal format.
Default value: 7483Н.
NH_SERVER_NAME
Values: localnet, Internet. Specifies whether an application will
communicate only with the HASP LM located in the local network or with
any other HASP LM.
Default value: Internet.
NH_DATFILE_PATH
Values: <Path>. A path that will be used to search for the haspaddr.dat
and newhaddr.dat files containing the HASP License Manager network
address. Basically, it makes sense to use this option only with the settings
NH_USE_SAP = Disabled and NH_USE_BROADCAST =
Disabled because otherwise the address of the HASP License Manager
can be determined automatically.
NH_SESSION
Values: <Number>. Sets the interval (in seconds) during which the pro-
gram tries to establish a connection with the HASP License Manager.
Default value: 2 seconds.
NH_SEND_RCV
Values: <Number>. Sets the maximum time of receiving or sending a
package for the HASP License Manager.
Default value: 1 second.

3.23.4. [NH_NETBIOS] section

NH_NBNAME
Values: <Name>. Specifies the name of the HASP License Manager (name
length - is up to 8 characters).
NH_USELANANUM
Values: <Number>. Sets a number of the communication channel to be
used as a communication channel.
NH_SESSION
Values: <Number>. Sets the interval (in seconds) during which the pro-
gram tries to establish a connection with the HASP License Manager.
Default value: 2 seconds.
NH_SEND_RCV
Values: <Number>. Sets the maximum time of receiving or sending a
package for the HASP License Manager.
Default value: 1 second.

3.23.5. [NH_TCPIP] section

NH_SERVER_ADDR
Values: <Address1>, <Address2>. Sets IP addresses for all HASP
License Managers. You can use an unlimited number of IP addresses and
host text names.
IP address: 192.168.0.65.
Local host name: hasp.local.
NH_SERVER_NAME
Values: <Name1>, <Name2>. It communicates with the HASP LM hav-
ing a specific name. Maximum - 6 names; each name can consist of a max-
imum 7 characters.
NH_PORT_NUMBER
Values: <Number>. Sets the network port number.
Default value: 475.
NH_TCPIP_METHOD
Values: TCP, UDP. Sends a TCP or UDP packet.
Default value: UDP.
NOTE. Setting the parameter to TCP is ignored. HASP License Manager is
always accessed via UDP.

NH_USE_BROADCAST
Values: Enabled, Disabled. Use the UDP broadcast mechanism.
Default value: Enabled.
NH_SESSION
Values: <Number>. Sets the interval (in seconds) during which the pro-
gram tries to establish a connection with the HASP License Manager.
Default value: 2 seconds.
NH_SEND_RCV
Values: <Number>. Sets the maximum time of receiving or sending a
package for the HASP License Manager.
Default value: 1 second.

3.24. nhsrv.ini
Some HASP License Manager settings can be configured using the
nhsrv.ini configuration file.
File location:
• On Windows OS: This file is searched for in various directories in the
following sequence:
 Directory where the HASP License Manager executable file is lo-
cated
 A current Windows directory;
 The Microsoft Windows system catalog (%SYSTEMROOT%\
system32- for the 32-bit version and %SYSTEMROOT%\ sys-
tem - for the 64-bit version);
 A Microsoft Windows directory (%SYSTEMROOT% directory);
 The directories listed in the PATH environment variable (only
when installing the HASP License Manager as a Microsoft Win-
dows application).
 In the OS Windows, it is recommended to place the nhsrv.ini file,
if necessary, in the directory where the HASP License Manager
executable file is located. Verifying that the HASP License Man-
ager found and read the configuration file is possible using the log
Activity Log/Server Activity Log.
• On Linux: Location of the nhsrv.ini configuration file should be spec-
ified using the -c parameter. The default configuration file location is
undefined.
The HASP License Manager is configured using the settings of various pa-
rameters in the [NHS_SERVER] section of the nhsrv.ini file:
NHS_IP_LIMIT
Values: <ipAddr>, <ipAddr>,...
Defines the range of network stations served by the HASP License Manag-
er. Example: 10.1.1.1, 10.1.1.*,10.1.1.1/32, 10.1.1.1/24.
NHS_ADAPTER
Values: <ipAddrSubMask>,<ipAddrSubMask>,...
Specifies the IP address of one or more network cards to be served by the
HASP License Manager. It is used when using the HASP License Manager
with Win32. Example: 10.1.1.111, 255.255.0.0.
NHS_USERLIST
Maximum number of users simultaneously connected to the HASP License
Manager. Default value: 250.

3.25. rescntsrv.lst
The file is located in the data directory of each working server marked as
central server.
The file contains the values of the resource consumption counters defined
by the counter settings. The values in this file are updated every 20 seconds.
Used to restore counter values after restarting the server cluster.

3.26. ring-commands.cfg
This file contains the register of module instances registered for use with the
ring utility. The file is a text file encoded in UTF_8 (without BOM), the file
format is -YAML.
File location:
• On Windows OS:
%ALLUSERSPROFILE%\Application Data\1C\1CE
(%ALLUSERSPROFILE%\1C\1CE for Windows Vista and higher).
 • On Linux: /etc/1C/1CE.
The file looks like this:
license:
-
file: C:\Program Files\1C\1CE\license-
tools\lib\com._1c.license.activator.ring-0.1.0-12.jar
arch: x86_64
version: 0.1.0

In this file:
• license - The module name. In the ring utility, this name precisely is
used as the <module> parameter.
• – - a sign of the beginning of description of the module.
• the file - parameter contains the full name of the file with module.
• Thearch - parameter describes the architecture of the used module.
• The version - parameter describes a version of the module being used.

3.27. srv1cv83
IMPORTANT! This configuration file is used only when launching the
“1C: Enterprise” server in the Linux operating system.
The configuration file /etc/ sysconfig / srv1cv83 (for the RPM system) is
used to set the startup parameters of the 1C: Enterprise server agent using
the /etc/init.d/srv1cv83 script. If the installation was performed for a DEB
system, then the following parameters should be edited in the
/etc/init.d/srv1cv83 file.
The following parameters can be configured using this configuration file:
SRV1CV8_KEYTAB
A path to the Kerberos private key file.
SRV1CV8_DATA
A directory in which the server cluster service files will be located (includ-
ing a list of clusters and a list of the cluster infobases).
SRV1CV8_PORT
The main port number of the cluster agent. This port is used by the cluster
agent to access a central server. The cluster agent port is also specified as
the network port of the working server.
SRV1CV8_REGPORT
The network port number of the cluster created by default when the initial
launching of the ragent.
SRV1CV8_RANGE
Network port ranges for dynamic selection. The service ports of the cluster
processes are selected from them if it is impossible to select them from the
settings of the corresponding working server.
SRV1CV8_DEBUG
Launch in debugging mode:
• 0 -without a debug mode (by default);
• 1 - in debug mode
A debugging is possible only via TCP/IP protocol. Debugging over HTTP is
not supported in this startup mode.
SRV1CV8_SECLEV
The connection security level;
• 0 - Turned off (by default);
• 1 - Setting a connection;
• 2 - Constantly.
SRV1CV8_PINGPERIOD
A period of time (in milliseconds) during which a verification of the inter-
ruption tracking system is taking place.
Default value: 1 000.
SRV1CV8_PINGTIMEOUT
A timeout (in milliseconds) of verification of the interruption monitoring
tracking system.
Default value: 5 000.

3.28. swpuser.ini
The swpuser.ini file is designed to override the users on whose behalf
working processes and the cluster manager will be executed. By default,
working process and cluster manager run on behalf of the same user as the
server agent. For more details about structure of a server cluster.
The swpuser.ini file is located in the directory of the registry of a cluster
with which a server agent works with; it has the following format:
user=<user name for rphost>
password=<user password for rphost>
[rmngr_user=<user name for rmngr>
[rmngr_pass=<user password for rmngr>]]
[registry=<cluster registry directory>]
[<port>:
[user=<user name for rphost>
[password=<user password for rphost>]]
[rmngr_user=<user name for rmngr>
[rmngr_pass=<user password for rmngr>]]
[registry=<cluster registry directory>]]

In this file, you can specify:

• A user (and their password) on whose behalf the working processes
will be executed in all clusters on this computer (user and
password parameters). If not specified, then the production server is
running on behalf of the same user as the server agent.
• A user (and their password) on whose behalf the cluster managers will
be executed in all clusters of this computer (rmngr_user and
rmngr_pass parameters). If not specified, then the cluster manager
is running on behalf of the same user as the server agent.
• A root directory of the cluster registries for all clusters of this central
server (registry parameter). If not specified, a directory named
like reg_<port> in the directory with a list of clusters of the main
cluster manager will be used (specified in the -d parameter when
starting the cluster agent).
If you need to change the cluster registry directory, please keep in
mind that the user on whose behalf a cluster manager is working must
have full rights to this directory.
• If it is necessary for each cluster to specify its own set of parameters,
then for this a section with the port number of the cluster manager is
created in the swpuser.ini file and in this section all the above param-
eters can be specified.
If an individual cluster registry is specified for a cluster, then the user
on behalf of which the manager of that cluster is running must have
full rights in the specified directory.
IMPORTANT! Passwords in the example are for demonstration purposes
only. It is strongly not recommended to specify these (or similar) passwords
in the systems engaged in commercial operation.
Consider an example of using the swpuser.ini file. In this example, two
clusters are running on a computer (with ports 1541 and 1641); the -
d"d:\cluster\main" parameter is specified in the server agent launch line.
The directory d:\cluster\main contains the file swpuser.ini containing the
following:
user=srv_1c_rphost
password=123
rmngr_user=srv_1c_rmngr
rmngr_pass=123
registry=d:\cluser\common
1541:
user=srv_1c_rphost_1541
password=123
rmngr_user=srv_1c_rmngr_1541
rmngr_pass=123
registry=d:\cluser\one

As a result:
• For a cluster with the 1541 cluster manager port, the cluster registry
directory d:\cluser\one and the users srv_1c_rphost_1541 and
srv_1c_rmngr_1541 will be used for working process and a cluster
manager, respectively. The user srv_1c_rmngr_1541 should have
full access to the d:\cluser\one directory; the actual directory with
the cluster registry data will be d:\cluser\one\reg_1541.
• A cluster with the cluster manager port 1641 (and all clusters that can
be added in future if the swpuser.ini file is not changed) will use the
subdirectories of the directory d:\cluser\common to store their clus-
ter registries and the srv_1c_rphost and the srv_1c_rmngr users to
enable the working processes and cluster managers (respectively) to
operate. The actual directories with the cluster registries will be the di-
rectories d:\cluser\common\reg_1641 and so on.
When you modify the name of a user running a server agent (ragent), make
sure that the following requirements and recommendations are complied
with:
• Windows OS:
 A user has to be a member of a group of administrators.
 A user shall be assigned the following rights:
 Right (Adjust memory quotas for a process).
 Right (Replace a process level token).
 Belonging to a group of administrators does not guarantee
availability of the above rights.
• Linux:
 A user running a server agent has to be a superuser (root).
 When you start other server cluster processes, pass and
rmngr_pass parameters of a configuration file will be ignored.
When you change a user running a server agent (ragent), users running
cluster managers (rmngr) and working processes (rphost) need to be ex-
pressly specified. Otherwise, all server cluster processes will be executed on
behalf of a system administrator, and this is a highly risky scenario.
 The remaining rights that need to be assigned to users running server cluster
processes.
For the users on whose behalf working processes and cluster managers will
be started, the operating system profiles should be created. To create a pro-
file, it is enough to allow user the interactive input so that it is executed
once. After that, a profile will be created and the interactive entrance can be
disabled. The users on whose behalf working processes and cluster manag-
ers are launched, a full access should be given to the following directories:
• On Windows OS: %ALLUSERSPROFILE%\1C\1cv8
• On Linux: /var/1C
If it is necessary to specify the user name with domain, the user name must
be as follows: \\domain-name\user-name.

3.29. testcfg.xml
The testcfg.xml file is designed to configure the range of ports used in au-
tomated testing of the application solutions running in the web client.
The file is located in the configuration files directory of the 1C:Enterprise
instance used as a testing client. The file is optional.
If the file is not found, ports from the standard range (1538–1539) are used
for communication.
Example:
<config xmlns="http://v8.1c.ru/v8/testcfg">
<testports range="1538:1539"/>
</config>

The attributes of the item testports are described below.

range
Type: String. Contains a range of ports that the web server uses to or-
ganize communication between the test manager and test client.

3.30. Object list file

3.30.1. General description
This file is used to specify a list of objects that are used during configura-
tion comparison operations or working with configuration storage.
The file with the list of objects is an XML file with the following structure:
<Objects…>
<Configuration…/>
<Object…>
<Subsystem…/>
</Object>
</Objects>

Namespace: http://v8.1c.ru/8.3/config/objects.

3.30.2. <Objects>
The root element of the file. This element can contain no more than one
item<Configuration> and one or several items <Object>.
The item may contain the following attributes:
version mandatory
Version of the file list.
Type: String.
Only version 1.0 is supported. For any other version, error Version x.x of
the object file list is not supported by this version of the platform will
be generated.

3.30.3. <Configuration>
Describes the root configuration object. No more than one item is allowed.
The item may contain the following attributes:
includeChildObjects mandatory
Use subordinate (to any degree) objects of the root configuration item in the
operation.
Type: Boolean.

3.30.4. <Object>
Describes one configuration object (possibly together with the subordinate
objects) involved in the operation. Any number of items is allowed. No
more than one item<Subsystem> can be subordinated to the item.
The item may contain the following attributes:
fullName
Full name of the object in the first configuration.
It is used only when configuring the configuration comparisons and when
working with the configuration repository. When configuring the configura-
tion comparisons, a fullName or a
fullNameInSecondConfiguration attributes must be specified. An
attribute is required when working with the configuration repository.
Type: String.
fullNameInSecondConfiguration
Full name of the object in the second configuration.
Used only when configuring the configuration comparison. When configur-
ing the configuration comparisons, a fullName or a
fullNameInSecondConfiguration attributes must be specified.
Type: String.
includeChildObjects mandatory
Use subordinate (to any degree) objects of the configuration object specified
in the fullName attribute in the operation.
The subordinate objects of a subsystem include the subordinate subsystems
and not the objects in the subsystem. To include the objects in the subsys-
tem, use the nested<Subsystem> tag.
Type: Boolean.

3.30.4.1. <Subsystem>
Indicates whether to use the objects that are part of the subsystem selected
by the parent item <Object>. This item is applicable only for the items
<Object> that describe the object of the subsystem. No more than one
item is allowed.
The item may contain the following attributes:
includeObjectsFromSubordinateSubsystems mandatory
If this attribute is specified, all objects (along with the subordinate objects)
included in the subsystem described by the parent item will be added to the
list of the objects being processed.
Type: Boolean.
configuration optional
Indicates a configuration used as a source of the subsystem content when
configuring a configuration comparison.
Type: String.
Values:
• Main - to be taken from the main configuration. Used by default.
• Second - to be taken from the second configuration.

3.30.5. Examples
Use all the configuration objects.
<Objects xmlns="http://v8.1c.ru/8.3/config/objects" version="1.0">
<Configuration includeChildObjects = "true"/>
</Objects>

Use the Products catalog with subordinate objects.

<Objects xmlns="http://v8.1c.ru/8.3/config/objects" version="1.0">
<Object fullName = "Catalog.Products" includeChildObjects= "true"
/>
</Objects>

To use the Administration subsystem without the subordinate subsys-

tems and the objects (together with subordinates) that are included in the
Administration subsystem only.
<Objects xmlns="http://v8.1c.ru/8.3/config/objects" version="1.0">
<Object fullName = "Subsystem.Administration"
includeChildObjects= "false">
<Subsystem includeObjectsFromSubordinateSubsystems = "true"/>
</Object>
</Objects>

To use the root configuration object with no subordinate objects and the
subsystem GoodsAccounting with the subordinate subsystems and the
objects included in the subsystem GoodsAccounting and the subordi-
nate subsystems.
<Objects xmlns="http://v8.1c.ru/8.3/config/objects" version="1.0">
<Configuration includeChildObjects = "false"/>
<Object fullName = "Subsystem.GoodsAccounting"
includeChildObjects= "true">
<Subsystem includeObjectsFromSubordinateSubsystems = "true"/>
</Object>
</Objects>

3.31. A file of merge settings

3.31.1. General information
When saving merge configuration settings, the following are saved to the
file:
• A file version of the settings, the minimum version of the platform
that supports this version of the settings.
• A description of configurations:
 Name
 Version
 Supplier
• Merge options:
 Relation between the main and second configuration
 Comparison languages
  Permission to delete the main configuration objects
 Object copying mode
• Flags for using object/property in a merge.
• Established orders of subordinate objects.
• Settings for properties merging, including:
 Modules
 Forms
 Spreadsheet document templates
Only the non-default settings are saved.
A settings file is an XML file with the following structure:
<Settings…>
<MainConfiguration>
<Name/>
<Version/>
<Vendor/>
</MainConfiguration>
<SecondConfiguration>
<Name/>
<Version/>
<Vendor/>
</SecondConfiguration >
<OldVendorConfiguration>
<Name/>
<Version/>
<Vendor/>
</OldVendorConfiguration>
<SupportRules>
// Setting up the support rules
</SupportRules>
<Parameters>
// Parameters of merge
</Parameters>
<Conformities>
// Settings for the manual object matching
</Conformities>
<Objects>
// Settings for a merge of objects
</Objects>
</Settings>

The above sequence order of the items subordinated to the item

<Settings> element is important and must be observed when the file is
being generated on its own. Each item specified above consists of the nested
items (one or several) and may contain attributes. A more detailed descrip-
tion of the structure of each element is given below.
Namespace: http://v8.1c.ru/8.3/config/merge/settings.
3.31.2. <Settings>
3.31.2.1. General description
The root element of the file.
The item may contain the following attributes:
version mandatory
Settings file version.
Type: String.
platformVersion optional
The minimum version of the 1C: Enterprise platform compatible with this
configuration file.
The attribute is written while saving settings.
Type: String.

3.31.2.2. <MainConfiguration>
The element describes the main configuration options.
This item is optional.
<Name> mandatory
Name of the main configuration.
Type: String.
<Version> optional
Version of the main configuration.
Type: String.
The item <Vendor> optional
Name of supplier.
Type: String.

3.31.2.3. <SecondConfiguration>
Description of the second configuration involved in merge.
This item is optional.
Content of this item is similar to content of the item
<MainConfiguration>.

3.31.2.4. <OldVendorConfiguration>
Description of the configuration of a supplier participating in merge.
This item is optional.
Content of this item is similar to content of the item
<MainConfiguration>.
 3.31.2.5. <SupportRules>

3.31.2.5.1. General description

This item contains the support rule settings.
This item is optional.
The item's content is as follows:
<SupportRules>
<NewObjects>
<ChangesAllowedRul
<ChangesNotRecommendedRule/>
</NewObjects>
<DuplicateObjectsAndModifiedObjectsWithGetFromSecondConfiguration
Rule>
<ChangesAllowedRul
<ChangesNotRecommendedRule/>
</DuplicateObjectsAndModifiedObjectsWithGetFromSecondConfiguratio
nRule>
<ModifiedObjectsWithoutGetFromSecondConfigurationRule>
<ChangesAllowedRul
<ChangesNotRecommendedRule/>
</ModifiedObjectsWithoutGetFromSecondConfigurationRule>
</SupportRules>

3.31.2.5.2. <NewObjects>
This element specifies the support rules for new objects of a supplier.
<ChangesAllowedRule> optional
Specifies support rules for the supplier objects with delivery rule Changes
are allowed. The item can take the following values:
• ObjectNotEditable - Support rule Supplier object is not ed-
itable.
• ObjectIsEditableSupportEnabled - Support rule Supplier
object is editable with support saved.
• ObjectNotSupported -Support rule Supplier object is re-
moved from support .
Default value: ObjectNotEditable.
<ChangesNotRecommendedRule> optional
Specifies support rules for supplier objects with delivery rule Changes are
not recommended. The item can take the following values:
• ObjectNotEditable - Support rule Supplier object is not ed-
itable.
• ObjectIsEditableSupportEnabled - Support rule Supplier
object is editable with support saved.
 • ObjectNotSupported -Support rule Supplier object is re-
moved from support .
Default value: ObjectNotEditable.

3.31.2.5.3. <DuplicateObjectsAndModifiedObje
ctsWithGetFromSecondConfiguratio
nRule>
Specifies support rules for identical objects or objects with merge mode Get
from second configuration.
<ChangesAllowedRule> optional
Specifies support rules for the supplier objects with delivery rule Changes
are allowed. The item can take the following values:
• KeepCurrentRule - maintains the current support rule (only to
update configuration that is being supported).
• ObjectNotEditable - Support rule Supplier object is not ed-
itable.
• ObjectIsEditableSupportEnabled - Support rule Supplier
object is editable with support saved.
• ObjectNotSupported -Support rule Supplier object is re-
moved from support .
Default value:
• When enabling support: ObjectNotEditable.
• When updating on support: KeepCurrentRule.
<ChangesNotRecommendedRule> optional
Specifies support rules for supplier objects with delivery rule Changes are
not recommended. The item can take the following values:
• KeepCurrentRule - maintains the current support rule (only to
update configuration that is being supported).
• ObjectNotEditable - Support rule Supplier object is not ed-
itable.
• ObjectIsEditableSupportEnabled - Support rule Supplier
object is editable with support saved.
• ObjectNotSupported -Support rule Supplier object is re-
moved from support .
Default value:
• When enabling support: ObjectNotEditable.
• When updating on support: KeepCurrentRule.
3.31.2.5.4. <ModifiedObjectsWithoutGetFromS
econdConfigurationRule>
This item specifies the rules of support for modified objects with a merge
mode other than Take from the second configuration.
<ChangesAllowedRule> optional
Specifies support rules for the supplier objects with delivery rule Changes
are allowed. The item can take the following values:
• KeepCurrentRule - maintains the current support rule (only to
update configuration that is being supported).
• ObjectNotEditable - Support rule Supplier object is not ed-
itable.
• ObjectIsEditableSupportEnabled - Support rule Supplier
object is editable with support saved.
• ObjectNotSupported -Support rule Supplier object is re-
moved from support .
Default value:
• When enabling support: ObjectIsEditableSupportEnabled.
• When updating on support: KeepCurrentRule.
<ChangesNotRecommendedRule> optional
Specifies support rules for supplier objects with delivery rule Changes are
not recommended. The item can take the following values:
• KeepCurrentRule - maintains the current support rule (only to
update configuration that is being supported).
• ObjectNotEditable - Support rule Supplier object is not ed-
itable.
• ObjectIsEditableSupportEnabled - Support rule Supplier
object is editable with support saved.
• ObjectNotSupported -Support rule Supplier object is re-
moved from support .
Default value:
• When enabling support: ObjectIsEditableSupportEnabled.
• When updating on support: KeepCurrentRule.

3.31.2.6. <Parameters>

3.31.2.6.1. General description

This element contains the merge options.
This item is optional.
The item's content is as follows:
<Parameters>
<ConfigurationsRelation/>
<ComparisonLanguages>
<Language/>
</ComparisonLanguages>
<AllowMainConfigurationObjectDeletion/>
<CopyObjectsMode/>
</Parameters>

<ConfigurationsRelation> optional
The item indicates the relationship between the main and the second con-
figurations. The item can take the following values:
• ConfigurationsNotRelated - The main configuration is not
related to the second;
• SecondConfigurationIsDescendantOfMainConfigurat
ion - Second configuration is a descendant of the main one;
• MainConfigurationIsDescendantOfSecondConfigurat
ion - Main configuration is a descendant of the second configuration.
Default value: ConfigurationsNotRelated.
<AllowMainConfigurationObjectDeletion> optional
The item indicates whether objects of the main configuration can be deleted.
Type: Boolean.
Default value: False.
<CopyObjectsMode> optional
The item indicates a copy mode for the objects of a configuration being
loaded. In this case, the internal object IDs are not saved.
Type: Boolean.
Default value: False.

3.31.2.6.2. <ComparisonLanguages>
Indicates that the selective language comparison is used. The language
codes used for comparison are described by the items Language.

3.31.2.7. <Conformities>
This item contains a list of objects whose conformity is established manual-
ly.
This item is optional.
The item's content is as follows:
<Conformities>
<Conformity/>
</Conformities>

<Conformity>
This item describes a pair of the matched objects.
This item contains the following attributes:
fullName mandatory
A full name of the main configuration object.
Type: String.
fullNameInSecondConfiguration mandatory
A full name of the second configuration object.
Type: String.

3.31.2.8. <Objects>

3.31.2.8.1. General description

This item contains the configuration settings for merging objects.
This item is optional.
The item's content is as follows:
<Objects>
<Configuration>
<MergeRule/>
<MergeRuleForPropertiesChangedTwice/>
<MergeRuleForPropertiesChangedOnce/>
<ObjectOrder/>
<Properties/>
</Configuration>
<Object>
<MergeRule/>
<MergeRuleForPropertiesChangedTwice/>
<MergeRuleForPropertiesChangedOnce/>
<ObjectOrder/>
<Subsystem>
<MergeRule/>
<MergeRuleForPropertiesChangedTwice/>
<MergeRuleForPropertiesChangedOnce/>
<ObjectOrder/>
</Subsystem>
<Properties/>
</Object>
</Objects>

3.31.2.8.2. <Configuration>
Describes the configuration settings for the root configuration element. The
item must include at least one of the elements <MergeRule>,
<MergeRuleForPropertiesChangedTwice>,
<MergeRuleForPropertiesChangedOnce>, <ObjectOrder>,
<Properties>.
<MergeRule> optional
Describes the merge mode for a root element.
<MergeRuleForPropertiesChangedTwice> optional
Describes the merge mode for twice-changed root element properties.
<MergeRuleForPropertiesChangedOnce> optional
Describes the merge mode for a property of the root configuration item
changed in one configuration only.
<ObjectOrder> optional
Describes the order of subordinate objects.
<Properties> optional
Merge settings for properties of the root configuration object.

3.31.2.8.3. <Object>
Describes the merge settings for a specific configuration object.
This item contains the following attributes:
fullName optional
Full name of the object in the first configuration.
When configuring a configuration merge, either the attribute fullName or
the attributefullNameInSecondConfiguration must be specified.
Type: String.
fullNameInSecondConfiguration
Full name of the object in the second configuration.
When configuring a configuration merge, either the attribute fullName or
the attributefullNameInSecondConfiguration must be specified.
Type: String.

The item must include at least one of the <MergeRule>,

<ObjectOrder>, <Properties>, <Subsystem> items.
If the merge mode is not DoNotMerge and:
• If the object is in the main configuration only, the object will be delet-
ed.
• If the object is in the second configuration only, the object will be
added.
<MergeRule> optional
Describes the object merge mode.
<MergeRuleForPropertiesChangedTwice>
optional
Describes the merge mode for object properties that were changed twice.
<MergeRuleForPropertiesChangedOnce> optional
Describes the merge mode for properties of an object that has been changed
in one configuration only.
<ObjectOrder> optional
Describes the order of subordinate objects in an object.

<Subsystem>
Describes the merge settings for the objects that make up the subsystem.
Applies only to objects describing the subsystem.
includeObjectsFromSubordinateSubsystems mandatory
If this attribute is specified, all objects (along with the subordinate objects)
included in the subsystem described by the parent item will be added to the
list of the objects being processed.
Type: Boolean.
configuration mandatory
From which configuration to take a composition of the subsystem.
Type: String.
Values:
• Main - to be taken from the main configuration. Used by default.
• Second - to be taken from the second configuration.
<MergeRule> optional
Describes the object merge mode.
<MergeRuleForPropertiesChangedTwice> optional
Describes the merge mode for object properties that were changed twice.
<MergeRuleForPropertiesChangedOnce> optional
Describes the merge mode for properties of an object that has been changed
in one configuration only.
<ObjectOrder> optional
Describes the order of subordinate objects in an object.
 3.31.3. Auxiliary items
3.31.3.1. <Properties>

3.31.3.1.1. General description

The item describes merge settings for properties of the configuration object.
The item's content is as follows:
<Properties>
<Property name="…">
<MergeRule/>
<MergeRuleForPropertiesChangedTwice/>
<MergeRuleForPropertiesChangedOnce/>
<Module>
<Methods/>
<Patch/>
</Module>
<FormModule>
<MergeRule/>
<MergeRuleForPropertiesChangedTwice/>
<MergeRuleForPropertiesChangedOnce/>
<Module/>
</FormModule>
<SpreadsheetDocument>
<MergeRule/>
<MergeRuleForPropertiesChangedTwice/>
<MergeRuleForPropertiesChangedOnce/>
</SpreadsheetDocument>
<Types>
<Type>
<MergeRule/>
</Type>
…
</Types>
<Content>
<Item>
<MergeRule/>
</Item>
…
</Content>
<Property/>
</Properties>

3.31.3.1.2. <property>
The item describes merge settings for a specific property of the configura-
tion object.
This item contains the following attributes:
name
The name of a property of the configuration object. Depending on the value
of this attribute, the <Property> item may include one of the following
elements: <Module>, <FormModule>, <SpreadsheetDocument>,
<Types>, <Content>.
Type: String.

The item includes the following items:

<MergeRule>
Describes merge mode for a property.
<MergeRuleForPropertiesChangedTwice>
Describes the merge mode for object properties that were changed twice.
<MergeRuleForPropertiesChangedOnce> optional
Describes the merge mode for properties of an object that has been changed
in one configuration only.

3.31.3.1.3. <Module>
The item describes advanced merge settings for a module.
The item contains the following items:
<Methods>
The item describes merge settings for a module by procedures.
<Patch>
Information intended for automated modification of the module text in
1C:Enterprise language, in the universal format (unidiff).

3.31.3.1.4. <FormModule>
The item describes advanced merge settings for a form module.
The item contains the following items:
<MergeRule>
Describes a merge mode of a module.
<MergeRuleForPropertiesChangedTwice>
Describes a module merge mode for a form that was changed twice.
<MergeRuleForPropertiesChangedOnce>
Describes a merge mode for a module that was changed in one configura-
tion only.
<Module>
Contains advanced settings for merging a form module.

3.31.3.1.5. <SpreadsheetDocument>
The item describes advanced merge settings for a spreadsheet document.
The item contains the following items:
<MergeRule>
Describes a merge mode for a spreadsheet document. It can take one of the
following values:
• Merge - Merge documents.
• Unite - Include the contents of both tabular documents.
<MergeRuleForPropertiesChangedTwice>
Describes a merge mode for a spreadsheet document that was changed
twice.
<MergeRuleForPropertiesChangedOnce>
Describes a merge mode if the tabular document is changed in one configu-
ration only.

3.31.3.1.6. <Types>

Item description
The item describes advanced merge settings for types.
The item contains one or more items:
<Type>
The item describes merge settings for a specific type.

<Type>
This item contains the following attributes:
name mandatory
Full name of the type to which the merge rule applies.
Type: String.

The item must contain one <MergeRule> item.

<MergeRule> mandatory
Describes the object merge mode.
3.31.3.1.7. <Content>

Item description
The item describes additional settings for merging the contents of exchange
plan, subsystems, and functional options.
The item contains one or more items:
<Item>
The item describes merge settings for a specific item in content of the above
objects.

<Item>
This item contains the following attributes:
name mandatory
Full name of the type to which the merge rule applies.
Type: String.

The item must contain one <MergeRule> item.

<MergeRule> mandatory
Describes the object merge mode.

3.31.3.2. <Methods>

3.31.3.2.1. General description

This item describes merge settings for configuration modules. The item
contains one or more items describing settings:
• Merging procedures/functions (item <Method>). One or more in-
stances of this item are allowed.
• Merging section of declaration of variables (item
<VariableDeclarationArea>). No more than one instance of
this item is allowed.
• Merging the main section of application (item <MainArea> ). No
more than one instance of this item is allowed.
The item's content is as follows:
<Methods>
<Method>
<MergeRule/>
<Patch/>
<Method/>
<VariableDeclarationArea>
<Methods/>
<Patch/>
</VariableDeclarationArea>
<MainArea>
<Methods/>
<Patch/>
</MainArea>
</Methods>

3.31.3.2.2. <Method>
The item describes settings for merging a specific procedure/function of a
module in 1C:Enterprise language.
This item contains the following attributes:
name
Name of the method used in the main and the second configuration (if the
NameInSecondConfiguration attribute is not specified).
Type: String.
nameInSecondConfiguration
Name of the method used in the second configuration if the mapping was
specified manually. Optional.
Type: String.

Behavior particularities:
• If a procedure is in both files, the merge will be performed according
to the mode or contents of the <Patch> item will be used.
• If a method is only in the first file, it will be deleted if a merge mode
is not equal to DoNotMerge.
• If a method is only in the second file, it will be added if a merge mode
is not equal to DoNotMerge.

The item includes the following items:

<MergeRule>
Describes the merge method.
<Patch>
Information intended for automated modification of the module text in
1C:Enterprise language, in the universal format (unidiff).
3.31.3.2.3. <VariableDeclarationArea>
The item describes merge settings for the variable declaration section.
The item includes the following items:
<MergeRule>
Describes a merge mode of the variable declaration section.
<Patch>
Information intended for automated modification of the module text in
1C:Enterprise language, in the universal format (unidiff).

3.31.3.2.4. <MainArea>
The item describes merge settings for the main program section.
The item includes the following items:
<MergeRule>
Describes a merge mode for the main section of application.
<Patch>
Information intended for automated modification of the module text in
1C:Enterprise language, in the universal format (unidiff).

3.31.3.3. <MergeRule>
The item describes a merge mode of an item. It can take one of the follow-
ing values:
• DoNotMerge - do not merge.
• GetFromSecondConfiguration - take from the second config-
uration.
• MergePrioritizingMainConfiguration - merge with a pri-
ority of the main configuration.
• MergePrioritizingSecondConfiguration - merge with a
priority of the second configuration.
• MergeWithExternalTool - merge using an external program
(supported by modules).

3.31.3.4. <MergeRuleForPropertiesChanged
Twice>
Describes the merge mode for object properties that were changed twice. It
can take one of the following values:
• DoNotMerge - do not merge.
• GetFromSecondConfiguration - take from the second config-
uration.
 • MergePrioritizingMainConfiguration - merge with a pri-
ority of the main configuration.
• MergePrioritizingSecondConfiguration - merge with a
priority of the second configuration.
• MergeWithExternalTool - merge using an external program
(supported by modules).

3.31.3.5. <MergeRuleForPropertiesChanged
Once>
Describes a merge mode for properties of the objects modified in only one
of the configurations. It can take one of the following values:
• DoNotMerge - do not merge.
• GetFromSecondConfiguration - take from the second config-
uration.

3.31.3.6. <ObjectOrder>
Describes the order of subordinate objects. It can take one of the following
values:
• GetFromMainConfiguration - take order from the main con-
figuration.
• GetFromSecondConfiguration - take order from the second
configuration.

3.32. File of differences in

configuration uploads
When executing the batch launch command of designer/
DumpConfigToFiles with the –getChanges parameter, a file is
generated that contains a list of differences between the two compared con-
figurations.
A file is generated in UTF-8 encoding with the following format:
• Each object getting into this file is described in a separate line
• If no changes are found, an empty file is formed
• If configuration changes require full unloading, then instead of a list
of objects the file will contain a single line: FullDump
• Each line is preceded by a prefix describing the nature of a change:
 New: - Contains a full name of the added object.
 Modified: - Contains a full name of the modified object. Renam-
ing an object is fixed in a separate line.
3.33. Standalone server
configuration file
3.33.1. General information
The standalone server configuration file is a YAML file in the version 1.2
(http://www.yaml.org/spec/1.2/spec.html) in the UTF-8 encoding. The
configuration file contains parameters that define the server settings and
parameters of the infobase that is served by the server.
In the case of using the time range value, the units of measurement should
be indicated:
• nano, ns - nanoseconds.
• micro, us - microseconds.
• milli, ms - milliseconds.
• seconds, sec, s - seconds.
• minutes, min, m - minutes.
• hours, h - hours.
• days, d - days.
The configuration file itself consists of the following sections, with the for-
mat given below:
• server - contains server parameters.
• database - contains database parameters.
• infobase - contains infobase parameters.
• http - contains the parameters for web access to the infobase.

3.33.2. server
Section describes server parameters.
address
The network address that will be used to access the standalone server copy.
You can specify the IP-address of the server, as well as aliases. The parame-
ter can take values:
• any - for all computer addresses on which the standalone server is
running.
• localhost - The alias of the 127.0.0.1 address.
• IPv4 address - network address in the IPv4 format.
• IPv6 address - network address in the IPv6 format.
Default value: localhost.
port
The TCP port which will be used to access the application. The value of this
parameter can be a number from 1 to 65535.
Default value: 8314.
host
Name of the computer that is running standalone server.

3.33.3. database
The section describes the database parameters. Depending on the version in
use of the standalone server, the following parameters are required:
• The infobase is located in the DBMS. Mandatory parameter dbms,
server, name.
• The infobase is located in the 1Cv8.1CD file. path mandatory pa-
rameter.
Simultaneous use of the dbms and pathparameters is not permissible.
dbms mandatory
Type of the DBMS in use. The parameter can take values:
• MSSQLServer - Microsoft SQL Server;
• PostgreSQL - PostgreSQL;
• IBMDB2 - IBM DB2;
• OracleDatabase - Oracle Database.
The remaining parameters of the indicated DBMSs correspond to the re-
quirements of the client-server version of the 1C:Enterprise platform.
server mandatory
The DBMS server name.
name mandatory
Database name.
user
The name of the user on behalf of whom the standalone server will connect
to the DBMS.
password
The DBMS user password.
path mandatory
Path to the 1Cv8.1CDdatabase file.
3.33.4. infobase
The section describes the infobase parameters, which is located in the data-
base described in the database section.
id
Infobase identifier in UUID format.
You can specify a unique symbolic identifier - in this case, each time the
server starts, the unique identifier will be generated (can be used for testing
purposes).
Default value: unique.
name
Infobase name If not specified, it will be generated as a string representation
of the infobase identifier actual value.
distribute-licenses
Manages the issuance of client licenses by the standalone server.
The parameter can take values:
• allow/yes/true - the client licenses are granted by the standalone
server.
• deny/no/false - the client licenses are not granted by the
standalone server.
schedule-jobs
Manages the scheduled-jobs execution.
The parameter can take values:
• allow/yes/true - the scheduled-jobs are executed.
• deny/no/false - the scheduled-jobs are not executed.

3.33.5. http
3.33.5.1. General information
The settings described in the http section of the standalone server configu-
ration file are similar to the publication settings that are stored in the de-
fault.vrd file.

3.33.5.2. General section

The section describes the parameters for accessing the infobase through a
web server (which is the standalone server).
It is permissible to create several access options to one infobase using a web
server.
base
The base path to access the infobase using a web server. You can organize
several publications to one infobase that differ in the basic path and other
publication parameters.
Default value:/.
auth
The section that describes authentication parameters.
zones
The section that describes separator parameters.
application
The section that describes accessibility using client applications.
odata
The section that describes the Odata publication parameters.
web-services
The section that describes the Web-services publication parameters.
http-services
The section that describes the Http-service publication parameters.
distro
The section that describes the parameters for publishing client application
distribution package.

3.33.5.3. Authentication parameter (auth)

3.33.5.3.1. OpenId authentication parameters

(openid)
rely
The section that describes the parameters for accessing the OpenId authenti-
cation provider.
provider
The section that describes the infobase parameters that acts as an OpenID
provider.
3.33.5.3.2. Parameters for accessing the
OpenId authentication provider
(rely)
url
Specifies the URL of 1C:Enterprise infobase used as OpenID provider.

3.33.5.3.3. Parameters of the infobase acting as

an OpenID provider (provider)
lifetime
Indicates the lifetime of the identifier authentication flag in seconds.
Default value: 86 400 seconds.
return-to
It is a regular expression that defines the mask for permitted names of web-
sites that can be used to redirect the user's web browser (see
openid.return_to request parameter) after OpenID provider com-
mand is executed.
One or more elements may be specified.

3.33.5.3.4. OpenIDConnect (openid-connect)

authentication parameters
providers
This item contains description of external OpenID providers supporting
OpenID Connect v1.0 authentication protocol
(http://openid.net/connect/). The description is an array of objects,
where each object describes one OpenID provider. The array is represented
by JSON serialization.
allow-standard
The item allows or prohibits 1C:Enterprise authentication. If this item is
false, authentication using the providers described in default.vrd file will
be available in the authentication form on web client startup.
The item can take the following values:
• true - 1C:Enterprise authentication is permitted. Default value.
• false - 1C:Enterprise authentication is forbidden.

3.33.5.4. Separator parameters (zones)

The section contains a separator description for the base access directory. If
the application contains several separators, this section may contain several
records. Each record describes the parameters of one separator in the order
of their (separators) sequence in metadata.
Each separator is described by the following parameter set:
value
Explicitly specifies the value of separator placed in this position.
safe
The parameter manages the option to change the separator value from the
application code:
• true - the separator value can be changed from the built-in language
(you can change the data area).
• false - the separator value cannot be changed from the built-in lan-
guage (you can not change the data area).
Default value: false.
specify
Determines whether the published infobase address must contain this sepa-
rator value.
• true - the access URL must contain the separator value.
• false - the access URL can not contain the separator value.
Default value: false.

3.33.5.5. Managed application publishing

parameters
publish
Determines the option to use the client application to access the infobase:
• true - you can get access using the client application (thin, web - or
mobile client).
• false - you can not get access using the client application. You can
use only published internet services.
Default value: true.
exit-url
Specifies the URL to open after exiting the web client.

3.33.5.6. OData (OData) publication

parameters
publish
Manages the availability of the standard OData interface through the speci-
fied publication.
Default value: false.
reuse-sessions
The section that describes the reuse-sessions.

3.33.5.6.1. Reuse-sessions mode parameters

mode
Session reuse mode. The parameter can take values:
• DontUse - sessions are not reused.
• Use - reuse is defined by the client and governed by HTTP request
parameters to the Internet service;
• AutoUse - sessions are reused automatically.
Default value: AutoUse.
max-age
The session idle time after which the session is terminated (in seconds).
Default value: 20 seconds.
pool-size
The maximum number of sessions that can be generated during automatic
session management.
Default value: 10.
pool-timeout
Time to wait for an available session after the session pool is filled (in sec-
onds).
Default value: 5 seconds.

3.33.5.7. Web-services publication

parameters

3.33.5.7.1. General parameters

The section describes the access parameters to the Web services that are
implemented in the application.
publish-by-default
If this parameter is not set or set to true, all Web services that are added to
the configuration will be automatically available for use, unless explicitly
prohibited by the service parameter.
Default value: true.
publish-extensions-by-default
If the parameter is set to true, all Web services that are located in attached
extensions are allowed. If the attribute is set to false, Web services in
extensions are not allowed.
Default value: false.
service
The section that describes the web service parameters. You can specify one
or more services (if several Web services are developed in the configura-
tion).

3.33.5.7.2. Web services parameters

publish
Web service publication (actual - use) is allowed.
Default value: true.
name
Web service name.
alias
Web service synonym.
reuse-sessions
The section that describes session reuse when working with a Web service.

3.33.5.8. Parameters for publishing http-

services

3.33.5.8.1. General parameters

The section describes the access parameters to the HTTP-services that are
implemented in the application.
publish-by-default
If this parameter is not set or set to true, all HTTP-services that are added
to the configuration will be automatically available for use, unless explicitly
prohibited by the service parameter.
Default value: true.
publish-extensions-by-default
If the attribute is set to true, all HTTP services that are located in connect-
ed extensions will be available for use. If the parameter is set to false, the
HTTP services from the extensions will not be available for use.
Default value: false.
service
The section that describes the Http-service parameters. You can specify one
or more services (if several HTTP services are developed in the configura-
tion).

3.33.5.8.2. HTTP service parameters

publish
HTTP service publication (actual - use) is allowed.
Default value: true.
name
HTTP service name.
root
Root URL of the HTTP service property. The property is used to determine
the HTTP service that should process the received request.
reuse-sessions
The section that describes session reuse when working with a HTTP ser-
vice.

3.33.5.9. Distribution package publication

parameters (pubdst)
win32
The full file name of the distribution package file with archive for the 32-bit
client application for Windows OS.
win64
The full name of the distribution package file with archive for the 64-bit
client application for Windows OS.
mac64
The full file name of the distribution package file with archive for the 64-bit
client application for macOS.
Appendix 4.
Supplementary utilities

4.1. Verification utility

chdbfl
This utility is designed for offline verification and correction of database
files.
IMPORTANT! Before using this utility, it is necessary to make a back-
up copy of the database file.
This utility is designed to work only with the file database. The utility is
available only in the 32-bit version. A file database is used:
• To store a file infobase
• To store a configuration storage
To start the utility from 1C:Enterprise installation directory, you need to run
chdbfl application. This will display a window (see fig. 107).

Fig. 107. Infobase verification and correction utility

In the field Name of infobase file, specify or select the infobase file name.
Select the check box Fix detected errors to fix the errors found during
verification. Also, select this check box to optimize the storage of internal
information that accelerates infobase opening.
To start the utility, click Execute. Make sure the infobase is not yet opened
in Designer or in 1C:Enterprise mode.
Messages about the errors found are displayed in a text box.
Messages about the results of the utility's performance are displayed below
the text box.
This utility can also be used for verification of configuration storage.
It is recommended to follow these steps when using the utility:
• Create a backup copy of the database file.
• Perform verification without selecting the check box Fix the detect-
ed errors
• If during verification no issues have been detected, then a verification
with the checked check box Fix errors detected - can be performed;
at the same time, the operation of re-indexing of infobase or infobase
storage will be executed. It is recommended to perform such an opera-
tion regularly.
• If any issues have been detected during verification, you should cor-
rect the infobase errors. If the utility reports lost data, it is not recom-
mended to continue working with this infobase. You can:
 Retrieve the remaining data and configuration that can be used to
create a new infobase
 Get the latest version of configuration that can be used to create a
new storage

4.2. The integrity

monitoring utility ci
4.2.1. General information
The integrity monitoring utility (ci) is designed to monitor the state of the
file system objects and the database used in 1C: Enterprise, and to detect the
situation of changes in these objects. To determine whether an object has
remained unchanged, a comparison of the hash sums of the monitored ob-
jects ((control objects)), which are calculated using the SHA-1 algorithm
(the cryptographic hashing algorithm), is used. Verification process consists
of generating the template hash sum values and the subsequent regular veri-
fication.
NOTE. The utility is not supported in macOS.
The utility works with the following control objects:
• Files located in the file system
• Some tables of 1C:Enterprise database
Lists of control objects are specified using the data source template. The
data source template is described by a universal data source descriptor.
Such templates can be specified in the utility startup command line directly
or as content of the file specified in the in parameter. Such file is known as
a template list.
A list of control objects and the corresponding hash sums (this pair is called
reference) is stored in a special reference database that is generated by the
utility when started in the template database generation mode. When the
utility is started in verification mode, the hash sums are calculated and rec-
onciled with the template database generated earlier. As a result, a report
file is generated.
The utility does not automatically control self-integrity. To restrict access to
the utility, template database, and verification results, use the operating sys-
tem functionality.

4.2.2. List of information

source templates
If it is necessary to specify several control objects for a simultaneous verifi-
cation (or a set of objects), a special file - list of information source tem-
plates can be used Each line in this file contains a template of the source of
information. The number of lines in the file is unlimited. A comment starts
with the character "#". A comment line as well as the empty lines and the
lines consisting of spaces, are ignored while generating a list of control ob-
jects.
A template list file should be in the UTF-8 encoding only.
Examples of universal descriptors of data sources:
# Control object – file /tmp/vokas/spru.cvs
file:///tmp/vokas/spru.cvs

# Control object – all files in c:\Program Files\1cv8\8.3.4.408\bin

rdir://c:\Program Files\1cv8\8.3.4.408\bin

# Control object – all .rc and .cfg files in /home/user/.kde and

subdirectories
rdir:///home/user/.kde?*.rc,*.cfg

# Control object – all files beginning with "V8", files in

directory /tmp, without subdirectories.
ndir:///tmp?V8*.txt

# Control object – all tables supported in the database located on

the MS SQL Server
mssql://user:password@server/instance/dbname

# Control object – "users" and "config" tables on the PostrgeSQL

server
postgre://user:password@server:123/dbname?users,config

# Control object – "users" tables in the file database

dbe://c:\DB\checked_db?users

4.2.3. A universal descriptor

of the source of
information
To describe the object of control, a special format -is used: the universal
descriptor of the source of information. In general, the universal descriptor
of the information source looks like:
proto://[user:[password]@][server[:port]][/path/resource][?mask]
Let's consider in detail each component part of the descriptor:
• proto - Description of the Object of control's kind. As a work mode,
the following files can be taken:
 file - A separate file from the file system;
 ndir - Files located in directory (without traversing subdirectories);
 rdir - Files located in directory and all the nested directories;
 mssql - Database , located in the Microsoft SQL Server DBMS;
 ora - Database located in the Oracle Database DBMS;
 postgre - Database located in the PostgreSQL DBMS;
 db2 - Database located in the DB2 DBMS;
 dbe - A file version of the 1C:Enterprise database.
 • user:password@ - describes the user name (user) and password
(password) required to access the object of control. If the database
tables are monitored, then the DBMS user is specified as a user in-
stead of the 1C: Enterprise database user. It is recommended to use the
parameters of the user on whose behalf the 1C: Enterprise database
was created. The “@” symbol is required if the username and pass-
word are specified.
• server: port - A name of computer (and access port) on which is
launched the DBMS serving the 1C: Enterprise database;
• /path/resource - A full path to the file or directory in the notation of
the operating system used. In the OS Windows, a system should begin
with the name of a disk; in the OS Linux - - with designation of a root
file system (/). If a connection to the client-server version of the data-
base is used, then as a path can be taken the name of database in terms
of the used DBMS if the DBMS does not support the organization of
server instances and a combination consisting of the name of instance
and the database name for the DBMS supporting this organization. If a
database name with an indication of a DBMS instance is specified as a
path to a resource, then an access to DBMS is performed using the de-
fault access port, and a specification of the port number in description
of the name of server on which the DBMS operates, is not supported.
• ?mask - A list of information source descriptor parameters separated
by commas. Depends on protocol If the files described by the ndir or
rdir protocols are used as a control object, the file masks can be used
as parameters. If as an object of control the “1C: Enterprise” database
table is acting, then the table names can be used as parameters:
 config - Configuration of database;
 users - A table of the configuation users;
Both of these tables are virtual and contain information from several
tables of the “1C: Enterprise” database. If the universal data descriptor
contains a link to one of the above tables, the hash sum is calculated
for all data in the table (physical tables, completely or not). Capability
to control a table fragment is not supported.
NOTE. When generating a universal data source descriptor, avoid the fol-
lowing characters: @ (except in case of separation of the
username/password and the name of computer running the DBMS), /, \,:,?
(except when specifying in the file masks but not earlier), ~.
 4.2.4. File of the template
base
Hash sums of objects of control are stored in a special file -of the database
of templates. A file contains information in the UTF-8 format. File location
and name are specified when the utility is started. The file format is as fol-
lows:
[Normalized view of universal data source descriptor]
<control object> = <hash>

In this format, Normalized view of universal data source descriptor

contains a string in the same way as it is specified in the data source tem-
plate. However, a universal data source descriptor is converted to a normal-
ized view. During normalization, the following actions are performed:
• For all protocols, a forward slash (“/”) is added to the end of the de-
scription of objects of control (before the “?”)
• For protocols describing directories, mask “*" is added if no mask was
found
• For protocols describing databases, an explicit specification of the pa-
rameters config,users is added if no mask was found
• For protocols describing databases, the “*” mask is replaced with the
explicit indication of config,users
• Masks are lexicographically sorted
• Back slashes ("\") are replaced with the forward slashes ("/")
• Several consecutive slashes (any) are replaced by one straight slash
(for example, the construction “//\\//” is replaced by “/”).
A string <Object> = <hash> - contains a name of the object of control
and a hash sum of that object. There may be more than one such line. If a
universal data source descriptor contains a reference to a specific file, then
the <object>expression is absent and the line begins with the “=” charac-
ter.
An example of a fragment from the template database:
[dbe://C:/1C DB/DB folder/?config]
config = FEC3FC5E46AE98299217D6885B3BE28C4F4D6FB9

[dbe://C:/1C DB/Another DB folder/?config,users]

config = FEC3FC5E46AE98299217D6885B3BE28C4F4D6FB9
users = A244BE3830C2B7075C0BB684896B97A0324984A0

[file://C:/Program Files
(x86)/1cv82/8.2.9.356/docs/ru/V8UpdateFrom82Beta.htm]
= 392BC75149AE02565C7E31592EDCD60F00BFA03C

[ndir://C:/Program Files (x86)/1cv8/8.3.5.625/bin/?*]

1cv8.exe = 232F2BCCE6ABB95FD56E3CB3FADE528D851A5D69
1cv8_root.hbk = 025B4C8465D3CD851363B2102478B1CAF2EC444E
1cv8_root.res = 8F48869F82BB222EE25E18502605AC117BB5736A
1cv8_ru.hbk = 81CBB0D5573D8517913053EA88AAADE9785AB443
...

4.2.5. Report file

Results of the utility's performance are recorded in a report file. The file is
in UTF-8 format. File location and name are specified when the utility is
started. However, the specified name will be converted as follows: Date and
time of the report generation will be added to the file name; for example, if
a report is to be saved to C:\temp\report.rpt, the actual file name will look
like C:\temp\report-14.02.26-14.07.58.019446.rpt.
The file has the following format:
[.params]
Key=value

[Normalized view of universal data source descriptor]

<Control object> = <Detected change>

The .params section is always included and contains a description of the

utility startup parameters. As a Key can act the following values:
• datetime - Date and time of launching a utility;
• workdir - a working directory at launching utility;
• exepath - A path to the executable file containing a utility;
• mode - A launching utility mode:
 create - A mode of generating a base of templates;
 check - A template verification mode.
• etalon - A path to the base of templates;
• report - A path to the report file (as specified in the command line at
launching a utility);
• debug - A path to the file containing debug information or an empty
string if debug information output is not specified;
 • in - A path to the file containing parameters. If more than one –in pa-
rameter is specified in the start command line, then a presense of sev-
eral in keys is possible in the .params section;
• param - all the recognized command line parameters at launching a
utility separated by commas.
If any source (from the database of templates) detects differences between
the database of templates and the actual state of files on disk, then a section
describing the changed source is placed in the report file and the detected
changes for objects of control are displayed below. If an object of control
has not changed -, then information on such an object is not displayed.
The following possible changes are processed:
• A - A new control object has been detected in the source of infor-
mation;
• D - An object of control that existed at the time of generating a base of
templates, was deleted from the source of information;
• M - An object of control has been modified.
Let's review a fragment of the report file:
[dbe://C:/1C DB/DB folder/?config,users]
users = M

[ndir://C:/Program Files (x86)/1cv81/bin/?*]

1CMailV8.dll = D
1CMailV8.dll.32 = A

This report file indicates that:

• Content of the user table has been changed for the file infobase locat-
ed in the C:/1C DB/DB directory.
• In the directory C:/Program Files (x86)/1cv81/bin, file
1CmailV8.dll was deleted and a new file 1CmailV8.dll.32 is detected.

4.2.6. Using the utility

The utility is started using the command line with the following parameters:
ci <mode> --in <SourceTemplate> --etalon <ReferenceDatabaseFile> --
report <ReportFile> --debug <DebugInformationFile> [description of
source]

Parameters have the following values:

mode
A utility's working mode:
• --version, -v - show a version number of the integrity monitoring util-
ity.
 • --help, -h - show reference information on the make and check
modes. In this case, a mode should be indicated with a space after the
command for receiving reference information.
• make - To create a file of the database of templates or to update data
on any information sources (if the database of templates exists and it
contains data on the source that was specified when the utility started).
• check - To check integrity of the transmitted list of sources on the
base of templates.
The following parameters must be specified only when using a utility in the
make and check modes.
--in, -i
This parameter is used to specify a path to the data sources template. There
may be more than one such parameter.
For the make and check modes, at least one description of a source must be
specified. This can be the --in (-i) parameter or a simple indication of the
source description (see source description parameter below).
--etalon, -e
This parameter is used to specify a full path to the file with the reference
database.
It is mandatory for the make and check modes.
--report, -r
This parameter is used to specify a full path to the report file.
It is mandatory for the make and check modes.
--debug, -d
This parameter is used to specify a full path to the file with debug infor-
mation. The file is needed for the 1C technical personnel in case of an in-
vestigation into the utility’s incorrect behavior.
source description optional
Specifies a data source without specifying a template file (including multi-
ple descriptions). For that, a source should be specified in exactly the same
format as each row of the data source template list. The utility uses all
source descriptions specified during startup (both using parameter in and
explicitly).

4.2.7. Recommendations for

installation and use
The integrity monitoring utility does not have self-monitoring functions.
Therefore, integrity monitoring of the utility files is entrusted to the system
administrator. It can be protected by using the file system permissions for
the utility directory, reference database files, and report files.
A viable use case is as follows:
1. The utility is installed in the directory different from the 1C:Enterprise
installation directory.
2. A privileged user with restricted rights (sufficient to view all control
objects) is created.
3. Access rights to the executable and configuration files of the utility
are only granted to this user (any access by any other users is denied).
4. The utility is always started on behalf of this user.
The above rules will ensure high level of protection against unauthorized
access and misuse.
The general usage procedure is as follows:
1. To run the utility, log in as a privileged user. If the utility is started
from the system scheduler, make sure that the scheduler runs it on be-
half of the privileged user.
2. The utility is started in one of these modes: creating a reference data-
base, or checking integrity of data sources.
3. Analysis of the utility performance report is performed.
Thus, the utility (and its performance results) is only accessible to the trust-
ed persons who know the name and password of a privileged user created to
run the integrity monitoring utility.
 4.3. Conversion utility
cnvdbfl
A database file has several versions of the internal format:
1. A size of the internal page of database file in version 8.2.14 - is equal
to 4,096 bytes. A size of the internal file cannot exceed 4 GB.
2. 8.3.8 Version -A size of the internal page of database file can have
several values: 4 096, 8 192, 16 384, 32 768 and 65 536 bytes. In ad-
dition, version 8.3.8 provides an optimal format for internal data stor-
age. Size of the internal file cannot exceed 4 GB (with page size of 4
096 bytes) or 6 GB (with page size of 8 192, 16 384, 32 768, or 65
536 bytes).
1C:Enterprise 8.3.8 and later is compatible with 1Cv8.1CD files of any
format. 1C:Enterprise 8.3.7 and earlier is compatible with 1Cv8.1CD files
of version 8.2.14 only. Conversion between the two formats is possible ei-
ther through dumping/restoring the infobase to the .dt file or by using the
cnvdbfl utility.
The cnvdbfl command-line utility allows to:
1. Convert the 1Cv8.1CD files between different formats
2. Resize the file page for 8.3.8 format
To run the utility, use this command line:
cnvdbfl <keys> <path to 1CV8.1CD>

The keys are:

• --help or -h
Displays brief information about the utility.
• --version or -v
Displays version of the utility.
• --info or -i
Displays information about the format of 1Cv8.1CD. For the database
files that have not been used with 1C:Enterprise 8.2.14 or later, file in-
formation cannot be displayed; a diagnostic message is displayed in-
stead.
• --convert or -c
Converts 1Cv8.1CD file. If the command is used without parameters,
the file is converted to 8.3.8 format with a page size of 8192 bytes.
One of the following parameters should be specified:
 --format=<format> or -f <format>
Used to specify the format into which the 1Cv8.1CD file should be
converted. The <format (format)> can have the following val-
ues:
  8.2.14 - Execute conversion into format 8.2.14.
 8.3.8- Execute conversion into format 8.3.8.
 --page=<page size> or –p <Page size>
Serves for specifying a page size for format 8.3.8. A default value
- 8192. When specifying the parameter –f 8.2.14, this parameter is
ignored. <page size> can have the following values:
 4096 or 4K
 8192 or 8K
 16384 or 16K
 32768 or 32K
 65536 or 64K
For examples of using the utility, see below.
Convert to 8.2.14 format:
cnvdbfl -c -f 8.2.14 c:\temp\1cv8.1cd

Convert to 8.3.8 format with default page size:

cnvdbfl -c -f 8.3.8 c:\temp\1cv8.1cd

Convert to 8.3.8 format with page size of 16K:

cnvdbfl -c -f 8.3.8 -p 16k c:\temp\1cv8.1cd

Get information about 1Cv8.1CD:

cnvdbfl -i c:\temp\1cv8.1cd

4.4. Ring utility

4.4.1. General information
The ring utility - is a cross-platform console (not having a graphical inter-
face) utility for managing the local configuration of the 1C: Enterprise sys-
tem processes and for performing various operations necessary to support
the performing system.
The utility ring has a module architecture. A module - is a set of overall
(within the meaning or actions performed) functionality accessed through
commands. A number of commands per module is unlimited. A command -
is a sort of action that has a certain set of parameters (or without them). One
call to the ring utility leads to an execution of a single command of one
module. The utility can use several modules at the same time.
A list of the installed and used modules is stored in the registry of module
instances (ring-commands.cfg).
 Parameters that are passed to commands cannot contain spaces. If the pa-
rameter value contains a space, - this value must be enclosed in quotation
marks.
An overall scheme of the command call:
ring <module> <command> [--parameter "parameter value"]

In the above scheme of calling the command:

• ring - The utility name.
• <module> - The module name.
• <command> - The executed command name.
• --parameter - A parameter and its value for a command. A num-
ber of parameters as well as mandatory and optional parameters, de-
fault values, etc. are determined for each command individually.
When using modules and commands with the ring utility on Windows,
keep in mind that the command-line characters must not exceed 8 bits. If
you use a language with characters exceeding this limit, it is recommended
to select the appropriate replacement for these characters. For example, in-
stead of the character “ə”, use “a” or “e”.

4.4.2. System requirements

The ring utility is supported on the same operating systems as the 1C:
Enterprise itself. The utility ring is accessible in both 32-- and 64-bit ver-
sions.
Additionally, the ring utility requires for functioning:
• Java 8 or later
(http://www.java.com/en/download/).http://www.java.com/ru/downlo
ad/

4.4.3. Installing the utility

Utility installation is executed when installing other products that require
this utility. Other products may be modules of the ring utility or include
modules for this utility.
The ring utility without modules installed does not have any practical val-
ue, so installing the ring utility separately is not supported.

4.4.4. Use recommendations

4.4.4.1. Setting a utility display language
ring utility displays information in a language selected by the operating
system. For information concerning the way interface language can be
changed in, see documentation related to the operating system you use.
 If ring utility has to display information in a language which is different
from that specified in the operating system settings, in RING_OPTS envi-
ronment variable specify -Duser.country=ru -Duser.language=RU pa-
rameter. If RING_OPTS variable has already been assigned a value, add a
space and further the said string.
For an example of environment variable specified using a command line,
see below:
• On Windows OS:
set RING_OPTS=-Duser.country=ru -Duser.language=RU

• On Linux OS (bash command processor):

export RING_OPTS=-Duser.country=ru -Duser.language=RU

The utility supports the following two output languages: Russian and Eng-
lish.

4.4.4.2. Incorrect utility output

Make sure that Consolas or any other True Type font is specified for the
terminal which supports Unicode. Make sure that you have selected a prop-
er language in the operating system for programs failing to support
Unicode. Whenever this setting is modified, you need to reload your com-
puter for it to become valid.
If operating system settings cannot be modified, when you use Consolas
font before starting ring, run a command intended to change a code page
and specify a code page which is relevant to your language, for example:
chcp 1251

4.4.4.3. Selecting coding upon redirection

of utility output in a file
When you use Windows OS and redirect ring utility display in a file, un-
readable symbols can be present in a file. This is due to the fact that lan-
guage settings for programs failing to support Unicode are incompatible
with those in the system interface. You can obtain data in a file in readable
format by any of the following methods.
• Set a language for programs failing to support Unicode being compat-
ible with interface language.
• Use UTF-8 coding and RING_OPTS environment variable.
4.5. Licensing utility
4.5.1. General information
The licensing utility is designed to execute the following tasks:
• Initial license acquisition
• License reacquisition and renewal
• Checking license validity for the current computer
• Displaying the license list
• Getting information about a license
• Deleting a license
• Updating the license
When describing the licensing utility, the term "license storage" is used.
License storage is a directory where the files with the activated software
licenses are located. Depending on the operating system in use, the licens-
ing utility uses the following directories as a license storage by default:
• Windows OS: %ALLUSERSPROFILE%\1C\licenses (%Pro-
gramData%\1C\licenses for Windows Vista and later)
• Linux: /var/1C/licenses
When displaying licenses, a unified presentation is used: PIN code-number.
So, if pincode 123-456-789-012 can be applied to a software license and
this license is used for the product with the registration number
8000314159, this license will be displayed as: 123456789012-8000314159.
This name must be used whenever a command of the licensing utility re-
quires the license name as a parameter.
Two software license activation methods are available:
1. Usage of the activate command. In this case, activation occurs
immediately through the web service of the licensing center, without
generating intermediate files.
2. Usage of the prepare-request, acquire and generate
commands in sequence. In this case, a request file for the licensing
center (the prepare-request command) is prepared, then a re-
quest to the licensing center is made (via e-mail), and a response of
the licensing center (as a file) is received. Also, a response file from
the licensing center can be generated via a web service, without using
e-mail (the acquire command). Then, based on the request and re-
sponse, a license file (the generate command) is acquired.

4.5.2. System requirements

In fact, the licensing utility is a separate module that requires the ring util-
ity to its execution. The module is called license. From the point of view
of the actions executed, the "license module" and "licensing utility" are
interchangeable terms. From a technical point of view, the "licensing utili-
ty" - is the ring utility and the license module, and the "license
module" - is a separate module that requires the ring utility for its opera-
tion.
The license module requires the installed ring utility. The license
module is available in 32-- and 64-bit versions.
For work of the license module, you need:
• ring utility 0.8.2 or later
• JCE for Java 8
(http://www.oracle.com/technetwork/java/javase/downloads/jc
e8-download-2133166.html) or correct Java configuration file (de-
pending on Java version).
• On Windows OS: Windows Script Host system running on the com-
puter on which the license module is started

4.5.3. Installing the module

4.5.3.1. Installing the module
The distribution package of the licensing utility is delivered together with
the distribution package of the 1C:Enterprise system in the form of a file.
The distribution package file has a name of the 1c-enterprise-license-
tools-a.b.c +d-OS-arch.ext kind, where:
• a.b.c+d - this is the full number of the utility supplied in the distribu-
tion package, which corresponds to the number in the a.b.c.d kind.
• OS - operating system for which the utility distribution package is de-
signed:
 windows - the distribution package is designed for Windows OS.
 linux - the distribution package is designed for Linux OS.
• arch - Module architecture. Can take values:
 Windows OS:
 x86 - a module of the 32-bit version;
 x64 - a module of the 64-bit version.
 Linux:
 i386 - a module of the 32-bit version;
 x86_64/amd64- The 64-bit version of the utility (for the
.rpm/.deb packets).
• ext - file extension with distribution package:
 Windows - zip.
 Linux - tar.gz.
To install the utility, you need to unzip the archive with the distribution
package in the temporary directory (including all subdirectories) and then
run the 1ce-installer/1ce-installer-cli file. After the com-
mand is executed, the 1C:Enterprise installer will be started. Details of op-
eration with this installer (both in graphical and in console version) can be
got on ITS (https://its.1c.ru/db/inst10doc).
After a module is installed, its registration in the registry of module instanc-
es can be verified.

4.5.3.2. Configuring Java

For the licensing utility to work correctly, depending on the version of Java
used, some additional settings must be made:
• Java version is younger than 1.8 update 151 - you need to install JCE.
• Java version is equal to or older than 1.8 update 151 - two options are
possible:
 Set the crypto.policy parameter in the java.security file to
unlimited (add the line crypto.policy=unlimited to
this configuration file or remove the comment from this line).
 Install JCE.
• Java 9 version and older - Set the crypto.policy parameter in the
java.security file to unlimited (add the line
crypto.policy=unlimited to this configuration file or remove
the comment from this line).
Depending on the Java version and the Java version in use, the ja-
va.security configuration file is located in different places:
• Java 1.8:
 JDK - %JAVA_HOME%\jre\lib\security.
 JRE - %JAVA_HOME%\lib\security.
• Java 9 or later: %JAVA_HOME%\conf\security.

4.5.4. Module commands

4.5.4.1. Activate
License activation using a licensing center web service.
 Command line:
ring license activate --first-name <name> --middle-name <middle
name> --last-name <last name> [--email <email>] --company <company>
--country <country> --zip-code <zip code> [--region <region> --
district <district>] --town <town> --street <street> --house
<house> --building <building> --apartment <apartment> --serial
<serial number> --pin <PIN> [--previous-pin <previous PIN>] [--path
<path>] [--validate] [--conf-location <path>] [--send-statistics
<mode>]

A description of parameters:
• first-name - is the first name of a licensee. This parameter is op-
tional if company parameter is specified.
• middle-name - is the middle name of a licensee. This parameter is
optional if company parameter is specified.
• last-name - is the last name of a licensee. This parameter is op-
tional if company parameter is specified.
• email - is the email address of a licensee.
• company - is the company of a licensee. When specifying the param-
eters first-name, middle-name, last-name this parameter is
optional. At least 5 characters are required, but there should not be
more than 3 identical characters in a row.
• country - A country of registration. Cannot be empty.
• zip-code - Zip code. Cannot be empty.
• region - Province/region/area.
• district - District.
• town - Town. Cannot be empty.
• street - Street. Cannot be empty.
• house - A house number. When specifying the building or
apartment parameters, this parameter is optional. Cannot be empty.
• building - Building. When specifying the house or apartment
parameters, this parameter is optional. Cannot be empty.
• apartment - Apartment. When specifying the house or
building parameters, this parameter is optional. Cannot be empty.
• serial - A serial number of a software product.
• pin - A pincode used at activating license.
• The previous-pin - When re-activating a license, this parameter
should contain the pincode that was used during the initial activation
of license. Mustn't coincide with the parameter value pin.
• path - Specifies a path to the license repository if it differs the de-
fault path.
 • If validate - is specified, then the execution of a command will be
completed with an error if an attempt to get any of the key parameters
resulted in a runtime error. If a parameter is not specified, the occur-
rence of an error when receiving any key parameter will not prevent a
license from its successful activation. However, the license fields cor-
responding to the parameters not received will be filled with empty
values which will make it impossible to continue using the activated
license.
• conf-location - specifies a directory with conf.cfg configuration
file. This file analyzes ExternalResourcesMode parameter,
which selects the applied licensing centre address.
If this parameter is blank or the specified directory does not contain
conf.cfg file, the search for this file is performed in the following di-
rectories:
 On Windows:
 32-bit application in the 64-bit OS:
%PROGRAMFILES(x86)%\1cv8\conf.
 Otherwise: %PROGRAMFILES%\1cv8\conf.
 On Linux:
 Directory ~/.1cv8/1C/1cv8/conf (~ - home directory of the
user, on behalf of which the 1C:Enterprise server operates).
• send-statistics - sends statistical information to 1C:Remote
service (pult.1c.com, port 443). <mode> parameter can have the fol-
lowing values:
 true - information is sent. Default value.
 false - information is not sent.
Result:
Upon successful registration, server returns a license file, which is placed in
the specified storage. When the identical data (including kit data) is re-
entered on the same machine, a similar license file is generated.
If successful, the utility returns 0. Otherwise, the return code is not 0 and an
error message is generated in the standard output stream.

4.5.4.2. Prepare-request
If a software license cannot be activated using the web service of the licens-
ing center, you can activate the license by sending an email to the licensing
center. To do this, the prepare-request, acquire and generate
commands are used in the specified order.
The prepare-request command prepares the file for transfer to the
Licensing Center.
 Command line:
ring license prepare-request --first-name <first name> --middle-
name <middle name> --last-name <last name> [--email <email>] --
company <company> --country <country> --zip-code <zip code> [--
region <region> --district <district>] --town <town> --street
<street> --house <house> --building <building> --apartment
<apartment> --serial <serial number> --pin <PIN> [--previous-pin
<previous PIN> --request <file>] --validate [--send-statistics
<mode>]

A description of parameters:
• first-name - is the first name of a licensee. This parameter is op-
tional if company parameter is specified.
• middle-name - is the middle name of a licensee. This parameter is
optional if company parameter is specified.
• last-name - is the last name of a licensee. This parameter is op-
tional if company parameter is specified.
• email - is the email address of a licensee.
• company - is the company of a licensee. When specifying the param-
eters first-name, middle-name, last-name this parameter is
optional. At least 5 characters are required, but there should not be
more than 3 identical characters in a row.
• country - A country of registration. Cannot be empty.
• zip-code - Zip code. Cannot be empty.
• region - Province/region/area.
• district - District.
• town - Town. Cannot be empty.
• street - Street. Cannot be empty.
• house - A house number. When specifying the building or
apartment parameters, this parameter is optional. Cannot be empty.
• building - Building. When specifying the house or apartment
parameters, this parameter is optional. Cannot be empty.
• apartment - Apartment. When specifying the house or
building parameters, this parameter is optional. Cannot be empty.
• serial - A serial number of a software product.
• pin - A pincode used at activating license.
• The previous-pin - When re-activating a license, this parameter
should contain the pincode that was used during the initial activation
of license. Mustn't coincide with the parameter value pin.
• The request - specifies a full path to the file in which information
will be placed for transmission to the Licensing Center. If not speci-
 fied, then the request text to the Licensing Center will be output to the
standard output stream.
• If validate - is specified, then the execution of a command will be
completed with an error if an attempt to get any of the key parameters
resulted in a runtime error. If a parameter is not specified, the occur-
rence of an error when receiving any key parameter will not prevent a
license from its successful activation. However, the license fields cor-
responding to the parameters not received will be filled with empty
values which will make it impossible to continue using the activated
license.
• send-statistics - sends statistical information to 1C:Remote
service (pult.1c.com, port 443). <mode> parameter can have the fol-
lowing values:
 true - information is sent. Default value.
 false - information is not sent.
Result:
Content of the Licensing Center request file is generated and written to a
file or standard output stream.
If successful, the utility returns 0. Otherwise, the return code is not 0 and an
error message is generated in the standard output stream.

4.5.4.3. Acquire
The command generates a response file based on a previously generated
request file using the Licensing Center's web service.
Command line:
ring license acquire [--request <RequestFile>] [--response
<ResponseFile>] [--conf-location] [--send-statistics <mode>]

A description of parameters:
• request - Is a full name of the file with the request to the Licensing
Center. If a parameter is not specified, then the content of the request
file is expected from the standard input stream.
• response - Is a full name of the file to which a response from the
License Center will be posted. If a parameter is not specified, then the
contents of the response file will be output to the standard output
stream.
• conf-location - specifies a directory with conf.cfg configuration
file. This file analyzes ExternalResourcesMode parameter,
which selects the applied licensing centre address.
 If this parameter is blank or the specified directory does not contain
conf.cfg file, the search for this file is performed in the following di-
rectories:
 On Windows:
 32-bit application in the 64-bit OS:
%PROGRAMFILES(x86)%\1cv8\conf.
 Otherwise: %PROGRAMFILES%\1cv8\conf.
 On Linux:
 Directory ~/.1cv8/1C/1cv8/conf (~ - home directory of the
user, on behalf of which the 1C:Enterprise server operates).
• send-statistics - sends statistical information to 1C:Remote
service (pult.1c.com, port 443). <mode> parameter can have the fol-
lowing values:
 true - information is sent. Default value.
 false - information is not sent.
Result:
A Licensing Center's response
If successful, the utility returns 0. Otherwise, the return code is not 0 and an
error message is generated in the standard output stream.

4.5.4.4. The generate command

A command is intended to generate a license file based on data from a re-
quest to the Licensing Center and its (center) response.
Command line:
ring license generate --license <LicenseFile> --request
<RequestFile> --response <ResponseFile> [--send-statistics <mode>]

A description of parameters:
• license - Is a full name of the file with a resulting license. If a pa-
rameter is not specified, then the contents of the file of the activated
license is output to the standard output stream.
• request - Is a full name of the file with the request to the Licensing
Center.
• response - Is a full name of the file to which a response from the
License Center will be posted.
• send-statistics - sends statistical information to 1C:Remote
service (pult.1c.com, port 443). <mode> parameter can have the fol-
lowing values:
 true - information is sent. Default value.
 false - information is not sent.
 Result:
A file with an activated license.
If successful, the utility returns 0. Otherwise, the return code is not 0 and an
error message is generated in the standard output stream.

4.5.4.5. The command list

The command is intended to display a list of licenses in the license reposito-
ry.
Command line:
ring license list [--path <path>] [--send-statistics <mode>]

A description of parameters:
• path - Specifies a path to the license repository if it differs the de-
fault path.
• send-statistics - sends statistical information to 1C:Remote
service (pult.1c.com, port 443). <mode> parameter can have the fol-
lowing values:
 true - information is sent. Default value.
 false - information is not sent.
Result:
A list of the license names found.

4.5.4.6. The command info

Displays information about the specified license.
Command line:
ring license info [--name <name>] [--path <path>] [--send-
statistics <mode>]

A description of parameters:
• name - Is a name of a license for which information is expected. If
this parameter is absent, then the system expects from the standard in-
put stream the contents (not the name!) of a file with the activated li-
cense.
• path - Specifies a path to the license repository if it differs the de-
fault path.
• send-statistics - sends statistical information to 1C:Remote
service (pult.1c.com, port 443). <mode> parameter can have the fol-
lowing values:
 true - information is sent. Default value.
 false - information is not sent.
 Result:
License information in the following format:
Information about user:
Name :
Middle Name :
Last Name :
Country :
Zip code :
City :
Street :
Apartment/Office :
Product information :
Date of equipment :
Description :
Registration number :
Product code :

The current computer hardware is not validated to match the hardware used
to activate a license.

4.5.4.7. Validate
Checks whether the current computer hardware matches the hardware regis-
tered at the moment of license activation.
Command line:
ring license validate [--name <name>] [--path <path>] [--send-
statistics <mode>]

A description of parameters:
• name - Is a name of a license for which information is expected. If
this parameter is absent, then the system expects from the standard in-
put stream the contents (not the name!) of a file with the activated li-
cense.
• path - Specifies a path to the license repository if it differs the de-
fault path.
• send-statistics - sends statistical information to 1C:Remote
service (pult.1c.com, port 443). <mode> parameter can have the fol-
lowing values:
 true - information is sent. Default value.
 false - information is not sent.
Result:
Confirmation that the computer hardware matches the hardware registered
at the moment of license activation, or a list of differences (if the hardware
lists are different).
 If successful, the utility returns 0. Otherwise, the return code is not 0 and an
error message is generated in the standard output stream. Some situations
are highlighted by special error codes:
• 1 - The computer parameters changed;
• 2 -An error in verifying the digital signature of a license.

4.5.4.8. The command put

Places a selected file with the activated license into the specified license
repository.
Command line:
ring license put --license <FullName> [--path <storage>] [--send-
statistics <mode>]

A description of parameters:
• license - A full path to a file of the activated license that will be
placed in the license repository.
• path - Specifies a path to the license repository if it differs the de-
fault path.
• send-statistics - sends statistical information to 1C:Remote
service (pult.1c.com, port 443). <mode> parameter can have the fol-
lowing values:
 true - information is sent. Default value.
 false - information is not sent.
Result:
Places the specified file with the activated license in the specified (explicitly
or implicitly) license repository.
If successful, the utility returns 0. Otherwise, the return code is different
from 0.

4.5.4.9. Get
Obtains an activated license from a license repository and writes it to a file.
Command line:
ring license get -name <name> [--license <FullName>] [--path
<storage>] [--send-statistics <mode>]

A description of parameters:
• name - Is a name of a license for which information is expected.
• license - A full path to the file in which the received license will
be written. If not specified - , the contents of the license file is output
to the standard output stream.
 • path - Specifies a path to the license repository if it differs the de-
fault path.
• send-statistics - sends statistical information to 1C:Remote
service (pult.1c.com, port 443). <mode> parameter can have the fol-
lowing values:
 true - information is sent. Default value.
 false - information is not sent.
Result:
Obtains an activated license from a repository and writes it to a file with the
specified name.
If successful, the utility returns 0. Otherwise, the return code is different
from 0.

4.5.4.10. Remove
Removes a license from a license repository.
Command line:
ring license remove -name <name> [--path <storage>] [--all] [--
send-statistics <mode>]

A description of parameters:
• name - Is the name of a license to be removed from a repository.
• path - Specifies a path to the license repository if it differs the de-
fault path.
• all - delete all licenses with the given name in the storage.
• send-statistics - sends statistical information to 1C:Remote
service (pult.1c.com, port 443). <mode> parameter can have the fol-
lowing values:
 true - information is sent. Default value.
 false - information is not sent.
Result:
A license is removed from the license repository.
If successful, the utility returns 0. Otherwise, the return code is different
from 0.

4.5.4.11. update
Updates (re-obtains) all licenses from the license storage. License update
means re-obtaining a license in the licensing center with the same parame-
ters: registration number, PIN, key parameters. Files with activated software
licenses that exist before the update are saved with the .oldlic extension for
backup purposes.
 Command line:
ring license update --conf-location <ConfigurationFile> [--force
<value>] [--path <storage>] [--validate] [--send-statistics <mode>]

A description of parameters:
• conf-location - platform configuration file location directory.
Used to search for the conf.cfg configuration file, which analyzes the
ExternalResourcesMode parameter. If the parameter is not
specified or the conf.cfg file is missing in the specified directory, an
attempt will be made to find the conf.cfg file in the following directo-
ries:
 On Windows OS:
 32-bit application in the 64-bit OS:
%PROGRAMFILES(x86)%\1cv8\conf.
 Otherwise: %PROGRAMFILES%\1cv8\conf.
 On Linux:
 ~/.1cv8/1C/1cv8/conf (~ directory - user's home directory
on behalf of whom the licensing utility is run).
• force - defines the behavior of the licensing utility if errors occurred
during the license update. The parameter can take the following val-
ues:
 true - the error is ignored and the file during the processing of
which the error occurred is skipped. Processing continues.
 false - file processing is interrupted, all licenses are restored
from the backups (default value).
• path - Specifies a path to the license repository if it differs the de-
fault path.
• validate - indicates whether to check the hardware data received
from the system. The parameter can take values:
 true - check.
 false - do not check (default value).
• send-statistics - sends statistical information to 1C:Remote
service (pult.1c.com, port 443). <mode> parameter can have the fol-
lowing values:
 true - information is sent. Default value.
 false - information is not sent.
Result:
All licenses in the license storage is updated.
If successful, the utility returns 0. Otherwise, the return code is different
from 0.
 4.5.4.12. Information for 1C:Remote Service
The following data is sent to 1C:Remote service:
• OS type: Windows or Linux.
• OS full name.
• Architecture of a computer running a utility.
• Version of a licensing utility so started.
• Architecture of a licensing utility so started.
• Version of Java managing the said utility.
• Name of a licensing utility command being executed.
• UUID generated on the basis of the following data (hash in UUID
format):
 computer MAC address;
 utility version;
 utility architecture.
• Data batch ID.
• Computer UUID generated on the basis of server MAC address (hash
in UUID format).
• Command execution date and time.

4.6. Administrative console

utility 1cv8a
The administrative console utility (1cv8a) is intended to speed up verifica-
tion and correction of certain issues:
• Verifying and fixing the exchange plan node tables.
• Verifying and fixing the hash fields of the infobase tables.
The administrative console utility allows to fix some infobase issues with-
out starting Designer and in a shorter time. This is thanks to the fact that the
administrative console utility processes only the problematic objects and at
the same time performs a limited set of fixes.
To run the utility, use this command line:
1cv8a <modes> <keys>

The modes are as follows:

• help [режим] or h [режим]
Displays brief information about the utility or a mode of operation.
• ib-check-and-repair oribcr
Verifies and repairs data.
The following parameters can be specified:
 --repair or -r
Indicates that the errors will be repaired.
 --exchange-plan-integrity or-epi
 Verifies and repairs the exchange plan node tables.
 --exchange-plan-integrity-outFile=<XML file name> or -
epiof <XML file name>
Specifies a name of the XML file used for saving status of
ThisNode records of the exchange plans. This parameter is
required when executing the command with the --exchange-
plan-integrity parameter.
 --dimhash-integrity or -dhi
Recalculates totals to eliminate incorrect totals calculations for
the accumulation registers and accounting registers if at least
one dimension has String type and the dimension index con-
tains more than 16 database fields. A recalculation of the total
is performed only if the --repair parameter is used simultane-
ously with the --dimhash-integrity parameter. If the --repair
parameter is not specified -, then only a verification of the fact
that there are the incorrect totals of the accumulation registers
and accounting in infobase is performed.
 --connection-string=<string>
Specifies an infobase connection string.
 --file=<path> or -f <path>
Specifies a path to the file infobase directory.
 --server=<server:port/infobase> or -
s <server:port/infobase>
Specifies client/server infobase connection parameters.
 --user=<name> or -u <name> or -n <name>
Specifies a name of the user on whose behalf a connection to
infobase will be performed.
 --password=<password> or –p <password>
Specifies a password of the infobase user on whose behalf a
connection to infobase will be performed.
 --unlock-code=<code>
Specifies a permission code for connecting to infobase (if spec-
ified).
 --security-level=<level>
Indicates security level of a server connection.
 --verbose
Indicates whether detailed progress messages will be displayed.
 4.7. Running Designer in
agent mode
4.7.1. General information
Agent mode - Is a special version of the packet mode of launching Design-
er in which it (Designer) performs the functions of SSH- and the SFTP
server and accepts commands using these protocols.
When working in the agent mode, Designer can work only with one in-
fobase at a time. If there is a need to work simultaneously with several in-
fobases -, then it is necessary to launch several Designers in the agent mode.
An overall scheme of work in the agent mode is, as follows:
1. Designer is started in the agent mode.
2. A remote computer connects to the agent.
3. Files are exchanged with the agent over the SFTP client.
4. Commands to the agent are sent and results obtained over the SSH cli-
ent.
When in the agent mode, Designer provides a specific set of commands to
be discussed further in this section. All commands are executed interactive-
ly and concurrently. While executing a command, you cannot know its pre-
cise execution status. All messages generated after commands are executed
are completely identical to the messages generated when the similar com-
mands are executed in the Designer batch mode.
login as: adminadmin

admin@localhost's password:

1C:Enterprise 8.3 1C Designer Shell © 1C LLC 1996-2018

designer>

A result of the command performance in the agent mode can be presented in

two formats: text format (default), and JSON message format. When in the
JSON message format, server always returns an array of information about
work results. A special command is used to select format for work results.
At the end of processing all commands, the Designer agent sends a message
of the success, error, cancel or question kinds. The help com-
mand sends a message of the success kind at the end; and when an un-
known command - is entered, it sends a message of the error kind.
In order to start the agent mode, the following command should be execut-
ed:
1cv8 DESIGNER <infobase> /AgentMode [agent mode parameters]
[/Visible].

When entering a startup command line, consider the following:

 • To specify an infobase, any of the following methods can be used: pa-
rameter /IBName, /F or /S. Do not specify the parameters defining
username and password for accessing the infobase; these parameters
will be ignored. Login and password will be required in response to
the corresponding requests in the remote access console. It is not rec-
ommended to connect to an infobase in the agent mode on behalf of a
user whose name includes national characters.
• If the /AgentMode parameter is found in the command line, Designer
will ignore all parameters except: agent mode parameters; parameters
specifying infobase; parameter /Visible.
• Specifying the /Visible parameter causes a special window to appear
on the screen. This window is used to quit the agent mode. If Designer
is started without this parameter, you have to use the remote access
command line to quit the agent mode .
While Designer runs in agent mode, one client can be connected via SSH
and several clients via SFTP.

4.7.2. List of commands

The following commands are available in the agent mode:
• The command help.
• A group of commands overall - overall commands.
• A group of commands options - commands working with settings.
• A group of commands config - commands of editing configuration.
• A group of commands tools - server commands of working with in-
fobase.
Within this section, it is assumed that all commands return results in text
format. As an example of returning the JSON messages, the output of the
help command will be considered. It should also be clear that agent com-
mands – including commands for receiving reference information – will be
returned in the JSON message format.
It should be remembered that all examples given in this section are not
complete structures and are intended only to demonstrate performance of
the reviewed mechanisms or methods.

4.7.3. help
This command displays help information. The help command with no
parameters displays general information on using the agent mode.
designer> help
Usage:

help [options] [arguments]

General parameters:

--version | -v
Gets version of the utility

Mode:

help (h)
Displays help information for the specified mode.

Arguments:
MODE
The mode for which information needs to be obtained about
keys of the command line

Supported modes:

help Displays help information for the specified

mode.
common Common commands
options Settings management
config Configuration mode
infobase-tools Infobase utility commands
designer>

If more specific information about a group of commands or a particular

command is required, then all this information should be entered after the
keyword help. For example, to get information about the group of com-
mands options, execute the help options command.
designer> help options
Usage:

options [command] [options]

General parameters:

--version | -v
Gets version of the utility

Mode:

options
Settings management

Commands:

list
Displays values of all settings

get
Gets a value of a setting

--output-format
Output format

--show-prompt
Shows the command-line prompt

set
Sets a value of a setting

--output-format=<text|json>
Output format

--show-prompt=<yes|no>
Shows the command-line prompt
designer>

To get 1C:Enterprise version while in the agent mode, execute the help –
version command.
designer> help --version
8.3.10.2000
designer>

If output format is set to JSON messages, the following information about

the 1C:Enterprise version will be displayed:
designer> options set --output-format=json
[
{
"type": "success",
"message" ""
}
]
designer> help --version
[
{
"type": "success",
"body": "8.3.10.1772"
}
]
designer>

In this example, the first command (options set ...) sets the output
format, and the second command gets the 1C:Enterprise version.

4.7.4. Common group

commands
Commands of the common group are responsible for general operations. A
group includes the following commands:
• connect-ib - Connect to infobase the parameters of which are
specified at launching the agent mode.
• disconnect-ib - Disconnect from infobase which was previously
connected using the connect-ib command.
• shutdown - The shutdown Designer in the agent mode.
The commands of this group have no parameters.

4.7.5. Options group

commands
4.7.5.1. Command group purpose
The commands of the options group are responsible for managing set-
tings of the current session. A group includes the following commands:

4.7.5.2. list
Using this command, you can view a list of parameters and their (parame-
ters) current status.

4.7.5.3. get
This command allows you to get parameter values. The following parame-
ters are available for the command:
 • --output-format - allows to specify a output format of the com-
mand's performance:
 text - Commands return a result in the text format.
 json - Commands return a result in a format of the JSON mes-
sages.
• --show-prompt - Allows to control a presence of the designer>
command line prompt:
 yes - There is a prompt in a command line;
 no - There is no prompt in a command line.
• --notify-progress - allows you to get information about the
display of the progress of the command execution.
• --notify-progress-interval - allows you to get the time in-
terval through which the information about progress is updated.

4.7.5.4. set
This command allows you to set parameter values. The following parame-
ters are available for the command:
• --output-format - allows to specify a output format of the com-
mand's performance:
 text - Commands return a result in the text format.
 json - Commands return a result in a format of the JSON mes-
sages.
• --show-prompt - Allows to control a presence of the designer>
command line prompt:
 yes - There is a prompt in a command line;
 no - There is no prompt in a command line.
• --notify-progress - allows you to manage the output of infor-
mation about the progress of the command execution:
 yes - progress displays;
 no - progress does not display (default value).
• --notify-progress-interval - allows you to specify the
time interval through which the information about progress is updated.
The value is set with an accuracy of 0.1 seconds. The default value is
1 second. Violation of accuracy leads to generation of the
CommandLineFormaError error.
4.7.6. The commands of a
group config
4.7.6.1. Command group purpose
The commands of aconfig group are responsible for configuration edit-
ing.

4.7.6.2. dump-config-to-files
The command allows you to export the configuration to xml files. The fol-
lowing parameters are available for the command:
• --dir <path> - Contains a path to a directory to which a configu-
ration will be exported. A parameter is obligatory.
• --extension <extension name> - Contains the name of ex-
tension that will be exported to files.
• --all-extensions - If a parameter is specified, then all the con-
figuration extensions will be exported to files.
• --format [hierarchical|plain] - Determines the export-
ing format. A hierarchy (hierarchical) The exporting format is
used by default.
• --update - To update the existing exporting. In this case, only those
objects whose versions differ from the versions specified in the Con-
figDumpInfo.xml file will be exported.
• --force - To perform a full exporting if, when trying to update ex-
porting (parameter update) it turned out that the current version of
the exporting format does not match a version of the exporting format
specified in the ConfigDumpInfo.xml file.
• --get-changes <path> - To generate a file that contains chang-
es between current and specified exporting of a configuration.
• --config-dump-info-for-changes <path> - Is a path to
the ConfigDumpInfo.xml file which is used to generate the change
file between the two instances of exporting a configuration.
• --list-file <file> - To export only the metadata objects
and/or the external properties specified in a file regardless of whether
they were changed or not.

4.7.6.3. load-config-from-files
The command allows you to import the configuration to xml files. The fol-
lowing parameters are available for the command:
• --dir <path> - Contains a path to the directory from which a con-
figuration will be loaded. A parameter is obligatory.
 • --extension <extension name> - Contains a name of the
extension that will be loaded from files.
• --all-extensions - If a parameter is specified, then all configu-
ration extensions will be loaded from the files.
• --format [hierarchical|plain] - Determines the export-
ing format. A hierarchy (hierarchical) The exporting format is
used by default.
• --files <File[, file]> - A list of files to be loaded. File-
names are separated by commas. File paths are relative to the down-
load directory. Absolute paths are not supported. When using the --
list-file parameter, it is not used.
• --list-file <file> - A path to the file that lists the download-
ing files. One line corresponds to one file. File paths are relative to the
download directory. Absolute paths are not supported. When using the
--files parameter, it is not used.
• --update-config-dump-info - After downloading is finished,
to create in the directory the ConfigDumpInfo.xml file corresponding
to the loaded configuration.

4.7.6.4. dump-cfg
The command allows you to export the configuration or extension to the
file. The following parameters are available for the command:
• --file <path> - path to the configuration file (cf-file) or exten-
sion (cfe-file).
• --extension <extension name> - contains the extension
name that will be exported to the file.

4.7.6.5. load-cfg
The command allows you to import the configuration or extension from the
file. The following parameters are available for the command:
• --file <path> - path to the configuration file (cf-file) or exten-
sion (cfe-file).
• --extension <extension name> - contains the extension
name that will be imported from the file.

4.7.6.6. dump-external-data-processor-or-
report-to-files
The command allows you to export external processings or reports to xml
files. The following parameters are available for the command:
• --file <file> - Contains the name of a file that will act as the
root file of uploading the external data processor/report upload in the
XML format. A parameter is obligatory.
 • --ext-file <file> - Is a full name of the file with the exporting
external data processor (* .epf) or report (* .erf).
• --format [hierarchical|plain] - Determines the export-
ing format. A hierarchy (hierarchical) The exporting format is
used by default.

4.7.6.7. load-external-data-processor-or-
report-from-files
The command allows you to import external processings or reports from
xml files. The following parameters are available for the command:
• --file <file> - Contains a name of the file that is the root file of
exporting the external data processor/report in the XML format. A pa-
rameter is obligatory.
• --ext-file <file> - A full file name with loadable external da-
ta processor (* .epf) or report (* .erf).

4.7.6.8. update-db-cfg
The command allows you to update the database configuration. The follow-
ing parameters are available for the command:
• --prompt-confirmation - Determines a need for requesting a
user to confirm acceptance of changes during restructurization of in-
fobase.
• --dynamic-enable - Initially, it tries a dynamic update; if the at-
tempt fails, a background update will be started.
• --dynamic-disable - By specifying this parameter a dynamic
update is disabled.
• --warnings-as-errors - If this parameter is specified, then all
warnings that may occur when updating the database configuration
will be considered errors.
• --background-start - If this parameter is specified, a back-
ground configuration update will be launched and the current session
will be terminated.
• --background-cancel -If this parameter is specified, then the
launched background configuration database update will be canceled.
• --background-finish - If this parameter is specified, then the
launched background configuration update of database will be com-
pleted. At the same time an exclusive lock will be imposed on data-
base and the final phase of updating will be carried out.
• --background-resume - If this parameter is specified, then a
system continues the previously suspended background database con-
figuration update.
 • --server - This parameter indicates that the database configuration
update must be performed on the 1C: Enterprise server side.
• --extension <extension name)> - extension name.
When the update-db-cfg command is being executed, the following
operation algorithm is used:
• In the event that it is impossible to exclusively lock the database and a
dynamic update is possible (the --dynamic-disable parameter is
not specified) -, the dynamic update of the database configuration will
be performed.
• In the event that it is possible to exclusively lock the database but re-
structuring of database is not required -, then the usual database con-
figuration update will be performed.
• In the event that it is possible to exclusively lock the database but re-
structuring of database is required, then some actions will be per-
formed in the following sequence:
 A list of changed objects is created
 A resulting list is displayed in the console;
 If there is a need to confirm a user for accepting changes (parame-
ter --prompt-confirmation) -, then a user is asked a corre-
sponding question;
 If an answer to a question is negative -, then an update is canceled
with the issuance of a corresponding notification;
 If an answer is positive or a request was not needed -, then an up-
date continues , as planned.

4.7.6.9. mobile-app-write-file
The command allows you to save the configuration for creating a mobile
application in an xml file. The following parameters are available for the
command:
• --file <filename> - a name of a file to save configuration to.

4.7.6.10. mobile-client-write-file
The command allows you to save the configuration for creating a mobile
client in an xml file. The following parameters are available for the com-
mand:
• --file <file name> - defines the name of the file that contains
the private key. This key is used to generate a signature.

4.7.6.11. mobile-client-digi-sign
The command allows you to generate a digital signature of the mobile client
configuration. The following parameters are available for the command:
• --file <file name> - defines the name of the file that contains
the private key. This key is used to generate a signature.
4.7.6.12. manage-cfg-support
The command allows to disable the configuration support. The following
parameters are available:
• --disable-support -indicates necessity to disable the configura-
tion support. The error is generated, if the parameter is absent.
• --force - disable configuration support even if changes are not
permissible in the configuration. The error is generated if the parame-
ter is absent and if the attempt to disable the configuration support is
made for the configuration, for which the changes are restricted in the
support control interactive mode.

4.7.6.13. Group of extension commands

4.7.6.13.1. Command group purpose

config extensions command group is designed to manage extensions
using agent mode.

4.7.6.13.2. create
The command is designed to create extensions in the infobase. The exten-
sion is created as empty. To import the extension you should use
theconfig load-cfg or config load-config-from-files
command. The following parameters are available:
• --extension <name> - sets extension name. A parameter is ob-
ligatory.
• --name-prefix <prefix> - sets the name prefix for the exten-
sion. A parameter is obligatory.
• --synonym <synonym> - extension name synonym. Multilingual
string in function format Nstr().
• --purpose <purpose> - extension purpose. <Purpose> can
take the following values:
 customization - purpose Adjustment (default value);
 add-on - purpose Add-in;
 patch - purpose Correction.

4.7.6.13.3. delete
The command is designed to remove the extension from the infobase. The
following parameters are available:
• --extension <name> - sets the extension name to be deleted.
• --all-extensions - indicates that all extensions must be deleted.
4.7.6.13.4. Group of property commands

Command group purpose

config extensions properties command groups allows to define
and get extension properties.

get
The command is designed to get extension properties located in the in-
fobase. The following parameters are available:
• --extension <name> - sets the name of the extension for which
you want to get properties.
• --all-extensions - indicates that it is necessary to get the prop-
erties of all extensions imported into the infobase.

set
The command is designed to set extension properties located in the in-
fobase. The following parameters are available:
• --extension <name> - specifies extension name for which you
want to set properties.
• --active <mode> - define extension activity. <Mode> Can take
the following values:
 yes - extension is active.
 no - extension is not active.
• --safe-mode <mode> - defines operation in safe mode. <Mode>
Can take the following values:
 yes - extension operates in a safe mode.
 no - extension operates in unsafe mode. In this case, the security
profile name is automatically reset (the profile name is set as equal
to an empty string).
• --security-profile-name <profile> - defines the name
of the security profile that the extension runs under. If the name of the
security profile is specified, then the flag of operation in a safe mode
is automatically set.
• --unsafe-action-protection <mode> - defines a mode of
protection against unsafe actions. <Mode> Can take the following
values:
 yes - protection against unsafe actions in the extension is enabled.
 no - protection against unsafe actions in the extension is disabled.
 • --used-in-distributed-infobase <mode> - defines the
option of the extension to work in the distributed infobase.<Mode>
can take the following actions:
 yes - The extension is used in the distributed infobase.
 no - The extension is not used in the distributed infobase.
• --scope <scope> - extension scope. <Scope> can take the fol-
lowing actions:
 infobase - The extension is valid for the whole infobase.
 data-separation - the extension is valid for the whole in-
fobase.

4.7.7. Infobase-tools group

commands
4.7.7.1. Command group purpose
The commands of the infobase-tools group are responsible for ob-
taining service information about infobase.

4.7.7.2. debug-info
Using this command, get information about the debugger settings for the
infobase. The following debugger configuration parameters are available:
 enabled -A sign of debugging to be started.
 protocol - A debugging protocol: tcp or http.
 server-address - The debugging server address for this in-
fobase.

4.7.7.3. data-separation-common-
attribute-list
This command allows you to get a list of separator names of the infobase.

4.7.7.4. dump-ib
The command is designed to infobase export into the dt-file. The following
parameters are available:
• --file <filename> - defines dt file name.

4.7.7.5. restore-ib
The command is designed to infobase import into the dt-file. The following
parameters are available:
• --file <filename> - defines dt file name.
4.7.7.6. erase-data
The command deletes the infobase data.

4.7.8. Format of the JSON

messages
In the event that the output format is set as JSON messages, a server will
always return an array of various combinations of the following values:
• Name: type, mandatory.
 Values: log | success | error | canceled | question |
dbstru | loading-issue | progress | extension-
info.
 Describes a kind of messages:
 log - Information message.
 success - An operation has completed successfully.
 error - An operation has completed with an error
 canceled - An operation canceled.
 question - Question for a user.
 dbstru - Information on a process of restructuring.
 loading-issue - Errors and warnings accumulated during
configuration import from files.
 progress - information about the progress of the command
execution.
 extension-info - information about the extension, which
is in the infobase.
• Name: error-type
 Values: none.
 Contains a kind of error that occurred when executing the com-
mand:
 UnknownError - An unknown error.
 DesignerNotConnectedToInfoBase - A connection to
infobase is not established.
 DesignerAlreadyConnectedToInfoBase - A connec-
tion to infobase is already established.
 CommandFormatError - An incorrect command format.
 DBRestructInfo - An error in restructuring database.
 InfoBaseNotFound - infobase not found.
 AdministrationAccessRightRequired - Administra-
tive rights are required to complete the operation.
 ConfigFilesError - Errors in the process of im-
port/export of configuration from/to the file.
 DesignerAlreadyStarted - running configurator is de-
tected.
 InfoBaseExclusiveLockRequired - exclusive locking
of the infobase is required.
 LanguageNotFound - language is not found.
 ExtensionWithDataIsActive - The configuration ex-
tension is active and contains data.
 ExtensionNotFound - extension is not found.
• Name: message
 Values: none.
 Contains a localized error message.
• Name: body
 Values: JSON message.
 A content of this value depends on a specific operation.

4.7.9. Notification about the

progress of time-
consuming operation
execution
Some commands may require significant time for their execution. There is
an option to configure the agent mode so that the progress of the command
will be displayed either in the type of messages or directly on the console
screen. The progress display is configured using the options set com-
mand.
The commands inform about progress only if the corresponding mode is
enabled in the settings. The frequency of updating information is also set by
the settings parameter. Progress is measured as a percentage. If the progress
has not changed over the time interval, then the message is not sent.
The following commands support the display of progress:
• dump-config-to-files;
• load-config-from-files;
• dump-external-data-processor-or-report-to-
files;
• load-external-data-processor-or-report-from-
files;
• dump-cfg;
• load-cfg;
• update-db-cfg.
4.7.10. Recommendations for
configuring the SSH
clients
When configuring the PuTTY SSH client, the following settings are rec-
ommended:
• The parameters of a group Terminal:
 Parameter Local echo - Force on;
 parameter Local line ending - Force on.
• Group of parameters Window - Translation:
 Parameter Remote character set - UTF-8.
• Group of parameters Connection - SSH - TTY:
 Turn on parameter Don`t allocate a pseudo-terminal.

4.8. Client application agent

1cecla
4.8.1. General information
Appendix 1C: Enterprise- alert and launch (hereinafter referred to as the
“Client application agent”) is intended to receive messages from server of
the interaction system as well as to centrally display alerts. In this case,
messages are received and displayed also if the application itself (for which
a message is intended) is not currently launched. The client application
agent, in addition to accumulation and display of alerts, allows to quickly
navigate to the client application for which a message has been received, as
well as to control a display of alerts. If an application is not running, an
agent starts this application. Also, the client application agent being
launched replaces all the infobase icons that (in Windows OS) are located in
the system tray of the taskbar with a single agent icon.
The client application agent is being released in the following versions:
• The executable file for Windows OS in the 32-bit version;
• The executable file for Linux OS in the 32-- and 64-bit versions;
• Web browser extension for Google Chrome, Mozilla Firefox in 32-
and 64-bit versions (depending on the bit depth of the web browser
used), as well as the Microsoft Internet Explorer extension in 32-bit
version.
4.8.2. Agent installation
When installing the 1C: Enterprise (except for a separate thin client distri-
bution), a distribution kit of the client application agent is located in:
• On Windows OS: in the ExtDst directory of a specific 1C:Enterprise
version
• On Linux:
 The 32-bit system version: /opt/1C/v8.3/i386/ExtDst
 The 64-bit system version: /opt/1C/v8.3/x86_64/ExtDst
The agent packet file's name is of a kind 1c-enterprise-client-application-
agent-a.b.c.d.arch, where:
• a.b.c.d - Is a full version number of the agent located in the packet
which corresponds to a number of the a.b.c.d kind.
• arch - The utility architecture. Can take values:
 Windows OS:
 x86 - The 32-bit version of the agent.
 Linux:
 i386 - The 32-bit version of the agent;
 x86_64 - The 64-bit version of the agent.
For Windows OS, the packet has an .exe extension, for Linux OS - - .sh.
Installation of the agent is initiated by launching the corresponding installa-
tion packet manually using the 1C:Enterprise language or from the settings
dialog of the interaction system from the client application. The client ap-
plication agent is installed in the following directories:
• Windows OS:
 32-bit application in the 64-bit OS:
%PROGRAMFILES(x86)%\1C\1CE\1cecla\ecs_ver_<api-
version>.
 Otherwise:
%PROGRAMFILES%\1C\1CE\1cecla\ecs_ver_<api-version>.
• Linux:
 ~/bin/1cecla/ecs_ver_<api-version> (for any OS bitness).
• <api-version> expression is a number equal to the version of collab-
oration protocol with a collaboration system server.
The executable file name of the client application agent is: 1cecla.
Only one version of the client application agent can be installed on a com-
puter at a time.
If an installed client agent is detected during installation of 1C:Enterprise,
version of the installed agent is determined. If version of the installed agent
application is lower than the agent version in the platform being installed,
the following actions are performed:
• The client application agent is updated to the latest version
 • The web browser extension is updated if necessary
• The client application agent is restarted if it was launched before in-
stalling the new version of 1C:Enterprise
When the client application starts, the installed and running version of the
agent is checked. If it is earlier than the available version of the agent, a
dialog box opens displaying the information about availability of a later
version of the agent and the update hyperlink. Clicking the hyperlink starts
the update process.
After the client application agent is installed in OS Windows, the client will
automatically start at Windows startup. In Linux you need to manually
specify that the client application agent must start at system startup. You
should remember the agent needs a running GUI to start.

4.8.3. Agent interface

To access the client agent interface, the client agent manager is used. It is
accessible through the global context property
ClientApplicationAgent.
The application interface allows to:
• Install the agent
• Check for availability of new agent versions
• Get/install presentation of the client application from the agent context
menu
• Connect the current client application to (or disconnect from) the
agent
• Enable or disable the agent status change handler
The agent connects to the running client application automatically, upon the
start of the client application. However if you need the client application
agent to display alerts even when the client application is not currently run-
ning, you must use the
ClientApplicationAgent.StartConnection() method. You
can read the actual connection status using the handler attached with the
ClientApplicationAgent.DisableConnectionStatusHandl
er() method. To change the presentation of the application in the agent
list, use
theClientApplicationAgent.GetApplicationName()/Clien
tApplicationAgent.SetApplicationName() methods.
Appendix 5.
Error handling

The text of an error message is generated as follows:

• The most deeply nested (meaning the first) exception is extracted from
the chain of exceptions.
• The description text of the first exception is used as short presentation
of the error:
 For module compilation errors, the short presentation also indi-
cates the error location (module line containing the error).
 For run-time errors, the short presentation does not indicates the
error location (module line containing the error).
• The short presentation of the error is displayed to the user in a dialog
box. This dialog box may include Details… button if the following
conditions are met:
 Debug mode is active
 The error is related to 1C:Enterprise language
 The chain contains multiple exceptions
• The detailed presentation of the error is generated from the descrip-
tions of all exceptions in the chain.
If the error notification dialog box has no Details… button and the error is
critical (terminating the application), this dialog box instead contains the
Show information for the technical support hyperlink.
If the dialog box displays a 1C language error, clicking the Details… button
opens a window with the errors details and Designer… button.
While the thin client or web client is running, the following exceptions are
handled in the client/server mode:
• If any locked infobase connections are detected at system startup, an
error message is displayed and the user is prompted to reestablish the
connection.
• If the server version and the client version do not match, an error mes-
sage is displayed and the user is prompted to restart the client.
• If the user has no rights to start the thin client, the system behavior
depends on whether the –AppAutoCheckMode command was exe-
cuted:
 If the command was executed at startup, the system attempts to
start the thick client automatically.
 If the command was not executed at startup, an error message
window is displayed (the user is not prompted to restart the client).
 • If connection to 1C:Enterprise server (or a web server) fails for a re-
peatable request or a request executed before the session start, the er-
ror message is displayed and the user is prompted to repeat the re-
quest. If the user does not choose to repeat the request, the client does
not close. If the request is not repeatable, the error message is dis-
played and the user is prompted to restart the client.
• If an error occurs during the processing of the request on the server,
the error message window appears with the option to restart.
• If a session error occurs (for example, the session was removed by the
administrator), the error message window appears and the user is
prompted to restart the client.
When an internal platform error occurs, the web client generates an error of
this type: Unknown error: <error description>.
If web client or thin client connected via web server is used to connect to
the infobase, the following error codes are used for abnormal situations:
• 400 Bad Request - describes the application solution errors without
critical consequences for the operation of the client application (in-
cluding all runtime exceptions). Can't be caught to be displayed to
user.
• 500 Internal Server Error - describes the application solution errors
with critical consequences for the operation of the client application,
for example:
 Unrecoverable database exceptions
 Exceptions related to deleted sessions or missing session data
• 502 Bad gateway - describes the server cluster errors or maintenance
operations errors with critical consequences for the operation of the
client application, for example if it is impossible to connect to
1C:Enterprise server.
• 503 Service Unavailable - describes the server cluster errors or
maintenance operations errors with critical consequences for the oper-
ation of the client application, for example if it is impossible to con-
nect to the DBMS server.
IMPORTANT! To keep the system operational do not catch errors with
code 400. You can catch errors with 50x codes to display more friendly
error messages.
Appendix 6.
Internet services for
retrieving shared
infobase list and client
distribution package

6.1. Retrieving the shared

infobase list
6.1.1. General information
NOTE. Available only for CORP licenses.
When working remotely (for example, via a web server) you need to re-
trieve the shared infobase list. However you cannot use the
CommonInfoBases parameter of configuration file 1cestart.cfg to re-
trieve the list. You can get the shared infobase list if it was published using
the Internet service. To get the list, you can use either HTTP requests or
web services.
If the shared infobase list is retrieved using HTTP connection, the certificate
of the server used to retrieve the list is checked using the certificates of the
root certificate authority obtained from the corresponding OS system stor-
age.

6.1.2. Using web services

To get the shared infobase list through a web service, you need to publish a
specific web service that will return the list. This web service is described
below in more detail.

6.1.2.1. Overview
The interactive launcher (1cv8s) can get the shared infobase list either from
a local network or from the Internet. To retrieve the shared bases list from
the Internet, you need to start the interactive launcher and specify the ad-
dress of the list (the InternetService or WebCommonInfoBases
parameter in file 1cestart.cfg).
The shared infobase list retrieval procedure must meet the following re-
quirements:
• The WebCommonInfoBases.CheckInfoBases() method is
called anonymously
• The WebCommonInfoBases.GetInfoBases() method is
called with authentication
• The infobase that returns the shared infobase lists must contain a list
of users allowed to request these lists.
First, the WebCommonInfoBases.CheckInfoBases() method is
called (anonymously). If the launcher is started manually for the first time
for this computer and this user, the ClientID
and InfoBasesCheckCode parameters take the value 00000000-
0000-0000-0000-000000000000. If the launcher is not started for
the first time, the client code and the code of the current shared infobases
list are passed as parameters. The web service method determines whether
the shared infobase list for the client needs to be updated. If the update is
needed, -the InfoBasesChanged output parameter must be set to True
and the URL parameter must contain the address of the web service that
implements the WebCommonInfoBases.GetInfoBases() method
(requires authentication). Otherwise, InfoBasesChanged must be set to
False and URL must contain an empty string.
The algorithm of checking for the changes in the shared infobase list is not
regulated and can be arbitrary. Please note that the launcher does not calcu-
late the code value identifying the shared infobase list but simply stores the
value that was passed during the previous call of the web service.
If results of the call of WebCommonInfoBases.CheckInfoBases()
method indicate that the list needs to be updated, the launcher calls the
WebCommonInfoBases.GetInfoBases() method of the web ser-
vice. The web service is located at the address returned by the
WebCommonInfoBases.CheckInfoBases() function in its URL
parameter. The GetInfoBases() method must match the user on whose
behalf the web service is authenticated with a client code. The mapping can
be “personal” -when the user identifies himself or herself with personal
username and password and receives the personal shared infobase list. In
addition, the mapping can be a “role-based” -when user identifies his or her
belonging to a certain role, such as Operator, Storekeeper, etc., and ob-
tains the shared infobase list common to all users with the same role. You
should note that in the first case, the infobase implementing the
GetInfoBases() method needs to contain the list of all users who can
run the 1cv8s launcher connected to this web service. In the second case,
the list of users can contain the role names only.
The GetInfoBases() method must return three values:
 • Client code (if not specified)
• The list of shared infobases in v8i format
• The code value identifying the passed infobase list This value will be
passed to the WebCommonInfoBases.CheckInfoBases()
method at the next check for whether the shared infobase list needs to
be updated.
If the shared infobase list is retrieved for the first time, the client code (the
ClientID parameter) is 00000000-0000-0000-0000-
000000000000.
Please also consider the following:
• The infobase implementing the WebCommonInfoBases web ser-
vice needs to be published in two different publications.- This is be-
cause calling the CheckInfoBases() and GetInfoBases()
methods requires different levels of authentication.
• The anonymous access is organized by explicitly specifying the user
on whose behalf the access is performed in the default.vrd file.
• The user on whose behalf the anonymous access is organized should
not be able to call the method for retrieving the infobase list. The user
should only indicate whether the list has changed for the passed
ClientID value.
• All publications serving the WebCommonInfoBases web service
must prohibit the web client.
• If the shared infobase list is used by the mobile client, this file must
contain the correct values of the MobilePublicKey parameter for
the infobases to be displayed in the mobile client.

6.1.2.2. Web service description

Web service name: WebCommonInfoBases. The timeout for execution
of any web service method is 3 seconds.
The web service methods are listed below.

CheckInfoBases
Description:
This method is used by the 1cv8s launcher to determine whether the shared
infobase list needs to be retrieved.
Parameters:
ClientID input
Type: String. Contains the client ID used to check whether the shared
infobase list needs to be updated.
 InfoBasesCheckCode input
Type: String. Identifies the shared infobase list. The code must uniquely
identify the current shared infobase list. If the list is modified in any way,
the code needs to be assigned a new value that was not previously used for
this client ID.
InfoBasesChanged output
Type: Boolean. Indicates that the shared infobase list must be retrieved
again.
URL output
Type: String. The URL to be requested if the shared infobase list has
changed since the last call.
Returns:
Arbitrary type, the value is ignored.

getInfoBases
Description:
Parameters:
ClientID input/output
Type: String. Contains the client ID for which the shared infobase list is
retrieved. If the client ID is not specified (or equal to 00000000-0000-
0000-0000-000000000000), the method assigns the client ID and
returns it in this parameter.
InfoBasesCheckCode output
Type: String. Value of the code identifying the shared infobase list re-
turned by this method in the InfoBases parameter.
InfoBases output
Type: String. The shared infobase list in the v8i format.
Returns:
Arbitrary type, the value is ignored.

6.1.2.3. Implementation example

This section reviews an example of web service used to retrieve the shared
infobase list.
NOTE. The example given in this section is not complete. It is intended for
the general functionality demonstration.
 A simple configuration including one catalog and one web service is used as
a web service.
The catalog is organized as follows:
• Name SaredInfoBasesList.
• Code type String, length is 36 characters.
• Attributes:
 Name ListCode, type UniqueIdentifier.
 Name IBList, type String, unlimited length.
• The remaining parameters have default values.
This catalog will store the list of customer IDs (standard attribute Code),
the shared infobase list (attribute IBList) and the current version of the
infobase list (attribute ListCode) determined when the list was last re-
trieved for this client. The version of the list is a unique identifier and it is
changed each time a directory item is saved. For this purpose in the object
module, the handler BeforeWrite is defined:
Procedure BeforeWrite(Cancel)
ListCode = New UniqueIdentifier;
EndProcedure

In addition in the configuration the WebCommonInfoBases web service

must be created with the following operations defined:
• CheckInfoBases, the Return Value Type property is set to
string, the Possibly Empty Value checkbox is set. The remaining
properties are set to default values.
• GetInfoBases, the Return Value Type property is set to
string, the Possibly Empty Value checkbox is set. The remaining
properties are set to default values.
Text of the web service operations:
Function CheckInfoBases(ClientID, InfoBasesCheckCode,
InfoBaseChanged, URL)

If ClientID = "00000000-0000-0000-0000-000000000000"
And InfoBasesCheckCode = "00000000-0000-0000-0000-000000000000"
Then
// the first request of the client
InfoBaseChanged = True;
URL = "/listservice2/ws/WebCommonInfoBases";
Return "";
EndIf;
Client = Catalogs.SharedBaseList.FindByCode(ClientID);
If Client.Empty() Then
// no such client
InfoBaseChanged = False;
Else
// check that the list on the client side and our list are the
same
If InfoBasesCheckCode = Client.ListCode Then
// the list is not changed
InfoBaseChanged = False;
URL = "";
Else
// the list is changed
InfoBaseChanged = True;
URL = "/listservice2/ws/WebCommonInfoBases";
EndIf;
EndIf;
Return "";
EndFunction

Function GetInfoBases(ClientID, InfoBasesCheckCode, InfoBases)

If ClientID = "00000000-0000-0000-0000-000000000000" Then

CurUser = InfoBaseUser.CurrentUser();
// need to add new client
// as a code of the catalog element the unique identifier
// of the infobase user will be used
Object = Catalogs.SharedBaseList.NewElement();
Object.Code = String (CurUser.UniqueIdentifier);
// the client name will be equal to the user name
Object.Name = CurUser.Name;
// the IB list is empty at the first call
Object.IBList = "";
Object.Write();
// to form the returned values of the web service
InfoBasesCheckCode = Object.CodeList;
InfoBases = Object.IBList;
ClientID = Object.Code;
Else
// here we get the data for the existing client code
Client = Catalogs.SharedBaseList.FindByCode(ClientID);
If Client.Empty() Then
// no such client
 InfoBasesCheckCode = "";
InfoBases = "";
Else
InfoBasesCheckCode = Client.CodeList;
InfoBases = Client.IBList;
EndIf;
EndIf;
Return "";

EndFunction

After creating the configuration, the web service should be published to the
web server twice. Then the addresses of published web services should be
stored. Suppose that web services are published at the addresses:
• http://localhost/listservice - anonimous web service;
• http://localhost/listservice2 - the web service requiring authentica-
tion;
The infobase should contain users: Anonymous, and, for example, users
Operator, Storekeeper, Accountant.
The default.vrd file, which describes the publication at
http://localhost/listservice, is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/listservice"
ib="File=X:\DB\ListBase;Usr=Anonimous"
enable="false">
<ws>
<point name="WebCommonInfoBases"
enable="true"/>
</ws>
</point>

The default.vrd file, which describes the publication at

http://localhost/listservice2, is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/listservice2"
ib="File= X:\DB\ListBase;"
enable="false">
<ws>
<point name="WebCommonInfoBases"
enable="true"/>
</ws>
</point>

In the settings of the web server where you published the web service for
retrieving the shared infobase list, the HTTP HEAD request should be disa-
bled (at least for virtual catalogs to access the web service). Otherwise, the
web service will not be used.
In the launch window setup form, you need to add a web service with the
address shown above including the suffix ws:
http://localhost/listservice/ws/.
After completing the configuration you should run the launcher. When
prompted to enter a username and password to access the 1C:Enterprise
web service, you should enter the names Operator, Storekeeper, Ac-
countant. The corresponding entries are added to the SharedBaseList
catalog. If you place into the IBList attribute of each catalog element
your list in the v8i format, this list will be added to the list of infobases of
the launcher after authentication.

6.2. Getting the client

application distribution
package
6.2.1. General information
NOTE. Available only for CORP licenses.
When operating remotely (using web server), it is necessary to automatical-
ly get the distribution package of the client application when the system
version is changed on the 1C:Enterprise server (or on the web server). In
this case the search for a new version using the
DistributiveLocation parameter of the configuration files may not
give the result. To get the distribution package, you can use the option to
publish the client application distribution package using the web service. To
get the list, you can use either HTTP requests or web services.
If you get the client application distribution package using the HTTPS con-
nection, then the server certificate (from which the distribution package is
requested) is verified using the certificates of the root certification authori-
ties, obtained from the system storage of the corresponding OS.

6.2.2. Using web services

To get the client application distribution package using web service you
need to publish a special web service that return this distribution package.
This web service is described below in more detail.
 6.2.2.1. Overview
If the thin client (1cv8c) is launched with command
/AppAutoCheckVersion, then it attempts to select the version of the thin
client if it does not match the version of the 1C:Enterprise server or the web
server extension. For this purpose the following three mechanisms are used
(in order of use):
• Search for the distribution package in the local network - using the pa-
rameters of configuration files (1cestart.cfg and 1cescmn.cfg)
DistributiveLocation.
• Getting the client application distribution package at the URL speci-
fied in the default.vrd (attribute of the point element) or conf.cfg
configuration files (PublishDistributiveLocation * pa-
rameters). The priority value is the value specified in the default.vrd
file.
• Get the file using the web service for obtaining the client application
distribution package. The web service address must be specified in the
1cestart.cfg configuration file (parameters InternetService or
WebDistributiveLocation) or in the launch window settings
dialog box.
The thin client analyzes the result of the request to the web service. If
the web service returns 0 in the Size parameter, then it is considered
that the required client application distribution package does not exist,
and the error is generated that the versions of the client application
and the server do not match. Otherwise, the user is prompted to down-
load and install the client application, and the size of the distribution
package received is shown. If the answer is positive, the new version
is downloaded and installed. Then the necessary version of the client
application is restarted. When you import the distribution package file,
the timeout for the operation is 600 seconds. When executing distribu-
tion package import, redirect on the web server side is not supported.

6.2.2.2. Web service description

Web service name: WebDistributiveLocation. The timeout for exe-
cution of any web service method is 3 seconds.
The web service methods are listed below.

GetDistributiveInfo
Description:
This method is used by the thin client (1cv8c) to get the required version of
the client application distribution package in the following cases:
• When connecting via a web server in the client-server variant the ver-
sion of the client application doesn't match the server version.
 • When connecting via a web server in the file variant the version of the
client application doesn't match the server extension version.
Parameters:
OS input
Type: String. The type of operating system for which you need to get the
client application distribution package.
Values: Windows, MacOS.
Arch input
Type: String. The architecture of operating system for which you need to
get the client application distribution package.
Values: x86, x86_64.
Version input
Type: String. The version number of the client application for which you
need to get the client application distribution package.
Size output
Type: Number. The size of the client application distribution package (in
bytes). If the requested distribution package is missing, you must return the
value 0.
URL output
Type: String. URL for downloading the client application distribution
package. When generating the URL you should remember that the distribu-
tion package file should be accessible to the web server. In addition, the
user getting the distribution package should also have permissions to down-
load this file.
The client application distribution package is a zip archive of distribution
files.
Returns:
Arbitrary type, the value is ignored.

6.2.2.3. Implementation example

Let us consider an example of web service to get the client application dis-
tribution package.
NOTE. The example given in this section is not complete. It is intended for
the general functionality demonstration.
A simple configuration is used as the web service. It implements the web
service only and does not contain any other configuration objects. The client
application distribution packages are located in a special directory to which
 the web server should have access. In this configuration the WebDistribu-
tiveLocation web service must be created, for which: the operation
GetDistributiveInfo is defined, the Return Value Type property is
set to string, the Possibly Empty Value checkbox is set. The remaining
properties are set to default values.
Text of the web service operations:
Function GetDistributiveInfo(OS, Arch, Version, Size, URL)

DistributiveDirectory = "C:\inetpub\Distribs\";
DistributiveURL = "http://host/site/distribs/";
// make the zip file name
FileName = "tc-" + Lower(OS) + "-" + Arch + "-" + Version +
".zip";
Archive = New File(DistributiveDirectory + FileName);
If Archive.Exists() Then
Size = Archive.Size();
URL = DistributiveURL + FileName;
Else
Size = 0;
URL = "";
EndIf;
Return "";
EndFunction

You need to specify the correct values in the

DistributionPackageDirectory and
DistributionPackageURL variables that correspond to the real name
of the distribution package directory of the client application (when access-
ing it from the Web-service, - the DistributionPackageDirectory
variable and when accessing it through the web service, the -
DistributionPackageURL variable).
The name of the file with the distribution package should be tc-windows-
x86-8.3.3.100.zip or similar (depending on the OS type and the requested
client application architecture). The name of the archive file is determined
by the program code of the demonstration web service shown above.
After creating the configuration, the web service should be published to the
web server. Then the address of published web services should be stored.
Suppose the web service is published at http://localhost/getdistr.
In the launch window setup form, you need to add a web service with the
address shown above including the suffix ws:
http://localhost/getdistr/ws. Now, to get the distribution package, this
web service is requested. If the directory DistributionDirectory
(on the computer with the web service) contains the zip archive with correct
distribution package, - this file is transferred to the computer that requested
the distribution package.
 Appendix 7.
The parameters of the
command line to launch
1C:Enterprise

7.1. General information

about the system
command line interface
The 1C:Enterprise system allows to perform certain actions using the com-
mand line interface. Some applications provide a command line interface as
an additional tool to the graphical interface, for example, the launcher.
Some applications can be controlled using the command line interface only.
The examples of such applications are command-line launcher and
1C:Enterprise server.
In general case, the 1C:Enterprise command line interface has the following
structure:
Приложение|URL [Режим] [Команда1 [Команда2 […]]]

In this description:
• Application - is the name of the used application. The need to
specify the full path to the launched application, the case of the used
characters, and other features depend on the operating system and en-
vironment in which the application is used. To launch the web client,
the URL of the infobase published on the web server is the name of
the application.
• Mode - is an optional parameter to launch some applications.
• CommandN - is one or more commands that the application must exe-
cute (including additional command parameters). Command - is some
specific action. Each command, in general, has mandatory and option-
al parameters, and some optional value. The possibility to combine
several commands in one command line depends on the launched ap-
plication, the launch mode (if applicable) and the commands them-
selves. Some commands may be mutually exclusive, that is, you can
use only one command from a specific list.
All command line elements are separated by character " " (space). When
describing the command line interface, the following characters may be
used:
• The character " " (space) - separates all the elements of the launch
command line interface.
• Commands and parameters can be specified using several methods:
 Method 1:
 The symbol "/" (slash) - this symbol begins each command.
The web client is exception where the command is not preced-
ed by this symbol. Web client commands are separated by
character "&".
 The character "-" (dash) - precedes a command parameter.
 The parameters are specified along this scheme, for example,
when launch the 1C:Enterprise server (ragent) or in the case of
batch launch the Designer (1cv8).
 Method 2:
 The command is specified without preceding characters. The
parameter starts with the character "--" (double dash) in case of
specifying the full parameter name or "-" (dash) in case of
specifying the abbreviated name of the parameter.
 The parameters are specified along this scheme, for example,
for the ring utility.
 Method 3:
 The command starts with the character "--" (double dash) in
case of specifying the full command name or "-" (dash) in case
of specifying the abbreviated name of the command.
 The parameters are specified along this scheme, for example,
for the cnvdbfl utility.
 When the documentation describes the command line interface of
an application, first a general description of the command line is
given. It shows how the application parameters are specified.
• The characters "[" and "]" - these characters enclose an optional text.
For example, the instruction /command [-parameter] means
that it is possible to specify this command as follows: /command, or
/command -parameter. In the first case (without specifying a pa-
rameter), the command uses for this parameter some default value.
• Symbol "|" - this symbol separates elements that can't present in a giv-
en place at the same time. For example, the description
/command1|/command2 means that in this place you can use ei-
ther command1 or command2. But simultaneous usage of these
commands is not allowed.
• The characters "<" and ">" - these characters usually enclose a brief
description of the command parameter. The command description ex-
 plains the actual values of the parameter. Obviously, you should not
transfer these characters into the actual command line. In addition in
most command interpreters these characters mean redirection of
standard input/output streams, so the direct transfer of these characters
into the real command line leads to radical change in the meaning od
the command entered.
• Please note that the values may be specified not only for commands,
but also for command parameters.
If the value of a command or parameter contains spaces, then we recom-
mend to enclose this value in quotes. The symbol " itself in the parameter
text should be entered as \", and the symbol \ in the parameter value text
before the symbol " should be entered as \\. For example, the value of the
parameter ef \abc \\" "\ should be entered as follows: ef \abc \\\\\" \" \\.
Some examples of the description of the 1C:Enterprise launch command
line commands are given below.
/TComp [-None|-Deflate|-SDC]

This example describes the TComp command, for which you can specify
one of three following parameters: -None or -Deflate or -SDC. It is not
mandatory to specify the parameters. The command can be issued without
any parameters, in the form /TComp.
/VA<mode>

This example shows the VA command, which contains a value (<mode>) as

a parameter. The value must be specified after the command without space.
The specific values of this command will be described later in the descrip-
tion of the command.
/MergeCfg <cf-file name> -Settings <settings file name> [-
EnableSupport | -DisableSupport] [-IncludeObjectsByUnresolvedRefs |
-ClearUnresolvedRefs] [-force]

This example shows the description of the MergeCfg command, which

contains:
• mandatory parameter <cf-file name>;
• mandatory parameter Settings with its parameter <settings
file name>;
• one of the following optional parameters: EnableSupport or
DisableSupport;
• one of the following optional
parameters:IncludeObjectsByUnresolvedRefs or
ClearUnresolvedRefs;
• optional parameter force.
 7.2. Selecting run mode
At launch you can use one of the startup modes listed below. Simultaneous
use of multiple modes is not allowed.

7.2.1. Launch in
1C:Enterprise mode
1cv8 ENTERPRISE [<options>]

The launch options can include:

• The general launch options.

7.2.2. Launch in designer

mode
1cv8 DESIGNER [<commands>]

The commands can include:

• The general commands.
• One of the following command sets:
 Designer launch commands.
 Commands for creating delivery and update files.
 Commands for configuration repository.
 Registration 1C:Enterprise as an OLE-Automation-server.

7.2.3. Launch in the infobase

creation mode
1cv8 CREATEINFOBASE <connection string> [/AddToList [<infobase
name>]] [/UseTemplate <template file name>] [/Out <file name>]
[/L<language code>] [/VL<locale code>] [/O<connection speed>]
[/DumpResult <file name>]

At the application startup you can use the following parameters:

• <Connection string> - a string specifying the parameters for access
to the database.
• /AddToList - the parameter indicating that the created infobase
should be added to the base list. The base is added under the name
<infobase name>. If <infobase name> is not specified, then the
default name is used similar to the name formed when infobase is
added to the infobase list manually.
If the parameter is not specified, the base will not be added to the list.
 • /UseTemplate - Create an infobase based on the template specified
in the <template file name> parameter. You can use configuration
files (.cf) and infobase dump files (.dt) as templates. If the template is
not specified, ignore this parameter.
• /L <language code> - the language code for the platform inter-
face.
• /VL <session locale code> - the session locale code used
for formatting Number and Date data, and also in
NumberInWords() and PeriodPresentation() methods.
• /DumpResult <file name> - saves the infobase creation result
to a file. The result - is a number (0 - if the file is saved successfully).

7.3. General startup

commands
7.3.1. Connection parameters
/F <directory>
The directory where the database file 1Cv8.1CD is located.
/S <address>
The address of the infobase stored on the 1C:Enterprise server. It is generat-
ed as <application server computer name>\ <reference name of the
infobase on the 1C:Enterprise server>.
/IBName <infobase name>
Launch the infobase by the base name in the infobase list. You can enclose
the name in double quotation marks if needed. (If the name contains double
quotation marks, replace each double quotation mark character with two
double quotation mark characters). If multiple infobases share the specified
name, display an error.
/IBConnectionString
The complete infobase connection string, as provided by
IBConnectionString() function. Parts of the connection string can
be overridden by already specified parameters. It happens if the
/IBConnectionString parameter is placed in the command line be-
fore them. Since a connection string always contains double quotation
marks, Enclose it in double quotation marks and replace each double quota-
tion mark character inside the connection string with two double quotation
mark characters.
Additional connection string parameters in thin client mode:
 • wsn - username for authentication on the web server;
• wsp - password for authentication on the web server;
• wspauto - use automatic proxy settings;
• wspsrv - the proxy address;
• wspport - the proxy port;
• wspuser - username for proxy with authorization;
• wsppwd - password for proxy with authorization.
/WS <url>
WS-connection string.
/O<connection speed>
The connection speed (used in the thin client). The command is used to con-
figure the infobase list item. The <connection speed> parameter can
take the following values:
• Normal - usual connection speed (the default value);
• Low - low connection speed
/TComp [-None|-Deflate|-SDC]
Sets the compression mode for traffic between the server and the thin client.
For this command you can specify one of the following parameters:
• -None - compession disabled.
• -Deflate - use the deflate compression method (one of the most
common compression schemes for HTTP data).
• -SDC - use the proprietary compression method (the default value).
UsePrivilegedMode
Launch the client application in privileged mode. Available to authenticated
users with administrator privileges. A record stating that the privileged ses-
sion mode is set or cannot be set is added to the event log.
/SLev<level>
Defines the security level of the client connection to the 1C:Enterprise serv-
er. For this command you can specify one of the following values:
• 0 - unsecured connection;
• 1 - secured connection only for authentication process;
• 2 - the connection is secure through the entire session.
If the command is specified without value, this is equivalent to entering the
command with value 0 - /SLev0.
/Z"<common attribute 1>,<common attribute 2>, ...,
<common attribute N>"
Setting separators when starting the client application.
7.3.2. Authentication
/N<name>
User name. As in the user list in Designer.
/P<password>
The password for the user provided in /N command. If the password is
empty, omit this option.
/WA<mode>
The operating system authentication usage mode at 1C:Enterprise startup. If
you omit /WA command, it is treated as /WA+ command line option.
<mode> can take the following values:
• + - Require operating system authentication at 1C:Enterprise startup.
• - - Prohibit operating system authentication at 1C:Enterprise startup.
/WSA<mode>
The operating system authentication usage mode on the web server. If you
omit /WSA option, it is treated as /WSA+ command line option.
<mode> can take the following values:
• + - forced authentication using the operating system on the web server
(default value).
• – - prohibit the authentication using the operating system on a web
server.
/WSN <name>
The web server authentication user name if /WSA+ option is specified.
Specify the password in the /WSP option.
/WSP <password>
The web server authentication password for the user specified in /WSN op-
tion.
/NoProxy
Disable proxy usage (only for web service connection).
/Proxy -PSrv <address> -PPort <port> [-PUser <user
name> [-PPwd <password>]]
Use specified proxy settings, ignoring defaults (only for web service con-
nection).
/OIDA<mode>
Defines whether pass-through user authentication between various infobas-
es and/or external resources is used (thin and web clients only). If the
/OIDA option is missing during the client startup or the /OIDA+ option is
used, the authentication is attempted via the OpenID provider with the ad-
dress specified in the default.vrd file of the infobase publication.
If the OpenID provider requires interactive authentication (it is an initial
request or the authentication timeout expired), the client prompts to enter
the user name and password.
The user list of the OpenID provider infobase is used for authentication.
The name of the infobase user being authenticated using OpenID must
match the user name in the OpenID provider infobase.
<mode> can take the following values:
• + - use OpenID authentication (the default option).
• - - do not use OpenID authentication.
/Authoff
Perform OpenID logout (close a user session). The user session is complet-
ed irrespective of the authentication method to be used subsequently.
/SAOnRestart
Indicates that at restart of the client application from this session the
username and password are required. By default users are not prompted to
enter passwords.
This option is not applicable to the thin client.

7.3.3. Specifying run mode

/AppAutoCheckVersion<mode>
Automatic selection of the required version for each infobase.
<mode> can take the following values:
• + - select version at startup (the default value).
• – - don't select version at startup.
By default version is selected. The /AppAutoCheckVersion command
is equivalent to the /AppAutoCheckVersion+ command.
/AppAutoCheckMode
Automatically select the appropriate application (the default configuration
start mode and the default start mode for end users) based on the infobase
data.
/RunModeOrdinaryApplication
Start the thick client in ordinary application mode, regardless of the config-
uration settings and the user that starts the application. This option is not
applicable to the thin client.
/RunModeManagedApplication
Start the thick client in the managed application mode, taking into account
the client settings in the infobase list (setting Default run mode):
• Auto - run the thin client;
• Thin client - run the thin client;
• Web client - run the web client;
• Thick client - run the thick client in managed application mode.
The client is started with automatic client selection disabled.
/AppArch <bitness>
Allows you to specify the bitness of the client application used.
<bitness> can accept the following values:
• x86 - use the x32 version only.
• x86_prt - use mainly the x32 version.
• x86_64 - use the x64 version only.
• x86_64_prt - use mainly the x64 version.
/MainWindowMode <startup mode>
It allows to expressly specify the startup mode for client application main
window. <startup mode>can accept one of the following values:
• -Normal - ordinary startup mode.
• -Workplace - workplace mode.
• -EmbeddedWorkplace - embedded workplace mode (for embed-
ding a web client in a third-party website).
• -FullscreenWorkplace - full screen workplace mode.
• -Kiosk- kiosk mode.

7.3.4. Managing certificates

/HttpsCert [-windows] [-linux] [-macos] [-recent]
[-auto] [-choose] [-file <path>] [-pwd <password>]
[-none]
Source of the client certificate.
The command parameters:
• -windows - Take the client certificate from the Microsoft Windows
system certificate store. This parameter is ignored if you specify at
least one of the following parameters: -file and -none.
• -linux - indicates that when connecting, you should use a certificate
from the dedicated Linux OS directory in which the certificates are
stored. This parameter is ignored if you specify at least one of the fol-
lowing parameters: -file and -none.
 • -macos - indicates that when connecting, you should use a client cer-
tificate from the macOS system certificate store. This parameter is ig-
nored if you specify at least one of the following parameters: -file
and -none.
• -recent - select or use a previously selected client system certifi-
cate when running on Windows or macOS.
If the system user certificate store contains multiple suitable certifi-
cates, the user is prompted to select a certificate using the system cer-
tificate selection dialog box. Further, this certificate will be selected
automatically.
This is the default method for client certificate selection for the -
windows and -macos parameters if the -auto and -choose pa-
rameters are not specified.
• -auto - automatically select a client certificate from the Windows or
macOS system certificate store and uses it. This parameter is ignored
if the command does not have -windows or -macOS parameter (re-
spectively).
• -choose - always select Windows or macOS client certificate manu-
ally.
If the system user certificate store contains multiple suitable certifi-
cates, the user is prompted to select a certificate using the system cer-
tificate selection dialog box regardless of the previous selection of any
certificate. The selected certificate can be used automatically in the fu-
ture with the -recent parameter.
You can use this parameter if you need to avoid the automatic usage
of the previously selected client certificate from the Windows or ma-
cOS store and instead select a new certificate appropriate for this con-
nection. This parameter is ignored if the command does not have -
windows/-macOS parameter or when -auto parameter is speci-
fied.
• -file <path> - The file that contains the client certificate and the
private key. This parameter is ignored if -none parameter is speci-
fied in the command.
• -pwd <password> - The password for the file that contains the
client certificate and its private key. If the server requires a client cer-
tificate and the certificate file is password-protected, the password is
required to establish a connection. This parameter is ignored if -file
parameter is not specified in the command.
• -none - Do not use a client certificate. Only connections to servers
that do not require client certificate verification are available.
If neither -windows, nor -linux, nor -macos, nor -file, nor -none
parameter is specified, the /HttpsCert option is ignored.
/HttpsCA [-windows] [-linux] [-macos] [-file
<path>] [-pwd <password>] [-none]
The source of digital certificates of certifying centers. They are used to val-
idate the server certificate.
The command parameters:
• -windows - when connect to check the server certificate you must
take CA certificates from the Microsoft Windows system certificate
store. This parameter is ignored if at least one of -file and -none
parameters is specified.
• -linux - indicates that to check the server certificate during the con-
nection, it is necessary to use certificates of certification authorities
from the dedicated Linux OS directory in which the certificates are
stored. This parameter is ignored if you specify at least one of the fol-
lowing parameters: -file and -none.
• -macos - indicates that to check the server certificate during the con-
nection, it is necessary to use certificates of certification authorities
from the macOS OS system store of certificates. This parameter is ig-
nored if you specify at least one of the following parameters: -file
and -none.
• -file <path> - Take certifying center certificates from the speci-
fied file. This parameter is ignored if -none parameter is specified in
the command.
• -pwd <password> - The root certificates file password. If the cer-
tificate file is password-protected, the password is required to estab-
lish a connection. This parameter is ignored if -file parameter is not
specified in the command.
• -none - Do not use root certificates and do not check the server cer-
tificate.
If neither -windows, nor -linux, nor -macos, nor -file, nor -none
parameter is specified, the /HttpsCA command is ignored.
/HttpsForceSSLv3
Force the thin client to use SSL 3.0 protocol when accessing the web server
over HTTPS.
Simultaneous use of parameters /HttpsForceSSLv3
and /HttpsForceTLS1_0 is not allowed. When they are specified sim-
ultaneously, the behavior is undefined.
/HttpsForceTLS1_0
Force the 1C:Enterprise to use TLS 1.0 protocol when accessing the web
server over HTTPS.
Simultaneous use of parameters /HttpsForceSSLv3
and /HttpsForceTLS1_0 is not allowed. When they are specified sim-
ultaneously, the behavior is undefined.

7.3.5. Interface settings

/iTaxi
Run in the Taxi interface mode.
/itdi
Run in the "Forms in tabs" interface mode .
/DisplayAllFunctions
Enable the All functions menu item.

7.3.6. Locale settings

/L<language code>
The language code for the platform interface.
/VL<session locale code>
The session locale code used for formatting Number and Date data, and
also used in NumberInWords() and PeriodPresentation()
methods.

7.3.7. Debug settings

/debug [<mode>] [-attach]
Start the client application in debug mode. The parameter <mode> defines
the debugging protocol:
• -tcp - Use TCP/IP for debugging;
• -http - Use HTTP for debugging.
If -attach parameter is present, the debugger automatically attaches the
client and server debug items of the application, and then they are registered
on the debug server. This option is applicable only to debugging over
HTTP.
/debuggerURL <debugger address>
This command specifies the debugger address (when debugging over
TCP/IP) or the debug server address (when debugging over HTTP) for de-
bug mode. When specifying a debug server, you must specify not only the
name of the computer on which the debug server is running, but also the
communication port.
DisplayPerformance
Display the number of server calls and the volume of data sent to the server
and received from it.
/EmulateServerCallDelay [-Call<delay>] [-
Send<delay>] [-Recevie<delay>]
This command simulates the operation of the client application when the
connection is slow.
The following parameters are available:
• -Call<delay> - indicates the delay in seconds when the server is
called. If the parameter is not specified, the delay is 1.45 seconds.
• -Send<time> - indicates the delay in seconds per every 1 KB of da-
ta sent to the server. If the parameter is not specified, the delay is 0.45
seconds.
• -Recevie<time> - indicates the delay in seconds per every 1 KB
of data received from the server. If the parameter is not specified, the
delay is 0,15 seconds.
The maximum delay -is 9.99 seconds.

7.3.8. Testing settings

/TestManager
Start the thick or thin client for managing other testing clients using a dedi-
cated object model.
/TestClient [-TPort<TCP port number>]
Start the thick or thin client as testing client.
The -TPort <TCP port number> parameter indicates the port number
for interaction between the client and the test manager. The default port
number is 1538.
/UILogRecorder [–TPort<TCP/IP port number>] [-
File<path>]
Log interactive user actions and generate a 1C:Enterprise script scenario
that reproduces the performed actions. You can use this option with the
/TestClient option.
The command parameters:
• -TPort<TCP port number> - The port number used for interac-
tion between the client and the test manager. The default port number
is 1538.
• -File<path> - The file that will store the user action log after the
recording is stopped, provided that a test manager is not connected to
the client.
7.3.9. Client application
checks
/EnableCheckModal
Enable the strict check for modal methods calls.
/EnableCheckExtensionsAndAddInsSyncCalls
Enable the strict check for synchronous calls in add-ins, in the file system
extension, and in the cryptography extension. Ignored when run the thick
client.
/EnableCheckServerCalls
Enable the check for context server form calls in event handlers where the
server calls are prohibited. If the parameter is specified, then in the context
server call in handlers where such calls are prohibited, a message will be
displayed in the message window. The same message is shown in the In-
formation for technical support dialog box.
/EnableCheckScriptCircularRefs
Enable detection of circular references during the script execution.

7.3.10. Auxiliary parameters

/C <text string>
Passes a parameter to the application.
/ClearCache
Clear the cache of client/server calls, which stores form metadata, modules,
module text search index, and more.
/AllowExecuteScheduledJobs -Off|-Force
Manage the execution of scheduled jobs. Start scheduled jobs on the client
that was started first (excluding clients with
AllowExecuteScheduledJobs –Off). Once the session of this cli-
ent is closed, start scheduled job in any other active session. Once a session
with AllowExecuteScheduledJobs –Force is started, new sched-
uled jobs are started in this session, regardless of the availability of other
sessions.
/UC <access code>
Connect to the infobase with a connection lock enabled. If non-empty ac-
cess code is set for lock you have to provide the access code in parameter
/UC to bypass the lock.
This option is not applicable to the thin client running over the web client.
/RunShortcut <file name>
Allows to run the 1C:Enterprise with infobase list stored in the specified
file. You can select a shared infobase list file (*.v8i), or an infobase
shortcut file (*.v8l).
/AppAutoInstallLastVersion<mode>
Manages automatic installation of the new versions of the client application.
<mode> can take the following values:
• + - installation of the new versions is enabled.
• – - installation of the new versions is disabled.
/Execute <external data processor file path>
Runs external processing with full path specified as the command value in
the 1C:Enterprise mode immediately after the system start. When the
/Execute parameter is specified the/URL parameter is ignored.
/URL <address>
Follow the link after opening the application. The links in e1c and http(s)
format are supported:
• If the link is external -, search for a running client application by the
connection string specified in the parameter. Note that a link cannot be
opened if the client application has a modal or blocking window open.
Then attempt to follow the local link that is a part of the original link,
and activate the main application window. If the attempt is not suc-
cessful, do not close the client application. If the original link does not
include a local link (because it only includes the infobase address), ac-
tivate the main client application window.
• If a client application with the specified connection string is not found,
use the connection string from the /URL option instead.
• If the link is local -, start the client application, then attempt to follow
the local link.
For http(s) links, this option always starts or activates the thin client.

7.3.11. Other parameters

/@ <file with commands>
Allows you to specify the command line in the file given by the value of the
command (<file with commands>). In this file each command must be
separate line (with all its parameters).
/Out <file name> [-NoTruncate]
Specify the file for storing utility messages. If the -NoTruncate parame-
ter is specified (separated by a space), the file is not cleared (not used with
the thin client).
You can open the file during the batch execution. The messages are not
buffered. They are written directly to the file.
/DisableStartupMessages
Disable the following startup messages:
• Database configuration does not match stored configuration.
Continue?
• Your computer capabilities are inadequate to edit configuration
help. To edit HTML documents you must install Microsoft Inter-
net Explorer version 7.0 or higher.
• Your computer capabilities are inadequate to edit HTML docu-
ments, including help sections. To edit HTML documents, you
must install Microsoft Internet Explorer version 7.0 or higher.
HTML document editing will be unavailable during this session.
/DisableStartupDialogs
Skip the authentication and startup dialog boxes. Further:
• An error is generated in the following cases:
 If the command line is not enough to select the infobase or define
the startup mode.
 If the command line is not enough to authorize the user in the in-
fobase.
 If the command line has invalid authorization in the configuration
store.
 An attempt is made to create an infobase (CREATEINFOBASE),
but an administrator has been set for the server cluster.
• If the command-line options do not contain repository authentication
data, start Designer without connecting to a repository.
The command is supported by the configurator, thin and thick client appli-
cations. When using this command in the command line for starting the
client application, the batch mode for starting the client application is ena-
bled.
/DisableSplash
Disables the splash on 1C:Enterprise startup if it is completely replaced.
Contact the 1C Company to replace the splash.
/LogUI
Log the user actions.
 /UseHwLicenses<mode>
Defines whether the search for a local dongle is performed.
<mode> can take the following values:
• + - Search for a local dongle.
• - - Do not search for a local dongle.
/DisplayUserNotificationList
Displays the new messages from the collaboration system and the notifica-
tion center when starting a client application.

7.4. Running Designer in

batch mode
7.4.1. General information
The parameters listed in this section (and its subsections) cannot be com-
bined in a single launch command line, unless otherwise explicitly stated.
To enable batch start mode, select the Configurator start mode
(DESIGNER) in the command line and then specify the common start
commands necessary for operation, as well as the required batch start com-
mand. The infobase export command may look like this:
1cv8 DESIGNER /IBName "My db" /DumpIB c:\temp\dump.dt

If you specify a file with its full path as a command line parameter of the
Designer batch mode, ensure that all of the directories that form the path
exist. Otherwise, the operation will fail.
Modules locked with password are ignored in the Designer batch mode.
When processing such a module, a diagnostic message is generated.
If the command line command supports the –Extension and –
AllExtensions parameters, the simultaneous use of both parameters is
not supported and the system behavior in this case is unpredictable.
When working with extensions (–Extension and –AllExtensions
parameters), the return code is set to 0 upon successful completion, other-
wise the return code is 1.

7.4.2. Upload/download
infobase
/DumpIB <file name>
Export infobase to file.
/RestoreIB <file name>
Load infobase from file.

7.4.3. Restoring infobase

structure
/IBRestoreIntegrity
Attempt to restore the infobase structure If other parameters are found, they
are ignored.
In order to get the result of the recovery, you must specify the /Out com-
mand line parameter. In the file specified in the /Out parameter, the follow-
ing information is stored:
• Restoring the infobase is not required. This means that the struc-
ture of the infobase is not corrupted. The return code in this case is 0.
• The infobase is restored successfully. This means that the structure
of the infobase is restored successfully. The return code in this case is
0.
• If any error occurred during the recovery attempt, - the error text is
stored in the file and the return code in this case is 1.
It is recommended to run Designer with the /IBRestoreIntegrity
parameter if the previous database configuration update (in batch mode or
interactively) was not fully completed, for example, due to a crash of De-
signer or shutting down the computer.

7.4.4. Configurations and

extensions
/DumpCfg <cf/cfe file name> [-Extension <extension
name>]
Save the configuration or the extension of the configuration to a file. To
save the extension configuration you need correctly specify the -
Extension parameter.
/LoadCfg <cf/cfe file name> [-Extension <extension
name>]
Load the configuration or the extension of the configuration from a file. To
load the extension configuration you need correctly specify the -
Extension parameter. If at the time of load the extension is not exists in
the infobase,- it is created with the specified name. If the extension speci-
fied in the -Extension parameter is connected to the configuration re-
pository,- it cannot be loaded.
/MergeCfg <cf-file name> -Settings <settings file
name> [-EnableSupport | -DisableSupport] [-
IncludeObjectsByUnresolvedRefs | -
ClearUnresolvedRefs] [-force]
Merge current configuration with a file (using settings file).
The following parameters are available:
• <cf file name> - name of cf file with merged configuration.
• -Settings <settings file name> - allows to specify the
configuration merging settings file name.
• -EnableSupport - to put the configuration on the support, if pos-
sible to merge with the support. The support rules in this case should
be specified in the settings file.
• -DisableSupport - not to put on support, even if it is possible.
• -IncludeObjectsByUnresolvedRefs - if merge settings con-
tain the objects that are not included in the list of merged ones and ab-
sent not in the main configuration, but referenced from objects includ-
ed in the list, then such objects are also marked for merging, and an at-
tempt is made to continue the merging. Attempts are made until there
are objects referencing the objects that are not included, or until the
complete configuration is selected. Similar to Mark All for Merging
button in the window with unresolved references, repeating of at-
tempts only.
• -ClearUnresolvedRefs - references to objects, not included in
the list of merged objects, are cleared. Similar to Continue button in
the window with unresolved references.
• -force - perform merging, if there are:
 warnings of deleted objects referenced in the objects not included
in the merging (such objects will be excluded from the merging);
 settings applying warnings.
The merging will be interrupted in the above cases, unless specified.
If there is a possibility to put the configuration on support, and the -
EnableSupport or -DisableSupport parameter is not specified,
then the merge will be aborted with error The possibility to merge with
the support is detected. If there is no possibility to put the configuration
on support, but the -EnableSupport or -DisableSupport parame-
ter is specified, then the merge will be aborted with error No possibility to
merge with the support.
If there is a possibility to put the configuration on support, and the -
EnableSupport parameter is specified, but there is no SupportRules
element in the settings file, then the following support rules are set:
• New vendor objects:
  Objects with vendor rule Changes allowed - Set the support rule
Vendor object is not editable
 Objects with vendor rule Changes not recommended - Set the
support rule Vendor object is not editable
• Duplicate objects or objects with merge rule Get from new vendor
configuration:
 Objects with vendor rule Changes allowed - Set the support rule
Vendor object is not editable
 Objects with vendor rule Changes not recommended - Set the
support rule Vendor object is not editable
• Modified objects with a rule other than Get from new vendor con-
figuration:
 Objects with vendor rule Changes allowed - Set the support rule
Vendor object can be edited and are still supported.
 Objects with vendor rule Changes not recommended - Set the
support rule Vendor object can be edited and are still sup-
ported.
If unresolved links are detected in objects from the merged (second) config-
uration, and the -IncludeObjectsByUnresolvedRefs or -
ClearUnresolvedRefs parameters are not specified, then the merge is
aborted. For each object the list of properties of objects with unresolved
links and the list of objects not included on these links are stored in the utili-
ty message file.
The warnings are written in the utility message file regardless the value of
the -force parameter.
/CompareCfg –FirstConfigurationType <configuration
type> [-FirstName <configuration name>] [-FirstFile
<file path>] [-FirstVersion <version number>] –
SecondConfigurationType <configuration type> [-
SecondName <configuration name>] [-SecondFile <file
path>] [-SecondVersion <version number>] [-
MappingRule <rule>] [-Objects <file name>] -
ReportType <report type> [-IncludeChangedObjects]
[-IncludeDeletedObjects] [-IncludeAddedObjects] -
ReportFormat <format type> -ReportFile <file name>
Compare two configurations and generate a file with a comparison report.
The following parameters are available:
• -FirstConfigurationType - The type of the first configuration
to compare. The parameter can take values:
 MainConfiguration - Main configuration;
 DBConfiguration - Database configuration;
 VendorConfiguration - Vendor configuration;
  ExtensionConfiguration - Configuration extension;
 ExtensionDBConfiguration - Configuration extension
from database;
 ConfigurationRepository - Configuration from a reposi-
tory;
 ExtensionConfigurationRepository - Configuration
extension from an extension repository;
 File - Path to the configuration file or configuration extension
file.
• -FirstName <additional ID> - Name of the first configura-
tion. The parameter can take the following values (depending on the
value of the /FirstConfigurationType parameter):
 VendorConfiguration - Vendor configuration name;
 ExtensionConfiguration - Extension configuration name;
 ExtensionDBConfiguration - Extension configuration
name (from database).
For the other values of the /FirstConfigurationType parame-
ter this parameter is not applicable.
• -FirstFile - the path to the configuration file (.cf) or to the exten-
sion configuration file (.cfe). This parameter makes sense only if the
/FirstConfigurationType parameter has value File.
• -FirstVersion - Version of the configuration repository. This pa-
rameter makes sense only if the /FirstConfigurationType pa-
rameter has value ConfigurationRepository or
ExtensionConfigurationRepository.
• -SecondConfigurationType <configuration type> -
The type of the second configuration to compare. The parameter val-
ues are fully equivalent to the parameter values
/FirstConfigurationType.
• -SecondName <additional ID> - Name of the second config-
uration. Completely the same as for /FirstName.
• -SecondFile - the path to the configuration file (.cf) or to the ex-
tension configuration file (.cfe). Completely the same as for
/FirstFile.
• -SecondVersion - Version of the configuration repository. Com-
pletely the same as for /FirstVersion.
• -MappingRule <rule> - The object mapping rule (if the configu-
rations are not related).
 ByObjectName - By object name. Used by default.
 ByObjectIDs - Map by object IDs.
 • -Objects <file name> - path to a file with the list of objects to
be involved in the operation. If the file is specified -, the operation in-
volves the objects specified in the file only, otherwise the operation
involves the complete configuration.
• -IncludeChangedObjects - Include changed subordinate ob-
jects in the report.
• -IncludeDeletedObjects - Include deleted subordinate objects
in the report.
• -IncludeAddedObjects - Include added subordinate objects in
the report.
• –ReportType <report type> - Type of the comparison report:
 Brief - Brief report.
 Full - Full report.
• -ReportFormat <format type> - Describes the format of the
report file:
 txt - Text document.
 mxl - Spreadsheet document.
• -ReportFile <file name> - Specifies the file name for the
comparison report.
/UpdateDBCfg [-Dynamic<Mode>] [-BackgroundStart] [-
BackgroundCancel] [-BackgroundFinish [-Visible]] [-
BackgroundSuspend] [-BackgroundResume] [-
WarningsAsErrors] [-Server] [-v1|-v2] [-Extension
<Extension name>]
Update the database configuration.
It should be understood that the background update mechanism is not relat-
ed to selection of the restructuring mechanism. If a background update is
indicated, selection of the restructuring mechanism option (-v1|-v2) will
be ignored.
The following parameters are available:
• -Dynamic<mode> - Shows whether dynamic update is performed.
<mode> can take the following values:
 – - explicitly prohibits dynamic update.
 + - allows dynamic update. First the system attempts to perform a
normal update. If the attempt fails,- the system attempts to perform
a dynamic update. The dynamic update is also allowed if the –
Dynamic+ parameter is not specified or if the -Dynamic pa-
rameter is specified without the mode.
• -BackgroundStart - starts the background database configuration
update and exits. If in addition the –Dynamic or –Dynamic+ pa-
 rameter is specified, the system attempts to do the dynamic update
first. If this attempt fails, the background update is launched.
• -BackgroundCancel - Cancel a running background database
configuration update.
• -BackgroundFinish - quits the background database configura-
tion update (performs a change acceptance phase): the system at-
tempts to lock the database exclusively and perform the final phase.
When the –Visible flag is specified, if it is impossible to complete
the background update (go to the change acceptance phase) then the
dialog box is displayed with the Cancel, Retry, End Sessions and
Rtry buttons. If the flag is not specified,- the execution fails.
• -BackgroundSuspend - Pause a background database configura-
tion update.
• -BackgroundResume - Resume a paused background database
configuration update.
• -WarningsAsErrors - Treat all warnings as errors.
• -Server - the update is performed on the server (makes sense only
in the client-server configuration). If this parameter is specified for a
background update, the following rules apply:
 The refreshing phase of the update is always performed on the
server.
 The processing phase and the change acceptance phase of the up-
date can be performed both on the client and on the server.
 The option to start a background update on the client and complete
it on the server, or vice versa, is available.
 The optimized restructuring mechanism is not used (the -v2
command is ignored if one is specified).
• -v1|-v2 - defines the restructuring mechanism in use. If the restruc-
turing mechanism version (-v1 or -v2) is not specified, then the re-
structuring mechanism of the version specified in the conf.cfg file (on
the client application side) will be used. Otherwise use the version
specified in the command line. If an optimized restructuring mecha-
nism is specified, but the use of this mechanism conflicts with other
parameters, -the usual restructuring mechanism will be used.
• -Extension <extension name> - the specified extension is
updated.
Selection of the restructuring mechanism used is as follows:
• If the command line contains an explicit indication of the restructuring
mechanism used, - the specified mechanism will be used.
• If the command line does not indicate the restructuring mechanism
used, - the restructuring mechanism specified by the UpdateDBCfg
 parameter of the conf.cfg file (on the client application side)
will be used.
• In any case, the –Server command indicates that the restructuring
will be executed on the server. This command does not affect the se-
lection of the restructuring mechanism used.
You can use /UpdateDBCfg after the following options:
• /LoadCfg;
• /UpdateCfg;
• /ConfigurationRepositoryUpdateCfg;
• /LoadConfigFiles;
• /LoadConfigFromFiles;
• /MobileAppUpdatePublication;
• /MobileAppWriteFile;
• /MobileClientDigiSign;
• /MobileClientWriteFile.
/DumpDBg <cf/cfe file name> [-Extension <extension
name>]
Save to a file the database configuration or the configuration of the exten-
sion saved to the database. To save the extension configuration you need
correctly specify the -Extension parameter.
/DumpDBCfgList [-Extension <extension name>] [-
AllExtensions]
Displays the name of the main configuration (if no one parameter is speci-
fied) or the name(s) of the extension(s). The following parameters are avail-
able:
• -Extension - Displays the name of the specified extension.
• -AllExtensions - Displays the names of all extensions.
/RollbackCfg [-Extension <extension name>]
Revert to database configuration.
If the -Extension parameter is specified, the configuration saved in the
database for the specified extension is restored.
/DeleteCfg [-Extension <extension name>] [-
AllExtensions]
Deletes the extension with the specified name. If you specify the –
AllExtensions option, all extensions are deleted. This command can't
be used without parameters.
/DumpConfigFiles <dump directory> [-Module] [-
Template] [-Help] [-AllWritable] [-Picture] [-
Right] [-Extension <extension name>]
Dumps some properties of configuration objects (modules, templates, imag-
es, access rights and reference information) to files. The following directo-
ries and parameters are available:
• <dump directory> - The directory that stores property files;
• -Module - Upload modules;
• -Template - Upload templates;
• -Help - Upload help topics;
• -AllWritable - Upload only properties of writable objects;
• -Picture - Upload common pictures;
• -Right - Upload rights.
• –Extension - Process the extension with the specified name.
/LoadConfigFiles <load directory> [-Module] [-
Template] [-Help] [-AllWritable] [-Picture] [-
Right] [-Extension <extension name>]
Restores some properties of configuration objects (modules, templates, im-
ages, access rights and reference information) from files. The following
directories and parameters are available:
• <load directory> - The directory that stores property files;
• -Module - Load modules;
• -Template - Load templates;
• -Help - Load hepl topics;
• -AllWritable - Load only properties of writable objects;
• -Picture - Load common pictures;
• -Right - Load rights.
• –Extension - Process the extension with the specified name. If the
extension is bound to a repository, the objects to be loaded must be
locked in that repository.
If the batch mode command is executed successfully, returns code 0, other-
wise - returns code 1 (and 101 if the data contain errors).
/DumpConfigToFiles <dump directory> [-Format
<mode>] [-Extension <Extension name>] [-
AllExtensions] [–update] [–force] [–getChanges file
name>] [–configDumpInfoForChanges <file name>] [-
listFile <file name>] [-configDumpInfoOnly]
Uploads configuration to files. The following parameters are available:
• -Format - defines the format of upload configuration files:
 Plain - linear format;
  Hierarchical - hierarchical structure. Used by default.
• –Extension - Uploads the specified extension.
• –AllExtensions - Uploads all extensions, doesn't upload main
configuration. Each extension is uploaded to a directory with corre-
sponding name.
• -update - Indicates to update previous unload, that is, upload only
objects with versions differ from the versions of previously uploaded
objects.
Version file (ConfigDumpInfo.xml) is taken from current dump di-
rectory. If the current version of the upload format does not match the
version of the version file format or if the version file is not found, an
error is generated. After upload complete the version file is updated.
It is possible to add the following parameters:
 -force - If the current version of the upload format does not
match the version of the format in the version file, a full upload is
performed.
 -configDumpInfoForChanges - If before upload the current
upload directory is not empty, an error is generated. Matching the
current version of the upload format to the version of the upload
format in the version file is not checked. Upload generates new
version file. The file specified in the -
configDumpInfoForChanges parameter is not updated.
• -force - Perform full upload if attempt to update the upload reveals
the mismatch between the current version of the upload format and the
version of the format stored in the version file (ConfigDump-
Info.xml). Used in combination with the -update parameter only.
Otherwise it is ignored.
• -getChanges <file name> - The specified file contains the list
of changes in the current configuration regarding the upload and, ac-
cordingly, the file of the version which directory is indicated by the
parameter of the command /DumpConfigToFiles. For this pa-
rameter the file name is required.
Can be used with the –configDumpInfoForChanges parameter.
In this case the changes are determined relative to the version file
(ConfigDumpInfo.xml) specified in this parameter. If the file version
is not found when using the -configDumpInfoForChanges pa-
rameter an error is generated.
• -configDumpInfoForChanges <file name> - Specifies the
version file (ConfigDumpInfo.xml) to check changes. This parameter
requires the full file name.
This parameter can be used only with the parameters -update and -
getChanges.
 • -listFile <file name> - Specifies file with the list of objects
unloaded regardless of their update status. For this parameter the file
name is required.
Objects from the list are uploaded completely, except the subordinate
objects that are treated as separate objects of development. To upload
such subordinate objects, they should be explicitly indicated in the list.
If an object from the list has subordinate objects that are not separate
development objects but have external properties, then the external
properties of these objects are also dumped.
In the file containing the names of the objects to be exported, you can
specify the Configuration identifier, which is the equivalent of
the configuration root. If the Configuration identifier is present
in the file, which is not followed by the name of the root configuration
object, then during exporting this identifier will be equivalent to the
full name of the configuration root object, i.e., an entry of the
Configuration.Help type is equivalent to the
Configuration.ConfigurationName.Help entry.
You can use both names containing the Configuration identifier
and the full name of the root configuration object at the same time. In
the event that you want to export two external properties of the root
configuration object, for example Help and Splash, then in the file
with the list of objects you can specify the following lines:
Configuration.Help
Configuration.ConfigurationName.Splash

This parameter can't be used with other parameters.

• -configDumpInfoOnly - specifying this parameter leads to the
fact that only the version file (ConfigDumpInfo.xml) is generated
during dumping. If the -format parameter will be specified in the
command line, the version file will be generated for the specified ex-
port format. By default, a version file is generated for the hierarchical
export format.
This parameter can only be combined with the -format parameter.
Combination with other parameters is not allowed.
See also:
• ConfigDumpInfo.xml.
/LoadConfigFromFiles <export directory> [-Extension
<ExtensionName>] [-AllExtensions] –files
«<files>» –listFile <ListFiles> -Format <mode> [-
updateConfigDumpInfo]
Restores a configuration from files. Loading extensions to the main config-
uration (or vice versa) is not supported. When the configuration files are
fully restored, the restore format (linear or hierarchical) is automatically
determined. For partial restore, the automatic format detection is not sup-
ported. The format should be explicitly specified using the parameter –
Format.
The following parameters are available:
• –Extension - Uploads the specified extension. If the extension
doesn't exist, - it is created. If the extension is bound to a repository it
can't be fully loaded. If the loaded objects are locked in the extension
configuration repository the load may be partial.
• –AllExtensions - The extensions are loaded from files. Each
subdirectory in the specified directory is considered an extension. This
parameter is incompatible with the –files and -listFile param-
eters.
• -files - Specifies which files should be loaded when the configura-
tion is partially loaded from files. Each file can be specified with the
full path or with the relative path for the load directory. The list of
files must be enclosed in quotes; the file names must be separated by
comma. This parameter can't be used with the –AllExtensions
parameter.
• -listFile - Specifies file with list of the loaded files. Files are
listed there one file name per line, each name can be full path to the
file or relative path from the download directory. Strings must be sep-
arated by a line break. Line break is supported in both Windows and
Linux formats. - File is expected to be in UTF-8 encoding. Blank
strings are not supported. If the string starts from REM it is skipped.
This parameter can't be used with the –AllExtensions parameter.
• -Format - defines the format of upload configuration files:
 Plain - linear format;
 Hierarchical - hierarchical structure. Used by default.
This parameter can be used only with the -files or -listFile
parameters.
• -updateConfigDumpInfo - Creates in the end of load the Con-
figDumpInfo.xml version file corresponding to the loaded configura-
tion. If a configuration is being loaded partially (the -files or -
listFile parameter is present), updates the existing version file.
If you specify the –files and –listFile parameters simultaneously,
the parameter specified first in the command line is used.
See also:
• ConfigDumpInfo.xml.
7.4.5. Checking configurations
and extensions
/CheckModules [-ThinClient] [-WebClient] [-
MobileClient] [-MobileAppClient] [-Server] [-
MobileAppServer] [-ExternalConnection] [-
ThickClientOrdinaryApplication] [-
ExtendedModulesCheck] [-Extension <extension name>]
[-AllExtensions]
Checks modules. Specify at least one of the check options, otherwise the
check is not performed. The following parameters are available:
• -ThinClient - Perform the check in thin client mode.
• -WebClient - Perform the check in web client mode.
• -MobileClient - Perform the check in mobile client mode.
• -MobileAppClient - Perform the check in mobile application cli-
ent mode.
• -Server - Perform the check in 1C:Enterprise server mode.
• -MobileAppServer - Perform the check in mobile application
server mode.
• -ExternalConnection - Perform the check in external connec-
tion mode.
• -ThickClientOrdinaryApplication - Perform the check in
client application mode.
• -ExtendedModulesCheck - Check object method and object
property calls using . (dot) for a limited set of types, and check wheth-
er string literals - that serve as parameters for certain functions, such
as GetForm(), are valid.
• -Extension - Performs specified checks for given extension.
• -AllExtensions - Performs specified checks for all extensions.
/IBCheckAndRepair [-ReIndex] [-LogIntegrity | -
LogAndRefsIntegrity] [-RecalcTotals] [-
IBCompression] [-Rebuild] [–RebuildStandaloneCfg]
[-TestOnly | [[-BadRefCreate | -BadRefClear | -
BadRefNone] [-BadDataCreate | -BadDataDelete]]] [-
UseStartPoint] [-TimeLimit:hhh:mm]
Performs the testing and correction for infobase. The following parameters
are available:
• -ReIndex - The tables re-indexing;
• -LogIntegrity - Check the logical integrity;
 • -LogAndRefsIntegrity - Check the logical and reference integ-
rity;
• -RecalcTotals - Totals recalculation;
• -IBCompression - The tables compression. For the file variant a
special optimization is also performed.
• -Rebuild - Infobase tables restructuring.
• -RebuildStandaloneCfg - rebuilds a configuration which is in-
tended to be used on a mobile client in standalone mode.
• -TestOnly - Tests the infobase only. If testing and correction of
the infobase are specified (-TestOnly parameter is missing), you
can specify the following parameters:
In case of references to non-existent objects:
 -BadRefCreate - Create objects;
 -BadRefClear - Clear objects;
 -BadRefNone - Do not change with partially missing objects.
In case of partially missing objects:
 -BadDataCreate - Create objects;
 -BadDataDelete - Delete objects.
• -UseStartPoint -Continue testing from the saved point of return
at which tests were interrupted in the previous session.
• -TimeLimit:hhh:mm - Limited maximum time of the test session:
 hhh - hours (0..999);
 mm - minutes (0..59).
When specifying a parameter please note that some processes can't be
interrupted at arbitrary time during testing and correction, and some
processes can't be interrupted at all. Therefore, the execution is inter-
rupted after the specified time, but only when it is possible. In other
words, you should not expect that if you specify time limit of 1 hour,
the testing and correction will be interrupted exactly after 1 hour.
Simultaneous use of parameters within the subgroup of parameters is not
possible.
/CheckConfig [-ConfigLogIntegrity] [-
IncorrectReferences] [-ThinClient] [-WebClient] [-
MobileClient] [-MobileAppClient] [-Server] [-
MobileAppServer] [-MobileClientStandalone] [-
ExternalConnection] [-ExternalConnectionServer] [-
ThickClientManagedApplication] [-
ThickClientServerManagedApplication] [-
ThickClientOrdinaryApplication] [-
ThickClientServerOrdinaryApplication] [-
DistributiveModules] [-UnreferenceProcedures] [-
HandlersExistence] [-EmptyHandlers] [-
ExtendedModulesCheck] [-CheckUseModality] [-
CheckUseSynchronousCalls] [-UnsupportedFunctional]
[-MobileClientDigiSign] [-Extension <Имя
расширения>] [-AllExtensions]
Centralized configuration test. The following parameters are available:
• -ConfigLogIntegrity - Check the logical integrity of the con-
figuration. It is the standard check (typically performed before updat-
ing the database).
• -IncorrectReferences - Search for invalid references. Search
references to deleted objects. The search is performed in the entire
configuration, including rights, forms, templates, interfaces, and so on.
In addition the system searches for logically incorrect links.
• -ThinClient - Perform module syntax check for managed applica-
tion environment emulation mode (thin client, file mode).
• -WebClient - Perform module syntax check in web client environ-
ment emulation mode.
• -MobileClient - Perform module syntax check in mobile client
environment emulation mode.
• -Server - Perform module syntax check in 1C:Enterprise server en-
vironment emulation mode.
• -ExternalConnection - Perform module syntax check in exter-
nal connection environment emulation mode (file mode).
• -ExternalConnectionServer - Perform module syntax check
in external connection environment emulation mode (client/server
mode).
• -MobileAppClient - Perform module syntax check in mobile
platform environment emulation mode (client mode).
• -MobileAppServer - Perform module syntax check in mobile
platform environment emulation mode (server mode).
• -MobileClientStandalone - syntactic control of modules in
the mode of emulation of the mobile client environment, performed in
standalone mode.
• -ThickClientManagedApplication - Perform module syntax
check in managed application environment emulation mode (thick cli-
ent, file mode).
• -ThickClientServerManagedApplication - Perform mod-
ule syntax check in managed application environment emulation mode
(thick client, client/server mode).
• -ThickClientOrdinaryApplication - Perform module syn-
tax check in ordinary application environment emulation mode (thick
client, file mode).
• -ThickClientServerOrdinaryApplication - Perform
module syntax check in ordinary application environment emulation
mode (thick client, client/server mode).
• -ExternalConnection - Perform module syntax check in exter-
nal connection environment emulation mode (file mode).
• -ExternalConnectionServer - Perform module syntax check
in external connection environment emulation mode (client/server
mode).
• -DistributiveModules - Deliver modules without their
sources. If the configuration distribution settings specify that some
modules are delivered without their sources, check whether module
images can be generated.
• -UnreferenceProcedures - Search for unused procedures and
functions. Search for local (not exported) procedures and functions
that are never referenced, including unused event handlers.
• -HandlersExistence - check the existence of assigned handlers.
Check the availability of handlers assigned to interfaces, forms, and
controls.
• -EmptyHandlers - check for empty handlers. Search for event
handlers that perform no actions. Such handlers can impact the system
performance.
• -ExtendedModulesCheck - Check object method and object
property calls using . (dot) for a limited set of types, and check wheth-
er string literals - that serve as parameters for certain functions, such
as GetForm() are valid.
• -CheckUseModality - Search the modules for modal method
calls. Use this parameter only with -
ExtendedModulesCheck parameter.
• -CheckUseSynchronousCalls - Search the modules for syn-
chronous method calls. Use this parameter only with -
ExtendedModulesCheck parameter.
• -UnsupportedFunctional - Search for functionality that can't
be performed in the mobile application. This includes the following:
 Metadata that do not have their classes implemented in the mobile
platform.
 Exchange plans in configuration that have the Distributed in-
fobase property.
 Types not implemented in the mobile platform:
 In Type properties of metadata attributes, constants, and ses-
sion parameters.
 In Command parameter type property of the Com-
mand configuration object.
  In Type property of attributes and form attribute columns.
 Forms having Ordinary type.
 Form controls that are not implemented in the mobile platform.
(the check is not performed for forms which Use purpos-
es property does not include mobile devices)
 Complex desktop (contains multiple forms)
• -MobileClientDigiSign - Verify the digital signature of the
configuration for the mobile client.
• -Extension - Performs specified checks for given extension.
• -AllExtensions - Performs specified checks for all extensions.
/CheckCanApplyConfigurationExtensions [-Extension
<extension name>] [-AllZones] [-Z «separators»]
Checks whether the extension can be used with the specific infobase.
The following parameters are available:
• -Extension - Check for the specified extension considering all
previously loaded extensions. If the extension name is not specified,
then all extensions are checked in order of load.
• -AllZones - Check the extension in all data areas of the current in-
fobase.
 The -Extension and –AllZones parameters, and the –Z and –
AllZones parameters can't be used together.
 The result of checking the applicability of the extensions for each
area is preceded by the string of -Z, followed by the separators for
the tested area.
• -Z - setting separator values to test. If the -Z option is not specified,-
the data area with unspecified separators is tested.
If the -Z parameter and the /Z command are specified at the same
time, the separators specified in the -Z parameter are used to launch
the Designer and user selection. The separators specified in the /Z
command are used to specify the data area to test the applicability of
the extension.

7.4.6. Configuration support

/UpdateCfg <CF or CFU file name> -Settings <set-
tings file name> [-IncludeObjectsByUnresolvedRefs |
-ClearUnresolvedRefs] [-
DumpListOfTwiceChangedProperties] [-force]
Update a supported configuration.
Merge current configuration with a file (using settings file).
The following parameters are available:
 • <cf- or cfu file name> - name of the file with configuration
to be merged (.cf file) or with the configuration update file (.cfu file).
• -Settings <settings file name> - allows to specify the
configuration merging settings file name.
• -IncludeObjectsByUnresolvedRefs - if merge settings con-
tain the objects that are not included in the list of merged ones and ab-
sent not in the main configuration, but referenced from objects includ-
ed in the list, then such objects are also marked for merging, and an at-
tempt is made to continue the merging. Attempts are made until there
are objects referencing the objects that are not included, or until the
complete configuration is selected. Similar to Mark All for Merging
button in the window with unresolved references, repeating of at-
tempts only.
• -ClearUnresolvedRefs - references to objects, not included in
the list of merged objects, are cleared. Similar to Continue button in
the window with unresolved references.
• -DumpListOfTwiceChangedProperties - output a list of the
properties changed two times to a service message file.
• -force - perform merging, if there are:
 warnings of deleted objects referenced in the objects not included
in the merging (such objects will be excluded from the merging).
 warnings of the properties, that have been changed twice and for
which the merging mode has not been selected (such properties
will be merged with default settings).
 objects, which are restricted from changing by the support rules
(such objects will be excluded from merging).
 settings applying warnings.
The merging will be interrupted in the above cases, unless specified.
Warning of the properties that have been changed twice will be output to
file for outputting the service messages, which are output to service mes-
sages file regardless of -force parameter.
/ManageCfgSupport [-disableSupport [-force]]
Allows to disable the configuration support. The following parameters are
available:
• -disableSupport - specifies the requirement to disable configu-
ration support. The error is generated, if the parameter is absent.
• -force - disable the configuration support event if the changes are
restricted in configuration. The error is generated if the parameter is
absent and if the attempt to disable the configuration support is made
for the configuration, for which the changes are restricted in the sup-
port control interactive mode.
7.4.7. Commands for creating
distribution and update
files
/CreateTemplateListFile <file name> [-
TemplatesSourcePath]
Create the configuration template file. The following directories and param-
eters are available:
• <file name> - configuration template list file name. If this is not
specified, the file is created in the specified directory with default
name; if the name only is specified, the file is created with the speci-
fied name in the specified directory. The following path is used, if the
full path is specified;
• -TemplatesSourcePath - path for configuration template files
searching. If it is not specified, the path, specified in the startup set-
tings dialog box, is used.
/CreateDistributivePackage <directory name> -File
<distribution pachage description file name> -
PackageFileName <archive name> [-Option <distribu-
tion option>] [-MakeSetup] [-MakeFiles] [-digisign
<license parameters file name>] [-WarningAsError]
Create a distribution package archive or distribution package files based on
a distribution package description. If the configuration contains the mobile
client signature, the check, if the specified signature matches the configura-
tion meta-data, is performed before command execution. If the configura-
tion signature does not match the configuration, the diagnostic message is
generated and the further system behavior is determined by the -
WarningAsError parameter.
It is possible to use either -MakeSetup or -MakeFiles parameter. If
none of these parameters are specified, the -MakeSetup is used (i.e. dis-
tribution package is created). The following directories and parameters are
available:
• <distribution package creation directory> - speci-
fies the distribution package creation directory or distribution package
files directory.
• -File <distribution package descrition file> -
specifies the distribution package description file.
• -PackageFileName <archive name> - distribution package
zip archive file name. The archive is created in <distribution
package creation directory>. Used in combination with -
 MakeSetup parameter only. If the specified file name has ".zip" ex-
tension, it will be added automatically. If the parameter is no speci-
fied, the default name will be used: updsetup.zip.
• -Option <distribution option> - create a distribution op-
tion based on the distribution package description. The Complete dis-
tribution option is used by default.
• -MakeSetup - create the distribution package.
• -MakeFiles - create the distribution package files.
• -digisign <licence parameters file name> - specifies
the user workplace licensing parameters.
• -WarningAsError - if this parameter is specified, mismatch of
mobile client digital signature with the current meta-data is interpreted
as error with process termination. If the parameter is not specified -
signature and configuration mismatch is not treated as an error and the
process is not interrupted.
/CreateDistributionFiles [-cffile <cf file name>]
[-cfufile <cfu file name> [-f <cf file name>|-v
<distribution package version>]+][–digisign <li-
cense parameters file name>] [-WarningAsError]
Create the distribution and update files. If the configuration contains the
mobile client signature, the check, if the specified signature matches the
configuration meta-data, is performed before command execution. If the
configuration signature does not match the configuration, the diagnostic
message is generated and the further system behavior is determined by the -
WarningAsError parameter.
The following directories and parameters are available:
• -cffile <cf file name> - indicates to create the distribution
file;
• -cfufile <cfu file name> - indicates to create the update
file;
• -f <cf file name> - the name of the distribution package, in-
cluded in the update;
• -v <distribution package version> - the version of the
distribution package, included in the update;
• -digisign <licence parameters file name> - specifies
the user workplace licensing parameters.
• -WarningAsError - if this parameter is specified, mismatch of
mobile client digital signature with the current meta-data is interpreted
as error with process termination. If the parameter is not specified -
signature and configuration mismatch is not treated as an error and the
process is not interrupted.
-f <cf file name>|-v <distribution package version>
parameters group is repeated for each distribution package file included in
the update.
/CreateDistributive <distribution package creation
directory> -File <distribution package description
file name> [-Option <distibution option>] [-
MakeSetup] [-MakeFiles] [-digisign <license parame-
ters file name>] [-WarningAsError]
NOTE. This command is depreciated and not recommended for use.
Create a distribution package or distribution package files based on a distri-
bution package description. If the configuration contains the mobile client
signature, the check, if the specified signature matches the configuration
meta-data, is performed before command execution. If the configuration
signature does not match the configuration, the diagnostic message is gen-
erated and the further system behavior is determined by the -
WarningAsError parameter.
It is possible to use either -MakeSetup or -MakeFiles parameter. If
none of these parameters are specified, the -MakeSetup is used (i.e. dis-
tribution package is created). The following directories and parameters are
available:
• <distribution package directory> - specifies the distri-
bution package creation directory or distribution package files directo-
ry;
• -File <distribution package description file> -
specifies the distribution package description file;
• -Option <distribution option> - create a distribution op-
tion based on the distribution package description. The Complete dis-
tribution option is used by default;
• -MakeSetup - create the distribution package;
• -MakeFiles - create the distribution package files;
• -digisign <licence parameters file name> - specifies
the user workplace licensing parameters.
• -WarningAsError - if this parameter is specified, mismatch of
mobile client digital signature with the current meta-data is interpreted
as error with process termination. If the parameter is not specified -
signature and configuration mismatch is not treated as an error and the
process is not interrupted.
7.4.8. External reports and
data processors
When dumping/loading the external data processors (reports) you need to
understand the process of type information in XML files when applied to
batch mode. If the external data processor (reports) reference to the configu-
ration objects, when dumping such data processor (report) to files, types of
such references shall be dumped as a unique type IDs. Therefore, when
loading from such files the type will be determined only if the data proces-
sor is loaded to the same configuration or to the configuration, which is the
child object of the configuration, from which the dumping has been per-
formed. The types will be defined incorrectly in other cases.
In order to avoid this dumping and loading must be performed after specify-
ing the infobase connection parameters in the Designer batch start command
line. In this case the text type representations will be output in the dump
files instead of the unique IDs. In order to have the reference to a real con-
figuration type in the data processor generated at loading it is required to
specify the infobase parameter at loading. If the loading is performed with-
out specifying these parameters, the type data will be lost.
If the external data processor (report) does not reference to the configura-
tion objects, such objects may be dumped/loaded without specifying the
infobase connection parameters.
/DumpExternalDataProcessorOrReportToFiles <dump
root file> <external data processor (report)> [-
Format Plain|Hierarchical]
Dumps external data processor (report) in XML format. Format 2.0 dump is
used.
The following parameters are available:
• <dump root file> - contains full path to the dump root directo-
ry. Mandatory parameter.
• <external data processor (report)> - full path to ex-
ternal data processor (report) in .epf (.erf) format.
• -Format - specifies dump format:
 Plain - linear format;
 Hierarchical - hierarchical format (default).
/LoadExternalDataProcessorOrReportFromFiles <dump
root file> <external data processor (report)>
Loads the external data processor (report) from XML format. Format 2.0
dump is used.
The following parameters are available:
 • <dump root file> - contains the full path to the root directory,
containing the external data processor (report) in XML format files.
Mandatory parameter.
• <external data processor (report)> - full path to the
external data processor (report) in .epf (.erf) format, resulting from
the dumping. Resulting file extensions will be determined automati-
cally based on XML files. If the extension is incorrect in the command
line -, it will be automatically replaced with the required extension.

7.4.9. Mobile application

/MobileAppUpdatePublication
Update mobile application publication if created earlier, otherwise the error
is generated. Preliminary update of the database configuration is possible.
/MobileAppWriteFile <zip-file name>
Save configuration to a zip-file. The specified file may be used to build an
application for a mobile device. The file contains configuration description
and related data. Preliminary update of the database configuration is possi-
ble.

7.4.10. Mobile client

/MobileClientWriteFile <file name>
Save configuration to a file. The specified file may be used to build an ap-
plication for a mobile device. Preliminary update of the database configura-
tion is possible.
/MobileClientDigiSign
Sign the mobile client configuration. Preliminary update of the database
configuration is possible.

7.4.11. Event log

/ReduceEventLogSize <Date> [-saveAs <file name>] [-
KeepSplitting]
Truncate the event log. The following parameters are available:
• Date - new event log limit in YYYY-MM-DD format;
• -saveAs <file name> - parameter to save a copy of the export-
ed records;
• -KeepSplitting - required to preserve splitting into files in peri-
ods.
7.4.12. Deleting data
/EraseData [/Z[<separators>]]
Delete the infobase data. Parameter /Z specifies the region to delete data
from. Only users with the Administration right can delete the data.

7.4.13. Predefined data

/SetPredefinedDataUpdate [-Auto] [-
UpdateAutomatically] [-DoNotUpdateAutomatically]
The parameter is intended for specifying the predefined data update modes.
The following parameters are available:
• -Auto - actual value is calculated automatically (default value). For
the master infobase node - value will be -
UpdateAutomatically, for subordinate infobase node this wiil
be -DoNotUpdateAutomatically.
• -UpdateAutomatically - predefined elements will be created
and existing values will be updated automatically during infobase re-
structuring.
• -DoNotUpdateAutomatically - new predefined elements will
not be created and their values will not be updated automatically dur-
ing infobase restructuring.

7.4.14. Distributed infobase

/ResetMasterNode
Cancel distributed infobase master node assignment. Parameter is similar to
call of SetMasterNode() method with Undefined parameter value.

7.4.15. Configuration
repository operations
7.4.15.1. Repository access parameters
Commands, specifying the configuration repository parameters, may be
combined with the other repository operations commands.
/ConfigurationRepositoryF <repository directory>
The parameter is intended for specifying the configuration repository path.
/ConfigurationRepositoryN <name>
The parameter is intended for specifying the configuration repository
username.
/ConfigurationRepositoryP <password>
The parameter is intended for specifying the configuration repository user
password.

7.4.15.2. Creating repositories

/ConfigurationRepositoryCreate [-
AllowConfigurationChanges -ChangesAllowedRule <Sup-
port rule> -ChangesNotRecommendedRule <Support
rule>] [-NoBind] [-Extension <Extension name>]
Create the configuration repository. The following parameters are available:
• -AllowConfigurationChanges - allow configuration changes,
if the configuration is supported and changes are not allowed.
• -ChangesAllowedRule <Support rule> - sets a support
rule for the objects with changes allowed by vendor. The following
rules are available:
 ObjectNotEditable - vendor object is not editable,
 ObjectIsEditableSupportEnabled - vendor object is ed-
itable, support enabled,
 ObjectNotSupported - vendor object is not supported.
• -ChangesNotRecommendedRule - sets a support rule for the ob-
jects with changes not recommended by vendor. The following rules
are available:
 ObjectNotEditable - vendor object is not editable,
 ObjectIsEditableSupportEnabled - vendor object is ed-
itable, support enabled,
 ObjectNotSupported - vendor object is not supported.
• -NoBind - no binding to the created repository.
• -Extension <Extension name> - allows to specify the name
of extension, the repository of which will be created by the command.
If the parameter is not specified -, main configuration repository will
be created.
7.4.15.3. User management
/ConfigurationRepositoryAddUser -User <Name> -Pwd
<Password> -Rights <Rights> [-RestoreDeletedUser]
[-Extension <Extension name>]
Create a configuration repository user. The user currently connected to the
repository must have administrative rights. If a user with the specified name
exists, the user is not created. The following parameters are available:
• -User - name of the user created.
• -Pwd - password of the user created.
• -Rights - rights granted to the user. Values:
 ReadOnly - viewing right,
 LockObjects - objects locking right,
 ManageConfigurationVersions - version change right,
 Administration - right to use administrative functions.
• -RestoreDeletedUser - if a deleted user with the same name is
found, this user is restored.
• -Extension <Extension name> - allows to specify the name
of extension, with the repository of which the command will be exe-
cuted. If the parameter is not specified-, the operation is performed
with the main configuration repository.
/ConfigurationRepositoryCopyUsers -Path <path> -
User <Name> -Pwd <Password> [-RestoreDeletedUser]
[-Extension <Extension name>]
Copy the users from the other configuration repository. Deleted users can-
not be copied. If a user with the specified name exists, the user cannot be
added. The following parameters are available:
• -Path - path to the source repository.
• -User - user in the source repository.
• -Pwd - user password in the source repository.
• -RestoreDeletedUser - if a deleted user with the same name is
found, this user is restored.
• -Extension <Extension name> - allows to specify the name
of extension, with the repository of which the command will be exe-
cuted. If the parameter is not specified-, the operation is performed
with the main configuration repository.

7.4.15.4. Objects management

/ConfigurationRepositoryLock [–Objects <file name>]
[-revised] [-Extension <Extension name>]
Locks objects from configuration repository for editing.
The following parameters are available:
• -Objects <file name> - path to a file with the list of objects to
be involved in the operation. If the file is specified -, the operation in-
volves the objects specified in the file only, otherwise the operation
involves the complete configuration.
• -revised - get locked objects if required.
• -Extension <Extension name> - allows to specify the name
of extension, with the repository of which the command will be exe-
cuted. If the parameter is not specified-, the operation is performed
with the main configuration repository.
Batch mode return code:
• 0 - no errors.
• 1 - there are errors. Error text is output to the service message file.
/ConfigurationRepositoryUnLock [–Objects <file
name>] [-force] [-Extension <Extension name>]
Releases locked objects in configuration repository.
The following parameters are available:
• -Objects <file name> - path to a file with the list of objects to
be involved in the operation. If the file is specified -, the operation in-
volves the objects specified in the file only, otherwise the operation
involves the complete configuration.
• -force - describes the behaviour with the objects changed locally:
 Parameter is specified - locally changed objects will be retrieved
from the repository. Changes will be lost.
 Parameter is not specified - the error will be generated for the lo-
cally changed objects, and the operation will be cancelled for all
the objects involved in the operation.
• -Extension <Extension name> - allows to specify the name
of extension, with the repository of which the command will be exe-
cuted. If the parameter is not specified-, the operation is performed
with the main configuration repository.
Batch mode return code:
• 0 - no errors.
• 1 - there are errors. Error text is output to the service message file.
/ConfigurationRepositoryCommit [–Objects <file
name>] [-comment <comment text>] [-keepLocked] [-
force] [-Extension <Extension name>]
Stores object changes to configuration repository.
The following parameters are available:
• -Objects <file name> - path to a file with the list of objects to
be involved in the operation. If the file is specified -, the operation in-
 volves the objects specified in the file only, otherwise the operation
involves the complete configuration.
• -comment <comment text> - comment to the stored objects.
Must be put in double quotes. To specify the comment in several lines
each line mush be specified using its own -comment parameter.
• -keepLocked - keep the stored objects locked. If it is not specified,
the objects involved in the operation will be released after storing the
changes.
• -force - describes the behaviour if the references to deleted objects
are detected:
 Parameter is specified - reference deletion attempt will be made.
 Parameter is not specified - error will be generated.
• -Extension <Extension name> - allows to specify the name
of extension, with the repository of which the command will be exe-
cuted. If the parameter is not specified-, the operation is performed
with the main configuration repository.
Batch mode return code:
• 0 - no errors.
• 1 - there are errors. Error text is output to the service message file.

7.4.15.5. Managing configurations

/ConfigurationRepositoryBindCfg [-
forceBindAlreadyBindedUser] [-forceReplaceCfg] [-
Extension <Extension name>]
Binds the previously unbound infobase to configuration repository. The
following parameters are available:
• -forceBindAlreadyBindedUser - binds even if this user al-
ready has the configuration bound to this repository.
• -forceReplaceCfg - if the configuration is not empty, this pa-
rameter confirms replacement of the configuration with the configura-
tion from repository.
• -Extension <Extension name> - allows to specify the name
of extension, with the repository of which the command will be exe-
cuted. If the parameter is not specified-, the operation is performed
with the main configuration repository.
/ConfigurationRepositoryUnbindCfg [-force] [-
Extension <Extension name>]
Unbind the configuration from the configuration repository (user must have
administrator rights in this infobase). If a user is authenticated in the reposi-
tory (interactively or via command-line parameters) the configuration un-
binding also affects the repository (the binding data is deleted). If a user is
not authenticated in the repository, the configuration is only locally un-
bound from the repository.
If the configuration contains locked objects that have been modified in re-
gard to the repository, the respective message is displayed the unbinding is
not performed.
–force - the parameter is intended for skipping the authentication dialog
box (if the repository user parameters are not specified) and for ignoring
captured and modified objects.
-Extension <Extension name> - the parameter allows to specify
the extension name, with the repository of which the command will be exe-
cuted. If the parameter is not specified-, the operation is performed with the
main configuration repository.
/ConfigurationRepositoryDumpCfg <cf file name> [-v
<repository version number>] [-Extension <Extension
name>]
Save configuration from repository to a file. The following parameters are
available:
• -v <repository version number> - version number, if the
version number is not specified or equals -1, the latest version will be
saved.
• -Extension <Extension name> - allows to specify the name
of extension, with the repository of which the command will be exe-
cuted. If the parameter is not specified-, the operation is performed
with the main configuration repository.
/ConfigurationRepositoryUpdateCfg [-v <repository
version number>] [-revised] [-force] [-Objects
<file name>] [-Extension <Extension name>]
Update configuration from repository.
The following parameters are available:
• -v<repository version number> - version number in con-
figuration repository. If the configuration is bound to a repository, the
version number (if specified) will be ignored and the latest repository
configuration version will be retrieved. If the configuration is not
bound to a repository, the specified version will be retrieved. If the
version is not specified (or the value equals -1), - the latest configura-
tion version will be retrieved.
• -revised - get locked objects if required. If the configuration is not
bound to a repository, this parameter will be ignored.
• -force - if the new configuration objects are expected to be re-
trieved or the existing ones are expected to be deleted from the reposi-
tory during the batch configuration update, specifying this parameter
 confirms approval of the above operations by the user. If the parame-
ter is not specified -, the actions will be skipped.
• -Objects <file name> - path to a file with the list of objects to
be involved in the operation. If the file is specified -, the operation in-
volves the objects specified in the file only, otherwise the operation
involves the complete configuration.
• -Extension <Extension name> - allows to specify the name
of extension, with the repository of which the command will be exe-
cuted. If the parameter is not specified-, the operation is performed
with the main configuration repository.

7.4.15.6. Service operations

/ConfigurationRepositorySetLabel [-v <repository
version number>] [-name] <label name> [-comment
<comment text>] [-Extension <Extension name>]
Sets the repository version label.
The following parameters are available:
• -v <repository version number> - repository version
number for setting the label. If the version is not specified, the label is
set for the latest repository version. If the specified version does not
exist, the error is displayed.
• -name <label name> - label text in double quotation marks.
• -comment <comment text> - text of a comment to a label being
set. Must be put in double quotes. To specify the comment in several
lines each line mush be specified using its own -comment parameter.
• -Extension <Extension name> - allows to specify the name
of extension, with the repository of which the command will be exe-
cuted. If the parameter is not specified-, the operation is performed
with the main configuration repository.
Batch mode return code:
• 0 - no errors.
• 1 - there are errors. Error text is output to the service message file.
/ConfigurationRepositoryReport <file name> [-NBegin
<version number>] [-NEnd <version number>] [-
GroupByObject] [-GroupByComment] [-Extension <Ex-
tension name>]
Generate a repository history report. If the grouping options are not speci-
fied and the configuration compatibility mode is Do not use, the report
shall be generated with version-based grouping. The report will be generat-
ed with object-based grouping in Version 8.1 and Version 8.2.13 compat-
ibility modes. If the database configuration compatibility property does not
match the compatibility property of the configuration being edited, the val-
ue of database configuration compatibility mode is considered when pro-
cessing the command line. The following file names and parameters are
available:
• <file name> - the report file name;
• -NBegin - number of stored version, used as the first version for re-
port generation;
• -NEnd - number of the stored version, used as the last version for re-
port generation;
• -GroupByObject - flag to generate a report by version with group-
ing by objects;
• -GroupByComment - flag to generate a report by version with
grouping by comments;
• -Extension <Extension name> - allows to specify the name
of extension, with the repository of which the command will be exe-
cuted. If the parameter is not specified-, the operation is performed
with the main configuration repository.
/ConfigurationRepositoryOptimizeData [-Extension
<Extension name>]
Optimizes data storage in the configuration repository.

7.4.15.7. Managing repository caches

/ConfigurationRepositoryClearCache [-Extension <Ex-
tension name>]
Clear the local configuration repository database.
-Extension <Extension name> parameter allows to specify the
name of extension, with the repository of which the command will be exe-
cuted. If the parameter is not specified-, the operation is performed with the
main configuration repository.
/ConfigurationRepositoryClearLocalCache [-Extension
<Extension name>]
Clear the local configuration version cache.
-Extension <Extension name> parameter allows to specify the
name of extension, with the repository of which the command will be exe-
cuted. If the parameter is not specified-, the operation is performed with the
main configuration repository.
/ConfigurationRepositoryClearGlobalCache [-
Extension <Extension name>]
Clear the global configuration version cache.
-Extension <Extension name> parameter allows to specify the
name of extension, with the repository of which the command will be exe-
cuted. If the parameter is not specified-, the operation is performed with the
main configuration repository.

7.4.16. Agent mode commands

/AgentMode
Enable Designer Agent mode. If this command is present,
/DisableStartupMessages /DisableStartupDialogs com-
mands are ignored, if specified.
/AgentPort <Port>
Specifies the TCP port to be used by Designer Agent in SSH server mode.
If the command is not specified, Designer Agent uses TCP port 1543 by
default.
/AgentListenAddress <Address>
Command parameter allows to specify the IP address, which Designer
Agent listens to. If the command is not specified, IP address 127.0.0.1 will
be used by default.
/AgentSSHHostKey <private key>
Command parameter allows to specify the path to private host key. If the
parameter is not specified, /AgentSSHHostKeyAuto command must be
specified. If none of the commands are specified -, Designer cannot start in
Agent mode.
/AgentSSHHostKeyAuto
The command specifies, the host private key is located in the directory be-
low (depending on the operating system):
• On Windows OS: %LOCALAPPDATA%\1C\1cv8\host_id.
• On Linux: ~/.1cv8/1C/1cv8/host_id.
• On macOS: ~/.1cv8/1C/1cv8/host_id.
If the specified file is not found, a new 2048-bit private RSA key is generat-
ed.
/AgentBaseDir <working directory>
This command allows to specify the working directory, which is used for
SFTP server and for configuration dump and restore commands.
If the command is not specified, the following directory is used:
• On Windows: %LOCALAPPDATA%\1C\1cv8\<Unique infobase
ID>\sftp.
• On Linux: ~/.1cv8/1C/1cv8/<Unique infobase ID>/sftp.
 • On macOS: ~/.1cv8/1C/1cv8/<Unique infobase ID>/sftp.

7.4.17. Other parameters

/Visible
Makes the batch command execution visible to the user. A splash screen is
displayed during the Designer mode operation.
When executed in Agent mode - the message box is displayed.
/RunEnterprise
Start "1C:Enterprise" after batch command execution. The additional com-
mand line may be specified after the command. The parameters passed in it
will be used instead of current session parameters during "1C:Enterprise"
start. Additional command line must be put into quotation marks. If it has
nested quotation marks, these must be doubled.
/ConvertFiles <file name|path>
Perform batch 1C:Enterprise 8.x. files conversion <file name|path> -
file or directory name.
If the directory is specified, all the documents available in this directory and
all its subdirectories are converted. The files must be writable for successful
conversion. If the file specified is parameter is not writable, the error mes-
sage is generated.
In the directory operation mode the non-writable files are skipped without
an error message.
The Designer mode must be started and the configuration, where the con-
version will be performed, must be opened for this function to operate. In-
fobase name and authentication parameters may be specified using the
standard command line parameters. If these parameters are not specified,
the respective requests will be displayed similar to the other command line
functions operating in Designer mode.
/DumpResult <file name>
Dump Designer operation result to file. The result - is a number (0 - if the
file is saved successfully).

7.5. Batch client application

start mode
Batch start mode of the client application - is a dedicated start mode. During
operation of this mode, the 1C:Enterprise platform does not generate dialog
boxes. This mode is effective from the moment of start to the end of the
execution of the BeforeSystemStartWork event handler of the appli-
cation module. WhenSystemStartWork event handler is called upon
completion of the batch mode of the client application. The client applica-
tion work does not automatically end after the end of the batch mode for
start the client application. Batch mode for start the client application is
supported by thin and thick client applications and is activated by the
/DisableStartupDialogs command of the command line for start
the client application. The web client does not support batch mode. Errors
that occur during the execution of the batch mode for starting the client ap-
plication can be written to the service message output file. Service message
output files are specified with the /Out command.
When working in batch mode for starting the client application, all the fea-
tures of the /DisableStartupDialogs command are in effect, in ad-
dition, a number of other features are applied.
If during the batch mode for starting the client application, a call to some
asynchronous method is executed, then:
• Such methods will be executed after the execution of the
BeforeSystemStart event handler, but before the completion of
the batch mode. This behavior will be observed if the client applica-
tion started successfully and the main application window opens.
• If the batch mode ended with a failure to start the application (the
Failure parameter of the BeforeSystemStart event handler
is set to True), then asynchronous calls will not be made.
The client application batch mode does not support opening windows. In a
scenario where a window is about to be open:
• The window is blocked.
• An error is generated.
To define that the client application is currently prohibited from opening
windows, the ProhibitFormOpening() global context method is
used.
The external processing, passed as the value of the /Execute command,
starts after the batch mode of the client application ends.
If during execution of the
StartApplications()/BeginStartApplication() global con-
text methods a runtime error is detected, an exception will be generated
when working in the batch mode.
7.6. Registering
1C:Enterprise as OLE
Automation server
/RegServer [-AllUsers | -CurrentUser | -Auto]
Register V83.Application and V83C.Application objects. One of the follow-
ing parameters may be used:
• -AllUsers - the objects are registered for all the PC users. If the us-
er has insufficient rights to register, the error message is generated. If
the /Out <FileName> parameter is specified, the message is out-
put to file, otherwise the message- is displayed at the user screen.
• -CurrentUser - the objects are registered for the current user.
• -Auto - the objects are registered for all the PC users, if the user has
sufficient rights. If the user does not have sufficient rights, the objects
are registered for the current user. No dialog boxes are displayed.
If the optional parameters are not specified, the registration is performed
subject to the rights of the registering user:
• if the user has the rights to register for all the PC users-, the object is
registered for the PC;
• if the user has insufficient rights to register for all the PC users -, the
user is prompted to register for the current user.
/UnregServer
Unregister V83.Application and V83C.Application objects.

7.7. Infobase connection

string
7.7.1. General information
Connection string- is a string defining infobase parameters, where each of
this is a fragment in the following format <Parameter
name>=<Value>, where:
• Parameter name - parameter name;
• Value - parameter value.
Fragments are separated by ;. If the value contains spaces, it must be put in
double quotation marks ("). Parameter set is determined by the created in-
fobase type- file-based or client-server infobase. There is also a common
parameter set, applicable for any infobase type.
Connection string is specified as a list of infobases under the list, may be set
in a mode selection command line parameter CREATEINFOBASE, as a
CreateInitialImage() methods parameter.

7.7.2. Common parameter set

Usr
Specifies the user name.
Pwd
Specifies user password.
LicDstr
Manages the client licenses through the 1C:Enterprise server. Parameter
value:
• Y - acquire client licence through 1C:Enterprise server. If the client
application did not acquire the software or hardware license from the
HASP local or network key, the attempt is made to acquire the license
through 1C:Enterprise server.
• N - do not acquire client licence through 1C:Enterprise server. Default
value.
Z n
Specify the application solution separator values.
prmod
Specifies the need to start the system in the privileged mode (parameter
value is 1). Authenticated user with administrator rights is permitted to start
the system. A record stating that the privileged session mode is set or cannot
be set is added to the event log.

7.7.3. File-based infobase

parameters
File
Directory name, where the infobase file is located;
Locale
Language (country) to be used during infobase opening or creation. This
parameter has available values similar to <Format string> parameter
in Format() method. Locale parameter is optional. If the parameter is
not specified, the regional settings of the current infobase will be used.
DBFormat
Specifies the format to create the file-based database.
Values: 8.2.14 and 8.3.8.
Default value: 8.2.14.
DBPageSize
Specifies the page size of the created database in 8.3.8 format (format is
defined in DBFormat parameter).
Values: 4096 or 4k, 8192 or 8k, 16384 or 16k, 32768 or 32k, 65536
or 64k.
Default value: 4096 or 4k.

7.7.4. Client-server infobase

parameters
Srvr
Srvr - 1C:Enterprise server name in format:
[<protocol>://]<address>[:<port>], where:
• <protocol> - optional, TCP is only supported,
• <address> - server name or IP address in IPv4 or IPv6 formats,
• <port> - optional, default main cluster manager port is 1541.
Example:
• server - server name is specified, other parameters have default
values;
• tcp://server:1641 - protocol, server name and port are speci-
fied;
• 127.0.0.1:1541 - server IP address (in IPv4 format) and port are
specified;
• [fe10::c47b:90b7:fa32:a2fa%12] - server IP address (in
IPv6 format) is specified, where the protocol and port have default
values.
In order to ensure the uninterrupted running of the client applications sever-
al cluster addresses may be specified. For that:
• Srvr parameter value may contain the list of cluster addresses sepa-
rated by commas. Spaces cannot be used in this list.
• In the infobase adding dialog box of the client application the
1C:Enterprise server cluster property value may contain the list of
cluster addresses separated by commas.
Ref
Name of the infobase stored on the 1C:Enterprise server.
DBMS
Database server type:
• MSSQLServer - Microsoft SQL Server;
• PostgreSQL - PostgreSQL;
• IBMDB2 - IBM DB2;
• OracleDatabase - Oracle Database.
DBSrvr
Database server name.
DB
Name of database on the database server.
DBUID
Database server username.
DBPwd
The password of the database server user. If the database server user pass-
word is not specified, this parameter may be omitted.
SQLYOffs
Date offset, used for date storing in Microsoft SQL Server. Can take value 0
or 2000. This parameter is optional. If it is not specified, value 0 is used.
Locale
Language (country), similar to file-based type.
CrSQLDB
Create database if none present. Parameter value:
• Y - create database if none present.
• N - do not create database. Default value.
SchJobDn
Restrict scheduled jobs in the infobase created. Parameter value:
• Y - allow;
• N - restrict. Default value.
SUsr
Cluster administrator name, where the initial image will be created. This
parameter is mandatory if the administrators are defined in the cluster and
the operation system authentication is not defined or does not suit them;
SPwd
Password of the cluster administrator.
7.8. Webclient command
line
O=<connection speed>
Defines the connection speed:
• Normal - normal connection speed,
• Low - low connection speed
C=<text string>
Passes a parameter to the application.
N=<name>
User name. As in the user list in Designer.
P=<password>
Password for the user specified in N parameter. If the password is empty,
omit this option.
WA<mode>
The operating system authentication usage mode at 1C:Enterprise startup. If
/WA parameter is not specified, it is treated as /WA+ command line parame-
ter.
<mode> can take the following values:
• – - restrict operating system authentication at 1C:Enterprise startup.
• + - Require operating system authentication at 1C:Enterprise startup.
OIDA<mode>
Defines whether pass-through user authentication between various infobas-
es and/or external resources is used (thin and web clients only). If the
/OIDA option is missing during the client startup or the /OIDA+ option is
used, the authentication is attempted via the OpenID provider with the ad-
dress specified in the default.vrd file of the infobase publication.
If the OpenID provider requires interactive authentication (initial request is
performed or the authentication timeout expired), the client prompts to enter
the user name and password.
The user list of the OpenID provider infobase is used for authentication.
The name of the infobase user being authenticated using OpenID must
match the user name in the OpenID provider infobase.
<mode> can take the following values:
• + - use OpenID authentication (the default option).
• – - do not use OpenID authentication.
Authoff
Perform OpenID logout (close a user session). The user session is complet-
ed irrespective of the authentication method to be used subsequently.
L=<language code>
The language code for the platform interface.
VL=<session locale code>
The session locale code used for formatting Number and Date data, and
also used in NumberInWords() and PeriodPresentation()
methods.
DisableStartupMessages
Suppresses startup message Databasee configuration does not match
stored configuration. Continue?.
DisplayAllFunctions
Enables All functions main menu item
DisplayPerformance
Display the number of server calls and the volume of data sent to the server
and received from it.
Debug=[<mode>[,attach]]
Specifies the debug protocol (tcp or http) and an (attach) flag, which
shows that the debugger will automatically attach the debug items (both
client and server) of the started application to be registered on the debug
server. attach parameter is only used for debugging over HTTP.
If debug command is specified without parameter- TCP/IP debiggung pro-
tocol is used.
DebuggerURL=<debugger URL>
Specifies the debugger the application must connect to immediately after
startup. In case of debugging over TCP/IP the debugger URL (protocol,
computer and port) is specified. In case of debugging over HTTP the de-
bugging server URL is specified.
TestClient
Start web client in test client mode. TestClientID parameter must be
used to identify the specific web client instance.
TestClientID<ID>
Allows the test manager to access the web client by its ID when web client
is started in test client mode. If the ID is not specified or several clients are
started with the same value, the random ID is selected.
UsePrivilegedMode
Start the web client in privileged mode. Available to authenticated users
with administrator privileges. A record stating that the privileged session
mode is set or cannot be set is added to the event log.
Z=<Common attribute 1>,<Common attribute
2>,...,<Common attribute N>
Setting separators when starting the client application.
itdi
Ignored. The application will be started in Taxi interface mode.
isdi
Ignored. The application will be started in Taxi interface mode.

iTaxi
Run in the Taxi interface mode.
SYSTEMWEBCLIENTSTAT
Enables web client usage statistics collection functionality. This functionali-
ty is intended for 1C Company specialists.
OidcSelectedProvider
Allows to specify the configured OpenID Connect provider name to be used
for user authentication at web client startup.
MainWindowMode=startup mode>
It allows to expressly specify the startup mode for client application main
window. <startup mode>can accept one of the following values:
• -Normal - ordinary startup mode.
• -Workplace - workplace mode.
• -EmbeddedWorkplace - embedded workplace mode (for embed-
ding a web client in a third-party website).
• -FullscreenWorkplace - full screen workplace mode.
• -Kiosk - kiosk mode.

7.9. Mobile version

command line
1C:Enterprise mobile version supports specifying several commands and
parameters, which can be specified in the client applications startup com-
mand line for PC.
The supported commands (list) with specification of the sections containing
the client application command line parameters for PC are given below.
• /N, /P, /WSN, /WSP, /WSA, /OIDA, /Authoff,
/UsePrivilegedMode, /Z, /O
• /HttpsForceSSLv3, /HttpsForceTLS1_0
• /L, /VL
• /ClearCache, /C, /URL
• /DisableStartupMessages
Appendix 8.
Components and
resources used

The following components have been used in the software product:

• Dictionaries, used in full-text search, are based on the dictionary bases
and Russian, Ukrainian and English thesauri, provided by "Informat-
ic" company.
• Interface translated by:
 Bulgarian - "DAVID Holding Inc."
 Vietnamese - 1C Vietnam LLC (http://1c.com.vn)
 Georgian - Integrated Business Solutions LLC (IBS)
 Latvian- "ANDI M" LLC
 Lithuanian - "AVAKOMPAS" CJSC
 Kazakh - 1C Kazakhstan, "Infosoftprom" LLP, Kazakhstan
• zlib general purpose compression library
version 1.2.11, January 15, 2017
Copyright © 1995–2017 Jean-loup Gailly and Mark Adler
• Portions of this software are based in part on the work of the Inde-
pendent JPEG Group
• PNG reference library.
libpng version 1.6.34
Copyright © 1998–2017 Glenn Randers-Pehrson
Copyright © 1996–1997 Andreas Dilger
Copyright © 1995–1996 Guy Eric Schalnat, Group 42, Inc.
• TIFF Software Distribution.
Copyright © 1988–1997 Sam Leffler
Copyright © 1991–1997 Silicon Graphics, Inc.
• Various 1C products provide read/write capability and/or other LZW
capability covered by Unisys-owned U.S. patent 4,558,302. Licensing
information can be obtained by contacting Unisys at the following ad-
dress:
Unisys Corporation
Welch Licensing Dept. - MSC1SW19
Township Line and Union Meeting Roads
P.O. Box 500
Blue Bell, PA 19424-0001
Fax: (215) 986-3090
• PROJ 4 release 4.4
 Copyright © 2000, Frank Warmerdam
• The ZipArchive Library 4.6.1
Copyright © 2000 - 2014 Artpol Software - Tadeusz Dracz
• Dr. Gladman's AES library: (A Password Based File Encryption Ex-
ample with AES and HMAC-SHA1).
Copyright © 2002, Dr Brian Gladman, Worcester, UK. All rights re-
served.
• This product includes software developed by the OpenSSL Project for
use in the OpenSSL Toolkit (http://www.openssl.org/).
This product includes cryptographic software written by Eric Young
([email protected]). This product includes software written by Tim
Hudson ([email protected]).
• Portions of this software are copyright © 2017 The FreeType Project
(www.freetype.org). All rights reserved.
• ICU 4.6.
Copyright © 1995-2011 International Business Machines Corporation
and others.
• ImageMagick version 6.9.3-10.
Copyright © 1999–2016 ImageMagick Studio LLC.
• libgsf version 1.10.1.
Copyright © 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005
Free Software Foundation, Inc.
• STLport-5.1
Copyright © 1994 Hewlett-Packard Company
Copyright © 1996-1999 Silicon Graphics Computer Systems, Inc.
Copyright © 1997 Moscow Center for SPARC Technology
Copyright © 1999-2003 Boris Fomitchev.
• libxml2 2.9.10
Copyright © 1998-2012 Daniel Veillard. All Rights Reserved
• libxslt 1.1.34
License for libxslt except libexslt Copyright © 2001–2002 Daniel
Veillard. All rights reserved.
License for libexslt Copyright © 2001–2002 Thomas Broyer, Charlie
Bozeman and Daniel Veillard. All rights reserved.
• curl version 7.57.0 (29th of November 2017)
Copyright © 1996–2017, Daniel Stenberg, <[email protected]>.
• wxWidgets 3.0.1 Copyright (c) 1998-2014 Julian Smart, Robert
Roebling et al
• Google Closure Library
Copyright 2006 The Closure Library Authors. All rights reserved.
• Closure Stylesheets
Copyright 2008 Google Inc.
• Closure Compiler
 Copyright 2014 The Closure Compiler Authors.
• Google Closure Templates
Copyright 2009 Google Inc.
• SQLite database engine
Copyright © 2004–2013 D. Richard Hipp and team.
• Mimetic 0.9.7 Copyright (c) 2009 Stefano Barbato
The MIT License
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the «Soft-
ware»), to deal in the Software without restriction, including without
limitation the rights to use, copy, modify, merge, publish, distribute,
sublicense, and/or sell copies of the Software, and to permit persons to
whom the Software is furnished to do so, subject to the following
conditions: The above copyright notice and this permission notice
shall be included in all copies or substantial portions of the Software.
• libEtPan! - a mail library
Copyright (C) 2001, 2005 - DINH Viet Hoa
All rights reserved.
Copyright (C) 2007 g10 Code GmbH
All rights reserved.
Copyright (C) 2006 Andrej Kacian <[email protected]>
All rights reserved.
Copyright (c) 1983, 1990, 1993
The Regents of the University of California. All rights reserved.
• libxdiff 0.23 - file differential library
Copyright (C) 2003 Davide Libenzi <[email protected]>
• libssh 0.7.3
Copyright (c) 2003-2014 by Aris Adamantiadis, Andreas Schneider et
al
• WebSocket++ (https://www.zaphoyd.com/websocketpp)
Copyright (c) 2014, Peter Thorson
• Google Protocol Buffers
Copyright 2008 Google Inc.
• AOP Alliance
• Apache Commons IO 2.4
Copyright 2002-2012 The Apache Software Foundation
• Guava: Google Core Libraries for Java 16.0.1
Copyright (C) 2014 The Guava Authors
• Google Guice 3.0
Copyright 2006-2011 Google, Inc.
• ICU4J 2.6.1
Copyright (c) 1995-2012 International Business Machines Corpora-
tion and others
• JSR-330: Dependency Injection for Java
Copyright (C) 2009 The JSR-330 Expert Group
• Simple Logging Facade for Java (SLF4J) 1.7.7
Copyright (C) 2004-2013 QOS.ch
• PostgreSQL JDBC driver
Copyright (C) 1997-2011, PostgreSQL Global Development Group
• Microsoft JDBC Driver 6.2 for SQL Server
Copyright (C) Microsoft Corporation
• mstch 1.1.3
Copyright (c) 2015 Daniel Sipka
• NSIS 3.02.1
Copyright (C) 1999-2017 Nullsoft and Contributors
• diff-match-patch
Copyright 2018 The diff-match-patch Authors
• Gperftools-2.7
Copyright (c) 2005, Google Inc.
• libuuid
Copyright (C) 1996, 1997, 1998, 1999 Theodore Ts'o.
Appendix 9. New and modified
sections

Deleted section:
• .
Added section:
• Section 6.4.2. By default, when password is under attack.
• Section 6.9.2. Client/server mode of infobase.
• Section 8.10.1.6. Embedding Web Client.
• Section 8.10.2.3. Embedding Web Client.
• Appendix 4.4.4. Use recommendations.
• Appendix 4.5.4.12. Information for 1C:Remote Service.
Modified section:
• Section 1.1. Thin client.
• Section 1.2. Thick client.
• Section 1.3. Web client.
• Section 1.9.3. License types.
• Section 1.9.4. CORP license applicability.
• Section 6.2.8.5. OpenID Connect authentication.
• Section 6.2.8.7. Use of biometrics to log in through a mobile client.
• Section 6.3. Active users list.
• Section 6.6. Infobase parameters.
• Section 6.16.3.2. Viewing event log.
• Section 6.16.11. Database copy management.
• Section 8.3.1. General publication procedure.
• Section 8.3.2.1. Dialog buttons.
• Section 8.3.2.2.1. General parameters.
• Section 3.3. *.v8i.
• Appendix 4.5.4. Module commands (all subsections).
• Appendix 7.3.3. Specifying run mode.
• Appendix 7.4.5. Checking configurations and extensions.
• Appendix 7.8. Webclient command line.