Category: windows server

Hyper-V 2012 + Storage Sapces

2012-12-02 / / 1 Comment

Amikor megjelent a Windwos Server 2012 megtetszett a Storage Spaces nevű szerkezet. Azt gondoltam, hogy az új Hyper-V tetején kialakítok egy virtualizált háttértároló infrastruktúrát.

Építettem egy szervert. Az alaplapi 6 csatornás intel RST RAID vezérlőre felraktam 6db merevlemezt. Ebből az első kettőből RAID 1-es tömb készült, a maradék négyet pedig hagytam magában. A RAID tömbre felraktam a Hyper-V Server 2012-t, tettem rá egy virtuális gépet, ami a raiden lévő vhd-ból bootol, és odaadtam neki a maradék négy lemezt pass-through módban. A virtuális gépre felraktam egy Windows Server 2012-t. A virtuális gépen belül pedig a pass-through lemezekből összeraktam egy Storage Spaces Pool-t.

Minden szépen működött. Adat is került az újonnan kialakított virtuális “NAS”-ra.

Elkövetkezett a kies november 19.-ei hétfői nap, amikor is látom a Nagios-ban, hogy jónéhány gépet frissíteni kéne, köztük a virtuális nas alatti Hyper-V hosztot is.

Végigmentem a gépeken, utoljára maradt a Hyper-V. Felmentek a frissítések, újraindult. Elindítottam a különböző virtuális gépeket, minden elindult

kivéve…

a remek virtuális nas-om.

1. pofon:

Közölte a drága, hogy nem tudja felcsatolni a lemezeit. Remek. 🙁

Megnéztem a diskpartban, ahol a boot lemezen kívül nem láttam semmit. Itt kellene lennie négy darab offline disknek.

Az első gyanúsítottam az integrált Intel RST vezérlő meghajtója/menedzsmentje volt. Ilyen ugyanis nincs. Mind a mai napig az Intel nem adott ki hozzá 2012-n működő darabot. Azt feltételeztem, hogy a non-raid diskeket valamelyik hotfix miatt nem látja az operációs rendszer.

Körül akartam nézni a device managerben, hogy lássam mi a helyzet.

2. pofon:

A Hyper-V Szerverből adódóan ez egy core edition. Mint ilyen, nincs device manager rajta.

– Távolról még read-only módban sem lehet device managert indítani, mert ezt, a korábban meglévő lehetőséget a Microsoft eltávolította
– Itt írják, hogy tegyük fel a Server-Gui-Mgmt-Infra windows feature-t, de ezt nem tudom megtenni, hiszen ez nem egy teljes Windwos core, hanem a Hyper-V szerver, amin nincs ilyen
– PowerShell alapú device management nem része az operációs rendszernek. Van hozzá letölthető, de ezt valahogy nem akartam feltenni (így utólag kár volt)

Miután nincs device manager, tehát jön a vakrepülés. Nézzük meg, hogy mi történik, ha a lemezeket áttesszük egy másik vezérlőre. Volt a fiókban egy Intel RS2BL040 RAID vezérlő. Gondoltam erre átrakom a lemezeket és meglátom mi lesz.

3. pofon:

Szétszedtem a gépet. Amikor kihúztam az alaplapról a SATA kábeleket, az egyik beakadt és az alaplapi SATA csatlakozó műanyag része jött a kábellel együtt. 🙁 Remek. Alaplapcsere.

Még a kinyírt alaplappal és a fenti vezérlővel megpróbálkoztam.

4. pofon:

A jelzett Intel vezérlő az okosabb fajta. Mint ilyen nem adja tovább az operációs rendszernek a konfigurálatlan lemezeket (JBOD mód). A butábbik testvére az RS2WC040 persze igen. Azt nem mertem megkockáztatni, hogy felkonfiguráljam őket egyesével RAID 0-ának, mert ki tudja mit ír vissza és mi lesz az adatokkal.

Szereztem olcsón (5eFt/db) HP SC40Ge vezérlőket, amik tudják a JBOD módot. Beraktam a gépbe. Semmi sem változott. a diskpart nem lát semmit.

Tegnap reggel nekiálltam, hogy megejtsem az esedékes alaplapcserét. Miután még mindig az Intel/MS hotfix volt a gyanúsított, félreraktam a rendszer eredeti boot lemezeit, és két új lemezre raktam fel a Hyper-V-t minden hotfix nélkül. És láss csodát, még mindig nem látta a hiányzó lemezeim.

Ekkor megfogalmazódott bennem a gyanú, hogy lehet, nem is ott keresgélek, ahol kellene. Mi van, ha a Storage Spaces által felkonfigurált pool-t a Hyper-V szerver maga önhatalmúlag bevételezi.

Felraktam egy teljes Window Server 2012-t, hogy lássak is valamit, vége legyen végre ennek a vakrepülésnek.

Nyertem. 🙂 A device managerben látszanak a lemezek és a Storage Spaces konfig lát egy read-only pool-t (azt amit kerestem). Ezek után találtam is erről egy thread-et a Microsoft support fórumon.

Visszaraktam az eredeti boot lemezeket, rendbeszedtem a konfigurációt. Innen kezdve a Storage Pool-t a Hyper-V szerver kezeli és a Storage Pool virtuális kötetei lettek átadva a NAS-nak pass-through lemezként.

A véleményem, hogy a tipikus “not a bug it’s a feature” esettel állunk szemben. Ezt valaki csúnyán benézte az MS-nél: Ami pass-through az pass-through, teljesen mindegy, hogy a virtuális gép mit rak rá.

A mentés ronda lelkivilága

2012-06-05 / / 0 Comments

Ritkán szoktam az Exchange blogról linkelni, valahogy úgy érzem, hogy aki érdeklődik a téma iránt, az úgyis rajta lóg az rss csatornájukon. Most viszont kitettek egy nagyon-nagyon-nagyon hiánypótló írást, melyet mindenkinek el kell olvasnia, azoknak is, akik csak ezt a blogot követik. (“Ha én valamit szeretek magamban, az a szerénység.”)

IE9 + Windows Update

2012-04-14 / / 0 Comments

Telepítettem egy új Windows Server 2008 R2-t (a régi megdeglett, fátylat rá, hogy miért). Felraktam az összes szükséges update-et, de folyton közni, hogy márpedig ő IE9-et akar telepíteni (pedig már fenn van).

Elkövettem egy Windows Update reset-et (SoftwareDistribution, catroot2 mappa töröl). A Windows Update friss meleg ropogósnak tűnik. Mint amit még sosem futtattak. Lefuttatom. Még mindíg közli, hogy kéne neki egy IE9.

Gugli a mi barátunk:

http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/2c252dbe-c833-424d-9b75-4948bb8fb816

Jó hosszú. Összefoglalva:

1. Szedd le az IE9-et (a Programs and Features alatt, ha megjeleníted az update-eket akkor látod és le is tudod szedni)

2. Rebbot

3. Töltsd le a standalone telepítőt innen: http://windows.microsoft.com/en-US/internet-explorer/downloads/ie-9/worldwide-languages

4. Telepítsd fel /update-no kapcsolóval

5. A Windows Update-ből rakd fel a felkínált cumulative fix-et.

Imádom a lehetetlen küldetéseket

2012-03-03 / / 0 Comments

Napok óta a Windows 8 bétával foglalkozik a szakmai blogoszférának a Windowsra érzékeny része. Olyannyira benne van a levegőben, hogy már én is elgondolkoztam, hogy feldobok egy szervert és egy klienst a tesztrendszeremre. Ha időm lesz. Ha.

Viszont vannak olyan emberek – és az összes kalapomat megemelem előttük, pedig van pár – akik nem elégszenek meg azzal, hogy felraknak egy Windows 8 szervert, hanem úgy istenigazából nekiszaladnak és megnézik, hol vannak a határai. És mennyire kemény betonból vannak.

Paul Cunningham úgy döntött, hogy Exchange 2010-et telepít a béta Windows 8 szerverre. És nem riasztotta el, hogy ez abszolút nem támogatott. És akkor sem dőlt a kardjába, amikor a telepítő is közölte vele ezt a hírt. Hiszen a registry-t lehet editálni is, és miért ne hazudhatnánk be a Windows 2008-at (6.1) a Windows 8 (6.2) helyett? Ja, hogy a telepítés után nem indul el az Exchange? Kérem, ha már elkezdtünk hekkelni, miért állnánk meg pont itt?

A teljes cikk: Installing Exchange Server 2010 on Windows Server 8 Beta.

Ideje van a keresésnek és ideje a vesztésnek

2011-08-29 / / 0 Comments

Nem is voltak annyira elszálltak ezek a prédikátorok, amikor a látszólag zöld szövegeket nyomták. Legalábbis a csapat, aki a Windows 2008 szerver telepítő rutinját írta, tanulhatott volna Salamontól.

A tesztrendszeremhez kellett volna egy 32 bites Windows Server 2008. Msdn-es telepítőkulcsom még volt, telepítő médiám… a fene tudja. Úgy emlékeztem, hogy van, csak nem tudtam, hogy hol. Semmi baj, tudomásom szerint a Microsoft oldaláról letöltött eval verzió ugyanaz, a kulccsal simán lehet aktiválni.
Letöltöttem, kiajánlottam a virtuális gépnek, indít, nyelvválasztás… majd telepítő kód. Nosza, begépeltem.

Windows installation has encountered an error and needs to be restarted.

Ez volt a válasz. Ejnye már. Beindítottam a riadóláncot, kértem még néhány kódot. Mindegyikre ugyanezt a választ kaptam, függetlenül attól, hogy milyen tipusú kód volt.
Oké, ennyit az eval verzióról. Kuncsorogtam egy msdn verziójú telepítőt az msdn kódom mellé, azzal már gond nélkül felszaladt, úgy, hogy nem kért semmilyen kódot.

Botor dolog lenne persze azt mondani, hogy az eval szar, az msdn meg jó. A kettő között olyan 200 KB különbség van, azaz a két telepítő gyakorlatilag ugyanaz. Egy különbség van csak, de az elég groteszk ahhoz, hogy megérjen egy írást.

  • Az msdn verzió annyival rövidebb, hogy nem kér semmilyen kódot. Feltelepíted, majd kapsz 3 napot, hogy aktiváld.
  • Az eval verzió logikája, hogy nem kell hozzá kód, de 180 nap után a kardjába dől. Természetesen ezen időszak alatt, ha van rendes kulcsod, aktiválhatod és teljes értékű szervered lesz.

Eddig nincs is gond. Csakhogy valami mekkmester úgy gondolta, hogy utólag rárak még valami okosságot. Azt mondta, hogy milyen remek lenne, ha az eval verzióba már telepítés előtt be lehetne ütni a valós kódot, így két legyet ütünk egy csapásra. Berakták. Azzal a szubrutinnal együtt, amelyik online akarja leellenőrizni a kódot, hogy valós-e. Mindezt a telepítésnek abban a fázisában, amikor nemhogy mini operációs rendszer nincs a gépen, de még network sem. Trükkös, mi? Az ellenőrzés nyilván elhasal, bármilyen kódot is írsz be. Egyedül akkor megy tovább, ha üresen hagyod a mezőt. Gondolj bele, mennyi értelme van feltenni egy kérdést, de csak akkor továbbengedni a delikvenst, ha nem válaszol semmit.
És mindezt pluszban programozták bele a telepítőbe.
Finom.

Megjegyzés

Mindemellett el tudom képzelni, hogy pont fordítva történtek a dolgok és mind az eval, mind az msdn verzió a bolti változatból keletkezett, a kódbekérő rész részleges, illetve teljes kiműtésével. Sőt, még azt sem tartom kizártnak, hogy létezik valahol egy manual, ahol leírják, hogy az eval verziónál tilos bármit is beírni az ablakba. (A letöltési oldalon mindenesetre csak annyit említenek, hogy nem kötelező.) Még az is lehet, hogy nem akar online ellenőrizni, hanem egyszerűen csak kivették belőle a validáló rutint. Sok minden lehet. Ha így van, akkor ez az egész már nem tűnik annyira nagy hülyeségnek… de gányolásnak igen.

No Feature!

2011-07-07 / / 7 Comments

Nem, nem a jó öreg Sex Pistols nótáról lesz szó. Rosszabb. Belépsz egy frissen telepített Windows Server 2008 R2 gépre, tennéd fel a kötelező telnet klienst – és nem látsz se feature-t, se szerepet, sőt, amikor rákattintasz az add gombra, kövér hibát kapsz: RPC hiba. Hangsúlyozom, frissen telepített, patchelt oprendszer, semmi extra alkalmazás.
Nyilván újra lehetne telepíteni a rendszert, de csak a foltozás egy fél nap, ergo ha negyed nap alatt megtaláljuk a hibát, már jók vagyunk. (Mint Mr Garrison az üvegcsővel és az egérrel.)
Természetesen gugli. Lehangoló eredménnyel. Némi képzavarral élve, RPC hibával foglalkozó oldalakkal Dunát lehet rekeszteni. Végül csak sikerült megtalálnom a tűt a szénakazalban: Fix my IT system.

A megoldás több, mint érdekes.

Le kell tölteni a Microsofttól egy segédprogramot, a System Update Readiness Tool nevezetűt. Nem kicsi a szentem, közel 100 mega. Ráadásul nem is csak egy böhöm nagy dll, tele felesleges funkciókkal, hanem tényleg dolgozik. Nálam közel 20 percig futott. Átnézte, hogy mi csúszott szét a patchelések során, milyen inkonzisztenciák alakultak ki – és szépen elrendezett mindent. A biztonság kedvéért ráküldtem egy újraindítást – és szépen megjelent az összes tulajdonság és szerepkör.

Ki mennyire autoritatív?

2010-07-26 / / 0 Comments

Érdekes jelenségbe futottam bele a napokban. Különböző tartományok felé DNS lekérdezéseket kellett volna futtatnom – és nem igazán értettem az eredményeket.

De ehhez egy kis ismétlés.

Anélkül, hogy túlzottan belemennék a DNS részleteibe: tudjuk, hogy vannap primary zónák, vannak AD integrált zónák… de ezek most hidegen hagynak minket.
A finomságok a secondary és a stub zónáknál kezdődnek, illetve bejönnek a képbe a zónadelegálások is.

Secondary zóna:
A primary (elsődleges) zónát tükrözi le egy másik DNS szerverre, gyakorlatilag teljes egészében.

Stub zóna:
Szintén tükröz, de nem az egész zónát, hanem csak az A, NS és SRV rekordokat szedi le.

Zónadelegálás:
Megadjuk, hogy egy hozzánk tartozó zóna alzónájának ki a DNS szervere. Ez tetszőleges külsős DNS szerver is lehet.

És akkor a konkrét jelenség. Nemzetközi környezet, tartomány tartomány hátán. Szeretném megtudni az egyes tartományok MX rekordjait. Aztán nem mindegyikét kapom meg. Viszonylag hamar kiderült, hogy ahol stub zóna van, ott megkapom, ahol meg zónadelegálás, ott nem.
Mondanom sem kell, a névfeloldás mindegyik esetben tökéletesen megy – de az MX rekord beszerzése nem egy egyszerű kérés.

nslookup
ls -t MX kerdeses.domain

Stub zóna esetén vagy megkapom a kérdéses MX rekordot, vagy jogosultsági hiányosságból kifolyólag elutasítanak. Delegált zóna esetén viszont azt kapom vissza, hogy a zóna ismeretlen. Pedig – mint írtam is – a névfeloldás remekül megy, azaz dehogyis ismeretlen a zóna.

Keresgélés a neten. Azt írja a DNS hibakereső doksi, hogy ha nem autoritatív DNS szervert kérdezek, akkor jöhet ilyen üzenet. Ellenteszt: delegált zónánál kiegészítettem a lekérdezést:

nslookup
server a.zona.eredeti.dns.szervere.ahova.a.delegacio.mutat
ls -t MX kerdeses.domain

Láss csodát, egyből működött.

Ezzel akár már elégedett is lehetnék, de nem hagyott nyugodni a kisördög. Most akkor mi van a stub zónával? Gyors teszt: a stub zóna is non-authoritative választ ad, tetszőleges lekérdezésre. Azaz olyan rekord esetén is, mely egyébként már letükröződött a helyi DNS szerverre. Akkor meg miért működik az MX lekérdezés? Ha mindkét módszernél egyformán nem-autoritatív a kérdezett helyi szerver, akkor miért működik az MX lekérés a stub zónánál és miért nem a delegálásnál?
Nyilván azért, mert a stub egy hajszállal autoritatívabb, mint a delegálás.

Kis szar ablak

2010-06-16 / / 7 Comments

Hosszú szünet után visszatérés morgással.

Árulja már el nekem valaki fejlesztő, hogy mennyivel kerül többe egy olyan ablak, amelyiken vannak méretező kontrollok? Egész egyszerűen nem fér a fejembe, hogy a mai napig sokszor olyan kis szar ablakokat használunk a windows-ban, melyeket képtelenség felnagyítani.

Ma például megint egy levél útvonalát kellett volna feltérképeznem. Outlook, levél, options – és feljött az a hangyaf@sznyi ablak. Aztán nesze, görgessél jobbra-balra, fel-alá, próbálj összerakni egy ilyen bonyolult láncolatot úgy, hogy csak egy bélyegnyi ablakot kapsz rá.

De meggyőződésem, hogy a biztonsági jogosultságok állítgatása is azért kínai a legtöbb informatikusnak, mert kap egy ilyen egérmozi méretű ablakot, aztán turkáljon benne a 40-50 elemi jogosultság között. A jó ég áldja meg, mire a lista végére érek, már rég elfelejtettem, mi volt az elején, egyben meg ugye nem lehet látni a pici ablak miatt. Azon a kurva nagy felbontású képernyőn.

Ez egy akkora ergonómiai baromság, hogy nincs is megfelelő szó a minősítésére. És az MS oldalán szemmel láthatóan úgy gondolják, hogy ez így nagyon jó, hiszen még a Windows7-ben is ugyanolyan pici, méretezhetetlen ablakok vannak, mint az NT4-ben. Pedig biztos nem én vagyok az első, aki hőbörög.

Szorgos hétköznapok

2009-09-07 / / 3 Comments

A feladat első lépése: telepítsünk HP Blade szerverre Windows Server 2008-at. Nem nagy ügy, virtual media bekonnektálva, nextnextfinish. ILO-ról beléptem, a hálókártyát beállítottam, a hardveres kolléga fellapátolta a PSP-t… aztán más projektre szólított a kötelesség. Miután ott eljutottunk odáig, hogy a labda már az ügyfél oldalán pattogott, jöhettem vissza a blade szerveremhez. Melyet időközben tokkal-vonóval, cage-dzsel, storage-dzsal átcipeltek egy másik épületbe. Ez ugye az alkalmazástelepítőt nem érdekli, a lényeg, hogy a drót túloldalán ott ficánkoljon a vas.

Nos, ez ficánkolt. Például az általam beállított IP címen nem tudtam elérni. ILO. A kártya DHCP-n volt. Visszaállítottam. Erre közölte, hogy ilyen konfigja már van egy hálózati kártyának, akarom, hogy azt törölje? Na, a hülye megőrzött valami régi értéket… persze, töröld, fiam.
Gépnév? Ez is átalakult valami random krikszkraksszá. Visszaneveztem, újraindítás. Megint nem lehetett elérni RDP-n. ILO. A hálókártya megint DHCP-s lett. Ekkor tűnt föl, hogy megváltoztatta Local Area Connection mögött a számot. Mi a fene? Ez minden újraindításkor újradetektálja és új kártyának ismeri fel a meglévő hálókártyáját? Visszakonfiguráltam. Megint figyelmeztetett, hogy ilyen konfig már van. Töröld, b+. Az OK után kiváncsiságból visszanéztem: kitörölte a DGW értékét. Visszaírtam.

Mehettünk tovább.

Átnéztem a rendszertervet – és kiderült, hogy más IP tartományba kerültünk, mint amit 1 hónappal ezelőtt tudtam. Már remegő kezekkel mentem be az IPv4 beállítások közé. Átírtam az IP címet, újraindítottam a szervert. Mondanom sem kell, megint elveszett. ILO. Újabb szám a hálókártya neve mellett – és persze DHCP-s. Káromkodás. Visszakonfiguráltam, dühösen lenyomtam a figyelmeztetést, miszerint egy nemlétező hálózati kártyának is ugyanez a konfigurációja. Dögölj meg. A beállítás után visszanéztem: és eldobtam a billentyűzetet. Nem csak a DGW-t törölte ki, hanem visszaállította a régi IP címet is. Kijavítottam. Leokéztam. Visszanéztem. Megint átírta az IP címet.

Ekkor néztem körbe, hová van elrejtve a kandikamera.

Gép újraindítás. Jé, most nem lett DHCP-s. IP konfig, beírtam a DGW-t, átírtam az IP címet – és végre bele is törődött, nem bírált felül.

Oké. Next.

Léptessük be a tartományba. Belépett. Kért egy újraindítást. Ajjaj.

Természetesen megint DHCP-s lett, valami lehetetlen címmel. ILO. Megint befaragtam. Megint visszaragadta a régi IP címét, miközben törölte a DGW-t. Újraindítás. Megint befaragtam. Jó lett.
Huh.
Innentől már volt net. SP2. Gondolom, kitaláltad: újraindítás, DHCP, befaragás, régi IP cím, Default Gateway, újraindítás, befaragás.
Windowsupdate. Újraindítás. DHCP, bef, rIP, DGW, újr, bef.
Itt történt egy érdekesség: az időközben felugrott maliciózus kódokat kirugdosó program mellékesen megjegyezte, hogy volt valami conflicker.b a gépen, de letúrta.
Bakker.
Amíg átmentem a másik projektre, a gép csak úgy állt ott, mint szende lófütty a vadvirágos réten… a conflicker meg beporozta. Szóltam a permetezős kollégáknak, hogy fertőtlenítsenek. Nem mintha nem bíznék meg a maliciózus removal tool-ban… de nem bízok meg. Nos, jelzem, hogy meg lehet – a gép tiszta lett. Csakhogy a kolléga nekiállt feldobni egy SEP-et – és találd ki, mi lett belőle? Újraindítás. DHCP, bef, rIP, DGW, újr, bef.
Pedig itt már azt hittem, hogy megvan a bűnös, innentől már rendben lesz minden.

Bevadultam. Kitöröltem az összes hálókártyát. Becsörtettem a registry-be, kitöröltem minden olyan GUID nevű objektumot, ahol a Connection alobjektumban szerepelt a ‘Local Area Connection’ string. Végül újratelepítettem a HP PSP-t.
Újraindítás. Nos, az eddig letiltott két hálókártya eltűnt. Maradt az az egy, amelyiken link is volt. És átváltott DHCP-re. Bef, rIP, DGW, újr, bef.

Ekkor már keményen délután volt. Az egész napom azzal ment el, hogy egyszerűen csak hozzá akartam férni egy géphez. Közel 9 órát töltöttem el ILO felület előtt – és ha volt már hozzá szerencséd, akkor tudod, mennyire frusztráló is tud ez lenni.

Kész. Projekt lefújva. Ezek voltak az első gondolataim. Másik hardver nincs, ez lett volna egy cluster első node-ja… de egy ennyire kiszámíthatatlan hálózati kártyával öngyilkosság lett volna belevágni. Jön egy failover, aztán DHCP-re vált a kártya. Jól néznénk ki.

Ekkor kezdtem alaposabban gondolkodni. Tényleg nem értem néha magamat. Nagyon szűk határidő, sok feladat – és egy egész napot végigszívok egy lehetetlen hibával, lehetetlen körülmények között – ahelyett, hogy egyből gugliznék. Vagy nák.
Viszont még csak elképzelésem sem volt, hogyan fogalmazzam meg a jelenséget, emiatt kiindultam abból a ritka hülye üzenetből, miszerint egy régi, már nem használt hálózati kártyámnak is ugyanaz a konfigurációja, mint a mostaninak.
Nem írom le a teljes vadászatot, több ugráson keresztül ugyan, de eljutottam ide . Ránézésre baromira nem stimmel. XP. Meg nem konnektált hardverek a Device Manager-ben.

Device Manager displays only non-Plug and Play devices, drivers, and printers when you click Show hidden devices on the View menu. Devices that you install that are not connected to the computer (such as a Universal Serial Bus [USB] device or “ghosted” devices ) are not displayed in Device Manager, even when you click Show hidden devices.

Ez a lényeg kérem, a dőlt betűs rész. Ghost egységek. Hát mi a fene lehet ez, mint egy kupac szellemként rejtőzködő, valójában nem létező hálókártya? Gondold el: van egy hálózati kártya, melyet egyszer így ismert fel, egyszer meg úgy. És ezeket váltogatja. Ilyenkor úgy érzi, hogy kivettem egy hálókártyát és betettem helyette egy másikat. A réginek megőrzi a konfigurációját – mert hátha egyszer vissza fog kerülni – az újat meg DHCP-re rakja. Aztán amikor én beállítom az újon ugyanazt a konfigot és azt mondom neki, törölje a régi hálózati kártyát – akkor nem magát a kártyát törli, hanem csak a konfigját. Jön a következő boot, ekkor a másik kártyának ismeri fel – és kezdődik minden előlről.
Nyilván valami hasonlóra gondoltam én is – de a Device Manager-ben hiába kapcsoltam be a Show Hidden Device opciót, ez csak az ellenség megtévesztése volt. Nem mutatott ez semmit, maximum a szélben lengedező lófüttyöt azon a vadvirágos réten.

Előtte ugyanis el kell indítani egy command promptot adminisztrátori joggal, majd beadni neki, hogy:

set devmgr_show_nonpresent_devices=1

Vigyázat. Én legalábbis megszoptam. Ha ezután elindítottam a Control Panelből egy Device Manager-t, akkor a Show Hidden Device után megint a jólismert árvalányhajas lófütty jött. Ez ugyanis már másik session-nak számít. Azaz nem vagánykodásból kell a promptból indítani a konzolt.

start devmgmt.msc

Na, ekkor jött meg az összes fantom hálózati kártya. Mind a tizensok.

Nagyítás

(A kép már egy későbbi állapotot ábrázol – de jól láthatóak a piros X-szel megjelölt fantom hálókártyák.)

Egyenként kitöröltem a bagázst – és minden rendben lett. Félórán keresztül csak restartoltam, IP címet állítgattam… de tényleg minden rendben.
Aztán eltöltöttem még egy kis időt, mire gatyába ráztam a WINS és DNS szervereket – szegények, mit képzelhettek erről az állandóan máshogy bejelentkezgető hostról – és kész. Jöhet a cluster.

Első lépés: faiover cluster feature telepítése. Lement. Reboot. Na?
Úgy van. DHCP. Csak most ugye megspékelve azzal, hogy a a failover cluster a régi adapterhez rendelődött hozzá, az újnál meg semmi. Illetve lófütty. Hálókártyák rendezése, failover cluster le, failover cluster fel, restart. DHCP. Bef, rIP, DGW, újr, bef.

Péntek éjfél. Ekkor fejeztem be aznapra, mert sürgős kardbadőlhetnékem támadt.

Szombat: új nap, új remények. Először eltávolítottam a rendszerből a HP NIC drivereket, hogy ne tudja keverni, milyen hálókártyának ismeri fel. Nem segített. Sóhaj, partíció töröl, operációs rendszer újratelepül. Kisérletképpen HP PSP nélkül. És csodák csodája, minden muzsikál. A 3 hálózati kártya masszívan tartja magát, se a gépátnevezés, se a tartományba léptetés nem hatja meg. Huh. Ellenteszt. Felraktam a HP Support Pack-ot, restart. DHCP. Bef, rIP, DGW, újr, bef.
Oké. Megvan a bűnös. Valamelyik program/driver a csomagból behülyíti a Windows-t.
Partíció radír, Windows újratelepül. Belépek… erre a hálózati kártyán még mindig ott volt az előző domaintagságra utaló hálózati név. Hát ez meg hogyan élte túl a teljes újratelepítést? Megnéztem a hálózati részt, ott vigyorgott a fantom kártya. Azannya. Újabb gyalu, a biztonság kedvéért 5 GB-vel kisebb új partícióra. Ha ezt is változatlanul éli túl a hálókártya, akkor elnevezem David Copperfield-nek.(1)

(1) Persze én voltam a hülye. Egyszerűen csak DHCP-re váltott, IP címet kapott, azon meg felismerte a tartományt. Csak nekem volt furcsa, hogy frissen telepített oprendszer már tartományt mutat.

De nem. Teljesen szép, szűz Windows 2008 jött fel. Oké. Hálózati kártya bekonfigurálva, gép átnevezés, reboot.
DHCP. Bef, rIP, DGW, újr, bef. Kardbadőlés.
Abszolút üres Windows, sehol semmi – és ott vigyorog a fantom kártya. Ami a reboot előtt az éles kártya volt. Aznapra ennyi jutott a sikerélményekből.

Vasárnap. Sebnyalogatás.

Hétfő. Ekkor már valamennyire állnia kellett volna a clusternek… ehhez képest legszívesebben már rég elhantoltam volna azt a szutyok vasat. Új ötlet. Hardveres kollégával konzultálva kiderült, hogy a gépben egy duálportos és két single portos hálókártya van. Mivel a cage csak három hálózati kimenettel rendelkezik, így az egyik hálózati kártyát letiltották – csakhogy ez pont a duál portos egyik portja lett. Lehet, hogy ettől hülyült meg a Windows. Mivel nekem elég a két hálózati kapcsolat, így váltunk: letiltják a duál portost és marad a két másik.
Kolléga elutazott a szerverekhez, átkonfigurálta.
Teszt.
Két fantom hálózati kártya vigyorgott vissza. Meg a tükörből az őrület. Aztán a remény fénye: lehet, hogy ez a két fantom még korábbi kisérletezések maradéka? Töröltem, Scan for new hardware… és nincs több fantom. Kezdtem reménykedni. Megint Scan. Még mindig jó. Kérem… én nem ehhez vagyok szokva. Elkezdtem őrült módon mindenfélének átnevezgetni a gépet, majd újraindítgattam. (Később csak az volt egy óra, míg a WINS szervereket kipucoltam.) De tartotta magát a gép, nem jöttek elő a fantomkártyák. Jöhetett a tartománybaléptetés, a HP PSP csomag… meg minden más.
28 órányi munka alatt eljutottam oda, hogy elkezdhettem bekonfigurálni az operációs rendszert. Miközben az egész cluster elindítására volt 3 munkanapunk. Szerencsére volt közben egy hétvége – az ugye nem számít, maximum csak nekem, de az meg megint nem számít. Így ha hajnalig nyomom, akkor esély van utolérni magunkat. (Kedd reggelre igértük a működőképes clustert.)

Szóval így.

Proxycfg

2009-09-04 / / 0 Comments

Csak jelzem, hogy élek.

Apró feljegyzés, leginkább magamnak.

Windows Server 2008. SP2-t felraktam. Már csak a maradék hotfixek hiányoztak. Windowsupdate, azt mondta, szétnéz… majd hibaüzenet.
Rutinos öreg róka már gépelte is be, hogy: proxycfg. Erre jött a válasz, hogy: miről beszélsz?
Hmm. Nincs. Végre egy kis izgalom. (Ezt tessék ironikusan érteni.)

De van helyette netsh. Így:

netsh
winhttp
show proxy

És igen, a beállított érték ‘direct access’ volt.

set proxy isaserver:8080
show proxy

És kész. Innentől már söpört is a windowsupdate.

Pislant a hálókártya

2009-07-21 / / 6 Comments

Erre az esetmegoldásra nem leszek büszke, de tanulság azért akad benne.

Nagyon fontos ügyfél (habár hülyeség, mindegyik az) telefonál, hogy megállt a cégnél az internetelérés. Különböző okok miatt az ISA webproxy-ra gyanakszik. Mivel internet nélkül nincs élet, így a bejelentés magas prioritású.
A megoldást nehezíti, hogy magát a belső hálózatot nem mi üzemeltetjük, abszolút semmi hozzáférésünk sincsen. Csak az ISA-t kezeljük mi.

Megnéztem a logokat, mi is a helyzet a webforgalommal: a 80-as porton remekül hasítottak a bitek, még a vizsgálat közben is. Leellenőriztem, hogy ez valós forgalom-e. Az volt. Ment vissza a levél: Kedves Ügyfél, te valamit nagyon benéztél, az ISA-n gyönyörűen megy a http.

Amire jött az indignált válasz, hogy márpedig ez nem megy. Biztos, hogy jó forgalmat néztem?

Bakker. Nem. Hiszen a böngészők webproxy kliensek, akik a webproxy filter listening portján érik el az ISA-t. A 80-as porton csak akkor megy webes forgalom, ha nem webproxy kliens forgalmaz. A konkrét esetben a webproxy filter egy lehetetlen porton (na jó, annyira nem, de akkor sem írom le) figyelt, arra rákeresve rögtön dőltek is a denied connection üzenetek.

Hát, ez már mindjárt más. Akkor itt tényleg baj van.

Event log. Tele volt gyönyörű kövér 14118-as hibákkal. Azt mondja:

Description: The Web Proxy filter failed to bind its socket to IP address port xxxx. This may have been caused by another service that is already using the same port or by a network adapter that is not functional. To resolve this issue, restart the Microsoft Firewall service. The error code specified in the data area of the event properties indicates the cause of the failure.

A részletes hibakód: 0x80072740.

Néhány perc keresgélés után meg is lett a magyarázat. (Komolyan mondom, ma egy informatikusnál az internetes keresési képesség a második legfontosabb készség. Az első az angol nyelv ismerete.) Itt van a KB cikk.
(Ne keverjük össze ezzel a másik cikkel: habár a hibaüzenet ugyanaz, de ez az írás arra az esetre vonatkozik, amikor IIS is fut az ISA mellett.)

Akkor most mi is a hipotézisünk? A hétvégén valószínűleg volt egy rövid időszak, amikor leesett a link az ISA szerver belső lábáról. Ekkor a Windows Server 2003 le is kapcsolta a konkrét hálózati kártyát. Ezt hívják úgy, hogy Media Sense… és feature. Igenám, de amikor visszajön a link és feléled a hálózati kártya, az ISA szerver webproxy filtere nem képes rákapaszkodni a kijelölt portjára. Támadhatják őt a böngészőkből a kliensek, nincs bind. (A pikáns az, hogy a netstat szerint persze ott figyel a megadott porton.) Megoldás? Újra kell indítani a Microsoft Firewall klienst.
Majd.
Eddigre ugyanis az ügyfél morogva beröffentett egy linux proxy-t, mondván ők nem érnek rá. Annyiból igazuk is volt, hogy az ISA nem csak az internet felé forgalmaz, hanem a nagyon fontos anya- és társvállalatok felé is, azt a forgalmat meg még egy percre sem lehet megszakítani szolgáltatás újraindításával.
Majd este.

Addig volt időm körbenézni – és sikerült be is igazolnom a hipotézist: abban a 10 percben, amikor az ISA log szerint megállt a webproxy filter, ott figyelt két bejegyzés a system event logban is:
Warning Event 4: Adapter xxxxxxx Adapter Link Down.
Majd pár perccel később:
Information: Adapter xxxxxxx Adapter Link Up.

A többi már annyira nem érdekes, késő este újra lett indítva a szervíz, minden a helyére került.

Ja, a tanulság: ISA szerveren lehet, hogy nem hülyeség letiltani a Media Sense opciót.
(Windows Server 2008-ban alaphelyzetben le is van.)

Feljegyzés magamnak

2008-12-16 / / 1 Comment

Még az ősszel kaptam egy megbízást. Mondanom sem kell, eddig esélyem sem volt foglalkozni vele… és most is éppen csak beleharaptam a témába, éppen csak elkezdtem anyagot gyűjteni.

De azért lepődtem már meg.

Nézzük például az EAP autentikációt. Azt ugye tudjuk, hogy az EAP alapvetően nem egy önálló autentikáció, sokkal inkább egy keretrendszer. Mint az MMC: beletűzdeljük a snap-in-eket és így lesz egy jól használható valami belőle. Az EAP-ba ilyesmiket szoktak beledöfni, hogy TLS (melyről tudjuk, hogy az SSL leszármazottja), illetve MS-CHAPv2. (Bónusz kérdés: mi a különbség az MS-CHAPv2 és NTLMv2 között? Bónusz válasz: a módszer ugyanaz. Csak máshol használjuk.)
No, most jön a meglepődés. Vajon MS rendszerekben wifi autentikációhoz melyik EAP sündísznót használjuk? Az EAP-TLS-t? Ahol tudjuk, hogy a TLS elődje az tkp. Netscape kreálmány? Vagy inkább az MS saját édes gyermekét?
Persze, hogy az EAP-TLS-t. Az MS édes gyermeke… most nem kapott lapot.

De mielőtt szottyosra zokognánk a kispárnánkat, olvassunk tovább.

Nemcsak EAP van a világon… létezik PEAP is. Mi a különbség? Úgy van, nagyon jól éreztél rá: a ‘P’ betű. ‘P’, mint Protected. Anélkül, hogy túlzottan belemennék a részletekbe, a különbség lényege az, hogy az EAP esetén a felek kölcsönös becsületsértegetése nyilvános, míg a PEAP esetén már ez is titkosított. És igen, a PEAP-nál már egyenrangú a PEAP-TLS és a PEAP-MSCHAPv2.

Agyonütni… de csak az egyiket

2008-09-11 / / 0 Comments

Régi probléma. Van egy DNS szerverként is működő tartományvezérlő számítógépünk, melyben két hálókártya is van. Az egyik a külvilág felé néz, a másik a belső háló felé. (Csak a pontosság kedvéért: a külvilág azért nem a vad internet, hanem VPN-en keresztül egy másik kontinensen lévő társ vállalat.) Mindkét kártya felé adunk névfeloldási szolgáltatást.

Mi a gond?

Hát az, hogy a belső zónába simán beregisztrálódik a DC mindkét hálózati kártyájának a címe, sőt, az összes két hálókártyás gép címe is – emiatt néhányan panaszkodnak, hogy rossz IP címeket kapnak vissza.

Jó, mik a lehetőségeink?

A leginkább logikus természetesen az, hogy bemegyünk a hálózati kártyák beállításai közé, aztán a külsőn kikattintjuk, hogy automatikusan beregisztrálja magát. Logikus… de nem működik. Mégpedig azért nem, mert van ennél erősebb beállítás is. A DNS konzolban a konkrét szerver tulajdonságainál lehet beállítani, hogy mely hálózati kártyáin ad névfeloldási szolgáltatást a szerver. Márpedig ha mindkettőn, akkor mindkettő be is regisztrálódik. Ha a gép nem DNS szerver, akkor ugyanezt a registry-n keresztül tudjuk szabályozni:
a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters kulcs alatt fel kell venni egy változót PublishAddresses néven (reg_sz), majd pontosvesszővel elválasztva be lehet írni a regisztrálandó IP címeket. (Ha a változó nem létezik, akkor mindkét IP cím regisztrálódik.)

Ez mind szép, persze, de a mi problémánkat nem oldja meg. Ugyanis mi mindkét kártyán szolgáltatunk. Csak éppen nem szeretnénk, ha a külső cím is megjelenne a belső zónánkban.

Váltsunk csapásirányt. Miért is baj, hogy megjelenik a DC külső címe is? Vagy az Exchange szerveré? Egyáltalán, baj? Hiszen akik kintről kiváncsiak a zónára, azoknak szükségük is lehet erre a bejegyzésre. Azt kellene megoldani valahogyan, hogy a DNS kaméleon legyen: ha a külső hálózati kártyájáról jön egy kérdés, akkor a külső IP címeket dobja vissza, ha a belső kártyájáról, akkor a belsőket.

Happy end: van ilyen beállítás. DNS konzol, a szerver tulajdonságainál az advanced fül alatt ott vigyorog egy olyan beállítás, hogy ‘enable netmask ordering’. Ő a barátunk.

Névfeloldás

2008-08-19 / / 3 Comments

Jogosan kérdezheted, mit lehet még ebből a témából kifacsarni? Leírtak már mindent, amit csak lehet.

Mégis találtam érdekességet.

Kezdjük a szituáció felvázolásával:

  • Több tartományból álló környezet.
  • Minden tartomány minden tartományvezérlője DNS és WINS szerver is egyben. A WINS szerverek replikációs partnerek. Az összes DNS zóna AD integrált, méghozzá forest szinten.
  • Az összes szerver az egyik – mondjuk a.cegnev.hu – tartományban van.
  • Van DHCP.

Jelenség:
Kiderült, hogy az összes tartományból (b.cegnev.hu, c.cegnev.hu), amennyiben rövid névvel akarják elérni a szervereket, a WINS végzi el a névfeloldást.
Nyilván nem ez a cél: minek autózzunk Trabanttal, ha van Lexusunk is?

Ismételjük csak át a névfeloldást:

  • A kliens megnézi a saját lokális cache-ét.
  • Ha nem talál semmit, akkor hozzácsapja a rövid névhez az összes beállított suffix-ot, majd az így kialakult FQDN-t megnézi a megfelelő zónafájlokban.
  • Ha még mindig nem talál semmit, akkor megy a WINS-hez.
  • Tovább is van, de ez most nem lényeges.

Megnéztük, és azt tapasztaltuk, hogy minden kliens gépen csak primary suffix van beállítva, a DNS ablakban bizony üres a DNS suffix search ablak.
Oké. helyben vagyunk. Mivel a keresett szerver az a.cegnev.hu zónában van, de ez nincs rajta a keresési listán, a WINS fogja végül kapni a munkát.

Megvan a probléma, javítsuk ki. Nyilván többszáz gépes, neadjisten több telephelyes környezetben az ‘egyenként sorbajárjuk a gépeket’ módszer nem igazán hatékony.
Mik is jöhetnek szóba lehetőségként?

  • Biztosan létezik valamilyen DHCP opció.
  • Biztosan létezik valamilyen csoportházirend beállítás.
  • Ha neadjisten egyik sem, még mindig ott van a netsh, mely mindent tud.
  • Ad abszurdum, még nekiállhatunk saját szkriptet is írni.

Nos, van választék bőven, nézzük meg, melyik is működik konkrétan.

Első találat:

The following methods of distribution are not available for pushing the domain suffix search list to DNS clients:
• Dynamic Host Configuration Protocol (DHCP). You cannot configure DHCP to send out a domain suffix search list. This is currently not supported by the Microsoft DHCP server.
• Netsh (Netshell). The Netsh utility has no command to set or to change the domain suffix search list.
• Group Policy. In Windows 2000, Group Policy has no mechanism for distributing the domain suffix search list. However, Windows Server 2003 includes this feature.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
294785 New group policies for DNS in Windows Server 2003.
• Microsoft Visual Basic Scripting Edition (VBScript). No application programming interfaces (APIs) are available that enable you to script a change to the domain suffix search list.

Első pillantásra komplett infarktus. A felsorolt módszerek egyike sem működik. Ráadásul még a netsh sem!
Aztán jön az alaposabb olvasás. Dátum? 2007 március. Hát, nem mai cikk. Érintett rendszerek? Windows 2000 szerverek, Windows 2000 Prof. Huhh.

Aztán ott van egy link az idézetben: milyen új opciók jöttek be DNS kezelés terén a Windows 2003 szerver csoportházirendjében? És igen:

• Enable or disable dynamic registration of the DNS records by a client
• Configure DNS suffix search list of the clients
• Devolution of the primary DNS suffix in a name resolution process
• DNS suffix search list

Örülés. Szerencsére a kliens fél évvel ezelőtt átlépett natív AD2003-ba.
Egyébként cucli lett volna: egyedül a Windows 2000 Resource Kit Regini programja jöhetett volna szóba. (Melynek már a beszerzése sem túl egyszerű: a Windows 2000 RSK oldalon nincs fent, igaz lehet próbálkozni a Windows 2003 RSK-val.)

Echange 2007 és backup

2008-06-23 / / 5 Comments

Ki tudja, mi a viszony az Exchange 2007 és a Windows Server 2008 NtBackup programja között? Illetve, ha már itt járunk, mi a helyzet a Windows Server 2003 NtBackup programjával?

Az első kérdésre könnyű a válasz: a Windows Server 2008-nak nincs NtBackup programja. Pont. A beépített backup program (Windows Server Backup) nem ismeri az Exchange szervert, ergo képtelen menteni is az adatállományait, képtelen kezelni a tranzakciós logokat. Pont. Akinek nem tetszik, el is lehet költözni az országból.
Azért szerencsére ennyire nem durva a helyzet. Megint egy remek iterációs folyamatot figyelhetünk meg. Először az Exchange és a Windows Server 2008 team-ek dugták össze a fejüket, mint megannyi hétfejű sárkány. Aztán azt sütötték ki, hogy tele van az ipar jobbnál jobb külső gyártók jobbnál jobb (oké, csak viccelek) termékeivel – miért kellene annyit görcsölniük a Windows Server Backup-pal? És ebben tényleg van valami, én itt Magyarországon még egy ügyfélnél sem találkoztam NtBackup-ra épülő Exchange mentéssel – pedig mi az amerikai cégekhez képest maximum kerekítési hibák vagyunk. (Na jó, a MOL-nak megszavazok egy nullával való osztást is. 🙂 )
Így is lett. Csakhogy amint ez az egész kiderült, vérig sértett SOHO rendszergazdák kötözték magukat a redmondi mamutfenyőkhöz. Erre beindult a negyedrangú rungekutta, az algoritmus végén pedig kiiterálódott a megoldás: az Exchange-s fiúk készíteni fognak egy plug-int a Windows Server Backuphoz, melynek segítségével VSS-re épülő(!) mentést tudunk készíteni a gyári programmal az Exchange szerverről, tudunk majhd játszani a logtörlésekkel, meg ilyenek. Bár a fejlesztók sejtelmesen megcsillogtatták, hogy a granularitás nem lesz az igaz, de az nem derült ki, ez miben is fog megnyilvánulni: nem lehet majd adatbázis szinten menteni vagy nem lehet inkrementálisat/differtenciálisat menteni? Nem tudjuk. Az egész még csak ötlet szintjén létezik.

Na és akkor mi is a helyzet a 2003 világban? Létezik NtBackup, ismeri a VSS-t, integrálva van az Exchange 2007-tel is. De vajon tudunk-e árnyékmentést végezni Exchange adatbázisról? Nos, VSS ide vagy oda, nem. Illetve igen. Pontosabban, attól függ.
Nagyon nem mindegy, ugyanis, hogy egy adatbázisra pusztán fájlként tekintünk-e? Ekkor működik ugyan a VSS, de az elmentett adatbázis állapota ‘dirty shutdown’ státuszú lesz – és ha belegondolunk, ez teljesen normális is, hiszen nem lettek rájátszva a logok. Ha viszont Exchange-et is értő mentést akarunk készíteni NtBackup-pal, akkor felejtsük el a VSS-t. Ilyesmit csak külső backup programmal fogunk tudni.

Linkek:

Spagetti routing tábla

2008-06-11 / / 0 Comments

Egyik ügyfelünknél beköltözött a nagy Sztochasztikus Vezetékelharapó az informatikai rendszerükbe. Időnként ugyanis az egyik kritikus telephelyükről nem érték el a központi Exchange szervert. Máskor viszont minden tökéletesen ment.
– Máskor tökéletesen ment? – kérdeztem vissza – Akkor hívjátok a networkos emberünket, mert ez nem Exchange hiba lesz.
És dobáltam tovább a dartsokat.

A networkos ember megnézte a routereket, switcheket, tűzfalakat… minden tökéletesen működött. Nem volt mit tenni, meg kellett várni egy üzemzavart. Meg is jött. Networkos ember ismét átnézett mindent. Alles oké. Csak éppen az Exchange szerver se telnet, se icmp szinten nem volt elérhető.
Vicces.
Aztán a kolléga tovább vizsgálódott, végül arckarmolás mellett felüvöltött: a rohadt istenit az Exchange szervernek!
Ekkor tettem le a nyílhegyeket. Lehet, hogy mégis érintve vagyok?

Mielőtt továbbmennénk, pár szó a hálózatról. Ez egy országos kiépítettségű hálózat, rengeteg telephellyel, subnettel, dmz-vel. Nem viccelek, a dmz-k mennyiségre kétszámjegyűek, nem ritka a két-három kijárattal bíró subnet sem. Nem is a szétszórt routerek kezelik a route logikát, hanem van középen egy RSP (Route Switch Processor), ő az ész. Meg a default gateway is mindenhol.
És akkor nézzük meg, mi borította ki a kollégát. Kéremszépen, megnézte az Exchange szerver route tábláját – és vagy 187 bejegyzést talált benne. 187 rosszat. Ez már nem volt annyira vicces.
Arra viszonylag hamar rájöttünk, mi történik: jön egy Outlook kliens valamelyik másik subnetből, az Exchange szerver meg felveszi annak a routernek a lábát a route táblába, ahonnan a kliens jött, természetesen a szabályban a kliens IP címe szerepel 255.255.255.255 maszkkal.
De miért is okozott ez a jelenség ekkora problémát?
Az elején mondtam, hogy az a bizonyos telephely borzalmasan kritikus az ügyfél számára. Ergo redundáns bérelt vonal van kihúzva, úgy, hogy a szolgáltatók sem azonosak. Ha ledől az egyik vonal, a routerek automatikusan átváltanak a másikra, az RSP is ennek megfelelően módosítja az útvonalakat. Csakhogy az a szerencsétlen helóta Exchange szerver minderről semmit sem tud, továbbra is a route táblájában lévő, immár fals kijárattal próbálkozik. Miért nem megy el az RSP-hez? Mert a 255.255.255.255 maszk szorosabban illeszkedik a csomagra, mint a default gateway maszkja.

Vadul elkezdtem keresni a neten, de nem igazán tudtam jól megfogalmazni a kérdésemet. Ha legalább a jelenség nevét tudnám. Végső menedékként dobtam egy körlevelet nagytudású, művelt cimboráimnak, hogy ki találkozott már ilyesmivel. Rövidesen meg is jött a válasz. Gömöri Zoli szerint a router dumál vissza a szervernek, hogy van egy rövidebb út Géza, mostantól menj arra, engem meg hagyj ki a buliból. Stone pedig megírta a jelenség nevét és azt, hogy hol lehet kikapcsolni. Imhol:

  • A jelenség – és a kulcs – neve: EnableICMPRedirects
  • Registry ág: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\

Ha az érték nulla, akkor a szerver magasról leszarja, mit mond a router.
Beállítottuk, az incidens elhárult.
Jöhetett a problémamegoldás. Biztos, hogy nem okoz galibát ez a registry módosítás? Mivel most már volt név a kezemben, körbenéztem. Találtam is egy ajánlást, hogyan védjük szervereinket (D)DOS ellen – hát például úgy, hogy a fenti értéket egyre állítjuk. Oké. Akkor ez a kérdés meg lett válaszolva.
De miért csak mostanában jelentkezett a hiba, régebben miért nem? Nos, kiderült, volt korábban egy RSP csere. A művelet tökéletesen sikerült, az új RSP remekül működött – csakhogy ez az ún. icmpredirect érték defaultban engedélyezett volt minden lábán. A réginél meg nyilván nem.
Azaz, ha biztosra akartunk menni, akkor nem csak az Exchange szerveren kellett beállítani, hogy ne figyeljen arra, mit mond a router – hanem a routeren is, hogy ne molesztálja a hostokat.
Most, és csak most mondhatjuk azt, hogy lekezeltük a problémát… írhatjuk végre a változásigénylést.

A Powershell és a Windows Server 2008 Core

2008-06-03 / / 5 Comments

Ez bizony két különböző világ. A Powershell az .Net alapú, márpedig a Server Core alatt nem fut a .Net.

Két dolgot tehetünk:

  • Megvárjuk, amíg a Microsoft valamelyik Feature Pack-ba belerakja.
  • Hekk!

Dimitrij Sotnyikov az utóbbit választotta. Istenem, türelmetlen típus.

Habár le is lehetne fordítani az írását, de mégsem teszem. A lépések annyira egyértelműek, a megértésükhöz sincs szükség semmilyen Rigó utcai certifikációra.

Szóval az írás. Itt.

ps1. Bár Dimitrij bevallja, ő is ‘szerezte’ az ötletet, Alex Kibkalo blogjából. De valamiért mégsem azt az írást linkeltem be.

ps2. Az írás korábban készült, de már erre a blogra terveztem kirakni. Gondoltam, pár napot csak tudok vele várni. Hát, nem. Közben Kurbli is kirakta.

Windows Server 2008 for Dummies

2008-05-25 / / 0 Comments

2007 végén, 2008 elején jelent meg a Technet blogon egy sorozat, melyben a Windows Server 2008 újdonságait igyekeztem bemutatni, kifejezetten egyszerű, szájbarágós módon. A megértést karikatúrák alkalmazásával próbáltam könnyebbé tenni.
Tisztára, mint a Dummies sorozat.

  1. Read-only Domain Controller
  2. A parancssor meglódul – server core
  3. A hálózat és annak védelme
  4. Látszólag
  5. A legegyszerűbb alkalmazásdisztribúció
  6. IIS7 – granulálok!
  7. Erőkagyló
  8. Aki nem lép egyszerre
  9. iSCSI
  10. Színház az egész világ
  11. Van másik!
  12. Címtár auditálás
  13. Kulcskérdés
  14. A klónok háborúja
  15. Szereti a tik a meggyet

Shell vs GUI

2007-12-03 / / 0 Comments

Különösen Exchange körökben gyakori téma mostanság a fenti két megközelítés összevetése. Ha napjainkban látunk valahol két embert vitatkozni, ahol az egyik a kényelmet, a másik a hatékonyságot erőlteti, jó eséllyel megtippelhetjük, hogy Exchange adminokról van szó.
Pedig a szembeállítás nem mai keletű.

Beesett egy igény a kollégákhoz. Ügyfél AIX rendszergazdája kért egy A rekord bejegyzést az egyik AD integrált DNS zónába. Konkrétan megadott TTL értékkel.
A helyi mérnök pislogott egy kicsit, aztán azt mondta, hogy rendben, majd intézkedik. Meg is kaptam a kérdést: lehetséges ez?

Ha a grafikus felületre nézünk, akkor nem. A rekordok a zóna SOA rekordjából öröklik a TTL beállítást, mely alaphelyzetben 1 óra. Gondoltam, megnézem, hogy egyáltalán a rekord objektumnak van-e olyan tulajdonsága, hogy TTL? Adsiedit. Nem találtam semmi hasonlót. Most akkor mondjam annak a morc Unix rendszergazdának, hogy a mi rendszerünk nem támogat ilyesmit? Ki fog kacagni, hiszen egy akármilyen mezei karakteres DNS szerver is ismeri azt a figurát, hogy gepnev 3600 IN A ip.cim. Legalább 25 éve.
Mondjuk, attól, hogy nem találtam semmit, még nem lehet kizárni, hogy ott van. Lehet, hogy belezárták egy blobba. Lehet, hogy rossz napja volt a dizájnernek és hülye nevet adott a tulajdonságnak.
Gugli.
És igen, valahol, egy fórumon találtam egy írást, ahol valaki – mintegy mellékesen – megemlíti, hogy lenullázta egy rekord TTL értékét. Tehát lehet. Most már csak az a kérdés, hogyan.
Nyilván parancssorból. Anno amikor vizsgára tanultam, ismertem is a progit, csak azóta kiesett a fejemből. Imhol a kérdéses sor:

dnscmd servername /recordadd zoneFQDNname hostFQDN ttl 3600 A ip.cim

Ja, hogy mi is az a TTL? Time-To-Live, azaz az az érték, ameddig a bejegyzés bentmarad a lekérdező DNS szerver cache-ében. Ha nullára állítjuk, akkor a rekordunk elillan, azaz sehol sem cache-elődik.

Az ellopott tartományvezérlő esete

2007-09-08 / / 0 Comments

A szerverszobában, a szokásos hétfő reggeli névsorolvasáson azt vesszük észre, hogy eggyel kevesebb tartományvezérlő válaszolja azt, hogy ‘jelen’.
Mi ilyenkor a teendő?
Először természetesen a pánik. Egy-két perc dühödt headbanging a szerverrack-en határozottan ki tudja tisztítani az ember tudatát.
Amint elül a pánik, az ember kezdi végigondolni a lehetőségeit. Sajnos ekkor már késő. Ugyanis nagyon gyorsan kellene cselekednie, hogy csökkentse a hálózatát fenyegető veszélyt.
A legjobb, ha már azelőtt elgondolkodik a helyzetről, mielőtt elcsakliznák tőle a gépet.

Ezt tette Steve Riley a 2006 szeptemberi Technet Magazinban.
Miután végiggondolt mindent, részletesen kielemezte a lehetőségeket, ezenkívül számbavett minden rejtekutat – a következtetését egy mondatban foglalta össze: ember, építsd újra az egész AD erdőt.
Borzasztóan hangzik. (Eltekintve attól, ha a kedves olvasó nem pont AD telepítésekből él.) Ennél még a korábbi pánik is kellemesebb volt.
Ezt Riley is elismeri, ezért hívja fel a figyelmet arra, hogy tegyünk meg időben mindent a tartományvezérlőink védelmében.

Azaz:

  • Láncoljuk le őket valami elvihetetlen tárgyhoz. Ha ugyanezt elektronikusan is meg tudjuk oldani az még jobb.
  • A címtárat több erdőből építsük fel, majd vezessünk be szelektív autentikálást.
    Azt hiszem, ez megér némi magyarázatot. Először is, ilyesmi csak Windows2003 címtárban létezik. Másodszor – és ez nekem is újdonság volt – a Microsoft szakított az eddigi ‘használj egy erdőt és egy tartományt’ modellel. Feltételezem, nem kis mértékben a szelektív autentikáció miatt.
    Mi is ez pontosan? Addig gondolom oké, hogy ha egy cég egy címtárban több erdőt használ, akkor azokat egy forest root-on keresztül össze is kell trustolnia. Itt, a truston lehet beállítani az autentikáció típusát: ez lehet teljes vagy szelektív. A teljes azt jelenti, hogy az egyik erdőbeli felhasználó (Farkas), amikor megpróbálja elérni a másik erdőbeli erőforrást (Piroska), akkor megadja a felhasználói nevet és jelszót, majd az erőforrás jogosultsági listája alapján vagy eléri azt, vagy sem. Ezzel szemben a szelektív autentikációnál már az is egy jogosultság, hogy a Farkas egyáltalán autentikálhatja-e magát.
    Ebben az esetben ha lenyúlják az egyik erdő tartományvezérlőjét, akkor csak az illető erdőt kell újrahúzni, illetve azokat az erőforrásokat megpiszkálni a többi erdőben, amelyek egyáltalán autentikálhatóak voltak a kompromittált erdő felől.
  • Telepíts read-only DC-t.
    Ez – mondjuk úgy – jótanács a jövőre nézve. Read-only DC majd a Longhorn Server családban lesz, mint ahogy ezen a blogon tanult kollégám nagyon alaposan ki is vesézte a témát.
  • Végül Riley leírja, hogyan kell gyorsan, hatékonyan címtárat tervezni. Gondolom azért, hogy újratelepítéskor nem kelljen azon agyalnunk, milyen elvek mellett is építettük fel anno az egyes alrendszereket.

Nos, oké. Riley letette a voksát.

Ekkor lépett színre Joe. (Joe Richards az egyik személyes kedvencem. Mint írtam korábban, a fiú Directory MVP, néhány nagy sikerű segédprogram megalkotója és a maga kendőzetlen, nyers modorában egészen jó cikkek szerzője.)
Szóval Joe rögtön azzal kezdi, hogy ez egy nagyon jó a kérdés, de szerinte teljesen rossz a válasz. Nem is vacakol sokat, felsorolja a _rögtön_ lezongorázandó teendőket:

  • Töröljük az ellopott tartományvezérlőt a címtárból. Azonnal. Gondolkodás nélkül. Erre teljesen jó az NTDSUTIL segédprogram. (Én fűzném hozzá, hogy ha volt a DC-n valamilyen FSMO, akkor azt természetesen el kell tőle rabolni.)
  • Reseteljük mindenkinek az accountját, akinek lokális belépési lehetősége volt a tartományvezérlőkön. (Népszerűségi indexünk egész biztosan fel fog szökni – de erről majd később.)
  • Reseteljük mindenkinek az accountját, akinek file/registry/services módosítási joga van az erdő tartományvezérlőin.
  • Reseteljük mindenkinek az accountját, akinek jogosultsága volt bármilyen AD-hoz kapcsolódó alkalmazás (Exchange, SMS, MOM, stb…) menedzseléséhez.
  • Ha a fenti adminok közül valamelyiknek van nem admin felhasználója, reseteljük azt is. Lehet, hogy az illető ugyanazokat a jelszavakat használta.
  • Reseteljük az összes DC jelszavát. (Segítségképpen megadja, hogy a PSExex és a NetDom resetpwd lesz a mi barátunk.)
  • Reseteljük a krbtgt tartományi felhasználó accountját. Méghozzá kétszer. Ekkor fognak elveszni a korábbi TGT-k. Szerencsére. (TGT: Ticket Granting Ticket; jegy, amellyel jegyet lehet igényelni a Kerberos szervertől.)
  • Reseteljük mindenkinek az accountját, akinek joga volt a normális felhasználói aktivitáson túl belepiszkálni a címtárba.

És most el lehet kezdeni filozofálni. Joe véleménye szerint a fenti adminisztrátori teendőkhöz 2-5 adminisztrátor bőven elegendő. Határozottan kijelenti, hogy ennyi accounttal végigzongorázni a fenti listát, másodpercek kérdése. Ha több accountunk van, érdemes szkriptelni. Ha ez a gyorsaság nem megy kézségszinten, nos, akkor Joe szerint kutyaütők vagyunk, nem rendszergazdák. A címtár a hálózat legnagyobb értéke, akinek a dolga ezt védeni, annak nagyon ott kell lennie a szeren.

A másik filozófikus kérdés: egyeztessünk-e előtte? Joe szerint semmiképpen sem. Tegyük a dolgunkat. Itt másodpercek számítanak. És ha azok az opciók, hogy lesz néhány parázs veszekedésünk vagy egy korrupt címtárunk… akkor mindenképpen az elsőt kell választanunk. Sőt, Joe szerint már akkor elveszítettük a csatát, ha éles helyzetben egyáltalán azon filózunk, hogy értesítsük-e őket vagy sem.

A fentieken kívül két dolgot kell még megtennünk:

  • Járassuk le a sárga földig az összes felhasználó jelszavát. Előtte azért szóljunk oda a helpdesknek…
  • Figyelmeztessük az összes rendszer összes service account tulajdonosát, hogy egy órán belül változtassák meg az accountok jelszavát. Ha nem teszik meg, változtassuk meg mi. Jobb utólag röviden elnézést kérni, mint hetekig tartó türelmet később. Egy ideiglenesen leállt alkalmazás nem ugyanaz a nagyságrend, mint egy korrupttá vált címtár. (Nem tudom… azért a banki alkalmazásoknál nekem lennének kétségeim. Ezzel – Joe szerint – meg is buktam. Ő ugyanis a nem tervezett leállítás viszonylag rövid idejét veti össze a címtár – újrafelépítés okozta – hosszabb leállás idejével. Igenám, de az utóbbi tervezett. _Normális_ leállás után a cég addig kitalál valami metódust, mittudomén, papírnoteszt és postagalambot, meg egy adatfeldolgozási technikát, hogy hogyan lehet majd ezeket beledolgozni az újra felállt rendszerbe. Lehet, hogy ez kevesebb költséggel jár, mint egy inkonzisztens adatbázis.)

Végül természetesen a hapi szót kerít arra, hogy régen rossz, ha egy ilyen helyzetben improvizálnod kell. Hiszen rég a fiókban – és a megfelelő emberek fejében – kellene lennie a haváriatervnek.
Hogy miért is jó egy ilyen terv? Itt inkább idézem Joe-t:

A. Understand what your weaknesses are now so you can correct them.
B. Be able to block things others try to bring into your environment that will add more weaknesses later.
C. Have something you can follow when the fan and the excrement meet f2f.

Itt a vége felé térjünk vissza egy kicsit a realitás talajára. Azért ma már szinte mindenütt természetes, hogy van valamilyen szerverszoba – és ezek valamilyen formában zárhatók is. Ilyen helyekről szervert ellopni már nem olyan egyszerű.
Csakhogy… nem csak cégközpontok vannak a világon, hanem telephelyek is. Márpedig mifelénk még mindig elég drága a sávszélesség ahhoz, hogy érdemes legyen távoli helyekre is egy-egy lokális tartományvezérlőt lerakni. Általában az is igaz, hogy ezek a vidéki DC-k leginkább munkaállomás kategóriájú gépek, lelökve valamelyik sarokba – hiszen a plusz gép költségét is nehezen nézik el az informatikának, nemhogy még szerverszoba is legyen a telephelyen. Nos, ezeket már könnyű megcsapni – márpedig akármennyire vidéki is a DC, de ott van rajta a tartományi névtér írható változata, az egész erdő konfigurációs névterének írható változata és az egész erdő sémájának olvasható változata.
Ijesztő.
Erre lesz majd megoldás a Read-only DC – hiszen az azon végrehajtott Ad változtatások nem replikálódnak szét a címtárban, így hiába dugná vissza a gonosz tolvaj a preparált tartományvezérlőt, nem érne vele semmit. (Ettől függetlenül a tartomány felhasználóinak a jelszavát feltörheti, tehát a fentebb írt jelszó resetelések tartományi szinten továbbra is meg kell történjenek.)

Nos, ennyi. Elolvashattunk két véleményt. Nekem a magam részéről Joe elképzelése jobban tetszik – különösen azért, mert felhívja a figyelmet, hogy lennie kell egy alaposan kidolgozott tervnek erre az esetre is.
Tényleg, nálatok van?