Yhdessä tai minun ensimmäinen blogiviestit, Me sen jälkeen siirtää asiakkaan SPS kokonaisprosessia on kuvattu 2003 Moss. Lukija vasemmalle kommentti kysytte tarkemmin ja tässä se on.

Maahanmuuton projektin, Meillä oli löytää hyvä tapa siirtää SPS paljon 2003 asiakirjat yli Moss. Ensimmäinen kuormitus oli helppo. Luo uusi kohdetiedostokirjasto MOSS ja siirtää tiedostot Resurssienhallinnan avulla.

Tämä on uusi asiakirjakirjasto:

Avata kaksi ikkunaa tutkimusmatkailijat. SPS ensimmäinen pisteeseen 2003 ja toinen MOSS uuteen asiakirjakirjastoon. Seuraavat kuvakaappaus osoittaa tämän. Huomaa, että top-selain on todella suunnattu minun c:\Temp asema, mutta voitte kuvitella, se osoittaa SPS 2003 asiakirjakirjaston:

Tämän jälkeen vetämällä ja pudottamalla, minun tavoite näyttää tältä:

Nyt on aika käsitellä metatiedot. On vain yksi sarake metatietojen näiden asiakirjojen nimeltä "sijainti." Voimme nähdä edellä "kaikki asiakirjat" Katso, että sijainti on tyhjä. Se on helppoa, kirjoita sijainti tietoja taulukkonäkymän avulla, tai jopa mennä kunkin asiakirjan ominaisuuksia yksi kerrallaan lisää sijainti. Oletetaan, että ei ole käytännöllinen tapa määrittää sijainti-sarakkeen arvon automaattisesti ja että loppukäyttäjien tulee tehdä käsin. Lisäksi, Oletetaan että on olemassa satoja asiakirjat (ehkä tuhansia) ja että se kestää monta monta päivää päivittämään metatiedot. Kuten me kaikki tiedämme, kukaan ei istua alas ja toimi neljä viisi päivää peräjälkeen, päivityksen metatiedot asiakirjat. Sen sijaan, ne puhkeaa että ajan viikkoja tai mahdollisesti pidempään. Tämän prosessin helpottamiseksi, voimme luoda "korvamerkittöminä tiedot" Katso kuten:

Nyt, Kun joku istuu alas viettää kohdistettu päivittäin tunnin tai kaksi tag siirretyt tiedostot, he voivat käyttää "korvamerkittöminä-asiakirjat" Katso keskittyä niiden työtä:

Käyttäjien tag asiakirjoina, ne pudota pois tästä luettelosta.

Tämä käsite korvamerkittöminä tietonäkymän voi myös auttaa luokan data validation ongelma ihmiset tiedustella foorumeilla. Kättelyssä, ei ole mitenkään estää ladattaessa asiakirjaa palvelimeen Moss ja kirjoita ei metadataa. Voimme määrittää erityisesti sivustosarake on pakollinen, ja käyttäjä ei voi paina Tallenna painiketta. Kuitenkin, Jos käyttäjä lataa ja sitten sulkee selaimen (tai käyttää windows explorer ladata asiakirjan), Me emme voi pakottaa käyttäjä syöttää metatiedot (uudelleen, kättelyssä).

Tätä lähestymistapaa voidaan käyttää apuna tilanteessa. Käytämme "huonosti tagged tietoja" Katso helposti tunnistaa nämä asiakirjat ja korjata ne. Pari tätä KPI: tä ja sinulla on hyvä näkyvyys tietoihin porautuminen hallita näissä poikkeuksellisissa olosuhteissa.

</loppu>

Tilaa blogiin.

Tällä viikolla, Olen kamppaillut vähän minun joukkue saada MOSS asennettu yksinkertainen Kahden palvelimen palvelinfarmi. Joiden läpi, Minulla on ongelmia ihmiset raportin ollessa suurempi Arvonkorotus MSDN-foorumit ja muualla.

Lopullinen farmin kokoonpano:

• SQL/hakemisto/Intranet WFE palomuurin sisäpuolella.
• WFE demilitarisoitu alue.
• Jonkinlainen palomuuri DMZ ja sisäisen palvelimen välillä.

Ennen kuin aloitimme projektin, annamme asiakkaan tietää, mitkä portit on tarpeen olla avoin. Aikana antaa ja ottaa, edestakaisin tuosta, sanoimme koskaan varsinaisesti kaksi tärkeää asiaa:

1. SSL tarkoittaa tarvitset varmenteen.
2. DMZ-palvelin täytyy kuulua toimialueeseen.

Päivästä lähtien, oli jopa asentaa MOSS ja oppinut, että toimialuetilit tietokantaan ja MOSS ei ollut luotu. Asioiden edistämiseksi, Menin eteenpäin ja asentaa kaikki paikallisen käyttäjätilin intranet-palvelimelle.

Tässä vaiheessa, huomasimme sekaannus aikana SSL-sertifikaatti ja, Valitettavasti, päättänyt olla meidän infrastruktuuri kaveri palata myöhemmin viikolla jatkaa asennusta DMZ-palvelin. Sillä välin, Meidän ratkaisu arkkitehdit edennyt liiketoiminta jutut.

Viikonloppu kuluu ja asiakas saa todistuksen.

Meidän infrastruktuuri kaveri näkyy ja huomaa että DMZ-palvelin ei ole liitetty mihinkään toimialueeseen (edustan toimialueen rajoitettu luottamus tai intranet-toimialueen). Tuhlasimme lähes 1/2 joka päivä. Jos annamme ei ollut puuttuu SSL-varmenteen juuttua meille, Meidän huomanneet tämän aikaisemmin. Voi hyvin….

Toinen päivä päivältä ja eri turvallisuusasioiden komiteoiden, asianomaiset osapuolet ja (ei niin) viattomia sivullisia kaikki samaa, että se on OK liittyäksesi intranet-toimialueen DMZ-palvelin (Tämä on POC, Loppujen lopuksi, tuotanto-ratkaisu).

Infrastruktuurin kaveri tulee wrap asioita. Tällä kertaa onnistuneesti läpi nykyajan haaste hellästi tunnetaan nimellä "ohjatun SharePointin määrittämisen." Meillä on kurkistaa keskitetyn hallinnan ja … yee haw! … DMZ-palvelin näkyy tilalla. Katsoa hieman tarkemmin ja ymmärtää rikkoi avoinna Champaign punkki vähän aikaisin. WSS-palveluita on juuttunut "alkaa" tila.

Pitkän tarinan lyhyesti, on käynyt ilmi, unohdin muuttaa käyttäjätietoja kautta keskitetyn hallinnan tili alkuperäinen paikallisen tilin toimialueen käyttäjätilejä. Teimme näin, Ohjattu määritystoiminto uudelleen juoksi ja voila! Olimme liike.

</loppu>

Tilaa blogiin.

Vaikka ei ole kirjaimellisesti tosi, käytännön asiana, internet-pohjaisissa web-edusta, demilitarisoitu alue on oltava toimialueen (ts. ei joissakin yksittäiseen palvelimeen omaa pikku työryhmään). Se ei tarvitse olla samassa toimialueessa kuin sisäinen WFE(s) ja muut palvelimet (ja luultavasti ei pitäisi), mutta se on toimialueen.

Kollegani ja minä viettänyt kohtuuttomasti aikaa ehdotuksen, joka sisälsi SharePoint ennakkoedellytyksiä. Tähän sisältyy kattava luettelo palomuurikokoonpanoissa, jotka mahdollistaisivat DMZ-palvelimen liittyä tilalla ja niin edelleen. Valitettavasti, lause jonnekin, joka sanoi lisääminen epäonnistui, siitä, että, "koko verinen Tämä kokoonpano on jotta DMZ WFE palvelin, toimialueen, liittyä sisäisen tilan."

Täydellinen myrsky tapahtumat, jossa periaatteessa Etsimme vasemmalla kun voi näytti oikein, yrittäneet yhdessä salata ongelman meiltä melko myöhään prosessissa, mikä estää minua vetoaa minun "kertoa huonoja uutisia jo" sääntö.

Huokaus.

Tilaa blogiin.