ge][

Outlook 2010, ошибка с сертификатом

2011-11-15T04:02:00.001-08:00

Оказывается Outlook 2010 не работает с самоподписанными сертификатами, в независимости являются ли они доверенными или нет.
В данном случае самоподписанными стоит считать сертификаты выданные сами себе и с Basic Constraints = "End Entity"

Outlook 2010 отображает следующее сообщение:

При этом другие службы Exchange работают без каких-либо проблем, например, OWA, autodiscover и т.д. С сертификатом все в порядке: доверие есть, не просрочен, с именами все в порядке.

Решением проблемы было выпуск сертификата Центром Сертификатов.

Генри Вальтер пишет: http://blogs.msexchange.org/walther/2010/05/18/certificate-warning-when-using-self-signed-exchange-certficate-and-outlook-2010/
а Microsoft молчит.

Трансляция пользователей в SQL 2000 (миграция)

2011-09-09T05:48:00.000-07:00

TSQL-скрипт предназначенный для трансляции Windows-пользователей и Windows-групп в SQL Server 2000.

Ссылка на скрипт: http://pastebin.com/hwc4bgZX
Важно: Не забывайте делать резервные копии :)

1. Проблема.
При миграции пользователей между лесами (доменами) основной SID пользователя меняется. Если сохраняется SID-History, то проблем не возникает. Но если далее удалить SID-history, то у пользователя может пропасть доступ к определенным ресурсам. Один из них - SQL-сервер.
Для таких ресурсов как файловые серверы есть соответствующие мастеры для смены основного старого SID в ACL на новый (ADMT, Security Translation Wizard). Но для SQL-а таких средств (известных мне) нет.
Данный скрипт решает эту проблему.

2. Как работает?
Вы запускаете скрипт. Он находит Windows-пользователей (logins) в SQL-сервере и пытается получить всех пользователей из целевого домена (получается смигрированных). Поиск происходит по логинам (sAMAccountName). Если пользователь (login) не создан в SQL, то происходит создание пользователя.
Далее происходит перебор всех баз и связывание пользователей (user) с новыми login'ами, по sid.
Старые пользователи (login) не удаляются из SQL-сервера.
Можно производить трансляцию при миграции баз данных, в том числе и системных (master) между серверами (при использовании локальных аккаунтов в качестве login).

