让’s say you’ve决定将某些自定义功能作为SharePoint 2013应用程序提供给您的用户。您’ve决定将其发布到适当的内部SharePoint App Catalog中（而不是在公共SharePoint Store中可用）。在大公司里’即使我们希望所有人都可以使用该功能，期望所有用户安装此类内部应用程序可能也不现实。
答案*可能*是使用其中一种在以下位置部署应用程序的选项：“tenant scope”. 这适用于本地部署和Office 365 / SharePoint Online。 本文着眼于这些选项，但只是为了提醒我们整个系列的位置，以下是目录：
- SharePoint 2013应用–架构，功能和UX注意事项
- 入门–在SharePoint应用程序中创建列表，内容类型，字段等（配置）
- 在应用程序网络中使用数据以及为什么要这样做
- 从SharePoint 2013应用访问最终用户数据（在宿主网站中）
- 将SharePoint 2013应用推广到企业-租户范围和PowerShell安装 [本文]
- Azure是新的SharePoint‘_layouts’ directory
- “Host web apps” –将文件（例如母版页）设置到主机网站
- “Host web apps” –设置字段和内容类型
- 将SP2013提供程序托管的应用程序/远程事件接收器部署到Azure网站（用于Office 365应用程序）
- 在SharePoint应用程序中使用Web部件
- 部署到命名网站集
- 部署到特定托管路径下的所有站点
- 部署到通过特定网站模板创建的所有网站
我说*可能*。以这种方式部署应用程序时，需要注意一个关键的细节–可能是非常理想的交易或破坏交易的交易。本质上，该应用程序的所有已安装实例*共享*一个应用程序网站。这意味着您在应用程序中提供的所有列表或库都将在安装该应用程序的所有网站之间共享。正如我所说，这可能正是您希望应用程序运行的方式，或者完全反对它’s design.
使用此模型的过程如下：
- 将应用上传到应用目录。
- 安装 该应用程序到App Catalog网站集–是的，对于这种情况，我们实际上必须在该位置安装应用程序（原因将在稍后阐明）。
- 转到“网站目录”页面并找到该应用程序。在此处（仅此处）的标注菜单上，您’会有一个动作标记为‘DEPLOYMENT’:
- 点击‘DEPLOYMENT’按钮转到管理页面。
在此页面上，我看到了3个部署选项–单个网站集：
..或部署到受管路径下的所有站点，或从某个模板创建的所有站点：
一旦您’几分钟后，选择了适当的选项并单击“确定”。’会发现您的应用已登陆目标位置：
您可能会猜到’一个执行部署的计时器作业。这是 应用安装服务 计时器作业，默认情况下设置为每5分钟运行一次。
租户范围内的应用程序安装的重要方面
如前所述，所有应用程序实例共享一个应用程序网络。它的工作方式是 安装到App Catalog网站的实例将用于所有实例 –无论用户从哪个站点进入应用程序，有效地始终将用户始终重定向到应用程序域上的此URL：
那里 are also important by-products of this:
- 安装了该应用程序的站点中的用户无法删除该应用程序–不管他们在那里的权限
- 这是有道理的，因为它们将有效卸载所有人使用的
- 个人“usages”的应用程序不会被报告 Get-SPAppInstance –仅返回App Catalog网站中的实例（注：仅适用于本地SP2013）
对应用程序的任何更改（例如，应用程序升级，应用程序删除）都需要在安装到“应用程序目录”网站上的实例中进行管理。
但是我想要其他东西-批量发布我的应用程序，但事实并非如此 “single instance”
那么在这种情况下，PowerShell是您的朋友–这是安装新应用的两步过程：
- 采用 导入SPAppPackage 最初将应用安装到网站集中，然后..
- 采用 安装SPApp 安装到单个网站
有关SharePoint 2013应用程序的cmdlet的完整列表，请参阅 SharePoint 2013中的App Management Service cmdlet 在TechNet上。 Corey Roth在其中一些cmdlet上也有贴子.
如果你’重新安装在Office 365上’有限的PowerShell cmdlet集（截至2013年4月），您’我需要使用一种客户端API来完成同一件事。 I’m开始形成.NET CSOM代码的视图“wrapped”使用PowerShell是执行此操作的好方法–因为它可以与TFS自动构建等集成。
应用安装愉快！
12条评论：
I've understood that this "batch installation" also has limitations as to what kinds of artifacts the app is allowed to install (see http://msdn.microsoft.com/en-us/library/fp179896.aspx), e.g. app parts and custom actions can not be provisioned to host webs.
还有，我们'使用Install-SPApp cmdlet时，应用程序权限存在一些问题。即，该应用需要在主机网络上手动受信任才能使其运行。您是否遇到过类似的问题？
@Jarno，
同意这两个观点。首先，我'd想认为以后的更新*可能*会改变这一点-我可以'真的想过任何必须这样做的技术原因。
但是，在第二个步骤中，显然Install-SPApp有效地跳过了应用安装程序同意该应用的步骤's权限请求。它仍然需要在某个时候发生。它'关于是否也可以使用PowerShell完成这一问题，这是一个有趣的问题-我还没有't yet looked.
显然，这一切都没有'不适用于租户范围的应用程序，因为将其安装到“应用程序目录”网站的人当时同意了“权限请求”。
干杯，
克里斯。
克里斯，你好
我已经在我的Prom应用程序目录中安装了自定义应用程序，这是一个由Prom Provider托管的应用程序，但是我可以'将我的应用程序部署到理想的网站集中，并收到一条错误消息："输入的网站集无效。"!!
您以前遇到过此问题吗？有什么建议吗？
干杯，
帕尔
@Parham，
这发生在你'重新尝试指定与您的应用程序目录无关的网站集'重新合作。请记住，应用目录是在Web应用程序级别关联的。
有效地你're going "across the boundary"，并且需要更改指定的应用目录或网站集。
HTH，
克里斯。
你好
我遇到了像Jarno这样的有关手动信任的问题。有没有一种方法可以设置可被Powershell信任的应用程序？
嘿克里斯，
"If you’重新安装在Office 365上’有限的PowerShell cmdlet集（截至2013年4月），您’我需要使用一种客户端API来完成同一件事。一世’m开始形成.NET CSOM代码的视图“wrapped”使用PowerShell是执行此操作的好方法–因为它可以与TFS自动构建等集成。"
您将如何在office365中做到这一点？
@匿名，
实际上，PowerShell正在调用客户端API之一而不是服务器API。您'将需要运行PowerShell的盒子上的客户端API位。
这里's是Anders Rask的示例，用于导入SP2013搜索配置（托管属性等）- http://andersrask.sharepointspace.com/Lists/Posts/Post.aspx?ID=42
HTH，
克里斯。
我没有找到任何通过内置的SharePoint PowerShell cmdlet信任应用程序的方法。但是，我写了一个'workaround'相信它对我足够好。基本上，我使用PowerShell Internet Explorer自动化来完成此任务。
这里 is my sample code, you'll need to modify a few things etc to get it work, but hopefully is a good starting point. I am using this as part of my TFS Build process that builds the app, installs the app, and now trusts it automatically. I used //officesharepointci.codeplex.com/ for this and then modified it to add this:
写主机"尝试信任该应用..."
$ authorizeURL ="$($web.Url.TrimEnd('/'））/ _ layouts / 15 / appinv.aspx？AppInstanceId = {$（$ appInstance.Id）}"
写主机"Loading url:" $authorizeURL
$ oIE =新对象-com internetexplorer.application
尝试
{
$ oIE.visible = $ true
$ oIE.navigate2（$ authorizeURL）
睡眠-第二个
而（$ oIE.busy）{
睡眠-毫秒50
}
写主机"Loaded Page:" $oIE.Document.Title
睡眠-秒5
$ button = $ oIE.Document.getElementById（"ctl00_PlaceHolderMain_BtnAllow")
如果（$ button -eq $ null）
{
写主机"找不到要按的按钮"
写主机$oIE.Document.documentElement.outerText
}
其他
{
写主机"找到[信任]按钮，单击..."
}
$ button.click（）＃单击按钮，即使它出错（这也会使TFS Build Red错误显示）
睡眠-第二个
而（$ oIE.busy）{
睡眠-毫秒50
}
写主机"Now we're on page:"$ oIE.Document.Title" - " $oIE.LocationURL
＃如果成功按下按钮，我们现在应该在“网站设置”页面上。
如果（$ oIE.Document.title -like"*trust*")
{
写主机"Error: "$ oIE.Document.body.getElementsByClassName（"ms-error").item().InnerText
扔（"Error Trusting App:"+ $ oIE.Document.body.getElementsByClassName（"ms-error").item().InnerText)
}
其他
{
写主机"应用程序被成功信任！"
}
}
最后
{
$ oIE.Quit（）
}
@大卫，
不错的工作！善于使用IE自动化，尤其是在构建过程中。
感谢分享！
克里斯。
@大卫，
该解决方案运行完美。使用IE屏幕没有't even occur to me!
那里'也是一种自动化应用程序部件安装的方法。通常你可以't导出应用程序部件，我怀疑他们将导出模式设置为"Do not allow"因为.webpart文件包含一个引用宿主Web的GUID（显然总是不同的）。
您可以做的是导出应用程序部件（只允许首先从Web部件导出它）'的设置）。如果打开.webpart文件，则您'll notice there's具有名称的属性元素'ProductWebId'在文件中。它包含原始应用程序部件从中导出到主机网络的GUID，并且在导入.webpart文件时需要在运行时替换它。
因此，只需将.webpart文件读入内存，然后将该文件添加到网络中，请修改ProductWebId元素'的值，以反映新宿主网站的ID。然后，您可以像其他任何导出的Web部件一样以编程方式添加它。
I'我很确定您也可以完全以编程方式添加ClientWebPart，但是我还没有't tried that yet.
但是再次感谢David，通过以下步骤，我现在可以自动化应用程序和应用程序部件的安装：
1）将应用上传到应用目录
2）将应用程序安装到网络上（使用您的方法）
3）通过更改ProductWebId guid将导出的应用程序部件安装到页面上
亚诺
@Jarno，
也很酷。那么，您是使用CSOM还是其他远程代码来执行此操作？
谢谢，
克里斯。
谢谢克里斯和所有评论者。这篇文章已经发布了一段时间，只是想看看是否有关于通过Powershell安装应用程序并信任它的方式有任何更新。最后的解决方案是IE脚本。有人吗
同样，似乎仍不支持具有自定义功能区操作的应用程序的批量安装:(因此，我们'重新考虑执行批处理powershell脚本来进行安装。
发表评论