Zrovna jsem si tu zprovoznil SharePoint Foundation 2010 Search a zažil při tom všechny problémy, které jsem už viděl několikrát :-) Tak je pojďme pěkně rozebrat. Mě osobně připadá, že nastávají téměř vždycky. Bude to asi tím, že když někdo to prostředí nechce mít bezpečné, tak mě nepotřebuje :-) A když ho chcete mít bezpečné, máte problémy. SharePoint totiž vůbec nepočítá s ne-výchozí bezpečností. A jak mi to tak připadá, tak ani moc nepočítá s tím, že všechny jeho servisní účty nejsou lokálními adminy :-)
Už při instalaci si obvykle užiju dost zábavy, nicméně tentokrát jsem měl možnost skrýnšotovat rozjíždění tak jednoduché věci, jakou je SharePoint Foundation 2010 Search. Tak tady to je. Obdoby následujících problémů najdete všude na internetu, ale nikoliv přesně moje konkrétní. Tak proto to tu píšu.
Problém první - VSS Writer
SharePoint Foundation 2010 Search si registruje při své konfiguraci doplnět služby Volume Shadow Copy (VSS), kterou používá zálohování k tomu, aby bezpečně zazálohovalo soubory všech aplikací. Indexovací engine má svoje pracovní soubory na disku v datovém adresáři SharePointu. Pokud se zálohuje, musí se to dozvědět a nepodnikat žádné větší akce.
Jednou z konfigurací, kterou provádí, je vytvoření jednoho klíče a zapsání nějakých hodnot do registrů:
HKLM\SYSTEM\CurrentControlSet\Services\VSS\Diag\SPSearch4 VSS Writer
No a když tam nemůže zapsat a tenhle klíč vytvořit, prostě to krešne s následujícím erorem:
Event Log: Application
Event Type/Level: Error
Event Source: VSS
Event ID: 8193
Message: Volume Shadow Copy Service error: Unexpected error calling
routine RegOpenKeyExW(-2147483646, SYSTEM\CurrentControlSet\Services\VSS\Diag).
hr=0x80070005, Access is denied.
Writer Class ID: {35500004-0201-0000-0000-000000000000}
Writer Name: SPSearch4 VSS Writer
Writer Instance ID: {dd154346-7a8d-40bd-af2d-098985e1b9ac}
Řešení je jednoduché. Stačí si v registrech ten klíč buď rovnou vytvořit, nebo prostě nechat ten účet, který vidíte v detailním zobrazení dané události, do tohohle klíče zapisovat. V mém příkladu máme, že zapisovat tam musí být schopen účet, pod kterým běží právě služba SharePoint Foundation 2010 Search.
Problém druhý - DCOM oprávnění
Další chyba, která se vyskytuje poměrně často, nemusí být spojena jenom se SharePoint, takže její řešení je docela obecné a může se hodit častěji. Jedná se tedy o toto:
Event Log: System
Event Type/Level: Error
Event ID: 10016
Event Source: DistributedCOM
Message: The application specific permission settings do not grant
Local Activation permission to the COM Server application with CLSID
{61738644-F196-11D0-9953-00c04fd919c1} and APPID
{61738644-F196-11D0-9953-00c04fd919c1} to the user ... from address
LocalHost (using LRPC). The security permission can be modified
using the Component Services administrative tool.
Tady je řešení sice také velmi jednoduché, nicméně poněkud pracné a vyžaduje vyhledávání v REGEDITu. Jde o to, že nějaký program se snažil přistupovat k DCOM komponentě (v našem případě IIS WAMREG Admin Service) a neměl k tomu oprávnění. Stačí mu toto oprávnění tedy přidělit pomocí Component Services konzole. Nechápu jenom, proč ta logová událost nemůže rovnou napsat jméno té DCOM komponenty. Musíte si ji tedy vyhledat v REGEDITu. Pustíte si ho a vyhledáte v klíči HKEY_CLASSES_ROOT\AppID hodnotu toho unikátního identifikátoru (GUID).
Když ho znáte, stačí si otevřít konzoli Component Services, rozkliknout seznam pod DCOM Config a tam už tuto aplikaci naleznete a můžete jí nastavit příslušná oprávnění - v mém případě pro uživatele, pod kterým běží moje webová aplikace (web application, vlastně IIS APPPOOL). Jen pro pořádek, je možné, že máte okénko s bezpečností zašedlé a nemůžete tam nic změnit - to se vyřeší tak, že v registrech nastavíte skupině Administrators plné řízení na celý ten klíč, který jste před chvilkou vyhledali (a musíte převzít vlastníctví).
Problém třetí - Přístup na datový disk
Vzhledem k tomu, že jsem to už řešil několikrát, nebylo těžké na to přijít, ale pamatuju si, že poprvé jsem se na něčem podobném zadrbal na několik hodin. Nicméně tohle je velmi pěkný příklad na řešení potíží s přístupem nějaké aplikace k nějakým prostředkům a použití nástroje Process Monitor ze Sysinternals. Takže nejprve chybka a potom jak to vyřešit:
Event Log: Application
Event ID: 71
Event Source: SharePoint Foundation Search
Event Type/Level: Error
Message: Content index on Component: ... could not be initialized.
Error Search.Access is denied. 0x80070005
Problém byl v tom, že jsem si nainstaloval SharePoint datové adresáře na jiný diskový oddíl. Já ho také vždycky zabezpečím tak, že do je rootu může jen skupina Administrators. A teprve pod tím vytvářím různé aplikační adresáře. Pokud program není idiot, normálně to funguje. Ne tak SharePoint. Z nějakého inteligentního důvodu potřeboval číst v rootu toho datového oddílu. Stačilo tedy přidělit oprávnění pro čtení a bylo hotovo.
Zajímavé je, jak na to přijdete. Naučte se používat Process Monitor ze Sysinternals. To je program, který monitoruje všechna volání systémových funkcí všech programů a zobrazuje jejich návratové hodnoty. Už se mi to moockrát hodilo. Stačí si nastavit filter tak, abyste viděli jen chyby. A zkusíte spustit tu akci, která vám nefunguje. A rovnou vidíte, který program se kam nedostal. Úžasný nástroj. Jenom příprava toho filtru je trošku bolestivější :-)
Problém čtvrtý - WINHTTP proxy
Poslední událost, která potřebovala řešení byla spojena s nastavením proxy. Pokud mám v síti Threat Management Gateway 2010 nebo starší ISA Server, povoluju přístup do internetu jen ověřeným uživatelům. A to i v případě aktualizací. Když to chcete odfláknout, stačí si udělat obvykle výjimku pro aktualizační stránky, nebo třeba pro IP adresy vašich serverů. Jenže není důvod - můžete mít jediné pravidlo povolující HTTP i HTTPS všem ověřeným počítačům. Už jsem o tom psal tady.
Event Log: Application
Event Source: SharePoint Foundation Search
Event Level/Type: Warning
Event ID: 14
Task Category: Gatherer
Message: The start address sts4://www.sevecek.com/contentdbid={guid}
cannot be crawled. Context: Application 'search_index_file_on_the_search_server',
Catalog 'Search'. Details: The crawler could not communicate with the server.
Check that the server is available and that the firewall is configured correctly.
If the repository was temporarily unavailable, an incremental crawl will fix
this error. (0x80041200, hr=80041200)
Tady byl problém právě s proxy. Jak jsem zjistil na googlu, hodnota 0x80041200 znamená PRTH_E_NOT_REDIRECTED (Redirected URL does not exist). Tady jsem musel použít přítele gůgla, protože můj druhý přítel, utilita ERR, v tomto případě nezaznamenala zásah. Takže řešení bylo z chyby celkem jasné. Zřejmě ten podivný sérč leze do content database pomocí veřejného URL její aplikace (public URL - AAM - Alternate Access Mapping). Místo aby logicky použil vnitřní URL (internal URL). No co už.
Takže jsem musel vyřešit dvě věci - zaprvé jsem musel zařídit, aby adresa www.sevecek.com byla vůbec dostupná a vedla správně na můj SharePoint server. Za druhé jsem musel přidat pomocí NETSH výjimku pro tato jména tak, aby tam SharePoint Foundation Search nelezl přes proxy - viz. tento článek.
A to je pro dnešek už všechno :-)