A Case of the 504s, Revisited

Recently I was working with someone from the technet forums to test their open federation.  I added the contact to my list and sent them a message and immediately received the dreaded 504 error in MOC.  Since this has been a hot topic on the forums and I see lots of searches landing people here for 504 errors I wanted to share again.  I began the troubleshooting process by starting a new debug session on my edge server to grab a SIP trace (see my previous article on the same subject here for more information).  

Just as I had seen before, the 504 error turned out to be DNS related (if your car won’t start it’s probably DNS!)  


Something a little different was going on this time though, the name that wasn’t resolving this time was actually a private FQDN and not the public name of the access edge server, in the results pain of snooper we see the following error:   

Unable to resolve DNS A record”;source=”sip.mycompany.com”;LookupFQDN=”EdgeIntFQDN.partnercompany.local

I checked with my contact at the company and verified I was actually seeing the internal name as I expected and then we had a look at the settings.  It turns out to save money on certificates the company had used one SAN certificate for all roles on the edge server, and put SANs in for each public FQDN with the Subject Name matching the edge servers private name.  Here is how the services/roles were named:

Edge Private Interface EdgeIntFQDN.partnercompany.local
Access Edge Sip.partnercompany.com
Web Conferencing Edge Webconf.partnercompany.com
A/V Edge Av.partnercompany.com

When running through the Step 3 of the edge server deployment, the administrator was able to configure IP addresses and names for each service:

Here is what the access edge FQDN looked like before the new cert was installed:

After the install was completed, a new public certificate was installed.  Here is an example closely matching the certificate they used, notice the subject of the certificate (“issued to:”):

Also, note the SAN fields utilized in the certificate:

Once the new certificate was installed, it was selected for use with the access edge, notice the “FQDN” field is updated with the subject of the certificate (which isn’t the public FQDN of the service):

This same method and certificate were utilized on the web conferencing edge, which in turn broke federation and some portions of external access.

To correct the issue, a new certificate for each role was requested with the subject matching the public FQDN:

Once the access edge was configured with the new certificate, the FQDN populated with the expected value, fixing the issue.

One thing to note here, the A/V service doesn’t actually check the subject name of the certificate, and could therefore be anything you wanted. 

To avoid un-necessary confusion I would make this certificate match the public FQDN of the A/V edge, but there is no reason to use a public certificate here.

Although it is against best practices, I’ve seen a number of companies use the same certificate for all 4 roles.  The catch is, the access edge and web conferencing edge roles will automatically update their own FQDN’s based on the certificates subject name.  Your best bet here is to follow the guidelines Microsoft has provided and have a different certificate for each role.  If you want to save some cash by using just one certificate for all 4 roles, you’ll need to have the certificate re-issued for each role and make sure the subject name of the certificate matches the roles public name or you may very well run into this.  You can also use the edge server planning tool to help you plan for certificates.

Hope this helps


About Kevin Peters

My name is Kevin Peters.
This entry was posted in Uncategorized and tagged , , , , , , . Bookmark the permalink.

3 Responses to A Case of the 504s, Revisited

  1. Pingback: Deploying an Edge Server with Lync « The OCS Guy's Blog

  2. VenkataRamana says:

    Dear All,

    This is good article for us ,

    here i have one question to you ,which Lync Edition you have used for Lync edge server when you installing lync Edge server, is it Lync Standard edtin or Enterprise edition?
    can we use ocs 2007r2 standard edition for ocs 2007r2 edge server if ocs 2007r2 front-end server as configured with ocs 2007 r2 Enterprise edition ?
    please let me know.


    • Kevin Peters says:

      Hello VenkataRamana,

      For Lync you will not need a license for your edge and you can use standard edition. For OCS 2007 R2 you can use a standard edition edge against an R2 enterprise pool as well.

      Hope this helps!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s