Dum la pasinta semajno, Mia Kolego Kaj mi estis faranta iun laboron por kliento en NYC. Ni estis elprovantaj malsamajn flankojn de MUSKA efektivigo uzanta ilian "normon" Laborstacia konstruo (Kiel oponita al niaj tekkomputiloj). Dum faranta tion, Ni kuris en kelkaj eraroj de sekvanta ĉi tiujn paŝojn:

• Malfermi supre F-inan vortan dokumenton tra fenestra esploristo (Kiu uzas WebDAV).
• Fari ŝanĝon.
• Savi ĝin.

Ni venis konscii ke kelkaj tempoj (Kutime la unua tempo) Ni savis la dokumenton, La savi ne "senmoviĝis." Savi ne savis. Ni tirus tiun dokumenton subtenas supre kaj niaj ŝanĝoj simple ne estis tie.

Ni ne komprenis la radikan aferon ĉe ĉi tiu punkto, Sed ni kalkulis ke ni devus fari certe ke la plej lasta f-ino Office serva amaso estis instalita sur tiu labora stacio. La ITaj homoj iris kaj faris tion. Ni iris tra la testo denove kaj ni eltrovis novan problemon. Kiam ni savis ĝin, Ni nun akiris ĉi tiun eraron:

Ĉi tiu tempo, Ĝi ŝajnis kiel ĉiu ŝanĝo estis, Fakte, Savita, Ĉu ni alrespondis Jes aŭ Ne al la skriba demando.

Ni fine havis rigardi la realan version de Oficejo kaj ĝi rezultas ke la laborstacio estis kuranta f-ino Office 2000 Kun serva amaso 3 Kiu aperas sub Helpo -> Proksimume kiel "Oficejo 2002".

La moralo de la rakonto: Mi ĉiam uzos Oficejon 2003 Kiel mia minimuma etalona oficeja versio kiam uzanta WebDAV kaj MUSKON.

</Fino>

Aboni al mia blogo.

(Por serĉa motoro celoj, Tio ĉi estas la teksto de la eraro):

Linio: 11807

Cindrigi: 2

Eraro: Objekto ne subtenas ĉi tiun nemoveblaĵon aŭ metodon

Kodo; 0

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

Ĉu vi deziras daŭri fluajn skribojn sur ĉi tiu paĝo?

En unu aŭ mia Tre unuaj blogaj poŝtoj, Mi priskribis la entutan procezon ni sekvis migri klienton de SPS 2003 Al MUSKO. Leganto lasis rimarkon petanta pli da detalo kaj ĉi tie ĝi estas.

Por tiu migrada projekto, Ni devis trovi bonan vojon movi multan SPS 2003 Dokumentas super al MUSKO. La komenca ŝarĝo estis facile sufiĉa. Krei novan celan dokumentan bibliotekon en MUSKO kaj uzaj fenestroj esploristo movi la dokumentojn.

Tio ĉi estas la nova dokumenta biblioteko:

Malfermi supre du fenestrajn esploristojn. Indiki la unuan ĉe SPS 2003 Kaj la sekundo ĉe la nova dokumenta biblioteko en MUSKO. La sekvanta ekrano pafis rezultojn tio ĉi. Noti ke la pinta retumilo estas efektive indikanta ĉe mia c:\Temp stirado, Sed vi povas imagi ĝin indikanta al SPS 2003 Dokumenta biblioteko:

Post kiam tiu kaleŝo kaj fala operacio, Mia celo similas tion ĉi:

Nun ĝi estas tempo trakti la metadata. Supozi nin havas nur unu kolumnon de metadata por ĉi tiuj dokumentas nomita "lokon." Ni povas vidi de la sur "ĉiuj dokumentoj" Vidi ke la loko estas malplena. Ĝi estas facile sufiĉa uzi datuman folian vidon eniri la lokon, Aŭ eĉ iri en la nemoveblaĵoj de ĉiu dokumento unu de unu aldoni lokon. Lasita-a supozi ke estas ne praktika vojo asigni la lokan kolumnon valoro aŭtomate kaj tiuj finaj uzantoj devas fari tion ĉi mane. Cetere, Lasita-a supozi estas centoj de dokumentoj (Eble miloj) Kaj ke ĝi prenos multaj multaj tagoj ĝisdatigi la metadata. Kiel ni ĉiuj scias, Neniu estas iranta sidi malsupren kaj laboro por kvar el kvin tagoj rekte ĝisdatiganta meta datumo por dokumentoj. Male, Ili rompos ke ekstere super periodo de semajnoj aŭ eble pli longa. Faciligi ĉi tiun procezon, Ni povas krei "untagged datumo" Vidi kiel montrita:

Nun, Kiam iu sidas malsupren elspezi ilia asignita #?iutaga horon #a? du etikedi migrita dokumentojn, Ili povas uzi la "untagged dokumentoj" Vidi koncentri ilian penon:

Kiel uzanta etikedo dokumentoj, Ili falas de #?i tiu listo.

