Per praeitą savaitę, mano kolega ir aš tai daryti tam tikrą darbą klientui NYC. Mes buvo išbandyti įvairių aspektų MOSS įgyvendinimo naudojantis jų "standartas" darbo vietoje statyti (Priešingai nei mūsų nešiojamieji kompiuteriai). Darydamas, kad, Mes vyko į keletą klaidų, atlikdami šiuos veiksmus:

• Atverti MS word dokumentą per windows explorer (kuri naudoja WebDAV).
• Keisti.
• Įrašykite jį.

Mes priėjo prie suvokti, kad kartais (paprastai pirmą kartą) Mes įrašyti dokumentą, įrašyti ne "klijuoti." Įrašyti neįrašė. Mes jėga tą dokumentą atgal į viršų ir mūsų pakeitimus tiesiog buvo ne ten.

Mes ne suprasti šaknų klausimą šiuo metu, bet supratome, kad mes turėtų įsitikinti, kad naujausią pakeitimų paketą MS Office turėjo buvo įdiegta kad darbo stotis. IT žmonės nuėjo ir padarė, kad. Mes vyko bandymas dar kartą ir mes atrado naują problemą. Kada mes išgelbėti jį, Mes dabar turime ši klaida:

šį kartą, atrodė, kaip kiekvieną pakeitimą buvo, tiesą sakant, įrašyti, ar mes atsakyti taip arba ne scenarijus klausimas.

Mes galiausiai turėjo žvilgsnis į faktinę Office versiją ir paaiškėja, kad darbo vietos buvo paleisti MS Office 2000 su pakeitimų paketu 3 kuris rodo pagal Žinynas-> Apie „Office 2002 m.".

Moral of the story: Bus visada naudoti Office 2003 kaip mano minimalus bazinės linijos office versija, kai naudojant WebDAV ir MOSS.

</pabaigos>

Prenumeruoti savo dienoraštį.

(Paieškos variklio tikslais, tai yra dėl klaidos tekstas):

Eilutės: 11807

Char: 2

Klaida: Objektas nepalaiko šios ypatybės arba metodas

Kodas; 0

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

Ar norite tęsti scenarijus šiame puslapyje?

Vienoje arba mano pirmoji dienoraščio, Aprašiau bendrą procesą mes po perkelti klientas iš SFS 2003 iki MOSS. Skaitytojas paliko komentarą prašydama išsamiau ir čia yra.

To migracijos projekto, teko rasti geras būdas perkelti daug SFS 2003 dokumentų per MOSS. Pradinė apkrova buvo gana paprasta. Sukurti naują paskirties dokumento bibliotekoje Moss ir naudoti "windows Explorer" perkelti dokumentus.

Tai yra naujoje dokumentų bibliotekoje:

Atidaryti du langus tyrinėtojai. SFS pirmojo taško 2003 ir naujoje dokumentų bibliotekoje Moss antrą. Šių ekrano nuotrauka rodo tai. Atkreipkite dėmesį, kad viršuje naršyklės iš tikrųjų rodo mano c:\Temp automobiliu, bet galite įsivaizduoti, ji nukreipta į su SFS 2003 dokumentų biblioteka:

Po to vilkite ir upuść operacijos, mano tikslas atrodo taip::

Dabar atėjo laikas spręsti metaduomenų. Tarkime, mes turime tik vieną stulpelį metaduomenų dėl šių dokumentų pavadintas "vietą." Mes galime matyti iš "visų dokumentų" Rodyti, kad yra tuščia vieta. Tai gana paprasta naudoti duomenų lapo rodinys įveskite vietą, ar net eiti į kiekvieno dokumento ypatybės vieną įtraukti viet ą. Tarkime, kad yra praktiškai neįmanoma priskirti vietos stulpelio vertę automatiškai ir kad galutinių vartotojų turi padaryti tai rankomis. Be to, Tarkime, kad yra šimtai dokumentų (gal tūkstančiai) ir kad ji bus daug daug dienų atnaujinti metaduomenų. Kaip mes visi žinome, niekas ketina atsisėsti ir dirbti keturias penkias dienas tiesiai atnaujinti meta duomenis dokumentams. Vietoj, jie bus kad išeiti per savaites ar galbūt ilgesnį laikotarpį. Palengvinti šį procesą, Mes galime sukurti yra "nežymėtas duomenys" Rodyti kaip parodyta:

Dabar, kai kas nors sėdi žemyn į išleisti jų paskirtus kasdien valandą ar dvi pažymėti migravo dokumentai, jie gali naudoti "nepažymėtų dokumentų" siekiant sutelkti savo pastangas:

Kaip vartotojai žymelę dokumentai, jie užsnūsti šiame sąraše.

Ši sąvoka yra nepažymėtų duomenų rodinį taip pat gali padėti su klasės duomenų tikrinimo problema žmonių paklausti apie Forumai. Out of the box, Tai jokiu būdu neleiskite vartotojui įkelti dokumento į MOSS ir meta duomenis įvedate ne. Mes galite nurodyti, kad konkrečios svetainės stulpelį, kurio yra privalomas ir vartotojui nebus leidžiama stumti įrašyti mygtuką. Tačiau, Jei vartotojo nuotraukos ir uždaro naršyklę (arba naudoja windows explorer įkelti dokumento), Mes negali priversti vartotoją įvesti meta duomenų (dar kartą, out of the box).

