Не удалось запустить службу агент сервера 1с ошибка 1069
Ошибка 1069: Не удалось запустить службу SQL Server VSS Writer
Доброго времени суток! Прошу прощения сразу, потому что я не совсем разобрался в какой именно.
Не могу запустить службу времени на домене
Не могу запустит службу времени на домене. Eventid 7000 Сбой при запуске службы "Служба времени.
Не могу запустить службу Общий доступ к подключению к Интернету(ICS)
Здравствуйте, настраиваю дома точку доступа WiFi У меня windows 7 максимальная Столкнулся с такой.
Спасибо
Здесь надо Проверить конфигурацию. Видимо, путь неправильно прописан во время установки, но и на других компьютерах с XP Она тоже не запускается. не было проблем с 7ой.
Какой путь?
У вас учетка, от имени которой стартует служба - .\Admin. Следовательно имя машины ".".
Если это не так, то приведите учетку к виду ИмяМашины\Admin.
ТС надо в свойствах службы назначить учётную запись LOCAL_SYSTEM (либо отметить галочуой соответствующую учётную запись - от версии винды зависит), либо осознанно указать имя и пароль учётной записи, от которой должна работать служба SQLSERVER (SQLEXPRESS)
В терминах MSSQL "." озаначает локальный сервер. Насчет такого обозначения локальной учетной записи - в первый раз слышу. Более того, это не работает. Может есть пруфлинк?
При чём тут термины MSSQL, если речь идёт об авторизации заапуска службы.
Пруфлинк искать не буду, принтскрин бы показал да не хочу работодателя прогневать.
А если ТСу требуется из сиквела обращаться к сетевым ресурсам, то пусть указывает доменную учётную запись, либо локальную учётную запись, имеющую соответствующие разрешения на сетевых ресурсах, иначе получит ошибку 1005.
Вообще-то я прямо сейчас с этими вещами работаю и спорить не собираюсь. Пусть ТС попробует и напишет чем кончилось.
Воспроизводимый в каком виде? виртуалку сдампить? )
запись вида .\Имя делается для того, чтобы отличить
доменную учётку "имядомена\имя1" от локальной "мойкомпьютер\имя1", аналог этой записи ".\имя1"
Принтскрин ошибки позволяет предполодить, что на момент установки на машине ТС была локальная учётка Admin, и в процессе настройки этот админ решил стартовать службу сервера от себя, а потом админскую учётку заблокировал либо удалил либо пароль сменил.
В вашем случае надо положить шарик в дырочку слева от "встроенную учётную запись" и выбрать LOCAL_SYSTEM в вываливающемся списке, расположенном под указанной надписью.
Добавлено через 4 минуты
В журнале событий: "Служба "SQL Server (SQLEXPRESS)" завершена из-за внутренней ошибки 1814 (0x716). "
действие от пользователя Н/Д
хотя Запуск от Admin
Исправлено: ошибка входа в систему в сетевых подключениях в Windows 10
Любые быстрые исправления будут полезны!
Одной из проблем для нас был формат имени пользователя учетной записи, который мы изначально использовали
домен \ имя пользователя
и получил ошибку 1069-logon, затем я попытался проверить имя пользователя в свойствах | Вкладка входа в систему Службы (в Панели управления / Диспетчере служб), используя «Обзор» и «Поиск» для имени пользователя, и она оказалась предложенной и подтвержденной ОК с обратным форматом
имя пользователя @ домен
Это также сработало и разрешило ошибку 1069, и позволило нам создать сценарий запуска с помощью sc.exe.
- 1 Эй, Моска, ты точно понял первопричину, почему [email protected] принято и почему domain\username не принято?
- Я предполагаю, что служба не может узнать права пользователя за форматом "домен \ имя пользователя", и может с форматом @
- Откройте диспетчер служб. Если вы не знаете, сделайте это, нажав Win + R, затем введите services.msc
- Затем щелкните правой кнопкой мыши на SQL Server обработать и щелкнуть Свойства
Затем перейдите в Войти в систему, и выберите Этот аккаунт:
Затем нажмите Просматривать, и добавьте свое имя пользователя в поле. (Обратите внимание, что он должен содержать домен, в моем случае это AD \ myusername), Проверить имена и принимаю.
Наконец, введите свой пароль в два других поля, и все, у вас должно быть разрешение на запуск процесса.
Ошибка 1069 расплывчата и может иметь разные причины. Здесь я делюсь своим опытом.
Я столкнулся с этой ошибкой при попытке запустить службу под моей учетной записью (я пытаюсь заставить свои службы видеть тот же LocalDB, что и интерактивные процессы, запущенные в моей учетной записи в целях разработки). Я использую MSA (учетная запись Microsoft) с входом в систему с помощью PIN-кода Windows обычно, поэтому я редко ввожу свой пароль Windows. Чтобы решить эту проблему, я заблокировал экран, выбрал «Ввод пароля» вместо ввода PIN-кода, а затем ввел свой пароль. Я предполагаю, что это каким-то образом напомнило Windows мой пароль и сделало мою локальную учетную запись более законной.
- В Server 2016 Windows предложила сделать это за меня, когда я настроил службу для работы под этой учетной записью; однако этот ответ помог мне убедиться, что это так. Благодарность!
- У меня, вероятно, такая же проблема, но я не могу заставить ее работать, попробовал все, что вы сказали, Windows по-прежнему выдает мне ошибку 1069.
У нас также была эта проблема, потому что учетная запись была настроена так, что срок действия пароля истек. После того, как мы обновили учетную запись, чтобы срок ее действия не истек, и установили пароль, эта ошибка прекратилась.
- Да, у нас была проблема, связанная с паролем, когда пароль администратора домена был изменен, и служба была настроена специально для использования этой учетной записи. Служба работала нормально, пока через некоторое время сервер не был перезапущен.
также проверьте политику «Запретить вход в систему». пользователя не следует добавлять туда
При запуске службы SQL Server ошибку 1069, что приводит к сбою логотипа. В этой статье содержится разрешение событий, связанных с ошибкой 1069.
Оригинальная версия продукта: SQL Server
Исходный номер КБ: 282254
Симптомы
С помощью applet Services:
Windows не удалось запустить службу SQL Server на локальном компьютере.
Ошибка 1069. Служба не начала работу из-за сбоя логотипа.
С помощью командной подсказки:
Произошла ошибка системы 1069.
Служба не начала работу из-за сбоя логотипа.
Причина
Эта проблема возникает из-за проблемы с самой учетной записью службы или сведениями, сохраненными для учетной записи службы.
Решение
Разрешения для ИД событий 7041 и ID событий 7038 отличаются. Обратите внимание на ID события и описание события, связанного с сбоем в журнале событий системы. Затем используйте соответствующие сведения для устранения проблемы.
ID события: 7041
Ошибка logon: пользователю не был предоставлен запрашиваемого типа логотипа на этом компьютере.
Чтобы устранить эту проблему, проверьте, какие разрешения назначены учетной записи службы с помощью локальной Параметры безопасности (Secpol.msc).
Проверка этих прав в разрешениях сервера. Дополнительные сведения см. в Windows Privileges and Rights. Вручную назначьте недостающие разрешения.
Просмотрите учетную запись службы, чтобы узнать, назначены ли ему какие-либо разрешения На отказ* Удалите все разрешения Deny* из учетной записи SQL службы, а затем перепроверите. Например, если учетной записи службы был назначен логотип службы отказа вместе с ним, отзовите право на логотип и перезапустите SeDenyServiceLogonRight SeServiceLogonRight SeDenyServiceLogonRight SQL Server.
ID события: 7038
Этот пользователь не может войти, так как эта учетная запись в настоящее время отключена
Для устранения данной проблемы выполните следующие действия.
Если SQL Server учетной записью запуска является учетная запись локального пользователя на компьютере, откройте управление компьютером (compmgmt.msc) и убедитесь, что учетная запись службы отключена в локальных группах пользователей &. Если она отключена, включите учетную запись и перезапустите SQL Server службу.
Если SQL Server учетная запись запуска — это учетная запись Windows домена, проверьте, отключена ли учетная запись в active Directory Users and Computers. Если она отключена, включите учетную запись и перезапустите SQL Server службу.
Пароль пользователя необходимо изменить перед входом
Для устранения данной проблемы выполните следующие действия.
Если учетная запись SQL Server запуска — это учетная запись локального пользователя на компьютере, откройте управление компьютером (compmgmt.msc) и закройте пароль в следующем свойстве logon для SQL Server Startup Account в локальных группах пользователей &. Затем выберите ОК и перезапустите SQL Server службу.
Если учетная запись SQL Server запуска — это учетная запись Windows домена, откройте active Directory Users and Computers, а затем убедитесь, что в учетной записи SQL Server запуска пользователь должен изменить пароль при следующем включенном свойстве логотипа.
Если свойство на шаге 2 включено, необходимо либо очистить этот параметр, либо войти в интерактивный доступ к клиенту Windows, а затем установить новый пароль, а затем обновить новый пароль для службы SQL Server с помощью средства диспетчер конфигурации SQL Server.
Имя пользователя или пароль некорректно
Для устранения данной проблемы выполните следующие действия.
Если на шаге 1 сбой и сообщает ту же проблему, необходимо сбросить пароль для Windows логотипа. Если учетная запись SQL Server запуска — учетная запись локального пользователя на компьютере, откройте управление компьютером (compmgmt.msc) и сбросйте пароль локального пользователя. Если учетная запись SQL Server является учетной записью Windows домена, откройте active Directory Users and Computers, а затем измените учетные данные. После обновления учетных данных вернись в диспетчер конфигурации SQL Server, введите те же учетные данные и запустите службу.
Введите правильный пароль в учетной записи SQL Server службы на SQL Server хост-компьютере. Для этого выполните процедуры из служб SCM — измените пароль используемых учетных записей.
Эта учетная запись в настоящее время заблокирована и не может быть внесена в систему
Для устранения данной проблемы выполните следующие действия.
Если SQL Server учетная запись запуска — это учетная запись локального пользователя на компьютере, откройте управление компьютером (compmgmt.msc) и укройте учетную запись заблокирована для учетной записи SQL Server запуска в локальных группах пользователей &. Затем выберите ОК и перезапустите SQL Server службу.
Если SQL Server учетная запись запуска является учетной записью Windows домена, откройте active Directory Users and Computers и убедитесь, что SQL Server учетной записи запуска учетная запись заблокирована.
Если свойство на шаге 2 включено, необходимо очистить этот параметр, установить надежный пароль и использовать те же учетные данные для конфигурации SQL Server запуска с помощью диспетчер конфигурации SQL Server.
Не удалось запустить службу Агента Сервера 1С:Предприятия 8.3 на Локальный компьютер. Ошибка 2: Не удается найти указанный файл.
Описание ошибки:
Проблема возникла по факту, если кратко, после установки на сервере более нового релиза платформы 1С:Предприятие 8.3 и последующим его же удалением в ближайшее время.
По опыту практически очевидно, что проблема в настройке службы Агента сервера, т.е. скорее всего в том, что неверно указан файл запуска. Как и оказалось - в используемых файлах службы стоит путь к папке с релизом 8.3.12.1685, а установлен по факту только релиз 8.3.9.2033. Как уже было отмечено в кратком описании ошибки - это результат практически последовательной попытки установить релиз 8.3.12.1685, а после неудачной попытки - практически сразу его удаление. При этом ранее все работало на релизе 8.3.9.2033.
Очевиднее некуда, что в данном примере необходимо переуказать в настройке службы путь к каталогу релиза в 8.3.9.2033.
Для этого открываем редактор реестра. В моем случае для ОС Windows Server 2008 R2 Standart x64 путь до настроек службы оказался следующим: [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\1C:Enterprise 8.3 Server Agent (x86-64)\] (если у Вас другая ОС, то можете подсмотреть, где будет располагаться в редакторе реестра путь к настройке службы в статье, похожей по тематике - как найти ветку реестра для соответствующей версии Агента сервера 1С: Предприятие 8)
В строку свойства "ImagePath" изменяем в строке номер релиза на актуальный. Сохраняем. Пробуем запустить службу агента сервера. Должна запуститься.
Хотя проблема с запуском службы "Агент сервера 1С:Предприятие 8.3" была устранена но на этом проблемы после беглой неаккуратной установки/удаления более нового релиза платформы 1С 8.3 не закончились.
Если интересно то, как решалась последующая ошибка после устранения описанной проблемы в этой статье, то перейдите к публикации: "Ошибка при выполнении операции с информационной базой" при попытке запустить базу
Это руководство поможет вам диагностировать и устранить проблемы, связанные со сбоем, в консоли администрирования в 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. Data Protection Manager сборки.
Ошибка 917: подключение к службе DPM потеряно
Подключение к службе DPM потеряно.
Сведения о возможном завершении работы службы см. в журнале событий приложения.
Ниже приведен снимок экрана этой ошибки:
- DPM
- DPMRA
- агент SQL Server (для экземпляра DPM)
- SQL Server (для экземпляра DPM)
- Служба виртуальных дисков
- Служба теневого копирования томов
Если одна из служб не запущена, попробуйте запустить ее, а затем снова откройте консоль DPM.
Если службы запущены и проблема не устранена, проверьте, находится ли база данных в режиме восстановления.
Ошибка 1069: служба не запущена из-за сбоя входа в систему
Если у вас возникли проблемы с запуском одной из служб, связанных с DPM, это может быть вызвано учетной записью запуска от имени службы. Не удается запустить службу со следующей ошибкой:
Ошибка 1069: служба не запущена из-за сбоя входа в систему.
Ниже приведен пример снимка экрана ошибки:
Единственными службами, которые могут работать с учетной записью, отличной от SYSTEM, являются SQL Server учетные записи. Используйте следующую таблицу, чтобы проверить правильность учетных записей и наличие у них допустимых паролей.
Лучший способ изменить SQL Server учетных записей пользователей — использовать диспетчер конфигурации SQL Server интерфейса.
Имя службы | Учетная запись запуска от имени | Тип запуска. | Исследовать, не выполняется ли она? |
---|---|---|---|
MSDPM | SYSTEM | Manual | Да |
DPMRA | SYSTEM | Автоматически | Нет |
агент SQL Server (для экземпляра DPM) | Учетная запись домена (должна быть локальной администратором) | Автоматически | Да |
SQL Server (для экземпляра DPM) | Учетная запись домена (должна быть локальной администратором) | Автоматически | Да |
Служба виртуальных дисков | SYSTEM | Manual | Да |
Служба теневого копирования томов | SYSTEM | Manual | Да |
Диспетчер доступа DPM | SYSTEM | Автоматически | Да |
Координатор агента DPM | SYSTEM | Manual | Нет |
DPM CPWrapper | SYSTEM | Manual | Нет |
Модуль записи DPM | SYSTEM | Автоматически | Да |
DPMLA | SYSTEM | Manual | Нет |
Вспомогательная служба DPM VMM | SYSTEM | Manual | Нет |
Проверьте, находится ли база данных в режиме восстановления.
Если база данных находится в режиме восстановления, это может привести к проблемам, когда службы пытаются подключиться к ней. База данных переводит базу данных в режим восстановления из-за сбоя или сбоя DPMSync. Чтобы проверить, так ли это, выполните следующий SQL запрос к DPMDB:
Если возвращается PropertyValue значение 1, база данных находится в режиме восстановления.
Выполните следующий SQL, чтобы выведите базу данных из режима восстановления:
После завершения перезапустите службу DPM и повторите попытку в консоли.
Истекло время ожидания службы
Если учетные записи запуска от имени службы настроены правильно, может возникнуть проблема с временем ожидания службы. Если время ожидания службы истекло при попытке запуска, можно применить следующую запись реестра:
DWORD: ServicesPipeTimeout
Значение: 300000
Если запись не существует, ее можно создать. Значением является время ожидания в миллисекундах (мс), например 60 000 равно 1 минуте (60 секунд). Чтобы реализовать изменение, необходимо перезапустить службу. При необходимости измените значение.
Служба запускается, но затем завершается сбоем
Если служба запускается, а затем завершается сбоем, проверьте журнал событий приложения на наличие ошибки, указывающая, какая служба завершила работу сбоем. Проверьте наличие записей с ошибкой в качестве уровня и MSDPM (или любой другой службы DPM) в качестве источника во время сбоя. Вкладка " Общие" для события должна содержать сведения о службе, которая завершила сбой, и некоторые сведения о сбое.
Например, процесс MSDPM , который завершается сбоем с идентификатором события 999, содержит следующие сведения:
Не удается найти описание события с идентификатором 999 из исходного MSDPM. Либо компонент, вызывающий это событие, не установлен на локальном компьютере, либо установка повреждена. Вы можете установить или восстановить компонент на локальном компьютере.
Если событие возникло на другом компьютере, сведения об отображении должны были быть сохранены вместе с событием.
В событие были включены следующие сведения:
Непредвиденная ошибка вызвала сбой процесса msdpm. Перезапустите процесс DPM msdpm.
Ниже приведен снимок экрана этого события:
В этом примере в разделе "Сведения о проблеме" показано, что сбой с кодом ошибки 0x80004015 который сопоставляется с:
Класс настроен для запуска в качестве идентификатора безопасности, который отличается от вызывающего объекта.
Затем мы можем приступить к изучению проблемы в качестве проблемы с учетной записью пользователя. Так как служба MSDPM завершилась сбоем, следующим шагом является просмотр соответствующего журнала ошибок DPM. Расположение по умолчанию для этих журналов ошибок DPM похоже на C:\Program Files\Microsoft System Center 2012\DPM\DPM\Temp\ .
Журналы ошибок именуются для службы, в журнале и текущий файл журнала для каждой службы называется curr.errlog.
В случае сбоя службы система также создает файл аварийного завершения, аналогичный показанному ниже.
Событие сбоя записывается в самом конце файла и отображает дополнительные сведения.
При устранении неполадок с различными службами их причины и способы их устранения выходят за рамки этого руководства. Журналы событий, журналы ошибок и CRASH-файлы должны предоставить достаточно информации для устранения наиболее распространенных ошибок на форуме поддержки DPM.
Ошибка 948. Не удается подключиться к серверу DPM
Если службе не удается подключиться к базе данных DPM, она, скорее всего, не сможет запуститься. В этом случае вы увидите ошибки, аналогичные следующим:
Не удается подключиться к . (Идентификатор: 948)
Убедитесь, что служба DPM запущена на этом компьютере.
Раздел "Сведения о проблеме" в журнале событий должен содержать дополнительные сведения о характере сбоя. Обычно база данных находится в автономном режиме или недоступна для связи (скорее всего, она находится на удаленном сервере) или при входе в систему может возникнуть сбой. В таких сценариях в журнале событий, вероятно, возникнет ошибка, аналогичная одному из следующих примеров:
Ниже перечислены некоторые распространенные причины.
Сбой входа
Этот файл журнала ошибок должен содержать все неудачные записи аудита входа. Устраните эти ошибки, назначив разрешения учетной записи, указанной для базы данных, на которую имеется ссылка. Обычно это учетная запись SQL Server запуска от имени или учетная запись SYSTEM:
Для учетной записи SYSTEM можно добавить соответствующие разрешения в SQL Server Management Studio, перейдя в SecurityLogins > и щелкнув правой кнопкой мыши системную учетную запись. Убедитесь, что выбрана роль системного администратора, как показано ниже:
Для учетной SQL Server запуска от имени сбросьте учетную запись в диспетчер конфигурации SQL Server.
База данных или экземпляр находится в автономном режиме
Вы должны были проверить, запущена ли SQL Server на этом этапе. В противном случае проверьте его сейчас. После SQL Server службы попробуйте подключиться к экземпляру из SQL Server Management Studio (SSMS). Иногда это может завершиться ошибкой, если сервер выполнил вход с учетной записью, отличной от учетной записи, в которой он был установлен. В этом сценарии попробуйте выполнить SSMS от имени администратора. Если вы можете подключиться успешно, DPMDB будет подключен к сети. Если DPMDB находится в автономном режиме, он будет выглядеть следующим образом:
Если DPMDB находится в автономном режиме, щелкните DPMDB правой кнопкой мыши, выберите " Задачи", а затем выберите " Подключиться". После подключения к сети проверьте, устранена ли проблема.
Проблемы, связанные с сетью
Если вы видите ошибки, которые предлагают наличие проблемы, связанной с сетью, проверьте подключение к базе данных с сервера DPM, выполнив следующие действия:
Создайте UDL-файл. Самый простой способ — переименовать пустой .txt с расширением UDL.
Дважды щелкните UDL-файл и выберите экземпляр и базу данных для тестирования в раскрывающемся списке.
Щелкните "Проверить подключение".
Если это не удается, проверьте, можно ли проверить связь SQL Server с сервера DPM и убедиться, что разрешение имен работает правильно. Кроме того, убедитесь, что возвращен правильный IP-адрес. Убедитесь, что адрес также указан правильно на SQL Server > DPM. Проверьте другие очевидные причины, по которым трафик может не проходить, например брандмауэры.
Читайте также: