Federation always fun as you may have read in one of my previous blogs. Starting this week we had some issues at a customer where the Free/busy lookups across environments stopped working. Not only to other Exchange environments but also Office 365.

Both the Outlook logging and event logs on the CAS provided the same error. The complete error message is displayed below:

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.

The bold part marks the error in this case An error occurred when processing the security tokens in the message. This error tells you there is an issue with the security token which your server has received from the Microsoft Federation Gateway. So probably this customer is not the only customer facing this issue.

Microsoft has acknowledged there were some issues earlier this week which not only affected this functionality but also some Office 365 services.

Office 365 status

Currently a work around is available to fix this issue. To fix the issue you will need to refresh the federation trust metadata. This can be done by using the following Powershell cmdlets:

Get-Federationtrust|Set-Federationtrust -Refreshmetadata

It is important to know that this cmdlet will need to be run on both sides else it may not fix the issues. Once the cmdlet have been executed it may take some time before the free/busy lookups start to work again.

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

During a migration to Office 365 I had this issue. The migration of a mailbox was stalled several times with the following entry logged in the migration log Relinquishing job because the mailbox is locked. Sometimes this occurs only once but I have seen times that the mailbox will get stuck in this phase.

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.

When searching in Googl you will see several tips but most of them will point to TMG or a Firewall which will block the large amount of requests Office 365 sends because it thinks it’s unsafe. Microsoft has published a Knowledge Base article about this which you can find here.

The solution Microsoft offers is raising the value of the Custom Limit in the Flood Mitigation Settings. Microsoft will tell you to raise this number to a higher value but it depends on the amount of mailboxes how high you will configure this value.

TMG Flood Migration settings

Of course this is a nice solution but it might require the modification of the value multiple times. Despite this value will be applied to all IP addresses including those from evil users. There must be a nicer solution. A more suitable solution is to not apply the Flood mitigation settings to the IP addresses of Office 365.

To configure this it is recommended to create a computer group which contains the separate IP addresses and subnets which are being used by Office 365. In the image below you can see an example.

Floot Mitigation - IP Exceptions

For a complete overview of the IP addresses used by Office 365 you van visit the following pages:

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

It is recommended to visit both pages and add the IP’s and subnets to the computer group. Once the group is created add the group to the IP Exceptions tab. Once the configuration has been activated in TMG you wille see that the migrations will continue and will not stop anymore. This last benefit has another benefit the migration of a mailbox will be completed faster.

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 the first two parts of the blog series about troubleshooting federated sharing we had a look at the infrastructure and configuration which is required. Besides this we did some basic troubleshooting on the components involved during federated sharing. In this part we will look at some examples which I gathered during troubleshooting a federated sharing issue.

Below you will see an example of an error which was received when trying to retrieve the free/busy information from a user hosted on another Exchange environment.

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.

When looking at the marked text you will see the actual cause, a certificate issue. So how to deal in this case? The first step you can take is try to access the Exchange Web Services of the other Exchange environment. In this case we can do it by browsing to https://mail.domain/com/ews/exchange.asmx/WSSecurity what will probably happen is that you receive a certificate warning. And that is exactly why the lookup fails. The certificate from the remote Exchange environment is not valid according to the validation procedure. However when you open it in a browser you will see the reason why the certificate is not trusted. This can be caused by several things among them:

  • Certificates is signed by a root CA which is not trusted
  • Name on the certificate is incorrect

In this case the root CA was not trusted by the Exchange environment. By importing the root CA in the Enterprise Trusted Root folder of the CAS the problem was solved.

The second one was pretty hard to troubleshoot but the solution to solve it was pretty easy. Again the error is marked in the text below. The error tells you that the other side did close the connection. OK nice and now what? In this case you will need to search in the IIS logs on the CAS of the target Exchange environment to see what happens when traffic from your Exchange environment arrives at the CAS.

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.

Search for traffic destined to /ews/exchange.asmx/WSSecurity and you will probably find the error that did occur. Normally when everything works a 200 will be displayed. If you do receive a 4XX error then verify that the federation with the Microsoft Federation Gateway works correctly as explained in the first part. Besides this verify that WSSecurity is enabled on the Autodiscover and EWS directory.

However you might get other errors, in this case it was a 500 error. What this means and that it doesn’t know how to deal with the traffic which arrives and will close the connection. If this happens make sure WSSecurity is enabled on the virtual directories for Autodiscover and EWS. When this is confirmed verify that the svc-integrated handler is assigned to both the Autodiscover and EWS. If this is both configured correctly everything should be OK but why doesn’t it work?

In some occasions it may happen that EWSSecurity is correctly enabled but for some reason IIS doesn’t pick this up. If this happens an iisreset will fix your issue and you will be able to retrieve the free/busy information from the other Exchange organization.

Here ends the series of troubleshooting federated sharing. I am aware there might be other solution for the issues you might find during the implementation but these were just two examples of issues I found.

I hope you liked this series and if you have any questions use the contact form on the site to send me a message or ask your question by posting a comment.

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

It has been a while ago since I received this book for review, initially I started reading it on my way to Exchange Connections in Las Vegas on my iPad mini. And the last few weeks I finished reading the book. So what do I think of the book? The book is a must have resource for everyone who is working with Exchange 2013. Tony Redmond is amazing good in describing the several parts of Exchange related to mailbox and high availability. Yes you are reading it correct this book only describes the mailbox an high availability of Exchange 2013. For the Client Access ,Connectivity and UM part of Exchange 2013 you will have to read the book from Paul Robichaux.

Tony starts with describing some important things you will have to consider when implementing Exchange 2013. This starts with a discussion about the architecture and continuous with several decisions you have to make before implementing Exchange 2013. Then he continuous to describe which preparations you have to make before you can implement Exchange 2013. After these topics have been described Tony describes how to install it and the basic management tools you will need to use to manage your Exchange 2013 and in more detail how to manage your mailboxes.

Starting from chapter 8 the book makes a very deep dive. For those who are already familiar with Exchange 2013 and want to skip the basic things this is were you should start reading the book. In very deep detail Tony describes several topics among them:

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

For example in the how does the store work chapter will describe what is under the hood of the store. When you have read this chapter you will probably have a better understanding of the store process and how complex the product Exchange is under the hood. After the store is described the book continuous with the database availability group. In this chapter Tony describes several topics related to the DAG including: design considerations, daily administration tasks and several important components of the DAG among them the active manager.

Once the mailbox and high availability part have been discussed the book continues with the mailbox migration process. In this chapter the components are discussed which are key components of the migration process and of course how to perform the migration. This is not limited to only the cmdlets but also contains several practical tips from Tony about planning.

Some people are already working with the compliance part but some haven’t probably touched it. Both groups will benefit from this chapter as it describes some basic things but contains enough detail so people with experience will also learn a lot from this chapter. Compliance is a topic which becomes more important now-a-days since more and more companies will start implementing it either due to company regulations or government regulations.

In the last chapter Tony describes one of the probably most discussed topics of Exchange. Will it be there in the next release? How long will Microsoft Public Folders? These are just a few questions you will hear every time during the development phase of the next version of Exchange. In Exchange 2013 the Public Folders have changed a lot since the public folders can now be part of a normal mailbox database so no separate public folder database anymore. But how to get from the “legacy” Public Folder to the “new” Public Folder. Read Tony’s book and you have some good info on how to do this.

So what’s the conclusion of this review? The book is a must read for everybody who works with Exchange. It does not contain the basic information which most books do but describes several things in very deep detail. Besides this Tony also provides some additional information which really adds value to the book.

So if you got curious about the book just press the link below to buy the book:

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 – part II

In the first part of the blog series about troubleshooting federated sharing we had a look at the server side. We discussed which parameters you should verify during troubleshooting and if they are configured incorrectly how to fix them.

Now we will continue our journey in this second part. In this part we will have a look at the reverse proxy side followed by the client side.

Let’s start with having a look at the reverse proxy.

Because you don’t want your Exchange environment is directly accessible via the internet most companies will us a reverse proxy to “publish” their Exchange environment. This can either be done via a Microsoft product such as TMG or ARR. The first one will be end-of-support shortly so if not having one in place don’t start implementing it but use ARR or a 3rd party solution. When looking at the third party solutions there are a lot of solutions you can use. For example BlueCoat, Kemp Technologies or F5 have products which offer this functionality.

So what can be the problem with the reverse proxy which is used for publishing the Exchange environment? Well there can be many problems among them:

  • Authentication issues
  • Name resolving issues
  • Routing issues

This are just three of the sort of issues you can experience when using a reverse proxy. I am sure there are a lot more sorts. In this blog we will focus on the authentication issues. The reason for this is that these are the issues you will probably encounter during your journey in configuring 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.

For federated sharing it is required that all the federated sharing sessions will be passed-through to the CAS without having to authenticate. Authentication in this case will take place on the CAS/CAS Array. So one thing to make sure is that you will create the rules required for federated sharing above the existing rules. As mentioned in the first part the URL’s which are required are as follows:

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

If you are using the TMG to publish these URL’s ensure the following options are select:

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

Most companies will use Form Based Authentication (FBA) to publish their Exchange Services to the internet. If this is the case you will need to change the listener. This because by default the listener will required all users to authenticate before they can connect which makes sense.

However for the URL’s used for federated sharing the authentication takes on the CAS so we also want to disable this specific option.

To do this get the properties of the listener and select the authentication tab. Open the advanced authentication options by pressing the advanced button and uncheck the option Require all users to authenticate.

Once configured you will need to find out if the rule really works the way you want. For example if configured in the wrong order the traffic will not even hit configured rule. To monitor this piece some logging will need to be enabled on the TMG side. I personally recommend you to create a filter using the following parameters:

  • Filter by: rule
  • Condition: equals
  • Value: name of the publishing rule used to publish these services

Now logging is configured try to do a free/busy from another Exchange environment or from Office 365. If the rule is on the correct place you should see that the traffic hits the rule.

If you do not see any logging the traffic will not hit the rule. In that case verify the already discussed parameters and try again. In some cases it might take a few minutes before the TMG has picked up the new config so if it does not work directly wait a few minutes and try again.

Another issue you might see are authentication issues in the TMG log. This will be either 401.x or 403.x errors in most cases. In this case verify that when you browse to the following pages no form will be displayed:

If a form is displayed please verify the delegation settings on the rule and the authentication settings on the listener.

OK enough about TMG let’s continue with the client side. By default Outlook has disabled logging for troubleshooting purposes so before starting the troubleshooting you will need to enable it. Microsoft has published a knowledge base article on how to enable the troubleshooting logging which can be found here.

When you have reproduced the issue it is time to look at the logs. Depending on the version of Outlook you the log are named different and are located in different locations. Below an overview of Outlook version, the log location and log file name:

Version Location Filename
Outlook 2007 %temp%\OLKas date-time -fb.log
Outlook 2010 %temp%\OLKas date-time -AS.log
Outlook 2013 %temp%\Outlook logging Outlook-########.etl

So if you are on Outlook 2007/2010 your good investigate the logs yourself. If you are using Outlook 2013 you will have to send the etl file to Microsoft support for research.

Below you will find an example of a log file create with Outlook 2010. Let’s analyse it:

First Outlook will determine the URL for the availability service. Outlook will use autodiscover to do determine the availability URL.

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

As you can see Outlook already will use the URL from a previous autodiscover request:

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

The URL in cache is the one that is used for requesting the availability service:

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

Next step is to send the actual request which is send as an XML to the target CAS. As you can see this XML request will be used to request the free/busy information from a specific user:

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

Once the type of request has been determined the parameters will be provided in the body. You will see the following parameters to be used in every free/busy request:

  • ex12t:Timezone: the timezone which is being used: in this case 60
  • ex12t:StandardTime: the default value of the time for the request being send, I guess if no specific time is specified it will use this one
  • ex12t:Time: the standard time for which we want to know the availability: in this case 03:00:00
  • ex12t:DayOrder: the standard day (date) you want to know the availability for: in this case 5
  • ex12t:Month: the standard month: in this case 3
  • ex12t:DayOfWeek: the day for which you want to know the availability: in this case Sunday
  • ex12t:DaylightTime: I haven’t figured out this one but it looks like it has something to do with the winter/summer time
  • ex12t:Address: the smtp address of the user for which you want to know the availability: in this case johan.@johanveldhuis.nl
  • ex12Routingtype: the transport method which is used for sending the actual request once you hit the send button and your CAS will deliver it to the mailbox of the user determined in the ex12t:Address: in this case smtp
  • ex12t:AttendeeType: the type of attendee this can be either required or optional: in this case required
  • ex12t:FreeBusyViewOptions: contains the meeting specific details
  • ex12t:Starttime: the start time of the meeting: in this case 2013-09-09T18:00:00
  • ex12t:Endtime: the end time of the meeting: in this case 2013-10-09T18:00:00
  • ex12t:MergedFreeBusyIntervalInMinutes: the intervals for which you would like to display the availability by default per 30 minutes
  • ex12t:RequestedView: which info we want to see for the user: in this case detailed

request

Now the XML has been generated the actual request can be send:

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

Next we will receive the response which will tell us the request has been successfully send or that it failed. In this case the HTTP status code will tell us the request has been send successfully:

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

Once the request has been send we will receive an answer from the source CAS which tries to route the request to the remote CAS. It starts with some generic XML which contains the server version information. This is the version number our own CAS. In this case we can see it runs Exchange 2010 SP3.

Next information contains the actual response the source CAS received from the remote CAS. This part will start with FreeBusyResponseArray this part contains the ResponseMessage as you can see there is a security related issue. This issue will prevent Outlook from receiving the free/busy for the other user.

After the message we will see some more detailed information which will show you which request the source CAS tries to send to the remote CAS.

response

In the final part you will see the actual error message and from which CAS it did receive this error. In this case error 5016 id received from CAS02. Outlook will display the 5016 error when hovering over the free/busy info from the specific user.

Here ends the second part of the blog series about troubleshooting federated sharing. In this part we had a look at the requirements for the reverse proxy and some basic troubleshooting and continued with troubleshooting from the client side.

In the third and last part of the article we will discuss some issues I have seen happening when setting up federated sharing.

If you have any comments/questions please let me know.

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

 By using federated sharing it is possible to exchange free/busy informative between different Exchange organizations. This can be done by using the Microsoft Federation Gateway (MSFG) when no direct trust exists between the Active Directories. The MSFG is in this case responsible for providing a ticket which is used for authentication. By using a ticket a CAS can contact the CAS from the other organization to retrieve the free/busy information.

To use this feature several things will need to be configured:

  • trust with the Microsoft Federation Gateway
  • organizational relationship must be configured
  • autodiscover and EWS must allow WS Security authentication
  • the reverse proxy needs to allow unauthenticated traffic to the following url’s:
    • /EWS/exchange.asmx/WSSecurity
    • /autodiscover/autodiscover.svc/WSSecurity
    • /autodiscover/autodiscover.svc

Several sites contain a step-by-step plan on how to configured this. An overview of those sites can be found on the end of this article.

When you setup these things everything should work, indeed should. In most cases it will work but in some cases you will need to perform some troubleshooting. In this serie of blogs we will have a look how you can validate that it works and perform some troubleshooting in case something doesn’t work.

But how can you troubleshoot these issues? First of all it is very useful if you have a contact person who has access to the other Exchange organization. In most cases this isn’t a big issue but when using Office 365 or another form of hosting this can be very hard sometimes.

To start the troubleshooting process you mostly would like to verify your own Exchange organization first. Things that could be checked are:

  • verify if autodiscover allows WS Security for authentication
  • verify the external EWS url
  • verify if Exchange Web Services will allow WS Security for authentication

If your Exchange organization contains multiple CAS then Powershell is your friend and you can use several cmdlets to verify the steps above:

Get-AutodiscoverVirtualDirectory|select server, WSSecurityAuthentication

Get-AutodiscoverVirtualDirectory

You will get an output like above. Verify if the value of the column WSSecurityAuthentication is set to true

If WSSecurity is not true then use the following cmdlet to enable it:

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

Using this cmdlet the authentication method will be configured but to offer this authentication type you will need to perform an IISReset. Additional you can verify if the svc-integrated handler is attached to the autodiscover virtual directory:

IIS

Next step is to verify the Exchange Web Services, this can be done by using the Get-WebServicesVirtualDirectory cmdlet:

Get-WebServicesVirtualDirectory|select server, ExternalUrl, WSSecurityAuthenticationcmdle

Get-WebServicesVirtualDirectory

Again the same rule apples WSSecurityAuthentication needs to be set to true. Besides this the ExternalUrl needs to contains a valid value. This url needs to accessible from the internet. If this is not the case it simply won’t work.

In case that WSSecurity is not true enabled it by using the following cmdlet:

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

The same applies for EWS as it did for autodiscover perform an IISReset to activate the authentication method. Besides this verify if the ws-security handler is attached to the EWS virtual directory.

If no external url is configured you will need to configure one. Before you do this make sure the certificate contains all the correct names. If you will configure a value but it is not part of your certificate you will get errors.

To verify if the certificate contains the correct names we will use Powershell again:

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

Verify if the CertificateDomains contain the FQDN you are planning to use for EWS, for example mail.domain.com of ews.domain.com. If this name is not on the certificate you will need to renew your certificate.

If the certificate contains the name for the external URL then you can continue configuring it:

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

Using the cmdlet above the external URL on all Client Access Servers will be configured the same. REMARK: in some scenarios this is not what you want. Please verify if this is the case in your scenario before configuring the external url.

When this has been configured and validated it is time to verify the Federation Trust and the Organization Relationship.

This can be done by starting with Test-FederationTrustCertificate which will verify if the certificate used for the trust is correct and is installed on all CAS. During the creation of the trust the self-signed certificate will normally be distributed to all CAS in your environment. But in some cases this may not happen. If this is the case the CAS will be unable to authenticate against the Federation Gateway of Microsoft which will eventually result the autodiscover process to fail.

Test-FederationTrustCertificate

Test-FederationTrustCertificate

Verify that the State column for all CAS contain the value installed.

Additionally you can run the Test-FederationTrust cmdlet to verify if the Federation Trust really works. By default this cmdlet will use the extest account:

Test-FederationTrust

If you don’t have an extest account or you would like to use another user add the UserIdentity parameter:

Test-FederationTrust -UserIdentity user@domain.com

This cmdlet will perform several tests and will output the results on the screen, verify if no errors did occur.

As final step of the process you can verify the Organization Relationship. This is only applicable if the other organization has issues when looking up the free/busy information for your mailboxes. By using an organization relationship you will give the other organization permission to retrieve free/busy information of your organization. If not all domains are listed here it can cause strange issues such as it works for domain A but not for domain B while they are located in the same Exchange environment.

To troubleshoot these kind of issues you can use two cmdlets:

  • Get-OrganizationRelationShip,  retrieves the current configuration
  • GetFederationInformation, will send an autodiscover request to the other organization to retrieve the configuration

The following parameters are important in this case:

  • DomainNames
  • TargetApplicationUri
  • TargetAutoDiscoverEpr

One remark must be made about the DomainNames parameter. In some cases this parameter doesn’t have to be the same for both cmdlets. Some organizations only want to share free/busy information with a specific domain and not all domains hosted by the other Exchange organization.

In this part of the series we did have a look which configuration items you will need to verify in your Exchange organization. Besides this we did had a look on how to fix them if they are configured incorrectly.

In the second part we will have a closer look at the reverse proxy and client part of troubleshooting.

Below are some pages which contain use full information about federated sharing:

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

Several companies have published their Exchange environment by using TMG. As you may know Microsoft has announced to discontinue the product but when working in the field you will still see that customers are using TMG.

One of the features of the Lync 2013 mobile client is to retrieve your contacts and free/busy information using Exchange Web Services (EWS). It depends on your TMG config if this will work. You may wonder why? For this we will need to have a closer look at the listener. For those who do not work much with TMG using the listener we can configure:

  • Which certificate is used to provide HTTPS
  • What kind of authentication types do we accept

So the item we need to have  closer look at is the authentication types. Using the authentication types we can configure how clients can authenticate against our Exchange environment. There are various options which you can configure for authentication amongst them:

  • HTTP form
  • Basic

Let’s assume you created one rule to publish OWA, ECP, ActiveSync, EWS and Autodiscover. In this case the listener is probably configured to offer form based authentication. Which will perfectly work for Outlook, OWA, ECP and ActiveSync. But it doesn’t work for Lync 2013 mobile clients. Normally when clients try to authenticate they will hit the form. Some clients however can’t authenticate using the form and will fall back to basic authentication. ActiveSync devices are an example of clients which work like this.

But the Lync 2013 mobile client doesn’t contain the option to fall back to basic authentication which results in authentication to fail. When you have enabled the logging on your device and examine it after trying to authenticate you will see this:

First the form will be displayed (below a small part of the 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>

Followed by the following error:

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

So how to solve the issue? Well the resolution is pretty simple allow basic authentication for autodiscover and EWS. This can be realized via two methods:

  • Create a new publishing rule for EWS and Autodiscover and select the option No delegation, but client may authenticate directly. Ensure the rule may be used for the All users group instead of the Authenticated users. This rule must be placed above the existing publishing rules which are used for publishing Exchange
  • Create a new web listener and new publishing rule for EWS and Autodiscover. The remark which must be made to this method is that it requires new IP-address

If you want to have more information about publishing your Exchange environment either using TMG or UAG then  good starting point is the document of Greg Taylor which contains some guidelines on how to publish your Exchange environment using TMG/UAG. This document can be found on the site below:

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

Using OWA and Internet Explorer 11

Now Windows 8.1 RTM is available via Technet and MSDN it is installed by several ITpro’s. And then it is just a matter of time befor someone finds  an issue. This because the code of Exchange doesnt recognize Internet Explorer 11 correctly and this will result in OWA to be displayed in light mode. As you may know OWA light doesn’t connect all the options which are available in the full blown OWA. Microsoft will probably fix this in a future update so you can use Internet Explorer 11 in full blown mode. This is confirmed by something I discovered when using Office 365. It looks like my tenant is already upgraded because Interne Explorer 11 works OK for me. The on-premise environments will need to wait till Microsoft releases an update which contains the correct code to recognize Internet Explorer 11.

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

20130821-172919.jpg

A few weeks ago the Exchange 2013 version of the Powershell Cookbook was published by Packt Publishing. This version also introduced a additional writer for the book: Jonas Andersson. A frequent Exchange blogger with quality articles so before I started reading I was convinced the book should be from high quality also. The second writer is the one who was also responsible for the first part Mike Pfeiffer. Those who missed the first part and are working with Exchange 2010, please read the book it contains very usefull info.

Enough about the writers and the first part . Let’s start reviewing the secondary part which is mostly decicated to Exchange 2013. The book starts from the beginning so if you are not familiar with Powershell the book will introduce how Powershell will work and you can benefit from it. And trust me I also found some nice tips for future use my scripts although I use Powershell almost every deployment.

Once the writers discus some basics which you really want to know they describe the abilities Powershell will give your per part of Exchange. For example they discuss which Powdershell cmdlets you can use for managing the Exchange Transport part. Per Exchange part a very clear description is given including some really nice examples.

As last and bonus part the writers describe how you can use EWS via Powershell which extends Powershell again. For those who are familiar with basic Powershell this is a must read chapter.

So what’s my conclusion about the book: a really nice book both for Exchange Powershell starters but also for people that are more experienced with Powershell for Exchange.

You can buy the book via the site below:

Packt Publishing

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

Exchange 2010 SP3 Rollup 2 released

Microsoft has released Exchange 2010 SP3 Rollup 2 yesterday. This rollup will fix the following issues:

  • 2837926 Error message when you try to activate a passive copy of an Exchange Server 2010 SP3 database: “File check failed”
  • 2841150 Cannot change a distribution group that contains more than 1,800 members by using ECP in OWA in an Exchange Server 2010 environment
  • 2851419 Slow performance in some databases after Exchange Server 2010 is running continuously for at least 23 days
  • 2853899 Only the first page of an S/MIME signed or encrypted message is printed by using OWA in an Exchange Server 2010 environment
  • 2854564 Messaging Records Management 2.0 policy can’t be applied in an Exchange Server 2010 environment
  • 2855083 Public Folder contents are not replicated successfully from Exchange Server 2003 or Exchange Server 2007 to Exchange Server 2010
  • 2859596 Event ID 4999 when you use a disclaimer transport rule in an environment that has Update Rollup 1 for Exchange Server 2010 SP3 installed
  • 2860037 iOS devices cannot synchronize mailboxes in an Exchange Server 2010 environment
  • 2861118 W3wp.exe process for the MSExchangeSyncAppPool application pool crashes in an Exchange Server 2010 SP2 or SP3 environment
  • 2863310 You cannot send an RTF email message that contains an embedded picture to an external recipient in an Exchange Server 2010 SP3 environment
  • 2863473 Users cannot access Outlook mailboxes that connect to a Client Access server array in an Exchange Server 2010 environment
  • 2866913 Outlook prompts to send a response to an additional update even though the response request is disabled in an Exchange Server 2010 environment
  • 2870028 EdgeTransport.exe crashes when an email message without a sender address is sent to an Exchange Server 2010 Hub Transport server
  • 2871758 EdgeTransport.exe process consumes excessive CPU resources on an Exchange Server 2010 Edge Transport server
  • 2873477 All messages are stamped by MRM if a deletion tag in a retention policy is configured in an Exchange Server 2010 environment

Especially when you are planning to migrate from Exchange 2010 from Exchange 2003 or Exchange 2007 this rollup is recommended. The rollup fixes an issue which can occur with Public Folder replication between Exchange 2003/2007 and Exchange 2010. Because replicating the public folder content is one of the steps you might see this issue if you won’t deploy Exchange 2010 SP3 rollup 2.

The second interesting thing in the release notes is a fix for the MsExchangeSyncAppPool which crashes. This issue occurs only when offering ActiveSync services to your end-users and you will use Apple devices. In this case it can happen that the CPU usage on the CAS is high (between 80% and 100%). Users might in this case not be able to sync their mailbox content because throttling is applied. Cause of this issue is the throttling mechanism. Exchange 2010 SP3 Rollup 2 contains a fix for this issue which should prevent this issue from occurring again.

Looking at the third issue you may think what? Slower performance which is experienced by users when their mailbox is hosted in a database which his created after Exchange 2010 SP3. This problem occurs only if the database is online for more then 23 days.

You can download Exchange 2010 SP3 rollup 2via the link below:

download

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