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”.
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:
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?
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.
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.
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)
Click Edit Acrylic Hosts File.
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.
Save and close the file.
Change your network settings so that Acrylic gets first shot at the routing.
Click Start Acrylic Service.
Test the routing with a ping request like ping foo.app.doghousetoys.com.
You should now be able to run your app because Acrylic is doing the DNS work for you.
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.
Ready to start your next project with us? That’s great! Give us a call or send us an email and we will get back to you as soon as possible!