Ошибка 1069 служба не запущена

Устранение неполадок консоли DPM – Data Protection Manager

Ошибка 1069 служба не запущена

  • 08/22/2020
  • Чтение занимает 7 мин
    • r
    • o

Это руководство поможет вам диагностировать и устранять проблемы, связанные с аварийным сбоем, с помощью консоли администрирования в System Center 2016 Data Protection Manager (DPM 2016) и System Center 2012 Data Protection Manager (DPM 2012 или DPM 2012 R2). Типичные идентификаторы ошибки сбоя включают 917, 999, 948 и 1069.

Исходная версия продукта:   System Center 2016 Data Protection Manager, System Center 2012 Data Protection Manager, System Center 2012 R2 Data Protection Manager
Исходный номер статьи базы знаний:   10057

Прежде чем начать устранение неполадок, убедитесь, что установлен последний накопительный пакет обновления для System Center Data Protection Manager. Последнюю версию можно найти в статье System Center — Build Data Protection Manager.

Ошибка 917: потеряно подключение к службе DPM

При работе со сбоями консоли важно понимать, что консоль на сервере DPM использует несколько доступных служб. Если любая из этих служб перестанет работать или завершится ошибкой, скорее всего будет выдано сообщение об ошибке 917:

Подключение к службе DPM потеряно.
Просмотрите журнал событий приложений, чтобы получить сведения о возможном завершении работы службы.

Ниже приведен снимок экрана с этой ошибкой:

Если при запуске консоли произойдет сбой, убедитесь, что запущены все службы DPM. Службы, которые должны быть запущены, перечислены в сообщении об ошибке:

  • ПРИЛОЖЕНИЮ
  • DPMRA
  • Агент SQL Server (для экземпляра DPM)
  • SQL Server (для экземпляра DPM)
  • Служба виртуальных дисков
  • Служба теневого копирования томов

Если одна из служб не запущена, попробуйте запустить ее, а затем снова откройте консоль DPM.

Если службы запущены, а проблема по-прежнему возникает, Убедитесь, что база данных находится в режиме восстановления.

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

Ошибка 1069: служба не была запущена из-за ошибки входа

Если у вас возникли проблемы с запуском одной из служб, относящихся к DPM, она может быть вызвана учетной записью запуска от имени службы. Сбой при запуске службы со следующей ошибкой:

Ошибка 1069: служба не была запущена из-за ошибки входа.

Ниже приведен пример снимка экрана с сообщением об ошибке:

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

Примечание

Лучший способ изменения учетных записей пользователей SQL Server — использование интерфейса диспетчера конфигураций SQL Server.

Имя службыУчетная запись запуска от имениТип запуска.Проверить, не работает ли он?
мсдпмСИСТЕМЫВручнуюДа
DPMRAСИСТЕМЫАвтоматическиНет
Агент SQL Server (для экземпляра DPM)Учетная запись домена (должна быть локальным администратором)АвтоматическиДа
SQL Server (для экземпляра DPM)Учетная запись домена (должна быть локальным администратором)АвтоматическиДа
Служба виртуальных дисковСИСТЕМЫВручнуюДа
Служба теневого копирования томовСИСТЕМЫВручнуюДа
Диспетчер доступа DPMСИСТЕМЫАвтоматическиДа
Координатор агента DPMСИСТЕМЫВручнуюНет
DPM CPWrapperСИСТЕМЫВручнуюНет
Модуль записи DPMСИСТЕМЫАвтоматическиДа
дпмлаСИСТЕМЫВручнуюНет
Служба модуля поддержки VMM DPMСИСТЕМЫВручнуюНет

Проверка того, находится ли база данных в режиме восстановления

Если база данных находится в режиме восстановления, это может вызвать проблемы при попытке служб подключиться к ней. База данных переводится в режим восстановления из-за сбоя или сбоя DPMSync. Чтобы проверить, есть ли в этом случае, выполните следующий запрос SQL для ДПМДБ:

select * from tbl_DLS_GlobalSettingwhere PropertyName 'DbRecovery'

Если PropertyValue возвращено значение 1, база данных находится в режиме восстановления.

