Ошибка: Вход в систему не произведен: конечная учетная запись указана неверно
При выделении одной подсети (основной домен) в другой поддомен (новый домен) в этом же лесу произошла странная ошибка. Пользователи из основного домена не видят на сервере нового домена общие папки. Компьютеры с Windows XP ничего не сообщают, а просто показывают пустое содержимое общих папок. А по «net view \\dcgs») получаю «Ошибка 5. Отказано в доступе».
А Windows Server 2008 и другие более поздние операционные системы конкретно сообщают об ошибке:
Шаг 1. Клиент
Шаг 2. Клиент
Иногда, после проделанных действий ошибка может снова появится. Причина может быть в DNS-суффиксах подключения: В данном примере сперва использовался другой DNS-сервер домена k43.guap.ru, а не текущего домена gs.k43.guap.ru. Машина находится в двух доменах, и выполнен вход под пользователем из другого домена. Так или иначе это приводится к «неправильному» порядку DNS-суффиксов.
В настройках сетевого адаптера, в настройках протокола Интернета (TCP-IP), на вкладке «Общие» нажимаем кнопку «Дополнительно» и указываем нужный порядок DNS-суффиксов:
После этого проверяем правильность разрешения:
Шаг 3. DNS-сервер
На DNS-сервере следует проверить интерфейсы по которым прослушивают клиентов:
Поскольку в DNS создаются записи типа A для интерфейсов отмеченных галочками, то теоретически может возникнуть следующая ситуация. Пусть DNS-сервер прослушивает по двум адресам: 192.168.200.1 и 169.254.0.17. Когда клиент разрешает имя сервера в IP-адрес, то ему может попасться любой адрес из указанных. Если настройками брандмауэра стоит разрешение на подключение к 192.168.200.1, а на остальное запрет, то при получении адреса 169.254.0.17 клиент не сможет подключиться к DNS-серверу. Или если второй адрес использовался как RAS-подключение (суть модемное соединение), но при обрыве связи этот адрес более не доступен, но клиент его закешировал, то снова возникнет проблема подключения.
Шаг 4. DNS-сервер
Теперь все сведения об устаревших записях выбудут удалены автоматически.
Windows 7 вход в систему не произведен конечная учетная запись указана неверно
Вход в систему не произведен: конечная учетная запись указана неверно.
Однажды на работе произошла «жопа». После установки новых компьютеров в учебный отдел, вбивания их в домен, прописывания принтеров при обращении некоторых компов к сети вылетала ошибка «Вход в систему не произведен: конечная учетная запись указана неверно.» (Картинки кликабельны).
Поначалу я думаю проблемы с доменом или настройками. На всех 5 машинах перевбил в домен, с нуля настроил всю сеть, но проблема не прошла. И именно на тех двух злосчастных компах.
Я сразу заметил, что при обращении по IP адресу к машине все прекрасно работало.
А при обращении по NETBIOS и DNS имени к компу выскакивала такая ошибка.
Поначалу я не прохавал в чем проблема. Полез в инет покопался по форумам, как всегда, ничего не нашел, но наткнулся на пару путевых постов. Ребята говорили, что им помогла переустановка DNS сервера на контроллере домена, меня такая перспектива не радовала. Поэтому приключения я продолжил в одиночестве.
Поскольку проблема возникала именно при обращении к DNS серверу, начал копать его.
В nslookup начал пробивать эти имена и тут смотрю, что-то не то. Адреса не те, что у компов. В общем DNS сервер хранил не те записи о компьютерах. Короче имя компа не соответствовало DNS имени в сети.
Полезли в домен. А тут раз и адреса не совпадают. Сразу вспомнил, что по адресам 192.168.0.61 у меня был Учебный отдел. А поскольку к нам добавилась еще одна кафедра и в это же время в Учебный отдел привезли компы, я решил навести порядок в распределении IP адресов, которое красиво смотрится у нас в серверной на сетке.
DNS сервер за 2 суток не обновился и хранил старые записи. Поэтому набирая
я обращался не к компу по адресу 192.168.0.61, а к компу на новой кафедре. Отсюда и ошибка с именем пользователя.
Решается проблема 2 кликами.
В настройках нашего DNS сервера dnsmgtm.msc Открывает меню. GATEWAY (У нас так сервер называется). Меню Properties (Настройки). Там находим вкладку Advanced (Дополнительно) и включаем очистку устаревших записей DNS сервера. «Enable automatic scavenging of state records». Я поставил раз в сутки. И проблема решена. Если сразу не решится, то просто удаляем записи о глючных компах из DNS оснастки. Они сами появятся заново, при перезагрузке тех рабочих машин.
Комментарии
Комментарий от Настя [ 6 апреля, 2012, 08:36 ]
Благодарю автора за идею. Очень полезная информация. Удачи, и новых отличных идей
Комментарий от Татарин [ 7 сентября, 2012, 14:48 ]
Большое спасибо была таже проблема не печатал принтер перенастроил обращение с имён на ip адреса теперь всё супер))))
Комментарий от Михаил [ 27 ноября, 2012, 14:14 ]
Комментарий от yurvasya [ 11 февраля, 2013, 15:14 ]
Комментарий от Игорь [ 21 февраля, 2013, 09:57 ]
Вот спасибо так спасибо! Тоже голову ломали сегодня 🙂
Комментарий от Akill [ 7 ноября, 2013, 03:31 ]
Где тут лайк оставить?
Комментарий от Евгений [ 7 марта, 2014, 10:38 ]
Комментарий от Андрей [ 19 июня, 2014, 16:10 ]
Наконец-то наткнулся на толковое решение, а то везде какую-то билиберду пишут и просят логи с найстроками сети 🙂 Спасибо!
Комментарий от Леонид [ 13 августа, 2014, 14:11 ]
А мне не помагло :(( Галочку потавил, по ИП обращение проходит, а по имени нет. Nslookup возвращает все корректно.
Спасибо! Всё логично, но всего знать невозможно… СПАСИБО!
Устранение ошибки Windows «не удается войти в учетную запись»
Проблемы, связанные с повреждением профиля пользователя, являются одними из самых распространенных, обычно они сопровождаются сообщениями «Не удается войти в учетную запись» и «Вы вошли в систему с временным профилем». Поэтому сегодня мы решили рассказать, как устроен профиль пользователя, что может привести к его повреждению и какими методами можно восстановить нормальную работу системы.
Начнем с симптомов, первым признаком того, что что-то пошло не так служит надпись Подготовка Windows на экране приветствия, вместо Добро пожаловать.
Затем вас «порадует» сообщение «Не удается войти в учетную запись» с вариантами повторного входа и продолжения работы.
Если закрыть данное окно, то мы увидим еще одно сообщение, немного проливающее свет на происходящее «Вы вошли в систему с временным профилем».
Если профиль временный, то получается, что по какой-то причине постоянный профиль пользователя загрузить не получилось. Поэтому не будем пороть горячку, а постараемся разобраться, что такое профиль пользователя, какие данные он содержит и что может быть причиной невозможности его загрузки.
Это вполне удобно и оправданно, с учетом того, сколько всего пользователи держат на рабочих столах, а те же SSD далеко не резиновые. Но речь не об этом, гораздо интереснее то, что скрыто от глаз простого пользователя.
Папка AppData предназначена для хранения настроек и пользовательских данных установленных программ и в свою очередь содержит еще три папки: Local, LocalLow и Roaming.
Рассмотрим их подробнее:
А теперь самое время подумать, повреждение каких из указанных данных может привести к проблемам с загрузкой профиля? Пожалуй, что никаких. Следовательно в профиле должно быть что-то еще. Конечно оно есть, и если внимательно посмотреть на скриншот профиля пользователя выше, то мы увидим там файл NTUSER.DAT. Если включить отображение защищенных системных файлов, то мы увидим целый набор файлов с аналогичными именами.
Вот мы и подобрались к сути. В файле NTUSER.DAT находится ветвь реестра HKEY_ CURRENT_USER для каждого пользователя. И именно повреждение ветви реестра делает невозможным загрузку профиля пользователя. Но не все так плохо, как может показаться на первый взгляд. Реестр достаточно хорошо защищен от возможных сбоев.
Файлы ntuser.dat.LOG содержат журнал изменений реестра с момента последней удачной загрузки, что делает возможным откатиться назад в случае возникновения каких-либо проблем. Файлы с расширением regtrans-ms являются журналом транзакций, что позволяет поддерживать ветку реестра в непротиворечивом виде в случае внезапного прекращения работы во время внесения изменений в реестр. В этом случае все незавершенные транзакции будут автоматически откачены.
Таким образом, выяснив из чего состоит профиль пользователя и повреждение какой именно его части делает невозможным загрузку, рассмотрим способы восстановления системы.
Способ 1. Устранение проблемы в профиле пользователя
Прежде всего, при возникновении проблем со входом в учетную запись следует проверить на ошибки системный том, для этого загрузитесь в консоль восстановления или среду Windows PE и выполните команду:
В некоторых случаях этого может оказаться достаточно, но мы будем рассматривать худший вариант. Проверив диск загрузимся в систему и откроем редактор реестра, перейдем в ветку
Слева увидим некоторое количество разделов с именем типа S-1-5 и длинным «хвостом», которые соответствуют профилям пользователей. Для того чтобы определить какой профиль принадлежит какому пользователю обратите внимание на ключ ProfileImagePath справа:
Итак, нужный профиль найден, теперь снова смотрим в дерево слева, в котором должны находиться две ветки, одна из которых с окончанием bak.
Теперь наша задача переименовать основной профиль в bak, а bak в основной. Для этого добавляем к основному профилю любое расширение, скажем .ba, затем переименовываем резервный профиль в основной, убрав из его имени .bak, и снова переименовываем ba в bak.
Кстати, могут быть ситуации, когда для вашей учетной записи существует только ветка bak, в этом случае просто уберите ее расширение.
Затем находим в новом основном профиле два ключа RefCount и State и устанавливаем значения обоих в нуль.
Перезагружаемся. В большинстве случаев, если профиль серьезно не поврежден, данные действия приведут к успеху, в противном случае переходим к способу 2.
Способ 2. Создание нового профиля и копирование туда пользовательских данных
Поэтому мы рекомендуем иной способ. Снова открываем редактор реестра переходим в
и удаляем все ветви, относящиеся к вашему профилю. Перезагружаемся.
После этого Windows создаст для вашей учетной записи новый профиль, как будто бы первый раз вошли в данную систему. Но ваш идентификатор безопасности (SID), при этом останется неизменным, вы снова окажетесь владельцем всех собственных объектов, сертификатов и т.д., и т.п.
По окончании процесса копирования снова входим в свою учетную запись и проверяем работу аккаунта. Все данные и настройки должны снова оказаться на своих местах. Однако не спешите удалять старую папку и дополнительную учетную запись, возможно некоторые данные потребуется перенести еще раз. Это может быть связано с тем, что некоторые программы, хранящие настройки в поврежденной ветви реестра могут решить, что выполнена новая установка и перезаписать перенесенные файлы, в этом случае достаточно выборочно скопировать необходимые данные.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Зашел на сервера, в евентах куча ошибок и в логах бесперибойника зафиксированно несколько перепадов напряжения и полные отключения серверов (в щадящем режиме) из-за оотсутствия света. Как раз обилие ошибок, наблюдается после последнего выключения серверов.
Пока из манипуляций: перезагрузил сервера, воткнул роутер на раздачу адресов, собрал логи и сам пытаюсь разобраться.
Тип события: Ошибка Источник события: Userenv Категория события: Отсутствует Код события: 1053 Дата: 08.06.2012 Время: 12:00:39 Пользователь: NT AUTHORITY\SYSTEM Компьютер: BACKUP-SRV Описание: Не удалось определить имя пользователя или компьютера. (Главное конечное имя неверно. ). Обработка групповой политики прекращена.
Дополнительные сведения можно найти в центре справки и поддержки, в «http://go.microsoft.com/fwlink/events.asp». __________________________
Тип события: Ошибка Источник события: Userenv Категория события: Отсутствует Код события: 1030 Дата: 08.06.2012 Время: 9:32:46 Пользователь: UFOPRIM\Администратор Компьютер: BACKUP-SRV Описание: Не удалось запросить данный список объектов групповой политики. Проверьте в журнале событий наличие сообщений, описывающих причины сбоя.
Дополнительные сведения можно найти в центре справки и поддержки, в «http://go.microsoft.com/fwlink/events.asp». ___________________________
Дополнительные сведения можно найти в центре справки и поддержки, в «http://go.microsoft.com/fwlink/events.asp». _______________________________
Тип события: Ошибка Источник события: Kerberos Категория события: Отсутствует Код события: 4 Дата: 06.06.2012 Время: 13:46:17 Пользователь: Н/Д Компьютер: BACKUP-SRV Описание: Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера host/backup-srv.ufoprim.local. Использовавшееся конечное имя: LDAP/backup-srv.ufoprim.local/ufoprim.local@UFOPRIM.LOCAL. Это значит, что пароль, который был использован для шифрования билета службы Kerberos, отличается от пароля на конечном сервере. Обычно это происходит, если в конечной сфере (UFOPRIM.LOCAL) и в сфере клиента имеются учетные записи компьютеров с одинаковыми именами. Обратитесь к системному администратору.
Дополнительные сведения можно найти в центре справки и поддержки, в «http://go.microsoft.com/fwlink/events.asp». _______________________________ Тип события: Ошибка Источник события: DhcpServer Категория события: Отсутствует Код события: 1059 Дата: 06.06.2012 Время: 12:11:48 Пользователь: Н/Д Компьютер: BACKUP-SRV Описание: Служба DHCP не смогла обнаружить папку для авторизации сервера.
Раздел каталога: DC=ForestDnsZones,DC=ufoprim,DC=local
Локальный контроллер домена давно не получал данные репликации с нескольких контроллеров домена. Далее приведено количество контроллеров домена с разделением по интервалам.
Более 24 часов: 1 Более недели: 1 Более месяца: 1 Более двух месяцев: 1 Более времени жизни захоронения: 0 Время жизни захоронения (в днях): 60 Возможно, контроллеры домена не выполняют репликацию вовремя из-за ошибок. Возможно, они пропустили смену пароля и не могут пройти проверку подлинности. Возможно, контроллер домена, не выполнивший репликацию в течение времени жизни захоронения, пропустил удаление некоторых объектов и был автоматически заблокирован до согласования.
Чтобы идентифицировать контроллеры домена по именам, установите средства поддержки с установочного компакт-диска и запустите программу dcdiag.exe. Также можно использовать средство поддержки repadmin.exe для отображения задержек репликации контроллеров домена в лесе. Команда: «repadmin /showvector /latency
Дополнительные сведения можно найти в центре справки и поддержки, в «http://go.microsoft.com/fwlink/events.asp». ______________________________________
Тип события: Ошибка Источник события: DNS Категория события: Отсутствует Код события: 4000 Дата: 08.06.2012 Время: 17:37:06 Пользователь: Н/Д Компьютер: BACKUP-SRV Описание: DNS-серверу не удалось открыть Active Directory. Без этого он не сможет загружать зону. Данный DNS-сервер настроен для получения и использования информация из каталога для этой зоны. Проверьте, что Active Directory функционирует нормально и перезагрузите зону. Данные события содержат код ошибки.
Дополнительные сведения можно найти в центре справки и поддержки, в «http://go.microsoft.com/fwlink/events.asp». Данные: 0000: 2a 23 00 00 *#..
Тип события: Ошибка Источник события: Userenv Категория события: Отсутствует Код события: 1054 Дата: 07.06.2012 Время: 17:14:39 Пользователь: NT AUTHORITY\SYSTEM Компьютер: DC-SRV Описание: Не удалось получить имя контроллера домена в этой сети. (Указанный домен не существует или к нему невозможно подключиться. ). Обработка групповой политики прекращена.
Дополнительные сведения можно найти в центре справки и поддержки, в «http://go.microsoft.com/fwlink/events.asp». _____________________________
Тип события: Ошибка Источник события: DhcpServer Категория события: Отсутствует Код события: 1046 Дата: 07.06.2012 Время: 18:36:51 Пользователь: Н/Д Компьютер: DC-SRV Описание: Служба DHCP/BINL на локальном компьютере, входящем в административный домен Windows «ufoprim.local», определила, что она не авторизована для запуска. Обслуживание клиентов остановлено. Возможными причинами могли стать: Эта машина является частью предприятия службы каталогов и авторизована в том же домене. (Для получения дополнительной информации обратитесь к справке по программе «Управление службой DHCP»).
Эта машина не может обнаружить предприятие службы каталогов и она обнаружила службу DHCP на другой машине в сети, принадлежащей предприятию службы каталогов, в котором этот компьютер не может авторизоваться.
Произошли непредвиденные ошибки сети.
Тип события: Ошибка Источник события: NTDS General Категория события: Глобальный каталог Код события: 1126 Дата: 08.06.2012 Время: 10:12:47 Пользователь: NT AUTHORITY\АНОНИМНЫЙ ВХОД Компьютер: DC-SRV Описание: Active Directory не удается подключиться к глобальному каталогу.
Дополнительные данные Значение ошибки: 1355 Указанный домен не существует или к нему невозможно подключиться. Внутренний ID: 3200cf3
Действие пользователя: Убедитесь, что глобальный каталог находится в лесу и доступен для контроллера домена. Для диагностики можно использовать программу NLTEST.
Дополнительные сведения можно найти в центре справки и поддержки, в «http://go.microsoft.com/fwlink/events.asp». ________________________________________
Тип события: Ошибка Источник события: NTDS Replication Категория события: Репликация Код события: 1864 Дата: 08.06.2012 Время: 9:47:17 Пользователь: NT AUTHORITY\АНОНИМНЫЙ ВХОД Компьютер: DC-SRV Описание: Состояние репликации для следующего раздела каталога на локальном контроллере домена.
Раздел каталога: DC=ufoprim,DC=local
Локальный контроллер домена давно не получал данные репликации с нескольких контроллеров домена. Далее приведено количество контроллеров домена с разделением по интервалам.
Более 24 часов: 1 Более недели: 1 Более месяца: 1 Более двух месяцев: 1 Более времени жизни захоронения: 1 Время жизни захоронения (в днях): 60 Возможно, контроллеры домена не выполняют репликацию вовремя из-за ошибок. Возможно, они пропустили смену пароля и не могут пройти проверку подлинности. Возможно, контроллер домена, не выполнивший репликацию в течение времени жизни захоронения, пропустил удаление некоторых объектов и был автоматически заблокирован до согласования.
Чтобы идентифицировать контроллеры домена по именам, установите средства поддержки с установочного компакт-диска и запустите программу dcdiag.exe. Также можно использовать средство поддержки repadmin.exe для отображения задержек репликации контроллеров домена в лесе. Команда: «repadmin /showvector /latency
Дополнительные сведения можно найти в центре справки и поддержки, в «http://go.microsoft.com/fwlink/events.asp». _____________________________________
Последние бэкапы (Acronis) есть с давностью от полутора месяца. Почему-то есть желание восстановить работоспособность не используя их.
На форуме ни одна подобная тема и я их тоже читаю.
Тогда зачем было создавать новую, а не спросить в уже имеющейся?
———- Заслуженный SCOтовод, почетный SUNтехник и любитель Кошек
Всего записей: 16953 | Зарегистр. 13-06-2007 | Отправлено:14:10 08-06-2012
S_H_V_E_D
Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Потому что на данном этапе мне сложно сравнивать свою ситуацию с уже обсуждаемыми, и ответов в них я не нашел. Вместо критики или посоветуй что-то, если компетентен, или проигнорируй
Всего записей: 257 | Зарегистр. 08-07-2005 | Отправлено:15:15 08-06-2012
ipmanyak
Platinum Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Vlary прав, зачем плодить темы, можно было задать вопрос в той ветке. Ваша проблема пережевана тысячекратно на всех форумах, в том числе и на этом.
Цитата:
backup-srv
Цитата:
NETLOGON Service is paused on [DC-SRV] . DC-SRV failed test Services
Разберись с этим, служба должна быть запущена. Серверы по командам
Net Stop Netlogon Ipconfig /flushdns Net Start Netlogon Ipconfig /registerdns
На BACKUP-SRV DNS-сервер запущен, но с АД зона не загружена На DC-SRV DNS-сервер запущен, зона отображается, записи устаревшие, но обратил внимание, что некоторые прописанные мной позавчера статические адреса для ПК отображаются, однако после подключения в сеть роутера и назначении других динамических адресов, все осталось попрежнему (адреса не соответствуют).
Как сделать чтоб работало?
Цитата:
Разберись с этим, служба должна быть запущена. Серверы по командам
Net Stop Netlogon Ipconfig /flushdns Net Start Netlogon Ipconfig /registerdns
должны обновить свои записи в DNS
Записи обновились и служба снова ушла в паузу.
Я так понимаю, что занимаемся исправлением DC-SRV т.к. он Owner и на нем есть что-то работающее от DNS, и при его работе, пользователи хоть как-то авторизуются, правильно я рассуждаю?
На DC-SRV из ошибок:
Вот это нужно решать в первую очередь? Только с чего начать чтобы не сделать хуже?
Блиин Чувак =) СПАСИБО. У меня наметился прогресс, благодаря тебе.
То ли через командную строку служба «Сетевой вход в сестему» не запускалась, то ли я чего натыкал копаясь на support.microsoft.com (на момент написания поста, кроме руборда была открыта http://support.microsoft.com/kb/839880). Но дело в том, что попытался еще раз проделать предложенный тобой вариант, только уже останавливая и запуская службу через диспетчер. И о чудо, уже какое-то время, служба работает, ошибка
исчезла, я попробовал зарегистрировать в домене комп указав принудительно в настройках сети DNS сервер (192.168.1.1) и все получилось.
Осталось разгрести другие ошибки, если они конечно сами не пройдут =)
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Блиииин поторопился радоваться, попробовал другой ПК ввести в домен и снова неудача.
После того как утром удалось запустить»Сетевой вход в систему», появились только такие штуки
Тип события: Ошибка Источник события: NETLOGON Категория события: Отсутствует Код события: 5722 Дата: 09.06.2012 Время: 14:46:52 Пользователь: Н/Д Компьютер: DC-SRV Описание: При установке сеанса с компьютера PC не получено подтверждение имен. В базе данных безопасности содержатся ссылки на учетные записи PC$. Ошибка: Отказано в доступе.
Дополнительные сведения можно найти в центре справки и поддержки, в «http://go.microsoft.com/fwlink/events.asp».
Тип события: Предупреждение Источник события: NtFrs Категория события: Отсутствует Код события: 13508 Дата: 08.06.2012 Время: 20:42:03 Пользователь: Н/Д Компьютер: DC-SRV Описание: Служба репликации файлов столкнулась с проблемами при включении репликации с «BACKUP-SRV» на «DC-SRV» для «c:\windows\sysvol\domain», использующего DNS-имя «backup-srv.ufoprim.local». Служба репликации файлов (FRS) продолжит повторные попытки. Ниже указаны причины, по которым может выдаваться это предупреждение.
[1] FRS не может разрешить DNS-имя «backup-srv.ufoprim.local» с этого компьютера. [2] FRS не запущена на «backup-srv.ufoprim.local». [3] Сведения в Active Directory о топологии для этой реплики реплицированы еще не на все контроллеры домена.
Это сообщение об ошибке записывается в журнал для каждого подключения один раз. После исправления ошибки в журнал будет записано другое сообщение, означающее, что соединение установлено.
_______________________________ Тип события: Предупреждение Источник события: W32Time Категория события: Отсутствует Код события: 22 Дата: 09.06.2012 Время: 15:42:29 Пользователь: Н/Д Компьютер: DC-SRV Описание: The NTP-сервер поставщика времени обнаружил ошибку при выполнении цифровой подписи NTP-ответа для 192.168.1.11:123. NTP-сервер не удалось предоставить клиенту безопасное (подписанное) время, запрос пропущен. Ошибка: Пользователь с указанным именем не существует. (0x80070525)
Дополнительные сведения можно найти в центре справки и поддержки, в «http://go.microsoft.com/fwlink/events.asp».
В dc-SRV получил ошибки, что нельзя реплицировать, т.к. последняя репликация была более 60 дней назад.
Как восстановить работу контроллера на backup-srv, или можно пересоздать его заного?
Отключил репликацию, регистрирую ПК в домене на клиентских ПК пишет
Имя журнала: System Источник: Microsoft-Windows-GroupPolicy Дата: 13.06.2012 16:35:48 Код события: 1058 Категория задачи:Отсутствует Уровень: Ошибка Ключевые слова: Пользователь: система Компьютер: SHITOVA-NEW.ufoprim.local Описание: Ошибка при обработке групповой политики. Попытка чтения файла «\\ufoprim.local\sysvol\ufoprim.local\Policies\<31B2F340-016D-11D2-945F-00C04FB984F9>\gpt.ini» с контроллера домена была неудачной. Параметры групповой политики не могут быть применены, пока не будет исправлена эта ситуация. Это может быть временным явлением, его возможные причины: a) Ошибка разрешения имен или проблемы сетевого подключения к текущему контроллеру домена. b) Запаздывание репликации Active Directory (созданный на другом контроллере домена файл еще не реплицирован на текущий контроллер домена). c) Отключен клиент распределенной файловой системы (DFS). Xml события:
1058 0 2 0 1 0x8000000000000000
1919
System SHITOVA-NEW.ufoprim.local
4 816 1 47252 3 Системе не удается найти указанный путь. \\dc-srv.ufoprim.local CN=<31B2F340-016D-11D2-945F-00C04FB984F9>,CN=Policies,CN=System,DC=ufoprim,DC=local \\ufoprim.local\sysvol\ufoprim.local\Policies\<31B2F340-016D-11D2-945F-00C04FB984F9>\gpt.ini
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Ошибки 1058 и 1030 это кажись обычная рассинхронизация. Все 5 ролей DC на dc-srv? Если да и неохота пробовать запустить в ручном режиме синхронизацию, то смотри в сторону dcpromo /forceremoval на backup-srv. А потом опять его в домен загонишь. Кстати там еще понадобится делать metadata cleanup через оснастку ntdsutil. PS. Vlary прав лучше посмотри в профильной теме там наверняка есть такие же ситуации (сам проходил в 2006 году).
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Такое бывает когда коннект плохой ИМХО
Добавлено: Такое бывает когда коннект плохой ИМХО
Всего записей: 512 | Зарегистр. 24-02-2009 | Отправлено:15:37 14-06-2012
anjunabeatc
Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору anjunabeatc Бэкапы есть, не хочу их трогать пока, хочу без них вопрос решить, благо время позволяет, опыт будет полезен. На работу пользователей мои манипуляции сказываются не сильно, можно сказать вообще не сказываются. Но вчера уже принял более координальные меры, принудительно удалил AD, DNS с BACKUP-SRV. Переименовал BACKUP-SRV в BACKUP-SERV (и сменил ip), снова ввел в домен, перенастроил в путях для резервирования одну букву.
Хозяином всех операций является DC-SRV, он работает исправно. После удаления BACKUP-SRV, все манипуляции с AD (регистрация ПК, заведение пользователей и т.д.) работают прекрасно.
Сейчас вопрос стоит о настройке дополнительного контроллера на базе BACKUP-SERV.
На данный момент удалил все записи о BACKUP-SRV из DNS и AD, ошибок со вчерашнего дня не было. Из WARNING на DC-SRV сейчас:
Цитата:
[WARNING] The DNS entries for this DC cannot be verified right now on DNS server 192.168.1.37, ERROR_TIMEOUT
Alienrus Где же ты раньше был =) я именно такие действия и сделал, только сделал бы их раньше если бы ты раньше написал. Всеравно спасибо большое.
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Чтобы почистить хвосты на dc-srv (упоминание про backup-srv) нужно запустить ntdsutil и там провести metadata cleanup. Ссылка на доку support.microsoft.com/KB/216498. В твоем случае нужно читать про первый метод.
Проблемы, связанные с повреждением профиля пользователя, являются одними из самых распространенных, обычно они сопровождаются сообщениями «Не удается войти в учетную запись» и «Вы вошли в систему с временным профилем». Поэтому сегодня мы решили рассказать, как устроен профиль пользователя, что может привести к его повреждению и какими методами можно восстановить нормальную работу системы.
Затем вас «порадует» сообщение «Не удается войти в учетную запись» с вариантами повторного входа и продолжения работы.
Если закрыть данное окно, то мы увидим еще одно сообщение, немного проливающее свет на происходящее «Вы вошли в систему с временным профилем».
Если профиль временный, то получается, что по какой-то причине постоянный профиль пользователя загрузить не получилось. Поэтому не будем пороть горячку, а постараемся разобраться, что такое профиль пользователя, какие данные он содержит и что может быть причиной невозможности его загрузки.
Это вполне удобно и оправданно, с учетом того, сколько всего пользователи держат на рабочих столах, а те же SSD далеко не резиновые. Но речь не об этом, гораздо интереснее то, что скрыто от глаз простого пользователя.
Рассмотрим их подробнее:
Вот мы и подобрались к сути. В файле NTUSER.DAT находится ветвь реестра HKEY_ CURRENT_USER для каждого пользователя. И именно повреждение ветви реестра делает невозможным загрузку профиля пользователя. Но не все так плохо, как может показаться на первый взгляд. Реестр достаточно хорошо защищен от возможных сбоев.
Итак, нужный профиль найден, теперь снова смотрим в дерево слева, в котором должны находиться две ветки, одна из которых с окончанием bak.
Теперь наша задача переименовать основной профиль в bak, а bak в основной. Для этого добавляем к основному профилю любое расширение, скажем .ba, затем переименовываем резервный профиль в основной, убрав из его имени .bak, и снова переименовываем ba в bak.
Перезагружаемся. В большинстве случаев, если профиль серьезно не поврежден, данные действия приведут к успеху, в противном случае переходим к способу 2.
