Алексей Максимов, Автор в Блог IT-KB

Разрешение проблем возникающих при установке и настройке Microsoft SQL Server 2005 на Windows Server 2008

18.02.2010 Автор:Алексей Максимов
11 430 Просмотров 2 комментария
Перечень проблем, возникающих при установке и первоначальной настройке MS SQL Server 2005 на Windows Server 2008, которые встречались на моей практике чаще всего:
- При установке SQL Server 2005 нет возможности установить Report Services (в мастере установки недоступна опция) либо не устанавливаются клиентские компоненты и прочие дополнительные модули
- Остановка процесса установки MS SQL Server 2005 на стадии Setting File Security
- Нет возможности установить Report Services т.к. в программе установки включение этой опции недоступно.
- После установки SQL Server 2005 отказывается стартовать служба полнотекстового поиска - SQL Server FullText Search
- После установки SP3 для SQL Server 2005 служба SQL Server Reporting Services не стартует с описанием ошибки об истечении таймаута запуска
- После установки SP3 на SQL Server может потеряться доступность вэбузла SQL 2005 Reporting Service
При установке SQL Server 2005 нет возможности установить Report Services (в мастере установки недоступна опция) либо не устанавливаются клиентские компоненты и прочие дополнительные модули

Сценарий с которыми приходилось сталкиваться:

В мастере установки SQL Server 2005 отмечаются для установки клиентские модули и утилиты управления и настройки, в том числе SQL Server Management Studio, но после окончания установки эти модули в системе отсутствуют.

Причина и решение проблем:

Вероятнее всего установка производится с архивного носителя (не с оригинального инсталляционного CD).
К примеру в архивной поставке RTM версия SQL Server 2005 x64 English Standard Edition мы имеем два архива:

SW_CD_SQL_Svr_Standard_Edtn_2005_64Bit_X64_English_1_x64_MLF_X11-57664.EXE
SW_CD_SQL_Svr_Standard_Edtn_2005_64Bit_X64_English_2_x64_MLF_X11-57665.EXE

В первом архиве находятся файлы необходимые для установки самого движка SQL Server, а во втором всевозможные к нему добавы типа Report Services, SQL Server Management Studio и т.п...
Так вот архитектура инсталлятора SQL Server подразумевает то, что эти два архива перед установкой будут распакованы в соответствующие каталоги с конкретными именами: Servers и Tools
И при этом ещё эти каталоги должны находиться вместе в одном каталоге. Только в таком случае можно будет гарантировать успешный и правильный исход программы установки.
Кажется полным бредом...но тем не менее это факт проверенный на практике.

Остановка процесса установки MS SQL Server 2005 на стадии Setting File Security

При попытке установить MS SQL Server 2005 x64 на Windows Server 2008 Standard x64 столкнулся с проблемой - программа установки "замерзает" на шаге "Setting File Security"

В этот момент статусном логе установки можно наблюдать последние записи что-то типа:

<EndFunc Name='SetCAContext' Return='T' GetLastError='203'>
Doing Action: Write_sqlRegSDDL
PerfTime Start: Write_sqlRegSDDL : Tue Feb 24 15:00:07 2009

Как оказалось эта проблема связана с тем что для текущего домена в котором выполняется установка существуют
доверительные отношения с другими доменами и в некоторых случаях процесс установки из-за этого может затягиваться более чем на сутки
на стадии "Setting File Security". В общем-то проблема описана в статье MS KB 910070
Таже приводится весьма замороченный способ исправления проблемы с манипуляциями по пропатчиванию msi пакетов программ инсталляции SQL Server 2005.

Бойцами невидимого фронта опытным путём было выяснено что в момент “замерзания” программы установки достаточно выключить сетевой интерфейс чтобы имитировать пропадание сетевого подключения, после чего (у меня получилось примерно 10 минут) программа установки как ни в чём не бывало продолжит свою работу.

Бойцы невидимого фронта:
- MSDN Forums - Problem installing sql server express
- SimonS Blog on SQL Server Stuff - SQL 2005 install hangs on "Setting File Security"
Нет возможности установить Report Services т.к. в программе установки включение этой опции недоступно

Как известно компонент Microsoft SQL Server 2005 - Report Services требует наличие прeдустановленных служб IIS.
При включении роли Вэб-сервер (IIS) на Windows Server 2008 в дефолтной конфигурации компонент Report Services не будет доступен для установки.
Лечится это так - в настройке ролей сервера в разделе IIS добавить компоненты - IIS 6 Management Compatibility - Совместимость управления IIS 6.
Об этом описано в статье MS KB 938245 - How to install and how to configure SQL Server 2005 Reporting Services on a computer that is running Windows Server 2008

Также дополнительную информацию по этому вопросу можно найти в стаптье из SQL Server 2005 Books Online (November 2008) - How to: Install and Configure Reporting Services on Windows Server 2008

После обновления роли IIS перезагружаем сервер. После ребута установка Report Services станет доступной.

После установки SQL Server 2005 отказывается стартовать служба полнотекстового поиска - SQL Server FullText Search

После установки SQL Server 2005 отказывается стартовать служба полнотекстового поиска - SQL Server FullText Search и в журнале System при старте этой службы регистрируется ошибка с кодом Event ID 7003 (источник - Service Control Manager Eventlog Provider)
и содержанием:

The SQL Server FullText Search (MSSQLSERVER) service depends the following service: NTLMSSP. This service might not be installed.

Проблема имеет два решения:

1) В системном реестре отключить зависимость от службы NTLMSSP: Найти в системном реестре ключ HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesmsftesqlDependOnService
Удалить из значения ключа параметр "NTLMSSP" и перезагрузить сервер.

2) Более простое и правильное - после установки SQL Server 2005 установить c WSUS пакет исправлений SP2 (или более новый).

После установки SP3 для SQL server 2005 cлужба SQL Server Reporting Services не стартует с описанием ошибки об истечении таймаута запуска

Замечено что после установки SP3 на SQL Server 2005 может перестать автоматически стартовать служба SQL Server Reporting Services, а при попытке стартовать службу вручную мы получим ошибку с описанием типа "Error 1053: The Service did not respond to start or control request in a timely fashion".

В данном случае проблема может заключаться в том, что службе не хватает времени, отведенного системой на ответ от службы о том, что она выполнила запуск (по умолчанию это значение составляет 30 секунд). Для решения этой проблемы предлагается увеличить значение установленное по умочанию как минимум вдвое:

В системном реестре находим ветку HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl
Создаем в ней параметр DWORD с именем ServicesPipeTimeout и значением 60000 (Десятичное значение)
Перезагружаем компьютер и убеждаемся в то что проблемная служба успешно стартовала.

Обращаю ваше внимание на то что значение параметра указывается в миллисекундах и влияет на запуск всех служб в ОС.
Источник: Microsoft KB824344 How to debug Windows services

После установки SP3 на SQL Server может потеряться доступность вэбузла SQL 2005 Reporting Service

Данная проблема связана с тем что при установке SP3 на SQL Server 2005 в свойствах вэб узла SQL 2005 Reporting Service слетают настройки безопасности.
Для решения проблемы в консоли Internet Information Services (IIS) Manager раскроем Default Web Site и в нем найдем ReportServer. Выберем Handler Mappings.

Выбираем справа Edit Feature permissions и включаем права на Script и Execute.
Установка SP2 на CCR кластер Exchange Server 2007 SP1 в среде Windows Server 2008

17.02.2010 Автор:Алексей Максимов
3 114 Просмотров Комментариев нет
Рассмотрим установку пакета обновлений SP2 на кластерный экземпляр CCR Exchange Server 2007 SP1 под управлением ОС Windows Server 2008 x64 SP2.
В моём примере в качестве нод кластера будут выступать два сервера с именами KOM-TCSO-CM01 и KOM-TCSO-CM02 (активная и пассивная ноды соответственно), имя CCR кластера - KOM-TCSO-MAIL

Технически процесс установки SP2 на кластерный экземпляр CCR Exchange Server 2007 SP1 состоит из трёх основных этапов:
- Обновление первого (пассивного) узла кластера;
- Остановка CCR кластера, перемещение кластера на обновлённый узел и обновление самого кластера.
- Обновление второго узла кластера
Рассмотрим более подробно все три этапа.

Этап #0. Подготовительные процедуры

Перечисленные ниже процедуры рекомендуемы к выполнению на обоих узлах кластера непосредственно перед запуском программы установки SP2:
- Останавливаем все службы, которые используют открытые дескрипторы счетчиков производительности.
  К общеизвестным службам, которые надо остановить, относятся служба журналов производительности и предупреждений (Performance Logs & Alerts), а также все агенты Microsoft Operations Manager (например System Center Management).
- Останавливаем и затем запускаем заново службу удаленного реестра (Remote Registry).
- В силу того что на запуск служб Exchange в некоторых ситуациях может уходить достаточно много времени и это может привести к ошибкам в процессе установки, рекомендуется увеличить системное значение таймаута запуска служб как минимум вдвое (по умолчанию это значение составляет 30 секунд).
  В системном реестре находим ветку HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl
  Создаем в ней параметр DWORD с именем ServicesPipeTimeout и значением 60000 (Десятичное значение).
  
  Указанное значение параметра указывается в миллисекундах и влияет на запуск всех служб в ОС.
  Для вступления данного параметра в силу потребуется перезагрузка сервера.
  
  Источник: Microsoft KB824344 How to debug Windows services
- Если сервер не имеет прямого подключения к интернету, необходимо на время процесса установки в свойствах обозревателя IE выключить параметр «Проверять аннулирование сертификатов издателей».
  Дело в том что, при установке пакета обновления Exchange пытается подключиться к веб-сайту со списком отзыва сертификатов. Проблемы возникают из-за того, что Exchange пытается проанализировать список отзыва сертификатов для проверки сертификата подписи кода при каждой компиляции сборки в управляемый код. Чтобы обойти эту проблему и сократить время установки, отключите параметр Проверять аннулирование сертификатов издателей на обновляемом сервере. Для этого выполните описанные ниже действия
  
  1. Запустите Internet Explorer.
  2. В меню Сервис выберите пункт Свойства обозревателя.
  3. Откройте вкладку Дополнительно и перейдите в раздел Безопасность.
  4. Снимите флажок Проверять аннулирование сертификатов издателей и нажмите кнопку ОК.
  5. После завершения установки накопительного пакета обновления установите флажок Проверять аннулирование сертификатов издателей
Дополнительные сведения см. в статье 974445 базы знаний Майкрософт Создание образов NGEN занимает слишком много времени

Этап #1. Обновление первого (пассивного) узла кластера

Для начала в консоли Exchange Management Console откроем свойства нашего CCR кластера и убедимся, что он находится в состоянии Online, и пассивной нодой в кластере на данный момент является сервер KOM-TCSO-CM02

Теперь выполним первый этап обновления – обновление пассивного узла кластера на сервере KOM-TCSO-CM02.
Для этого распакуем дистрибутив SP2, откроем командную строку с правами администратора и запустим команду установки:

setup.com /mode:upgrade

После завершения процесса установки выполняем перезагрузку сервера.

В некоторых случаях в конце процесса конфигурирования на этапе Finalizing Setup может возникнуть ошибка запуска службы MSExhangeMailSubmission. Но после перезагрузки сервера эта служба, как правило, успешно стартует. Одной из возможных причин проблем запуска служб, как я уже сказал, может стать маленький таймаут ожидания системы.

Этап #2. Обновление кластера.

После перезагрузки заходим на обновленную пассивную ноду (KOM-TCSO-CM02) и снова проделываем подготовительные процедуры перед очередным запуском программы установки. Затем открываем консоль Exchange Management Shell и выполняем команду по остановке нашего CCR кластера (на этом этапе пользователи потеряют подключение к нашему серверу):

Stop-ClusteredMailboxServer KOM-TCSO-MAIL -StopReason “SP2 Install”

Далее выполним команду перемещения кластера CCR на обновлённую пассивную ноду (KOM-TCSO-CM02):

Move-ClusteredMailboxServer KOM-TCSO-MAIL -TargetMachine KOM-TCSO-CM02 -MoveComment “SP2 Install”

Далее из командной строки запустим процедуру обновления кластера CCR:

setup.com /upgradecms

С этого момента наш обновленный кластер запущен и снова принимает подключения клиентов работая на обновленной ноде.
Для того чтобы в этом убедиться, мы можем например открыть консоль Exchange Management Console и посмотреть свойства нашего кластера.
Как мы можем видеть, версия кластера изменилась на новую и теперь соответствует версии SP2.

Теперь можно перейти к окончательному этапу – обновлению второго узла кластера.
Не забываем вернуть в работающее состояние службы, остановленные на этапе подготовительных процедур (клиентов MOM, SCOM и т.п.)

Этап #3. Обновление второго узла кластера

Заходим на второй узел кластера (KOM-TCSO-HT01) и выполняем подготовительные процедуры, описанные ранее.
Далее мы должны обеспечить полное перемещение всех кластерных ресурсов Windows Failover Cluster на уже обновленный узел. Делаем это с помощью CLI-утилиты cluster.exe. Сначала получим список всех кластерных групп:

cluster group

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

cluster group <GroupName> /move

Выглядеть это будет примерно так:

Теперь все кластерные ресурсы расположены на первой обновленной ноде (KOM-TCSO-CM02) и мы можем запустить программу установки SP2 на необновленной ноде (KOM-TCSO-CM01):

setup.com /mode:upgrade

После этого перезагружаем сервер и проверяем работоспособность всех служб Exchange.
На этом установку SP2 в на CCR кластер Exchange Server 2007 можно считать оконченной.

Официальное описание процесса обновления можно найти на сайте TechNet Microsoft:
на русском языке - http://technet.microsoft.com/ru-ru/library/bb676320(EXCHG.80).aspx
на английском языке - http://technet.microsoft.com/en-us/library/bb676320(EXCHG.80).aspx

Загрузка SP2 для Exchange Server 2007 доступна по ссылке: Exchange Server 2007 Service Pack 2
Установка CCR кластера Microsoft Exchange Server 2007 SP1 на базе Windows Server 2008 SP2

17.02.2010 Автор:Алексей Максимов
3 530 Просмотров Комментариев нет
Для установки кластера CCR необходимо чтобы на обоих узлах отказоустойчивого кластера была установлена ОС Windows Server 2008 Enterprise SP2 x64 и присутствовали все системные обновления, вышедшие после выхода SP2 для Windows Server 2008 (предпочтительно обновление через службу WSUS).
Оба сервера, которые будут выступать у нас в качестве нод кластера, должны быть оснащены двумя сетевыми интерфейсами (один для подключений к локальной сети, второй для обеспечения работы кластера). Присвоим на обоих серверах сетевым интерфейсам соответствующие наименования.

После присвоения имен необходимо изменить порядок использования сетевых интерфейсов. Для этого выбираем Advanced >Advanced Settings

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

Далее производим настройку сетевых интерфейсов (идентично на обоих серверах):

· Отключаем использование IPv6 на обоих сетевых интерфейсах (в силу того что нами этот протокол на текущий момент не этот протокол используется);
· Отключаем на кластерном сетевом интерфейсе (NIC2 - Cluster) использование
Client for Microsoft Networks
File and Printer Sharing for Microsoft Networks
Link-Layer Topology Discovery Mapper I/O Driver
Link-Layer Topology Discovery Responder

В конечном итоге мы должны получить такую вот картину:

Далее мы конфигурируем настройки IPv4 в свойствах сетевых интерфейсов.
Для интерфейса публичной сети (NIC1 – Public) задаем следующие параметры:
- статический IP адрес нашей сети (например, 10.161.0.20 на первом сервере и 10.161.0.21 на втором сервере);
- маску сети (например, 255.255.255.0 на обоих серверах);
- IP адрес шлюза по умолчанию (например, 10.161.0.1 на обоих серверах);
- IP адреса DNS серверов (например, 10.161.0.10 и 10.161.0.9 на обоих серверах);
- Проверяем наличие признака динамической регистрации имени в DNS (Закладка DNS, параметр «Register this connection`s addresses in DNS» – включен)

Для кластерного сетевого интерфейса (NIC2 - Cluster) задаем следующие параметры:
- статический IP адрес внутренней кластерной сети (например, 192.168.254.254 на первом сервере и 192.168.254.253 на втором сервере);
(важно чтобы IP адреса кластерной сети не пересекались с адресами нашей публичной серверной сети)
- маску сети (например 255.255.255.0 на обоих серверах);
- IP адрес шлюза по умолчанию не указываем на обоих серверах;
- IP адреса DNS серверов не указываем на обоих серверах;
- Проверяем то, что признак динамической регистрации имени в DNS выключен (Закладка DNS, параметр «Register this connection`s addresses in DNS» – выключен)

Установка необходимых компонент Windows Server 2008
Кластерный почтовый сервер на базе Windows Server 2008 требует следующих ролей и функций на каждом кластерном узле:
- Web Server (IIS)
- PowerShell
- Fail-Over Clustering
Для ускорения процесса установки необходимых компонент, воспользуемся утилитой ServerManagerCMD.exe, входящей в состав операционной системы. Открыв командную строку с правами администратора выполним следующую последовательность команд:

ServerManagerCmd -i PowerShell
ServerManagerCmd -i Failover-Clustering
ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-ISAPI-Ext
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Windows-Auth

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

Создание кластера Windows Server 2008

Для создания кластера мы воспользуемся оснасткой Failover Cluster Management (Панель управления > Administrative Tools).
В консоли Failover Cluster Management вызываем мастер создания нового кластера (Меню Action > Create a Cluster…)

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

Вводим доменные имена серверов, которые будут выступать у нас в качестве узлов кластера

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

По нажатию кнопки Next поверх мастера установки кластера откроется мастер проверки конфигурации…

Ознакомимся с представленной нам информацией и на следующем шаге на экране Testing Options выберем рекомендуемую опцию проведения всех тестов.

Подтверждаем параметры тестирования

После прохождения этапов тестирования открывается страница результатов.

В нашем случае мы видим, что тест пройден успешно, но есть кое-какие предупреждения, информацию о которых можно получить из более детального HTML отчета по кнопке View Report…

Как видно отчета мастеру проверки не понравилась наша дисковая подсистема. Например, он не увидел дисков, которые можно использовать для конфигураций кластеров с общим дисковым массивом. Но так как мы собираемся строить кластер Exchange Server 2007 CCR, мы можем проигнорировать данные предупреждения и завершить работу мастера проверки. После этого мы снова вернёмся в мастер создания кластера и сразу попадём на экран, в котором нужно ввести имя кластера Windows Server 2008 и его IP адрес. Нужно учесть, что здесь задается не то имя, которое будет использоваться для подключения клиентов Exchange, а то которое необходимо для самого кластерного экземпляра Windows Server 2008, на который мы в последствии будем устанавливать сам кластерный экземпляр Exchange Server 2007.

Далее мастер делает проверку доступности имени в AD и если всё в порядке, предлагает нам начать процесс создания нового кластера

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

Все, кластер установлен и теперь можно приступить к этапу конфигурирования кластерных ресурсов.

Настройка кластерных сетей

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

Изменим имя кластерной сети с «Cluster Network 1» на «Public network».
Выберем опции «Allow the cluster to use this network» и «Allow clients to connect through this network».
То есть на данный кластерный интерфейс у нас будут разрешены запросы клиентов из сети.

Затем изменим имя кластерной сети с «Cluster Network 2» на «Private network» и проверим, чтобы была выбрана опция «Allow the cluster to use this network» , а опция «Allow clients to connect through this network» была выключена. Таким образом, мы заставим кластер использовать данную кластерную сеть только в целях межузлового обмена.

Настройка кворума File Share Majority

Теперь необходимо настроить кворумный ресурс кластера, то есть создать файловый ресурс на отдельном сервере (в нашем случае файловый ресурс располагается на сервере Hub-Transport в том же сайте AD, в котором расположены узлы кластера). Для этого залогинимся на выбранный сервер с ролью Hub-Transport (в нашем случае это сервер с именем HT01), и в корне диска C создадим новый каталог командой:

MKDIR FSM_DIR_<имяCCRкластера>

Где <имяCCRкластера> – это имя, которое вы собираетесь использовать для кластерного почтового сервера.
Например, в нашем случае имя создаваемого каталога будет FSM_DIR_MAIL

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

NET SHARE FSM_<имяCCRкластера>=C:FSM_DIR_<имяCCRкластера> /GRANT:everyone,FULL

Например, в нашем случае команда будет выглядеть так
NET SHARE FSM_MAIL=C:FSM_DIR_MAIL /GRANT:everyone,FULL

Затем настраиваем разрешения файловой системы на данный каталог с помощью команды:

CACLS C:FSM_DIR_<имяCCRкластера> /G BUILTINAdministrators:F <имяWindowsкластера>$:F

Например, в нашем случае команда будет выглядеть так
CACLS C:FSM_DIR_MAIL /G BUILTINAdministrators:F MAILCL$:F

Таким образом, мы создали сетевой каталог для кворумного ресурса кластера и дали на него полные права встроенной группе администраторов сервера с ролью Hub-Transport HT01 и учетной записи кластера MAILCL, созданной в домене после его создания.

Далее необходимо настроить кластера так, чтобы он ссылался на ресурс, который мы только что создали и использовал его в качестве своего кворумного ресурса. Для этого открываем оснастку Failover Cluster Management на одном из узлов кластера, устанавливаем курсор на имя нашего кластера, выбираем «More action» в меню Actions, а затем выбираем опцию «Configure Cluster Quorum Settings…»

Откроется мастер настройки кворума. Ознакомимся с представленными сведениями и жмем «Next».

На странице выбора конфигурации кворума выбираем опцию «Node and File Share Majority»

В качестве кворумного ресурса-«свидетеля» указываем созданную нами ранее сетевую папку на сервере HT01

Мастер конфигурации кворума проверяет доступность сетевого ресурса, просит подтвердить наши намерения и завершает конфигурацию.

Проверка конфигурации кластера

Теперь при открытии оснастки Failover Cluster Management мы видим что наш кластер обладает ресурсами Имя кластера, IP и сетевой ресурс – «свидетель» кворума.

Настало время проверить конфигурацию нашего кластера. Для этого в консоли Failover Cluster Management установим курсор в корень дерева консоли и выберем в меню Action пункт «Validate a Configuration…»

Откроется уже знакомый нам мастер проверки конфигурации кластера. Укажем ему в качестве объекта проверки оба сервера входящих в наш кластер и запустим процедуру проверки. После чего внимательно изучим получившийся отчет на предмет возможных проблем. Если никаких серьезных проблем не обнаружено, можно считать работу с консолью Failover Cluster Management законченной.

Установка роли активного кластерного почтового сервера на первом узле кластера.

Запустите программу установки Exchange Server 2007 SP1. Примите условия лицензионного соглашения и укажите, хотите ли вы активировать отчеты об ошибках или нет.
На странице «Installation Type» выберите опцию Custom Exchange Server Installation.

Далее сделайте выбор роли Active Clustered Mailbox Role.

На странице параметров установки кластера выберите опцию «Cluster continuous replication», затем введите имя, которые вы хотите назначить вашему CMS (это имя будут использовать ваши клиенты Outlook для подключения к CMS). Путь для хранения БД почтовых ящиков будет индивидуальным для каждого сервера и может быть изменен после установки.

Далее укажите IP адрес, который будет использоваться кластерным экземпляром Exchange Server 2007.

Далее программа установки выполнит ряд проверок готовности к установке, и если проблем не возникнет, нажимаем Install, чтобы начать процесс установки активного узла CCR кластера Exchange Server 2007.

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

Установка роли пассивного кластерного сервера почтовых ящиков на втором узле кластера

Запустите программу установки Exchange Server 2007 SP1. Примите условия лицензионного соглашения и укажите, хотите ли вы активировать отчеты об ошибках или нет.
На странице «Installation Type» выберите опцию Custom Exchange Server Installation.
На странице «Server Role Selection» сделайте выбор роли Passive Clustered Mailbox Role.

Снова будет запущен процесс проверки готовности. По завершении этого процесса нажмите Install.
В моём случае процедура установки завершилась вот с такой вот ошибкой:

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

Далее, как и ранее на странице «Server Role Selection» я сделал выбор роли Passive Clustered Mailbox Role и запустил процесс.

На этот раз всё завершилось успешно и после финальной перезагрузки сервера мы получили работающий пассивный узел в кластере CCR Exchange Server 2007 SP1.
Интересный параметр GPO: Удалить команду "Выполнить" из меню "Пуск"

16.02.2010 Автор:Алексей Максимов
4 518 Просмотров 1 Комментарий

В процесс настройки ужесточенной групповой политики для применения на терминальных серверах наткнулся на интересное поведение одного из параметров GPO.

Путь в GPO:
Конфигурация пользователя/Административные шаблоны/Меню "Пуск" и панель задач

Параметр:
Удалить команду "Выполнить" из меню "Пуск"

Cуть в том, что при включении данного параметра, как выяснилось, в системе перестает корректно работать переход по UNC пути не только в Explorer и IE но и во всех других приложениях, например в той же 1С…т.е. переход с диска на диск в GUI путём клацанья мышкой как бы работает, но например из командного интерпретатора Cmd.exe при попытке подключения сетевого диска утилитой net – возникают ошибки по типу ограничения доступа…что само по себе не очень логично, и мне пришлось убить почти час времени чтобы среди кучи выставленных параметров GPO на терминальном сервере найти виновника странного поведения системы…
В описании к данному параметру GPO конечно есть какая-то далеко неоднозначная фраза что-то типа «перестает работать интерфейс»…но что она значит на деле приходиться узнавать путем хождения по граблям …
WSUS Troubleshooting: WebException: Базовое соединение закрыто: Не удалось установить доверительные отношения для защищенного канала SSL/TLS. ---> System.Security.Authentication.AuthenticationException

16.02.2010 Автор:Алексей Максимов
11 008 Просмотров 3 комментария

При поднятии роли WSUS на только что установленном сервере Windows Server 2008 столкнулся с проблемой при попытке синхронизации с Microsoft:

WebException: Базовое соединение закрыто: Не удалось установить доверительные отношения для защищенного канала SSL/TLS. ---> System.Security.Authentication.AuthenticationException: Удаленный сертификат недействителен согласно результатам проверки подлинности.

Изучил лог клиента который напрямую обращается на MS WSUS (c:WindowsWindowsUpdate.log) и обнаружил что клиент обращается на узел https://update.microsoft.com.

Решив воспроизвести ситуацию вручную, открыл этот узел в IE - и посмотрел свойства сертификата.
Цепочка сетификатов ведёт к корневому сертификату ЦС - GTE CyberTrust Global Root

Открыл на своем WSUS сервере остнастку certmgr.msc и выполнив поиск обнаружил что у меня нет такого корневого сертификата...

Пришлось скачать отсюда http://support.microsoft.com/default.aspx/kb/931125 файл rootsupd.exe...далее, по причине того, что этот пакет предназанчен только для WinXP (по крайней мере в Win2008 он просто не запускался) - пришлось распаковать и оттуда открыть файл сauthroots.sst
В нём то и оказался нужный мне сертификат КЦС - GTE CyberTrust Global Root..Импортировал этот сертификат через Мастер импорта сертификатов в хранилище Доверенные корневые центры сертификации (в хранилище Локальный компьютер)
...
Открываю остнастку WSUS, запускаю синхронизацию с MS WSUS... синхронизация заработала
Установка сертификата от Windows Server CA на веб-сервер Apache

15.02.2010 Автор:Алексей Максимов
11 437 Просмотров 3 комментария
Рассмотрим пример установки цифрового сертификата X509 на веб-сервер Apache, выданного локальным корневым Центром сертификации, работающим на Windows Server 2008. Пошагово решение задачи состоит из нескольких последовательных шагов:
- Генерация запроса на сертификат средствами OpenSSL к ЦС Windows;
- Получение от ЦС файла сертификата (.cer) в формате DER X509
- Конвертация полученного сертификата в .pem и прикручивание оного к веб-серверу Apache
Читать далее...
Event ID 1511 и 1515 при загрузке пользовательского профиля на Windows Vista и Windows Server 2008

14.02.2010 Автор:Алексей Максимов
12 236 Просмотров 4 комментария
Если на компьютере под управлением Windows Vista и Windows Server 2008 при входе в систему в момент загрузки пользовательского профиля пользователь получает сообщение о том что его профиль загрузить не удалось и будет использоваться временный профиль, это значит что его основной профиль по какой-то причине повреждён и его восстановленная копия безуспешно пытается загрузиться из реестра при логоне пользователя на компьютер. При этом в системном логе фиксируются события с кодом Event ID 1511 и 1515 Лечится это так:

1. Для начала завершим все сессии пользователя с неисправным профилем и удалим его из списка профилей (если он там отображается, если не отображается переходим к пункту 2):

- открываем snap-in "Свойства системы"
- переходим на закладку "Дополнительно"
- открываем "Профили пользователей"
- удаляем неисправный профиль пользователя.

2. Теперь надо вычистить информацию об этом профиле из реестра:

- для этого определяем SID пользователя. сделать это можно например с помощью утилиты psgetsid.exe
```
D:winToolsSysinternalsPsTools>psgetsid.exe MyDompetrov-va

PsGetSid v1.43 - Translates SIDs to names and vice versa
Copyright (C) 1999-2006 Mark Russinovich
Sysinternals - www.sysinternals.com

SID for MyDompetrov-va:
S-1-5-21-2882866809-389392232-255224647-3057
```
- далее открываем редактор реестра и переходим в куст: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList
- находим в этой ветке SID полученный ранее (возможно имя будет иметь формат SID.bak) и удаляем это ветку реестра.
- снова логинимся этим пользователем и проверяем то что в каталоге пользователей профиль создался корректно и сообщений об ошибках не фиксируется.

Дополнительная информация:
1. Error message when you log on to a Windows Vista-based computer by using a temporary profile: "The User Profile Service failed the logon. User profile cannot be loaded"
2. Vista - Event ID 1511, 1515 Profile loss to TEMP
Forefront Client Security Troubleshooting: The following non-MOM API has failed: objMomServerUtils.GetScriptResponseParameterValue(). Error code: -2147024891

12.02.2010 Автор:Алексей Максимов
2 276 Просмотров Комментариев нет

После развертывания сервера Forefront Client Security на Windows Server 2008 в топологии с одним сервером на консоли FCS можно обнаружить периодически (примерно раз в час) появляющиеся предупреждения о проблемах на FCS сервере. В отчетах это может выглядеть примерно так:

Также на сервере в логе Application параллельно фиксируются предупреждения подобного содержания.

Проблема решается включением доменной учетной записи пользователя DAS (в нашем случае это MyDoms-user) в локальную группу безопасности FCS сервера с именем MOM Administrators
Проблема с подключением сетевого ресурса размещенного на Windows Server при обращении по DNS-алиасу (CNAME)

12.02.2010 Автор:Алексей Максимов
8 086 Просмотров 2 комментария

Есть сервер под управлением Windows Server 2003/2008. На этом сервере размещён общий сетевой ресурс. Ну скажем например выставлен в общий доступ каталог ShareDocuments$. Реальное имя сервера - Server001.domain.com. Соответственно при необходимости подключения с этого сервера на клиентских компьютерах нашего каталога ShareDocuments$ используем команду

D:> net use Z: \Server001.domain.com\Share\Documents$
Команда выполнена успешно.

Тут всё понятно. Но в жизни может возникнуть такая ситуация, когда нужно подключить данный ресурс используя DNS-алиас (CNAME) этого сервера (например AnyServerWhithMyShare.domain.com). В таком случае попытка подключения сетевого каталога может завершиться неудачей, причем выдаваемый текст ошибки достаточно загадочен.

D:>net use Z: \AnyServerWhithMyShare.domain.com\Share\Documents$
Системная ошибка 52.
Вы не подключены, поскольку такое же имя уже существует в этой сети.
Для присоединения к домену откройте компонент панели управления "Система",
измените имя компьютера и повторите попытку.
Для присоединения к рабочей группе выберите другое имя рабочей группы.

Информацию по этому поводу удалось найти в статье Базы знаний Microsoft 281308 Подключение с общим доступом по протоколу SMB на компьютерах с операционной системой Windows 2000 или Windows Server 2003 не всегда работает с псевдонимом
Данную особенность можно назвать фичей, хотя весьма странной в статье выглядит фраза "Данное поведение является подтвержденной ошибкой продуктов Майкрософт, перечисленных в начале данной статьи. Первое исправление этой проблемы появилось в пакете обновлений 3 (SP3) для Windows 2000"

После соответствующих изменений реестра на сервере:
В разделе реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
был создан параметр DisableStrictNameChecking с типом данных REG_DWORD и значением 1 (десятичное)
и последующей перезагрузки сервера, подключение по CNAME заработало:

D:> net use Z: \AnyServerWhithMyShare.domain.com\Share\Documents$
Команда выполнена успешно.
WebDAV клиенты не могут загрузить в каталог на сервере файл размером более 30 Mb

12.02.2010 Автор:Алексей Максимов
6 135 Просмотров 1 Комментарий

Окружение: Windows Server 2008, IIS 7.0, расширение для IIS - WebDAV 7.5
Решение: Открываем на файловой системе сервера виртуальный каталог IIS в который необходимо разрешить загрузку больших файлов, там находим файл конфигурации web.config (если не находим - создаем).
В этот файл вносим следующие изменения:

<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="104857600"/>
</requestFiltering>
</security>

Таким образом мы установим разрешение на загрузку в виртуальный каталог через WebDAV файлов размером до 100 Mb.
Можно также воспользоваться командой

%windir%system32inetsrvappcmd set config -section:system.webServer/security/requestFiltering -requestLimits.maxAllowedContentLength:104857600

Она установит данное разрешение на уровне сервера, что делать – далеко не во всех случая правильно.