У меня есть сервер разработки с 3 экземплярами: по умолчанию, A и B. Это физический сервер, не кластерный. Каждый раз, когда задание syspolicy_purge_history запускается в 2 часа ночи, я получаю предупреждения о неудачном входе в систему. Глядя на этапы работы, все они успешно выполнены. Похоже, что в какой-то момент на этапе «Стереть фантомные записи о работоспособности системы» происходят неудачные попытки входа в систему.
syspolicy_purge_history на экземпляре B работает нормально.
syspolicy_purge_history в экземпляре по умолчанию, похоже, хочет подключиться к экземпляру B, в результате чего:
Error: 18456, Severity: 14, State: 11. Login failed for user
'Machinename\sqlsvc-B'. Reason: Token-based server access validation
failed with an infrastructure error. Check for previous errors.
[CLIENT: <local machine>] .
Powershell не сообщает об ошибках.
syspolicy_purge_history в экземпляре A, похоже, хочет подключиться к экземпляру по умолчанию, что приводит к
Error: 18456, Severity: 14, State: 11. Login failed for user
'Machinename\sqlsvc-Default'. Reason: Token-based server access
validation failed with an infrastructure error. Check for previous
errors. [CLIENT: <local machine>] .
Затем он пытается подключиться к экземпляру B, в результате чего
Error: 18456, Severity: 14, State: 11. Login failed for user
'Machinename\sqlsvc-B'. Reason: Token-based server access validation
failed with an infrastructure error. Check for previous errors.
[CLIENT: <local machine>] .
Powershell не сообщает об ошибках.
Я попробовал описанные здесь шаги, надеясь, что они это исправят. http://support.microsoft.com/kb/955726 Но опять же, это не виртуальный сервер и не в кластере. Есть ли у вас какие-либо предложения? Спасибо.
Я использовал обходной путь, опубликованный на эта страница подключения пользователя "Кайл Нейер". Это сработало для меня.
Просто замените код PowerShell на шаге 3 задания агента SQL "syspolicy_purge_history" (тот, который выполняется в экземпляре по умолчанию) следующим:
$SQLServerConnection = New-Object System.Data.SqlClient.SqlConnection
$SQLServerConnection.ConnectionString = "Data Source=$(ESCAPE_NONE(SRVR));Initial Catalog=master;Integrated Security=SSPI;Application Name=syspolicy_purge_history"
$PolicyStoreConnection = New-Object Microsoft.SqlServer.Management.Sdk.Sfc.SqlStoreConnection($SQLServerConnection)
$PolicyStore = New-Object Microsoft.SqlServer.Management.Dmf.PolicyStore ($PolicyStoreConnection)
$PolicyStore.EraseSystemHealthPhantomRecords()
Я столкнулся с этой проблемой несколько недель назад.
Каков был результат после выполнения метода 2 (воссоздать задание syspolicy_purge_history)?
Что касается вашего комментария «syspolicy_purge_history в экземпляре по умолчанию, кажется, хочет подключиться к экземпляру B», вы изменили шаг 3 (Стереть фантомные системные записи о работоспособности) так, чтобы он подключается к экземпляру DEFAULT, а не к экземпляру B?
Это на Windows Server 2008. После выполнения метода 2 были те же ошибки. На шаге 3 показано подключение к соответствующему приложению.
Экземпляр по умолчанию
SQLSERVER:\SQLPolicy\TEST\DEFAULT).EraseSystemHealthPhantomRecords()
Экземпляр А
SQLSERVER:\SQLPolicy\TEST\A).EraseSystemHealthPhantomRecords()
Экземпляр B
SQLSERVER:\SQLPolicy\TEST\B).EraseSystemHealthPhantomRecords()
У меня есть два экземпляра 2005 года и два экземпляра 2008R2 на одном сервере. Все они использовали СЕТЕВОЙ СЕРВИС для всех услуг. Я изменил службу агента SQL Server на одном из экземпляров 2008R2, чтобы использовать новую учетную запись домена, настроенную специально для этой цели. С тех пор примерно в 2 часа ночи я получаю отказы входа в систему на трех других экземплярах для этой новой учетной записи службы. Я никогда ничего не делал с управлением на основе политик.
Обходной путь, который я нашел Вот похоже, чтобы добавить учетную запись для этой новой учетной записи домена к трем другим экземплярам. Истинное исправление, казалось бы, заключалось в том, что Microsoft добавила параметр к процессу, который вызывается заданием syspolicy_purge_history, чтобы ограничить его область действия только текущим экземпляром, сделать это по умолчанию и задокументировать все это где-нибудь, кроме Connect.