2015年4月16日,星期四

Improving the Office 365 SharePoint混合experience

早在2014年2月,我写了 Office 365 SharePoint混合–你做什么和不做什么。在那篇文章中,我讨论了一个事实’关于混合的讨论很多,实际上很多组织在这个领域做一些事情–实际上,微软提供的是 从交钥匙解决方案那里’s quite a long list of 东西 you need to work on. That is, if your organization wants to provide any kind of “joined-up”对于最终用户而言,跨云中的站点和本地SharePoint环境中的站点的体验都很好。

It’可以这样说,目前,来自Microsoft的混合动力确实包括:

  • 搜索
  • BCS
  • A model for personal sites (OneDrive for Business sites) to live in the cloud, with some navigation for users, when other 东西 are on-premises

The list of 东西 you don’t get includes 东西 like (N.B. the 较早的文章 有更完整的列表):

  • 全球导航
  • 全局站点目录
  • A 联手 social experience (unless you use Yammer)
  • 任何形式的同步:
    • 品牌推广
    • 客制化
    • 分类法/托管元数据
    • 内容类型
    • 应用
    • 用户资料数据

..等等。

我完全希望SharePoint 2016可以改善这种情况–我认为这将是该产品的重点关注领域。但是在2015年4月,对于大多数人来说,尚需投入相当长的时间才能生产SP2016。

改善混合动力的常见要求–用户个人资料,分类和用户照片

从那以后我’我曾参与多个混合部署,并参与了缩小混合差距并改善体验的工作。在这篇文章中,我想谈一谈我的团队和我所涵盖的一些领域– what we’已经实施,我们的经验是什么。从我现在的立场来看,我仍然认为从某些方面来看(至少目前如此)混合动力是最复杂的选择。如果您可以选择仅运行所有SharePoint“things”在Office 365中,您可以一举降低复杂性,成本和工作量!但是,这不是’在所有可能的情况下,我都会与越来越多的组织进行交流,这些组织正在努力消除本地SharePoint,而支持SharePoint Online–但要到达那里需要时间。因此,在许多情况下,混合动力绝对有意义。

For 一 客户 in particular, we focused on solving three core problems:

用户资料

由于混合有效地为每个用户提供了两个完全独立/断开的用户配置文件,因此我们想提供 用户编辑个人资料的位置,更改已复制到其他位置。我们选了 本地SharePoint配置文件 作为“editable master”,因为在这种情况下(通过BCS)以及自定义AD字段已​​经集成了来自其他本地数据源的数据,因此已经进行了一些投资。我们的工作是将更改复制到SharePoint Online用户配置文件(尤其是不同步自定义/组织的字段)’d通过Azure Active Directory同步–稍后再讨论),以便无论在何处访问用户数据都保持一致

分类数据

需要将分类法数据从本地SP2013术语库同步到SharePoint Online术语库的背后是两个驱动因素–标记文件(当您’d也许可以预期),但是在自定义用户配置文件属性中使用了多个术语集这一事实也是如此。例如,例如,用户配置文件属性“Business unit” or “Division” –这些值来自定制术语集,以确保一致性和有效输入。为了使我们同步用户配置文件数据,此分类法数据也需要存在于Office 365中,否则无法保存配置文件,因为’指向缺少的值。换句话说,对分类数据有依赖性,因此我们可以同步用户配置文件数据。

用户照片

从表面上看,这比其他方法简单– the 客户 didn’希望允许用户编辑自己的照片,并具有一些处理现有系统中用户照片的过程(包括调整大小,应用边框以保持一致性等)。希望SharePoint Online用户配置文件也使用此照片。如果你’为了将照片批量同步到SharePoint Online,实际上,最好的方法是在Office 365级别进行处理(以便其他服务元素也显示照片),并且 设置用户照片 在此空间中提供了cmdlet。但是,我们发现这里的复杂性超出了我们的预期– more later.

我们实施了什么–利用OfficeDev模式和实践代码

总体而言,需要自定义代码来弥合这些差距。从一开始,我们就知道 OfficeDev模式and Practices libraries 有帮助的代码,我们围绕其中的一些部分设计了解决方案。在处理了许多繁重的工作之后,我们的重点是实施其中的一些“engine code”以一种企业的方式– something that could run on a schedule, have the 对 level of resilience, and be monitorable so that any failures could be identified. Helpdesk calls of the “嘿,当我去这里的时候’t have the 对 value for me, but when I go there it does!” and “I can’t正确标记此文档”毫无疑问,否则会发生–在一定程度上,我们肯定会偶尔遇到这种情况,但是我们希望能够主动识别/处理任何问题。

高层架构

OfficeDev P和P团队提供的各种代码虽然可以完成各自的工作(例如,帮助同步分类法或用户配置文件数据),但具体如何实现它们以及从何处运行取决于您–选项可以包括:

  • A 简单的控制台应用程序, installed to an on-premises server
  • 如上所述,但包装在PowerShell脚本中
  • 云选项,例如Azure中的WebJobs(但是您可能需要做一些额外的工作,例如,如果需要访问本地数据,则需要使用数据管理网关或类似工具)
  • 上述的一些组合,例如Azure中的中间层代码,“client”本地代码或脚本

在我们的案例中,因为所有三个方面都从本地数据开始,所以我们需要代码与本地系统进行通信–是SharePoint 2013环境,还是本地文件共享(例如照片)。因此,我们使用了“simple console app” option - this gave us the connectivity we needed, but also could be easily scheduled/monitored, and offered a familiar architecture that everyone was comfortable with. In code terms, however, we did separate out the core 引擎代码, so that it could be hosted somewhere else (e.g. Azure) if ever required.

用户资料

这里的解决方案专注于同步’将自定义用户配置文件数据从内部部署到SharePoint Online。 当然, Azure Active Directory同步 (原为DirSync)用于将某些用户数据从本地系统(Active Directory)同步到Office 365,包括初始创建配置文件 AAD Sync仅处理一组核心字段/属性!组织通常定义*许多*自定义用户个人资料字段(例如部门,部门,员工ID等)–因此,如果您希望将此数据导入Office 365 / SharePoint Online,则当前需要自定义解决方案。 我们的方法使用相对较新的(2014年11月)CSOM远程代码方法将数据写入SharePoint Online中的用户配置文件(在这种情况下不写入Azure AD)。我将其实现为一个两步过程,在该过程中,将为配置文件已更新的用户生成CSV文件(无论是通过用户,BCS字段还是从AD同步)。然后,导入将拾取该数据作为第二步。

实际上,由于CSOM既可用于从源读取,也可用于写入目标,因此只需更改配置文件中的值(例如URL,凭据),我们实际上就可以在我们连接到的任何SharePoint环境之间同步配置文件数据。 –任何一方都可以是本地或Office 365环境。这意味着我们有一个很好的解决方案,如果需求发生变化,可以对其进行调整。

最终结果是自定义配置文件数据已同步到Office 365,并有效地将用户“look the same”在两种环境中-例如在人物搜索中,或者“created by” or “last modified by”单击链接,依此类推。换句话说,用户体验才有意义。 (注:以下图像是Office 365 [2015年4月]中新的配置文件体验):

clip_image001

clip_image002

可以将特定字段设置为"do not import"(例如,不与AAD Sync更新的字段冲突),或出于其他任何原因: clip_image004
用户帐户也可以是"mapped"源/目标环境之间-在使用* .onmicrosoft.com帐户/未实现AAD同步和身份集成的情况下(例如测试环境),这很有用:

clip_image006

