Under den senaste veckan, min kollega och jag gör något arbete för en klient i NYC. Vi testade en olika aspekter av en MOSS implementering med deras "standard" arbetsstation bygga (i motsats till våra bärbara datorer). Medan du gör det, Vi sprang på några fel genom att följa dessa steg:

• Öppna upp ett MS Worddokument via Utforskaren (som använder WebDAV).
• Göra en förändring.
• Spara den.

Vi kom att inse att vissa gånger (vanligtvis första gången) Vi sparade dokumentet, Spara sticka inte"." Spara spara inte. Vi skulle dra dokumentet tillbaka upp och våra förändringar helt enkelt fanns inte.

Vi förstod inte roten frågan på denna punkt, men vi tänkte att vi bör se till att den senaste MS Office servicepack hade installerats på denna arbetsplats. IT folk gick och gjorde det. Vi gick igenom testet igen och vi upptäckte ett nytt problem. När vi sparade den, Vi fick nu detta fel:

Den här gången, Det verkade som om varje förändring var, I själva verket, sparade, om vi svarade ja eller nej till skript frågan.

Slutligen hade vi en titt på den aktuella versionen av Office och det visar sig att arbetsstationen var igång MS Office 2000 med servicepack 3 som dyker upp under hjälp-> Om som "Office 2002".

Sensmoralen i historien: Jag kommer alltid att använda Office 2003 som min minimistandard office version när du använder WebDAV och MOSS.

</slutet>

Prenumerera på min blogg.

(För search engine, Detta är den fel text):

Linje: 11807

Röding: 2

Fel: Objektet stöder inte egenskapen eller metoden

Koden; 0

URL: http://sharepoint01/DocumentReview/_vti_bin/owssvr.dll?location=Documents/1210/testworddocument.doc&dialogview=SaveForm

Vill du fortsätta att köra skript på den här sidan?

I en eller min första blogginlägg, Jag beskrev den övergripande processen följde vi för att migrera en kund från SPS 2003 till MOSS. En läsare lämnade en kommentar ber om mer i detalj och här är det.

För att migreringsprojekt, Vi var tvungna att hitta ett bra sätt att flytta en massa SPS 2003 dokument över till MOSS. Den första belastningen var lätt. Skapa ett nytt dokumentbibliotek mål i MOSS och Utforskaren för att flytta dokument.

Detta är det nya dokumentbiblioteket:

Öppna två fönster upptäcktsresande. Först punkten på SPS 2003 och andra på det nya dokumentbiblioteket i MOSS. Följande skärmdump visar detta. Observera att översta webbläsaren faktiskt pekar på min c:\Temp enhet, men ni kan föreställa er den pekar på en SPS 2003 dokumentbibliotek:

Efter att dra och släpp-åtgärden, min mål ser ut så här:

Nu är det dags att ta itu med metadata. Anta att vi har bara en kolumn av metadata för dessa dokument som heter "läge." Vi kan se från ovanstående "alla dokument" Visa att platsen är tom. Det är lätt att använda en data listvy för att ange plats, eller gå in i varje dokuments egenskaper en efter en att lägga till en plats. Låt oss anta att det finns inget praktiskt sätt att automatiskt tilldela lagerställekolumnen ett värde och att slutanvändare måste göra detta för hand. Vidare, Låt oss anta att det finns hundratals dokument (kanske tusentals) och att det kommer att ta många många dagar att uppdatera metadata. Som vi vet alla, ingen kommer att sitta ner och arbeta för fyra av fem dagar i rad uppdatera metadata för dokument. I stället, de kommer att bryta som under en period av veckor eller eventuellt längre. Att underlätta denna process, Vi kan skapa en "otaggade data" vyn som visas:

Nu, När någon sitter ner för att tillbringa sina tilldelade dagliga timme eller två att märka migrerade dokument, de kan använda "otaggade dokument" Visa att fokusera sina ansträngningar:

Som användare tag dokument, de tappar bort denna lista.

Begreppet en otaggade datavyn kan också hjälpa med en klass av data validering problem folk fråga om på forum. Ur lådan, Det finns inget sätt att förhindra att en användare överföra ett dokument till MOSS och inte ange metadata. Vi kan ange att en viss webbplatskolumn är obligatoriskt och användaren inte kommer att tillåtas att trycka Spara knappen. Men, om användaren överför och sedan stänger webbläsaren (eller använder Utforskaren att ladda upp dokumentet), Vi kan inte tvinga användaren att ange metadata (igen, i kartongen).

