Все сделали по инструкции , но MS SQL Server все равно бунтует? Можно пойти на какой-нибудь форум и пожаловаться там.
Highload решил упростить вам задачу и просто собрал топ причин, почему не устанавливается Microsoft SQL Server, в одном материале.
На компьютере уже был MS SQL Server, и какие-то его файлы мешают новой установке
Даже если перед установкой новой версии MS SQL Server вы удалили старую, что-то могло не удалиться. Это «что-то» система продолжает держать и не дает поставить новую СУБД (систему управления базами данных).
Решение: почистить файлы вручную (вплоть до реестра) или какой-то программой; переустановить фреймворк и распространяемый Visual C++ Redistributable
Пользователя, которого вы назначили управлять сервером, не существует (или у него нет нужных прав)
В начале установки нужно задать пользователя и пароль учетной записи, которая будет управлять службой MS SQL Server. Если этого пользователя нет, он ограничен в правах доступа или система просто решила испортить вам день, с СУБД будут проблемы. Она либо не установится, либо установится криво.
Проверка согласованности разделов реестра SQL Server — Ошибка при установке MS SQL Express
Решение: можно долго и нудно разбираться с текущим пользователем, но лучше просто создать нового; или вообще использовать системную учетную запись (SYSTEM)
Имя компьютера и/или имя пользователя задано кириллицей
То есть русскими буквами. Примитивная причина, но иногда такое случается.
Решение: поменять имя компьютера на английское И заодно проверить всех пользователей
Вы ввели неправильный пароль пользователя
Опять же — чистая невнимательность. Если на этапе установки ввести не тот пароль для пользователя, который будет управлять службой, Microsoft SQL Server не напишет вам, что он неправильный.
Решение: вручную проверить пароль пользователя
Версия SQL Server не поддерживается текущей версией Windows Server
Или наоборот. Посмотрите список требований к вашей версии SQL Server на сайте Microsoft. Если вашего Windows Server в списке нет — ничего не попишешь.
Решение: поставить другую версию SQL Server, или обновить Windows Server, или просто поставить SQL не на сервер, а на обычный Windows
Версия SQL Server не поддерживается вашей Windows
Например, SQL Server 2012 подходит для Windows от Vista до семерки, а с установкой на десятку могут быть проблемы.
Решение: как и в прошлом пункте, только с поправкой на обычный Windows; если очень нужна именно эта версия SQL, можно попробовать запустить ее в режиме совместимости с какой нибудь из других версий Windows — «методом проб и ошибок»
Вы поставили новую версию SQL Server
Это не совсем проблема, так как в этом случае все, скорее всего, установится, но не будет окошка с запуском программы . В новых версиях MS SQL сам сервер и SQL Server Management Studio (SSMS, визуальная оболочка) разъединены. Поэтому если нужна именно программа, в которой можно будет визуально работать с базами, то нужно ставить еще и SSMS.
WSUS + SQL на Core. Часть вторая — настройка учетной записи служб
Решение: поставить старую версию SQL Server, установить Management Studio или просто работать без графической оболочки
Вы засорили реестр
Иногда это приводит не к ошибке инсталляции, а к ее бесконечной загрузке. Если прошло несколько часов и ничего не установилось — это оно.
Решение: удалить из реестра HKLMSOFTWAREWOW6432NodeMicrosoftMicrosoft SQL Server Management Studio ; а лучше вообще почистить реестр вручную или программой
Вы скачали кривой дистрибутив
Такое тоже может быть, особенно если скачивали не с официального сайта .
Решение: скачать нормальный дистрибутив
Мешают вирусы
В этом случае, как именно они повлияют на установку, предсказать невозможно.
Решение: удалить Microsoft SQL Server подчистую (то есть, в том числе из реестра); проверить ПК на вирусы; установить все заново
Highload нужны авторы технических текстов. Вы наш человек, если разбираетесь в разработке, знаете языки программирования и умеете просто писать о сложном!
Откликнуться на вакансию можно здесь .
Эта статья поможет вам решить проблему, возникаюную при установке или обновлении Microsoft SQL Server после ужесточения безопасности.
Оригинальная версия продукта: SQL Server 2008, SQL Server R2, SQL Server 2012
Исходный номер КБ: 2000257
Симптомы
Рассмотрим следующий сценарий. Чтобы усилить безопасность, вы удалите некоторые права пользователей по умолчанию для локальной группы администраторов в Windows операционной системе. При подготовке к настройке SQL Server этой системы вы добавляете учетную запись Setup в группу локальных администраторов.
Scenario3: Не удается установить SQL Server 2012 или SQL Server R2 2008
Правило «Настройка привилегий учетной записи» не удалось. У учетной записи, SQL Server установки, нет одного или всех следующих прав: права на архивации файлов и каталогов, права на управление аудитом и журнала безопасности, а также права на отладку программ. Чтобы продолжить, используйте учетную запись с обоими этими правами.
SQL Server учетной записи установки не имеет привилегии SeSecurityPrivilege на указанном файловом сервере в пути. Эта привилегия необходима в действии по настройке безопасности папок SQL Server программы установки. Чтобы предоставить эту привилегию, используйте консоль Local Security Policy на этом файловом сервере, чтобы добавить SQL Server учетную запись установки в политику «Управление аудитом и журналом безопасности». Этот параметр доступен в разделе «Назначения прав пользователей» в разделе Локальные политики в консоли Local Security Policy.
Эта проблема возникает из SQL Server учетной записи установки не имеет разрешений на файловом сервере, на котором SeSecurityPrivilege размещена сеть.
Причина
Такое поведение является особенностью данного продукта. В дополнение к добавлению учетной записи пользователя, которая работает в качестве локального администратора, учетная запись пользователя Setup требует следующих прав пользователя по умолчанию для успешного завершения установки.
Резервные файлы и каталоги | SeBackupPrivilege |
Программы отлаговки | SeDebugPrivilege |
Управление журналом аудита и безопасности | SeSecurityPrivilege |
Дополнительные сведения о разрешениях, необходимых для установки SQL Server, см. в разделе «Необходимые условия» следующих статей MSDN:
Кроме того, если SMB Fileshare используется в качестве параметра хранилища для каталога данных или любых других каталогов (каталог баз данных пользователей, каталог журналов баз данных пользователей, каталог tempDB, каталог журналов TempDB или резервного копирования), для учетной записи установки в SMB fileserver, как описано в следующей статье MSDN: Установка SQL Server с хранилищем файловSMB fileshare
Папка sMB Network share | ПОЛНЫЙ КОНТРОЛЬ | SQL Server и SQL Server учетная запись службы агентов |
SMB Fileserver | SeSecurityPrivilege | SQL Учетная запись установки |
Решение
Чтобы добавить права в учетную запись локального администратора, выполните следующие действия:
Дополнительные сведения
Чтобы проверить список привилегий, которые в настоящее время связаны с учетной записью, используемой для установки, можно использовать AccessChk.exe. Чтобы скачать этот инструмент, см. в рубрике AccessChk v6.13.
Использование: accesschk.exe- a *
Например: c:toolsaccesschk.exe -a testdcsetupaccount *
Вопросы и ответы
Почему seSecurityPrivilege требуется на файловом сервере для каталога Резервного копирования в совместной акции UNC?
Это разрешение требуется для получения acLs в каталоге резервного копирования по умолчанию, чтобы убедиться, что SQL Server учетной записи службы имеет полные разрешения на папку. Это также задает ALS, если отсутствуют разрешения для учетной записи SQL службы, чтобы она выполняла резервное копирование в каталоге. Настройка выполняет эти проверки для каталога резервного копирования по умолчанию, чтобы при выполнении резервного копирования в каталоге по умолчанию пользователь не сталкивался с ошибкой или проблемой (из-за отсутствующих разрешений) при выполнении резервного копирования в каталоге по умолчанию.
SeSecurityPrivilege требуется для изменения acLs get/set из каталогов и подстановок. Это происходит потому, что даже пользователи, у которых есть разрешения на полный контроль в каталогах, не имеют разрешений на доступ к данным OWNER и Audit из каталога.
Почему ошибка, описанная в сценарии 4, возникает SQL Server 2012 и более поздних версиях SQL Server?
В SQL Server 2012 г. и более поздних версиях Корпорация Майкрософт начала поддерживать данные и файлы журналов в SMB-файле. В рамках этого улучшения была улучшена возможность установки для ужесточения проверок, чтобы клиенты не сталкивались с ошибками или ошибками из-за недостаточного количества разрешений после установки. В версиях SQL Server 2012 года клиенты по-прежнему могут настроить путь сетевого обмена для каталога Резервного копирования, если у учетной записи службы SQL нет разрешений на выполнение резервного копирования. Однако в этой ситуации они столкнутся с ошибкой после установки. Эти сценарии теперь предотвращены при запуске проверки SQL 2012 г. на сетевой совместной основе.
Столкнулся с интересной ошибкой при установке MS SQL Server 2014 на новом сервере Windows Server 2012 R2. Установка SQL Server прерывается почти в самом конце с ошибкой «Не найден дескриптор запуска компонента Database Engine» (Could not find the Database Engine startup handle).
В логе установки Summary.txt при этом присутствует ошибка:
Данная ошибка установки MS SQL Server связана с тем, что используются стандартные настройки установки, при котором служба SQL Server запускается под непривилегированной учетной записью NT ServiceMSSQL$V2014. У данной учетной записи может быть недостаточно полномочий для запуска службы SQL Server, поэтому запустить службу невозможно, и установщик завершается с ошибкой «Could not find the Database Engine startup handle». Также эта ошибка может указывать на то, что ранее на компьютере уже пытались установить SQL Server и не очистили файлы и службы, оставшиеся от предыдущей установки.
- Корректно деинсталлируйте все программы, связанные с SQL Server через Панель управления и перезагрузите сервер (проверьте, что не осталось файлов и папок в каталоге C:Program FilesMicrosoft SQL ServerMSSQL12.xxx);
- Запустите чистую установку из дистрибутива SQL Server. На вкладке «Server Configuration» убедитесь, что служба SQL Server Database Engine запускается под учетной записью NT ServiceMSSQLSERVER;
В свете недавних событий с повышением вирусной активности многие организации стали уделять больше внимания вопросам всестороннего усиления мер безопасности в собственных ИТ-инфраструктурах. При этом некоторые из применяемых мер могут создать дополнительные сложности в работе самих ИТ-специалистов. Как известно, в последних вариациях вирусов-шифровальщиков, таких как Petya , используются такие инструменты компрометации учётных данных, как Mimikatz . Одним из методов защиты от Mimikatz является запрет на получение в Windows-системе привилегии SeDebugPrivilege. В инфраструктуре Active Directory настроить такое ограничение можно глобально для всех компьютеров домена с помощью параметра групповой политики «Debug programs» в разделе Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment:
Если в данной политике явно задать доменную группу безопасности, то только члены данной группы смогут получить привилегию SeDebugPrivilege на всех компьютерах домена, на которые будет действовать данная групповая политика. Однако данная политика может осложнить жизнь не только инструментам типа Mimikatz, но и вполне легитимным приложениям, которые в своей работе могут использовать привилегии отладки. Например, после включения данной политики программа установки SQL Server 2012 может завершаться с ошибкой проверки правила » Setup account privileges » … …в том случае, если пользователь, от имени которого выполнятся установка, не был предварительно включён в соответствующую доменную группу безопасности, даже не смотря на то, что данный пользователь входит в группу локальных администраторов сервера.
Если заглянуть в отчёт SystemConfigurationCheck_Report.htm , который создаётся в процессе установки SQL Server в каталоге типа » C:Program FilesMicrosoft SQL Server110Setup BootstrapLog\ «…
…, то мы увидим, что срабатывает правило HasSecurityBackupAndDebugPrivilegesCheck, которое и выполняет проверку наличия прав доступа SeSecurityPrivilege, SeBackupPrivilege и SeDebugPrivilege. Как я понял, если хотя бы одна из перечисленных привилегий не будет доступна пользователю, от имени которого запущен процесс установки SQL Server, то ошибка при проверке правила HasSecurityBackupAndDebugPrivilegesCheck неизбежна. Как же быть в такой ситуации тем пользователям, которые являются локальными администраторами серверов, но не могут при этом установить SQL Server не прибегая к помощи администраторов безопасности уровня домена? Неужели каждый раз придётся терзать доменную группу безопасности, определённую в политике «Debug programs»? Возникла идея «поковырять» вопрос того как, обладая правами локального администратора на сервере, но не входя при этом в группу безопасности из политики «Debug programs», успешно выполнить установку SQL Server. После некоторых экспериментов в этой области на платформе Windows Server 2012 R2 Standard с установщиком SQL Server Standard 2012 SP2 удалось добиться желаемого результата. В решении задачи помогла старенькая утилита ntrights.exe из пакета Windows Server 2003 Resource Kit Tools . Примеры использования утилиты можно найти в статье How to Set Logon User Rights with the Ntrights.exe Utility Чтобы получить необходимую нам привилегию SeDebugPrivilege, достаточно выполнить команду типа: где KOMVasya имя доменного пользователя, от имени которого мы будем выполнять установку SQL Server. После выполнения этой команды, соответствующему пользователю необходимо выполнить logoff/logon и запросить информацию о текущем наборе прав, например с помощью утилиты whoami: Как видим, теперь все три нужные нам привилегии, необходимые для установки SQL Server получены, и мы можем снова попытаться выполнить установку. И на этот раз предварительная проверка и последующая установка должны пройти успешно.
Однако помните про то, что после очередного применения групповой политики право SeDebugPrivilege будет снова изъято (согласно настроек доменных GPO) и уже после следующего logoff/logon данная привилегия у нашего пользователя перестанет работать. На мой взгляд, такое поведение системы можно расценивать, как уязвимость, которую помимо легитимного локального администратора может эксплуатировать и вредительское ПО с уровнем прав локального администратора. То есть, даже с глобально включённой в домене политикой «Debug programs», по факту остаётся риск получения права SeDebugPrivilege со стороны вредоносного ПО, использующего такие инструменты, как Mimikatz. Я столкнулся с интересной ошибкой при установке MS SQL Server 2014 на новую виртуальную машину под управлением Windows Server 2012 R2. Установка SQL Server была прервана почти в конце с ошибкой « Не удалось найти дескриптор запуска компонента Database Engine ». В журнале установки SQL произошла следующая ошибка (файл summary.txt):
Особенность: Услуги СУБД
Статус: Ошибка: подробности см. В журналах.
Причина сбоя: во время процесса установки функции произошла ошибка.
Следующий шаг: используйте следующую информацию для устранения ошибки, удалите эту функцию, а затем снова запустите процесс установки.
Имя компонента: функции экземпляра служб СУБД SQL Server
Код ошибки компонента: 0x851A0019
Описание ошибки: не удалось найти дескриптор запуска компонента Database Engine.
- Правильно удалите все программы, связанные с SQL Server, из панели управления и перезапустите сервер (убедитесь, что в папке C: Program Files Microsoft SQL Server MSSQL12.xxx нет файлов или папок).
- Запустите установку из дистрибутива SQL Server с нуля. На вкладке Конфигурация сервера убедитесь, что служба ядра СУБД SQL Server запущена с учетной записью NT Service MSSQLSERVER;
- Измените эту учетную запись на NT AUTHORITY SYSTEM;
- Продолжите установку SQL Server. Ошибка не должна появиться снова.
После завершения установки мы настоятельно рекомендуем изменить учетную запись, под которой запускается компонент SQL Server Database Engine, на непривилегированную учетную запись.
Вам не нужно предоставлять этой учетной записи права локального администратора (достаточно предоставить необходимые привилегии в настройках безопасности SQL Server).
Вы можете использовать учетные записи с привилегиями системного администратора: NT Service MSSQLSERVICE или NT Service SQLSERVERAGENT.
Чтобы изменить учетную запись, под которой работает SQL Server:
- Запустите диспетчер конфигурации SQL Server и перейдите к службам SQL Server;
- Нажмите SQL Server (MSSQLSERVER), затем нажмите кнопку «Обзор» и в поле «Эта учетная запись» укажите учетную запись, под которой должна быть запущена служба, или используйте gMSA (учетная запись группы управляемых служб). Введите пароль пользователя и сохраните изменения;
- Перезапустите службы SQL Server.
Источник: kompyutery-programmy.ru
Получение привилегии SeDebugPrivilege при включенной политике Debug Program
15.09.2017
itpro
SQL Server, Безопасность, Групповые политики
комментариев 6
В предыдущей статье мы рассказывали, что одной из техник защиты от извлечения паролей из памяти Windows mimikatz-like утилитами является запрет получения debug-привилегии для администраторов системы с помощью групповой политики Debug Program. Однако недавно обнаружилось, что без прав отладки (в Windows это привилегия SeDebugPrivilege), локальный администратор сервера не может установить или обновлять Microsoft SQL Server. Дело в том, что установщик SQL Server при запуске проверяет наличие привилегий SeSecurity. SeBackup и SeDebug, которые нужны ему для запуска процесса SQL Server и получения информации об успешном запуске SQL Server. Вот как это выглядит.
Во время установки SQL Server при выполнении предварительных проверок установщик спотыкается на проверке Setup account privileges.
Щелкнув по ссылке “Failed”, можно увидеть такое сообщение:
Rule “Setup account privileges” failed.
The account that is running SQL Server Setup does not have one or all of the following rights: the right to back up files and directories, the right to manage auditing and the security log and the right to debug programs. To continue, use an account with both of these rights. For more information, see https://msdn.microsoft.com/en-us/library/ms813696.aspx, https://msdn.microsoft.com/en-us/library/ms813959.aspx and https://msdn.microsoft.com/en-us/library/ms813847.aspx.
Откроем теперь отчет установки SystemConfigurationCheck_Report.htm.
Как вы видите, установщик при проверке правила HasSecurityBackupAndDebugPrivilegesCheck установил, что у текущего процесса отсутствует одна из следующих привилегий:
- SeSecurity – управление журналами аудита и безопасности
- SeBackup – права на резервное копирование файлов и каталогов
- SeDebug — право отладки программ
В логе есть более детальная информация, указывающая, что у процесса установки отсутствует флаг SeDebug:
(09) 2017-09-12 14:25:13 Slp: Initializing rule : Setup account privileges
(09) 2017-09-12 14:25:13 Slp: Rule is will be executed : True
(09) 2017-09-12 14:25:13 Slp: Init rule target object: Microsoft.SqlServer.Configuration.SetupExtension.FacetPrivilegeCheck
(09) 2017-09-12 14:25:13 Slp: Rule ‘HasSecurityBackupAndDebugPrivilegesCheck’ Result: Running process has SeSecurity privilege, has SeBackup privilege and does not have SeDebug privilege.
(09) 2017-09-12 14:25:13 Slp: Evaluating rule : HasSecurityBackupAndDebugPrivilegesCheck
(09) 2017-09-12 14:25:13 Slp: Rule running on machine: msk-sql10
(09) 2017-09-12 14:25:13 Slp: Rule evaluation done : Failed
Я решил поискать обходной путь получения прав SeDebugPrivilege без изменения или отключения политики Debug programs. И как оказалось, имеется довольно простой способ обхода этой политики при наличии прав локального администратора на сервере. В этом нам поможет утилита secedit, позволяющая управлять локальными политиками безопасности сервера.
Проверяем текущие привилегии:
whoami /priv
Как вы видите, сейчас в текущем токене пользователя отсутствует привилегия SeDebugPrivilege .
Экспортируем текущие права пользователей, настроенные групповыми политиками в текстовый файл:
secedit /export /cfg secpolicy.inf /areas USER_RIGHTS
Теперь с помощью любого тестового редактора нужно открыть на редактирование файл secpolicy.inf и в секцию [Privilege Rights] добавить строку, предоставляющую права Debug Programs группе локальных администраторов.
Примечание. SID группы локальных администраторов S-1-5-32-544 можно заменить на любой другой. Процесс преобразования имени группы или пользователя в SID описан в статье Как узнать SID пользователя по имени и наоборот
Сохраните файл. Теперь нужно применить новые пользовательские права:
secedit /configure /db secedit.sdb /cfg secpolicy.inf /overwrite /areas USER_RIGHTS
Примечание. Необходимо подтвердить перезапись текущих настроек.
Теперь нужно выполнить логофф/логон и с помощью secpol.msc убедиться, что для группы локальных администраторов назначены права Debug Program. Это же подтверждает команда whoami /priv:
SeDebugPrivilege Debug programs Enabled
Теперь можно запускать установку/обновлений SQL Server. Но стоит иметь в виду, что привилегия SeDebugPrivilege в данном случается назначается лишь временно и они будут сброшены при следующем обновлении групповых политик (но уже после logoff пользователя).
Как вы понимаете, включение запретительной политики Debug programs не является панацей от получения права SeDebugPrivilege вредоносными программами, которые уже проникли на сервер с правами локального администратора, что может скомпрометировать все учетные записи пользователей/администраторов, работящих на сервере.
Предыдущая статья Следующая статья
Источник: winitpro.ru
Решено установка кластера SQL server
Добрый день, решил спросить в отдельной теме. Ставлю SQL сервер 2019 в режиме отказоустойчивого кластера. Есть три виртуальные машины у каждой свой системный диск и к каждой приделан один и тот же LUN как диск E:. Как в данном случае выбирать каталоги экземпляра? По задумке хочется что бы базы данных были на E: диске. Где это выбрать при установке ? Это корневой каталог экземпляра ?
Последнее редактирование модератором: 12.03.2020
alxmel
Участник
Подскажите что это может быть?
Путь MSSQL15.CLUSTERDBMSSQLDATA имеет неправильный формат или не является абсолютным.
alxmel
Участник
Все разобрался сам, надо было добавить диск в кластер
alxmel
Участник
Теперь не то что то с правами..
ЗАГОЛОВОК: Сведения о сообщении
Отсутствует учетная запись системного администратора. Чтобы продолжить, укажите как минимум одну учетную запись Windows для подготовки в качестве системного администратора SQL Server.
Surf_rider
Администратор
Команда форума
ну пользователя то добавьте от кого служба работать будет.
alxmel
Участник
ну пользователя то добавьте от кого служба работать будет.
А какой Ip адрес надо указывать при кластерной установке SQL ?
ЗАГОЛОВОК: Установка Microsoft SQL Server 2019
Произошла следующая ошибка:
Не удалось сохранить общие свойства для ресурса «SQL IP Address 1 (CLUSTERDB)». Ошибка: Произошел сбой при вызове кода кластера от поставщика. Сообщение об исключении: IP-адрес кластера уже используется.
Fox
Участник
А какой Ip адрес надо указывать при кластерной установке SQL ?
укажите не занятый свободный IP адрес
alxmel
Участник
А где хранятся имена кластера SQL сервера ? Я удалил его и хочу поставить заново но он мне говорит что
Группа кластера «SQL Server (MSSQLSERVER)» находится вне сети. Чтобы продолжить, переведите группу в режим «в сети».
——————————
Группа кластера «SQL Server (MSSQLSERVER)» содержит ресурс «SQL IP Address 1 (CLUSTERDB)» типа «IP Address», наличие которого не допускается в группе ресурсов SQL Server. Убедитесь, что в группе кластера отсутствуют ресурсы SQL Server из другого экземпляра или ресурсы, имеющие типы общей службы.
Где мне удалить теперь CLUSTERDB ??
Surf_rider
Администратор
Команда форума
Вот здесь — оснастка Диспетчер отказоустойчивости кластеров
Оттуда удалите и все
Surf_rider
Администратор
Команда форума
Вот в помощь руководство неплохое по инсталляции кластера