Safranka Mátyás Microsoft Consulting Services WSS és SPS üzemeltetési tapasztalatok a gépteremből Safranka Mátyás Microsoft Consulting Services

Napirend WSS és SPS bevezető SPS architektúra Keresés, indexelés IIS beállítások Mentés, visszaállítás Antivírus Hasznos tippek

Miért? Egyre több WSS, SPS implementáció SPS Pilotok tapasztalatai Csoport munka Portál Fájlszerver++ SPS Pilotok tapasztalatai Próba rendszerek kerülnek éles használatba Fejlesztők vs. Üzemeltetők „Fejlesztő kiszolgáló” sztereotípia Fejlesztők és üzemeltetők kommunikációja SPS üzemeltetési kérdések mellőzése

WSS vs. SPS Windows SharePoint Services (WSS) Csoport munka támogatás Ingyenes Windows Server 2003 FP Más termékek is építenek rá (pl.: Project Server, SPS) SharePoint Portal Server 2003 (SPS) Csoport munka ÉS portál funkciók A WSS szolgáltatásokra épül Keresés szolgáltatás, portál és nem portál tartalmakra is Nagyvállalati igények szerint kialakítva

Verziók és termékek Windows SharePoint Services 2.0 SP2 SQL 2005 támogatás .NET 2.0 támogatás (de nem követelmény) Reverse Proxy támogatás 64 biten futás (32 bit emulációval ) A Language Template Pack SP2 is kell(het) SharePoint Portal Server 2003 SP2 Először kell a WSS SP2

WSS telepítése DC-re (SBS) A DCpromo UTÁN kell telepíteni az IIS-t Egyébként nem támogatott Ellenkező esetben: Hitelesítési probléma a Central Admin siteon Javítása: aspnet_regiis futtatása IIS_WPG, ASPNET és Network Service jogok beállítása

SPS architektúra

SPS Kiszolgálói szerepek Web A web kiszolgálók feladata az SPS portálok és WSS (Windows SharePoint Services) oldalak webes felületének megjelenítése. Keresés (Search) A keresés funkciót biztosító komponens feladata, hogy a beérkező keresési kéréseket a meglevő index állományok alapján feldolgozza Indexelés (Index) Az indexelés szolgáltatás feladata, hogy a portál tartalmakban, WSS oldalakban, feltöltött dokumentumokban vagy egyéb intranetes helyeken tárolt tartalmakban (pl.: Exchange nyilvános mappák, fájlkiszolgálók) tárolt dokumentumok teljes tartalomra keresés index állományát elkészítsék. Egy tartalmat csak egy index kiszolgáló járhat be. Feladat (Job) A Feladat (job) kiszolgáló feladata, hogy kezelje az WSS-ben nem levő SPS funkciókat, mint például: Single-Sign on oldalak, felhasználói profil importálás, látogatottsági statisztikák készítése, portál tartalmak bejárása, értesítések szolgáltatás kezelése Adatbázis Az SPS konfigurációs adatok, portál és felhasználói adatok valamint feltöltött tartalmak tárolását végző SQL adatbázis kiszolgáló (SharePoint komponens nem települ rá)

Egy kiszolgáló <1000 felhasználó Adatbázis: SQL2000/2005 MSDE Nincs nagy rendelkezésre állás

Közepes farm <20000 felhasználó Adatbázis Front-End SQL 2000/2005 Fürtözött (MSCS) Front-End Fürtözött (NLBS) Mentés Nagy rendelkezésre állás Index szerver nem single point of failure Az indexelés szolgáltatás feladata, hogy a tárolt dokumentumok teljes tartalomra keresés index állományát elkészítsék.

Nagyméretű farm >100000 felhasználó Adatbázis Front-End Index SQL 2000/2005 Fürtözött (MSCS) Front-End Fürtözött (NLBS) Mentés Index Külön területek bejárása Nincs redundancia Egy tartalmat csak egy index kiszolgáló járhat be.

Adatbázisok <portalname>_PROF Felhasználói profil adatok <portalname>_SITE Site-ok adattárolása, tartalom adatbázis <portalname>_SERV Portál szolgáltatások információinak tárolása (pl. keresés, értesítés) SPS01_Config_db (alap név) SPS farm konfiguráció, keresési beállítások, stb. STS_<…> WSS-ben létrehozott tartalom adatbázisok

Szolgáltatás fiókok Kiszolgálófarm fiók beállítások Konfigurációs adatbázis Tartalom hozzáférés Portál alkalmazás készlet Windows szolgáltatások fiókja Javaslat: mindegyik legyen azonos fiók Nem biztonsági kockázat Támogatott SharePoint felügyeleti csoport tagja legyen mindegyik account A szerviz accountok kezelésével kapcsolatban eltér az Administrators’ Guide és a Sharepoint Support álláspontja. Mindkét gyakorlat megfelelő, elfogadott és támogatott. A szerviz accountok kezelésének elsődleges helye a Central Administration ’Configure Server Farm Account Settings’ lapja. Az Administrators’ Guide azt javasolja, hogy a lapon található három, különböző funkciót három külön account lássa el. A Terméktámogatásnál leszűrődött tapasztalatok alapján, az egyszerűség elvét követve egyetlen account használatát javasoljuk mindhárom funkció betöltésére, mivel ez nem jelent biztonsági kompromisszumot. A használt account mindenféleképp tagja kell, hogy legyen a Central Administration ’Set Sharepoint Administrative Group Account’ lapján megjelölt felhasználói csoportnak. A Sharepointok accountjai a rendszerben a következő helyeken jelennek meg: -Az IIS-ben a Sharepoint webhelyekhez (beleértve a portálokat) tartozó Application Pool-ok Identity accountjaként (alapértelmezésben CentralAdminAppPool és MSSharepointPortalAppPool) -A Sharepointhoz tartozó szervizek (Microsoft SharepointPS Search, Sharepoint Portal Administration, Sharepoint Portal Alert, Sharepoint Timer Service). A Sharepoint szerviz accountoknak a következő csoportokban kell tagnak lenni: -a szerveren helyi csoportok: Administrators (esetleg Power Users), IIS_WPG, SPS_WPG, STS_WPG, SPS_Query -az SQL Serveren a szerver szerepkörök között Security Adminstrator és Database Creator, az adatbázis szerepkörök között minden SPS adatbázisnál db_owner legyen. © 2002 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Jogosultságaik (folyt.) Csoporttagságok: Power users IIS_WPG SPS_WPG STS_WPG SPS_Query SQL jogok: Security Administrator Database Creator SQL adatbázis jogok: db_owner az SPS és WSS adatbázisokon

Hardver skálázódás Front-End Index Back-End SQL Memória és processzor intenzív műveletek Oldalra skálázódik jobban Mentés diszk igénye! Index Processzor intenzív Hálózat intenzív Felfelé skálázódik, oldalra tartalom bontással Back-End SQL Diszk helyigény Memória igény

Keresés, indexelés

Indexelésről általában Indexelést végzi: WSS: SQL Full-Text indexing SPS: MSSearch service Az indexelés üzemeltetési kihívásai: Minél aktuálisabb legyenek az index állományok Az indexelés erőforrás intenzív Ha az üzemi működés közben fut egy intenzív indexelés az zavart okozhat a SharePoint elérésében

Indexelés (SPS) NLBS Cluster

Indexelés típusok Full Incremental Incremental Inclusive Adaptive A leginkább erőforrás intenzív Törli a korábbi index bejegyzéseket és újra generálja Incremental Csak a változások rögzítése Nem távolítja el az indexből a törölt elemeket Incremental Inclusive Törli is az indexből a törölt elemeket Erőforrás igényesebb mint a sima Incr. Adaptive Ami az előző Adaptive crawl óta legvalószínűbb, hogy változott Idővel javul a teljesítménye Full Update During a full update, SharePoint Portal Server updates all content in a content index. A full update of a content source includes adding new content, modifying changed content, refreshing the content index for existing unchanged content, and removing deleted content from the content index. This is the most time-consuming and resource-intensive type of update, and it should be done only in the following situations: •If you create a new rule that affects only one content source.•If files are renamed in a specific content source.•If it is the first crawl of a content source.•If you include or exclude a new file type.•If permissions are changed on documents in the content source. While all updates pick up permission changes, only the full updates pick up changes to membership in local groups. This is why it is recommended that you not use local groups to secure content that SharePoint Portal Server crawls.•If there is a power outage. In this case, SharePoint will want to run full indexes to reset the index. It might be faster to reset the index files and clean them out before running a full index. (Resetting the index files is discussed in Chapter 22.)•If you change the noise word file.•If there is an area name change.•If you reset the content index.Given all these changes that will force you to rerun a full index, it is best that you plan for them so that the full indexes can be run without overloading either the indexing server or the content source’s server. Incremental Update An incremental update of a content source includes only changed content. SharePoint Portal Server does not remove deleted content from the content index and does not recrawl unchanged content. For this reason, performing an incremental update is faster than performing a full update. You can perform an incremental update if you know that content has changed but you do not want to perform a full update and you don’t mind having some deleted content continue to appear in your index. A periodic incremental update creates the index without using the time or resources required for a full update, which enables you to perform a full update less frequently. Incremental (Inclusive) SharePoint Portal Server 2003 introduces another type of update known as the incremental (inclusive) update. This update is similar to the incremental update except that it includes deleted content. The incremental (inclusive) update also detects deleted entries in the Microsoft Windows SharePoint Services document libraries and lists. The incremental update detects modified or new documents and list items only. The incremental update is the least expensive update if it is used with Windows SharePoint Services sites. The incremental (inclusive) update is more resource intensive than the regular incremental update and should therefore be run less often if performance is a top priority for you. Adaptive Update An adaptive update, like the incremental update, crawls only the content that, statistically speaking, is most likely to have changed since the last adaptive update. Because adaptive updates are likely to miss at least some content changes, these updates will crawl all the content in a content source every two weeks. Unlike the incremental update, the adaptive update increases its efficiency every time it is run based on a statistical analysis of the historical information on what content has and has not changed. The time required for an adaptive update varies and is based on the different types of content sources and the protocol handler. The recommended approach is to run adaptive updates daily for large source groups and more often for smaller source groups. Avoid running full updates whenever possible. However, how you choose to configure your index updates is dependent on your search requirements. If your organization is search intensive and requires immediate updates to the search indexes as new content is added or removed, you might need to schedule updates to occur more frequently. You must balance the search requirements with the time it takes to perform an update and propagate content indexes. There is also a scheduling factor to consider too. Updates are both processor and RAM intensive. You’ll want to ensure that you’re scheduling your updates to occur when your servers running SharePoint Portal Server and Windows SharePoint Services are not being backed up, scanned for viruses, or performing any other routine that consumes large processor resources, RAM resources, or both. In addition, you shouldn’t crawl content sources during their nightly routines either. Therefore, a best practice is to create a schedule matrix and schedule the crawling of content sources when those sources are being used the least. © 2002 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Index tartalom források Portal Content SharePoint portál tartalmak Nem jelentős erőforrás igény Alapértelemzetten a 10 percenként incr. (incl.) indexelve People Content Profilok és személyes oldalak indexelése Alapértelmezetten 60 percenként incr. indexelve Non-Portal Content Site Directory site gyűjteményei (vagyis: a WSS site-k!) Alapértelmezetten minden éjjel incr. Indexelve Ez lesz a legzűrösebb, erőforrás igényesebb Custom Exchange public folders Fájl megosztások Egyéb webes tartalmak (pl.: más Intranet portálok) Másik SharePoint-ok Lotus Notes DB-k

Javasolt beállítások Portal content Full Incr. (inclusive) Hetente egyszer Incr. (inclusive) 10 min-naponta People content Hetente 1x 60 min-naponta Non-portal content Hetente v. havonta mindenképp hétvégén, ill. üzem időn NAGYON kívül Üzem időn kívül naponta Custom Hetente , havonta függően mennyire kritikus az ott tárolt tartalom Incr. v. inct (inclusive) Üzem időn kívül, úgy hogy ne fusson bele az üzemidőbe

