Archívum

Archive for the ‘Exchange’ Category

Exchange mentések vs Hyper-V

szeptember 15, 2016 Hozzászólás

Adott helyen egy VM (történetesen egy Exchange) átkerült egy 2012-es gazdagépről egy 2012 R2-t futtató gépre. A mozgatás után látszólag minden rendben működött, így a rendszergazda kollégák nem bolygatták többet.

Egy bizonyos idő eltelte után a szerver nem volt hajlandó fogadni a leveleket, a monitorozó-rendszer erőforráshiányra panaszkodott. Megnézve a paramétereket, a kollégák egyből kiszúrták, hogy itt bizony merevlemez-kapacitás hiányzik, s tudjuk, hogy az Exchange-be épített Back-pressure hatására inkább visszautasítja a levelek fogadását, mint veszélyeztesse „saját épségét”. Tüneti kezelésként gyorsan felszabadítottak némi helyet, de természetesen nem hagyták annyiban a dolgot, biztos, ami biztos alapon segítséget is kértek.

Utánajárva, hogy miért lett tele a kötet, kiderült, hogy a naplók törlése nem történt meg (ez akkor történik meg, amikor egy teljes mentés készül az Exchange-ről). Kiderült, hogy magán a levelező szerveren nem volt beállítva mentés, de a gazdagépen viszont igen, mégpedig a teljes VM mentése. Ez „triggerelni” szokta az Exchange-logok törlését is, itt viszont nem történt meg. Az okot keresve elég hamar rátaláltunk, hogy mikor volt az utolsó teljes mentés (Exchange-konzol segítségével kiolvasható), majd mivel a jelzett dátum körül történt a mozgatás, nyilvánvalóvá vált, hogy ezzel függ össze. Szerencsére a gazdagép Hyper-V konzolját megnyitva egyből látszott a probléma: az Integration Services (itt írtam róla legutóbb) nem volt naprakész. A friss, 2012 R2-s kiegészítőket telepítve, majd a VM-et újraindítva a következő mentés egyből ismét helyreállította a rendet.

Office 2016 gondolatok

november 6, 2015 7 hozzászólás

Az új Outlook 2016 sok embernek fog fejfájást okozni. Az ok egyszerű: Exchange kiszolgálóhoz csak akkor fog tudni csatlakozni, ha rendesen be van állítva az autodiscover szolgáltatás. Mielőtt ezt részleteznénk, nézzük a manuális lehetőségeket: vagy Outlook.com, illetve más Exchange ActiveSync (EAS)-kiszolgáló, vagy Pop/Imap kiszolgáló. Az EAS nem használható Exchange esetén, ugyanis az EAS-protokollt is tervezik kivezetni (miután az Outlook.com-ot átteszik Exchange-alapúra), helyette az OutlookAnywhere használata javasolt. Az idők folyamán így alakultak a lehetőségeink (teljesség igénye nélkül):

Outlook 2003: outlook2003

Outlook 2010: Outlook2010

Outlook 2013: outlook2013

Outlook 2016:outlook2016

Mivel manuális lehetőségünk nincs, nem marad más hátra, mint a levelezés automatikus beállítása. Ahhoz, hogy ez működjön, már Exchange 2007 óta velünk van az Autodiscover lehetőség – még ha eddig nem is mindenki használta.

No de miről is szól ez? Nagy vonalakban: a kliens kiküld egy igényt, mely szerint szeretne adott tartomány CAS-kiszolgálójához csatlakozni, erre kap egy választ, ami alapján „bekonfigurálja” magát (halkan megjegyzem, ez most tényleg nagyon konyha-nyelven volt elmondva). Ahhoz, hogy ez működjön, természetesen a minimum a jól beállított Exchange-kiszolgáló – s itt máris elakadtunk, hiszen az önjelölt rendszergazdák számára a levelezés beállítása kimerül a ki/bejövő forgalom megvalósításánál. Ha ezt az akadályt vettük, akkor még tanúsítvány(ok), illetve a DNS-nevek megfelelő beállítása van hátra.

Nem tartom kizártnak, hogy az új, 2016-os Office terjedése kapcsán nőni fog a „piros gombos” hívások száma, hiszen elég sok helyen a kiszolgáló alap-beállításokkal fut. S akkor még nem beszéltem arról, amiről már egyes kollégák is írtak, hogy Outlook-foltozás volt szükséges bizonyos Exchange-kiszolgálókkal való együttműködéshez.

Kategóriák:Exchange Címkék: , ,

Exchange DAG szívások

szeptember 15, 2015 Hozzászólás

Adott projekt kapcsán belefutottam egy olyan hibába, hogy az Exch DAG nem akart összejönni – az adatbázis replikációja folyamatosan hibára futott, azzal az üzenettel, hogy az elsődleges kiszolgálón hiányolt egy log-állományt (ami viszont ott volt). Sebaj, ezt a múltkor (bár nem írtam le) egy új adatbázis létrehozásával kerültük ki, amibe átmozgattuk a postafiókokat, most pedig úgy, hogy ideiglenesen áttettük körkörös logolásra, ekkor már simán létrehozta a másolatot (utána természetesen illik visszaállítani a logolást).

Következett (volna) a PF replikációja. Nos, itt látszólag minden szép és jó volt – csak épp replikáció nem történt… Tekintettel arra, hogy 2003-asról migráltak, a múltkoriak alapján manuálisan kellett létrehozni a szükséges mappákat (amennyiben nem akarunk manuálisan belenyúlni, akkor setup.com /prepareAD ismételt futtatásával is illik létrejönnie), valamint a megfelelő nyilvános mappa adatbázisokon módosítani az msExchOwningPFTree értékét, hogy a most létrehozott PF mappa DN-jére mutasson. Viszont az IS újraindítása után (mindkét szerveren) továbbra sem változott a helyzet – így ismét közösen folytattuk a nyomozást.

Egy eddig nem említett lehetőséget vetettünk be: a loggolás szintjét megemeltük (Server configuration, kiszolgálón jobb klikk, Manage Diagnostic Logging Properties) az alábbiak szerint:

  • MSExchangeIS
    • 9001 Public
      • Replication Backfill – High
      • Replication Errors – Medium
      • Replication General – High
      • Replication Incoming Messages – High
      • Replication NDRs – High
      • Replication Outgoing Messages – High

Az Application eseménynaplóban ezután a MSExchangeIS Public Store által generált alábbi bejegyzéseket kell figyeljük (teljes lista itt):

  • 3030
  • 3038
  • 3018
  • 3027

Ennek alapján tisztán látszott, hogy az eseménynaplóban szerepelt a kiküldött levél, de az is kiderült, hogy kiküldésre sem kerülnek a szinkronizációs levelek. Az ok: a kollégák a leírásból az utolsó lépést kihagyták: a Servers konténer törlését. Tartalmilag üres volt, de a konténer még létezett – ennek eltávolítása után máris helyreállt a replikáció.

Igen ám, de az előző tesztelések eredményeképpen az Exch2-n látszólag két PF lett felcsatolva. Ezt nem lehetett látni a PF-management konzolból (ott ráadásul a szerver kiválasztása ablakban hiba is fogadott), egyedül adott PF-mappa replikációjának beállításánál látszott ez a rossz állapot.

Lefuttattuk a

Get-MailboxServer | Get-PublicFolderDatabase

parancsot, ahol egy hibaüzenet segített a megoldás felé vezető úton:

WARNING: The object EXCH2-PFDB02 has been corrupted, and it’s in an inconsistent state. The following validation errors happened:

ADSI Edittel ellenőrizve/javítva a PF objektum msExchOwningPFTree tulajdonságát (ez magával vonja a visszacsatolás – BackLink – értékének módosulását is az msExchOwningPFTreeBL mezőben), majd az IS szolgáltatást újraindítva helyrebillent a lelki béke 🙂

Mielőtt még hátradőltünk volna, a végén, miután megvolt az új CAS Array is, a felhasználók panaszkodtak az ActiveSync működésképtelen voltára. Erre szerencsére „gyors” (értsd: Exchange-tempós 🙂 ) megoldást jelentett a Server config/Client Access varázslójának újrafuttatása (haladóbbak vehetik sorra az alól található fülek: OWA, ECP, stb. beállításait), hogy biztosan mindenhol jól legyen beállítva a külső csatlakozási elérhetőség (external name).

Kategóriák:Exchange Címkék: , ,

Exch 2010 SP3 UR8 – nem szabad!

december 12, 2014 8 hozzászólás

Bár nem szeretném elvenni a kenyeret a különböző hírportáloktól, de néhány nap eltelte után sem láttam még azt a hírt, hogy a Microsoft ismét elbaltázott egy frissítést (részint érthető, hiszen csak az hibázik, aki dolgozik – részint viszont olyan alaphiba csúszott be, ami egy hétköznapi tesztelésen már kiderült volna).

Konkrétan nem egy akármilyen termék, a piacon csak bizonyos nyelvi verziókat érintő foltról van szó, hanem a címben említett javításról. A környezetemben a legtöbb levelezési rendszer Exch 2003/2010 alapokon nyugszik (ez nem reprezentatív felmérés 🙂 ), s ezeken elég sok felhasználó postafiókja tengődik. Nos, a rendszergazdáknak álmatlan éjszakákat okozni azzal, hogy a folt telepítése után az Outlook véletlenszerűen nem tud megnyitni elemeket (pl. levelek, mappák), nem tud státuszt váltani (pl. olvasott/olvasatlan), illetve ismételt jelszó-kérésekkel bombázza a felhasználót (közöttük lehetnek VIP-userek is) – véleményem szerint nem a legjobb Karácsony előtti elfoglaltság.

Megoldás: nem szabad feltenni. Aki már feltette, az nyugodtan távolítsa el, egy újraindítás szükséges, de a nyugalom érdekében megéri. A Microsoft már visszavonta a foltot, dolgoznak a problémán, egy újabb verziót fognak kiadni – de aki Wsus-al rendelkezik (ki az, aki nem?), ott is a “Nem engedélyezett” státuszról nyugodtan tegye “Tiltott” állapotba.

Támadás-sorozat

április 24, 2014 Hozzászólás

Egyik ügyfélnél a biztonsági naplóban elkezdtek sorozatosan megjelenni Security 529 azonosítójú hibaüzenetek:

Forrás Eseményazonosító Legutóbbi előfordulás Összes előfordulás
  Security 529 2014.04.21. 3:20 1 530 *
Bejelentkezési hiba:
  Ok: Ismeretlen felhasználó vagy rossz jelszó
  Felhasználónév: oracle
  Tartomány:  
  Bejelentkezés típusa: 3
  Bejelentkezési folyamat: Advapi
  Hitelesítési csomag: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
  Munkaállomás neve: DL380
  Hívó felhasználóneve: DL380$
  Hívó tartománya: DOMAIN
  Hívó bejelentkezési azonosítója: (0x0,0x3E7)
  Hívó folyamatazonosítója: 2052
  Átvitt szolgáltatások:
  Forrás hálózati címe:
  Forrásport:

Első körben ellenőrizték a tűzfalat, de ott nem volt sem az RDP, sem a http beengedve, de természetesen az SMTP igen. Ez a tény, valamint a folyamat azonosítójának visszafejtése (Inetinfo.exe) vezettek el oda, hogy valószínűleg STMP-támadás áldozatai lettek.

További adatok kiderítése céljából az ESM-ben megemeltük a logolást: STMP-protokoll/log engedélyezés, majd a loggolás engedélyezése mellett található tulajdonság-lapon, annak is a speciális fülén tudunk további adatokat bekapcsolni.

Ennek alapján kiderült az ip-cím, majd ezt lekövetve az is, hogy egy Shanghaj-i címről küldik a hitelesíteni próbálkozó emaileket. Ilyenkor néha segít, ha a támadó gép szolgáltatójának írott levéllel jelezzük, hogy adott kliense fertőzött – volt, hogy ilyenkor aktív kommunikáció alakult ki 🙂

 

Kategóriák:Exchange Címkék: ,

Exchange 2010 SP3 UR2

augusztus 19, 2013 3 hozzászólás

A múlt héten, kedden kijött frissítések (legalábbis a címben említett folt biztosan) megmutatták, hogy miért jó megfontoltan telepíteni a javításokat. Legalábbis azon kollégák egy részénél, akik rendelkeznek a piros gombbal, páran máris jelezték segítségbeli igényüket.

