Продолжая тему.
В связи с тем, что в мае официально вышел Office 2010 возникла необходимость распространять список безопасных отправителей с контроллера домена и на Outlook 2010. Для этого придётся скачать административные шаблоны для Office 2010 и внести в шаблон outlk14.adm:

POLICY !!L_JunkMailImportList
KEYNAME "software\policies\microsoft\office\14.0\outlook\options\mail"
PART !!L_Checktoimportjunkmaillists CHECKBOX
VALUENAME "JunkMailImportLists"
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END PART
EXPLAIN !!L_JunkMailImportListExplain
END POLICY

кроме этого в секцию [Strings] надо внести следующее:

L_JunkMailImportList="Junk Mail Import List"
L_Checktoimportjunkmaillists="Check to import junk mail lists"
L_JunkMailImportListExplain="Your should enable Import List to add SafeSenders List file"

Пользователя AD можно добавлять в группы другого домена (доменные локальные или универсальные), который находится в том же лесу, что и домен пользователя. Правда, MS советует в такой ситуации использовать глобальную группу, которая находится в том же домене что и пользователь; пользователя добавлять в неё, а саму группу добавлять в группу из другого домена. Если же не прислушиваться к такому совету, то возникает забавная коллизия – в свойствах пользователя на закладке Member Of группа из другого домена не отображается, хотя на закладке Members группы другого домена пользователь есть! Этому даже посвещена одна из статей на сайте поддержки MS.

Как же посмотреть полный список групп пользователя? В вышеуказанной статье предлагается использовать утилиту showgrps.exe из состава ресурскита для Windows 2000 Server. А что делать если такого ресурскита нет и на дворе 2010 год? Видимо использовать PoSh. У меня для этих целей получился такой вот немного корявый скрипт:

$EntAdminCred = Get-Credential
$User = Get-QADUser domain\user -DontUseDefaultIncludedProperties

Connect-QADService -Service FQDN.domain.controller1 -Credential $EntAdminCred
Get-QADGroup -ContainsIndirectMember $User.DN -DontUseDefaultIncludedProperties | Select-Object NTAccountname
Disconnect-QADService

Connect-QADService -Service FQDN.domain.controller2 -Credential $EntAdminCred
Get-QADGroup -ContainsIndirectMember $User.DN -DontUseDefaultIncludedProperties | Select-Object NTAccountname
Disconnect-QADService

Блок connect/disconnect использовать столько раз – сколько доменов в лесу. $EntAdminCred – логин/пароль администратора, который имеет доступ к учётным записям всех доменов.

Сделал миграцию (p2v) контроллера домена (Windows 2003 R2 x64 Ent) с помощью SCVMM 2008 R2 на сервер Hyper-V на базе Windows 2008, потом импортировал эту виртуалку на сервер Hyper-V на базе Windows 2008 R2. После этого (и может и сразу после миграции – к сожалению не отследил виртуалка выпадает в BSOD. Ошибку пишет:

STOP: 0x0000007B (0xFFFFFADFEA40F3C0,0xFFFFFFFFC0000034,0×0,0×0).

Делаю загрузку последней успешной конфигурации – грузится, но отсутствуют все устройства, которые устанавливаются Integrational Services. Через Add/Remove Program удаляю сервисы интеграции. Перегружается успешно. Ставлю их опять – находятся все устройства, но при перезагрузке опять появляется BSOD. Как лечить? Переустановить не получится (DC).

На форумах технета навели на отличнейшую ссылку, которая проблему и решила. Решение выглядит следующим образом:

1. Загружаем виртуалку в режиме LastKnownGoodConfiguration.
2. Открываем реестр и смотрим следующий ключ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Wdf01000
3. Он должен иметь значение WdfLoadGroup. В моем случае (и у автора статьи из ссылки) там было base. Меняем на WdfLoadGroup.
4. Удаляем Integration Components.
5. Перегружаем виртуалку в обычном режиме.
6. Устанавливаем Integration Components заново.

По словам автора статьи, проблема была в том, что для загрузки драйвера хранилища требовалось подгрузить Windows Driver Framework (WDF), который не подгружался. Соответственно, не загружался драйвер хранилища, поэтому операционная система при запуске и вываливалась в BSOD с ошибкой о недоступности загрузочного устройства. Причиной же этого было некорректное значение соответствующего ключа реестра.

Наконец-таки дошли руки до интеграции SCVMM и OpsMgr. По идее, процесс выглядит достаточно просто – на сервере с OpsMgr ставится интеграционная компонента с диска SCVMM, на сервере с SCVMM ставится консоль OpsMgr. Затем в консоли SCVMM указывается корневой сервер OpsMgr. Всё выглядит просто в случае установки обоих продуктов на один сервер. Если же сервера разные, кроме этого базы хранятся на третьем сервере, то начинаются разные весёлые приключения.

Сам процесс интеграции в простейшем случае (всё на одном сервере) можно посмотреть здесь.

У меня же процесс интеграции застрял на этапе указания корневого сервера OpsMgr. Попытка возвращала ошибку «VMM service does not have necessary privileges to access the Operations Manager SDK service on <servername>. Add VMM service account as an administrator to the Operations Manager Server and try the operation again». Ниже небольшое описание того, как я ошибку победил.

1. Добавляем в группу локальных администраторов на корневом сервере OpsMgr сервисную учётную запись VMM.

2. Нужно дать права на чтение и на запись SPN для сервисной учётной записи OpsMgr SDK. Делается это через ADSIEdit следующим образом:

• В разделе Default naming context ищем сервисную учётную запись OpsMgr SDK.
• В её свойствах на закладке Security переходим в расширенные настройки (кнопка Advanced).
• Добавляем учётку SELF, на закладке Properties указываем область применения – This object only. Ставим галки Allow напротив Read servicePrincipleName и Write servicePrincipleName.
• После этого надо перезапустить сервис System Center Data Access на корневом сервере OpsMgr.

3. Создаём доменную глобальную группу VMMAdmins, добавляем в неё сервисную учётную запись VMM и учётную запись сервера VMM (объект компьютер).

4. Добавляем эту группу в Operations Manager Administrators через консоль OpsMgr (Administration => Security => User Roles => Operation Manager Administrators). Опять перезапускаем System Center Data Access (net stop OMSDK && net start OMSDK).

5. Перезапускаем сервер SCVMM, после этого через консоль VMM добавляем сервер OpsMgr (или через PoSh – Set-VMMServer -VMMServer <SCVMM Server> -OpsMgrServer <OpsMgr RMS Server>).

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

В настройках Junk E-mail в Outlook есть возможность составлять списки безопасных отправителей, письма от которых не будут проверяться локальным спам-фильтром. Кроме этого, в административных шаблонах Outlook 2003 и Outlook 2007 для групповых политик есть пункт «Specify path to Safe Senders list». По идее, в нём можно указать путь до файла txt со списком безопасных отправителей (список в формате: одна строка – одна запись). По умолчанию, этот список добавляется к существующему списку пользователя. Если нужно его подменить (то есть старые записи удалить и оставить только те, которые есть в txt файле) – необходимо задействовать настройку «Overwrite or Append Junk Mail Import List». Что удивительно – при включении этих пунктов ничего не произошло. Хотя в реестре появились необходимые ключи. После небольшого поиска наткнулся на причину этого странного поведения «The GPO is missing a key setting (…) after the GPO approach didn’t work. The missing registry value is JunkMailImportLists (DWORD). To make it available to your policy object, you’ll need to modify the Outlk11.adm file to add the following policy information». Итого, в сухом остатке, необходимо внести в шаблоны групповых политик (outlk11.adm и outlk12.adm) следующее: для outlk11.adm

POLICY "Junk Mail Import List"
PART "Check to import junk mail lists" CHECKBOX
VALUENAME JunkMailImportLists
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END PART
END POLICY

для outlk12.adm

POLICY !!L_JunkMailImportList
PART !!L_Checktoimportjunkmaillists CHECKBOX
VALUENAME JunkMailImportLists
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END PART
EXPLAIN !!L_JunkMailImportListExplain
END POLICY

кроме этого в outlk12.adm в секцию [Strings] надо внести следующее

L_JunkMailImportList="Junk Mail Import List"
L_Checktoimportjunkmaillists="Check to import junk mail lists"
L_JunkMailImportListExplain="Your should enable Import List to add
SafeSenders List file"

В итоге RSOP выдаст примерно следующее:

Microsoft Office Outlook 2003/Tools | Options…/Preferences/Junk E-mail

    Junk Mail Import List Enabled
        Check to import junk mail lists Enabled

    Overwrite or Append Junk Mail Import List Disabled
    Specify path to Safe Senders list Enabled
        Specify full path and filename to Safe Senders list \\DC\NETLOGON\SS.txt

Microsoft Office Outlook 2007/Tools | Options…/Preferences/Junk E-mail

    Junk Mail Import List Enabled
        Check to import junk mail lists Enabled

    Overwrite or Append Junk Mail Import List Disabled
    Specify path to Safe Senders list Enabled
        Specify full path and filename to Safe Senders list \\DC\NETLOGON\SS.txt

Понеслась…

Предположим, что у нас имеется удалённый офис. Офис немаленький, следовательно мы можем туда поставить полноценный контроллер домена. Кроме этого, удалённый офис будет поддерживать местная команда IT-специалистов и для ограничения их доступа только локальными ресурсами удалённого офиса выделим им отдельный домен в общем лесу. Задача имеет несколько путей решения и решается в 2 стадии. Попробуем решить задачу используя графические средства Windows 2008 Server (задача так же может быть решена утилитами командной строки или средствами файлов автоответов). Сначала надо будет создать отдельный сайт для удалённого офиса, потом в удалённом офисе установить будущий контроллер домена, включить его в наш основной домен и повысить его до контроллера домена параллельно создав новый корневой домен. Continue Reading »

1. Настройки сети. У нас для каждого узла кластера используется по 2 сетевых карты. Одна для доступа в рабочую сеть (Public), вторая для доступа во внутреннюю служебную сеть кластера (Private), которая используется для тактовых импульсов между узлами кластера. Для начала надо поставить правильный порядок доступа сервисов к нашим сетевым соединениям. Continue Reading »

Как и в Windows 2003 Server обновление схемы леса выполняется командой adprep. Расположена она на установочном диске в папке \sources\adprep. Обновление выпоняется в несколько шагов.

1. Обновление схемы. Выполняется на мастере схемы с помощью adprep /forestprep. На мастере схемы должно быть установлено как минимум Windows 2000 Server sp4. Если в лесу имеются серверы с Exchange 2000, то имеет смысл ознакомиться со статьёй «Обновление контроллеров домена Windows 2000 до Windows Server 2003″. Выполняется из под учётной записи, состоящей в группах Domain Admin, Schema Admin и Enterprise Admin корневого домена леса. Если в лесу несколько доменов и/или сайтов, то имеет смысл проверить корректную работу репликации с помощью repadmin /showreps. Результат выполнения adprep будет примерно следующий:

2. Обновление доменов. Выполняется на компьютере, который имеет доступ к мастеру инфраструктуры командой adprep /domainprep /gpprep. Выполняется из под учётной записи с правами администратора домена, в котором проводим обновление. Выполнение выглядит следующим образом:

3. Обновление инфраструктуры для подготовки к установке контроллеров домена только для чтения (rodc). Выполняется на компьютере, который имеет доступ к мастеру инфраструктуры командой adprep /rodcprep. Запускается с правами доменного администратора и администратора предприятия.

Шаг 3 может быть выполнен без первых двух, но этого делать крайне не рекомендуется. Второй шаг нужно делать после завершения репликации, после обновления схемы. Как минимум мастер инфраструктуры должен эти обновления получить. Кроме этого, на компьютерах, с которых запускается adprep нужно использовать дистрибутив с той же архитектурой, что и на самом компьютере. adprep с 64-битного дистрибутива на 32-битном контроллере домена просто не запустится либо выдаст ошибку. То же самое касается языка. Если контроллер домена англоязычный – запускать на нём adprep надо с англоязычного дистрибутива, если русский – то с русского.

Обнаружил сегодня в Гугль-Ридере с одной статье пару команд для определения типа OS и её архитектуры. Обе запускаются из командной строки. Тип OS определяется следующим образом:

wmic OS get OperatingSystemSKU

Команда возвращает числовое значение. Для Windows 2008 Server они следующие:

• 7 = Windows Server 2008 Standard Edition (full installation)
• 8 = Windows Server 2008 Datacenter Edition (full installation
• 10 = Windows Server 2008 Enterprise Edition (full installation)
• 12 = Windows Server 2008 Datacenter Edition (core installation)
• 13 = Windows Server 2008 Standard Edition (core installation)
• 14 = Windows Server 2008 Enterprise Edition (core installation)
• 42 = Hyper-V Server 2008

Более подброно модно посмотреть здесь. Тип архитектуры так:

wmic OS get OSArchitecture

Команда возвращает тип архитектуры (32- или 64-битная).