Lync 2013 external access to Exchange Web Services (EWS) via TMG

***** UPDATED as I realised the procedure wasn't quite right *****

I recently deployed Lync 2013 with external access at a client who runs Exchange 2010 with external access via TMG.  During initial testing all was well but later testing showed that both the Lync mobile client and Lync 2013 full client couldn't connect to EWS externally.

I'd already created pass-through rules for autodiscover and EWS (more on that later) and I was pretty sure Lync was setup correctly.

The front end's Lync Server event log was showing error ID 32054 for the LS Storage Service:

Storage Service had an EWS Autodiscovery failure.

StoreWebException: code=ErrorEwsAutodiscover, reason=GetUserSettings failed, smtpAddress=test@domain.public, Autodiscover Uri=https://autodiscover.domain.public/autodiscover/autodiscover.svc, Autodiscover WebProxy=<NULL>, WebExceptionStatus=TrustFailure ---> 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.
.......(truncated)
Cause: Autodiscovery Uri was not correctly configured or unreachable, that there is a problem with the Proxy, or other errors.
Resolution:
Check event details.  Check autodiscovery Uri is properly configured and reachable. Check that proxy setting is properly configured and reachable.  Validate Lync to Exchange Autodiscovery configuration by following the trouble shooting guide. If problem persists, notify your organization's support team with the event details.

Watching the TMG logs I noticed that connection attempts to Autodiscover were initially anonymous, unauthenticated and successful, followed by another successful connection but with a http response of 405 "method not allowed".  There were no subsequent EWS connections.

Then I randomly tried to connect from a different external location and everything worked, the Lync client successfully connected to EWS and all meetings and conversations appeared!!!

I started to realise there may be multiple issues so I looked at the front end server's event logs again.  The front end server was attempting to update my Lync account's presence information by connecting to a CAS.  The SIP domain uses the public namespace as Exchange (e.g. domain.public) which is different from the AD forest domain name (e.g. domain.internal).  The event log error showed me that the front end server was trying to connect to autodiscover using the public domain.

It seemed to be connecting but failing so I checked and there was a DNS record internally for autodiscover using the public domain (autodiscover.domain.public).  Then I realised that the CAS server certificate didn't include autodiscover.domain.public.  Why would it?  No prior need for it internally!  I re-issued the Enterprise CA certificates to the CAS servers and included all the public names on it, too.  Ta-da!  No more 32054 errors.

Back to TMG.  I'd correctly planned and deployed new rules for autodiscover and EWS using the web listener I'd created for Lync as it doesn't require authentication and the edge firewall will already have TCP 443 passing through to it.

Here's my method for this:

1. Assign a new public IP address for Autodiscover/EWS and route/NAT it through to TMG on TCP 443
2. Create a new public DNS A record for EWS (e.g. ews.domain.public), pointing to the newly-assigned IP
3. Add the new IP (or NATd IP) to TMG's external NIC
4. Create a new TMG web listener for EWS:
1. Require SSL
2. Listen on the EWS IP
3. Use the Exchange certificate
4. No authentication
5. Create a new TMG Exchange 2010 web client access rule above the existing Exchange rules:
1. Use Outlook Anywhere with additional folders
2. Use the EWS web listener
3. Use two public names: autodiscover.domain.public and ews.domain.public
4. Set the authentication delegation to 'No delegation, but client may authenticate directly'
5. Set the users to 'All Users'
6. Remove all paths except for /ews/* and /AutoDiscover/*
6. Change the Exchange web services virtual directories' external URL to use the new public name ews.domain.public (e.g. to change all CAS servers: Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -ExternalUrl https://ews.domain.public/EWS/Exchange.asmx)
7. Change the autodiscover public DNS record autodiscover.domain.public to use the same IP as ews.domain.public

Back to the problem, in TMG I watched the logs while I tested logging on to various Lync clients externally.  I had one of those 'I'm so dumb' flashes: TMG was configured to send traffic to a web farm of two CAS servers.  One was responding correctly, the other wasn't.

I looked at the rogue CAS and couldn't see any issues in the logs or any other signs that it wasn't working properly so I used the EMC to reset the Autodiscover virtual directory then ran iisreset /noforce.

That was it, all my external Lync 2013 clients were now able to access EWS and display meetings and conversations, no matter which CAS they hit.  Mucho happy me!


This post in its entirety is the copyright of Roland Paix. I don't mind if you link to it but if you copy any of the content you must provide a link to the post and credit me appropriately.

New-MailboxExportRequest fails when content filter is used with non-US date formats

There seems to be a bug when using the New-MailboxExportRequest cmdlet in Exchange 2010 and specifying a content filter using dates in non-US format.

The only solution I've found is to change the region format to US before running the Exchange Management Shell, then change it back (after launching EMS or after running your script/cmdlet).

Here's the detail:

Exchange 2010 has a new two-step method of exporting mailbox data to PST using the New-MailboxExportRequest cmdlet.  A user with the right permissions creates the export request and the Mailbox Replication Service on a CAS server uses the information in the request to export the data.

The user who runs the cmdlet must have the 'Mailbox Import Export' role and you'll probably want to create a new role group for this.

In the parameters of the cmdlet the content filter is specified with a date range.  If you use a variable for the dates you may find that you need to use double-quotes for the content filter instead of curly brackets like so:

New-MailboxExportRequest -Mailbox "Test User" -FilePath "\\Server\Share\TestUser.pst" -ContentFilter "(Received -lt '$DateRangeEnd') -and (Received -ge '$DateRangeStart')"

If the region format of the computer running the script uses a non-US date format (e.g. Australian or English : DD/MM/YYYY) then the cmdlet converts the input to the local format when it is run.  Unfortunately the MRS converts the format to US when it runs.  When the day is greater than 12 the cmdlet will run and the export request will be created but when the MRS processes it, it will fail with messages such as:

FailureCode: -2146233088
FailureType: InvalidContentFilterPermanentExceptionMessage
Error:
ContentFilter is invalid. The value "13/05/2013 12:00:00 AM" could not be converted to type System.DateTime. 

It seems that at each step the date is input or stored as a string and converted to date format.  Even if you use a date-formatted variable in the cmdlet Exchange will convert it to date format as the cmdlet is run.  The MRS then processes the export request and converts the stored date from a string to date format again.

I'm pretty sure of this because I've tried entering dates in lots of different ways, type, formats, cultures, strings, variables etc.  I've even called PowerShell using a hard-set US culture but it still refers to the computer's region format when it creates the export request.

The only solution that worked for me was to make sure the computer's region format is set to US before starting EMS, run my script/cmdlet then change the region format back to the local one.  You only have to have EMS started while the format is US, you can change it back to local as soon as EMS is running.

Caveat: I've only tried this while running the cmdlet on a CAS server.  If you run it remotely you may find you don't need to change any region settings or that you may need to change them on the CAS server.


This post in its entirety is the copyright of Roland Paix. I don't mind if you link to it but if you copy any of the content you must provide a link to the post and credit me appropriately.

Why does it take up to 2 days for new users to appear in Outlook?

Ever wondered why it can take a day or two before new users/groups/contacts/public folders show up in the address book in Outlook?

First of all, this affects Outlook clients running in cached mode as they use the Offline Address Book (OAB) for the Global Address List (GAL) rather than Active Directory which will be used when Outlook is in online mode.

Secondly, believe it or not, this is by design and is due to the way the OAB is generated and distributed to clients.

The OAB update process is something like this:

The OAB generation server is (by default) set to update the OAB at 5am daily.  It updates the OAB to a local folder.

Each OAB distribution server (regardless if you have only one or many) polls the OAB generation server every 8 hours (default) for updates.

Outlook in cached mode will download OAB updates when started or every 24 hours if left open (it's a bit more complex than that but I don't want to get bogged down here).

An example:

John creates new distribution groups on a Tuesday morning.  On Wednesday morning at 5am the OAB generation server updates the OAB with the new distribution groups.  Let’s say we’re unlucky and the OAB distribution servers don’t update their files for nearly 8 hours so just before 1pm Wednesday.

John's boss leaves his workstation running all the time with Outlook open.  Outlook checked for updates to its OAB on the Wednesday morning but the distribution groups weren't in the updates available on the OAB distribution servers at that time.  John's boss starts moaning about how John hasn't created the distribution groups right or that Exchange sucks or something and it's not until Thursday morning that John's boss's Outlook OAB updates with the DGs.

You should be able to see now why it’s possible for up to 2 days to pass before addresses appear in Outlook.  Throw in multiple sites and you could potentially add a few more hours into the equation.

What can you do to speed this up?

1. Reduce the OAB virtual directory polling internal from 8 hours to maybe 2 hours.  Not recommended as it adds overhead to client access servers during working hours.

2. Change the OAB update schedule to custom and run it multiple times per day.  Not recommended in larger environments due to the extra processing it can add to the OAB generation server but in smaller environments shouldn't matter.

3. Change the OAB update schedule to custom and run late in the evening, say 9pm.  You should try and set the schedule outside of backup windows and maintenance intervals.  By setting OAB generation schedule to 9pm, at the latest the OAB distribution servers should pick up the updates by 5am the next day making them available to Outlook clients when they’re started.

This is true to Outlook 2010 and Exchange 2010 and should also be for their 2007 equivalents.  Outlook 2003 gets its OAB updates from public folders but really, are you STILL using Outlook 2003?

This post in its entirety is the copyright of Roland Paix. I don't mind if you link to it but if you copy any of the content you must provide a link to the post and credit me appropriately.