SefaUtil Gui v2.1

SefaUtil GUI v2.1 bevat kleine aanpassingen voor issues die gemeld zijn door gebruikers.  In deze versie worden o.a. de volgende problemen verholpen

  • delegates zoeken optie werkt niet correct
  • tijd voordat wordt doorgeschakeld naar een geconfigureerd team werkt niet correct

Mocht je nog een probleem vinden met deze versie van het script laat een comment achter en ik neem contact met je op om te kijken hoe we het probleem kunnen verhelpen.

Download SefaUtil GUI v2.1

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Webnews
  • Y!GG
  • Ask
  • Live-MSN
  • Technorati
  • YahooMyWeb

SefaUtil GUI v2

Met veel genoegen presenteer ik SefaUtil GUI v2. Allereerst wil ik alle beta tester bedanken zij hebben veel waardevolle feedback gegeven en voor zover mogelijk heb ik deze feedback direct verwerkt in deze nieuwe versie.

SefaUtil v2

Maar wat is er allemaal verbeter in deze versie?

SQL querying

Er zijn diverse dingen verbeterd maar de verbetering waar ik het meest trots op ben is de manier hoe data wordt opgehaald. Zoals je misschien wel weet log SefaUtil elke keer in als je een query uitvoert of data wil wijzigen. Op advies van Greig Sheridan heb ik gekeken naar het script van  James Cussen waarin hij SQL gebruikt om informatie op te halen uit de Lync database d.m.v. SQL queries. Hierop gebaseerd ben ik onderzoek gaan doen hoe ik dit ook kon gebruiken. In deze versie worden de huidige instellingen opgehaald d.m.v. SQL queries. Dit zorgt ervoor data de data veel sneller getoond kan worden in de GUI. Het aanpassen van instellingen gebeurd nog steeds door gebruik te maken van SefaUtil.exe

Pool switching

Het wisselen tussen Pools kan nu direct vanuit de GUI uitgevoerd worden. Als een omgeving dus bestaat uit meerdere pools dan is het een kwestie van de correcte pool kiezen om van pool te wijzigen. Hiermee wordt voorkomen dat de tool afgesloten moet worden en vervolgens weer opnieuw opgestart moet worden. Daarnaast worden alleen de gebruikers getoond die gehost zijn op de betreffende pool. De delegates worden nog wel opgehaald door in de hele omgeving te kijken welke gebruikers Enterprise Voice enabled zijn.

Backup en recovery

Een optie om een back up & recovery uit te voeren van SefaUtil maakt het nu mogelijk om settings veilig te stellen. Test deze functionaliteit goed voordat je dit in productie gebruikt. Voor zover ik heb getest werkt deze functionaliteit goed maar ik raad aan de resteren optie eerst in een lab omgeving uit te testen.

Skype for Business support

Skype for Business support is uiteraard ook toegevoegd. Let er op dat dit een aparte versie van SefaUtil.exe vereist

Parameters

Diverse nieuwe parameters zijn toegevoegd:

  • SfB2015: kan gebruikt worden om de standaard locatie voor SefaUtil voor Skype for Business Server 2015 aan te passen
  • Groupiddigits: Kan gebruikt worden om het aantal getallen voor team calls aan te passen incl. #, de standaard waarde is 3
  • Loaddata: kan gebruikt worden om data niet automatisch te laten tijdens het opstarten van de tool

Daarnaast is de code geoptimaliseerd en zijn diverse bugs gefixed.

Net als alle andere software kan het zijn dat er nog problemen optreden ondanks het vele testen. Als je een issue tegenkomt laat dit dan aan me weten zodat we dit issue op kunnen lossen. Hiermee los je niet alleen het probleem op wat je zelf ervaart maar ook het probleem wat andere mensen mogelijk ondervinden.

SefaUtil V2 kan via onderstaande link gedownload worden:

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Webnews
  • Y!GG
  • Ask
  • Live-MSN
  • Technorati
  • YahooMyWeb

Federation altijd leuk zoals je hebt kunnen lezen in mijn vorige blogs. Deze week had een klant in een keer problemen met de Free/busy lookups tussen omgevingen. Dit was niet alleen het geval tussen Exchange omgevingen maar ook Office 365.

Zowel de Outlook logging als event logs op de CAS gaven dezelfde foutmelding. De complete foutmelding is onderstaand weergeven:

Process Microsoft.Exchange.InfoWorker.Common.Delayed`1[System.String]: <johan.veldhuis@domain.com>SMTP:johan.veldhuis@domain.com failed. Exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.AutoDiscoverFailedException: Autodiscover failed for e-mail address <johan.veldhuis@domain.com>SMTP:johan.veldhuis@domain.com with exception System.Web.Services.Protocols.SoapHeaderException: An error occurred when processing the security tokens in the message.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)
   at Microsoft.Exchange.SoapWebClient.AutoDiscover.DefaultBinding_Autodiscover.EndGetUserSettings(IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.UserSoapAutoDiscoverRequest.EndGetSettings(IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.<>c__DisplayClass4.<EndInvoke>b__3()
   at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.ExecuteAndHandleException(ExecuteAndHandleExceptionDelegate operation). —> System.Web.Services.Protocols.SoapHeaderException: An error occurred when processing the security tokens in the message.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)
   at Microsoft.Exchange.SoapWebClient.AutoDiscover.DefaultBinding_Autodiscover.EndGetUserSettings(IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.UserSoapAutoDiscoverRequest.EndGetSettings(IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.<>c__DisplayClass4.<EndInvoke>b__3()
   at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.ExecuteAndHandleException(ExecuteAndHandleExceptionDelegate operation)
   — End of inner exception stack trace —
. Name of the server where exception originated: EXC01. This event may occur when Availability Service cannot discover an Availability Service in the remote forest.

Het gemarkeerde deel geeft de foutmelding aan in dit geval An error occurred when processing the security tokens in the message. Deze foutmelding verteld je dat er problemen zijn met de security token die de server heft ontvangen van de Microsoft Federation Gateway. Dus zal dit vast niet de enige klant zijn die deze problemen heeft.

Microsoft heeft erkend dat er problemen zijn geweest eerder deze week die niet alleen effect hadden op deze functionaliteit maar ook op sommige Office 365 services.

Office 365 status

Op dit moment is er een work around beschikbaar om het probleem op te lossen. Om het probleem op te lossen dient de metadata gerefreshed te worden van de federation trust. Dit kan gedaan worden door gebruik te maken van de volgende Powershell cmdlets:

Get-Federationtrust|Set-Federationtrust -Refreshmetadata

Het is belangrijk om te weten dat dit cmdlet aan beide kanten uitgevoerd moet worden om het probleem op te lossen anders is het mogelijk niet opgelost. Wanneer eenmaal het cmdlet is uitgevoerd kan het enige tijd duren voordat de free/busy lookups weer gaan werken.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Webnews
  • Y!GG
  • Ask
  • Live-MSN
  • Technorati
  • YahooMyWeb

Relinquishing job because the mailbox is locked

Tijdens een migratie naar Office 365 liep ik tegen het volgende problem aan. De mailbox migratie warden regelmatig gestaakt met in de log de volgende melding Relinquishing job because the mailbox is locked. De ene keer was dit slechts voor enkele minute de andere keer leek de mailbox niet meer uit deze fase te komen.

12/20/2013 9:24:08 AM [DB4PR04MB459] The Microsoft Exchange Mailbox Replication service ‘DB4PR04MB459.eurprd04.prod.outlook.com’ (15.0.842.8 caps:01FF) is examining the request.
12/20/2013 9:24:09 AM [DB4PR04MB459] Connected to target mailbox ‘Primary (4ca8eac9-f378-4e82-8d07-f984c64176e8)’, database ‘EURPR04DG029-db041’, Mailbox server ‘DB4PR04MB459.eurprd04.prod.outlook.com’ Version 15.0 (Build 842.0).
12/20/2013 9:24:09 AM [DB4PR04MB459] Connected to target mailbox ‘Archive (07121074-d871-4db9-9f4e-153010131a50)’, database ‘EURPR04DG029-db041’, Mailbox server ‘DB4PR04MB459.eurprd04.prod.outlook.com’ Version 15.0 (Build 842.0).
12/20/2013 9:24:14 AM [DB4PR04MB459] Connected to source mailbox ‘Primary (4ca8eac9-f378-4e82-8d07-f984c64176e8)’, database ‘MB_Others’, Mailbox server ‘CAS02.corp.local’ Version 14.3 (Build 158.0), proxy server ‘CAS01.corp.local’ 14.3.151.0 caps:05FFFF.
12/20/2013 9:24:15 AM [DB4PR04MB459] Connected to source mailbox ‘Archive (07121074-d871-4db9-9f4e-153010131a50)’, database ‘MB_Archives_Large’, Mailbox server ‘CAS02.corp.local’ Version 14.3 (Build 158.0), proxy server ‘CAS01.corp.local’ 14.3.151.0 caps:05FFFF.
12/20/2013 9:24:15 AM [DB4PR04MB459] Relinquishing job because the mailbox is locked. The job will attempt to continue again after 12/20/2013 9:29:15 AM.

Als je op Google gaat zoeken kom je diverse tips tegen maar over het algemeen allemaal wijzend naar TMG of een Firewall welke de vele verzoeken van Office 365 als mogelijk onveilig verkeer ziet en daardoor dit verkeer blokkeerd. Microsoft zelf heeft hier al een Knowledge base artikel voor gepubliceerd wat je hier terug kan vinden.

De oplossing die wordt aangedragen door Microsoft is het verhogen van de Custom Limit in de Flood Mitigation Settings. Microsoft geeft aan deze te verhogen naar een hoger getal en dit te doen afhankelijk van het aantal mailboxen wat tegelijkertijd wordt gemigreerd.

TMG Flood Migration settings

Natuurlijk is deze oplossing wel aardig maar vereist dit misschien wel meerdere keren het aanpassen van de waarde. Daarnaast heeft deze waarde gevolgen voor alle IP adressen die verbinding maken dus ook kwaadwillende gebruikers. Er is vast wel een mooiere oplossing.  De oplossing zit hem in het niet toepassen van de Flood mitigation functionaliteit op IP adressen van Office 365.

Om dit te configuren is het verstandig een computer groep aan te maken met alle losse IP-adressen en subnets die gebruikt worden door Office 365. In onderstaande afbeelding is hier een voorbeeld van te zien.

Floot Mitigation - IP Exceptions

Voor een complete overzicht van IP-adressen die door Office 365 gebruikt worden kun je terecht op de volgende pagina’s:

Exchange Online Protection IP addresses
Office 365 URLs and IP address ranges

Het advies is om beide pagina’s te bekijken en de benodigde IP-adressen en subnets aan de computer groep toe te voegen. Zodra de groep is aangemaakt kun je op de IP Exceptions tab de groep toevoegen, Wanneer je de configuratie het geactiveerd in TMG zal je zien dat de migratie activiteiten weer op gang komen en niet elke keer worden gestopt. Dit laatste heeft uiteindelijk dus ook als voordeel dat de migratie van een mailbox sneller kan worden afgerond.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Webnews
  • Y!GG
  • Ask
  • Live-MSN
  • Technorati
  • YahooMyWeb

In de eerste twee delen van deze blog serie over het troubleshooten van federated sharing hebben we gekeken naar de infrastructuur en configuratie die vereist is. Daarnaast hebben we wat basis troubleshooting gedaan op de diverse componenten die betrokken zijn bij federated sharing. In dit deel kijken we naar enkele voorbeelden die ik ben tegengekomen tijdens het troubleshooten van federated sharing issues.

Onderstaand un je een voorbeeld zien van een foutmelding dit optreed tijdens het ophalen van de free/busy informative van een gebruiker in een andere Exchange omgeving.

Process 1212: ProxyWebRequest FederatedCrossForest from S-1-5-21-1671710892-3805255249-3875359145-102309 to https://mail.domain.com/ews/exchange.asmx/WSSecurity failed. Caller SIDs: WSSecurity. The exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestProcessingException: System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

   at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)

   at System.Net.PooledStream.EndWrite(IAsyncResult asyncResult)

   at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)

   — End of inner exception stack trace —

   at System.Web.Services.Protocols.WebClientAsyncResult.WaitForResponse()

   at System.Web.Services.Protocols.WebClientProtocol.EndSend(IAsyncResult asyncResult, Object& internalAsyncState, Stream& responseStream)

   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.Proxy.Service.EndGetUserAvailability(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.FreeBusyApplication.EndProxyWebRequest(ProxyWebRequest proxyWebRequest, QueryList queryList, Service service, IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequest.EndInvoke(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.AsyncWebRequest.EndInvokeWithErrorHandling():. The request information is ProxyWebRequest type = FederatedCrossForest, url = https://mail.domain.com/ews/exchange.asmx/WSSecurity

Mailbox list = <Johan@domain.com>SMTP:Johan@domain.com, Parameters: windowStart = 10/1/2013 10:00:00 AM, windowEnd = 10/31/2013 10:00:00 AM, MergedFBInterval = 30, RequestedView = Detailed

. —> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

   at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)

   at System.Net.PooledStream.EndWrite(IAsyncResult asyncResult)

   at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)

   — End of inner exception stack trace —

   at System.Web.Services.Protocols.WebClientAsyncResult.WaitForResponse()

   at System.Web.Services.Protocols.WebClientProtocol.EndSend(IAsyncResult asyncResult, Object& internalAsyncState, Stream& responseStream)

   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.Proxy.Service.EndGetUserAvailability(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.FreeBusyApplication.EndProxyWebRequest(ProxyWebRequest proxyWebRequest, QueryList queryList, Service service, IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequest.EndInvoke(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.AsyncWebRequest.EndInvokeWithErrorHandling()

   — End of inner exception stack trace —

. Name of the server where exception originated:CAS01. Make sure that the Active Directory site/forest that contain the user’s mailbox has at least one local Exchange 2010 server running the Availability service. Turn up logging for the Availability service and test basic network connectivity.

Wanneer je naar de gemarkeerde regels kijkt in de text zie het de oorzaak van het problem al, een certificaat probleem. Maar hoe kun je dit nou het beste aanpakken? De eerste stap is om te kijken of je de Exchange Web Services van de andere Exchange omgeving kunt benaderen. In dit geval kan dat gedaan worden door met een web browser te gaan naar https://mail.domain/com/ews/exchange.asmx/WSSecurity het resultaat zal waarschijnlijk een certificaat waarschuwing zijn. En dat is ook exact de oorzaak waardoor dit problem wordt veroorzaakt. Het certificaat van de andere Exchange omgeving is niet geldig volgens de richtlijnen die hiervoor zijn. Als je de pagina echter opent in een webbrowser zie je ook waarom het certificaat niet vertrouwd wordt. Dit kan door diverse dingen worden veroorzaakt:

  • Certificaat is uitgegeven door een niet vertrouwde root CA
  • Naam op het certificaat is niet correct

In dit geval bleek het certificaat uitgegeven te zijn door een niet vertrouwede root CA. Door het root CA certificaat te importeren in de Enterprise Trusted Root folder van de CAS was het problem opgelost.

Het tweede voorbeeld was iets lastiger te troubleshooten maar de uiteindelijke oplossing was redelijk eenvoudig. Ook hier is de foutmelding weer gemarkeerd.

Process 1212: ProxyWebRequest FederatedCrossForest from S-1-5-21-1671710892-3805255249-3875359145-102309 to https://mail.domain.com/ews/exchange.asmx/WSSecurity failed. Caller SIDs: WSSecurity. The exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestProcessingException: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. —> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. —> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host

   at System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult)

   at System.Net.Sockets.NetworkStream.EndRead(IAsyncResult asyncResult)

   — End of inner exception stack trace —

   at System.Net.Security._SslStream.EndRead(IAsyncResult asyncResult)

   at System.Net.TlsStream.EndRead(IAsyncResult asyncResult)

   at System.Net.PooledStream.EndRead(IAsyncResult asyncResult)

   at System.Net.Connection.ReadCallback(IAsyncResult asyncResult)

   — End of inner exception stack trace —

   at System.Web.Services.Protocols.WebClientAsyncResult.WaitForResponse()

   at System.Web.Services.Protocols.WebClientProtocol.EndSend(IAsyncResult asyncResult, Object& internalAsyncState, Stream& responseStream)

   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.Proxy.Service.EndGetUserAvailability(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.FreeBusyApplication.EndProxyWebRequest(ProxyWebRequest proxyWebRequest, QueryList queryList, Service service, IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequest.EndInvoke(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.AsyncWebRequest.EndInvokeWithErrorHandling():. The request information is ProxyWebRequest type = FederatedCrossForest, url = https://mail.domain.com/ews/exchange.asmx/WSSecurity

Mailbox list = <Johan@domain.com>SMTP:Johan@domain.com, Parameters: windowStart = 9/29/2013 12:00:00 AM, windowEnd = 11/10/2013 12:00:00 AM, MergedFBInterval = 30, RequestedView = MergedOnly

. —> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. —> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. —> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host

   at System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult)

   at System.Net.Sockets.NetworkStream.EndRead(IAsyncResult asyncResult)

   — End of inner exception stack trace —

   at System.Net.Security._SslStream.EndRead(IAsyncResult asyncResult)

   at System.Net.TlsStream.EndRead(IAsyncResult asyncResult)

   at System.Net.PooledStream.EndRead(IAsyncResult asyncResult)

   at System.Net.Connection.ReadCallback(IAsyncResult asyncResult)

   — End of inner exception stack trace —

   at System.Web.Services.Protocols.WebClientAsyncResult.WaitForResponse()

   at System.Web.Services.Protocols.WebClientProtocol.EndSend(IAsyncResult asyncResult, Object& internalAsyncState, Stream& responseStream)

   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.Proxy.Service.EndGetUserAvailability(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.FreeBusyApplication.EndProxyWebRequest(ProxyWebRequest proxyWebRequest, QueryList queryList, Service service, IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequest.EndInvoke(IAsyncResult asyncResult)

   at Microsoft.Exchange.InfoWorker.Common.Availability.AsyncWebRequest.EndInvokeWithErrorHandling()

   — End of inner exception stack trace —

. Name of the server where exception originated: CAS01. Make sure that the Active Directory site/forest that contain the user’s mailbox has at least one local Exchange 2010 server running the Availability service. Turn up logging for the Availability service and test basic network connectivity.

De foutmelding verteld ons dat de connective is afgebroken door de andere kant. OK leuk maar wat nu? In dit geval geval kun je gaan kijken naar de IIS logs op de CAS van de andere Exchange omgeving om te kijken wat er gebeurd als het verkeer wordt aangeboden op de CAS.

Zoek voor verkeer dat als doel heel /ews/exchange.asmx/WSSecurity en waarschijnlijk zal je de foutmelding terugvinden. Normaal zal je zien dat aan het eind van de regel een 200 wordt weergeven. Als het echter niet werkt zal deze 200 niet zichtbaar zijn maar zie je bijvoorbeeld een 4xx fout. Wanneer dit het geval is controleer dan nogmaals de federatie met de Microsoft Federation Gateway zoals in deel 1 uitgelegd.

Maar er kunnen ook nog andere foutmelding verschijnen, bijvoorbeeld 500. Dit betekend dat de CAS niet weet hoe hij moet omgaan met het verkeer en daarom de connectie afsluit. Wanneer dit gebeurd is het van belang te controleren oe WSSecurity is ingeschakeld als authenticatie method voor Autodiscover en EWS. Wanneer dit het geval is controleer dan of de svc-integrated handler is toegewezen aan zowel de Autodiscover en EWS virtual directory. Wanneer dit ook goed geconfigureerd is zou alles moeten werken, maar waarom werkt het dan toch niet?

In sommige gevallen pakt IIS het inschakelen van  EWSSecurity niet goed op. Wanneer dit gebeurd dient je een iisreset uit te voeren om zal je hoogstwaarschijnlijk de free/busy van de andere Exchange omgeving wel kunnen zien.

Hier eindigt de blog serie over het troubleshooten van federated sharing. Ik ben me er van bewust dat er mogelijk andere oplossingen zijn om federated sharing problemen op te lossen maar dit zijn slechts twee voorbeelden van problemen die ik en tegengekomen.

Ik hoop dat je wat hebt kunnen leren van deze serie en mocht je vragen hebben neem dan contact met mij op via het contact formulier of door een comment te schrijven onder deze post.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Webnews
  • Y!GG
  • Ask
  • Live-MSN
  • Technorati
  • YahooMyWeb

Cover

Het is al een tijdje geleden dat ik dit boek heb ontvangen voor een review, initieel ben ik begonnen met het lezen van dit boek toen ik onderweg was naar Exchange Connections in Las Vegas op mijn iPad mini. De laatste paar weken heb ik de overige hoofdstuken gelezen. Maar wat denk ik van het boek? Het boek is een naslagwerk voor iedereen die werkt met Exchange 2013. Tony Redmond beschrijft diverse Exchange componenten gerelateerd aan mailbox en high availability in detail. Ja je leest het goed het boek gaat alleen maar over mailbox en high availability van Exchange 2013. Voor Client Access, Connectivity en het UM deel van Exchange 2013 zal je het boek van Paul Robichaux moeten lezen.

Tony begint met het beschrijven van diverse belangrijke dingen waar je over na moet denken als je overweegt om Exchange 2013 te gaan implementeren. Dit begint met een discussie over de architectuur en vervolgt met een aantal belangrijke beslispunten die genomen moeten worden voordat je Exchange 2013 gaat implementeren. Daarna vervolgt hij met het beschrijven van de voorbereidingen die genomen moeten worden voordat je Exchange 2013 gaat implementeren. Na deze onderwerpen beschrijft Tony het installatie process en de basis management tools die je kunt gebruiken om Exchange 2013 te beheren met zeer gedetaileerd het beheren van mailboxen.

Vanaf hoofdstuk 8 maakt het boek een diepe duik. Voor degene die al bekend zijn met Exchange 2013 en de basis willen overslaan is dit het hoofdstuk om te beginnen met lezen. Zeer gedetaileerd beschrijft Tony diverse componenten waaronder:

  • how does the store work
  • the database availability group
  • migrating mailboxes
  • compliance management
  • public folders and site mailboxes

In bijvoorbeeld het hoofdstuk how does the store work wordt beschreven hoe het store process er onder de motorkap uitziet. Wanneer je dit hoofdstuk hebt gelezen begrijp je waarschijnlijk beter hoe het store process werkt en hoe complex het product Exchange eigenlijk is. Nadat het store process is besproken gaat het boek verder met het beschrijven van de database availability group. In dit hoodstuk beschrijft Tony onderwerpen die gerelateerd zijn aan de DAG waaronder: het ontwerpen, dagelijks beheer en diverse andere belangrijke componenten van de DAG waaronder de active manager.

Nadat het mailbox en high availability deel zijn besproken gaat het boek verder met het mailbox migratie process. In dit deel worden de componenten besproken die van belang zijn voor tijdens het migratie process en natuurlijk hoe je een migratie uit kan voeren. Dit is niet gelimiteerd tot het beschrijven van de cmdlets maar bevat ook practische tips van Tony over het plannen van een migratie.

Sommige mensen werken misschien al met het compliance deel van Exchange en andere hebben het misschien nog nooit aangeraakt. Beide groepen zullen profiteren van het hoofdstuk omdat het een aantal basis dingen begrijpt maar met dusdanig veel detail dat iedereen wat kan leren tijdens het lezen van dit hoofdstuk. Compliance is een onderwerp wat steeds belangrijker wordt vandaag de dag steeds meer bedrijven beginnen met het implementeren er van door regels van het bedrijf zelf of de overhead.

In het laatste hoofdstuk van het boek beschrijft Tony het onderwerp van Exchange waarover het meest wordt gediscusieerd. Zit het er nog in in de volgende versie? Hoelang blijft Microsoft nog Public Folders ondersteunen? Dit zijn slechts een paar vragen die elke keer naar boven komen tijdens de ontwikkeling van de nieuwe versie van Exchange. In Exchange 2013 is er veel verandert aan de Public Folders dit omdat de Public Folders nu een special soort mailbox zijn en geen aparte public folder database meer nodig is. Maar hoe kom je van de “legacy” Public Folder naar de “new” Public Folder. Lees Tony’s boek en je hebt een hoop informatie hoe dit te doen.

Maar wat is de conclusive van deze review? Het boek is een must read voor iedereen die werkt met Exchange. Het bevat niet alleen de basis informatie zoals de meeste boeken bevatten maar is zeer gedetailleerd. Daarnaast geeft Tony extra informatie wat extra informatie toevoegd aan het boek.

Dus als je nieuwsgierig bent geworden druk op onderstaande link om het boek te kopen:

Buy Microsoft Exchange Server 2013 Inside Out: Mailbox and High Availability

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Webnews
  • Y!GG
  • Ask
  • Live-MSN
  • Technorati
  • YahooMyWeb

Troubleshooting federated sharing – deel II

In het eerste deel van de blog serie over het troubleshooten van federated sharing hebben we gekeken naar de server kant. We hebben besproken welke parameter gecontroleerd moeten worden en eventueel aangepast dienen te worden.

De reis gaat verder in dit tweede deel. In dit deel zullen we kijken naar de reverse proxy gevolgd door het client deel.

Laten we beginnen met het reverse proxy deel.

Omdat je niet wil dat je Exchange omgeving direct benaderbaar is vanaf het internet besluiten veel organisaties een reverse proxy te gebruiken om hun Exchange omgeving the “publiceren”. Dit kan gedaan worden door gebruik te maken van Microsoft producten zoals TMG or ARR. De eerste oplossing zal binnenkort end-of-support worden dus wanneer je nu nog begint met een implementatie kies dan voor ARR of een 3rd party oplossing. Wanneer we kijken naar de 3rd party oplossingen dan zijn er aardig wat oplossingen die gebruikt kunnen worden. Bijvoorbeeld Bluecoat, Kemp Technologies en F5 bieden producten aan die over deze functionaliteit beschikken.

Maar wat voor problemen kun je verwachten wanneer je een reverse proxy gebruikt om je Exchange omgeving te publiceren? De problemen die je kunt ondervinden zijn er diverse waaronder:

  • Authentication problemen
  • Name resolving problemen
  • Routing problemen

Dit zijn slechts drie soorten problemen die je kunt ondervinden wanneer je gebruik maakt van een reverse proxy. Maar ik weet zeker dat er nog veel meer zijn. In deze blog concentreren we ons op de authenticatie problemen. De reden hiervoor is dat het zeer waarschijnlijk is dat je tegen dit soort problemen op gaat lopen in je reis voor het configureren van federated sharing.

The authentication issue is one of those things you will see a lot. Especially when you are using pre-authentication. Using pre-authentication your session will be authenticated before it is send to the CAS/CAS Array which is located behind the firewall.

Voor federated sharing is het nodig dat alle federated sharing sessies door de reverse proxy worden doorgegeven aan de CAS zonder authenticatie uit te voeren. Authenticatie vindt namelijk plaats op de CAS/CAS Array. Een van de dingen die je daarom moet controleren tijdens het maken van de regels voor federated sharing is dat deze boven de bestaande regels worden geplaatst. Zoals al besproken in het eerste deel wordt er gebruik gemaakt van de volgende URL’s:

  • /EWS/Exchange.asmx/WSSecurity
  • /Autodiscover/Autodiscover.svc
  • /Autodiscover/Autodiscover.svc/WSSecurity

Wanneer je TMG gebruikt om deze URL’s te publiceren dient dit gedaan te worden met de volgende configuratie opties:

  • Authentication Delegation: No delegation, but client may authenticate directly
  • Users: all users

De meeste bedrijven gebruiken Form Based Authentication (FBA) om hun Exchange Services te publiceren richting het internet. Wanneer dit het geval is zal de listener aangepast moeten worden. Dit omdat de listener standaard is geconfigureerd om alleen geauthenticeerd verkeer toe te staan voordat er connectie opgezet kan worden.

Maar omdat de authenticatie voor de URL’s voor federated sharing plaatsvind op de CAS dienen we deze specifieke optie uit te schakelen.

Om deze optie uit te schakelen dien je de eigenschappen van de listener op te vragen en de autenticatie tab te selecteren. Open de advanced authentication options door op de knop advanced te drukken en schakel de optie Require all users to authenticate uit.

Wanneer de regels eenmaal zijn geconfigureerd kan het echte werk beginnen. Het kan bijvoorbeeld voorkomen dat verkeer niet door de nieuwe regel wordt afgehandelt. Om dit stuk te monitoren dien je logging in te schakelen op de TMG. Een van de filters die ik vaak gebruik is een filter met de volgende parameters:

  • Filter by: rule
  • Condition: equals
  • Value: naam van de publishing rule die gebruikt wordt voor federated sharing

Nu logging is ingeschakeld is he tijd om wat free/busy verkeer te genereren vanuit een andere Exchange organisatie of Office 365. Wanneer de regel op de correcte plaatst staat zal je zien dat er verkeer wordt gelogd.

Wanneer je geen verkeer ziet dan wordt dit verkeer dus door een andere regel afgehandeld. In dit geval is het verstandig om alle parameters nogmaals te controleren en opnieuw een test uit te voeren. In sommige gevallen kan het voorkomen dat het een aantal minute duurt voordat de TMG de nieuwe configuratie heft opgepakt wacht dus een paar minuten als het fout gaat en probeer het dan nogmaals.

Een ander problem wat je vaak terug zal zien is een authenticatie issue in de TMG log. Dit zullen in de meeste gevallen 401.x en 403.x errors zijn. In dit geval is het verstandig om te controleren of je de volgende sites kunt openen met een web browser:

Wanneer er een formulier getoond wordt controleer dan nogmaals de delegations settings op de rule en de authenticatie instellingen op de listener.

OK genoeg over de TMG laten we kijken naar de client kant. Standaard is logging in Outlook uitgeschakeld voor troubleshooting. Dus voordat je gaat troubleshooten dien je de logging in te schakelen. Microsoft heeft een knowledge base artikel gepubliceerd waarin beschreven wordt hoe troubleshooting logging ingeschakeld kan worden, dit artikel kun je hier vinden.

Wanneer je het problem hebt gereproduceerd is het tijd om de logging te onderzoeken. Afhankelijk van welke Outlook versie je gebruikt is de log file in een andere locatie geplaatst. Onderstaand een overzicht van de Outlook versie, log locatie en log bestandsnaam:

Versie Locatie Bestandsnaam
Outlook 2007 %temp%\OLKas date-time -fb.log
Outlook 2010 %temp%\OLKas date-time -AS.log
Outlook 2013 %temp%\Outlook logging Outlook-########.etl

Dus wanneer je Outlook 2007/2010 gebruikt kun je de logs zelf onderzoeken. Wanneer je gebruik maakt van Outlook 2013 zal je etl bestand naar Microsoft support op moeten sturen voor onderzoek.

Onderstaande een voorbeeld van een log bestand gemaakt met Outlook 2010 laten we dit eens analyseren:

Eerst zal Outlook de URL van de availability service gaan bepalen. Outlook gebruikt hiervoov autodiscover.

2013/09/25 11:38:40.041: Getting ASURL

Zoals je kunt zien weet Outlook de URL al vanwege een voorgaand autodiscover request:

2013/09/25 11:38:40.041: URL returned from cached autodiscover: https://mail.domain.com/ews/exchange.asmx

De URL in de cache is de URL die gebruikt zal worden om het verzoek naar toe te sturen:

2013/09/25 11:38:40.041: Request to URL: https://mail.domain.com/ews/exchange.asmx

De volgende stap is het verzenden van het verzoek en wordt verzondern als XML naar de target CAS. Zoals je kunt zien is dit een XML request voor de beschikbaarheid van een specifiek person:

2013/09/25 11:38:40.041: Request action: http://schemas.microsoft.com/exchange/services/2006/messages/GetUserAvailability

Wanneer het type request eenmaal is bepaald kunnen de parameers opgegeven worden in de body. Je zal hier de volgende parameters terugzien voor ieder free/busy request:

  • ex12t:Timezone: de tijdzone die gebruikt wordt, in dit geval: 60
  • ex12t:StandardTime: de standaard tijd die gebruikt wordt in het request, ik vermoed dat als een gebruiker geen specifieke tijd opgeeft deze waarde wordt gebruikt
  • ex12t:Time: de standaard tijd die wordt gebruikt om de beschikbaarheid te controleren, in dit geval 03:00:00
  • ex12t:DayOrder: de standaard dag(datum) die gebruikt wordt, in dit geval  5
  • ex12t:Month: de standaard maand, in dit geval 3
  • ex12t:DayOfWeek: de standaard dag waarvoor de beschikbaarheid gecontroleerd dient te worden, in dit geval zondag
  • ex12t:DaylightTime: deze parameter heb ik niet kunnen achterhalen maar het lijkt erop dat dit met zomer/wintertijd te maken heeft
  • ex12t:Address: het smtp adres van de gebruiker waarvan de de beschikbaarheid willen weten, in dit geval johan@johanveldhuis.nl
  • ex12Routingtype: de transport method die gebruikt wordt om het uiteindelijke verzoek te versturen wanneer je op de verzenden knop drukt en de CAS dit bericht zal afleveren in de mailbox van de gebruiker, in dit geval smtp
  • ex12t:AttendeeType: het type attendee, dit kan required of optioneel zijn, in dit geval required
  • ex12t:FreeBusyViewOptions: bevat de specifieke meeting details
  • ex12t:Starttime: de start tijd van de meeting: in dit geval 2013-09-09T18:00:00
  • ex12t:Endtime: de eind tijd van de meeting: in dit geval 2013-10-09T18:00:00
  • ex12t:MergedFreeBusyIntervalInMinutes: de intervallen waarvoor de beschikbaarheid gecontroleerd moet worden dit is standaard elke 30 minuten
  • ex12t:RequestedView: welke informative moet opgehaald worden van de gebruiker, in dit geval detailed

request

Nu de XML is gegenreerd is het tijd om het uiteindelijke verzoek te versturen:

2013/09/25 11:38:40.041: Sending request

Vervolgens zullen we een antwoord ontvangen waarmee we kunnen bepalen of het request succesvol is verstuurd of niet. In dit geval verteld de HTTP status code ons dat het bericht succesvol is afgeleverd:

2013/09/25 11:38:44.135: Request sent
2013/09/25 11:38:44.135: Response error code: 00000000
2013/09/25 11:38:44.135: HTTP status code: 200

Wanneer het request eenmaal is verzonden zal er ook een antwoord komen van de CAS server dat het verzoek wordt gerouteerd naar de target CAS. Dit begint met wat standaard XML informative die je meer informatie geeft over de server versie. Dit is het versienummer van onze CAS. In dit geval kunnen we zien dat dit Exchange 2010 SP3 is.

2013/09/25 11:38:44.135: XML response:

De volgende informatie bevat het uiteindelijke antwoord wat de source CAS heeft ontvangen van de remote CAS. Dit onderdeel start met FreeBusyResponseArray wat het onderdeel ResponseMessage bevat. Zoals je kunt zien treed er een security problem op. Dit voorkomt dat Outlook de free/busy informatie van de andere gebruiker ontvangt.

Nadat we dit bericht hebben ontvangen volgt er nog wat meer gedetaileerde informatie waarin gezien kan worden welk request wordt verstuurd van de source CAS naar de target CAS.

response

In het laatste deel is ook de uiteindelijke foutmelding terug te zien en van welke CAS deze informatie wordt ontvangen. In dit geval error 516 van CAS02. Outlook zal deze foutmelding weergeven als 5016 wanneer je met de muis over de gestreepte free/busy informatie van de specifieke gebruiker zal gaan.

Hier eindigt het tweede deel in de blog series over het troubleshooten van federated sharing. In dit deel hebben we gekeken naar de eisen die gesteld worden aan de reverse proxy configuratie en hebben we een aantal basis troubleshooting stappen besproken. Vervolgens zijn we verder gegaan met het troubleshooten vanaf de client kant.

In het derde en laatste deel van dit artikel zullen we een aantal problemen bespreken die ik zelf ben tegen gekomen tijdens het configureren van federated sharing.

Wanneer je commentaar/vragen hebt laat het met gerust .

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Webnews
  • Y!GG
  • Ask
  • Live-MSN
  • Technorati
  • YahooMyWeb

Door gebruik te maken van federated sharing is het mogelijk om o.a. agenda informatie te delen tussen verschillende Exchange organisaties. Hierbij kan gebruik gemaakt worden van de Microsoft Federation Gateway (MSFG) wanneer er geen directe trust tussen de Active Directories mogelijk is. De MSFG is dan verantwoordelijk voor het uitgeven van een ticket t.b.v. authenticatie. Door gebruik te maken van dit ticket kan de CAS vervolgens contact opnemen met de CAS Server van de andere organisatie om zo de free/busy informative op te halen.

Om dit te laten functioneren zijn er een aantal zaken die ingeregeld moeten zijn:

  • trust met de Microsoft Federation Gateway
  • organizational relationship moet geconfigureerd zijn
  • autodiscover en EWS moeten geconfigureerd zijn om WS authenticatie toe te staan
  • de reverse proxy moet ongeauthenticeerd verkeerd toestaan voor de volgende url’s:
    • /EWS/exchange.asmx/WSSecurity
    • /autodiscover/autodiscover.svc/WSSecurity
    • /autodiscover/autodiscover.svc

Een aantal sites met een stappenplan om dit te configureren vindt je aan het eind van dit artikel.

Zodra dit is ingeregeld zou alles moeten functioneren, inderdaad zou. In veel gevallen zal dit ook zo zijn echter soms loop je ook weleens tegen wat problemen op. In deze blog reeks kijken we hoe je het e.e.a. kunt valideren en troubleshooten mocht je dan tegen problemen aanlopen dan kun je in ieder geval deze tips gebruiken.

Maar hoe kun je dit soort problemen troubleshooten? Ten eerste is het handig als je een contactpersoon hebt die toegang heeft tot de andere Exchange organisatie. In veel gevallen zal dit niet een probleem zijn echter maak je gebruikt van Office 365 of een andere hosting vorm dan kan dit weleens lastig zijn.

Het meest handig is om eerst de Exchange omgeving zelf te controleren. Hierbij kan gedacht worden aan de volgende dingen:

  • controleer of autodiscover WS Security als authenticatie toestaat
  • controleer de externe EWS url
  • controleer of Exchange Web Services WS Security als authenticatie toestaat

Als je over meerdere Client Access Servers (CAS) beschikt dan is Powershell je vriend en kun je dit via een aantal cmdlet’s snel controleren:

Get-AutodiscoverVirtualDirectory|select server, WSSecurityAuthentication

Get-AutodiscoverVirtualDirectory

Je zal dan bovenstaande output ontvangen. Controleer hierbij of de waarde in de kolom WSSecurityAuthentication op true staat.

Mocht WSSecurity om e.o.a. reden niet op true staan voer dan het volgende cmdlet uit:

Get-AutodiscoverVirtualDirectory|Set-AutodiscoverVirtualDirectory -WSSecurityAuthentication:$true

Hiermee wordt de authenticatie method geconfigureerd echter is wel een IISReset vereist om dit ook daadwerkelijk te activeren. Additioneel kan gecontroleerd worden of de svc-integrated handler gekoppeld is aan de autodiscover virtual directory:

IIS

De volgende stap is het controleren van de Exchange Web Services hierbij kan gebruik gemaakt worden van Get-WebServicesVirtualDirectory:

Get-WebServicesVirtualDirectory|select server, ExternalUrl, WSSecurityAuthentication

Get-WebServicesVirtualDirectory

Hiervoor geld wederom  dat de waarde van de WSSecurityAuthentication kolom op true moet staan. Daarnaast dient de waarde van de kolom ExternalUrl een correcte waarde te bevatten. Deze url dient vanaf het internet toegankelijk te zijn. Is dit niet het geval dan zal het e.e.a. niet werken.

Mocht WSSecurity om e.o.a. reden niet op true staan voer dan het volgende cmdlet uit:

Get-WebServicesVirtualDirectory|Set-WebServicesVirtualDirectory -WSSecurityAuthentication:$true

Net als voor autodiscover geld hier dat een IISReset noodzakelijk is om de authenticatie methode te activeren. Controleer daarnaast of de ws-security handler voor de EWS virtual directory aanwezig is.

Mocht er geen externe url geconfigureerd zijn dan dient dit ook aangepast te worden. Echter voordat je dit gaat doen is het van belang om ervoor te zorgen dat het certificaat de correcte namen bevat. Configureer je namelijk een url hierop die niet op het certificaat voorkomt dan zal dit niet gaan werken en foutmeldingen opleveren.

Om te controleren of het certificaat de juiste names bevat kun je wederom gebruik maken van Powershell:

Get-ExchangeCertificate|? {$_.Services -like “*IIS*”}|select Subject, CertificateDomains|FL

Hierbij dient de waarde van CertificateDomains de FQDN te bevatten die voor EWS wordt gebruikt, bijvoorbeeld mail.domain.com of ews.domain.com. Komt deze naam er niet op voor dan dient het certificaat vervangen te worden door een certificaat waar deze FQDN wel op voorkomt.

Is het certificaat in orde dan kan de Externe URL geconfigureerd worden:

Get-WebServicerVirtualDirectory|Set-WebServicesVirtualDirectory -Externalurl “https://ews.domain.com/EWS/exchange.asmx”

Met bovenstaande cmdlet worden op alle Client Access Servers de externe url’s hetzelfde geconfigureerd. LET OP: in sommige scenarios is dit niet de bedoeling. Zorg ervoor dat je dit van te voren controleerd voordat je de externe url overall hetzelfde configureerd.

Wanneer dit is geconfigureerd is het tijd om de Federation Trust en de Organization RelationShip te controleren.

D.m.v. het test-FederationTrustCertificate kan gecontroleerd worden of het certificaat wat gebruikt wordt goed is en overall is geïnstalleerd. Tijdens het aanmaken van een trust wordt namelijk een self-signed certificaat geïnstalleerd op alle Client Access Servers in de omgeving. Het kan weleens voorkomen dat een certificaat niet op alle servers geïnstalleerd wordt. In dat geval zal de betreffende CAS zich niet kunnen authenticeren tegen de Federation Gateway van Microsoft waardoor ook het autodiscover proces mislukt.

Test-FederationTrustCertificate

Test-FederationTrustCertificate

Controleer hier of de State op alle CAS de waarde installed bevat.

Additioneel kan het  Test-FederationTrust cmdlet uitgevoerd worden om te controleren of de Federation Trust ook correct functioneerd. Standaard gebruikt dit cmdlet de extest account:

Test-FederationTrust

Heb je geen extest account of wil je een andere account gebruiken voeg dan de UserIdentity parameter hier aan toe:

Test-FederationTrust -UserIdentity user@domain.com

Dit cmdlet zal diverse tests uitvoeren en hiervan op het scherm weergeven. Controleer hierbij of er geen foutmeldingen worden vertoond.

Als laatste stap in het proces kan de Organization Relationship gecontroleerd worden. Dit is echter alleen van toepassing wanneer een andere organisatie geen free/busy informatie op kan halen van de Exchange omgeving. D.m.v. een organization relationship geeft u namelijk toestemming om free/busy informatie te delen met deze organisatie. Staan hier bijvoorbeeld niet alle domeinen op dan kan het zijn dat free/busy lookups wel vanaf domein A werken maar niet vanaf domain B terwijl dit dezelfde Exchange omgeving kan zijn.

Om dit te troubleshooten is het van belang om twee cmdlets te gebruiken:

  • Get-OrganizationRelationShip, hiermee kan de huidige configuratie opgehaald worden
  • GetFederationInformation, hiermee wordt d.m.v. autodiscover de informatie van de andere Exchange organisatie opgehaald

Vergelijk de volgende parameters hierbij:

  • DomainNames
  • TargetApplicationUri
  • TargetAutoDiscoverEpr

Hierbij dient opgemerkt te worden dat de DomainNames parameter niet altijd gelijk hoeven te zijn wanneer beide cmdlet’s worden uitgevoerd. Soms is het namelijk niet gewenst dat alle domeinen van de andere Exchange organisatie toegang hebben tot free/busy informatie.

In dit eerste deel van deze reeks hebben we vooral gekeken naar welke configuratie items in Exchange allemaal gecontroleerd kunnen worden. Daarnaast hebben we besproken hoe we een aantal van deze configuratie items kunnen aanpassen.

In het tweede deel zullen we verder gaan met de reverse proxy en het client deel van troubleshooting.

Onderstaand nog een aantal handige pagina’s met informative over hoe je federated sharing kunt configureren:

Office 365 Community: How to configure TMG for Office 365: open
TechNet: How does Federated Calendar sharing work in Exchange 2010?: open
TechNet: Exchange 2013: Sharing: open

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Webnews
  • Y!GG
  • Ask
  • Live-MSN
  • Technorati
  • YahooMyWeb

Diverse bedrijven publiceren hun Exchange omgeving door gebruik te maken van TMG. Zosls je misschien wel weet heeft Microsoft aangekondigd te stoppen met TMG maar toch kom je nog regelmatig tegen dat klanten nog TMG hiervoor gebruiken.

Een van de features van Lync 2012 mobile is om contacten en free.busy informatie op te halen door gebruik te maken van Exchange Web Services (EWS). Afhankelijk van de TMG configuratie die in gebruik is zal dit werken. Misschien vraag je je af waarom? Om deze vraag te beantwoorden moeten we eerst kijken naar de listener. Voor degene die niet veel meer werken/hebben gewerkt met TMG door gebruik te maken een listener kunnen we configureren:

  • Welk certificaat gebruikt moet worden in het geval dat HTTPS gebruikt wordt
  • Welke authenticatie methode wordt aangeboden

Het deel wat van belang is in dit geval zijn de authenticatie methodes. Met deze methodes kan geconfigureerd worden welke authenticatie methodes zijn toegestaan voor clients om zich te authenticeren. Er zijn meerdere authenticatie methodes beschikbaar o.a..:

  • HTTP form
  • Basic

Lten we er vanuit gaan dat er een regel gebruikt wordt om  OWA, ECP, ActiveSync, EWS en Autodiscover te publiceren. In dit geval zal de listener zeer waarschijnlijk geconfigureerd zijn om form based authenticatin aan te bieden. Sommige clients kunnen echter niet goed omgaan me form based authentication en zullen daarom terugvallen op basic authentication. ActiveSync is een voorbeeld van een client die p deze manier werkt.

Maar Lync mobile 2013 bevat niet de mogelijkheid om terug te vallen op basic authentication wat als gevolg heeft dat authenticatie mislukt. Wanneer je logging hebt ingeschakeld op je device zal je het volgende terugzien wanneer je probeert te authenticeren:

Eerst wordt het formulier weergeven (onderstaand is slechts een deel van de code):

<em><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"></em>
<em><!-- {57A118C6-2DA9-419d-BE9A-F92B0F9A418B} --></em>
<em><html></em>
<em><head></em>
<em>    <title>Microsoft Forefront TMG</title></em>
<em>    <meta http-equiv="Content-Type" content="text/html; CHARSET=utf-8"></em>
<em>    <meta content="NOINDEX, NOFOLLOW" name="Robots"></em>
<em>    <link href="/CookieAuth.dll?GetPic?formdir=3&image=logon_style.css" type="text/css" rel="stylesheet"></em>
<em>    <script src="/CookieAuth.dll?GetPic?formdir=3&image=flogon.js" type="text/javascript"></script></em>
<em><script type="text/javascript"></em>

Gevolgd door de volgende foutmelding:

2013-09-12 11:45:31.020 Lync[4120:5520] ERROR APPLICATION CEwsAutoDiscoverOperation.cpp/652:All possible ews autodiscover urls exhausted.Failing autodiscover operation

Maar hoe kunnen we dit probleem oplossen? De oplossing is redelijk eenvoudig sta het toe dat clients zich via basic authentication authenticeren. Dit kan je doen door een van de onderstaande methodes te gebruiken:

  • Maak een nieuwe publishing rule aan voor EWS en Autodiscover en selecteer de optie No delegation, but client may authenticate directly. Zorg ervoor dat de rgel gebruikt mag worden door All users group i.p.v. Authenticated users. Deze regel moet boven de bestaande regels worden geplaatst die gebrukt worden voor het publiceren van Exchange
  • Maak een nieuwe web listener en publishing rule aan voor EWS en Autodiscover. Opgemerkt dient te worden dat deze methode een extra IP-adres vereist

Wanneer je meer informatie wil hebben over hoe je Exchange kan publiceren dor gebruik te maken van TMG of UAG dan is het document van Greg Taylor een goed document om mee te beginnen. Dit document bevat richtlijnen die gebruikt kunnen worden om Exchange te publiceren door gebruik te maken van TMG/UAG/ Het documentis te vinden op onderstaande site:

TechNet: Publishing Exchange Server 2010 with Forefront UAG and TMG: open

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Webnews
  • Y!GG
  • Ask
  • Live-MSN
  • Technorati
  • YahooMyWeb

OWA gebruiken met Internet Explorer 11

Nu Windows 8.1 RTM beschikbaar is via Technet en MSDN is het al door veel ITpro’s geïnstalleerd. En dan is het wachten tot mensen tegen een probleem aanlopen. Omdat de code van Exchange Internet Explorer 11 nog niet goed herkent wordt OWA standaard weergeven in light mode. Zoals je misschien wel weet bevat OWA light niet alle opties die beschikbaar zijn in de full blown OWA.
Microsoft zal waarschijnlijk Exchange in een toekomstige update gaan aanpassen zodat Internet Explorer 11 ook gebruik kan maken van de full blown OWA. Een bewijs hiervoor is al terug te zien in Office 365. Mijn tentant is blijkbaar voorzien van een update waar IE 11 al correct wordt weergeven. Voor de on-premise omgevingen is het nog even afwachten op een volgende punt waarin Microsoft deze aanpassing verwerkt.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Webnews
  • Y!GG
  • Ask
  • Live-MSN
  • Technorati
  • YahooMyWeb