[Office]HOWTO: 重新激活 Office 365

[ 2013/09/24 13:39 | by gOxiA ]

OfficelogoOrange_Print

HOWTO: 重新激活 Office 365

        在过去安装 Office 时需要填写安装密钥,如果日后需要使用不同的密钥激活,只需要在添加删除中更改 Office 安装,便可重新填写密钥(在 Office 早期版本中可以通过删除注册表键值完成)以激活 Office。自 Office 2013 开始,因为新提供了 Office 365 订阅方式来授权使用 Office,所以激活机制有所改变,购买了 Office 365 的机构用户可以在不向最终用户分发密钥的前提下,让其使用自身帐号登录 Office 来激活产品,并且允许每用户在多达5台设备上激活 Office 进行使用,这是一种全新的、灵活的激活和授权政策,而且对于一些中小型企业雇主,此举将使得公司软件资产更为安全,因为当要撤销一台设备上的授权时,只需要用户登录 Office 365 的 Web Portal 停用 Office 安装即可,如下图所示。

image

        在实际应用时,当停用授权设备上的 Office 后,因某些原因并不会立刻生效,当遇到用户急需使用其他机构用户帐号激活的场景时,要使用以往的办法重新激活 Office 是无效的,因为当通过添加删除程序更改当前 Office 安装时可能会发现,Office 365 的安装程序并未提供重新输入密钥的选项,如果贸然参考资料去修改注册表,恐怕会使情况更糟糕。

image

难道就没有解决办法了吗?必须要重新安装 Office?!

        其实,在 Office 中提供了相关的工具,如果在网上搜索,可能看到更多的是“使用 Osaui.exe 重新激活订阅许可证”这篇官方文档,但是该命令只在 Office 2010 中提供,而并未包含在 Office 2013 中,所以我们需要使用一个常见的 Office 脚本工具 – OSPP.vbs 来进行操作,命令行参考如下:

        首先,我们需要执行下面的脚本命令行先获取当前 Office 激活的密钥信息。(PS:虽然之前是通过 Office 365 机构用户的帐号激活的,但激活过程还是会先取得一个密钥,再进行激活。)

cscript ospp.vbs /dstatus

        然后,从授权信息中取得密钥后五位,并执行下面的脚本命令行。

cscript ospp.vbs /unpkey:value

        注:上面命令行中的 Value 替换为密钥,可参考下图:

image

        再次打开 Office 程序,便会弹出激活向导,此时便可直接输入密钥或使用机构用户帐号登录激活。

Tags: , , , ,

ws2012r2-logo

Windows Server 2012 Hyper-V 复制

        早在去年11月份 gOxiA 就与大家分享了 Windows Server 2012 Hyper-V 虚拟机可移动性方面的几篇文章:“Windows Server 2012 使用 SMB 共享存储的实时迁移”、“Windows Server 2012 Hyper-V over SMB”、“详解 Windows Server 2012 无需共享存储的实时迁移”。这些功能和特性确实极大的方便了 ITPro,使大家能够轻松、快速、安全的对虚拟机进行迁移。当对这几部分的实时迁移有一定的学习和理解后,Hyper-V 复制就显得更加容易,所以之前也就没有再单独写这部分的文章。

        最近遇到几个案例都是探讨虚机备份和低成本的异地灾备的,而且这几天在做 Windows Server 2012 R2 Preview 到 RTM 迁移时也涉及到了 Hyper-V 复制,所以打算写篇东西出来跟大家分享分享,也算给自己留个存档。Hyper-V 复制,即:Hyper-V Replica,也称之为 Hyper-V 副本,是一种异步虚拟机复制技术,基于 HTTP 协议进行传输,所以它也非常适合应用在广域网环境中。在设计上,Hyper-V 复制主要用于商业连续性和灾难恢复场景。因为不需要任何共享存储,所以该技术可用于任何服务器、网络或存储供应商的设备。

Hyper-V_Replication

        要为 Hyper-V 主机启用复制功能,首先确保当前主机已经加入到 AD,并参考无需共享存储的实时迁移对主机做 Kerberos 委派,添加“hyper-v replica service”,然后还要修改当前主机的 Hyper-V 设置,在“复制配置”下勾选“启用此计算机作为副本服务器”,并选择“使用 Kerberos (HTTP)”端口保持80默认,在“授权和存储”选项下,选择“允许从任何经过身份验证的服务器重进行服务”,并指定副本的默认存储位置。可参考下图设置:

image

        在完成上述设置后向导会提示防火墙设置的相关警告,我们只需要进入防火墙设置允许 Hyper-V 副本 HTTP 通过。

image

        接下来,便可选择一台虚机进行复制的配置,整个过程可以参考下面的截图。

1

选择虚拟机,启用复制。

2

指定副本服务器,填写服务器名称。

3

因为仅允许使用 Kerberos 身份验证(HTTP),所以在连接参数向导中仅有一种可选模式,如果网络带宽比较紧张,建议勾选“压缩通过网络传输的数据”。

4

选择复制 VHD,是非常人性化的配置,比如当前虚机本身附加有备份用的磁盘,那么在做 Hyper-V Replica 时可以不对这些备份用VHD做复制,当然有些用户也可能仅是为了复制虚机的数据VHD而不需要系统盘,那么也可以在该步骤中进行选择。

5

根据需要配置复制频率,默认为每5分钟将更改发送到副本服务器。

6

在容灾级别不高而且对数据存储容量毕竟敏感的场景下,可以“仅保留最新恢复点”。

7

“选择初始复制方法”下,可以结合场景并根据实际情况进行选择。如果当前场景是局域网环境,并且此时网络带宽并不拥挤,那么可使用默认的“通过网络发送初始副本”作为初始复制方法,并“立即启动复制”。

8

9

        在完成初始复制后,Hyper-V 复制功能会按照之前设置计划的时间频率将虚拟机的变更发送出去。这些变更时通过日志文件追踪的,并且将在变更发往复制服务器前进行压缩。在主服务器上,变更会被保存在一个.hrl文件中,该文件与被复制的VHD文件位于相同位置下。

        Hyper-V 复制的故障转移操作有三个主要选项:

  1. 计划内故障转移,顾名思义也就是按照预先确定的计划来进行故障转移。该方式需要满足两个前提条件:在初始故障转移前,虚拟机必须关闭;被复制主机必须也启用复制功能,并允许接收来自复制主机的复制。
    image
  2. 测试故障转移,在复制服务器上进行操作,允许在不中断当前持续的复制配置下,生成并启动一个新的用于测试用途的虚拟机。
    image
  3. 计划外故障转移,很容易理解了,被复制主机意外宕机时,我们便可以在复制主机上执行“故障转移”,将该虚机启动上线。
    image

        玩转 Windows Server 2012 Hyper-V 的实时迁移和复制功能,并灵活应用在不同场景下,将会使 ITPro 感到无比轻松。

        参考:Hyper-V 副本概述演示 Hyper-V 副本Deploy Hyper-V Replica

ws2012r2-logo

在 Windows Server 2012 R2 RTM 和 Preview 之间迁移虚机将会失败

        Windows Server 2012 R2  RTM 在9月10日签约 MSDN/TechNet 向订阅用户发布,这次微软还是非常重视用户反馈的,最终选择提前向订阅用户发布 RTM。gOxiA 在第一时间下载了 Windows Server 2012 R2 RTM,并着手升级当前的 Windows Server 2012 R2 Preview 环境,两台基于 Windows Server 2012 R2 Preview 的 Hyper-V 主机,分别跑了一些虚机,因为服务器有 iDRAC,所以即使 gOxiA 没在办公室只需 VPN 到单位网络,通过 iDRAC 远程控制服务器,并通过 WDS 部署即可,非常方便!

        因为 Windows Server 2012 RTM 不支持从 Preview 版本进行就地升级,所以必须要全新安装,虽然目前 Hyper-V 可以直接导入磁盘上存储的虚拟机,但是为了保险起见还是利用无需共享存储的实时迁移将虚拟机暂时移动到了另一台 Hyper-V 上。之后全新的安装过程非常简单,因为是在千兆网环境下通过 WDS 进行部署的,所以整体的速度非常非常快。

        对新装的 Windows Server 2012 RTM 进行基础配置,加域等等的工作之后,便打算将之前跑在上面的虚拟机迁移回来,但是在实际操作时却遇到了问题,会提示无所进行迁移,因为接收到的虚拟机迁移数据无效或已损坏!由于之前忘记截图,所以 Hyper-V 管理器上的提示窗体截图没能保存下来,还好日志中有该问题的记录,提供出来给大家作为参考。

Hyper-V-VMMS_22042

        由于错误提示非常简单,并没有更具体的信息,而且 Windows Server 2012 R2 RTM 刚刚发布,参考文章少之又少,所以只能自己一点一点摸索解决!回忆之前 Windows Server 2012 到 2012 R2 Preview 的升级,是基于本地的就地升级,所以也没发现有什么问题,但是隐约记得在升级完第一台服务器后,确实也执行过实时迁移操作,并没有遇到这次的问题,难道是我本身虚机数据出现了损坏?!检查了各虚机数据都是正常的,但迁移就是无法通过,无奈试试 Hyper-V 复制。即,在位于 Preview 版上的虚拟机配置 Hyper-V 副本,将配置和数据传输到 RTM 上。一试,还真成功了!为了不再耽误时间,所以决定将要升级的 Preview 服务器上的所以虚机都通过 Hyper-V 副本功能传输到 RTM 这台服务器上。在完成传输后,关闭这些虚机,并执行“计划的内故障转移”即可。

image

        当所有配置了 Hyper-V 副本的虚拟机都执行了计划内故障转移之后,相信 Preview 上所有的虚机都以完成了到 RTM 的迁移。现在只需再为这些虚机“删除复制”以禁用副本功能,便可开始进行 Windows Server 2012 RTM 的全新安装。

image

        当第二台 Windows Server 2012 R2 RTM 安装和配置完毕后,发现在两台服务器间的实时迁移恢复正常了,因此判断 Windows Server 2012 R2 RTM 与 Preview 的实时迁移应该存在兼容性问题,如果大家也在实际环境中遇到了这样的问题,不妨换种思路参考 gOxiA 的亲身经历来解决。

分页: 119/472 第一页 上页 114 115 116 117 118 119 120 121 122 123 下页 最后页 [ 显示模式: 摘要 | 列表 ]