Чтобы перевести базу данных из режима восстановления, выполните следующий запрос SQL:

updated tbl_DLS_GlobalSettingset PropertyValue = '0'where PropertyName 'DbRecovery'

После завершения перезапустите службу DPM и снова запустите консоль.

Время ожидания службы истекло

Если учетные записи запуска от имени службы настроены правильно, возможно, возникла проблема со временем ожидания службы. Если при запуске службы время ожидания истекает, можно применить следующую запись реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control

DWORD: ServicesPipeTimeout
Значение: 300000

Если запись не существует, ее можно создать. Значение — это время ожидания в миллисекундах (МС), например 60000 равно 1 минуте (60 секунд). Для реализации изменения необходимо перезапустить службу. При необходимости скорректируйте значение.

Служба запускается, а затем завершает работу

Если служба запускается и затем завершается сбоем, проверьте журнал событий приложений на наличие ошибки, указывающей на сбой службы.

Проверьте наличие записей с ошибкой в качестве уровня и мсдпм (или любой другой службы DPM) в качестве источника во время сбоя.

На вкладке Общие для события должны содержаться сведения о службе, которая завершилась сбоем, и некоторые сведения о сбое.

Например, процесс мсдпм , который завершается с кодом события 999, содержит следующие сведения:

Не удается найти описание для события с ИДЕНТИФИКАТОРом 999 из источника МСДПМ. Компонент, который вызывает это событие, не установлен на локальном компьютере или поврежден. Компонент можно установить или восстановить на локальном компьютере.

Если событие возникло на другом компьютере, отображаемая информация должна быть сохранена вместе с событием.

В событие включена следующая информация:

Непредвиденная ошибка привела к сбою процесса “мсдпм”. Перезапустите процесс DPM “мсдпм”.

Снимок экрана этого события:

В этом примере в разделе сведения о проблеме показано, что произошел сбой с кодом ошибки 0x80004015, который сопоставляется с:

Класс настроен для запуска в качестве идентификатора безопасности, отличного от вызывающего абонента

После этого мы можем начать исследование неполадок с учетной записью пользователя. Так как это была служба МСДПМ, которая завершилась сбоем, следующий шаг — просмотр соответствующего журнала ошибок DPM. Расположение по умолчанию для этих журналов ошибок DPM аналогично C:\Program Files\Microsoft System Center 2012\DPM\DPM\Temp\ .

Журналы ошибок именуются для службы, в которой они хранятся, а текущий файл журнала для каждой службы называется “д * . еррлог*”.

Если произошел сбой службы, система также создает файл аварийного восстановления, подобный показанному ниже:

Событие Crash записывается в конец файла и показывает дополнительные сведения.

При устранении неполадок со сбоями различных служб их причины и решения не выходят за рамки этого руководства.Журналы событий, журналы ошибок и файлы аварийного восстановления должны предоставлять достаточно информации для устранения наиболее распространенных ошибок с помощью форума поддержки DPM.

Ошибка 948: не удается подключиться к серверу DPM

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

Не удается подключиться к . (ID: 948)
Убедитесь, что служба DPM запущена на этом компьютере.

В разделе сведения о проблеме в журнале событий должны быть представлены дополнительные сведения о причине сбоя.

Как правило, база данных находится в автономном режиме или недоступна (скорее всего, если она находится на удаленном сервере) или при входе в систему возникать ошибки.

В таких сценариях, скорее всего, появится сообщение об ошибке в журнале событий, как в одном из следующих примеров:

Ниже приведены некоторые распространенные причины.

Учетная запись, которая не может войти в систему, должна быть четко указана в сообщении об ошибке.В противном случае можно проверить мсдпмкурр. еррлог в папке временных файлов DPM.

Если это не поясно, попробуйте использовать файлы ERRORLOG в расположении установки SQL Server (например, C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Log ).

Путь может изменяться в зависимости от установленной версии SQL Server или в случае, если она установлена не по умолчанию.

Этот файл журнала ошибок должен включать все неудачные записи аудита входа. Для устранения этих ошибок необходимо назначить разрешения учетной записи, указанной для базы данных, указанной в ссылке. Как правило, это может быть учетная запись запуска от имени SQL Server или СИСТЕМная учетная запись:

  • Для учетной записи System можно добавить соответствующие разрешения в SQL Server Management Studio, перейдя к разделам ” Безопасность” >Logins и щелкнув правой кнопкой мыши системную учетную запись. Убедитесь, что выбрана роль sysadmin , как показано ниже:
  • Для учетной записи запуска от имени SQL Server Сбросьте учетную запись в диспетчере конфигурации SQL Server.

База данных или экземпляр отключены

Вы должны убедиться, что служба SQL Server запущена в данный момент. В противном случае проверьте эту возможность. После запуска службы SQL Server попробуйте подключиться к экземпляру из SQL Server Management Studio (SSMS).

Иногда это может произойти, если сервер вошел в систему под другой учетной записью, отличной от учетной записи, в которой он был установлен. В этом сценарии запустите SSMS с правами администратора. Если вы можете успешно подключиться, ДПМДБ находится в сети.

Если ДПМДБ находится в автономном режиме, он будет выглядеть следующим образом:

Если ДПМДБ находится в автономном режиме, щелкните правой кнопкой мыши ДПМДБ, выберите задачи , а затем выберите перевести в оперативныйрежим. После подключения к сети проверьте, устранена ли проблема.

Если вы видите ошибки, предлагающие проблему, связанную с сетью, проверьте подключение к базе данных с сервера DPM, выполнив следующие действия:
  1. Создайте файл UDL. Самым простым способом является переименование пустого TXT-файла с расширением UDL.

  2. Дважды щелкните файл UDL и выберите экземпляр и базу данных для тестирования из раскрывающегося списка.

  3. Щелкните проверить подключение.

В противном случае убедитесь, что вы можете проверить связь с сервером SQL Server с сервера DPM и проверить, правильно ли работает разрешение имен. Кроме того, убедитесь, что возвращен правильный IP-адрес. Убедитесь, что адрес также правильный в SQL Server > сервере DPM. Проверьте наличие других очевидных причин, по которым трафик может не получиться, например брандмауэров.

Источник: https://docs.microsoft.com/ru-ru/troubleshoot/system-center/dpm/troubleshoot-data-protection-manager-console-crash

Служба не запущена из-за ошибки входа

Ошибка 1069 служба не запущена

Когда вы страдаете от того, что служба не запускается из-за ошибки входа в систему, особенно при перезапуске сервера Windows, проблема обычно связана с изменением пароля для профиля, используемого агентом SQL Server.

Однако иногда пароль может оставаться прежним, и вы уверены, что не вносили никаких изменений.

В дополнение к этому вы устали менять используемое имя входа и возвращать его обратно в исходное доменное имя, которое вы не можете делать каждый раз, когда что-то идет не так.

Выше может произойти из-за:

  • Смена пароля для учетной записи, с которой служба настроена для входа
  • Данные пароля повреждены (в реестре)
  • Право на вход в систему в качестве службы было отменено для указанной учетной записи пользователя

Не нужно беспокоиться об этом, поскольку у нас есть только правильные решения для решения проблем, при которых служба не запускалась из-за ошибки входа в систему, ознакомьтесь с приведенными ниже решениями.

Как исправить сервис не запускался из-за ошибки входа в систему

  1. Настройте службу для использования встроенной системной учетной записи
  2. Измените пароль для указанной учетной записи пользователя, чтобы он соответствовал текущему паролю для того же пользователя.
  3. Восстановить право пользователя на вход в систему как сервис

Решение 1. Настройте службу на использование встроенной системной учетной записи.

Если служба не запустилась из-за ошибки входа в систему, настройте ее на запуск со встроенной системной учетной записью, выполнив следующие действия:

  1. Нажмите клавишу Windows + R, чтобы открыть командную строку с повышенными правами Выполнить .
  2. Введите services.msc и нажмите Enter.
  3. Найдите службу Идентификация приложения , щелкните ее правой кнопкой мыши и откройте Свойства .
  4. Откройте вкладку Войти .
  5. Нажмите Учетная запись локальной системы .
  6. Не устанавливайте флажок Разрешить взаимодействовать с рабочим столом .
  7. Нажмите Применить
  8. Перейдите на вкладку Общие .
  9. Нажмите Пуск , чтобы перезапустить службу.
  10. Закройте инструмент Services.

