Olen projekti, jossa meidän täytyy kerätä vertailuluvut ympäri toiminto nimeltä "Jaa tarina." Ajatus on hyvin yksinkertainen — Jos etsit mielenkiintoinen artikkeli intranetissä ja haluat jakaa sen jonkun kanssa, valitsemalla linkin "Jaa tämä tarina" Lähetä se kaverisi.

Olemme pelannut mukautetun lomakkeen tähän tarkoitukseen, mutta loppujen lopuksi, järki voitti ja käytämme vain tuttu <href = mailto:…> tekniikka. (<href mailto:…> on yllättävän vahva hieman HTML; Bonuksena, Tämä yhteys tuo minut takaisin minun UNIX man sivut vanhaan; Oi niitä aikoja!).

Tämä tekniikka tarjoaa loistava käyttöliittymä loppukäyttäjille, koska he saavat käyttää tuttuja MS Outlook-asiakas (tai mikä tahansa sähköpostiohjelma on asennettu).

Se tekee asioista vaikeampaa meille huono kehittäjä tyypit koska ne asiakkaan * myös * haluaa tulevaisuudessa raportti, joka osoittaa, kuinka usein käyttäjät jakavat tarinoita ja mitkä tarinat jaetaan usein.

Me whiteboarded joitakin mahdollisia ratkaisuja. Suosikkini on kopio (CC) SharePoint-luetteloon. Näin, käyttäjä vielä saa outlook-asiakasohjelma, kun saamme kaapata tapahtuma, koska me saada kopio email itse. Joitakin haittoja selvää. Suurin ongelma on, että käyttäjä voisi yksinkertaisesti tyhjä ulos tai muuten mankeli CC osoite. Ja, välttämätöntä, että Tapahtumakirjasto sähköposteja. Meillä ajoitetun työn vastuussa puhdistuksen tussitaulu.

Jos sinulla on viisas lähestymistapa tämän ongelman ratkaisemiseksi, Älä kerro.

</loppu>

Tilaa blogiin.

Noudata minut viserrys http://www.twitter.com/pagalvin

Pyydettyä ja luvattujen, Olet ladannut esitys siitä, miten voit hankkia "suuri" vaatimuksia käyttäjät SharePoint hankkeita ja toteutukset. Se on täällä: http://CID-1cc1edb3daa9b8aa.SkyDrive.Live.com/Self.aspx/SharePoint/Paul Galvin Great Requirements.zip

Olen esittänyt tämä SharePointin parhaiden käytäntöjen konferenssissa, helmikuu 2009 (www.sharepointbestpractices.com). Jos olet osallistunut konferenssiin, Saat käyttöösi tämä myös konferenssin DVD.

Esitys sisältää paljon muistiinpanoja useimmat dioja. Se ei ole vain luoti kohtaa.

(Katso tästä muut esityksessäni hallinnon tapaustutkimus: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!3099.entry

</loppu>

Tilaa blogiin.

Noudata minut viserrys http://www.twitter.com/pagalvin

Kuten SharePoint-konsultti monenlaiset, Olen joutunut paljon SharePoint-toiminnot. Joskus, Sukeltaa melko syvällä. Muina aikoina vain huomaa sitä olen rientää joukko valikkovaihtoehdot. Yksi niistä on "omatoimisen sivuston luomisen." Minulla ei ole ollut tarvetta sille vasta tällä viikolla.

Tällä viikolla, Minun täytyy ratkaista liiketoiminnan ongelmia, joka mielestäni on tulossa yleisempiä kuin yritysten hellittää ja omaksua enemmän suoraan loppukäyttäjälle valvoa SharePoint. Tässä tapauksessa, Olen suunnitellut sivustomalli tukea tietyn käyttäjäyhteisön. Ihmiset tässä yhteisössä olisi voitava luoda omia sivustoja ovat tällä mallilla, kun halu iskee niitä.

Muistin nähneeni omatoimisen sivuston luomisen"" ennen ja minä olen aina makaavat että takana pääni ajatellut että "luonnin" mikä tarkoittaa SharePoint lingo, ilmeisesti tarpeeksi, jotain "päälle minulle jos haluat, että käyttäjät voivat luoda sivustoja, kun he haluavat."

Niin, Käynnistä se, koetus se rikki ja minulle, se ei luo sivustoja. Se luo sivusto kokoelmat. Suuri ero. Se ei ole sitä, mitä haluan, Ei todellakaan.

On mahdollista antaa käyttäjien luoda uusi alisivustot kautta mukautetun käyttöoikeustason. Tämä on juuri, jos olisin mennyt ensiksi paitsi että otsikon "omatoimisen sivustonluonnin" Label petti minua. Kautta hermona, I learn that it’s deceived others as well 🙂

Olen edelleen työtä, miten vähän enemmän virtaviivainen prosessi oleskellessaan puhtaasti kättelyssä, mutta selvä polku seuraa. Vain ei saada hajamielinen etiketti.

</loppu>

Tilaa blogiin.

Noudata minut viserrys http://www.twitter.com/pagalvin

Olin yksi 20 tai 30 (tai ehkä 100?) panelistit eilen illalla New Yorkin SharePoint käyttäjät-ryhmä Kokous. Sijaan tavallista esitysmuodossa, Tämä oli tietoja q&A yleisö ja paneelin jäsenten välillä. Varhain, Michael Lotter käyttöön minut uusi idea ja halusi jakaa.

Joku yleisöstä on kuvattu, miten hänen yrityksensä oli maksanut konsultti kirjoittaa hänen yrityksensä. Konsultti kirjoitti sen konsolisovelluksen SharePoint-objektimallin avulla. Tämän seurauksena, Tämä tarkoitti sitä, että ohjelma oli suoritettavaksi palvelimessa tilalla. Tämä tarkoitti sitä, että jokainen, joka halusi käyttää app on Kirjaudu palvelimeen, tehdä työtä ja kirjaudu ulos. Aluksi, Tämä ei ollut ongelma, mutta pian, enemmän ja enemmän (ei-tekniset) käyttäjä kaivata jotta apu hyödyllisyys. Hänen kysymys oli (mukaillen):

"Mitä vaihtoehtoja minulla? En halua pitää antaa käyttäjä halko suoraan palvelimeen, mutta he tarvitsevat tätä toimintoa."

Michael Lotter ehdotti että hän määrittää uuden virtuaalikoneen, Liity maatilan WFE: ssä ja antaa käyttäjien suorittaa hakemuksen sieltä.

Tämä on aika upea idea. Yleisesti tämä ratkaisu tuo mieleen ajatus, olennaisesti vain väliaikainen, lähes Kertakäyttöiset WFE. Mielestäni se on melko siisti käsite. Väliaikainen WFE suorittaa konsolisovellus, joka käyttää SharePoint-objektimallin. Voit myös käyttää sitä stsadm komentoja suoritetaan. Se ei tarvitse olla osa säännöllisesti paikallisen tasapainottaminen. Jos se menee alas, tai saa tuhoutunut, Voit vain spin uuden. Toistan itseäni, mutta minun täytyy vain sanoa, että se on todella siisti idea.

</loppu>

Tilaa blogiin.

Noudata minut viserrys http://www.twitter.com/pagalvin

Tämä viime viikolla, joku kysymyksen luominen SharePoint-ympäristö, joka käsitellä melko suuri määrä uusia asiakirjoja (10,000 +/- Tässä tapauksessa). En tiedä paljoakaan tästä, Mutta Kiitos tämän valkoisen kirjan, Mielestäni paljon aiempaa paremmin tietoon.

Minulle, Tämä valkoinen kirja on aika paljon vain kirjanmerkki tällä hetkellä, mutta alkoi käsittelyssä läpi sen ja ajattelin, haluaisin korostaa minun tärkein take-away. SharePoint voi skaalata käsitellä, vähintään, Tämä kuormitus:

• 50k uusia asiakirjoja päivässä.
• 10 miljoonaa asiakirjoja yhteensä.

Kirjoitan 50k / 10MM lukuja, koska ne on helppo muistaa. Niin kauan kuin te tiedätte minimivaatimuksia, et saa vaikeuksiin. Enimmäismäärät ovat vähintään 10 prosenttia korkeampi kuin että ja äärimmäinen viritys, mahdollisesti paljon korkeampi.

Kiitos, Mike Walsh, jälleen kerran ja hänen Weekly WSS FAQ päivityksiä ja korjauksia post. Jos et ole tilannut sen, te pitäisi vakavasti ajatella jokseenkin ajava se.

</loppu>

Tilaa blogiin.

Viime viikon aikana, minun katrabaho ja minä teemme töitä asiakkaan NYC. Olimme testaus eri osa MOSS täytäntöönpano "-standardin" työaseman koontikäännös (Toisin kuin meidän sylimikrot). Vaikka teemme, että, Me juoksi tulee muutamia virheet tekemällä seuraavat toimet:

• Avaa MS word-asiakirjan windows Explorerin kautta (joka käyttää WebDAV).
• Muuttaa.
• Tallenna se.

Tulin ymmärtämään, että joskus (yleensä ensimmäistä kertaa) Me tallennettu asiakirja, Tallenna ei "keppiä." Tallenna Tallenna. Osaamme asiakirjan takaisin ylös ja muutokset eivät olleet siellä.

Emme ymmärrä juuri kysymys tässä vaiheessa, mutta ajattelimme, että meidän pitäisi varmistaa, että työn asema oli asennettu uusin MS Office service pack. SE ihmiset meni ja teki sen. Kävimme läpi testin ja huomasimme uusi ongelma. Kun me tallennettu, nyt sai tämän virheen:

Tällä kertaa, tuntui jokainen muutos oli, Itse asiassa, tallennettu, Me vastasi kyllä vai ei skriptit kysymykseen.

Meillä oli vihdoin katsomaan todellinen versio Office ja käy ilmi, että työasema on käynnissä MS Office 2000 service pack 3 joka näkyy alle Help-> Aiheesta "Office 2002".

Tarinan opetus: Olen aina käyttää Office 2003 kuin minun vähintään perustason office versio WebDAV ja MOSS.

</loppu>

Tilaa blogiin.

(Etsi moottorin tarkoituksiin, Tämä on virhe on teksti):

Rivi: 11807

Char: 2

Virhe: Objekti ei tue tätä ominaisuutta tai menetelmää

Koodi; 0

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

Haluatko jatkaa käynnissä komentosarjat tällä sivulla?

Yhdessä tai minun ensimmäinen blogiviestit, Me sen jälkeen siirtää asiakkaan SPS kokonaisprosessia on kuvattu 2003 Moss. Lukija vasemmalle kommentti kysytte tarkemmin ja tässä se on.

Maahanmuuton projektin, Meillä oli löytää hyvä tapa siirtää SPS paljon 2003 asiakirjat yli Moss. Ensimmäinen kuormitus oli helppo. Luo uusi kohdetiedostokirjasto MOSS ja siirtää tiedostot Resurssienhallinnan avulla.

Tämä on uusi asiakirjakirjasto:

Avata kaksi ikkunaa tutkimusmatkailijat. SPS ensimmäinen pisteeseen 2003 ja toinen MOSS uuteen asiakirjakirjastoon. Seuraavat kuvakaappaus osoittaa tämän. Huomaa, että top-selain on todella suunnattu minun c:\Temp asema, mutta voitte kuvitella, se osoittaa SPS 2003 asiakirjakirjaston:

Tämän jälkeen vetämällä ja pudottamalla, minun tavoite näyttää tältä:

Nyt on aika käsitellä metatiedot. On vain yksi sarake metatietojen näiden asiakirjojen nimeltä "sijainti." Voimme nähdä edellä "kaikki asiakirjat" Katso, että sijainti on tyhjä. Se on helppoa, kirjoita sijainti tietoja taulukkonäkymän avulla, tai jopa mennä kunkin asiakirjan ominaisuuksia yksi kerrallaan lisää sijainti. Oletetaan, että ei ole käytännöllinen tapa määrittää sijainti-sarakkeen arvon automaattisesti ja että loppukäyttäjien tulee tehdä käsin. Lisäksi, Oletetaan että on olemassa satoja asiakirjat (ehkä tuhansia) ja että se kestää monta monta päivää päivittämään metatiedot. Kuten me kaikki tiedämme, kukaan ei istua alas ja toimi neljä viisi päivää peräjälkeen, päivityksen metatiedot asiakirjat. Sen sijaan, ne puhkeaa että ajan viikkoja tai mahdollisesti pidempään. Tämän prosessin helpottamiseksi, voimme luoda "korvamerkittöminä tiedot" Katso kuten:

Nyt, Kun joku istuu alas viettää kohdistettu päivittäin tunnin tai kaksi tag siirretyt tiedostot, he voivat käyttää "korvamerkittöminä-asiakirjat" Katso keskittyä niiden työtä:

Käyttäjien tag asiakirjoina, ne pudota pois tästä luettelosta.

Tämä käsite korvamerkittöminä tietonäkymän voi myös auttaa luokan data validation ongelma ihmiset tiedustella foorumeilla. Kättelyssä, ei ole mitenkään estää ladattaessa asiakirjaa palvelimeen Moss ja kirjoita ei metadataa. Voimme määrittää erityisesti sivustosarake on pakollinen, ja käyttäjä ei voi paina Tallenna painiketta. Kuitenkin, Jos käyttäjä lataa ja sitten sulkee selaimen (tai käyttää windows explorer ladata asiakirjan), Me emme voi pakottaa käyttäjä syöttää metatiedot (uudelleen, kättelyssä).

Tätä lähestymistapaa voidaan käyttää apuna tilanteessa. Käytämme "huonosti tagged tietoja" Katso helposti tunnistaa nämä asiakirjat ja korjata ne. Pari tätä KPI: tä ja sinulla on hyvä näkyvyys tietoihin porautuminen hallita näissä poikkeuksellisissa olosuhteissa.

</loppu>

Tilaa blogiin.

Tällä viikolla, Olen kamppaillut vähän minun joukkue saada MOSS asennettu yksinkertainen Kahden palvelimen palvelinfarmi. Joiden läpi, Minulla on ongelmia ihmiset raportin ollessa suurempi Arvonkorotus MSDN-foorumit ja muualla.

Lopullinen farmin kokoonpano:

• SQL/hakemisto/Intranet WFE palomuurin sisäpuolella.
• WFE demilitarisoitu alue.
• Jonkinlainen palomuuri DMZ ja sisäisen palvelimen välillä.

Ennen kuin aloitimme projektin, annamme asiakkaan tietää, mitkä portit on tarpeen olla avoin. Aikana antaa ja ottaa, edestakaisin tuosta, sanoimme koskaan varsinaisesti kaksi tärkeää asiaa:

1. SSL tarkoittaa tarvitset varmenteen.
2. DMZ-palvelin täytyy kuulua toimialueeseen.

Päivästä lähtien, oli jopa asentaa MOSS ja oppinut, että toimialuetilit tietokantaan ja MOSS ei ollut luotu. Asioiden edistämiseksi, Menin eteenpäin ja asentaa kaikki paikallisen käyttäjätilin intranet-palvelimelle.

Tässä vaiheessa, huomasimme sekaannus aikana SSL-sertifikaatti ja, Valitettavasti, päättänyt olla meidän infrastruktuuri kaveri palata myöhemmin viikolla jatkaa asennusta DMZ-palvelin. Sillä välin, Meidän ratkaisu arkkitehdit edennyt liiketoiminta jutut.

Viikonloppu kuluu ja asiakas saa todistuksen.

Meidän infrastruktuuri kaveri näkyy ja huomaa että DMZ-palvelin ei ole liitetty mihinkään toimialueeseen (edustan toimialueen rajoitettu luottamus tai intranet-toimialueen). Tuhlasimme lähes 1/2 joka päivä. Jos annamme ei ollut puuttuu SSL-varmenteen juuttua meille, Meidän huomanneet tämän aikaisemmin. Voi hyvin….

Toinen päivä päivältä ja eri turvallisuusasioiden komiteoiden, asianomaiset osapuolet ja (ei niin) viattomia sivullisia kaikki samaa, että se on OK liittyäksesi intranet-toimialueen DMZ-palvelin (Tämä on POC, Loppujen lopuksi, tuotanto-ratkaisu).

Infrastruktuurin kaveri tulee wrap asioita. Tällä kertaa onnistuneesti läpi nykyajan haaste hellästi tunnetaan nimellä "ohjatun SharePointin määrittämisen." Meillä on kurkistaa keskitetyn hallinnan ja … yee haw! … DMZ-palvelin näkyy tilalla. Katsoa hieman tarkemmin ja ymmärtää rikkoi avoinna Champaign punkki vähän aikaisin. WSS-palveluita on juuttunut "alkaa" tila.

Pitkän tarinan lyhyesti, on käynyt ilmi, unohdin muuttaa käyttäjätietoja kautta keskitetyn hallinnan tili alkuperäinen paikallisen tilin toimialueen käyttäjätilejä. Teimme näin, Ohjattu määritystoiminto uudelleen juoksi ja voila! Olimme liike.

</loppu>

Tilaa blogiin.

Vaikka ei ole kirjaimellisesti tosi, käytännön asiana, internet-pohjaisissa web-edusta, demilitarisoitu alue on oltava toimialueen (ts. ei joissakin yksittäiseen palvelimeen omaa pikku työryhmään). Se ei tarvitse olla samassa toimialueessa kuin sisäinen WFE(s) ja muut palvelimet (ja luultavasti ei pitäisi), mutta se on toimialueen.

Kollegani ja minä viettänyt kohtuuttomasti aikaa ehdotuksen, joka sisälsi SharePoint ennakkoedellytyksiä. Tähän sisältyy kattava luettelo palomuurikokoonpanoissa, jotka mahdollistaisivat DMZ-palvelimen liittyä tilalla ja niin edelleen. Valitettavasti, lause jonnekin, joka sanoi lisääminen epäonnistui, siitä, että, "koko verinen Tämä kokoonpano on jotta DMZ WFE palvelin, toimialueen, liittyä sisäisen tilan."

Täydellinen myrsky tapahtumat, jossa periaatteessa Etsimme vasemmalla kun voi näytti oikein, yrittäneet yhdessä salata ongelman meiltä melko myöhään prosessissa, mikä estää minua vetoaa minun "kertoa huonoja uutisia jo" sääntö.

Huokaus.

Tilaa blogiin.

Foorumin käyttäjät usein kuin kysymyksiä näin:

> Moi,
>
> Ystävällisesti kertoa minulle, jos on mahdollisuus rakentaa mukautetun luettelon kanssa
> pääkomponentti ja tietokomponentti tyyppi (kuten laskut) ilman InfoPathin avulla.
>

SharePoint tarjoaa joitakin ruutuun ominaisuuksia, jotka tukevat erilaisia liiketoimintavaatimusten kuten pois.

Yleensä, yksi linkkejä kahden luettelon avulla hakusarake. Luettelo A sisältää laskun otsikkotiedot ja luettelossa B sisältää laskutustiedot.

Ylläpitää asiakasnumerot luetteloita avulla, tuotenumerot, jne.

Sisältökysely-web-osan käytöstä (Moss vain) ja/tai tietonäkymän web-osan yhdistettyjen näkymien luetteloiden luominen. SQL Server Reporting Services (SRS) löytyy myös raportointi puolelle.

Kuitenkin, on joitakin tärkeitä rajoituksia, että vaikea käyttää puhdasta OOBE ominaisuuksia mitään, että on edes kohtuullisen monimutkainen. Näitä ovat:

• Koon liittyvä haku luettelee vs. "smartness" sarakkeen tietotyypin syöteargumenttien. Sarakkeen valintatyypin esittäytyy UI eri tavalla sen mukaan, onko käytössä Multi-Select vai ei. Kummassakin tapauksessa, OOBE ohjausobjekti näyttää kaikki käytettävissä olevat kohteet lähdeluettelosta. Jos lähdeluettelossa on 1,000 kohteita, Tämä tulee olemaan ongelma. Haku valvonta ei sivu läpi ne asiat. Sen sijaan, se vetää ne kaikki ohjausobjektiin. Se tekee erittäin hankala käyttöliittymä sekä tietojen syöttämiseen ja suorituskyvyn.
• Haut "vetäytyä" yhden sarakkeen tietojen. Et koskaan vedä takaisin useamman kuin yhden sarakkeen tietojen lähde-luettelosta. Esimerkiksi, et voi valita asiakas "12345" ja numero sekä asiakkaan nimi ja osoite samaan aikaan. Hakua näyttää vain asiakkaan numero ja muuta. Tämä tekee avuton ja hankala käyttöliittymä.
• Sisäinen muotoinen tiedoksiantoa. Olen kirjoittanut tästä täällä. Voitaisi tehdä CSS avattavista, ehdollisesti ottaminen kentät, jne.
• Johdannaispoistoja tai sisäänrakennettu viite-eheys. SharePoint kohtelee mukautettuja luetteloita pienille tai keskisuurille yrityksille ja ei salli linkittää ne toisiinsa äänimaailmansa ERD. Esimerkiksi, SharePointin avulla voit luoda kaksi mukautettuja luetteloita, "asiakas" ja "laskun otsikko". Voit luoda laskun ylätunnisteen linkkejä asiakkaan asiakasluetteloon. Sitten, asiakkaan poistaminen luettelosta. Kättelyssä, ei ole mitenkään estää tämän. Ratkaista tällaiset ongelmat, tavallisesti käyttämäsi tapahtumakäsittelijät.

Se voi tuntua synkkä, mutta haluaisin silti käyttää SharePoint lähtökohta rakentaa sellainen toiminto. Vaikka on olemassa erot mitä tarvitset ratkaisu, SharePoint mahdollistaa näiden puutteiden käyttämällä työkaluja kuten:

• Tapahtumakäsittelijät. Käyttää niitä viite-eheyden.
• Mukautettuja sarakkeita: Luo mukautettuja ja käyttää niitä sijasta oletuksena hakusarake. Lisää henkilöhaku, puskurointi ja AJAX-ominaisuudet, jotta ne vastaavat.
• BDC. Vain MOSS-toiminto mahdollistaa kyselyn muita SharePoint-luetteloita superior käyttöliittymä tavallista hakusarake. BDC pääsee myös back-end-palvelinsovellukselle. Käytä BDC välttää replikointi. Sen sijaan jäljitellä asiakastiedot loppupäätä ERP-järjestelmä, Käytä BDC sen sijaan. BDC-ominaisuudet tarjoavat arka käyttäjä liitäntä vetää tiedot suoraan ERP-järjestelmä, jossa se kuuluu ja välttää hässäkkä säilyttää replikointi ratkaisu.

  BDC on MOSS-ominaisuus (ei käytettävissä WSS) ja haastava määrittäminen.

• ASP.NET web-lomakkeen: Luoda täysin varustellun AJAX-pohjaisten lomakkeen, joka käyttää SharePoint objekti mallista ja web services hyödyntää SharePoint-luetteloiden samalla hyvin reagoiva käyttöliittymä.

Viimeinen vaihtoehto voi tuntea olet alkaen tyhjästä, mutta katsovat, että SharePoint-alustan lähtee sinulle seuraavat piirteet:

• Suojausmalli huolto.
• Valikkojärjestelmän ylläpito.
• "Päätaulukko" (ts. Mukautetut luettelot) turvallisuus, sisäänrakennettu huolto ja tarkastus.
• Etsi.
• Loppupäätä integrointityökalujen (BDC).

Jos aloitat uuden tyhjän projektin visual studiossa, paljon infrastruktuuria ja LVI rakentaa ennen kuin lähestyt SharePoint tarjoaa.

Mielestäni Microsoft aikoo laajentaa SharePoint tämänsuuntaisia sovelluskehitys. Se tuntuu luonnollinen jatke pohja olemassa SharePointiin. Microsoftin CRM sovellus tarjoaa paljon laajennettavuus tyyppejä tarvitaan tukemaan otsikon tietokomponentin sovelluskehitys. Vaikka nämä ominaisuudet ovat CRM: ssä, tekniikka on ilmeisesti SharePoint-kehitysryhmän ja odotan, että se tekee sen tavalla osaksi SharePoint-tuotteen loppuun mennessä 2008. Jos jollakulla on tietoa tai tietoa tästä, Jätä kommentti.

</loppu>