A gond ugyanis az, hogy a megszokottól ellentétben az említett folt igényli az SP3 telepítőt. Ha ezt automatikusan nem találja, illetve a telepítés során nem mutatjuk meg neki (pl. automatikusan Wsus-ról próbál települni), akkor  Error 8024002D hibaüzenettel sikertelen telepítésnek lehetünk tanúi:

Exch2010SP3UR2

Nem kell megrémülni, a szokott helyről letöltve az SP3-at, kicsomagolva, majd újraindítva a telepítést sikeresek lehetünk. Sőt, ha nem akarunk azzal bajlódni, hogy megmutassuk a telepítőnek a szervízcsomag helyét, csomagoljuk ki egyből abba a könyvtárba, ahol az várja. Ennek lekérdezése az alábbi paranccsal történik:

Get-ItemProperty “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{4934D1EA-BE46-48B1-8847-F1AF20E892C1}” | Select InstallSource

A kicsomagolás után ráengedjük a foltot, majd hátradőlhetünk…

p.s. a folt telepítése utáni újraindítást követő ellenőrzésre (mint itt írtam, nem jó a szokásos Get-ExchangeServer) használhatjuk vagy a már hivatkozott cikkbeli Névjegy-et, vagy az alábbi parancsot:

GCM exsetup |%{$_.Fileversioninfo}

Kategóriák:Exchange Címkék: , ,

Email-méret és BPA

május 24, 2013 Hozzászólás

A szokástól eltérően, a teljes megértéshez kicsit megfordítottam a leírás sorrendjét, időrendben haladva az ok-okozati összefüggések taglalásában.

Adott ügyfélnél, egy SBS 2011-nél, felmerült egy olyan igény, ami alapján (bár jeleztem, hogy nem életszerű, de) beállították a levelezéshez megengedett korlátot 25 MB-ra.

Rá egy időre lefuttatták a BPA-t, amely egyből jelezte, hogy

„The Internet Information Services (IIS) virtual directory for EWS has a maxRequestLength value that does not match the get-transportconfig MaxSendSize value.”

Mint tudjuk, a BPA kapásból javasol is javítást:

1. Find the Web.config file on the Client Access server. The default location is C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\ews.

2. Make a backup copy of the web.config file.

3. Start the Exchange Management Shell and use powershell “get-transportconfig | ft MaxSendSize” to get the global max Send size, for example, 20M.

4. Find the maxRequestLength value, and change it to the value that you want. The value is in Bytes. The maxRequestLength value in the Web.config file: <httpRuntime maxRequestLength=”2097151″ />. Make this value match the one from get-transportconfig command line.

5. Save and close the web.conifg file.

Szófogadóak voltak, így a fenti ajánlás szerint beállították, sőt, biztos, ami biztos, a Default Web site-ot is újraindították – majd bizonyos idő elteltével különböző hibák miatt Lotus szavaival élve „megnyomták a piros gombot” 🙂

Mielőtt még hívtak volna, s elhárítva a problémákat felgöngyölítettem volna a történteket, a következő hibák jelentkeztek.

1. a „legkisebb”, hogy az Alkalmazás eseménynaplója tele lett ASP.Net 2.0.50727.0 által generált, 1310 azonosítóval rendelkező figyelmeztetéssel:

Event code: 3008

Event message: A configuration error has occurred.

Application information:

    Application domain: /LM/W3SVC/1/ROOT/EWS-3283-130129818793082179

    Trust level: Full

    Application Virtual Path: /EWS

    Application Path: C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\EWS\

    Machine name:

Exception information:

    Exception type: ConfigurationErrorsException

    Exception message: The value for the property ‘maxRequestLength’ is not valid. The error is: The value must be inside the range 0-2097151. (C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\EWS\web.config line 2377)

2. Outlookból nem lehetett beállítani az Out-of-Office lehetőségét, hibára futott (OWA-n gond nélkül működött):

„Your automatic reply settings cannot be displayed because the server is currently unavailable. Try again later.”

OutOfOffice

3. A mobilről történő email-szinkronizáció (ami régebben ment), most nem működött

