Mazinův blog o SharePointu

Kombinace SharePointu 2010 a InfoPathu 2013 je smrtící, naštěstí jen na serveru

mazin — Fri, 10 May 2013 20:00:00 GMT

Na vývojovém počítači jsem si nainstaloval Office Professional Plus 2013, včetně InfoPathu 2013, protože InfoPath čas od času používám a chtěl jsem si i vyzkoušet, co umí nového. Nadšení z nových Office, no dobře tak úplně nadšený jsem nebyl, mi ale zkazila tato chyba na některých místech v Centrální administraci:

Failed to call GetTypes on assembly Microsoft.Office.InfoPath.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c. Could not load file or assembly 'Microsoft.Office.InfoPath, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The system cannot find the file specified.

Už hlášení samotné naznačuje, o co jde. SharePoint se pídil po nějakém typu (pravděpodobně se pokoušel vytvořit objekt) z assembly Microsoft.Office.InfoPath.Server.dll verze 14.0. Tedy z SharePoint Serveru 2010. Místo toho mu ale .NET runtime podal z GAC (global assembly cache) verzi 15.0. Přestože v GAC obsahoval obě verze. Verze 15.0 pochází z InfoPathu 2013 a v ní požadovaný typ není.

Řešení bylo naštěstí jednoduché. Odinstalovat InfoPath 2013. Holt si ho budu muset vyzkoušet jinde. Ještě podotýkám, že daná chyba se vyskytuje jen na SharePoint Serveru, SharePoint Foundation postižen není. Ten totiž zmiňovanou assembly nepoužívá.

Zvláštní chování SharePointu 2010 při smazání a znovuvytvoření webu

mazin — Thu, 09 May 2013 19:45:00 GMT

Nedávno jsem se setkal opět s velmi zajímavým chováním. Podle mého názoru jde o chybu.

Šlo o následující věc. Nasadil jsem funkci se sloupcem webu. Pak jsem ho potřeboval změnit. Proto jsem aktualizoval sloupec a funkci nasadil a aktivoval znovu. Protože se ale sloupec neaktualizoval správně ani po opakované deaktivaci funkce a odebrání řešení, rozhodl jsem se smazat celý web a vytvořit nový na stejné adrese. A začaly se dít věci…

Na nově vytvořeném webu sice nebyla moje funkce, ale už tam byl problémový sloupec! Zkoušel jsem stejný postup na několika SharePointech a výsledek byl ještě zajímavější. Na některých se chování opakovalo. Na jiných znovuvytvoření webu proběhlo korektně, tedy bez “automatického” vytvoření zkoumaného sloupce. Porovnáním serverů jsem došel k tomu, že špatné chování bylo na serverech s nainstalovaným SP1. Správně se chovaly servery bez SP1. A tehdy mi to došlo. Problém bude asi v koši. Protože teprve v SP1 se weby mažou do koše. Před SP1 se weby mazaly rovnou, bez možnosti obnovy. Ještě jsem to ověřil vysypáním koše na SP1 instalacích a to moje podezření potvrdilo.

V rámci přesunu webu do koše si SP musí držet informaci i o sloupcích daného webu. To je v pořádku. Je to nutné kvůli případnému obnovení. Chyba ale je v tom, že pokud vytvořím nový web na stejné adrese, tak se mi sloupec objeví i v něm. Zřejmě mají drženou vazbu sloupce na web pomocí URL adresy webu.

Ponaučení by mohlo znít asi tak, že teprve odstraněním věci (v našem případě webu) z koše se věc opravdu smaže. Do té doby stále existuje a může vám komplikovat život i v situacích, kdy byste to nečekali. A není to jen tato.

SharePoint 2010 ve Windows 8

mazin — Mon, 01 Apr 2013 23:00:00 GMT

SharePoint 2010, na rozdíl od verze 2013 , lze nainstalovat na klientské operační systémy. To je známá věc a na Windows 7 to mám vyzkoušeno. Nyní jsem testoval instalaci na Windows 8.

Instalace

Instalace je velmi podobná té na Windows 7. Jde především o konfiguraci Windows samotných, tedy instalaci IIS a .NET frameworku 3.5. Pak prerekvizity SP a úpravu instalačních souborů. Více se dočtete zde. Pro správný průchod Průvodce konfiguraci produktu SharePoint je nutné přepnout IIS do režimu .NET 2.0, tedy alespoň po dobu instalace. Jinak průvodce spadne s tím, že web.config obsahuje 2 stejné sekce.

Provoz

Během provozu se objevuje stejný problém s právy jako při instalaci SharePointu na Windows 2008 R2. Jde o přístup účtu IIS poolu ke COM objektu IIS WAMREG admin Service. Píšu o něm zde.

Další komplikace souvisí s PowerShellem. Windows 8 obsahuje PowerShell verze 3. PowerShell příkazy používané SharePointem jsou určeny pro PowerShell verze 2 a nejsou kompatibilní s verzí 3. Proto je nutné spustit PowerShell 2. To se udělá příkazem PowerShell –version 2.

Práva jsou ve Windows 8 velmi utažená. Proto je nutné PowerShell spouštět vždy jako administrátor. Ve Windows 7 to bylo doporučované, ale ve Windows 8 je to nezbytné. Totéž platí pro Visual Studio při vývoji. Velkým překvapením pro mne ale bylo zjištění, že i prohlížeč je nutné spouštět jako administrátor. Jinak nebudete mít v centrální administraci dostupné všechny volby (viz. 2 obrázky níže) a změny mnohých dalších nastavení skončí chybou.