További index javaslatok Central Administration -> Manage The Search Service -> <index server> -> Timeout settings 90 sec Administration -> Manage The Search Service -> Manage site hit frequency rules Új site hit frequency rule: Limit max. doc. number: 10 NLBS FE-k esetén az egyik kiszolgáló elérését adjuk meg az index szervernek ne az NLBS címet Csak az egyik FE kiszolgálót használja el az indexing

IIS tuning

IIS beállítások okai FYI: Hibás beállítások eredménye lehet: SPS = ASP.NET kód + ISAPI filter .NET „rugalmas” memória használata SPS web partokkal memória fog „szivárogni” Neked memory leak, Nekünk a legjobb cache-ünk Az IIS w3wp-k időnként újra fognak indulni Hibás beállítások eredménye lehet: Nagy memória használat -> SPS elérés lassulás, fennakadások Lassú w3wp újraindulás->SPS elérés lassulás, time out-ok Elhaló w3wp-k -> SPS elérhetetlen

Adminisztráció és felügyelet IIS 6.0 emlékeztető Mini-webszerverek w3wp.exe önálló folyamatok futtatása, saját ISAPI szűrők Web Admin Service Konfiguráció- és alkalmazásfelügyelet INETINFO XML Metabase FTP NNTP SMTP Adminisztráció és felügyelet WAS Application Pool Felhasználói mód HTTP.SYS Kernel módú HTTP figyelő, és útvonalválasztó a HTTP kéréseknek Cache Kérési sorok HTTP.SYS IIS6.0 Kernel mód TCP/IP

Recycling Újrahasznosítás adott időben VM méret folyamatonként .NET memória kezelés: machine.config <processModel> Memorylimit Alap érték: 60%

Performance Kernel queue: >=1000/w3wp Web garden: Hány w3wp.exe legyen az app poolhoz Szempontok Egyik elakad egy kéréssel a többi kiszolgál w3wp újraindulásakor ott a többi Jobb processzor kihasználás Ha túl sok w3wp: Memória overhead Processzor overhead Javasolt: 2 w3wp/CPU

Health Rapid-fail protection SPS esetén: Az app magát jelenti hibásnak Hibák esetén leállítja az app poolt. SPS esetén: Tiltsuk le Menjen ameddig bír Ha hibát jelzett, de nem halt bele, menjen tovább Process elhalást az Enable pinging detektál

Backup, restore

Backup eszközök SPSBackup.exe Stsadm.exe Adatbázisok teljes mentése portálonként (kivétel ConfigDB) Gyors visszaállás katasztrófa esetén Stsadm.exe Webhely gyűjtemények mentése SPBackup utility (SPS Resource Kit) feltérképezi a webhelyeket és elkészíti mentési szkriptet az stsadm.exe-hez Egyes webhelyek visszaállíthatósága NTBackup A testre szabások, web kijelzők és sablonok mentése Ezek részben az adatbázisban részben az FE kiszolgálók fájlrendszerében tárolódnak Disaster recovery: http://www.microsoft.com/technet/prodtechnol/sppt/reskit/c2861881x.mspx

Verziók ellenőrzése Egy mentést csak azonos verziójú és nyelvű SPS/WSS-re lehet visszatölteni Mentés verzió ellenőrzése: Command Prompt: findstr -b vti_extenderversion <backup file> WSS verzió ellenőrzése http://<sps central admin:port>/vslist.aspx Enterprise Manager -> Databases -> <portalName>1_SITE -> Tables -> SystemVersion & PortalSchemaVersion

WSS és SPS verziók WSS verzió tippek SPS C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\ISAPI\owssvr.dll WSS rtm SPS-en 11.0.5530 WSS rtm 11.0.5608.0 WSS sp1 11.0.6361.0 WSS sp1 + MS05-006 11.0.6411.0 WSS sp2 11.0.6568.0 (KB 887624) SPS C:\Program Files\SharePoint Portal Server\Bin\mssrch.dll SPS rtm 11.0.5704.0 SPS sp1 11.0.6715.0 SPS sp2 11.0.8019.0 (KB887623)

Testreszabások WSS/SPS frissítések felülírhatják a testreszabáskor módosított fájlokat! Ne az eredeti template-ket módosítsuk Ghosted/un-ghosted oldalak Ghosted oldalak: ASP.NET parser Un-ghosted oldalak: WSS SafeMode parser Ghosted pages are pages whose actual content does not reside in the content database, but a corresponding row for the page can be found in the database.  For example, the default home page is a ghosted page.  New web part pages are also ghosted.  Ghosted pages are handled by the Asp.net parser.  Ghosted pages become un-ghosted once the file has been modified (e.g. using FrontPage 2003 or via web folders).  All uploaded .aspx files are automatically considered as un-ghosted.    Un-ghosted pages are routed through the WSS SafeMode parser.  The SafeMode parser a) prevents server-side code from executing and b) depends exclusively on the SafeControls list to determine which controls can, or can not, be rendered.  To determine if a page is un-ghosted, open the Query Analyzer  and run the following query against the _SITE database: SELECT DirName, LeafName, Content FROM Docs WHERE (LeafName LIKE ‘%aspx%’) If the Content is not NULL, than the page is no longer mapped to the physical files on the Front-End servers. © 2002 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Antivírusról pár szóban

Anti-vírus dolgok Fájl szintű kereséséből kihagyandó SQL Back-end: .MDF, .LDF, .NDF, .TRN, .BAK és.SLS sqlmangr.exe és sqlservr.exe SPS Front-End és Index: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\* C:\Program Files\SharePoint Portal Server\Bin\* C:\WINDOWS\Temp\FrontPageTempDir\* C:\Documents and Settings\<SPSAccount>\Local Settings\Application Data\* C:\Documents and Settings\<SPSAccount>\Local Settings\Temp\* C:\Inetpub\wwroot\* <ill. a portál könyvtára> C:\WINDOWS\system32\LogFiles W3wp.exe, cbd.exe, cidaemon.exe, owstimer.exe

AntiGen for SharePoint Sybari AntiGen for SharePoint 8.0 4 külön vírusirtó motor használata Javasolt konfiguráció: Dokumentumok ellenőrzése csak feltöltéskor Teljes adatbázis ellenőrzés hetente Állomány feltöltés szabályozás nem csak kiterjesztés alapján Telepítés: Front-End kiszolgálókra Memória használat: ~20 MB/szál Processzor használat megnő

Hasznos tippek, linkek

Ütemezések

SPS tréningek 2286: Implementing Microsoft® Windows® SharePoint® Services (eLearning) http://www.microsoftelearning.com/eLearning/offerDetail.aspx?offerId=11817 2014: Customizing Microsoft® SharePoint® Products and Technologies 2003 http://www.microsoft.com/learning/syllabi/2014bfinal.asp 8036: Designing IT Platform Collaborative Applications with Microsoft® SharePoint® 2003 Workshop http://www.microsoft.com/learning/syllabi/en-us/8036afinal.mspx

TIFF indexelés Az index kiszolgálón: Vagy: Regedit HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MSPaper Új DWORD felvétele: PerformOCR Értéke: 1 Microsoft Search service újraindítása Vagy: Support\Tools mappa az SPS 2003 CD-n Tiff_ocr_on.reg elindítása

RTF, PDF fájlok indexelése RTF fájlok: http://www.microsoft.com/sharepoint/server/techinfo/reskit/RTF_Filter.asp PDF fájlok: Adobe iFilter 6.0 letöltése és telepítés az index kiszolgálón http://www.adobe.com/support/downloads/thankyou.jsp?ftpID=2611&fileID=2457 regsvr32.exe pdffilt.dll .pdf fájlok felvétele az indexelendő fájltipusok közé

WSS lomtár/WSS app-ok WSS lomtár 30 előre elkészített WSS app: Véletlen felhasználói törlések ellen http://msdn.microsoft.com/msdnmag/issues/05/02/RecycleBinforWSS/default.aspx Nem része a alap funkcionalitásának, így a terméktámogatás nem vonatkozik rá! 30 előre elkészített WSS app: http://www.microsoft.com/technet/prodtechnol/sppt/wssapps/default.mspx Pl: Help Desk, Change Management, PR Work site, és sok egyéb üzleti és IT feladat sablonok

© 2002 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.