Меню

Не удалось синхронизировать так как указанное имя является дубликатом



Если при синхронизации с компьютером выводится ошибка -54

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

При попытке синхронизации iPhone, iPad или iPod touch с компьютером может появляться следующее сообщение.

«Не удается синхронизировать iPhone [имя устройства]. Произошла неизвестная ошибка (-54)».

Это возможно, если файл на компьютере или устройстве iOS либо iPadOS заблокирован. Нажмите кнопку «ОК», чтобы продолжить синхронизацию.

Если содержимое не синхронизируется, выполните следующие действия.

  • Перезагрузите компьютер и устройство iOS или iPadOS.
  • При использовании iTunes в ОС macOS Mojave или более ранней версии либо на компьютере с Windows убедитесь в наличии последней версии iTunes и последних обновлений программного обеспечения для вашего устройства.

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

Объедините медиафайлы на компьютере

Медиафайлы в программе «Музыка» или медиатеке iTunes могут храниться в нескольких местах. Попробуйте объединить файлы в одну медиатеку.

Проверьте наличие проблем с программным обеспечением безопасности сторонних производителей

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

Синхронизируйте небольшой объем содержимого

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

Удалите содержимое и загрузите его повторно

Удалите содержимое и импортируйте его повторно

Если содержимое получено не из iTunes Store, удалите и повторно импортируйте его из первоначального источника.

Удалите файлы PDF из процесса синхронизации

Эта проблема может возникнуть при попытке перенести сделанные в iTunes покупки с устройства iOS или iPadOS на компьютер. Также это возможно при попытке синхронизации с Apple Books, так как при этом используется тот же самый процесс. В этом случае проблема может возникать с файлами PDF, сохраненными в программе «Книги» на устройстве iOS.

Чтобы устранить эту проблему, используйте команду «Поделиться» в программе «Книги» на устройстве, чтобы отправить файл PDF на свой адрес электронной почте. При этом копия файла PDF сохраняется в вашей учетной записи электронной почты и становится доступной для выбранных адресов электронной почты, доступ которым возможен с вашего компьютера. Затем удалите файл PDF с устройства.

Источник

Не работает синхронизация ЗУП 3.1 – БП 3.0. Что может проверить бухгалтер?

Обмен не проходит, документы не переносятся

1) Проверка соответствия релизов БП 3.0 и ЗУП 3.1

Частой причиной ошибок при обмене выступает разрыв между обновлениями конфигураций ЗУП 3.1 и БП 3.0.

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

2) Проверка корректности подключения

Заходим в раздел Администрирование – Синхронизация данных – Настройка синхронизации данных.

Встаем мышкой на нужный обмен — кнопка Настроить – кнопка Ещё – Настройки подключения:

В открывшемся окне производим проверку подключения по одноименной кнопке:

Данную проверку следует произвести как в ЗУП 3.1, так и в БП 3.0.

Распространенные ошибки подключения:

При подключении через сетевой каталог – разные папки для обмена в ЗУП 3.1 и БП 3.0 (в данном случае нужно проверить оба пути и указать верный); отсутствие доступа до папки (обратиться к системному администратору для настройки общего доступа);

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

Обмен проходит, документы не переносятся

Документы регистрируются к обмену в автоматическом режиме при добавлении, изменении. Бывают случаи, когда документ по какой-то причине не переносится.

1) Убедиться, что нужный документ по дате попадает в период, с которого начинается обмен данными:

Если необходимо, следует провести корректировку настроек обмена.

2) Проверить Предупреждения при обмене, раздел Непринятые по дате запрета:

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

3) Зарегистрировать документ к обмену вручную

Для этого необходимо перейти по кнопке Состав отправляемых данных, выбрать нужный вид документа, затем по кнопке Зарегистрировать или правой кнопкой мыши в соседней табличной части зарегистрировать нужный документ к обмену:

Затем следует повторить проведение обмена между конфигурациями.

Важно отметить, что сообщение «Не удалось синхронизировать данные» при обмене через каталог не всегда означает, что обмен не прошел.

Для анализа рекомендуем переходить по активной ссылке Журнал регистрации в полученном сообщении результата обмена:

Где мы увидим, что сообщение обмена было принято ранее, поэтому получать в ЗУП 3.1 из БП 3.0 было нечего.

