TFTP сервер в Windows Server 2008 R2

Как и в Windows Server 2003, в Windows Server 2008 R2 сервер TFTP используется как часть Windows Deployments Services для загрузки установочных образов Windows по сети. Однако, в ряде случаев, TFTP сервер может понадобиться для задач, не имеющих отношения к WDS. Каким образом можно установить и настроить сервер TFTP?

Для установки TFTP требуется запустить Server Manager и добавить новую роль Windows Deployment Services. На этапе выбора компонентов нужно выбрать Transport Server.

После завершения установки требуется создать на диске папку, которая будет являться корневой для TFTP сервера (например, "C:\TFTPRoot").

В реестре в ветке HKLM\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSTFTP требуется создать новый параметр RootFolder типа String и указать в качестве значения путь к ранее созданной папке.

Также следует обратить внимание на параметр реестра ReadFilter, который по умолчанию разрешает загрузку файлов только из папок "boot\" и "tmp\". Если требуется загрузка файлов из других каталогов или корня, измените значение данного параметра (например, на '*').

Теперь запустите службу WDS:
WDSUTIL /Start-TransportServer

Не забудьте перевести службу Windows Deployment Services в режим автоматического запуска (например, с помощью оснастки "Службы" services.msc), чтобы не запускать ее вручную при каждой загрузке сервера.

Проверьте, что в брандмауэре Windows созданы необходимые правила для работы TFTP.

На этом настройка TFTP сервера завершена.

Проблема с проверкой CRL сертификатов в Exchange 2010

Часто при использовании цифровых сертификатов для Exchange 2010 вы можете столкнуться со следующей ошибкой в консоли EMC, сопровождающейся описанием: The certificate status could not be determinde because the revocation check failed.

Из-за этого вы не можете назначить данный сертификат для служб Exchange из консоли (хотя, при желании, можете это сделать с помощью комманды Enable-ExchangeCertificate из EMS). При этом просмотр самого сертификат может не показать ничего подозрительного.

Более того, попытка проверить доступность списка отзыва сертификатов вручную (например, с помощью веб-браузера, файлового менеджера или adsiedit) заканчивается успешно. Что делать в таком случае?

Если вы используете сторонний сертификат доверенной организации (вроде VeriSign или Thawte), прочитайте данную статью, возможно, ваши проблемы решатся.

Если же вы используете собственную инфраструктуру открытых ключей и центры выдачи сертификатов (например, на базе Microsoft CA), то следует проверить корректность настроек путей AIA и CRL в вашей инфраструктуре. Сделать это можно через оснастку pkiview.msc, запущенной на сервере выдачи сертификатов.

В данном примере используется двухуровневая инфраструктура PKI, с корневым изолированным ЦС (Offline Standalone Root CA) и подчиненным ЦС уровня предприятия (Enterprise Intermediate CA). Проблемы могут быть из-за неправильного конфигурирования путей на этапе установки ЦС или из-за их недоступности на текущий момент (ошибок в DNS, маршрутизации, блокировки брандмаэрами, антивирусами).

Чтобы исправить ошибку в данном случае необходимо сделать доступным CRL хотя бы по одному из двух доступных путей (http или file).

Кроме того, если ваш корневой ЦС является автономным и не доступен по сети, хорошей идеей будет блокировка проверки CRL корневого ЦС. Если этого не сделать, то, например, при проверке выданного сертификата для Exchange с помощью утилиты certutil -verify -urlfetch <certname.crt> вы можете встретить в тексте отчета сообщение об ошибке: CertUtil: The revocation function was unable to check revocation because the revocation server was offline 0x80092013 (-2146885613).

Для блокировки проверки выполните на подчиненном ЦС команду: certutil -setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE и перезапустите службу ЦС net stop certsvc & net start certsvc

После этого вернитесь на сервер Exchange, очистите кэш certutil -urlcache crl delete и перезагрузите сервер Exchange.

Использование InterOrg Replication Tool для миграции Public Folder на Exchange 2010

При выполнении Cross-Forest миграции Exchange сервера (например, с Exchange 2007 на Exchange 2010) одним из шагов может стать перенос содержимого общих папок из старой почтовой инфраструктуры в новую. Для этого можно воспользоваться утилитой InterOrg Replication Tool. Несмотря на то, что утилита поддерживает только устаревшие версии Exchange, она достаточно неплохо работает и с Exchange 2010. Однако есть ряд моментов, на которые стоит обратить внимание.

Для работы утилиты требуется наличие установленной консоли Microsoft Exchange System Manager. По этой причине у вас могут быть проблемы с работой InterOrg Repl Tool на Windows Server 2008 R2. Лучше всего выделить для этих целей отдельный сервер Windows Server 2003, входящий в домен, и установить на него InterOrg Repl Tool.

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

В старом лесу на сервере Exchange выполните:

Get-PublicFolder -Recurse | ConvertTo-Csv > "C:\Temp\ListOfPublicFolders.csv"

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

Foreach($PublicFolder in (Import-Csv "C:\Temp\ListOfPublicFolders.csv"))
{
If($PublicFolder.Name -ne "IPM_SUBTREE")
{
New-PublicFolder -name $PublicFolder.Name -Path $PublicFolder.ParentPath
}
}

После получения идентичной структуры общих папок загрузите и настройте InterOrg Replication Tool в соответствии с рекомендациями из статей:
http://www.msexchange.org/tutorials/Configuring-InterOrg-Replication-Tool.html
http://exchangeserverinfo.com/2008/02/28/interorg-replication-from-exchange-2003-forest-to-exchange-2007-sp1-forest.aspx

Очень вероятно, что при подключении к серверу Exchange 2010 вы столкнетесь с ошибкой "Unable to logon to Exchange Server using mailbox information.".

В этом случае проверьте, что выполняются следующие рекомендации.

1) Проверьте, что вы можете подключиться к серверу, используя NetBIOS имя, если это невозможно, то в строке Server вместо NetBIOS имени укажите FQDN.

2) Проверьте, что между исходным и целевым серверами Exchange корректно настроен брандмауэр и разрешены MAPI подключения. Как вариант, вы можете временно отключить все брандмауэры и разрешить весь трафик.

3) Временно отключите требование шифрования на CAS серверах в лесу Exchange 2010:

Set-RpcClientAccess –Server <ИМЯ_СЕРВЕРА_EXCHANGE> –EncryptionRequired $False

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

В случае удачной репликации вы увидите состояние Successful в окне Exchange Replication.