2008. február havi bejegyzések

MOSS blobcache

Aki ismeri az ASP.NET cache szolgáltatásait és tudja, hogy a SharePoint az ASP.NET-re épül, annak számára nem újdonság, hogy a SharePoint is támogatja az output cachinget és az object cachinget. Amit viszont nem tud az ASP.NET, de a SharePoint igen, az a blob cache.

Tudvalevő, hogy a SharePoint a megjelenítéshez használt fájlok egy részét fájl rendszerben, más részét pedig adatbázisban tárolja. A fájl rendszer gyors, az adatbázis lássú. Ezért aztán inkább azt szeretjük, ha a fájl rendszerből tudja a rendszer kiszolgálni a kéréseket. Különösen érdekes ez akkor, amikor sok apró fájlt kell visszaküldeni a kliensre, mint például az apróbb képek, stíluslapok és kliens oldali szkript fájlok.

Nevével ellentétben elsősorban ezeknek a tipikusan ritkán változó apró fájloknak a gyorsítótárazására találták ki a blob-, vagyis binary large object cache-t. Ha ezt bekapcsoljuk, akkor a kliens a webszerver fájl rendszerében közvetlenül kaphatja meg az ott tárolt fájlokat, nem kell értük elmennie a kérésnek egészen az adatbázisig.

Bekapcsolni nagyon egyszerű, web.config-ot kell módosítani. Az alábbi sztringet megtaláljuk a fájlban telepítés után, csak állítsuk az enabled tulajdonság értékét false-ról true-ra:

<BlobCache location="C:blobCache" path=".(gif|jpg|png|css|js)$" maxSize="10" enabled="true" />

A location értelemszerűen az a mappa, ahova a gyorsítótár kerül. Ezt célszerű nem az alapértelmezett helyén, a C:blobCache mappába tenni, bátran vigyük át másik meghajtóra.

A path egy reguláris kifejezés, nyugodtan átírhatjuk, alapértelmezés szerint a gif, jpg, png, css és js végződésű fájlok kerülnek a gyorsítótárba, de bővíthetjük a listát.

A maxSize paraméter a cache mérete gigabájtban, nem aprózták tehát el.

Itt ugyan nem szerepel, de létezik egy max-age attribútum is, ahol megadhatjuk, hogy a kliensek hány másodpercig tárolhatják el ezeket a fájlokat. Ez alapértelmezés szerint 86400, tehát 24 óra.

Mindezt web applicationönként állíthatjuk, tehát készüljünk fel arra, hogy esetleg több helyen is kell módosítanunk telepítés után. A Central Admin Site például tipikusan olyan, ahol ezeket a fájlokat nyugodtan lehet gyorsítótárazni, az éles publikus szerverünk meg aztán végképp. A fejlesztői web applicationre viszont a kevesebb debuggolás érdekében nem érdemes bekapcsolni. Nem árt tudni, hogy draft és checked out állapotban lévő fájlokat a rendszer nem cache-el.

A cache-t természetesen lehet üríteni is, ám itt jön az igazi csavar, az opciót ugyanis nem web application, hanem site collection szinten vezették ki a felhasználói felületre. Ehhez tehát:

  1. Navigáljunk el a Site Settings oldalra, majd ott kattintsunk a Go to top level site settings linkre.
  2. A Site Collection Administration oszlopban kattintsunk a Site collection object cache linkre. Ez nem azt jelenti, hogy a blob cache és az object cache ugyanaz. Ez azt jelenti, hogy a blob cache nem kapott saját menüpontot, hanem ide dugták az ellenség megtévesztése érdekében.
  3. A Disk based cache reset opciónál kattintsuk be a Force this server to reset its disk based cache opciót. Vigyázat, ez az egész szerver összes webalkalmazásának gyorsítótárát törölni fogja!

Tehát bekapcsolni web application szinten lehet, az opciót site collection szinten találjuk meg, de az egész szerverre vonatkozik. Az egész farmra vonatkozó törlési lehetőséget pedig csak az object cache kapott. Igazán logikus, nem?

 