Иными словами, файл с данными, который был отправлен конфигурацией БП 3.0 к запуску текущего обмена не обновлялся. Это означает, что данные из сообщения уже были загружены в ЗУП 3.1 ранее и повторно загрузка производиться не будет.

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

Статью подготовила старший консультант «ИнфоСофт» Анастасия Ткаченко

Источник

iPhone или iPad не синхронизируется с компьютером? Есть решение

Бывают случаи, когда iPhone или iPad не удается синхронизировать с iTunes, а также выполнить резервное копирование или восстановление устройства. Если вы столкнулись с подобной проблемой, может помочь сброс папки Lockdown на Mac или Windows. Сейчас расскажем, как это сделать.

Чтобы сбросить Lockdown на OS X, необходимо сперва отключить все iOS-устройства от компьютера и закрыть iTunes. Затем открыть Finder, зажать сочетание клавиш Shift+Cmd+G, ввести путь ниже и нажать Enter.

Выберите все файлы в этой папке и переместите их в корзину. В OS X удаляются файлы из Lockdown, но не сама папка.

На Windows все немного легче. Опять же отключаем все устройства на iOS, закрываем iTunes и нажимаем «Пуск». В поле поиска вводим команду ниже и нажимаем «Ввод».

Два раза щелкните по папке Apple, где удалите папку Lockdown. Учтите, что после этого необходимо перезагрузить и компьютер, и iOS-устройство, иначе впоследствии система может выдать ошибку.

Если у вас вдруг еще Windows XP, действия те же самые, только папку Apple нужно будет найти в Application Data. После этого устройство можно заново подключить к компьютеру и обязательно нажать «Доверять».

Новости, статьи и анонсы публикаций

Свободное общение и обсуждение материалов

Лонгриды для вас

Осенью 2019 года Apple представила iPhone 11 и собственный сервис с фильмами и сериалами Apple TV+. В качестве подарка компания предоставила год бесплатного …

Несмотря на то что мы уже достаточно давно живём в эпоху современных смартфонов, вокруг них до сих пор существует целая масса мифов. Поэтому многие искренне …

iOS при всей своей простоте и интуитивности на самом деле полна неочевидных функций и даже скрытых возможностей, обнаружить которые случайно оказывается прак…

Источник

Ошибка KCC ID 11 и дублированные SPN имена у CNF записей

Ошибка KCC ID 11 и дублированные SPN имена у CNF записей

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в России по системному администрированию Pyatilistnik.org. В прошлый раз мы с вами разобрали ситуацию, при которой у вас в системе отсутствовала библиотека vcruntime140.dll и из-за нее у вас не запускалась игра или программа. В сегодняшней публикации я хочу вам показать решение ошибки с кодом ошибки 11: The KDC encountered duplicate names while processing a Kerberos authentication request. Ее вы можете встретить на своих контроллерах домена.

Читайте также:  Assassins creed unity очки синхронизации турнир

Описание ошибки «The duplicate name»

Ранее я вам показывал на своем тестовом стенде установку Active Directory на сервера Windows Server 2019. Инфраструктура работает и живет своей жизнью, а это означает, что вы можете в процессе ее работы сталкиваться с различным букетом ошибок, вот вам свежие примеры:

Это вполне нормально, что появляются ошибки. Факторов, из-за которых так происходит очень много:

  • Проблема с сетью и связью
  • Проблемные обновления
  • Фаэрволы
  • Антивирусы
  • Сбои служб и многое другое

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

И так залез я как-то на один контроллер домена и обнаружил там в логах системы ошибки:

Данная ошибка у меня появлялась каждые 5-7 минут.

Причины появления ошибки с дублированием SPN

Service Principal Names (Имя участника службы (SPN)) — это уникальный идентификатор экземпляра службы. SPN-имена используются проверкой подлинности Kerberos для связи экземпляра службы с учетной записью службы. Это позволяет клиентскому приложению запрашивать, чтобы служба аутентифицировала учетную запись, даже если у клиента нет имени учетной записи.

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

Прежде чем служба проверки подлинности Kerberos сможет использовать имя участника-службы для проверки подлинности службы, имя участника-службы должно быть зарегистрировано на объекте учетной записи, который используется экземпляром службы для входа в систему. Данный SPN может быть зарегистрирован только на одном аккаунте. Для служб Win32 установщик службы указывает учетную запись для входа при установке экземпляра службы. Затем установщик создает имена участников-служб и записывает их как свойство объекта учетной записи в доменных службах Active Directory.

Если две или несколько учетных записей компьютеров имеют одно и то же зарегистрированное имя участника службы, то логично, что это ведет к некому конфликту. Для поиска дублированных SPN есть cmd утилита «setspn«. Откройте командную строку от имени администратора и введите команду:

Благодаря ключу -X вы получите дубли. Если вам необходимо произвести поиск дубликатов SPN в лесу, то добавьте ключ -F.

В результате чего я увидел свои дубли:

HOST/DC01.Pyatilistnik.org/PYATILISTNIK зарегистрирован на этих учетных записях:
CN=DC01,OU=Domain Controllers,DC=root,DC=pyatilistnik,DC=org
CN=DC01\0ACNF:ba395d9d-1193-4df4-bcea-860e94f52dec,OU=Domain Controllers, DC=root,DC=pyatilistnik,DC=org

HOST/DC01.Pyatilistnik.org зарегистрирован на этих учетных записях:
CN=DC01,OU=Domain Controllers,DC=root,DC=pyatilistnik,DC=org
CN=DC01\0ACNF:ba395d9d-1193-4df4-bcea-860e94f52dec,OU=Domain Controllers, DC=root,DC=pyatilistnik,DC=org

HOST/DC01/PYATILISTNIK зарегистрирован на этих учетных записях:
CN=DC01,OU=Domain Controllers,DC=root,DC=pyatilistnik,DC=org
CN=DC01\0ACNF:ba395d9d-1193-4df4-bcea-860e94f52dec,OU=Domain Controllers, DC=root,DC=pyatilistnik,DC=org

Оказалось, что у моего контроллера домена есть некий дубль в виде какого-то CNF объекта. Еще посмотреть дубли вы можете и старой командой ldifde:

Как удалить дублированный SPN

Избавиться от ошибки 11 весьма просто в большинстве случаев, но бывают и исключения, где приходится слегка больше времени. У утилиты etspn есть ключ -D.

setspn -D HOST/servername servername

setspn -D HOST/servername.xxx.organization.org servername

Либо вы можете зайти по пути, где хранится объект и открыть там редактор атрибутов, где в строке с атрибутом servicePrincipalName вы можете обнаружить все SPN и удалить нужный.

Разберем мой пример, где я должен найти объект CN=DC01\0ACNF:ba395d9d-1193-4df4-bcea-860e94f52dec по пути OU=Domain Controllers,DC=root,DC=pyatilistnik,DC=org, но могут быть ситуации, что вы не сможете его обнаружить, так как его могли удалить ранее.

Объекты CNF и RND

Когда создаются объекты в Active Directory, они получают относительное отличительное имя (RDN — Relative Distinguished Names), которое должно быть уникальным в родительском организационном подразделении (OU) или контейнере . Это обеспечивает уникальность атрибутов extevedName и canonicalName в лесу. Организационное подразделение или контейнер — это место, где новый объект будет находиться в Active Directory.

Объекты в AD однозначно идентифицируются по их отличительному имени (DN). DN формируется с использованием относительного различающегося имени (RDN, CN=имя_компьютера) плюс имена контейнеров (OU=someOUname) и домена (DC=your, DC=domain,DC=com), которые содержат объект. Если DN должен быть уникальным, то не может быть двух объектов, которые используют один и тот же RDN в одном и том же контейнере.

Если вы попытаетесь создать объект в Active Directory с RDN существующего объекта в том же подразделении, то вы получите сообщение об ошибке, например «Не удается создать новый объект-компьютер, поскольку пред-Windows 2000 имя уже используется Выберите другое имя и повторите попытку«. Если вы попытаетесь создать объект с уникальным RDN, но с именем sAMAccountName, совпадающим с именем существующего объекта в домене, вы получите то же сообщение об ошибке. Но как видите на картинке вы можете попадать в ситуации, при которых такие дубли RND будут созданы.

Ситуации при которых могут быть созданы дублирующие объекты CNF

Предположим ситуацию, что у меня мой тестовый домен root.pyatilistnik.org имеет несколько контроллер домена. Предположим, что есть два сотрудника тех поддержки и они решили выполнить эту задачу, и не знали, что делают ее параллельно. Каждый завел в AD компьютер с именем W10CL-TEST01, только проблема в том, что репликация в какой-то момент делалась с ошибками между разными контроллерами и получилось так, что защиты от дублей не произошло. И на каждом контроллере домена появился такой объект. Далее связь восстанавливается и что мы получим?

Когда атрибут модифицируется или создается, это изменение помечается отметкой об изменении. Метка изменения содержит номер версии, время последней записи и исходный сервер, это как в DNS. Когда контроллеры домена получают конфликтующие обновления, они проверяют метку изменения и принимают обновление с более высоким номером версии. Если номера версий совпадают, контроллеры домена проверяют время последней записи и принимают тот, который имеет более позднюю отметку времени. Последнее, что нужно решить, какое обновление принято, если номер версии и метки времени идентичны, — это глобальный уникальный идентификатор базы данных сервера (GUID). Изменение от сервера с более высоким GUID будет принято. Когда контроллеры домена добавляются в домен, эти идентификаторы GUID назначаются, и назначение является произвольным.

Но поскольку AD поддерживает репликацию объектов каталога с несколькими хозяевами между контроллерами домена в домене, изменяющими данные в одно и то же время (в одном и том же интервале репликации) на разных контроллерах домена, все же может иметь место два объекта с одинаковым именем (RDN) в одном контейнере (RDN). Скорее всего, это происходит при репликации между различными сайтами, когда интервал репликации по умолчанию составляет 180 минут или по меньшей мере 15 минут (если не настроен из реестра).

Когда два объекта создаются с одинаковым относительным отличительным именем (RDN) в одном и том же родительском подразделении или контейнере, конфликт распознается системой, когда один из новых объектов реплицируется на другой контроллер домена. Когда это происходит, один из объектов переименовывается.

DC автоматически изменит относительное различающееся имя объекта с более низким GUID на уникальное имя \0ACNF: . Объект с более высоким GUID сохраняется с оригинальным именем. Вот пример:

Это событие может быть зарегистрировано в журнале системных событий с идентификатором 12292 или в журнале Directory Service с идентификатором 1226.

Читайте также:  Самсунг не синхронизирует контакты с google

Объект:
DC=_kerberos._tcp.Root._sites,DC=root.pyatilistnik.org,CN=MicrosoftDNS, DC=DomainDnsZones,DC=root,DC=pyatilistnik,DC=org
GUID объекта:
4585391f-083c-4e35-ad9f-9b4cf72a6cc2
GUID существующего объекта:
c31f59df-4c64-42ae-9dd9-ed7ac89f884f

Объект со следующим GUID будет переименован, поскольку это имя уже принадлежит другому объекту.

GUID объекта:
c31f59df-4c64-42ae-9dd9-ed7ac89f884f
Имя переименованного объекта:
_kerberos._tcp.Root._sites
CNF:c31f59df-4c64-42ae-9dd9-ed7ac89f884f

Уникальное имя формируется с использованием GUID объекта. Формат для нового RDN: \0ACNF:

  • \0A — зарезервированный символ, представляющий символ завершения строки (перевод строки)
  • CNF (Conflict Name) — константа, указывающая конфликт
  • ObjectGUID — печатное представление значения атрибута objectGuid.

Когда вы пытаетесь переместить этот объект в AD, то вы не сможете это сделать, потому что синтаксис атрибута, указанный для службы каталогов, недопустим. Это вызвано тем зарезервированным символом, который не отображается в RDN или атрибутах имени, но может быть виден в атрибуте DN.

Указанные выше номера версий и временные метки являются значениями метаданных репликации, которые хранятся в атрибуте replPropertyMetaData объекта. Этот атрибут не реплицируется, поэтому значения различаются на каждом контроллере домена. Эти метаданные можно просмотреть с помощью утилиты командной строки repadmin.

Как видите, в моем примере у объектов разное время создания, и когда реплика появилась тот объект у которого значение CN меньше был переименован. Важным моментом является то, что один из объектов переименован, но sAMAccountName не изменяется. Результатом могут быть два объекта с одинаковым sAMAccountName в домене, по крайней мере, пока процесс, описанный в следующем разделе, не распознает дубликат. Конечно, один из объектов должен быть удален.

Как найти в CNF объекты

По мимо команды setspn вы можете найти все дублированные объекты RND через вот такую команду:

Еще можно воспользоваться LDAP запросами в ADUC. Выберите пользовательский поиск и на вкладке дополнительно введите:

В итоге получите список всех объектов CNF.

или еще можно воспользоваться конструкцией:

Что делать с CNF объектами

Хорошо, теперь мы знаем, как эти конфликты рождаются. Далее мы должны выяснить, как их решить. Вы не можете переименовать объект компьютера, используя Active Directory Users and Computers. Одним из способов является удаление объектов AD вручную, а также переименование и повторное подключение компьютеров к домену:

  1. Сначала вы должны узнать или сбросить пароль локального администратора, чтобы вы могли войти в систему, если что-то пойдет не так, и вы больше не сможете войти в систему с учетными записями домена.
  2. Войдите в систему как администратор, присоедините компьютер к рабочей группе, НЕ перезагружайте компьютер!
  3. Удалите конфликтующие объекты AD и подождите, пока это удаление будет реплицировано на все контроллеры домена в домене.
  4. Присоедините компьютер к домену и переместите новый объект AD в OU, где вы хотите, чтобы он находился, НЕ перезагружайте компьютер
  5. Теперь у вас есть возможность дождаться репликации вновь созданного (и перемещенного) объекта в домене.

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

Что такое lingering object liquidator

Так как у меня в AD уже нет такого объекта, то это остался мусор, который нужно удалять. lingering object liquidator — это устаревшие объекты — это объекты в AD, которые были созданы, реплицированы, удалены и затем собраны сборщиком мусора по крайней мере на контроллере домена, который инициировал удаление, но все еще существует как живые объекты на одном или нескольких контроллерах домена в том же лесу. Длительное удаление объектов традиционно требует длительных сессий очистки с использованием таких инструментов, как LDP или repadmin /removelingeringobjects

  • Устаревшие объекты могут привести к долгосрочному расхождению для объектов и атрибутов, находящихся на разных контроллерах домена в лесу Active Directory.
  • Наличие устаревших объектов предотвращает репликацию новых созданий, удалений и модификаций конечных контроллеров домена, настроенных для использования строгой согласованности репликации. Эти не реплицированные изменения могут применяться к объектам или атрибутам пользователей, компьютеров, групп, членства в группах или ACLS.
  • Объекты, преднамеренно удаленные администраторами или приложением, продолжают существовать в виде живых объектов на контроллерах домена, которым еще не удалось получить сведения о удалении для входящих репликаций.

Устаревшие объекты могут возникать, если контроллер домена не реплицируется в течение интервала времени, превышающего время жизни захоронения (tombstone lifetime-TSL). Затем контроллер домена повторно подключается к топологии репликации. Объекты, которые удаляются из службы каталогов Active Directory, когда контроллер домена отключен, могут оставаться на контроллере домена как устаревшие объекты.

Когда объект удаляется, Active Directory реплицирует удаление как объект-надгробие (tombstone). Объект-надгробие состоит из небольшого подмножества атрибутов удаленного объекта. Путем входящей репликации этого объекта другие контроллеры домена в домене и в лесу получают информацию об удалении. Tombstone хранится в Active Directory в течение определенного периода. Этот указанный период называется TSL. В конце TSL надгробный объект окончательно удаляется.

Значение TSL по умолчанию зависит от версии операционной системы, запущенной на первом контроллере домена, который установлен в лесу. Все, что выше Windows Server 2008 имеет значение 180 дней. Короче хорошего в этом мало и нужно это исправлять, так как эта запись будет теперь болтаться в корзине AD. Для удаления таких устаревших объектов есть две утилиты:

  • Repadmin /removelingeringobjects
  • Lingering Object Liquidator (LoL)

Если контроллер домена отключен на период, превышающий TSL, один или несколько объектов, удаленных из Active Directory на всех других контроллерах домена, могут остаться на отключенном контроллере домена. Такие объекты называются затяжными объектами (lingering objects). Поскольку контроллер домена находится в автономном режиме в течение времени, когда надгробный объект жив, контроллер домена никогда не получает репликацию tombstone.

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

  • Если на контроллере домена назначения включена согласованная строгая репликация, контроллер распознает, что он не может обновить объект. Контроллер локально останавливает входящую репликацию раздела каталога с исходного контроллера домена.
  • Если на контроллере домена назначения отключена согласованность строгой репликации, контроллер запрашивает полную копию обновленного объекта. В этом случае объект повторно вводится в каталог.

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

