SharePoint: Odstranění konfigurační cache

SharePoint je plný magie, nainstalujete a nakonfigurujete farmu, všechno běží jak má, uplyne několik týdnů či měsíců a najednou se začne celá farma chovat nedeterministicky (možná po instalaci nějakých CU), v logu se zobrazují hlášky jako "Cannot connect to the configuration database”, SqlException, padá služba časovače Windows SharePoint Services Timer V4, nespouštějí se workflow nebo padají na chyby atd.

Příčina porušení konfiguračních XML cache mi není jasná, nečekaný výpadek elektrického proudu a nekonzistentní stav? Nevím. V každém případě sám SharePoint  není schopen tento stav opravit a je nutné znovu přegenerovat tyto soubory.

  • Otevřete Administrative Tools a Services
  • Zastavte službu Windows SharePoint Services Timer V4 (případně pomocí příkazu net stop sptimerv4)
  • Otevřete pomocí Exploreru cestu %ALLUSERSPROFILE% \Application Data\Microsoft\SharePoint\Config\
  • Tato cesta obsahuje několik adresářů ve tvaru GUID, odstraňte veškerý obsah těchto adresářů – samotný adresář s název ve tvaru GUID musí zůstat!!! Pouze jejich obsah smažte.
  • Znovu spusťte službu Windows SharePoint Services Timer V4 (případně pomocí příkazu net start sptimerv4)
  • Mělo by dojít k automatickému vygenerování nových konfiguračních XML souborů
  • Restartujte IIS server pomocí IISRESET.EXE
  • Hotovo

Jak na změnu hierarchie webů a podwebů ve WSS 3.0 / MOSS 2007

web-shema-presunu

Pokud jste někdy navrhovali hierarchii nějakého webu na Sharepointu hurá systémem (tedy bez jakékoliv analýzy), nebo po někom takový web začali spravovat, určitě jste dříve či později řešili potřebu změny hierarchie webů, přesun webu pod jiný atd. Ale ouhle, taková funkce ve WSS ani v MOSSu není, na webu existuje sice spousta “užitečných” rad typu “vytvořte si template celého webu do STP a pak z něho vytvořte nový web kde potřebujete”, ale tento postup má celou spoustu závažných much na kráse:

  • při vytvoření nového webu z templatu dojde k vytvoření u všech seznamů, knihoven, pohledů, workflows atd nových identifikátorů! To na první pohled to nemusí ničemu vadit, pokud ale používáte nějaké rozšíření třetí stranou, dost možná se začnou objevovat zajímavé chyby, přestanou fungovat workflow, joby, nastavení alertů atd. (ve verzích před SP2 byl export do STP vůbec problematický)
  • spousta schovaných informací a nastaveních se vůbec nepřenese
  • určitě narazíte na limit velikosti STP (500 MB) – a už vůbec manipulaci a upload takového souboru přes browser a IIS

Naštěstí existuje i jedno mnohem lepší řešení v podobě rozšíření příkazové řádky STSADM o nové příkazy, mimo jiné také o příkaz pro přesun webu pod jiný.

Ukázka:

stsadm -o gl-moveweb -url <URL webu> -parenturl <nový rodič>

stsadm -o gl-moveweb -url http://intranet/vedeni/marketing -parenturl http://intranet

Tyto rozšíření STSADM příkazové řádky jsou dostupné i s kompletním popisem na webu http://stsadm.blogspot.com/

Oprava boot loaderu – hláška „Element not found“ při příkazu bootrec

Pokud vám příkaz bootrec nefunguje a vypisuje chybu „Element not found“, je potřeba nastavit partition jako aktivní.

  • vložte instalační medium OS
  • přejděte do módu „Repair“ po nastartování instalátoru OS
  • spusťte diskpart z příkazového řádku
  • zvolte disk příkazem: select disk #
  • zvolte oddíl příkazem: select partition #    ( # je číslo oddílu )
  • aktivujte příkazem: active
  • hotovo = oprava je sice snadná, ale chvilku mi trvalo, než mi došlo v čem je problém 🙂

Následně již tyto příkazy fungují jak mají:

bootrec /fixmbr
bootrec /rebuildbcd
bootrec /fixboot

 

Funguje v OS:

Windows Vista, Windows 2008 Server, Windows 7

WSS: The site is too large to save as a template. The size of a template cannot exceed 10485760 bytes.

Chyba:

The site is too large to save as a template. The size of a template cannot exceed 10485760 bytes.

Řešení:

Standardně je nastavena maximální velikost šablony SITE/LISTu na 10 MB, v reálném světě je to velice málo a je potřeba nastavit vyšší hodnotu pomocí příkazu:

[more]

stsadm -o setproperty -propertyname max-template-document-size -propertyvalue 104857600

Tento příkaz nastaví maximální velikost templatu na 100MB, maximální nastavitelná hodnota je 500MB.

