вторник, 9 февраля 2021 г.

Kaspersky Security Center - наследование политик.

1. 

1.1. Если политика не унаследована, но замок открыт - применяются те настройки, которые были применены к устройству до назначения политики. Чаще всего это настройки заданные инсталлятором, локально до применения политики или те настройки, которые остались от предыдущей политики. С открытым замком новая политика не переопределяет уже установленных на хосте значений.

1.2) Если политика унаследована, но замок открыт - будут применятся настройки родительской политики. Настройки заданные инсталлятором или локально будут переопределены. Это верно для KES до версии 11.4 включительно. В KES 11.5 появилась функция "Разрешить локальные исключения" - если такая галочка стоит, то настройки исключений заданные локально объединяются с настройками заданными политикой.

1.3) Если замок закрыт, не имеет значения, унаследована политика или нет. Применяются значения, заданные в политике подгруппы. Значения, заданные родительской политикой, переопределяются. Функция KES 11.5 "Разрешить локальные исключения" работает так же.

2.

Если речь идет о настройках исключений, то нужно исходить из того, какая версия KES установлена на клиентском устройстве.
- Для KES 11.4 и более старых достаточно оставить настройки как у Вас. отключить наследование, оставить замок открытым и редактировать список исключений локально.
- Для KES 11.5 можно закрыть замок и разрешить использование локальных исключений. (Функционал был добавлен именно с этой целью - определять централизовано фиксированный список исключений, но оставить пользователю возможность вносить свои исключения)

суббота, 20 июня 2020 г.

Установка и настройка L2TP VPN-сервера на Ubuntu Server

Настраиваем VPN сервер посредством l2tp + ipsec.
Внутри контейнера в качестве ipsec демона будем использовать openswan, а в качестве l2tp сервера стандартный xl2tpd из репозиториев:
apt-get install xl2tpd
В репозиториях нет openswan, ставим из исходников.
Для начала придется установить дополнительные библиотеки, необходимые для сборки:
apt-get install libgmp3-dev gawk flex bison make
Далее, качаем с офф-сайта openswan:
wget https://download.openswan.org/openswan/openswan-latest.tar.gz
tar -xvzf openswan-latest.tar.gz
Собираем и устанавливаем (директория может быть более свежей версии):
cd openswan-2.6.51 
make programs
make install
Приступим к настройке ipsec демона.
Приведем конфиг /etc/ipsec.conf к виду:
config setup
   nat_traversal=yes
   virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
   oe=off
   protostack=netkey

conn L2TP-PSK-NAT
   rightsubnet=vhost:%priv
   also=L2TP-PSK-noNAT

conn L2TP-PSK-noNAT
   authby=secret
   pfs=no
   auto=add
   keyingtries=3
   rekey=no
   ikelifetime=8h
   keylife=1h
   type=transport
   left=SERVER.IP
   leftprotoport=17/1701
   right=%any
   rightprotoport=17/%any
Наиболее важные моменты конфига прокомментированы. Также следует не забыть составить конфиг именно таким образом, как указано выше, то есть с сохранением пробелов в начале строки у тех команд, у которых они указаны, так как отступ команды демоном привязывается к блоку, определяемому безотступным «conn».
Теперь зададим авторизацию для работы с ipsec. Существует два метода авторизации — по сертификату и по ключу ( PSK ). В данном примере мы настроим авторизацию по ключу в файле /etc/ipsec.secrets:
11.11.11.11 %any: PSK "mykey"
11.11.11.11 — это внешний IP адрес нашего сервера (или %any)
%any — это встроенная переменная обозначающая любой IP адрес
PSK — метод авторизации ( может быть RSA )
«mykey» — секретный ключ для авторизации, который потребуется передать клиенту.

Скрипт для настройки сети

