Tré-Systems

/Örjöngés on
Kedves drága Tré-Systems,
Mondjátok már meg, hogy a teljesen legitim - Microsoft Office 365 által kiállított és egyébként más domain-ben az AWS Route53 által elfogadott - DKIM rekordot mi a bús francért nem lehet a DNS szervernek csúfolt hulladékotokba bejegyezni????
/Örjöngés off

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 - Ö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?

Drága Microsoft - Ez nem igazán jött össze

Sűrű gratulációim, az Office 365-ös CRM üzemeltetőknek.

Lync telepítés bonyolultan

Cégünk jelenleg SkyPE-ot használ a belső kommunikációra (instant message, telefon,videokonferencia). Az utóbbi időben elég sok bajunk van vele. Szakadozik, lebontogat. Ezen túl, céges környezetben igen kényelmetlen használni.
A tárgyalóban van egy gép. Ezt használják a kollégák a belső gittrágásokhoz konferenciagépnek. Van rajta egy jog nélküli felhasználó akinek a SkyPE felhasználója mindenkinél fel van véve aki a konferenciákon részt vesz.

Múlt hét Hétfő:
Kezdődő gittrágás kapcsán jönnek a kollégák, hogy a SkyPE kliens nem tudja frissíteni magát, kéne neki egy admin. Odamegyek, kétszer megpróbálok belépni az atyaúristen felhasználómmal az UAC-ba, nem enged be. A kollégák elzavarnak, hogy hagyjuk, a gittrágás megy ennélkül is, és az most fontossürgős.

Kedd délután:
Megtalált a manágement, hogy Lync kéne. Némi kavarás, hogy épp tudok-e E3 próbát kérni az O365-ből. Nem tudtam, vettünk néhány felhasználót próbára. Este 9-re ketyegett a Lync

Csütörtök:
Elővettem a tárgyalóban lévő gépet. Megpróbáltam belépni rá adminként (domain adminként). Közölte, hogy nem tud beengedni, mert a gép és a domain közötti trust az örök vadászmezőkre távozott. Kísérlet jobbra, kísérlet balra, semmi.
Kiderült, hogy sikerült két gépnek azonos nevet adni. Hurrá!!!
Fogtam a másik gépet amely láthatóan birtokolta az accountot a domainben és átneveztem.
Újabb bejutási kísérletek következtek, sikertelenül.
A lokál admin jelszavát nem tudom. Próbáltam kideríteni, nem jött össze.

Péntek:
Sürgetés a manágementtől, hogy lehet-e már Lync-et teszteli. Nem.
Törjük föl:

A homlokomon látható balek felirat villogtatása bekepcs

Keresek offline password hack toolt.
Találok egyet. Kiírom USB-re, gép nem bootol.
Keresek másikat. Közli, hogy USB, csak a fizetősben. Ok. CD-t írok. Bootol (Linuxot). Megmutatja a felhasználókat. Közli, ha jelszót akarok változtatni, fizessek.
Anyád.
Fizetek.
Letöltöm,
USB kolcsot gyártok.
Bedugom a gépbe, nem bootol.
Anyád.
CD-t írok. Bootol. XP-t!!!!!!
Grafikus felület, nem látja a diszket.
Már, hogy a repedtsarkú büdös istenit látná a nyüves 13 éves XP a diszket egy akutális UEFI-s notin?
Mi a halálért kellet azt a linuxot ami megmutatta az accountokat XP-re cserélni.
Pénz kuka. Eddig is utáltam azokat a cégeket, amik free toolok tetejére épített grafikus szirszarból csinálnak pénzt. Általábban messze elkerülöm, csak most sürgős és fontos. Reméltem legalább működik. Hát nem.

Ma (azaz Hétfő):
Nézzük meg, hogy a Hiren aktuális verziója kezeli-e a Windows 8.1-et.
És igen.
Hiren letölt, CD süt, bootol.
Nem bootol. Megáll valahol a password change-es linux közepén.
Néhány kernel opció kipróbál, semmi. Csókoltatom a Lenovo-t, vagy valakit.
Noti szétkap, vinyó ki, HP desktop-ba be.
F2, F8, F9, F10 össze-vissza nyomkodása: Hiren elindul.
Kinyírom az Admin jelszót.
Vinyó vissza a notiba.
Admin nem tud belépni. WTF?
Megint szétszed, diszk, vissza a HP-ba.
Megnézem tüzetesebben:

User: Administrator
Is Admin: Yes
Status: Locked

User: XXXXXXXX
Is Admin: Yes
Status: Blank

Hogy az a jó büdös. Nem figyeltem oda. A lokál admin tiltva, helyette viszont van egy user JELSZÓ NÉLKÜL, ADMIN JOGOKKAL!!!!

Áááááááááááááááááááááááááááááááááááááááááááááááá!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Balek lámpa kikapcs

Vinyó vissza,
Jelszómentes userrel belép,
domainből kiléptet,
domainba beléptet.
Domain Adminnal belép,
Lync letölt telepít.
Az össz áldozat, a tárgyaló user automatikus loginja. Ezt még orvosolnom kell.

Dynamics CRM: Költözés a felhőbe 2.

Nagynehezen megszereztem a Connector for Microsoft Dynamics nevű eszközt. Lassan működik is. Az egész felhőbe költözésről találtam egy jó cikksorozatot. A blognak viszont nincs keresője. Kibogarásztam az összes részt, itt vannak a linkek:

Part 1 - Downloads
Part 2 – Connector Installation
Part 3 – Connector Configuration
Part 4 – Configure and Run a Simple Integration
Part 5 – Mappings
Part 6 – Sample Data Integration – Part 1
Part 7 – Sample Data Integration – Part 2
Part 7 – Sample Data Integration – Part 3
Part 7 – Sample Data Integration – Part 4
Part 7 – Sample Data Integration – Part 5
Part 8 – Record Actions

Dynamics CRM: Költözés a felhőbe

Most biztosan valakiknek a tyúkszemére lépek. Bizton állíthatom abszolult igazságtalan leszek. NEM ÉRDEKEL. Akinek nem tetszik az ...

Röviden: A FENTI FUNKCIÓ NEM LÉTEZIK!!!
(A határán vagyok annak, hogy azt mondjam a főnökömnek, hogy ha kirúg ehez akkor sem nyúlok hozzá. Elegem van.)

Hosszabban:
Van egy Dynamics CRM 2011-ünk tele egy rakás adattal és kb. 10 felhasználóval, tehát nem egy nagy rendszer. Eddig kb. másfél napot töltöttem azzal, hogy megoldást találjak az adataink migrációjára. A Microsoftnak NINCS megoldása.
A következő lehetőségek körvonalazódnak:
1. Specializált szolgáltató igénybevétele.
Egy fórumon találtam egy céget akinek van megoldása. Azt írták hozzá, hogy "reasonable price". Ja reasonable - £6950
2. Manuálisan minden entitás export majd a másik oldalon import:
Ez egy vicc. Kb. minden szétesik, a fele nem megy át, a kapcsoaltok, tulajdonosok elvesznek. Csatolmányok exportja Excel cellákba??? Mégis hogyan???
3. Nem migráció, hanem szinkron
Ez bíztató.
Microsoft Dynamics CRM 2011 Instance Adapter
Ez elvileg képes két CRM organizációt szinkronizálni. Arról csak, homályos információk vannak, hogy ez vajon az Online-al működik-e, de talán.
Letöltöm. Telepíteném. Nem találom a könyvtárat ahova tenni kéne. Megnézem jobban a doksit. Van benne egy link a Microsoft Dynamics Connector nevű cuccra. Rákattintok a linkre, jön egy Live login. Bejelentkezek, üres képernyő.
Hurrá. Firefox félrerak, IE.
Bejelentkezek, közli, hogy valami CustomerSource account nincs hozzárendelve a Live ID-mhoz, és, hogy menjek a saját CustomerSource adminomhoz. Húú, nekem már olyan is van? Nincs.
Nyomozok.
Kiderül, hogy vagy CustomerSource vagy PartnerSource account kellene. Nekem olyan nincs. PartnerSource azért, mert láthatóan az a Silver vagy a Gold Dynamics kompetenciához jár, nekem, meg olyan nincs (Sőt nem is lesz).
Hosszú órákon keresztül próbálom kideríteni, hogy lehet-e nekem ilyen.
Microsoft.hu online CRM támogatás. Csak fizetős opció van. Nem igazán fizetnék azért, hogy megtudjam, lehet-e megfelelő accountom.
Partner portál támogatás.
Próbáljunk egy online chat-et:

Khmm. Délután kettő van.
Ok, hívjuk őket telefonon:

Az a szám, ott vajon mi lehet? Biztos, csak én nem tudom telefonszámra dekkódolni.
Próbáljuk meg az informális csatornákat:
Telefon 1.
- PartnerSource account? Ő nem tud róla, hogy neki lenne olyan.
Telefon 2.
- Megpróbálok belépni. Nem enged be
- Akkor nincs
Telefon 3.
- Három éve nem foglalkoztam Dynamics-el

További nyomozás:
Egy fórum bejegyzésből kiderül, hogy valamikor a CRM Online felhasználóknak automatikusan adtak CustomerSource hozzáférést:
http://community.office365.com/en-us/forums/148/t/78035.aspx
Mint az jól megfigyelhető az MS agent típusú biorobrotjai abszolult pontosan tudják, hogy hol vannak. Nem volt kicsit sok a fű?

Még van két levegőben lógó ötletem, hogy hozzájussak a cucchoz.

Na szóval. Az egész történet bicskanyitogató. És még nincs vége.
Hogy ha én választanék migrálnám e az On Premise CRM-et a felhőbe?
Nincs az az isten.
Fogom-e ezt másnak ajánlani?
Amíg ez ilyen - no way.

U.I.
Találtam egy doksit a Microsoftnál a hőn áhított migrációs folyamat fordítottjára. Ezzel kezdődik:

"To request a backup of your Microsoft Dynamics CRM Online database contact Technical Support for Microsoft Dynamics CRM Online. For contact information, see Contact Technical Support."

Ez most komoly? Nem, nem lehet. Ma én vagyok a kész átverés show alanya. Vajon, hol lehet a kamera? Vagy meghekkelték a webkamerámat?

Office 365 - dirsync bug (ja bocs feature)

Hétfőn neki is láttam a nagy teljesen felesleges migrációnak.
Új Exchange telepítés, hibrid újrakonfiguráálás, számomra is meglepő módon, alig néhány elszállással végzett.
Az csoda számba megy nálam, hogy a Hybrid wizzard már másodszorra (persze minden adatmódosítás nélkül) képes volt hiba nélkül lefutni.
A végeredményben csak egy gond maradt. Nem tudodok az On-Premise teszt useremről levelet küldeni a cloud usereknek. Ezt, majd megoldom (úgyis várnom kellett az Amazonra, hogy megcsinálja a reverse rekordom, aminek hiánya nyugodtan lehet az ok).
Nekikezdtem a mailboxok migrációjának. Erre némely usernél ezzel a hibával örvendeztet meg:

Arra viszonylag gyorsan rájövök, hogy ezek a mailboxok nem az On-Premise környezetből lettek migrálva, hanem a felhőben "gyártódtak".
Megnézem, hogy mi a helyzet.
És tényleg nincs Mailbox GUID:

Irány a kugli.
Találok valami zavaros fórum bejegyzést, hogy a Dirsync-nek kéne ezt megoldania.
Megnézem, nincs bekapcsolva a Dirsync-en a kétirányú szinkron. Hogy ez mikor kapcsolódott ki arról lövésem sincs. Visszakapcsolom, full resync.
Probléma marad.
Ok, akkor nekiugrok, ADSI Edit. Kitöltöm. Pontosabban kitölteném, de semmi kedvem kézzel konvertálgatni a GUID formátumot HEX-be.
Kugli.
Itt a konverter:

GUID beír, migráció próba, működik.

Utóirat:
Ma nekiállok megírni ezt a cikket. Elkezdem keresni a fórumbejegyzést ami a Dirsync rendbetételét javasolta. Azt nem találom, helyette ez kerül elő:
http://community.office365.com/en-us/wikis/exchange/566.aspx
A dolog, iskolapéldája, hogy az O365 support (aki az említett fórumbejegyzésre válaszolt) mennyire van képben. A Dirsync nem írja vissza a GUID-ot és ez LE IS VAN DOKUMENTÁLVA!!!

Utóirat 2:
Azon gondolkozom, hogy a probléma esetleg proaktívan orvosolható lenne. Az EMC tud olyat, hogy bizonyos feladatokra rá lehet kapcsolódni és plusz dolgokat lehet vele csináltatni. Ezzel korábban már volt dolgom, csak most nem találom a cikket róla (lehet, hogy nem is írtam?).
Na szóval, ebbe a mechanizmusba be lehet tenni egy scriptet ami az online mailbox legyártásakor berakja a GUID-ot a helyére. Ez az a script amit most fix nincs időm megírni.

Office 365 - CRM Új fejezet

Korábban már írtam az O365/CRM kálváriánkról itt:
http://it-pro-hu.blogspot.com/2014/01/office-365-hogyan-nincs-ingyenes-crm.html
http://it-pro-hu.blogspot.com/2014/01/office-365-es-tenyleg-nincs-crm-trial.html
Most hétfőre megszületett a management döntése:
Bármily fájdalmas is (legalábbis nekem biztosan) meglépjük a Tenant váltást.
Még tettem egy utolsó lagymatag kísérletet arra, hogy találjak más megoldást. Persze nincs. Az Észt Tenant nem váltható át UK Tenant-é és az Észt Tenant-be nem lehet CRM-et rakni.
Ez utóbbinál álljunk meg egy szóra.
Észtországban, nincs Online CRM. Belefutottam egy Microsoft-os FAQ-ba. Ez felsorolja azt a 42 (érted! NEGYVENKETTŐ) nyelvet amin az Online CRM elérhető. Mit gondolsz az Észt mint nyelv köztük van? Guess!!! És igen! Ott virít a listában.
Ez számomra egy bohózat. Vagy inkább egy Kafkai magasságokba (bár ez itt inkább mélység) törő abszurd.
Na mentem vissza migrálni...

Office 365 - Murphy

Az egyik ügyfelemnek már régen tartozom az Exchange szerverén egy disclaimer beállítással. Ma reggel nekigyürkőztem és megcsináltam.
A múlt héten a főnököm, még mielőtt elutazott kiadta feladatba, hogy a sajátunkat is csináljam meg (visszajött feladatnak amit én találtam ki. :-D ).
Az ügyfél dolgán felbuzdulva nekiálltam a sajátunknak. Kitöltöttem az AD-ban a paramétereket (cím, telefonok, stb.), leszinkronizáltam az O365-be, majd bementem az online felületre, hogy legyártsam a disclaimert. Ott egy Exchange, Service Degraded ützenet fogadott:

Murphy szeret engem. :-D

Office 365 - És tényleg nincs CRM Trial (legalábbis nekem)

Ezen már csak röhögni tudok - kínomban.
A helyzet a következő:
A cég ahol ez az egész dolog pörög Észt. Miután a székhely, és a könyvelés Tallinn-ban van, az Office 365-öt is Észtországba regisztráltam (A Tallinni címre kiállított számlára van szükségem).
Észtország nincs rajta a CRM országlistáján.

A jó (Good):
Miért nem iratom át az accountot máshova?  Mert nem lehet.
Ez biztos valami adminisztratív baromság! Nem. Itt védenem kell a Microsoft mundért. Az Amazonos tapasztalataimból kiindulva, az a gyanúm, hogy a lokáció megadása nem adminisztratív, hanem technikai ügy. Ez dönti el, hogy az adataim melyik datacenterbe kerülnek. Könnyen lehet, hogy abban a datacenterben ahol az én accountom van még fizikailag nincs CRM. Az ilyesmit nem egy pillanat felépíteni.

A rossz (Bad):
Ki vagyok akadva a kommunikáción. Ezt miért nem tudta már az első jóember megmondani egy hete amikor beszéltem velük. Miért kellett végignyomni az egész cirkuszt, kifizetni, az így felesleges accountokat. Ha már látom a megoldást ezt azért megpróbálom leverni rajtuk.

A csúf (Ugly):
Ha mindenképp akarom a CRM-et akkor a megoldás az új account gyártása, immár UK lokációval. Mindent végigküzdeni, átmigrálni, lerendezni, kemény meló, ráadásul az ehhez rendelkezésreálló eszközök darabszáma és használhatósága duplanulla.
A legrosszabb az egészben, hogy nekem kell végigszívnom.

Office 365 - Hogyan nincs ingyenes CRM trial

Hmmm. Mostanság megint kezd több lenni az IT mint az Elektronika itt (na ezen majd változtatok).

Na akkor lássuk ezt a CRM trialt.
A cégünk Október végén átállt Office 365-ra. Pontosabban az Exchange Online Plan 1 fedőnevű valamire.
A múlt hét csütörtökén az egyik főnökünk kitalálta, hogy a meglévő CRM 2011-ünket is be kéne tolni a felhőbe, és ezt ki kéne próbálni. Semmi gond, trial van, elindítom és 10 perc múlva már lehet nyomogatni (gondoltam én).
CRM Trial van, elindítom és:

"Microsoft Dynamics CRM Online Trial cannot be added to your account together with plans you already have. "

Na jó. Keresgélek, nem találok semmi értelmeset. Gonodlom gyorsítsunk a dolgon, megmaradt a saját kis cégemből 10 partner órám. Az évforduló, meg 15-én van tehát nem vesztek semmit.
Levél a partner supportnak.
Visszahív egy kedves fiatalember. A következők derülnek ki:

• CRM csak E3 plan-hez renedlhető
• Ő E3 Trial-t nem tud adni, menjek a normál supporthoz
• Az 5GB helyett 20GB tárhely, menjek a normál supporthoz

Levél a normál supportnak. Visszahívnak. Eredmény:
A lejárt, félig kihipózott E3-am nem engedélyezhető vissza, vennem kell legalább egy E3 licenszet. Az 5GB helyett 20 csak akkor kérhető, ha már kifizettem.

A management jóváhagyja a licensz vásárlást a CRM-ben érdekelt négy embernek.
Irány a portál. Kiderül, hogy lehet licenszet upgrade-elni, nem kell pluszban venni. Megpróbálom. Csak az egész cégre engedi. Nyomozok. Kiderül, hogy tényleg. Ha mást akarok, irány a support.
Tegnap írok nekik. Válasz nincs.

Ma délben telefon. Némi kínszenvedés és tologatás után sikerül a 4 licenszet átválatni E3-ra.
CRM Trial indít:

"Microsoft Dynamics CRM Online Trial cannot be added to your account together with plans you already have. "

Hogy az a jó...
Biztos az a baja, hogy nekem saját magamnak nincs E3 licenszem.
Portal:
Nini. Tudok E3 trial-t regisztrálni (tegnap még nem tudtam). Hmmm. Akkor miért is kellett megvennem a licenszeket?

Csinálok E3 trialt. Adok magamnak E3-at.

CRM Trial indít:

"Microsoft Dynamics CRM Online Trial cannot be added to your account together with plans you already have. "

Itt tartok most. Még nem adtam fel, de lassan megkérem a managementet egy on-premise migrációra.

Plusz megjegyzés:
A Microsoft marketing tökéletes. Merem feltételezni, hogy a callcenter Office 365 Lync-en fut. Tehát nincs az az isten, hogy akárkinek javasoljam az Office 365 Lync-et. Ennél trágyább hangminőséget telefonon még soha senkinek sem sikerült produkállnia (VoIP-on sem).

Office 365 - Ahogy a Microsoft a dolgokat kezeli

Pénteken néhány kollégánk a Londoni irodában jelezte, hogy az Outlook nem tud kapcsolódni a levelezéshez.
Megnéztem, hogy mi történt az Office 365 szolgáltatással. Az Outlook hozzáférés valóban nem működött. Itt a szolgáltatásnapló:

Lefordítottam a fentieket egy közérthető párbeszédes formába. (Megjegyzés: ez a beszélgetés nem hangzott el):

Ügyfél: - Nem működik
Támogatás: - Megnéztük, működik
Ügyfél: - Nem, nem működik
Támogatás: - Mint már korábban is mondtam - MŰKÖDIK
Ügyfél: Nem, nem, nem. Nem működik. Nem tudom használni
Támogatás: - Lassan és hangosan mondom, hogy te is megértsd - M Ű K Ö D I K !!!
Ügyfél: - Ezt nem hiszem el. NEM TUDOK DOLGOZNI !!!
Támogatás: - Hopp. Tényleg nem megy. Javítjuk.

Office 365 - Csináljunk "Open Relay"-t

Szerinted nem lehet?
Pedig igen.
Amit itt leírok az nem teljesen "Open".
A dolog arról szól, hogy vannak gépeink amik levelet akarnak küldeni. Authentikáció nélkül, ki a nagyvilágba.
Rosszul hangzik? Pedig nem.
A legegyszerűbb eset, ha van egy web server amely a regisztrációról megerősítő levelet küld. A gép maga valahol van a nagyvilágban és nem az O365/Azure felhőben.
Jó-jó, de miért nem authentikáltan?
Mert az pénzbe kerül. Miért?
Mert authentikálni csak létező felhasználóval tudunk. Annak meg postaláda kell. A rendszerünk valamelyik felhasználója pedig erre nem jó, mert el kellene tenni a web szerver konfigurációjába a jelszavát (rossz ötlet).

Hogy is kell ezt összehozni?
Így:
1. Először is elmegyünk az Exchange Admin Center/Mail Flow/connectors-hoz.
2. Ott azt mondjuk, hogy Add (megnyomjuk a nagy büdös plusz gombot).
3. Ezek után beállítjuk az abrán lévő dolgokat.

(Nem kell megijedni, nincs ekkora monitorom, csaltam. a Paint.Net a mi barátunk)

Amint ezt megtettük, kész is vagyunk.
A dologhoz még az tartozik hozzá, hogy a küldő oldalon az Office 365-től az MX beállításhoz kapott FQDN-t kell használnunk mint smarthost és nem az smtp.office365.com-ot.

Office 365 - Public Folder: Van, de minek

A kollégáim kitalálták, hogy legyen közös naptár az Office 365 Exchange-ben.
Erre ugye a jól bevállt módszer a nyilvános mappa.
Megcsináltam.
Pontosabban csináltam egy nyilvános mappát ami e-mail-eket tartalmazhat.

Az Oulookban nem jelent meg.
Elmentem ebédelni.
Megjelent.
Hurrá.
Megpróbáltam az All Public Folders alá létrehozni egy naptár típusú PF-et.
Közölte nincs jogom. Remek. Az All Public Folders jogait pedig nem lehet állítani (ha mégis akkor csak PowerShell-ből, azzal pedig most nem szórakoztam).
Legyártom a naptárakat a korábban létrehozott e-mail típusú cucc alá, mindenkinek jogot adok.
Béke...

Akkor most jöjjön a kliens:
Outlook 2013. Látom a naptárat a folder nézetben. A naptár nézetben sehogy sem tudom felvenni. A mappa tulajdonságainál nyoma sincs, hogy felvehetném a naptár nézetbe, a kedvencekhez nem tudom hozzáadni. Remek.
OWA. Ezzel indítunk: http://community.office365.com/en-us/forums/158/t/160677.aspx.
MS mondja OWA-ban nincs PF
User mondja OWA-ban van PF ha hozzáadod a kedvencekhez
Másik MS mondja (ja tényleg) OWA-ban van PF
Közösen mondják Se naptár se névjegyalbum.

Hurrá.
Akkor most mi a jófrancnak van a PF? A választ tudom:
Az én bosszantásomra.

Office 365 - Dynamic Distribution Group

Kollégám próbál egy tervezett leállás levelet kiküldeni a plepsnek. Nem megy ki. A múltkor kiment.
Mi történt azóta? Katasztrófa.
A katasztrófa neve: Office 365 Hybrid Deployment
Mi történhetett?
gugli
Eredmény:
http://support.microsoft.com/kb/2685437
Ezek szerint valami email stempli hiányzik a distribution groupomról. Csináljuk meg:
A stempli nem hiányzik...
A DISTRIBUTION GROUP HIÁNYZIK!!!
Újabb keresgélés:
http://community.office365.com/en-us/forums/156/t/187434.aspx
Innen:
"In Office 365 with Hybrid Deployment, if you create Dynamic Distribution Groups on the on-premises Exchange organization, these objects are not replicated to Office 365 via DirSync. Therefore for mailboxes in the Office 365 cloud they will not see the Dynamic Distribution Group in their Global Address List, and so therefore can only email the members of the list by sending an email directly to their email address.
To show the Dynamic Distribution Group in the GAL in the cloud, you need to add a MailContact to the cloud that represents the Dynamic Distribution Group. This MailContact object should have the following mappings: 

On-Premises DDL	Cloud MailContact
Name	Name
proxyAddress	ExternalEmailAddress
Alias	Alias

Note that this MailContact object is made in Office 365 or Exchange Online and not in the on-premises AD. It is not replicated to the cloud via DirSync. If it exists on premises then the name for the DDL will appear twice in the on-premise GAL, once as a DDL and once as a contact object.
To determine the information need for the cloud contact object, run the following in Exchange Management Shell on premises: Get-DynamicDistributionGroup | fl Name,EmailAddresses,LegacyExchangeDN"


Először is, szidom mindenkinek a jó édes nénikéjét, hogy miért nem lehet ezt tisztességesen megcsinálni.

Elkezdek gondolkodni, majd nem csinálom meg a fentieket. Helyette, létrehozom mégegyszer a dinamikus disztribuciós listát a felhőben.

Hogy miért?

Mert a fenti megoldás sok sebből vérzik:

1. A felhőben lévő felhasználók az Outlookban névjegyet látnak és nem disztribuciós listát
2. A saját Exchangeben lévő felhasználók látják a névjegyet is és a disztribuciós listát is ugyanis a névjegyek szinkronja működik, ráadásul két irányban
3. Ping Pong. Miután a disztribuciós lista nem létezik a felhőben így ki sem lehet fejteni a felhőben. Küldök egy levelet a listának (pontosabban a névjegynek). A levél elmegy a saját Exchange-be, ott kifejtődik a disztribuciós lista, majd visszamegy a felhőbe. Sávszélesség és idő.
4. Mi történik, ha végül felszámolom a saját Exchange-en a transportot, mailboxot és átköltöztetem a felhőbe a transportot? A disztribuciós listára menő levelek nem fognak megérkezni.

Miért nem okoz gondot ez a megoldás? Mert nincs szinkron, így a két lista sohasem fog összecsattanni egymással.
Pontosabban fog, majd ha a Dirsync lekezeli ezeket. Akkor majd ki fogom bírni, hogy kapok néhány ütközésről szóló levelet.

Office 365 (félre)konfigurálva

Nem kis kínszenvedés árán (AD FS, aoutodiscover szívások) a céges levelezés lassan beköltözik az Office 365-ba. Hibrid konfigurációt csináltam, mert nem akartam menekülő út nélkül összerakni az egészet. Mi van ha gáz van, ha valami nem működik, stb.?
Tegnap az egyik főnököm jelzi, hogy egy specifikus embertől nem jött meg egy levél, amit végülis a magán címén megkapott, de a cégesen nem.
Nézem az Event logot és ezt látom:

Ok, akkor nézzük meg az SMTP logot. Na az nincs mert, a Manage Hybrid Configuration Wizard ugyan létrehozta ezt az inbound connectort, csak éppen a logolást nem kapcsolta be rajta.
Megnézek még egy-két beállítást, kicsit tuningolok, hátha.
Bekapcsolom a logolást, hogy lássuk mi van...

Ma reggel. Megnézem az event logot, a fenti bejegyzések változatlanul ott vannak.
Irány az SMTP log (mostmár van):

Itt látszik, hogy a feladó IP-je beleesik az Office 365 által kreált konnektor IP tartományába. Megnézem, hogy ki a feladó: messagelabs.com.
A messagelabs.com a weben a Symantec oldalára irányít.
A MessageLabs egy online levélszűrő. A Symantec felvásárolta őket jó régen:
http://www.symantec.com/about/news/release/article.jsp?prid=20081117_01
Na tehát a következő derül ki számomra:
A MessageLabs IP címei beleesnek az "Inbound from Office 365" konnector tartományába. A MessageLabs kimenő SMTP-in ki van kapcsolva a TLS, Az "Inbound from Office 365" konnektoron kötelező a TLS. Eredmény: A levelek nem jönnek be.
Ez félre van konfigurálva drága Microsoft, de nagyon.
Létrehozok egy bugfix connectort TLS enforcement nélkül és felveszem az IP-t.
Küldök egy service requestet az O365 supportnak.
Gondolkozom, további logturkálás/nslookup. Kiderül, amit sejtettem: A MessageLabs több száz forrás IP-ről küld levelet. Bugfix konnentor elvet, TLS enforcement kikapcsol (adjunk egy pofont a biztonságnak).

Továbbgondolom. Íme az elméletem:
A Manage Hybrid Configuration Wizard a teljes Azure felhő összes IP tartományát felveszi a "Inbound from Office 365" konnektorra. Valaki nem gondolta végig azt, hogy Azure cloud <> Office 365. Natív spekuláció, de el tudom képzelni, hogy a MessageLabs az Azure infrastruktúrán fut.
Tehát, ha valaki Mail szervert üzemeltet az Azure-ban és a kimenő SMTP-n a TLS nincs engedélyezve, az nem tud levelet küldeni egy Hybrid Exchange-nek.
Mi rosszabb, ugyanez valószínüleg a teljes Office 365 infrastruktúrára igaz ezek alapján:
http://community.office365.com/en-us/forums/158/t/156048.aspx
Ezzel csak az a gáz, hogy ha bemigrálom a bejövő levelezésemet is, ott már nem tudom a TLS enforcement-et kikapcsolni.