SharePoint Experts, Information Architects, Expert Witness

SICG provides a broad array of business and technology consulting from architecture to design to deployment of global systems with a focus on surfacing data in the enterprise. We focus on the "How", not just the possible. Contact me direct: or call 704-873-8846 x704.

Search This Blog

Friday, February 8, 2013

Configure Apps for SharePoint 2013 and unable to set DNS CNAME record

Following up a great post by Gauray Mahajan in configuring Apps for SharePoint 2013 - this is the 'back side' of the App setup done through Central Administration and absolutely necessary for your Apps to work. You can read his Post here.

In the basically four steps he outlines - setting up DNS, enabling the services then setting up the Application Services and Proxies (using PowerShell*). If you follow his instructions to the letter, it will all work.

However, one issue I came across a few times is in setting up CNAME record in DNS. If you follow his instructions, it may or may not work so here's how to get around it.

When you first setup the DNS CNAME record (as he outlines), the entry will look like this (in my case, the DNS is simply

When you click OK, you might unfortunately see this message when you try to save the record:

So this tells you a lot right? Right. So after a little checking around, this somewhat generic message really won't help even though it is properly set so here's the work around. When you first create the CNAME record, don't specify the FQDN:

Click OK to save the record (this should work). Once it is created, right click on the new entry and select Properties - when the popup appears you can now specify the FQDN (in my case again, this is simply Click OK and the record will be updated properly!

OH - One other thing; in some cases I've had to reboot the Front End server to make sure it picks this up (before you start the work there).

* I think PowerShell is great - however I think it is extremely lazy on MS's part to defer to it when setting up crucial services instead of enabling these through the UI. Not to mention, it hampers developers (who generally don't have this access) and means the Administrator has to spend a lot of time learning it. While in the Developer Kitchens in Redmond, I did voice this issue - someone at Microsoft REALLY likes to type or never got out of their Unix/Linux command line habits!