MVP Reconnect ajándék

Az MVP Reconnect ajándékom megérkezett a Microsoft-tól:

Microsoft MVP Reconnect

Azt mondják, hogy más kárából tanul az okos. Én ebben nem hiszek. Azt gondolom, hogy az okos legalább a saját kárából tanul.
Azt gondolom ez történt a Microsoft-tal.
Egy jó pár évvel ezelőtt az akkori informatikai rendszerünk elérte azt a bonyolultságot, hogy a felmerülő problémákat, már nem lehetett minden esetben saját kútfőből megoldani. Az akkor éledező internet (itt most tartalom és nem technológia szempontjából jelzem, hogy éledező) sem volt képes mindenre választ adni. Ez volt a motivációm, hogy csatlakozzak az akkori még elég kezdetleges magyar technet levelezőlistához.
Viszonylag hamar kiderült számomra, hogy kevés kérdésemre kapok választ, annál inkább segíteni tudok másoknak. Ez elsősorban a levelezés (Exchange) témáját érintette.
Ennek következtében egy ponton bekerültem az MVP programba.
Ez működött is három évig. Közben az MVP-kre egyre nagyobb nyomás nehezedett, hogy ne csak a levelező listán/fórumon álljanak helyt, hanem oktatóanyagokat írjanak, blogoljanak, előadjanak, stb.
Ezen túl nekem személyesen is sokban változott az életem, mind munkában, mind családilag.
Sajnos ezidőben a Microsoftnál is változott az MVP program. A korábbi, helyi MVP Lead-et, aki pontosan tisztában volt azza, hogy mi történt és az emberek mennyi munkát raktak a programba, lecserélték egy regionális aktakukacra, akit kizárólag a számok érdekelték. Hány blog postot írtál, hány előadást tartottál, stb.
Ennek eredményeként a korábbi lead ígéretével ellentétben, aktakukacunk kirakott a programból.
A hiba alapvetően itt volt. Ennek arra kellett volna sarkalnia, hogy pedálozzam magam vissza. Helyette bennem inkább a sértődöttség/teszek rá érzés munkállt.
Ezzel el is távolodtam a programtól, pedig pont az ezt követő időszakban lettek olyan munkatapasztalataim, melyeket a közösség javára tudtam volna fordítani.
Azt gondolom, hogy az én történetem nem egyedi. A sokan hasonlóan távozhattak. Ez a Microsoftnak egyértelműen hozzáértő emberek elvesztését jelentette. Úgy tűnik ebből tanultak.
Létrehozták az MVP Reconnectet.
Jelentkeztem.
A jelentkezésemet elfogadták, így mától MVP Reconnect member lettem.

Amikor a fagyi visszanyal

Nem tudom, hogy ennek az elejét megírtam-e már, de most nem találom.

Úgy egy éve történt, hogy a cégünk vezetése megbízott azzal, hogy oldjam meg egyetlen publikusan elérhető szoftverünk internetes letölthetőségét (a technológiánk demója).
Azt gondolhatnánk, ez egy egyszerű feladat. Kirakod a webre oszt jóvan.
Hát nem. A probléma ott kezdődik, hogy van egy óriás vállalat a világon - Microsoft-nak hívják - aki a biztonságra hivatkozva, nagy ívben tesz rá, hogy más is fejleszt szoftvert nem csak a hozzá hasonló méretű mamutok.
Miről is beszélek. A SmartScreen-ről. Ez az a cucc ami hisztizik, ha letöltesz valamit a netről, hogy ez nem szokásosan letöltött cucc és eztért veszélyes. Tévedések elkerülése végett. Az IE által a háttérben visszaküldött hash-ek darabszámán kívül semmit sem figyel (ja még a logo approved miskulanciát igen, de erről picit később).
Keresgéltem a neten adtak mindenféle ötletet, a következőket próbáltam:
- Az MS által elfogadott publikus CA (GoDaddy) tanusítványával titkosított oldalra raktam ki
- Vettem egy valag pénzért code signing tanusítványt (Commodo) és azzal írtam alá a kódot
Nem nyert.
Tovább olvasva, az derült ki, hogy az egyetlen lehetőség a kódot validáltatni az MS-el. Ez biztosan működne is ha:
- Lenne még vagy n fejlesztőnk aki csak a validációs procedúrával foglalkozna
- A kód nem használna egy rakás 3rd party cuccot, amit fix nem tudok validáltatni, mert ugye itt már nem csak arról van szó, hogy amit teríteni próbálok, az nem trójai, nem vírus, nem okoz kárt, hanem arról is, hogy a szoftverminőseg megfelel-e az előírásaiknak.
Na szóval, letettünk arról, hogy ezt a problémát megoldjuk és elkönyveltük, hogy ez a nagyok játéka (abba sajnos nem mentek bele az urak, hogy szimuláljak jópár ezer letöltést script-ből, mintha az IE lett volna).

Ma reggel meguntam, hogy a Skype (azt ugye tudjuk, hogy Microsoft tulajdon) nem jelöli olvasottnak az üzeneteimet, meg időnként összekeveri az üzenetek sorrendjét. El kezdtem keresgélni, és kiderült, hogy az alig egy hetes kiadás javítja:
http://community.skype.com/t5/Windows-desktop-client/Skype-Chat-Messages-are-in-the-wrong-place/m-p/4259230#M398647
Miután ez még automatikusan nem került kiküldésre, és kevesen tudnak róla, így kevesen is töltötték eddig le:

És a fagyi visszanyalt.
Ugye ez azt jelenti, hogy a Skype nem biztonságos, tele van ADware-el és kémkedik utánunk?

Outlook 2016 - Nem feature, bug

Ma jött egy frissítés az Office 2016-hoz.

Örömmel jelentem, hogy az Exchange 2010-es fiókom elkezdett működni. Tehát ez nem a feature, hanem a bug kategóriában indul.

Microsoft - Amikor megint "gondolkodtak"

No comment.

Microsoft - Örjöngök

Az teljesen normális, hogy a tetves O365-ben 13-án leadott hibajegyre a mai napig annyi sem jött, hogy fapapucs?

Windows 8.1 vs Microchip CDC

ENGLISH VERSION

És a nyertes...

Én. :-)

Miután sikerült felélesztenem az FRDM-KE06Z boardot, elkezdtem küzdeni a robottal.

Mintegy három nap szenvedéssel keresztülrágtam magam a Freescale nem túl értelmes driver tömegén, a CodeWarriorba rosszul települő mintaprogramon, és a saját mellényúlásaimon.

Eljutottam oda, hogy a motor vezérlés megy PWM-mel.

El kezdtem gondolkozni, mi legyen a folytatás. Az egyik lehetőség, hogy felteszem a még hiányzó optikai érzékelőt és megcsinálom a klasszikus "kövesd a vonalat" robotot - ehhez valahogy most nincs túl sok kedvem, bár biztos, hogy fel fogom szerelni az érzékelőt.

Ezen kívül még számtalan ötlet jutott eszembe, de van egy dolog ami piszkálja a fantáziámat. Ennek a freedom boardnak van infravörös adó-vevő része. Ezt két dologra tudnám használni. Közelítésérzékelőnek, vagy távirányító infra vevőnek.

Végülis arra jutottam, hogy ez utóbbinak állok neki.

Ahhoz, hogy valami fogalmam legyen a megírandó kódról előkapartam két eszközt a fiókból:

Egy a DealeXtrame-ről származó mini távirányító (ez lesz a robot távirányítója)

Egy dangerousprototypes féle IR Toy (ezzel akarom megnézni a frekvenciákat, kódokat, jelformákat)

Fogtam az IR Toy-t feldugtam a gépemre és...

Na szóval a cik itt kezdődik.

Az IR Toy-t nem ismerte fel a gép.

Nyomoztam. A drivere a firmware upgrade package-ben van benne. Letöltöttem.

Közölte, hogy ehhez az OS-hez nincs aláírva és nem rakta fel.

Valahonnan emlékeztem rá, hogy van valami USB telepítő az ilyen típusú eszközökhöz. Megkerestem, letöltöttem. Zadig WinUSB fedőnevű szerkezetről van szó. Fel is raktam vele az IR Toy-t. Minden szép, csak épp soros portom nem lett tőle.

Vissza a gyökerekhez. El kezdtem keresgélni, hogyan lehetne Windows 8.1-hez is jó cat fájlt gyártani a meglévő inf-hez. Elvégre a driver működése (usbser.sys) nem kérdéses, hiszen az az operációs rendszer része, csak kell egy olyan inf ami a Vendor/Product ID-t hozzárendeli ehhez a driverhez.

Rá is találtam az inf2cat.exe címü eszközre. Ez a Windows WDK része.

Feltelepítettem egy 8-as WDK-t és hozzá egy 8.1-es update-et.

Inf2cat lefuttat:
"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\Inf2Cat.exe" /drv:<inf path> /os:7_X86,7_X64,8_X86,8_X64,6_3_X86,6_3_X64
Nem fut le.

A mérleg: 1 error, 2 warrning

Error: a fájlban megadott driver dátum túl régi az új operációs rendszerekhez

Warrning: a hivatkozott driver fájl nincs rajta a forráslistán.

A dátumot (és a verziót) átírtam, a warrningok meg természetesek, hiszen rendszer driverről van szó.

Inf2cat mégegyszer. Lefut, megkapom a cat fájlt.

Driver telepít. Valami ismeretlen hibát dob.

Nyomozás tovább. Kiderül, hogy az alap ok a Windows 8/8.1 driver policy, ami nem engedi meg az aláíratlan meghajtókat. Itt volt számomra a félreértés. Nem csak a bináris drivernek, hanem az inf fájlnak is kell az aláírás.

Két lehetőségem maradt:

• Kikapcsolni a driver policy-t a telepítés idejére
• Aláírni a drivert ( pontosaban a cat fájlt)

Válasszuk a nehezebbet.

Ez alapján a leírás alapján indultam, de messze leegyszerüsítettem azt:
http://technet.microsoft.com/en-us/library/dd919238(v=WS.10).aspx

Van saját enterprise root ca-m, így a thrusted root dolgokkal nem kell foglakoznom.

Először is kell egy Code Signing tanúsítvány.

1. Felraktam a CA-ra. Code Signing template-et mert nem volt fenn.

2. Kértem maganak egy tanúsítványt a certificates mmc-ből (saját account)

3. Kiexportáltam a tanusítványt (private kulcs nem kell)

4. Beimportáltam a tanúsítványt a trusted Publishersbe (machine account)

Akkor most írjunk alá

5. SignTool-al /a kapcsolóval (A tanúsítványt megtalálja magától, timestamp meg nem kell most még. Max timestamp nélkül a driver megáll a tanusítvány lejáratakor.) aláírtam a cat fájlt:
"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool.exe" sign /a mchpcdc.cat

Dirvet telepítés...

Felment, van soros portom.:

U.i.: Azon gondolkozom, hogy kéne csinálni egy weblapot, ami egy saját root ca-val egy driver template-ből megcsinálja ezt a hókusz-pókuszt bárkinek úgy, hogy csak a Product/Vendor ID-t kelljen megadni.

Amazon EC2 - Windows PPTP

Első nap (este):
Jelentkezett a főnököm, hogy mi a helyzet a Windows Server 2012-es átállásunkal. Én balga elkezdtem vele beszélgetni. Mondtam, hogy a két DC kész van, a FSMO role-okat átbillentettem. Mondta, hogy látni szeretné. Kiderült, hogy az OpenVPN-je nem működik. Miután ezt a kollégám csinálta és még nem tudok eleget róla nem akartam hibakeresni este 7 felé. Mondtam neki, hogy ott a PPTP ami még félkész (DirectAccess-t kell összeraknom, de ha már az ott lesz akkor miért ne menjen rajta más VPN kapcsolat is). Mondtam 2 perc, összerakom. A 2 percből 3 óra kínszenvedés lett.
Az Amazon security policyban ügyesen a 1723-as UDP portot állítottam be a TCP helyett. Amikor erre rájöttem még mindíg problémás volt a kapcsolódás.
Gondolkoz gondolkoz.
A hálózat amiről beszélek a VPC (Virtual Private Cloud) LAN-ja (egy internettől elzárt 10-es IP tartomány)
Az Amazon egy fura szerkezet. Láthatóan minden interface routolt. A DHCP a sajátjuk, ha egy interface-hez nem állítok be egy címet a webes felületen akkor, ha fejem tetejére állok sem fog azon kommunikálni a gépem. Elkezdtem csalni. A VPN szerver hálózati interface-ére felvettem annyi másodlagos IP-t amennyit engedett (összesen 3-at). Az RRAS-on ki akartam kapcsolni a DHCP-t nem ment, az opció szürke. Keresgélek, kiderül, hogy ezt valami policy-ból kapja amit a DirectAccess management felületén lehet állítgatni. Ok. Kikapcsolom ott és megadom neki a static poolnak azt a három másodlagos címet.
Kapcsolat próba.
Beengedi a klienst. Hohó béke van. Működik. Lejelentem a főnöknek - lémer :-(
Főnök jelzi, hogy kapcsolódni ugyan tud, de a belső gépeket nem látja.
Próbálok pingelni. A VPN szerver LAN oldali lábáig jutok. Azt még tudom pingelni, tovább semmit.
Feladom. Este 9 nem akarok már ezzel foglalkozni, a dolog amúgy sem volt se fontos se sürgős. Jelzem, hogy ha nem baj másnap folytatnám.
Második nap:
Elkezdek Netmont telepíteni a kliensre is a szerverre is. Rájövök, hogy tulajdonképpen nem kötelező nekem a static poolt ugyanarról a hálóról osztanom. A routing tábla piszkálásával (az amazon routing táblájáról beszélek) oda tudom irányítani a forgalmat, nem kell hozzá a másodlagos IP címes dolog.
Megcsinálom így. Nem megy.
A kolléga mondja, hogy neki van erre egy ötlete. Állít valamit a szerveren. Változás nincs.
Elkezdem nézni az egészet a NetMonnal. Kiderül, hogy a kliensről a csomag szépen elmegy a LAN-on lévő szerverig, majd onnan vissza is jön és a VPN szervernél eltűnik a levegőben. Ez egyértelműen az RRAS körüli routing hibára utal, hiszen az Amazonon minden irányban keresztül mentek a csomagok.
Kínomban próbálok RDP-vel is kapcsolódni, hátha csak az ICMP-vel van baja. Valami "bad checksum" üzenetek vannak a NetMonban. Ennek nem tulajdonítok különösebb jelentőséget, elvégre még a ping sem megy.
További kemény guglizás. Semmi értelmes. Valahol azt olvasom, hogy az off-lan IP tartományhoz fel kell venni egy címet a hálókártyára másodlagos címet. Felveszem, nincs változás.
Elkezdek a technetklub fórumon kérdezősködni. Semmi értelmes válasz.
Feladom. Más munkám is van.
A főnököm kérdezi, hogy mi ezzel a helyzet. Mondom, hogy még mindíg nem megy és a CRM költségkalkulációt csinálom. Válasz: Jó, a CRM fontosabb. Huhh.
Második nap (este):
Újra nekiugrok. Elkezdek felúzni egy második VPN szervert. Próbálnék összehozni egy kéthálókártyás konfigot (RRAS standard verzió, hátha a NAT-os dologgal van baja). Ez sehogy sem megy. Ha kirakom a netre akkor nem tudom belógatni a VPC-be. Ha a VPC-be rakom akkormeg nem tudok neki közvetlenül internetes címet adni, csak NAT-on kersztül. Végülis felhúzok valamit, amiről kb. a második újraindítás után kiderül, hogy nem tudom többé elérni (RDP only mizéria). Lezúzom.
Újrakezdem az egészet. Marad az egy hálókártya. Próbáljunk meg egy tiszta állapotot, hátha a DirectAccess-es konfig a gond. Mire odajutok, hogy a gép felrakja a security fixeket, nagyon késő van. Másnap folyt köv.
Harmadik nap:
Befejezem a második VPN gép konfigurációját. Csak az RRAS, nincs DirectAccess. A helyzet ugyanaz. Sőtt még rosszabb. Itt még vissza sem jönnek a csomagok a LANon  lévő belső szervertől.
Nézem jobbra, nézem balra, semmi. Örjöngök. Két percre vagyok tőle, hogy lezúzzam az egészet és felrakjak egy linuxos PPTP-t.
Szólok a kollégának, hogy nézze meg. A két VPN szerveren ugyanaz van beállítva, ugyanúgy van a routing összerakva. Az egyiknél visszajönnek a csoamgok a LANos gépektől, a másiknál nem. Nézi-nézi, majd eszébe jut valami. Most derül ki, hogy mit állított az előző napon.

Itt kérem security van. A rendszer ellenőrzi, hogy a bejövő és a kimenő IP forgalom megfelel-e a konfiguráltnak. Ezt ki is lehet kapcsolni. Itt ki is kell az off-lan tartomány miatt.
Hurrá. Mostmár mindkét VPN szerveren visszajönnek a csomagok a LAN-ról.
Mit oldott ez meg? Kb. semmit. Ettől még nem megy a VPN.
Feladom. Dél van, el kell mennem elintézni valamit.
Visszajövök és elkezdek AD FS-el, O365-el, Exchange és CRM migrációval foglalkozni. Ezek messze fontosabbak.
Kicsit később még bevillan valami. Mi van akkor, ha annak a NetMonban látott "bad checksumnak" mégis van jelentősége.
Gugli.
Látok olyan bejegyzéseket, hogy más is tapasztalt ilyesmit az Amazon EC2-ben, de azok átmeneti jelenségek voltak és hardver hibára utalnak. Emlegetnek még holmi checksum offload-ot, meg a hálókártya beállítgatásait. Nézzük meg, fájni nem fáj. Irány a Device Manager.

Nézd már, itt van egy olyan beállítás, hogy "Correct TCP/UDP Checksum Value". Ezek tudnak valamit. Ezek szerint el szokott romlani amit javítani kell. Kapcsoljuk be!
És minden elkezd működni.
Épp a Microsoft/Citrix/Amazon jó édes nénikéjét szidom felváltva. Azt, hogy melyik a tettes nem tudom, de ez egy csúnya nagy BUG (jó-jó tudom: feature).

Microsoft 3D

Hosszú ideje most érzem először, hogy a Microsoft csinál valamit, ami előremutat és nem amatőrök próbálkozása arra, hogy csinálni kéne valamit, de fogalmunk sincs, hogy mit:
http://mobile.nytimes.com/blogs/bits/2013/06/26/microsoft-moves-to-simplify-3-d-printing/
Azt gondolom, hogy a hír időzítése nem volt véletlen:
http://m.techcrunch.com/2013/06/19/stratasys-acquiring-makerbot-combined-company-will-likely-dominate-3d-printing-industry/