Any users who fail to import for some reason will automatically be re-tried (even if their profile hasn't changed since the last 在 tempt). Information on which users are failing, how many times they've failed, and the last failure reason is maintained 作为import jobs run:

clip_image008

由于它们持续运行,因此这些工具被设计为可监视的。他们将摘要写到Windows事件日志中,以供SCOM或其他监视工具使用,以获取并发送有关任何失败的电子邮件通知:

clip_image010

此外,Log4Net的实现是为了提供丰富的日志记录以帮助解决任何问题:

clip_image012

分类数据(例如用于标记的术语集)

分类同步可以从源到目标同步大多数类型的更改(新术语集,新术语,重命名等)。繁重的工作实际上是由Microsoft代码完成的( OfficeDev模式&练习Core.MMSSync 解)。

最终结果是,在源环境(在这种情况下为本地SP2013)中创建的任何术语集都被复制到目标环境(Office 365):

clip_image013
这允许跨在线/本地站点以一致的方式标记文档,并且还可以将绑定到术语集的用户配置文件字段标记为在两种环境中均能正常工作。

clip_image014

同步用户照片

我们这里的机制主要是一个PowerShell脚本,该脚本使用Set-UserPhoto PowerShell cmdlet(实际上是一个Exchange Online cmdlet–并且要求用户在Office 365中拥有一个Exchange Online邮箱),但与某些现有的照片处理流程集成在一起。但是,由于我们遇到了一些问题,最终决定完全更改此方法–下一节将对此进行更多介绍。

我们遇到的挑战

在大多数情况下,这些工具的开发进行得很好– however, we definitely did encounter a couple of road-bumps along the way. These were 东西 like:

  • 典型的客户端基础结构问题–工具在我们的环境中可以很好地运行,但是在锁定更多的服务器上运行并通过其他网络基础架构(例如反向代理)运行时,与云的通信将不太可靠。
    • 最后,这对于该客户证明是一个重要的问题(但可能对他们的情况有些特定)。当网络连接不够完美时,特别是用户照片PowerShell脚本将因身份验证问题而失败– and it was hard to “engineer in”这里绝对可靠。最后,我们决定一种更简单的方法是更改​​策略以允许用户编辑自己的照片(在SharePoint Online中:)
  • 一些分类同步挑战
    • 尽管此处的P和P代码具有相当的弹性,但我们确实遇到了偶然的错误(很可能与连接性/上一点有关)。大多数情况下,这些将在下一次运行时得到解决。
  • 远程代码的节流和批处理问题
    • 在开发过程中,关于 如何处理Office 365代码中的限制。这很有用,但是我们还发现OfficeDev模式和实践内部代码的某些部分在我们使用它的方式上造成了问题(即使更高版本也实现了节流/重试模式)。关于PnP代码*或*我们进行的通话没有什么无效–为了成功处理我们所需的一切,还需要进行一些调整。

概要

最终,我们能够实现我们的同步工具,以便最终用户’混合SharePoint的经验得到了改善。我认为任何形式的云开发都将始终在通信中偶尔遇到错误,而在企业范围内,’通常,对此有一定的容忍度是一个好主意(例如,我们针对失败的用户个人资料更新的重试机制)。 OfficeDev模式和实践代码为我们提供了很多帮助– there’毫无疑问,没有这些,要弥合这些差距将需要更多的努力。

如前所述,我’d期望SharePoint 2016能够在本地改善混合情况– but this work wasn’t a huge effort to make big steps towards this 对 now.

2015年4月6日,星期一

在Ignite和SharePoint的演变 2015会议上的演讲

如您所知’在SharePoint / Office 365空间中’即将举行的几次大型会议– I’将会在Microsoft提供会议’5月在芝加哥举行的Ignite会议,以及4月之前在伦敦举行的最出色的SharePoint的演变会议。进行新的对话总是需要很多准备,但是在会议之后,我’我期待着更详细地写一些我的主题’一直在探索。在那之前,我认为两个会议都将非常特别,如果您’重新去其中之一(或 建立,四月在旧金山)我想你’会很开心,学到很多东西。这是我的会议的详细信息(注:这些摘要中有一些更新没有’在撰写本文时已进入网站):

点燃

MS_Ignite_400px在Office 365应用程序开发中处理应用程序生命周期管理 

5月7日,星期四,10:45AM-12:00 AM

对于正在进行云友好的SharePoint或Office 365开发的团队来说,应用程序可能是重点关注的领域-无论是SharePoint还是更新的Office 365 / Azure AD应用程序。摆脱传统SharePoint开发模型的好处之一是ALM和持续集成等方面变得更加容易-最后,"开发更困难,因为它是SharePoint!"。在本节中,我们将讨论如何进行应用开发"right"方式-以ASP.NET为框架,以Azure为托管平台为重点。我们将介绍良好的做法,例如实施自动构建,仔细研究“持续部署”应用程序,还讨论了现有应用程序的升级/上线过程。在多个演示中,我们将展示Visual Studio Online和Azure如何成为成功的组合,并了解诸如"Deployment Slots" in Azure can help.

将您的SharePoint完全信任代码转换为Office App模型(小组讨论)

5月5日,星期二-5:00 PM-6:15 PM
面板 –Vesa Juvonen,Frank Marasco,Bob German,Erwin van Hunen,Chris O’Brien

本次会议是一个小组讨论,讨论了将SharePoint自定义项移至云应用程序模型的示例和模式-在Office 365或"cloud-friendly"本地SharePoint的实施。该小组由Microsoft OfficeDev模式和实践小组的成员以及独立的MVP组成。两者都从现场带来经验,但也有不同的观点。由于当开发人员必须离开服务器端SharePoint API代码和功能框架元素时情况发生了变化,因此讨论将围绕5个相关的热门主题-品牌,围绕远程代码的选项(包括.NET,JavaScript和PowerShell),提供自定义网站,沙盒解决方案的故事,最后是Office 365 API如何与应用程序模型配合使用。我们承诺进行热烈的讨论,现场代码示例以及Q的时间&A!

 

SharePoint的演变

Speaker_Square_banner

在Office 365应用程序开发中处理应用程序生命周期管理

与上面的Ignite会话相同

New developer choices - comparing 应用 for SharePoint with 外部 Office 365 apps

微软发布新的开发模型后,我们所有人都很快学会了如何开发SharePoint应用程序。唐’当他们这样做时,您只是喜欢它吗?在一个"external" or "standalone"应用程序,则无需将应用程序安装到SharePoint网站-这可以带来巨大的好处。但是,必须使用新的API,并且开发人员必须了解Azure AD的适用范围。虽然此模型当前仅适用于Office 365,但Microsoft暗示此方法可能很快会应用于本地SharePoint,因此这对所有开发人员都将变得重要。本课程旨在帮助您快速入门。

结束语

I also plan to publish videos of the demos from these sessions. There have been quite a few changes in Azure recently, and my ALM session covers some of the cool 东西 such as 部署槽, with a hat tip to other related capabilities such 作为“Traffic Routing”可用于A / B测试等功能。

I’我也非常期待Ignite的小组讨论。像其他小组成员一样’我对所讨论的话题肯定有意见:)

无论如何,希望能在其中一个会议上见到你。请来打个招呼’re there!