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

Любят наши люди стабильность. Даже когда не слишком получается. Вот очередной случай с форума 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», а также — ряда других событий,  в частности — сообщений о проблеме обработки групповой политики из-за невозможности найти контроллер домена. Читать далее

Web Application Proxy — товар скоропортящийся

У Web Application Proxy(WAP) в Widnows Server 2012 R2 есть нехорошая особенность: стоит серверу WAP постоять без дела (в выключенном состоянии или без связи с сервером AD Federation Services) пару недель — и он уже сам по себе не заработает. Симпотматика при этом наблюдается следующая: служба WAP не запускается, фиксируя в журнале событий System событие Event ID 7023 от источника Service Control Manager с ошибкой 401 (Unauthorized):
Читать далее

Публикация 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. Но это уже другая история.

 

Windows Server — не для бедных

Была у меня мечта — сделать отказоустойчивое решение для запуска виртуальных машин под Hyper-V в варианте «для бедных» — только на обычных компьютерах, без использования общей дисковой памяти. Виделись мне возможными два варианта реализации. Первый вариант — собрать кластер из трёх хостов Hyper-V с общей памятью в виде кластерного Storage Spaces с зеркалированием, состоящего из трёх iSCSI-дисков,  а диски iSCSI — подключить с target’ов, размещёнными на тех же самых хостах Hyper-V, разместив при этом отдаваемые виртуальные диски (VHD) на встроенных в хосты физических дисках. Второй вариант — поднять некластерную виртуальную машину на одном узле кластера Hyper-V (разместив её на встроенном физическом диске), настроить её репликацию на второй узел и организовать переключение при необходимости на реплику и обратно скриптом, выполняемым как Generic script role. И оба варианта не удалось реализовать из-за искусственных ограничений, введённых Microsoft при работе некоторых ролей сервера на узлах кластера.

Подробности неудач описаны ниже.

Читать далее

На изолированной от Интернет машине обновления лучше отключать явно.

Ставил сегодня по некоторой, совершенно не важной для дальнейшего рассказа, надобности  .NET 4.0 из полного пакета установки на изолированную от всяческих сетей свежую виртуальную машину (Win2K8 x86 SP2 ) на стенде. Хотя пакет и полный, и формально из интернета ему выкачивать ничего не надо — установить не получилось: установщик вернул код ошибки 0x8024402c. Этот код ошибки, как известно,  относится к службе автоматического обновления (Windows Update) и означает, что эта служба не смогла установить связь с сервером обновлений (центральным в Microsoft или местным WSUS). Это хорошо было видно и по журналу этой службы (%WinDir%\WindowsUpdate.log): да, пыталась, да получила ошибку таймаута.

Ну, почему получила ошибку — это очевидно: машина-то к интернету не подключена, совсем. Интереснее другое: зачем она вообще туда полезла и, главное, — как сделать, чтобы не лазила, причём второе важнее. Поэтому у меня возникла идея всё-таки слазить в настройки Windows Update и явным образом указать не проверять обновления.

Идея сработала — после отключения обновлений пакет .NET 4.0 установился без проблем.

Dynamic Access Control для Windows 7

В своих новых (некогда) ОС Windows 8 и Windows Server 2012 Microsoft реализовала ряд технологий, получивших общее маркетинговое название «динамическое управление доступом» (Dynamic Access Control, DAC). В частности, динамическое управление доступом включает в себя использование для авторизации доступа к файл-серверу не только SID учётных записей пользователей и групп безопасности, в которые эти записи входят, но и других атрибутов учётных  записей в каталоге Active Directory (таких, как принадлежность к определённому подразделению) через посредство утверждений (claims) о пользователе. Технологии эти, похоже, оказались интересными пользователям, но, к сожалению, Microsoft плохо озаботилась тем, чтобы подробно их документировать в Technet Library — ограничившись, по существу, лишь описанием типовых сценариев развёртывания. И теперь время от времени на различных форумах я натыкаюсь на вопрос, вынесенный в заголовок — можно ли использовать динамическое управление доступом для клиентов файл-сервера, работающих под управленем более ранних версий ОС Windows — такими, как Windows 7. Читать далее