Van ez a kiváló eszköz, ami kiváltja a szerverre való belépést, hisz ha felinstalláljuk, akkor a gépünkről elérjük az adott szerver Server Managerét, illetve akár az Active Directory : felhasználók és számítógépek programját. Először is innen töltsük le:

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=7887

Ez a Windows 7-hez jó. Ha megvagyunk vele, akkor be kell állítani mit szeretnénk elérni. Ezt a Vezérlő pult / Programok és szolgáltatások / Windows szolgáltatások ki-be, bekapcsolása alatt érjük el.

RSAT windows szolgáltatás bekapcsolása

Kapcsoljuk be az összes jelölő négyzetet, így minden eszközünk meglesz a menedzseléshez. Ez által megjelennek az Administrative tools-ban a felinstallált elemek. Az AD, DHCP, DNS, Certificate service stb MMC konzolok. Ha mégsem, akkor csináljunk egy újraindítást.

Ha ezzel megvagyunk, akkor örülünk. Például indítsuk el a Kiszolgáló kezelőt. Próbáljuk meg csatlakozni egy adott szerverhez. Ahhoz, hogy ez sikerüljön, előtte állítsuk be a szerveren a Server Managerben, a Configure Server Manager Remote Management-et. Így:

remote management

De még ezek után is előfordulhat ez:

Kiszolgáló kezelő nem tud csatlakozni...

Ugyan ez azt mondja, hogy engedélyezzük amit már fent megtettünk, de hát evvel nem vagyunk előbbre. Ezért csináljunk valami mást, mert úgy tűnik még mindig nem fogadja a kérésünket a WS Management a cél szerveren. Lépjünk be Remote Desktoppal a másik szerverre és indítsunk egy Powershell-t. Majd írjuk be ezt:

winrm quickconfig

erre valami olyasmit kaptunk:

WinRM already is set up to receive requests on this machine.

WinRM is not set up to allow remote access to this machine for management.

Ennek megoldására adjuk ki ezt a parancsot:

enable-psremoting -force

Ez meg fogja oldani minden gondunkat.

Történt egyszer, hogy áramszünet volt és fent említett szerver kikapcsolódott. Újraindulás minden szépen működni látszott. Aztán mégis kiderült, hogy mégse igaz ez teljesen, mert a levelezés nem mén.

Mit csinál ilyenkor az egyszerű, de lelkes gazda?

Mindenek előtt mentést csinál az exchange adatbázisról

tesztel: jön be levél, megy ki levél? Nem, és igen. Ilyen sorrendben. Mert pl kifele mén a levél és megkapja, de a válasz nem érkezik meg sosenem.

Exchange szolgáltatásokat indít, újraindít

Adatbázist mozgat

Symantec szolgáltatásokat tilt le

Próbálkozik különböző accountokkal is

Adatbázist mountol, dismountol

Adatbázist tartalmazó könyvtárának a jogait ellenőrzi

AZTÁN MÉGSE JÓ

Végül kiderült -némi segítséggel-, hogy nem az adatbázissal van baj, hanem az Information Store service-el, és leginkább a Symantec Mail Security-jével. Mert ez utóbbit, nem bántotta, mert az Manual indítási formában volt, és nem tulajdonított neki jelentőséget. Aztán pedig de.

Szóval a Mail security 2 szolgáltatásának ki-bekapcsolgatásával, végül jó lett.

Hm. Mi ebből a tanulság? Ne keressünk okokat:)

Gyanússá vált az egyik szerver. Mégpedig a Windows 2003 SP2. Azt tűnt fel, hogy nem lehet felmenni a Microsoft, a windowsupdate és egyéb antivírus oldalakra (Symantec, Eset, Kaspersky stb). Egyébként jól működött. De mégsem tetszett a dolog, és a szokásos módon csökkentett módban újraindítva, szépen leellenőriztem a Malwarebytes szoftverével. Némiképp beárnyékolta a dolgot, hogy nem tudott frissülni, mert nyilván a malwarebytes.org sem volt elérhető. Hmm. Mindenesetre lefuttattam és semmit se talált. Kipróbáltam még egy másikat is, de az se talált. Hát mit mondjak nem voltam megnyugodva. Aztán gondolkoztam mi lehet a bibi, hogy a fenti oldalakon kívül minden más bejön. El kezdtem nézelődni DNS tájékán és mit írt ki az ipconfig -displaydns?

Hát, hogy elég sok CN domain van ottan… Hm. Felettébb gyanús…kínaiak már itt is itt vannak???

Flushdns-el kitöröltem, kipróbáltam, nem jó. Újraindítottam, kipróbáltam, nem jó.

Displaydns-re megint előjöttek rengeted zagyva kínai oldal bejegyzés pl.: eskduvre.cn

Most már biztos voltam benne, hogy itt valami kártevő lakik. Aztán valahogy rátaláltam a Kaspersky oldalán a Removal Tools-ra és az ki is hozta, hogy a System32-ben ott csücsül egy gonosz DLL. És ő maga a Net.worm.win32.kido.ih. Megsemmisítette, majd minden rendben működött. Érdekes, és persze jó is csak egy kis darabja volt a rendszeremben, legalábbis az előző leíráshoz képest. És az is érdekes a Microsoft  szerint (MS08-067), ez a sebezhetőség már az SP2-vel orvosolva volt.

Hát mégse. Mi ebből a tanulság? Ne bízz 100%-osan egy viruskergetőben sem. És gyakran frissíts windowst, és legyél okos:), hogy felismerd ezeket a gyanús viselkedéseket.

Szeretnénk ha egy felhasználónak erősen korlátozott jogai lennének egy domainben. Ez konkrétan csak egy program elindítását jelenti, a többi beállítás, start menü, stb tiltva legyen. Mit fogunk csinálni? Egy OU-t hozunk létre a tartományban, majd az abban figyelő felhasználó(k)ra lesz érvényes a házirend.

Hozzunk létre egy OU-t a tartományunkban, majd abban a kívánt felhasználót. Vagy ha már létezik, akkor pottyantsuk bele.

Group policy készítés első lépés

Ha ezzel megvagyunk, akkor a létrehozott OU-n jobb klikk, tulajdonságok, majd az utolsó fülön, – Group policy-, válasszuk az Open gombot.

Group policy lassan megjelenik

Erre megnyílik a várva várt Group Policy Management program, ahol mindent el tudunk rontani…:)

A titokzatos Group Policy Management

Itt szemünk elé tárul a fa struktúránk, benne is a nemrég készített Organization Unit-unk. Na, a szokásos jobb gombos menüből, amit az OU-ra kattintva kapunk, válasszuk a Create and Link a GPO here…-t. Adunk neki egy szimpatikus nevet, ezzel elkészítettünk egy GPO-t, a szervezeti egységünk alá. Válasszuk ki bátran, és ekkor látjuk a fenti képet. Természetesen belefirkálások nélkül fogjuk látni:) Jobb oldalt alul, a Security Filtering részben, töröljük az az alapértelmezett felhasználókat, mert akkor mindenkire vonatkozni fog a házirend. Viszont bele kell tenni azt a felhasználót, akire érvényesíteni szeretnénk.

A GPO-n jobb klikk és az Edit-et választva, a Csoportházirendobjektum-szerkesztőben találjuk magunkat. Itt ízlés szerint lehet szűkíteni a felhasználó jogait.  Én a Felhasználó konfigurációja alatt matattam, a Start menü és tálca, Asztal és a Vezélőpult beállításait változtatva. Figyelem, ezek a változtatások azonnal érvényre jutnak mihelyst, az adott ablak OK gombjára nyomunk. Ezért érdemes kipróbálgatni egy kliensen az eredményt.

Ha nem frissülne a házirend a kliensen, akkor a gpupdate paranccsal siettetethetjük.

Miről is van szó? Például a postaláda megteltségére vonatkozó levelekről. Ha nem tetszik ahogy kinéz, vagy más tartalmat akarunk bele. Két megoldás kínálkozik. Az egyik: letöltjük az RLTOOLS-t innen, majd ezzel szerkesztjük a Exchsvr\bin\MDBSZ.dll-t, mivel ott taláható a beépített levél sablon, amit küld az Exchange szerver.

A másik, ami talán felhasználóbarátabb, bár elég sok lépésből áll, az az Exchange Quota Message Service használata. Jelen esetben, mivel ezt csináltam meg, ezt fogom részletezni.

Hogy is működik ez tulajdonképp? Az elv az, hogy van ez a fent említett service, és néhány registry módosítás után ami letiltja a beépített üzenetküldést, átveszi az irányítást, és egy erre a célra létrehozott mailbox-ban található levél sablonokat küldi. Ennyi az egész. Lássuk részletesen.

Mi kell hozzá? Először is egy Exchange 2003 server:), ami legalább SP1-el fel van vértezve. Aztán kell maga a service, ami innen letölthető. És a postaláda.

Hozzuk létra a felhasználót, valami beszédes névvel. Adjunk neki postaládát is. Legyen a neve QuotaMessageService.

Installáljuk fel az ExQMS-t. Az exe először kibontódik, az általunk megadott könyvtárba, majd indítsuk el a ExQMS.msi-t. A szokásos licence elfogadás és célkönyvtár megadása után, bekéri az email címet ahonnan fogja küldeni a leveleket, és ahol a template-k találhatóak. Az előbbi felhasználónevet feltételezve ez a QuotaMessageService@domainnév.com lesz. Természetesen a @ utáni részt mindenki a saját domainjére cserélje.

Ha ez megvan, jöhet a registry módosítás. Nyissuk meg a HKEY_LOCAL.MACHINE\System\CurrentControlSet\Services\MSExchangeIs\szervernév alatt a Private-al kezdődő ágat. Ahol a szervernév a saját szervered neve. Készítsünk egy új duplaszó típusú bejegyzést a Local System Ignores Quota névvel. Értéke legyen 1. Megjegyzendő, ha több private ág is található a fenti kulcsa alatt, akkor mindegyikben meg kell csinálni ezt a módosítást. Ha már így benne vagyunk, akkor készítsünk még egy ilyen jó kis duplaszavas bejegyzést, melynek neve…legyen a Disable Quota Messages,értéknek szinten adjunk 1-et.

Indítsuk újra az Exchange Information Store service-t, ezt megtehetjük a Computer Management, Service-es szekciójában, vagy parancssorból a NET STOP MSExchangeIS és NET START MSExchangeIS parancsok kiadásával.

Ha ez megvan, akkor örüljünk, de nem vagyunk még kész:)

Lépjünk be egy kliens gépen a QuotaMessageService-el, és konfiguráljuk be az outlookot. Az ExQMS telepítése közben létrejön egy személyes mappa, QuotaMsg.pst néven a szerveren a c:\program files\Microsoft Exchange Quota Message Service könyvtárban. Ezt másoljuk át a kliens gépre és állítsuk be az outlookban. Ebben vannak a sablonok. Másoljuk is át a postaládába a QuotaMessages foldert, ami alatt a 1033-as alkönyvtár van. Fontos, hogy ne az Inbox alá másoljuk, hanem a gyökérbe. Az itt található 3 db levél, a warning, nosend, és nosendreceive levél alapján küldi a service a megfelelőt, attól függően, hogy melyik beállított kvótát lépte túl a delikvens. Az ezekben a levelekbe csatolt sablonokat módosíthatjuk kényünk kedvünk szerint.

Indítsuk el a Microsoft Exchange Quota Service-t a szolgáltatások fülön, a comp. managementben. Ezzel kész is vagyunk. A megengedett postaláda méreteket, pedig az Exchange System Manager-ben állíthatjuk, a Mailbox Store tulajdonságai alatt.