Примечание. . При попытке открыть свойства службы с помощью средства «Службы» на панели управления компьютер может перестать отвечать на запросы и получить сообщение об ошибке: Сервер RPC недоступен. .

Это может произойти, если служба RPC не запущена из-за сбоя входа в систему со службой или службы зависимостей, поскольку некоторым приходится ждать запуска своих служб зависимостей, прежде чем они сами запустятся.

  • ТАКЖЕ ЧИТАЙТЕ: экран входа в систему Windows 10 медленный, завис, заморожен [FIX]

Решение 2. Измените пароль для указанной учетной записи пользователя, чтобы он совпадал с текущим паролем для того же пользователя.

Вот как настроить пароль для указанной учетной записи пользователя, чтобы он соответствовал текущему паролю для этого пользователя:

  1. Снова перейдите к Сервисам, следуя инструкциям предыдущего решения.
  2. В поле поиска введите Администрирование и нажмите на него
  3. Нажмите Услуги
  4. Щелкните правой кнопкой мыши по нужному сервису и выберите «Свойства».
  5. Нажмите вкладку Вход в систему
  6. Измените пароль и нажмите Применить .
  7. Перейдите на вкладку Общие .
  8. Нажмите Пуск , чтобы перезапустить службу.
  9. Нажмите ОК и закройте инструмент «Службы».

ТАКЖЕ ПРОЧИТАЙТЕ: лучшее программное обеспечение для восстановления паролей в Windows 7, которое сэкономит вам время

Решение 3. Восстановите право пользователя на вход в систему в качестве службы

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

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

Вот как это сделать, если пользователь находится в домене Active Directory:

  1. Нажмите правой кнопкой мыши Пуск .
  2. Нажмите Панель управления
  3. Введите Администрирование и выберите его
  4. Нажмите Пользователи Active Directory и Компьютеры .
  5. Щелкните правой кнопкой мыши организационную единицу, в которой предоставлено право пользователя на вход в систему в качестве службы (по умолчанию организационная единица контроллеров домена)
  6. Нажмите правой кнопкой мыши нужный контейнер и выберите Свойства .
  7. Перейдите на вкладку Групповая политика .
  8. Нажмите Политика контроллеров домена по умолчанию .
  9. Нажмите Изменить , чтобы запустить диспетчер групповой политики.
  10. Разверните Конфигурация компьютера .
  11. Разверните Настройки Windows .
  12. Разверните Настройки безопасности .
  13. Разверните Локальные политики .
  14. Нажмите Назначение прав пользователя .
  15. Нажмите правой кнопкой мыши Войти в систему как сервис на правой панели.
  16. Нажмите Добавить пользователя или группу .
  17. Введите имя, которое вы хотите добавить в политику, в поле Имена пользователей и групп .
  18. Нажмите OK .
  19. Выход из диспетчера групповой политики
  20. Закрыть свойства групповой политики,
  21. Выход из оснастки «Active Directory – пользователи и компьютеры» консоли управления (MMC)

Как восстановить права пользователя на рядовом сервере (автономно)

Вот как это сделать, если пользователь является участником автономного рядового сервера:

  1. Запустите оснастку MMC «Локальные параметры безопасности».
  2. Разверните Локальные политики.
  3. Нажмите Назначение прав пользователя .
  4. Нажмите правой кнопкой мыши Войти в систему как сервис на правой панели.
  5. Нажмите Добавить пользователя или группу .
  6. Введите имя, которое вы хотите добавить в политику, в поле Имена пользователей и групп .
  7. Нажмите OK .
  8. Закройте оснастку MMC «Локальные параметры безопасности».

Помогло ли какое-либо из приведенных выше решений исправить службу, не запущенную из-за ошибки входа в систему? Дайте нам знать ваш опыт в разделе комментариев ниже.

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

Источник: https://generd.ru/fix/sluzhba-ne-zapushhena-iz-za-oshibki-vhoda/

Поделиться:
Нет комментариев

    Добавить комментарий

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.