Technorati tags: , ,
Reklámok

WSS Gatherer Error 2424

Nálam MOSS-on, másnál WSS-en jelentkezett az alábbi hiba keresésnél:

Your search cannot be completed because of a service error.
Try your search again or contact your administrator for more information.

Ez pont annyira jó, mint az Unexpected error. A Windows Application logban megjelent egy 2424-es azonosítójú Error bejegyzés, aminek forrása a Windows SharePoint Services 3 Search, kategóriája pedig Gatherer, tehát gyanús, hogy van köze a fenti hibához. Lássuk az üzenetet:

Description: The update cannot be started because the content sources cannot be accessed. Fix the errors and try the update again.

Kicsivel többet mond, mint az előző, valahol a tartalom elérésénél lehet a probléma. A KB927012 szerint akkor jön elő, ha a WSS Search Service a Network Service felhasználó nevében fut. Nos, nem csak akkor. Akkor is előjöhet, ha követjük az ajánlott best practice-t és más felhasználót adunk meg a service accountként és content access accountként.

A megoldás: azonos service és content access account használata. Ehhez:

  1. Irány a SharePoint Central Administration oldal.
  2. Tovább az Operations oldalra.
  3. A Topology and Services csoportban válasszuk a Services on server hivatkozást.
  4. Kattintsunk a Windows SharePoint Services Search szolgáltatásra.
  5. Adjunk meg azonos felhasználókat a Service Account és a Content Access Account mezőknél.

Ha ez sem jönne be, akkor célszerű lehet az alábbiakkal próbálkozni:

  • IISRESET, mi más 🙂
  • A Services on Server oldalon érdemes leállítani (Stop) és újraindítani (Start) a szolgáltatást és másik adatbázist megadni. A keresés többek szerint nagyon nem szereti, ha már létező adatokkal kell együttélnie.

És ami a legszebb: találtam olyat sorstársat, aki ezután visszaállította az eredeti felhasználó nevet és jelszót, és minden működött szépen. Tehát valamilyen jogosultság állítási probléma lehet a háttérben, ami érdekes módon az SP1 telepítésekor előszeretettel jelentkezik.

 

SharePoint DCOM error 10016

SharePoint esetén – legyen az Office SharePoint Server (MOSS) vagy Windows SharePoint Services (WSS) – érdemes megszabadulni minden piros vagy sárga bejegyzéstől az eseménynaplóban, mert annyira komplex rendszerről van szó, hogy szinte minden komponense hatással van a másikra. Tehát még ha nem is tűnik relevánsnak a hiba a leírása alapján, okozhat gondot valahol teljesen máshol.

Az alábbi 10016 kódú DistributedCOM hibát például már több helyen láttam a Windows System logban:

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{61738644-F196-11D0-9953-00C04FD919C1} to the user DEMODOMSspAppPool SID (S-1-5-21-1716361853-3848672439-3488686640-1120) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

A hiba tipikusan akkor jön elő, ha nem vadul mindenhol a helyi admin felhasználót adjuk meg service accountként telepítéskor, hanem próbáljuk magunkat a least privilege elvhez tartani. Ebben az esetben az IIS application pool felhasználókra érkezik panasz, amilyen az én esetemben a Shared Service Providernél használt DEMODOMSspAppPool felhasználó.

Íme a megoldás:

  1. Nyissuk meg a Component Services MMC-t.
  2. Nyissuk ki a Component Services -> Computers -> My Computer -> DCOM config ágat.
  3. Keressük meg a rengetegben az IIS WAMREG admin Service elemet, ez ugyanis a hibaüzenetben említett {61738644-F196-11D0-9953-00C04FD919C1} .
  4. Nyissuk meg a Properties ablakot.
  5. Kattintsunk a Security fülre, majd a Launch and Activation Permissions csoportban válasszuk a Customize opciót és kattintsunk az Edit gombra.
  6. A megjelenő ACL ablakban vegyük fel a hibaüzenetben szereplő felhasználót és adjuk neki Allow Local Activation jogot.
  7. Végül eresszünk el egy IISRESET-et, mint minden SharePoint matatás végén 🙂

Természetesen létrehozhatunk egy security csoportot is, beletehetjük a felhasználókat és adhatunk annak Local Activation jogot. Ezzel nekem az volt a problémám, hogy single server scenarioban, tartományvezérlőn az Active Directory Users and Computers sehogy nem engedte, hogy az NT AUTHORITYNETWORK SERVICE felhasználót hozzáadjam egy security grouphoz.

 

Technorati Tags: ,,,

SharePoint_AdminContent adatbázis neve

"Lustaság – fél egészség, de te légy teljesen egészséges." – tartja a graffiti. Úgy látszik ezt az elvet követte az a félkegyelmű, aki Redmondban kitalálta, hogy ahelyett, hogy kitenne még egy szövegdobozt a telepítő alkalmazás felhasználói felületére, bedrótozza az adatbázis nevét a kódba. Legalábbis lényegében ezt csinálta, amikor belekódolt egy GUID-ot a SharePoint Admin Content adatbázis nevébe. Annak az egy paraméternek biztosan túl nagy lett volna a TCO-ja, ezért inkább a rendszergazdák szívjanak azzal, hogy egy ilyen idétlen nevű adatbázis kell kerülgetniük: SharePoint_AdminContent_b73dd91a-a0f2-4d8bad9f-ba4ab53b3ce3.

Szerencsére van megoldás, és mint annyiszor, most is parancssorban. Ne indítsuk el a telepítő végén a SharePoint Products and Technologies Configuration varázslót, hanem használjuk a C:Program FilesCommon FilesMicrosoft Sharedweb server extension12bin mappában található PSCONFIG segédprogramot, ami lényegében a varázsló parancssori változata. Írhatjuk például ezt:

psconfig -cmd configdb -create -server SERVER -database SharePoint_Config -user DOMAINSPDataAccess -password jelszo -admincontentdatabase SharePoint_AdminContent

ahol az adatbázisok neve SharePoint_Config és SharePoint_AdminContent, az SQL a SERVER nevű gépen található és a farm data access accountja a DOMAINSPDataAccess felhasználó, akinek a jelszava jelszo. Egyes forrásokkal ellentétben nem szükséges létrehozni előre az adatbázisokat, nekem legalábbis létrehozta őket a fenti utasítás hatására.

Következő lépésben hozzuk létre a Central Administration webhelyet szintén kódból a 9999 porton NTLM hitelesítéssel:

psconfig -cmd adminvs -provision -port 9999 -windowsauthprovider onlyusentlm

Akinek megtetszett a parancssor, végignézheti a psconfig többi kapcsolóját is, amikkel elvileg akár teljesen automatizált telepítés is elképzelhető. A többieknek pedig célszerű a Start menüből lefuttatni a varázslót, amely immár fel fogja ismerni a config és admin content adatbázisokat, valamint további számos feladatot is elvégez. Például létrehozza az Office Server Web Services nevű Web Applicationt az IIS-ben, aminek a portszámát az STSADM -setsspport kapcsolójával módosíthatjuk.

 

Technorati Tags: ,,,

Activation Error: Code 0x8007232b

Épp egy Windows Server 2008 VPC-t telepítek és aktiválás közben az alábbi sokat mondó hibaüzenetet kaptam:

Activation Error: Code 0x8007232b
DNS Name does not exist

A KB929826 szerint ez akkor fordulhat elő, ha volume-licensed mediáról akarunk Vistát telepíteni. Nálam az lett a megoldás, hogy a Computer properties ablakban a Change product key gombra kattintva megadtam ismét a termékkulcsot és hagytam, hogy utána a Windows automatikusan aktiválja magát.