Během minulého týdne, můj kolega a já dělal nějakou práci pro klienta v NYC. Byli jsme testování různé aspekty provádění MOSS pomocí jejich standardních"" sestavení pracovní stanice (na rozdíl od našich noteboocích). Při tom, narazili jsme na pár chyb pomocí následujících kroků:

• Otevřít dokument MS word pomocí Průzkumníka systému windows (který používá protokol WebDAV).
• Změnu.
• Uložit.

Přišli jsme si uvědomit, že některé krát (obvykle při prvním) Zachránili jsme dokument, ukládání "nestrkal." Uložit, neuložil. Jsme by vytáhnout tento dokument zpět a naše změny jednoduše tam nebyl.

V tuto chvíli nerozumíme kořen problému, Ale jsme si řekli, že měli bychom se ujistit, že už byla nainstalována nejnovější aktualizace service pack pro MS Office na pracovní stanici. IT lidé šel a udělal to. Prošli jsme test znovu a objevili jsme nový problém. Když jsme ho zachránili, Nyní máme tuto chybu:

Tentokrát, Vypadalo to, že každá změna byla, Vlastně, uloženo, zda jsme odpověděli ano nebo ne otázka skripty.

Měli jsme konečně podívat na aktuální verzi sady Office a ukazuje se, že pracovní stanice se systémem MS Office 2000 s aktualizací service pack 3 která se objeví pod pomoc-> O jako "Office 2002".

Ponaučení z příběhu: Bude vždy používat úřadu 2003 jako moje verze minimální základní úřad při použití protokol WebDAV a MECHU.

</Konec>

Přihlásit se na mém blogu.

(Pro účely vyhledávání motor, To je text chyby):

Čára: 11807

Znak: 2

Chyba: Objekt nepodporuje tuto vlastnost nebo metodu

Kód; 0

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

Chcete pokračovat ve spouštění skriptů na této stránce?

V jednom nebo moje úplně první blog příspěvky, Popsal jsem celý proces sledovali jsme k migraci zákazníků z SPS 2003 na mech. Čtenář opustil komentář žádají o podrobnější informace a je to tady.

Pro tento projekt migrace, Museli jsme najít dobrý způsob, jak přesunout spoustu SPS 2003 dokumenty v MECHU. Počáteční zatížení bylo snadné. Vytvořit novou knihovnu dokumentů cíl v MECHU a pomocí programu Průzkumník přesuňte dokumenty.

To je nová knihovna dokumentů:

Otevřete dvě okna průzkumníci. První bod na SPS 2003 a druhá na novou knihovnu dokumentů v MECHU. Následující snímek obrazovky ukazuje. Všimněte si, že nejlepší webový prohlížeč je ve skutečnosti ukázal na mé c:\dočasný disk, ale lze si představit, že přejdete SPS 2003 Knihovna dokumentů:

Poté přetáhněte a přetažení operace, můj cíl vypadá takto:

Nyní je čas se vypořádat s metadaty. Předpokládejme, že máme jen jeden sloupec metadat pro tyto dokumenty, s názvem "umístění." Můžeme vidět z výše uvedeného "všech dokumentů" názor, že místo je prázdné. Je to snadné, stačí použít zobrazení datového listu k zadání umístění, nebo dokonce jít do každého dokumentu vlastností po jednom přidat umístění. Předpokládejme, že neexistuje žádný praktický způsob, jak přiřadit umístění sloupce hodnotu automaticky a že koncoví uživatelé musí dělat to ručně. Navíc, Předpokládejme, že existují stovky dokumentů (Možná tisíce) a že to bude trvat mnoho mnoho dní aktualizace metadat. Jak všichni víme, Nikdo nebude sednout a pracovat pro čtyři z pěti dní aktualizace metadata dokumentů. Místo toho, Oni to vypukne po dobu týdnů nebo i déle. K usnadnění tohoto procesu, můžeme vytvořit netagovanými daty"" Zobrazit, jak je uvedeno:

Nyní, Když někdo sedí na tráví jejich přidělené denní hodinu nebo dvě značky přenesené dokumenty, mohou použít "netagovaných dokumentů" pohled zaměřit své úsilí:

Jako uživatelé značky dokumentů, Oni odejdou tohoto seznamu.

Tato představa netagované dat zobrazení může také pomoci s třídou problému ověření dat, které lidi zeptat na fórech. Out of the box, neexistuje žádný způsob, jak uživatelům zabránit v ukládání dokumentu na MECHU a není zadejte meta data. Můžeme určit, že sloupec určitého webu je povinné a uživateli nebude povoleno posunout uložit tlačítko. Avšak, Pokud uživatel uloží a zavře prohlížeč (nebo Průzkumník windows používá k odeslání dokumentu), Nemůžeme nutit uživatele k zadání metadat (znovu, po vybalení z krabice).

Tento postup lze použít k pomoci této situace. Můžeme použít "chybně tagované údaje" pohled do snadno identifikovat tyto dokumenty a jejich opravy. Pár toto s KUV, a máte dobré viditelnosti údajů s podrobnostem ke správě těchto výjimečných okolností.

</Konec>

Přihlásit se na mém blogu.

Tento týden, Trochu jsem bojoval se svým týmem, aby si MOSS nainstalován v jednoduché dvou serverové farmy. S prošla, Mám větší uznání za problémy lidí zprávy na fóra MSDN a jinde.

Konfigurace konečné farmy:

• SQL/Index/Intranet WFE uvnitř brány firewall.
• WFE v DMZ.
• Nějaký druh brány firewall mezi DMZ a interní server.

Než jsme začali projekt, Nechali jsme klient vědět, porty, které musí být otevřené. Během dávat a brát, a zpět nad, Řekli jsme nikdy výslovně dvě důležité věci:

1. SSL znamená, že potřebujete certifikát.
2. DMZ server musí být součástí domény.

Den první, k instalaci MOSS se objevil a zjistil, že nebyl vytvořen doménové účty pro databáze a MOSS. Přesunout věci, jsme šli dopředu a nainstaloval všechno s místním účtem na serveru sítě intranet.

V tomto okamžiku, zjistili jsme, že zmatek nad SSL certifikát a, Bohužel, rozhodl se, že náš člověk infrastruktury vrátit později tento týden pokračovat v instalaci serveru DMZ. V střední čas, Jsme architekti řešení pohnula s obchodními stuff.

Jde o víkendu a klient obdrží certifikát.

Naše infrastruktura chlap objeví a zjistí, že DMZ server není připojen k žádné doméně (obvodové doménu s omezenou důvěru nebo domény sítě intranet). Promarnili jsme téměř 1/2 den na to. Pokud jsme nenechali nás zabořit chybějící certifikát SSL, by jsme to zjistili dříve. Oh dobře….

Další den projde a různé bezpečnostní výbory, zúčastněné strany a (není to tak) Nevinní přihlížející všichni shodují, že je OK zapište DMZ server s domény sítě intranet (To je POC, Koneckonců, není výrobní řešení).

Infrastruktury prisel zabalit věci. Tentokrát jsme úspěšně projít moderní denní rukavici, laskavě známý jako "Průvodce konfigurací služby SharePoint." Jsme se podívat v centrální správě a … Yee haw! … DMZ server je uveden v serverové farmě. Jsme trochu pozorněji a uvědomit si, že jsme rozbila Champaign trochu roztoč brzy. Služba WSS se zasekl v "začíná" stav.

Dlouhý příběh krátký, ukazuje se, že jsme zapomněli změnit identitu účtu služby prostřednictvím Centrální správa z původního místního účtu na nový účet domény. Když jsme to dělali, znovu spuštěn Průvodce konfigurací a voila! Byli jsme v podnikání.

</Konec>

Přihlásit se na mém blogu.

Ačkoli to není pravda, doslova, jako praktická záležitost, v doméně musí být internetovém webu front-end v zóna DMZ (tj. ne nějaký samostatný server ve své vlastní malé pracovní skupiny). To nemusí být ve stejné doméně jako vnitřní WFE(s) a další servery (a pravděpodobně by neměla), ale to musí být v doméně.

Moji kolegové a já jsem strávil nadměrné množství času na návrh, který zahrnoval SharePoint předpoklady. To zahrnovalo komplexní seznam konfigurací brány firewall, které by umožnily DMZ serveru pro připojení k farmě a tak dále. Bohužel, jsme se nepodařilo přidat někde větu, že řekl, o tom, "zatracený bodem této konfigurace je umožnit serveru DMZ WFE, v doméně, Chcete-li připojit k vnitřní farmy."

Dokonalá bouře událostí, kde jsme v podstatě podíval vlevo když jsme mohli podíval vpravo, spikli skrýt tento problém od nás poměrně pozdě-až v procesu, brání mi vyvolání mého "brzy říct špatnou zprávu" pravidlo.

Povzdech.

Přihlásit se na mém blogu.