SSL Mutual String & Exchange 2010

[Verwijderd]

Na enkele uren/dagen rondsurfen op het grote internet, heb ik beslist toch mijn vraag hier eens te posten, omdat ik er niet uitkom. De situatie is als volgt:

Wij hebben een Hosted Exchange 2010 omgeving gespreid over twee AD-Site's. Wij werken samen met een partner en dit maakt de zaak een heel stuk ingewikkelder. Wij bezitten namelijk het AD-Domein en de hoofdsite. Maar zij willen ook mailboxen verkopen maar onder hun naam zonder verwijzing naar ons. Dit is de basis van het probleem. Ik ben op dit moment al redelijk ver met het volledig uitrollen van het systeem, maar zit met een probleem: Autodiscover

Op dit moment is het zo:
mail.domein1.com verwijst naar de CAS-Array in Datacenter 1
mail.domein2.com verwijst naar de CAS-Array in Datacenter 2

Alles werkt hiervoor: RPC over HTTPS, Web Access, EWS ( zowel via mail.domein1.com en mail.domein2.com ). Afhankelijk van waar de mailbox verblijft DC1 of DC2, ... Geen probleem. Nu hadden wij enkele problemen met OOF en Agenda in de Outlook Clients ( die krijgen niet de correcte EWS-links door, waardoor deze niet werkten ). Ter info: Al onze klanten connecteren via RPC over HTTPS

Nu heb ik voor mail.domein1.com ( en de hosted domeinen die standaard via DC1 verlopen ) de autodiscover met IIS redirection ingesteld. Er wordt verwezen naar een IP in DC1 en de CAS-Array antwoord met de Autodiscover settings. Nu dit werkt zonder probleem. De settings worden mooi opgehaald en alle gegevens worden doorgegeven. Dit zijn de settings die hij doorkrijgt:

Proxy-server: https://mail.domein1.com
SSL Mutual String: msstd:*.domein1.com
+ alle overige instellingen

Tot hier geen enkel probleem. Het probleem stelt zich als volgt.
De problemen met de OOF en de Agenda heb ik dus ook voor mailboxen die connectie maken via het tweede Datacenter. Dus wil ik ook voor hen een Autodiscover systeem aanmaken. Het idee is hier om de mailboxen die standaard op DC2 verblijven een autodiscover record aan te maken die verwijzen naar een IP in DC2 ( die doorgelust is naar de CAS-Array in Datacenter 2 ). Dit werkt ook zonder probleem, de settings worden opgehaald, maar daar zit nu net de fout. Dit zijn de gegevens die de Autodiscover service van de CAS-Array in DC2 doorgeeft:

Proxy-server: https://mail.domein2.com
SSL Mutual String: msstd:*.domein1.com
+ alle overige instellingen

De SSL Mutual string wordt dus verkeerd doorgegeven, waardoor Outlook dus geen verbinding wil maken met de Exchange server ( wat ook logisch is ). Hier loop ik dus vast. Ik krijg Exchange maar niet uitgelegd dat hij, als het Autodiscover Request toekomt op de CAS-Array in DC2 dat hij een andere mutual SSL-String moet doorgeven.

Wat heb ik reeds geprobeerd. Het eerste dat ik getest heb is de OutlookProviders aangepast zodat er geen mutual string niet meer doorgegeven wordt.

code:

[PS] C:\Users\...\Desktop>Get-OutlookProvider

Name           Server      CertPrincipalName    TTL
----           ------      -----------------    ---
EXCH                                              1
EXPR                                              1
WEB                                               1

Het probleem hiervan is dat ik hem enkel kan wijsmaken dat hij geen specifieke string meer kan doorgeven.
Met bovenstaande instellingen krijg ik volgende instellingen door:

CAS-Array DC1
Proxy-server: https://mail.domein1.com
SSL Mutual String: msstd:mail.domein1.com

CAS-Array DC2
Proxy-server: https://mail.domein2.com
SSL Mutual String: msstd:mail.domein2.com

Het probleem hier is dat de beide certificaten wildcard certificaten ( *.domein1.com en *.domein2.com ) zijn en dat dus beide niet meer werken. Geen oplossing dus. Volgende idee, was om de OutlookProvider wijs te maken dat indien een request binnen kwam op de een van de members van de CAS Array in DC2 er een andere Mutual String doorgegeven moest worden:

code:

[PS] C:\Users\...\Desktop>Get-OutlookProvider

Name      Server               CertPrincipalName             TTL
----      ------               -----------------             ---
EXCH                                                           1
EXPR                           msstd:*.domein1.com             1
CAS01     CAS01.MAIL.GLOBAL    msstd:*.domein2.com             1
CAS02     CAS02.MAIL.GLOBAL    msstd:*.domein2.com             1
WEB                                                            1

Dit is dan de uitkomst van de autodiscover:

CAS-Array DC1
Proxy-server: https://mail.domein1.com
SSL Mutual String: msstd:*.domein1.com

CAS-Array DC2
Proxy-server: https://mail.domein2.com
SSL Mutual String: msstd:*.domein1.com

Dus nog steeds niet de oplossing, want clients op het tweede datacenter hebben daar nog steeds niets aan, en die krijgen fouten. Ik ben hier al enkele dagen naar opzoek.

Heeft er hier iemand ervaring mee? Of weet er iemand een idee wat ik nog kan aanpassen of wijzigen zodat toch de juist mutual string doorgegeven wordt?

[wagenveld]

Het zal wel aan mij liggen, maar het is nogal een ingewikkeld verhaal Ik snap niet helemaal waarom je nou 2 email domeinen (en dus 2 Exchange omgevingen) op deze manier aan elkaar knoopt? Mis ik iets over root en child domains? In dat geval, waar zit de root? Is het niet eleganter om het geheel uit elkaar te splitsen? Is dit ook van toepassing: http://blogs.technet.com/...erview.aspx?wa=wsignin1.0

[Jazzy]

Wat is dit nu eigenlijk, is dit een setup.com /hosting installatie of een normale installatie?

[Verwijderd]

Het is een /hosting installatie. Het probleem is hier inderdaad dat veel te complex wordt. Er zijn dingen belooft ( door de sales ) geweest aan de partner voor we zelf volledig met de installatie compleet waren, waardoor er nu dus bepaalde 'onmogelijke' constructies gemaakt moeten worden.

De volledige exchange installatie is één domein, maar moet als toegankelijking zijn als twee onafhankelijk 'producten' naar buiten gebracht worden, zodat je het ene niet kun koppelen naar het andere. Ik heb er al enkele dingen kunnen doorkrijgen zodat het iets doenbaarder is om te werken.

Maar het probleem nu komt er gewoon op neer dat ik verschillende autodiscover setting moeten kunnen doorgeven afhankelijk van de CAS-Array die antwoord. Het klinkt niet logisch, maar het is voorlopig de enigste oplossing.

Op dit moment heb ik de volgende 'tijdelijke' oplossing:

code:

[PS] C:\Users\...\Desktop>Get-OutlookProvider

Name      Server               CertPrincipalName             TTL
----      ------               -----------------             ---
EXCH                                                           1
EXPR                           none                            1
WEB

Dit zorgt ervoor dat geen mutual string meegegeven wordt, maar ik zou een andere oplossing willen die het toch mogelijk maakt om de string door te geven.

wagenveld schreef op maandag 21 november 2011 @ 21:10:
Het zal wel aan mij liggen, maar het is nogal een ingewikkeld verhaal Ik snap niet helemaal waarom je nou 2 email domeinen (en dus 2 Exchange omgevingen) op deze manier aan elkaar knoopt? Mis ik iets over root en child domains? In dat geval, waar zit de root? Is het niet eleganter om het geheel uit elkaar te splitsen? Is dit ook van toepassing: http://blogs.technet.com/...erview.aspx?wa=wsignin1.0

Het zou stukken gemakkelijker zijn om dit uit elkaar te halen, maar dit is geen optie... ( jammer genoeg )

[ Voor 20% gewijzigd door Verwijderd op 22-11-2011 20:51 ]

[Jazzy]

Wat zegt je control panel leverancier er van eigenlijk? Die zou ik er in deze fase wel bij betrekken want wat je moet doen nu is zeer ongebruikelijk. Vraag me af hoe dat straks gaat werken als er mailboxen op moeten komen.

[Verwijderd]

Even los van je probleem:

/hosting mode will be supported through the standard support lifecycle for Exchange 2010. It will still be available in SP2 and any future service packs or roll-ups. No additional functionality or features will be added to /hosting mode, however, and we don’t recommend using /hosting mode going forward due to its reduced feature set and the fact that it will add complexity to future upgrades.

http://blogs.technet.com/...ture-of-hosting-mode.aspx

[Verwijderd]

Verwijderd schreef op dinsdag 22 november 2011 @ 21:12:
Even los van je probleem:

/hosting mode will be supported through the standard support lifecycle for Exchange 2010. It will still be available in SP2 and any future service packs or roll-ups. No additional functionality or features will be added to /hosting mode, however, and we don’t recommend using /hosting mode going forward due to its reduced feature set and the fact that it will add complexity to future upgrades.

http://blogs.technet.com/...ture-of-hosting-mode.aspx

Dit is pas een deprimerend bericht ( niets persoonlijks hoor )

In het begin van het jaar, als we gestart zijn met de uitrol van de volledige setup moest alles zo gebeuren. Wij hadden contact gehad met enkele MVP's van Microsoft betreffende dit geval en raden allemaal /hosting aan. Dit was namelijk de enige manier voor het aanbieden van een deftige hosted exchange aan onze klanten. Na uren werk, zoeken en configureren, zijn we aan de eindmeet. En dan lees je dit soort berichten. Vooral deze zin vind ik verbasingwekkend...

Migrating from Exchange 2010 /hosting mode to the on-premises configuration of Exchange (2010 or future versions) will require deployment into a separate forest.

Dat wil zeggen volledig van scratch beginnen. Anders zullen we geen upgrade's meer kunnen uitvoeren.
Nu dat zien we later wel


Ontopic dan

Jazzy schreef op dinsdag 22 november 2011 @ 21:02:
Wat zegt je control panel leverancier er van eigenlijk? Die zou ik er in deze fase wel bij betrekken want wat je moet doen nu is zeer ongebruikelijk. Vraag me af hoe dat straks gaat werken als er mailboxen op moeten komen.

Wat bedoel je met de control panel leverancier? Alles is op dit moment de standaard Exchange installatie zonder 3rd party tools ( willen we liefst zo houden ). Of heb je het hier over onze partner?

[Jazzy]

Verwijderd schreef op woensdag 23 november 2011 @ 09:39:
In het begin van het jaar, als we gestart zijn met de uitrol van de volledige setup moest alles zo gebeuren. Wij hadden contact gehad met enkele MVP's van Microsoft betreffende dit geval en raden allemaal /hosting aan. Wie heb je precies gesproken?

Ik denk dat je wat dingen door elkaar haalt want bij Microsoft werken geen MVP's. In Nederland zijn er drie MVP's voor Exchange Server. Eentje doet voor zover ik weet niets met /hosting, de andere heeft onlangs deze mening gegeven: http://www.uclabs.nl/arch...0-hosting-mode-revisited/ en de derde ben ik.

Wat bedoel je met de control panel leverancier? Alles is op dit moment de standaard Exchange installatie zonder 3rd party tools ( willen we liefst zo houden ).

Een /hosting installatie is vrijwel niet te gebruiken zonder control panel. Als je zometeen een klant krijgt dan moet je een hele serie handelingen uitvoeren in PowerShell om een omgeving met de juiste instellingen voor ze aan te maken. Dat is echt niet te doen zonder control panel.

Het verbaast me wel een beetje dat jullie niet op de hoogte waren van de discussie over /hosting. Microsoft gaat niet door met /hosting en raad iedereen aan om een gewone on-premises installatie op basis van SP2 te doen en dat ABP te gebruiken om een (soort van) multi-tenant constructie op te zetten. En SP2 is al uit voordat jij dit issue met de CAS rol opgelost hebt...

Als ik jou was zou ik niet verder door experimenteren om iets te bouwen waar geen toekomst in zit. Dit http://blogs.technet.com/...for-hosting-exchange.aspx is een goed statement om intern bij jullie de discusie opnieuw te starten.

[Verwijderd]

Jazzy schreef op donderdag 24 november 2011 @ 07:56:
Als ik jou was zou ik niet verder door experimenteren om iets te bouwen waar geen toekomst in zit. Dit http://blogs.technet.com/...for-hosting-exchange.aspx is een goed statement om intern bij jullie de discusie opnieuw te starten.

Bedankt voor alle gegevens. Ik denk inderdaad dat we gaan kijken om te wachten op SP2. Vooral het deel waar staat dat er een framework komt voor het gebruik van het on-premise als hosting. En het eenvoudiger maken van provisioning. Nu is dit een ramp om de provisie door te geven aan personen die dit zouden moeten kunnen, maar geen powershell kunnen. We gaan hier intern nog eens bespreken wat we er verder mee gaan aanvangen.

Alleen al voor het terug beschikbaar zijn van de verloren feature's ( Public Folders, UM, ... ) is het overwegen waard!

Bedankt voor de info! Ik laat anders wel nog eens weten wat we ermee gaan doen

[ Voor 6% gewijzigd door Verwijderd op 24-11-2011 09:58 ]

[Jazzy]

Graag gedaan en hou ons zeker op de hoogte.