Задался целью, по аналогии как вынес тестовые базы связки 1C 7.7 + SQL на отдельную систему "Перенос базы без функционала Гибкие блокировки на другой сервер" поступить также с базами склада, но там используется связка 1С:Предприятие 8.3 (8.3.18.1208), Конфигурация Управление торговлей, редакция 11 (11.4.13.227) + SQL Server 2016 (13.0.5026.0). К тому же также хочу на сервере где сервис базы данных использовать групповую системную учетную запись, а значит предстоит на основе моих опубликованных заметках собрать все воедино.

Итого план решения задачи:

Шаг №1: Под виртуализацией ESXi 7 создаю виртуальную машину на базе операционной системы Windows Server 2016 Std:

  • RAM: 60Gb
  • HDD: 150Gb (Это диск C) - тут будет система
  • HDD: 500Gb (Это диск D) - тут будут каталоги с файлами mdf & ldf
  • CPU: 1 (4 cores)
  • OS: Windows Server 2016 Std
  • Hostname: srv-db03-test.polygon.local (а боевой srv-db03.polygon.local)

Шаг №2: Чтобы использовать данную групповую системную учетную запись еще на одном сервере нужно все также на домен контроллере (srv-dc01) сделать следующее. Я для себя сделал базовый скрипт, который делает то что нужно мне.

c:\scripts\gmsa.ps1
$server1 = Get-ADComputer SRV-DB01
$server2 = Get-ADComputer SRV-DB04
$server3 = Get-ADComputer SRV-DB05
$server4 = Get-ADComputer SRV-DB10
$server5 = Get-ADComputer SRV-DB06
$server6 = Get-ADComputer SRV-DB03-TEST
Set-ADServiceAccount -Identity SVC1Cv8  -PrincipalsAllowedToRetrieveManagedPassword $server1,$server2,$server3,$server4,$server5,$server6
Get-ADServiceAccount -Identity SVC1Cv8 -Properties PrincipalsAllowedToRetrieveManagedPassword

Отобразить на каких системах можно использовать групповую системную учетную запись SVC1Cv8$:

PS C:\scripts> (Get-ADServiceAccount -Identity SVC1Cv8 -Properties *).Principals
AllowedToRetrieveManagedPassword
CN=SRV-DB01,CN=Computers,DC=polgyon,DC=local
CN=SRV-DB05,CN=Computers,DC=polygon,DC=local
CN=SRV-DB06,CN=Computers,DC=polygon,DC=local
CN=SRV-DB04,CN=Computers,DC=polygon,DC=local
CN=SRV-DB10,CN=Computers,DC=polygon,DC=local
CN=SRV-DB03-TEST,CN=Computers,DC=polygon,DC=local
PS C:\scripts>

Шаг №3: Запускаю скрипт (on srv-dc01) где переменная $server6 есть новых хост с установленным SQL Server 2016 (Version 13.0.5026.0):

Win + X - Command Prompt (Admin)

C:\Windows\system32> powershell
PS C:\Windows\system32> C:\scripts\gmsa.ps1

Шаг №4: Подключаюсь к srv-db03-test по RDP, как Domain Admins и устанавливаю коммандлеты для работы с групповой системной учетной записью SVC1Cv8:

Win + R -> Command Prompt (Admin)

C:\Windows\system32> powershell
PS C:\Windows\system32> Install-WindowsFeature -Name "RSAT-AD-PowerShell"
PS C:\Windows\system32> shutdown /r/ t/3
PS C:\Windows\system32> Test-ADServiceAccount -Identity "SVC1Cv8"
True

Шаг №5: Подключаюсь к srv-db03-test по RDP, как Domain Admins и вношу в локальные групповые политики, что групповой системной учетной записи SVC1Cv8$ можно работать как сервис и запускать задания:

Win + R -> gpedit.msc & Win + X – Run -> gpedit.msc – Local Computer Policy – Computer Configuration – Windows Settings – Security Settings – Local Policies – User Rights Assignment

  • Log on as a batch job: добавляем системную учетную запись, т.е. POLYGON\SVC1Cv8$
  • Log on as a service: добавляем системную учетную запись, т.е. POLYGON\SVC1Cv8$

Шаг №6: Устанавливаю по заметке SQL Server такой же версии, как на боевом srv-db03, а именно это SQL2016 (13.0.5026.0)

Шаг №7: Изменяю, что запуск SQL Server & SQL Agent должны работать от имени групповой системной учетной записи, т.е. должно получиться вот так:

  • Name: SQL Server (MSSQLSERVER)
  • Log On As: POLYGON\SVC1Cv8$
  • Name: SQL Server Agent (MSSQLSERVER)
  • Log On As: POLYGON\SVC1Cv8$

и добавляем в Security - Logins — учетную запись SVC1Cv8$ и даем роль sysadmin

Шаг №8: Теперь когда SQL Server работает можно либо перенести mdf & ldf файлы предварительно сделать Detach базы c боевого сервера srv-db03, опираясь на заметку "Изменить месторасположение базы данных на SQL Server 2014" , а после перенести их на srv-db03-test и выполнить Attach базы, изменить владельца на групповую системную учетную запись.

Вот к примеру база, именуется, как UT26102022

Шаг №9: Подключаюсь к srv-db04 по RDP, как Domain Admins и запустив оснастку управления информационными базами Administration of 1C Enterprise server (к примеру, Вы можете посмотреть заметку "Патчим 1С сервер 8.3 на Server 2016 Std" где я показываю нюансы запуска этой оснастки.

Шаг №10: Создаю "Информационную базу" в оснастке "Кластер 1С" на srv-db04

  • Имя: UT26102022
  • Описание: UT26102022
  • Защищенное соединение: выключено
  • Сервер базы данных: прописываю созданный выше сервер где у меня будут чисто тестовые базы, т.е. srv-db03-test.polygon.local
  • Тип СУБД: MS SQL Server
  • База данных: UT26102022
  • Пользователь сервера БД: ничего не указываю, т.к. на srv-db04 Кластер 1С работает от имени групповой системной учетной записи и на srv-db03-test сервис MS SQL Server также от имени групповой системной учетной записи работает.
  • Пароль пользователя БД: ничего не указываю, т.к. на srv-db04 Кластер 1С работает от имени групповой системной учетной записи и на srv-db03-test сервис MS SQL Server также от имени групповой системной учетной записи работает.
  • Разрешить выдачу лицензий сервером 1С:Предприятия: Да

нажимаю "Да" и получаю ошибку

SQL Server Network Interfaces: The target principal name is incorrect.

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

Спустя некоторое количество времени в логах через оснастку SQL Management Studio нашел сообщение вида:

The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/srv-db03-test.polygon.local:1433 ] for the SQL Server service. Windows return code: 0x21c7, state: 15. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.

Начал раскручивать тему SPN и решил:

C:\Windows\system32>setspn -l srv-db03-test
Registered ServicePrincipalNames for CN=SRV-DB03-TEST,CN=Computers,DC=polygon,DC=local:
        MSSQLSvc/srv-db03-test.polygon.local:1433
        MSSQLSvc/srv-db03-test.polygon.local
        TERMSRV/SRV-DB03-TEST
        TERMSRV/srv-db03-test.polygon.local
        RestrictedKrbHost/SRV-DB03-TEST
        HOST/SRV-DB03-TEST
        RestrictedKrbHost/srv-db03-test.polygon.local
        HOST/srv-db03-test.polygon.local

C:\Windows\system32>

C:\Windows\system32>setspn -D MSSQLSvc/srv-db03-test.polygon.local:1433 srv-db03-test
Unregistering ServicePrincipalNames for CN=SRV-DB03-TEST,CN=Computers,DC=polygon,DC=local
        MSSQLSvc/srv-db03-test.polygon.local:1433
Updated object

C:\Windows\system32>setspn -D MSSQLSvc/srv-db03-test.polygon.local:1433 POLYGON\SVC1Cv8$
Unregistering ServicePrincipalNames for CN=SVC1Cv8,CN=Managed Service Accounts,DC=polygon,DC=local
        MSSQLSvc/srv-db03-test.polygon.local:1433
Updated object

C:\Windows\system32>setspn -A MSSQLSvc/srv-db03-test.polygon.local:1433 POLYGON\SVC1Cv8$
Checking domain DC=polygon,DC=local

Registering ServicePrincipalNames for CN=SVC1Cv8,CN=Managed Service Accounts,DC=polygon,DC=local
        MSSQLSvc/srv-db03-test.polygon.local:1433
Updated object

Переключился в оснастку "Кластер 1С" и успешно создал информационную базу где база данных расположена на новом сервере srv-db03-test.polygon.local и запущена от имени групповой системной учетной записи не указывая "Пользователь сервера БД" и "Пароль пользователя БД". Т.е. как и должно быть.

Почему так произошло и что поспособствовало этой ошибки пока не знаю, либо взгляд был затуманен множеством действий, либо это была Пятница, но теперь я с учетом данной заметки знаю чуть больше чем до этого и главное решил поставленную задачу, а именно развернуть сервер и вынести на него все тестовые базы дабы не отнимать ресурсы боевой базы. Просто раньше было 1,2,3 тестовые базы, а не более 10 как сейчас.

На этом заметка завершена, с уважением автор блога Олло Александр aka ekzorchik.

От ekzorchik