MOSS Small Farm installasie en config Oorlog Story

5 antwoorde

Hierdie week, I’ve struggled a bit with my team to get MOSS installed in a simple two-server farm. Having gone through it, Ek het 'n groter waardering vir die aard van die probleme wat mense verslag te doen oor die MSDN forums en elders.

Die finale plaas opset:

  • SQL / Index / Intranet WFE die binnekant van die firewall.
  • WFE in die DMZ.
  • 'N soort van firewall tussen die DMZ en die interne bediener.

Voordat ons begin met die projek, we let the client know which ports needed to be open. During the give and take, heen en weer oor daardie, ons nooit uitdruklik gesê twee belangrike dinge:

  1. SSL beteken dat jy nodig het om 'n sertifikaat.
  2. The DMZ server must be part of a domain.

Dag een, we showed up to install MOSS and learned that the domain accounts for database and MOSS hadn’t been created. To move things along, we went ahead and installed everything with a local account on the intranet server.

Op hierdie punt, ons ontdek die verwarring oor die SSL sertifikaat en, ongelukkig, decided to have our infrastructure guy come back later that week to continue installing the DMZ server. In die gemiddelde tyd, Ons oplossing argitekte vorentoe beweeg met die besigheid goed.

'N naweek gaan verby en die kliënt verkry die sertifikaat.

Ons infrastruktuur man opdaag en ontdek dat die DMZ bediener is nie gekoppel aan enige domein (óf 'n omtrek domein met 'n beperkte trust of die intranet domein). We wasted nearly a 1/2 dag wat. If we hadn’t let the missing SSL certificate bog us down, we would have discovered this earlier. Oh well….

Nog 'n dag verby en die verskeie sekuriteit komitees, belanghebbende partye en (nie so) onskuldige omstanders almal eens dat dit OK is die DMZ bediener met die intranet domein aan te sluit (dit is 'n POC, na al, nie 'n produksie-oplossing).

Infrastructure guy comes in to wrap things up. This time we successfully pass through the the modern-day gauntlet affectionately known as the "SharePoint Configuration Wizard." We have a peek in central administration and … Yee Haw! … DMZ server is listed in the farm. We look a little closer and realize we broke open the Champaign a mite bit early. WSS services is stuck in a "starting" status.

Lang storie kort, it turns out that we forgot to change the identity of the service account via central administration from the original local account to the new domain account. We did that, re-hardloop die opset towenaar en voila! We were in business.

</einde>

Skryf in op my blog.

Technorati Tags:

5 gedagtes oor "MOSS Small Farm installasie en config Oorlog Story”

  1. Cimares
    Dit is heeltemal ok jou SQL te hê in 'n ander Vlan / subnet as jou WFEs. In werklikheid is dit aanbeveel, Na alles soos voorheen, Watter sekuriteit deskundige gaan om jou te laat SQL stok in die DMZ? Die aanbeveling is dat jou SQL verkeer nie gebruik van die dieselfde koppelvlak kaarte as die gebruiker verkeer, Maar selfs hierdie verband kan pas deur middel van 'n firewall vir ekstra beskerming.
    The restriction related to multiple WFEs in a farm environment relates to if you’re using Microsoft load balancing, dan is hierdie moet almal in dieselfde VLAN.
    Antwoord ↓
  2. Paul

    I can almost beat your SSL certificate issue. We had everything created and were ready to extend the web app with SSL (dan herlei hawe 80 in IIS). The administrator had a .cer file ready to go. But NONE of the options or crazy contortions to apply it in IIS will work–Die webwerf vertoon altyd 'n skoon bladsy soos die terrein versameling bestaan ​​nie.

    Na baie gebons van koppe, we learned this was caused by the cert request not coming from that server. The administrator simply gevra for a cert and was emailed the resulting key. With no private key, the SSL tunnel could not get built between the WFE and the browser. We wasted 1/2 dag wat.

    Antwoord ↓
  3. Christelike geskryf:
    Baie interessante! I highly doubt that it shouldn’t be supported to host the WFE’s in one VLAN/DMZ and APP/SQL in another VLAN/DMZ.
    Die TechNet artikels oor ondersteun Extranet scenario's het nie enige besprekings, óf – but TechNet could be incorrect 🙂 None of our clients would allow their SQL Servers to sit on the same VLAN/DMZ as the WFE, so ek hoop die MS het dit verkeerd.
    Kan jy uitbrei oor wat die probleem met die spoeg die opset wees? Prestasie redes net? Of doen hulle dit in werklikheid beteken dat die WFE se behoort te wees op dieselfde VLAN / DMZ? Dit sou meer sin maak vir my.
    Die uwe,
    Christian
    Antwoord ↓
  4. Paul Galvin
    Dit is 'n baie goeie vraag.
    Ons is baie nou dop tot die MS dokumentasie, so I can’t imagine how they would refuse to support it. Wat gesê het:, Ek is nie 'n infrastruktuur persoon, so dit is moontlik dat ek terme is misbruik in my post.
    Soos ek dit verstaan, the correct approach is to have (ten minste) two AD domains. One internal domain and one in the perimeter network. The perimeter network’s AD would have a "limited trust" verhouding met die interne AD.
    But you probably already know all that 🙂
    Bottom line, Ek weet nie. We did not receive or look directly to Microsoft for guidance on this one.
    –Paul G
    Antwoord ↓
  5. Tom Dietz
    Is hierdie opset ondersteun? At the SharePoint Conference in Seattle in March, I was chatting with some Microsoft Engineers and they said that supported configurations do not allow WFEs to cross VLANs or routers. I assume that since the WFE is in a DMZ, it is crossing some sort of firewall/router or is in its own VLAN.
    So basies die DB en WFE / inligting Servers almal het om te wees op dieselfde VLAN.
    Hulle was regtig vasbeslote oor hierdie–it’s actually a slide in the ‘Geographical’ ontplooiing sessie as jy toegang het tot die dek.
    Ek het gelees TechNet artikels wat illustreer monster konfigurasies wat weerspreek hul verklarings, maar die MS ouens het basies gesê dat TechNet is verkeerd.
    Antwoord ↓

Laat 'n antwoord

Jou e-posadres sal nie gepubliseer word nie. Verpligte velde gemerk *