Допустим, у вас есть лес из нескольких доменов, и 100 пользователей были удалены из домена в России, в то время как DC в Доминикане был отключен от сети. Наконец, Доминиканский глобальный каталог возвращается в оперативный режим и начинает репликацию, но, поскольку он не реплицировал удаление тех 100 пользовательских объектов, которые теперь были удалены из Active Directory, он считает, что эти объекты должны быть реплицированы его партнерам. Так что теперь партнеры копируют объекты, и эти 100 учетных записей снова оживают — вроде как. Поскольку глобальный каталог Доминиканы содержит копию домена России, он реплицирует копии этих объектов.

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

  • Код события 1864 — Это событие будет указывать на наличие затяжных объектов. Обратите внимание, что он содержит подсчет количества DC, которые не реплицировались за день, неделю, месяц, два месяца или время жизни захоронения. Последняя запись важна. К сожалению, событие не сообщит нам имя контроллера домена, который не реплицировался за время существования захоронения.
  • Событие 2042 — событие указывает на то, что включена строгая репликация, исходный контроллер домена не реплицировался в в период tombstone и пытается реплицировать, поэтому репликация отключена из источника. Событие предоставляет GUID источника в формате записи DNS CName:982a942e-40e4-4e3c-8609-bae0cfd2affb._msdcs.pyatilistnik.org. Понятное имя контроллера домена можно легко найти, просмотрев записи псевдонимов в зоне _msdcs в оснастке DNS.
  • Событие 1388 — Другой контроллер домена (DC) попытался реплицировать этот объект, которого нет в локальной базе данных Active Directory. Возможно, объект был удален и уже был собран сборщиком мусора на этом контроллере домена. Эта система назначения получила обновление для объекта, который должен был присутствовать локально, но не присутствовал.
  • Событие 1988 — При репликации доменных служб Active Directory в следующем разделе обнаружены объекты, которые были удалены из базы данных доменных служб Active Directory контроллеров домена (DC). Это событие регистрируется, потому что исходный контроллер домена содержит устаревший объект, которого нет в локальной базе данных Active Directory контроллеров домена.
Читайте также:  Перенос профиля chrome на другой компьютер без синхронизации

Как удалить устаревшие объекты

Сначала я покажу встроенную утилиту repadmin. Первым делом вам нужно посмотреть наличие таких объектов, для этого используется ключ /advisory_mode. Конструкция будет выглядеть вот так:

  • — Полное доменное имя или GUID (Отличительное имя) контроллера домена, на котором есть устаревшие объекты, которых нет на других участниках репликации.
  • — GUID контроллера домена, который содержит актуальную копию базы Active Directory, чаще всего это главный контроллер домена.
  • — отличительное имя раздела каталога, в котором находятся устаревшие объекты. Проще всего указать корень домена.
  • /advisory_mode — это необязательный параметр, который выполняет поиск устаревших записей в режиме чтения, БЕЗ УДАЛЕНИЯ. Всегда старайтесь выполнить команду с параметром /advisory_mode, а уже потом без него.

Чтобы узнать GUID нужного контроллер введите команду:

Параметр /advisory_mode будет регистрировать на контроллере домена у которого есть объекты (Lingering Objects) события с кодом ID 1942. Данное событие укажет количество найденных и оставшихся объектов.

Исходный контроллер домена:
5fc9cc16-b994-426d-81c8-c9ff27f29976._msdcs.root.pyatilistnik.org
Количество проверенных устаревших объектов:

Объекты, которые были удалены и собраны в качестве мусора на исходном контроллере домена, но все еще существуют на данном контроллере домена, указаны в следующих записях журнала событий. Чтобы удалить устаревшие объекты без возможности восстановления, перезапустите эту процедуру без параметра проверки.

Когда вы обнаружили, что объекты «Lingering Objects» присутствуют, то вам необходимо из команды убрать параметр /advisory_mode. В результате чего устаревшие объекты с данного контроллера домена будут удалены. На контроллере будут события с кодом:

  • ID 1937 — указывает, что процесс удаления начался
  • ID 1945 — будет описан каждый удаляемый объект
  • ID 1939 — указывает, что процесс удаления завершен

Далее вам необходимо то же самое выполнить на других контроллерах домена, где есть устаревшие объекты. Проверяем репликацию.

Разрешить/запретить репликацию с серверами, которых давно не было в сети

Если вы хотите запретить репликацию с контроллерами домена которых давно не было в сети, то для этого есть 2 ключа в реестре. Их необходимо выставить на каждом из контроллеров домена, чтобы между ними проходила репликация. После успешной синхронизации/репликации и (желательно неоднократной) проверки того, что все работает. Откройте редактор реестра Windows и перейдите в раздел:

  • Strict Replication Consistency — Отключение строгой согласованности репликации, выставите для отключения значение «0»
  • Allow Replication With Divergent and Corrupt Partner — Включает репликацию с испорченными партнерами, если его нет, то создайте его, и выставите значение «1».

После запуска будет разрешена синхронизация между контроллерами домена. Чтобы проверить, что контроллеры синхронизираются, необходимо на одном из них открыть: «Active Directory Sites and Services» — Sites — Default-First-Site-Name — Servers и по очереди открываем КАЖДЫЙ контроллер домена, у него — NTDS Settings, после чего кликаем правой кнопкой по имени контроллера домена (внутри NTDS Settings) и выбираем «Реплицировать конфигурацию на выбранный контроллер домена». Все должно синхронизироваться.

Не забываем потом сменить значения «Strict Replication Consistency» на «1» и «Allow Replication With Divergent and Corrupt Partner» на «0».

Как удалить устаревшие объекты через Lingering Object Liquidator (LoL)

Microsoft имеет отдельную утилиту, которая призвана удалять устаревшие объекты, называется она «Lingering Object Liquidator (LoL)». Скачиваем утилиту по адресу:

Системные требования:

    1. У вас должен быть установлен NET 4.5.2 или выше, на том компьютере или сервере, где вы планируете запуск утилиты. Напоминаю вам инструкцию, как узнать текущую версию NetFramework.
    2. У учетной записи от имени которой вы будите запускать утилиту, должны быть права администратора домена, если доменов несколько то лучше воспользоваться правами администратора предприятия.
    3. Система из которой вы будите производить работы, должна иметь доступ на уровне сети и портов ко всем необходимым контроллерам домена. Конкретные порты включают DNS, Kerberos, RPC, LDAP и эфемерный диапазон портов, используемый целевым DC.
    4. Необходимо включить правило брандмауэра для службы «Удаленный вызов процедур (RPC)» на каждом контроллере домена, который будет сканироваться инструментом. В противном случае Lingering Object Liquidator выводит сообщение об ошибке «Исключение: сервер RPC недоступен».
    5. Удаление устаревших объектов в средах AD Lightweight Directory Services (AD LDS/ADAM) не поддерживается.
    6. Удаление устаревших объектов с помощью этого инструмента не поддерживается на контроллерах домена под управлением Windows Server 2003 R2 или более ранних версий (инструмент использует функцию подписки на журнал событий, которая не была добавлена ​​до Windows Server 2008).

Запустите инструмент от имени администратора домена (если вы хотите просканировать весь лес), если вы не запускаете инструмент с повышенными правами, возникает ошибка 8453. В LoL вам нужно выполнить три действия:

  • В Naming Context — Выберите в какой части вам необходимо искать устаревшие объекты
  • Reference DC — контроллер домена на котором нет объектов для удаления
  • Target DC — контроллер домена с которого будет удален устаревший объект

После заполнения данных вам нужно нажать на кнопку «Detect Lingering Objects«


Примечание. Журнал событий службы каталогов может полностью заполниться, если среда содержит большое количество устаревших объектов, а журнал событий служб каталогов использует максимальный размер журнала по умолчанию. Инструмент использует тот же метод обнаружения устаревших объектов, что и repadmin и repldiag, регистрируя одно событие для каждого найденного объекта.

Инструмент использует метод консультативного режима, предоставляемый DRSReplicaVerifyObjects, который используется как repadmin /removelingeringobjects /Advisory_Mode, так и repldiag /removelingeringobjects /advisorymode. В дополнение к обычным событиям, связанным с консультативным режимом, зарегистрированным на каждом контроллере домена, он отображает каждый из устаревших объектов в основной панели содержимого. Если нужно уже удалить объекты. то нажмите соответствующую кнопку «Remove Selected Lingering Objects».


На этом у меня все, мы научились удалять устаревшие SPN, устранять ошибку ID 11 и удалять CNF и RND объекты. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

Источник

Adblock
detector