В настоящее время мы используем Win2K3 SBS в качестве контроллера домена с дополнительным сервером Win2K3 для размещения файлов и практически ничего не делаем. Вероятно, мы рассматриваем возможность расширения в другие офисы в ближайшем будущем.
Я думаю о том, чтобы иметь центральный контроллер домена с сервером win2k3 на каждом сайте, реплицирующим AD, общие файлы / документы, групповые политики и т.д., при этом независимо от каждого сайта запускается сервер обмена, т.е. электронные письма будут username@location1.domain.com или username@location2.domain.com с записями MX, указывающими на IP-адреса соответственно. Таким образом, я полагаю, что не будет необходимости в постоянном канале VPN и не возникнет много проблем с отключением, если каталоги, файлы и AD пользователя являются локальными. Не имея отдельных доменов для каждого из сайтов, это означает, что я могу управлять всем сервисом самостоятельно.
Я не совсем уверен, возможно ли подобное с сервером SBS. Если да, то какую ОС мне следует использовать в качестве центрального контроллера домена? Как мне настроить его так, чтобы AD и общие каталоги, GP и т. Д. Реплицировались на удаленные серверы? Могу ли я запустить несколько серверов Exchange в одном домене?
Любая помощь приветствуется!
Похоже на довольно простое развертывание.
Похоже, вы уже создали свой домен. Поскольку вы используете SBS, имейте в виду, что существующий компьютер SBS будет вынужден удерживать все гибкие одиночные роли Active Directory. Это, вероятно, не имеет большого значения, но ограничение в 75 пользователей в SBS может быть. В то время как SBS предлагает привлекательную цену для получения дешевого пакета Windows и Exchange, вам может быть лучше просто приобрести лицензии Windows и Exchange Server, если вы собираетесь приблизиться к пределу в 75 пользователей. Вы также не сможете использовать Windows SBS в каждом удаленном месте, если хотите, чтобы это была единая инфраструктура Active Directory / Exchange. У вас может быть только один Windows SBS Server в данном лесу Active Directory, поэтому вам нужно будет приобрести «обычные» лицензии Windows Server и Exchange Server для удаленных расположений. (Я бы лично приобрел рабочие места с корпоративной лицензией Windows Server 2008, чтобы вам было разрешено «понизить» права до W2K3 и чтобы вы могли переназначить программное обеспечение новым серверным компьютерам в будущем без «повторной покупки» "так же, как и с программным обеспечением с лицензией OEM ...)
Этот начальный контроллер домена должен быть DNS-сервером, и он должен использовать либо корневые ссылки, либо перенаправители на DNS-серверы вашего интернет-провайдера, чтобы разрешить им имена в Интернете. Если вы хотите использовать его в качестве DHCP-сервера для локальной сети на центральном сайте, настройте и его.
Это также хорошее время, чтобы спланировать IP-подсети, которые вы будете использовать для удаленных офисов, и создать записи для сайтов (группы подсетей, которые имеют «хорошее» соединение между ними - обычно одно местоположение WAN / VPN ), подсети и ссылки на сайты. Если ваш VPN представляет собой сетку, вы можете соединить все сайты вместе с помощью одной ссылки на сайт. Если ваша VPN является распределенной, вам следует создать ссылку на сайт для подключения каждого распределенного сайта к центральному сайту. Если ваша VPN не позволяет передавать данные от одного луча к другому через концентратор, вам следует отключить параметр «Мостить все ссылки сайтов». Я замалчиваю это без дополнительных подробностей, но вы можете найти подробную документацию от Microsoft. Правильное понимание этого важно для правильной работы репликации Active Directory и правильной работы доставки почты Exchange 2007 на удаленные серверы. (Если вы придерживаетесь E2K3, разветвления топологии сайта Active Directory не будет.)
Поскольку ваш домен уже существует, вы можете начать создание контроллеров домена для удаленных сайтов. Вы можете сделать это через VPN-соединения или можете подготовить серверы в LAN с начальным DC. В любом случае убедитесь, что новые контроллеры домена, которые начинают свою жизнь как «обычные» машины Windows Server, используют исходный контроллер домена для DNS, пока они не станут репликами контроллеров домена для вашего домена. Прежде чем продолжить, убедитесь, что машины, которые становятся репликами контроллеров домена, имеют хороший DNS. Вы должны иметь возможность найти доменное имя AD с помощью «nslookup» и получить обратно существующие имена / адреса DC. Если не можете, прежде чем продолжить, выясните, почему.
После того, как вы повысили реплику контроллера домена, установите на нем службу DNS-сервера. Убедитесь, что каждый DC для удаленного офиса также помечен как сервер «Глобального каталога» (в свойствах «NTDS Settings» под объектом сервера в «Active Directory Sites and Services»). Это ускорит вход в систему на клиентских компьютерах и заставит доставку электронной почты Exchange работать без необходимости использования VPN в каждом удаленном месте.
Использование одного домена Active Directory приведет к тому, что все ваши серверы будут совместно использовать общую базу данных Active Directory, включая учетные записи пользователей, группы, OU, групповую политику и т. Д. Если у вас нет очень большого количества пользователей (и, поскольку вы планируете использовать SBS, вы все равно ограничены одним доменом) у вас должно быть все в порядке с одним доменом AD для всего. (Черт возьми, даже если бы у вас было очень большое количество пользователей, я бы все равно направил вас к одному домену, если у вас не было другого смягчающего фактора, из-за которого вам понадобилось несколько доменов.)
Я бы планировал, чтобы объекты групповой политики обрабатывали «перенаправление папок» в общие папки на каждом контроллере домена удаленного офиса для папок «Мои документы» и «Рабочий стол» пользователя. Я бы также развернул перемещаемые профили пользователей. Я бы работал над созданием клиентских компьютеров без гражданства. Я бы организовал свои пользовательские объекты в подразделения, которые представляют удаленные местоположения, а затем по ролям оттуда, если необходимо. (Я делаю это исходя из предположения, что вы, вероятно, в конечном итоге делегируете управление какому-нибудь «человеку-компьютеру» в каждом удаленном месте для выполнения сброса пароля, так что расположение пользователей по физическому местоположению поможет вам в некотором роде.)
Я бы поместил клиентские компьютеры в подразделения, представляющие каждое удаленное местоположение, и при необходимости применил групповые политики (для направления клиентов на соответствующий сервер WSUS и т. Д.). Позже я бы использовал DFS и репликацию (тип которой зависит от версии Windows Server), чтобы реплицировать иерархию папок, содержащую любые пакеты установщика Windows для программного обеспечения, которое вы хотите «протолкнуть» на клиентские компьютеры на удаленном компьютере. офисов, так что в каждом офисе есть копия иерархии папок установочных пакетов.
Если у вас везде есть версия Windows Server R2, вы можете использовать репликацию DFS (DFS-R) для репликации иерархии папок с подчиненных серверов на хаб-сервер (и наоборот). Теоретически вы можете реплицировать иерархию папок на все распределенные серверы, чтобы пользователи могли прозрачно перемещаться между местоположениями и получать доступ к локально кэшированным копиям своего профиля и перенаправленных папок. На практике это обычно не работает, потому что репликация DFS-R не справляется с трафиком. Однако для поддержки центральной копии распределенных серверов на концентраторе в целях резервного копирования DFS-R может делать то, что вам нужно.
re: Exchange - я понимаю, что вы пытаетесь сделать с MX, я думаю. Вы заинтересованы в том, чтобы входящая Интернет-почта для каждого удаленного местоположения доставлялась непосредственно на SMTP-сервер этого местоположения, а не доставлялась в концентратор, а затем распределялась по VPN. Вы жестяная банка сделайте это, но из-за проблем с антивирусом электронной почты и спамом вы можете обнаружить, что имеет больше смысла доставлять электронную почту в концентратор, а затем распространять на сайты reomte.
Непонятно, что вы подразумеваете под «независимым» запуском Exchange. Все компьютеры с Exchange Server, установленные в одном лесу Active Directory, имеют общую конфигурацию, Exchange «Организация». Вам потребуется несколько лесов Active Directory, чтобы иметь несколько организаций Exchange, а вам это действительно не нужно.
Я бы развернул один компьютер с Exchange Server в каждом удаленном месте. На каждом компьютере с сервером Exchange будут размещаться почтовые ящики для пользователей в этом месте, и он сможет доставлять электронную почту непосредственно в Интернет и на другие компьютеры с сервером Exchange в сети.
Если вы думаете, что вам вообще нужны SMTP-адреса и MX-адреса для Exchange для работы, то это не так. Exchange не использует записи MX для доставки электронной почты между разными компьютерами Exchange Server одной организации Exchange.
В своей сети вы должны развернуть дополнительные «группы маршрутизации» Exchange, каждая из которых представляет удаленное местоположение и содержит компьютер с сервером Exchange для этого удаленного местоположения. «Соединители групп маршрутизации» (или другие типы «соединителей») используются для передачи топологии сети в Exchange (подобно тому, как Active Directory использует топологию «сайт» и «связь сайтов» для расчета путей репликации). Exchange «просто знает», как связаться с соответствующим удаленным сервером, когда электронная почта отправляется из одного удаленного места в другое. В этом процессе не используются SMTP-адрес и записи MX.
Мне непонятно, почему вы беспокоитесь о том, что VPN не будет работать 24 x 7. Он виртуальный по своей природе, поэтому не должно быть дополнительных затрат на постоянную доступность VPN. Я бы использовал качественное аппаратное оконечное оборудование VPN для завершения VPN-туннелей в каждом удаленном месте либо в режиме концентратора, либо в режиме ячеистой сети, в зависимости от того, сколько у вас удаленных местоположений. (Лично я бы использовал либо устройства Cisco ASA-5505, либо небольшие серверные компьютеры под управлением Linux и OpenVPN, но существует множество возможных решений.)
Вы жестяная банка запланировать репликацию Active Directory (и даже репликацию почты Exchange / репликацию общих папок) в нерабочее время, если вы хотите, чтобы трафик через VPN был в разумных пределах свободным в обычные рабочие часы. На мой взгляд, я бы поддерживал VPN в рабочем состоянии 24 x 7 и использовал бы его для постоянного трафика AD и Exchange, поскольку может показаться, что вы пытаетесь сохранить файлы пользователей в каждом офисе, и, как правило, пользователи не будут отправлять трафик через VPN.
Я рекомендую развернуть службы обновления программного обеспечения Windows (WSUS), пока вы делаете все это. Вы можете получить документацию от Microsoft по конкретным вопросам, но я бы планировал использовать центральный сервер WSUS с серверами реплик, работающими в каждом удаленном месте. Как я сказал ранее, я бы использовал групповую политику, применяемую либо в удаленном подразделении, либо на сайте Active Directory, чтобы направлять клиентские компьютеры на их ближайшую реплику WSUS.
Без сомнения, вам скажут, что для этого вам понадобятся различные отдельные серверы в каждом удаленном месте. Вы можете использовать отдельную физическую или виртуальную машину для каждой «роли», если хотите. Я скажу вам, исходя из своего собственного опыта, что вы могли бы обойтись с одной физической машиной, действующей как файловый сервер, DC, сервер WSUS и сервер Exchange в каждом удаленном месте, просто отлично, пока машина "мощная" "достаточно для количества пользователей в локации. Это было бы отлично иметь физически отдельные машины, но только если этого требует нагрузка. (Теперь сомневаюсь, что я получу комментарии от противников о том, что Microsoft не «рекомендует» запускать Exchange на контроллере домена ... и хотя это правда, продукт Windows SBS делает именно это, и он отлично работает. Все, что я могу понять, это то, что у этих типов комментаторов либо неограниченный бюджет для покупки лицензий Windows Server, либо им никогда не приходилось иметь дело с реалиями, когда небольшой бюджет имеет большое значение.)
Помните, что в этом сценарии у ваших пользователей не будет центрального URL-адреса для доступа к Outlook Web Access для веб-почты. Exchange может предоставить такой центральный URL-адрес, но это будет основано на наличии компьютера с «передним» сервером Exchange, который будет обращаться к «внутренним» серверам в каждом удаленном месте через VPN. Возможно, было бы разумнее сообщить пользователям о доступе к OWA через URL-адрес удаленного местоположения, а затем предоставить соответствующие переадресации портов в каждом удаленном местоположении для OWA.
Уф. Это было весело.
Если вы не очень хорошо знакомы с задействованными продуктами, вам стоит потратить некоторое время на лабораторный сценарий, моделирующий это. Если вы все еще обеспокоены, найдите консультанта (с хорошими рекомендациями), который будет работать с вами лицом к лицу в течение нескольких часов, выполняя настройку для первого удаленного офиса. Делайте подробные заметки, задавайте много вопросов и собирайте все необходимые сведения, чтобы вы могли выполнять следующие офисы самостоятельно. (Вы не поверите, но есть консультанты, которые с радостью «научат человека ловить рыбу». Лично я ненавижу повторяющуюся работу и, хотя мне нравится зарабатывать деньги, я лучше научу Заказчика, как делать что-то самостоятельно, если они так выбирают, чем повторяют одно и то же снова и снова.)
Как я уже сказал, это довольно простое развертывание. Вы пытаетесь использовать продукты (возможно, за исключением SBS, в зависимости от количества пользователей) именно для того, для чего они были предназначены, и вы не обнаружите, что «боретесь» с продуктами.
Вы можете сделать все это без указания сайта пользователя в адресе электронной почты. Вы просто помещаете почтовый ящик пользователей на сервер их сайта. Затем, когда они отправляют почту пользователю на другом сайте, сеть Exchange обрабатывает все это, когда между сайтами устанавливается VPN-соединение.
Время от времени вам потребуется VPN-соединение между сайтами для обработки репликации AD и репликации файлового сервера.
Здесь вы выходите за рамки SBS. Вы, вероятно, захотите просто получить несколько лицензий Windows 2003, чтобы справиться со всем. По одному на каждый сервер. Вы можете виртуализировать все это в VMware или Hyper-V, так что вам понадобится только один или два физических сервера на каждом сайте.
По словам Гарри Белсфорда, написавшего много книг о SBS, у него есть одно простое правило: SBS завершается, если вы расширяетесь на второй сайт. Когда я консультировал SBS, это мне очень помогло. Хотя SBS можно превратить в какую-то многосайтовую вещь, вы смотрите на дополнительные расходы на сервер, которые превращают разницу между вашим первым сервером и SBS в очень незначительную стоимость. Вы ничего не говорите о количестве пользователей в каждом офисе. Было бы полезно узнать, равно ли это число 10 (я бы ни в коем случае не развернул сервер Exchange для конкретного сайта для 10 пользователей), 100 (возможно) или 1000 (все же возможно). Все сводится к качеству ваших WAN-ссылок, типу трафика, через который вы отправляете (существует большая разница между типом трафика компании, занимающейся художественной / графикой, и издателя, который работает только с текстовыми файлами).
Итак, было бы здорово получить немного дополнительной информации, прежде чем мы (по крайней мере, я) сможем что-то сказать об этом.