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”以一种企业的方式–可以按计划运行,具有适当级别的弹性以及可监控的东西,以便可以识别任何故障。服务台的“嘿,当我去这里的时候’没有给我合适的价值,但是当我去那里的时候,它确实具有价值!” 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’现在需要为此付出巨大努力。

4条评论:

匿名 said...

想知道您的想法是关于"move"远离O365中的SharePoint功能,以提供更多不同的服务。

看着Delve的公告吧'好像我们可以说MySites现在快要用完了,因此标记的概念可能会转移到添加到Delve板上(请注意,'不知道Delve笔记在哪里"tags"储存起来,以为他们're still referred to as 标签 in the api).

I sat in on the Yammer training 在 the SharePoint conference last year and when the SharePoint folk in the room brought up questions on how would Yammer 标签 and SharePoint managed metadata 标签 going to be aligned it was a "we aren'真的在想这个" answer.

With Delve boards and the new people page 我可以 see that the notion of tagging could be elevated out of Managed Metadata entirely for O365 在 least.

SharePoint user profile data is of course imported into Managed Metadata (done this loads of times myself and used the data for site navigation and search personalisation) but do you see a need to get the Managed Metadata and Delve board 标签 aligned?

也许我们'会看到一种将用户配置文件属性配置为delve标签类型的方法吗?

柯克说过...

克里斯,好帖子。我们过去曾经解决过其中一些问题,但我认为那是在PnP可用之前'确保我们也有不同的要求,所以我们采取了不同的途径...

一种用于配置文件的方法是,我们决定将O365配置文件作为真实来源之一。我们将配置文件属性从本地复制到联机(不幸的是,即插即用),然后创建本地重定向,以将用户从本地带到在线配置文件。由于我们只有一个事实来源,而且用户从未访问过本地配置文件,因此不需要同步,但是我们的代码进行了一次复制,因此能够以与您的方法类似的方式工作。

When it came to user profile images we found a lot of nuances that were undesirable. These may be better today, but I suspect they are not. I blogged about it here: http://www.threewill.com/user-photo-sync-behavior-in-office-365/

对于搜索,我们使用了混合搜索方法,但是由于无法通过防火墙在线访问本地,因此无法显示本地搜索结果。因此,我们将本地搜索中心作为主要搜索中心。对于在线搜索结果,如果他们已经登录到本地,我们将尝试将用户重定向到本地搜索中心。本地搜索结果将显示来自本地和在线的混合结果。

-柯克

柯克说过...

Oh, I should have also mentioned that we created a user profile image proxy to run on-prem so that if the user was not authenticated into SharePoint online, he/she could still see the online user photo. This is in addition to the redirection link to the profile mentioned in my last comment and is to support having the O365 profile 作为"one source of truth".

-柯克

尼科说过...

感谢您分享克里斯。希望在半年前,当我使用SharePoint 2013和Office365设计大型混合云解决方案时就知道了。本可以节省很多时间。

只想与您分享有关分类同步挑战的其他一些经验。 P&P代码对我们不起作用,因为它不支持某些重要的术语库属性。但是,我们偶然发现了一款​​价格实惠的产品 ServiceAware术语库同步 正是我们需要解决的挑战,以保持内部SharePoint 2013和Office365之间的术语保持同步。

-尼古拉