1с центральный сервер не аутентифицирован выполнение операции на рабочем сервере невозможно

Обновлено: 03.07.2024

Доброго времени суток друзья, столкнулся с проблемой, не могу разобраться с ее решением. Обо всем по порядку.
Не так давно, мы начали переход на 1С БП 3.0 и все что на ней основано, по сравнению с 2.0 тормозить она стала раз в 5 больше, базы открывались от 2 до 5 минут! Решение пришло быстро, MS SQL Server.
Так как для меня это первый опыт его настройки, начал я тренироваться в виртуальной машине Hyper-V, все работало более менее, пока я не загрузил туда БД сельхоз отдела, примерно через 2 - 3 часа работы сервер перестает работать, базы не подключается, даже напрямую на этом же сервере. В локальной сети выходит ошибка "1541 descr = сервер не доступен (не отвечает, завершается аварийно или порт занят другим приложением". Сначала я грешил на сетевую карту, потом на брандмауер (его отключение тоже не помогло), и вот вчера я взял физический сервер, все настроил установил, перенес базы и буквально час назад та же беда! Все драйвера обновлены, мощности сервера должно хватать (Xeon X5606 2.13 Ghz/24Gb RAM DDR3 1333/LAN 1Gb) у сети топология "Звезда". Последнее на что грешу то что сервер не включен в домен Active Directory, но тогда почему и на самом сервере база отваливается?
Кратко о ПО:
1С Предприятие 8.3.8.2088
MS SQL Server 2014 SP1
Windows Server 2008R2
Буду рад любому совету.

Дополнено:
Аналогичная проблема проявляется на Debian. С одной базой УТ10 работает нормально. При переносе старой БД (бухгалтерия) с файлового варианта на SQL (postgres) периодически раз в 1-2 недели базы становятся недоступными до перезапуска службы srv1cv83. Есть ощущение что чем больше баз переносится тем меньше срок работы до перезапуска, так при переносе 5 БД срок работы был 2-3 дня.
К одной базе УТ10 доступ осуществляется локально (на одной машине), при добавлении других баз работа с ними начинается через клиентов по сети, но в момент сбоя базы недоступны ни в каком виде до перезапуска службы srv1cv83.
В технологическом журнале из подозрительного можно выделить только следующее:

Доброго времени суток, есть 2 сервера, на них установлены сервера 1С, на главном сервере развернут центральный сервер, на втором вторичный, в главном добавлен другой как рабочий сервер. Распределил между ними менеджеры кластера, а вот создать рабочие процессы могу только на центральном сервере. При попытке сделать это на вторичном пишет "Ошибка добавления рабочего процесса: Центральный сервер не аутентифицирован. Выполнение операции на рабочем сервере невозможно."
Рабочий сервер особо не настраивался, потому как без понятия что там делать. что я делаю не так?
Пошагового мануала в нете не нашел. может тут добрые люди помогут?

администратор сервера установлен одинаковый на обоих серверах?

вроде они вообще не указаны. щас попробую прописать

Нужно процессы вторичного создавать из консоли первичного.. угу?

Поехали тролить?И всего-то через 15 минут. хмм. я сюда за помощью обратился, а не троллингом)
(4) Пользователей 100шт

(1) Спасибо за наводку) Помогло, осталось только проверить, что бы все работало как надо

Так, создать создал, но теперь не могу ничего сделать с инф базой. пишет "изменение ифн базы возможно только в активном кластере". не то опять сделал)Есть еще добрые знающие люди?

(9) Что бы в кластер запихнуть, распределение вычислений-всё такое.
Если фигню скажу, Вы, поправьте меня..не силен в этих вопросах

кстате, если сделать 2 сервера 1с к одной базе, то можно 2 раза в конфигуратор зайти одновременно..

2(11) ы. Если второй будет в кластере и будет только выполнять указанные сервисы, то нельзя будет.

(11) Это несомненно круто, но как нагрузку раскидать на 2 сервера?Это основной вопрос..

не ну хрен знает, конечно, вам видней, но по-моему на кластер то как раз нагрузка никакая по сравнению с sql сервером..

это к тому, что зачем делить нагрузку, если она и так никакая..

(15) хммм, хреновый из меня объяснятель. начну с начала. Есть 2 машины, на обоих стоят сервера 1с.
1й сервер (главный) "немного" не справляется с нагрузкой, появился второй, такой же по конфигурации, следовательно поступило предложение сделать из двух машин кластер баальшооой-пребаальшооой, что бы работало все быстрее чем обычно.
в главном кластере добавил второй сервер как "Рабочий сервер", в нем добавил "менеджер кластера", раскидал менеджеры по сервакам, создал у обоих сервов рабочие процессы. Теперь пытаюсь запустить базу (до этого стояли запреты на подключения и регл. задания), а она пишет "изменение ифн базы возможно только в активном кластере".
И Рабочие процессы активны и используются только у главного сервера, у вторичного они помечены как неактивные. надеюсь сейчас понятнее станет

(16) sql сервер как раз достаточно сильный, в большинстве своем курит бамбук, а вот сервак 1с "стоит раком"

(22) так моя логика мышлений шла в правильном направлении?
Я не могу понять, почему она не дает мне изменить инф базу?

то есть ты просто в консольке пытаешься снять галку блокировки соединения с базой - верно? и у тебя не выходит

(24) да, зато попробовал снять ее на втором сервере и она снялась. какая сейчас картина, 2 сервера, у обоих задано по 2 рабочих сервера, указаны соответственно они друг у друга как вторичные, каждый видит и использует только свои рабочие процессы, а процессы другого сервера у него неактивны. где то я накосячил, причем в корне накосячил

гы. так чтобы они друг у друга были вторичные - это нонсенс имхо.. :)

(26) Щас попробую проверить, запустить что-нить весомое и поудалять на основном рабочие процессы, посмотрю перекинется ли на вторичный. или как еще проверить можно?

удалить рабочие процессы не даст, если у них есть конекты.
И не перекинется, потому что на втором сервере какие у тебя свервисы? разве все? может только некоторые типа фоновых заданий или нумерации объектов?

(28) произошло чудо, законнектился на одном серве, а соединения в процессах появились на обоих машинах

Неделю назад была установлена платформа 8.3.9.2170 вместо 8.3.5.1482. Неделю проблем не было.

2 дня назад на одной из баз возникла указанная ошибка. При чем больше ни каких подробностей (нет ни кодов ошибок ни дополнительной информации).

Гугл посоветовал перезапустить процесс сервера 1С. Но в кластере еще порядка 5 рабочих баз. Поэтому этот вариант рассматривался как крайний. Удалось устранить переподключением базы в консоли кластера.

Вчера еще 4 базы (2 копии, 2 рабочих). Восстановить одну из баз выше указанным путем не удалось.
Посмотрел кэш ИБ - пустой. Т.е. даже служебные папки не создались в т.ч. файл журнала регистрации.

Собственно вопрос - в чем может быть проблема? Чем лечить?

А вообще может можно настроить как-то технологический журнал чтобы какие-то плохие события отлавливать?

(9) судя по ошибке это просто что-то отвалилось. Скорее смотреть нужно логи винды! Сейчас утром тоже самое словил. 8.3.6.2332. Вчера сделал рядовое изменение конфигурации.
Буду ждать админа. Как вариант. Перезапуск RPhost каждые 8 часов. И базу Выгрузить dt и загрузить.

Дополнение.
Базы продолжали падать. Для некоторых, способ переподключения в консоли, перестал работать. Ошибка повторялась.

На выходных для лечения было принято следующее:
1. Остановка кластера.
2. Чистка кэша ИБ. Всех. Журналы регистрации соответственно тоже были убиты(файловые, не SQLite). Точнее, копии оставил на всякий случай.

Больше проблем не возникало.

(6)
Доброе время суток!
Клиент-сервер, 8.3.10.2580, на одном сервере физическом.
Ту же проблему наблюдаем: иногда при запуске (и Предприятия, и Конфигуратора), иногда во время работы пользователей выходит та же ошибка, что и на скриншоте выше. Кто-нибудь решил проблему? перенастроен сервер 1с: увеличено с 1 до 4 количество инф. баз на рабочий процесс, снижено количество подключений на рабочий процесс с 250 до 50; Два месяца как проблема не повторялась.
В чем была причина и повторится ли вновь - не понятно.

Столкнулись с похожей проблемой.
Просто не создавался новый процесс для подключения к базе. Баз очень много.

В консоли настройках рабочего сервера стоит обычно диапазон IP портов 1560:1570
Если же баз больше 10-и и все используются и на каждую создается отдельный процесс,
то диапазона может не хватить .
Тут либо диапазон увеличить, либо по несколько баз на процесс вешать.
Проблему решили расширением диапазона.

