I recently left my old position and started working at our University’s Computing Centre. This also meant changes to my job assignments. I’m now deep diving into Exchange, Lync and SharePoint. All of this will of course take (a lot of) time and I decided to start from scratch with a Test Lab Guide (TLG) – Test Lab Guide: Configure an Integrated Exchange, Lync, and SharePoint Test Lab. (No need to break peoples calendars just yet 🙂 ) This TLG will be the base for all my testing from now on so it’s important to get it working properly. I got the basics up ‘n running quite fast, but then more and more trouble arose. I followed the guide to the letter, but to no avail. Google was short on answers, so the problems needed to be split up into smaller chunks. The main problem was to configure cross-product integration with all the servers. In order for the Exchange, Lync, and SharePoint servers to participate in cross-product scenarios and solutions, they must be configured to trust each other through server-to-server authentication trusts (OAuth). There’s a script (https://technet.microsoft.com/en-us/library/jj204975.aspx) for this, but it didn’t work for me 😦 (Well, might actually work better now when I have better basic understanding of what the script do. It probably also works better now that the certificates are configured correctly).
I got lots of error 401 and/or SSL errors, for example:
Cannot acquire auth metadata document from ‘https://sp1.corp.contoso.com/_layouts/15/metadata/json/’. Error: The remote server returned an error: (401) Unauthorized)
Cannot acquire auth metadata document from ‘https://sp1.corp.contoso.com/_layouts/15/metadata/json/’. Error: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
After much digging around I came to the conclusion that it has to do with the servers’ certificates. I had certificates set up for auto-enrolment, but they somehow didn’t get auto-enrolled on the servers. A small detail, perhaps, but it took me forever to figure this out. I had to manually request the AD published certificates (https://technet.microsoft.com/en-us/library/cc730689.aspx). It’s like begging for trouble playing around with self-signed certificates in an environment like this so I’m glad I got it sorted out.
The problems didn’t disappear even though I was using certificates signed from the Domain CA. The https binding in IIS defaults to whatever it feels like, so you have to change the https site binding to the certificate issued by your CA. Information about IIS site bindings can be found here http://www.orcsweb.com/blog/mark-newnam/how-to-set-up-site-bindings-in-internet-information-services-iis/ or here http://blogs.technet.com/b/chrad/archive/2010/01/24/understanding-iis-bindings-websites-virtual-directories-and-lastly-application-pools.aspx for example. After this was done everything was already much better.
Still, the script wouldn’t work. Step by step I decided to manually try stuff from the script instead. After much fiddling I got it working (don’t even remember how anymore, but it was a lot of trial and error). I did at least the following things (scroll backs in PowerShell and memory dumps from my head):
On the Exchange server (the first server that got all the server-to-server trusts working):
Fig. 1. Partner with Lync
Fig 2. Partner with SharePoint
Checking partnership with Get-PartnerApplication:
Fig 3. Get-PartnerApplication
Everything OK!
Source: https://technet.microsoft.com/en-us/library/jj649094%28v=exchg.150%29.aspx
On Lync server:
Fig 4. Partner with Exchange
Fig 5. Partner with SharePoint
Checking partnership with Get-CsPartnerApplication:
Fig 6. Get-CsPartnerApplication
Everything OK!
Source: https://technet.microsoft.com/en-us/library/jj205253.aspx and https://technet.microsoft.com/en-us/library/jj204975.aspx (This was the failing script for me, so I did it in stages as in the screenshots above). Many more sources also which I can’t remember…
On SharePoint server:
Fig 7. Partner with Exchange (never mind the error, the partnership was already done).
Fig 8. Partner with Lync
Checking Get-SPTrustedSecurityTokenIssuer:
Fig 9. Get-SPTrustedSecurityTokenIssuer
Seems OK! The permissions on the SharePoint 2013 server was already set up at an earlier stage:
At the Windows PowerShell command prompt, type the following commands:
$exchange=Get-SPTrustedSecurityTokenIssuer $app=Get-SPAppPrincipal -Site http://<HostName> -NameIdentifier $exchange.NameId $site=Get-SPSite http://<HostName> Set-SPAppPrincipalPermission -AppPrincipal $app -Site $site.RootWeb -Scope sitesubscription -Right fullcontrol -EnableAppOnlyPolicy
Source: https://technet.microsoft.com/en-us/library/jj655399.aspx, https://technet.microsoft.com/en-us/library/jj670179.aspx
Well, I learned a lot yet again. I had to dig into much other stuff as well, but at least it was easily done with Google. The main problems were certificates and server-to-server trust issues. The TLG itself was very nicely written, although it didn’t work as expected for me. None the less everything is now set up and working so I can continue doing all kinds of tests. This test-environment will help me A LOT on my journey with Exchange, Lync and SharePoint. Wish me luck, I know I’m gonna need it 🙂
My next experiment will be to add another exchange server (or two) and use Database Availability Groups (DAGs). (Actually already done using the excellent guide at http://exchangeserverpro.com/exchange-server-2013-database-availability-groups/)
I’ll also be looking at High Availability for the CAS. Stay tuned!
More useful sources (out of the millions I already found):
http://memphistech.net/?p=280
https://digitalbamboo.wordpress.com/2013/09/24/setting-up-exchange-unified-messaging-with-lync-2013-integration-for-voicemail/
http://blog.insidelync.com/2012/08/the-lync-2013-preview-unified-contact-store-ucs/
https://mchahla.wordpress.com/2013/01/12/integrating-lync-server-2013-exchange-server-2013-owa/
A random blog from a sysadmin 