• CertUtil.exe на Windows XP & ЦС на Windows Server 2012 R2 - 0x80094011 - Имеющиеся разрешения для центра сертификации не позволяют текущему пользователю получать сертификаты

    imageИз исходных данных имеем - автономный Центр сертификации (ЦС) на базе Windows Server 2012 R2 и клиентский компьютер на базе Windows XP SP3, с которого выполняется попытка получения корневого сертификата ЦС с помощью утилиты CertUtil.exe (из состава Windows Server 2003 Administration Tools Pack). В результате получаем ошибку:

    0x80094011 (-2146877423) Имеющиеся разрешения для центра сертификации не позволяют текущему пользователю получать сертификаты

    image

    Описание причины такого поведения можно найти в документе TechNet Library - Windows Server 2012 R2 and Windows Server 2012 - What's New in Certificate Services in Windows Server

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

  • Антивирус для Windows Server - настраиваем список исключений. Обновлено 11.08.2016

    imageВ ходе настройки политик управления клиентами любого антивирусного ПО необходимо определять список каталогов, имён процессов или даже расширений фалов, которые должны исключаться из Real-Time сканирования. Постараюсь собрать в одном месте информацию о рекомендуемых параметрах исключений и по мере необходимости буду его корректировать.  Стоит отметить, что список составлен исходя из приложений, которые эксплуатируются в моём рабочем окружении. Список разделен по основным категориям сервисов и там где возможно есть ссылки на официальные рекомендации производителей ПО. Во всех случаях подразумевается что программное обеспечение установлено в каталоги «по умолчанию».

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

  • Интеграция исправлений Windows в локальный WSUS с помощью Local Update Publisher

    imageМожет возникнуть ситуация, когда есть потребность в установке исправления Windows (Hotfix) недоступного через WSUS на большое число компьютеров. Для автоматизации этой задачи можно использовать разные инструменты, такие как logon-скрипты, GPO, SCCM. Рассмотрим альтернативный метод распространения исправления Windows с помощью утилиты Local Update Publisher на примере недавно выпущенного обновления, описанного в статье базы знаний Microsoft - KB2647169 - Windows Fax and Scan cannot send a fax if Internet Explorer 9 is installed in Windows 7 or in Windows Server 2008 R2 исправляющего проблему описанную в заметке Не работает консоль “Факсы и сканирование Windows” после установки IE9– Ошибка сценария 2107

    Local Update Publisher (LUP) это свободно распространяемая утилита, которая позволит нам создать собственный пакет обновления и интегрировать его в инфраструктуру существующего локального сервера WSUS. По большому счёту LUP это упрощённый графический инструмент для работы с стандартными функциями WSUS API 

    Итак, со страницы загрузки проекта скачаем программу установки Local Update Publisher.msi и набор вспомогательных файлов RunIt v5.zip

    Установим LUP и первым делом в меню Tools > Certificate Information создадим само-подписанный сертификат, который потребуется нам для подписания создаваемого нами в дальнейшем пакета обновления WSUS. В веб-документации проекта можно найти информацию о том, что вместо само-подписанного сертификата можно использовать сертификат созданный на основе локального доверенного ЦС, но мне так и не удалось это сделать … возможно из-за того, что на своём WSUS сервере я не использую SSL, а может быть по какой-то другой причине … если честно, я сильно не зарывался в эту тему. Тем более я сразу столкнулся с такой особенностью LUP, что при первом подключении к серверу WSUS само-подписанный сертификат создается автоматически и изменить его в дальнейшем через UI не представляется возможным, про что честно написано в веб-документации. Так как само-подписанный сертификат будет использоваться для цифрового подписания создаваемого обновления, мы должны распространить его на все компьютеры использующие WSUS, в том числе и на сам сервер WSUS. Для этого экспортируем сертификат через меню Tools > Certificate Information > Export Certificate

    image

    Полученный файл сертификата мы можем распространить на компьютеры сети например с помощью GPO. Сертификат должен быть включен в два хранилища – Trusted Root Certification Authorities и Trusted Publishers

    image

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

    Так как в своём примере мы решили рассмотреть хотфикс описанный в статье KB2647169, скачиваем по ссылке указанной в статье два соответствующих файла файла:

    441143_intl_i386_zip.exe – для 32-битных систем
    441144_intl_x64_zip.exe – для 64-битных систем 

    Распаковываем их и получаем соответственно два файла Автономного установщика обновлений:

    Windows6.1-KB2647169-x86.msu
    Windows6.1-KB2647169-x64.msu

    Распаковываем msu файлы в разные подкаталоги. Сделать это можно как любым архиватором например 7zip так и встроенной в Windows утилитой expand

     

    cd /d "C:TempKB2647169"

    mkdir "x64"

    expand "Windows6.1-KB2647169-x64.msu" -F:* "x64"

    mkdir "x86"

    expand "Windows6.1-KB2647169-x86.msu" -F:* "x86"

    Из ранее загруженного архива вспомогательных файлов LUP копируем файл RunIt.exe в папку x86 и RunIt64.exe в папку x64.

    В интерфейсе LUP в меню Tools > Create Update вызываем мастер создания обновления

    image

    Как вы уже наверно поняли, мы специально сделали два подкаталога с распакованными файлами обновления для того, чтобы создать два отдельных пакета WSUS в зависимости от разрядности клиентской ОС. Рассмотрим пример создания первого пакета для 32-битных систем.

    На поле Update File выберем вложенный в каталог x86 вспомогательный файл RunIt.exe. C помощью кнопки Add Files добавим в пакет все файлы, которые есть в каталоге x86 за исключением самого файла RunIt.exe

    image

    На следующем шаге мастера зададим основные настройки пакета, а именно:

    • Package Type: Update

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

    • Package Title: Hotfix….KB2647169

      Сюда введём название нашего обновления. Традиционно в название пакета входит номер статьи KB. Не будем отходить от этой традиции, так как именно это название будет отображаться на клиенте WSUS в процессе установки обновления.
    • Description

      Заполняется по желанию. Я в своём примере в качестве описания использовал название статьи KB и причину возникновения исправляемой проблемы.

    • Classification: Hotfix

      Из выпадающего списка можно выбрать и другие значения классификации. Но я полагаю что желательно придерживаться оригинальной классификации обновления, которую в своём примере я подчерпнул из файла Windows6.1-KB2647169-x86-pkgProperties.txt

    • Vendor: Microsoft
    • Product: Windows
    • Article ID: 2647169

      Код статьи в базе знаний Microsoft

    • Support URL: http://support.microsoft.com?kbid=2647169

      Ссылка на статью в базе знаний Microsoft. Ссылка так же взята из файла Windows6.1-KB2647169-x86-pkgProperties.txt

    • Reboot Behavior: Never Reboots

      Режим требования перезагрузки после установки выбираем исходя из требований описанных в соответствующей статье базы знаний Microsoft

    • Command Line:  %windir%system32pkgmgr.exe /quiet /n:Windows6.1-KB2647169-x86.xml

      Командная строка непосредственной установки обновления с ссылкой на файл настроек xml который должен быть в составе распакованных файлов в папке x86

    image

    На следующем шаге мастера Package Level – Installed Rules мы должны определить правила проверки которые нам дадут информацию о том, что данное обновление уже установлено и не требуется. Воспользуемся примером приведённым в онлайн-документации к LUP и создадим правило проверки наличия обновления с помощью нехитрого WMI запроса:

    • Rule Type: WMI Query
    • WMI Namecpase: rootcimv2
    • Query: Select HotFixID from win32_quickfixengineering where HotFixID = 'KB2647169'

    image

    В нашем примере будет достаточно одного этого правила.

    image

     

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

    На следующем шаге Package Level – Installable Rules мы должны определить состав условий которые должны быть соблюдены для того, чтобы обновление могло успешно установиться. Опять же воспользуемся примером приведённым в онлайн-документации к LUP и создадим ряд правил:

    • Processor Architecture: x86

      Так как в данном примере мы создаем пакет из файлов рассчитанных только на 32-битные системы.

    • Windows Version: Windows 7 (c SP1 и без него) с типом Workstation

      Эти два условия объединённых в группу OR говорят о том что мы можем устанавливать это обновление только на определённую клиентскую версию ОС с первым пакетом обновлений или без него (опять же чётко согласно требованиям статьи базы знаний Microsoft по этому обновлению)

    • File Version: Xpsprint.dll ниже версии 6.1.7601.21866

      Это дополнительное условие основано на информации публикуемой в статье базы знаний по обновлению, где расписано то, какие файлы меняются данным обновлением и до какой версии. В нашем примере информация в KB вы глядит так:

    image

     

    В общей сложности мы создали 4 условия в общей группе условий по умолчанию AND, при этом внутри этой группы два условия объединены в группу OR

     

    image

    Следующие два шага Installation Item Level – Superseded Rules и Installation Item Level – Rule Metadata в нашем примере мы можем пропустить оставив без изменений.

    На финальном шаге жмакаем Finish и дожидаемся пока наше обновление опубликуется в WSUS 

    image

    При первоначальной попытке публикации я получил ошибку, которая, как оказалось, была связана с тем, что на сервер WSUS из групповой политики не успел попасть само-подписанный сертификат LUP. Также обратите внимание на то, что установка нашего уже опубликованного обновления подписанного таким сертификатом на клиентских ПК в дальнейшем также может завершаться с ошибкой из-за этой же причины.

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

    image

    В процессе управления одобрениями мы будем оперировать группами созданными на самом WSUS сервере. В нашем примере мы сделаем одобрение на тестовую группу компьютеров чтобы проверить корректность установки обновления.

    image

     

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

    image

    Сводную статусную информацию о ходе установки обновления на компьютерах мы сможем видеть также в консоли LUP на закладках Status и Report выбрав соответствующий пакет.

    image

     

    В этом примере мы рассмотрели создание и распространение пакета для 32-битных систем. По аналогии можно создать пакет для 64-битных систем из файлов которые мы в начале заметки распаковали в каталог x64.

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

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

    Более полную информацию о работе LUP на английском языке можно найти на странице веб-документации проекта, в частности в статье Local Update Publisher - Distributing Hotfixes and MSUs with LUP

  • Remote Desktop Services - Строим отказоустойчивую ферму RD Connection Broker

    imageНачиная с этой записи, постараюсь сделать ряд заметок о Службах удалённых рабочих столов Microsoft Windows Server 2008 R2 – серверной роли Remote Desktop Services (RDS). Для начала рассмотрим процесс создания фермы серверов RDS с использованием механизма балансировки нагрузки с помощью Remote Desktop Connection Broker (RDCB).

    Описание задачи

    Не будем заострять внимания на описании функций служб Remote Desktop Services, так как этой информации более чем достаточно в официальных источниках Microsoft. Предметом этой заметки будет пошаговое практическое описание процесса создания фермы из трёх виртуальных серверов, на каждом из которых будут совмещены компоненты RD Session Host и кластеризованная служба RD Connection Broker. То есть мы попробуем при минимуме серверных экземпляров Windows Server 2008 R2 собрать отказоустойчивое решение RDS.

    По информации доступной из блога TechNet Blogs > Mark Ghazai's Blog > Windows Server 2008 R2 Highly Available (Clustered) Remote Desktop Connection Broker на каждом из серверов в кластере RD Connection Broker будет использоваться локальная база с информацией о всех пользовательских сессиях в ферме и лишь одна из нод кластера будет иметь активный экземпляр этой БД, который будет использоваться при обслуживании пользовательских запросов всей этой фермы. В случае недоступности активной ноды БД перестроится на другом сервере и начнёт обслуживать запросы клиентов.

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

  • Замена сертификата APC Web/SNMP Management Card

    secure_web_hostВ предыдущей заметке рассматривалась процедура связки механизма аутентификации на контроллерах управления APC Web/SNMP Management Card с RADIUS сервером и отдельно отмечалось, что при использовании доменной аутентификации важно защитить HTTP трафик шифрованием с помощью цифровых сертификатов.  По умолчанию для построения HTTPS соединения контроллеры APC создают само-подписанный сертификат, на который по понятным причинам веб-браузеры реагируют выводом соответствующих предупреждений о недоверии данному сертификату. Чтобы избавиться от этих предупреждений мы можем заменить само-подписанный сертификат на контроллере на сертификат выданный нашим локальным доверенным центром сертификации на базе Windows Server.

    Веб-интерфейс контроллеров управления APC не имеет встроенных средств для выдачи запроса на получение сертификата нужного ему формата. Для этих целей мы будем использовать специальную утилиту - APC Security Wizard (текущая версия - 1.02), доступную для загрузки с сайта APC.

    При установке в создаваемый каталог копируется всего один файл - APC Security  Wizard.exe. Запускаем мастер и для выдачи запроса на получение сертификата выбираем пункт Certificate Signing Request 

    image

    Затем указываем каталог и имя файла в формате *.p15 в котором будет сохранён генерируемый закрытый ключ.

    image

    Далее вводим основные сведения для создания запроса.  Поля помеченные звездочкой являются обязательными для заполнения. Значение поля Common Name должно соответствовать FQDN имени, зарегистрированного в DNS для нашего контроллера управления. Именно это имя мы будем использовать в дальнейшем при открытии веб-интерфейса через веб-браузер по протоколу HTTPS

    image

    Далее визард нам покажет сведения о том, в каком файле был сохранён наш запрос. Имя файла с расширением *.csr будет соответствовать имени ранее заданного файла закрытого ключа

    image

    Теперь мы берём файл запроса (в нашем случае это KOM-AD01-UP006-Request.csr) и размещаем в локальном центре сертификации на базе Windows Server как обычный запрос и сразу выдаём на этот запрос сертификат.

    image

    После, из консоли управления ЦС открываем сертификат и вызываем мастер экспорта сертификата в формат *.cer (X.509)

    image

    Снова запускаем утилиту APC Security Wizard и на этот раз уже выбираем опцию импорта сертификата – Import Signed Certificate 

    image

    Затем указываем файл сертификата полученного из локального ЦС в формате X.509…

    image

    …а так же указываем имя файла содержащего закрытый ключ, который был создан на первоначальном этапе создания запроса (в нашем случае это файл KOM-AD01-UP006-Request.p15)

    image

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

    image

    image

    Открываем веб-интерфейс контроллера управления APC и на закладке Administration в разделе Network > Web > access включаем опцию применения HTTPS

    image

    В настройках ssl certificate с помощью кнопки обзора выберем наш результирующий файл сертификата и нажмём кнопку Apply.

    image

    Если сертификат создан правильно, то после выполнения logoff/logon мы увидим, что веб-приложение контроллера управления начало использовать его в работе и браузер больше не выдает предупреждений безопасности.

  • Exchange Server 2010 How-to: Установка ролей Client Access и Hub Transport в NLB кластере на Windows Server 2008 R2

    imageС учетом нововведений в Exchange Server 2010, которые приближают роль Client Access к действительно оправдывающей своё название компоненте, перед нами возникает задача обеспечения максимально возможной отказоустойчивости этой роли в продуктивной среде. На сегодняшний день существуют лучшие методики и рекомендации Microsoft, которые обеспечение отказоустойчивости Exchange посредствам WNLB уже не признают как рекомендуемые, а вместо этого предлагают использовать аппаратные решения обеспечения балансировки нагрузки и отказоустойчивости. Однако в реальной практике, по тем или иным причинам, не все себе могут позволить придерживаться таких рекомендаций, и поэтому использование NLB на платформе Windows Server в такой ситуации будет вполне приемлемым вариантом. Я пошагово опишу на практическом примере процедуру установки ролей Exchange Server 2010 SP1 - Client Access (CA) и Hub Transport (HT) на два сервера, включённых в NLB кластер на Windows Server 2008 R2 в среде виртуализации Hyper-V Server 2008 R2.

    С точки зрения сетевого взаимодействия, схема отказоустойчивого NLB кластера из двух серверов Exchange 2010 с ролями Client Access и Hub Transport в нашем случае будет выглядеть так:

    clip_image002

    Среда исполнения

    В качестве серверов, на которые будет произведена установка Exchange Server 2001 SP1, будет использоваться два виртуальных сервера на базе хостов виртуализации на ОС Hyper-V Server 2008 R2. Каждый виртуальный сервер имеет следующую конфигурацию:

    • ОС Windows Server 2008 R2 Standard EN;
    • Объем выделенной ОЗУ - 4 Gb;
    • Число логических процессоров – 4;
    • Жёсткий диск – VHD фиксированного размера в 60 Gb;
    • Два синтетических сетевых адаптера

    При создании второго сетевого адаптера, который будет использоваться для построения NLB в свойствах виртуальной машины Hyper-V необходимо разрешить спуфинг МАС адресов (Enable spoofing of MAC addresses)

    image

    На Microsoft есть статья, описывающая возможные проблемы, связанные с построением NLB кластеров в окружении Hyper-V -KB953828 - Windows Server 2008 Hyper-V virtual machines generate a Stop error when NLB is configured or when the NLB cluster does not converge as expected


    Подготовка ОС к созданию кластера NLB

    После того как виртуальные машины сконфигурированы, на них установлена ОС и установлены все последние обновления с Windows Update, приступаем к настройке ОС для подготовки к созданию NLB кластера.

    Первым делом через Server Manager установим компоненту (фичу) Network Load Balancing

    image

    Так же компоненту NLB можно установить с помощью команды:

    dism /online /enable-feature /featurename:NetworkLoadBalancingFullServer

    clip_image007

    Дополнительную информацию об альтернативных способах установки NLB можно найти в статье MSDN Blogs - Clustering and High-Availability - Installing Network Load Balancing (NLB) on Windows Server 2008 R2

    Как обозначилось ранее, на каждом виртуальном сервере мы имеем по два сетевых интерфейса. Назовём их NIC1 и NIC2 и условимся что, согласно нашей схемы, NIC1 будет отвечать за управление самим сервером (будет зарегистрирован в DNS на FQDN имя сервера) а NIC2 (для которого включён спуфинг MAC адресов) будет участником NLB кластера.

    clip_image008

    Откроем окно настройки сетевых подключений и в меню Advanced > Advanced Settings и проверим порядок использования подключений (Connections). NIC1 должен иметь приоритет над NIC2.

    clip_image009

    Так же в свойствах сетевого подключения, которое будет использоваться для подключения к NLB кластеру (в нашем случае - NIC2) можно отключить все компоненты, за исключением TCP/IP:

    clip_image010

    В свойствах компонента TCP/IP зададим только выделенный IP адрес и маску подсети и по кнопке Advanced откроем окно дополнительных настроек

    clip_image011

    Обратите внимание на то, что в системах Windows Server 2008/2008R2 IP форвардинг пакетов между локальными интерфейсами внутри системы по умолчанию выключен, и для того чтобы наш NLB интерфейс стал доступен, нам нужно включить IP форвардинг на сетевом подключении входящем в NLB кластер командой:

    netsh interface ipv4 set interface “NIC2 – NLB” forwarding=enabled

    В окне дополнительных настроек TCP/IP на закладке DNS отключим механизм регистрации в DNS

    clip_image012

    После этого в локальной доменной зоне прямого просмотра DNS нам необходимо создать статическую А-запись для будущего NLB кластера.

    clip_image013


    Создание кластера NLB

    На первом виртуальном сервере (KOM-AD01-HT01) открываем консоль Network Load Balancing Manager. (меню Пуск > Administrative Tools). Выбираем пункт меню Cluster > New Cluster

    clip_image014

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

    clip_image015

    На странице параметров хоста (Host Parameters) оставляем настройки по умолчанию:

    clip_image016

    В следующем окне мастера создания кластера добавляем IP адрес NLB кластера, на который мы ранее в DNS зарегистрировали А-запись.

    clip_image017

    Далее указываем FQDN кластера NLB (по той самой A-записи), а также режим его работы. Если серверы Exchange 2010 CAS установлены на VMware ESX или имеют другие требования к выбору многоадресного режима нужно выбрать режим Multicast , в нашем же случае нужно выбрать опцию одноадресного режима - Unicast.

    clip_image018

    На странице правил портов (Port rules) удаляем имеющееся по умолчанию правило и добавляем необходимые нам правила. При добавлении правила портов убираем флажок All и указываем конкретный интерфейс NLB и диапазон портов, который хотим добавить в кластер NLB.

    clip_image019

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

    • TCP 25 – Отправка почты по SMTP (для Legacy приложений);
    • TCP 80 – Перенаправление HTTP > HTTPS в IIS;
    • TCP 110 – Получение почты по POP3 (для Legacy приложений);
    • TCP 143 – Подключение по IMAP4;
    • TCP 443 - Outlook Anywhere, Exchange ActiveSync и Outlook Web App;
    • TCP 135 – MAPI RPC для подключения клиентов;
    • TCP 1024-65535 – MAPI RPC (Динамический диапазон RPC) для подключения клиентов;
    • TCP 993 – Secure IMAP (в Filtering mode Affinity установить в значение None);
    • TCP 995 – Secure POP (в Filtering mode Affinity установить в значение None);

    Диапазон динамических портов RPC при желании можно изменить до использования конкретного статического порта. Пример того как это можно сделать описан в статье Новая служба RPC Client Access Service в Exchange 2010 (обратите внимание на то, что в статье упор делается на RTM Exchange Server 2010, а с выходом SP1 процедура настройки статических портов RPC несколько изменилась).

    clip_image020

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

    image

    Далее, переходим на имя NLB кластера и пунктом меню Add Host to Cluster вызываем мастер добавления второго хоста в кластер.

    clip_image022

    Указываем имя нашего второго виртуального сервера (KOM-AD01-HT02), выполняем к нему подключение(Connect) и выбираем соответствующее сетевое подключение на этом удалённом сервере:

    clip_image023

    Значения на странице параметров хоста (Host Parameters) оставляем по умолчанию (приоритет хоста в кластере NLB будет выбран автоматически и при желании его можно изменить в много-хостовых конфигурациях)

    clip_image024

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

    clip_image025


    Подготовка ОС к установке Exchange Server 2010 SP1

    Предварительные требования к ОС для установки Exchange Server 2010 можно найти по ссылке - TechNet Library - Exchange 2010 Prerequisites. Перед развёртыванием Exchange Server 2010 в AD должны быть проведены процедуры расширения схемы, подготовки леса и домена. Порядок проведения этих процедур описан в статье Exchange Server TechCenter - Prepare Active Directory and Domains.

    Так как на наших виртуальных серверах мы планируем включение роли Hub Transport, нам желательно предварительно скачать и установить Microsoft Office 2010 Filter Packs. Фильтры IFilter, входящие в пакет Microsoft Office 2010 Filter Pack используются в подсистеме поиска Exchange для индексирования текстового содержимого в форматах файлов Microsoft Office 2007/2010.

    В Exchange Server 2010 SP1 программа установки Exchange должна сама зарегистрировать фильтры IFilter из пакета фильтров Office 2010 Filter Pack в службе поиска Exchange, в отличие от RTM версии, где регистрацию нужно проводить в ручную, поэтому всё, что нам предварительно нужно сделать, это скачать 64-битную версию пакета и установить её…

    clip_image026

    Далее все необходимые системные компоненты для ролей Client Access и Hub Transport можно быстро установить с помощью PowerShell:

    Import-Module ServerManager

    Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart

    После окончания установки компонент, сервер выполнит перезагрузку. И так как набор используемых в ОС компонент расширился, сразу после перезагрузки выполним запрос к серверу WSUS и установим все доступные обновления.

    Мы планируем наши сервера для роли Client Access и поэтому необходимо изменить тип запуска службы Net.Tcp Port Sharing Service на Автоматический. Сделать это можно также командой PowerShell:

    Set-Service NetTcpPortSharing -StartupType Automatic

    Дополнительно, перед установкой роли Client Access, нам необходимо учесть требования раздела «Install the Exchange 2010 SP1 Hotfixes for Windows Server 2008 R2» онлайн документации и вручную скачать и установить обновления (которые не распространяются через WSUS), необходимые для корректного сосуществования с Exchange Server 2010 SP1:

    · KB982867 - WCF services that are hosted by computers together with a NLB fail in .NET Framework 3.5 SP1
    · KB979744 - A .NET Framework 2.0-based Multi-AppDomain application stops responding when you run the application
    ·
    KB983440 - An ASP.NET 2.0 hotfix rollup package is available for Windows 7 and for Windows Server 2008 R2
    ·
    KB977020 - FIX: An application that is based on the Microsoft .NET Framework 2.0 Service Pack 2 and that invokes a Web service call asynchronously throws an exception on a computer that is running Windows 7

    Скачаем по ссылкам указанным в KB пакеты исправления соответствующие нашей платформе – x64 и произведём их установку. После установки этих обновлений потребуется перезагрузка системы.

    clip_image027

    Без предварительной установки этих обновлений инсталлятор Exchange Server 2010 SP1 попросту не даст установить роль Client Access.


    Установка Exchange Server 2010 SP1

    Распаковываем ISO дистрибутив Exchange Server 2010 с интегрированным SP1 и запускаем Setup.exe в режиме Run as Administrator.

    Выбираем пункт 3 - Choose Exchange language option и указываем то, что для установки используем только языковые пакеты, входящие в состав дистрибутива

    image

    Затем выбираем пункт 4 - Install Microsoft Exchange

    Проходим шаги Introduction, License Agreement, Error Reporting и на шаге Installation Type выбираем Custom Exchange Server Installation, а так же на всякий случай отмечаем галку автоматической установки недостающих системных компонент:

    image

    На шаге выбора ролей отмечаем роли Client Access Role и Hub Transport Role

    image

    На следующем шаге нам будет предложено ввести FQDN имя нашего CA сервера (массива) опубликованное в Интернет. В моём случае точка публикации находится на другом сервере и поэтому я оставлю это значение пустым.

    image

    Затем инсталлятор проверит наличие в системе всех необходимых компонент для возможности установки выбранных ролей

    image

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

    image

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


    Установка последнего Rollup для Exchange Server 2010 SP1

    Информацию о текущих версиях Exchange Server можно найти по адресу - TechNet Wiki - Exchange Server and Update Rollups Builds Numbers

    На момент написания этой заметки, последним пакетом исправлений является - Update Rollup 2 for Exchange Server 2010 SP1 - 14.1.270.1 (12/9/2010) KB2425179

    Порядок установки последнего накопительного пакета обновлений описан в статье - TechNet Library - Install the Latest Update Rollup for Exchange 2010. Следуя его рекомендациям, для ускорения процесса установки, на время установки можно отключить проверку списков отзывов сертификатов в свойствах Internet Explorer (Открываем Internet Explorer и в меню Tools > Internet Options > Advanced > Security отключаем флажок Check for publisher’s certificate revocation).

    clip_image040

    Дополнительные сведения см. в статье 974445 базы знаний Майкрософт Создание образов NGEN занимает слишком много времени

    Для установки Rollup открываем командную строку в режиме Run as Administrator и запускаем из неё программу установки обновления, в нашем случае это файл Exchange2010-KB2425179-x64-en.msp, дожидаемся окончания установки и снова перезагружаем сервер, чтобы удостовериться в том, что все необходимые службы Exchange Server стартуют в штатном режиме.

    clip_image041


    Подготовка и привязка SAN сертификата

    Для корректной работы защищённого доступа к службам массива Client Access необходимо создать новый сертификат, так как FQDN, используемый для доступа в серверы Client Access в NLB кластере, не соответствует FQDN, заданному в поле общих имён или в поле альтернативных имён в SSL сертификате, который автоматически устанавливается на каждом сервере Client Access во время установки Exchange Server 2010. То есть нужно создать сертификат, в котором присутствуют несколько FQDN (сертификат с альтернативными именами объекта – SAN - Subject Alternative Name) – FQDN Client Access Array, FQDN каждого узла кластера NLB и служебные имена (такие как Autodiscover)

    Для создания запроса для нового SAN сертификата можно использовать Exchange Management Shell (командлет New-ExchangeCertificate):

    $RequestData = New-ExchangeCertificate -GenerateRequest -SubjectName "E = V.Pupkin@holding.com,CN = KOM-AD01-CA01.Holding.com,OU = KOMI,O = Holding Ltd.,L = Syktyvkar,S = Komi republic,C = RU" -DomainName kom-ad01-ca01.holding.com, kom-ad01-ht01.holding.com, kom-ad01-ht02.holding.com, autodiscover.holding.com, kom-ad01-ca01, kom-ad01-ht01, kom-ad01-ht02 -KeySize 1024 -PrivateKeyExportable $true

    Set-Content -path "C:TempCAS_SAN_Cert.req" -Value $RequestData

    Далее, на основании полученного файла запроса в локальном центре сертификации (если он настроен на поддержку сертификатов с Subject Alternative Name) можно получить сертификат.

    В нашем случае для отправки запроса и получения сертификата будет использоваться веб-узел локального центра сертификации Active Directory Certificate Services.

    На странице Advanced Certificate Request перейдём по ссылке “Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.” и скопируем содержимое сгенерированного ранее запроса

    clip_image042

    После того как размещённый запрос на сертификат обработан администратором центра сертификации, мы можем с этого же веб-узла локального центра сертификации Active Directory Certificate Services загрузить сертификат в формате «Base 64 encoded» по ссылке « View the status of a pending certificate request » а затем «Download certificate chain».

    image

    Теперь импортируем полученный сертификат, используя Exchange Management Shell с помощью командлета Import-ExchangeCertificate:

    Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path С:Temp CAS_SAN_Cert.p7b -Encoding byte -ReadCount 0))

    После импорта сертификата командлет вернёт нам Thumbprint, по которому можно будет проверить текущее состояние сертификата с точки зрения Exchange и его привязки к сервисам командлетом Get-ExchangeCertificate:

    Get-ExchangeCertificate -Thumbprint <thumbprint> | FL

    clip_image045

    В данный момент мы видим, что сертификат используется только службами IMAP и POP и нам нужно включить сертификат для остальных клиентских служб и SMTP. Для этого воспользуемся командлетом Enable-ExchangeCertificate:

    Enable-ExchangeCertificate –Thumbprint <thumbprint> -Services "IMAP, POP, IIS, SMTP"

    Теперь наш новый сертификат необходимо установить на втором узле NLB кластера (на сервере KOM-AD01-HT02). Для этого нужно произвести на сервере KOM-AD01-HT01 экспорт этого сертификата с закрытым ключом из хранилища Certificates /Local Computer/Personal. Сделать это можно через оснастку управления сертификатами.

    clip_image046

    в Certificate Export Wizard на странице Export Private Key выберите опцию Yes, export the private key

    image

    На странице Export File Format выберите Personal Information Exchange – PKCS #12 (.PFX) и поставьте отметку напротив Include all certificates in the certificates path if possible.

    image

    Затем введите пароль для защиты закрытого ключа, который мы в дальнейшем будем использовать для импорта сертификата на сервер KOM-AD01-HT02

    image

    Далее указываем имя файла и завершаем мастер экспорта сертификата. Полученный файл в формате PFX копируем на наш второй сервер (KOM-AD01-HT02) и, открыв на нём Exchange Management Shell, выполняем импорт сертификата с помощью командлета Import-ExchangeCertificate:

    clip_image053

    При этом появиться запрос на ввод учетных данных. В поле User name можно ввести любой текст, а в поле Password нужно ввести пароль, который мы ранее задали при экспорте сертификата в формате PFX. После того как сертификат успешно импортирован, как описывали ранее, выполняем привязку этого сертификата к службам Exchange на этом сервере:

    Enable-ExchangeCertificate –Thumbprint <thumbprint> -Services "IMAP, POP, IIS, SMTP"


    Создание массива Client Access Array (CAA)

    Теперь собираем сам массив Client Access Array. Для этой цели воспользуемся командлетом New-ClientAccessArray:

    New-ClientAccessArray -Fqdn KOM-AD01-CA01.holding.com -Site "MyMainSite" -Name "KOM-AD01-CA01.holding.com"

    Посмотреть свойства и проверить текущее состояние массива можно с помощью командлета Get-ClientAccessArray

    clip_image054


    Настройка Client Access URLs в массиве CAA

    Теперь для каждого сервера CAS в массиве CAA должны быть установлены URL обеспечивающие доступ к службам Exchange через NLB. То есть мы должны проверить следующие URL:

    · Autodiscover. Виртуальный каталог - /Autodiscover
    · Outlook Web Apps. Виртуальный каталог - /OWA
    · Exchange Control Panel. Виртуальный каталог - /ECP
    · Exchange Active Sync. Виртуальный каталог - /Microsoft-Server-ActiveSync
    · Offline Address Book. Виртуальный каталог - /OAB
    · Exchange Web Services. Виртуальный каталог - /EWS

    Итак, на каждом CAS сервере, входящем в ферму NLB (Массив CAA):


    1) Параметр AutoDiscoverServiceInternalUri должен быть установлен в значение CAA FQDN. Проверить это можно следующим скриптоблоком:

    $CASArrayName = "KOM-AD01-CA01.holding.com"

    $CAAObj = Get-ClientAccessArray | Where-Object {$_.Name -eq $CASArrayName}

    $CAAHosts = $CAAObj.Members

    Foreach ($CASHost in $CAAHosts)

    {

    Get-ClientAccessServer -Identity $CASHost.Name | FL Identity,AutoDiscoverServiceInternalUri

    }

    Результат должен быть примерно таким:

    clip_image055


    2) Для каждой веб-службы значение параметра InternalNLBBypassURL должно быть установлено в значение Server FQDN. Проверить это можно следующим скриптоблоком:

    $CASArrayName = "KOM-AD01-CA01.holding.com"

    $CAAObj = Get-ClientAccessArray | Where-Object {$_.Name -eq $CASArrayName}

    $CAAHosts = $CAAObj.Members | Select-Object Name

    Foreach ($CASHost in $CAAHosts)

    {

    Get-WebServicesVirtualDirectory -Server $CASHost.Name  | FL Identity, InternalNLBBypassUrl

    }

    Результат должен быть примерно таким:

    clip_image056


    3) Параметры InternalURL и ExternalURL для каждой веб-службы должны быть заданы в соответствии с таблицей:

    Виртуальный каталог

    InternalURL

    ExternalURL
    (AD Сайт с подключением к Интернету)

    ExternalURL
    (AD сайт без подключения к Интернету)

    /OWA

    NLB FQDN

    NLB FQDN (Внешнее имя)

    X

    /ECP

    NLB FQDN

    NLB FQDN (Внешнее имя)

    X

    /Microsoft-Server-ActiveSync

    NLB FQDN

    NLB FQDN (Внешнее имя)

    X

    /OAB

    NLB FQDN

    NLB FQDN (Внешнее имя)

    X

    /EWS

    NLB FQDN

    NLB FQDN (Внешнее имя)

    X

    Для быстрого получения информации о том, какие в текущий момент значения InternalURL и ExternalURL установлены на всех серверах массива CAA можно использовать скриптоблок:

    $CASArrayName = "KOM-AD01-CA01.holding.com"

    $CAAObj = Get-ClientAccessArray | Where {$_.Name -eq $CASArrayName}

    $CAAHosts = $CAAObj.Members | Select Name

    Foreach ($CASHost in $CAAHosts)

    {

    Write-Host $CASHost.Name "Client Access URLs:" -ForegroundColor Cyan

    Write-Host ""

    $UrlOWA = Get-OwaVirtualDirectory -Server $CASHost.Name

    Write-Host "OWA Internal:" $UrlOWA.InternalUrl

    Write-Host "OWA External:" $UrlOWA.ExternalUrl

    $UrlECP = Get-EcpVirtualDirectory -Server $CASHost.Name

    Write-Host "ECP Internal:" $UrlECP.InternalUrl

    Write-Host "ECP External:" $UrlECP.ExternalUrl

    $UrlASc = Get-ActiveSyncVirtualDirectory -Server $CASHost.Name

    Write-Host "ASc Internal:" $UrlASc.InternalUrl

    Write-Host "ASc External:" $UrlASc.ExternalUrl

    $UrlOAB = Get-OabVirtualDirectory -Server $CASHost.Name

    Write-Host "OAB Internal:" $UrlOAB.InternalUrl

    Write-Host "OAB External:" $UrlOAB.ExternalUrl

    $UrlWeb = Get-WebServicesVirtualDirectory -Server $CASHost.Name

    Write-Host "EWS Internal:" $UrlWeb.InternalUrl

    Write-Host "EWS External:" $UrlWeb.ExternalUrl

    Write-Host ""

    }

    Для того чтобы быстро установить все значения InternalURL в FQDN CAA воспользуемся скриптоблоком:

    $CASArrayName = "KOM-AD01-CA01.holding.com"

    $CAAObj = Get-ClientAccessArray | Where {$_.Name -eq $CASArrayName}

    $CAAFQDN = $CAAObj.Fqdn

    $CAAHosts = $CAAObj.Members | Select Name

    Foreach ($CASHost in $CAAHosts)

    {

    $OWADirObj = Get-OwaVirtualDirectory -Server $CASHost.Name

    Set-OwaVirtualDirectory -Identity $OWADirObj.Identity -InternalUrl "https://$CAAFQDN/owa"

    $ECPDirObj = Get-EcpVirtualDirectory -Server $CASHost.Name

    Set-EcpVirtualDirectory -Identity $ECPDirObj.Identity -InternalUrl "https://$CAAFQDN/ecp"

    $AScDirObj = Get-ActiveSyncVirtualDirectory -Server $CASHost.Name

    Set-ActiveSyncVirtualDirectory -Identity $AScDirObj.Identity -InternalUrl "https://$CAAFQDN/Microsoft-Server-ActiveSync"

    $OABDirObj = Get-OabVirtualDirectory -Server $CASHost.Name

    Set-OabVirtualDirectory -Identity $OABDirObj.Identity -InternalUrl "http://$CAAFQDN/OAB"

    $WebDirObj = Get-WebServicesVirtualDirectory -Server $CASHost.Name

    Set-WebServicesVirtualDirectory -Identity $WebDirObj.Identity -InternalUrl https://$CAAFQDN/EWS/Exchange.asmx

    }


    Подключение баз данных Exchange к CAA

    Если базы данных на серверах с ролью Mailbox создаются после создания массива CAA, то значение атрибута RpcClientAccessServer каждой БД должно быть задано как FQDN массива CAA. Проверить это можно с помощью команды:

    Get-MailboxDatabase | Format-List Name,RpcClientAccessserver

    clip_image057

    Если базы данных были созданы до настройки CAA, то значение атрибута RpcClientAccessServer будет иметь FQDN конкретного сервера с ролью Client Access. Переопределить это значение, указав FQDN массива CAA можно командой:

    Set-MailboxDatabase "MyDB" -RpcClientAccessServer "KOM-AD01-CA01.holding.com"


    Проверяем работоспособность Client Access Array

    Проверить работоспособность CAA можно, например, с помощью MS Outlook 2007/2010, служба Autodiscover должна разрешить имя сервера как FQDN массива. Откроем мастер добавления новой учетной записи в Outlook, утвердительно ответим на вопрос о настройке учетной записи электронной почты..

    clip_image058

    Дождёмся окончания процесса автоконфигурации..

    clip_image059

    После окончания работы мастера откроем в Outlook свойства созданного профиля учетной записи и проверим то, что подключение настроено на FQDN массива CAA

    image

    Обратите внимание на то, что при использовании клиентов Outlook 2003 может возникнуть проблема при подключении, если на серверах Exchange в службе RPC Client Access включено требование шифрования. Проверить текущее состояние этой настройки можно командой:

    Get-RpcClientAccess | Format-List Server,EncryptionRequired

    Дальше можно проверить возможность подключения к OWA с указанием всех вариантов имени CA/CAA в URL используемых при создании SAN сертификата и поочерёдно сымитировать отказ одного из серверов в NLB кластере, чтобы удостовериться в том, что сервисы клиентского доступа Exchange Server при этом остаются доступными.

    Дополнительная информация:

    TechNet Library - Exchange Server 2010 Library.
    Exchange Server TechCenter - White Paper: Understanding the Relative Costs of Client Access Server Workloads in Exchange Server 2010
    MSExchange.ru - Новая служба RPC Client Access Service в Exchange 2010
    Yannick Varloud Blog - Exchange Server 2010 : How to setup a Client Access Array

  • SCCM - Обновление корневых сертификатов

    При попытке развернуть последнюю версию JRE на Windows 7 столкнулся с ситуацией, когда программа установки завершается с ошибкой:

    Имя журнала: Application
    Источник: MsiInstaller
    Дата: 26.01.2011 8:37:12
    Код события: 11330
    Категория задачи: Отсутствует
    Уровень: Ошибка
    Ключевые слова: Классический
    Пользователь: mydomuser
    Компьютер: WS001.mydom.com
    Описание:
    Product: Java(TM) 6 Update 23 -- Error 1330.A file that is required cannot be installed because the cabinet file \sccm-serverSourcesJRE_1.6.0_23x86Data1.cab has an invalid digital signature. This may indicate that the cabinet file is corrupt. Error 266 was returned by WinVerifyTrust.

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

    При этом на компьютерах с Windows XP данной проблемы нет, так как эти ОС получают с WSUS соответствующее обновление - Update for Root Certificates [October 2010] (KB931125)

    clip_image001

    Для того чтобы обеспечить обновление корневых сертификатов на всех клиентских системах Windows можно скачать файл rootsupd.exe и форсированного распространить его. В моём случае, для этой цели я воспользовался SCCM, создав новый пакет распространения:

    clip_image002

    Для пакета сделана соответствующая программа, которая в скрытом режиме будет запускать исполняемый файл rootsupd.exe.

    clip_image001[4]

    После распространения созданного пакета на все точки распространения SCCM и объявления на коллекцию клиентских ПК, проблема с развёртыванием JRE будет исчерпана.

    Для тех, у кого нет возможности использовать SCCM, распространить это обновление можно и другими доступными способами, например через GPO.

  • Active Directory Certificate Services - Увеличение срока действия выдаваемых сертификатов

    По умолчанию Центр сертификации служб Active Directory Certificate Services (AD CS) при создании новых сертификатов ограничивает срок действия этих сертификатов одним годом. Чтобы увеличить срок действия вновь выдаваемых CA сертификатов необходимо изменить настройки службы сертификации в системном реестре:

    HKEY_LOCAL_MACHINESystemCurrentControlSetServicesCertSvcConfiguration<CAName>

    Значение параметра ValidityPeriod (по умолчанию Years) определяет единицы измерения времени, а значение параметра ValidityPeriodUnits (по умолчанию 1) определяет количество единиц времени для вновь выдаваемых сертификатов. Если изменить значение параметра ValidityPeriodUnits например на 10, то соответственно все вновь выдаваемые сертификаты будут действовать 10 лет.

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

    net stop certsvc
    net start certsvc

    Данное справедливо для версий служб сертификации ОС Windows Server 2000/2003/2003R2/2008/2008R2

    Источник: Microsoft KB254632: How to change the expiration date of certificates that are issued by a Windows Server 2003 or a Windows 2000 Server Certificate Authority

  • Установка сертификата от Windows Server CA на веб-сервер Apache

    imageРассмотрим пример установки цифрового сертификата X509 на веб-сервер Apache, выданного локальным корневым Центром сертификации, работающим на Windows Server 2008. Пошагово решение задачи состоит из нескольких последовательных шагов:

    • Генерация запроса на сертификат средствами OpenSSL к ЦС Windows;
    • Получение от ЦС файла сертификата (.cer) в формате DER X509
    • Конвертация полученного сертификата в .pem и прикручивание оного к веб-серверу Apache

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