• PowerShell – Сравнение включённых правил брандмауэра на двух компьютерах

    Compare Windows Firewall rules with PowerShellСтолкнулся с ситуацией, когда в разборе полётов у одного из Hyper-V серверов с включенным брандмауэром Windows Firewall потребовалось сравнить  действующие правила с другим сервером. Первое, что пришло в голову - с помощью PowerShell удалённо через вызов Invoke-Command слить правила Windows Firewall с обоих серверов в текстовые файлы и затем сравнить их содержимое.

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

  • PowerShell – Получение информации о локальных пользователях и группах

    Чтобы быстро получить информацию о списке локальных пользователей на удалённом компьютере можно воспользоваться подключением через PowerShell к интерфейсу WMI с запросом в одну строку:

    Get-WmiObject Win32_UserAccount -ComputerName MyPC -Filter "Domain= MyPC'"

    Тоже самое, но уже при обращении к интерфейсу ADSI:

    $computerName = "MyPC"

    $computer = [ADSI]"WinNT://$computerName,computer" 

    $computer.psbase.Children | Where-Object { $_.psbase.schemaclassname -eq 'user' } | Format-Table Name, Description -autoSize

    Если нужно получить информацию с локального компьютера в переменной $computerName укажем значение "."

    По аналогии для получения списка локальных групп безопасности удалённого компьютера используем команду:

    Get-WmiObject Win32_Group -ComputerName MyPC -Filter "Domain='MyPC'"

    ..или

    $computerName = "MyPC"

    $computer = [ADSI]"WinNT://$computerName,computer" 

    $computer.psbase.Children | Where-Object { $_.psbase.schemaclassname -eq 'group' } | Format-Table Name, Description -autoSize

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

    $computerName = "MyPC"

    $computer = [ADSI]"WinNT:// $computerName,computer"

    $computer.psbase.children | where { $_.psbase.schemaClassName -eq 'group' } | foreach {

        write-host "Group:" $_.Name

        write-host "Descr:" $_.Description

        write-host "-----"

        $group =[ADSI]$_.psbase.Path

        $group.psbase.Invoke("Members") | foreach {

        $ADSIName = $_.GetType().InvokeMember("AdsPath", 'GetProperty', $null, $_, $null)

            if ($ADSIName -match "[^/]/[^/]") {

            [String]::Join("", $ADSIName.Split("/")[-2..-1])

            }

            else {

            $ADSIName.Split("/")[-1]

            }

        }

        write-host

    }

    Источники информации:

    Janel Blog - Script pour l'énumération des membres d'un groupe

    Powershellcommunity Forum - Listing local user accounts on remote machines

  • HP System Management Homepage - Установка FQDN Local Server Certificate

    imageПри установке HP System Management Homepage (SMH) по умолчанию использует самоподписанный сертификат, что приводит к паническим предупреждениям веб-браузеров. Встроенный механизм управления локальным сертификатом HP System Management Homepage непосредственно через веб-интерфейс, несмотря на свой почтенный срок существования, до сих пор не умеет формировать запрос на создание цифрового сертификата с атрибутом commonName в формате FQDN. Если для сравнения взять, например веб-интерфейс управления iLO2, то там такая возможность появилась в одном из предпоследних релизов firmware, что само по себе подаёт надежду на то, что технари HP таки одумаются и добавят такую возможность и в функционал HP System Management Homepage… А пока такой возможности нет, мы попробуем использовать альтернативный метод установки сертификата SMH, имеющего в качестве commonName FQDN имя сервера, подписанного нашим локальным доверенным центром сертификации.

    Проделаем несколько несложных действий:

    • Сгенерируем запрос на сертификат средствами OpenSSL к ЦС Windows;
    • Получим от ЦС файла сертификата (.cer) в формате X.509 Base-64;
    • Заменим сертификат в встроенном веб-сервере HP System Management Homepage

    Для того чтобы создать запрос к ЦС Windows нам понадобиться OpenSSL, а именно 3 файла из его состава – openssl.exe, ssleay32.dll, libeay32.dll. Сложим их в один каталог (например в каталог C:ToolsOpenSSL).

    Для подготовки запроса к ЦС создадим конфигурационный файл для OpenSSL - текстовый файл myopenssl.cfg со следующим содержимым:

    [ req ]
    distinguished_name = req_distinguished_name

    [ req_distinguished_name ]
    commonName = FQDN of server
    commonName_default = SERVER.mydom.com
    countryName = Country Name (2 letter code)
    countryName_default = RU
    0.organizationName = Organization Name (eg, company)
    0.organizationName_default = MyCompany
    localityName = Locality Name (eg, city)
    localityName_default = Syktyvkar
    organizationalUnitName = Organizational Unit Name (eg, section)
    organizationalUnitName_default = KOMI

    Как вы понимаете, в этом файле мы указываем параметры, которые нужны для идентификации запроса сертификата в ЦС, т.е. указываем имя сервера, которому требуется сертификат, имя организации и т.п.
    Для формирования запроса с закрытым ключом нам нужно получить собственно сам закрытый ключ используемый сервером в данный момент – файл file.pem (по умолчанию расположен в каталоге C:hpsslshare).
    Далее создаем запрос на сертификат с учётом подготовленных ранее параметров и ключевого файла командой:

    C:ToolsOpenSSL >openssl req -config myopenssl.cfg -new -key file.pem -out myreq.req

    clip_image002

    Полученный файл запроса myreq.req загружаем в центр сертификации Windows Server, где выдаем сертификат на загруженный запрос. Выгружаем из ЦС новый сертификат в файл с именем cert.pem в формате X.509 в кодировке Base-64.

    Файл cert.pem копируем в каталог, где HP SMH хранит файл самоподписанного сертификата (по умолчанию каталог C:hpsslshare). При этом имеющийся там файл на всякий случай сохраняем и переименовываем в cert.back.

    После этого на сервере с HP SMH перезапускаем службу HP System Management Homepage командами:

    Net stop SysMgmtHp
    Net start SysMgmtHp

    В итоге открываем HP System Management Homepage в вэб-браузере (по умолчанию URL типа https://server.mydom.com:2381/) и убеждаемся в том, что HP SMH использует определенный нами сертификат и предупреждения безопасности браузера отсутствуют.

  • Ошибка обработки GPP: Group Policy object did not apply because its targeting item failed with error code 0x86012004

    imageРанее уже описывалась проблема с обработкой Group Policy Preferences (GPP) в части применения нацеливания (Item-level targeting) на OU - Долгая обработка GPP на этапе “Applying Group Policy Drive Maps policy” на клиентах RODC Windows Server 2008 R2

    В ходе дальнейшей эксплуатации GPP для изменения членства группы Администраторов на доменных компьютерах описанная проблема проявила себя по аналогичному сценарию (при нацеливании на доменные OU). Чтобы уйти от этого, приняли решение использовать нацеливание на группы безопасности, то есть изменять членство группы Администраторов в зависимости от членства учетной записи компьютера в той или иной доменной группе безопасности. Однако после настройки GPP и применения на клиентских компьютерах с Windows 7 и Windows Server 2008 R2 обнаружилось, что данная настройка GPP не отрабатывает. Сбор трейсов GPP выявил ошибку обработки типа:

    Failed filter [FilterGroup]. [ hr = 0x86012004 "Клиентское расширение перехватило необрабатываемое исключение "filter expand" в: "Access violation (0xc0000005) occurred at 0xca12dad1; the memory at 0xca12dad1 could not be ????."%100790275" ]

    Как выяснилось, эта проблема известна уже почти год и описана в статье KB976399 - FIX: You cannot apply Group Policy settings on a computer that is running Windows 7 or Windows Server 2008 R2 when security group filters are used in Group Policy preference settings.

    К удивлению для себя выяснил, что данное обновление через WSUS не раскатывалось и для его применения MS предлагает воспользоваться отдельно загружаемым файлом исправления

    Имеющийся на данный момент перечень исправлений включенных в готовящийся к выпуску SP1 для Windows 7 и Windows Server 2008 R2 - Documentation for Windows 7 and Windows Server 2008 R2 Service Pack 1 Release Candidate (KB976932) говорит нам о том, что этот фикс туда включен. Так что ждём релиза SP1, а пока можем выбрать для себя либо вариант с отдельной установкой фикса на проблемных клиентов, либо опять же нужно выбирать альтернативные методы нацеливания.

  • Exchange Server 2007 – Просмотр статистики БД почтовых ящиков

    Для получения статистики об использовании почтовых ящиков пользователями организации в Exchange Server 2007 можно воспользоваться Exchange Management Shell и командлетами Get-MailboxDatabase и Get-MailboxStatistics.

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

    $MailBoxServer = "MyMailBoxServer"

    Get-MailboxDatabase | Where-Object {$_.ServerName -eq $MailBoxServer} | Select @{Label="SG Name";Expression={$_.StorageGroupName}}, @{Label="DB Name";Expression={$_.Name}}, @{Label="Mailboxes";Expression={(Get-Mailbox -Database $_.Identity | Measure-Object).Count}} , @{Label="DB Size";Expression={"{0:N2}" -f ((get-mailboxstatistics -database $_.Identity | Measure-Object -Property TotalItemSize,TotalDeletedItemSize -Sum | Select-Object Sum | Measure-Object -Property Sum -Sum).Sum.ToString() /1024KB)}} | Sort -Property "DB Name" | Format-Table –AutoSize

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

    $FullDBIdentity = "MyMailBoxServerMyStorageGroupMyDataBase"

    Get-MailboxDatabase -Identity $FullDBIdentity | Get-MailboxStatistics | Sort -Property TotalItemSize | Select DisplayName,@{label="TotalItemSize(MB)";expression={$_.TotalItemSize.Value.ToMB()}},ItemCount,StorageLimitStatus | Format-Table -AutoSize

     

    Если же нас интересует информация только о почтовых ящиках, у которых превышен лимит хранения почты, выполним скрипт:

    $FullDBIdentity = "MyMailBoxServerMyStorageGroupMyDataBase"

    Get-MailboxDatabase -Identity $FullDBIdentity | Get-MailboxStatistics | Where-Object {$_.StorageLimitStatus -ne "BelowLimit"} | Sort -Property TotalItemSize | Select DisplayName,@{label="TotalItemSize(MB)";expression={$_.TotalItemSize.Value.ToMB()}},ItemCount,StorageLimitStatus | Format-Table –AutoSize

     

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

    Exchange Server TechCenter - Get-MailboxDatabase: Exchange 2007
    Neil Hobson - Getting Mailbox Statistics in Exchange 2007
    Exchange Server Share Blog - Exchange 2007: Database Statistics in Powershell

    PowerShellCommunity Forums - Exchange Mailbox Database size

  • System Center DPM 2010 QFE Rollup KB2250444 (3.0.7706.00)

    imageВ первой половине Ноября появился пакет исправлений для DPM 2010 RTM – System Center DPM 2010 QFE Rollup (KB2250444) который изменяет версию DPM до 3.0.7706.00

    Описание: Description of the hotfix rollup package for System Center Data Protection Manager 2010: November 10, 2010
    URL для скачивания: System Center Data Protection Manager 2010 QFE Rollup

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

    Наконец то исправлена ошибка, с которой неоднократно приходилось сталкиваться - когда при создании Protection Group мы пытались изменить предлагаемые по умолчанию размеры партиций Replica volume и Recovery point volume – в некоторых случаях из этого ничего не выходило :)

  • SQL Server 2008 - Перенос файлов БД tempdb на отдельный диск

    imageПри планировании развертывания приложений активно использующих системную временную базу данных SQL Server tempdb, необходимо учитывать тот факт, что по умолчанию файлы этой БД расположены на системном диске. Соответственно для того чтобы избежать в будущем возможных проблем, связанных с переполнением системного диска из-за увеличения размера файлов tempdb, нам по возможности нужно выделить для файлов этой БД отдельное логическое дисковое пространство.

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

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

    По умолчанию БД tempdb настроена на авто-расширение (Autogrow) и при каждой перезагрузке SQL Server пересоздаёт файлы этой БД с минимальным размером инициализации (Initial Size). Опираясь на рекомендации вышеуказанного документа, мы увеличим размер инициализации файлов tempdb таким образом, чтобы свести к минимуму затраты системных ресурсов на операции авто-расширения.

    Для того чтобы определить где в текущий момент физически располагаются файлы БД tempdb, откроем  SQL Server Management Studio и выполним SQL запрос:

    SELECT name, physical_name AS CurrentLocation

    FROM sys.master_files

    WHERE database_id = DB_ID(N'tempdb');

    GO

    Получим примерно такой результат:

    image

     

     

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

    USE master;

    GO

    ALTER DATABASE tempdb

    MODIFY FILE (NAME = tempdev, FILENAME = 'H:TempDB_Datatempdb.mdf' , SIZE = 10240);

    GO

    ALTER DATABASE tempdb

    MODIFY FILE (NAME = templog, FILENAME = 'I:TempDB_Logtemplog.ldf' , SIZE = 3072);

    GO

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

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

    SELECT name, physical_name AS CurrentLocation, size, state_desc

    FROM sys.master_files

    WHERE database_id = DB_ID(N'tempdb');

     

    Если всё нормально, результат должен быть примерно таким:

    image

     

     

     

    После этого необходимо удалить файлы tempdb.mdf и templog.ldf с их старого месторасположения.

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

    MSDN Library- Moving System Databases

    MSDN Library - How to: Move a Database Using Detach and Attach (Transact-SQL)

    KB224071 - How to move SQL Server databases to a new location by using Detach and Attach functions in SQL Server

  • SCOM 2007 R2 – Пакетный перевод агентов в Maintenance Mode

    imageВ окружении с большим количеством агентов мониторинга SCOM 2007 R2 массовый перевод этих агентов  в режим обслуживания (Maintenance Mode) через UI консоль может стать весьма хлопотным занятием. На помощь в таком случае как всегда приходит Operations Manager Shell.

    Например, для того чтобы перевести в Maintenance Mode все сервера в имени которых встречается “SQL”, с текущего момента сроком на 2 часа в Operations Manager Shell можно выполнить следующий нехитрый скрипт:

    $Time1 = [DateTime]::Now

    $Time2 = $Time1.AddMinutes(120)

    $Agents  = Get-Agent | Where {$_.Name –match "SQL"}

    $Agents | foreach {New-MaintenanceWindow -StartTime $Time1 -EndTime $Time2 -Reason "PlannedOther" -Comment "Maintenance Mode Window" -MonitoringObject $_.HostComputer}

    Здесь вместо функции AddMinutes() можно также использовать AddHours() и AddDays()

    Или другой пример, когда необходимо указать конкретный диапазон дат:

    [DateTime] $Time1 = "11/23/2010"

    $Time1 = $Time1.ToUniversalTime()

    [DateTime] $Time2 = "11/28/2010"

    $Time2 = $Time2.ToUniversalTime()

    $Agents  = Get-Agent | Where {$_.Name –match "SQL"}

    $Agents | foreach {New-MaintenanceWindow -StartTime $Time1 -EndTime $Time2 -Reason "PlannedHardwareMaintenance" -Comment "Hardware Maintenance" -MonitoringObject $_.HostComputer}

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

    %SYSTEMROOT%system32WindowsPowerShellv1.0powershell.exe C:MaintenanceModeStartMaintenanceModeWindow.ps1

    Так же для того чтобы скрипт успешно отработал при таком вызове из планировщика задач, в начало скрипта следует добавить строки инициализации командлетов Operations Manager Shell и вызов подключения к корневому серверу управления SCOM (RMS):

    $RMSServer = 'RMSServerName'

    Add-PSSnapin "Microsoft.EnterpriseManagement.OperationsManager.Client";

    Set-Location "OperationsManagerMonitoring::";

    New-ManagementGroupConnection -ConnectionString:$RMSServer;

    Set-Location $RMSServer;

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

    System Center TechCenter - How to Put a Monitored Object into Maintenance Mode in Operations Manager 2007

    System Center TechCenter- Operations Manager 2007 R2 Cmdlets - New-MaintenanceWindow

    Collection of Maintenance Mode Scripts, Utilities and MPs for Opsmgr and Essentials 2007 (Updated for SCOM 2007 R2)

    System Center Operations Manager Forums > Extensibility > Setting all entities to maintenance based on a particular class

  • SCOM 2007 R2 – Изменение статуса ManuallyInstalled для агентов

    В некоторых случаях может возникнуть ситуация, когда по каким-то причинам произведена ручная установка агентов SCOM на ряд компьютеров. Для таких агентов в UI консоли недоступны опции смены основного сервера управления (Change Primary Management Server), восстановления (Repair) и удаления (Uninstall). Помимо этого после применения новых кумулятивных обновлений (CU) такие агенты не будут переходить в режим принудительного обновления, что опять же потребует их обновления «в рукопашную». Получить список таких агентов можно как в UI консоли, так и в  Operations Manager Shell:

     

    Get-Agent | where {$_.ManuallyInstalled -match ‘true’} | ft name,ManuallyInstalled

     

    Для повышения централизованной управляемости нам потребуется изменить статус ручной установки для таких агентов. Через UI консоль это сделать невозможно by design. Через Operations Manager Shell у нас в данном случае также не получится изменить данное свойство, так как оно установлено как ReadOnly. Для решения данной задачи можно воспользоваться советом из блога Кевина Холмана: Kevin Holman's OpsMgr Blog - How to get your agents back to "Remotely Manageable" in OpsMgr 2007 R2

     

    Для того чтобы вывести список агентов установленных вручную, подключимся к базе данных «OperationsManager» и выполним запрос:

     

    SELECT bme.DisplayName FROM MT_HealthService mths

    INNER JOIN BaseManagedEntity bme ON bme.BaseManagedEntityId = mths.BaseManagedEntityId

    WHERE IsManuallyInstalled = 1

     

    Для того чтобы изменить статус всех вручную установленных агентов, выполним запрос:

     

    UPDATE MT_HealthService

    SET IsManuallyInstalled=0

    WHERE IsManuallyInstalled=1

     

    Если же мы не хотим менять статус для всех агентов, а лишь для одного какого то конкретного агента, выполним запрос:

     

    UPDATE MT_HealthService

    SET IsManuallyInstalled=0

    WHERE IsManuallyInstalled=1

    AND BaseManagedEntityId IN

    (SELECT BaseManagedEntityID FROM BaseManagedEntity

    WHERE BaseManagedTypeId = 'AB4C891F-3359-3FB6-0704-075FBFE36710'

    AND DisplayName = 'agentname.domain.com')

     

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

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

  • SCOM 2007 R2 – Включение Agent Proxy на группе агентов

    imageПо мере начала использования новых пакетов управления (MP) в SCOM, может возникнуть необходимость включения  механизма «Agent Proxy» на группе агентов, например, когда мы используем MP для мониторинга AD, нам необходимо включить проксирование для всех агентов, имеющих роль контроллеров домена.

    При большом количестве агентов, сделать это в UI консоли -  не самый лучший вариант, так как у нас есть Operations Manager Shell.

    Например, для того чтобы получить информацию о том в каком состоянии находится значение атрибута «ProxyingEnabled» на агентах, содержащих в имени «dc» в консоли Operations Manager Shell  выполним:

    Get-Agent | where {$_.computerName -match 'dc'} | ft name,proxyingEnabled

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

    $Agents = Get-Agent | where {$_.computerName -match 'dc'}

    $Agents | foreach {$_.ProxyingEnabled = $true}

    $Agents | foreach {$_.ApplyChanges()}