I en eller min første blogginnlegg, Jeg beskrevet hele prosessen vi fulgte for å overføre en kunde fra SPS 2003 til MOSS. En leser igjen en kommentar ber om flere detaljer og her er det.

For overføring prosjektet, Vi måtte finne en god måte å flytte en masse SPS 2003 dokumenter over MOSS. Den første lasten var lett nok. Opprette en ny måldokumentbiblioteket i MOSS og bruk windows Utforsker til å flytte dokumentene.

Dette er det nye dokumentbiblioteket:

Åpne to Vinduer oppdagelsesreisende. Punktet første SPS 2003 og andre på det nye dokumentbiblioteket i MOSS. Følgende skjermbilde viser dette. Merk at den beste nettleseren faktisk peker på min c:\temp-stasjonen, men du kan forestille deg den peker til en SPS 2003 dokumentbibliotek:

Etter at dra og slipp-operasjon, min mål ser slik ut:

Nå er det tid til å håndtere metadata. Anta vi har bare én kolonne med metadata for dokumentene kalt "sted." Vi kan se fra ovenfor "alle dokumenter" vise at plasseringen er tomt. Det er lett nok å bruke tabellvisning data til å angi plasseringen, eller gå til hver dokumentegenskapene én etter én til en. La oss anta at det er ingen praktisk måte å tildele plassering-kolonnen en verdi automatisk og at sluttbrukere må gjøre dette for hånd. Videre, La oss anta at det finnes hundrevis av dokumenter (kanskje tusenvis) og at det vil ta mange mange dager oppdatere metadata. Som vi vet alle, ingen kommer til å sitte ned og arbeide for fire av fem dager rett oppdatere metadata for dokumenter. I stedet, de vil bryte det over en periode på uker eller muligens lenger. Til denne prosessen, Vi kan lage en "umerkede data" visningen som vist:

Nå, Når noen sitter ned for å tilbringe sine tildelte daglig time eller to å merke overførte dokumenter, de kan bruke "ukodede dokumenter" å fokusere sin innsats:

Som brukere kode dokumenter, de faller denne listen.

Denne oppfatningen av en ukodede datavisning kan også hjelpe med en klasse av data validering problemet folk spørre om på forumet. Esken, Det er ingen måte å forhindre at brukerne laste opp et dokument til MOSS og deretter ikke inn metadata. Vi kan angi at en bestemt områdekolonne er obligatorisk og brukeren vil ikke kunne trykke lagre knappen. Men, Hvis brukeren laster opp og deretter lukker nettleseren (eller bruker windows Utforsker til å laste opp dokumentet), Vi kan ikke tvinge brukeren om å oppgi metadata (på nytt, esken).

Denne fremgangsmåten kan brukes til å hjelpe med situasjon. Vi kan bruke en "dårlig merket data" Vis å lett identifisere dokumentene og rette dem. Par dette med en KPI og du har god sikt til dataene med drilldown-administrere disse eksepsjonelle omstendigheter.

</slutten>

Abonner på bloggen min.

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.

Selv om det ikke er bokstavelig oppfylt, som en praktisk materie, en Internett-rettet webfront i en DMZ må være i et domene (dvs.. ikke en frittstående server i sin egen lille arbeidsgruppe). Det trenger ikke å være i samme domene som den interne WFE(s) og andre servere (og burde ikke), men det må være et domene.

Mine kolleger og jeg tilbrakte en overdreven mengde tid på et forslag som inkluderte SharePoint forutsetninger. Dette inkluderte en omfattende liste over brannmurkonfigurasjoner som vil gi DMZ server til gården og så videre. Dessverre, Vi kan ikke legge til setningen et sted som sa, effekt, "hele blodig poenget med denne konfigurasjonen er å la serveren din DMZ WFE, i et domene, bli med interne gården."

En perfekt storm av hendelser, hvor vi i utgangspunktet så venstre når vi kan ha sett rett, konspirerte for å skjule problemet fra oss til ganske sent i prosessen, dermed hindrer meg fra å starte min "fortelle dårlige nyheter tidlig" regel.

Sukk.

Abonner på bloggen min.