Задался целью, по аналогии как вынес тестовые базы связки 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: 60GbHDD: 150Gb (Это диск C) - тут будет системаHDD: 500Gb (Это диск D) - тут будут каталоги с файлами mdf & ldfCPU: 1 (4 cores)OS: Windows Server 2016 StdHostname: 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 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.