Centrální administrace v IE spuštěném s a bez admistrátorského režimu.

Závěr

SharePoint 2010 nainstalovat a provozovat na Windows 8 lze. Chce to ale trpělivost a připravit se na komplikace s právy a PowerShellem.

Školení v Gopasu

mazin — Tue, 05 Feb 2013 21:12:36 GMT

Připravil jsem pro vás v Gopasu školení pokročilých programovacích technik pro SharePoint 2010. Jde o pětidenní školení GOC 3382, které navazuje na MOC 10175. Obsahuje témata, která v MOC kurzu nejsou, ale která jsou podle mě důležitá při tvorbě SharePoint řešení. Pokusil jsem se do něj vměstnat své zkušenosti s SP vývojem. Neobsahuje tedy to, co si Microsoft myslí, že byste měli vědět, ale to, co jsem během bezmála 10 let vývoje skutečně použil. Podrobnosti najdete zde. První běh školení je naplánovaný od 25.2. Srdečně vás zvu.

Další díl příběhu SharePoint 2010 vs IE x64

mazin — Sun, 03 Feb 2013 21:21:01 GMT

Před pár dny jsem opět řešil zpočátku velmi podivný uživatelský problém.

Uživatelský popis zněl asi takto: "Do knihovny dokumentů můžu nahrát wordovský dokument, můžu je upravovat, ale při pokusu o přidání dokumentu pomocí tlačítka v ribbonu se mi objeví stránka s chybou o nedostatku práv. Ta s možností žádosti o přístup."

Analýza nastavení práv nepřinesla nic. Práva byla nastavena dobře. Navíc, pokud by byla na vině práva, nešlo by ani nahrávat dokumenty. Kromě toho by v takovém případě byla nedostupná ikona pro přidání dokumentů. Zkontroloval jsem proto i typy obsahu a event receivery, ale stále nic podezřelého. Při testu na jiném počítači se stejným uživatelem bylo všechno OK. No a odtud byl už jen kousek k tomu, abych zkontroloval verzi IE. A bingo!

Nepříjemné chování vyhledávacího engine SharePointu 2010

mazin — Sun, 18 Nov 2012 20:35:35 GMT

Vyhledávání je důležitou schopností SharePointu. Zvláště v SharePoint Serveru, kde se dá (na rozdíl od Foundation edice) všemožně konfigurovat, jde o mocný nástroj k tomu, aby uživatel našel, co potřebuje. Kromě SharePointu samotného umí prohledávat i jiné webové zdroje.

Trpí ale jednou vadou, která bohužel snižuje jeho použitelnost. Každý webový zdroj, který má být prohledán, indexován a připraven k fulltextovému vyhledávání je, kromě jiného, definován tzv. počáteční adresou (může jich být i více). Zde prohledávací (crawl) engine začíná a zpracovává nalezené stránky. Získává z nich data pro fulltext index a hledá v nich odkazy na další stránky a tak pokračuje dál a dál. Problém je v tom, že URL (resp. část URL za adresou serveru a portem), podle normy rozlišuje mezi velkými a malými písmeny (je tedy case sensitive). Bohužel crawl engine v SP převádí adresy na malé znaky. Minimálně ty počáteční. A to i přesto, že je v konfigurační DB má uložené tak, jak mu je zadáte. Pokud tedy cílový web rozlišuje mezi velkými a malými znaky např. rozlišuje mezi DocId a docid, může se vám stát, že z webového zdroje prohledáte pouze chybovou stránku.

Podpora více jazyků v SharePointu

mazin — Mon, 05 Nov 2012 19:45:00 GMT

Podpora více jazyků je v dnešním globalizovaném světě v podstatě nutností. Mnoho firem dnes působí v několika zemích a proto potřebuje, aby jejich portály dokázali používat všichni z nich, bez ohledu na jazyk, kterým hovoří. Pojďme se podívat, co nám v této oblasti nabízí SharePoint 2010. Podpora více jazyků v SharePointu 2010 má několik aspektů. Budeme se jim věnovat v jednotlivých kapitolách.

Systémová podpora

Prvním z aspektů je podpora více jazyků na úrovni prostředí jako takového. To znamená v administraci, nastavovacích stránkách a dialozích, v menu, ribbonech atd. Tedy věci, které přímo nesouvisí s obsahem. Zde fungují tzv. jazykové balíčky. Tímto způsobem se dá do anglické instalace SharePointu přidat podpora např. češtiny nebo obráceně. Jazykové balíčky obvykle existují ve 2 variantách. Pro SharePoint Foundation a pro SharePoint Server. Dříve bylo nutné instalovat je na server postupně. Nyní to už není nutné. Aktuálně SharePoint podporuje cca 49 jazyků. Podpora více jazyků se zapíná na úrovni jednotlivých webů. Instalací jazykového balíčku získáte:

šablony webů a seznamů v daném jazyce
lokalizované nastavovací stránky, dialogy, ribbony a jiné systémové části SharePointu
překlady jmen systémových seznamů (jako např. Úkoly, Stránky webu) a systémových sloupců (jako jsou Nadpis, Autor,..)

Vícejazyčnost seznamů a knihoven dokumentů

Dalším aspektem je vícejazyčnost názvů seznamů, knihoven dokumentů, sloupců, typů obsahů a zobrazení. Když nainstalujete jazykový balíček, systémové seznamy, sloupce, a typy obsahu se lokalizují automaticky. Co ale vaše vlastní seznamy, sloupce a typy obsahu? Po zapnutí lokalizace vám v nastavení webu vám přibydou možnosti exportovat zmíněné texty do souboru. Vytvoří vám to standardní soubor se zdroji tak, jak ho znají vývojáři .NETu. Jde o RESX soubor. V podstatě je to XML soubor. Ten obsahuje vždy klíč, hodnotu a komentář pro každý přeložitelný text. Obecně může obsahovat i obrázky, ale to SharePoint nepodporuje. Naopak je důležité při překladu nastavit správně kód jazyka do něhož jste soubor přeložili. Jde o 4místné číslo, tzv. LCID. Jejich výčet najdete například zde. Výsledek překladu importujete zpět do SharePointu a od toho okamžiku máte lokalizované:

názvy vlastních seznamů
názvy vlastních sloupců
názvy a popis vlastních typů obsahů

Bohužel se tímto způsobem nedají lokalizovat názvy zobrazení, takže i když se název seznamu (např. Úkoly a Tasks) a jeho sloupce bude měnit podle jazyka uživatele, tak zobrazení budou mít pořád stejné názvy tedy Všechny položky nebo All Items.

Grafický vzhled

K podpoře více jazyků patří i formátování. Proto má v SharePointu každý jazyk svoji sadu kaskádních stylů. Pokud jste si tedy upravili styly v jednom jazyce, bylo by vhodné provést tytéž změny i dalších vámi podporovaných jazycích, ať to uživatele při jejich přepínání nemate.

Vícejazyčnost dat

Bylo by krásné, kdyby se text úkolu, který napíšete česky, zobrazoval anglickému kolegovi anglicky, ale to se v SharePointu 2010 neděje. Bohužel se tam ale neděje ani to, že by se vám měnily hodnoty sloupců typu volba (např. stavů úkolů). SharePoint nepodporuje dynamickou vícejazyčnost dat. Hodnoty sloupců v SharePointu jsou prostě vždy uloženy v jednom jazyce.

Zastavme se na chvíli u vytváření seznamů. Tato situace totiž souvisí s daty. Především s typem sloupce volba o němž jsem se zmiňoval. Šablony seznamů i sloupce webu mohou podporovat více jazyků, na druhou stranu jsme si řekli, že SharePoint ukládá hodnoty sloupců pouze v jednom jazyce. SharePoint při vytváření seznamů bere jazyk šablony s jejíž pomocí byl web na němž vytváříte seznam vytvořen. Pokud jste aktuální web vytvořili z české šablony, tak se pro potřeby vytvoření seznamu vezme jeho česká definice (pokud je definována). Na anglickém webu (resp. na webu vytvořeném z anglické šablony) se vytvoří seznam s anglickými hodnotami ve výčtovém sloupci.

Jedinou vyjímkou, kde je podporována dynamická vícejazyčnost v datech jsou spravovaná metadata (managed metadata). Toto je funkce, která je dostupná v SharePoint Serveru a umožnuje “tagovat” záznamy nebo dokumenty pomocí značek z tzv. taxonomických stromů. To jsou stromy pojmů, které mohou uživatelé použít jako značky. A každý pojem může být definovaný v několika jazycích. Rozdíl oproti klíčovým slovům (keywords) v pojetí SharePointu je v tom, že jako klíčové slovo může uživatel použít cokoli co ho napadne. Naproti tomu u spravovaných metadat, je někdo zodpovědný za správu a údržbu těch taxonomických stromů a uživatel musí vybírat pouze hodnoty z těchto stromů.

Varianty

V Sharepoint Serveru máte oproti Foundation verzi k dispozici ještě jednu zajímavou funkci, která pracuje s více jazyky. Jde o takzvané varianty. Ty přistupují k více jazyků jiným způsobem než jsme si dosud popisovali. Pracují na úrovni webu a podporují jeho jazykové varianty, resp. varianty jeho stránek (podporuje to pouze stránky uložené v knihovně dokumentů Stránky webu). Popis této funkce by vydal na samostatný příspěvek, ve stručnosti to funguje následovně:

Využívá publikačního mechanizmu
Vytvoříte si web, bude mít např. adresu http://server/web.
Pod ním vytvoříte několik podwebů např. http://server/web/cs a http://server/web/en.
V administraci kolekce webů každý z nich označíte různým jazykem a jeden z nich stanovíte jako zdrojový. Zbylé weby představují různé jazykové verze zdrojového webu.
Při úpravě stránek ve zdrojovém webu jsou publikovány na weby variant. Na vás je zajistit překlad do příslušných jazyků. Toto SharePoint neřeší. Po překladu a publikaci je dostupná nová stránka (resp. nová verze stránky) uživatelům s daným jazykem.
Uživatel přistupuje na adresu http://server/web a podle nastaveného jazyka je přesměrován na odpovídající web.

Určování jazyka

Dosud jsme se bavili o tom, jak SharePoint podporuje vícejazyčnost sebe sama i svého obsahu. Jak ale SharePoint určuje jaký jazyk použít pro zobrazení, resp. práci s daty?

