Archive for the ‘ На форумах Technet ’ Category

О переименовании контроллера домена обратно

Любят наши люди стабильность. Даже когда не слишком получается. Вот очередной случай с форума Microsoft Technet. Жил в некой маленькой конторке домен (в смысле — единственный контроллер домена) с именем SERVER на Windows Server 2003. Жил — не тужил, но вот настало время ему апгрейдиться. То ли потому что Windows Server 2003 уже давно как производителем с поддержки снята, то ли ещё по какой причине — это мне неведомо.
Админ тамошний, не долго думая, поднял второй контроллер — DC2 — на новой современной(почти) Windows 2012, а старый контроллер понизил. Затем, ради этой самой стабильности — чтобы не утруждать себя перенастройкой приложений — дал админ новому контроллеру IP старого и переименовал его в старое имя — SERVER — через свойства системы. И тут что-то пошло не так: сначала при переименовании Windows сообщила, что такое имя уже существует, а после перезагрузки стал недоступным домен, не получилось открыть консоль «AD Users and Computers»… Ну, такой факт, что резервной копии, чтобы вернуть всё взад, у этого админа не было, даже и упоминать не стоит: так всегда бывает в подобных случаях у подобных админов. Короче — печаль.
Читать далее

Новые возможности — новые проблемы: разрешение имён в Windows

Не секрет, что с течением времени появлением новых версий Windows расширяются возможности настройки подсистемы разрешения имён(resolver) в этой ОС. Становится возможным штатным образом делать такие вещи, которые раньше требовали хитрой настройки, если вообще были возможны. Но эти новые возможности несут в себе и потенциал новых проблем, вызванных неправильной их настройкой. И проблемы эти не так то просто обнаружить традиционными инструментами, к которым администраторы привыкли за долгие годы работы. Недавно я как раз занимался обсуждением на русском форуме Technet темы, которая служит хорошей иллюстрацией такого положения дел.

Дело обстояло следующим образом. У автора темы внезапно сервер-член домена (под управлением Windows Server 2012 R2) перестал находить контроллер домена через DNS. В журнале событий при этом имелась соответствующая случаю диагностика в виде довольно часто возникающих предупреждений с Event ID 1014 и источником Microsoft Windows DNS Client: «Разрешение имен для имени _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs… истекло после отсутствия ответа от настроенных серверов DNS», а также — ряда других событий,  в частности — сообщений о проблеме обработки групповой политики из-за невозможности найти контроллер домена. Читать далее

Публикация Sharepoint на нестандартном порту.

Сегодня встретил на форуме Techent cообщение с такой вот проблемой, касающейся публикации Sharepoint (для справки: автор заменил в URL реальное имя своего домена на слово domen):

Добрый день. Проблема с публикацией SP в интернет.
Задал адрес в альтернативном доступе для Интернет указал как http://sp.domen.ru
На шлюзе (Kerio Control) опубликовал по порту 8855 натом на внутренний адрес и порт 80.
При заходе спрашивает логин-пароль, а далее дико дико тупит. Через раз вываливается в 504 тайм аут. Это если заходить на адрес http://sp.domen.ru:8855/sites/sitename
через раз показывает в итоге сам сайт кое как подгружая страницу, но работать на сайте не получается, ибо как сказал выше постоянно 504 gateway time out.
Что ему нужно? )

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

sharepoint-publication

Конечно, предпочтительным вариантом показать сопоставления было получить выдачу команды Get-SPAlternateURL в Powershell (с текстом работать удобнее), но для понимания, кто виноват и что делать, этой картинки достаточно.
На картинке мы видим, что для зоны Интернет назначено единственное (создаваемое по умолчанию) сопоставление внешнего имени (http://sp.domen.ru:8855) самого на себя. Но так как у автора вопроса в реальности подключение на порт 8855 на шлюзе перенаправляется на порт 80 сервера Sharepoint, а не 8855, то это сопоставление не работает. Поэтому подключение извне воспринимается как относящееся к зоне По умолчанию, и в страницах ответа возвращаются URL, соответствующие зоне По умолчанию, но не зоне Интернет.
Чтобы сопоставление заработало, нужно добавить правильный внутренний URL (по которому перенаправляется запрос на шлюзе) в список внутренних URL для зоны Интернет.

Для этого на странице, скриншот который приведен выше, надо перейти по ссылке «Добавить внутренние URL-адреса».  На открывшейся странице в строке ввода «Добавить внутренний URL» следует написать для нашего случая http://sp.domen.ru. А в общем случае там нужно указать URL с именем хоста из внешнего имени (в нашем случае это sp.domen.ru), но с портом внутреннего сервера, на который реально перенаправляются внешние запросы (в нашем случае это — порт HTTP по умолчанию). А в  списке зон  ниже на этой странице нужно выбрать зону Интернет.
При такой настройке Sharepoint будет (в нашем случае) понимать, что если он получил запрос на 80-й порт с именем хоста sp.domen.ru (это имя передаётся в заголовке запроса HTTP), то все URL ссылок в ответе (на картинки, на ссылки для перехода и пр.) должны начинаться с внешнего URL зоны для внешнего доступа — http://sp.domen.ru:8855

После такой настройки публикация Sharepoint ожидаемо заработала.

PS Как сообщил автор, в данном случае публикация была чисто с целью протестировать саму возможность публикации. Ну, а для работы, конечно, в целях безопасности публиковать Sharepoint нужно исключительно по протоколу HTTPS. Но это уже другая история.

 

Чистьте Active Directory!

Я уже писал ранее о том, как не удалённый вовремя из Active Directory  вышедший из строя контроллер домена может мешать её работе. И вот, форумы русского Technet принесли ещё один пример того, как не вычищенные вовремя из Active Directory следы «мёртового» контроллера домена могут мешать нормальному функционированию. Автор вопроса на форумах наткнулся на ситуацию, когда он не может добавить в домен новую рабочую станцию. При этом, в журнале событий фиксировалось событие с кодом 16651 от источника Microsoft-Windows-Directory-Services-SAM , говорящее об исчерпании пула относительных идентификаторов (RID) и о проблеме получения нового пула. Однако, автор вопроса уверял, что контроллер — владелец роли RID Master работоспособен. Дополнительный опрос и диагностика показали следующую картину: у автора вопроса физически был ровно один контроллер домена, который являлся владельцем всех ролей FSMO, но в базе данных Active Directory остались записи для другого, неработоспособного контроллера домена, и тесты dcdiag сообщали о совершенно естественных проблемах репликации с этим, физически отсутствующим контроллером. И именно это послужило источником проблемы. Дело в том, что владелец роли FSMO (при настройках по умолчанию) после запуска не начинает функционировать в качестве такового до тех пор, пока он не проведёт начальную синхронизацию раздела каталога, с которым связана соответствующая роль FSMO, с каким-либо другим контроллером домена, на котором есть копия этого раздела. Сделано это из соображений безопасности — чтобы случайно включенный в сеть бывший владелец роли, у которого роль была принудительно изъята и передана другому контроллеру, не нарушил функционирование Active Directory. Поэтому у автора, хотя роль RID master и была перенесена на функционирующий контроллер, этот контроллер не начал выполнять функции RID master, потому что не мог провести начальную синхронизацию, о необходимости которой говорило наличие в AD другого контроллера домена. После удаления из AD записей о неработоспособном контроллере, когда  необходимость в начальной синхронизации отпала, проблема была решена — новый пул RID был получен и рабочая станция была успешно добавлена. Мораль всей этой истории такова — не оставляйте в AD следы вывденных из эксплуатации контроллеров доменов: они могут помешать работе.