ÁghyBlog

A Hungarian SharePoint User Group (HUNSUG) hamarosan újabb találkozót tart, a téma ezúttal a SharePoint 2010 Upgrade.

• Időpont: 2010. szeptember 21. 17:00
• Helyszín: Microsoft Magyarország, Kőrösök terem
• Előadó: Joel Oleson (Online roundtable meeting)

Jelentkezés és bővebb információ a HUNSUG Facebook oldalán.

Ide kapcsolódik a következő változás is. A HUNSUG eddig egy zártkörű site-ot tudhatott magáénak, ám egyre nagyobb igény mutatkozott egy igazi közösségi site iránt. Ezért született meg a HUNSUG hivatalos Facebook oldala, ahol ezentúl minden fontos információt, eseményt, akciót, állásajánlatot, stb. megosztunk Veletek, egymással. Csatlakozz Te is, hogy ne maradj le semmiről!

Természetesen PowerShell René Hézser írja le, hogyan lehet PS-ből letölteni minden előkövetelményt, és hogyan lehet szintén PS-ből automatikusan telepíteni is azokat: How To install SharePoint 2010 prerequisites automatically

Szép!

A SharePoint alapú rendszerek tervezése során gyakran kell szembesülnöm azzal, hogy sokak számára a SharePoint jogosultságkezelése egyfajta misztikum (értem ezalatt az üzemeltetőket, fejlesztőket és végfelhasználókat egyaránt). Pedig a dolog nem is olyan nagy ördöngősség.

A SharePoint maga nem végez felhasználó-hitelesítést (authentication), ezt a feladatot valamelyik alatta lévő rétegre, az ASP.NET-re vagy az IIS-re bízza. Mivel leggyakrabban intranetes portálok kialakítására használják a SharePointot, alapértelmezés szerint az IIS Windows Integrated Authentication van bekapcsolva, ez a felhasználókat az Active Directoryból vagy a helyi számítógép felhasználói közül veszi.

A SharePoint jogosultságkezelése tehát alapértelmezésben Active Directory-alapú, de van lehetőségünk más authentikációs módot is választani (pl. Extranet esetében javasolt a Form Based Authentication, FBA). Ahhoz, hogy a különféle típusú felhasználókat és felhasználói csoportokat egységesen kezelhessük, SharePoint oldalon is lehetőségünk van csoportok definiálására, valamint felhasználók közvetlen hozzáadására. Ezekbe a csoportokba egyedi felhasználók vagy AD csoportok is tartozhatnak, ám SharePoint csoportok egymásba szervezésére nincs lehetőségünk. A különféle tartalmakhoz ezeket a SharePoint csoportokat (valamint az AD csoportokat és felhasználókat) rendelhetjük hozzá különféle jogosultságokkal.

Fontos, hogy azok a felhasználók, akik vagy közvetlenül, vagy valamilyen csoporton keresztül nem kerültek hozzárendelésre semmilyen SharePoint tartalomhoz, nem férhetnek hozzá ezekhez, még csak nem is láthatják ezek létezését. Egyetlen kivétel lehet csupán: ha engedélyeztük az Anonymous hozzáférést (pl. Internet esetében). Ebben az esetben a nem nyilvántartott felhasználók az általános anonim hozzáférési jogokat kapják meg.

A hozzáférést több szinten definiálhatjuk, s ezek között fentről lefelé öröklődhetnek a jogosultságok, vagy minden szinten egyedi jogosultságokat definiálhatunk. Ezek a jogosultsági szintek, tartalmi oldalról a következők:

• site collection
• site
• lista / dokumentumtár
• mappa
• listaelem / dokumentum

Sajnos jogosultságok más dimenzió mentén történő meghatározására nincs lehetőségünk. Így nem határozhatjuk meg, hogy az adott elem bizonyos oszlopait csak a felhasználók egy köre láthassa, s másik oszlophalmazt pedig másik felhasználói csoport. Ugyancsak nincs lehetőségünk arra sem, hogy listanézetekhez definiáljuknk hozzáférési szabályokat.

Jogosultsági szintek, elemi jogok

A fentieken túl természetesen azt is meg kell mondanunk, hogy az adott felhasználó(k), csoport(ok) milyen joggal fér(nek) hozzá az adott tartalmakhoz. Ezt úgy valósíthatjuk meg, hogy az egyes tartalom-csoport(/user) párokhoz hozzárendelünk előre definiált jogosultsági szinteket. Például a Tartalomszerkesztő csoport tagjai a Közérdekű Hírek listához "módosítási" és "értesítésküldő" jogosultsági szinten férnek hozzá.

Ezek a jogosultsági szintek elemi jogokból épülnek fel. Az alapértelmezett, beépített szinteken túl természetesen nekünk is van lehetőségünk újabb jogosultsági szintek definiálására (pl. az "értesítésküldő" szintet senki ne keresse by default ;-)). Néhány elemi jogosultság, melyekből építkezhetünk:

• lista elem létrehozása
• lista elem szerkesztése
• lista elem törlése
• dokumentumverziók megtekintése
• dokumentumverziók törlése
• kivétel felüldefiniálása
• figyelmeztetések küldése/kezelése (más felhasználóknak is!)
• jogosultságok kezelése
• tartalmak létrehozása
• webhelyszerkezet módosítása
• személyes nézet létrehozása
• stb.

Az elemi jogok között olyanokat is találunk, melyek egymásra épülnek, ám szerencsére ezt a SharePoint automatikusan kezeli helyettünk: ha olyan jogot adunk a jogosultsági szintet, amely más jogokra is épít, akkor vizsgálat után bekapcsolja valamennyi szükséges elemi jogot.

Kerberos

A Kerberos az MIT által kifejlesztett, ticketing-alapú authentikációs módszer, amely a jelszó alapú hitelesítés legfontosabb gyengeségeit hivatott kiküszöbölni: A kliens kérésekre a Kerberos szerver egy authentikációs jegyet (ticket) biztosít, amennyiben a kérés érvényes felhasználói azonosítót (user credential) és szolgáltatásazonosítót (Service Principal Name, SPN) tartalmaz. A kliens ezután ezt a ticket-et használja a hálózati erőforrás (esetünkben SharePoint) eléréséhez.

Microsoft Office SharePoint Server 2007 esetében az alábbi egységeket védhetjük Kerberos alapú hitelesítéssel:

• MOSS 2007 és SQL Server közötti kommunikáció;
• SharePoint Central Administration Web Application;
• Shared Services Administration Web Application;
• egyéb, tetszőleges webalkalmazás (felhasználói tartalmak, funkciók, stb.);
• Shared Service-ek.

MOSS 2007 intranet környezet esetében a Kerberos konfigurációja utólag, a telepítést és egyéb beállításokat követően történik. A gördülékeny működés érdekében ezért azt szoktam javasolni, hogy a SharePoint környezet kialakítása az alapértelmezett NTLM authentikációval történjen, s csak később, fokozatosan kerüljön bevezetésre a Kerberos.

Néhány trükk

1. A ticketing miatt a Kerberos csak hosszabb session-ök esetében lesz gyorsabb, mint az egyszerű NTLM. Ezért a Kerberos bevezetése előtt mindenképp érdemes a felhasználói szokásokat, a különféle session-ök időtartamát naplózni és elemezni. Bob Fox és Spence Harbar egyik prezentációjában találtam az alábbi, igen beszédes  összehasonlítást:

2. Kerberos alapú hitelesítést SSP-kre csak a SharePoint Infrastructure Updates (vagy természetesen az SP2) telepítése után alkalmazhatunk.

3. Egy tévhiedelem szerint a MOSS 2007 csak akkor tudja Kerberos-alapú webalkalmazásaink tartalmait felindexelni, ha az a default porton ül (TCP 80 vagy SSL 443), más portok esetében csak NTLM-mel vagy Basic Authentication-nel. – Felejtsük el, ugyanis mindez egyetlen mozdulattal kiküszöbölhető! Mégpedig úgy, ha a nem-alapértelmezett porton található webalkalmazásunkra Host Header-t definiálunk – ekkor ugyanis a SharePoint máris képes lesz bejárni és indexelni annak tartalmát.

Elkészült a SharePoint 2007 SP2 bugfix. Mint azt korábban írtam, az SP2 telepítésekor a MOSS átvált 180 napos trial verzióra, s ha nem adjuk be neki ismételten a Product Key-t, 180 nap után működése megáll. A hotfix segítségével javításra került ez az SP2 hiba, így most már bátran telepíthető.

Bovebb információ és letöltés ITT.

A SharePoint Product Group pénteken jelentette meg közleményét, mely szerint súlyos bugot találtak a SharePoint SP2-ben. Röviden arról van szó, hogy az SP2 telepítése után a szerver úgy fog viselkedni, mintha 180 napos trial lenne! – Vagyis 180 napig teljes funkcionalitással, „észrevétlenül” ketyeg a bomba, majd 180 nap után a felhasználók számára elérhetetlenné válik a teljes SharePoint. Adat, funkcionalitás és beállítások nem vesznek el.

A bug javításán dolgoznak, addig is működő workaround, ha a SharePoint szervernek újra beadjuk a product key-t.

A hivatalos redmondi közleményt itt olvashatjátok.

Első, és legfontosabb: aki Nintex Workflow-t használ, NE telepítse az SP2-t, ugyanis kompatibilitási problémákat okoz! Remélhetőleg hamarosan megjelenik az update. Bővebb infó itt.

A SharePoint AdminWikin Jeremy összegyűjtötte azokat a file-okat, melyek frissülnek/módosulnak/újak az SP2 telepítése után.

Penny pedig azt gyűjtötte össze, melyik SharePoint verziószám pontosan milyen update szintet takar.

Folyt. köv., én is most állok neki telepíteni néhány szerverre…

Megjelent végre az SP2. Leginkább Joel írását tudnám ajánlani az SP2 előnyeiről:

Performance Reliability/Stability Fixes

2. Browser support for IE 8 and improvements in tier 2 browsers (Firefox)

3. Reliability improvements in Indexing and Index Corpus

4. Security Improvements

5. New STSADM Commands including some to fix corruption and relationships (orphaning)

BONUS! Pre Upgrade Checker! - 960577 (http://support.microsoft.com/kb/960577/ ) List of all Windows SharePoint Services and SharePoint Server Pre-Upgrade Checker knowledge base articles.  This WILL Be required for the next version.

A hivatalos bejelentés pedig: http://blogs.msdn.com/sharepoint/archive/2009/04/28/announcing-service-pack-2-for-office-sharepoint-server-2007-and-windows-sharepoint-services-3-0.aspx

Hivatalosan is bejelentették: az SP2 április 28-ra várható. Az SP2-vel érkező frissítések és javítások listája itt található.

Ez az év is izgalmasan kezdődik: most jelentek meg ugyanis az első olyan ügyfelek, akik Windows Server 2008-ra upgrade-elnek, így a MOSS 2007 is átkerül erre az op.rendszerre. Nyugaton és az USA-ban lassan már az a meglepő, ha valaki Win2003-at használ, itthon úgy tűnik, most indul a hullám.

Szó ami szó, tegnap telepítenem kellett. Az op.rendszer, Windows 2008 frissen telepítve várt rám, ám sem domain nem volt, sem SQL, szóval volt még alapoznivaló bőven, de ha az emberlánya este 10 körül áll neki, időnk mint a tenger… Fél 2 után már készen is állt minden, hogy a MOSS 2007 elkezdjen felkúszni.

A többi SharePoint MVP-től tudom azonban, hogy ez a scenario elég sok “apró” meglepetéseket tartogathat, így aztán előszedtem minden ide vonatkozó korábbi levelezést és blogpostot, s ezekkel az információkkal felvértezve álltam neki a Nagy Feladatnak. Szerencsémre túl sok falba már nem ütköztem, a legfontosabbakat azonban összefoglalnám:

• A WSS 3.0 nem része a Windows Server 2008-nak, így ha valaki ezt a verziót szeretné telepíteni, külön le kell töltenie;
• A “sima” WSS 3.0 és MOSS 2007 nem megy fel Win2008-ra, úgynevezett slipstream telepítőt kell használni, melyekben már az SP1 is benne van. Ennek készítéséről Hódy Árpád már írt egy cikket, másrészt mind a WSS 3.0 SP1 Slipstream, mind a MOSS 2007 SP1 slipstream készen letölthető, innen már menni fog a dolog.
• Maga a telepítés és a Config Wizard futtatása simán ment, a Central Administration megfelelő működéséhez azonban szükség volt arra, hogy a site-ot az IE Intranet zónájához adjam. Nekem egyszerűen nem ment pl. a Web Application létrehozás (OK gomb lenyomása után semmi nem történt), de pl. Reza JavaScript errorokat is kapott. Nekem elég volt hozzáadni a site-ot az Intranet zónához, majd frissíteni a böngésző tartalmát, ő (és sokan mások) ennél nehezebben tudta csak megoldani a dolgot.

Most jöhetnek az éles telepítések, ügyfeleknél, valódi üzleti környezetben…

Tegnap érdekes tapasztalatot szereztem egy ügyfél-telepítés során. Frissen telepített MOSS farm várt rám, hogy konfiguráljam, illetve másik farmon lévő tartalmakat, custom feature-öket migráljak át rá. Egyszerűnek tűnt a történet: egyetlen MOSS szerver, a háttérben különálló SQL 2005-tel. Egyszerűnek tűnt, de…

A tartalmi adatbázis (content database) készen állt, létrehoztuk az új webalkalmazást (Web application), hozzácsatoltuk a meglévő adatbázist, s minden jónak is tűnt. Ok, a tartalom készen áll, konfiguráljuk és állítsuk be a szükséges dolgokat… Például a keresést, ami aztán tényleg nem lehet bonyolult ezek után: Central Administration, Operations fül, ott pedig Services on Server - indítsuk el a WSS Search Service-t, és az Office Server Search Service-t.

Hoppá! A második service nincs a listában! Sőt, a Server roles lista is teljesen diasbled… Ezért aztán nem tudjuk beállítani a keresést, nem tudunk SSP-t létrehozni, stb. Ha kiadjuk az STSADM -osearch parancsot, “No Search Service” hibaüzenetet kapunk.

Valami tehát op. rendszer vagy adatbázis szinten nem stimmel (igen, a .NET framework 3.5 SP1 történet után kicsit paranoid lettem…). Már a sikítás határán voltam… Szerencsére ehelyett megkérdeztem Bobot és Pault, van-e ötletük. Azt ajánlották, nézzem meg, véletlenül nem Web Front-end telepítés történt-e Complete mód helyett. S lám, a telepítési naplóban találtam egy ilyen bejegyzést: “Setting server role to WFE.”

Itt kezdtem sikítani. A WFE telepítés ugyanis nem teszi lehetővé az Indexing service elindítását.

Szedjünk le mindent, s telepítsük újra az egészet Complete módban, SP1-gyel, Language Pack-kel, stb. És igen: az Office SharePoint Server Search service megjelent a listában, és el tudtuk indítani! Sőt, a Server role lista is működni kezdett, ahogyan azt vártuk is.

A tanulság tehát: a SharePoint telepítés során nagyon könnyű “eltévedni” (akár véletlenül is). Figyeljünk tehát oda, mikor melyik opciót választjuk, különben később lesz nehéz helyrehozni a rendszert. Farmon belül tehát először egy Complete szervert telepítsünk, s csak utána adjunk hozzá Web front-end-eket, de önállóan soha ne hozzunk létre WFE-t!

Paul bejegyzését a beszélgetésünkről az alábbi címen olvashatjátok: http://paulgalvin.spaces.live.com/Blog/cns!1CC1EDB3DAA9B8AA!2748.entry

Várhatóan 2009 február és április között érkezik a WSS 3.0 és a MOSS 2007 újabb javítócsomagja, az SP2. A legfontosabb várható frissítések:

• Office client:
• Improved Outlook Calendaring Reliability
• Improved Outlook Performance
• Enabling Object Model support for Charts in PowerPoint and Word
• Improved cryptographic functionality by supporting all cryptographic algorithms offered by the operating system
• Improved functionality in Excel’s charting mechanism
• Ability to ungroup SmartArt graphics (and as a result, the ability to add animations to them in PowerPoint)
• Ability for Visio to export UML models to an XML file compliant with the XMI standard
• Tool that enables the uninstall of Office client Service Packs
• SharePoint server:
• Performance and manageability improvements to variations in Enterprise Content Management (ECM) including STSADM commands for repairing links between source and target pages
• Improvements around processing status approvals from Office Project Web Access into Office Project Professional 2007
• Improvements to read-only content databases and index rebuild timer jobs in Windows SharePoint Services 3.0

A SharePoint Product Group honlapján olvashatjátok a részletes bejelentést,

Ügyfelünk kétségbeesetten hívott egyik délután: az éles MOSS szerverükön saját készítésű (SharePoint Designer) Workflow-kat tesztelt, és hát tűzoltásra lenne szükség: a szerver óráját előre állította 24 órával, majd vissza, s (nem meglepő módon) néhány dolog hirtelen működésképtelenné vált: a nyitóoldal nem jelenik meg, ehelyett "The Context has expired and can no logner be used." hibaüzenettel elszáll; a content query (tartalomlekérdező) kijelzők üres tartalmakkal jelennek meg, stb.

A probléma súlyosságához képest (a vállalati intranet gyakorlatilag használhatatlanná vált) a megoldás roppant egyszerű volt: az összes SharePoint service újraindítása, és egy iisreset után minden újra a régi. "Csupán" a listákhoz tartozó, időközben aktuális értesítéseket küldte ki újra a rendszer a felhasználóknak.

SharePoint 2007 alatt minden Webalkalmazás (Web Application) saját tartalom-adatbázissal (content database) rendelkezik. Természetesen minden WebApp-hoz több DB is tartozhat, sőt cserélhetjük és változtathatjuk is alatta.

De vajon miért lehet ez fontos számunkra? Természetesen nemcsak poénból Nagyon hasznos lehet akkor például, ha egy teljes site collection-t szeretnénk egyik helyről a másikra mozgatni (pl. fejlesztői környezetből az ügyfélhez). Lássuk tehát a művelet lépéseit:

1. A szokásos módon, a Central Administration felületén hozzuk létre a Webalkalmazást. Ekkor meg kell adnunk a háttér-adatbázis nevét, legyen például “ContentDB_Tmp”.
2. Innen kezdve haladhatunk tovább a Central Admin felületén is, ám én jobban szeretem az stsadm-et (például mert szélesebb körben használható). Lássuk tehát, hogyan haladunk tovább az stsadm parancs segítségével!
3. Először is, ha nem vagyunk egészen biztosak a webalkalmazáshoz tartozó tartalom-adatbázis pontos nevében, kérdezzük le:

   stsadm -o enumcontentdbs -url http://mymoss

   <Databases Count="1">
     <ContentDatabase Server="MYDBSERVER" Name="ContentDB_Tmp" />
   </Databases>

4. Ha megvan az adatbázis neve (ContentDB_Tmp), máris törölhetjük:

   stsadm -o deletecontentdb -url http://mymoss
       -databasename ContentDB_Tmp -databaseserver MYDBSERVER

5. Ezen a ponton van tehát egy olyan webalkalmazásunk, amely üres, nem tartozik hozzá tartalom-adatbázis. Csatoljuk hozzá a régi rendszerről átmozgatottat, melynek neve példánkban ContentDB_FullContent:

   stsadm -o addcontentdb -url http://mymoss
       -databasename ContentDB_FullContent -databaseserver MYDBSERVER

6. Ennyi az egész! Végül, hogy megbizonyosodjunk a művelet sikerességéről, futtassuk le újra a legelső stsadm parancsot:

   stsadm -o enumcontentdbs -url http://mymoss

   <Databases Count="1">
     <ContentDatabase Server="MYDBSERVER" Name="ContentDB_FullContent" />
   </Databases>

Alig néhány órája érhetők el publikusan azok a WSS és MOSS update-ek. Ezek bőven többet jelentenek a szokásos hotfixeknél, hiszen a hibajavításokon túl fontos funkcionális bővítéseket is tartalmaznak. Megújult például a keresés, mind az adminisztrációs, mind a felhasználói oldalon, az új admin felület például így néz ki:

Hasonló módon találhatunk Content Deployment update-eket, hatékonyság-növelő frissítéseket, stb. A teljes feature listát, és bővebb információt a Product Group Blogjában találtok.

Egyik ügyfelünknél WSS 3.0 alapokon futott néhány alkalmazás, s most született meg az üzleti döntés: áttérnek MOSS 2007-re. A telepítés meg is történt, az üzemeltetés profin megoldotta az installálást, s vártak bennünket, hogy a meglévő tartalmakat átmigráljuk. Ez önmagában teljesen “normális” feladat, ám most némi csavar volt a történetben: az egyik feature ugyanis GUID alapján azonosítja a dokumentumokat, s a migráció során ezért arra is ügyelni kell, hogy minden tartalom megőrizze a saját GUID-ját.

Hogyan áll neki az ember egy ilyen jellegű feladatnak? - Természetesen tervezéssel. Számbavesszük, mi az, amit át kell vinnünk: site-ok, listák, dokumentumtárak, feature-ök, speciális beállítások, és speciális követelmények. Ez utóbbi csoportba tartozik a GUID-kérdés is: hogyan lehetünk egészen biztosak abban, hogy minden szép és jó marad?

A terv tehát: adatbázis-szinten végezzük el a migrációt. A WSS megfelelő content adatbázisát másoljuk át az új DB szerverre, majd etessük meg a SharePointtal. Rögtön megfogalmazom kicsit szakmaibb nyelven is, ám előtte még jött egy csavar a történetbe, ugyanis a helyszínen szembesültünk azzal a problémával, hogy az ügyfél bizony magyar nyelvű MOSS-t telepített. A WSS pedig angol volt…

Sebaj, a Language Pack csodákra képes: nem az első alkalom, hogy a magyar MOSS-t angol LP-kel fejeljük meg, több helyen volt már szükség ilyen megoldásra. Jöhet a migráció.

Állítsuk le tehát a WSS Service-eit, hogy a WSS_Content adatbázist detach-elni tudjuk. Ezután másoljuk a megfelelő MDF és LDF file-okat az új DB szerverre, és ott attach-eljük. Ha szükség van a WSS-re is a továbbiakban, akkor állítsuk vissza az eredeti adatbázist is, és indítsuk újra a WSS service-eket.

Ezután a MOSS-on hozzuk létre a megfelelő Web Application-t, de más content database névvel, példánkban legyen WSS_Content_Temp. Ezt kell majd kicserélni a régi, WSS-ről átemelt adatbázisra. Csatoljuk tehát hozzá a webalkalmazásunkhoz:

stsadm.exe -o addcontentdb -url http://<server>:<port> -databasename <content database> -databaseserver <DB Server name>

Most tehát van egy olyan Web Application-ünk a MOSS-on, amely mögött két content adatbázis van. Erre azonban semmi szükség, a Central Admin > Application Management > Content Databases oldalon töröljük a WSS_Content_Temp adatbázist, és kész is: a site collection már úgy létezik, ahogyan eredetileg a WSS-ről átemeltük. Egyetlen “aprósággal” kell még persze megfejelni a dolgot: a megfelelő feature-ök telepítése és aktiválása után már használatba is vehetjük, s láss csodát: minden ugyanúgy működik, mint a korábbi WSS-en.

Megmaradtak a GUID-ok, a Created By és Last Modified By mezők is megtartották eredeti értéküket, s nem vették fel a migrációt végző felhasználót - az egész folyamat tehát transzparens maradhatott, egyedül az új URL-ből veszik észre a felhasználók, hogy valami történt. És persze azokból a plusz funkciókból, melyeket a MOSS-tól kapnak, szép fokozatosan.