MOSS småbruk installasjon og konfigurasjon krigen historie

Denne uken, Jeg har slitt litt med mitt lag å få MOSS installert i en enkel to-serverfarm. Etter å ha gått gjennom den, Jeg har en større forståelse for slags problemer folk rapport på MSDN-foraene og andre steder.

Den endelige farmkonfigurasjonen:

  • SQL/Index/intranett WFE innenfor brannmuren.
  • WFE i DMZ.
  • En slags brannmuren mellom DMZ og den interne serveren.

Før vi startet prosjektet, Vi lar klienten vet hvilke porter måtte være åpne. Under gi og ta, frem og tilbake over som, vi sa aldri uttrykkelig to viktige ting:

  1. SSL betyr at du trenger et sertifikat.
  2. DMZ server må være del av et domene.

Dag én, Vi møtte opp for å installere MOSS og lært at domenekontoene for database og MOSS hadde opprettet. Å flytte ting sammen, Vi gikk foran og installert alt med en lokal konto på intranett-server.

På dette punktet, Vi oppdaget forvirring over SSL-sertifikatet og, Dessverre, besluttet å ha vår infrastruktur fyr komme tilbake senere denne uken fortsette installasjonen DMZ server. I mellomtiden, Vi løsning arkitekter flyttet frem med forretningsområder ting.

En helg går, og klienten får sertifikatet.

Vår infrastruktur fyr dukker opp og oppdager at DMZ server ikke er med i noe domene (enten en perimeterdomenekontrolleren med begrenset tillit eller intranett-domene). Vi kastet bort nesten en 1/2 dag på som. Hvis vi ikke hadde lar mangler SSL-sertifikatet knele oss, Vi hadde oppdaget dette tidligere. Nåvel….

En annen dag, passerer og de ulike sikkerhet-komiteene, interesserte parter og (ikke så) uskyldige tilskuere alle enige om at det er OK å delta DMZ server med intranett-domene (Dette er en POC, når alt kommer til alt, ikke en produksjon-løsning).

Infrastruktur fyr kommer inn å bryte ting opp.. Denne gangen vi kunne passere gjennom den moderne gapestokk kjærlig kjent som "konfigurasjonsveiviseren for SharePoint." Vi har en titt i Sentraladministrasjon og … Yee haw! … DMZ-serveren er oppført i farmen. Vi se litt nærmere og innser vi brøt åpen Champaign litt midd tidlig. WSS tjenester er fast i en "starter" status.

Lang historie kort, Det viser seg at vi glemte å endre identiteten til tjenestekontoen via Sentraladministrasjon fra den opprinnelige lokale kontoen til nye domenekontoen. Vi gjorde det, re-løp konfigurasjonsveiviseren og voila! Vi var i virksomhet.

</slutten>

Abonner på bloggen min.

Technorati Merkelapper:

5 tanker om “MOSS småbruk installasjon og konfigurasjon krigen historie

  1. Cimares
    Det er helt ok å ha din SQL i et annet Vlan/delnettverk enn din WFEs. Faktisk anbefales det, tross alt som nevnt før, Hva sikkerhetsekspert skal la deg stikke SQL i dmz? Anbefaling er at SQL-trafikk ikke bruker samme grensesnitt-kort som brukertrafikk, men selv denne tilkoblingen kan pas gjennom en brannmur for ytterligere beskyttelse.
    Begrensningen gjelder flere WFEs i et gården miljø gjelder hvis du bruker Microsoft belastningsfordeling, så må dette være i samme VLAN-nettverket.
    Svar
  2. Paul

    Jeg kan nesten slå SSL sertifikat problemet. Vi hadde alt opprettet og var klar til å utvide webprogrammet med SSL (Omdiriger deretter porten 80 i IIS). Administratoren hadde en CER-filen klar til å gå. Men ingen alternativer eller gal contortions bruke den i IIS fungerer–nettstedet viser alltid en tom side som områdesamlingen ikke finnes.

    Etter mye banging av hoder, vi lærte Dette skyldtes cert forespørselen ikke kommer fra serveren. Administratoren bare spurte for en cert og ble sendt nøkkelen. Med ingen privat nøkkel, SSL-tunnel kunne ikke får bygget mellom WFE og leseren. Vi kastet bort 1/2 dag på som.

    Svar
  3. Christian skrev:
    Meget interessant! Jeg tviler sterkt på at det ikke bør støttes hvis du vil plassere WFE på ett VLAN/DMZ og APP/SQL i et annet VLAN/DMZ.
    TechNet-artiklene om støttede ekstranett-scenarier ikke har noen reservasjoner, 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åper inderlig MS fikk det galt.
    Du kan utdype hva skal være problemet med spytter konfigurasjonen? Bare av ytelsesgrunner? Eller gjør de faktisk mener at den WFES bør være på samme VLAN/DMZ? Som ville være mer fornuftig for meg.
    Vennlig hilsen,
    Kristne
    Svar
  4. Paul Galvin
    Det er et veldig godt spørsmål.
    Vi sporer svært tett i MS-dokumentasjonen, så jeg ikke forestille meg hvordan de ville nekte å støtte det. Som sagt, Jeg er ikke en infrastruktur person, så det er mulig at jeg er misbruker vilkårene i mitt innlegg.
    Som jeg forstår det, riktig tilnærming er å ha (minst) to AD domener. En intern domene og ett i perimeternettverket. Perimeternettverkets annonse ville ha en "begrenset tillit" forhold til interne Annonsen.
    But you probably already know all that 🙂
    Bunnlinjen, jeg vet ikke. Vi ikke motta eller se direkte til Microsoft for veiledning på denne.
    –Paul G
    Svar
  5. Tom Dietz
    Støttes denne konfigurasjonen? Ved SharePoint Conference i Seattle i mars, Jeg pratet med noen Microsoft Engineers og de sa at støttede konfigurasjoner ikke tillater WFEs å krysse VLAN og rutere. Jeg antar at siden WFE i en DMZ, Det er krysset en slags brannmur/ruter eller er i sin egen VLAN.
    Så i utgangspunktet må DB og WFE/App servere alle være på samme VLAN-nettverket.
    De var veldig steinhard om dette–Det er faktisk et lysbilde i det ' geografisk’ distribusjon-økten hvis du har tilgang til dekk.
    Jeg har lest TechNet artikler som illustrerer prøven konfigurasjoner som motsier sine uttalelser, men MS gutta i utgangspunktet sa at teknikken er galt.
    Svar

legg igjen et svar

e-postadressen din vil ikke offentliggjøres. Obligatoriske felt er merket *