Především je potřeba si říci, že v SharePointu 2010 jazyk není vlastností jednotlivých uživatelů. Jazyk uživatele je určován nastavením prohlížeče. Pokud chce uživatel jazyk změnit má na to volbu v menu u svého přihlašovacího jména. Ale ani tato změna se nikam neukládá a slouží pouze pro danou session.
Tento přistup má mnoho důsledků. Jedním z nich je fakt, že s jazykem uživatele nemohou pracovat procesy na pozadí. K nim informace o nastavení prohlížeče daného uživatele “neprobublá”. Např. workflow nemůže využít znalosti jazyka uživatele a nemůže mu vytvořit úkol s textem v jazyce, kterému uživatel rozumí. Stejně to funguje v případě notifikací. Ty jsou uživateli zasílány v jazyce webu. Tedy podle jazyka šablony ze které byl daný web vytvořen. To je způsob jakým SharePoint řeší situaci, kdy není schopen rozhodnout, jaký jazyk v dané situaci použít.
Jazyk webu se také používá při vytváření seznamů (viz. výše).

Co vícejazyčnost nepodporuje?

data v seznamech a knihovnách dokumentů (s vyjímkou spravovaných metadat)
názvy zobrazení seznamů a knihoven dokumentů
jména skupin
vlastní úrovně oprávnění
hodnoty parametrů webpartů
šablony dokumentových typů obsahu – každý typ obsahu dokumentu má pouze jednu šablonu. Pokud chcete mít několik jazykových verzí, musíte vytvořit odpovídající počet typů obsahu.

Novinky v SharePointu 2013

V SharePointu 2013 je jazyk vlastností uživatele a např. upozornění na to berou vliv.

Další novinkou v SharePointu 2013 je služba Machine Translation Service. Ta se pokouší o automatizovaný překlad i dat, tedy to, co SharePoint 2010 neumí. Při využití Office Web Apps (práce s dokumenty přímo v prohlížeči) to překládá i dokumenty. Dělá to pomocí služby Bing. Posílá tedy data MS službě. Výsledky překladů se ukládají do cache. Její použití je na zvážení. Vaše data (resp. vašich zákazníků) jsou odesílána třetí straně. Navíc se jedná o automatizovaný překlad, který ne vždy musí být ideální. Nicméně se stále zlepšuje.

Chyba při rozcházení Windows Azure Workflow 1.0 Beta

mazin — Mon, 03 Sep 2012 18:35:00 GMT

Vyšla nová verze SharePointu 2013. Zatím tedy jako Preview, ale i tak si zaslouží prozkoumání. Jednou z výrazných novinek je změna v hostování workflow. Jednak byl proveden upgrade použitého Workflow Runtime z verze 3.5 na 4.5. Taky byla celá funkcionalita vytažena do samostatného produktu, který se jmenuje Windows Azure Workflow. Z důvodů zpětné kompatibility SharePoint 2013 sám obsahuje původní Workflow Runtime, takže již vytvořená workflow vám budou fungovat.

Při rozcházení jsem ale narazil na jeden problém. Evidentně udělali soudruzi z Redmontu někde chybu. Věřím, že ve finální verzi bude odstraněna. Je to typická chyba, kdy programátor nevezme v úvahu nastavení místního prostředí. Instalace proběhla v pořádku, ale problém nastal v konfiguraci. Konfigurační průvodce sice doběhl v pořádku. Workflow služba (Workflow Service Backend) ale neběžela a při pokusu o spuštění padala s chybou s nicneříkající chybou v EventLogu. Bylo nutné prozkoumat ještě log služby. Ten najdete také v EventLogu v sekci "Applications and Services Logs\Microsoft-Workflow\Operational". Zde najdete chybu "'WorkflowServiceMaxDispatcherFailureRate' is not formatted correctly. The configuration string should be parsable to a 'Single' type. Current config value is '0.1'.'" Problém byl tedy v konfigurační databázi (WFResourceManagementDB). Ta obsahuje tabulku WorkflowServiceConfig, ve které jsou uloženy konfigurační údaje. Jde o klasickou tabulku typu klíč - hodnota (v tomto případě sloupce ConfigName a ConfigValue). Oba údaje jsou řetězce. Instalace vytvořila pár WorkflowServiceMaxDispatcherFailureRate (viz. text chyby) s hodnotou "0.1". Nicméně služba při startu se snažila tento řetězec zpracovat jako číslo, ale to padalo. Když jsem hodnotu upravil na "0,1", služba se rozeběhla. Evidentně se to pokoušela zpracovat česky. A to i přesto, že server byl nainstalován anglicky. Formát čísel apod. byly sice nastaveny na češtinu, ale i když jsem to změnil na angličtinu, tak to nepomohlo.

Přeji úspěšné testování.

Mazání historie workflow

mazin — Wed, 08 Aug 2012 21:00:00 GMT

SharePoint má jednu záludnou vlastnost. A totiž tu, že nemaže obsah seznamů historie pracovního postupu. A to ani v případě smazání položek nad nimiž ta WF běžela. Za určitých okolností by to mohlo mít smysl. Můžu asi chtít si projít historii životního běhu záznamu, který už neexistuje. Měl by ale existovat nějaký mechanizmus, který by zajišťoval, že množství takových záznamů nepřeroste rozumnou míru. Zvláště v případě "ukecaných" WF a velkého množství položek to může vést k extrémnímu počtu záznamů v databázi. Problém je o to horší, že záznamy o běhu workflow se ukládají do "běžných" seznamů jako jsou "Historie pracovního postupu" a tedy do tabulky AllUserData. Zde jsou zjednodušeně řečeno uloženy všechny záznamy ze seznamů a knihoven dokumentů jedné databáze obsahu. V praxi jsem zažil jednu databázi obsahu, kde záznamy o běhu workflow tvořily více než 90% řádků v tabulce AllUserData.

Naštěstí někdo už tento problém řešil a napsal nástroj na dávkové mazání historie workflow. Najdete ho na MSDN.

Doporučuji vám proto projít si seznamy jako jsou Historie pracovního postupu a podobně. On ten nastroj totiž umožňuje mazání záznamů po dávkách včetně jejich vymazání z koše. Díky tomu řeší hned 2 problémy, na které byste narazili při prostém mazání položek ze seznamů:

problém s velkými transakčními logy (o tom jsem se zmiňoval v jednom ze svých dřívějších příspěvků)
ke skutečnému odstranění záznamů z DB dojde až po vysypání koše, což opět může narazit na transakční problém.

Potíže se záznamy auditu

mazin — Mon, 11 Jun 2012 21:45:00 GMT

SharePoint server umožňuje auditovat přístup k informacím, co kdo otevřel, změnil a podobně. Toto je velmi užitečná funkce, díky které můžete doložit kdo a kdy přistoupil k citlivým informacím. Zvláště v případě jejich vyzrazení se to může hodit. Nastavuje se ve Správě kolekce webů, kde se dají nastavit události, které se mají auditovat.

Pro jednotlivé záznamy:

Otevírání nebo stahování dokumentů, zobrazování položek v seznamech nebo zobrazování vlastností položek
Úpravy položek
Rezervování položek nebo vracení položek se změnami
Přesouvání nebo kopírování položek do jiného umístění na webu
Odstraňování nebo obnovování položek

Pro seznamy, knihovny a weby:

Úpravy typů obsahu a sloupců
Prohledávání obsahu webu
Úpravy uživatelů a oprávnění

Dále se dá nastavit, zda a po jaké době se mají auditní informace mazat. To velmi doporučuji. Už na středně velkém portálu totiž mohou auditní informace přibývat netušenou rychlostí. Nese to sebou ale jedno úskalí související s mazání starších záznamů. Za to je zodpovědný job Oříznutí protokolu auditování (Audit Log Trimming), který se standardně spouští jednou za měsíc. Tento job totiž spouští uloženou proceduru proc_TrimAuditEntries. Ta bohužel není napsaná zrovna nejlépe. Auditních záznamů totiž může, jak už jsem zmínil, vznikat poměrně dost (u jedné středně velké firmy jsem zažil i několik milionů záznamů denně, záleží na pracovitosti uživatelů). Proto se jejich mazání jednou měsíčně nemusí obejít bez komplikací. Jde především o to, že zmíněná procedura maže záznamy jedním delete příkazem, tedy v jedné transakci. Díky tomu, v případě velkého množství záznamů, můžete narazit na omezení velikosti transakčního logu nebo v horším případě na velikosti disku s tímto logem. Navíc se ještě job v takovém případě neozve a neskončí chybou, takže se na první pohled zdá, že je vše v pořádku. Ale není. Když se mu nepodařilo smazat data jeden měsíc, tak se mu to určitě nepodaří ani žádný další a tabulka s logy AuditData utěšeně narůstá...

Řešení problému má 2 fáze:

Je potřeba promazat tabulku AuditData. To uděláte opakovaným spouštěním procedury proc_TrimAuditEntries s pečlivým nastavením parametru @EndDate (mažou se starší záznamy). Nejlépe ještě před tím přepněte databázi do simple recovery modu (tím omezíte velikost transakčního logu). Potom ji opět přepněte zpět do Full recovery modu.
Přeplánujte job Oříznutí protokolu auditování tak, aby se spouštěl dostatečně často. Současně nastavte omezení velikosti transakčního logu tak, aby to zvládl mazání starých auditních záznamů.

Na závěr musím říct, že bohužel procedura proc_TrimAuditEntries není jediná v SP, která není připravena na to, že bude manipulovat s velkým množstvím dat, takže se podobný problém může vyskytnout i v jiných situacích.

Odkazy v upozorněních

mazin — Sun, 25 Mar 2012 20:25:00 GMT

Upozornění jsou užitečná funkce v SharePointu. Jenže sebou přinášejí jeden problém (rozhodně ne jediný). Tím problémem je, jakou adresu má SharePoint použít u odkazů v upozorňovacím emailu. Např. na editaci položky, úpravu nastavení upozornění a podobně. SharePoint totiž může mít hned několik adres. Dají se spravovat v sekci Konfigurovat mapování alternativních adres URL v Centrální administraci.

Aby se s tím SharePoint nějak popral postupuje podle následujících pravidel:

Uživatelovi se posílají upozornění s adresou, která odpovídá adrese použité v okamžiku vytvoření.
U upozornění, které definuje administrátor (např. notifikace při přiřazení úkolu), je to adresa, kterou použil admin.

Zejména u těch uživatelsky definovaných upozornění jde o poměrně rozumný přístup, protože umožňuje různým uživatelům mít v upozorněních různou adresu. Navíc adresa odpovídá té, kterou uživatel minimálně jednou použil.

U administrátorem definovaných upozorněních už to tak jednoduché není, protože administrátor může pro přístup k SharePointu používat jinou adresu než běžní uživatelé. Musí na to prostě pamatovat.

Naštěstí existuje powershell příkaz, kterým se URL adresy dají přemapovat. Bohužel není mezi standardními SharePointími příkazy, ale dá se stáhnout z MSDN. Bude se vám hodit nejen v situaci, kdy uživatel začne používat jinou adresu než v okamžiku definice upozornění, ale i v situaci, kdy např. obnovíte farmu ze zálohy na stroji, který se jmenuje jinak než ten původní.

Chyba při nasazení projektů z Visual Studia, které vznikly importem WSP

mazin — Sun, 25 Mar 2012 19:30:00 GMT

