Домены Windows, 2003 SBS, Exchange и AD в нескольких сайтах/местоположениях

KDE был недавно портирован к Windows, таким образом, необходимо смочь использовать KPDF, который является большим.

http://windows.kde.org/

2
задан 20 October 2009 в 05:26
3 ответа

Походит на довольно простое развертывание.

Это кажется, что Вы уже создали свой домен. Так как Вы используете 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 и так, чтобы можно было повторно присвоить программное обеспечение новым серверам в будущем w/o "перепокупка" его, как Вы имели бы к с лицензируемым для OEM программным обеспечением...),

Этот начальный DC должен быть сервером DNS, и он должен использовать или корневые подсказки использования или средства передачи к серверам DNS Вашего ISP, чтобы позволить этому разрешать интернет-имена. Если Вы хотите использовать его в качестве сервера DHCP для LAN в центральном сайте, настройте это, также.

Это - также хорошее время, чтобы распланировать подсети IP, которые Вы будете использовать для удаленных офисов, и создать записи для сайтов (группы подсетей, которые имеют "хорошую" возможность соединения между ними - обычно незамужняя WAN / местоположение VPN), подсети и ссылки сайта. Если Ваша VPN является сеткой, можно соединить все сайты вместе с единственной ссылкой сайта. Если Ваша VPN является осевой, необходимо создать ссылку сайта для соединения, каждый говорил сайт с узлом связи. Если Ваша VPN не позволяет коммуникацию от, каждый говорил с другим, говорил через концентратор затем, необходимо выключить, "Соединяют все ссылки сайта мостом". Я заминаю этот w/o обеспечение большого количества детали, но можно найти подробную документацию от Microsoft. Разбирание в этом важно для разбирания в выполнении репликации Active Directory и доставке почты Exchange 2007, функционирующей правильно к удаленным серверам. (Если Вы придерживаетесь E2K3 затем нет никакого разветвления топологии сайта Active Directory.)

Так как Ваш домен уже существует, можно начать создавать DCS для удаленных сайтов. Можно сделать это через соединения VPN, или можно подготовить серверы на LAN с начальным DC. Так или иначе убедитесь, что новый DCS, которые запускают их жизни как "простые ванильные" машины Windows Server, использует начальный DC для DNS, пока они не продвинуты на то, чтобы быть DCS копии для Вашего домена. Проверьте, что машины, становящиеся DCS копии, имеют хороший DNS перед продолжением. Необходимо смочь к поиску AD доменное имя с помощью "nslookup" и возвратить exisiting имена DCS / адреса. Если Вы не можете, фигура почему перед продолжением.

После того как Вы продвинули DC копии, установите сервис DNS-сервера на него. Удостоверьтесь, что каждый DC для удаленного офиса также отмечен как "Глобальный Каталог" сервер (в свойствах "NTDS Settings" под серверный объектом в "Сайтах Active Directory и Сервисах"). Это ускорит входы в систему в клиентских компьютерах и заставит доставку электронной почты Exchange работать w/o требование VPN в каждом удаленном месте.

Используя единственный Active Directory домен заставит все Ваши серверы совместно использовать общую базу данных Active Directory, включая учетные записи пользователей, группы, OUs, групповую политику, и т.д. Если у Вас нет очень больших количеств пользователей (и, так как Вы - планирование использования SBS, Вы ограничены единственным доменом так или иначе), необходимо быть очень хорошо w/единственным доменом AD для всего. (Heck, даже если бы у Вас действительно были очень большие количества пользователей, я все еще регулировал бы Вас к единственному домену, если у Вас не было некоторого другого фактора смягчения, который заставил Вас нуждаться в нескольких доменах.)

Я запланировал бы объекты групповой политики обработать "Перенаправление Папки" в совместно используемые папки на каждом удаленном офисном DC для папок "My Documents" и "Desktop" пользователя. Я также развернул бы профили роумингового пользователя. Я работал бы к наличию клиентских компьютеров не сохраняющих состояние. Я организовал бы свои пользовательские объекты в OUs, которые представляют удаленные местоположения, и затем ролью оттуда, при необходимости. (Я делаю это учитывая, что Вы, вероятно, закончите тем, что делегировали управление для некоторого "компьютерного человека" в каждом удаленном месте для выполнения сбросов пароля, таким образом, положить пользователей физическим местоположением получит Вас часть пути там.)

Я поместил клиентские компьютеры в OUs, представляющий каждое удаленное местоположение, и применяю групповые политики по мере необходимости (прямым клиентам к соответствующему серверу WSUS, и т.д.). Позже, я использовал бы DFS и репликацию (которые вводят в зависимости от версии Windows Server, который Вы имеете) копировать иерархию папок, которая содержала любые пакеты Windows Installer для программного обеспечения, которое Вы хотите "выставить" к клиентским компьютерам в удаленных офисах, таких, что каждый офис имеет копию иерархии папок пакетов установки.

Если у Вас есть R2 verson Windows Server везде, можно использовать репликацию DFS (DFS-R) для тиражирования иерархий папок от, говорил серверы с сервером концентратора (и обратное). В теории Вы могли копировать иерархию папок в весь, говорил серверы, таким образом, что пользователи могли прозрачно переместить между местоположениями и доступом локально кэшируемые копии своего профиля и перенаправили папки. На практике это обычно не работает, потому что репликация DFS-R не заканчивает тем, что не отставала от трафика. Для поддержания центральной копии говорил серверы в концентраторе в целях резервирования, тем не менее, DFS-R может сделать то, в чем Вы нуждаетесь.

ре: Exchange - я вижу то, что Вы пытаетесь сделать с MX, я думаю. Вы интересуетесь наблюдением входящей интернет-электронной почты для каждого удаленного местоположения, поставленного непосредственно серверу SMTP того местоположения, по сравнению с тем, чтобы быть поставленным концентратору и затем распределены через VPN. Можно сделать это, но из-за почтового антивируса и проблем против спама можно найти, что имеет больше смысла поставлять электронную почту концентратору и затем распределенный reomte сайтам.

Неясно, что Вы подразумеваете под рабочим Exchange "независимо". Все компьютеры Exchange Server, установленные в том же лесу Active Directory, совместно используют общую конфигурацию, Exchange "Организация". У Вас должно было бы быть несколько лесов Active Directory, чтобы иметь несколько Организаций Exchange, и Вы действительно не хотите это.

Я развернул бы единственный компьютер Exchange Server в каждое удаленное местоположение. Каждый компьютер Exchange Server разместил бы почтовые ящики для пользователей в том месте и будет способен к поставке электронной почты непосредственно к Интернету и к другим компьютерам Exchange Server в сети.

Если Вы думаете, что Вам нужны "сайт-специфичные" адреса SMTP и MX для Exchange для работы вообще, это не имеет место. Exchange не использует записи MX для поставки электронной почты между различными компьютерами Exchange Server той же Организации Exchange.

В Вашей сети Вы развернули бы дополнительный Exchange "маршрутизация групп", каждый представляющий удаленное местоположение и содержащий компьютер Exchange Server для того удаленного местоположения. "Маршрутизация коннекторов группы" (или другие типы "коннекторов") используется для передачи топологии сети 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 Software Update Services (WSUS), в то время как Вы делаете все это, также. Можно получить документацию от Microsoft на специфических особенностях, но я запланировал бы центральный сервер WSUS с серверами копии, работающими в каждом удаленном местоположении. Как я сказал ранее, я буду использовать групповую политику, примененную или в удаленном местоположении OU или в сайте Active Directory к прямым клиентским компьютерам к их самой близкой копии WSUS.

Несомненно Вам скажут о необходимости в различных отдельных серверах в каждом удаленном месте для этого. Можно использовать отдельную реальную или виртуальную машину для каждой "роли", если Вы хотели бы. Я скажу Вам, на основе моего собственного опыта, что Вы могли обойтись единственной реальной машиной, действующей как файловый сервер, DC, сервер WSUS и Exchange Server в каждом удаленном месте очень хорошо, пока машина достаточно "раскормлена" для количества пользователей в месте. Было бы хорошо иметь физически отдельные машины, но только если загрузка гарантирует его. (Теперь сомнение, я получу комментарии от голосующих против о том, как Microsoft не "рекомендует" выполнить Exchange на DC... и в то время как это верно, продукт Windows SBS, делать просто, что, и она хорошо работает. Все, что я могу изобразить, - то, что эти типы комментаторов имеют или неограниченный бюджет для покупки лицензий Windows Server, или они никогда не должны были на самом деле иметь дело с фактами того, чтобы заставлять маленький бюджет иметь большое значение.)

Знайте, что у Ваших пользователей не будет центрального URL, с которым можно получить доступ к Веб-доступу Outlook для веб-почты в этом сценарии. Exchange может обеспечить такой центральный URL, но он был бы основан на наличии "Фронтэнда" компьютер Exchange Server, который получит доступ к серверам "Бэкэнда" в каждом удаленном месте через VPN. Могло бы просто иметь больше смысла говорить пользователям доступу OWA через удаленный определенный для местоположения URL и затем обеспечивать соответствующий порт вперед в каждом удаленном местоположении для OWA.

Ух. Это было забавой.

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

Как я сказал, это - довольно простое развертывание. Вы пытаетесь использовать продукты (возможно, за исключением SBS, в зависимости от Вашего пользовательского количества) для точно, для чего они были предназначены, чтобы использоваться, и Вы не собираетесь "бороться" с продуктами.

4
ответ дан 3 December 2019 в 09:13
  • 1
    Потрясающий ответ! –  atomicharri 20 October 2009 в 18:13
  • 2
    Большой ответ, Evan. Не желая разочаровать, у меня есть немного Нет Говорящее, чтобы сделать. Объединение некоторых приложений с DC (особенно обмен), конечно, может работать, но если что-нибудь пойдет не так, как надо, то Microsoft не будет поддерживать его. В бизнес-контексте, который важен для большого количества людей. Таким образом, мой совет был бы, если несколько ролей приложения должны работать на единственном поле, сделайте физическую установку, сервер Hyper-V затем добавляет каждую роль в отдельных виртуальных машинах. –  Tim Long 3 November 2009 в 02:46
  • 3
    Личный опыт показал мне это " не supported" от Microsoft во многом зависит от того, с кем Вы говорите в Product Support Services. Однако я могу найти обильную документацию, указывающую, что рабочий Exchange на кластерном узле, который является также контроллером домена, является " не supported" но I' m испытывающий затруднений, придумывающих документацию, говоря, что рабочий Exchange на контроллере домена является чем-то большим чем " не recommended". –  Evan Anderson 3 November 2009 в 06:30

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

Вам будет нужно соединение VPN между сайтами каждый однажды и некоторое время обработать AD репликацию и репликацию файлового сервера.

Вы добираетесь вне SBS здесь. Вы, вероятно, захотите просто заставить набор лицензий Windows 2003 обрабатывать все. Один для каждого сервера. Можно виртуализировать все это под VMware Hyper-V так, чтобы Вам только были нужны один или два физических сервера на каждом сайте.

2
ответ дан 3 December 2019 в 09:13
  • 1
    Я согласился бы с этим. Активные домены каталога должны использоваться для установки административных границ, не географических границ. It' s совершенно разумный и нормальный в лесу AD 2003 для многих сайтов, чтобы быть в том же домене. Плюс, имея всю почту прибывают в единственный сервер шлюза, помогает сделать сканирование антивируса (сервис как ExchangeDefender был бы превосходен для этого, и ED только поставит к единственному обозначенному IP-адресу). –  Tim Long 3 November 2009 в 02:50

По словам Harry Belsford, который записал много книг по SBS, у него есть одно простое правило: SBS заканчивается, если Вы расширяетесь до второго сайта. Когда я сделал консалтинг SBS, это служило мне хорошо. Хотя SBS можно настроить в некоторую многоузловую вещь, Вы смотрите на дополнительные затраты сервера, которые поворачивают различие между Вашим первым сервером и SBS в очень крайнюю стоимость. Вы ничего не говорите о числе пользователей в каждом офисе. Было бы полезно, чтобы иметь, знают, равняется ли это число 10 (никакой способ, которым я развернул бы сайт-специфичный Exchange Server для 10 пользователей), или 100 (возможно), или 1000 (все еще, возможно). Все это сводится к качеству Ваших каналов WAN, тип трафика, который Вы отправили бы через (существует большая разница между типом трафика художественной/графической компании и издателем, который только работает с текстовыми файлами).

Так, немного больше информации было бы большим, прежде чем мы (по крайней мере, I) сможем сказать что-то об этом.

1
ответ дан 3 December 2019 в 09:13

Теги

Похожие вопросы