Remove-SPWebApplicationAppDomain..You’re Killing Me

After March 2013 PU was released for SharePoint 2013, new PowerShell cmdlets were brought into this world for setting up the SharePoint App Store. I’m a fan, but noticed something that I’d like to share. Read more about these cmdlets here:

Now take a look at the screenshot and let me know what’s wrong:


OK, here’s what is up. The cmdlet New-SPWebApplicationAppDomain created a new binding for Port 80 for the WebApplication specified. This is because of the way SharePoint Apps work..they don’t play well with host instead of setting up a new web app listening on Port 80 you can have SharePoint add this binding for you. There may be a circumstance down the road where you decide you want to have a site on port 80 and decide to remove the App Domain using Remove-SPWebApplicationAppDomain. You take a look in more Port 80 binding. BUUUUT when you go to create the new web app you get thrown an error message saying “The IIS Web Site you have selected is in use by SharePoint. You must select another port or hostname.” BWOMP

I can run remove/add-spwebapplicationappdomain commands all day and it’ll create and delete the binding in IIS but running the PowerShell commands above you can see that even though IIS is cleaned up, the config database still sees that binding.

At this time I haven’t found a great fix..but here’s what I got (I have tested this on multiple SharePoint 2013 servers..the latest being one with September 2014 CU):

Change the port using PowerShell.


Since this is affecting the Default zone only you could extend the web app to a temp URL, delete the Default Zone, and extend the original URL back to the default zone, and delete the temp URL zone. I go through this procedure because of custom solutions deployed to the farm. If you delete all zones, things just don’t seem to work right.

SharePoint 2013 App Part – This content cannot be displayed in a frame

I have been working on a project to setup SharePoint 2013 Apps. Setup went smoothly in test, but when I did the setup on prod something didn’t seem right. Here are the hurdles I had to overcome:

  1. Since the environment is using host headers (which use the server IP address) we had to bind an additional IP address to the NIC. This is because since the wildcard certificate for the primary domain already exists for the main site, we cannot attach the wildcard certificate for the app domain unless we bind an additional IP address and change the CNAME to a wildcard A Record pointing to the new IP (Or create a new A record and then point the CNAME to that..Too much work!).
  2. Now that everything was properly configured and I was able to ping and it returned the new IP address we went ahead and added an app part to a team site. We got an unexpected message where our beautiful SharePoint app should be: “This content cannot be displayed in a frame”…UUUUUGHHHH!
    1. contentiframeerror
    2. If I click the “Open this content in a new window” link it will open a sign in screen. Hmmmm
      1. fbalogin
    3. Now I started comparing differences between test and prod and noticed that the default zone on prod has FBA enabled and doesn’t on test. I was able to replicate this on test by enabling FBA for the default zone. Luckily we don’t need FBA on the default zone and only the extended zone (in this case extranet) so I disabled FBA and called it a day. If you need FBA enabled on the default zone you could create a custom login page that forces integrated authentication.


SharePoint 2013 – Requesting Apps using the App Catalog

After a SharePoint 2013 environment has been configured for Apps, by default the SharePoint Store is open for all farm administrators and anyone with Site Owner/Full Control access to a SharePoint site. If you are using non-default permission levels you need the “create subsites” and “manage web site” permissions to add an app for SharePoint. There is no way of keeping site owners from of browsing the SharePoint Store, but we can configure the environment so that they must request an app from the store and only specified administrators can approve these requests.

To suit this requirement Microsoft created the App Catalog. There can only be one app catalog site collection (Yes, it is its own site collection) per web application. The setting to keep site owners from downloading apps directly is set in Central Admin > Apps > Configure Store Settings. If there is no App Catalog setup you will receive the following error: “Sorry you need to create an app catalog site…” Hit back and go to Manage App Catalog. During the creation of the new App Catalog (With the familiar site collection creation screen) you will be asked to add a Primary Site Collection Admin and End Users. The Primary Site Collection Admin is your “App Gatekeeper” and the End Users are the site owners that you want to be able to see apps from the app catalog.

Once the App Catalog is all setup you can go back to the Configure Store Settings page and you should see the following options (The default for the first option is Yes, but I moved it to no so site owners cannot acquire apps directly):


Now, if a site owner goes to add an app for the SharePoint site they will be able to search the SharePoint Store, but when they click the App they will be presented with a Request It option instead of a Add It option (If the checkbox was marked as yes from the previous screenshot)

clip_image003 Vs. clip_image005

Once the site owner clicks Request It, they will need to specify licensing options (How many user licenses or is it for everyone) and an optional “request justification” field. Once the site owner submits the request, it will show up in the App Catalog’s “App Requests” List:


From here the App Catalog Admin(s) can approve or decline app requests. Once the status has been changed to Approved the App Catalog Admin will need to go to the SharePoint Store and acquire the app. This is done by clicking the link next to View App Details on the App Request entry:


Once this is done the site owner can check the “Your Requests” list and notice the status of their request. After the App has been acquired and approved the App will show up in the “Apps You Can Add” list.


Setting up Yammer with On Premise SharePoint 2013 Start To Finish

I went through and did an entire setup for on premise SharePoint 2013 and how to integrate Yammer using the app in the SharePoint Store. This covers all the prerequisites such as setting up the service applications, configuring DNS, and then goes over the changes that must be made in SharePoint to replace SharePoint social features with Yammer features. Check it out:


SharePoint 2013 App Environment Configuration

After working through a few issues with the App Management Service Application I figured I should blog my findings. The App Management service actually needs another service application created before it’ll work properly: The Subscription Settings Service Application (See here for instructions on setting it up – It can only be configured with PowerShell:

After setting up this Service Application the “Microsoft SharePoint Foundation Subscription Settings Service” needs to be started in order for Apps to work. In 2010 this was only for multi-tenant installations, but there is now a dependency for apps.

After setting up the appropriate services you need to configure a generic web application that has a blank host header and listens on port 80. Because of how the redirect for the app domain works IIS will try to resolve the app URL by using the default IIS web site, which of course doesn’t work. This appears to be fixed in the March 2013 Public Update  (

One gotcha here is that if the NETBIOS name of the server is longer than 15 characters make sure that the generic web application is equivalent to this. Do not go in and change the URL to the full server name as this causes issues!

Here’s a quick checklist to go through when setting up the App Environment:

  1. Create a fwd lookup zone for apps (
  2. Create a CNAME alias from app domain to SharePoint Domain
  3. OPTIONAL: Wildcard SSL Cert for app domain
    1. Note: If you have a wildcard certificate for *, you would need to purchase another wildcard certificate for * if you are using a subdomain as your app domain. Microsoft highly recommends that you create a new domain name for apps.
  4. Create the Subscription Settings Service Application using PowerShell ONLY
  5. Start the Microsoft SharePoint Foundation Subscription Settings Service
  6. Configure the App Management Service Application (Central Admin or PowerShell)
  7. Configure App URLs in Central Admin (App Domain and App Prefix)
    1. Note: Anytime you make a change to this you need to do an IISReset
  8. OPTIONAL: If using Host Headers you will need to create a generic web app that has a blank host header and listens on port 80 (Or 443 if you are using HTTPS). (Unless March 2013 Public Update is applied)


Edit 8/7/13: For a full setup with screenshots check out