Блог IT-KB - Страница 81 из 84 - Собрание заметок об информационных технологиях

Exchange Server 2007 How-to: Настройка анонимной ретрансляции почты

08.10.2010 Автор:Алексей Максимов
6 519 Просмотров 1 Комментарий
Иногда для некоторых «не очень продвинутых» приложений типа всякого рода АРМ и т.п. требуется возможность анонимной отправки почты наружу с использованием протокола SMTP.

По умолчанию такого рода ретрансляция почты в Exchange 2007 не работает. Можно включить анонимную ретрансляцию почты в Exchange 2007 для определенного хоста следующим образом:
- Создать Receive Connector с типом использования Custom;
- Добавить группы разрешений «Анонимные» для созданного Receive Connector;
- Назначить разрешения на ретрансляцию участнику безопасности «Анонимный вход» для созданного Receive Connector
Открываем консоль Exchange Management Console:

Переходим в Server Configuration > Hub Transport > Выбираем сервер HT > Receive Connectors
Выбираем пункт меню Actions – New Receive Connector

В открывшемся мастере создания нового коннектора указываем его имя и выбираем тип Custom

Далее указываем FQDN имя нашего HT-Сервера для которого мы создаем этот коннектор и номер порта. По умолчанию используется 25 порт, но мы при желании можем задать другой номер порта, при этом не стоит забывать, что если мы используем для SMTP подключений NLB кластер, то в нём должна быть включена поддержка соответствующего порта.

Далее мы указываем IP адрес хоста (или нескольких хостов) для которого мы хотим разрешить анонимную ретрансляцию почты. Значение по умолчанию 0.0.0.0-255.255.255.255 нужно удалить.

Далее, когда уже коннектор создан, открываем его свойства и если у нас нет необходимости (или нет возможности) в использовании TLS – на закладке Authentication отключаем его.

На закладке Permission Groups включаем опцию для анонимных пользователей.

Затем открываем Exchange Management Shell и выполняем командлет на нашем HT-сервере:

Get-ReceiveConnector "ARM Anonymous Mail Relay" | Add-ADPermission -User "NT AUTHORITYANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"

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

Источник
Exchange Server TechCenter - How to Allow Anonymous Relay on a Receive Connector
SCOM 2007 R2 - Мониторинг серверов вне домена

03.10.2010 Автор:Алексей Максимов
9 171 Просмотров 10 комментариев
Для мониторинга серверов вне домена (рабочие группы или недоверенный домен) архитектура SCOM, в качестве использования основного метода, предполагает использование дополнительной роли - Gateway Server. Подход с развертыванием дополнительного сервера SCOM с ролью Gateway Server имеет смысл в том случае, если количество подключаемых к системе мониторинга объектов велико, и Gateway Server выполняет в таком случае роль доверенного посредника между агентами вне домена и доменным сервером управления. В случае же если количество серверов в рабочей группе (или же в недоверенном домене) невелико – можно использовать другой метод – взаимная аутентификация клиента вне домена (агента мониторинга) и сервера управления в домене на основе цифровых сертификатов.

Описание процедуры подключения сервера в составе рабочей группы к серверу управления SCOM в составе домена.

Основные этапы:

1. Импортирование корневого сертификата доверенного центра сертификации.
2. Создание и установка сертификата на сервер управления.
3. Создание и установка сертификата на сервер в составе рабочей группы
4. Экспорт сертификата для дальнейшего использования в SCOM
5. Включение разрешения ручной установки агентов мониторинга на сервере управления
6. Установка агента мониторинга на сервер в составе рабочей группы
7. Импорт сертификата в агент мониторинга с помощью утилиты MOMcertimport
8. Одобрение агента на сервере управления

1. Импортирование корневого сертификата доверенного центра сертификации.

В рамках доменной инфраструктуры распространение корневых сертификатов доверенных центров сертификации может быть реализовано с помощью механизмов доменных групповых политик (GPO) . Таким образом, мы предполагаем, что на доменном сервере управления SCOM уже установлен корневой сертификат доверенного центра сертификации. Это можно проверить на сервере SCOM открыв оснастку mmc.exe и добавив в неё Snap-In – Certificates для Computer account как это отображено на скриншотах.

После того как мы подключимся к консоли управления сертификатами, переходим в область Trusted Root Certification Authorities и убеждаемся в том, что там присутствует сертификат нашего локального доверенного центра сертификации, от имени которого мы в дальнейшем будем выдавать сертификаты для наших не доменных клиентов и самого SCOM сервера.

Подобным образом проверяем наличие корневого сертификата и на не доменном сервере, на который мы в дальнейшем будем устанавливать агента SCOM. Если корневой сертификат не установлен то можно, например, открыв вэб-узел службы сертификации получить корневой сертификат для его последующего импорта в хранилище корневых сертификатов компьютера. Например, в нашем случае, это будет https://kom-ad01-app23.MyDom.com/certsrv/

После того как мы сохранили предложенный корневой сертификат на локальный диск, можно импортировать его используя уже знакомую консоль управления сертификатами.

В открывшемся мастере импорта сертификатов указываем расположение полученного файла корневого сертификата

Затем выбрать хранилище сертификатов - Trusted Root Certification Authorities - Local Computer (будет отображаться, только если включена опция Show physical stores)

После успешного импорта сертификата снова проверим его наличие в указанном нами хранилище сертификатов

На этом этап установки корневого сертификата доверенного центра сертификации можно считать законченным.

2. Создание и установка сертификата на сервер управления.