4. új felhasználó létrehozásakor a kezdeti Welcome-üzenetet nem tudta kiküldeni (a log útvonala: C:\Program Files\Windows Small Business Server\Logs\adduser.log)

[29532] 130513.203257.3291: Messaging: CreateBaseMessage with Exchange Service Binding url [https://sites/EWS/Exchange.asmx]

[29532] 130513.203257.5479: Messaging: Failed to submit email via Exchange Web Services. Message: Client found response content type of ‘text/html; charset=utf-8’, but expected ‘text/xml’.

The request failed with the error message:

<b> Description: </b>An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.

<b> Parser Error Message: </b>The value for the property ‘maxRequestLength’ is not valid. The error is: The value must be inside the range 0-2097151.

<httpRuntime maxRequestLength=”25845760″ />

<b> Source File: </b> C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\EWS\web.config<b>

[ConfigurationErrorsException]: The value for the property ‘maxRequestLength’ is not valid. The error is: The value must be inside the range 0-2097151. (C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\EWS\web.config line 2377)

[HttpException]: The value for the property ‘maxRequestLength’ is not valid. The error is: The value must be inside the range 0-2097151. (C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\EWS\web.config line 2377)

[29532] 130513.203257.5635: Messaging: MessagingTaskException: Failed to submit email via Exchange Web Services – Error# (80003)

A megoldás a maximális, régi érték (2097151) visszaírása lett. Ugyanakkor nem mellékes megemlíteni, hogy KB cikkben már „ismert problémaként” írnak róla, gyakorlatilag a BPA ajánlásának figyelmen kívül hagyása javasolt. Ugyanakkor a mellékelt nyomozás jelzi, hogy nem csak a BPA bolondul meg magasabb érték esetén…

Exchange 2010 EMC Initialization failed

február 5, 2013 12 hozzászólás

Egy érdekes hibában kérték a segítségem. Adva van egy SBS 2011, ami frissen van telepítve, s teljesen jól működik, majd hirtelen egyik napról a másikra az Exchange kezelőfelület nem érhető el, se EMC, se EMS használatával. A hibaüzenet:

„Initialization failed

The Following Error occurred while attempting to connect to the specified Exchange server

The attempt to connect to http://…/Powershell using “Kerberos” authentication failed:

Connecting to remote server failed with the following message: Logon Failure: unknown user name or password. For more information, see the about_Remote_Troubleshooting Help topic.”

EMCKerberos

Rákérdezve, a szokásos választ kaptam: senki nem módosított semmit, „magától” állítódott el. No persze 🙂 Természetesen első körben az IIS-re gyanakodtam, hogy esetleg ott állítottak el valamit. Ellenőriztem az útvonalat, a jogosultságokat – de minden rendben volt. Egyáltalán már az furcsa volt, hogy eddig ugyanezzel a felhasználóval semmi gond nem volt, jelszó sem változott – mégis rossz hitelesítésre panaszkodik.

Az első körben történt ellenőrzések után jött egy ellenpróba: egy másik, megfelelő jogosultságú felhasználóval történő bejelentkezés, illetve a programok futtatása. S íme, ott nem volt semmi gond, tehát egyértelműen az eredeti fiókkal vagy profillal van gond.

Bár megkaptam az engedélyt a profil törlésére/újbóli létrehozására, nem hagyott nyugodni a dolog. Ha be tudok jelentkezni (tehát jó a név/jelszó páros), akkor miért dobja mégis el a kezelőfelület?

Nem mondom, hogy a neten szétnézve egyből megtaláltam a választ, viszont nem hagytam a dolgot, így kitartásomat végül siker koronázta: egyik helyen írtak egy javaslatot, amit ellenőrizve, kiderült, hogy valaki (ugye tudjuk, senki nem állított semmit, tehát a szellemek…) felvett egy rossz adatot (valahogyan, de ugye ez a szellemeknek nem okoz gondot) a „Hitelesítő adatok kezelője” (Credential Manager) tárolójába. A gondot az okozta, hogy a helyi SBS FQDN-je volt megadva, mint elérési útvonal, viszont a hitelesítő adatok nem stimmeltek – s mivel valamiért az Exchange kezelői felületei nem a bejelentkezett felhasználó adatait vették át, hanem az innen kiolvasott adatot, elhasaltak. A rossz adatot törölve természetesen máris hátradőlhettem, probléma megoldva. A szellemekkel meg majd még lesz egy beszélgetésem…

Kategóriák:Exchange Címkék: , ,

Nokia C6 certificate management

január 16, 2013 4 hozzászólás

Blogomban már szerepelt az Exchange – mobil-eszközök együttműködéséről cikk, most ezzel kapcsolatban egy „apróság” merült fel: a hálózatban lecserélésre került a Root CA. Azokon a mobil-készülékeken, ahol alapból minden tanúsítvány elfogadásra kerül, ez nem okozott gondot, viszont például egy Nokia C6-on ez már nem volt egyértelmű.

A leggyorsabb megoldás az, ha a tanúsítványt (pl. DER) formátumban felmásoljuk a készülékre, majd telepítjük. S itt jön egy lényeges rész: amikor rákérdez, hogy minek a hitelesítésére szeretnénk használni, akkor az Internet mindenképp legyen engedélyezve. Bár a neve csalóka, hiszen igaziból az Exchange tanúsítványának ellenőrzésére fogjuk használni, az Online certificate check nem kötelező, mint ahogy természetesen a VPN sem.

Amennyiben nem a fentiek alapján állítjuk be, úgy a szinkronizálás folyamatában feldobja a tanúsítvány-engedélyező ablakot, ahol látszólag van lehetőségünk csak egyszeri alkalomra, vagy véglegesen elfogadni a tanúsítványt, viszont ez utóbbi választása esetén a szinkronizáció nem valósul meg. Ekkor a Settings/Phone/Phone management/Security settings/Certificate management/Auth certificates menüt kiválasztva, azon belül a feltelepített tanúsítvány Trust settings beállításait érdemes ellenőrizni.

Kategóriák:Exchange Címkék: , ,

Exchange Send as… jog

október 26, 2012 8 hozzászólás

Exchange 2010 környezetben abban kérték a segítségem, hogy egy megfelelő jogosultságú fiókkal próbálták egy másik fióknak a „Send as…” beállításait módosítani, s az hibával elhasalt:

Error:

Active Directory operation failed on Server.Domain.hu. This error is not retriable. Additional information: Access is denied.

Active directory response: 00000005: SecErr: DSID-031521D0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

The user has insufficient access rights.

Ez annál is érdekesebb volt, ugyanis eddig az illető csont nélkül tudta kezelni a fiókokat, elvileg nem változott semmi – de attól még jogosultsági problémára hivatkozott a kezelőfelület.

Nem tudott vele mit kezdeni, így hozzám került a dolog, sőt, kapásból egy kérdés is felmerült: amikor az ESM-et (Exchange Management Shell, a PowerShell levelező kiszolgálóra „felkészített” verziója) próbálta más felhasználó nevében futtatni (vész esetére van egy másik, magas jogosultságú fiók), akkor ugyanazt a PS parancsot kiadva, az kiakadt egy hibaüzenettel:

The term ‘Add-ADPermission’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Kezdjük mindjárt ezzel. Más felhasználóval futtatva az ESM-et egy „sima” PowerShell felületet kapunk, ami nincs felkészítve az Exchange funkciók kezelésére. Bár MS nem támogatja az RBAC kikerülése miatt, de ebbe is be tudjuk tölteni a levelezőkiszolgáló funkcióit:

add-pssnapin Microsoft.Exchange.Management.PowerShell.E2010

Ezután már ugyanúgy használhatjuk az Exchange-specifikus utasításokat, más felhasználó nevében is.

Visszatérve az eredeti problémához. Ahhoz, hogy egy felhasználó az előbb említett jogot tudja módosítani, az „Organization management” csoport tagja kell legyen. De az ugye nem elég, az is szükséges, hogy a csoportnak joga legyen a célfiókhoz – s a kérdéses rendszerben itt csúszott valahol egy porszem a gépezetbe. Mint másik cikkemben is, itt is legegyszerűbben az öröklődés bekapcsolásával lehetett orvosolni a gondot…

Kategóriák:Exchange Címkék: , ,