3. Ограничения.
- Работает только с SQL Server 2000.
- Работает только если логины пользователей из старого и нового домена совпадают.
- Не транслирует системные таблицы (master, msdb, model, tempdb

4. Как запустить?
Сначала необходимо изменить переменные @SourceDomain и @TargetDomain на исходный и целевой домен соответственно.
Далее необходимо запустить скрипт. Это можно сделать с помощью инструментов SQL Query Analyzer, osql и др.

--Текст скрипта
---------------------------------------------------------
exec sp_configure 'allow_update',1
reconfigure with override
go

declare @SourceDomain nvarchar(255), @TargetDomain nvarchar(255)
set @SourceDomain = 'INTERMARK'
set @TargetDomain = 'CORP'

select name as SourceName, REPLACE(name,@SourceDomain + '\',@TargetDomain + '\') as TargetName,
    sid as SourceSID, SUSER_SID(REPLACE(name,@SourceDomain + '\',@TargetDomain + '\')) as TargetSID
into #Temp1
from master..syslogins
where (name like (@SourceDomain + '\%') or name like (@TargetDomain+'\%'))
    and SUSER_SID(REPLACE(name,@SourceDomain + '\',@TargetDomain + '\')) is not null
    and isntname = 1

declare Logins cursor local forward_only static
for
    select t1.TargetName
    from #Temp1 t1
    where not exists (select null from #Temp1 t2 where t1.TargetName = t2.SourceName)

open Logins

declare @logname nvarchar(255)

fetch next from Logins into @logname

    while @@FETCH_STATUS = 0
    begin
        exec sp_grantlogin @loginame = @logname
        fetch next from Logins into @logname
    end

close Logins
Deallocate Logins

declare Dbs cursor local forward_only static
for
    select name
    from sysdatabases
    where name not in ('master','model','tempdb','msdb')
    --where name in ('Northwind')

open Dbs

    declare @name sysname
    fetch next from Dbs into @name

    declare @sql_text nvarchar(4000)

    while @@fetch_status=0
    begin
        select 'Обработка базы ' + @name + ':'

        set @sql_text = 'select ' + QUOTENAME(@name,'''') + ' as dbname, ' +
            ' u.name as UserName, t1.SourceSID, t1.TargetSID from #Temp1 as t1 join ' +
            QUOTENAME(@name) + '..sysusers u on t1.SourceSID = u.sid'

        execute(@sql_text)

         set @sql_text = 'update users ' +
             ' set sid = t1.TargetSID' +
             ' from ' + QUOTENAME(@name)+ '..sysusers as users ' +
             ' join #Temp1 t1 on users.sid = t1.SourceSID '

        execute(@sql_text)

        fetch next from Dbs into @name
    end

close Dbs
deallocate Dbs

drop table #Temp1

exec sp_configure 'allow_update',0
reconfigure with override
go
---------------------------------------------------------

Сбор сведений об Active Directory

2011-08-23T05:46:00.000-07:00

Иногда необходимо быстро собрать информацию об Active Directory.
Средств для сбора информации очень много.
Есть Active Directory Topology Diagrammer, но чтобы им пользоваться нужно установить Visio, плюс информация графическая, что тоже может не устроить.
Есть dcdiag, netdom, repadmin и т.д., но выдаваемая информация текстовая и не структурированная (это понятно, утилиты же для диагностики, а не для сбора информации, (или для конфигурирования)).
А хотелось бы, чтобы эта информация была хорошо структурирована, и чтобы ее можно было выгрузить или скопировать куда-либо в отчет, например, в отчет об обследовании.

Для этого написал небольшой скриптец, на powershell. Присутствует привязка к powershell, но сейчас все начинают переходить на 2008 r2 (или Windows 7), а там powershell предустановлен (даже 2.0). Если нет, то придется устанавливать.

Требования к скрипту:
- Powershell 1.0
- Net framework 2.0
- права администратора домена (можно обойтись обычным пользователем, но тогда не будет определенной информации)

Что делает скрипт? Вы ему указываете с какого леса (лесов) AD собрать информацию, он ее собирает и выгружает в xml-файл. В поставке идет трансформатор-xml - xsl-файл. С помощью этого файла вы можете получить информацию в удобном и читаемом (на мой взгляд) виде.

Гибкость в том, что если вы хотите поменять отображение, вам необходимо написать свой xsl-файл, при этом информацию заново собирать не нужно, скрипт переписывать не нужно.

Как запустить?
1) распаковываете архив (далее будем считать что вы распаковали в папку c:\temp)
2) запускаем powershell.exe
3) выполняем cd c:\temp\audit
4) выполняем .\ad_report.ps1 -forestlist "dns-имя_леса"
5) открываем каталог c:\temp\audit и открываем сформированный xml-файл с помощью веб-обозревателя (например, Internet Explorer)

Далее можно смотреть результат или скопировать куда-либо, например, в Excel/Word.
Если на этапе 4 появится сообщение о невозможности выполнить скрипт, убедитесь, что разрешен запуск неподписанных скриптов. Для разрешения запуска неподписанных скриптов необходимо выполнить команду Set-ExecutionPolicy RemoteSigned. После этого продолжить с шага 4.

Некоторые дополнительные возможности:
1) Запуск для сбора с нескольких лесов AD:
.\ad_report.ps1 -forestlist "dns-имя_леса1","dns-имя_леса2","..."
2) Можно указать другой выходной файл:
.\ad_report.ps1 -forestlist "dns-имя_леса1","dns-имя_леса2","..." -resultfile "имя_файла.xml"
3) Можно указать другой трансформатор, тогда его имя попадет в результирующий xml-файл (по-умолчанию, туда попадает файл ad_report.xsl):
.\ad_report.ps1 -forestlist "dns-имя_леса1","dns-имя_леса2","..." -resultfile "имя_файла.xml" -xslfile "трансформатор.xsl"
4) если вы укажете несколько лесов в параметре -forestlist, то сформируется один результирующий файл для всех указанных лесов, можно сформировать для каждого леса отдельный, вот так:
"dns-имя_леса1","dns-имя_леса2","..." | foreach { .\ad_report.ps1 -forestlist $_ -resultfile "имя_файла$($_).xml" -xslfile "трансформатор.xsl"

Файл для скачивания:
http://ifolder.ru/25343914

Миграция базовой инфраструктуры Microsoft. Часть 2.

2011-06-03T15:21:00.000-07:00

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

Первую часть можно найти по следующей ссылке – http://gexeg.blogspot.com/2011/05/microsoft-1.html

Аутентификация.

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

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

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

Помимо определения направления, вам необходимо определить тип доверительных отношений. Внешние доверительные отношения могут создаваться между лесами и доменами (non-Windows Kerberos-сферы – третий тип, но к нам он не относится).

Если уровни лесов Windows Server 2003 или выше, то мы можем создать доверительные отношения уровня леса. Такие доверительные отношения создаются в корневых доменах леса и являются транзитивными на уровне корневых доменов. Это означает, что все домены из одного леса, будут доверять доменам другого (доверяемого) леса. На уровне лесов, если брать их как единый объект, транзитивности нет.

Если уровень леса ниже Windows Server 2003 и повысить его нельзя ни при каких условиях, то придется создавать внешние доверительные отношения между доменами. Минус по сравнению с доверием между лесами очевиден – таких доверительных отношений необходимо создать больше.

Способов создания доверительных отношений достаточно много: оснастка Active Directory Domains and Trusts, скрипты, утилита netdom, использование различных API (Win32 API, классы .Net Framework) и т.д.

Стоит отметить, что утилита netdom не умеет создавать доверительные отношения между лесами, поэтому вам придется воспользоваться другими способами. Самый простой из них это оснастка Active Directory Domain and Trusts. Подробнее о создании доверительных отношений на уровне леса – http://technet.microsoft.com/en-us/library/cc780479%28WS.10%29.aspx.

А вот для создания доверительных отношений между доменами netdom подойдет.
Создаем односторонние доверительные отношения:

Netdom trust “source.com” /d:”target.com” /ud:”администратор target.com” /pd:”пароль администратора target.com” /uo:”администратор source.com” /po:”пароль администратора source.com” /add

Добавляем /twoway и получаем двухсторонние доверительные отношения.

Основными структурами защиты доступа к данным, таким как файлы, принтеры, реестр, являются избирательные списки контроля доступа – DACL (Discretionary Access Control List). Элементы из DACL описывают уровень доступа, который будут иметь участники безопасности при обращении к защищенным данным. Участники безопасности представлены в виде идентификаторов безопасности– SID (Security Identifier). В Active Directory такие идентификаторы есть у объектов групп, пользователей, компьютеров. При миграции, в целевой инфраструктуре создаются новые учетные записи с новыми идентификаторами безопасности (далее основной SID). И получается, что доступ к данным у учетных записей с новыми SIDами должен пропасть. Но есть возможность перенести старые идентификаторы, сохранив их в атрибуте SIDHistory (назовем их вторичными SIDами). Контроль доступа к данным учитывает оба типа SIDов. Доступ к данным в этом случае должен сохраниться.

С одной стороны SIDHistory штука хорошая, с другой стороны создает определенные проблемы с безопасностью. Получается, что сисадмин из доверяемого домена может прописать в SIDHistory идентификатор полномочной учетной записи из доверяющего домена, и тем самым, получит доступ к каким-либо важным данным. Чтобы от этого защититься, придумали функционал фильтрации SIDов. Первый – фильтрация только SIDHistory, а второй, более строгий – фильтрация всех «инородных» SIDов. Инородными считаются идентификаторы, не относящиеся к доверяемому домену.

Для доверительных отношений на уровне лесов (forest trusts) определена только фильтрация вторичных SIDов, для внешних доверительных отношений (external trusts) фильтрация всех «неродных SIDов». В случае с внешними доверительными отношениями к фильтруемым SIDам будут относиться идентификаторы из SIDHistory и идентификаторы универсальных групп. Такое поведение называют карантином (Quarantine). Включается этот карантин для всех внешних доверительных отношений, создаваемых на контроллерах домена под управлением Windows Server 2000 SP4 или выше.

Почему возникают проблемы с универсальными группами? Происходит это по той причине, что пользователь может быть членом универсальных групп из любого домена в пределах леса. Соответственно, если пользователь входит в универсальную группу из другого домена, то в TGT-referral попадут SIDы других доменов. Структуры TGT относятся к аутентификации по протоколу Kerberos. В этих структурах находятся списки идентификаторов пользователя (первичных и вторичных), а также список идентификаторов групп (первичных и вторичных) членом которых является пользователь. TGT-referral относятся к структурам Kerberos, которые пересылаются в другой домен. Во время создания доверительных отношений создаются TDO-объекты (Trusted Domain Objects). В этих объектах и содержится информация об идентификаторе доверяющего домена. Принимающий домен (доверяющий) производит фильтрацию SID и удаляет все SID, которые не относятся к доверяемому домену.

Фильтрация применяется и к аутентификации по протоколу NTLM. Сам процесс аутентификации NTLM несколько отличается от Kerberos.

А почему с forest trust нет проблем с универсальными группами? Это не происходит, потому что в TDO-объектах доверительных отношений между лесами (forest trust) хранятся идентификаторы безопасности каждого домена доверяемого леса. Соответственно идентификаторы универсальных групп будут входить в этот список и отфильтровываться не будут. А что случится с SIDHistory, сформированным в результате миграции внутри леса (intraforest migration)? За счет все той же информации из TDO, такие идентификаторы будут считаться родными (только в случае с forest trust), поэтому проблем не возникнет. Получается, что поведение фильтрации EnableSidHistory не совсем соответствует своему названию. Название «карантин» (Quarantine) все же больше подходит, по крайней мере предназначение тоже самое – фильтрация всех неродных SIDов.

Подробнее о нецелевом использовании SIDHistory - http://gexeg.blogspot.com/2009/12/active-directory.html
Подробнее о работе доверительных отношений - http://technet.microsoft.com/ru-ru/library/cc738955%28v=ws.10%29.aspx
Подробнее о протоколе Kerberos - http://technet.microsoft.com/ru-ru/library/cc739058%28v=WS.10%29.aspx
Подробнее о протоколе NTLM - http://davenport.sourceforge.net/ntlm.html

Отдельное спасибо читателю, ник которого Argon. Указал на ошибку с фильтрацией SID, что заставило меня разобраться в этом раз и навсегда :)

Существует множество инструментов, которые позволяют мигрировать объекты безопасности Active Directory, сохраняя SID в SIDHistory. Вот некоторые из них: ADMT, sidhist.vbs, sidewalk.exe. Две последние утилиты из набора Support Tools. Все эти инструменты используют функцию DsAddSidHistory из библиотеки Ntdsapi.dll. Функция документированная, описана здесь - http://msdn.microsoft.com/en-us/library/ms675918(VS.85).aspx

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

Отключить фильтрацию можно с помощью утилиты netdom. Если у вас доверительные отношения между лесами (forest trust), то необходимо выполнить следующую команду:

Netdom trust source.com /d:target.com /ud:”администратор target.com” /pd:”пароль администратора target.com” /uo:”администратор source.com” /po:”пароль администратора source.com” /EnableSidHistory:yes

Если необходимо проверить статус фильтрации SID введите туже самую команду, но без параметра yes:

Netdom trust source.com /d:target.com /ud:”администратор target.com” /pd:”пароль администратора target.com” /uo:”администратор source.com” /po:”пароль администратора source.com” /EnableSidHistory

Если у вас внешние доверительные отношения (external trust), то поможет следующая команда (/Quarantine:no):

Netdom trust source.com /d:target.com /ud:”администратор target.com” /pd:”пароль администратора target.com” /uo:”администратор source.com” /po:”пароль администратора source.com” /Quarantine:no

Проверить статус можно с помощью параметра /Quarantine без значения no:

Netdom trust source.com /d:target.com /ud:”администратор target.com” /pd:”пароль администратора target.com” /uo:”администратор source.com” /po:”пароль администратора source.com” /Quarantine

Перечисленные команды отключают фильтрацию SID на ресурсной стороне. То есть на той стороне, где находятся ресурсы, к которым необходимо получить доступ. Мы это сделали на стороне source.com.

Но у нас есть системы из source.com, которые могут обращаться к смигрированным ресурсам в домене target.com. Нужно ли отключать фильтрацию SID в этом случае? Скорее всего, да. Во-первых, исходный домен мог когда-то уже участвовать в процессе миграции (между лесами – cross-forest). У учетных записей этого домена заполнен атрибут SIDHistory, SIDы которого участвуют в назначении прав на ресурсы. Во-вторых, пользователи (или компьютеры) могут быть членами универсальных групп.

Тут применяются те же самые правила:

если доверительные отношения между лесами (forest trust), то необходимо отключать фильтрацию SID с помощью параметра /EnableSidHistory:yes;
если доверительные отношения между доменами (external trust), то необходимо отключать фильтрацию SID с помощью параметра /Quarantine:no.

А что если, по каким-то причинам, нам нельзя мигрировать вторичные SIDы или отключать фильтрацию (или и то и другое)? Решение этой задачи есть. Но при этом сам процесс миграции меняется, становится более сложным в реализации, по сравнению с традиционным. Если всё-таки есть возможность отключить фильтрацию на время миграции и переносить SIDы, то лучше это сделать. Подробнее об особенностях миграции в такой конфигурации поговорим немного позже.

Подробнее о фильтрации SID:
http://technet.microsoft.com/en-us/library/cc772816%28WS.10%29.aspx (Disable SID filter quarantining)
http://technet.microsoft.com/ru-ru/library/cc772633%28WS.10%29.aspx (Configuring SID Filtering Settings)
О создании внешних доверительных отношений - http://technet.microsoft.com/en-us/library/cc738617%28WS.10%29.aspx
О синтаксисе netdom trust - http://technet.microsoft.com/en-us/library/cc835085%28WS.10%29.aspx.
Необходимые порты TCP/IP для создания доверительных отношений (а также их дальнейшей работы) - http://technet.microsoft.com/ru-ru/library/cc756944%28WS.10%29.aspx

Окружение пользователя.

С доверительными отношениями разобрались, переходим к виртуализации пользовательского окружения. Перемещаемые профили (roaming profiles) пользуются большим спросом. Плюсов от их использования очень много, минусов практически нет. Но при миграции возникают определенные трудности использования этого функционала. Если конкретнее, то перемещаемые профили пользователей не загружаются между лесами. Это означает, что если пользователь из одного леса зайдет на рабочую станцию (или сервер) в другом лесу, то он получит пустой рабочий стол. Его перемещаемый профиль не загрузится. Более того, не отработают и групповые политики назначенные пользователю в его «родном» домене или лесу. Такое поведение наблюдается, начиная с Windows 2000 SP4.

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

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

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

В домене исходного леса создайте групповую политику.
С помощью административных шаблонов установите значение параметра Computer Configuration\Administrative Templates\System\Group Policy\Allow Cross-Forest User Policy and Roaming Profiles в значение Enabled.
Полезно будет отключить конфигурацию пользователя, поскольку она не используется.
Необходимо продумать фильтрацию групповой политики. Будет это на основе иерархии, по группам безопасности или фильтрами WMI, решать вам. Но хотелось бы еще раз отметить, что данные настройки должны распространяться на компьютеры. Если будете использовать фильтрацию по группам, то делайте это универсальными или глобальными группами, поскольку в многодоменной среде есть особенности использования доменнолокальных групп при назначении прав на объекты каталога.
Если доменов в лесу несколько, то необходимо, либо создать несколько объектов групповых политик и повторить перечисленные выше действия, либо привязать существующую групповую политику. Лучше создавать дополнительные, иначе будет труднее отлавливать ошибки.

Те же действия, с 1 по 5, необходимо проделать в целевом лесу. Хотелось бы отметить, что в целевом домене это может не понадобиться, если у вас есть ограничения на создание доверительных отношений. Эти ограничения описаны в разделе аутентификация, выше.

В описании к административным шаблонам указано, что настройка Allow Cross-Forest User Policy and Roaming Profiles относится только к Windows Server 2003 и выше, но на самом деле, работает для Windows 2000 SP4 и выше. Для более низких версий, описанной проблемы не возникает – профили загружаются в любом случае.

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

Подробнее об управлении групповыми политиками можно почитать здесь - http://technet.microsoft.com/en-us/library/cc784283%28WS.10%29.aspx
Про перемещаемые профили и Windows 2000 с SP4 – http://support.microsoft.com/kb/823862
Дополнительные сведения для Windows Server 2003 – http://technet.microsoft.com/en-us/library/cc757395%28WS.10%29.aspx

Еще раз напомню, где находится первая часть. Здесь.

Добавляем пользователей, компьютеры, группы в локальные группы

2011-05-30T00:48:00.000-07:00

Add computers, users or groups to local group (on member servers or domain controllers):

@echo off
set objMask=%1
set LocalGroupName=%2
for /F "skip=1" %%i in ('dsquery * -filter "(&(|(objectClass=user)(objectClass=group))(sAMAccountName=%1))" -attr sAMAccountName -limit 0') do (
echo "Add %%i to %LocalGroupName%:"
net localgroup %LocalGroupName% %%i /Add
)

Сохраняем в файл с расширением bat.
Запускаем: имя_батника.bat маска_поиска имя_локальной_группы
Например: AddPrincipalToLocalGroup.bat *srv* Administrators

Миграция базовой инфраструктуры Microsoft. Часть 1.

2011-05-14T00:48:00.000-07:00

Введение.

Тема миграции базовой инфраструктуры Microsoft не нова. Но полной и самодостаточной информации о проведении этого процесса очень мало, если не сказать, что такой информации вообще нет. На просторах сети Интернет можно найти очень много статей, описывающих процесс миграции, но все эти статьи являются какими-то «огрызками» и полной картины не раскрывают. Если говорить о миграции на новые платформы, то здесь информации еще меньше.

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

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

Что будем считать базовой инфраструктурой, и что в нее будет входить?

Служба каталогов Active Directory. По праву AD можно назвать ключевым компонентом в базовой инфраструктуре;
DNS;
DHCP;
WINS;
Файловые серверы;
Принт-серверы;
Терминальные серверы и фермы терминальных серверов;
DFS и ее элементы.

Сейчас все больше и больше организаций используют Exchange-сервер в качестве средства объединенных коммуникаций. Exchange напрямую зависит от Active Directory, и миграция службы каталогов безусловно повлияет на работу Exchange-пользователей. Документация по миграции Active Directory есть, но в этой документации не описывается процесс миграции AD совместно с Exchange. В свою очередь, в других документах описывается миграция Exchange, но она не рассматривается совместно с миграцией Active Directory. Примерно туже самую картину я наблюдал на проектах, в которых участвовало несколько архитекторов – один по AD, второй по Exchange. Зачастую их действия не были согласованы – миграция двух систем проходила несколько изолировано, особенности совместной миграции не учитывались. Получалось, что одна система (архитектор) мешала другой (другому).

Есть определенные особенности миграции серверов Microsoft SQL Server. Включим в миграцию и их.

Что будем считать миграцией? Миграцией будем считать перенос ресурсов из одного или нескольких лесов в целевой лес. Такая модель чаще всего встречается на практике.

Сам процесс миграции это только полдела (скорее всего даже меньше). Миграция процесс сложный, долгий, включает в себя множество задач, распределенных во времени, выполнение которых позволит добиться какого-то результата, достичь поставленных целей. Я фактически назвал определение понятия проект. Для выполнения проекта требуется определенный подход. Методологий по управлению проектами много, тема большая, в этой статье рассматриваться не будет. Хорошие рекомендации по управлению проектами даны в методологии MSF (Microsoft Solution Framework). Некоторые считают, что эта модель подходит только для разработчиков и к инфраструктурным проектам не относится. На самом деле это не так. Материал методологии хорошо подходит и к инфраструктурным проектам, необходимо только немного поабстрагировать. В этой методологии не будет описано «как и что делать», в ней не будет жестких правил ведения проектов, но в ней даются ценные советы, которые вам помогут выполнить любой проект, не только ITшный.

Также в проектировании помогут стандарты, например, ГОСТы. Из них вам также необходимо выбрать определенные рекомендации, которые вам помогут выполнить проект успешно. Найти ГОСТы для автоматизированных систем можно здесь - http://www.rugost.com/index.php?option=com_content&task=category&sectionid=6&id=22&Itemid=53

Я для себя выработал некую методику, являющуюся гибридом ГОСТов и методологии MSF. Применяю ее на практике.

Некоторые рекомендации по ведению проектов, а точнее по управлению проектной группой, можно подчерпнуть из книги Страуструпа «Язык программирования С++», второе и третье издание. В этой книге есть отдельная глава, посвященная проектированию.

Контролировать ход проекта вам поможет Microsoft Project. Есть хорошая книга Гультяева А.К. по управлению проектами в Microsoft Project. Советую прочесть.

Исходные данные.

Какие у нас есть исходные данные?
У нас есть исходная инфраструктура, состоящая из одного леса и нескольких доменов.
Имя корневого домена - source.com/SOURCE. Дочерний домен – child1.source.com/CHILD1. Версии контроллеров доменов в source.com - Windows Server 2003 с SP2, в child1 – Windows 2000 Server с SP4. В доменах работают несколько пользователей. Рабочие станции – 2000, XP, Vista, Windows 7. Есть серверы Windows 2000 Server, Windows Server 2003/2008R1/2008R2.

В каждом домене установлен Exchange-сервер версии 2003 с SP2. Если на Exchange-сервере не установлен SP2, то необходимо это сделать до миграции почтовых ящиков пользователей. Exchange 2010 поддерживает миграцию почтовых ящиков только с версий Exchange Server 2003 SP2 и Exchange Server 2007 SP2.

Есть определенные требования к версиям контроллеров доменов при миграции почты на Exchange Server 2010 (или на Exchange 2007). Об этих особенностях немного позже.

Мы уже спроектировали целевую инфраструктуру и даже ее развенули. В качестве целевой инфраструктуры будет выступать домен target.com/TARGET. Версия контроллеров доменов Windows Server 2008 R2.

На отдельном сервере установлен Exchange Server 2010. На этом сервере установлены все роли, а точнее роли Hub, CAS и Mailbox. За обработку внешней почты сейчас отвечает один из серверов в исходном домене. После миграции эту роль на себя возьмет еще один сервер в новой инфраструктуре – Exchange Server 2010 с ролью Edge Transport.

У нас также будут разные типы серверов в исходном домене. Нам их тоже придется мигрировать в новую инфраструктуру. О миграции серверов немного позже.

Интеграция.

Миграция является процессом достаточно долгим и сам процесс подразумевает долгосрочное сосуществование двух систем – старой и новой.

Поэтому нам необходимо интегрировать нашу текущую инфраструктуру с целевой.

Разрешение имен.

С чего начать интеграцию? Лучше всего с настройки разрешения имен между инфраструктурами. Нам необходимо, чтобы смигрированные ресурсы могли разрешать имена несмигрированных ресурсов, и наоборот. Наиболее популярные механизмы разрешения имен в Windows-сетях – это DNS и NETBIOS.

Будем считать, что DNS-серверы развернуты на контроллерах доменов. Обслуживают эти DNS-серверы зоны для своего раздела и зону _msdcs.корневой_домен_леса. Зоны интегрированы в Active Directory.

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

Рассмотрим первый способ – пересылки:

В общем-то, ничто нам не мешает использовать этот механизм. Сначала мы настраиваем в исходном домене пересылку для целевого домена. Для пересылки мы указываем ближайшие DNS-серверы целевого домена. Что означает ближайшие? Как правило, в многодоменной среде, для региональной площадки выделяется отдельный домен (в нашем случае это child1.source.com). При миграции в новый домен, компьютеры будут регистрировать A-записи на локальных контроллерах домена, то есть на контроллерах домена той же физической площадки, что и в исходном лесу (при условии, что мы правильно настроили конфигурацию сетевой карты клиентов DNS; об этом чуть позже). Поэтому было бы правильным настроить пересылку именно на эти локальные контроллеры доменов.

В целевом домене мы проделываем тоже самое – настраиваем пересылку для исходного домена между ближайшими DNS-серверами.

Если исходные DNS-серверы – Windows 2000, необходимо использовать вторичные зоны или продумать способ разрешения имен совместно с глобальными пересылками на DNS-серверы целевого домена.

Начиная с Windows Server 2008, появилась возможность реплицировать записи пересылок между DNS-серверами. Можно воспользоваться этим механизмом, чтобы не делать одну и туже работу несколько раз.

Второй механизм – использование вторичных зон:

Здесь мы разрешаем пересылку зоны между серверами исходного и целевого доменов. Создаем вторичные зоны: на исходных DNS-серверах вторичные зоны для целевого домена, на целевых для исходного домена. В качестве master-сервера используем ближайший DNS-сервер. Настраиваем оповещение при изменениях. Число изменений до оповещения – 1.

Третий способ – использование зон-заглушек:

Этот функционал появился в Windows Server 2003. С помощью зон-заглушек мы можем получать информацию об авторитетных DNS-серверах – NS- и A-записи серверов, обслуживающих указанную зону. Причем, эта информация будет еще и динамически обновляться.

В общем-то, способ отличный, но для нашего примера подходит лишь частично. DNS-серверы из домена child1 получат NS/A-записи для всех DNS-серверов домена target.com (случаи с DisallowNSAutoCreation не будем рассматривать). Для разрешения имен, они также будут обращаться к одному из этих NS-серверов. Когда мы смигрируем компьютер в новый домен, он зарегистрируется на «новом», ближайшем DNS-сервере. Еще несмигрированные компьютеры будут обращаться к старым DNS-серверам, а те в свою очередь на какой-то DNS-сервер из нового домена. На какой? Успеет ли новая A-запись для смигрированного компьютера реплицироваться на этот какой-то DNS-сервер? Ответить на этот вопрос трудно. Поэтому зоны-заглушки из старого домена в новый, для нашей конфигурации, не подойдут. А вот в противоположную сторону мы их можем использовать.

Начиная с Windows Server 2008 R1, у нас есть возможность реплицировать зоны этого типа между DNS-серверами. Стоит воспользоваться этой возможность, тем более целевой лес у нас Windows Server 2008 R2.

Хотелось бы отметить несколько плюсов и минусов этих трех способов.

Способ с пересылками достаточно прост в конфигурации, при этом трафик передачи зоны равен нулю. Но трафик запросов больше, чем у вторичных зон. Есть некоторые ограничения при миграции с Windows Server 2000: нет поддержки условных пересылок. Также есть проблемы с актуальностью данных. Например, если какая-то запись изменится, скажем, поменялся IP-адрес компьютера, то изменения будут отражены на пересылающей стороне только после истечения срока кэширования записи и при повторном запросе. Это касается и способа с зонами-заглушками. Что не скажешь о вторичных зонах, где информация более актуальна (при условии настройки оповещений при изменении).

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

Вариант с зонами-заглушками имеет практически те же плюсы и минусы, что и способ с пересылками.

Три способа. Какой лучше? Способ с пересылками является наиболее простым. Зоны-заглушки можно использоваться лишь частично. Второй способ является более сложным, а значит, увеличивается вероятность отказа. На вопрос я так и не ответил. Решайте сами.

Если между взаимодействующими системами (клиентами, DNS-серверами), есть брандмауэры, нам необходимо разрешить трафик DNS – 53 TCP/UDP.

Теперь немного о разрешении NETBIOS-имен. Основным способом разрешения имен в системах Windows 2000 и выше является DNS, но есть приложения, которые до сих пор используют NETBIOS-функции и короткие имена. Microsoft сделала определенный шаг, чтобы избавиться от этого. Теперь, начиная с Vista/Win2008, NETBIOS-функции не поддерживаются. Надеюсь, что в скором времени мы избавимся от NETBIOS-имен навсегда. Но отсутствие поддержки вовсе не означает, что такие приложения не будут работать в лесах Windows 2008 R2. Использование NETBIOS-имен также продолжается.

Есть три способа разрешения NETBIOS-имен: файлы LMHOSTS, широковещательные рассылки и WINS-серверы.

Для LMHOSTS ничего переносить не нужно, такие файлы мигрируются вместе с компьютерами. Другое дело, если вы будете в процессе миграции переименовывать системы. В этом случае вам необходимо вручную подправить эти файлы. На широковещание мы не сможем повлиять, поэтому здесь ничего сделать нельзя. Для миграции WINS-инфраструктуры мы можем воспользоваться одним из следующих способов:

1) Перенести инфраструктуру WINS после миграции ресурсов Active Directory;

2) Настроить репликацию между новыми и старыми WINS-серверами, переключить компьютеры на новую инфраструктуру до миграции ресурсов AD;

3) Как и второй способ, но компьютеры переключаем после миграции в новый лес.

Первый и третий способ хорош тем, что мы не сталкиваемся с проблемами актуальности и сходимости данных. Все компьютеры направлены на одни и те же WINS-серверы (смигрированные и несмигрированные компьютеры), а значит, имеется единая точка, как обновления ресурсов, так и их разрешения. Затем нам придется настраивать репликацию между инфраструктурами (или для третьего способы мы уже это сделали) и, когда все ресурсы перенесены, необходимо переключить компьютеры на новые серверы. Если переключить все компьютеры за один раз, то наверняка столкнемся с некоторыми проблемами при разрешении имен. Гарантировать переключение всех компьютеров вряд ли можно в большой инфраструктуре. А если переключать порциями, то увеличится время миграции.

Лучше столкнуться с проблемами в меньших масштабах и решать их (предотвращать) по мере поступления. Как раз это второй способ. Мы сначала настраиваем репликацию между старым и новым лесом, а затем, перед миграцией, порциями (слотами), переключаем компьютеры на новые WINS-серверы. В этой конфигурации несмигрированные ресурсы смотрят на одни серверы, смигрированные на другие. Возникает проблема с латентностью репликации данных между этими системами. Но, как я говорил, новые системы предпочитают DNS, поэтому мы вряд ли столкнемся с проблемами. А если и столкнемся, то, скорее всего, на небольшой части компьютеров.

У нас есть возможность интегрировать DNS с WINS’ом – сделать для DNS-зоны WINS-просмотр. Нужно ли это делать для миграции? Лучше не стоит. Это лишнее усложнение, которое чревато ошибками и вероятность отказа сложных систем все же больше, чем у простых. Если говорить о реальных проблемах, то могут возникнуть ошибки при аутентификации по протоколу Kerberos. И вот почему. Например, пользователь запрашивает некоторую службу по короткому имени – SERVICE01. Подставляется некий суффикс и имя получается длинное – SERVICE01.target.com. Далее запрос отправляется на DNS-сервер, в котором для зоны target.com настроен обзор в WINS. Если DNS не находит в зоне target.com указанной записи, он отбросит доменные метки и запросит у WINS’а запись SERVICE01. WINS ответит IP-адресом. Но из какого домена эта запись? WINS – система плоских имен, поэтому неизвестно. DNS-сервер вернет пользователю ответ: SERVICE01.target.com=IP-адрес. IP-адрес будет, скорее всего, правильным – пинги пустить можно. Но вот что, если пользователь хотел обратиться к службе из старого леса – service01.source.com. Тут как раз и могут возникнуть проблемы при поиске службы по ServicePrincipalName. В результате могут возникнуть проблемы с аутентификацией по протоколу Kerberos.

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

Как поступить, если мы решили настраивать репликацию базы WINS между инфраструктурами? Реплицировать ли базу только между ближайшими WINS-серверами или это будет смешанная репликация?

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

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

Требования к открытию портов TCP/IP, используемых WINS-серверами - http://technet.microsoft.com/ru-ru/library/cc784026%28WS.10%29.aspx.

Разрешению имен стоит уделить особое внимание. Причем, не только при миграции. Ошибки, связанные с разрешением имен, составляют 80-90% от общего количества (если не брать в расчет ошибки ИТ-специалистов).

На этом настройка разрешения имен не заканчивается. Мы будем и далее обсуждать эту тему.

В следующей статье мы продолжим интеграцию наших инфраструктур.

Скрипты для проекта миграции Active Directory и Exchange

2011-05-05T02:01:00.000-07:00

Сегодня, 05.05.2011, будет проходить MCP-клуб, в Москве.
На нем я буду рассказывать о миграции на новую платформу Active Directory - Windows Server 2008 R2.

Для миграции понадобятся следующие скрипты:
http://narod.ru/disk/16065285001/migration.zip.html

mirror: http://ifolder.ru/24157027

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

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

PKI: Мифы о мифах.

2011-04-07T13:58:00.001-07:00

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

Меня заинтересовали (проще говоря - прикапался) некоторые высказывания, которые достаточно пространно (а на мой взгляд неправильно) характеризуют эту инфраструктуру.
Примерно это звучало как, инфраструктура PKI – это набор правил, которые должны соблюдаться. Что эти правила соблюдаются во всех аспектах PKI. Что у PKI железная логика. Что доверие к сертификату строится по наличию «сертификатов пути» в контейнерах Trusted Root Authority и Trusted People (если говорить о реализации в Windows). Что при использовании приватного ключа для электронной подписи налагаются ограничения на валидность сертификата (конкретно шел разговор о просроченности сертификата). Вроде все.

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

Начнем с размышлений о том, что такое PKI. PKI – это инфраструктура открытого ключа. То есть это набор правил, политик, программных и аппаратных средств, которые и составляют эту инфраструктуру. И необязательно это только электронные виды средств, это и люди, и документы (писульки) и т.д. А ключевыми фигурами в этой инфраструктуре выступают закрытый и открытый ключи. Как вы их будете использовать – это ваше дело. Все зависит от требований.
PKI настолько гибкая инфраструктура, что каких-либо правил не налагает, а предоставляет только вспомогательные средства, позволяющие принимать решения по использованию ключей входящих в эту инфраструктуру.
Для меня всегда остается загадкой использование PKI конкретным приложением. Например, нельзя с полной уверенностью сказать налагает ли приложение какие-либо ограничения на сертификат, должен ли этот сертификат быть доверенным, действительным по датам, должен ли он содержать определенную политику приложений, в какое хранилище этот сертификат нужно устанавливать. Я даже не могу точно сказать, как строится цепочка доверия – используются ли промежуточные сертификаты из хранилища пользователя или компьютера.
И это все из-за того, что инфраструктура PKI очень гибкая и ни какой железной логики у нее нет. Используйте ключи так, как хотите.

Рассмотрим пример использования ключей PKI. Попутно ответим на другие заблуждения.
1) Сгенерируем наш объект испытаний (статья написана 08.04.2010):
makecert -a sha1 -sky signature -b 04/01/2011 -e 04/02/2011 -r -pe -sr CurrentUser -n "CN=Self" -ss My
Этот сертификат является самоподписанным, недоверяемым и просроченным. Устанавливается в хранилище пользователя.

2) Продолжим следующим кодом (c#):

X509Store store = new X509Store("My", StoreLocation.CurrentUser);

store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly);

X509Certificate2 cert = store.Certificates[1]; // Сертификатов у меня 2. Сгенерированный находится под номером 1. Можно также воспользоваться методом Find для поиска по атрибутам сертификата

RSACryptoServiceProvider csp = null;

csp = (RSACryptoServiceProvider)cert.PrivateKey;

SHA1Managed sha = new SHA1Managed();

string str = "VADIM";

UnicodeEncoding encoding = new UnicodeEncoding();

byte[] data = encoding.GetBytes(str);

byte[] hash = sha.ComputeHash(data); //генерим хэш

byte[] signature = csp.SignHash(hash, CryptoConfig.MapNameToOID("SHA1")); //Генерируем сигнатуру

//Здесь представим, что принимающая сторона проверяет сигнатуру

str = "VADIM1"; // Исходная строка.. злоумышленник ее изменил.. Затем замените на VADIM без единички.. в конце должно показать true

byte[] destData = encoding.GetBytes(str);

byte[] hashdest = sha.ComputeHash(destData);

csp = (RSACryptoServiceProvider)cert.PublicKey.Key;

MessageBox.Show(

(csp.VerifyHash(hashdest, CryptoConfig.MapNameToOID("SHA1"), signature)).ToString()); // Должно отобразиться false.

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

Что мы получили? Мы развеяли миф об использовании нехороших сертификатов при подписывании. Шифрование нехорошими сертификатами не буду демонстрирова – поверьте на слово или прочитайте про анонимный TLS в Exchange 2010 (в качестве примера).
Давайте теперь разберемся с контейнерами Trusted Root Authority и Trusted People. Не факт, что приложение будет использовать контейнер Trusted People при определении доверия к сертификату.

Проверка происходит следующим образом (опять же конкретная реализация):

X509Chain chain = new X509Chain(false);

chain.Build(cert); // проверяем наш предыдущий сертификат

На данном этапе сертификат не установлен в Trusted Root Authority и не установлен в Trusted People.
Массив chain.Status должен содержать два элемента – один говорит о том, что нет доверия, второй, что сертификат просрочен.

Давайте теперь добавим сертификат в Trusted People. Copy-Paste.
Выполним тот же код:

X509Chain chain = new X509Chain(false);

chain.Build(cert);

Массив chainStatus содержит те же два элемента.

А теперь добавим в Trusted Root Authority.

Код:

X509Chain chain = new X509Chain(false);

chain.Build(cert);

На этот раз chain.Status содержит только один элемент – просроченный сертификат.
Здесь мы развеяли миф о том, что при построении доверия используются оба контейнера.
Стоит обратить внимание на параметр конструктура – false. True означает, что мы будем использовать при проверке сертификата контекст компьютера, false – пользователя (как в нашем случае). Видите, даже тут нельзя точно сказать какое хранилище будет использоваться при проверке валидности. Гибкий PKI.

Мы провели проверку валидности по умолчанию (можно было указать проверку других параметров). Вопрос: используется или нет Trusted People при построении доверия? Нельзя сказать точно. Поскольку в проверку все-таки можно включить этот контейнер или даже другие контейнеры. Но в нашем случае Trusted People не использовался, а Trusted Root Authority использовался.

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

Спасибо за внимание, комментарии приветствуются.

Загрузчик музыки вКонтакте

2011-03-18T09:01:00.000-07:00

param(
   [string]$url,
   [string]$targetpath
)

function replaceCharacters($str){
   [char[]]$replaceChars=@('<','>',':','"','/','\','|','?','*',',','&','#',';',' ')
   #[char[]]$replaceChars=@('<','>',':','"','/','\','|','?','*')
   $replaceChars | foreach {
       $str = $str.Replace($_,"_")
   }
   return $str.Trim()
}

$progress = {
   param($eArgs)
   Write-Progress -Activity "Информация о загрузке файла" -CurrentOperation "Загрузка файла" -Id 1 -PercentComplete $eArgs.ProgressPercentage
}

$webclient = New-Object System.Net.WebClient
$content = $webclient.DownloadString($url)
$webclient.add_DownloadProgressChanged($progress)
#Поиск ссылок
$reg = [regex]"id=`"audio_info([0-9_]+)`" value=`"(http://[a-zA-Z0-9_.]+(/[a-zA-Z0-9]+)+\.mp3)"
$matches = $reg.Matches($content)

foreach ($matche in $matches){
   $id = $matche.Groups[1].Value
   $dwnldstr = $matche.Groups[2].Value
   #поиск названия
   $reg = [regex]"\<span id="`"title$($id)`"\" >([^\<]+)\"
   $soundName = (replaceCharacters $reg.Matches($content)[0].Groups[1].Value) + ".mp3"

   "Качаем `"$soundName`"...." | Out-Host
   #$webclient.DownloadFile($matche.Value, $targetdirectory + $matche.Value.ToString().Split([Char[]]@("/"))[-1])
   $webclient.DownloadFile($dwnldstr, (Join-Path $targetpath $soundName))
}

ISA/TMG Links

2011-01-28T06:57:00.000-08:00

Forefront Threat Management Gateway 2010 Capacity Planning Too:
http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=01b2f7a5-8165-4ead-9693-994504f66449

Email Protection in Forefront TMG 2010 Release Candidate:
http://blogs.technet.com/b/isablog/archive/2009/11/10/email-protection-in-forefront-tmg-2010-release-candidate.aspx

How to migrate Microsoft ISA Server 2006 to Microsoft Forefront TMG:
http://www.isaserver.org/tutorials/How-migrate-Microsoft-ISA-Server-2006-Microsoft-Forefront-TMG.html

Фиксация групп рассылок при миграции почты между организациями Exchange (2003/2007/2010).

2011-01-20T05:00:00.000-08:00

Решил выложить ряд скриптов, полезных при миграции AD/Exchange.

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

Попробуем рассмотреть схему инфраструктуры AD/Exchange на момент миграции (пусть будет Exchange 2003 исходный и Exchange 2007 целевой):

1) Мы интегрировали два леса и две организации Exchange (Пользователей пока не мигрировали) – настроили маршрутизацию между двумя организациями, настроили синхронизацию Global Address List в ILM 2007 FP1 (или MIIS 2003, или FIM 2010). При такой схеме, почта, отправленная из целевого леса разрешается с помощью контакта в адрес @source.com и с помощью настроенного Send-connector’а маршрутизируется в исходный лес.

2) Мы мигрируем пользователей/группы из исходного леса в целевой лес, с сохранением SID. Получаем следующую картину.

У смигрированных пользователей нет атрибутов Exchange, соответственно почтовых ящиков. Их перенесут позже.

3) Дальше мы мигрируем почту пользователей (возможно параллельно с компьютерами) командлетом Move-Mailbox и получаем следующую картину:

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

Чтобы этого не случилось, нам необходимо удалить почтовый ящик из целевого домена сразу после миграции. Сделать это можно соответствующим параметром командлета Move-Mailbox (смотрите справку по данному командлету) и, если у нас исходный лес Exchange 2003, это можно сделать соответствующим мастером из Exchange System Management или Active Directory Users And Computers (если зарегистрирована соответствующая оснастка-расширение). Первый способ подходит для Exchange 2003 и для Exchange 2007. Второй способ только для Exchange 2003. Но первый способ я бы не рекомендовал использоваться для Exchange 2003, поскольку почтовый ящик удаляется физически и его нельзя подцепить обратно в случае отката действий. Здесь скрипт, который помогает автоматизировать этот процесс: http://gexeg.blogspot.com/2010/02/exchange-2003.html. Также можно проделать эти действия с помощью утилиты ADModify.

4) Удалили мы почтовый ящик из исходного домена, каким либо способом. Теперь у нас следующая картина:

5) Запускаем ILM 2007 для синхронизации GAL. У нас создается соответствующий контакт в исходном домене и проблема из пункта 4 решается. Теперь почта для этого пользователя будет разрешаться в контакт и маршрутизироваться в целевой лес.

Появляется еще одна проблема. До этого пользователь состоял в группе рассылки «Группа рассылки 1». Он и сейчас там есть, но у него нет атрибутов. Поэтому почта, отправленная на группу рассылки не попадет в ящик пользователя «Пользователь 1» (как из целевого, так и из исходного домена).

Как решить эту проблему? Очень просто, необходимо добавить контакт «Контакт (Пользователь1)» в группу рассылки «Группа рассылки 1).

Теперь почта, отправленная на группу рассылки исходного домена, будет расширяться (expand) в контакт и маршрутизироваться в целевой лес. Почта, отправленная на группу рассылки из целевого домена, будет разрешаться в контакт целевого домена, маршрутизироваться в исходный лес, далее в исходном лесу попадет на группу рассылки, расширится в контакт и маршрутизируется в целевой лес. Трафик, конечно не оптимальный, но работает.

Ручное добавление контактов в группу становится кошмаром, когда таких контактов много (сотни, тысячи). Тут нужна автоматизация.

Я столкнулся с этой проблемой и написал скрипт, который позволяет автоматизировать задачу ручного добавления контактов в группы рассылки.

Скрипт - fix_distribution_group.ps1

Синтаксис:

fix_distribution_group.ps1 -slotfile <Входной файл> [-SourceDomain <домен-источник>] [-TargetDomain <целевой_домен>] [-Force]

-slotfile <входной файл> - файл со списком логинов смигрированных пользователей с почтовыми ящиками. Обязательный параметр.

-SourceDomain <домен-источник> - домен источник. Необязательный параметр. В этом домене происходит поиск контактов и групп распространения пользователей. В этом же домене происходят изменения – контакт добавляется в группу распространения. Поэтому необходимы соответствующие права. Если этот параметр опустить, то будет использоваться текущий контекст пользователя и его домен. Может быть указано в формате DNS-имя или NETBIOS-имя.

-TargetDomain <целевой-домен>. Необязательный параметр. В этом домене происходит поиск почтового ящика пользователя, для того чтобы потом найти соответствующий контакт в исходном домене. Необходимые права – только на чтение. Если этот параметр опустить, то будет использоваться текущий контекст пользователя и его домен. Может быть указано в формате DNS-имя или NETBIOS-имя.

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

-Help. Вызов справки по скрипту.

Примечание:

Необходимо указать хотя бы один из параметров sourcedomain или argetdomain. Эти параметры не должны быть одинаковыми. Соответствующие проверки происходят. В случае неправильности – будет выдана ошибка.

Примеры:

fix_distribution_group.ps1 -slotfile slot1.txt -SourceDomain source.com

fix_distribution_group.ps1 -slotfile slot1.txt -SourceDomain source.com –TargetDomain target.com

fix_distribution_group.ps1 -slotfile slot1.txt -SourceDomain source.com -Force

Описание работы и ограничения:

Работает скрипт следующим образом. Читается файл, указанный в параметре slotfile. Содержание файла – логины (sAMAccountName), построчно. Для каждого пользователя из файла происходит поиск этого пользователя в исходном домене (по атрибуту sAMAccountName). Далее у найденного пользователя определяются группы распространения, в которых он состоит (поэтому не нужно удалять пользователя из этих групп или вообще удалять). После этого происходит поиск в целевом домене (по sAMAccountName). У найденного пользователя (целевой домен) происходит чтение атрибута legacyExchangeDN. Затем в исходном домене по атрибуту proxyAddresses ищется контакт, у которого есть этот адрес (legacyExchangeDN). Если контакт найден, то он добавляется во все ранее найденные группы распространения пользователя исходного домена.

Во входном файле можно указать подстановочные знаки LDAP, но при поиске будет возвращен только один объект (первый).

Есть ограничение. Поскольку поиск в целевом домене происходит по sAMAccountName (в идеале нужно искать по SIDHistory), то исходный и целевой пользователи должны иметь одинаковые sAMAccountName (хотя можно использовать хитрость с подстановочными знаками во входном файле).

Поиск по SIDHistory не трудно реализовать (есть в одном из моих скриптов, который также скоро выложу, можно выдрать из него).

Сам скрипт:

http://ifolder.ru/22021460

ISA 2004, ISA 2006, TMG2010 Medium Business Edition не поддерживает перенаправление трафика

2011-01-19T04:59:00.000-08:00

Столкнулся с такой проблемой при миграции с ISA 2000 на ISA 2006.С ISA 2000 перенаправление с использованием ICMP работает, с 2006 нет.
Симптомы:
1) ICMP-трафик между сетями работает, TCP нет. Не происходит фаза инициализации TCP, хотя пакеты между хостами ходят.

Подробнее проблема описана здесь:

ISA Server 2004, ISA Server 2006, and Microsoft Forefront Threat Management Gateway, Medium Business Edition do not support traffic redirection.
http://support.microsoft.com/kb/888042/en-us

Подробнее о ICMP Redirection:
http://support.microsoft.com/kb/195686/en-us

Windows Links

2011-01-14T07:14:00.000-08:00

Windows Server 2008 R2 Edition Comparison by Technical Specification:
http://www.microsoft.com/windowsserver2008/en/us/r2-compare-specs.aspx

Windows Server 2008 R2 Differentiated Feature Comparison by Edition:
http://www.microsoft.com/windowsserver2008/en/us/r2-differentiated-features.aspx

Explanation of ICMP Redirect Behavior (Перенаправление трафика с помощью ICMP):
http://support.microsoft.com/kb/195686/en-us

При назначении IP-адреса сетевому адаптеру появляется сообщение об ошибке:

IP-адрес XXX.XXX.XXX.XXX, указанный для этого сетевого адаптера, уже назначен другому адаптеру имя адаптера. Имя адаптера скрыто от папки «Сетевые подключения», поскольку он либо физически отсутствует в компьютере, либо является устаревшим и не работает. Если обоим устройствам назначен один и тот же адрес, только одно из них сможет его использовать. Это может привести к неполадкам в работе системы. Ввести другой IP-адрес для этого адаптера в список IP-адресов в окне дополнительных параметров?

http://support.microsoft.com/kb/269155

Выравнивание разделов в Windows:
http://support.microsoft.com/kb/929491/en-us

How to use the "netsh advfirewall firewall":
http://support.microsoft.com/kb/947709/en-us

Event KB:
http://kb.prismmicrosys.com/

Adm template:
http://gps.cloudapp.net/

IIS Resource Kit Tools:
http://www.microsoft.com/downloads/en/details.aspx?familyid=56FC92EE-A71A-4C73-B628-ADE629C89499&displaylang=en

Windows Bitlocker Drive Encryption Design and Deployment Guide:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=41ba0cf0-57d6-4c38-9743-b7f4ddbe25cd&displaylang=en

DiskShadow:
http://technet.microsoft.com/en-us/library/cc772172.aspx

Утилита для управления привязками служб и протоколов на сетевом интерфейсе (tool for modifying network bindings from the command line):
http://archive.msdn.microsoft.com/nvspbind

Повсём:
http://technet.microsoft.com/en-us/windowsserver/bb633748.aspx

Исключения антивируса на контроллерах доменов:
http://support.microsoft.com/kb/822158/en-us

Исключения антивируса для SQL Server:
http://support.microsoft.com/kb/309422/en-us

Service overview and network port requirements for the Windows Server system
http://support.microsoft.com/kb/832017/en-us

Win Error Structure:
http://msdn.microsoft.com/en-gb/library/cc231198.aspx
Error Code Lookup tool:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=985

Active Directory Links

2010-12-30T12:37:00.001-08:00

How to query Active Directory by using a bitwise filter:
http://support.microsoft.com/kb/269181

AD Troubleshooting:
http://technet.microsoft.com/en-us/library/bb727056.aspx

Group policy filtering with domain local groups:
http://support.microsoft.com/kb/309172

Machine Account Passwords Process:
http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx

Exchange 2007/2010, Outlook, при отправке удаляются категории

2010-12-16T06:43:00.000-08:00

При отправке письма (или другого элемента (item)) с определенной категорией (цвет) происходит удаление этой категории и у получателя категория не отображается.

Это происходит на уровне транспорта, на Hub Transport, при конвертации письма. Отключается следующим образом:

Set-TransportConfig -ClearCategories:$false

Подробнее о синтаксисе: http://technet.microsoft.com/en-us/library/bb124151.aspx

VMWare Links

2010-12-14T07:30:00.000-08:00

VMware Compatibility Guide:
http://www.vmware.com/resources/compatibility/search.php

vCenter Server 4.0 DB Calculator:
http://www.vmware.com/support/vsphere4/doc/vsp_4x_db_calculator.xls

VUM sizing calculator:
http://www.vmware.com/support/vsphere4/doc/vsp_4x_db_calculator_oracle.xls

Processors and guest operating systems that support VMware Fault Tolerance:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008027

VMware VMDirectPath I/O
http://communities.vmware.com/docs/DOC-11089

vSphere Licensing:
http://www.vm4.ru/2010/10/vsphere-licensing.htm
http://www.vmware.com/products/vsphere/buy/small_business_editions_comparison.html

vSphere 4.1 Configuration Maximums:
http://www.vmware.com/pdf/vsphere4/r41/vsp_41_config_max.pdf

Setting the number of cores per CPU in a virtual machine:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010184

Сравнения решений виртуализации от различных вендоров:
http://www.virtualizationmatrix.com/matrix.php

Расположение файла журнала установки Windows Vista, Windows 7, Windows Server 2008/2008R2

2010-11-23T12:55:00.001-08:00

http://support.microsoft.com/kb/927521

Exchange 2010. Проблема с делегированием прав на управление группой.

2010-11-15T12:36:00.000-08:00

Начиная с RTM 2010 в Exchange отключена (удалены права) функция делегирования полномочий на управление членством в группе.

При попытке назначить правило управления членством в группе вылезает ошибка:
EMS:
Set-DistributionGroup -BypassSecurityGroupManagerCheck -MemberJoinRestriction 'ApprovalRequired' -MemberDepartRestriction 'Open' -Identity 'exch2010.com/Users/su_group02'

Members can't add themselves to security groups. Please set the group to Closed for requests to join.
+ CategoryInfo : InvalidData: (:) [Set-DistributionGroup], RecipientTaskException
+ FullyQualifiedErrorId : 86106FD4,Microsoft.Exchange.Management.RecipientTasks.SetDistributionGroup

EMC:

--------------------------------------------------------
Microsoft Exchange Error
--------------------------------------------------------
The following error(s) occurred while saving changes:

Set-DistributionGroup
Failed
Error:
Members can't add themselves to security groups. Please set the group to Closed for requests to join.
--------------------------------------------------------
OK
--------------------------------------------------------

Детали и решение проблемы:
http://msexchangeteam.com/archive/2009/11/18/453251.aspx

Ссылки по Hyper-V

2010-11-11T05:07:00.000-08:00

Windows Server Virtualization Validation Program:
http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvp.htm

Backup and Disaster Recovery for Server Virtualization: