Troubleshooting App Configuration in SharePoint 2013

Troubleshooting App Configuration in SharePoint 2013
3 votes, 4.33 avg. rating (87% score)


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

  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.

  5. Create an App Catalog for the web apps that need one.
  6. Upload your App and test the configuration.

    • Test user deployed app
    • Test Tenant deployed app
  7. Optional: Configure and deploy Access Services

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 * 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

  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.


This is good post worth reading and very good content which helped me for my app. It is cross post added as is to preserve the quality

Author: Matthew Mcdermott, MVP, trainer at Critical Path Training


July 3, 2015 · Adi · No Comments
Tags: , ,  · Posted in: Apps, SharePoint 2013

Leave a Reply

What is 10 + 5 ?
Please leave these two fields as-is:
IMPORTANT! To be able to proceed, you need to solve the following simple math (so we know that you are a human) :-)