Handling SimpleURLs and Reverse Proxy during migration

I’ve thought about writing this post for a while, as the topic isn’t really covered very well in the Lync 2013 migration documentation. The issue is also only relevant when migrating from Lync 2010 to Lync 2013.

The scenario is this: You are doing a migration from Lync 2010 to Lync 2013. You are following the migration steps provided in the migration documentation, and have planned and prepared your migration, deployed a pilot pool and moved some pilot users to Lync 2013. Internally everything is working as it should,  all modalities are working and conferencing works via the meeting join page using simple urls regardless of which server the user is on.

Now, most of the deployments I do are not large enough that it is needed to use more than one FE pool and for external access one Edge pool and one reverse Proxy. Because of this, most of the conferencing going on is involving external participants. This means that modalities and meeting join needs to be working for the pilots in external scenarios as well. The next step in the migration documentation covers some of this with the deployment of the Edge server. This will handle the peer to peer modalities, but what about the simple URLs?

If you try to reuse the existing reverse proxy rules, you will end up in one of these situations:

  1. You keep the rule as it is, pointing toward the Lync 2010 pool
    If you do this, simple URLs and meeting join will continue working for meetings created by the Lync 2010 users. But if someone external tries to join a meeting created by one of the pilot Lync 2013 users, they will be met with a page saying “Sorry, something went wrong, and we can’t get you into the meeting.” and if you click on “more info” you will get en error saying “Error:Invalid Conference organizer or Conference ID” like this:
    meetingjoinerror
    The Lync 2013 pilot users will also not be able to log in via the mobile client.
  2. You change the rule, pointing it toward the new Lync 2013 pool
    If you do this, everyting will work as it should for the Lync 2013 users. But if someone tries to join a meeting created by one of the Lync 2010 users, they will be met with an ordinary IIS “404 not found” page
    404

Both of these solutions are not really wanted in a normal migration, so what do we do then? The solution is to handle it as a normal multiple pool deployment. This is as it turns out not really well documented in the TechNet library, but on the Request and Configure a Certificate for Your Reverse HTTP Proxy page there is a note saying this:

If your internal deployment consists of more than one Standard Edition server or Front End pool, you must configure web publishing rules for each external web farm FQDN and you will either need a certificate and web listener for each, or you must obtain a certificate whose subject alternative name contains the names used by all of the pools, assign it to a web listener, and share it among multiple web publishing rules.

This means that you will need to deploy a new reverse proxy publishing rule for the new Lync 2013 Pool with a different DNS name for the external services. The rule will also need to use a certificate that contains all the simple URL names in addition to the new name for the external web services and lyncdiscover. This will in most cases create a need for a new public certificate for this new rule.

By doing this Lync is able to redirect the traffic to the webservices between the reverse proxy rules as it does on the inside, and all functionality should be available for both existing Lync 2010 users and the Lync 2013 pilot users.

Creating certificates for Codian MCUs

If you want to use HTTPS (without the annoying browser certificate warnings) or MTLS with a Codian MCU, you’ll need to install a certificate on the MCU.

Remember that you’ll need the “Encryption” release key to enable SSL in any form. This is a free key that kan be ordered from TAC.

Under Network -> SSL certificates, you’ll find this screen:

Certificate config

So we need to provide a certificate and a private key corresponding to the certificate, which means that we need to create a CSR and import both the key and the certificate to the MCU.

I’ll show how to do this using openSSL and a Windows CA. If there is an OCS/Lync implementation in the environment, you could use the wizard to create the cert, but you would have to split it up with something like openSSL afterwords anyway, so the easiest thing is just to create it all with openSSL.

openSSL can be found for almost any platform, I use openSSL for win32 

Create the CSR

Use this command to create the CSR

openssl req -new -newkey rsa:2048 -nodes -out <name_of_the_cert>.csr -keyout <name_of_the_key_file>.key -
subj "/C=<countrycode>/ST=<state>/L=<City>/O=<Organisation>/OU=<Organisational Unit>/CN=<fqdn.of.mcu>"

Exchange all the <variables> with the correct values.

This should create two files, <name_of_the_cert>.csr and <name_of_the_key_file>.key and place them in the same directory as you run the command.

Create the cert

Copy the .csr file to the CA. In a cmd window, navigate to the folder you copied the .csr to and run:

certreq -submit -attrib "CertificateTemplate: WebServer" <name_of_the_cert>.csr

If the CA is configured to issue certs automagiacally, you should have be asked where to save the .cer. If not, you’ll have to open the CA MMC snapin and issue the cert manually.

Add the cert to the MCU

Back on the MCU, browse to the .cer in the Certificate field and the .key in the Private Key field. Leave the password field empty. Restart the MCU and you should be good to go.

Creating a trust store

The trust store to be uploaded needs to be in .pem format. Export the root certificate you need to trust to a DER encoded file. (normally .cer) and run the following command:

openssl x509 -inform der -in <rootcert>.cer -out <rootcert>.pem

<rootcert>.pem can be uploaded as the trust store. 

Address book issues

I had a weird problem with an 2007R2 installation last week. The addressbook had stopped working. I checked all the normal errors, certificates and IIS on the FE, but everything seemed to be just fine. The addressbook files were created, and I could download all files in the browser. Everything seemed to be normal, except that the clients were giving the error about not being able to download the addressbook.

After a bit of searching the internets, I came across this. Seems that there was some new functionality added to IE8 where it refuses the certificate if the CRL is unreachable.

The solution is either to fix the CRL, or to uncheck “Check for server certificate revocation” under advanced settings in >IE8.

Communicator phone edition certificates, Standalone CA

I recently was installing OCS in a domain where we for some reason could not use an enterprise CA, so a standalone was installed. This works fine on the MOC clients, but it was a problem when we were trying to use Communicator Phone Edition.

According to the phone ed. deployment guide, the CPE gets the certificate from AD like this:

1.   The device searches for Active Directory directory objects of category certificationAuthority. If the search returns any objects, the device will use the attribute caCertificate. This attribute is assumed to hold the certificate and the device will install the certificate.

The Root CA certificate must be published in the caCertificate for Communicator Phone Edition. To place the Root CA certificate in the caCertificate attribute, use the following command:

certutil -f -dspublish <Root CA certificate in .cer file> RootCA.

2.   If the search for Active Directory objects of category CertificationAuthority does not return any objects, or if the objects have empty caCertificate attributes, the device searches for Active Directory objects of category pKIEnrollmentService in the configuration naming context. Such objects exist if certificate AutoEnrollment was enabled in Active Directory. If the search returns any objects, it will use the dNSHostName attribute returned to reference the CA and it will then use the Web interface of the Microsoft Certificates Service to retrieve the Root CA certificate by using the HTTP GET command http://<dNSHostname>/certsrv/certnew.p7b?ReqID=CACert&Renewal=-1&Enc=b64.

If neither of these methods succeeds, the device displays the error message “Cannot validate server certificate” and the user is unable to use the device.

The certutil command described above requires you to have necessary rights in the forest, which we didn’t have.

The solution ended up being:

* Run the server 2k3 reskit tool pkiview.msc
* Right click Enterprise PKI and choose Manage AD Containers
* In the NTAuthCertificates tab, add the root certificate of the standalone CA

That should be it! When we did this the phones started downloading the right certificate.

Edit: This might not be working perfectly. Some phones use an extreme amount of time downloading the right certificate. Might be the messy PKI in the forest being the problem, but i will need to test this some more…