• When you import external data from an OData data feed to a workbook in Microsoft Excel 2013, you receive the following error message: 

"The content of the data feed is not valid for an Atom feed."

This issue occurs if the data feed has a custom field that has a lookup table and a graphical indicator.

Sometimes there are legitimate OData feed problems that are data related, rather than code related that can break. For instance, Projects with custom fields that have orphaned Lookup Table references, which can be fixed by simply opening them and republishing. Troubleshooting them to isolate the specific projects can be difficult, but I'd like to share one strategy I've found that works well. It also applies to any consumer of OData feeds, not just Excel.

1. (Using Chrome, since it has a record count feature built into the Find feature) Open your base OData feed to get the first 100 records.
1. https://<SERVER_NAME>/<INSTANCE_NAME>/_api/ProjectData/[en-US]/Projects?$orderby=ProjectName asc
2. Hit Control-F to bring up the Find window in Chrome. Search for “ProjectName”. If there are no failures, you will get “1 of 201” as a record result.
3. If you find a failure, scroll to the bottom, and find the ProjectName of the last project that loaded. This will be the last good project. Sort the Project Center view by project name with no filters in a separate window, to find the name of the next project, and that will be the problem project.
4. Open and publish the project. Once the publish is complete, test again, and repeat steps 3-4 until you successfully get all 201 records from the first set.
5. Now open the OData feed for the next 100 records by injecting the SKIP verb.
1. https://<SERVER_NAME>/<INSTANCE_NAME>/_api/ProjectData/[en-US]/Projects?$skip=100&$orderby=ProjectName asc
6. Control-F again on the result set, and verify 201 results on the “ProjectName” search. If there are no failures, you will get “1 of 201” as a record result.
7. If you find a failure, again scroll to the bottom, and find the ProjectName of the last project that loaded. This will be the last good project. Sort the Project Center view by project name with no filters in a separate window, to find the name of the next project, and that will be the problem project.
8. Open and publish the project. Once the publish is complete, test again, and repeat steps 5-7 until you get all 201 records from the first set.
9. Once that set returns clean, increment the SKIP verb value by 100 and repeat steps 6-8.
1. https://<SERVER_NAME>/<INSTANCE_NAME>/_api/ProjectData/[en-US]/Projects?$skip=200&$orderby=ProjectName asc

 Keep repeating at step 9 until the entire project list loads correctly.

I highly recommend Chrome for this purpose because it loads the XML feed of the OData stream. IE gives you a summary that does indeed have a total record count, but does not list project names unless you View Source on the resulting page, and the Find works better in Chrome for this purpose. You can turn off the Atom View in IE by going to Internet Options, Content tab, select the setting for "Feeds and Web Sites" and turn off "Turn on feed reading view" checkbox. But this doesn't give you the nice visual row counts of found objects that Chrome has.
Pulling the MSP_PROJECTS_USERVIEW table and dropping it in Excel to get an index also helps identify the next project in the list, if you halve the X/200 record count in the find window. (one ProjectName value in the open xml brackets, another in the close brackets, so two per 100 records.)

Keep in mind, this technique of publishing won’t fix the issue with the OData feed being broken between the March and June CU’s. You still need to load the CU.

Hat tip to Dan MacDonald at Sensei Project Solutions for initially putting me on the track of querying with OData verbs to narrow the problem down.

Overview (Things you need)

• A Wildcard SSL Cert.
• Wildcard DNS routing.
• Enable internet endpoint routing.
• Turn on App Management Service and the Microsoft SharePoint Foundation Subscription Settings Service.
• Create Subscription Settings Service and App Management Service app and proxy.
• Configure App Store URL's in Central Admin.

You'll want to familiarize yourself with the official documentation as well.

https://technet.microsoft.com/en-us/library/fp161236.aspx

Wildcard Certificates

There are some items not clearly covered in the documentation above. Like, where to put the cert, how to configure it, etc. I'll go over the items I've discovered, and between that and the documentation, should put all the pieces together for you:

1. DNS name needs a wildcard prefix: '*.Myserver.Mydoman.net'. The asterisk is the standard 'wildcard' element.
2. Friendly Name gets the prefix too. '*.Myserver.MyDomain.Net'.
3. CN of the Subject gets it as well: "CN = *.Myserver.MyDomain.Net'.
4. You want the certificate in the path of the trusted Root signer.
5. You place the cert in the Personal Certificates folder of the Computer's zone, not the user zone when you start up the certificate snap-in to import it.
6. Bind the cert in IIS Manager to your web application.
7. The trickiest part I ran into was, you have to put the server names in the Subject Alternative Name zone of the certificate. Short and long names. Presumably you're running in SSL anyway, so this works for the apps, and the server, Example Subject Alternative Name:

DNS Name=*.ProjectServer
DNS Name=*.ProjectServer.MyDomain.Net

DNS Name=ProjectServer

DNS Name=ProjectServer.MyDomain.Net

DNS Name=MyAppServer1

DNS Name=MyAppServer2
DNS Name=MyWFEServer1
DNS Name=MyWFEServer2
DNS Name=MyWFEServer3
DNS Name=MyWFEServer4

DNS Name=MyAppServer1.MyDomain.Net

DNS Name=MyAppServer2.MyDomain.Net
DNS Name=MyWFEServer1.MyDomain.Net
DNS Name=MyWFEServer2.MyDomain.Net
DNS Name=MyWFEServer3.MyDomain.Net
DNS Name=MyWFEServer4.MyDomain.Net

Wildcard DNS Routing

This piece is covered pretty well in the docs. So I'll skip it, but I'll try and answer any questions that come up. I just create a zone for it.

Enable Internet Endpoint Routing.

This is a proxy and firewall issue. Essentially you're just opening up access for the app store to reach out and hit the MSFT SharePoint store. It's possible to install apps from the store offline, if you can get the author to send you a copy of the installer package, but this is not guaranteed/out of your control, so probably not the best way to handle it. Plan ahead on this piece, because this will likely be a business decision around security, more than a config issue. The Config is generally easy, if your server can hit bing.com, you're there, and this piece is complete.

Enable Services

Very easy, just launch SharePoint Central Admin and click on 'Services on Server'. Turn on both services. But keep in mind, this does NOTHING to configure them, and the subscriptions settings literally cannot be configured through the Central Admin UI. You MUST use PowerShell.

Create Proxies

Enter PowerShell. There's several example scripts out there, they vary in nuance, but this worked great for me. I run them line by line, just in case.

$account = Get-SPManagedAccount DOMAIN\FARMADMIN
$appPool = New-SPServiceApplicationPool -Name SubscriptionServiceAppPool -Account $account
$serviceApp = New-SPSubscriptionSettingsServiceApplication -ApplicationPool $appPool -name "Subscription Settings Service" -DatabaseName "FARMNAME_Subscription_Settings_DB"
$serviceAppProxy = New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $serviceApp
$appPoolAppSvc = New-SPServiceApplicationPool -Name AppServiceAppPool -Account $account
$appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $appPoolAppSvc -Name "AppServiceAppPool" -DatabaseName "FARMNAME_App_Service_DB"
$proxyAppSvc = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc

Pretty easy. Moving on.

Configure URL's

This piece is pretty straightforward. Pop back into Central Admin and click on the Apps section.

Click Configure App URL's, and enter the app domain in the top box: ProjectServer.MyDomain.Net

In the bottom box, enter the prefix for any app that will be running in the farm. I just use "App", nothing fancy.

Troubleshooting

At this point, you should be able to add apps, and things should work great. Note the use of the word 'should'. There are some gotcha's, and items that may not have gotten set correctly.

• The first, and most important, is to keep in mind who you are and where you are. If you are logged in as the FarmAdmin account, you cannot interact with the app store. You'll get cryptic errors.
• Second, you should be in the web app you want to add applications to. Most likely, your app install will be blocked if you entered the app store through Central Admin. Be in PWA or whatever you called your Project Server app when you enter the app store.
• "Sorry, apps are turned off. If you know who runs the server, tell them to enable apps." This must be a catch-all error. Of course, it's caused by setting the option in Configure Store Settings in SharePoint Central Admin to 'no' for allowing users to get apps from the store. Assuming that is not the problem, the error can be very frustrating. Most likely cause is a config piece that sometimes gets set, sometimes not when creating the App Management Service.

In Central Admin go to Application Management and Manage web Applications.

Highlight the web app you need to access the store on (where it is currently failing) and click Manage Features.

Activate the "Apps that require accessible internet facing endpoints" feature at the top. Click ok.

Click Service Connections. Most likely, the App Management Service Application for the '[custom]' connections group, is not checked. Turn it on.

• More specific to the bulk edit apps for Project Server, ensure the oData feed is functioning, or they will never work. You should be able to see Project data at <ProjectServer.MyDomain.Net/PWA>/_api/projectdata/Projects . If you can't, the bulk edit apps won't work. This can be broken by having a reserved name in a Custom Field, such as naming a field "Project ID". If you need that name, try an underscore instead of a space, to make it unique.
• Memory/CPU Consumption. Keep an eye on the W3WP process on your WFE servers. This is also where apps run, and if the app is badly designed or misbehaving, it can potentially bring down your farm. Especially if, again in the case of Project Bulk Edit apps, it allows your user to attempt to load every project and every field on the server.

Hopefully this helps demystify the process a bit, and fills in some of the gaps on the documentation linked up towards the top. Have a great day!