В /root/ipsec
Добавляем содержимое:
iptables --table nat --append POSTROUTING --jump MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
for each in /proc/sys/net/ipv4/conf/*
do
echo 0 > $each/accept_redirects
echo 0 > $each/send_redirects
done
/etc/init.d/ipsec restart
Делаем скрипт исполняемым
chmod +x /root/ipsec
Добавляем в rc.local и запускаем
sh /root/ipsec
Теперь пришло время настроить l2tp сервер. Он будет работать через протокол ppp.
Приводим конфиг /etc/xl2tpd/xl2tpd.conf к виду:
[global]
port = 1701
ipsec saref = yes
saref refinfo = 30

[lns default]
ip range = 10.1.2.2-10.1.2.255
local ip = 10.1.2.1
refuse chap = yes
refuse pap = yes
require authentication = yes
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
name = vpnserver
Далее настраиваем конфиг ppp, который запрашивается нашим l2tp демоном ( /etc/ppp/options.xl2tpd ):
require-mschap-v2
ms-dns 8.8.8.8
ms-dns 8.8.4.4
asyncmap 0
auth
crtscts
lock
hide-password
modem
#debug
name vpnserver
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4
В случае возникновения проблем со связью или с подключением для дебага работы l2tp просто раскомментируем «#debug» и смотрим в системный лог /var/log/syslog на наличие ошибок.
Настраиваем авторизацию в ppp ( /etc/ppp/chap-secrets ):
user vpnserver password *
Рестартуем все сервисы
/etc/init.d/ipsec restart
/etc/init.d/xl2tpd restart
Проверяем работу
ipsec verify
Checking if IPsec got installed and started correctly:

Version check and ipsec on-path                         [OK]
Openswan U2.6.50/K4.9.0-3-amd64 (netkey)
See `ipsec --copyright' for copyright information.
Checking for IPsec support in kernel                    [OK]
 NETKEY: Testing XFRM related proc values
         ICMP default/send_redirects                    [OK]
         ICMP default/accept_redirects                  [OK]
         XFRM larval drop                               [OK]
Hardware random device check                            [N/A]
Two or more interfaces found, checking IP forwarding    [OK]
Checking rp_filter                                      [OK]
Checking that pluto is running                          [OK]
 Pluto listening for IKE on udp 500                     [OK]
 Pluto listening for IKE on tcp 500                     [NOT IMPLEMENTED]
 Pluto listening for IKE/NAT-T on udp 4500              [OK]
 Pluto listening for IKE/NAT-T on tcp 4500              [NOT IMPLEMENTED]
 Pluto listening for IKE on tcp 10000 (cisco)           [NOT IMPLEMENTED]
Checking NAT and MASQUERADEing                          [TEST INCOMPLETE]
Checking 'ip' command                                   [OK]
Checking 'iptables' command                             [OK]

воскресенье, 26 апреля 2020 г.

Application Default Credentials (ADC)

Установка ADC позволяет приложениям, работающим с GCP ресурсами и использующим Google API библиотеки, управлять ресурсами GCP через авторизованные API вызовы, используя credentials вашего пользователя. 

Создайте  АDC: $ gcloud auth application-default login

В конце всех действий вы должны получить:
Credentials saved to file: [/home/user/.config/gcloud/application_default_credentials.json]

среда, 22 апреля 2020 г.

Создание образа диска с помощью Packer на примере Google Cloud.

Создаем файл с расширением .json.

Например, ubuntu16.json:

{
    "builders": [ #основные параметры
        {
            "type": "googlecompute",
            "project_id": "infra-5314134",
            "image_name": "reddit-base-{{timestamp}}",
            "image_family": "reddit-base",
            "source_image_family": "ubuntu-1604-lts",
            "zone": "europe-west1-b",
            "ssh_username": "pawwwel",
            "machine_type": "f1-micro"
        }
    ],
    "provisioners": [ #запуск дополнительных скриптов
        {
            "type": "shell",
            "script": "scripts/install_ruby.sh",
            "execute_command": "echo '1' | sudo -S {{.Path}}"
        },
        {
            "type": "shell",
            "script": "scripts/install_mongodb.sh",
            "execute_command": "echo '1' | sudo -S {{.Path}}"
        }
    ]
}

Можно проверить правильность синтаксиса командой:

 packer validate ubuntu16.json

Запустить:

 packer build ubuntu16.json


Если хотим добавить изменяемые параметры:

1. нужно изменить файл

{
    "variables": { #добавить параметры
"project_id": null,
"zone": "europe-wes1-b",
"machine_type": "f1-micro",
"source_image": "null"
},

    "builders": [
        {
            "type": "googlecompute",
            "project_id": "{{ user `project_id` }}",
            "image_name": "reddit-base-{{timestamp}}",
            "image_family": "reddit-base",
            "source_image_family": "{{ user `source_image` }}",
            "zone": "{{ user `zone` }}",
            "ssh_username": "pawwwel",
            "machine_type": "{{ user `machine_type` }}"
        }
    ],
    "provisioners": [
        {
            "type": "shell",
            "script": "scripts/install_ruby.sh",
            "execute_command": "echo '1' | sudo -S {{.Path}}"
        },
        {
            "type": "shell",
            "script": "scripts/install_mongodb.sh",
            "execute_command": "echo '1' | sudo -S {{.Path}}"
        }
    ]
}

2. файл параметров

var.json


"project_id": "infra-5314134",
"source_image": "ubuntu-1604-lts"
}

3. запустить команду на выполнение:

packer build -var-file var.json ubuntu16json

Запустить из консоли создание виртуальной машины:

gcloud compute instances create vm001 --zone=europe-west1-b --machine-type=f1-micro --image=reddit-base-1587491511

суббота, 18 апреля 2020 г.

Install and configure Pritunl

Создаем VPN-сервер Pritunl на базе Linux.

На сайте указана следующая последовательность команд для Ubuntu:

sudo tee /etc/apt/sources.list.d/mongodb-org-4.2.list << EOF deb https://repo.mongodb.org/apt/ubuntu bionic/mongodb-org/4.2 multiverse EOF sudo tee /etc/apt/sources.list.d/pritunl.list << EOF deb http://repo.pritunl.com/stable/apt bionic main EOF sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com --recv E162F504A20CDF15827F718D4B7C549A058F8B6B sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com --recv 7568D9BB55FF9E5287D586017AE645C0CF8E292A sudo apt-get update sudo apt-get --assume-yes install pritunl mongodb-server sudo systemctl start pritunl mongodb sudo systemctl enable pritunl mongodb

Но возникает ошибка
gpg: keyserver receive failed: Server indicated a failure
после ввода команды 
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com --recv E162F504A20CDF15827F718D4B7C549A058F8B6B sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com --recv 7568D9BB55FF9E5287D586017AE645C0CF8E292A


Решается следующим образом:

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv E162F504A20CDF15827F718D4B7C549A058F8B6B sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 7568D9BB55FF9E5287D586017AE645C0CF8E292A

среда, 8 апреля 2020 г.

Linux netplan

Все конфигурационные файлы Netplan находятся в папке /etc/netplan/. Внутри папки находятся файлы с расширением  yaml.

Редактирование файлов:
1. все интерфейсы можно прописывать в одном файле.
2. нельзя использовать табуляцию, а только пробелы
3. параметры прописывать строго по иерархии

Пример:

network:
  version: 2
  renderer: networkd
  ethernets:
   enp3s0:
    dhcp4: yes
   enp8s0:
    dhcp4: no
    addresses: [ 192.168.1.10/24 ]
    gateway4: 192.168.1.1
    nameservers:
    addresses: [ 8.8.8.8, 8.8.4.4 ]

среда, 17 апреля 2019 г.

Создание выделенного сервера лицензирования 1С

Документ без названия

Постановка задачи

В качестве примера рассмотрим следующую исходную ситуацию: у нас есть кластер «1С» , состоящий из одного рабочего сервера SRV1, на версии платформы 8.3.8.2088 (-regport 2041 -port 2040 -range 2060:2091). Все сервисы исполняются на нём, на нем же активирована серверная и многопользовательская программная лицензия.
А также есть еще один кластер, состоящий из одного рабочего сервера SRV2, на версии платформы 8.3.9.1850 (-regport 3041 -port 3040 -range 3060:3091). На нём также исполняются все сервисы, и также активирована серверная и многопользовательская программная лицензия.
Описание параметров портов (report, port, range) приведено здесь.
Требуется вынести сервисы лицензирования с обоих серверов на отдельный сервер лицензирования SrvLic, то есть активировать две серверные и две многопользовательские лицензии на этом сервере и обеспечить их выдачу в оба кластера «1С».

Порядок действий

Все действия для настройки выделенного сервера лицензирования лучше разбить на два этапа:
  • подготовительный — подготовка сервера лицензирования: разворачивание служб «1С» , добавление его в список рабочих серверов в каждом кластере «1С» , проверка активности (доступности для использования);
  • заключительный — активация лицензий на выделенном сервере лицензирования и применение настроек по переносу на него сервиса лицензирования каждого из кластеров «1С».
Такой подход позволит минимизировать общее время простоя системы и устранить возможные проблемы вне этого периода.

Подготовительный этап

Для подготовительного этапа последовательность действий для настройки сервиса лицензирования на выделенном сервере SRVLic будет следующей:
  1. На сервере SRVLic устанавливаем компоненты сервера «1С:Предприятия» 8.3.8.2088 и 8.3.9.1850 (более подробная информация по установке сервера доступна в документации здесь).
Мы рекомендуем при установке «1С:Предприятие» снять опцию «Установить сервер „1С:Предприятие 8“ как сервис Windows». Это позволит выполнять установку и удаление версий платформы без необходимости остановки служб на сервере.
  1. Развертывание служб «1С» на сервере SrvLic осуществляем с помощью скриптов. Подробное рассмотрение вопросов развертывания разных служб на одном сервере рассматривается в статье «Как правильно обновить платформу „1С“ и запустить несколько служб „1С“ на одном сервере?» по ссылке.
Здесь мы ограничимся готовыми скриптами для нашего примера.
Служба «1C» для сервера Srv1:
sc create "1C:Enterprise SrvLic1" binpath= "\"C:\Program Files\1cv8\8.3.8.2088\bin\ragent.exe\" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d \"C:\Program Files\1cv8\srvinfo_srvlic1\"" displayname= "Агент сервера 1C:Предприятие SrvLic1" obj= "domain\USR1CV8" password= "password" start= disabled depend= Dnscache/Tcpip/lanmanworkstation/lanmanserver
, где
  • domain\USR1CV8 — пользователь от имени которого осуществляется запуск службы (в качестве пользователя желательно использовать доменную учетную запись, обладающую правом запуска служб и полными правами к каталогу указанному в параметре «-d»).
  • password — пароль пользователя, указанного в параметре «obj».
Служба «1C» для сервера Srv2:
sc create "1C:Enterprise SrvLic2" binpath= "\"C:\Program Files\1cv8\8.3.9.1850\bin\ragent.exe\" -srvc -agent -regport 1641 -port 1640 -range 1660:1691 -d \"C:\Program Files\1cv8\srvinfo_srvlic2\"" displayname= "Агент сервера 1C:Предприятие SrvLic2" obj= "domain\USR1CV8" password= "password" start= disabled depend= Dnscache/Tcpip/lanmanworkstation/lanmanserver
Необходимо обратить внимание, что для каждой вновь создаваемой службы должны быть заданы различные каталоги в параметре «–d».
Обратите внимание, что при выборе портов для запуска службы следует учитывать их доступность (это порты не должны быть заняты другими службами или приложениями). Для первой службы мы выбрали диапазон 1560:1591, для второй — 1660:1691. Кроме того, данные порты нужно добавить в разрешенные порты межсетевых экранов.
  1. На сервере SRVLic создаем каталоги служб «1С» и даем на них полные права пользователю «domain\USR1CV8»:
C:\Program Files\1cv8\srvinfo_srvlic1
C:\Program Files\1cv8\srvinfo_srvlic2
  1. Включаем и запускаем службы.
 


После запуска служб убеждаемся, что они работают, через команду консоли служб «Действия → Обновить»
  1. Удаляем автоматически созданные локальные кластеры «1С» через консоль администрирования серверов «1С» :Предприятие. Для этого регистрируем и запускаем консоль версии 8.3.8.2088:

"C:\Program Files (x86)\1cv8\8.3.8.2088\bin\RegMSC.cmd"
(запуск от имени Администратора)


"C:\Program Files (x86)\1cv8\common\1CV8 Servers.msc"  

Регистрируем и запускаем консоль для версии 8.3.9.1850:
"C:\Program Files (x86)\1cv8\8.3.9.1850\bin\RegMSC.cmd"
(от имени Администратора)
"C:\Program Files (x86)\1cv8\common\1CV8 Servers.msc"

НО. Есть еще нюанс. Если у вас второй экземпляр сервера другого релиза (например первый 8.3.8.2088, а второй 8.3.9.1850), то у вас возникнут определенные трудности связанные с запуском консоли сервера (см. описание в конце статьи).
И также удаляем «Локальный кластер»:

  1. Для функционирования системы программного лицензирования необходимо, чтобы на компьютере SrvLic была запущена служба WMI (Windows Management Instrumentation, http://msdn.microsoft.com/en-us/library/aa394582.aspx). Нужно проверить, что данная служба запущена, если нет — запустить ее (в документации данное требование описано здесь).
  2. Возвращаемся на сервер SRV1, в консоли администрирования серверов «1С:Предприятие» которого создаем (добавляем) новый рабочий сервер:

  1. Указываем для него имя, например, «Сервер лицензирования», сетевое имя сервера — SRVLic, порт, на котором работает служба «1С» версии 8.3.8.2088, у нас был задан порт 1540, и диапазон портов, который будет использоваться для процессов этой службы, для этой версии был задан — 1560:1591. Остальные параметры оставляем без изменений (большинство из них использоваться не будут).

Здесь нужно обратить внимание, что при добавлении нового рабочего сервера поле «Порт главного менеджера кластера» не доступен для редактирования.
Так как кластер сервера Srv1 развернут на 2041 порту…

… то в настройках добавленного рабочего сервера SrvLic нужно изменить порт главного менеджера кластера с 1541 на 2041 (если кластер был расположен на стандарном порту ничего изменять не надо, оба сервера в кластере смогу работать на одинаковом порту 1541). Для этого нужно повторно открыть свойства рабочего сервера SrvLic

  1. Теперь наш кластер должен содержать новый рабочий сервер:

Для того, чтобы сервисы не начали перераспределяться на только что добавленный сервер SrvLic, нужно сразу создать правило требований назначения функциональности, запрещающее абсолютно всё:



И применить требование назначения функциональности:

  1. Выполняем действия с 7 по 9 пункт для сервера Srv2. Напомним, что порт агента «1С» для добавленного сервера лицензирования SrvLic, на котором работает служба «1С» версии 8.3.9.1850 у нас был задан 1640, а диапазон портов — 1660:1691, порт главного менеджера кластера нужно установить в соответствии с принципами, изложенными в 7 пункте.
  2. Выполним настройку требований назначения функциональности для переноса сервиса лицензирования в добавленный сервер SrvLic. Откроем консоль администрирования серверов для сервера Srv1. В ветке «Рабочие серверы» переходим (раскрываем) добавленный сервер SRVLic, далее у него переходим (раскрываем) ветку «Требования назначения функциональности». Настраиваем требования назначения функциональности на добавленном рабочем сервере SRVLic следующим образом:
    • Требование 1:
      • Объект требования: Сервис лицензирования.
      • Тип требования: Назначать.
      • Имя ИБ: не указывается (оставить поле пустым)
      • Значение дополнительного параметра: не указывается (оставить поле пустым).
    • Требование 2:
      • Объект требования: Любой объект требования.
      • Тип требования: Не назначать.
      • Имя ИБ: не указывается (оставить поле пустым).
      • Значение дополнительного параметра: не указывается (оставить поле пустым).
Теперь требования назначения функциональности в консоли администрирования серверов «1С:Предприятие» должны выглядеть так, как на следующем рисунке и именно в таком порядке:
Поясним немного выполненные действия. Требование 1 обеспечит функционирование сервиса лицензирования на сервере SRVLic, а Требование 2 обеспечит функционирование на сервере SRVLic только сервиса лицензирования. То есть на сервере SRVLic не будут функционировать другие сервисы кластера и на него не будут назначаться клиентские соединения.
Необходимо обратить внимание на порядок расположения требований. Сначала должно располагаться более узкое по объектам требование. Для того, чтобы не настраивать для каждого из остальных сервисов правила требований назначения функциональности «Не назначать» — делается одно общее правило «Не назначать»/«Для всех». В область «Для всех» входят и клиентские соединения, и все прочие сервисы кластера, так же, как и «Сервис лицензирования», но так как для этого объекта требования у нас уже есть расположенное выше правило, то все последующие правила кластер применять к нему уже не будет. Более подробная информация об особенностях функционирования требований назначения функциональности приведена в документации здесь.
12. В блоке рабочего сервера кластера SRV1 также добавляем две функциональности в требования назначения функциональности.

Функциональности должны быть именно в указанной последовательности.
Добавляем сначала:
Сервис лицензирования - Не назначать


Затем:
Клиентское соединение с ИБ - Назначать


Этим мы говорим, что этот сервер готов отвечать на клиентские вызовы, но лицензии он не содержит.
И применить требование назначения функциональности:

13. Перезагружаем службу 1С.
14. Выполняем эти же действия по настройке требований назначения функциональности для сервера Srv2.
15. Как активировать лицензию в случае сервера лицензирования?
Для этого на клиенте в любой базе (хоть локальной) зайти в конфигуратор, перейти на интерфейс ввода лицензии, нажать Дополнительно и ввести адрес сервера лицензирования.
16. Активация ключа на сервере:



В этом случае активация произойдет на сервере лицензирования.
После можно проверить, появился ли файл лицензии в папке на сервере (рекомендуется записать, что за файл - эта информация может понадобиться при восстановлении лицензии - см. статью Восстановление по пин-коду).

Несколько версий сервера 1С на одном компьютере


По умолчанию, вы всегда запускаете консоль C:\Program Files\1cv8\common\1CV8 Servers (x86-64).msc, которая в свою очередь работает с определенной версией файла radmin.dll. Т.е. консоль для работы с платформой 8.3.8.2088 должна работать с файлом C:\Program Files\1cv8\ 8.3.8.2088\bin\radmin.dll, а для работы с 8.3.9.1850 - C:\Program Files\1cv8\8.3.9.1850\bin\radmin.dll. Есть рекомендации, что перед запуском консоли для работы с определенной версией сервера – необходимо каждый раз регистрировать нужную версию radmin.dll при помощи regsvr32. Однако мне этот вариант не помог (и судя по вопросам на форумах не мне одному). И я нашел один рабочий способ.
В папке C:\Program Files\1cv8\common создаете два файла 8.3.8.2088.reg и 8.3.9.1850.reg с соответствующим содержим:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{A42674D4-2D97-4988-A81D-2C113CC42A95}\InprocServer32]
@="C:\\Program Files\\1cv8\\8.3.8.2088\\bin\\radmin.dll"
"ThreadingModel"="Both"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{803144C8-17E6-4926-86C5-C195B6D226D4}\InprocServer32]
@="C:\\Program Files\\1cv8\\8.3.8.2088\\bin\\radmin.dll"
"ThreadingModel"="Both"
И
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{A42674D4-2D97-4988-A81D-2C113CC42A95}\InprocServer32]
@="C:\\Program Files\\1cv8\\8.3.9.1850\\bin\\radmin.dll"
"ThreadingModel"="Both"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{803144C8-17E6-4926-86C5-C195B6D226D4}\InprocServer32]
@="C:\\Program Files\\1cv8\\8.3.9.1850\\bin\\radmin.dll"
"ThreadingModel"="Both"

Также вы создаете два bat файла Console8382088.bat и Console8391850.bat с соответствующим содержимым:
regedit /s "C:\Program Files\1cv8\common\8.3.8.2088.reg"
mmc /s "C:\Program Files\1cv8\common\1CV8 Servers (x86-64).msc"
и
regedit /s "C:\Program Files\1cv8\common\8.3.9.1850.reg"
mmc /s "C:\Program Files\1cv8\common\1CV8 Servers (x86-64).msc"
И теперь для запуска консоли используете нужный вам bat файл Console83******.bat.