MOSS პატარა მეურნეობა მონტაჟი და კონფიგურაცია ომის ამბავი

ამ კვირაში, I’ve struggled a bit with my team to get MOSS installed in a simple two-server farm. Having gone through it, მე მაქვს უფრო დიდი მადლიერება სახის პრობლემები ხალხს ანგარიშს MSDN ფორუმი და სხვაგან.

საბოლოო ფერმის კონფიგურაციის:

  • SQL / ინდექსი / ინტრანეტის 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.

Day ერთი, 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. In საშუალო დრო, ჩვენ გადაწყვეტა არქიტექტორები გადავიდა დააჩქაროს ბიზნეს პერსონალი.

კვირის ბოლოს გადის და დამკვეთი იღებს მოწმობა.

ჩვენი ინფრასტრუქტურა ბიჭი გვიჩვენებს up და აღმოაჩენს, რომ DMZ სერვერზე არ შეუერთდა არც ერთი domain (ან პერიმეტრზე domain შეზღუდული ნდობის ან ინტრანეტის domain). 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 ყველა თვლის, რომ ეს OK შეუერთდეს DMZ ​​სერვერზე ინტრანეტით domain (ეს 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 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" სტატუსი.

დიდხანს სიუჟეტი მოკლე, 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, ხელახალი გაიქცა კონფიგურაციის ოსტატი და voila! We were in business.

</ბოლო>

გამოწერა ჩემი დღიური.

პროგრამები Tags:

5 thoughts on "MOSS პატარა მეურნეობა მონტაჟი და კონფიგურაცია ომის ამბავი

  1. Cimares
    ეს მშვენივრად ok თქვენი SQL სხვადასხვა VLAN / subnet ვიდრე თქვენი WFEs. სინამდვილეში ეს რეკომენდირებული, შემდეგ ყველა, როგორც აღვნიშნეთ, რა უსაფრთხოების ექსპერტი აპირებს მოდით თქვენ გამყარებაში SQL in DMZ? რეკომენდაცია არის, რომ თქვენი SQL მიმოსვლის არ გამოიყენება იგივე ინტერფეისის პლატები როგორც შესახებ მიმოსვლის, თუმცა არც ეს კავშირი შეიძლება Pas მეშვეობით firewall დამატებითი დაცვა.
    The restriction related to multiple WFEs in a farm environment relates to if you’re using Microsoft load balancing, მაშინ ეს უნდა იყოს იგივე VLAN.
  2. პოლ

    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. ქრისტიან დაწერა:
    ძალიან საინტერესო! 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? ეს უფრო გრძნობა ჩემთვის.
    პატივისცემით,
    ქრისტიან
  4. პოლ 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.
    –პოლ G
  5. ტომ 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 / ოთახი სერვერები ყველა უნდა იყოს იმავე VLAN.
    ისინი მართლა დარწმუნებულია შესახებ–it’s actually a slide in the ‘Geographical’ განლაგების სხდომა, თუ თქვენ გაქვთ deck.
    მე წავიკითხე TechNet სტატია, რომელიც ასახავს ნიმუში კონფიგურაციის, რომლებიც ეწინააღმდეგება მათი განცხადებები, მაგრამ MS ბიჭები ძირითადად განაცხადა, რომ TechNet არასწორია.

დატოვე პასუხი

თქვენი ელ-ფოსტა არ გამოქვეყნდება. აუცილებელი ველები მონიშნულია *