我已经走了一个兔子洞，发现很难知道现在要去哪里。
我有一个报告项目我尝试编写脚本以部署到高度控制的生产服务器上的SharePoint站点。在我的开发盒上，我可以从BIDS部署我的项目并运行报告。如果我将我的rdls，数据集和数据源直接上传到文档库，他们就不会这样做。我做了一些挖掘，发现上传的文件没有以任何方式链接，BIDS做了一些额外的步骤来为共享数据集设置DataSource，然后在Rdls上设置对这些DataSet的引用。
所以我一直在四处寻找，我可以看到我需要在ReportingServices2010.asmx上调用SetItemReferences来定义链接，但我迷失了使用Powershell。我发现的一些脚本专注于设置DataSources，因此我尝试使用其他脚本中的位进行调整，但却迷失了方向。一个例子是$Reference = New-Object -TypeName SSRS.ReportingService2010.ItemReference，但我不知道他们从哪里获得SSRS.命名空间。
顺便提一下，我的结构是： - 一个共享数据源指向SharePoint列表 - 一个指向共享DataSource的DataSet - 四个报告，没有嵌入的DataSources和五个嵌入式DataSet引用，每个引用指向应用各种过滤器的共享DataSet。
是否已有内置方法可以避免麻烦？
这里的要求是我需要一些非常简单的东西，不需要安装额外的PowerShell模块（如果可能的话）。网络受到高度控制，很难让我们自己运行的脚本得到批准，更不用说在Prod的机器农场安装了一些第三方模块。基本上，扫描，测试和正式批准任何插件至少需要六个月，但如果我们编写一个非常简单的脚本，那就容易多了。
答案 0 :(得分：1)
是 - 使用您的浏览器进行部署。我在高度控制的SharePoint 2010生产环境中使用SSRS编写了3个单独的报表项目。其中每一个，我都使用浏览器进行部署。
使用浏览器进行部署比PowerShell更简单。按照一般步骤outlined in the last part of this thread进行操作。通过Powershell做这件事是可能的，但任务要困难得多。
如果管理员对此生产环境进行了如此高度的控制，那么应该存在一个并行的暂存环境，该环境以精确的配置保留为生产环境，可供您使用，以便{SS}报告DevOps。您应该请求在暂存环境中测试您的安装，以便解决您的部署问题（通过浏览器或PowerShell）。如果您拒绝此请求，则需要再次请求。否则，如果你无法在类似的系统上开发，那就不可能完美。
这些报告的DevOps是比赛的最后一英里，如果您是第一个在您的组织中做到这一点的话，可能会很困难。你可以做到这一点，继续前进，你的报告将被安装。保持良好的记录，以便在开发未来报告时，您可以重复此过程，并将成为将来完成此过程的首选人员。不要失去信心。