Video tutorial instalace a konfigurace Search Serveru 2007 Express

Narazil jsem při brouzdání na MSDN na odkaz o který se rád podělím, jedná se o video tutorial instalace a konfigurace Search Serveru 2007 Express

http://www.microsoft.com/winme/0711/31250/Installation_and_Config/Default.html

EDIT:

našel jsem ještě pokračování:

http://www.microsoft.com/winme/0711/31250/End_User_Experience/Default.html

http://www.microsoft.com/winme/0711/31250/Federation/Default.html

Blog přesunut

Blog se mi konečně podařilo přesunout na vlastní doménu pavelnovotny.info, respektive se mi podařilo dokopad sebe sama, prozkoumat alternativy blogovacích nástrojů a pustit se do toho. Nakonec jsem použil BlogEngine.NET, hlavně pro svoji rychlou a snadnou instalaci, konfiguraci, skinovatelnost – vše bez nutnosti hlubokého zkoumání dokumentace, šlo to tak nějak samo.

Programové nastavení UseUnsafeHeaderParsing

Vzhledem k častému rozpadání spojení při volání některých java webservices serverů je nutné buď vypnout keep alive nebo nastavit useUnsafeHeaderParsing. První metoda výrazným způsobem ovlivní výkon, protože se při každém requestu znovu navazuje tcp spojení, druhá se zase doporučuje pouze u „bezpečných“ serverů, u kterých nehrozí nebezpečí útoků pomocí přetečení bufferu.

V případě projektů, při kterých je i server v naší režii, je určitě lepší cesta nastavením useUnsafeHeaderParsing, to je možné jak v app.config, tak i programově pomocí reflexe:

Nastavení v app.config:

<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing = "true"/>
</settings>
</system.net>

Programové nastavení pomocí reflexe:

[more]

public static bool SetAllowUnsafeHeaderParsing()
        {
            Assembly aNetAssembly = Assembly.GetAssembly(
              typeof(System.Net.Configuration.SettingsSection));
            if (aNetAssembly != null)
            {
                Type aSettingsType = aNetAssembly.GetType(
                  "System.Net.Configuration.SettingsSectionInternal");
                if (aSettingsType != null)
                {
                    object anInstance = aSettingsType.InvokeMember("Section",
                      BindingFlags.Static | BindingFlags.GetProperty
                      | BindingFlags.NonPublic, null, null, new object[] { });
                    if (anInstance != null)
                    {
                        FieldInfo aUseUnsafeHeaderParsing = aSettingsType.GetField(
                          "useUnsafeHeaderParsing",
                          BindingFlags.NonPublic | BindingFlags.Instance);
                        if (aUseUnsafeHeaderParsing != null)
                        {
                            aUseUnsafeHeaderParsing.SetValue(anInstance, true);
                            return true;
                        }
                    }
                }
            }
            return false;
        }

Více zde: http://msdn.microsoft.com/en-us/library/system.net.configuration.httpwebrequestelement.useunsafeheaderparsing.aspx

Zobrazení call stack při chybě

Sharepoint standardně při vzniku exception zobrazuje pouze její message, nikoliv i kompletní call stack, pro zobrazení všech detailů je potřeba modifikovat web.config následovně:

 

<customErrors mode="Off" />

<compilation debug="true">

 a ještě:

<SafeMode MaxControls="200" CallStack="true" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false">

nebo ještě lepší způsob je mofikace systémovými prostředky Sharepointu, tedy prostředníctvím objektu SPWebConfigModification:

SPWebApplication webApp = siteCollection.WebApplication;
SPWebConfigModification callStackModification = 
     new SPWebConfigModification("CallStack", "configuration/SharePoint/SafeMode");
callStackModification.Value = "true";
callStackModification.Owner = typeof(Program).FullName;
callStackModification.Sequence = 0;
callStackModification.Type = 
     SPWebConfigModification.SPWebConfigModificationType.EnsureAttribute;
SPWebConfigModification customErrorsModification = 
     new SPWebConfigModification("mode", "configuration/system.web/customErrors");
customErrorsModification.Value = "Off";
customErrorsModification.Owner = typeof(Program).FullName;
customErrorsModification.Sequence = 1;
customErrorsModification.Type = 
     SPWebConfigModification.SPWebConfigModificationType.EnsureAttribute;
SPWebConfigModification debugModification = 
     new SPWebConfigModification("debug", "configuration/system.web/compilation");
debugModification.Value = "true";
debugModification.Owner = typeof(Program).FullName;
debugModification.Sequence = 2;
debugModification.Type = 
     SPWebConfigModification.SPWebConfigModificationType.EnsureAttribute;
webApp.WebConfigModifications.Add(callStackModification);
webApp.WebConfigModifications.Add(customErrorsModification);
webApp.WebConfigModifications.Add(debugModification);
webApp.Farm.Services.GetValue<SPWebService>().ApplyWebConfigModifications();
webApp.Update();