Category: általános

SCCM konzol küzdés

Egyik kedves ügyfélnél erősen proxyzott környezet van. A SCCM-nek engedélyezték az auth nélküli proxy-t, meghatározott URL listával.

A feladat az SCCM co-management beállitása volt. Pár kattintás, Azure bejelentkezés, semmi extra. Aham…

Jól rákészültünk a proxybeállitásokra:

  • Winhttp proxyt beállitottuk (netsh winhttp show proxy szépen visszaadta)
  • SCCM site server opciónál a proxy-t belőttük
  • Az Edge böngészőben is definiáltuk a proxyszervert
  • Még a .NET frameworkbe is beillesztettük a proxy konfigot

 

Ezek után az SCCM konzol a csatlakozáskor úgy befagyott mint a szög. Pár percig nézegette a köldökét, a proxy szerver felé semmilyen forgalom nem ment, aztán feldobta a microsoft loginablakot, végigment a név/jelszó/mfa, majd nem történt semmi.

“Mindig a hálózat a hibás. Mindig.” ezt régi kollégától hallottam, szeretjük is mindenre ráhúzni, de mivel forgalom nem ment a proxy felé, nehéz volt rásütni. De négy helyen is definiálva van a proxy, miért nem talál oda?

Végül process monitorral vizsgálva előbújt, hogy a Microsoft Configuration Management.exe küzd kihivásokkal. Szerencsére neki is lehet proxyt beállitani (az ötödiket!), mégpedig a C:\Program Files (x86)\Microsoft Endpoint Manager\AdminConsole\bin folderben a Microsoft.ConfigurationManagement.exe.config fileba kell definiálni:

<system.net>
<defaultProxy useDefaultCredentials=”true” />
</system.net>

Ezek után már gond nélkül kitalált a proxyn keresztül és sikerült a co-management beállitás…

Exchange 2019 CU 14 megjelent

Megjelent az idei első Cumultative Update az Exchange Server 2019-hez: Download Cumulative Update 14 for Exchange Server 2019 (KB5035606) from Official Microsoft Download Center

A CU alapból bekapcsolja majd az Extended Protection feature-t (Windows Extended Protection <extendedProtection> | Microsoft Learn), aki ezt nem szeretné, az telepítse powershellből a CU-t a /DoNotEnableEP vagy /DoNotEnableEPFEEWS kapcsolóval.

A TLS 1.3 támogatás Windows 2022 Serveren csúszik, a CU15-be fogják (remélhetőleg) implementálni.

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ó:

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

https://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.

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

Most jön az, hogy hamut szórok a fejemre. Az előző cikk tesztjei során valamit nagyon benéztem.

Ami nem működik:

Attól, hogy egy megbízott tanúsítvánnyal aláírt oldalról érkezik a kép, az Outlook még nem fogja megjeleníteni.

Ami viszont működik:

Ha az OWA kliensen ahonnan a levelet küldjük feltelepítjük az S/MIME bővítményt, akkor az aláírásban elhelyezett kép beágyazott képként belekerül az elküldött levélbe így az Outlook meg fogja jeleníteni. A képet ehhez a mutatványhoz is egy megbízott SSL oldalon kell elhelyezni, viszont ehhez jó a saját tanúsítványunk is mert ebben a fogadó oldalnak nem kell megbíznia, a feladónak viszont, igen, hogy be tudja ágyazni a képet.

Ezzel a kérdés meg is lenne oldva, de mi történik, ha nem csak saját magunknak szórakozásból csinálunk ilyet, hanem cégesen több száz gépen kell az S/MIME-ot telepíteni?

Az S/MIME OWA kiterjesztés tulajdonképpen egy IE bővítmény, ami MSI alapú telepítővel rendelkezik. Ez az Exchange szerveren alapból a C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\smime könyvtárban owasmime.msi néven szerepel. Ezt ki tudjuk tolni Group Policy-ból az érintett kliensekre. Ezzel ugyanakkor még nem vagyunk meg, mert a bővítmény nem kerül automatikusan engedélyezésre. Ahhoz, hogy engedélyezzük a Group Policy User Configuration/Policies/Administrative Template/Windows Components/Internet Explorer/Security Features/Add-on Management alatt fel kell venni a {3050F819-98B5-11CF-BB82-00AA00BDCE0B} kulcsot, 1-es értékkel. Ez engedélyezik a bővítmény használatát.