Detta tillvägagångssätt kan användas för att hjälpa till med denna situation. Vi kan använda en "dåligt märkta data" Visa för att lätt identifiera dessa dokument och rätta till dem. Par detta med en KPI och du har god sikt i data med drill-down att hantera dessa exceptionella omständigheter.

</slutet>

Prenumerera på min blogg.

Denna vecka, Jag har kämpat lite med mitt team för att få MOSS installerat i en enkel två-servergrupp. Efter att ha gått igenom det, Jag har en större förståelse för typer av problem människor rapport på MSDN forum och någon annanstans.

Den slutliga Gruppkonfiguration:

• SQL/Index/intranät WFE innanför brandväggen.
• WFE i DMZ.
• Någon form av brandvägg mellan DMZ och den interna servern.

Innan vi började projektet, Vi låter klienten vet vilka portar måste vara öppna. Under ge och ta, fram och tillbaka över det, vi sagt aldrig uttryckligen två viktiga saker:

1. SSL innebär att du behöver ett intyg.
2. Den DMZ servern måste vara del av en domän.

Dag ett, Vi visade upp för att installera MOSS och lärt att domänkonton för databasen och mossa inte hade skapats. Att flytta saker, Vi gick vidare och installerat allt med ett lokalt konto på servern intranät.

Vid denna punkt, Vi upptäckte förvirringen över SSL-certifikatet och, Tyvärr, beslutat att ha vår infrastruktur kille komma tillbaka senare samma vecka fortsätta installera DMZ server. Under tiden, Vi lösning arkitekter gått framåt med business grejer.

En helg går och klienten erhåller certifikat.

Vår infrastruktur kille visar upp och upptäcker att den DMZ servern inte är kopplad till någon domän (antingen en perimeter-domän med begränsat förtroende eller domänen intranät). Vi slösat bort nästan en 1/2 dag som. Om vi inte hade låta saknas SSL-certifikatet mosse oss ner, Vi skulle ha upptäckt detta tidigare. Jaha….

En annan dag passerar och de olika utskott som säkerhet, berörda parter och (inte så) oskyldiga åskådare alla överens om att det är OK att gå med den DMZ servern med domän för intranät (Detta är en POC, Trots allt, inte en produktion lösning).

Infrastruktur killen kommer att avsluta saker. Denna gång vi framgångsrikt passera den moderna gatlopp tillgivet kallas "guiden Konfigurera SharePoint." Vi har en titt i central administration och … Yee haw! … DMZ server finns med i gården. Vi tittar lite närmare och inser vi bröt öppet Champaign lite kvalster tidigt. WSS tjänster har fastnat i en "börjar" status.

Lång historia kort, Det visar sig att vi glömde att ändra identiteten på kontot via central administration av från det ursprungliga lokala kontot till det nya domänkontot. Vi gjorde det, nytt körde guiden och voila! Vi var i rörelse.

</slutet>

Prenumerera på min blogg.

Även om det inte är bokstavligen sant, som en praktisk fråga, en mot internet frontwebb i en DMZ måste finnas i en domän (dvs. inte någon fristående server i en egen liten arbetsgrupp). Det behöver inte vara i samma domän som den interna WFE(s) och andra servrar (och förmodligen inte borde), men det måste vara en domän.

Mina kolleger och jag tillbringade orimligt mycket tid på ett förslag som medföljer SharePoint förutsättningar. Detta inkluderade en omfattande lista över brandväggskonfigurationer som skulle aktivera DMZ servern att gå med gården och så vidare. Tyvärr, Vi kunde inte lägga till en mening någonstans som sa, att effekten, "hela blodiga denna konfiguration är att låta din DMZ WFE server, i en domän, gå med i den inre gården."

En perfekt storm av händelser, där vi i princip såg vänster när vi kanske har tittat rätt, konspirerat för att dölja problemet från oss förrän ganska sent i processen, Således hindrar mig från att åberopa min "berätta dåliga nyheter för tidigt" regel.

Suck.

Prenumerera på min blogg.