Publishing Server 2012 R2 Work Folders with UAG 2010 SP3 Reverse Proxy

We already knew before 2012 R2 came out that we were going to use Work Folders in a trial later in the year. As soon as the ISO dropped we began organizing our server environment to handle Work Folders synchronization. Of course the biggest part of this is allowing synchronization from home, so reverse proxying a remote access solution was a must.

We use UAG 2010 and while Microsoft may have a wizard in the upcoming SP4, unfortunately is not available yet for early adopters. Here are the steps we used to make it work.



Prerequisites

Before you start it is best to use split-brain DNS for a smooth and speed workfolders experience. Create a new DNS record on your internal DNS servers using the external DNS FQDN with a low time-to-live, maybe 15 minutes, point this to your internal workfolders server IP. Then create the same DNS record on DNS servers authoritive for your external records and point this to your UAG trunk.

The records will resolve something like:
Internal: workfolders.consoto.info 192.168.1.1 (Internal Work Folders server)
External: workfolders.consoto.info 180.0.0.1 (External UAG Trunk)



Step by Step

1. Open UAG and take an existing trunk (or create a new trunk) that has Trunk authentication disabled. The trunk we used had a wildcard certificate and it worked perfectly. 

2. Add a new application. 

3. Select "Other Web Application (application specific hostname)", click OK. 

4. Name the application "workspaces" and application type "workspaces", click OK. 

5. Select "Configure an application server", click OK. 

6. In "addresses" enter your workspaces URL, we are using split-brain DNS so the internal and external address will be the same. 

For paths enter "/sync/1.0/" as this is the only part of the Work Spaces server that the reverse proxy needs to forward. 

In public hostname enter workspaces, you will need to create the corresponding external A record (or CNAME record for existing trunks), click OK. 

7. Leave "use SSO" unticked, click OK. 

8. Un-tick "add a portal and toolbar link", click OK. 

9. Leave "Authorize all users" ticked, click OK. 

10. Click finish to create the application. 

11. Now we must make some modifications to the URL set, to do this click "Configure trunk settings" under the trunk. 

12. Click the URL set tab and find the "workfolders_Rule1" rule. The rule already will show the URL of "/sync/1.0/.*", we need to modify the methods. 

The default methods are POST and GET, add in DELETE, PUT and HEAD. 

Click OK to save the settings. 

13. Click the "workfolders" application and select edit. 

14. Select the Web Settings tab and click "Allow POST requests without a content-type header", then click OK to accept the changes. 

15. Save your changes and activate your configuration

Aastra 6725ip POE problems with HP Procurve switching

We recently received a number of Aastra 6725ip handsets, the handsets immediately powered up via POE and connected to our Lync 2013 deployment. After I returned to work on Monday morning none of the phones were still connected to the Lync server, after rebooting them they no longer booted from POE.

This problem was introduced when they updated to newer OC Phone firmware editions 4.0.7577.4397 (CU9) and above. Although we can't confirm if the issue was introduced in firmware versions CU8 and below.

We tried a number of different Procurve switch models including other 5400 series switches (all fully populated with 900w POE+ power supplies) and 2900 series models, all experienced the same no power problems. The switches complained of not detecting an MPS signature and occasionally the switch also gave over current detection errors. If we used a POE injector or DC power supply the phone started without an issue. We also verified this was not an issue with POE power limits, pre-std-detection or LLDP.

After contacting Aastra they asked us to take a photo of the label underneath the phone. After the technician viewed the label they immediately offered to RMA all my phones but didn't give any reasons as to why they needed to be RMA'd.

After receiving the new phone I compared the labels and to no surprises the replacement unit is a Revision B compared to the previous Revision A unit.

While this is not in any way confirmed by Aastra, we theorize that in later editions of Lync 2013 phone edition some changes were made to the POE signature that caused incompatibilities with the Revision A Aastra 6725ip handsets and HP Procurve swit ches. If you are experiencing similar issues Aastra and very efficient at dealing with issues and promptly shipped me new handsets without any hassle.

The old handset

The new handset

Lync 2013 client popup credentials are required for Outlook

When we started migrating users to Exchange 2013 and Lync 2013, users began complaining of being prompted to enter their credentials for Outlook when starting Lync.

The exact error message is:
Credentials are required
Lync needs your username and password to connect for retrieving calendar data from Outlook

We did some Wiresharking and found this to occur when Lync was connecting to the EWS and Autodiscover Exchange URLs.



The Solution

1. Ensure your internal and external EWS/Autodiscover URLs are in the Internet Explorer local intranet zone. This will be extremely helpful in assisting you to troubleshoot the problem.

2. Logon to your Exchange server and open IIS.

3. Click the EWS directory under "Default Web Site".

4. Open Authentication, click Windows Authentication and then Providers.

5. Remove all entries except for NTLM.

6. Repeat the same for the Autodiscover directory.

7. Restart IIS.

Now restart your client and you should no longer be prompted for Outlook credentials.



Additional troubleshooting tips

Internet Explorer debug tools are great for troubleshooting authentication issues, but first ensure your EWS/Autodiscover URLs are in the Internet Explorer local intranet zone.

A simple test is to go to the EWS URL (http://yourdomain/EWS/exchange.asmx) in Internet Explorer, it should automatically negotiate authentication and show you the service page. If you don't receive the "You have created a service" page then your single sign on is not correctly configured.

1. Open Internet Explorer and press F12 to launch the debug tools.

2. Click Network and "Start Capturing".

3. Now open your EWS URL: http://yourdomain/EWS/exchange.asmx

4. Click "Stop Capturing" and click "Go to detailed view"

You can see the order of the authentication providers and any issues that might have occured during authentication. You can then repeat the same for Autodiscover, remember if Autodiscover can't negotiate pass through authentication then it will prompt the Lync user for credentials.

Integrating Office Web Apps 2013 with Exchange 2013 OWA and UAG gateway

Office web apps 2013 (OWA) is a great way to extend the functionality of Exchange 2013 Outlook Web App and give full Powerpoint viewing functionality in browser. When we built our new Exchange 2013 environment we wanted to offer Office Web apps internally and externally.

After building our environment we had no problems making OWA work internally with Outlook Web App, but externally we always received error messages from OWA.

"Sorry, we couldn't open this presentation because we ran into a problem. Please try again."

Our external Outlook Web App is accessed via a Forefront UAG trunk, however there were no error messages on the OWA, Exchange or UAG servers indicating a problem.

We ran Wireshark packet trace on the OWA server and found that when the request for the Powerpoint web app was established externally, the OWA server tried to establish a connection to UAG. This makes sense as the Powerpoint file needs to be transferred from Outlook Web App to OWA somehow and UAG stands in its way.



The Resolution

1. Create a simple A record in the hosts file of the OWA server.The A record should be the FQDN of your UAG trunk to the internal IP address of your Outlook Web App server, a load balancer address is fine here.

In our circumstance we needed to re-issue the Exchange certificates to include the UAG FQDN in the subject alternate name of the certificate. We tried without re-issuing the certificate but received the same "Please try again." error messages as above. As you would expect the OWA server is rejecting the certificate as it doesn't contain the correct FQDN.

You also need to ensure your OWA server has network connectivity to the HTTPS port of your Outlook Web App server.

While this is a simple fix, it did take us a while to even consider trying this. Now we have lots of happy users able to preview power point and word documents externally.

Outlook & Lync 2013 prompting for authentication with Exchange 2013 Outlook Anywhere

We are currently undergoing a massive migration from Exchange, Lync and Sharepoint 2010 to 2013. The first service being migrated is Exchange, making way for Lync and later Sharepoint. During our Exchange migration it hasn't all been smooth sailing, before we even got started we had to wipe our DAG and start again. However with a little persistence we got a trial DAG up and running and migrated a couple test mailboxes.

As we got into the trial we found some users with Outlook 2013 had single sign on (NTLM) while others were prompted for authentication. This also effected Lync as the UCMAPI service connects to Exchange via Outlook, so Lync was also prompting for credentials when the user logged in. While a password prompt is acceptable for external use, we were not happy with this for internal devices.

Clients that were prompted for authentication were able to single sign on to rpcproxy and EWS with Internet Explorer, so the problem didn't seem server based.

Hours were invested trying to resolve this problem, so of the fixes we attempted were:

• Packet tracing
• IIS log tracing
• Re-creating RPC and EWS directories
• Changing authentication in the Outlook client
• Changing authentication on exchange virtual directories
• Changing IIS authentication
• Adding exchange domains to local intranet zone in Internet Explorer
• Bypassing load balancers
• Client based registry hacks
• Client application re-installation

The Resolution

We were nearly at the point of building a second Exchange environment for testing when we made a breakthrough, I almost feel embarrassed admitting the problem, group policy.

Our legacy Exchange 2010 group policy was set up for RPC internally and https Outlook Anywhere externally, however we never set the MSSTD field, in fact we implicitly removed it with GPO.

As soon as we set the MSSTD field to one of the SAN names of the certificate (wildcards certificates are also fine), the Outlook client single sign on worked perfected and Lync stopped asking for authentication on sign in.

Hopefully you don't waste as much time as we did on this problem.