背景故事
早在我担任托管服务提供商的基础架构工程师时,补丁程序管理既是我人生的祸根,也是我所享受的东西。
我不喜欢在深夜里修补和重新启动服务器,因为必须安装在自己观察的服务器上,才能临时启动服务器,有时由于安装的补丁而崩溃并烧毁。但是,我确实很喜欢安排它,弄清楚一天中可以修补哪些服务器而不会影响服务等。我开发了一些非常好的文档,彩色电子表格和可重复使用的材料,可用于所有客户。
幸运的是,在我目前的职位上,我不必担心。但是最近,我在家庭实验室中投入了一些精力,在设置它并在上面安装新的虚拟机(VM)时,我感到恐惧,您要安装4个专用的补丁。不幸的是,在我参与使实验室运转起来的实际工作之前,必须要做的是。
回到我以前的工作中,我们(大部分)在客户端环境中使用Windows Server Update Services(WSUS)来管理其服务器和桌面补丁程序管理。我不想在家庭实验室设置中使用它,因为设置需要花费时间,在管理和维护上可能会非常耗时。由于这些天我都在工作,因此我想集中精力了解Azure如何帮助我解决此问题。
我的家庭实验室
在以前的博客中,我提到我的家庭实验室设备现在已经有些陈旧了,它是HP ProLiant Microserver N40L,第8代。它仍然可以让我对功能进行一些测试,并构建可以模仿客户经常拥有的功能的环境,并不是每个人的数据中心中都有闪亮的新锡或最新的操作系统,因此尝试了解如何在这些情况下仍然可以使用Azure是有帮助的。
从VMware到Hyper-V
因此,在过去的几个月中,我一直在家庭实验室中运行VMware以利用Azure Migrate,但是随着宣布Hyper-V支持现已在Azure Migrate的私有预览版中,我正在从VMware ESXi 5.5.0 Update 2环境我一直在运行Windows Server / Hyper-V环境。
问题
这带来了补丁问题。我为那些主机操作系统(OS)从Windows Server 2012 R2下载的ISO文件已过时。因此,在实际构建Hyper-V环境之前,我的第一个障碍是修补主机。第一次启动时,我进行了135次更新,等待我进行第一次检查。

我知道如果我使用ISO来构建我的VM,我将会遇到同样的问题,而且每次新补丁发布时,我都必须管理前进的机器,因此就解决了问题。
使用Azure更新管理进行修补
蔚蓝更新管理是Azure自动化解决方案的一部分。它可用于修补Azure计算机和非Azure计算机。但是,要在非Azure计算机上使用它,您还需要利用Log Analytics。因此,由于我的环境不是Azure,因此我需要设置Log Analytics工作区以及Automation。
入门
因此,第一步是在Azure中创建一个资源组以存储我的资源。如果您转到 蔚蓝门户, 点击 创建资源 并找到资源组。确保给它一个适当的名称,然后为您的资源组选择正确的位置。
第二步是在Azure中创建Log Analytics工作区。在您的资源组中,单击 加 并创建一个Log Analytics空间。
现在已经部署完毕,为了让我的本地计算机与Azure Log Analytics工作区进行对话,我需要安装代理。
代理安装
您需要安装的代理是Microsoft Monitoring Agent(MMA),对于那些熟悉SCOM的人来说,您将熟悉该代理,它与Log Analytics所需的代理相同。可以从您的Log Analytics工作区中的“设置”下下载代理。在安装代理期间,您需要输入您的工作区ID和工作区密钥,因此在安装过程中请他们处理。
现在已经安装了代理程序,并且我的机器正在与Log Analytics通讯,我需要开始实现所需的功能,以便为我的机器自动打补丁。这意味着日志分析解决方案...
日志分析解决方案
在Log Analytics中,有一些解决方案。解决方案可帮助您在Azure中利用服务。为了进行补丁管理,我需要在Log Analytics中安装更新管理解决方案。
要安装解决方案,请打开OMS Portal。在左侧下方,您将在左侧下方看到五个按钮。顶部的第四个按钮是 解决方案库,点击进入。
您正在寻找更新管理解决方案。选择此选项时,将要求您对其进行配置。如果您已经设置了一个自动化帐户,并希望将其重复使用,则配置屏幕将询问一个自动化帐户,然后输入相关详细信息。否则,请按照指示创建一个新的。
现在已经安装了解决方案,我可以开始为机器设置补丁程序了。为此,我需要打开 自动化帐户 刀。
选项之一,在列表的第9位是 更新管理,点击进入。您将看到几个选项。第一个要探索的是 安排更新部署,您可以在其中定义需要更新哪些计算机,何时,多长时间,应用哪些补丁以及是否允许计划重新启动计算机。

这非常类似于您设置组策略设置以与WSUS一起使用的方式,并具有一些额外的功能。
我在配置中设置了三个组:
- N40L主机 -这修补了我的主机
- Windows虚拟机 -这会修补主机中的Windows虚拟机
- Linux虚拟机 -这会修补主机中的Linux虚拟机
我的每个小组都有与他们在我的环境中的角色相关的维护时段和补丁计划。我始终建议您按照自己的高可用性需求和要求,对与它们的功能相关的机器进行相同的分组。在我的日程安排中,如果需要,我允许Update Management解决方案重新启动计算机。再次评估一下在您的环境中这是否可以。在您的环境中自动执行修补计划有很多好处,但是请务必对其进行计划并为您的计算机应用适当的设置。
以下是我的环境的屏幕截图:

它表明更新管理解决方案一直在努力修补我的环境并使其更新。一些机器被认为是合规的并且是最新的,而其他机器仍处于不合规的状态。
更新部署已运行,成功失败或必须缩短维护时段才能完全完成。如下所示:

故障可以由我解释,我将可引导的USB插入主机,因此当它重新启动时,它会感到困惑并尝试引导至该主机。
维护窗口太小,部分原因是更新部署尝试部署的补丁数量以及我的设置。这是在您的环境中提防的一个问题,如果您必须缩短维护时段,则它可能永远不会与您正在应用的所有修补程序完全兼容。这是您需要考虑的事情,在您的环境中是否可以接受,或者是否需要安排较大的维护时段(例如每月一次)以尝试追赶。
往前走
继续进行更新部署将为我解决补丁问题,只要我在实验室中构建新计算机(如果我安装了代理并将其添加到更新部署组中)就将得到解决。
有些过程仍然是手动的,但从长远来看,应该可以节省我的时间。
与往常一样,如果您想与我联系并就上述任何内容进行交谈,请通过Twitter与我们联系 @TechieLass
关于我

莎拉·里恩(Sarah Lean)
云倡导者
我叫Sarah Lean,我是Microsoft的一名高级云倡导者,专注于Azure的所有方面。
免责声明:
此博客中的信息按“原样”提供,不提供任何担保,也不授予任何权利。本博客不代表我雇主的想法,意图,计划或策略。这完全是我个人的看法。所有代码示例均按“原样”提供,没有任何形式的明示或暗示保证,包括但不限于对商人能力和/或特定用途适用性的暗示保证。