Jednou z užitečných věcí, která je nová ve Visual Studiu 2010 a v SharePointu 2010, je možnost "naklikat" si v UI seznamy, typy obsahu, zobrazení atd a následně to uložit jako šablonu webu. Dobré je, že šablona webu je WSP (kéž by to tak bylo i u šablon seznamů). Další na to navazující užitečná věc je ve Visual Studiu 2010. Zde můžete toto WSP naimportovat tak, že Visual Studio 2010 z něj vytvoří projekt. V takovém projektu můžete dodělat věci, které se v UI udělat nedají, nebo se dělají špatně.

Důvodem pro takovou dvojitou akci může být např. to, že ve Visual Studiu 2010 není designer seznamů, typů obsahu, zobrazení a je nutné je definovat psaním nepřehledných XML. Naštěstí ve Visual Studiu 11 už takový designer je.

Problém je ale v tom, že Visual Studiem 2010 vytvořené řešení používá u feature seznamů receiver Microsoft.SharePoint.Workflow.SPDeclarativeWorkflowProvisioningFullTrustOnlyFeatureReceiver. Ten (nebo něco co používá) ale psal někdo, kdo zřejmě nikdy neslyšel o jiných než v angličtině se vyskytujících se znacích.

Například takové zobrazení "Všechny položky" se totiž vytvoří jako "VÅ¡echny poloÅ¾ky". Je to proto, že š má UTF-8 reprezentaci c5a1. Zmíněný receiver ale nezpracovává konfigurační XML (např. schema.xml) jako UTF-8 (i když to mají nastavené v hlavičce), ale jako obyčejné ASCII, tedy po jednotlivých bytech. V tomto kódování odpovídá c5 znak Å a a1 znak ¡. Bohužel se to netýká jen seznamů, ale i zobrazení, sloupců atd zkrátka všemu, co může ve schématu seznamu být.

Závěr

Jde o školáckou chybu při psaní kódu. Navíc mi není jasné jak to mohlo projít testováním. Než bude stabilní verze Visual Studia 11, kde už designer seznamů je, je potřeba si na to dát pozor a doufat, že to v příští verzi MS v nějakém SP SharePointu opraví.

Extrémní velikost databáze služby Import uživatelských profilů

mazin — Mon, 20 Feb 2012 20:15:00 GMT

Před časem jsem řešil problém, kdy databáze služby Import uživatelských profilů měla velikost přes 21GB. To je na profily cca 150 členů domény poměrně dost. Začal jsem proto pátrat po tom čím by to mohlo být způsobeno a jak to vyřešit.

Prozkoumáním databáze (typicky ve svém jméně obsahuje UserProfile, její přesné jméno naleznete v konfiguraci služby Import uživatelských profilů) jsem zjistil, že drtivá většina dat se nachází v tabulce InstanceData. Tato tabulka slouží v průběhu importu. Problém je v tom, že se z ní nemažou nepotřebné záznamy z již proběhlých importů. Dokonce mezi uloženými procedurami můžete najít jednu, která se nachází ve schématu FIM a jmenuje se [TruncateInstanceData]. Je to dáno tím, že oproti předchozí verzi SP 2007, kde byl import omezen na Active Directory a byl řešen proprietárně, v SP 2010 je import řešen pomocí tzv. FIMu (Forefront Identity Manager). To je obecný nástroj pro distribuci informací z uživatelských profilů mezi různými systémy. Díky tomu může být zdrojem uživatelských informací i jiný informační systém, než jen Active Directory. Bohužel při implementaci FIMu (resp. jeho omezené části) do SharePointu došlo někde k chybě a zmíněná procedura se nevolá tak, jak by měla a nedochází k mazání již nepotřebných informací. Databáze proto roste a roste...

Řešením, které se nabízí, je ruční spuštění této procedury a její pravidelné spouštění. Protože ale procedura obsahuje jediný delete příkaz, může se vám stát, že po několika hodinách jejího běhu zjistíte, že skončila chybou a nedošlo ke zmenšení tabulky ani databáze. Je to proto, že elementární operace (např. DELETE) běží jako transakce. V průběhu transakce se vytváří log toho co se stalo, aby bylo možné případně transakci rollbackovat. Proto mazání velkého množství dat najednou vede k velkým nárokům na velikost databázového logu. Proto vám doporučuji následující:

Změnte recovery schéma z Full na Simple. Tím docílíte toho, že po dokončení transakce se jí vygenerovaná část logu smaže.
DELETE příkaz z procedury si vykopírute bokem a spouštějte několikrát za sebou s vhodnou podmínkou tak, aby množství mazaných záznamů nebylo příliš velké.
Nakonec proveďte shrink databáze. Tím se uvolní prázdné místo po smazaných záznamech a dojde ke skutečnému zmenšení databázových souborů. To uděláte např. pomocí kontextového menu databáze v MS SQL Management Studiu. Zde najdete položku Tasks -> Shrink
Přepněte recovery schéma databáze na původní hodnotu.

Protože jsem na webu narazil na informaci, že v některých databázích zmiňovaná procedura vůbec není, přikládám její podobu tak, jak jsem ji našel v mnou zkoumané databázi:

/****** Object:  StoredProcedure [FIM].[TruncateInstanceData] */
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE PROCEDURE [FIM].[TruncateInstanceData]
AS
BEGIN

--************************************************************
--*                                                          * 
--*   Copyright (C) Microsoft. All rights reserved.          *
--*                                                          *
--************************************************************
SET NOCOUNT ON;
DECLARE @truncationTime datetime;
SET @truncationTime = DATEADD(day, -1, GETUTCDATE());
DELETE FROM [dbo].[InstanceData]
WHERE ([created] < @truncationTime)
END
GO

Omezení výběru uživatelů v dialogu výběru uživatelů

mazin — Thu, 19 Jan 2012 21:30:00 GMT

Celé to začalo podivným chováním úkolů v SharePointu. Jeden uživatel (říkejme mu třeba Karel Novák) měl přiřazeno několik úkolů. O všech mu přišla notifikace, že mu byly přiřazeny, ale některé nemohl měnit z důvodů nedostatku práv. Prostředí bylo nastaveno tak, že právo měnit úkol měl pouze přiřazený uživatel a zadavatel úkolů. Zběžná kontrola úkolů neodhalila nic podezřelého. Oba zkoumané úkoly vypadaly na vlas stejně. Práva byla nastavena automatickým procesem a taky byla stejná. Tedy alespoň na první a druhý pohled. Nakonec jsem si všiml, že problém byl v tom, že není Karel Novák jako Karel Novák. I když byl ve firmě jediný. On totiž měl 2 loginy v různých doménách se stejným jménem. Díky tomu se v dialogu pro výběr uživatele zobrazoval 2x. Pokud ale zadavatel úkolu zadal přesné jméno už v dialogu úkolu a stiskl Ctrl+K tedy ověření, tak ověření prošlo. Ale který z těch dvou účtů byl vybrán, to už se zadavatel nedozvěděl.

Naštěstí s tímto problémem při vývoji SharePointu počítali, takže se dá omezit, ze kterých organizačních jednotek se mají nabízet uživatelé při výběru uživatelů.

Dá se určit organizační jednotka AD, na kterou se má omezit výběr uživatelů:
stsadm -o setsiteuseraccountdirectorypath -path "OU=Sales,DC=ContosoCorp,DC=local" –url http://ServerName

Taky se dá určit, že

při ověřování jména uživatele (tlačítko Kontrola jmen, nebo Ctrl+K) se mají brát v potaz pouze ti uživatelé, kteří mají přístup k dané kolekci webů:


          stsadm -o setproperty –pn peoplepicker-Peopleeditoronlyresolvewithinsitecollection –pv yes –url
          <Web application URL>

ve vyhledávacím dialogu (tlačítko Procházet) se mají brát v potaz pouze ti uživatelé, kteří mají přístup k dané kolekci webů:


          stsadm -o setproperty –pn peoplepicker-onlysearchwithinsitecollection –pv yes –url
          <Web application URL>

Pokud potřebujete něco sofistikovanějšího, můžete výběr uživatelů z AD omezit pomocí LDAP dotazu:
stsadm –o setproperty –pn peoplepicker-searchadcustomfilter -pv <LDAP query filter> -url <Web application URL>

Kompletní popis najdete na MSDN.

Při praktickém použití je ale nutné udělat ještě jednu věc. Samotné omezení výběru z Active Directory nestačí. Pokud totiž uživatel (resp. jeho login) už v SharePointu figuruje, např. proto, že mu byl přiřazen úkol, práva ... , je v seznamu uživatelů SharePointu. Jako takový je do výsledku vyhledávání v PeoplePickup editoru taky zahrnut, ať už výše uvedeným omezením vyhovuje, nebo ne. Proto je nutné, k tomu abyste se takového loginu zbavili uplně, odstranit ho i z tohoto "seznamu". S tím souvisí další trik. Standardně se totiž k seznamu všech uživatelů pomocí webového UI SharePointu nedostanete. Lze zobrazit jen členy určité skupiny. K tomu slouží stránka s adresou http://server/_layouts/people.aspx?MembershipGroupId=XXX. Parametrem XXX je ID té skupiny. Pokud použijete 0, dostanete seznam všech uživatelů bez ohledu na to členy jakých skupin jsou (pokud vůbec nějakých).

PerformancePoint v SharePointu 2010

mazin — Sun, 06 Nov 2011 00:00:00 GMT

Úvod

PerformancePoint funkcionalita umožnuje zobrazit uživatelům top level pohled na nejrůznější ukazatele s vizuální informací o tom, jak si který z nich stojí (dobře, špatně, tak něco mezi). Vizuálnost je řešena pomocí grafů, budíků, semaforů, různě se tvářících smajlíků a podobně. Ale tím možnosti PerformancePointu nekončí. Při napojení na Analysis Services je možné zpřístupnit v prostředí SharePointu i analytické nástroje jako analytický graf, analytickou tabulku a mapu strategie. V tomto příspěvku se podíváme na základy toho, co PerformancePoint funkcionalita v SharePointu 2010 obsahuje.

PerformancePoint byl ještě nedávno samostatný produkt. S příchodem SharePointu 2010 se z něj stala jedna ze součástí Enterprise verze. Tedy ne ze všeho, ale z většiny. Funkcionalita proClarity zůstala samostatná a její obchodní název je ProClarity server.

Nejprve je potřeba zprovoznit PerformancePoint službu a Secure Store Service. Druhá z nich je důležitá pro správu identit pod nimiž se bude přistupovat k datovým zdrojům (viz. dále)

Na úrovni kolekce webů je potřeba zapnout Publikování a Performance Point funkci. Díky tomu se vám v šablonách webů objeví Centrum Business Inteligence na němž můžete vytvářet a publikovat vše o čem si dnes budeme povídat. Taky se vám tím zpřístupní PerformancePoint webparty, které můžete umístit na jakýkoliv web a publikovat s jeho pomocí Performance Point záležitosti i jinde.