(17) а как расширить диапазон, не подскажите? в реестре?

(16) облазил консоль, нигде ничего похожего не нашёл.

Ошибка "Ошибка при выполнении операции с информационной базой server_addr=tcp. " -- winsock'овская. Сейчас она возникла при отвале компьютера от корпоративной сети. Время от времени у нас приходится переводить компьютеры в группу, а потом возвращать в домен. В данном случае возврат в домен вызвал ошибку: "Не удалось подключиться к контроллеру домена Active Directory для домена ___"
А в группе база стала доступна, хотя лежит на сервере (как приложение, так и БД).

Полностью моя ошибка выглядит так:

Ошибка при выполнении операции с информационной базой
server_addr=tcp://1C:1541 descr=207.148.248.143:1541:10060(0x0000274C): Попытка установить соединение была безуспешной.

(19)
"Но у меня другая причина: IP-адрес кластера не наш."
Столкнулся с похожей проблемой.
На севере 1С запускается и серверная и клиентская части 1С (база загружается).
При попытке подключиться с другого сервера получаем ошибку, но ip адрес совершенно другой.

Что было сделано, полностью переустановлен Агент сервера 1С (8.3.13). Заново установлены лицензии. Настроены правила фаервола.
Проверены файлы в C:\Program Files\1cv8\srvinfo

Как вычислить и вычистить этот непонятный ip .

Причина: после ночного обновления Windows и автоматической перезагрузки все службы запустились, но по-видимому не корректно. Помогла физическая перезагрузка сервера.

Инструкция по настройке рабочих серверов с Технологической Платформой 1С:Предприятие

Ниже приводится инструкция по настройке рабочих серверов с Технологической Платформой 1С:Предприятие.

Рекомендуется при настройке рабочего сервера пройти указанный ниже сheck-лист и продумать, нужна ли указанная ниже настройка в вашем конкретном случае.

Если такая настройка нужна, то выполнить её. Важно на каждом пункте сознательно принимать решение о том, как именно вы хотите настроить рабочий сервер.

1. Определить, сколько информационных баз будут использоваться в кластере для работы пользователей

Существует несколько вариантов развертывания:

  • в продуктивной среде и подготовительной зоне;
  • в тестовой зоне;
  • в зоне разработки.

Наибольшие требования с точки зрения доступности информационной системы будут в случае развертывания в продуктивной и подготовительной зонах.

В этих случаях желательно все нерабочие информационные базы вынести в отдельный кластер на отдельные серверы.

Возможно, возникнет желание сделать копию рабочей информационной базы и развернуть в том же кластере в продуктивной среде, например, для того, чтобы восстановить определенные данные за прошлые сутки. Стоит перебороть это желание и проследить, чтобы

  • к копии базы не было доступа у пользователей;
  • в копии базы были выключены регламентные задания;
  • копия базы не участвовала в обменах.

Для восстановления данных за предыдущие сутки не стоит использовать продукционный кластер, а получать необходимые данные с подготовительной зоны информационной системы.

Рекомендуется в продуктивной зоне настраивать кластер с минимальным числом необходимых баз, чтобы снизить возможное влияние тестовых баз на работу пользователей.

В тестовой зоне и зоне разработки ограничений по числу информационных баз в кластере условно нет.

2. Определить, сколько пользователей будет работать одновременно

Число одновременно работающих пользователей информационной базы является одним из основных параметров, определяющих нагрузку на информационную систему.

Этот параметр также необходим для корректного расчета конфигурации оборудования, который выполняется исходя из

  • Конфигурации системы;
  • Сценария работы пользователей;
  • Числа одновременно работающих пользователей;
  • Используемых версий программных продуктов.

3. Настроить профили пользователей ОС, от которых будут запускаться процессы кластера

Необходимо определиться, будут ли процессы кластера серверов работать от имени различных пользователей информационной системы.

Это может быть необходимо для того, чтобы код, который выполняется в rphost точно не мог обратиться к каким-либо определенным данным на рабочем сервере или выполнить операцию с административными правами.

Для этого нужно:

Для того, чтобы создать профили пользователей ОС достаточно один раз войти от их имени в ОС Windows.

4. Настроить логирование и дампы