Ĉi tiu ideo de untagged datuma vido ankaŭ povas helpi kun klaso de datuma validumado problemaj homoj demandas proksimume sur la forumoj. Ekstere de la skatolo, Tie estas neniu vojo malhelpi uzanton de uploading dokumento al MUSKO kaj tiam ne eniri meta datumo. Ni povas specifi ke aparta eja kolumno estas deviga kaj la uzanto ne estos permesita puŝi la savi butonon. Tamen, Se la uzantaj #al?uto kaj tiam fermas la retumilon (#A? uzaj fenestroj esploristo al #al?uto la dokumento), Ni povas?? Devigas la uzanton eniri meta datumo (Denove, Ekstere de la skatolo).

Ĉi tiu alproksimiĝo povas esti uzita helpi kun tiu situacio. Ni povas uzi "nebone etikedita datumon" Vidi facile identigi ĉi tiujn dokumentojn kaj ĝustigi ilin. Kupli tion ĉi kun KPI kaj vi havas bonan videblecon al la datumo kun borilo-malsupren administri ĉi tiujn esceptajn cirkonstancojn.

</Fino>

Aboni al mia blogo.

Ĉi tiu semajno, Mi luktis iom kun mia teamo akiri MUSKON instalita en simpla du-servila bieno. Iris tra ĝi, Mi havas pli grandan dankecon por la specoj de problemaj homoj raporto sur la MSDNaj forumoj kaj aliloke.

La fina biena konfiguracio:

• SQLa/Indekso/Intrareta WFE en la firewall.
• WFE en la DMZ.
• Iu speco de firewall inter la DMZ kaj la interna servilo.

Antaŭ ol ni komencis la projekton, Ni lasis la klienton scias kiun havenoj devita esti turniro. Dum la doni kaj preni, Malantaŭa kaj antaŭen super tio, Ni neniam eksplicite diris du gravajn aferojn:

1. SSL signifas vin devas ateston.
2. La DMZa servilo devas esti parto de domajno.

Tage unu, Ni aperis instali MUSKON kaj lernis ke la domajnaj kontoj por datumaro kaj MUSKO ne estis kreita. Movi aferojn laŭ, Ni iris antaŭen kaj instalis ĉion kun loka konto sur la intrareta servilo.

Ĉe ĉi tiu punkto, Ni eltrovis la konfuzon super la SSLa atesto kaj, Bedaŭrinde, Decidita havi nian infrastrukturan ulon revenita poste ke semajno daŭri instalanta la DMZan servilon. En la malbona tempo, Ni solvaj arkitektoj movis antaŭen kun la komerca aĵo.

Semajnfino iras de kaj la kliento akiras la ateston.

Nia infrastruktura ulo aperas kaj eltrovas ke la DMZa servilo ne estas aliĝita al ajna domajno (Aŭ perimetra domajno kun limhava fido aŭ la intrareta domajno). Ni malŝparis preskaŭ 1/2 Tago sur tio. Se ni ne lasis la forestantan SSLan ateston bog ni malsupren, Ni estus eltrovinta ĉi tiun pli fruan. Oh puto….

aliaj tagaj transludoj kaj la diversaj sekurecaj komitatoj, Interesita partiojn kaj (Ne sekve) Senkulpaj spektantoj ĉiuj konsentas ke ĝi estas BONE aliĝi la DMZan servilon kun la intrareta domajno (Tio ĉi estas POC, Post kiam ĉiuj, Ne produktada solvo).

Infrastruktura ulo eniras volvi aferojn supre. Ĉi tiu tempo ni sukcese pasas tra la la moderna-tago gauntlet ame sciita kiel la "SharePoint Konfiguracia Sorĉisto." Ni havas peek en centra administro kaj … Yee haw! … DMZa servilo estas enlistigita en la bieno. Ni rigardas malgrandan pli proksima kaj konscias nin rompis malfermi la Champaign akaro mordis frue. WSSaj servoj estas senmoviĝita en "komencanta" Statuso.

Longa rakonto mallonga, Ĝi rezultas ke ni forgesis ŝanĝi la identecon de la serva konto tra centra administro de la originala loka konto al la nova domajna konto. Ni faris tion, Re-kuris la konfiguracian sorĉiston kaj voila! Ni estis en komerco.

</Fino>

Aboni al mia blogo.

Kvankam ĝi ne estas laŭvorte vera, Kiel praktika afero, Interreto-alfrontanta araneaĵon fronta fino en DMZ devas esti en domajno (T.e. Ne iu aŭtonoma servilo en ĝia propra malgranda workgroup). Ĝi ne devas esti en la sama domajno kiel la interna WFE(S) Kaj aliaj serviloj (Kaj verŝajne devus ne), Sed ĝi devas esti domajno.

Miaj kolegoj kaj mi elspezis inordinate kvanto de tempo sur propono kiu inkluzivis SharePoint pre-requisites. Tio ĉi inkluzivis ampleksan liston de firewall konfiguracioj kiu ebligus la DMZan servilon aliĝi la bienon kaj tiel antaŭen. Bedaŭrinde, Ni malsukcesis aldoni propozicion ie kiu diris, Al la efiko, "La tuta sanga punkto de ĉi tiu konfiguracio estas permesi vian DMZan WFEan servilon, En domajno, Aliĝi la internan bienon."

Perfekta ŝtormo de eventoj, Kie ni resume rigardis lasita kiam nin eble rigardus rajton, Konspirita kaŝi ĉi tiun problemon de ni ĝis juste malfrue en la procezo, Kaj tiel malhelpanta min de alvokanta mia "Diri malbonan sciigon frue" Regulo.

Suspiro.

Aboni al mia blogo.