Hosszadalmas nézelődés után arra jutottam, hogy a hiba oka ott keresendő, hogy az érintett megosztást az adott munkaállomás csak lassan (500-700 milisec vagy hosszabb idő alatt) tudta elérni, viszont a policy ennyit nem vár. Keresgélésem innentől célirányossá vált, és az alábbi Policy beálltásra bukkantam, mellyel a probléma orvosolható:

Local Computer Policy\Computer Configuration\Administrative Templates\System\Logon szekcióban található egy Always wait for the network at computer startup and logon beállítás. Ennek értékét kell ilyen esetben Enable-re állítani.

E beállítást követően a rendszer már szépen megvárja, hogy az érintett megosztás megfelelően beállításra kerüljön, mielőtt tovaszáguld a következő utasításunk felé…

Ennek eredményeképpen találtam rá joeware.net-re és az ott elérhető tool-okra. Ezek segítségével számos feladatot könnyedén elvégezhetünk mindenféle scriptek nélkül, így például a felhasználói könyvtárak elérési útjának módosítását is. Mintaképpen álljon itt egy home könyvtár cseréjére szolgáló egyszerű paranccsori utasítás:

adfind -b "OU=Test,DC=w2k,DC=pl" -s subtree –f "(&(objectClass=user)(objectCategory=person))" samaccountname -adcsv | admod "homeDrive::Z:" homeDirectory::\\server\homes\{{samaccountName}}

Nem is olyan bonyolult ugye? Természetesen az AD lekérdezés módosításával további szűréseket lehet egyszerűen megvalósítani…

Szép kihívás! Nézegettem és megpróbáltam logikusan gondolkodva eredményre jutni. Sok minden látszik – és a programozói múlttal érthető is – de végül teljes sikert nem tudtam elérni. A kisérletek alapján nekizuhantam a netnek és az alábbi linken egy jó és hasznos megoldást sikerült találnom:

http://exchangeserverpro.com/how-to-move-wsus-30-to-a-new-server

A cikk tiszta és világos, s így együtt már sokmindenre választ és megoldást adott. Remélem sokaknak segít még.

powercfg.exe /hibernate off

Részletesebben: http://support.microsoft.com/kb/920730

Hosszas magyarázkodás helyett álljon itten a megoldás, törölni kell a registry-ből a  HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate kulcsot (a teljes kulcsot és ami alatta van), majd újra kell indítani a Windows Update Service-t.

Akit részletesebben érdekel az nézze meg a vonatkozó blog bejegyzést.

http://support.microsoft.com/kb/938245/

A feladatot a SourceForge.net -en lehet követni, a projekt neve Magical Jelly Bean Keyfinder

The ‘Microsoft.Jet.OLEDB.4.0′ provider is not registered on the local machine

Néztem ki a fejembõl bután, mi is történt. Némi utánolvasást követõen az alábbiakat találtam:

The ‘Microsoft.Jet.OLEDB.4.0′ provider is not registered on the local machine on my Vista 64 bit machine today. I made no code changes since I run it on a 32 bit OS.

Mit is kezdhetünk ezzel a problémával? A legegyszerûbb, ha a fordításkor fixen megmondjuk, hogy ez a program x86-os üzemmódban fusson. Miképp kell ezt megtennünk?

1. Töltsük be Visual Studio-ba a projektünket
2. Válasszuk ki a projekt fájl tulajdonságait
   Ennek hatására az alábbi ablak jelenik meg:
   
3. Válasszuk ki a Build fület
4. Állítsuk be a Platform Target-et x86-ra
5. Fordítsuk újra az alkalmazást

Ezt követõen a programunk szépen fog mûködni. A kérdés már csak az, hogy miért is nem lehet ezt x64 alatt simán futtatni? Miért nem tudja ezt a fõ zászlóshajók egyike sem (Vista x64, Windows2008 Server) futtatni?
Merõ luxus és felvágás csak ez az x64!

Lapzárta után érkezett:
Amúgy az MS KB-k között van egy cikk ami sokak szerint megoldás: http://support.microsoft.com/kb/278604

Nekültem tehát, hogy az eddig mostohaként kezelt – értsd nem használt – felhasználó kezelést megismerjem és használatba vegyem. Elsõ lépésben áttekintettem mit is nyújt számomra az IIS 7 majd átnéztem milyen kontrolok és lehetõségek vannak az ASP.NET 3.5 felületen – a Visual Studio 2008-ból elérhetõen – a kezemben. A terület elsõre sem rövid – hát még ha az ember bele is mélyed – de azért megpróbálom a benyomásaimat érthetõ formára hozva felvésni.

Nézzük mire is jutottam.

IIS 7.0 ASP.NET szolgáltatásai

Elsõ lépésben elõvettem teszt virtuális környezetemet és feltettem rá az IIS 7-t (meg persze elõtte a Windows 2008 Standard Servert ). Kellemes meglepetés fogadott üzemeltetõi szemmel nézve a dolgokat, mert elérhetõ és kényelmesen kezelhetõ minden olyan szolgáltatás amit a fejlesztõi felületen ASP.NET Configuration site-n keresztül lehet használni (sõt még további “apróságok” is).

Amint az a fenti képeken is jól látható, az IIS 7 gyárilag tartalmazza már a Role, az User és a többi komponens adminisztrációjához szükséges felületeket. Ezen felül valóban lehet adminisztrálni is ezeket, azaz már egy üzemi szolgáltatásnak nem feltétele, hogy az ember saját maga megírja az adminisztrációhoz szükséges alapvetõ felületeket. Gondoljunk csak arra, hogy éles üzemben bármikor szólhatnak, hogy nézzünk utána ennek vagy annak a felhasználónak létezik-e, és az ember nem szeret ilyenkor SQL táblákban és query-kben kutakodni. Természetesen fontos az is – amennyiben másképp nem rendelkezünk – a rendszer titkosítva tárolja a felhasználói azonosítás során kapott jelszavakat (hány rendszer bukik meg ezen apró de lényeges kérdésen a SOX auditok kapcsán).

Melyek a legfontosabb beállítási lehetõségek – szerintem -, vegyük Őket sorba:

• Alkalmazás beállítások
• Machine Key beállítások
• Felhasználókezelés és beállításai
• Role-ok beállítása
• Connection String-ek kezelése
• SMTP beállítások
• Session State kezelés beállításai

Van még egy fontos beállításokat tartalmazó terület, ez az Application Pool kezelését szabályzó rész.

IIS 7 ASP.NET Alkalmazás beállítások

Az alkalmazás paramétereit számos helyen és módon szabályozhatjuk az IIS 7-ben. Ezeket jellemzõen egy rendszerben csak egyszer állítunk be, illetve nem mindennap módosítjuk, hisz ezek nagyban befolyásolják rendszerünk mûködését.

Elsõ legfontosabb terület, hogy az alkalmazás fix paramétereit tudjuk könnyen kezelni (Application Settings). Az itt kezelt paramétereket a webes alkalmazásunk mint állandókat alkalmazza, de nekünk lehetõségünk van arra, hogy az egyes paramétereket minden esetben külön-külön szabályozhassuk.

Az alkalmazás mûködésének következõ beállítási felülete, az ASP.NET kódlapkezeléseket szabályzó oldala, az ASP.NET Globalization oldal. Ezen az oldalon egyenként adhatjuk meg, hogy a rendser mely fájlokat milyen kódlap szerint kezeljen alapértelmezésben (nem semmi! Ezzel régebben azért volt nyûg).

Ezután jön egy fontos beállítási lehetõség, a Machine Key beállítások halmaza. A képet nézve szerintem nem kell sok magyarázat ahhoz miket is lehet itt szabályozni. Fontos és lényeges, hogy itt kell beállítani milyen módon kezeljük a hozzánk érkezõ bizalmas adatokat, és miképp tároljuk azokat.

Ezek után már csak egy rész maradt, itt a folyamatszálak kezelését lehet szabályozni.

Kapcsolati stringek

Az egyes alkalmazások mûködése során jelentõs fontosságú, hogy mikor merre és milyen paraméterekkel kapcsolódunk az alkalmazás által használt adatbázisokhoz. A rendszer alapértelmezésben alkalmazott LocalSqlServer kapcsolata mellett a számunkra illetve az alkalmazásunk számára szükséges mennyiségû kapcsolati stringet vehetünk fel.

Érdekesség, hogy a LocalSqlServer kapcsolat mûködése alapértelmezésben az adatbázishoz csak a futásidõben kapcsolódó adatbázis szolgálja ki, amely alapesetben az ASP.NET DataDirectory-ban (/app_data) található aspnetdb.mdf fájl. Amennyiben a rendszerünk kiszolgálását nem MS SQL 2005 Express szolgálja ki, úgy ezen a beállításon – a számunkra szükséges módon – de változtatnunk kell!

SMTP E-mail beállítások

Amennyiben az alkalmazásunk bármilyen oknál fogva levelezni kíván – akár a felhasználókezelés miatt, akár általunk programozottan – akkor szükségünk van az E-mail szolgáltatások elérésének beállítására. Ezt az ASP.NET E-mail beállítások-nál tehetjük meg.

A beállítások értelmezése nem bonyolult, egy fontos dolog van, amennyiben az SMTP szerverhez a Use Localhost kapcsolót kapcsoljuk be, akkor szükségünk van a szerverünkre telepített – és megfelelõen konfigurált – SMTP szolgáltatásra. Ez alapértelmezésben megtalálható az IIS szolgáltatások között, de természetesen telepíthetünk a szerverre Exchange szervert is.

Role-k

A role-k az alkalmazásunk felhasználóinak logikai csoportosítását teszi lehetõvé, akár secuirty group-nak is kezelhetjük. Adminisztrációja roppant egyszerû, hisz csak egy nevet kell felvenni, vagy módosítani. Figyeljünk azomban arra, hogy az alkalmazás programozása során a neveket fixen kell “beégetni”, azaz ne nagyon piszkáljuk el a neveket, ha az alkalmazás forráskódja nincs a kezünkben!

Felhasználók kezelése

Végül eljutottunk az egész másik fontos részéhez a felhasználók kezelésének adminisztrációjához. A rendszer alapértelmezésben az ASP.NET felhasználókezelésében csak a gyári paramétereket kezeli, de ezeket – amennyiben szabályosan konfiguráljuk a rendszerünket a web.config fájlban – mi magunk is szabályozhatjuk. Az így megadott konfiguráció a kezelõfelületek is mûködését is szabályozzák!

Persze nem kis dolog, hogy listázni lehet a felhasználóinkat, de ugyanilyen fontos az is, hogy mi magunk is felvehetünk felhasználókat. Ezen felhasználókat az Add .NET User wizard-on keresztük vehetjük fel.

A felvehetõ paraméterek ebben az esetben csak a gyári adatok – míg a webes felület felvételi részén további paramétereket is “kikényszeríthetünk”, felvehetünk. Lényeges, hogy a Wizard is figyeli a web.config fájlban megadott jelszó szabályokat. Alapértelmezésben – ha másképp nem szabályozzuk – a rendszer minimális jelszóhossza 7 karakter, és ebbõl legalább egy karakter nem alfanumerikus jel kell legyen.
Második lépésben a meg kell adnunk, hogy felhasználónk milyen role-k birtokosa. Ezt egyszerûen az érintett role-k bekattintásával végezhetjük el.

Ezt követõen a Finish gomb megnyomására a rendszer elvégzi a szükséges ellenõrzéseket, majd – ha semmilyen gondot nem érzékel – akkor létrehozza a szükséges felhasználót. A felhasználónk automatikusan aktív állapotú lesz, és ezt követõen akár azonnal bejelentkezhet és használhatja alkalmazásunkat.

ASP.NET 3.x felhasználókezelési szolgáltatásait – az olvashatóság és kezelhetõség végett – egy következõ bejegyzésben tárgyalom.

Régebben a kiállításokon valódi szakmai élet volt, körbejártak az emberek, megnézték mi is van a másiknál, van-e a fennálló problémáikra másnál megoldás, stb. Tudom, ma már szinte mindenki a neten keresgeti a szükséges megoldásokat, de akkor minek is kellenek ezek az összejövetelek? Én egyre kevésbé tudom a választ… van aki esetleg tudja?

Ja és még valami apróság, Fóti Marci panaszkodott, hogy a hozzáértés szintjét jól jellemzi az alábbi látogatói észrevétel ami a virtuális labor gépei elõtt játszódott ma le:

Megnéztem mi fut a gépeken, de csak XP. Akkor mehetünk is az nekem is van!

Hmm. A gépeken Virtual PC volt rajtuk a Win Srv 2008 és mindenféle egyéb nyalánkság… Szóval kinek is tartjuk ezeket a bemutatókat? Miért is?

A kommenteket nézegetve megdöbbentõ volt látni, hogy még mindig mekkora elfogultsággal és bigottsággal nézik emberek az IT rendszereket. Míg a bejegyzés az alábbi érdekes két bekezdést tartalmazta:

Az igazgató – aki szerint ezek a dolgok mûködnek jól a nyílt forrású közösségben – példákat ír arra, hogy hogyan alkalmazták ezeket az elveket a Windows Server 2008 fejlesztése során. Bevallotta, hogy tanultak és folyamatosan tanulnak a nyílt forrású fejlesztési elvekbõl.

Sam Ramji elõadást fog tartani errõl San Francisco-ban az Open Source Business Conference rendezvényen, aholis a Linux Foundation részérõl Jim Zemlin fog beszélni arról, hogy “Mit tanulhat a nyílt forrás a Microsoft-tól és a proprietary világtól” címmel.

Addig magyar barátainakt nem ez, hanem a “lopnak tõlünk”, felhang kötötte le! Elképesztõ! Fel kéne már odáig nõni embereknek, hogy szinte semmi sem most kitalált dolog, hanem az eredeti “õs” számítástechnika megfelelõ adoptációja. Az egész LINUX-WINDOWS hitvita teljesen elképeszt újra és újra. Miért hiszi bárki, hogy az egyik jobb mint a másik? Nincs szent grál, csak egyik vagy másik feladatnak jobban megfelelõ, vagy kevésbé alkalmas rendszer. És itt már nem csak a bitszintû dolgokkal kéne foglalkozni!

Az eredeti cikk Port25 oldalán, a HUP.HU cikke – és bejegyzései – meg a hup oldalán olvasható.

A következõ idõszak igencsak mozgalmas lesz, de nézzük csak miért:

• Jön a Microsoft Windows 2008 beharangozó kampánysorozata, melyben mi is mint Aranyfokozatú támogató részt fogunk venni. Ezen elõadássorozat alatt számos eseményen meg kell jelenni, és demonstárlni az új eszközök nyújtotta lehetõségeket. Mi természetesen a Visual Studio Team Systems 2008-at mutatjuk be, és megpróbálunk az érdeklõdõknek megfelelni. Az elsõ elõadás március 5 Lurdy ház…
• Második fõ irányunk az MS termékeken belül a Dynamics CRM vonal, ahol szintén most fog megjelenni új termékváltozat (bár a 4.0 elvben elérhetõ már, de csak angolul, március végével lesz magyar változat is ). Ennek kapcsán lesz – szintén a Lurdy házban – máricus 20-n egy elõadás amelyen én is tartok majd egy 30 perces prezit az eszköz igényekhez való igazításáról, annak feltételeirõl és lehetõségeirõl. Természetesen az alapok mellett megmutatom milyen plusz fejlesztéseink vannak a CRM-ban a különbözõ kereskedelmi problémák megoldására. Szép kihívás mindezt 30 percben áttekinteni…
• Aztán jön a hó végefelé a CA Development Buddy Summit, ahol a CA megmutatja, elmondja miképp is vélekedik a világról, mit milyen termékkel tud és szeretne kiszolgálni, és megtudjuk azt is mindezt miképp ajánlja, javasolja. Érdekes, nagyon várt dolog ez részemrõl, hisz a Service Management terület a fõ érdeklõdési terület amihez egy kicsit lassacskán tán konyítok is.
• Márciustól meg indul egy nagyszabású felmérési, tervezési projekt, amibe meghívást kaptam. Érdekes munkának ígérkezik, érdekes emberekkel és új kihívásokkal teli feladatokkal, és környezetben. Biztos vagyok benn, hogy menni fog, de hogy valójában mennyi munka lesz benne, hogy a várt eredményt hozzam, azt jelenleg még nem látom.

Visszaolvasom egy pillanatra amit írtam. Hmmm. Ahhoz képest, hogy e mellett az apró mindennapi “nyûgök”, feladatok megmaradnak nem is tûnik oly kevésnek a dolog. Hát akkor hajrá elõre és lássuk mit is hoz a holnap!