Viimase nädala jooksul, minu kolleeg ja mul olid teeme mõned tööd kliendi NYC. Me olime katsetada erinevaid aspekte MOSS rakendamist, kasutades oma "standard" Workstation ehitada (Erinevalt meie sülearvutid). Seeläbi, et, Meil sattus mõned vead järgmisi samme:

• Ava MS word dokumenti windows Exploreri kaudu (mis kasutab WebDAV).
• Teha muutusi.
• Salvestage see.

Meil tuli aru, et mõned korda (tavaliselt esimest korda) dokumendi salvestamisest, Salvesta ei "kinni." Salvesta ei päästa. Me tõmmata selle dokumendi tagasi üles ja meie muutusi lihtsalt ei olnud.

Me ei saanud aru juur küsimuse siinkohal, Aga mõtlesime, et peaksime tegema kindel, et see töökoht oli installitud MS Office uusima hoolduspaketi. IT inimesed läksid ja tegid. Käisime läbi katse uuesti ja avastasime uus probleem. Millal me salvestatud, Meil on nüüd see viga:

Sel korral, tundus, et iga muutus oli, Tegelikult, salvestatud, Kas me vastata Jah või ei küsimus scripts.

Me lõpuks oli tegelik versioon Office Vaata ja selgub, et töökoht oli töötab MS Office 2000 hoolduspaketiga 3 mis näitab vastavalt Help-> Umbes nagu "Office 2002".

Moraal lugu: Ma alati kasutada Office 2003 minu vähemalt algtaseme Office'i versiooni kasutades WebDAV ja SAMMAL.

</lõpp>

Telli minu blogi.

(Mootori Otsingunimi, See on selle vea tekst):

Rida: 11807

(Märk): 2

Tõrge: Objekt ei toeta seda atribuuti või meetodit

Kood; 0

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

Kas sa tahad jätkuvalt skripte käivitada sellel lehel?

Ühes või minu kõige esimene blogi postitused, Ma kirjeldasin Seurasimme klient migreeruvad SPS kogu protsessi 2003 et MOSS. Lugeja kommenteerinud küsida üksikasju ja see siin.

Et migratsiooni projekt, tuli leida hea võimalus liikuda palju SPS 2003 dokumentide üle MOSS. Esialgset koormust oli piisavalt lihtne. Loo uus siht dokumenditeek MOSS ja windows Exploreri abil liikuda dokumendid.

See on uus dokumenditeek:

Avada aknast maadeavastajad. Ühtse otsemaksete kava esimese punktini 2003 ja teises etapis MOSS uude dokumenditeeki. Järgmine pilt näitab seda. Üles brauserid on tegelikult suunatud minu c Märkus:\temp drive, kuid võite ette kujutada, see on SPS osutades 2003 dokumenditeek:

Seejärel lohistage ja kukutage operatsiooni, minu siht näeb välja selline:

Nüüd on aega tegeleda metaandmed. Oletame meil on lihtsalt üks veerg metaandmeid nende dokumentide nimega "asukoht." Vaadake eespool "kõik dokumendid" Vaata, et asukoht on tühi. See on piisavalt lihtne, et andmevaade lehele saate sisestada asukoha, või isegi minema iga dokumendi atribuute ükshaaval asukoha lisamine. Oletame, et on praktiline võimalus määrata asukoha veeru väärtus automaatselt ning et lõppkasutajad peate seda tegema käsitsi. Peale selle, Oletame, on sadu dokumente (Võibolla tuhat) ja et see võtab palju palju päevi metaandmete värskendamine. Nagu me kõik teame, keegi saab istuda ja töötada neli viis päeva sirge dokumentide metaandmete värskendamine. Selle asemel, nad puhkeb mis nädalaid või isegi pikema perioodi. Protsessi lihtsustamiseks, loome oma "sildistamata andmed" View esitatud:

Nüüd, Kui keegi istub veeta oma eraldatud iga päev tunni või kaks tag rännanud dokumendid, nad saavad kasutada "sildistamata dokumentide" et keskenduda oma jõupingutused:

Kasutajatele tag dokumentidena, nad poistumisia selle loendi.

Sildistamata Andmevaate käsitlus aitab klassiga andmete valideerimise probleem inimesed küsida Foorumid. Karbist välja, ei ole võimalik takistada kasutaja dokumendi üleslaadimine MOSS ja seejärel Sisesta metaandmed. Meil saate määrata konkreetse saidi veerg on kohustuslik ja kasutajal ei lubata push Salvesta nupule. Aga, Kasutaja laadib ja sulgub brauser (või kasutab windows Exploreris üles laadida dokumendi), Me ei saa sundida kasutajal sisestada metaandmed (uuesti, karbist välja).

Selline lähenemine saab aidata sellise olukorra. Me kasutame "halvasti sildistatud andmed" Vaata kergesti tuvastada neid dokumente ja parandada. Paar seda KPI ja sul on hea nähtavus andmetele süvitsimineku hallata antud erandlikel asjaoludel.

</lõpp>

Telli minu blogi.

Sel nädalal, Olen võidelnud natuke minu meeskond saada lihtsa kaks serveriparki installitud MOSS. Olles läbinud, Mul on suuremat tunnustust liiki probleemidega inimesi aru MSDN-i foorumites ja mujal.

Lõplik serveripargi konfiguratsiooni:

• SQL/Index/sisevõrgu WFE tulemüüri sees.
• WFE DMZ.
• Tulemüüri DMZ ja sisemine serveri vahel mingi.

Enne hakkasime projekti, anname teada, millised pordid peavad olema avatud kliendi. Ajal anda ja võtta, edasi-tagasi üle, et, Me ei ole kunagi selgelt ütles kaks olulist asja:

1. SSL tähendab on serti tarvis.
2. DMZ server peab kuuluma domeeni.

Päevast, Me näitas üles paigaldada MOSS ja õppinud, et domeenikontode andmebaasi ja SAMMAL ei olnud loodud. Liikuda asju, läksime edasi ja paigaldatud kõik sisevõrgu server kohalik konto.

Sel hetkel, avastasime ning segiajamise üle SSL-sertifikaat ja, Kahjuks, otsustas, et meie infrastruktuuri mees tule tagasi hiljem sel nädalal DMZ serveri installimise jätkamiseks. Samal ajal, Me lahus arhitektid edasi tõsta ettevõtte asju.

Nädalavahetusel läheb ja klient saab tunnistuse.

Meie infrastruktuuri mees näitab üles ja avastab, et DMZ server on liidetud kõik domeeni (perimeetri domeeni piiratud usalduse või sisevõrgu domeeni). Me raisata ligi ühe 1/2 päev, mis. Kui me poleks puudu SSL-sertifikaat, mis on raba meile ette, oleme oleks avastanud seda varem. Oh hästi….

Teine päev möödub ja erinevate turvakomiteed, huvitatud isikud ja (ei ole nii) süütu kõrvalseisjad kõik nõustuvad, et OK DMZ server intranet domeeniga liitumiseks (See on ka POC, Pealegi, mitte tootmise lahendus).

Infrastruktuuri mees jõuab, et asju pakkima. Seekord me edukalt läbida ka tänapäeva gauntlet nn "SharePointi konfigureerimisviisard." Meil piiluda administreerimiskeskuse ja … Yee huu! … DMZ server on loetletud talu. Me vaatama veidi lähemale ja mõistma, me murdis avatud Champaign natuke maimuke varakult. WSS teenused on sattunud ka "algus" olek.

Pikk lugu lühike, selgub, et me unustasime muuta administreerimiskeskuse kaudu teenusekonto identiteedi Algne kohalikult kontolt uue domeeni konto. Me tegime seda, uuesti jooksis konfigureerimise viisard ja voila! Olime äri.

</lõpp>

Telli minu blogi.

Kuigi see ei ole sõna otseses mõttes tõsi, praktiline küsimusena, oma Interneti-suunalise veebi eesserver on ka DMZ peab olema domeenis (St. mitte mingi eraldiseisev server oma väike töörühma). See ei pea olema samas domeenis sisemine WFE(s) ja muud serverid (ja ilmselt ei tohiks), kuid see peab olema domeeni.

Minu kolleegid ja veetsin ametiasutustelt ebaproportsionaalsel hulgal aja ettepaneku, mis sisaldas SharePointi nõuandeteenust. See hõlmas tulemüüri koosseisud, mis võimaldaksid DMZ server liituda talu jne põhjalik nimekiri. Kahjuks, Me ei saanud lisada lause kuskil öeldud, selle kohta, "täiesti verine punkt see konfiguratsioon on võimaldada DMZ WFE server, domeeni, liituda sisemine talu."

Täiuslik torm sündmused, kus põhiliselt vaatasime vasakul kui me oleks võinud vaadanud õige, conspired varjata seda probleemi meilt kuni üsna hilja selles protsessis, Seega takistab mind kasutada minu "Ütle halb uudis varakult" reegel.

Sigh.

Telli minu blogi.