Мос малка ферма инсталация и конфигурация война история

Тази седмица, Аз съм се борят малко с моя екип да получите Мос, инсталирани в една проста две сървърна група. След като преминали през него, Имам по-голяма благодарност за вида на проблеми хората доклад на форумите на MSDN и другаде.

Конфигурацията на крайната ферма:

  • SQL/индекс/интранет WFE вътре в защитната стена.
  • WFE в DMZ.
  • Някаква защитна стена между DMZ и вътрешния сървър.

Преди да започнем проекта, Ние нека клиентът знае кои пристанища трябва да бъдат отворени. По време на даване и получаване, назад и напред през този, Ние никога не изрично каза две важни неща:

  1. SSL означава ви трябва сертификат.
  2. DMZ сървърът трябва да бъде част от домейн.

Един ден, Ние се появи да инсталират МЪХА и научих, че не е бил създаден акаунтите на домейна за база данни и Мос. За да се движат нещата напред, Ние went напред и настанявам всичко с локален акаунт на сървър, интранет.

В този момент, открихме объркване през SSL сертификата и, за съжаление, решихме да нашия инфраструктура човек се върне по-късно тази седмица да продължите с инсталирането на DMZ сървъра. Междувременно, Ние разтвор архитекти преместени напред с бизнес неща.

Един уикенд течение и клиента получава сертификат.

Нашата инфраструктура човек показва и открива, че DMZ сървърът не е присъединен към домейн (периметър домейн с ограничено доверие или домейн интранет). Ние губи почти 1/2 деня, в който. Ако не оставим липсващите SSL сертификата ни блато, Ние ще са открили това по-рано. О добре….

Друг ден преминава и различните комитети, сигурност, заинтересовани страни и (не е така) невинни минувачи всички са съгласни, че това е ОК, за да се присъединят в DMZ сървър с домейна на интранет (Това е Рос, Все пак, не на производството решение).

Инфраструктурата човек идва, за да приключи нещата. Този път, ние успешно преминават през съвременните ръкавицата предано, известна като "съветника за конфигуриране на SharePoint." Ние имаме един поглед в централното администриране and … Иии haw! … DMZ сървър е в списъка в земеделското стопанство. Ние изглежда малко по-близо и реализира Скъсахме отворен Шампейн акар малко рано. ВиК услуги се заби в "Начална" статус.

Дълга история кратко, Оказва се, че сме забравили да промените самоличността на акаунта на услугата чрез централната администрация от оригиналния мастен сметка към новия домейн акаунт. Ние го направихме, отново се завтече на съветника за конфигуриране и готово! Ние бяхме в бизнеса.

</край>

Абонирайте се за моя блог.

5 мисли за "Мос малка ферма инсталация и конфигурация война история

  1. Cimares
    Това е напълно ОК, за да накарате вашата SQL в друга Vlan/подмрежа от вашия WFEs. В действителност се препоръчва, в крайна сметка, както е споменато по-горе, Каква сигурност експерт ще ви позволи да си SQL в dmz? Препоръката е, че трафика на SQL не използва един и същ интерфейс карти като трафика на потребителя, но дори тази връзка може да па през защитна стена за допълнителна защита.
    Ограничението, свързано с няколко WFEs в среда на земеделското стопанство се отнася до ако използвате Microsoft балансиране на натоварването, след това всички те трябва да са в една и съща VLan.
  2. Пол

    Аз почти може да победи си SSL сертификат за издаване. Имахме всичко, създадено и са готови за разширяване на уеб ап с SSL (след това пренасочване на порт 80 в IIS). Администраторът е .cer файл готов да отида. Но нито една от опциите или луд contortions да го прилагат в IIS ще работи–Сайтът винаги показва празна страница като колекцията не съществува.

    След много чука на глави, научихме, че това е причинено от cert искането не идва от този сървър. Администраторът просто попита за сигурен и е изпратена получения ключ. С никакъв частен ключ, SSL тунел може да не получите построен между WFE и на браузъра. Ние губи 1/2 деня, в който.

  3. Кристиан пише:
    Много интересно! Аз силно се съмнявам, че тя не трябва да бъде подкрепена за домакин WFE в един VLAN/DMZ и ап/SQL в друг VLAN/DMZ.
    Технически статии за Поддържани екстранет сценарии не разполагат с никакви резервации, или – but TechNet could be incorrect 🙂 None of our clients would allow their SQL Servers to sit on the same VLAN/DMZ as the WFE, така че аз искрено се надявам MS имам погрешно.
    Може ли да разработва върху това, което трябва да бъде проблем с плюене конфигурацията? Голяма производителност само? Или да те всъщност означават, че На WFE в трябва да бъде на същия VLAN/DMZ? Това ще направи по-дълбок смисъл за мен.
    Искрено,
    Християнски
  4. Пол Galvin
    Това е много добър въпрос.
    Ние сме проследяване отблизо на MS документация, така че не мога да си представя как те ще откажат да го подкрепят. Това каза, Аз не съм човек, инфраструктура, така че е възможно, че аз съм злоупотребява условия в моя пост.
    Както аз го разбирам, правилният подход е да има (най-малко) две АД домейни. Един вътрешен домейн и един в периметъра на мрежата. На мрежата периметъра Рекламата ще има "ограничена доверие" връзка с вътрешна реклама.
    But you probably already know all that 🙂
    Долната линия, Не знам. Ние не получават или директно на Microsoft с нетърпение за ориентиране на този един.
    –Пол G
  5. Том Диц
    Е поддържат тази конфигурация? Конференцията на SharePoint в Сиатъл през март, Бях чатите с някои Microsoft инженери и те казаха, че поддържани конфигурации не позволяват WFEs да пресече VLANs или рутери. Предполагам, че тъй като WFE е в DMZ, Той е пресичане някаква защитна стена/рутер или е в своя собствена VLAN.
    Така че основно DB и WFE/ап сървъри трябва да бъде на същия VLAN.
    Те са наистина твърдо за това–Това е всъщност слайд в "географски’ разполагане на сесия ако имате достъп до палубата.
    Аз съм чел технически статии, които илюстрират примерни конфигурации, които противоречат на техните изявления, но MS момчетата основно каза, че технически не е наред.

Оставете отговор

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани *