I en eller min allerførste blogindlæg, Jeg beskrev den overordnede proces vi følges for at migrere en kunde fra SPS 2003 til MOSS. En læser har skrevet en kommentar, beder om flere detaljer og her er det.

For at migreringsprojekt, Vi var nødt til at finde en god måde at flytte en masse SPS 2003 dokumenter over til MOSS. Den oprindelige last var nemt nok. Opret et nyt mål-dokumentbibliotek i MOSS og bruge windows Stifinder til at flytte dokumenter.

Dette er det nye dokumentbibliotek:

Åbne to windows opdagelsesrejsende. Først punkt på SPS 2003 og andet på det nye dokumentbibliotek i MOSS. De følgende skærmbillede viser det. Bemærk, at den øverste browser faktisk peger på min c:\Temp-drev, men du kan forestille dig det peger på en SPS 2003 dokumentbibliotek:

Efter dette træk og slip-handling, mit mål ligner dette:

Nu er det tid til at beskæftige sig med metadata. Antage vi har kun én kolonne af metadata for disse dokumenter hedder "placering." Vi kan se fra de ovennævnte "alle dokumenter" Se, at placeringen er tom. Det er let nok at bruge en visning af data til at angive placeringen, eller endda gå ind i egenskaber for hvert dokument én efter én til at tilføje en placering. Lad os antage, at der er ingen praktisk måde at tildele kolonnen placering en værdi automatisk og at slutbrugerne skal gøre dette i hånden. Desuden, Lad os antage der er hundredvis af dokumenter (måske tusinder) og at det vil tage mange mange dage at opdatere metadataene. Som vi alle kender, ingen igangværende hen til sidde og arbejde for fire af fem dage lige opdatere metadata for dokumenter. I stedet, de vil bryde, over en periode på uger eller måske længere. At lette denne proces, Vi kan oprette en "ukodede data" Se som vist:

Nu, Når en person sidder ned for at tilbringe deres tildelte daglige time eller to at mærke overførte dokumenter, de kan bruge de "ukodede dokumenter" View til at fokusere deres indsats:

Som brugere tag dokumenter, de aflevere denne liste.

Begrebet en ukodede datavisning kan også hjælpe med en klasse af data validering problem folk spørge om på fora. Ud af boksen, der er ingen måde at forhindre, at en bruger uploade et dokument til mos og derefter indtaste ikke metadata. Vi kan angive at et bestemt webstedskolonne er obligatorisk, og brugeren vil ikke være tilladt at skubbe Gem knappen. Dog, Hvis brugeren uploads og derefter lukker browseren (eller bruger windows explorer til at uploade dokumentet), Vi kan ikke tvinge brugeren til at indtaste metadata (igen, ud af boksen).

Denne fremgangsmåde kan bruges til at hjælpe med denne situation. Vi kan bruge en "dårligt mærket data" Se let identificere disse dokumenter og rette dem. Par dette med en KPI og du har god synlighed til data med drill-down til at styre disse usædvanlige omstændigheder.

</slutningen>

Abonner på min blog.

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.

Selv om det ikke er bogstaveligt talt sandt, som et praktisk spørgsmål, en internet-facing Webfrontend i en DMZ skal være i et domæne (dvs. ikke en enkeltstående server i sin egen lille arbejdsgruppe). Det behøver ikke at være i det samme domæne som den indre hele Fiskeækvivalenter(s) og andre servere (og sandsynligvis bør ikke), men det skal være et domæne.

Mine kolleger og jeg tilbragte en uforholdsmæssig meget tid på et forslag, som omfattede SharePoint forudsætninger. Dette omfattede en omfattende liste af firewall-konfigurationer, der ville sætte DMZ serveren til at deltage i gården og så videre. Desværre, Vi kunne ikke tilføjes en sætning et sted, sagde, at effekten, "det helt blodig punkt af denne konfiguration er at lade din DMZ hele Fiskeækvivalenter server, i et domæne, at slutte sig til den indre gård."

En perfekt storm af begivenheder, hvor vi dybest set kiggede venstre når vi måske har set ret, sammensværgelse om at skjule problemet fra os forholdsvis sent i processen, dermed forhindrer mig i at påberåbe sig min "fortælle dårlige nyhed tidligt" regel.

Suk.

Abonner på min blog.