AuthorSUF

Copy/Paste a mi barátunk

Jelenleg egy Exchange 2013 alapú hosting infrastruktúra tervezésével foglalkozom. Mint kiderült bizonyos dolgok kikerültek a grafikus management felületből a korábbiakhoz képest. Például nincs OAB reszelés a felületen. A vége az lett, hogy nagyjából mindent PowerShell-ből kell megcsinálni. Ennek kapcsán az ember olvasgatja a helpet. Részletek különböző parancsok helpjeiből:

Get-Help New-DynamicDistributionGroup -full

-RecipientContainer <OrganizationalUnitIdParameter>
The RecipientContainer parameter filters the recipients used to build the dynamic distribution group based on their location in Active Directory. The value of the RecipientContainer parameter can be the canonical name of an organizational unit (OU) or a domain. If you don’t specify a value for the RecipientContainer parameter, the cmdlet will default to use the local container. This location is specified by using the OrganizationalUnit parameter.

Get-Help New-AddressList -full

-RecipientContainer <OrganizationalUnitIdParameter>
The RecipientContainer parameter filters the recipients used to build the dynamic distribution group based on their location in Active Directory. The value of the RecipientContainer parameter can be the canonical name of an organizational unit (OU) or a domain. If you don’t specify a value for the RecipientContainer parameter, the cmdlet will default to use the local container. This location is specified by using the OrganizationalUnit parameter.

Get-Help New-GlobalAddressList -full

-RecipientContainer <OrganizationalUnitIdParameter>
The RecipientContainer parameter filters the recipients used to build the dynamic distribution group based on their location in Active Directory. The value of the RecipientContainer parameter can be the canonical name of an organizational unit (OU) or a domain. If you don’t specify a value for the RecipientContainer parameter, the cmdlet will default to use the local container. This location is specified by using the OrganizationalUnit parameter.

Tombol a copy/paste, ellenőrzés nélkül. Nyugi, ez már a 2010-ben is pontosan ugyanígy van a helpben.

Előadás

Hogy itt is népszerüsítsem.

2013.05.23.-án előadást tartok az Exchange 2013 mobil lehetőségeiről.

Itt nem kifejezetten az újdonságokról lesz szó, hanem arról, hogy összességében mobil oldalról mi hozható ki az Exchange-ből.

A konferencia címe: http://app.hwsw.hu/

Exchange 2013 Setup + EAC

Nekiálltam az Exchange 2013-ra való átállásnak.

Miután az első 2013-as szerver nem abba a site-ba kerül ahol a schema master van, így a schema master site-jában kezdek neki, parancssorból a dolognak (PrepareSchema, PrepareAD, PrepareDomain)

2012-es member gép (ez sosem lesz Exchnange szerver):

Hisztizik, hogy RSAT AD DS kellene neki. Az nincs, ezen a gépen nem is lesz. Válasszunk mást.

2008 R2 DC, minden FSMO role tulajdonosa:

Hisztizik, hogy kéne neki egy .NET 4.0 – Ez átverés, a release notes-ból kiderül, hogy tulajdonképpen 4.5 kell neki. Nem ugrom be, felrakom a 4.5-öt

Kéne még egy Management Framework 3.0. Felrakom.

Ezek után lefutnak a szükséges dologk.

Csak azt tudnám, melyik idióta gyártott ilyen KÖTELEZŐ parancssori kapcsolót: /IAcceptExchangeServerLicenseTerms

Azt hiszem, ha az open világban valaki elkövetne egy hasonlót, keresztbe nyelné le a közösség.

Aki már egy kicsit utánanézett az Exchange 2013-nak az tudja (aki nem azt majd telepítés után fogja képen vágni), hogy az MMC alapú Exchange Management Console-nak vége, meghalt, eltemették.

Ami helyette van az a web alapú Exchange Administration Center.

Hosszas várakozás (2010 SP3, 2013 CU1) és némi küzdelem (Schema Upgrade másik site-on, millió tonna Windows Server Role, Feature, külön letöltendő telepíőkészlet, hatszáz újraindítás) árán sikerült a saját Exchange 2010-es infrastruktúrámba (homokozó) felraknom az első Exchange 2013-at.

A telepítő gyorsan meg is kérdezte, hogy akarom-e elindítani az Administrative Centert.

Akartam. Beléptem. Magyar.

Hogy az a…

Utálok magyarul szervert adminisztrálni.

Miért?

Nem, nem beszélek jobban angolul mint magyarul. Nem, nem felvágós úri hóbort. Hanem:

Ha valami bajom van, a magyar hibaüzenetekre, problémákra kb. 0 megoldást találok a neten.

Ok. Állítsuk át angolra:

Első ötlet: Átállítom az Internet Explorert angolra. Ez magyar, mert az operációs rendszer nyelve ugyan angol, viszont a területi beállítások magyarok, elsősorban a billentyűzet miatt. (Ez az átállítás sem egy matyóhímzés mióta az IE nyelvi beállításait integrálták a control panellel: Win8/IE10)

Kilépek az EAC-ból, becsukom az IE-t.

Megpróbálom elindítani az EAC-ot újra. Csempét nem gyártottak hozzá a start menűbe. Az IE history-ban sincs (vajon miért?). Google.

Kiderül, hogy a cím megyegyezik a 2010 ECP-vel. (https://server/ecp)

Bepötyögöm, belépek, kapok egy 2010-es OWA login ablakot. Mi vaaan?

Megpróbálom a gép összes lehetséges címével (loclhost, FQDN, IP). Mindre ugyanazt kapom vissza.

Google.

Kiderül, hogy abban az esetben, ha a mailbox még a 2010-es szerveren van akkor belépés után átirányít. Ez kikerülhető, ha így: https://server/ecp?ExchClientVer=15 adjuk meg a címet.

Sikerül. Belépek. Magyar.

Gondolkoz. Nézzük meg a postaláda nyelvét.

Belépek a 2010-es OWA-ba, kiderül, hogy magyar. Ok. Átállítom angolra.

IE becsuk, újra kinyit, EAC-ba belép. Magyar.

Get-MailboxRegionalSettings: látszik, hogy angol.

Vajon ez a beállítás honnan jön? AD.

Hopp. Nem azon a site-on van a 2013 mint a felhasználói postaláda 2010-e.

Get-MailboxRegionalSettings -DomainController <Exchange 2013 site DC>

Itt is angol.

Mi van, ha már lefutott a replikáció.

IE kilép, IE belép, EAC: Angol. – véééégre.

Exchange 2013 CU1 2.

No akkor. Megjelent. kb. fél órája, most töltöm lefelé.

Exchange 2013 CU1

Az Exchange Team Blogon jártam. Megláttam a rég várva várt címet Exchange 2013 RTM CU1 … Status.

A “Status” szó így hirtelen nem tett gyanakvóvá. Pedig kellett volna.

Szóval az ígéretekkel ellentétben a fenti update nem jelenik meg az első negyedévben. Tehát még nem tudok a meglévő 2010-es infrastruktúrámba 2013-at telepíteni.

A cél azért nincs messze. Ha igaz amit ígérnek, jövő hét kedden a kezünkbe kerül az új játék. 🙂

Az eltűnt e-mail esete

Tegnapelőtt este egy weboldal nem engedett be. Megpróbáltam resetelni a jelszavam. A folyamat:

Küldenek egy e-mail-t, amiben van egy link, erre kattintva kapok egy másik levelet, benne az egyszerhasználatos jelszavammal. Szokásos eljárás.

Megjött az első levél, rákattintok a linkre, közli, hogy küldi a jelszavam.

Második e-mail sehol. Várok… várok… még mindig várok. Nem jön.

A dolog nem volt se fontos, se sürgős, így napirendre tértem a téma felett.

Másnap reggel a telefonomon nézem az adott postaládát, a levél ott van. A megfelelő időben, előző este érkezett.

Leültem az irodai gépem Outlookja elé. A levelet ott sem látom. Akkor nézzük meg OWA-ban. Bejelentkezek a saját nevemben, majd megpróbálok átlépni abba a postaládába, ahova a levél érkezett (ez nem az elsődleges fiókom, hanem a freemail fiókom “exchange-esített” változata). Nem sikerül, az OWA dob egy ronda hibát valami null property-re.

Keresgélek a neten és ezt találom:

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

Remek, ezek szerint akkor tudom megnyitni a másik mailboxom ilyen módon az OWA-ban, ha a freemail.hu-t felveszem az accepted domain listára. Ehhez valahogy nincs kedvem.

Belépek a postaládába az eredeti felhasználója nevében.

A keresett levél ott van… és … azt állítja magáról, hogy private. Ok. Ez teljesen érthető. A private jelzéssel rendelkező leveleket a Full Access joggal rendelkező másik felhasználó nem láthatja.

Ez így nekem nem jó.

Tehát a megoldás:

– csinálok egy terjesztési csoportot

– belerakom az összes érintett másodlagos postaládát

– csinálok egy Transport Rule-t amely az összes a terjesztési csoport tagjainak menő levélről leszedi a Sensitivity fejlécet, ha abban private/personal/confidental van.

Teszt kívülről. Működik.

Disable-ExchangeCertificate

Ne is keressük a címben szereplő EMS cmdletet. Nincs ilyen. A párja az Enable-ExchangeCertificate természetesen létezik. Van még olyan, hogy Remove-ExchangeCertificate, de az nem ugyanaz.

Miről is van szó?

Egy kissé is tapasztalt Exchange rendszergazda tudja, hogy az Enable-ExchangeCertificate parancsal lehet, a certificate store-ban tárolt tanúsítványokat az Exchange különböző szolgáltatásaihoz rendelni.

Néhány héttel ezelőtt az egyik ügyfelünknél azt a feladatot kaptam, hogy rakjam rendbe a tanúsítványokat. Ez abból állt volna, hogy a régi, már nem használt tanúsítványokat leszedjük a szolgáltatásokról, majd a tesztidőszakot követően eltávolítjuk a store-ból.

Először elkezdtem keresni, hogy milyen parancsal lehet ezt megtenni. Sokat keresgéltem, de csak azt találtam, hogy a tanúsítványt el tudom távolítani a store-ból, de a szolgáltatást nem tudom leszedni róla.

Az ügyfélnél ez egy alacsony prioritású feladat volt, így  a dolgot végül is ennyiben hagytuk.

Tegnap a nagy álljunk vissza androidra című felbuzdulásom kapcsán nekiálltam, hogy rendbetegyem a saját Exchange-emen az IMAP tanúsítványát. A problémáról itt írtam: http://it-pro-hu.blogspot.hu/2013/02/mi-bajom-az-androiddal.html A feladat a következő:

Az IMAP-nak a már jó ideje megvett, de be nem üzemelt Netlockos tanúsítványt kell használnia, az IISnek ugyanakkor a saját CA által kiállítottat mert nem akartam most szétszedni az egyész SAN-os/Autodiscover-es miskulanciát.

Megpróbáltam az IMAP-ról leszedni a régi tanúsítványt és természetesen újra a néhány héttel ezelőtti problémába futottam. Itt és most viszont nem akartam feladni. Arra gondoltam, hogy az Exchange azt az információt, hogy melyik tanúsítvány van hozzárendelve egy adott szolgáltatáshoz, biztosan tárolja valahol. Az Exchange tudtommal a különböző konfigurációs beállításokat alapvetően két helyen tárolja: az Active Directory-ban és különböző XML konfigurációs fájlokban:

– ADSIEdit -> configuration namespace -> semmi

– LDIFDE -> configuration namespace export -> az export fájlban keresgélve -> semmi

– Előkerestem az IMAP és POP3 szolgáltatás .Net Assembly-jét -> .config fájl -> semmi

– IIS Metabase -> semmi

Kezd a dolog kifogni rajtam. Felhívtam Józsit, hátha van valami ötlete. Sajnos nem volt.

Tovább keresgélve ráakadtam erre a cikkre:

http://www.msexchange.org/articles-tutorials/exchange-server-2007/management-administration/managing-exchange-certificates-part3.html

Itt ezen megakadt a szemem:

By running the cmdlet, Enable-ExchangeCertificate, you will enable a certificate for one or more services by updating the metadata stored with the certificate.

Every service has different metadata requirements, and will have different properties updated:

  • POP3-IMAP4: msExchPopImapX509CertificateName property will be updated;
  • IIS: Default Web Site will be updated;
  • SMTP: the Network Service account will be granted Read access to the appropriate private file key in the directory Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys;
  • UM: certificate property will be updated to include Unified Messaging.

Hoppá, ezek szerint nem reszelgetünk konfigurációs információkat, hanem a névegyezőségből és a tanúsítvány jogokból adódik, hogy mi látszik a Get-ExchangeCertificate parancs kimenetében.

Ellenőrzésképpen tettem is egy gyors próbát.

Az alapállapot az volt, hogy mind a saját CA-m által kiállított tanúsítvány, mind a NetLock-os hozzá volt rendelve az IMAP szolgáltatáshoz.

Az IMAP szolgáltatáson elrontottam a site nevét.

Láss csodát: Mindkét tanúsítványról eltűnt az IMAP flag. Ezek után persze kérdés, hogy a rendszer mi alapján dönt, ha több lehetséges tanúsítvány van.

A másik része a dolognak az All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys könyvtár tartalma. Itt találhatóak a Local System tanúsítványai. Sajnos a fájlnevek köszönő viszonyban sincsenek a tanúsitvány thumbprintjével, firendly nevével, vagy CN-jével, vagy akár bármi értelmezhető paraméterével. Az itt található tanúsítványok közül az használható SMTP hitelesítésre amilyikre a Network Service usernek olvasási joga van (az az érzésem, hogy ez az olvasási jog ugyanúgy szükséges a POP3-hoz és az IMAP-hoz is de ezt még nem tudtam tesztelni, ha ez igaz és szükséges a tanúsítványok szétválasztása, akkor érdemes elgondolkozni, hogy a Network Service helyett egyedi service accountokat használjuk a szolgáltatásokhoz).

Ha itt állítani akarunk valamit akkor merül fel a kérdés, hogy a fájlok közül vajon melyiket kell piszkálnunk, amikor mi csak a tanúsítvány thumbprintjét ismerjük (jó lenne ezeket a jogokat a certificate mmc-ben állítani, de ott sajnos erre nincs lehetőség).

Vajon hogyan tudjuk a thumbprintet összerendelni a fájlokkal? Újabb keresgélés a neten. A megoldás innen adódik:

http://jorgequestforknowledge.wordpress.com/2012/02/10/managing-certificates-on-a-windows-computer-with-powershell/

Az itt található scripteket kicsit átpofozva írtam egy scriptet ami a thumbprint alapján megadja a fájl nevét és a jogosultságait:

param([string]$ThumbPrint)
$Cert = dir cert:\LocalMachine\My | where {$_.ThumbPrint -eq $ThumbPrint}
$MachineKeysLocation = $env:ALLUSERSPROFILE + “\Microsoft\Crypto\RSA\MachineKeys\”
$KeyFileName = $Cert.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName
$KeyFilePath = $MachineKeysLocation + $KeyFileName
Write-Host FriendlyName: $Cert.FriendlyName
Write-Host Subject: $Cert.Subject
Get-Acl $KeyFilePath | fl

EmployeeID vagy EmployeeNumber? Szerinted mindegy?

A válasz: NEM. Ha igen lenne, talán létre se jött volna ez a cikk.

De kezdjük az elején.

Kb. másfél éve építettünk egy elég nagy rendszert (AD/Exchange). Az ügyfél azzal az igénnyel állt elő, hogy az Active Directory-ba későbbi felhasználásra kerüljön bele a HR rendszerben használt egyedi azonosító.

Körülnéztem, hogy mit lehetne erre használni, és arra jutottam, hogy van két attribútum: Az EmployeeID és az EmployeeNumber. Nagyjából pénzfeldobással az elsőre esett a választás.

Az AD feltöltése kapcsán némi PowerShell scriptel ez kitöltésre is került.

Azt nem tudom, hogy az elmúlt időben használták-e ezt valamire, de két napja előjött az igény, hogy az EmployeeID jelenjen meg az Outlookban, a címlistában (GAL/OAB).

Az ügyfél azt is kibogarászta, hogy az Exchange-ben van egy Details Template Editor, amivel a kliens oldalon pl. a GAL-ban tárolt felhasználók tulajdonságlapjának megjelenését lehet beállítani (ez számomra újdonság volt, de mindig tanul az ember). A probléma csak az, hogy itt a választható attributumok között nem találta meg az EmployeeID-t.

Keresgélve ezt találtam:

http://blogs.technet.com/b/exchange/archive/2010/03/10/3409495.aspx

Ebből az derül ki (amit alapból is sejtettem), hogy egy AD attribútum, akkor jelenhet meg a GAL-ban, ha benne van a GC-ben. Tehát fogtam magam és bekapcsoltam, hogy az EmployeeID megjelenjen a GC-ben.

Három órával később az ügyfél jelentkezett, hogy a Details Template Editorban még mindig nem látja az EmployeeID-t.

Ma reggel ránéztem, és tényleg nincs ott. Újabb google. Az eredmény:

http://exchangepedia.com/2008/06/modifying-display-templates-and-additional-attributes.html

http://mostlyexchange.blogspot.hu/2005/03/adding-attributes-to-exchange-details.html

Tehát rövden:

Csak olyan AD attribútum jelenhet meg a Details Template-ben aminek van mAPIID-ja. Az EmployeeID-nak nincs, az EmployeeNumber-nek meg van. Remek.

Két megoldás kínálkozik. Vagy átpakoljuk az összes EmployeeID-t az EmployeeNumber-be, vagy az EmployeeID-nak csinálunk mAPIID-t.

Az első egy rövid PowerShell script, a második pedig egy kőkemény hegesztés, ami ráadásul nem is támogatott…

Hyper-V 2012 + Storage Sapces 2.

Elkezdtem az első 2012-es vizsgámra tanulni. Eközben bele-bele nézegetek a jelenlegi infrastruktúrám beállításaiba.

Pár napja eszrevettem, hogy a feltelepített Storage Spaces köteteimen nincs bekapcsolva a Deduplication. Akkor úgy voltam vele, hogy majd utánanézek később, mert most még nem sürgős.

Ma a nézelődés kapcsán képenvágott a szomorú valóság:

Miután a Host (ami az ingyenes Hyper-V Server 2012) elkobozta a Storage Poolt a guest-től (ami egy Windows Server 2012 Standard), nem is lesz dedupom (legalábbis nem mindenütt). Miért? Mert a Hyper-V Serverből hiányzik ez a Role Service.

Exchange 2010 SP3 – Végre

Tegnapi napon megjelent az Exchange 2010 SP3. !!!VÉGRE!!!

Ez talán a leginkább várt frissítése az Exchange-nek. A legfontosabb dologok amket tartalmaz:

– Az első Exchange 2010 kiadás ami telepíthető Windows 2012-re

– A minimális SP szint az Exchnage 2013 együttéléshez (ez sajnos még nem az igazi, mert Exchange 2013 oldalon kell hozzá egy CU1 jelű frissítés ami még nincs kész)

– Internet Explorer 10 támogatás

Forrás: http://blogs.technet.com/b/exchange/archive/2013/02/12/released-exchange-server-2010-sp3.aspx

Hyper-V 2012 + Storage Sapces

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á.

targetAddress avagy spóroljunk a licenszeken

Most következik az az eset, amikor bebizonyítom, hogy nem értek az Exchange-hez.

Mit csinálunk olyankor, amikor van egy email címünk, amiért a saját Exchange szervezetünk a felelős, de az ide érkező leveleket tovább kell küldenünk egy külső címre, és saját rendszerünkön soha egy darab levelet sem kell tárolnunk, ami a megadott címre érkezik?

Én (és az a gyanúm, hogy ezzel nem vagyok egyedül) a következőt tettem a fenti esetben. Létrehoztam a saját címünkhöz egy postaládát, a külső címhez egy kontaktot és a postaládát ráirányítottam a kontaktra. Megbékéltem azzal, hogy ez ronda, sőt minden egyes ilyen akció visz magával egy nem is túl olcsó CAL-t.

Mostanában a több ügyfélnél az Exchange 2003 – Exchange 2010 Cross-Forest migrációval birkózom (ez egyszer még megér egy másik cikket). Ennek kapcsán meglepetten tapasztaltam, hogy a migráció végén a rendszer egy olyan Mail Enabled User-t (ez ugye Exchange szempontból egy kontakt, és mint ilyen nincs postaládája) hagy maga után. Ami viszont képes leveleket továbbítani pontosan úgy, ahogy a fenti kérdésben szerepel.

Némi nyomozás után kiderült, hogy a tettes a targetAddress nevű AD property. Tehát minden levél, ami a kontakt egyik proxyaddress-ére érkezik azt a rendszer tovább küldi a targetAddress property-ben szereplő címre. Ráadásul a rendszer azt a kedvességet is megteszi (mind Exchange 2003 mind 2010 esetén), hogy a targetAddress property-t eleve kitölti a kontakt email címére.

Ebből adódóan az eredeti kérdésre adott válasz így változik:

Felveszünk egy kontaktot a külső címmel, majd a kontakt proxyAddresses listájába felvesszük az átirányítani kívánt saját címet.

Kész vagyunk. Mínusz egy CAL.

AntiSpam Update

Van egy dolog, ami már jó ideje bosszant.

Az Exchange 2007/2010 lehetőséget biztosít arra, hogy a Hub Transport szerveren feltelepísük a Microsoft AntiSpam agent-jeit. Ezzel kapunk egy jól működő, nagy tudású spam szűrő infrastruktúrát.

Ez ugyan nem annyira hatékony, mint a ForeFront for Exchange, továbbá nincs benne vírusirtó, viszont ingyen van.

Amikor ez a lehetőség először megjelent az Exchange 2007-ben, akkor lehetőségünk volt arra, hogy a hozzá tartozó definíciós fájlokat automatikusan frissítsük (Ez a ForeFront nélkül 3 hetente történt). Ez a lehetőség egy adott ponton megszűnt. Pontosabban, ha nincs ForeFrontunk akkor az Exchange maga nem frissít, hanem ezt a Windows Update teszi meg helyette.

Ezzel viszont gond van. Én magam részéről szerveren sosem kapcsolom be a frissítések automatikus telepítését (csak az automatikus letöltést), mert a folyamatos üzem miatt az nem elfogadható, hogy a szerver újrainduljon, amikor az update-nek ehhez van kedve, ráadásul bizonyos környezetekben a biztonsági frissítések csak tesztelés után kerülhetnek az éles rendszerbe. Ebből adódóan nem csak a biztonsági frissítések, hanem az AntiSpam definició sem települ automatikusan, aminek pedig kellene.

A fenti állapotot kezelendő írtam egy kis javascriptet ami feltelepíti az AntiSpam definíciós fájlt. És csak azt. Ha ezt a kis scriptet (cscript.exe SpamUpdate.js) berakjuk a Task Scheduler-be akkor a fenti problémát megoldottuk.

A script innen tölthető le.

Exchange 2013 – mégegyszer

A múlt heti hír folytatásaként, akit ez érint, annak leírom. A vártnál kb. három héttel korábban Október 24-től az MSDN és a Technet előfizetőknek letölthető az Exchange 2013 (továbbá a Lync 2013, az Office 2013 és a SharePoint 2013) .

Forrás: http://www.howexchangeworks.com/2012/10/exchange-lync-2013-rtm-bits-in-technet-msdn.html

Exchange 2013

Biztos már mindenki tud róla, de kiteszem ide is. Elkészült a végleges Exchange 2013.

További infó itt: http://blogs.technet.com/b/exchange/archive/2012/10/11/the-new-exchange-reaches-rtm.aspx

P.S. Már nagyon unom ezt. Harmadszor írom le a fenti szöveget. Először a gépem szállt el kékhalállat, másodszor pedig az IE-t nem szerette a WordPress.

IE9 + Windows Update

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.

Exchange 2010 SP2

Ma az egyik kollégámmal egy rendszer átállásáról beszélgettünk. Felmerült lehetőségként, hogy mi lenne, ha építenénk egy Exchange 2010 hosting környezetet amibe nem csak az ügyfél adatai kerülnének, hanem a sajátjaink is. Természetesen felmerült az alap kérdés: GAL separation. Innen jött a kérdés: Mikor lesz SP2 ami ezt már tudja.

Rákerestem.

Van.

Tegnap óta:

http://blogs.technet.com/b/exchange/archive/2011/12/05/released-exchange-server-2010-sp2.aspx

Letölthető innen:

http://www.microsoft.com/download/en/details.aspx?id=28190

Hotfix

Néhány hete, hogy tanuljak összeraktam egy Exchange 2010 DAG-ot több telephely között kábelnet vonalakon VPN-eken keresztül. Ez ugye hálózatilag nem a stabilitás magasiskolája.

Egyszer lett egy rövid kiesésem (egy-két perc). Erre fogta magát a DAG és szétesett. Nem ált helyre magátol, gyakorlatilag a Windows Cluster eszközeivel kellett szétszednem mert semmire sem reagált. Végülis újra össszeraktam és napirendre tértem a dolog felett.

Tegnapelőtt ráakadtam erre a cikkre. Végiggondolva az előző eset kísértetiesen hasonlított a cikkben leírtakra. Nosza rajta, szerezzük be a hotfixet, elvégre a fenti teszt DAG-om még létezik (azóta szerencsére nem volt vele újabb gond) valamint vár rám vagy három újabb DAG, csak azok már élesben.

Emlékeztem, hogy a Microsoftnak van egy webes formja ahol lehet hotfixet kérni. Meg is találtam itt.

Elküldtem az igénylést, erre ez a válasz jött tegnap:

Hello,

Thank you for contacting Microsoft Customer Service.

From the information you have provided in your message, I understand that you are located in Hungary. The Customer Service team you have reached is for North America. There are significant differences between North American versions of Microsoft products and those localized for your country.

You will be best assisted by the Microsoft subsidiary that specializes in your version of Microsoft products. You can reach them at +36 1 437 2800 or by visiting: http://www.microsoft.com/worldwide/phone/contact.aspx?country=Hungary

I hope the above information is useful. In case you require further assistance with regards to this issue, please feel free to contact us.

Thank you,

John

Microsoft Customer Service Representative

Na gratulálok. Hotfix nincs, ráadásul bődületes baromság, hogy különbség lenne a verziók között, ugyanis én a US English verzióhoz kértem fixet és nem a magyarhoz.

Azt találtam ki, hogy csinálok egy új e-mailt és bejelentkezem amerikaiként a formra. Meg is tettem. Amikor újra rákerestem a form címére (tegnap nem tettem el), megakadt a szemem az egyik találaton.

Egy próbát megér alapon össze is raktam az urlt: http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=2550886&kbln=en-us

Láss csodát, kaptam egy magyar nyelvű oldalt és 5 perc múlva a kezemben volt a hotfix, ahelyett hogy egy fél napot vártam volna az elutasításra.

Exchange javítások

Két új hotfix jelent meg.

Az egyik az Exchange 2010 SP1 soron következő immár 6-os rollupja. Letölthető innen, további infók róla itt.

A másik egy igen bosszantó, ugyanakkor nem életbevágóan fontos hibát hivatott orvosolni. Ha az Exchange Management Console-t futtató gépen fenn van az IE9 és a Mailbox szerepkör tualjdonságait piszkáljuk akkor nem lehet becsukni a konzolt. Ezt az üzenetet kapjuk és csak a Task Managerből lehet kilőni az MMC-t: “You must close all dialog boxes before you can close Exchange Manaagement Console.”

Bővebben itt.

Exchange 2010 OWA – Kép az aláírásban 3.

Milyen nehéz is elérni valamit amit a Microsoft nem tervezett bele eredetileg a termékbe. Már két körben írtam a témáról, hogyan helyezzünk el képet az OWA aláírásban. Ez a történet harmadik, de már most biztosan nem utolsó része.

Az előző kettő itt található:

http://www.emaildetektiv.hu/2011/08/18/exchange-2010-owa-signature-image/

http://www.emaildetektiv.hu/2011/10/03/exchange-2010-owa-signature-image-2/

A cikk második részének megírása után, a szükséges elemeket felraktam az ügyfél rendszerébe, majd nyugodtan hátradőltem, hogy nincs több dolgom a témában, csak teríteni az aláírásokat, amint az ügyfél emberei kitöltik a megfelelő adatokat az AD-ban.

Néhány nap múlva kaptam néhány teszt felhasználót, akiknél megvoltak az adatok, legeneráltam az aláírásokat képpel együtt, felhasználók tesztelnek, …

puff nagy pofon, nem működik.

Én tesztelek náluk az ő gépükön vnc-vel. Nekem megy.

Pár nap közdés után valaki rájött (ez nem én voltam), hogy ha új levelet küldök akkor jó, ha egy beérkező levélre válaszolok, akkor már az OWA-ban is egy nagy büdös piros x van a kép helyett. Tesztelés, ez bizony egy bug a rendszerben.

Két dolgot tehetünk:

1. Lejelentjük az MS-nek a hibát és reménykedünk, hogy megoldják.

2. Keresek valami megkerülő megoldást.

Hétfő (2011/10/17):

Mindkettőnek nekiugrottunk. A kollégák lejelentették az MS,nek én pedig elkezdtem Transport Agentet írni.

Estére el is készült az Agent váza, de még nem volt az igazi. Kollégám megfogalmazása erre a teszt levélre:

“az jó. csak mert abban igaz, hogy nem jön meg, de legalább a charcode is szar”

Hazamentem, este lett egy újabb öttletem, de az már nem fért bele a napba.

Kedd (2011/10/18):

Hajnalban nekiláttam, megcsináltam az Agentet, hibátlanul működött a teszt környezetben.

Lejelentettem, hogy jó, kértem a telepítéshez időpontot (Nem mennek a dolgok hű bele balázs módra, mert, ha minimális esélye van némi szolgáltatáskiesésnek, akkor arról mindenkinek tudnia kell. Itt volt ilyen, mert bizonyos struktúraválltás miatt az OWA tanúsítványát is cserélni kellet, ami az SSL Host header miatt okoz egy-két perc fennakadást)

Kaptam időt estére/másnap hajnalra.

Szerda (2011/10/19):

Hajnalban felraktam mindent.

Reggel ügyfél tesztel,…

Eredmény: szar.

Egész nap más dolgom volt, nem tudtam vele foglalkozni.

Este indolklás nélkül jön egy kérés, hogy kapcsoljam ki az OWA-ban a html link szűrést. Nem tudtam vele foglalkozni, majd holnap.

Csütörtök (2011/10/20):

Hajnalban elkezdtem tesztelni, hogy tegnap miért nem megy. Ki is derült, hogy a disclaimer a ludas (mert kérem itt aláírás is van, meg jogi nyilatkozat is). Ugyanis amikor beteszi a levél végére a szöveget akkor kiszedte az általam az aláírás html img tag-jébe becsempészett role=”contetntinfo:embed” attributumot (pedig szerintem ez szabványos, a W3C-től szedtem, modjuk a tag lezáró /> jelből is kiszedte a pert ami pedig az xhtml-ben már kötelező). Tehát a probléma orvosolható, ha az én Agent-em magasabb prioritást kap mint a Transport Rule Agent.

Valahol a tesztelgetés közepén beállítottam a tegnapi kérést. Engedélyeztem a HTML linkeket. Ettől meggyógult az eredeti probléma.

Mi van?????

Valaki akkora ész volt, hogy rájött, a piros x-es gondot az OWA “Web Beacon and HTML Filter” nevű szűrője okozza. Mekkora ász!

Reggel vissza is kérdeztem a kollágától:

– Erre ki jött rá?
– tesztelték.
SAP levélben linkek, nem tudták megbökni
– de arra, hogy ez megoldja az aláírásban kép balhét?
– arra senki.

Most őszintén. Ennek mekkora az esélye?

Agent kukába, a megoldás:

Get-OWAVirtualDirectory | Set-OWAVirtualDirectory -FilterWebBeaconsAndHtmlForms DisableFilter

Ugyan ez csökkenti a rendszer biztonságát, de valamit valamiért.

folyt. köv.