Эта процедура выполняется один раз (на период действия сертификата) на сервере управления, к которому необходимо подключить агентов вне домена.
- Логинимся на сервер управления с правами администратора и в вэб-браузере открываем URL доверенного центра сертификации (например https://kom-ad01-app23.MyDom.com/certsrv/ )
- Выбираем пункт “Request a certificate”
- Выбираем пункт “advanced certificate request”
- Выбираем пункт “Create and submit a request to this CA”
- Для формирования запроса заполняем необходимые реквизиты:
Name: Managementserver.domain.com (например KOM-AD01-MON01.MyDom.com)
Type: Other
OID: 1.3.6.1.5.5.7.3.1, 1.3.6.1.5.5.7.3.2
Отмечаем атрибут - Mark key as exportable
Friendly name: Managementserver.domain.com (например KOM-AD01-MON01.MyDom.com)

· Затем выбираем пункт “Submit” и закрываем веб-браузер.

· Отправленный запрос должен быть обработан администратором центра сертификации, то есть оправленный запрос должен быть одобрен и на его основе центром сертификации будет сгенерирован сертификат.

После того как это выполнено, переходим к следующему шагу.

· С сервера управления с правами администратора и в вэб-броузере открываем URL доверенного центра сертификации (например https://kom-ad01-app23.MyDom.com/certsrv/ )
Выбираем пункт “View status of a pending certificate request”

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

Необходимо учитывать тот факт, что процедура установки сертификата через веб-браузер по умолчанию поместит этот сертификат в хранилище текущего пользователя и при необходимости можно переместить этот сертификат в раздел Личное (Personal) хранилища Локальный компьютер с помощью mmc оснастки управления сертификатами. Для этого вышеописанным методом подключим в оснастку оба этих хранилища сертификатов и обычным перетаскиванием переместим полученный сертификат в хранилище Локальный компьютер.

3. Создание и установка сертификата на сервер в составе рабочей группы

Процедура создания и установки сертификата для сервера в составе рабочей группы идентична вышеописанной процедуре для сервера управления с одним только отличием – при формировании запроса в атрибутах Name и Friendly name необходимо указать NetBIOS имя сервера для серверов находящихся в составе рабочих групп и FQDN имя для серверов находящихся в составе недоверенных доменов.

4. Экспорт сертификата для дальнейшего использования в SCOM

Эта процедура проделывается один раз (на период действия сертификатов) на сервере управления и на сервере в составе рабочей группы или не доверенного домена.
- Логинимся на сервер с правами администратора
- Запускаем приложение MMC.EXE
- По описанной ранее процедуре добавляем в открытую консоль оснастку Сертификаты (Certificates) с помощью команды меню консоли «Add/remove Snap-in». В процессе добавления оснастки выбираем «Computer account» и «local computer»
- Переходим в раздел “Certificates (Local Computer)personalCertificates”
- Устанавливаем курсор на ранее созданном сертификате и в контекстном меню выбираем пункт Экспорта сертификата (“All tasks > Export”)
- В открывшемся Помощнике экспорта сертификатов выбираем следующие параметры экспорта : “Yes , Export the private key”
“Personal Information Exchange – PKCS #12 Certificates (PFX)”
“Enable Strong protection” (если присутствует)
- Набираем произвольный пароль для экспорта
- Сохраняем экспортированный сертификат на диск (Например С:ServerName.pfx)
- Закрываем консоль MMC
В дальнейшем выгруженный сертификат в формате *.pfx мы будем использовать на шаге 7.

5. Включение разрешения ручной установки агентов мониторинга на сервере управления

Прежде чем начать ручную установку агентов мониторинга на сервера в составе рабочих групп или недоверенных доменов, требуется на сервере управления SCOM включить опцию принятия на одобрение таких агентов. Путь к данной опции в консоли SCOM: «Administration -> Settings -> Security»

В свойствах «Security» сервера управления на закладке «General» необходимо включить опцию «Review new manual agent installation in pending management view»

6. Установка агента мониторинга на сервер в составе рабочей группы.

Установка агентского ПО на сервер вне доверенного домена или рабочей группы может быть выполнена как вручную, так и с использованием дополнительных сторонних средств автоматизации.
Для начала с сервера управления скопируем на клиентский сервер папку с файлами, необходимыми для установки агентского ПО. По умолчанию эта папка расположен а каталоге C:Program FilesSystem Center Operations Manager 2007AgentManagement и зависит от используемой архитектуры ОС клиентского сервера. В нашем случае это будет содержимое папки x86

Перед установкой самого агента SCOM необходимо установить пакет MSXML6.msi (в случае если этот компонент не был установлен в систему ранее). После этого запускаем программу установки самого агента SCOM 2007 R2 из пакета MOMAgent.msi

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

В процессе установки также запрашивается значение учетной записи «Agent Action Account» - рекомендуется использовать выбранную по умолчанию учетную запись «Local System».

Сразу после установки агента мы можем применить последнее обновление к нему. На момент написания этой заметки это CU#2 для SCOM 2007 R2 (в нашем случае это пакет - KB979257-x86-Agent.msp). Его установка проходит без каких либо запросов.

На этом ручную установку агента SCOM можно считать законченной.

7. Импорт сертификата в агент мониторинга с помощью утилиты MOMcertimport.

Эта процедура проделывается один раз (на период действия сертификатов) на сервере управления и сервере в составе рабочей группы или недоверенного домена.
- Скопируйте файл MOMcertimport.exe из каталога SupportToolsi386 или SupportToolsAMD64 в составе дистрибутива SCOM 2007 R2 на целевой сервер. Запустите командную строку cmd.exe и поменяйте текущий каталог на тот в который скопировали MOMcertimport.exe
- Выполните команду импорта экспортированного ранее сертификата:
  MOMcertimport.exe «С:Server.pfx»
При запросе пароля введите пароль указанный в процессе экспорта сертификата

По сути утилита momcertimport.exe делает только одну вещь — прописывает серийный номер сертификата, который должен использовать SCOM, в ветку реестра HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft Operations Manager3.0Machine Settings (параметр ChannelCertificateSerialNumber).

Данный ключ с правильным серийным номером сертификата должен быть прописан на каждом компьютере, который будет аутентифицироваться с помощью сертификатов.
- Перезапустите службу «System Center Management»
8. Одобрение агента на сервере управления

В консоли администрирования SCOM (Operations Manager Console) перейдите на закладку «Administration» и выберете пункт «Pending Management». Выберете появившийся сервер в составе рабочей группы и выполните для него одобрение (“Approve”). После одобрения клиент будет перемещён в группу «Agent Managed»

На этом процедуру установки и привязки внедоменного агента можно считать оконченной. Состояние работы агента можно в дальнейшем можно отслеживать по созданному после установки агента журналу событий

Если между сервером управления и агентом SCOM имеются брандмауэры, то возможно потребуется дополнительная их настройка. Информацию о портах, необходимых для штатной работы агента SCOM можно найти здесь:
- TechNet Library - Operations Manager 2007 R2 Supported Configurations
- TechNet Library - Using a Firewall with Operations Manager 2007
Дополнительная информация по теме:
- KB947691 - When you try to install a System Center Operations Manager 2007 agent on a workgroup computer without using a gateway server, Operations Manager 2007 cannot see the workgroup computer
- TechNet Blogs - System Center Operations Manager - Obtaining Certificates for Ops Mgr via Command Line or Script
Долгая обработка GPP на этапе "Applying Group Policy Drive Maps policy" на клиентах RODC Windows Server 2008 R2

19.08.2010 Автор:Алексей Максимов
13 984 Просмотров 5 комментариев

На этапе внедрения RODC на базе Windows Server 2008 R2 была замечена проблема, связанная с увеличением времени входа в систему на клиентских ПК. Проблема была выявлена на всех площадках, где для авторизации в домене и применения групповых политик клиенты использовали RODC. После ввода учетных данных процесс входа в систему на несколько минут «замерзал» на этапе «Applying Group Policy Drive Maps policy». Разумеется, подозрение сразу пало на обработку Group Policy Preferences (GPP) в части обработки подключения сетевых дисков, так как в одной из групповых политик, применяемых в части User Configuration у нас было некоторое количество таких подключаемых дисков через механизмы GPP с использованием для каждого подключения нацеливания (Item-level targeting).

Для подключения разных дисков использовались три вида нацеливания: по членству пользователя в доменной группе, по NetBios имени компьютера и по вхождению пользователя в определенный OU в домене.
Для того, чтобы выяснить то, обработка какого именно подключения являлась корнем проблемы, пришлось прибегнуть к включению трейсов для обработки параметров GPP. Для этого в групповой политике, применяемой к испытуемому клиентскому компьютеру, в разделе Computer Configuration потребовалось активировать и настроить параметр Policies > Administrative Templates > System > Group Policy >Logging and tracing > Drive Maps Policy Processing.

По умолчанию ведение трейсов выключено и параметры для определения размещения лог файлов ссылаются на каталог %COMMONAPPDATA%\GroupPolicy\Preference\Trace.

Как ни странно, мы не обнаружили на своих испытуемых системах Windows 7/Windows Server 2008 R2 переменной окружения %COMMONAPPDATA% и поэтому изменили путь для хранения логов с использованием существующей переменной окружения - %programDATA%. В данном случае нас интересовал параметр User trace и его значение получилось в нашем случае таким: %programDATA%\GroupPolicy\Preference\Trace\User.log

Уровень логирования пришлось использовать максимальный, чтобы получить весь доступный объем информации о происходящем в процессе обработки GPP. И на всякий случай было увеличено значение максимального размера лог-файла.

После того, как новая политика, включающая логирование применения GPP, была применена на клиенте с помощью команды gpupdate, был выполнен logoff/logon, чтобы спровоцировать обработку GPP в части подключения сетевых дисков пользователю. Теперь на испытуемом клиентском компьютере в указанном каталоге (C:\ProgramData\GroupPolicy\Preference\Trace) был обнаружен файл трассировки User.log.

После изучения лога стало понятно, что обработка GPP всех сетевых дисков проходила «на одном дыхании» и заметный провал во времени обработки (более 1 минуты) происходил именно на одном определенном диске - “H:”

Оказалось что это единственный сетевой диск, в котором для нацеливания использовался признак вхождения пользователя в определенный OU в домене. Было принято решение для пробы изменить нацеливание для данного сетевого диска по признаку членства пользователя в доменной группе… Каково же было наше удивление, когда время входа в систему сократилось в разы :). Приведу лог обработки после внесённых изменений, чтобы не быть голословным.

Причем повторюсь, что проблема наблюдалась только на клиентах, которые сидели в сайте с RODC, а на клиентах, имеющих в сайте полноценные DC такой «бяки» замечено не было.
Исходя из этой истории, напрашивается вывод о том, что к применению Item-Level targeting нужно подходить с аккуратностью и предварительной обкаткой разных вариантов, тем более GPP предоставляет нам хороший выбор таких вариантов.

Читать далее...
Установка Hyper-V Server 2008 R2 на серверную платформу HP ProLiant DL 360 G5

23.06.2010 Автор:Алексей Максимов
19 006 Просмотров 15 комментариев

Подготовка аппаратной платформы

Перед началом установки Hyper-V Server мы должны провести подготовку аппаратной платформы. В силу того что Hyper-V Server 2008 R2 это относительно новая ОС, для обеспечения корректной работы аппаратных компонент нам потребуется использовать последние версии драйверов с сайта производителя оборудования. Это требование с точки зрения корректной работы последних версий драйверов влечет за собой необходимость обновления всех прошивок Firmware нашего сервера. Поэтому берём за хорошую практику всегда приводить версии Firmware в актуальное состояние перед установкой ОС и последующей установкой драйверов.

При первоначальной загрузке сервера в BIOS первым делом выставляем порядок загрузки (Standard Boot Order) таким образом чтобы загрузка начиналась с CD.
Так как у нашего сервера два сетевых адаптера, сразу определимся в том, что первый из них (NIC1) мы будем использовать для доступа к хостовой ОС Hyper-V Server а второй (NIC2) будем использовать для доступа к виртуальным машинам. И так как информация о сетевых адаптерах нам потребуется на этапе первоначального конфигурирования ОС, сразу выписываем на листочек MAC адрес сетевого адаптера NIC2.

Далее переходим к включению необходимых для Hyper-V аппаратных возможностей процессора.
В Advanced Option > Processor Options > Включаем опции No-Execute Memory Protection и Intel(R) Virtualization Technology.

Скачиваем с сайта тех.поддержки Hewlett-Packard свежий пакет обслуживания серверов HP ProLiant включающий в себя все последние версии Firmware для аппаратных компонент нашего сервера. На момент написания данной заметки этот пакет имеет название HP ProLiant Software Maintenance Pack и версию 8.70 [21.01.2010]

Записываем полученный пакет в виде ISO образа на CD диск, и выполнив с него загрузку сервера, запускаем процедуру обновления Firmware. Встроенная в пакет утилита HP Smart Update Manager автоматически выполнит опрос аппаратных компонент сервера и любезно предложит нам обновить необходимые компоненты. После обновления можно приступать непосредственно к этапу установки ОС.

Установка Hyper-V Server 2008 R2

Процесс установки Hyper-V Server 2008 R2 достаточно прост и интуитивно понятен. Сначала определяемся с языковыми параметрами. На первоначальном этапе эти параметры можно оставить по умолчанию.

Задаём дисковую конфигурацию и выбираем диск, на который будем производить установку ОС. В процессе установки инсталлятор автоматически создаст на этом диске два раздела. Первый раздел – служебный размером в 100 Mb будет предназначен для хранения загрузочных файлов ОС. Второй раздел – сам системный том с исполняемыми файлами ОС и предустановленной ролью Hyper-V Server размером всего оставшегося места на указанном диске.

Оставшиеся два диска в нашем случае мы будем использовать для хранения виртуальных жестких дисков VHD наших будущих виртуальных машин. Для обеспечения отказоустойчивости в нашем случае все три диска представляют собой массивы уровня RAID-1.

Первоначальная настройка ОС

После завершения процесса установки, задаем пароль локального администратора и попадаем в ОС.
Первое что мы видим – это два консольных окна. Первое окно – окно командного интерпретатора cmd.exe запущенное в режиме повышенных привилегий, второе окно – командный файл базовой настройки сервера sconfig.cmd

Пройдём пошагово по всем этапам первоначальной настройки.
Для начала зададим имя нашего Hyper-V хоста. Для этого выберем пункт 2 (Computer Name) и введём имя сервера, после чего нам будет предложено перезагрузить сервер. Перезагрузим сервер.

После перезагрузки сервера включим удаленное управление нашим сервером. Для этого выберем пункт 4 (Configure Remote Management) и последовательно выберем пункты:

1) Allow MMC remote management (разрешим удаленный административный доступ через консоли MMC, автоматически включив при этом необходимые правила Windows Firewall)
2) Enable Windows Powershell (производится авто-установка фичи Windows Powershell и разрешается удаленное исполнение скриптов PS в режиме remotesigned). После выполнения этого действия потребуется перезагрузка сервера.
После перезагрузки снова вернёмся в Configure Remote Management и выполним следующий пункт…
3) Allow Server Manager Remote Management (включим удаленное управление сервером с помощью таких полезностей как PowerShell и WinRM)

Далее вернёмся в главное меню и включим возможность доступа к нашему серверу по RDP. В пункте 7 (Remote Desktop) выберем соответствующий параметр Enabled и выберем тип допустимых подключений (Allow clients running any version of Remote Desktop) так как этот параметр позволит нам получать доступ к серверу по RDP с старых RDP клиентов, не поддерживающих NLA.

Далее вернёмся в главное меню и перейдём к настройкам сети в пункт 8 (Network Settings). Здесь мы обнаружим 2 сетевых адаптера, имеющихся на борту сервера. Нам необходимо выбрать адаптер NIC1, как мы обговорили ранее , и настроить на нём статический IP адрес, который будет использоваться для доступа к хостовой ОС Hyper-V Server 2008 R2 и управления виртуальными машинами.

В нашем примере оба наших адаптера получили IP адрес с DHCP. Для того чтобы понять какой именно адаптер по индексу нам нужно настраивать, в окне командной строки выполним команду

ipconfig /all

Из вывода утилиты ipconfig по MAC адресу сетевого адаптера (его мы выписали из BIOS на первоначальном этапе) можно понять какой адрес он использует в данный момент как выделено на рисунке снизу.

Соответственно в нашем случае получается, что NIC1 у нас находится на интерфейсе с текущим адресом 10.160.136.53, то есть в sconfig.cmd он будет отображаться как #2. Его то мы и должны выбрать и настроить.

Задаем статический IP адрес, маску сети, шлюз по умолчанию в пункте 1 (Set Network Adapter IP Address) а затем значения IP адресов серверов DNS в пункте 2 (Set DNS Servers). На этом основную настройку с помощью sconfig.cmd можно считать законченной (позже мы к ней вернёмся).

Региональные настройки ОС.

Для задания региональных настроек ОС из командной строки вызовем апплет панели управления командой

intl.cpl

и в открывшемся окне на закладке Formats выберем Russia

На закладке Location выберем Russia и применим изменения (Apply)

На закладке Administrative скопируем выставленные нами региональные настройки в настройки профиля «по умолчанию» используемого для новых пользователей

И что важно, выберем язык (system locale) для использования в программах, не поддерживающих Unicode. После чего нам потребуется перезагрузить сервер.

После перезагрузки, мы сразу увидим результат наших новых региональных настроек – sconfig.cmd обрусеет :)

Теперь мы можем ввести наш сервер в домен. Для этого используем пункт 1 главного меню sconfig.cmd где укажем имя домена и учетные данные в домене с правом ввода компьютера в домен. После ввода в домен выполним перезагрузку сервера.

После перезагрузки сразу выполним установку всех последних системных обновлений с WSUS. Для этого воспользуемся пунктом 6 главного меню sconfig.cmd – Загрузка и установка обновлений.

Среди обновлений сразу выполняем установку пакета Forefront Client Security , который будет выполнять функции антивирусной защиты на нашем Core сервере.

После установки всех обновлений и перезагрузки сервера переходим к этапу установки драйверов для аппаратных компонент нашего сервера.

Установка и настройка SNMP Service

В случае, если в нашем окружении для мониторинга аппаратных компонент сервера используется программный комплекс HP Systems Insight Manager (SIM), перед установкой драйверов и программного обеспечения HP нам необходимо будет произвести ряд дополнительных действий:

- Установить и настроить службу SNMP;
- Настроить брандмауэр для взаимодействия компонент мониторинга HP Systems Insight

Службу SNMP в режиме Core устанавливаем следующей командой:

start /w ocsetup SNMP-SC

После установки службы её необходимо настроить, так как по умолчанию служба SNMP не отвечает на поступающие запросы сторонним хостам. Чтобы разрешить опрос клиентских компонент HP Systems Insight со стороны сервера HP Systems Insight Manager необходимо внести изменения в свойства службы SNMP. В силу того что сервер Core не имеет визуальных инструментов для управления службами, сделать это можно двумя альтернативными способами:

1) удаленно подключиться к нашему серверу оснасткой управления службами (services.msc) с другого компьютера под управлением Windows 7/Windows Server 2008 R2, имеющего уже установленную службу SNMP.

2) С другого компьютера с ОС Windows 7/Windows Server 2008 R2, имеющего уже установленную и настроенную нужным образом службу SNMP экспортировать куст реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesSNMPParameters
и затем импортировать его на Core сервере c Hyper-V Server 2008 R2.

Содержимое reg файла может быть примерно таким:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesSNMPParameters]
’NameResolutionRetries’=dword:00000010
’EnableAuthenticationTraps’=dword:00000001
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesSNMPParametersPermittedManagers]
’1’=’localhost’
’2’=’HP-SIM-SERVER’
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesSNMPParametersRFC1156Agent]
’sysServices’=dword:0000004c
’sysLocation’=’Syktyvkar, Gagarin str. 158, room 25’
’sysContact’=’Vasya Pupkin’
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesSNMPParametersTrapConfiguration]
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesSNMPParametersTrapConfigurationpublic]
’1’=’HP-SIM-SERVER’
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesSNMPParametersValidCommunities]
’public’=dword:00000004

Как наверное уже стало понятно из примера, нам необходимо как минимум настроить разрешение опроса по протоколу SNMP с строкой сообщества ‘public’ с правами ‘READ ONLY’ а также включить возможность отсылки трапов на наш сервер HP Systems Insight Manager. После настройки службу SNMP необходимо перезапустить для вступления изменений в силу.

Теперь нужно настроить брандмауэр для взаимодействия компонент мониторинга HP Systems Insight с сервером HP Systems Insight Manager. Для этого как минимум мы должны открыть в системе порты используемые для доступа к HP компонентам System Management Homepage, которые мы будем устанавливать в дальнейшем вместе с драйверами. Сделать это можно командами:

netsh advfirewall firewall add rule name=’HP System Management Homepage (Secure Port)’ protocol=TCP dir=in localport=2381 action=allow

netsh advfirewall firewall add rule name=’HP System Management Homepage (Insecure Port)’ protocol=TCP dir=in localport=2301 action=allow

Дополнительно про настройку брандмауэра в режиме командной строки можно почитать в статье KB947709 How to use the "netsh advfirewall firewall" context instead of the "netsh firewall" context to control Windows Firewall behavior in Windows Server 2008 and in Windows Vista

Установка драйверов

Для установки всех необходимых драйверов на наш сервер HP ProLiant DL 360 G5 скачиваем с сайта тех.поддержки Hewlett-Packard свежий пакет поддержки серверов HP ProLiant включающий в себя все последние версии драйверов для аппаратных компонент нашего сервера. На момент написания данной заметки этот пакет имеет название HP ProLiant Support Pack for Microsoft Windows Server 2008 x64 R2 и версию 8.30 [14.09.2009]

Полученный пакет драйверов распаковываем во временный каталог на сервере и запускаем из командной строки файл setup.exe. В силу того что инсталлятор пакета поддержки изначально позиционируется HP как мульти-платформенный, он без проблем заведётся и отработает на нашем сервере, работающем в режиме Core.

Обратите внимание на то, что если мы собираемся полноценно использовать функционал HP Systems Insight Manager, мы должны устанавливать весь набор предлагаемых программных компонент, даже не смотря на то что некоторые утилиты не смогут запускаться и работать интерактивно в режиме Server Core, так как зависят от наличия в системе браузера Internet Explorer, которого в режиме Core, как нам известно, нет.

Основными используемыми нами интерактивно на сервере утилитами могут быть:

- HP ProLiant Array Configuration Utility (CLI) for Windows - утилита командной строки для конфигурирования дисковых массивов на контроллерах семейства HP Smart Array;

- HP Network Config Utility - для конфигурирования параметров сетевых интерфейсов (например если нам потребуется организация аппаратных VLAN).

Утилита HP Network Config Utility представляет собой приложение с графическим интерфейсом, которое может быть вызвано командой

‘C:Program FilesHPNCUhpteam.cpl’

(в вашем окружении этот путь может быть другим)

В нашем сценарии нам не приходится прибегать к работе с данной утилитой.

Утилита HP ProLiant Array Configuration Utility (CLI) for Windows представляет собой приложение командной строки , которое может быть вызвано командой

‘C:Program Files (x86)CompaqHpacucliBinhpacucli.exe’

(в вашем окружении этот путь может быть другим).

Утилита сама по себе достаточно информативная и простая, имеет встроенный help по возможным комбинациям команд. Для того чтобы получить подробные сведения о конфигурации всех контроллеров HP SA в системе выполним команду

controller all show config detail

Вывод этой команды достаточно большой, поэтому прокомментирую только основные данные о текущей конфигурации:

Smart Array P400i in Slot 0 (Embedded)
Bus Interface: PCI
Slot: 0
....Array: A
Interface Type: SAS
...Logical Drive: 1
Size: 68.3 GB
Fault Tolerance: RAID 1
...... Mirror Group 0:
physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 72 GB, OK)
Mirror Group 1:
physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 72 GB, OK)

Из вывода утилиты мы например можем понять, что у нас:
- Используется контроллер HP Smart Array P400i (слот 0), он имеет два канала;
- Корзина имеет 6 дисков. первые 4 диска расположены на канале "1I", остальные 2 диска расположены на канале "2I";
- Создан массив RAID 1 на дисках 1 и 2 канала "1I"

Если стоит задача создать из неиспользуемых 4 дисков массив RAID5, это можно сделать командой:

controller slot=0 create type=ld drives=1I:1:3,1I:1:4,2I:1:5,2I:1:6 raid=5

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

controller all show config detail

Если стоит задача удаления дискового массива, используем команду типа:

controller slot=0 array C delete

Включение ICMP

В силу того что мы используем сервер с включенным Windows Firewall нам также нужно создать правило разрешающее ICMP трафик, чтобы мы могли пользоваться утилитой сетевой диагностики ping. Сделать это можно с помощью утилиты командной строки Netsh.

Для систем Windows Server Core 2008 / Hyper-V Server 2008 это будет выглядеть так:

netsh firewall set icmpsetting 8

Для систем Windows Server Core 2008 R2 / Hyper-V Server 2008 R2 (как раз наш случай) это будет выглядеть так:

netsh advfirewall firewall add rule name=’ICMP Allow incoming V4 echo request’ protocol=icmpv4:8,any dir=in action=allow

Включение удаленного доступа к Device Manager

После установки драйверов мы должны убедиться в том, что для ОС больше не осталось неопознанных устройств. При попытке удаленного доступа к диспетчеру устройств (Device Manager) нашего сервера мы можем получить отказ в доступе:

Для того чтобы включить доступ к Device Manager нашего сервера мы должны сконфигурировать разрешающий параметр Групповой политики (GPO). Изменения могут быть внесены как на уровне доменной политики, так и на уровне локальной групповой политики сервера (как в нашем примере).

Для этого с компьютера под управлением ОС не ниже Windows Vista или Windows Server 2008, откроем оснастку Local Group Policy Editor , подключимся к нашему Hyper-V серверу и внесём изменения в раздел GPO:

Computer configurationAdminstrative TemplatesSystemDevice Installation

параметр Allow remote access to the PnP interface установим в значение Enable

Для вступления данного параметра в силу потребуется перезагрузка сервера.
Обратите внимание на то, что при удалённом доступе через консоль Device Manager в любом случае мы будем иметь доступ только в режиме чтения, то есть, таким образом, например, не получится переустановить драйвер какого либо устройства на удаленной системе.

Для выполнения административных задач с драйверами устройств, предполагается использование локальных утилит при доступе на сервер через удаленный рабочий стол по RDP. Если по какой-то причине драйвер не имеет собственного инсталлятора или же инсталлятор не работает в среде Server Core, для управления драйверами устройств можно воспользоваться набором скриптов PowerShell - Core Configurator 2.0.
Для этого скачиваем архив Core Configurator 2.0, распаковываем в папку с именем не содержащим пробелов (например C:Tools) и запускаем стартовый скрипт Start_CoreConfig.wsf

Набор скриптов Core Configurator 2.0 помимо управления драйверами может быть полезен нам также и при многих других операция в ОС, работающей в режиме Server Core.

Удалённое управление томами NTFS

Для удалённого управления дисковыми томами на нашем Core сервере можно воспользоваться оснасткой Управление компьютером (compmgmt.msc). Это будет возможно только в случае, если на этапе первоначального конфигурирования сервера мы включили возможности удаленного управления сервером.

Создание виртуальной сети Hyper-V

Теперь для того, чтобы мы могли создавать на нашем Hyper-V сервере виртуальные машины, использующие доступ к внешней локальной сети, мы должны создать виртуальную сеть. Для этого можно использовать оснастку Hyper-V Manager (%ProgramFiles%Hyper-Vvirtmgmt.msc) входящую в состав Средств удаленного администрирования сервера.

Как мы определились ранее, для виртуальных сетей Hyper-V мы будем использовать отдельный сетевой адаптер нашего сервера, чтобы отделить трафик VM от трафика хостовой ОС.

После создания виртуальной сети можно будет создавать виртуальные машины с привязкой к этой виртуальной сети.
Вообще, справедливости ради, стоит отметить тот момент, что если в нашем окружении имеется мощное средство управления серверами Hyper-V - System Center Virtual Machine Manager, то управление виртуальными сетями и глобальными сетевыми параметрами Hyper-V хостов лучше всего выполнять именно из консоли SCVMM. Это позволит нам избежать возникновения ситуации дублирования MAC адресов в пулах разных Hyper-V серверов.

Установка агента DPM 2007

Для установки агента DPM 2007 SP1 на наш Hyper-V сервер с включенной службой Windows Firewall на консоли нашего Core сервера подключаем системный том с DPM сервера и запускаем установку клиента последней версии. В качестве параметра программе установки передаем имя нашего DPM сервера.

net use X: \DPMSERVERC$
cd /d ‘X:Program FilesMicrosoft DPMDPMAgentsRA2.0.8844.0amd641033’
DPMAgentInstaller_KB970867_AMD64.exe DPMSERVER.Mydom.com

После того как команда отработала, перезагружаем Core сервер (DPM клиент). После того как клиент поднялся из ребута на DPM сервере открываем DPM Management Shell и выполняем команду аттача клиента:

PS C:Program FilesMicrosoft DPMDPMbin> .Attach-ProductionServer.ps1
DPMServer:: KOM-AD01-BCP02.Mydom.com
PSName:: KOM-TPSY-VM02.Mydom.com
UserName:: Admin
Password:: *************
Domain:: Mydom.com

На нашем клиентском сервере проверяем, чтобы в процессе, установки инсталлятором агента DPM в правила Windows Firewall было вписано правило dpmra, которое разрешает любую сетевую активность клиентскому приложению DPM.
Если правило по какой-то причине не создано, можем добавить его руками примерно так:

Netsh firewall add allowedprogram ‘C:Program FilesMicrosoft Data Protection ManagerDPMbinDPMRA.exe’ DPMRA

Затем заходим на консоль DPM сервера и проверяем то, что наш Hyper-V сервер доступен как клиент DPM.

Установка агентов SCOM 2007 и SCVMM 2008 R2

В случае если на первоначальном этапе настройки ОС мы включили протоколы удаленного управления нашим сервером, в процессе удаленной установки агента SCOM 2007 с консоли SCOM не должно вызвать никаких затруднений.

Тоже самое можно сказать и про удаленную установку агента SCVMM 2008 R2 с консоли VMM

После всех вышеописанных действий наш сервер с ОС Hyper-V Server 2008 R2 станет полноценным управляемым членом нашей IT инфраструктуры.

На десерт…

После того как все основные этапы конфигурирования нашего сервера выполнены, можно позволить себе немножко пострадать фигнёй ;)

Давайте, к примеру, заменим пустую картинку экрана приветствия нашей ОС на какую-нибудь весёленькую бодрящую картинку. По умолчанию Windows 2008 хранит картинки пользователей в каталоге C:ProgramDataMicrosoftUser Account Pictures в виде файлов с именем DOMAIN+user.dat (например, Mydom+Admin.dat).
Можно стянуть такой файл с любой полной ОС Vista/Win7/2008/2008R2 с GUI, создать подкаталог User Account Pictures в указанном каталоге, так как он в Core по умолчанию отсутствует, и закинуть туда этот файл.
Теперь на экране приветствия нашей ОС мы будем видеть нашу жизнерадостную картинку ))).

Дополнительные ссылки:

Microsoft® Hyper-V™ Server 2008 R2

Microsoft Hyper-V Server 2008 Configuration Guide

Hyper-V Getting Started Guide

Server Core Installation Option Getting Started Guide
GPO: The client-side extension could not remove computer policy setting…because it failed with error code '0x8007000d The data is invalid.' (Event ID 8194 Source Group Policy Registry)

10.06.2010 Автор:Алексей Максимов
9 611 Просмотров 9 комментариев
В один момент заметил, что на одном из контроллеров домена под управлением Windows Server 2008 перестал работать механизм GP Preferences. При этом в логе System периодически фиксировалась ошибка
```
Log Name:      Application 
Source:        Group Policy Registry 
Date:          08.06.2010 6:04:43 
Event ID:      8194 
Task Category: (2) 
Level:         Error 
Keywords:      Classic 
User:          SYSTEM 
Computer:      DC02.mydom.com 
Description: 
The client-side extension could not remove computer policy settings for 'Default Domain Controllers Policy {6AC1786C-016F-11D2-945F-00C04fB984F9}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
```
Как выяснилось, проблема связана с тем, что по какой-то причине ломается кэш преференций какой-либо групповой политики, что в дальнейшем приводит к проблеме обработки преференций и в других политиках применяемых на данном компьютере.
Читать далее...
Использование механизма Disaster Recovery в DPM 2010

27.05.2010 Автор:Алексей Максимов
9 679 Просмотров 16 комментариев
Механизм обеспечения восстановления после катастрофичных сбоев или попросту катастрофоустойчивости (Disaster Recovery) в DPM 2010 реализован путём развертывания вторичного сервера DPM, являющегося хранителем реплики защищаемых данных первичного сервера DPM. Применение катастрофоустойчивой конфигурации необходимо для того чтобы застраховаться от следующих сценариев:
- Полная потеря первичного сервера DPM со всеми репликами защищаемых данных и всех его защищаемых клиентов.
- Потеря только первичного DPM сервера со всеми репликами защищаемых данных.
В первом случае вторичный DPM сервер будет выступать в качестве источника восстановления данных всех потерянных клиентов и при необходимости самого первичного DPM сервера. Во втором случае на время восстановления первичного DPM сервера, чтобы не прерывать цикл защиты данных, необходимо будет присоединить всех агентов DPM к вторичному серверу.
Читать далее...
Установка DPM 2010 на Windows Server 2008 R2

21.05.2010 Автор:Алексей Максимов
6 806 Просмотров Комментариев нет
Системные требования для установки DPM 2010

Общие системные требования можно найти по ссылке - DPM 2010 System Requirements
Отдельно стоит обратить внимание на то, что сервер DPM 2010 не может быть развернут в следующих конфигурациях:
- компьютер с установленной ролью Application Server
- компьютер, используемый в качестве сервера управления System Center Operations Manager
- компьютер с установленным Exchange Server
- компьютер, являющийся нодой кластера Служб кластеризации
Читать далее...
PowerShell: Управление членством групп AD

28.04.2010 Автор:Алексей Максимов
3 465 Просмотров Комментариев нет

Ситуация:
Есть некоторое количество доменных групп безопасности с большим количеством пользователей в каждой их них.
Возникает необходимость копирования членства в существующих группах в другие вновь созданные группы.

Решение:
Используем Quest Management Shell (PowerShell командлеты ActiveRoles Management Shell for Active Directory от Quest Software) и командой фактически в одну строку выполняем поставленную задачу:

Get-QADGroupMember Group1 | Add-QADGroupMember Group2

где Group1 – имя группы безопасности из которой получаем пользователей, Group2 – имя группы безопасности в которую копируем полученных пользователей.
После того как копирование произведено, можно выполнить сравнение состава групп таким образом:

Compare-Object ( Get-QADGroupMember Group1 ) ( Get-QADGroupMember Group2 ) -IncludeEqual
Обновление и кастомизация пакета Adobe Reader

26.04.2010 Автор:Алексей Максимов
5 611 Просмотров Комментариев нет
Цель: Получить пакет установки Adobe Reader, интегрировать в него последние обновления, удалить из него ненужные нам компоненты и развернуть получившийся пакет установки на клиентских ПК.

Решение:
Скачиваем последнюю доступную версию дистрибутив во временный каталог, например C:TempAdobe
AdbeRdr930_ru_RU.exe

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

AdbeRdr930_ru_RU.exe /sAll /rs /l /msi /qb- /norestart EULA_ACCEPT=YES

Объяснение используемых ключей:
/sAll - установка в Silent Mode, т.е. в скрытом режиме
/rs - подавление перезагрузки системы после установки продукта
/l - включить ведение логирования ошибок
/msi - набор ключей передаваемых приложению MSIEXEC

ну а далее мы, собственно говоря, и указываем параметры MSIEXEC

/qb- Выбор основного интерфейса установки
/norestart - Запрет перезапуска после завершения установки
EULA_ACCEPT=YES - Принятие лицензионного соглашения

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

Скачиваем инкрементальные обновления в временный каталог C:TempAdobe

AdbeRdrUpd931_all_incr.msp
AdbeRdrUpd932_all_incr.msp

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

Переходим в каталог и запускаем административную установку (распаковку в каталог) дистрибутива во временный каталог C:Temp AdobeInstallFiles с параметром применения к нему всех полученных обновлений

cd /d C:Temp Adobe
AdbeRdr930_ru_RU.exe -nos_o"./InstallFiles" -nos_ne

Далее создадим ещё один временный каталог C:TempAdobeUpdatedInstallFiles , в котором будем выполнять все операции по интеграции обновлений.
Теперь переходим в каталог InstallFiles и запускаем распаковку дистрибутива в каталог UpdatedInstallFiles

C:TempAdobe>cd InstallFiles
msiexec /a AcroRead.msi

После этого произойдёт копирование файлов в новый каталог UpdatedInstallFiles

Теперь последовательно выполняем команды интеграции обновлений в распакованный дистрибутив

CD /d C:TempAdobeUpdatedInstallFiles
msiexec /a C:TempAdobeUpdatedInstallFilesAcroRead.msi /p C:TempAdobeAdbeRdrUpd931_all_incr.msp

msiexec /a c:TempAdobeUpdatedInstallFilesAcroRead.msi /p c:TempAdobeAdbeRdrUpd932_all_incr.msp

Теперь в каталоге UpdatedInstallFiles мы имеем дистрибутив последней версии (9.3.2)

После того как дистрибутив обновлён, можно приступать к его кастомизации.

В процессе модификации мы сделаем следующие изменения:
- Предотвратим включение модуля Adobe Updater. Этот модуль отвечает за то чтобы периодические обновления каждого установленного экземпляр ПО из Интернета.
- Предотвратим регистрацию модуля SpeedLauncher. Этот модуль в процессе установки прописывает себя в системном реестре и загружается в память при каждом запуске системы. Его назначение - загрузка основных модулей Adobe в память для более быстрого запуска приложений. Реальный "выхлоп" от этой фичи весьма сомнителен.
- Предотвратим создание ярлыка "Adobe Reader 9" на рабочем столе общего пользовательского профиля в процессе установки.
- Включим автоматическое согласие с соглашением EULA.
- Включим предотвращение запуска исполняемых файлов из Adobe Reader.
Скачиваем пакет кастомизации Adobe Customization Wizard 9 (CustWiz90_en_US.exe) и устанавливаем его.

После процедуры распаковки и обновления в каталоге UpdatedInstallFiles имеется файл AcroRead.msi, который нам необходимо открыть из Adobe Customization Wizard 9 и произвести примерно следующие настройки:

На закладке Installation Options
- Run Installation = Unattended
- If reboot... = Supress reboot

На закладке Shortcuts
- Удаляем ярлык Adobe Reader 9 из Desktop

На закладке EULA
- Включаем чекбокс Suppress display of End User License Agreement (EULA)

На закладке Online and Acrobat.com Features
Включаем запрет всех функций обновления и доступа в Интернет как показано на скриншоте.

На закладке File Attachments
Включаем предотвращение запуска исполняемых файлов.

На закладке Direct Editor

- В таблице Component удаляем все строки содержащие 'AdobeUpdater' или 'Adobe_Updater'
- В таблице Feature удаляем строки содержащие 'AUM' или 'Updater'
- В таблице FeatureComponents удаляем строки содержащие 'AUM' или 'Updater'
- В таблице File удаляем строки содержащие 'AdobeUpdater' или 'Adobe_Updater'
- В таблице ModuleComponents удаляем строки содержащие 'AdobeUpdater' или 'Adobe_Updater'
- В таблице Registry удаляем строку 'Registry838'
- В таблице Registry удаляем строки содержащие 'Adobe_Updater' в значении полей Value и Component
- В таблице MsiFileHash удаляем строки содержащие 'AdobeUpdater'
- В таблице Shortcut проверяем чтобы не было строки 'SC_READER_DT', если она есть - удаляем.
- В таблице Property проверяем значение параметра SYNCHRONIZER = YES
- В таблице Property проверяем значение параметра EULA_ACCEPT = YES
- В таблице Property устанавливаем значение параметра DISABLE_BROWSER_INTEGRATION = YES

Далее в главном меню Adobe Customization Wizard 9 выбираем пункт Transform > Generate Transform и сохраняем mst файл, задав имя, например, AcroRead_Transform.mst

Теперь мы можем проверить установку командой:

START /WAIT MSIEXEC /I AcroRead.msi ALLUSERS=TRUE TRANSFORMS=AcroRead_Transform.mst /QB

Теперь в нашем каталоге UpdatedInstallFiles мы имеем обновлённый пакет установки и файл трансформации MSI. Перекладываем содержимое этого каталога в сетевую папку, которая используется у нас для распространения ПО и теперь всё, что нам остается сделать - это добавить получившийся пакет в GPO для централизованного развертывания на клиентские ПК или использовать его как источник развертывания средствами SCCM. При создании пакета распространения в GPO/SCCM выбираем файл AcroRead.msi и не забываем указать наш пакет трансформации AcroRead_Transform.mst.

Дополнительные источники:
Deploying Adobe Reader 9 for Windows
AppDeploy Acrobat Reader 9.x
Using Group Policy to Deploy Adobe Acrobat 9.3.2
Проблема репликации групповых политик (Event ID 13568 Source NtFrs)

07.04.2010 Автор:Алексей Максимов
16 565 Просмотров 7 комментариев

Нарвался на ситуацию когда в домене Windows Server 2008 на одном из контроллеров домена перестали обновляться групповые политики после некорректного выключения ОС. При этом с логе File Replication Service периодически фиксировались события с кодом 13568

Читать далее...