mercredi 25 mars 2015

Apps: ms.sp.int vs ms.sp.ext



During the set-up of a DR farm, we're facing a weird issue with apps. We have both a provider hosted app as well as a sharepoint hosted app deployed to a site using powershell. The apps are also registered using powershell. In the primary farm, all is well and the apps work ok.


Now because the content db's are synced, the apps move to the DR farm automatically. When you now click the app, SharePoint will throw an error like:



app "i:0i.t|ms.sp.ext|930fc405-2029-4afc-bfe4-8cd7a9f22e15@56775c06-47b3-4957-9b5b-003e2b4b0d23" does not exist.



Which is because the app isn't registered on the DR farm yet. So when we register the app, it starts working. This worked fine for the provider hosted app, but it didn't for the SharePoint hosted one.


When we run the powershell script to register an app, it will register



app "i:0i.t|ms.sp.ext|930fc405-2029-4afc-bfe4-8cd7a9f22e15@56775c06-47b3-4957-9b5b-003e2b4b0d23" does not exist.



But when opening the SharePoint hosted app in the brower, the error will read:



app "i:0i.t|ms.sp.int|930fc405-2029-4afc-bfe4-8cd7a9f22e15@56775c06-47b3-4957-9b5b-003e2b4b0d23" does not exist.



Note that the first reads ext and the second reads int, so they do not match (error is valid from that perspective). I suspect that int = sharepoint hosted and ext = provider hosted, but I haven't found any details on that. The powershell cmdlets only let me register "ext" principals, as there is no way to specify "int" instead. The weird thing is that this does work ok on the primary farm, so aparently the normal installation procedure registers the correct type.


Anyone ever seen this behaviour and perhaps has more indepth knowledge on what's going on behind the scenes?








0 commentaires:

Enregistrer un commentaire