MOSS Փոքր Farm տեղադրում եւ կարգավորում War Story

5 Գրառումներ

Այս շաբաթ, I’ve struggled a bit with my team to get MOSS installed in a simple two-server farm. Having gone through it, Ես ավելի մեծ երախտագիտություն համար տեսակի խնդիրների մարդիկ զեկույց MSDN ֆորումներում եւ այլուր.

Վերջնական ֆերմա կոնֆիգուրացիա:

  • SQL / համաթիվ / Intranet WFE ներսում firewall-.
  • WFE է DMZ.
  • Ինչ firewall-ի միջեւ DMZ եւ ներքին սերվերի.

Մինչ մենք սկսեցինք այդ ծրագիրը, we let the client know which ports needed to be open. During the give and take, ետ եւ առաջ ավարտվել է, Մենք երբեք բացահայտ ասել է երկու կարեւոր բան:

  1. SSL նշանակում է, դուք պետք է վկայական.
  2. The DMZ server must be part of a domain.

Օր մեկը, 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.

Այս պահին, Մենք իմացանք, որ շփոթություն է SSL վկայականի, տխուր, decided to have our infrastructure guy come back later that week to continue installing the DMZ server. Իսկ միջին ժամանակը, մենք լուծույթ ճարտարապետներ շարժվել առաջ, ինչպես նաեւ գործարար կազմի.

Մի շաբաթ գնում է, եւ հաճախորդը ստանում է վկայական.

Մեր ենթակառուցվածքը guy ցույց է տալիս ու հայտնաբերում է, որ DMZ սերվերը չի միացել որեւէ տիրույթում (կամ մի պարագծային տիրույթը սահմանափակ վստահության կամ Intranet դոմենից). We wasted nearly a 1/2 օր է, որ. If we hadn’t let the missing SSL certificate bog us down, we would have discovered this earlier. Oh well….

Եվս մեկ օր անցնում է, եւ բազմաթիվ անվտանգության հանձնաժողովները, շահագրգիռ կողմերը եւ (ոչ այնքան) անմեղ bystanders բոլորս համաձայն ենք, որ դա նորմալ է միանալ DMZ սերվերի հետ Intranet տիրույթում (սա POC, ի վերջո, ոչ արտադրական լուծում).

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 ալոճ! … 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" կարգավիճակ.

Երկար պատմությունը կարճ, 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, վերակազմակերպման վազեց կազմաձեւման Wizard եւ voila! We were in business.

</վերջ>

Անդամագրվել իմ բլոգում.

Արորդիների Tags:

5 thoughts on "MOSS Փոքր Farm տեղադրում եւ կարգավորում War Story”

  1. Cimares
    Դա հիանալի ok ունենալ ձեր SQL տարբեր VLAN / ենթացանցերի հասցեներով, քան ձեր WFEs. Իրականում այն ​​խորհուրդ է տրվում, Ի վերջո, ինչպես նշված է, ինչ է անվտանգության փորձագետ է Ձեզ մնում SQL է dmz? Խորհուրդն այն է, որ ձեր SQL երթեւեկությունը չի օգտագործում են նույն ինտերֆեյսի քարտերը, ինչպես նաեւ օգտագործողի երթեւեկությունը, Սակայն նույնիսկ այդ կապը կարող է դեսպանատան միջոցով firewall լրացուցիչ պաշտպանության.
    The restriction related to multiple WFEs in a farm environment relates to if you’re using Microsoft load balancing, ապա դրանք պետք է լինեն նույն VLAN.
    Պատասխանել ↓
  2. Paul

    I can almost beat your SSL certificate issue. We had everything created and were ready to extend the web app with SSL (ապա վերահղման նավահանգիստ 80 ի 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–կայքը միշտ ցուցադրում դատարկ էջ նման կայքի հավաքածուն գոյություն չունի.

    Հետո շատ banging եւ ղեկավարների, we learned this was caused by the cert request not coming from that server. The administrator simply խնդրել 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 օր է, որ.

    Պատասխանել ↓
  3. Christian գրել:
    Շատ հետաքրքիր! 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.
    Ի TechNet Հոդվածներ Մեր մասին օժանդակությամբ Extranet սցենարներ չունի որեւէ վերապահում, կամ – 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 ստացել սխալ.
    Կարող եք անդրադառնալ, թե ինչ պետք է լինի խնդիրն spitting կոնֆիգուրացիան? Արդյունավետության պատճառներ են? Կամ նրանք, ըստ էության նշանակում է, որ WFE է պետք է լինի նույն VLAN / DMZ? Որ ավելի շատ իմաստ ինձ.
    Sincerely,
    Քրիստոնյա
    Պատասխանել ↓
  4. Paul Galvin
    Դա շատ լավ հարց է.
    Մենք հետեւել ենք սերտորեն է MS փաստաթղթերի, so I can’t imagine how they would refuse to support it. Դա ասել է,, Ես ոչ թե ենթակառուցվածքների անձ, ուստի հնարավոր է, որ ես չարաշահել ժամկետը իմ գրառմանը.
    Քանի որ ես հասկանում, the correct approach is to have (առնվազն) two AD domains. One internal domain and one in the perimeter network. The perimeter network’s AD would have a "limited trust" հետ ներքին AD.
    But you probably already know all that 🙂
    Ստորին գիծ, Չգիտեմ. We did not receive or look directly to Microsoft for guidance on this one.
    –Paul G
    Պատասխանել ↓
  5. Tom DIETZ
    Սա կոնֆիգուրացիա աջակցությամբ? 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.
    Այնպես որ, հիմնականում DB եւ WFE / App Սերվերներ բոլորն էլ պետք է նույն VLAN.
    Նրանք իրոք անդրդվելի մասին–it’s actually a slide in the ‘Geographical’ տեղակայումը նստաշրջանը, եթե դուք օգտվել տախտակամած.
    Ես կարդացել TechNet հոդվածներ, որոնք ցույց են տալիս օրինակելի configurations հակասող իրենց հայտարարություններով, բայց MS տղաները հիմնականում ասել է, որ TechNet սխալ.
    Պատասխանել ↓

Ավելացնել կարծիք

Ձեր էլ. Փոստի հասցեն չի հրապարակվելու. Պահանջվող դաշտերը նշված են աստղանիշով *