MOSS lille gård Installation og konfiguration krig historie

Denne uge, Jeg har kæmpet lidt med mit hold til at få mos installeret i en simpel to-serverfarm. Efter at have gået igennem det, Jeg har en større forståelse for slags problemer folk rapport på MSDN fora og andre steder.

Den endelige farmkonfiguration:

  • SQL/Index/Intranet hele Fiskeækvivalenter inden for firewall'en.
  • Hele Fiskeækvivalenter i DMZ.
  • En slags firewall mellem DMZ og den interne server.

Før vi startede projektet, vi lade kunden vide, hvilke porte skal være åbne. Under give og tage, frem og tilbage over det, vi sagt aldrig udtrykkeligt to vigtige ting:

  1. SSL betyder, at du skal bruge et certifikat.
  2. DMZ server skal være en del af et domæne.

Dag ét, Vi dukkede op for at installere MOSS og lært at domænekonti for databasen og mos ikke havde været lavet. At flytte ting, Vi gik videre og installeret alt med en lokal konto på serveren, intranet.

På dette punkt, vi opdagede forvirringen over SSL-certifikat og, Desværre, besluttede at have vores infrastruktur fyr kommer tilbage senere i denne uge til at fortsætte med at installere DMZ server. I mellemtiden, Vi løsning arkitekter flyttede videre med business ting.

En weekend går og som klienten henter certifikatet.

Vores infrastruktur fyr dukker op og opdager, at DMZ server ikke er tilsluttet noget domæne (enten en perimeter domæne med begrænset tillid eller domænet intranet). Vi spildte næsten en 1/2 dag på at. Hvis vi havde lade mangler SSL-certifikatet Mose os ned, Vi ville have opdaget det tidligere. Åh godt….

En anden endagsbilletter og de forskellige udvalg, sikkerhed, interesserede parter og (ikke så) uskyldige tilskuere alle er enige om at det er OK at deltage DMZ server med domænet intranet (Dette er en POC, Efter alt, ikke en produktion løsning).

Infrastruktur fyr kommer til wrap ting op. Denne gang vi med held passerer gennem den moderne spidsrod kærligt kendt som "konfigurationsguiden af SharePoint." Vi har et kig i central administration og … Yee haw! … DMZ server er opført i gården. Vi ser lidt nærmere og indser vi brød åben Champaign lidt mide tidligt. WSS tjenester sidder fast i en "starter" status.

Lang historie kort, Det viser sig, at vi glemte at ændre identiteten af tjenestekonto via central administration fra den oprindelige lokale konto til det nye domæne-konto. Vi gjorde det, re-løb konfigurationsguiden og voila! Vi var i erhvervslivet.

</slutningen>

Abonner på min blog.

5 tanker om ”MOSS lille gård Installation og konfiguration krig historie

  1. Cimares
    Det er helt ok at have din SQL i et andet Vlan/undernet end din WFEs. Faktisk anbefales det, jo som før nævnt, Hvad sikkerhedsekspert vil lade dig holde SQL i dmz? Anbefalingen er at din SQL trafik ikke anvender de samme interface kort som bruger-trafik, Men selv denne forbindelse kan pas gennem en firewall for yderligere beskyttelse.
    Begrænsning relateret til flere WFEs i en gård miljø vedrører, hvis du bruger Microsoft belastningsjustering, derefter skal disse alle være i samme VLan.
    Svar
  2. Paul

    Jeg kan næsten slå dit SSL certifikat problem. Vi havde alt lavet og var parat til at forlænge WebApp med SSL (Omdiriger derefter porten 80 i IIS). Administratoren havde en .cer-fil klar til at gå. Men ingen af indstillinger eller skøre krumspring at anvende det i IIS vil arbejde–webstedet vises altid en tom side som gruppen af websteder ikke findes.

    Efter meget banging hoveder, Vi har lært dette var forårsaget af cert anmodning ikke kommer fra den pågældende server. Administratoren simpelthen spurgte for en cert og blev sendt den nøgle. Med ingen privat nøgle, SSL-tunnel kunne ikke få bygget mellem det hele Fiskeækvivalenter, og browseren. Vi går til spilde 1/2 dag på at.

    Svar
  3. Christian skrev:
    Meget interessant! Jeg tvivler stærkt på at det ikke bør støttes for at være vært for den hele Fiskeækvivalenters i ét VLAN/DMZ og APP/SQL i et andet VLAN/DMZ.
    TechNet-artiklerne om Understøttede Extranet scenarier ikke har nogen forbehold, enten – but TechNet could be incorrect 🙂 None of our clients would allow their SQL Servers to sit on the same VLAN/DMZ as the WFE, så jeg håber inderligt, fik at MS det galt.
    Du kan uddybe hvad skal problemet med spytte konfigurationen? Ydeevne grunde kun? Eller mener de i virkeligheden, at den Hele Fiskeækvivalenters bør være på den samme VLAN/DMZ? Det ville give mere mening for mig.
    Med venlig hilsen,
    Christian
    Svar
  4. Paul Galvin
    Det er et meget godt spørgsmål.
    Vi sporer meget nøje til MS dokumentation, så jeg ikke kan forestille mig, hvordan de ville nægte at støtte det.. Sagde, Jeg er ikke en infrastruktur person, så det er muligt, at jeg misbruger vilkår i mit indlæg.
    Som jeg forstår det, den korrekte fremgangsmåde er at have (mindst) to AD domæner. En indre gebet og en i det afskærmede netværk. Det afskærmede netværk annonce ville have et "begrænset tillid" forhold til den indre AD.
    But you probably already know all that 🙂
    Bundlinjen, Jeg ved det ikke. Vi ikke modtage eller kigge direkte til Microsoft efter vejledning på denne ene.
    –Paul G
    Svar
  5. Tom Dietz
    Understøttes denne konfiguration? SharePoint-konferencen i Seattle i marts, Jeg var chatter med nogle Microsoft Engineers og sagde de understøttede konfigurationer ikke tillader WFEs at krydse VLAN'er eller routere. Jeg antager, at da den hele Fiskeækvivalenter er i en DMZ, det krydser en slags firewall/router eller er i sin egen VLAN.
    Så dybest set skal DB og hele Fiskeækvivalenter/App servere være på samme VLAN.
    De var virkelig stejlt på dette–Det er faktisk et dias den ' geografiske’ installation session hvis du har adgang til dæk.
    Jeg har læst TechNet-artiklerne, der illustrerer prøve konfigurationer, der modsiger deres udtalelser, men MS fyre dybest set siger, at teknik er forkert.
    Svar

Efterlad et svar

Din e-mail adresse vil ikke blive offentliggjort. Krævede felter er markeret *