Не пройдена проверка dfsrevent windows server 2019
Обновлено: 07.07.2024
Ребят, помогите не свихнуться..
Достался сервер (Windows Server 2008 r2), о котором до сегодняшнего момента особо не задумывались – работает, есть не просит и ладно. Сейчас контора реструктурируется и решили – раз уж приводить все в порядок, то и систему обновить нужно.
Цель себе поставил такую - создать новый сервер, ввести его в домен, перенести на него AD и DNS, все остальное создать по новой и в дальнейшем либо оставить его (переименовав) либо провести обратную процедуру.
Для страховки, решил провести процесс переезда КД на VMware..
И так, решил перенеси контроллер домена (DCSRV) на новый (DC01)..
Сделал все в простом порядке:
1. DCSRV – dcdiag /q - все было чисто.
2. DCSRV – adprep и т.п. выполнил
Установил новую 2008 r2 (DC01)..
3. DC01 – dcpromo.. (все ок)
Перезагрузился и понеслось..
4. DCSRV – dcdiag /q:
5. DC01 – dcdiag /q:
6. Repadmin /showreps – все успешно на обоих серверах
7. Так как роли не передавал и смену хозяина не проводил, то netdom query fsmo на обоих показывает одно и то же – хозяин DCSRV
8. На всякий – ipconfig /all с DCSRV:
9. ipconfig /all с DC01:
Уже были попытки в таком состоянии сменить хозяина и передать роли – еще больше проблем.. Пробовал отключать основной сервер и захватить роли на втором – совсем плачевно: в ошибках можно заблудиться..
Такое ощущение. что кто то (до меня), что то сделал с папками sysvol, netlogon на DCSRV и система их в принципе передать не может..
net shsre на DCSRV показывает:
Ради эксперимента попробовал создать политику (групповые политики не используются),– НЕ работает..
Перечитал кучу статей, способы восстановления папок с исправлениями в реестре рассматривал, но в статьях речь идет про репликацию через NtFrs, у меня она отключена и включена DFS. Да и веток в реестре указанных в статьях у меня на DCSRV нет…
Пытался поколдовать с ролью управления DFS – эффекта ноль.. Создал и расшарил папки на DC01 – ничего..
Уже на стену лезу от безысходности.. помогите..
Добавлено:
Путем дальнейших копаний, нашел:
В журнале репликации DFS - ошибка 6410
В интернете информации совсем никакой - такое ощущение, что мой случай первый!!
Может кто уже сталкивался с подобным?
Добавлено:
Путем дальнейших копаний, нашел:
В журнале репликации DFS - ошибка 6410
В интернете информации совсем никакой - такое ощущение, что мой случай первый!!
Может кто уже сталкивался с подобным?
Схема твоя интересная, но я иные действия запланировал:
является мучением для немалого количества народа. но 99,9% людей решивших свои проблемы благополучно сваливает не ответив, что ж им помогло..
Сетевые настройки контроллеров
C:\Windows\system32> ipconfig -all
Настройка протокола IP для Windows
Адаптер Ethernet Ethernet:
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
Физический адрес. . . . . . . . . : 00-15-5D-01-22-00
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
IPv4-адрес. . . . . . . . . . . . : 192.168.174.10(Основной)
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз. . . . . . . . . : 192.168.174.1
DNS-серверы. . . . . . . . . . . : 192.168.174.10
127.0.0.1
NetBios через TCP/IP. . . . . . . . : Включен
Настройка протокола IP для Windows
Адаптер Ethernet Ethernet:
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
Физический адрес. . . . . . . . . : 00-15-5D-00-85-00
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
IPv4-адрес. . . . . . . . . . . . : 192.168.174.11(Основной)
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз. . . . . . . . . : 192.168.174.1
DNS-серверы. . . . . . . . . . . : 192.168.174.11
127.0.0.1
NetBios через TCP/IP. . . . . . . . : Включен
. ну и надеюсь зона хранится в AD ? ;)
Да, конечно в AD
Спасибо за ответ!
dcdiag /q на DC1
dcdiag /q на DC2
При попытке понизить DC1
Message
-------
Сбой операции по следующей причине.
А сегодня уже восстановили DC2.
Message
-------
Сбой операции по следующей причине.
на DC1
на DC2
dcdiag /q
на DC1
на DC2
. и еще куча подобных ошибок
For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state
Интерпретация значений state:
0 = Uninitialized
1 = Initialized
2 = Initial Sync
3 = Auto Recovery
4 = Normal (если так, то все ОК)
5 = In Error
Так же специфика пока не позволяет перезагружать серверы и рабочие станции.
Пауза на 3-4 дня. Обязательно напишу.
Сетевые настройки контроллеров
repadmin /syncall
DC1
DC2
В этой статье предоставляется решение проблемы, из-за которой миграция SYSVOL DFSR не удается после обновления контроллера домена до Windows Server 2019.
Применяется к: Windows Server 2019
Исходный номер КБ: 4493934
Сводка
В домене, настроенном для использования службы репликации файлов, папка SYSVOL не передается после обновления контроллера домена на основе Windows Server 2019 из более ранней версии Windows. Пока этот каталог не будет общим, контроллер домена не отвечает на запросы DCLOCATOR для LDAP, Kerberos и других рабочих нагрузок DC.
Симптомы
В домене, использующем устаревшую службу репликации файлов для SYSVOL, на месте обновляется контроллер домена до Windows Server 2019.
При попытке переноса домена на репликацию распределенной файловой системы (DFS) возникают следующие проблемы:
Все контроллеры домена на Windows Server 2019 в домене перестают делиться папкой SYSVOL и перестать отвечать на запросы DCLOCATOR.
Все контроллеры домена на Windows Server 2019 в домене имеют следующие ошибки журнала событий:
Имя журнала: репликация DFS
Источник: DFSR
Дата: <time>
ID события: 8013
Категория задач: Нет
Уровень: ошибка
Ключевые слова: Классический
Пользователь: N/A
Компьютер: <fqdn>
Описание:
DFSR не удалось скопировать содержимое sYSVOL-содержимого, расположенного в C: \ Windows \ SYSVOL\domain, в папку SYSVOL_DFSR, расположенную в домене C: \ Windows \ \ SYSVOL_DFSR. Это может быть связано с недостаточной доступностью дискового пространства или нарушением общего доступа.Дополнительная информация:
Папка Sysvol NTFRS: C: \ Windows \ SYSVOL \
Папка Sysvol DFSR: C: \ Windows \ SYSVOL_DFSR \ домена
Ошибка: 367 (создание процесса заблокировано.)
Имя журнала: репликация DFS
Источник: DFSR
Дата: <DateTime>
ID события: 8028
Категория задач: Нет
Уровень: ошибка
Ключевые слова: Классический
Пользователь: N/A
Компьютер: <fqdn>
Описание:
Миграция DFSR не смогла перейти в состояние "PREPARED" для контроллера <computer name> домена. DFSR будет повторно повторить при следующем опросе Active Directory. Чтобы принудить к немедленному повторному выполнению, выполните команду "dfsrdiag/pollad".
Дополнительная информация:
Контроллер домена: <computer name>
Ошибка: 367 (создание процесса заблокировано.)
Команда создает следующий вывод для DFSRMIG.EXE /GetMigrationState всех контроллеров Windows Server 2019:
Dfsrmig /getmigrationstate
Следующие контроллеры домена не достигли глобального состояния ('Prepared'):Контроллер домена (локальное состояние миграции) — тип DC ======================================
<Computer name>('Start') - Writable DCМиграция еще не достигла согласованного состояния для всех контроллеров домена.
Сведения о состоянии могут быть устаревшими из-за задержки служб домена Active Directory.
Глобальное состояние может быть подготовлено, перенаправлено или устранено в зависимости от того, какое глобальное состояние вы задали ранее.
Причина
Служба репликации файлов (FRS) была обескровлена в Windows Server 2008 R2 и включена в более поздние выпуски операционной системы только для обратной совместимости. Начиная с Windows Server 2019, для продвижения новых контроллеров домена требуется репликация DFS (DFSR) для репликации содержимого в совместной службе SYSVOL. Если вы пытаетесь продвигать компьютер на Windows Server 2019 в домене, который по-прежнему использует FRS для репликации SYSVOL, возникает следующая ошибка:
Из-за дефекта кода обновление контроллера домена Windows Server 2012 R2 или Windows Server 2016 до Windows Server 2019 не обеспечивает выполнение этого блока. При переходе на DFSR все обновленные контроллеры DFSRMIG.EXE /SetGlobalState домена Windows Server 2019 застряли на этапе Реализации и не могут завершить переход на подготовленные или более поздние этапы. Поэтому папки SYSVOL и NETLOGON для контроллеров домена больше не являются общими, а контроллеры домена перестают отвечать на вопросы о расположении клиентов в домене.
Обходной путь
Существует несколько обходных способов решения этой проблемы, в зависимости от того, какое глобальное состояние миграции вы указали ранее.
Проблема возникает на этапе Подготовки или перенаправления
Если вы уже запускали DFRSMIG /SetGlobalState 1 или DFRSMIG /SetGlobalState 2 ранее, запустите следующую команду в качестве администратора домена:
Подождите, пока репликация Active Directory будет распространяться по всему домену, а также чтобы контроллеры домена Windows Server 2019 снова начали работу на этапе Начните.
Убедитесь, что SYSVOL является общим для этих контроллеров домена и что SYSVOL снова реплицируется как обычно с помощью FRS.
Убедитесь, что в этом домене Windows сервер 2008 R2, Windows Server 2012 R2 или Windows Server 2016 контроллер домена. Убедитесь, что все разделы Active Directory и файлы в SYSVOL полностью итдируется из одного или более контроллеров домена и что они реплицирует Active Directory в обычном режиме, прежде чем на следующем шаге понизить все контроллеры домена Windows Server 2019. Дополнительные сведения см. в дополнительных сведениях, связанных с устранением неполадок с репликацией Active Directory.
Понизить Windows контроллеры домена на основе Сервера 2019 до серверов-членов. Это временный шаг.
Перенос SYSVOL в DFSR обычно Windows сервер 2008 R2, Windows Server 2012 R2 и Windows Server 2016 контроллеры домена.
Продвижение серверов Windows Server 2019 в контроллеры домена.
Проблема возникает на этапе устранения
Этап ликвидации FRS не может быть откатан с помощью DFSRMIG. Если уже задана ликвидация FRS, можно использовать любой из следующих обходных пути.
Вариант 1
В этом домене по-прежнему Windows сервер 2008 R2, Windows Server 2012 R2 или Windows Server 2016 контроллеры домена. Убедитесь, что все разделы Active Directory и файлы в SYSVOL полностью итдируется из одного или более контроллеров домена и что они реплицирует Active Directory в обычном режиме, прежде чем на следующем шаге понизить все контроллеры домена Windows Server 2019. Дополнительные сведения см. в дополнительных сведениях, связанных с устранением неполадок с репликацией Active Directory.
- Понизить Windows контроллеры домена на основе Сервера 2019. Это временный шаг.
- Перенос SYSVOL в DFSR в обычном режиме на остальных контроллерах Windows Server 2008 R2, Windows Server 2012 R2 и Windows Server 2016 домена.
- Продвижение серверов Windows Server 2019 в контроллеры домена.
Вариант 2
Все контроллеры домена в домене работают Windows Server 2019.
- Шаг 6 этого обхода требует продвижения по крайней мере одного Windows Server 2008 R2, Windows Server 2012 R2 или Windows Server 2016 DC.
- При неправильном изменении реестра с использованием редактора реестра или другого способа могут случиться серьезные проблемы. Для решения этих проблем может потребоваться переустановка операционной системы. Компания Microsoft не может гарантировать, что эти проблемы могут быть решены. Вносите изменения в реестр на ваш страх и риск.
В ADSIEDIT. Средство MSC измените следующее отличительное значение имени и атрибут в PDC Emulator:
CN=DFSR-GlobalSettings, CN=System,DC= <domain> ,DC= <TLD> msDFSR-Flags = 0
Подождите, пока репликация Active Directory будет распространяться по всему домену.
На всех контроллерах Windows Server 2019 измените значение реестра типов DWORD Local State до 0:
- Параметр реестра: локальное состояние
- Путь реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating SysVols
- Значение реестра: 0
- Тип данных: REG_DWORD
На всех контроллерах Windows Server 2019 перезапустите следующие службы, запустив следующие команды:
Убедитесь, что SYSVOL имеет общий доступ к этим контроллерам домена и что SYSVOL снова реплицируется как обычно с помощью FRS.
Продвижение одного или более Windows 2008 R2, Windows Server 2012 R2 или Windows Server 2016 контроллеров домена в этом домене. Убедитесь, что все разделы Active Directory и файлы в SYSVOL полностью итдируется из одного или более контроллеров домена и что они реплицирует Active Directory в обычном режиме, прежде чем на следующем шаге понизить все контроллеры домена Windows Server 2019. Дополнительные сведения см. в дополнительных сведениях, связанных с устранением неполадок с репликацией Active Directory.
Понизить Windows контроллеры домена на основе Сервера 2019 до серверов-членов. Это временный шаг.
Перенос SYSVOL в DFSR в обычном режиме на остальных контроллерах Windows Server 2008 R2, Windows Server 2012 R2 и Windows Server 2016 домена.
Продвижение серверов Windows Server 2019 в контроллеры домена.
Необязательный вариант: понижение Windows 2008 R2, Windows Server 2012 R2 или Windows Server 2016 dc, добавленных на шаге 6.
Ссылки
Дополнительные сведения о переносе FRS в DFSR для SYSVOL см. в следующих статьях:
Если есть силы бежать – кто поверит, что нет сил драться?!
Ошибки при репликации между двумя КД
Windows 95, 98, ME и 3,11; WinNT, Win2000, WinXP, Win2003, Vista, 7Ошибки при репликации между двумя КД
В сети существовало два КД на Windows Server 2003.
Итак, я наконец то собрался с силами и, отбросив лень, сел плавненько переезжать на 2008 Server R2 с 2003 Server R2, где крутилась АД в режиме работы леса и домена 2003.
Выполнил adprep для леса и домена, все прошло успешно.
Взял один из этих двух КД и переставил на нем ОСь на Windows Server 2008 R2.
Добавил машинку в домен, поднял роль АД. ДНС добавился автоматически. Открываю AD, смотрю на данные - вроде бы все замечательно отреплицировалось, даные перенеслись, новый, только что установленный сервак отображается в списке Контроллеров Домена.
Однако, решил прочитать журнал DNS на всякий пожарный и хорошо, что прочитал:
Как же тогда я вижу данные в АД все? и в ДНС?
Брандмауэр на серваке отлючен, пользователь обладает правами администратора.
Может быть я неверно указал настройки для ДНСов? Сейчас схема такая.
КД1 (с которого надо все стянуть на 2008 R2):
Правда не понятен откуда взят адрес 172.17.1.3? И вообще все, что связано с АД. я поднимаю только после установки и настройки DNS.
Правда не понятен откуда взят адрес 172.17.1.3?
Хм. Как я только не пробовал выставлять айпишники, но так еще нет
Сделал так. Ошибки те же.
Отключил UAC, Брандмауэр отключил еще вчера. Антивирус/файрвол сторонний убил.
Проверил службу "Браузер Компьютеров" - была не запущена. Установил тип запуска - автоматом, саму службу запустил.
После всего этого ребутнул сервак. После ребута ошибки были те же. Открыл "AD - пользователи и компьютеры". Создал новую учетку. Кроме того изменил некоторые существующие записи - на КД1 изменения отобразились.
Запустил dcdiag на новом КД2, ниже привожу результат:
Дальше - больше. На КД1 dcdiag выплевывает исключительно ошибки репликации.
При этом оба сервака видят друг друга через nslookup.
Очень надеюсь на помощь.
А что у вас за сервер CORE это первое и второе на w2k3 все ли роли захвачены? Внимательнее просмотрите DNS, все записи, которые микрософтовские, т.е. зоны, начинающиеся с "_"и записи в них. ну и попробуйте снова зарегистрировать основной контроллер можно любым способом ipconfig /registersdns или перезапуском netlogon. snorlov писал(а): А что у вас за сервер CORE это первое и второе на w2k3 все ли роли захвачены? Внимательнее просмотрите DNS, все записи, которые микрософтовские, т.е. зоны, начинающиеся с "_"и записи в них. ну и попробуйте снова зарегистрировать основной контроллер можно любым способом ipconfig /registersdns или перезапуском netlogon.До этого было 2 КД, оба на w2k3. Один из них я понизил, переставил ОСь на 2008 Server и снова поднял АД, введя его в домен.
CORE - это старый КД на w2k3, все 5 ролей принадлежат ему.
NetLogOn перезапускал, эффект тот же. Сейчас попробую перезарегистрировать КД.
Имеет ли смысл переустановить службы AD на новом КД (W2K8)?
Еще в доке читал, что необходимо поднимать DNS !ДО! установки AD, если поднимается дополнительный КД. Однако, dcpromo выполнил сам эту функцию и установил ДНС вместе АД.
DNS у меня интегрирован в AD.
Блин, а роли то у кого остались, похоже, что у CORE, которого сейчас физически нет. Вот и стоит ругань. Этот CORE у вас наверное и в DNS'е имеется, вы сказали, что вы его не обновили, а переставили, так что у вас появился новый кд snorlov писал(а): Блин, а роли то у кого остались, похоже, что у CORE, которого сейчас физически нет. Вот и стоит ругань.Было два КД. Один Core с айпишником 192.168.0.1, второй URAN с айпишником 192.168.0.2.
Так вот, URAN я понизил до роли простого сервера. Все роли на себя принял CORE.
После этого URAN я вывел из домена и отключил физически.
Еще раз проверил роли на CORE - все ок. Запустил dcdiag и netdiag - все ок. Подготовил лес и домен для w2K8 через adprep.
Вычистил из АД всю информацию об URAN, - там еще сохранилась на тот момент запись типа А.
Взял старый КД - URAN - переустановил там ОС на СЕРВЕР 2008. Ввел в домен. Запустил DCPROMO. Все прошло успешно. Поставил галочку глобального каталога и вуаля! Получил два КД:
Первый кд - это старый CORE на w2k3
Новый кд - URAN на w2k8
Между ними не работает репликация.
Но, физически у меня ДВА КД.
проблемы в DNS'е, останавливайте dns на uran, убивайте все записи об uran на core, затем на uran прописывайте первым dns'ом dns на core, регистрируйте uran в dns'e на core через registersdns, снова винмательно смотрим записи об uran, гоняем тесты и лишь затем поднимаем dns на uran, можно сначала его поднять как slave. snorlov писал(а): проблемы в DNS'е, останавливайте dns на uran, убивайте все записи об uran на core.В смысле удалить саму службу DNS? Тогда же и АД придется затирать.
На CORE затирать записи в DNS, я так понимаю.
Еще дополнительную инфу кидаю, которую только что сделал.
Привожу ipconfig. Сначала с w2k3 - старый КД:
PID 1304 соответствует службе DNS. Больше PID'ов, слушающих 53 порт я не вижу.
registerdns провел, через 15 минут будет результат.
snorlov писал(а): проблемы в DNS'е, останавливайте dns на uran, убивайте все записи об uran на core. В смысле удалить саму службу DNS? Тогда же и АД придется затирать.На CORE затирать записи в DNS, я так понимаю. Кто тебе сказал такую ересь, что при удалении/остановке DNS удалиться АД, DNS для AD может быть и unix'совым, главное, что бы эта служба была доступна кд, ну и обладала некоторыми свойствами, одно из которых динамическое обновление зон. Большинство твоих проблем связано с тем, что ты понизил uran, а потом по существу его убил, но записи о нем в AD и DNS'е остались, и под тем же именем вы в AD втащили новый кд. Кстати обратная зона в DNS'е есть? Спрашиваю потому, что она нужна для работы, но автоматом она не создается.
Так, ДНС я удалил с URAN.
Теперь там есть только АД. На сетевых интерфейсах обоих КД указал в качестве праймари ДНС айпишник первого КД - CORE. Альтернативный ДНС сделал пустым.
При этом Active Directory сообщает о следующих ошибках:
1) Исходный КД функционирует
2) Через net view/ping/nslookup новый КД находит старый. URAN находит CORE и наоборот
3) dcdiag /test:dns на CORE выполняется с успехом
4) Аналогично.
5) С базой знаний знакомлюсь.
Вопрос. Что мне вычищать на CORE? Записи типа А и CNAME?
Все ссылки на uran и его ip, обратная зона (0.168.192.in.addr-arpa, на виндовом серваке через мастер вроде там надо писать 192.168.0. ) на core есть? если нет, добавить ручками, ОБЯЗАТЕЛЬНО snorlov писал(а): Все ссылки на uran и его ip, обратная зона (0.168.192.in.addr-arpa, на виндовом серваке через мастер вроде там надо писать 192.168.0. ) на core есть? если нет, добавить ручками, ОБЯЗАТЕЛЬНОИмена в айпишники и айпишники в имена разрешаются.
Попробовал выполнить репликацию через Active Directory - сайты и службы - выполнилась без ошибок.
Попробовал выполнить репликацию из cmd, через repadmin - тут получил ошибку:
что делать дальше? мне не нравится выполнение repadmin. mr. brightside писал(а): Попробовал выполнить репликацию из cmd, через repadmin - тут получил ошибку:
Я не понимаю, откуда вы сделали такой вывод?
Когда я понижал URAN, то все записи я вычищал и из АД и из ДНС. Вычищал как через оснастки, так и через консоли.
Но старый DSA - 9119974d-4c8a-412a-a0ad-86b357a72fc1 (CORE) - не менялся. Он как был, так и остался. Более того, за все время его работы я его не трогал ни разу.
По всему выходит, что именно запись старого КД - 9119974d-4c8a-412a-a0ad-86b357a72fc1 - и невозможно определить. Может быть, имеет смысл перекинуть роли на новый КД, перекинуть ДНС, переставить ОСь на стором КД ввести в домен и снова сделать КД? Тогда все должно грамотно перерегистрироваться?
Если честно, 1000 страниц читать просто лень Тем более, что я не виндовый админ, а юниксовый
Скажите, пожалуйста, просто, куда капнуть, а то ведь время, время.
в первом случае она идет от кд, где запускается, к его партнерам, а во втором от партнеров к нему.А все 1000 страниц и не надо читать, я просто в более доступном виде не видел описания утилит для работы с AD на русском языке. в первом случае она идет от кд, где запускается, к его партнерам, а во втором от партнеров к нему.
А все 1000 страниц и не надо читать, я просто в более доступном виде не видел описания утилит для работы с AD на русском языке.
Здесь запись 229137f9-6e82-4293-8ac-4e69d4a2c037, - она не встречается в DNS или AD у меня, а в логе есть.
Ошибка на НОВОМ КД - W2k8 в разделе "Служба каталогов":
Эта, вторая запись DSA - 9119974d-4c8a-412a-a0ad-86b357a72fc1 - записана в DNS и AD как имя CORE - старого КД.
По поводу repadmin сейчас отпишусь
P.S. большое спасибо за ответы!
P.P.S. Книжку уже скачал
Вроде бы, все замечательно.
Так, теперь, если я правильно понял, мне необходимо вычистить все записи на ДНСе относительно нового КД. Вопрос: какие именно записи? Абсолютно все?
- в зоне прямого просмотра "папку верхнего уровня" и запись А?
- в msdcs псевдоним?
- а также записи _kerberos, _kpasswd, _ldap и _gc в разделах dc/domains/gc/pdc?
И в зоне обратного просмотра айпишник/имя сервера?
Или достаточно удалить запись типа А и Псевдоним CNAME?
После удаление мне надо будет перерегистрироваться в ДНС и посмотреть, что будет, верно?
Я бы вычистил все записи и после этого дал команду регистрации в dns, ну а потом поднял бы DNS на новом кд.Ну хорошо, проделал
Удалил все SRV-записи, установил ДНС, теперь мне ситуация еще более не понятна.
Ошибки остались все те же самые. В лог они валятся ИСКЛЮЧИТЕЛЬНО при загрузке ОСи на новом КД.
В процессе работы, если новый КД не перезагружать, все работает замечательно. Работает репликация. Ниже привожу репликацию из консоли и dcdiag на новом КД после усановки ДНСа. Также хочу отметить, что репликация из оснастки тоже работает и ошибок не выдает.
Repadmin:
Может, как-нибудь заставить запускаться DNS и AD с задержкой? Скажем, секунд в 30 или 60, пока все фоновые службы не стартанут.
Да, внимательно посмотрел логи и соотнес их со временем загрузки сетевой карты
DNS и AD пытаются начать работу сразу, как начинает грузиться ОСь, а сетевая карта ТОЛЬКО когда происходит ЛОГОН, т.е. на 2 с лишним минуты позже, чем вышеупомянутые службы уже пытаются начать работу.
Можно ли как-нибудь заставить сетевушку работать уже на этапе биоса?
Intel 82574L и 82578DM
Или, может, не в сетевушках дело, а в ОСи? Может, настройка какая?
А вот это странно, поскольку такого не может быть, старт сетевых сервисов должен происходить после поднятия карточек, посмотрите зависимость старта сервисов. Из вашей фразы можно предположить, что в сервере 2-е карты, может вся сложность именно из наличия 2-х карт? snorlov писал(а): А вот это странно, поскольку такого не может быть, старт сетевых сервисов должен происходить после поднятия карточек, посмотрите зависимость старта сервисов. Из вашей фразы можно предположить, что в сервере 2-е карты, может вся сложность именно из наличия 2-х карт?В том то и дело, что такого не должно происходить.
Эти сетевые карточки идут вместе с какой то управляющей утилитой, которая загружается исключительно при логоне пользователя в систему/домен. До этого они мертвые и никакого коннекта по сети нет.
я проанализировал логи, сверял время запуска AD/DNS/RDP с моментом старта сетевушек.
Сеть поднималась только когда я залогинивался в домене. Это абсолютно неприемлемо даже с точки зрения возможного отключения электричества - вот вырубится свет, УПС продержит сервак, потом тот уйдет в офф. Boot on power есть, но если сервак загрузится, то еще необходимо залогиниться, чтобы он стал в сети доступен
Обидно, жалко и непонятно, но я просто вставил Realtek в сервак и все проблемы сразу решились. Те ошибки, которые постил ушли, остались предупреждения про сертификаты Kerberos (RDP) и SASL аутентификация (AD). Но, это меня уже почти не волнует.
Точно также не поленился и опробовал Acorp - грузится замечательно. Сетевая карта оживает сразу после загрузки биоса.
Читайте также: