• TMG 2010 - Резервное копирование Array Configuration с PowerShell

    22.02.2012 Автор:Алексей Максимов
    3 896 Просмотров 2 комментария

    TMG 2010 - Backup Array Configuration with PowerShellОзадачившись вопросом автоматизации регулярного выполнения резервного копирования настроек Forefront TMG 2010 нашёл ряд интересных материалов, в том числе статью, описывающую процедуру настройки взаимодействия DPM сервера и DPM агента, установленного на сервере Threat Management Gateway – "How DPM 2010 Could Protect Forefront TMG 2010 with a Minimum Opening of Feeds" (в блоге The Microsoft MVP Award Program Blog). Учитывая то, что в моём случае серверы являются виртуальными и периодически подвергаются резервному копированию в виде VM на сервер DPM, нет особого смысла в установке агента DPM непосредственно внутрь этих виртуальных машин. Поэтому я решил ограничиться созданием на регулярной основе резервных копий конфигурации массива TMG. Из консоли Threat Management Gateway  Management эта процедура вызывается из меню действий или контекстного меню на конкретном массиве – Export (Back Up).

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

  • PowerShell - Удаляем устаревшие файлы

    07.02.2012 Автор:Алексей Максимов
    18 360 Просмотров 11 комментариев

    imageЕсли внутри корпоративной сети используются всевозможные сетевые ресурсы доступные множеству пользователей и выполняющие функции файлообменников, например сетевые папки или каталоги FTP серверов, то иногда может возникнуть необходимость в обслуживании таких ресурсов, например периодического удаления файлов и подкаталогов имеющих определённый срок давности. Хочу поделиться маленьким примером когда-то найденного (уже не вспомню где) PowerShell скрипта, который решает у меня такую задачу

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

  • PowerShell - Переименовываем удалённый компьютер

    25.01.2012 Автор:Алексей Максимов
    10 283 Просмотров 3 комментария

    Код для переименования удалённого компьютера с последующей перезагрузкой

    $Credential = Get-Credential

    $OldName = "WS001"

    $NewName = "WS002"

    $Comp = Get-WmiObject Win32_ComputerSystem -ComputerName $OldName -Authentication 6

    $OS   = Get-WmiObject Win32_OperatingSystem -ComputerName $OldName

    $Comp.Rename($NewName,$Credential.GetNetworkCredential().Password,$Credential.Username)

    $OS.Reboot()

  • SharePoint 2010 - Замена значений гиперссылок хранимых в колонке списка

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

    imageЗадача: На сервере SharePoint 2010 создан список (List), который используется как хранилище ссылок на файлы, доступные для скачивания с этого веб-сервера. Одной из колонок такого списка является гиперссылка. Возникает ситуация когда меняется URL этого веб-сервера и все элементы списка в этой колонке необходимо изменить.

    Решение: На веб-сервере выполним Powershell скрипт, который заменит определённое старое значение в колонке с гиперссылками на новое

     

    # $MyListName - Имя списка в сайте

    # $MyColumnName - Имя колонки с значением типа URL

    # $URLOld - Искомое значение существующего URL которое надо изменить

    # $URLNew - Новое значение URL на которое производим замену

    #

    $MySiteUrl = "http://new-server.holding.com"

    $MyListName = "Программное обеспечение"

    $MyColumnName = "URL"

    $URLOld = "http://old-server.holding.com"

    $URLNew = "http://new-server.holding.com"

    #

    $snapin = Get-PSSnapin | Where-Object {$_.Name -eq 'Microsoft.SharePoint.Powershell'}

    if ($snapin -eq $null) {

      Write-Host "Загрузка оснастки SharePoint Powershell"

      Add-PSSnapin "Microsoft.SharePoint.Powershell"

    }

    #                  

    $spSite = new-object Microsoft.SharePoint.SPSite($MySiteUrl)

    $spWeb = $spSite.OpenWeb()

    $spList = $spWeb.Lists[$MyListName]

    $spitems = $splist.items

    $i = 0

    foreach($item in $spitems){

      [Microsoft.SharePoint.SPListItem]$spListItem = $item  

      if ($spListItem[$MyColumnName] -like "*$URLOld*")

      {   

        $i = $i + 1   

        $fldUrl= new-object Microsoft.SharePoint.SPFieldUrlValue($Item[$MyColumnName])       

        $fldUrl.URL = $fldUrl.URL.Replace($URLOld, $URLNew)  

        $item[$MyColumnName] = $fldUrl

        $item.update()   

        Write-Host $item["Title"] $fldUrl

      } 

    }

    Write-Host "Изменено" $i "записей" -foregroundcolor "green"

  • SCVMM 2008 R2– Проверяем версию компонент интеграции

    07.09.2011 Автор:Алексей Максимов
    2 409 Просмотров 1 Комментарий

    imageВ консоли SCVMM 2008 R2 на закладке Hosts можно видеть текущую версию компонент виртуализации если включить отображение колонки Virtualization Software Version, чего не скажешь об уровне виртуальных машин, где визуально с помощью этой консоли определить то какая версия компонент интеграции установлена внутри виртуальных машин не представляется возможным. Для того чтобы попытаться получить данную информацию в сводном виде воспользуемся советом от Peter Noorderijk из заметки Hyper-v.nu - How to check the version of the Integration Components. Скрипт взят за основу, и немного расширен, а именно:

    • Добавлена загрузка PSSnapin VMM (на тот случай если скрипт выполняется не на сервере VMM)
    • Информация о хостах виртуализации берётся не из файла а из данных сервера VMM, к которому мы предварительно подключаемся.
    • Виртуальные машины с версией компонент интеграции не соответствующей номеру, указанному в переменных, - выделяются красным цветом для облегчения визуального анализа

    # Блок переменных

    # $VMMSrv - Имя сервера SCVMM на котором будут выбраны все хосты виртуализации и их VM для анализа

    # $ICCurrentVer - Текущая версия компонент интеграции которая должна быть установлена на VM

    #

    $VMMSrv = "KOM-SCVMM.holding.com"

    $ICCurrentVer = "6.1.7601.17514"

    #

    # Подгружаем оснастку PS VMM для работы с объектами SCVMM

    #

    $VMMMod = "Microsoft.SystemCenter.VirtualMachineManager"

    If ((Get-PSSnapin -Name $VMMMod -ErrorAction SilentlyContinue) -eq $null)

    {

        Add-PSSnapin $VMMMod

    }

    #

    # Функция получения и вывода сведений о компонентах интеграции на VM определённого хоста

    #

    Function Get-IntegrationServicesVersion ($HVhost = $(Throw "HVHost required"))

     {

     $kvps = Get-WmiObject -Namespace rootvirtualization `

     -ComputerName $HVHost `

     -Query "Select GuestIntrinsicExchangeItems From Msvm_KvpExchangeComponent"

     Foreach ($kvp in $kvps)

     {

     $vmkvp = $Kvp.GuestIntrinsicExchangeItems

     $VMICvArray = $vmkvp | Select-Object `

     @{Label="VMName";Expression={([xml]$vmkvp[0]).instance.property[1].value}},`

     @{Label="ICVersion";Expression={([xml]$vmkvp[14]).instance.property[1].value}} -first 1

     Foreach ($VMICv in $VMICvArray)

          {

                If ($ICCurrentVer -ne $VMICv.ICVersion) {

                Write-Host "IC ver.: " $VMICv.ICVersion " on " $VMICv.VMName -ForegroundColor Red

                } Else {

                Write-Host "IC ver.: " $VMICv.ICVersion " on " $VMICv.VMName

                }

          }

     }

     }

    #

    # Блок основного вывода

    #

    $VMHosts = Get-VMMServer -ComputerName $VMMSrv | Get-VMHost | Sort -Property "Name"

    Foreach ($HVhost in $VMHosts) {

    Write-Host "`nHyper-V Host: " $HVhost "`n" -ForegroundColor Green

    Get-IntegrationServicesVersion $HVhost

    }

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

      image

      Примечание:

      Скрипт не выводит информацию о виртуальных машинах, которые находятся в выключенном состоянии.

    • SCOM 2007 R2 - Назначение Primary и Failover серверов на агентах

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

      imageПо мере расширения инфраструктуры SCOM и увеличения серверов управления (Management Server) может возникнуть необходимость в форсированном назначении значений Primary Management Server и Failover Management Server для агентов, чтобы избежать ситуации когда при недоступном ближайшем первичном сервере управления агенты начнут обращаться на сервера управления на удалённых площадках нагружая при этом WAN-каналы там где это не желательно. Такое поведение агентов в конфигурации по умолчанию может быть обусловлено настройками, которые можно видеть в конфигурационном файле клиента в кэше коннектора соответствующей ему группы управления.

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

    • Forefront TMG 2010 – Разрешение нестандартных туннелируемых портов

      25.08.2011 Автор:Алексей Максимов
      13 416 Просмотров 15 комментариев

      Возникла необходимость использовать через TMG 2010 подключение к HTTPS узлу в интернете, использующему нестандартный порт (не 443). В настройке по умолчанию вэб-прокси TMG разрешает доступ только по порту 443. Для того чтобы изменить перечень разрешенных портов воспользуемся подключением к COM-объекту TMG с помощью PowerShell.

      Для того чтобы получить текущий список открытых туннелируемых портов, непосредственно на TMG сервере выполним PS скрипт:

      $ServerName = "MY-PROXY-SERVER"

      $FPCRoot = New-Object -comObject "FPC.Root"

      $TMGObj = $FPCRoot.Arrays.Connect($ServerName)

      $TMGObj.ArrayPolicy.WebProxy.TunnelPortRanges

      В первой строчке в переменной $ServerName укажите имя своего сервера TMG или имя массива TMG, если сервер является членом массива.


      Для того чтобы расширить список открытых туннелируемых портов, например 444 портом, выполним PS скрипт:

      $ServerName = "MY-PROXY-SERVER"

      $FPCRoot = New-Object -comObject "FPC.Root"

      $TMGObj = $FPCRoot.Arrays.Connect($ServerName)

      $TMGObj.ArrayPolicy.WebProxy.TunnelPortRanges.AddRange("SSL 444", 444, 444)

      $TMGObj.ApplyChanges()


      Для того чтобы удалить ранее добавленный порт выполним PS скрипт:

      $ServerName = "MY-PROXY-SERVER"

      $FPCRoot = New-Object -comObject "FPC.Root"

      $TMGObj = $FPCRoot.Arrays.Connect($ServerName)

      $TMGObj.ArrayPolicy.WebProxy.TunnelPortRanges.Remove("SSL 444")

      $TMGObj.ApplyChanges()

      Дополнительные источники информации:

    • PowerShell - Проверяем флаг защиты доменных OU от случайного удаления

      24.08.2011 Автор:Алексей Максимов
      9 902 Просмотров 10 комментариев

      imageВ оснастке Active Directory Users and Computers (dsa.msc) открыв свойства любого OU на закладке Object можно наблюдать флаг “Protect object from accidental deletion” (Защитить объект от случайного удаления). В библиотеке “Best Practices Analyzer for Active Directory Domain Services” есть хорошая заметка на тему управления этим флагом через PowerShell - AD DS: All OUs in this domain should be protected from accidental deletion

      Для того чтобы получить перечень всех OU на которых не установлен флаг защиты выполним скриптоблок:

      # Переменная $LDAPPathOU – ADSI путь к контейнеру внутри которого будем производить поиск OU (в формате distinguishedName)

      #

      $LDAPPathOU = "OU=ImportantOUs,DC=holding,DC=com"

      Import-Module ActiveDirectory

      Get-ADOrganizationalUnit -filter * -SearchScope Subtree -SearchBase $LDAPPathOU -Properties ProtectedFromAccidentalDeletion | Where {$_.ProtectedFromAccidentalDeletion -match "False"} | Select name, DistinguishedName | Format-Table –AutoSize


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

      $LDAPPathOU = "OU=ImportantOUs,DC=holding,DC=com"

      Import-Module ActiveDirectory

      Get-ADOrganizationalUnit -filter * -SearchScope Subtree -SearchBase $LDAPPathOU -Properties ProtectedFromAccidentalDeletion | Where {$_.ProtectedFromAccidentalDeletion -match "False"} | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true

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

    • DPM 2010 - Резервное копирование БД Exchange Server 2010 в группе DAG

      22.02.2011 Автор:Алексей Максимов
      14 147 Просмотров 5 комментариев

      imageРассмотрим использование DPM 2010 в качестве системы резервного копирования баз данных роли Mailbox Exchange Server 2010 на конкретном примере. В качестве исходных данных будем считать, что мы имеем два сервера Exchange Server 2010 с ролью Mailbox объединённых в группу Database Availability Group (DAG), на которых расположено шесть баз данных почтовых ящиков. Параллельно поставим перед собой задачу распределить нагрузку по двум серверам Mailbox. Читать далее...

    • Exchange Server 2010 How-to: Создание Database Availability Group (DAG) на Mailbox серверах на Windows Server 2008 R2

      16.02.2011 Автор:Алексей Максимов
      13 972 Просмотров 6 комментариев

      В прошлой заметке мы на конкретном примере рассмотрели создание и настройку NLB кластера для ролей Client Access и Hub Transport и теперь, отталкиваясь от ранее описанной конфигурации с работающим массивом Client Access Array, рассмотрим пошагово процедуру создания и первоначальной настройки отказоустойчивого кластера с группой DAG в Exchange Server 2010 SP1.

      С точки зрения сетевого взаимодействия, схема отказоустойчивого кластера DAG из двух серверов Exchange Server 2010 с ролями Mailbox в нашем случае будет выглядеть так:

      image


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

      В качестве серверов, на которые будет произведена установка Exchange Server 2010 SP1, будет использоваться два физических сервера HP ProLiant DL 380 G5. Каждый сервер имеет следующую конфигурацию:

      • ОС Windows Server 2008 R2 Enterprise EN;
      • Объем выделенной ОЗУ - 10 Gb PC2-5300 ECC;
      • 2 процессора Xeon 5160 (число логических процессоров – 4);
      • Два сетевых адаптера;
      • 8 HDD SAS 10K, из них 2 HDD по 73Gb в зеркале RAID1 под ОС и исполняемые файлы Exchange и 6 HDD по 136 Gb в non-RAID конфигурации (каждый диск отдельно). В итоге на каждом сервере по доступному дисковому пространству мы получим такую картинку:

      image


      Условимся, что каждый свободный диск по 136 Gb (D - I) будет использоваться под отдельную базу данных (файлы БД и логи на одном диске).

      Сервера будут иметь имена KOM-AD01-CM01 и KOM-AD01-CM02. Создаваемый в процессе описания кластерный экземпляр Exchange DAG будет иметь имя KOM-AD01-DAG1.

      В процессе создания DAG в двух-узловой конфигурации нам потребуется сервер-свидетель (Witness server). Для этой роли мы выберем установленный ранее HT сервер Exchange с именем KOM-AD01-HT01.


      Настройка сетевых параметров

      Итак, на каждом сервере мы имеем по два сетевых интерфейса. Назовём их NIC1 - Public и NIC2 – Cluster и условимся, что согласно нашей схемы, NIC1 будет отвечать за управление самим сервером (будет зарегистрирован в DNS на FQDN имя сервера) а NIC2 будет отвечать за работу сервера в кластере Windows Failover Cluster. При этом мы должны обеспечить прямое физическое соединение интерфейсов NIC2 между двумя серверами.

      image

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

      image

      Так же в свойствах кластерного интерфейса NIC2 можно отключить все компоненты, за исключением TCP/IP (HP Network Configuration Utility в нашем случае это неотключаемая часть вендорного ПО для поддержки расширенных функций сетевого адаптера):

      image

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

      image

      В окне дополнительных настроек TCP/IP на закладке DNS отключаем опцию регистрации этого подключения в DNS - Register this connection's addresses in DNS

      image


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

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

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

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

      image

      Далее все необходимые системные компоненты для роли Mailbox устанавливаем с помощью 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 –Restart

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

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

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

      image

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


      Установка 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

      На шаге выбора ролей отмечаем роль Mailbox Role

      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).

      image

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

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

      Помимо такого варианта установки Rollup можно попробовать воспользоваться и другим – разместить дистрибутив пакета исправлений в подкаталоге UPDATES дистрибутива Exchange Server 2010 SP1 перед процедурой первоначальной установки самого Exchange Server.


      Создание Database Availability Group (DAG)

      Если сервер, который планируется использовать в качестве сервера-свидетеля (Witness server), не является сервером Exchange, то перед тем как создавать DAG, на этом сервере необходимо включить доменную группу «Exchange Trusted Subsystem» в локальную группу администраторов (Administrators). В нашем случае в качестве сервера-свидетеля выбран сервер Exchange уже несущий роль Hub Transport и Client Access и поэтому в его локальной группе Администраторов уже присутствует данная группа безопасности и поэтому мы не будем испытывать проблем при попытке удалённого управления каталогом-свидетелем со стороны учетных записей серверов входящих в DAG.

      В интернете можно так же найти информацию о том, как в качестве сервера-свидетеля использовать контроллеры домена - для этого нужно включить группу “Exchange Trusted Subsystem” в доменную группу “Administrators”. Но как мы все понимаем, это далеко не «Best practice», ибо после таких действий полномочия учетных записей серверов Exchange в домене становятся слишком большие, что само по себе серьёзно понижает уровень безопасности в домене в целом.

      Итак, открываем Exchange Management Console (EMC) переходим в раздел Organization Configuration > Mailbox на закладку Database Availability Groups и в меню Action либо в контекстном меню выбираем пункт New Database Availability Group

      image

      В открывшемся мастере создания новой группы DAG указываем имя группы (будет использовано в дальнейшем для создания учетной записи кластера в домене), имя сервера свидетеля и каталог (по желанию). Если указать только имя сервера-свидетеля, а значение Witness directory оставить пустым, то будет создан каталог в виде %SystemDrive%DAGFileShareWitnesses<DAGFQDN> и на основе этого каталога будет создан сетевой каталог с именем <DAGFQDN>

      image

      Примечание: В дальнейшем, в случае необходимости, например при аппаратном или программном сбое сервера-свидетеля, изменить для DAG сведения о сервере-свидетеле и его каталоге в случае необходимости можно будет с помощью командлета Set-DatabaseAvailabilityGroup

      Создаем группу…

      image

      После этого в службе каталогов Active Directory будет создан объект класса msExchMDBAvailabilityGroup (его можно увидеть через оснастку ADSIEdit.msc)

      image


      Следующим этапом нам нужно задать статический IP адрес, который будет использоваться для предоставления доступа к кластерным ресурсам. Для этого откроем в консоли Exchange Management Console (EMC) свойства только что созданной группы DAG и на закладке IP Addresses добавим IP адрес:

      image

      Задачу назначения IP адреса группе DAG можно выполнить так же и через Exchange Management Shell командлетом Set-DatabaseAvailabilityGroup:

      Set-DatabaseAvailabilityGroup -DatabaseAvailabilityGroupIpAddresses '10.160.0.31' -Identity 'KOM-AD01-DAG1'

      Вообще стоит отметить, что и создание новой группы DAG более оперативно можно сделать через EMS командлетом New-DatabaseAvailabilityGroup:

      New-DatabaseAvailabilityGroup -Name 'KOM-AD01-DAG1' -WitnessServer 'KOM-AD01-HT01' -DatabaseAvailabilityGroupIpAddresses '10.160.0.31'

      Добавление первого сервера в DAG

      В консоли Exchange Management Console открываем Organization Configuration > Mailbox > Database Availability Group > выбираем нашу группу DAG и в меню Action выбираем пункт Manage Database availability Group Membership

      image

      В открывшемся мастере управления серверами-членами DAG с помощью Add добавляем первый сервер:

      image

      Итак, первый сервер в DAG добавлен…

      image

      Как мы видим, добавление сервера в DAG мы могли выполнить через Exchange Management Shell командлетом Add-DatabaseAvailabilityGroupServer:

      Add-DatabaseAvailabilityGroupServer -MailboxServer 'KOM-AD01-CM01' -Identity 'KOM-AD01-DAG1'

      В процессе добавления первого сервера в DAG произойдёт следующая последовательность действий:

      1) На сервер будут установлены компоненты Windows Failover Clustering, и будет создан новый кластер в режиме Node Majority с именем, соответствующим имени группы DAG. Переключение кластера в режим Node and File Share Majority, и как следствие использование сервера-свидетеля, произойдёт только после добавления в DAG второго сервера.

      image


      2) При создании кластера в доменном контейнере Computers будет соответствующая учетная запись объекта Cluster network object (CNO)

      image


      3) В DNS должна появиться A-запись с именем и IP адресом группы DAG

      image


      4) В свойства объекта DAG в Active Directory будет внесена информация о добавленном сервере

      image

       

      Добавление второго сервера в DAG

      Для добавления второго сервера в группу DAG можно воспользоваться мастером «Manage Database availability Group Membership» также как и при добавлении первого сервера, но мы для наглядности воспользуемся Exchange Management Shell:

      Add-DatabaseAvailabilityGroupServer -MailboxServer 'KOM-AD01-CM02' -Identity 'KOM-AD01-DAG1'

      image

      Результатом успешного выполнения этой команды будет:

      1) Добавление второго сервера в качестве второй ноды в Windows Failover Cluster с изменением режима работы кластера на Node and File Share Majority с сервером свидетелем.

      image


      2) Добавление информации о втором сервере в свойства объекта DAG в Active Directory


      3) Начинает использоваться служебный сетевой каталог, созданный на транспортном сервере – свидетеле (KOM-AD01-HT01) с появлением в нём информации о состоянии кластерного кворума


      Создание реплицируемых БД

      После того как DAG настроена, мы можем создать необходимое нам количество БД и настроить репликацию. Для создания новой БД на первом сервере Mailbox воспользуемся Exchange Management Console (Organization Configuration > Mailbox > Database Management > выбираем в меню Action пункт New Mailbox Database)

      В открывшемся мастере вводим имя новой базы данных и имя сервера на котором она будет использоваться как активный экземпляр:

      image

      Задаём расположение файла БД и подкаталога для логов…

      image

      Дожидаемся успешного окончания процесса создания и монтирования новой БД…

      image

      После того как база создана на первом сервере, сделаем её реплицируемой на второй сервер. Для этого в Exchange Management Console в разделе Organization Configuration > Mailbox > Database Management > выбираем нужную базу данных и в меню Action пункт Add Mailbox Database Copy…

      image

      В открывшемся мастере выбираем второй сервер Mailbox входящий в группу DAG, на котором будет размещена копия БД:

      image

      Дожидаемся окончания процесса …

      image

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

      Теперь в консоли Exchange Management Console можно проверить статус состояния активного экземпляра БД и её копии.

      image


      Проверка механизма Switchover

      После того как создано необходимое количество реплицируемых БД, мы можем проверить механизм переключения активных копий с одного сервера в группе DAG на другой (switchover). В нашем случае все активные копии БД в текущий момент находятся на сервере KOM-AD01-CM01. Выполним переключение активных копий на сервер KOM-AD01-CM02. Для этого в консоли Exchange Management Console в разделе Server Configuration > Mailbox выберем сервер с активными копиями и в меню Action выберем Switchover Server:

      image

      В открывшемся окне выбираем сервер, на который мы хотим переместить активные экземпляры всех БД. Если в группе DAG всего два сервера, то вполне можно выбрать вариант Automatically choose a target server.

      image

      После этого, сделав Refresh в консоли, мы увидим, что статус активности баз изменился, и теперь все активные экземпляры БД находятся на сервере KOM-AD01-CM02. Процедуру «переезда» активных копий обратно (с сервера KOM-AD01-CM02 на сервер KOM-AD01-CM01) можно выполнить так же и через Exchange Management Shell с помощью командлета Move-ActiveMailboxDatabase:

      Move-ActiveMailboxDatabase -Server "KOM-AD01-CM02"

      image


      Далее, перед вводом группы DAG в промышленную эксплуатацию так же не помешает выполнить и тестирование процедуры Failover-переключения активных копий БД между серверами участниками DAG, сымитировав отказ сервера являющегося носителем активных копий БД.

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

    Предыдущая страница Следующая страница