Mazinův blog o SharePointu

Chyba: Zkušební období pro tento produkt vypršelo.

mazin — Tue, 31 Aug 2010 13:25:00 GMT

Dnes jsem řešil další potíž s SharePointem 2007.

Projevovala se tak, že když jsem zkusil použít nějakou funkci MOSS 2007, která není součástí WSS 3.0, objevila se chybová hláška: "Zkušební období pro tento produkt vypršelo.". Proto jsem si na administračním webu ověřil, že nemám nainstalované pouze trial licenci. Neměl jsem. Pokračoval tedy v pátrání na Googlu. Ten opět nezklamal! Po chvíli hledání jsem našel pomoc. Skládala se ze 3 kroků:

Přidat do systémové proměnné PATH následující cesty:

%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Bin;
%ProgramFiles%\Microsoft Office Servers\12.0\Bin;

Nastavit práva na klíče v registrech:

pro skupinu WSS_WPG právo Čtení na klíč KEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\Office Server\12.0
pro skupinu WSS_ADMIN_WPG Úplné řízení na klíč HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\Office Server\12.0

IISRESET

Bohužel se mi nepodařilo přijít na příčinu. Dosud dotyčný SharePoint dělal co měl a už dlouho jsem na něj nic neinstaloval.

Ach těch nešťastných 64 bitů

mazin — Fri, 20 Aug 2010 11:00:00 GMT

SharePoint a Office programy spolu spolupracují, to je známý fakt. Microsoft se s každou další verzí snaží tuto spolupráci posilovat. To platí i pro nový SharePoint 2010 a Office 2010.

Proto mě na chvíli zaskočilo, když jsem zkoušel na svém vývojovém počítači použít funkci "Otevřít pomocí datového listu" a ono to skončilo chybou: "Seznam nemůže být zobrazen...". Na zmiňovaném počítači mám nainstalován SharePoint 2010x64 (jiný už ani není) a Office 2010 x64. Píšu to proto, že to zobrazení se totiž realizuje pomocí klientské ActiveX komponenty, která pochází z Office. Brzy se opravdu ukázalo, že problém souvisí s 64 bitovou verzí Office. "Zase?!" řekl jsem si. To proto, že jsem před časem řešil problém s tím, že mi nefunguje synchronizace Outlooku 2010 x64 a PDA (s Windows mobile) prostřednictvím Windows Mobile Device Center. To je totiž i v 64 bitových Windows 7 stále jen 32bitové a s 64bitovým Outlookem nespolupracuje. Musím tedy synchronizaci provádět přímo s Exchangem. I přesto ale každé připojení PDA k počítači představuje odklepnutí chybové hlášky v tom smyslu, že nemám nastaveného výchozího emailového klienta, nebo ten současný neumí zpracovat zaslaný požadavek. Naštěstí po odklepnutí se synchronizace provede bez problémů.

Ale zpět k problému se zobrazením v datovém listu. Řekl jsem si: "Aha, mám 32 bitový IE, Office je 64bitový. To on asi bude mít ten ActiveX pouze 64 bitový. Zkusím tedy 64 bitový IE.". Ale ani to nepomohlo. Nejenže to neřešilo tento problém, ale způsobilo i některé další (viz. můj dřívější příspěvek). Po chvíli hledání na Googlu jsem našel 3 řešení:

Nainstalovat 32 bitové Office
Stáhnout a nainstalovat 2007 Office System Driver for Data Connectivity Components
Nainstalovat 2007 SharePoint Services Support, která je součástí instalačního média Microsoft Office 2007

Já osobně jsem šel druhou variantou, i když objektivně asi nejlepší by byla varianta 1, protože problém 64 bitů u Office 2010 se může vynořit za chvíli zase někde jinde.:( Trochu mě mrzí, že na 64bitovém OS s 64bitovým produktem musím instalovat i 32 bitové komponentu starší verze, aby to fungovalo. V případě synchronizace Office<->PDA to zase je tak, že mám 64bitový OS, 64 bitovou aplikaci, ale klíčová komponenta toho OS je pouze 32bitová, takže si s 64 bitovou aplikací nerozumí. A to jsou všechny součásti produktem jedné firmy. A to firmy jako je Microsoft. Ach jo!

Už chápu, proč Microsoft všude píše: Instalujte si 32 bitové Office.

Problém s právy v SharePointu

mazin — Wed, 18 Aug 2010 21:20:00 GMT

Dnes jsem zase narazil na jednu "zajímavou vlastnost" SharePointu.

Týká se to práv, neboli oprávnění. Standardně se oprávnění v SharePointu, dědí tzn. oprávnění nastavená na úrovni seznamu (ale i knihovny dokumentů) se automaticky aplikují i na položky seznamu. Samozřejmě se ale dají nastavit oprávnění i na úrovni jednotlivých položek. V takovém případě se dědění přeruší a od toho okamžiku si oprávnění seznamu a dotčených položek žijí vlastním životem. Tedy mělo by to tak být... ale není.

Po čase zjistíte, že na úrovni seznamu už nemáte jen oprávnění, která jste sami nastavili, ale jsou tam oprávnění pro každého jednotlivého člověka (nebo skupinu), který má individuálně nastavená oprávnění na nějaké položce v daném seznamu. SharePoint totiž pro každého, komu je nastaveno oprávnění na úrovni položky, přidělí na úrovni seznamu oprávnění Omezený přístup. Toto oprávnění samo dotyčného neopravňuje k ničemu a SharePoint si ho tam přidává automaticky patrně z nějakého vnitřního důvodu.

Problém nastane v situaci, kdy se pokusíte oprávnění na úrovni seznamu smazat! V takovém případě se odstraní oprávnění nejen na úrovni seznamu, ale i všechna oprávnění dotčeného uživatele (nebo skupiny) ze všech obsažených položek. A to včetně těch, které mají individuálně nastavená práva.

Řešením (i když je to takové drbání levou rukou za pravým uchem) je oprávnění na úrovni seznamu nemazat, ale měnit je na oprávnění "Omezený přístup".

Představte si následující situaci:

Máme seznam úkolů. Na něm jsou nastavena oprávnění tak, že do něj mohou přidávat úkoly členové skupiny Vedení a Konzultanti. Dále nad tímto seznamem běží workflow, které se spustí při vložení úkolu. Reaguje tak, že přeruší dědění oprávnění a nastaví je tak, že skupina Vedení může úkol editovat a smazat a ten, komu je úkol přiřazen, ho může editovat. Konzultanti úkol mohou číst. Pak se rozhodnete, že konzultanti nebudou moci vkládat úkoly, takže jim oprávnění na úrovni seznamu v dobré víře odstraníte. Tím si ale nas....te do bot, protože v tu chvíli se konzultantům odeberou oprávnění čtení i ze všech úkolů.

Nejprve jsem doufal, že se toto chování týká jen SharePointu 2007, ale projevuje se stejně i v SharePointu 2010.

Kerberos a SharePoint

mazin — Fri, 13 Aug 2010 21:30:00 GMT

V jednom ze svých předchozích příspěvků jsem se dotkl autentizačního protokolu Kerberos. Dnes se mu budu věnovat podrobněji. Podíváme se především na to, jak nakonfigurovat počítač s SharePointem 2010 tak, aby pro autentizaci uživatelů využíval právě protokol Kerberos. Na úvod musím říct, že na webu je mnoho článků, které se tomu věnují, ale mnohé si protiřečí, obsahují jen část toho, co je potřeba udělat nebo obsahují chyby. Proto jsem se rozhodl to vyzkoušet a rozchodit. A řeknu vám: byl to boj.

Co to je Kerberos?

Kerberos je standardizovaný autentizační protokol vyvinutý na MIT, který Microsoft implementoval do svých operačních systémů. Podporuje ho od verze Windows 2000. Na rozdíl od protokolu NTLMv2 (nejčastěji používaný autentizační protokol ve Windows sítích) má následující výhody:

Je otevřený - jeho bezpečnost není založena na tom, že útočník neví, jak to funguje, ale na tom, že všichni ví jak to funguje a mohou bezpečnost zkoumat a chyby zveřejnit.
Je standard - jeho změna je sice možná, ale procesně dlouhá, takže se o ní pravděpodobně dozvíte dříve, než ji Microsoft implementuje. U proprietárních řešení si nemůžete být jisti, od které aktualizace jejich chování změní.
Je bezpečnější - nejenže využívá propracovanějšího schématu, ale je založen i na bezpečnějších kryptografických konstruktech.
Umožňuje delegaci - tzn. umožňuje, aby služba (v našem případě SharePoint) použila identitu uživatele a s jejím pověřením přistupovala k dalším službám. Díky tomu může zprostředkovat uživateli data (nebo funkcionalitu) ke kterým by SharePoint (resp. účet pod kterým běží) neměl přístup.

Kerberos využívá tzv. ticketů. To jsou v podstatě časově omezená potvrzení vydaná autentizačním serverem. Ty používá klient k prokazování své identity.

Blízký pojem k delegaci je pojem impersonace, který se používá častěji, hlavně ve světe ASP.NET. Někdy dochází k záměně resp. zmatení těchto pojmů, proto uvedu základní vlastnosti:

Impersonace

Služba přijme identitu volajícího (nebo taky nějakého konkrétně zadaného) uživatele.
Služba, která využila impersonaci, se tváří (předstírá), že běží v kontextu jiného uživatele.
Platnost impersonace je omezena na počítač, na kterém proces běží.
Lze ji použít jak s NTLM tak s Kerberem

Delegace

Služba běží v kontextu účtu, který ji byl přidělen.
Služba, která využívá delegace, komunikuje s ostatními službami s tím, že komunikaci provádí na základě pověření (delegace) dotyčného uživatele. To služba dokládá použitím ticketu uživatele.
Platnost delegace je omezena na služby, které mají možnost ověřit si platnost ticketu (mají kontakt s autentizačním serverem, typicky počítače v doméně) a tím, jak je možnost delegace uživatelova účtu nastavena (zda je možné jej delegovat a zda to může provést příslušná služba, viz. dále).
Tohle NTLM neumí

Rozdíl v tom, co umožňuje delegace Kerbera, ukazují následující obrázky:

Obrázky ukazují komunikaci mezi servery a účty pod nimiž komunikace/přístup může probíhat.

Nevýhody použití Kerbera vůči NTLM:

Díky propracovanosti je to složitější.
Je potřeba další konfigurace na úrovni domény i konkrétních služeb, aby to běželo.
Potřebuje ještě propustný port 88 pro vyřízení komunikace s autentizačním serverem.

Zprovoznění Kerbera

Rozchození Kerbera pro účely SharePointu se skládá z konfigurace na úrovni domény a konfigurace na služby. Konfigurace služby se v případě SharePointu skládá s konfigurace IIS serveru a SharePointu samotného.

Vytvoření SPN

Klíčovým pojmem ve světě kolem protokolu Kerberos je tzv. SPN (service principal name) do češtiny Microsoftem překládaný jako hlavní jméno služby. Kerberos ho používá jako identifikátor služeb. Službou je v tomto případě myšlen nějaký software, se kterým můžete komunikovat a který vás chce identifikovat. Proces autentizace obecně sebou nese 2 problémy:

Jak volající/uživatel prokáže, že je tím, za koho se vydává?
Jak volaný/služba prokáže, že je tím, koho chce uživatel volat a tedy ten, komu je ochoten prozradit svou identitu?

A právě druhý problém řeší SPN. V doméně existuje registr důvěryhodných služeb. Pokud se nějaká služba pokusí o autentizaci volajícího pomocí protokolu Kerberos a není v tomto registru, pokus bude automaticky neúspěšný. Pokud tedy chcete, aby vaše aplikace mohla autentizovat uživatele pomocí Kerbera, musíte mít v doméně registrované SPN. A jak takové SPN vypadá? Je to vlastně skupina následujících údajů:

protokol - HTTP, MSSQLSvc, ...
jméno počítače
číslo port - nepovinný údaj, standardní protokoly mají svá standardní čísla protokolů a proto je v SPN není potřeba uvádět
název doménového účtu, pod kterým služba běží - v našem případě se jedná o doménový účet, pod kterým běží aplikační pool webové aplikace SharePointu.

v následujícím formátu: protokol/plné jméno počítače:port doménový účet službu. Příklad http/pocitac.domena.cz:2145 domena\login

Práce se SPN se provádí pomocí příkazu SETSPN. Ten podporuje přidávání, změnu, mazání a zobrazení existujících SPN. Na manipulaci s registrovanými SPN musíte mít pochopitelně odpovídající doménová práva.

Pro potřeby SharePointu potřebujeme, aby v doméně bylo zaregistrováno SPN pro HTTP protokol, FQDN(úplné doménové jméno) počítače na němž SharePoint běží a doménový účet, pod kterým běží IIS aplikační pool SharePointu. Pokud SharePoint běží na jiném portu než 80, je potřeba do SPN přidat i číslo portu. Příklad:

SetSPN -S HTTP/Portal.vmlab.local vmlab\svcportal10App.

Pokud provozujete více SharePoint aplikací, které se liší portem, nebo doménovým jménem IIS aplikačního poolu, pod kterým běží, budete potřebovat i více SPN.

Nastavení delegace

I když je delegace úžasná věc, je potřeba být opatrný, protože to je dvousečná zbraň. Dvousečnost spočívá v tom, že uživatel si nemůže být jistý (nemá nad tím kontrolu) k čemu server jeho identitu použije. Může tedy jen doufat, že server s ní dělá to, co slibuje a nerozesílá místo toho např. spam. S tímhle rizikem naštěstí ale autoři protokolu počítali a dali správcům možnost omezit, k čemu (jakým dalším severům) může server uživatelskou identitu delegovat. Stejně tak se dá nastavit, že daný uživatelský účet nelze delegovat.

Nastavení delegace se provádí v Active Directory ve vlastnostech účtu.

Z obrázku je vidět, že delegaci lze docela pestře konfigurovat. Lze ji:

zakázat (výchozí stav)
povolit ji a omezit tak, že dotyčný účet (resp. služba běžící pod tímto účtem) ji může použít pouze ve vztahu k dalším službám používajícím Kerberos autentizaci
povolit ji a omezit tak, že dotyčný účet (resp. služba běžící pod tímto účtem) ji může použít pouze ve vztahu k službám s vyjmenovanými SPN

U uživatelských účtů se silnými právy se doporučuje zakázat možnost jejich delegace:

Konfigurace IIS

Podporu Kerbera je potřeba zapnout i zde. Ve správci IIS si vyberte webovou aplikaci SharePointu a v poté v hlavní části správce otevřete zabezpečení.

Zde můžete konfigurovat nejrůznější formy autentizace uživatelů. Nás bude zajímat windows autentizace, takže ji vyberte ze seznamu nabízených způsobů autentizace.

Poté je potřeba pomocí akce "Providers..." vybrat toho správného providera.

V nabídce je jich několik:

Negotiate
NTLM
Negotiate:LiveSSP
Negotiate:Kerberos

A tady už to začne jet z kopce. Volba NTLM je jasná. Negotiate:LiveSSP už možné méně (jedná se o autentizaci pomocí LiveID), ale tou se také nebudeme zabývat. Zbývá nám tedy Negotiate a Negotiate:kerberos. Obě varianty představují Kerberos. To označení Negotiate souvisí s autentizační metodou v rámci protokolu Kerberos. Ten totiž v rámci své definice podporuje několik metod autentizace a jednou z nich je právě metoda Negotiate. A aby to nebylo tak jednoduché, tak varianta Negotiate:Kerberos reprezentuje metodu Negotiate2, která je novější variantou Negotiate. Bohužel v IE 8 obsahuje chybu v implementaci této metody, takže ani tato varianta nepřipadá v úvahu, protože při jejím využití se uživatelé s IE 8 nepřihlásí, což ho jistě nepotěší.

Ve výsledku je vlastně pro Kerberos jedinou použitelnou variantou volba Negotiate.

V pokročilých nastaveních ještě zkontrolujeme, že je vypnutá Kernel-Mode autentizace a Extended Protection.

Konfigurace SharePointu

Na webu centrální administrace v sekci Security -> General Security -> Specify Authentication provider klikněte na jméno zóny, pro kterou chcete Kerberos nastavit. Tím se dostanete na stránku nastavení:

Poznámky a nástroje, které by se mohly hodit

Poznámky:

Jako první bych chtěl zdůraznit následující fakt. V případě lokálního přístupu ke službě se VŽDY použije NTLM autentizace. Pokud tedy chcete něco okolo Kerbera ladit, musíte přistupovat k službám po síti, nejlépe z jiného počítače.
NTLM autentizace se použije i v případě, že v URL použijete IP adresu a ne doménové jméno serveru. V takovém případě totiž není možné určit, které registrované SPN by se mělo použít. S danou IP adresou může existovat několik doménových jmen a tudíž i několik SPN.
Pro MS SQL existuje příkaz, kterým si ověříte, pomocí jakého protokolu jste aktuálně autentizováni: select auth_scheme from sys.dm_exec_connections where session_id=@@spid .Výsledek pak může vypadat nějak takto:

Nástroje:

setspn - pro manipulaci se SPN. Pomocí příkazu SETSPN -l domena\loginname můžete vypsat všechna SPN týkající se zadaného doménového účtu. Stejně to funguje i se jménem počítače:
Kerbtray.exe - je součástí Windows 2000 Resource Kitu a Windows 2003 resource kitu. Program běží v tray. Zobrazí vám Kerberos tickety, které aktuálně vlastníte.
KList - je součástí Windows 2000 Resource kitu (dá se stáhnout samostatně), nebo součástí Windows 2003 Resource kitu. Pomocí tohoto příkazu (je to program příkazové řádky) si můžete nechat vypsat aktuálně vydané tickety.
Fiddler - dokáže zachytit a zobrazit komunikaci prohlížeče s okolím. Tedy i tu která souvisí s Kerberem.
Network Monitor - zachytává data na úrovni TCP. Nízkoúrovňové ladění.
Dalším užitečným zdrojem informací o tom, co se ohledně Kerbera děje, je Event log. Je potřeba ale zapnout podrobnější logování Kerberos událostí. To uděláte pomocí úpravy registrů. Popis najdete zde.

Další zdroje:

Configuring Kerberos Authentication for Microsoft SharePoint 2010 Products - dokument ve wordu
Configure Kerberos authentication (SharePoint 2010) - článek na TechNetu
Troubleshoot Kerberos Errors - dokument ve Wordu. Vysvětluje chybové kódy Kerbera, které najdete v Prohlížeči událostí, a popisuje v čem může být problém.

Závěr

Autentizace uživatelů pomocí protokolu Kerberos má smysl pouze v případě, že chcete využít některou z jeho vlastností, kterou má navíc oproti NTLM. V ostatních případech nevidím, vzhledem k nutnému úsilí na rozchození, jeho použití jako účelné.

Nejčastěji využívanou je schopnost delegace, tzn. že SharePoint je schopen použít identitu uživatele k tomu, aby přistoupil k dalšímu systému (službě).

Druhým scénářem, který využívá výhody delegace, je situace, kdy nějaká stránka v SharePointu zobrazuje údaje z dalšího systému podle toho, který uživatel se na stránku dívá (a podle toho jaká má v daném systému práva).

Oba scénáře se potkávají při integraci SharePointu s Reporting Services MS SQL serveru, kdy SharePoint zobrazuje report umístěný na ReportServeru a ten report zobrazuje data, na která má uživatel práva, získaná z dalšího serveru.

Potíž s Internet Explorerem

mazin — Tue, 20 Jul 2010 11:00:00 GMT

Dnes pro Vás mám malou hádanku: Najděte na následujícím obrázku 2 rozdíly.

Docela jednoduché, že. To zajímavější ale bude přijít na to proč. Jedná se totiž o 2 současně spuštěná okna Internet Exploreru zobrazená vedle sebe v rámci jedné session na terminálovém serveru. Operační systém je Windows 2008 Enterprise x64 SP2 v české lokalizaci. V obou oknech je zobrazeno menu Akce stejné knihovny dokumentů na stejném webu SharePointu 2007. Přihlášený uživatel byl rozpoznán automaticky a je také stejný. Na první pohled je tedy vše stejné, až na ten výsledek, že.

Rozdíl je v tom, že pravé okno je 64bitovou verzi IE, zatímco levé okno je 32bitový IE. Funkce "Zobrazit pomocí Průzkumníka ..." je realizována pomocí technologie webDAV (více se o ní můžete dočíst zde). K jejímu využití je potřeba webDAV klient. V 64 bitových windows 2008 (ve Windows 7 také) evidentně funguje pouze jeho 32bitová verze. Stejné je to klientem funkce "Zobrazit v datovém listu", protože ani ta není realizována pomocí HTTP a HTML. Po tom, co jsem tady napsal, asi nikoho nepřekvapí, že odkaz na IE v panelu Snadné spuštění v 64 bitových systémech odkazuje na 32bitový IE. Pozor jen na aktivní uživatele, kteří si vytvoří vlastní odkaz a nasměrují ho na IE v adresáři C:\Program Files\Internet Explorer a ne na C:\Program Files (x86)\Internet Explorer.

Ještě poznámka na závěr. Stejného efektu (jen jinak vizuálně prezentovaného) samozřejmě dosáhnete i s SharePointem 2010 a jinými 64bitovými Windows.

Screencast na MSTV.cz

mazin — Mon, 28 Jun 2010 11:24:00 GMT

Tentokrát udělám vyjímku a tento příspěvek bude na neodborné téma. V podstatě jde o reklamní sdělení, ale protože budu dělat reklamu sám sobě, tak doufám, že mi to odpustíte. Dnes mi vyšel 1. příspěvek na webu MSTV.cz. Příspěvek najdete zde: Vývoj jednoduchého webpart pro SharePoint 2010. Další budou doufám následovat (v šuplíku mám schované 3).

Reporty v SharePointu 2010

mazin — Sat, 26 Jun 2010 21:59:00 GMT

Novou vlastností MS SQL 2008 R2 je možnost zpracovávat reporty nad daty uloženými v seznamech SharePointu (2007 i 2010). Jak to udělat můžete vidět například na webu MSTV. Já jsem šel o něco dál. Zprovoznil jsem následující sestavu: SQL Server 20087 R2 + Reporting Services v tzv. integrated módu a SharePoint 2010 jako úložiště reportů a místo jejich zobrazení.

Integrace Reporting Services a SharePointu 2010

Postupoval jsem následovně:

Nainstaloval jsem SQL server 2008 R2 včetně Reporting Services (dají se doinstalovat dodatečně). V instalačním kroku, který se týkal konfigurace reporting Services jsem zvolil možnost, že je nebudu konfigurovat nyní. Další 2 možnosti byly: Native mode (weby pro správu a zobrazování reportů si spravují Reporting Services samy) a Integration Mode (integrace s SharePointem, to je sice můj cíl).
Nainstaloval jsem SharePoint 2010 a pro uložení databáze jsem využil SQL server z kroku 1.
Pomocí ReportingServices Configuration Management nástroje jsem:

určil účet, pod kterým má služba Reporting Services běžet. Použil jsem stejný účet, pod kterým běží SQL server.
vytvořil databázi Report Serveru
nastavil web service URL a Report Manager URL vytvořením webových aplikací na IIS serveru nainstalovaném na stejném stroji jako ten SQL
nakonfiguroval Reporting services do Integrated modu.

Na SharePoint 2010 jsem nainstaloval SQL Server 2008 R2 Reporting Services Add-in for Microsoft SharePoint Technologies 2010. Ten vám umožní konfigurovat nastavení spolupracujících Reporting services, ale také nainstaluje webpart pro zobrazení reportů (Report Viewer) a typy obsahů věcí využitelných v reportech (Report Builder Model a Report Data Source) a pro reporty samotné (Report Builder Report).
Aktivoval jsem vlastnosti Report Server Integration Feature a Report Server Central Administration Feature na webu centrální administrace
Provedl jsem konfiguraci na straně SharePointu v administračním webu (v sekci General Application Settings):

Integrate a Report Server - sem jsem vložil jméno serveru hostujícího reporting services a určil jméno instance. To umožní report serveru přístup k databázi SharePointu, aby mohl Report Server získat informace nutné zpracování reportů uložených v SharePointu (přístup k reportu samotnému, ke sdíleným datovým zdrojům a datasetům).
Reporting Services Integration - na této stránce jsem nastavil web service URL report serveru z bodu 3.3. Taky je zde potřeba určit pod jakým účtem se bude přistupovat Report Serveru. Můžete určit konkrétní účet, nebo povolit windows autentizaci. Druhá možnost naráží na omezení NTLM (více v kapitole Bezpečnost při zobrazení reportů).
Reporting Services Server Defaults - zde jsem jen zkontroloval a nechal jsem výchozí hodnoty. Nastavují se zde věci jako timeout, možnost stažení Report Builderu... Ty se dají ovlivnit na úrovni jednotlivých webů SharePointu.

Vytvořil jsem knihovnu pro datové zdroje a přiřadil jsem k ní typy obsahu Report Builder Model a Report Data Source
Vytvořil jsem knihovnu dokumentů pro reporty a použil jsem v ní typ obsahu Report Builder Report.
Vytvořit jsem zkušební report - zkušenosti jsem shrnul v kapitole Vytváření reportů
Na, k tomu účelu vytvořenou, stránku umístit webpart pro zobrazení reportů (Report Viewer) a nastavil jsem jeho vlastnosti. Především jsem určil report, který se má zobrazit, a jeho parametry.

Bezpečnost při zobrazování reportů

Bezpečnost v reportech je komplikované téma. Je zde celá řada služeb a jejich účtů, které se v procesu generování reportu využívají. Pokud to zkombinujeme s SharePointem, je jich ještě o 1 více.

Navíc existují 2 základní scénáře pro informace zobrazené v reportu:

Chci, aby report zobrazoval informace z dat, k nimž má práva uživatel, který si report prohlíží. Tento scénář se hodí tehdy, pokud chci mít 1 report, jehož výsledky jsou závislé na tom, jaká práva má uživatel v systému obsahujícím data. Např. report prodejů. Když si ho zobrazí obchodník, vidí report, ze svých prodejů. Když si ho zobrazí vedoucí obchodníků, který má právo číst data o prodejích jednotlivých obchodníků, vidí souhrnná data za všechny. K realizaci tohoto scénáře potřebuji, aby se identita koncového uživatele dostala až do systému obsahujícího zdrojová data.
Chci, aby report zobrazoval informace z dat, ke kterým uživatel, který si report prohlíží, přístup nemá. V tomto scénáři chci zpřístupnit uživateli souhrnná data bez toho, aniž by měl uživatel přístup ke zdrojovým datům. Příkladem může být report dostupný všem obchodníkům, který zobrazuje klíčové ukazatele obchodního oddělení (např. sumu realizovaných prodejů), aniž by jednotliví obchodníci měli přístup ke všem údajům o prodejích. Řešením je použít vyhrazený účet, který je součástí definice datového zdroje použitého v reportu.

Obvykle se využívá druhého scénáře a to hned ze několika praktických důvodů:

První scénář předpokládá, že systém, který report zobrazuje, je schopen předat identitu uživatele, který si report prohlíží, do Reporting Services. Ty pak následně musí být schopny použít tuto identitu tak, aby pod ní přistoupily ke zdrojovým datům reportu.
V systému, který obsahuje zdrojová data pro report musím řídit přístup jednotlivých uživatelů reportu. To obvykle bývá spojeno s velkou administrativní náročností, a proto se nejčastěji založí 1 účet, který má přístup k datům potřebným k vygenerování příslušného reportu a práva jednotlivých uživatelů se neřeší. Navíc často systémy používají vlastní systémy identit.
MS SQL, jako nejčastějším zdroji dat pro Reporting Services, neumí řídit přístup k jednotlivým řádkům tabulek. Umí řídit přístup pouze k celým tabulkám a sloupcům v nich. Protože ale reporty obvykle zobrazují data z konkrétních tabulek a jejich sloupců, tak se skutečnost, že k nim daný uživatel nemá práva, projeví nejčastěji tak, že report nejde vygenerovat. Tudíž nemá smysl práva pro jednotlivé uživatele řešit.
NTLM, což je standardní autentizační protokol používaným při Windows autentizaci, neumí delegovat bezpečnostní token dále (a tedy neumí předat identitu uživatele předat dále, viz. bod 1).

Pokud ale zdrojem dat pro report je SharePoint, tak nám odpadají důvody č. 2 a 3. Stále nám ale zbývají body 1 a 4 byť spolu souvisí. Řešením je využití autentizačního protokolu Kerberos. Pár detailů můžete najít např. zde. Blíže si o něm a jeho zprovoznění v SharePointu, Reporting Services, MS SQL povíme jindy.

Vytváření reportů

Při vytváření reportů hostovaných v SharePointu a pracujících s daty z SharePointu jsem narazil na následující komplikace:

Visual Studio 2008 neumí vytvořit report založený na SharePoint datech. Je to proto, že nepodporuje dotyčný datový zdroj. To se dá obejít tím, že jako zdroj použijete webovou datovou službu http://server/_layouts/lists.asmx. Použití WCF jako zdroje dat ale má problém v tom, že neumožňuje zadat uživatelský účet, pod kterým má být přístup k datům (volání webové služby) proveden. Jedinou možností je Windows autentizace, nebo přístup bez hesla. Problém použití Windows autentizace je diskutován výše (bez rozchozeného Kerbera je to k ničemu).
Visual Studio 2010 se sice tváří, že vytvářet reporty založené na datech v SharePointu umí, ale díky chybě, kterou obsahuje, to neumí. Problém je v tom, že sice mezi datovými zdroji SharePoint je, ale kliknutím na tuto možnost se vám zobrazí stejný dialog, jako při konzumaci dat z webové službu.
Jedinou fungující možností tedy je použít Report Builder 3.0, ale ani s ním to není bez komplikací. S jeho pomocí se nedají vytvářet sdílené datové zdroje. Dají se vytvářet pouze zdroje lokální (jsou součástí reportu), nebo konzumovat sdílené. Sdílené datové zdroje a datasety, jsou takové, které nejsou součástí reportu, ale jsou uloženy samostatně v knihovně dokumentů a report se na ně pouze odkazuje. Jejich použití je doporučené, protože je můžete použít v několika reportech a případnou změnu související s přesunem datového zdroje provedete jen jednou. Navíc můžete řešit práva přístupu k jednotlivým zdrojům dat. Sdílené zdroje dat můžete vytvářet prostřednictvím UI SharePointu pomocí typu obsahu Report Data Source.
Konzumace dat z SharePointu je problematická, protože obvykle se v reportu zobrazují data z několika navzájem provázaných tabulek (v případě SharePointu seznamů nebo knihoven dokumentů). Spojení těch tabulek se ale realizuje na úrovni reportu obtížně a komplikovaně. Při přístupu k datům v SQL se to proto řeší obvykle tak, že report nepřistupuje přímo k jednotlivým tabulkám, ale k view, které spojení (join) provede na databázové úrovni. To však v případě dat pocházejících z SharePointu nelze, protože není jak definovat SharePointí ekvivalent onoho view.

Záludnosti využití InfoPath formulářů publikovaných na SharePoint

mazin — Fri, 18 Jun 2010 12:15:00 GMT

InfoPath umožňuje publikovat formuláře na SharePoint a rovněž umí odesílat vyplněná data do SharePointu. To se dobře hodí pro různé žádanky a podobné věci. Údaje z vyplněného InfoPath formuláře se totiž dají propagovat do vlastností typu obsahu, který se při publikaci na SharePoint vytvoří. Výsledkem pak je, že máte formulář, který si uživatel otevře a vyplní. Když dá Odeslat, data se uloží do určené knihovny, která má přiřazený odpovídající typ obsahu (vzniklý při publikaci). Díky propagaci vlastností může nad vyplněnými daty běžet workflow, které např. osobu uvedenou ve formuláři vyzve ke schválení a podobně.

Díky použití InfoPath formulářů máte k dispozici bohatší uživatelské rozhraní pro získávání dat od uživatelů. Musí ale mít nainstalovaný lokální InfoPath. Tato podmínka se dá obejít tím, že šablonu vytvoříte a publikujete jako webový formulář. To má ale na druhou stranu omezení ve funkčnosti formuláře a v tom, že to nepodporuje "bezplatné" WSS, dokonce ani MOSS, ale až MOSS Enterprise.

V průběhu používání InfoPath formulářů ve spojitosti s SharePointem jsem narazil na 4 momenty hodné zřetele:

Vícenásobná publikace

Pokud publikujete jeden formulář na 2 místa (např. na testovací server a ostrý) a potom v něm provedete změnu a opět ho publikujete na původní místo, máte problém. V typu obsahu, který InfoPath v průběhu opakované aktualizuje se vám "zdvojí" sloupce. Vypadá to tak, že v seznamu, kam se data ukládají, jsou např. 2 sloupce s názvem "Cena" (tzv. display name). Oba mají různý static name, typicky cena a cena1. Bohužel mnoho funkcí (včetně workflow) v SharePointu pracuje právě s Display name (tedy to, co vidí uživatel). Navíc se tento problém projevuje i tak, že stará data (ta, která byla uživateli vyplněna před aktualizací) jsou v původních sloupcích a nově vložená data se ukládají do nových sloupců. Do nových sloupců se ukládají i přeuložená data (taková, která sice vznikla před aktualizací, ale byla změněna pomocí šablony po aktualizaci). Zmatek v datech mají nejen uživatelé, kteří v seznamu vidí 2 stejně pojmenované sloupce, z nichž jeden obsahuje informace vyplněné do okamžiku aktualizace, a druhý, který obsahuje informace vložené nebo změněné po aktualizaci formuláře. Stejný problém mají i workflow. Problém je způsobený tím, že při publikaci se do formuláře (nejen do kopie, která se umístí na SharePoint, ale i do formuláře, který vás InfoPath donutí uložit během publikace) ukládají GUIDy jednotlivých polí. Děje se to při vytváření typu obsahu a tyto GUIDy se později používají při opakované publikaci šablony (aktualizaci). Během publikace totiž InfoPath kontroluje, jestli GUID prvku formuláře odpovídá GUIDu některého ze sloupců publikovaného typu obsahu. Jestliže ne, vytvoří v typu obsahu sloupec a vygeneruje mu GUID. Když existuje, aktualizuje jeho definici. Pokud ale publikujete formulář na server A, získáte 1. sadu GUIDů. Pak ho publikujete na server B a máte druhou sadu. Pak ho publikujete opět na server A máte za krkem "dvojitého Nelsona"! GUIDy ve formuláři totiž neodpovídají GUIDům v typu obsahu, a proto je do typu obsahu přidána ještě jedna sada úplně stejných sloupců. Potíže jsou navíc umocněny tím, že s typy obsahu, které vzniknou v průběhu publikace, nemůžete prakticky nic dělat (s vyjímkou jejich použití v knihovně dokumentů a jejich odstranění).

Workflow nad vyplněnými daty

Workflow pracující nad těmito položkami mají zvláštní chování. Projevuje se to tak, že workflow reagující na změnu je spuštěno tolikrát kolik je datových položek ve formuláři. Workflow napsané ve Visual Studiu, které je spouštěno vložením dat, musí nejprve počkat (pomocí delay aktivity), protože jinak jsou hodnoty vlastností prázdné. Z obou těchto projevů se dá usuzovat na to, že po uložení vyplněných dat na server se zřejmě spustí asynchronní proces, který postupně z XML dat zjišťuje hodnoty elementů mapovaných do typu obsahu. Tyto hodnoty pak ukládá do sloupců odpovídající položky. Díky tomu jsou hodnoty sloupců bezprostředně po vložení prázdné a dojde k několikanásobné aktualizaci položky.

Otevírání pomocí prohlížeče

Také jsem narazil na následující problém. Zapnul jsem na MOSSu Enterprise funkce a najednou se InfoPath data začala otevírat na webu. Samozřejmě to dopadlo špatně, protože šablona nebyla vyvíjena jako webová. Navíc ani v konfiguraci InfoPath services nebylo nastaveno, že by se ta šablona měla zpracovávat na webu. Zjišťoval jsem příčinu a zjistil jsem, že při HTTP žádosti je klient přesměrován na stránku MOSSu, která má na starosti zobrazení webových InfoPath šablon. Zatímco do té doby bylo klientovi vráceno XML vyplněných dat. Nicméně se stále dala požít volba "Zobrazit pomocí aplikace Microsoft Office InfoPath" z kontextového menu. Prozkoumal jsem tedy, jak to dělá a přišel jsem na to, že URL odkazu na vyplněná data je potřeba rozšířit o parametry "OpenIn=PreferClient" a "NoRedirect=true", které zajistí, že se data budou vždy otevírat pomocí klientského programu InfoPath. Takže výsledné URL, pokud chcete, aby se vyplněná data vždy otevírala pomocí klientského InfoPathu, musí vypadat nějak takto: http://server/web/vyplnenadata/zaznam.xml?OpenIn=PreferClient&NoRedirect=true.

Přidávání/mazání datových prvků z formuláře

Smažete-li při aktualizaci šablony nějaký datový prvek, máte problém. Data vyplněná v předchozí verzi šablony nepůjdou s pomocí nové otevřít. Obráceně (přidávání polí) to funguje dobře. Takže pokud šablonu rozšíříte, nebo funkčně či vzhledově obohatíte, většinou vám pomocí nové verze půjdou otevřít i stará data. Na šablonu je potřeba se dívat jako na definici dat (ekvivalent XSD), funkční logiky a vzhledu. Pokud je šablona kompatibilní na úrovni definice dat, je to v pořádku. Musíte si ale dát pozor pokud nad vyplněnými daty máte workflow. To musí být připraveno na to, že v tom nově přidaném sloupci nic nebude. Workflow totiž bude zpracovávat i záznamy vyplněné před úpravou.

Problém s přidáním doménového uživatele do skupiny

mazin — Sun, 13 Jun 2010 21:05:00 GMT

Tak jsem zase narazil na jednu "zajímavou vlastnost" SharePointu 2007 (resp. WSS 3.0). Tentokrát se týká práce se skupinami v SharePointu a doménovými uživateli (alespoň podle informací na webu se problém týká pouze jich).

Projevuje se následovně: V doméně se vám objeví nový uživatel a vy jej chcete přidat do některé ze skupin, které máte v SharePointu vytvořené. Když se o to pokusíte, objeví se vám chyba "Operace přerušena". Aby to nebylo tak jednoduché, dochází k tomu u skupin, které mají větší počet uživatelů (cca více než 100, alespoň tedy podle mých experimentů).

Řešení je v nastavení proměnné SQL spojení XACT_ABORT na OFF. Protože nejsme schopni ovlivnit parametry spojení do SQL databáze, které SharePoint vytváří, musíme nastavit na SQL serveru výchozí hodnotu této proměnné pro všechna spojení. To může být problém, pokud dotyčný SQL server hostuje databáze i jiných systémů. Proměnná XACT_ABORT totiž výrazně ovlivňuje reakci SQL serveru na chyby, které nastanou při zpracování SQL příkazů.

Více se o tom můžete dočíst na webu MSDN. Ve stručnosti jde o to, že pokud je hodnota nastavena na ON a při zpracovávání některého z příkazů transakce dojde k chybě, tak je ukončena s chybou (ROLLBACK) celá transakce. V případě nastavení hodnoty na OFF, vyhodnocuje SQL závažnost chyby a celou transakci ukončí s chybou jen v závažných případech. V ostatních případech pokračuje SQL dál ve zpracovávání příkazů transakce, jen nastaví hodnotu systémové proměnné @@ERROR po provedení inkriminovaného příkazu. Po něm následující příkazy tak na neúspěch mohou reagovat.

Instalace SharePointu 2010 na Window 7

mazin — Thu, 03 Jun 2010 21:11:00 GMT

Jednou z novinek SharePointu 2010 je možnost nainstalovat ho na klientské OS jako jsou Windows 7 nebo Windows Vista. To je určeno především vývojářům, kteří dosud museli vyvíjet ve virtuálním stroji hostovaném na svém počítači, nebo museli jako primární OS používat některý ze serverových Windows. Obě varianty mají svoje mouchy.Protože SharePoint 2010 je 64bitový, musí být 64bitový samozřejmě i ten OS, na který ho chcete nainstalovat. Pokud to ale zkusíte bez přípravy, hned při spuštění instalace dojde k chybě v tom smyslu, že instalace na tomto typu operačního systému to nepůjde.

Na internetu jsem našel několik článků, které popisovaly jak to udělat včetně jednoho na MSDN. Většina z nich se vztahovala k beta verzím a neodpovídají dnešní situaci. Ten článek na MSDN, taky (i když se tváří, jako že se vztahuje k RTM verzi), nicméně se z něj dá vyjít.Já jsem to zkoušel na Windows 7. Na počítači jsem měl nainstalované Visual Studio 2010 a SQL server 2008 R2, protože už na něm vyvíjím jiné aplikace. Dále jsem postupoval takto:

Nejprve jsem nainstaloval hotfixy, o kterých se v článku hovoří:
- Microsoft FilterPack 2.0 je na instalačním mediu X:\PrerequisiteInstallerFiles\FilterPack\FilterPack.msi
- Microsoft Sync Framework
- SQL Server Native Client
- Windows Identity Foundation (Windows6.1-KB974405-x64.msu)
- Chart Controls (není prý potřeba, pokud instalujete SharePoint Foundation 2010. Neoveřoval jsem to, instaloval jsem SharePoint Server 2010)
- SQL Server Analysis Services - ADOMD.Net (není prý potřeba, pokud instalujete SharePoint Foundation 2010. Neoveřoval jsem to, instaloval jsem SharePoint Server 2010)
- KB971831
- KB976127
Nakopíroval jsem instalační medium na disk, protože bude nutné upravit některé instalační soubory.
Upravil jsem instalační config.xml soubor. Stačí do něj přidat element <Setting Id="AllowWindowsClientInstall" Value="True"/>. Na rozdíl od zmíněného článku jsem u média, které jsem měl dispozici, nemusel rozbalovat instalační soubor. Stačilo jen upravit config soubor, který byl v adresáři /files/..... (je tam několik podadresářů, které odpovídají různým režimům instalace)
Zkontroloval jsem instalaci komponent OS, které jsou v článku zmíněny (především komponenty webového server a jeho managementu). Bohužel skript, který je v článku, a který by měl instalaci provést, nefunguje.
V prvním kroku instalace je možnost zkontrolovat a nainstalovat prerekvizity. Tato možnost, ale bohužel ani po úpravě config souboru nefunguje a skončí hned po spuštění chybou.
Spustil jsem instalaci. Díky úpravě config souboru neskončila chybou.
Zahájil jsem instalaci SharePointu 2010.
První krok, který se objeví, obsahuje tlačítka Standalone a Server Farm. Ta jsou bohužel špatně otextovaná a jejich skutečný význam je úplně jiný. Standalone by se správně mělo jmenovat Default, protože spustí instalaci bez dalších dotazování. Server Farm tlačítko by se mělo jmenovat Custom, protože vede k tomu, že v dalším kroku umožňuje určit další parametry instalace.
Druhý krok instalace. Zobrazí se opět 2 tlačítka. Stand-alone (instalace webové části SharePointu a SQL serveru 2008 Express najednou) a Complete (instalace pouze webové části SharePointu). Tentokrát už jsou správně pojmenované, ale doplňující komentáře jsou podle mě zavádějící. Stand-alone totiž provede instalaci všeho, co k běhu potřebujete (tedy i SQL serveru), zatímco Complete provede jen instalaci webové části a předpokládá, že SQL server vyřešíte jinak. Nicméně poznámka, že Complete varianta je určena k instalaci farmy je správná.

Další komplikace, na kterou jsem narazil, se týká průvodce nastavení SharePointu 2010 (SharePoint 2010 Product Configuration Wizard). Spočívá v tom, že pokud nainstalujete SharePoint jako farmu (viz. výše), musíte pro přístup do databáze použít doménový účet. Problém tedy budete mít v případě, že chcete nainstalovat nejprve SQL (a použít ho i pro jiné aplikace) a potom SharePoint 2010 na počítač, který není v doméně. O nutnosti použít doménový účet se ale dozvíte až během průvodce. V tu chvíli však už nemůžete změnit režim instalace, takže vám nezbývá než SharePoint 2010 odinstalovat a nainstalovat ho znovu tentokrát v režimu Standalone.

Upřímně řečeno jsem z toho v rozpacích. Na to, že to má být (a je) výrazné vylepšení pro vývojáře, je cesta k výsledku pěkně trnitá. Nevím, jestli je to instalačním mediem, které jsem měl k dispozici, nebo to má být úvodní test s tím, že kdo není schopen to nainstalovat, nemá co vyvíjet pro SharePoint.

P. S. Poté, co jsem to otestoval a na administračním webu rozchodil všechny dostupné aplikační služby, z 4BG paměti mi zbylo v klidu necelých 400MB volných, to na Visual studio 2010, několik IE a další nástroje a pomůcky nestačí. Doporučuji tedy, po seznámení se se službami, ty co nebudete pro vývoj potřebovat vypnout, nebo si pořídit více paměti.

Potíže se vzorci ve WSS a MOSSu

mazin — Mon, 24 May 2010 14:45:00 GMT

SharePoint umí pracovat se vypočítanými hodnotami, resp. vzorci. Syntaxe je podobná vzorcům, které znáte z Excelu.

Lze je použít dvěma způsoby:

definovat jejich pomocí výchozí hodnotu nějakého sloupce. Nemůže se ale odkazovat na ostatní sloupce. Užitečné v případě, že chcete použít "konstant" jako je aktuální datum a čas, nebo aktuální uživatel.
vytvořit vypočítaný sloupec. V jeho definici se pak určí vzorec, který určuje hodnotu tohoto sloupce na základě hodnot jiných sloupců v záznamu. Zde pro změnu nemůže použít aktuální datum a čas nebo aktuálního uživatele.

Výpočty mají i další omezení. Za to největší považuji skutečnost, že se nedají použít se systémovými sloupci, např. se sloupcem Nadpis (Title). Tento sloupec je specifický tím, že je s ním v seznamových zobrazeních svázáno kontextové menu položek tzv. ECB a kliknutím na něj se zobrazí detail záznamu. Problém je v tom, že občas slovo Nadpis působí hloupě. Představte si např. evidenci lidí. Máme tam sloupce jako: jméno, příjmení, titul atd. Ale abychom zachovali standardní chování musí seznam mít ještě sloupec Nadpis. Ten se dá sice přejmenovat (např. na "Úplné jméno"), jenže co do něj psát? A jak? Nutit uživatele, aby tam v podstatě opsal ještě jednou důležité údaje ze záznamu je hloupost. Ideální by bylo, aby se tam zřetězily (nebo jinak spojily) ony důležité údaje automaticky. V našem případě by asi bylo fajn, kdyby tam byl "titul jméno příjmení". A tady by se hodila vypočítaná hodnota, jenže ouha: sloupec Nadpis nemůže být vypočítaný. Může mít sice výchozí hodnotu, jenže ta zase nemůže vycházet z hodnoty jiného sloupce, takže se to musí řešit event handlerem, nebo workflow. Problém je v designu. Vypočítaný sloupec totiž není nějaký příznak sloupce, ale je to samostatný datový typ.

Aby to ale nebylo tak jednoduché, nachystali pro nás v MS ještě jedno překvapení. Počeštili totiž i jména funkcí, které se ve vzorcích dají použít. To samo o sobě nezní tak tragicky, konečně SharePoint se snaží být přívětivý i k těm uživatelům, kteří nejsou zrovna zběhlí v programování a angličtině. Má to ale 2 háčky:

Pokud seženete nějaké vzory, triky a podobně na anglických webech, musíte pak nalezené výrazy "přeložit". K tomu by vám měla posloužit dokumentace.
Mizernou dokumentaci českých výrazů na weby Microsoftu - Protože neexistuje seznam funkcí, máte k dispozici pouze seznam příkladů. V něm jsou ale chyby. To v kombinaci s naprosto nicneříkající chybou, kterou vám SharePoint vrátí, pokud zadáte výraz špatně, tvoří slušný základ pro dlouhé zimní večery.

K bodu 2 (seznam příkladů naleznete zde - http://office.microsoft.com/cs-cz/sharepointserver/HA101054791029.aspx?pid=CH101760291029 ) můžu uvést 2 příklady za všechny:

Funkce DATUM (a nejen ona) je uváděna s čárkou jako oddělovačem parametrů - skutečný oddělovač je středník.
V sekci "Kombinace textu s datem nebo časem" se dočtete, že když chcete do textu dostat z data rok, musíte do formátovacího řetězce dát písmeno r. Není tomu tak! Je to písmeno y. Tady šli překladatelé dokumentace ještě dál, než programátoři, kteří přeložili "jen" jména funkcí. Překladatelé přeložili i parametry. Naštěstí pro dny a měsíce to v češtině a angličtině vychází stejně (d,m). Jen ty roky (y, r) v tom falírují.

K dobru je potřeba vývojářům SharePointu přičíst to, že pokud vzorec napíšete česky (nebo jiným jazykem), v definici seznamu se uloží anglicky. Díky tomu můžete potom seznam uložit jako šablonu a použít i na webu s jiným jazykem. Přenášení šablon mezi různými jazykovými verzemi SharePointu není úplně přímočarý proces, ale jde to.

Zvláštní chyba při použití typu obsahu odvozeného od typu složka

mazin — Tue, 11 May 2010 19:45:00 GMT

Dnešní "vlastnost" mě opravdu "pobavila".

Narazil jsem na ni při práci s typy obsahu v knihovně dokumentů. Vytvořil jsem si typ obsahu webu odvozený od typu Složka (říkejme mu např. "Moje složka") a přidal jsem do něj nepovinný sloupec webu typu vyhledávání odkazující se do dalšího seznamu. Tomuto sloupci můžeme říkat třeba "Ukazovák". Taky jsem si vytvořil další typ obsahu webu, tentokrát odvozený od typu obsahu Dokument (nazval jsem ho "Můj dokument") a v jeho definici použil opět "Ukazovák".

Oba typy obsahu jsem použil v knihovně dokumentů. Pomocí menu Nový jsem do ní vložil nový dokument typu "Můj dokument". Pak jsem vytvořil složku typu "Moje složka" s názvem Test A, ale sloupec Ukazovák jsem nechal prázdný. Pak jsem pomocí příkazu "Upravit vlastnosti" upravil hodnotu sloupce "Ukazovák" složky "Test A" tak, že jsem pomocí dropdownu zvolil položku z odkazovaného seznamu se jménem "Pokus" a stiskl tlačítko Uložit.

A pak už jsem jen nechápavě koukal! V seznamovém zobrazení jsem viděl položku s Názvem "Test A", která měla ve sloupci "Ukazovák" hodnotu "Test A". Když jsem na ni kliknul, dostal jsem se dovnitř složky "Test A" (přestože sloupec byl definovaný jako odkaz do jiného seznamu). To byl ale WOW efekt! Když jsem použil "Upravit vlastnosti" nebo "Zobrazit vlastnosti", zobrazily se správné hodnoty, tedy "Pokus". Zkusil jsem totéž s vloženým dokumentem, ale hodnoty jeho sloupce "Ukazovák" se všude zobrazovaly správně. Přejmenování složky vedlo i k úpravě hodnoty sloupce "Ukazovák" v seznamu.

A teď: Babo raď! Po nějaké době pátrání a nikam nevedoucích pokusů jsem zjistil, že "chyba" byla v definici sloupce webu "Ukazovák". Při jeho vytváření jsem nastavil, že zobrazovanou hodnotou má být: "Nadpis (odkaz na položku)". To způsobovalo toto podivné chování. Když jsem definici upravil a dropdownu vybral "Nadpis", vše začalo fungovat.

Problém s BlobCache

mazin — Mon, 19 Apr 2010 21:52:00 GMT

BlobCaching je užitečná funkce SharePointu, která umožňuje odlehčit databázovému serveru a urychlit přístup k souborům sdíleným pomocí SharePointu. Dá se zapnout ve web.configu a ukládá soubory, jinak uložené v databázi obsahu, na disk webového serveru. Díky tomu je pak přístup k nim rychlejší. Další detaily najdete např. zde.

S úspěchem jsme BlobCache využívali až do okamžiku, kdy uživatelé začali hlásit, že v našich stránkách se nezobrazují obrázky. Začal jsem pátrat po příčinách problému. Nejprve jsem zkontroloval, že soubory obrázků jsou v příslušné knihovně dokumentů. Byly tam a byly u nich zobrazeny i náhledy. I práva byla nastavena správně. Když jsem se ale pokusil daný obrázek zobrazit, nastal problém v podobě oblíbené chybové hlášky "Operaci nelze dokončit". V eventlogu ani v logu SharePointu nic nebylo. Napadlo mě, že by to mohlo být způsobeno zapnutou publikací (ta nám už pár horkých chvil připravila), ale na dotyčném webu byla vypnutá. Pátral jsem proto dále a uvědomil jsem si, že se to týká jen obrázků, ale ne ostatních dokumentů. To mě přivedlo na stopu BlobCache a když jsem si ještě zapnul debug výpisy bylo jasno. SharePoint padal ve funkci Microsoft.SharePoint.Library.SPRequestInternalClass.GetAllAclsForCurrentSite, která se, podle jejího názvu, snažila získat všechny Access Control List (seznam práv k jednotlivým položkám) pro danou site.

Co ale s tím a proč to dosud fungovalo bez potíží? Pídil jsem se po internetu a našel jsem mnoho rad o tom, že je to způsobeno porušením cache na disku, a že je tedy potřeba provést její reset. Ani opakovaný nezabral. Pátral jsem tedy dále, až jsem narazil zde na někoho se stejným problémem, který to ale "hnal vejš" a obrátil se na podporu Microsoftu. Dostal překvapivou odpověď, viz. poslední příspěvek na té stránce. Když to shrnu, jde v podstatě o to, že funkce BlobCache přestane fungovat tehdy, když máte na SharePointu více než 10000 položek s vlastním nastavením práv (tedy takové, které není děděné z nadřazené položky). Dá se jen spekulovat proč. Pravděpodobně vývojářský tým došel k závěru, že taková operace (která je ale nutná, aby nebyl uživateli poskytnut soubor, na který nemá právo) by už trvala příliš dlouho a zisk z cache na disku by byl minimální, pokud vůbec nějaký. Škoda jen, že to není v dokumentaci k BlobCache, a že to prostě jednoho krásného dne padne na ústa. Oněch 10000 položek s individuálně nastavenými právy totiž není pro podnikový intranet nic závratného.

Konfigurace vyhledávání v SharePointu - 1. část

mazin — Mon, 05 Apr 2010 18:10:00 GMT

Úvod

Toto je 1. díl minisérie o vyhledávání v SharePointu. Než se pustíme dál, chtěl bych jen upozornit, že se budu věnovat fulltextovému vyhledávání a ne prostému filtrování obsahu seznamů.

Mimochodem, je zvláštní, že webparty umožňující pokročilejší filtrování dat v seznamech a knihovnách dokumentů, jsou až v Enterprise verzi MOSSu. Tím pokročilejší myslím něco víc, než umí i WSS, tedy omezení výběrem hodnoty v záhlaví sloupce. Nevím, jestli pánům v Redmontu to připadalo jako Enterpise funkce, mě to připadá jako to nejzákladnější. Takže pokud se nechcete před zákazníky cítit trapně, až jim budete vysvětlovat, že ano SharePoint fitrovat data umí, ale že je to bude stát Enterprise licenci a Enterprise CALy, musíte se spolehnout na komponenty 3. stran, nebo na svou tvořivost.

Ale zpět k fulltextovému vyhledávání.

Fulltextové vyhledávání v SharePointu má tři fáze, jako ostatně většina podobných vyhledávání:

Nejprve se projdou definované zdroje dat. Smyslem této fáze je pořídit kopie datových zdrojů pro další zpracování. V podstatě tato fáze má 2 módy:

úplné - dojde ke smazání (pokud už existují) stávajících informací a ke kompletnímu projití zadaných zdrojů dat. Náročné, ale důkladné, proto se provádí méně často (např. při výrazné změně struktury nebo obsahu zdroje dat).
přírůstkové procházení - soustředí se na aktualizaci již nalezených dat, podmínkou je alespoň jedno úspěšné úplné projití. Je rychlejší, ale něco může přehlédnout. Provádí se častěji než úplné procházení. Cílem je zajistit aktuálnost výsledků hledání

Nalezená data se zpracují a uloží se do formy, ve které je možné snadno a rychle hledat, vytváří se tzv. index.
Při zadání vyhledávacího dotazu je provedeno hledání nad předzpracovanými daty z kroku 2. Díky tomu je sice možné dotaz vyhodnotit rychle, ale hrozí riziko, že jsou vrácena neaktuální data. Nalezená data jsou pak zpracována do uživatelsky přívětivé podoby.

WSS vs. MOSS

Celý další popis se týká prakticky jen MOSSu, protože na WSS nic z toho nenajdete. Pokud jsou oblasti, kde WSS a MOSS se moc neliší, tak v podpoře vyhledávání jsou to nebe a dudy. Ve WSS můžete v Administračním webu pouze:

určit pod jakým účtem poběží vyhledávací job
pod jakým účtem bude procházen web (tedy)
jak často bude probíhat procházení webu

Globální nastavení

Začíná v nastavení Sdílených služeb, protože právě ony jsou v MOSSu zodpovědné za procházení a indexaci datových zdrojů (ale i za mnoho dalších věcí, kterým se ale dnes věnovat nebudu). Nastavení se provádí na administračním webu a dají se zde nastavit následující věci:

Procházení:

Zdroje dat - tedy to, co se má procházet. Může jít o weby SharePointu, jiné weby, sdílené disky, veřejné složky Exchange a data z Bussiness Data Catalogu (MOSS Enterprise)
Plány procházení - to znamená, kdy a jak často se datové zdroje mají procházet, aby se nalezly nové informace, nebo aby se zjistily změny
Pravidla procházení - ze zadaných zdrojů lze, s pomocí hvězdičkové konvence, vyjmou některé adresy. Např. testovací weby apod. Stejně tak ale lze říci, že některé adresy se mají procházet pod jiným účtem atd.
Účet, v jehož kontextu se má procházení provádět. Velmi důležité místo při hledání odpovědi na otázku: Proč při hledání uživatelé nevidí záznamy, které jsou na procházených webech, a ke kterým mají přístup? Odpovědí totiž často bývá: Ano uživatelé k informacím přístup mají, ale ne účet indexovací služby.
Typy souborů - určují se přípony souborů, které mají být při procházení analyzovány.

Dále se definuje, jak se mají nalezené informace zpracovávat:

Směrodatné stránky - dá se stanovit, že informace pocházející ze zadaných adres mají větší váhu než ostatní. Stejně tak se dají určit adresy naopak s méně hodnotnými informacemi.
Obory - data nalezená během procházení se dají sdružovat do oborů. Příslušnost k nějakému oboru je dána pomocí pravidel. Pravidla pracují s vlastnostmi nalezených dat, jejich zdrojem a URL adresou. Standardně je vytvořen obor Osoby, který zahrnuje všechny nalezené informace typu osoba. Pomocí pravidel také můžete informaci z oboru vyřadit.
Vlastnosti metadat - zde se provádí mapování vlastností indexovaných dat (tzv. procházené vlastnosti, vlastnosti záznamů a dokumentů, které SharePoint při procházení datových zdrojů najde) na tzv. spravované vlastnosti (vlastnosti propagované a použitelné při zadávání dotazu a zpracování výsledků hledání). Funguje to následovně:

vytvoříte seznam A a v něm sloupec B
Při procházení na to SharePoint přijde a vytvoří novou procházenou vlastnost. Vlastnosti se snaží členit do kategorií.
Můžete vytvořit spravovanou vlastnost, nazvat ji B, propojit ji s vlastností z předchozího bodu. Nejtěžší je najít vlastnost, která vás zajímá, mezi těmi stovkami až tisící procházených vlastností. Odměnou vám ale bude, že se spravovanými vlastnostmi se dají dělat ve vyhledávání užitečné kejkle. Např. ji můžete použít při definici oboru. Blíže se na spravované vlastnosti podíváme v dalším díle o vyhledávání.

Mapování serverů - toto se používá v situacích, kdy vyhledávací služba používá k procházení jiné URL adresy (např. lokální), než budou používat uživatelé
Odebrání výsledků hledání - zde můžete stanovit, že určité URL adresy mají být z výsledků odstraněny - vnitřně to funguje tak, že se vytvoří pravidlo procházení (viz. výše) a zadané adresy se ani neprochází.

Kromě administračního webu, kde se definují globální vlastnosti vyhledávání, mohou výsledky vyhledávání ovlivnit i správci jednotlivých kolekcí webů, webů a i "správci" jednotlivých seznamů.

Na úrovni kolekce webů:

Zapnout podporu Centra vyhledávání. Můžete vytvořit speciální web pro vyhledávání (šablona Centrum vyhledávání). Na tomto webu se pak dá hodně ovlivnit, co uživatel může hledat a jak se mu prezentují výsledky. Této problematice se budu věnovat v dalším díle. V tomto nastavení určujeme, které centrum hledání dané kolekce webů vyřizovat (můžete jich mít ve farmě samozřejmě více) a zobrazovat výsledky.
Vlastní obory - rozšiřuje množinu globálně definovaných oborů hledání. Obory se projeví jako možnost omezit hledání na stránce Rozšířeného hledání, nebo na stránce hledání v Centru vyhledávání
Klíčová slova - lze definovat tzv. aliasy. To znamená, že pokud uživatel zadá např. cesťák, najdou se všechny záznamy, které obsahují frázi cestovní příkaz. Také lze definovat nejvhodnější dokumenty (angl. best bet). To jsou dokumenty, které se mají zobrazit jako první ve výsledcích při hledání daného výrazu. Dá se omezit i časová platnost klíčových slov.

Na úrovni webu se mohou definovat:

jestli má být daný web zahrnutý do hledání
jestli se mají indexovat pouze data v seznamech, nebo i publikované APSX stránky (to může být bezpečnostní problém, pokud stránka nekorektně hlídá práva)
sloupce, které se nemají prohledávat - např. proto, že obsahují citlivé informace. V tomto nastavení můžete ovlivnit pouze sloupce definované na úrovni webu. Nemůžete tak ovlivnit sloupce definované přímo v seznamech (knihovnách dokumentů)
tzv. související odkazy - to vytvoří další obor hledání nazvaný "Související weby" a umožňuje to správcům webů definovat vazby mezi weby. Vlastně to dává šanci uživateli hledat informaci na daném webu, a pokud nic nenajde, nebo toho najde méně než by čekal, může zkusit právě obor "Související weby".

Na úrovni jednotlivých seznamů:

zda má být seznam zahrnut do výsledků vyhledávání
nastavení práv ovlivňuje samozřejmě taky vyhledávání, protože před zobrazením výsledků se ověřuje, zda má hledající uživatel k nalezeným záznamům práva. Nastavením, resp. odejmutím práv účtu, pod kterým probíhá procházení zdrojů dat (viz. výše), můžete zamezit indexaci jednotlivých záznamů v seznamu

iFiltry

Dalším způsobem, jak ovlivnit výsledky vyhledávání, je použití iFiltrů. Jedná se o moduly, které umožňují prohledávacímu stroji zpracovat nejen vlastnosti dokumentů jako je jméno, ale i obsah. Standardně obsahuje SharePoint iFiltery pro MS formáty jako jsou Word, Excel, PowerPoint a podobně.

Pokud chcete naučit váš SharePoint indexovat i nějaký "exotický" formát, např. PDF , pak musíte:

obstarat si a nainstalovat příslušný iFilter na server ve farmě, který má roli vyhledávacího serveru
přidat příponu typu souboru, který iFilter zpracovává mezi typy souborů, které bude SharePoint indexovat. To uděláte v konfiguraci vyhledávání na administračním webu.
určit ikony, kterou má SharePoint zobrazovat u souborů s danou příponou, jinak bude zobrazovat nicneříkající univerzální ikonu. To uděláte takto:

obrázek (např. jpeg nebo png, ideálně o velikosti 16x16px) nahrajete do adresáře např. C:\Program Files\Common FIles\Microsoft Shared\Web Server extensions\12\TEMPLATE\IMAGES
do souboru DOCICON.XML v adresáři C:\Program Files\Common FIles\Microsoft Shared\Web Server extensions\12\TEMPLATE\XML přidáte mapování obrázku na příponu. Například tedy: <Mapping Key=”pdf” Value=”pdficon_small.gif” OpenControl=”"/>

spustíte úplné procházení, aby se zindexovaly už uložené soubory, jež podporuje nainstalovaný iFilter.

Práva

Ještě bych se chtěl zastavit u práv. Výsledky hledání jsou samozřejmě ovlivněny právy. A to hned dvakrát. Nejprve jsou to práva účtu, který je použitý při procházení. Pak to jsou práva uživatele, který provádí hledání. Dá se zkrátka říct, že má-li být schopen uživatel informaci najít. Musí k ní mít práva on i účet, který prochází datové zdroje.

Taky bych chtěl v souvislosti s právy zmínit jednu věc. Protože SharePoint neumožňuje nastavit práva na jednotlivé sloupce seznamů, řeší se to často úpravou New, Display a Edit dialogů seznamů. S tím ovšem souvisí jedno nebezpečí. Jestliže si nedáte pozor a příslušný seznam neoznačíte, že se nemá indexovat, může se stát to, že citlivý údaj se objeví ve výsledcích vyhledávání! Dokonce ani vyřazení příslušného sloupce (za předpokladu že sloupec je definovaný na úrovni webu) z indexování nepomůže. Problém je v tom, jak SharePoint ukládá záznamy do databáze a jak funguje vyhledávání:

Záznamy jsou v databázi uloženy ve formě XML a takto jsou i zpracovány při indexaci obsahu
SharePoint standardně ve výsledcích hledání u jednotlivých záznamů zobrazuje i okolí hledané informace

Kombinací těchto dvou skutečností se může stát následující situace:

Existuje např. seznam zaměstnanců se sloupci Jméno, příjmení, plat a funkce. Plat je tajný a údaje z tohoto sloupce může vidět pouze personální manažer. Proto vývojáři upravili New, Display a Edit dialogy. Jenže pak přijde uživatel a do vyhledávacího pole zadá funkci některého zaměstnance. SharePoint ho najde a ve výsledcích zobrazí nalezený záznam: jeho nadpis, cestu k němu a už zmiňované okolí nalezené hodnoty, v našem případě funkce, kterou navíc zvýrazní. Protože hodnota platu je v XML záznamu uložena hned vedle hledané hodnoty funkce, dozví se uživatel i to, co by asi neměl. Když ale klikne na odkaz, aby se dozvěděl více, zobrazí se upravený display dialog, zafunguje jeho logika a vše je OK.

Závěr

Uff, snad jsem na něco nezapoměl. Probrali jsme jen část z toho, co můžete v SharePointu nastavit ohledně vyhledávání. Většina věcí, o kterých jsem se dnes zmínil, se týká toho, co a jak SharePoint indexuje. Tedy toho, co získá ze zdrojů dat a co se tudíž může objevit ve výsledcích. V příštím díle se podíváme na to, jak rozšířit možnosti hledání pro uživatele, tak aby mohl co nejlépe určit, co hledá. Taky se podíváme na to, jak ovlivnit formu, jakou jsou mu podány výsledky hledání.

Problém při sdílení OneNote bloků v SharePointu

mazin — Mon, 08 Mar 2010 06:00:00 GMT

Nedávno jsem narazil na "zajímavou vlastnost" SharePointu, resp. OneNotu. Využíváme SharePoint pro sdílení a synchronizaci OneNote poznámkových bloků. Skupiny uživatelů mezi sebou sdílely tímto způsobem informace rychle se měnící informace. Vše běželo normálně až do okamžiku, kdy jsem si všiml, že IIS logy SharePointu mají najednou téměř padesátinásobnou velikost. Stejný nárůst byl i u počtu přístupů. To samozřejmě nevěstilo nic dobrého. Krátkou analýzou logů jsem zjistil, že většina požadavků se vztahuje ke sdíleným OneNote blokům. Během jedné sekundy přišlo několik desítek požadavků jednoho uživatele a trvalo to několik hodin. Naštěstí to byly všechno požadavky, které sever obsloužil za 25ms, takže to server nezabilo.

OneNote ukládá bloky jako adresáře, stejné je to i se skupinami oddílů. Teprve jednotlivé oddíly jsou uloženy jako soubory. A v těchto dvou větách je ukrytý problém. Po několika hodinách pátrání a zpovídání uživatelů, jsme přišli na příčinu. Jeden z uživatelů totiž vytvořil nový oddíl, v jehož jméně použil znak +. Přestože v SharePointu lze normálně vytvořit adresář se znakem + v názvu, OneNotu to ale dělalo problém. Vedlo to k tomu, že začal generovat obrovské množství HTTP požadavků. Problém se projevoval jen u těch uživatelů, kteří používali OneNote blok obsahující inkriminovaný oddíl.

Doufám, že tímto ušetřím některým z vás šediny z hledání příčiny problému, protože jinak je sdílení OneNote bloků pomocí SharePointu užitečné a přínosné.