Šis metodas gali būti naudojami siekiant padėti su tokia situacija. Mes galime naudoti "blogai pažymėtose duomenys" Rodyti lengvai nustatyti šiuos dokumentus ir juos pataisyti. Pora šį KPI ir turite gerą matomumą duomenys detalizavimo valdyti šias ypatingas aplinkybes.

</pabaigos>

Prenumeruoti savo dienoraštį.

Šią savaitę, Aš kovojo šiek tiek su mano komanda gauti MOSS įrengti paprastas dviejų serverių. Paėjus per ji, Turiu didesnę dėkingi už problemų žmonės ataskaitą rūšių MSDN forumuose ir kitur.

Galutinis ūkio konfigūracijos:

• SQL/Index/intraneto WFE viduje ugniasienę.
• WFE, DMZ.
• Tam tikros rūšies užkardos DMZ ir vidinė serverio.

Prieš pradėjome projektą, mes tegul žino, kuriems uostams reikia atidaryti kliento. Metu duoti ir priimti, pirmyn ir atgal per tą, Mes niekada aiškiai pasakė du svarbūs dalykai:

1. SSL tai jums reikia sertifikato.
2. DMZ serveris turi būti domeno dalis.

Pirmos dienos, Mes įdiegti MOSS parodė ir sužinojau, kad nebuvo sukurta domeno abonentų duomenų bazės ir samanų. Pereiti dalykų, Mes nuvyko į priekį ir įdiegti viską su vietos į intraneto serverio.

Šiuo metu, mes pamatėme painiavos per SSL pažymėjimą ir, Deja, nusprendėme, kad mūsų infrastruktūros vaikinas grįžti vėliau tą savaitę tęsti diegimą DMZ serveris. Tuo tarpu, Mes tirpalo architektų persikėlė į priekį su verslo daiktai.

Savaitgalis eina, ir klientas gauna pa.

Mūsų infrastruktūros vaikinas pasirodo ir atranda, kad DMZ serveris nėra prijungta prie bet kurio domeno (perimetro domeno su ribotą pasitikėjimą arba intraneto domeno). Mes iššvaistytos beveik per 1/2 dieną, kad. Jei mes ne leisti įklimpti mums trūksta SSL sertifikatas, Mes būtų atrastas tai anksčiau. Oh well….

Kitą dieną eina ir įvairių saugumo komitetų, suinteresuotųjų šalių ir (ne taip) nekaltų praeivių visi sutinka, kad ji yra OK prisijungti su intraneto domeno DMZ serveris (tai yra POC, vis dėlto, ne gamybos sprendimas).

Infrastruktūros vaikinas ateina į susivynioti dalykų. Šiuo metu mes sėkmingai pereiti į šiuolaikinės pirštinė meile vadinamas "SharePoint konfigūracijos vedlys." Mes turime žvilgtelėti centriniame administravime ir … Yee haw! … DMZ serverio yra nurodytas ūkio. Mes, šiek tiek arčiau ir suprantame, mes sumušė atidaryti Champaign šiek tiek erkė anksti. WSS paslaugų įstrigo į "pradeda" statusas.

Trumpai tariant, pasirodo, kad mes pamiršo pakeisti tarnybos abonementą per centrinė administracija tapatybė iš pirminės vietos paskyros į naują domeno sąskaitą. Mes padarėme, kad, vėl vyko konfigūravimo vedlį ir voila! Mes į verslo.

</pabaigos>

Prenumeruoti savo dienoraštį.

Nors tai tiesiog netiesa, kaip praktiškai, interneto žiniatinklio priekinės dalies, kad DMZ turi būti domeno (ty. ne kai standalone serverio savo mažai darbo grupės). Ji nebūtinai turi būti tame pačiame domene kaip vidaus WFE(s) ir kitų serveriai (ir tikriausiai neturėtų), bet ji turi būti domeno.

Mano kolegos ir aš praleido labai daug laiko pasiūlymą įtraukta SharePoint Pre-Rekvizitai. Tai apėmė išsamų ugniasienės konfigūracijų, kurie leistų DMZ serverio prisijungti prie ūkio ir tt. Deja, mums nepavyko įtraukti sakinį kažkur sakė, kad, poveikis, "visą kruviną ši konfigūracija yra leisti savo DMZ WFE serverio, domenas, prisijungti prie vidaus ūkio."

Perfect storm įvykių, kai mes iš esmės atrodė kairėje kai mes gali turėti pažvelgė į dešinę, prabilo slėpti šią problemą iš mūsų kol gana vėlai į šį procesą, tokiu būdu užkertant kelią man nuo remtis savo "anksti pasakyti blogos naujienos" taisyklė.

Atodūsis.

Prenumeruoti savo dienoraštį.