Для этого необходимо настроить:

  • Технологический журнал
  • Сбор дампов процессов кластера средствами Платформы (указнием в logcfg.xml секции dump) либо Windows Error Reporting Services

Хорошей практикой будет настроить сбор WER для rmngr и ragent, но не указывать rphost.

5. Проверить настройки операционной системы

5.1. Настроить рабочий сервер

5.2. Настроить рабочий сервер

Необходимо настроить рабочий сервер в соответствии с инструкцией, которая позволяет избежать ошибки "An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full"

5.3. Убедиться, что брадмауэр операционной системы настроен таким образом, что не запрещает процессам кластера взаимодействовать корректно.

Информация по клиент-серверному варианту работы здесь;

Обратите внимание на используемые порты, которые указываются в параметрах центрального сервера,


в свойствах кластера серверов,


и рабочих серверов кластера.


Также необходимо открыть порт для указания сетевого порта для ras в случае использования. --port или -p указывает сетевой порт, по которому утилита администрирования будет взаимодействовать с сервером администрирования. Значение по умолчанию равно 1545.

5.4. Убедиться, что на рабочих серверах кластера одновременно не используется IPv4 и IPv6.


5.5. Убедиться, что схема управления питанием - "Высокая производительность".


5.6. Убедиться, что установлены компоненты Microsoft Data Access Components

Этот пункт нужен для настройки с СУБД MS SQL Server.

В противном случае будете получать ошибку вида: "Компоненты OLE DB провайдера не найдены".

6. Необходимо настроить сетевой стек для обеспечения возможности обработки большого числа подключений

