ÁghyBlog

Egyik ügyfelünknél érdekes és roppant bosszantó problámával szembesültünk.

A környezet: 64 bites Windows Server 2003 SP2, rajta MOSS 2007 Enterprise, és természetesen .NET framework 2.0 és 3.0. Az SQL 2005 külön szerveren. Az egész egy fejlesztői tesztszerver, rajta kb. 1 éve folyik a munka: ez jelenti az integrációs “hidat” közöttünk és az ügyfél között: minden új fejlesztést először ide szállítunk, itt folyik a tesztelés, majd amikor funkcionálisan rendben a dolog, akkor kerül át az éles környezetbe.

Egyik új fejlesztésünkben szerettük volna használni a Linq4SP-t, ehhez pedig szükségünk volt (lett volna) a .NET framework 3.5-re is. A mi fejlesztőkörnyezetünkben csodaszépen működött minden, irány az ügyfél, a fent nevezett környezettel. Az üzemeltetés fel is készült: feltelepítette a .NET framework 3.5 SP1-et, hogy előkészítse számunkra a terepet. A solution is felment, szépnek tűnt a világ, ám a tesztelés során az eddig működő Records Center minden kérésre hibát dobott: The DevRC Records Center could not be found or accessed.

A Records Center konfigurálási hibát kizártnak tekinthettük, hiszen korábban működött, és a beállításait senki nem módosította. Azonban egészen biztosnak kellett lennünk abban, hogy nem RC oldali a hiba, nekiálltunk hát kísérletezni:

1. Átütöttük a Records Center beállításait, hogy egy másik MOSS tesztrendszer Records Centerébe küldje a dokumentumokat. Hibaüzenet ugyanaz.
2. Egy korábbi projektünk során szükség volt arra, hogy a beépített Records Center Web Service-t saját implementációra cseréljük. Ezt a web service-t élesítve az adott, problémás szerveren, továbbra is ugyanaz a hibajelenség. A web service-hez nem is érkezett meg a kérés.

Ez a két tény egyértelműen azt bizonyítja, hogy a hiba a dokumentumok elküldésekor lép fel, s nem azok RC-beli fogadásakor. De hogy valóban mi okozta, azt még bizonyítani kellett.

Leszedtem tehát a .NET framework 3.5-öt, s maradt a 3.0 és 2.0 - hibaüzenet továbbra is. Ez tehát nem elég, de feltételeztük, hogy a framework telepítése okozta a galibát, ezért mentem tovább: a 3.0 és a 2.0 is lekerült a gépről, majd újra fel. - Az ötlet jónak tűnik, ám ez a lépés ugye eléggé “belemászik” a SharePoint lelki világába, hiszen ezek adják a SP egyik legfontosabb alapját. Nem meglepő tehát, ha a framework-ök cseréje után a SharePoint megadta magát, az IIS nem tudja feldolgozni a kéréseket, s a Config Wizard sem segít.

Első lépés tehát: ASP.NET 2.0 engedélyezése az IIS-ben. A telepítés utáni alapértelmezés ugyanis Prohibited…

Haladunk, haladunk, a Central Administration már elérhető, a tartalmi oldalak azonban HTTP 403 hibát dobnak, IISRESET után is. A site tehát már elérhető, de valahol authentikációs hibába fut a kérés, ráadásul még a “háttérben” - tehát vagy IIS, vagy SQL eléréssel lesz a gond. Mivel az SQL-hez nem volt közvetlen hozzáférésünk (lévén ügyféloldali éles SQL szerverről van szó), a MOSS admin felhasználónak pedig adatbázis létrehozásához sincs joga, új webalkalmazást (web application) nem tudunk létrehozni, hogy teszteljük: az működne-e. Meglévő webalkalmazást viszont tudunk kiterjeszteni (extend web application): válasszuk tehát ezt az opciót, s a meglévő (de egyelőre működésképtelen) http://dev:80 környezetünket terjesszük ki, mondjuk az Intranet zónában, a http://dev:12345 portra. Néhány pillanat múlva azt láthatjuk, hogy a korábbi site-ok az új címen gond nélkül, ugyanúgy elérhetők, mint az egész “móka” előtt. Sőt… Feléledt az eredeti, http://dev:80 is!…

Hmmm, vajon ennek mi lehet az oka? Adatbázis-szinten a SharePoint valami olyan konfigurációs hibába futott, amely miatt az extend előtt nem tudott “mit kezdeni” a kérésekkel, most pedig az extend hatására ez a konfigurációs beállítás a helyére billent.

Rövid próba: a Records Center is működik… A http://dev:12345 törlése után tehát ismét előállt ugyanaz a környezet, mint a .NET framework 3.5 SP1telepítése előtt. - Kezdődhet a reprodukció!

Némileg módosított forgatókönyvet követtem azonban: először az SP1 nélküli, “sima” .NET framework 3.5-öt telepítettem a gépre. Láss csodát: a Records Center működik továbbra is gond nélkül. Amint viszont felkerül az SP1, a Records Center meghal.

A tanulság tehát: 64 bites környezetben, MOSS Enterprise és .NET Framework 3.5 SP1 összeakad(hat). Hogy pontosan mi történik a háttérben, és milyen egyéb feltételek játszanak még közre a hiba bekövetkezésében, azt Redmondban már vizsgálják. Reméljük, hamarosan lesz hotfix is…