Nástrojem, kterým se PerformacePoint věci konfigurují, je Dashboard Designer (Návrhář řídících panelů). To je ClickOnce aplikace a odkaz na ní je uveden na stránce webu Centra Business Inteligence.

Datový zdroj

Určuje odkud, jakým způsobem a pod jakou identitou se budou získávat data, která se pak budou prezentovat pomocí PerformancePoint funkcionality.

Je možno definovat následující typy připojení:

Analysis Services - umožňuje čerpat data z Analysis Services SQL serveru. Spoustu pokročilé funkcionality Performance Pointu je omezena tím, že datový zdroj pro ni musí být tohoto typu.
Seznam SharePointu
SQL
Excel services
Excelový soubor

U datového zdroje si je potřeba uvědomit jednu důležitou věc, která se týká autentizace. Pokud nemáte rozchozený Kerberos, nebo zdroj dat neleží na stejném počítači jako SharePoint, nemá smysl v při nastavování autentizace používat volbu "Identita vázaná na uživatele". Důvod je v tom, že NTLM ověření se nedá delegovat dále, mimo počítač vůči kterému proběhlo.

Ukazatel (Indicator)

Definuje škálu, to znamená můžete určit popis, obrázek a barvu textu a pozadí pro až 10 "hodnocení". Například různé smajlíky, teploměry apod. Tyto škály se pak využívají pro grafické znázornění dat klíčových ukazatelů výkonu. Existují 2 druhy ukazatelů:

Standardní - jejich logika je založena na hesle: "čím větší, tím lepší". Jinými slovy řečeno. Nejlepší a nejhorší hodnota jsou na kraji škály.
ty, které mají nejlepší hodnotu uprostřed a oba "konce" představují "špatné" hodnoty.

Ukazatel sám ještě není svázán s konkrétními daty.

Klíčový ukazatel výkonu (Key Performance Indicator - KPI)

Spojuje dohromady předchozí věci a několik dalších nastavení. Určuje:

zdroje dat - jeden nebo více zdrojů dat pro zobrazení indikátoru.
skutečnost - sloupec ze zdroje dat, který reprezentuje "naměřené" hodnoty.
cíl - sloupec ze zdroje dat, nebo pevná hodnota, která představuje cíl, kterého se snaží skutečnost dosáhnout. Zdroj dat cíle může být jiný než zdroj dat pro skutečnost.
filtry - už na této úrovni můžeme definovat podle jakých kritérií bude možné hodnoty skutečnosti omezovat během analýzy dat
ukazatel
mapování vztahu skutečnosti a cíle na jednotlivé hodnoty ukazatele. Například určuje, že pokud skutečnost představuje 0 - 20% cílové hodnoty, použije se k jejímu zobrazení první "hodnota" (grafický symbol) škály ukazatele.

Klíčový ukazatel výkonu může obsahovat několik skutečností a cílů.

Filtr

Jde hodnoty z datového zdroje, které mohou být v dashboardu použity pro omezení zobrazené množiny dat. Problém je, že většinou musíte určit konkrétní hodnoty např. 1,2,3,4,5,6 a nemůžete říci: "Tento filtr bude umožňovat omezit zobrazení výsledků podle věku osoby s tím, že rozsah bude určen tím, jaké hodnoty se nachází ve sloupci "věk" datového zdroje.

Přehled výkonnostních metrik (scorecard)

První vizuální věc, tedy něco, co můžete uživatelům ukázat pomocí webpartu na stránce SharePointu. Je to vlastně zobrazení KPI, grafu,... s výběrem konkrétních metrik cílů. K zobrazení scorecard je určen webpart Přehled výkonnostních metrik serveru PerformancePoint.

Řídící panel (dashboard)

Další vizuální věc. Může se skládat ze všeho o čem jsem dosud psal. K jeho zobrazení na SharePointu ji ale musíte publikovat, nestačí to jen uložit. Jde totiž o celé stránky s webparty (scorecardy, filtry, grafy, viz. níže) a jejich propojeními. Kromě specifických PerformancePoint filtrů je možné využít i standardní SharePoint filtry. Užitečný je např. filtr aktuální osoby. To už ale neuděláte pomocí PerformancePoint Designeru. Musíte publikovanou stránku následně otevřít pomocí SharePoint Designeru.

Webparty

K zobrazení věcí PerformancePointu na stránkách SharePointu slouží následující webparty:

Filtr serveru PerformancePoint - zobrazí filtr definovaný v rámci PerformancePoint funcionality
Přehled výkonnostních metrik serveru PerformancePoint - webpart pro zobrazení scorecard
Sestava serveru PerformancePoint - zobrazuje grafy
Výběr zobrazení serveru PerformancePoint

Jak jsem se zmiňoval v úvodu, tyto webparty lze použít, při aktivaci příslušných funkcí, i jinde než na webech Bussiness Inteligence Center.

Závěr

PerformancePoint se hodí pro manažerský pohled na data. To znamená, že pohledem na teploměry klíčových ukazatelů výkonu manažer zjistí, jestli není něco potřeba řešit. Pomocí analytických možností následně může řešit, kde je zakopaný pes. PerformancePoint může pracovat nad tabulkami v SQL, seznamy SharePointu, ale většina cool funkcí je svázána s napojením na Analysis services MS SQL serveru a rozhodně se vám při práci s PerformancePointem budou zkušenosti (ať už vlastní, nebo cizí) hodit.