Настройки, которые необходимо выполнить (в дополнение к настройке 5.2. Настроить рабочий сервер в соответствии с инструкцией):

  • Запустить regedit и в ветке HKLM\System\CurrentControlSet\Services\Tcpip\Parameters указать
    • MaxFreeTcbs= 100000
    • TcpTimedWaitDelay= 30
    • MaxUserPort= 65535
    • EnableDynamicBacklog= 1
    • MinimumDynamicBacklog= 20
    • MaximumDynamicBacklog= 20000
    • DynamicBacklogGrowthDelta= 10
    • Выполнить: netsh int ipv4 set dynamicport tcp start=10000 num=55536
    • Выполнить: netsh int ipv4 set dynamicport udp start=10000 num=55536

    7. Настроить кластер серверов

    7.1. Необходимо добавить рабочие серверы в кластер

    7.2. Настроить условия перезапуска

    Настроить условия перезапуска по превышению порога памяти.

    7.3. Настроить расположение каталога кластера

    Необходимо убедиться, что

    • на дисках достаточно места;
    • сеансовые данные расположены на быстрых дисках;


    7.4. Настроить число соединений и информационных баз на процесс

    Настройку необходимо выполнить с учетом конфигурации системы

    Постарайтесь выполнять настройку таким образом, чтобы она не приводила к запуску 100 процессов rphost, т.к. значительное число процессов rphost приводит к неэффективному использованию памяти процессами кластера.

    Не стоит просто так уменьшать параметр "Число соединений на процесс" или "Число информационных баз на процесс".

    Если у вас нет технического обоснования, почему именно так лучше, рекомендуем оставить значения по умолчанию


    7.5. Выполнить настройки для случая нескольких рабочих серверов в кластере.

    • Обязательно должно быть явно указано расположение:
      • сервиса журнала регистрации;
      • сервиса полнотекстового поиска данных;
      • сервиса работы с внешними источниками данных;
      • расположение клиентских и серверных лицензий и сервисов лицензирования;
      • расположение сеансовых данных.

      8. Первый запуск

      На этом этапе следует выполнить следующие шаги:

      • Запустить кластер серверов, создать информационную базу;
      • Зарегистрировать программные лицензии;
      • Убедиться, что пользователь может войти в информационную базу без ошибок.

      9. Отказоустойчивость

      В случае необходимости настройки отказоустойчивого кластера, выполните следующие шаги.

      9.1. Проверить лицензии.

      Убедитесь, что на рабочих серверах, которые должны выполнять роль Центральных серверов достаточно лицензий для работы всех пользователей в информационной системе при отсутствии одного из Центральных серверов в случае возможного (теоретически) отказа.

      9.2. Установить флаг "Центральный сервер".

      Установить флаг как на рисунке ниже.


      9.3. Установить флаг "Уровень отказоустойчивости"

      Установить параметр, пример на рисунке ниже.


      Подробную информацию про уровень отказоустойчивости вы можете прочитать в статье

      Обратите внимание, что не нужно просто так указывать максимально возможный уровень отказоустойчивости, т.к. это приведет к избыточным накладным расходам.

      9.4. Скорректировать строку соединения

      Необходимо скорректировать строку соединения с информационной базой.

      Имеется возможность указания списка резервирования с помощью строки соединения с информационной базой или в соответствующем поле свойств информационной базы.

      Список указывается в формате Server1, Server2:Port, Server3.

      10. Замечания

      10.1. Не настраивайте exec backup (или аналогичные утилиты) на директории кластера серверов

      Причина в том, что в этих директориях могут располагаться хранилища с сеансовыми данными, выполнять backup которых не нужно, а создание backp-а которых будет приводить к избыточным накладным расходам.

      10.2. Не настраивайте сжатие данных дисков с директорией кластера


      10.3. Не забывайте про периодическое выполнение дефрагментации дисков ОС Windows.

      10.4. Настроить защиту от вирусов.

      В случае расположения рабочих серверов кластера в зоне, к которой доступ строго ограничен, не имеет смысл настраивать антивирусные решения на рабочих серверах.

      Настройка антивирусных решений на таких серверах будет оказывать существенное влияние на производительность при практическом отсутствии выигрыша с точки зрения защиты.

      При этом, стоит обеспечить защиту антивирусными решениями те пользовательские компьютеры, с которых выполняется доступ к рабочим серверам кластера и сетевым директориям.


      В сегодняшней статье я расскажу об уязвимостях сервера 1С в корпоративной сети.

      Как показала практика, в инсталляциях с 1С все допускают одни и те же ошибки разной степени серьезности. Я не буду касаться очевидных вещей вроде установки обновлений, но пройдусь по специфике работы сервера приложений под Windows. Например, по возможности бесконтрольно манипулировать базами Microsoft SQL с помощью инструментов 1С.

      Исторически так сложилось, что редко когда системные администраторы и программисты 1С работают как одна команда. Чаще всего специалисты по 1С не вникают в тонкости системного администрирования, а сисадмины не стремятся постичь нюансы работы 1С.

      И получается инфраструктура с «детскими болячками», очевидными для специалиста по ИБ ― ниже привожу личный ТОП таких проблем.

      По умолчанию платформа 1С при установке создает специальную учетную запись с ограниченными правами, под которой работают службы сервера ― USR1CV8. Все идет хорошо, до тех пор пока не становятся нужны ресурсы сети: например, для автоматических выгрузок-загрузок. Учетная запись по умолчанию не имеет доступа на сетевые папки домена, поскольку является локальной.

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



      Заходим на сервер по RDP, видим такое окно и получаем нервный тик.

      Конечно, «захардкоженые» пароли и сетевые ресурсы с анонимным доступом на запись встречаются редко. В отличие от работы сервера 1С из-под обычной доменной учетной записи. Разумеется, с возможностью выполнить произвольный код «на сервере».

      Как известно любому 1С-нику, но не любому системному администратору, в обработках 1С есть два режима выполнения процедур: на сервере и на клиенте. Запущенная в «серверном» режиме процедура будет выполнена под учетной записью службы сервера приложений. Со всеми ее правами.

      Если сервер 1С работает с правами администратора домена, то потенциальный вредитель сможет сделать с доменом что угодно. Разумным выходом станет создание специальной учетной записи ― по мотивам USR1CV8, только уже в домене. В частности, ей стоит разрешить вход только на определенные серверы в оснастке «Пользователи и Компьютеры Active Directory».



      Настройка входа только на разрешенные серверы.

      Не лишним будет и разрешить вход на сервер только в качестве службы, отключив возможность локального (интерактивного) входа в систему. Сделать это можно через локальные политики безопасности непосредственно на сервере, либо с помощью доменных групповых политик.



      Назначение прав пользователя в локальной политике безопасности.

      Все то же самое касается и учетной записи сервера Microsoft SQL. Седых волос может прибавиться от вредных привычек:

      • запускать SQL с правами администратора компьютера или даже домена для удобного резервного копирования;
      • включать возможность запуска исполняемых команд через хранимую процедуру xp_cmdshell для переноса резервных копий на сетевые ресурсы через красивые планы обслуживания.

      Регулярно в практике встречается подключение баз данных к серверу 1С под пользователем «SA» (суперпользователь в SQL). Вообще, это не так страшно как звучит, ведь пароль от SA захэширован в файле 1CV8Reg.lst на сервере приложений. Хэш злоумышленник получить гипотетически может ― не забываем про права учетной записи сервера ― но расшифровка окажется долгой, особенно если использовать брутфорс.

      Но все же не лишним будет настроить аудит доступа к этому файлу с уведомлением ответственных лиц.

      Другое дело, когда программистам 1С «делегируют» обязанности DBA. Опять же, из личного опыта: сервер SQL был в зоне ответственности программистов, как и интеграция внешнего сайта с базами 1С. Итогом был пароль SA в скриптах сайта.

      Для собственного успокоения стоит поставить на SA сложный пароль или вовсе деактивировать эту учетную запись. На SQL тогда нужно включить доменную аутентификацию для управления и создать для 1С отдельное имя входа с правами на необходимые базы.

      Если вы не хотите оставить возможность создавать базы SQL через интерфейс 1С, то новому пользователю хватит общей роли public и db_owner непосредственно в базе 1С.

      Это можно проделать через Management Studio или простым скриптом T-SQL:

      Правам пользователей в 1С почему-то мало кто уделяет внимание. А ведь пользователь с правами «Административные функции» или «Администрирование» запросто выгрузит базу в .DT через конфигуратор и унесет домой ― это подарит не одно мгновение волнительного счастья вашему руководству. Поэтому стоит поймать на рюмочку чая 1С-ника и посидеть совместно над базой, чтобы узнать, какие пользователи имеют подобные права. А заодно ― чем грозит понижение их полномочий.



      Право выгрузить базу у роли Полные Права в типовой 1С: Бухгалтерии 2.0.

      Следующий важный момент ― запуск внешних обработок. Как мы помним, в 1С можно запускать код с правами учетной записи сервера. Хорошо, если она не имеет административных прав на систему, но все равно стоит исключить возможность запуска подобных обработок для пользователей. И не забудьте попросить специалиста по 1С «встраивать» дополнительные отчеты и обработки в базу. Хотя не во всех обработках поддерживается встраивание ― эта возможность зависит от версии 1С.



      Проверить, какие типовые роли не имеют прав на открытие внешних обработок, можно в конфигураторе.

      Все эти действия не только помогут защититься от потенциального «внутреннего вредителя», но и станут дополнительной преградой на пути вирусов-шифровальщиков, маскирующихся под обработки 1С.

      Если все же необходим запуск внешних обработок, то неплохим вариантом контроля и подстраховки будет аудит их запуска. Штатного механизма аудита у 1С пока нет, но в сообществе уже придумали несколько обходных маневров. Внедрять эти механизмы стоит в паре со специалистом 1С, также как и настраивать уведомления о событиях в журнале регистраций базы.

      Отдельно отмечу возможность настройки доменной аутентификации пользователей вместо аутентификации 1С. И пользователям будет удобнее ― меньше паролей в их памяти снижает риск появления стикеров на мониторе.

      Итак, пользователи теперь не могут запускать обработки, учетная запись сервера максимально ограничена. Но есть и еще кое-что: учетная запись администратора кластера 1С, которая не создается по умолчанию.

      Ее отсутствие опасно: любой человек с ноутбуком при открытом доступе к сетевым портам сервера (по умолчанию это TCP:1540) может создать там свою базу, и ограничений на запуск обработок не будет. А еще злодей сможет получить информацию по базам данных, по работающим пользователям, изменить параметры кластера и даже принудительно завершить работу определенных пользователей.

      Пример скрипта на PowerShell, изгоняющего всех пользователей изо всех баз сервера:

      Использование подобного способа работы с сервером 1С в благих целях уже упоминалось в одной из предыдущих статей.

      Создать администратора кластера не просто, а очень просто ― достаточно щелкнуть правой кнопкой на пункте «администраторы» в управлении кластером 1С, создать нового администратора, задав логин и пароль.



      Создание администратора кластера 1С.

      Я коснулся лишь части недоработок при настройке 1С: Предприятия. Для самостоятельного изучения рекомендую почитать до сих пор не потерявшие актуальность материалы:

      Поделитесь в комментариях своими нестандартными решениями и курьезами при работе с системой 1С: Предприятие.

      Читайте также: