原文发布于 2012 年 7 月 18 日,星期三

Office 365 ProPlus 包括多个服务组件。John Jendrazak 在其 Office Next 博客(该链接可能指向英文页面)上的文章中曾多次提及这些主题,但这次我想尝试谈谈托管环境的 IT 管理员。用户是服务的中心,他们应该能够在自己使用的任何设备上体验 Office。365 ProPlus 允许用户在最多五台计算机上安装 Office;结合使用 SharePoint Online 时,用户甚至可以在临时使用的计算机上获得丰富的 Office 体验。所以无论在家中、在办公室还是在旅途中,Office 365 ProPlus 用户都可以高效工作并与 Office 保持连接。他们的应用程序设置、最近使用的文件和文件夹的链接、自定义词典乃至他们在文档中上次所在位置的书签都会随他们一起在设备间漫游。与此同时,IT 管理员可以管理这些体验、访问服务、代表用户部署 Office 以及快速添加或删除用户帐户—就连对季节工或临时工也是如此。本节介绍用于实现 Office 365 ProPlus 体验的服务和技术组织结构。

身份

Office 365 ProPlus 服务的核心是身份概念。Office 365 中的活动用户帐户是提供其他 Office 365 服务的关键。每个 Office 365 用户都有一个 Online Services ID,它既可用于访问服务,也可用于存储个性化设置的关键列表并链接到最近使用的 Office 15 应用程序的文档。Microsoft Online Services ID 和相应的个性化设置信息集中存储在 Windows Azure 中,并在 Office 应用程序启动过程中、运行 Office 程序时在帐户之间切换或登录到 Office365.com 时加载。Office 365 ProPlus 软件安装要求用户使用此 ID 登录以激活 Office 365 软件。IT 管理员还可以根据需要添加或删除用户帐户及其服务访问权限;状态更改会很快反映在用户应用程序和服务中。以下是使用 Office 365 的组织的三个主要身份选项的体系结构。

 

Microsoft Online Services ID

 

  

    

此选项不要求本地基础结构或目录服务。管理员可以手动从本地目录导入用户,但随着新用户加入或老用户离开本地目录服务,管理员将需要手动添加或取消帐户。密码、身份验证和授权均在云端进行管理。

 

使用目录同步的 Microsoft Online Services ID


 

 

此选项与本地 Active Directory 目录服务结合使用,对来自目录服务的用户帐户进行同步。在这种情况下,用户主体名称和相关用户属性与联机目录存储每三个小时同步一次。密码、身份验证和授权均在云端进行管理。

使用 Active Directory 联合身份验证服务的单一登录


 
 

当组织要共享���户使用其本地域访问 Office 365 服务时的登录信息时,将使用此选项。此选项为 Office 365 服务和本地目录服务保留相同的登录信息。本地基础结构用于管理 Office 365 服务的密码、身份验证和授权。密码不在云端进行存储和管理。

即点即用交付

即点即用交付是 Office 365 ProPlus 的新功能,它能够使用流媒体技术提供 Office 应用程序。从单击启动安装到第一次使用 Office 所需的时间可能只有一分钟,而传统 Office 安装经常超过 20 分钟。使用即点即用还有几个其他优点,包括:

-         支持同时运行新版本和早期版本的 Office

-          软件独立更新,无需打扰最终用户

-          轻松地使用 Office 加载项、依赖的应用程序和 Office 应用程序进行自定义

-          与传统 Office 安装相比,安装更快、首次运行更快

-          从自行安装到企业“推送”部署的灵活部署和安装选项

即点即用得益于 Microsoft 对应用程序虚拟化技术和 Office 2010 即点即用的多年投入。新 Office 即点即用技术基于客户反馈和不断改进,使本地应用程序和加载项能够与 Office 安装交互—通过其他形式的应用程序虚拟化提供 Office 或 Office 2010 即点即用实现无法实现此功能。即点即用还使用虚拟文件系统 (VFS) 而不是装入点安装 (MNT) 以避免创建 Q:\ 或类似驱动器。

 

Office 365 ProPlus 即点即用与 Microsoft Application Virtualization 4.6 和 Office 2010 的比较

此模型与其他应用程序虚拟化相比的最大差别之一在于 Office 功能在组件级别加载而不是等待大功能块。在旧模式中,5 到 10% 的应用程序通常作为第一个功能块加载,它允许应用程序启动和执行几个基本任务,然后加载应用程序的其余部分并缓存在第一功能块边界内。此模型非常适合小型应用程序,但一个独立的 Office 应用程序有数百 MB,其中许多组件在应用程序的 Office 套件之间共享。因此,大功能块必须拆分为多个组件来帮助首次运行。

组件按照预定义序列全部加载,如果用户尝试提前加载序列中比较靠后的组件,则该功能将动态加载并使对应的应用程序部分工作。在后台通过运行 intergratedoffice.exe 进程来实现对整个 Office 套件的缓存,即使应用程序正在运行时也是如此。经常有人问我这样的问题:“我需要将所有应用程序功能加载到缓存中吗?”不需要。尽管您的使用可以控制各功能的优先顺序,但最终所有功能都将在后台缓存。

另一个主要差异是:过去虚拟应用程序之间完全独立.这在使用 Windows XP 以及更早的系统时相当有利,因为当时常发生 DLL 冲突。对具有文件和注册表虚拟化的 Windows Vista 和很多第一次体验 Windows 7 的企业用户而言,DLL 冲突问题已经基本得到解决,当时 IT 管理员开始意识到文件和注册表虚拟化(重命名为用户帐户控制虚拟)自己就可以解决 Windows 中应用程序到应用程序的冲突问题。对于 Office 来说,隔离模式是一项挑战,因为 Office 本身是一个可扩展平台,其他应用程序可以调用它,使用 Office Starter 或者试用 Office 2010 (aka Click-to-Run v1) 的人会记得 Office 加载项无法与 Office 安装版本会话。同样地,如果 APP-V 4.6 用于发送 Office 2010,也就意味着我必须将加载项排成 Office 序列,而且如果我想执行在 Excel 2010 的 App-V 提交副本上安装 Power Pivot 作为本地可执行文件之类的操作时,它将不能按计划工作,应用程序安装包组需要对 Office 包重新排序以包括 Power Pivot。所有的这些事件、更新到 Windows 平台和挑战意味着我们需要打开隔离模式并允许本地自定义、应用程序和加载项与 Office 即点即用进行集成。除使用应用程序虚拟化的 Office 365 ProPlus 之外,系统上的其他对象都可以与其进行交互。最简单的示例之一是安装语言包—只要我有使用即点即用的 Office 基本安装,我就可以安装语言包来更改 Office 的运行方式。加载项和其他本地自定义也是如此。

我们添加了与本地应用程序集成的功能,但同时也保留了与 Office 其他版本并列安装的功能。过去进行基于 MSI 的安装时这有可能实现,但在安装两个版本的 Office 方面始终存在许多问题。应用程序虚拟化解决了很多问题,但仍有一些仍尚未解决,例如哪个应用程序应该具备默认文件关联。在 Windows 7 中,最后安装的应用程序拥有默认的文件关联,在 Windows 8 中则由用户决定该默认程序。尽管并列安装存在给我们带来挑战,但它大大减少了推出新 Office 的风险,因为当检测到文件不兼容或其他自定义项无法按预期工作等极少数情况出现时,用户可以恢复较旧的版本。在现实世界中,即便预期计划做到最好,管理员也不可能在 Office 新版本作为产品推出之前对每一个文件和每一个加载项都进行测试,因此支持并列安装会有所帮助。如何为移除旧 Office 版本以及决定这些策略和操作进行规划随即成为了一项挑战,因为您不想将来因支持两个 Office 版本受到困扰,尤其是当两个版本装在同一台机器上时。换句话说,并列安装应该用于使转换变得轻松并和将部分测试返回给用户,但用户不应将其作为可以依赖的永久配置。

 

 

与 Microsoft Office 2003 并列运行的 Office 365 ProPlus

既然现在我讲到有关支持的话题,那么我们来谈谈软件更新。许多人认为更新是强加给用户的,虽然一些人喜欢“始终保持最新”这句话并支持自动更新(或只是在更新文件出现时允许更新),但是其他人—特别是那些曾看到更新导致重大问题的人不会这样做。使用即点即用的 IT 管理员拥有软件更新体验的完全控制权,并可以选择接收自动更新或推出基于组织测试和验证的特定 Office 程序。一系列最近的 Office 即点即用程序会提供给 Office 365 管理员,帮助它们保持当前状态,同时更具情况进行变通,允许在部署新程序进入生产之前先进行测试.

用户需要自己安装 Office 365 ProPlus 吗?

不需要。虽然能够安装自己的应用程序在某些人听来是一种自由,但是对于一些我在 Windows 时合作过的公司而言,他们有 200000 个应用程序,或者用个更合理的数字比如 10000 个应用程序,那么要求每一位新员工去手动安装 50 到 100 个工作时要用到的应用程序可能就不是什么好办法了。因此作为 IT 管理员的我们需要站在用户的立场上找到一种安装应用程序的方式,我喜欢称之为“推动部署”,而在自助式方案中,我称之为“拉动部署”。即点即用的设计目的在于同现有的 IT 服务管理工具和流程集成,从而以托管方式使推动和拉动部署在 Microsoft 系统中心配置管理器或者其他企业软件分配工具等产品中得到应用。在本地 PC 上安装即点即用安装,其他具有基于 MSI 的软件安装的 PC 机用户也可以使用该安装,因此其工作方式类似于我们现在部署 MSI 或者其他任何基于 EXE 的安装包的方式,实际上即点即用使用 EXE 文件进行初始化安装。一旦该安装得到完全缓存,Office 就能离线使用,无需连接到 Internet 或 Office 365 服务。

漫游设置

漫游设置经过更新和扩展,使用户能够轻松地在设备间切换,并看到他们上次工作时的文档和文件。过去当 Office 与 Windows Live 服务配套使用时漫游设置功能有限。但新 Office 将漫游功能扩展为登录体验的核心。当用户登录并启动一个应用程序时,以下核心设置被加载到他们各自的 Office 应用程序中:

-         最近使用文档的链接(http 文件路径)

-         最近访问地址的链接(http 文件路径)

-         上次阅读 Word 文档的位置

-         上次查看的 PowerPoint 幻灯片

-         自定义词典(所有应用程序)

-         Office 主题和用户图片(所有应用程序)

 

John O’Sub 自动登录到 Word 2013 Preview,他最近的文件和文件夹与 Office 主题一起显示

当应用程序启动时,这些设置加载到 Office 应用程序中。因为文件(文档、电子表格、演示文稿、笔记等)本身并不漫游,所以对应用程序启动性能的影响非常小。Office.com 中的用户体验还将启用有关设置以便与最近使用的文档和最近访问的位置等用户门户体验一起漫游。

Office on Demand

Office on Demand 是 Office 的新交付选项,它使用即点即用的一个变量,使 Office 应用程序可以将要求的交付以流媒体的形式传输到任何使用 Windows 7 或更新的系统且连接到 Office 365 服务的 PC 中。用户通过 Office 365 中的 SkyDrive Pro 访问 Office on Demand。在这种情况下,Office 应用程序—如 Word、PowerPoint 或 Excel—是流式的并且仅在 30 秒之内可用。Office on Demand 不需要 PC 上的管理员权限,所以它可以在任何使用 Windows 7 或更新的系统且连接到 Internet 的 PC—甚至是暂时使用的 PC 上使用。Office 365 ProPlus 订阅用户在可以访问 Office on Demand 的 PC 数量方面不受限制。所有默认从用户配置文件内运行的应用程序进程将从与用户帐户相关的 SkyDrive Pro 位置打开,并保存到该位置。

Office on Demand 应用程序使用应用程序虚拟化隔离模型进行传送,所以无法用加载项、自定义或依赖的应用程序自定义 Office on Demand 应用程序,除非它们已在现有 Office 安装中出现。在这种情况下,应用程序也不会在系统中注册或控制 Windows 中的文件类型关联。一旦用户离开 Office on Demand 应用程序会话,后面的用户无法访问 Office 应用程序或前一个用户远程存储的文件。Office on Demand 在以下应用程序中可用:

-          Word

-          Excel

-          PowerPoint

-          Access

-          Publisher

-          InfoPath

Lync、OneNote 和 Outlook 不能通过 Office on Demand 交付使用。Office on Demand 的交付通常包含 Office 365 ProPlus 程序的最新版本,Office on Demand 程序通常通过 Office 365 公共云计算服务调配,所以与前面所述的本地即点即用交付不同,Office on Demand 无法通过本地基础设施进行交付。

第一次从 PC 上启动 Office on Demand 时,您需要允许安装名为“Microsoft Office(漫游)”的 ActiveX 控件。一旦该加载项就绪,用户便可以启动 Office on Demand。对于希望使用这种方法将 Office 传送到共享计算机或其他桌面服务体系结构的组织,您可以将 ActiveX 控件预安装在您的组织中此交付模型的目标 PC 上。Office on Demand 也是培训用户使用新 Office 用户界面和功能而不要求使用软件发布基础结构进行广泛部署的极好途径,此外由于使用标准用户帐户权限的用户可以使用 Office on Demand,您不需要授予用户管理员帐户权限。

 

Office on Demand 可以通过活动 SkyDrive Pro 帐户访问。原因在于如果用户只是暂时使用 PC 并需要访问他或她的文件,接入点从打开一个文件中接入,保存位置将返回到打开文件的联机位置。Office on Demand 禁用长期本地高速缓存,有助于确保程序关闭且用户注销时文件将存储到它们打开时的联机位置。

 

单击文档,您将首次启动与该文件相关联的 Office Web 应用程序。在许多情况下,Office Web 应用程序的功能足以查看和编辑文件。如果要使用 Office Web 应用程序中没有的功能,您可以选择在已存在的 Office 中编辑文件或者启动使用 Office on Demand 启动一个新 Office 程序。

 

要从 Office Web 应用程序启动 Office on Demand 程序,您可以在 Web 应用程序查看器模式(如上)中单击“编辑文档”或者在 Web 应用程序编辑模式中单击“在 WORD 中编辑文档”。PowerPoint 和 Excel 等其他 Office 程序使用类似的进程。

 

Office on Demand 程序数据存储在 %userprofile% 根文件夹中。在 PC 上第一次启动 Office on Demand 后,Office 被完全缓存在 %userprofile% 目录中,随后 Office on Demand 的启动几乎即时发生,因为它们是从本地缓存中执行。一旦 Office CDN 上更新了 Office 版本,Office on Demand 将再次流传输含有该更新版本的 Office 程序。

集中处理诸多分散信息

身份涉及到该服务的很多部分,为用户设置一个本地定位 ID 使多设备安装、托管用户解除配置、漫游设置、Office on Demand 和许多服务端功能成为可能。目录服务已成为实现传统本地/私有云服务、系统管理、协作以及其他工作负荷功能的核心,而联机 ID 对启用该服务模型也至关重要。身份能够提供内容和 Office 365 ProPlus 应用程序交付体验,并能在您超出企业网络的外围网络,且开始混合托管和个人设备时,进一步扩展到其他工作负荷。

如果您确实想深入了解身份管理选项,请参阅企业 Office 365 部署指南。有关即点即用的详细信息,我会在接下来的几篇文章中深入讲解,不过您也可以参阅 TechNet 上的即点即用概述Office 365 即点即用安装程序体系结构概述

这是一篇本地化的博客文章。请访问 Office 365 ProPlus Administrator Series: Office 365 ProPlus Service Components – a look at Identity, Click-to-Run delivery, Roaming Settings and other Features 以查看原文