Vítejte na blog.vyvojar.cz Přihlásit | Registrovat | Pomoc
Titulní Blogy Fotky Soubory

Mazinův blog o SharePointu

  • Anonymní přístup do SharePointu

    Anonymní přístup není úplně obvyklý scénář použití SharePointu ve firemním prostředí, ale jsou situace, kdy se bez něj neobejdete. Například v případě, že chcete SharePoint použít jako veřejně dostupný web. Anonymní přístup se dá kombinovat s Windows i formulářovým ověřováním (FBA), včetně jich obou. V takovém případě jste schopni dosáhnout situace, kdy některé části SharePointu jsou dostupné jen Windows ověřeným uživatelům (obvykle interním zaměstnancům), jiné mohou být přístupné uživatelům ověřeným pomocí FBA. A něco můžete zpřístupnit i uživatelům, kteří se nepřihlásí vůbec.

    V tomto článku si ukážeme, jak se anonymní přístup zapíná, konfiguruje a jaké má další vlastnosti.

    Konfigurace

    Zapíná se na úrovni webové aplikace, podobně jako jiná nastavení autentizace.


    Pak je potřeba zapnout přistup na webové aplikaci v Zásadách pro anonymní přístup. Tím se dá umožnit anonymní přístup pouze pro určité zóny. Dá se:

    • žádné - řešit si to budou jednotlivé weby, listy a položky.
    • odepřít zápis – v takovém případě mohou anonymní uživatelé pouze číst. Paušálně pro celou zónu aplikace.
    • odepřít vše - např. chci zakázat anonymní přístup uživatelům intranetu, ale v extranetu povolit.

     

    Nastavování oprávnění

    Na úrovni webů (sekce Oprávnění webů) můžete nastavovat práva jako obvykle.

    Nově ale najdete v ribbonu tlačítko anonymní přístup, které umožní nastavit obecně přístup. Máte následující možnosti:

    • Celý aktuální web – bez přihlášení mohou uživatelé přistupovat jak k seznamům, knihovnám i stránkám. Samozřejmě jen k těm, u kterých to nastavíte v oprávnění.
    • Seznamy a knihovny – anonymní přístup je povolen jen ke knihovnám dokumentů a seznamům. Stejně jako v předchozím bodě se konkrétní přístup nastavuje v oprávněních vybraných seznamů a knihoven.
    • Nic – nepřihlášení uživatelé nemají k této kolekci webů přístup.

    Dokud ho tady nepovolíte, na webech se v nastavení práv nic neobjeví a ani není možnost se na nich nepřihlásit.

     

    Nepřihlášení uživatelé mají v ribbonu nastavování práv seznamů a knihoven dokumentů zvláštní tlačítko Anonymní přístup, podobně jako při nastavování oprávnění webů.

    Na úrovni seznamů se dá nastavovat jen omezený výčet oprávnění:

    • Přidat položky
    • Upravit položky
    • Odstranit položky
    • Zobrazit položky

    Nelze využívat jiných natož vlastních úrovní oprávnění.

    V knihovně lze nastavit jen zobrazení položek.

    Anonymní uživatelé nemohou mít práva na jednotlivé položky. Lze ale využít následujícího triku:
    Anonymní uživatel má přístup na úrovni Omezený přístup. Pokud tedy na seznamu povolíte přístup anonymním uživatelům, ale na konkrétních položkách přerušíte dědění, nebudou mít k těmto položkám anonymní uživatelé přístup.

    Další postřehy:

    • Spuštění WF vyžaduje přihlášení. Jde o to, že stránky ohledně WF vyžadují autentizaci.
    • Anonymní uživatel sice vidí ikonu Otevřít v průzkumníkovi, ale bude ho to nutit přihlásit se.
    • Anonymní uživatel nemůže nastavovat pole uživatel nebo skupina, nemá tam totiž people picker, ale hlášku “Ovládací prvek není k dispozici, protože nemáte příslušná oprávnění”.

    Poznámky z pohledu programátora

    • Dejte si pozor na to, že pokud není uživatel přihlášen, v SPWeb.CurrentUser je null.
    • Jestliže potřebujete vytvořit aplikační stránku, která nebude vyžadovat přihlášení, musíte ji odvozovat od UnsecuredLayoutsBasePage místo LayoutsBasePage a je potřeba přetížit vlastnost AllowAnonymousAccess tak, aby vracela true.
    • Práva anonymním uživatelům se nastavují pomocí AnonymousPermMask64 - to je maska práv. V knihovnách dokumentů platí, že nelze povolit přidávání, editaci a mazáni. I když to v kódu nastavit lze, nebude to fungovat.
    • Vlastnost AnonymousPermMask64 je dostupná pouze na třídách SPWeb a SPList, viz informace o tom, že nelze nastavovat práva na jednotlivých položkách.
    • Pomocí SPList.AnonymousPermMask64 = SPBasePermissions.EmptyMask; odstraníte veškerá práva nepřihlášených uživatelů k objektu.
    • Použití <UserID>, tedy odkaz na aktuálního uživatele, v CAML dotazu způsobí výzvu k přihlášení uživatele.
    • Ve sloupcích Author a Editor jsou hodnoty "-1;#" ze které nevyrobíte objekt typu SPUser.
  • SharePoint 2013 ServicePack 1

    Před časem vyšel service pack pro Office 2013. V rámci balíku service packů vyšel i service pack 1 pro SharePoint.

    Stáhnout jej můžete z této stránky, kde najdete service packy pro jednotlivé verze:

    • SharePoint Foundation
    • SharePoint Server
    • Project Server
    • Office Web Apps

    Upřímně řečeno jsem docela zklamaný z toho, co obsahují. Pročítal jsem k němu KBčka, zkoušel jsem ho, ale nic zásadního z pohledu nových funkcí jsem nenašel. V podstatě jde o:

    • lepší podporu IE 11
    • propojení účtů uživatelů onpremise a OneDrive for Business
    • možnost instalace na Windows 2012 R2. To je ale zatím jen teoretická šance, protože jde o SP1. Takže byste museli nejprve nainstalovat SharePoint na Windows 2012 R2 bez SP, což se vám nepodaří. A pak na něj nainstalovat SP1. Dokud nebude dostupná instalace včetně SP1, není tato novinka použitelná. EDIT – tak instalace včetně SP1 jsou už dostupné viz komentáře. Díky za upozornění.

    Jinak jde vlastně o souhrn všech předchozích kumulativních updatů, tedy opravy chyb. Nicméně i za to jsem rád. Vzhledem ke svým špatným zkušenostem s instalací kumulativních updatů dávám přednost instalaci SP. Detailní popis změn (nejen SharePointu, ale i Office) najdete v tomto excelu.

    Protože už uplynulo několik týdnů od vydání, zdá se, že to dobře otestovali a že se nedočkáme opětovného vydání, případně stažení a opětovného vydání, jako se to stává u kumulativních updatů.

    Instalace sama je rychlá a nesetkal jsem se s žádnými potížemi.

    Takže zálohujte servery, proveďte instalaci na všech strojich ve farmě a nezapomeňte spustit PSConfig.

  • Konfigurace výběru uživatelů

    V Sharepointu mohou uživatelé vybírat jiné uživatele pomocí tzv. people pickeru, tedy prvku pro výběr uživatelů. Typicky při nastavování práv nebo v uživatelském sloupci Uživatel nebo skupina. Sloupec můžete nakonfigurovat aby umožnoval vložit jen uživatele, nebo uživatele a skupiny.

    Pokud máte na SharePointu zapnutou form based autentizaci (FBA) s membership providerem, mohou uživatelé pocházet z:
    • domény
    • FBA
    a skupiny z:
    • domény
    • FBA
    • SharePointu samotného

    Někdy je užitečné, nebo dokonce nutné omezit výběr nabízených skupin a uživatelů z domény. Např. pokud máte několik domén se stejnými uživateli, může se stát, že uživatel zadá do prvku pro výběr uživatele nebo skupiny jméno “Jan Novák” a nabídnou se mu 2. Jeden bude pocházet z domény A a druhý z domény B. Který je správný ale uživatel nepozná nepozná a může být problém.

    Pro omezení toho, co people picker nabízí má SharePoint několik nastavení. Dejte si pozor na to, že některá z nich ovlivňují chování pole pro zadávání uživatelů, jiná ovlivňují vyhledávací dialog a jiná obojí. Další problém je, že MSDN dokumentace je někdy zavádějící a na různých místech uvádí různý význam některých parametrů.

    Omezení výběru uživatelů jen na ty, kteří mají nějaká práva na kolekci webů

    Nastavení pro tlačítko Kontrola jmen:
    stsadm -o setproperty –pn peoplepicker-Peopleeditoronlyresolvewithinsitecollection –pv yes –url <URL webové aplikace>

    Nastavení pro okno Procházet:
    stsadm -o setproperty –pn peoplepicker-onlysearchwithinsitecollection –pv yes –url <URL webové aplikace>

     

    Omezení výběru uživatelů (a skupin) jen ze zadané organizační jednotce (organization unit)

    Užitečné, když chcete například zabránit používání AD skupin. Uživatele, které chcete používat, přesunete do k tomu účelu vytvořené organizační jednotky, ale nebude v ní mít žádné skupiny.

    stsadm -o setsiteuseraccountdirectorypath -path <Valid OU name> –url <Site Collection URL>

    Příklad: stsadm -o setsiteuseraccountdirectorypath -path "OU=Sales,DC=ContosoCorp,DC=local" –url http://Server/sites/sitecoll

    Oproti ostatním se nastavuje na úrovni kolekce webů. Pozor: hodnotou je jen 1 organizační jednotka, ne více!

    Toto nastavení ovlivňuje jak tlačítko Kontrola jmen, tak okno Procházet.

     

    Omezení výběru pomocí LDAP dotazu

    Někdy je potřeba omezit výběr např. jen na uživatele, ne skupiny a podobně. Toto je nejflexibilnější nastavění, ale pozor: Toto nastavení ovlivňuje pouze okno Procházet! Ne Kontrolu jmen. Sad smile 
    Tedy to tvrdí MSDN. Článek je sice o SP 2007, ale odkazují se na něj i články o SP 2010. Naštěstí to platí jak pro oba typy výběru uživatelů. Vyzkoušeno.

    Stsadm –o setproperty –pn peoplepicker-searchadcustomfilter -pv <LDAP dotaz> -url <URL webové aplikace>

    Základy LDAP můžete najít zde.

    Příklad (vrátí pouze aktivní uživatele, ne skupiny):

    stsadm -o setproperty -pn peoplepicker-searchadcustomfilter -pv "(&(objectCategory=person)(objectClass=user)(!userAccountControl:1.2.840.113556.1.4.803:=2))" -url http://Server

    Omezení výběru jen na FBA uživatele

    Hodí se v situaci, kdy máte SharePoint v doméně (téměř vždy, kvůli administraci), ale SharePoint uživatele spravujete pomocí FBA a jen s nimi chcete pracovat.

    stsadm -o setproperty -pn peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode -pv yes -url <URL webové aplikace>

    Toto nastavení ovlivňuje jak tlačítko Kontrola jmen, tak okno Procházet.

     

    Než začnete některou z vlastností měnit, určitě si uložte původní hodnotu. Tu zjistíte příkazem:

    stsadm -o getproperty –pn <jméno vlastnosti>

  • Podivnosti metody EnsureUser

    EnsureUser je užitečná metoda objektu SPWeb, která vám najde uživatele podle zadaného jména. A nejen to, pokud není dosud v na webu evidovaný, tedy není v seznamu uživatelů webu, tak jej tam přidá.

    Její prototyp je SPWeb.EnsureUser(string logonname) s návratovou hodnotou typu SPUser. Podle MSDN má být logonname ve tvaru domain\username, a když uživatel neexistuje, vyhodí vyjímku. Jenže co při použití claims autentizace? A pokud navíc ještě mám vlastní membership provider?

    Pojďme se na podívat postupně.

    Pokud požíváte pouze Windows autentizaci, máte celkem klid, metoda se chová podle MSDN. Ověří, jestli uživatel existuje. Pokud ano, vrátí vám ho a případně (jestli už tam není) ho přidá do seznamu uživatelů webu.

    Pokud máte zapnuté claims identity a FBA, začne se to komplikovat:

    1. Ve webpartech a jiném webovém kódu metoda funguje dobře. Ověří login pomocí membership providera a domény, jestli uživatel existuje a případně ho přidá mezi uživatele webu. V parametru snese oba formáty loginu, tedy claims(”i:0#.f|mymembershipprovider|username” – ”i:0#.w|domain\username”) i jednoduchý (”login” -”domain\username”).
    2. V event receiverech, jobech a PowerShellu se začne chovat divně. Když použijete jednoduchý formát, bude vám o všech FBA uživatelích tvrdit, že neexistují. Takže musíte použít claims tvar. Pak ale přestane existenci uživatele kontrolovat a přidá uživatele do seznamu uživatelů webu, i když neexistuje. A vrátí vám spokojeně jeho objekt. Takto “založený” uživatel se nemůže přihlásit, protože neexistuje v doméně ani v membership provideru. Uživatelé ho nemohou použít v people pickeru, ale váš kód s ním pracovat může a například takovému uživateli vytvoří úkol. Sad smile

    Při analýze vykonávaného kódu jsem zjistil, že v prvním případě se SharePoint snaží najít uživatele nejen v doméně, ale i u membership providera voláním metod GetUser, FindUsersByEmail a FindUsersByName. Z toho plyne, že parametrem metody nemusí být nutně jen username. V druhém případě se metody membership providera nevolají.

    Závěr:

    Při použití FBA autentizace a uživatelů si musíte nejprve sami prostřednictvím membership providera ověřit, jestli daný uživatel existuje. A teprve v kladném případě můžete zavolat EnsureUser metodu. Ta vám jej ”zaeviduje” na webu a vrátí jeho SPUser objekt. Můžete si na to vytvořit vlastní Ensure metodu, ideálně jako extension metodu SPWeb objektu.

  • Potíže s datovým listem

    Datový list je oblíbeným způsobem jak provádět hromadné úpravy v seznamech a knihovnách dokumentů. Má ale několik omezení:

    1. Pro práci s ním musíte mít lokálně nainstalovaný Access – je to totiž vlastně jen Access zobrazení SharePointího seznamu, resp. datový zdroj otevřený v Accessu.
    2. Prohlížeč musí podporovat ActiveX (takže jen Internet Explorer) a musí odpovídat bitová verze prohlížeče a Accessu, tedy 64b - 64b a 32b – 32b. O těchto potížích jsem psal dříve.
    3. Omezeně pracuje s vlastními typy sloupců – pokud máte naprogramovaný vlastní prvek pro práci s hodnotou, bude vám v tomto případě k ničemu.
    4. Nereflektuje úpravy formulářů ani vlastní formuláře – jde totiž o syrovou úpravu dat.
    5. Má potíže s povinnými poli v typech obsahu – problém se projevuje, když máte v seznamu několik typů obsahu s různými povinnými poli. Datový list požaduje vyplnění všech, bez ohledu na to, že typ obsahu aktuálního řádku požadovaný sloupec neobsahuje. Řešení, které se nabízí, je dočasně nastavit všechny sloupce jako nepovinné. Ale ani to není tak jednoduché. Nastavení na úrovni seznamu totiž u webových typů obsahů (a tedy i webových sloupců) nezabere. Dokonce ani nastavení povinnosti na úrovni webového typu obsahu (resp. jeho sloupců) nepomůže. Až nastavení webového samotného sloupce řeší náš problém. Má to ale neduh. Změna webového sloupce ovlivní všechna jeho použití, tedy nejen náš typ obsahu, ale i všechny ostatní typy obsahu a všechny seznamy, kde je sloupec použitý.
  • Odkazy v datech SharePointu a maily

    SharePoint umožňuje vkládat do uživatelských dat odkazy. Jednak do sloupců typu odkaz, ale i do sloupců typu víceřádkový text. Má to ale několik záludností. Jednou z nich je fakt, že pokud SharePoint usoudí, že odkaz směřuje do něj samotného, odřízne z odkazu serverovou část. Udělá z něj tedy relativní odkaz (server relative). To je důležité proto, že každá webová aplikace SharePointu může mít několik adres. Ty se nastavují v centrální administraci v sekci Mapování alternativních adres URL. A aby odkazy fungovaly ze všech, nesmí být absolutní. Ve webovém rozhraní to funguje dobře. Problém nastává v okamžiku, kdy se takto upravené odkazy mají objevit např. v emailech. V notifikacích to má SharePoint vyřešeno tak, že při vytvoření notifikace si uloží i právě použitou adresu serveru a tu pak použije v okamžiku odesílání emailu. Tomuto chování jsem se věnoval dříve. Pokud ale chcete emaily odesílat vy, například v jobu, musíte to vyřešit vlastním způsobem. Pro inspiraci nabízím:
    Regex r = new Regex("href=\u0022/");
    string output = r.Replace(inputString, "href=\u0022" + site.WebApplication.Sites[0].Url + "/");

    Nicméně toto řešení není 100%, protože relativní odkazy doplní o výchozí adresu webové aplikace z níž položka pochází, což nemusí vyhovovat všem uživatelům. Obecně je problém v tom, že nevíte jakou adresu používá uživatel, kterému notifikaci posíláte, k přístupu na SharePoint.

  • Propojení metadat dokumentů a sloupců knihoven dokumentů v SharePointu

     

    SharePoint umožnuje ukládat do knihoven dokumentů soubory a definovat jim vlastnosti (metadata), které je pak možné využít k organizaci souborů, vyhledávání a ve workflow. Tato metadata se nestávají součástí dokumentů. Jsou uložené v databázi SharePointu. Mnoho formátů souborů má vlastní metadata, uložená přímo v nich. U obrázků to jsou typicky souřadnice pořízení, datum pořízení, expozice a mnoho dalších. U Office dokumentů jsou to pro změnu klíčová slova, autor, počet stránek, nadpis dokumentu, popis, … Můžete si dokonce definovat vlastní metadata a od formátu 2007 (tedy přípony jako jsou DOCX, XSLX, PPTX) můžete tato metadata umístit do těla dokumentu. Takže, když budete mít svou vlastnost např. číslo faktury, tak se to číslo může objevit přímo v textu dokumentu. A v případě změny vlastnosti dokumentu dojde při prvním otevření dokumentu k aktualizaci I v textu. Může to fungovat i obráceně. Tedy, že se text vepsaný na určité místo “propíše” do vlastnosti dokumentu.

    Jak jsem se zmínil, SharePoint automaticky nepropojuje vlastnosti, které u souborů eviduje, s vlastnostmi dokumentů samotných. Je to hlavně proto, že způsob ukládání vlastností v dokumentech se liší formát od formátu. Nicméně v případě Office formátů k tomu dochází. To znamená, že pokud do knihovny dokumentů uložíte Office dokument a určíte mu vlastnosti (typicky určením typu obsahu) SharePoint je automaticky přidá k uživatelským vlastnostem dokumentu. Totéž se stane v okamžiku, kdy typu obsahu definujete nějaký Office dokument jako jeho šablonu.

    Při stažení (otevření) dokumentu se pak aktualizuje nejen seznam vlastností Office dokumentu, ale i jejich hodnoty. Jinými slovy, při stažení dokumentu SharePoint provede kontrolu uživatelských vlastností dokumentu a doplní k nim chybějící z knihovny dokumentů. Současně aktualizuje hodnoty těchto vlastností tak, aby odpovídaly hodnotám vlastností daného dokumentu v knihovně. Při nahrání dokumentu do SharePointu probíhá aktualizace vlastností stejně, ale přenos hodnot je opačný, tedy z metadat dokumentu do vlastností v SharePointu.

    Ukládání vlastností u Office dokumentů je vyřešeno tak, že se u každé vlastnosti kromě jejího InternalName a DisplayName ukládá její “původ”. Tím je GUID typu obsahu, nebo GUID seznamu. Díky tomu je zajištěno, že i kdyby dokument prošel několika SharePointy a ty měly stejně pojmenované sloupce, SharePoint s nimi bude zacházet jako s různými vlastnostmi. Díky tomu schválení dokumentu v jednom SharePointu nebude znamenat, že je dokument schválený i v druhém. SharePoint připouští, aby dokument měl jen 1 sadu vlastností. Pokud tedy zjistí, že už nějakou obsahuje, smaže ji a nahradí aktuální. Sloupce, které reprezentují stav workflow se do dokumentu “nepropisují”.

    Důležitým aspektem tohoto mechanizmu je, že se spouští asynchronně po nahrání dokumentu do knihovny. Z toho plyne fakt, že se může stát (a mě se opakovaně stávalo např. u InfoPath dokumentů) situace, kdy se vám spustí např. workflow při vložení dokumentu, ale ve SharePointích vlastnostech dokumentu ještě nejsou aktualizovány hodnoty z vlastností dokumentu samotného.

    Dalším důležitým důsledkem propojení vlastností z SharePoint knihovny (typu obsahu) a vlastností dokumentů včetně hodnot je to, že si dokument své vlastnosti uchovává i mimo SharePoint. To je většinou užitečné, ale je potřeba to mít na paměti, protože jinak si člověk může způsobit horké chvilky. Představme si následující situaci: Máme knihovnu dokumentů pro evidenci smluv, která mimo jiné se obsahuje sloupec stav smlouvy. Tento sloupec vyjadřuje stav přípravy, schvalování a nakonec i podpisu smlouvy. A v této knihovně mějme jednu smlouvu, která prošla všemi fázemi. Pak přijde požadavek na přípravu nové smlouvy, která bude velmi podobná té už existující. Proto by logickým krokem mohlo být to, že vezmeme původní smlouvu a zkopírujeme ji pod jménem druhé smlouvy. Následně bychom mohli upravit její text. Protože jsou ale součástí dokumentu i metadata, máme rázem i druhou smlouvu kompletně schválenou, ačkoliv ji nikdo neviděl. To je samozřejmě špatně. Kdyby se metadata z SharePointu nepropagovala do dokumentu a zpět chovalo by se to v tomto okamžiku logičtěji.

    Popsané chování (provázání vlastností SharePointu a vlastností dokumentů jako takových) je out-of-the-box u Office dokumentů a obrázků. SharePoint na to má obecný mechanizmus tzv. document parserů. Jsou to COM objekty, které implementují ISPDocumentParser rozhranní. Dají se naprogramovat v .NETu (viz. MSDN Custom Document Parsers). V SharePointu jsou registrovány na objektu SPWebService v kolekci PluggableParsers. Jde v podstatě o mapovací tabulku přípony dokumentu a odpovídajícího parseru. Stejnou tabulku můžete v XML podobě najít na disku v souboru DOCPARSE.XML. Editace dokumentu ale sama o sobě nefunguje, musíte provést změnu vlastnosti webové aplikace, např. PowerShellem nebo SharePoint Managerem.

    Další možností, jak tento přenos vlastností a jejich hodnot mezi SharePointem a dokumenty ovlivňovat je vlastnost ParserEnabled na objektu SPWeb. Tím můžete na úrovni jednotlivých webů přenos “globálně” zapnout, nebo vypnout. Bohužel to nejde na úrovni jednotlivých knihoven dokumentů.

  • Problém s mizejícím přehledem spustěných workflow

    Dnes mě SharePoint opět překvapil. Zákazník si stěžoval, že u některých položek, nad nimiž běželo workflow, nevidí nic v přehledovém okně WF. To, že nad položkou běželo nějaké workflow, bylo zřejmé z vlastností položek.

    Jak je to možné? Inu jednoduše. SharePoint z výkonových důvodů maže přehled o dokončených workflow nad položkou. A to včetně vygenerovaných úkolů! Zvlášť toto může být záludné. Sluší se zdůraznit, že k mazání dochází u dokončených workflow. Rozhodně ne u běžících. K mazání standardně dochází po 60 dnech od ukončení workflow. U každé asociace, tedy u každého připojení workflow k seznamu, se dá tato doba nastavit. Bohužel ne v UI, ale pomocí PowerShellu nebo v kódu.

    Mazání se netýká historie workflow. Takže informace, které si workflow během života loguje, zůstanou nedotčeny. Bohužel se k nim z UI nedostanete, protože se k nim normálně přistupuje pávě pomocí přehledu běžících a dokončených workflow. Sad smile

    Jako ultimátní řešení je vypnutí jobu “Automatické vyčištění pracovního postupu”, který se spouští každý den a který je za to promazávání zodpovědný. To ale nevidím jako nejšťastnější “řešení”, protože se vám bude plnit databáze dávno ukončenými úkoly a informacemi o dávno dokončených workflow. Proto spíše doporučuji provést revizi těch 60dnů a u konkrétních asociací to prodloužit.

  • User does not have permission to perform this action

    Nedávno se mi na SharePointím serveru začala v Event Logu objevovat pro mě nová chyba: “User does not have permission to perform this action”. Ze stack trace bylo zřejmé, že jde o SQL problém. A to přesto, že měl účet farmy všechna požadovaná databázová oprávnění pro SharePoint, tedy Security Admin a DB Creator.

    Chyba se objevovala nepravidelně a neměla vliv na běžný provoz. Přesto jsem ji nechtěl jen tak ignorovat. Inu googlil jsem a našel pár článků. Většinou se týkaly restoru databází po obnově, nebo ASP.NET. A tak mi došlo, že to možná bude souviset s přesunem databází SP z jednoho serveru na druhý. Nakonec jsem přišel na to, že zminovaná práva (Security Admin a DB Creator) jsou sice nutná, ale za určitých okolností nedostatečná oprávnění, která účet farmy musí na SQL serveru mít. Ještě je nutné, aby měl VIEW SERVER STATE právo.

    To se dalo zařídit jednoduše SQL příkazem: GRANT VIEW SERVER STATE TO <ucet farmy> a bylo po potížích.

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

    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

    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

    SharePoint 2010, na rozdíl od verze 2013 Sad smile, 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 spustěná jako administrátor

    Centrální administrace spustěná standardně

    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

    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

    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

    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.

Více článků Další stránka »

Syndication

News

  • Web Developer
  • Enterprise Application Developer

  • Microsoft Office SharePoint Server 2007, Application Development
  • Microsoft Windows SharePoint Services 3.0, Application Development
  • Microsoft Office SharePoint Server 2007, Configuration
  • Microsoft Windows SharePoint Services 3.0, Configuration
  • .Net Framework 2.0, Distributed Applications
  • .Net Framework 2.0, Web Applications
  • .Net Framework 2.0, Windows Applications
Powered by Community Server (Personal Edition), by Telligent Systems