Управление сервером приложений 1С с помощью PowerShell

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

В реальном мире перед администратором сервера приложений сразу же встает большое количество задач, решить которое можно только используя продвинутые методы интеграции. Такие как например менеджер COM-соединений сервера приложений. Описание его свойств и методом доступно в (страшно сказать) Синтакс-помощнике, в ветке Средства интеграции и администрирования -> Менеджер COM –соединений.

В то же время любимым продуктом администраторов серверов Windows для автоматизации различных рутинных процессов является PowerShell, который заменил устаревшие WSH\VBScript  скрипты и архаичные BAT-файлы, начиная с Windows Server 2003.

Осталось только объединить возможности двух «подсистем», написав скрипт на PowerShell, который будет управлять сервером приложений 1С, с помощью com-администратора. 

Первая и самая простая задача из «реального мира» – перезапуск сервиса «Агент сервера 1С» по расписанию (вернее стоп-старт с таймаутом, из-за особенностей работы агента сервера). На PowerShell это можно сделать по разному, например так:

Get-service "1C:Enterprise 8.2 Server Agent*" | stop-service

Start-Sleep -s 40

Get-service "1C:Enterprise 8.2 Server Agent*" | start-service

 В расписание, как обычно мы скрипт поставим в шедулере Windows.

Теперь вторая задача из «реального мира», уже посложнее.

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

Для PowerShell это тоже не слишком сложная задача:

# Сценарий разрывает все сессии пользователей во всех ИБ на выбранном кластере сервера приложений 1С
# Если часть сессий остается активными после этого, то он останавливает все рабочие процессы кластера

# Параметры запуска сценария: адрес сервера, основной порт кластера
$SrvAddr = "tcp://y001-ap-01:1640"

$MainPort = "5641"
########################################
$V82Com = New-Object -COMObject "V82.COMConnector"
# Подключение к агенту сервера

$ServerAgent = $V82Com.ConnectAgent($SrvAddr)
$ClusterFound = $FALSE
#Получим массив кластеров сервера

$Clasters = $ServerAgent.GetClusters()
foreach ($Claster in $Clasters)
{

if ($Claster.MainPort -eq $MainPort)
{
$ClusterFound = $TRUE
break
}
}

if (!($ClusterFound))
{
break
}

# Аутентификация к выбранному кластеру
# если у пользователя, под которым будет выполняться сценарий нет прав на кластер,
# можно прописать ниже имя пользователя и пароль администратора кластера

$ServerAgent.Authenticate($Claster,"","")

#получаем список сессий кластера и прерываем их
$Sessions = $ServerAgent.GetSessions($Claster)
write-host "Разрывается" $Sessions.Count "сессий..."
foreach ($Session in $Sessions)
{
$ServerAgent.TerminateSession($Claster,$Session)
}
if (($Sessions.Count -eq 0))
{
break
}

# Если часть сессий осталась активной можно остановить рабочие процессы
# Они перезапустятся автоматически главным менеджером кластера, но без "зависших" сессий

# Получаем список рабочих процессов кластера
$WorkingProcesses = $ServerAgent.GetWorkingProcesses($Claster)

foreach ($WorkingProcess in $WorkingProcesses)
{
if ($WorkingProcess.Running -eq 1)
{
write-host "Останавливаем процесс с PID =" $WorkingProcess.PID
#!!!здесь хорошо бы проверить что компьютер с которого запущен сценарий это выбранный в параметрах запуска сервер приложений 1С
Stop-Process $WorkingProcess.PID -Force

}

}

$V82Com = ""

Как видите в скрипте мы используем только методы объекта «Соединение с агентом сервера», т.е. работает на уровне кластера, а не на уровне конкретной информационной базы.

Так что следующей задачей будет например такая: поставить блокировку соединений на конкретную информационную базу. Это уже потребует использование объекта «Соединение с рабочим процессом» и аутентификации в конкретную ИБ.

# Сценарий устанавливает блокировку соединений в выбранной ИБ на выбранном кластере сервера приложений 1С

# Параметры запуска сценария: адрес сервера, основной порт кластера, информационная база

$SrvAddr = "tcp://y001-ap-02:1640"

$MainPort = "5641"

$InfoBaseName = "aspb4"

$V82Com = New-Object -COMObject "V82.COMConnector"

 # Подключение к агенту сервера

 $ServerAgent = $V82Com.ConnectAgent($SrvAddr)

$ClusterFound = $FALSE 

$InfoBaseFound = $FALSE              

#Получим массив кластеров сервера

 $Clasters = $ServerAgent.GetClusters()

foreach ($Claster in $Clasters)

{

if ($Claster.MainPort -eq $MainPort)

    {

    $ClusterFound = $TRUE    

    break

    }

}

if (!($ClusterFound))

  {

   break

  }

# Аутентификация к выбранному кластеру

# если у пользователя под которым будет выполняться сценарий нет прав на кластер,

# можно прописать ниже имя пользователя и пароль администратора кластера

 $ServerAgent.Authenticate($Claster,"","")

 # Получаем список рабочих процессов кластера

 $WorkingProcesses = $ServerAgent.GetWorkingProcesses($Claster)

foreach ($WorkingProcess in $WorkingProcesses)

  {                    

    if (!($WorkingProcess.Running -eq 1) )

    {

        continue   

    }

   $CWPAddr = "tcp://"+$WorkingProcess.HostName+":"+$WorkingProcess.MainPort  

   $CWP= $V82Com.ConnectWorkingProcess($CWPAddr)

   $CWP.AddAuthentication("", "")

    $InfoBases =$CWP.GetInfoBases()

 foreach ($InfoBase in $InfoBases)

   {

   if ($InfoBase.Name -eq $InfoBaseName )

     {

       $InfoBaseFound = $TRUE    

       break

     }

   }

  if (!($InfoBaseFound))

  {

   write-host "Не найдена указанная в параметрах запуска ИБ..."

   break

  }

 # Устанавливаем блокировку соединений ИБ

 $InfoBase.ConnectDenied = $True

 $CWP.UpdateInfoBase($InfoBase)               

  } 

$V82Com = ""

Вы можете соединить возможности второго и третьего сценария и получить «абсолютное  оружие» для отсоединения пользователей от конкретной ИБ, для проведения каких-либо регламентных работ. 

Вообще обилие свойств и методов COM-администратора позволяет решать совершенно различные задачи,  а не только связанные с «любимой» задачей администраторов «выгнать пользователей» .

Например, на постоянной основе получать объектные блокировки в конкретной ИБ и собрав статистику принять решение о недостатках модели метаданных.

Или собирать статистику о соединениях на кластере, чтобы ответить на вопрос «куда ушли все свободные лицензии?» (нетривиальная задача в корпоративной системе с кучей терминальных серверов, большим количеством ИБ и клиентов).

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