Anybody who has spent any time troubleshooting SharePoint Server issues, particularly in organizations that are so segmented that the DNS, AD, Network and Database folks won’t work with the SharePoint folks, knows that you have to learn a few tricks to determine if the problems are actually SharePoint problems or the result of DNS, AD, or other misconfigured network appliance. Any time I hear network folks tell me they “optimized” the network for my SharePoint Farm I cringe, wondering what they broke in the name of optimization. Here’s a tip if this happens to you, ask them to prove it. Ask them to show you before and after metrics that prove the optimization actually made a difference. This strategy has worked well in organizations that have some level of change management because it usually results in a pause for the initial state testing, and may provide you with a heads-up that “change is a-comin’”. The thing about configuring your farm for Apps is that many different folks are involved to make it work, some know SharePoint and some don’t, so you have to be able to test “OPC” (Other Peoples Configurations) to be sure they got it right. Remember, Apps are not just for SharePoint Apps, but are also used for things like Access Services (if you choose to deploy it), so this configuration is something you want to get “right”.

The Challenge with Apps

Usually I depend on using my HOSTS file to work around all manner of network and DNS issues, by changing the HOSTS file you can:

• Test SharePoint on URLs that are currently in use on other machines, for example before an upgrade. The production DNS points to the old version of the site, so I use HOSTS entries to direct my machine to the same URL on a new IP Address
• Determine if the network (or an appliance like a load balancer) is the problem. Use a HOSTS entry to route around the appliance virtual IP Address and go straight to a single SharePoint server
• Target a Single Server, similar to the above, use the HOSTS entry to pick a server for testing

The trouble with SharePoint Apps is that the configuration calls for a wildcard address. You cannot configure wildcards in a HOSTS file. Sure, once you have provisioned the App you could copy the address into your HOSTS file, but where’s the fun in that?

Apps Configuration in Review

There are many really good articles available for configuring the necessary services and DNS, but even with these resources, when I actually sat down to do it in a multi-server environment, it gave me pause. So, for those of you who have not gone down this road, here are my abbreviated steps for provisioning Apps in a SharePoint 2013 Farm.

1. Configure DNS for your Apps domain
   • In my case I wanted ‘app-[AppID].app.doghousetoys.com’
   • I followed Mirjam’s post
2. Configure the Service Applications – I started these on the web servers, they are lightweight.
   • Start and Provision the Subscription Settings Service Application
   • Start and Provision the App Management Service Application
3. Configure the App Management Service to use the URL for your App domain. Mine now looks like this:
4. Create a Web Application with NO Host Header – This is where I got tripped up conceptually and found no documentation for multi-server farms. You have to enter a Public URL, but it actually does not matter what URL you use. In my head I saw the machine name and knew that was “wrong”. It turns out it does not matter. Based on feedback from Gary and Spence, I just used the app domain as my Public Address, it doesn’t matter, but this made the most sense. Also, ensure that the application pool is shared with the web applications that will be using the Apps service.
   • Create an App Catalog for the web apps that need one.
   • Upload your App and test the configuration.
   • Test user deployed app
   • Test Tenant deployed app
   • Optional: Configure and deploy Access Services

• This is the most detailed article for the whole process: http://blogs.technet.com/b/anneste/archive/2014/10/31/configure-an-environment-for-apps-for-sharepoint-sharepoint-2013.aspx
• This is the go to article for deploying and troubleshooting Access Services: http://blogs.msdn.com/b/kaevans/archive/2013/07/14/access-services-2013-setup-for-an-on-premises-installation.aspx If that doesn’t help, call Kirk, don’t call me.

Testing Fails

So, here we are, every “i” dotted and “t” crossed and your tests fail miserably. Maybe the DNS team has not had the time to make the changes you requested, or they did and you click the link for your app and you see:

Cue the trombone. What do you do? Well, you could force that URL into your hosts file, but where is the fun in that? You won’t be testing the wildcard.

Another Tool in the Toolbox

Cue the whip crack and the theme song from The Good, the Bad and the Ugly. Acrylic DNS Proxy is a very small DNS proxy that, like Fiddler and other amazing tools, can be used for so much more than this! Once installed you will see a host of menu options (this is Windows 8.1, on Windows 7 you will see similar results)

Apps Troubleshooting

1. Click Edit Acrylic Hosts File.

2. Add a wildcard entry for your apps configuration. In my case I added *.app.doghousetoys.com and the virtual IP address for the farm. If you are troubleshooting the IP address routing related to the VIP, try using the IP address of one of the web servers.

3. Save and close the file.

4. Change your network settings so that Acrylic gets first shot at the routing.

5. Click Start Acrylic Service.

   

6. Test the routing with a ping request like ping foo.app.doghousetoys.com.

7. You should now be able to run your app because Acrylic is doing the DNS work for you.

Wrap It Up

I have to admit, the notion of troubleshooting wildcard DNS had me stumped until I discovered Acrylic. Give this a shot even if you don’t need it right now. It may come in handy in the future.