如何使用Windows Server 2016从Windows事件触发电子邮件警报

循序渐进：如何使用Windows Server 2016从包含事件详细信息的Windows事件触发电子邮件警报

介绍

从Windows事件触发电子邮件警报使用Windows Server 2016只需要几个步骤。指定触发该任务时将发生的操作。由于Microsoft已决定弃用“发送电子邮件”选项，因此我们唯一的选择是启动程序。在我们的例子中，该程序将是一个Powershell脚本，用于收集事件日志信息并对其进行解析。这样，我们就可以发送包含重要日志事件详细信息的电子邮件。此工作已在Windows Server 2016上得到验证。但我怀疑它应该适用于Windows Server 2012 R2和Windows Server 2019。如果您在任何其他平台上工作，请发表评论，如果您需要更改任何内容，请告诉我们。

步骤1-编写Powershell脚本

首先要做的是写一个Powershell脚本，运行时可以发送电子邮件。在研究这个问题时，我发现了很多方法来完成这项任务，所以我要向您展示的只是一种方式，但您可以随意尝试并使用适合您环境的方法。在我的实验室中，我没有运行自己的SMTP服务器，因此我必须编写一个可以利用我的Gmail帐户的脚本。您将在我的Powershell脚本中看到，对SMTP服务器进行身份验证的电子邮件帐户的密码是纯文本格式。如果您担心某人可能有权访问您的脚本并发现您的密码，请加密您的凭据。Gmail需要和SSL连接。 您的密码应该是安全的，就像任何其他电子邮件客户端一样。我有一个Powershell脚本的例子。与任务计划程序一起使用时，它将在Windows事件日志中记录任何指定的事件时自动发送电子邮件警报。在我的环境中，我将此脚本保存到C： Alerts DataKeeper.ps1

$ EventId = 16,20,23,150,219,220

$ A = Get-WinEvent -MaxEvents 1 -FilterHashTable @ {Logname =“System”; ID = $ EventId}
$ Message = $ A.Message
$ EventID = $ A.Id
$ MachineName = $ A.MachineName
$ Source = $ A.ProviderName


$ EmailFrom =“sios@medfordband.com”
$ EmailTo =“sios@medfordband.com”
$ Subject =“来自$ MachineName的警报”
$ Body =“EventID：$ EventID`nSource：$ Source`nMachineName：$ MachineName`nMessage：$ Message”
$ SMTPServer =“smtp.gmail.com”
$ SMTPClient = New-Object Net.Mail.SmtpClient（$ SmtpServer，587）
$ SMTPClient.EnableSsl = $ true
$ SMTPClient.Credentials = New-Object System.Net.NetworkCredential
（“sios@medfordband.com”，“mySMTPP @ 55w0rd”）;
$ SMTPClient.Send（$ EmailFrom，$ EmailTo，$ Subject，$ Body）

从Powershell脚本生成的电子邮件示例如下所示。 您可能已经注意到，此Powershell脚本使用Get-WinEvent cmdlet根据指定的LogName，Source和eventID获取最新的Event Log条目。然后它解析事件并将EventID，Source，MachineName和Message分配给将用于撰写电子邮件的变量。您将看到指定的LogName，Source和eventID与您在步骤2中设置计划任务时指定的ID相同。

第2步 – 设置计划任务

在任务计划程序中创建一个任务，如以下屏幕截图所示。

1. 创建任务确保将任务设置为“运行”，无论用户是否已登录。
2.  在“触发器”选项卡上，选择“新建”以创建将启动“在事件上”任务的触发器。在我的示例中，我将创建一个事件，触发任何时候DataKeeper（extmirr）将重要事件记录到系统日志。 创建一个自定义事件和新事件过滤器，如下所示…对于我的触发器，我触发通常受监控的SIOS DataKeeper（ExtMirr）EventIDs 16,20,23,150,219,220。您需要设置事件以触发要监视的特定事件。如果要通知来自不同日志或来源的事件，可以将多个触发器放在同一个任务中。
   

   

    

3. 配置事件触发器后，您将需要配置事件运行时发生的操作。在我们的例子中，我们将运行我们在步骤1中创建的Powershell脚本。
4. 默认的Condition参数应该足够了。
5. 最后，在“设置”选项卡上，确保允许按需运行任务，并在任务已在运行时“排队新实例”。
   

   

步骤3（如有必要） – 修复Microsoft Windows DistributedCOM事件ID：10016错误

理论上，如果您正确地执行了所有操作，您应该能够使用Windows Server 2016从Windows事件触发电子邮件警报。但是，我在我的一台服务器上遇到了一个奇怪的权限问题。这是我解决问题的方法。希望它也会对你有所帮助。在我手动触发事件的情况下，或者如果我直接运行Powershell脚本，一切都按预期工作，我会收到一封电子邮件。但是，如果正在监视的某个EventID被记录到事件日志中，则不会导致发送电子邮件。我唯一的线索是事件ID：10016。每次我希望任务触发器检测到记录的事件时，它都记录在我的系统事件日志中。

日志名称：系统
来源：Microsoft-Windows-DistributedCOM
日期：10/27/2018 5:59:47 PM
事件ID：10016
任务类别：无
等级：错误
关键词：经典
用户：DATAKEEPER  dave
电脑：sql1.datakeeper.local
描述：
特定于应用程序的权限设置不授予“本地激活”权限 
对于具有CLSID的COM Server应用程序 
{D63B10C5-BB46-4990-A94F-E40B9D520160}
和APPID 
{9CA88EE3-ACB7-47C8-AFC4-AB702511C276}
给用户DATAKEEPER  dave SID（S-1-5-21-25339xxxxx-208xxx580-6xxx06984-500） 
来自地址LocalHost 
（使用LRPC）在应用程序容器中运行不可用SID（不可用）。
可以使用组件服务管理工具修改此安全权限。

许多针对该错误的Google搜索结果表明该错误是良性的。它包含有关如何抑制错误而不是修复错误的说明。但是，我很确定这个错误是我目前失败的原因。如果我没有正确解决问题，使用Windows Server 2016从Windows事件触发电子邮件警报将很困难。经过多次搜索，我偶然发现了这个新闻组的讨论。  Marc Whittlesey的回应使我指出了正确的方向。这是他写的……

我几乎可以逐字逐句地遵循步骤1-15。然而，当我到达第16步时，我真的无法确切地说出他希望我做什么。起初我将DATAKEEPER dave用户帐户完全控制权授予了RuntimeBroker，但这并没有解决问题。最后我只是在所有三个权限上选择了“使用默认值”并修复了问题。 我不确定这是怎么发生的。我想我最好把它全部写下去，以防它再次发生，因为我花了一段时间来弄清楚它。

第4步 – 自动部署

如果需要在多个系统上启用相同的警报，请将任务导出到XML文件并将其导入其他系统。 或者甚至更好。 在文件共享上提供XML文件后，通过Powershell脚本自动执行导入作为构建过程的一部分，如以下示例所示。

PS C：> Register-ScheduledTask -Xml（get-content 
'\ myfileshare  tasks  DataKeeperAlerts.xml'|出弦） 
-TaskName“DataKeeperAlerts” - 用户数据管理员 dave 
-Password MyDomainP @ 55W0rd -Force

使用Windows Server 2016从Windows事件触发电子邮件警报

在我的下一篇文章中，我将向您展示如何在指定的服务启动或停止时收到通知。当然，您只需从Service Control Monitor监视EventID 7036即可。但是，只要任何服务开始或停止，这都会通知您。我们需要深入挖掘，以确保只有在我们关心的服务开始或停止时才会收到通知。如果您对我们的操作方法文章感兴趣，例如使用Windows Server 2016从Windows事件触发电子邮件警报，请单击此处。从Clusteringformeremortals.com转载

Azure Outage Post Mortem第3部分

结束Azure Outage Post-Mortem第3部分

我以前的博客帖子，Azure Outage Post-Mortem – 第1部分和Azure Outage Post-Mortem第2部分，基于来自博客帖子和Twitter的有限信息做出了一些假设。我刚刚参加了Ignite的一次会议，它更明确地说明了实际发生的事情。明天某个时候你应该能够自己查看会话。BRK3075 – 为意外做准备：解决Azure中断官方根本原因分析即将发布。与此同时，这里有一些从会话中收集到的信息。

原因

从死后的蔚蓝停电中，停电不是由先前报道的雷击引起的。相反，由于风暴的性质，电风暴下陷和膨胀。结果，它锁定了第一个数据中心的^冷水机组。在第一次停电期间，他们能够快速恢复冷却器，没有明显的影响。此后不久，第二个数据中心发生了第二次中断，无法正常恢复。这开始了一系列不幸的事件。

第二次停电

在此次停电期间，微软表示“工程师没有正确分类警报 – 冷水机组恢复没有优先考虑”。此时触发了大量警报。不幸的是，冷冻机处于脱机状态并没有得到应有的优先权。关于为何发生这种情况的RCA仍在调查中。微软声称当然有多余的冷却系统。但是，冷却系统未设置为自动故障转移。最近安装的新设备尚未经过全面测试。 所以它被设置为手动模式，直到测试完成。45分钟后，环境冷却失败，硬件停机，空气处理人员关闭，因为他们认为发生火灾。 工作人员因虚假火警而被疏散。在此期间，数据中心的温度在升高。某些硬件没有正常关闭，导致某些存储和网络损坏。手动重置冷却器并打开空气处理器后，温度开始恢复正常。他们花了大约3小时29分钟才能全面了解数据中心的状态。最大的问题是存储损坏。微软最关心的是数据保护。Microsoft将努力恢复数据以确保不会丢失数据。这当然需要一些时间，这延长了停机的总长度。好消息是没有客户数据丢失。 坏消息是，事情似乎需要24-48小时才能恢复正常。这是基于我在Twitter上从抱怨长时间停机的客户那里读到的内容。

假设

每个人都预计这次中断会影响在中南部地区的客户。但他们没想到的是，停电会对该地区产生影响。在会话中，Microsoft讨论了中断的一些扩展范围。

Azure服务管理器（ASM）

这可以控制Azure“Classic”资源，AKA，ARM之前的资源。任何依赖ASM的人都可能受到影响。我不清楚为什么会这样。南中部地区似乎拥有该服务的一些重要组成部分，而这些部分无法使用。

Visual Studio团队服务（VSTS）

同样，似乎许多支持此服务的资源都在中南部地区托管。Azure DevOps此博客文章的工程总监Buck Hodges（@tfsbuck）详细介绍了这次中断。

POSTMORTEM：VSTS 2018年9月4日

Azure Active Directory（AAD）

当中南部地区失败时，AAD按照预期的方式行事，并开始将身份验证请求指向其他地区。随着东海岸开始醒来并上线，身份验证流量开始增加。现在通常AAD会通过自动缩放来处理流量的增加。但是自动缩放依赖于ASM，当然它是离线的。如果没有自动缩放功能，AAD无法处理身份验证请求的增加。令人恼火的情况是Office客户端中的一个错误，这使得它们具有非常积极的重试逻辑，并且没有退避逻辑。这种额外的身份验证流量最终使AAD陷入困境。他们没有时间在Ignite会议期间进一步讨论这个问题。 他们将介绍的一个功能是让用户能够在将来手动故障转移存储帐户。因此，如果恢复时间目标（RTO）比（RPO）更重要，则用户将能够在备用数据中心恢复其异步复制的地理冗余存储，如果Microsoft未来再次遭遇延长中断的话。

你现在能做什么

在此之前，您将不得不依赖其他复制解决方案，例如SIOS DataKeeper Azure Site Recovery。或者是特定于应用程序的复制解决方案，它能够跨区域复制数据，并能够在您的控件中实施灾难恢复计划。了解有关我们的蔚蓝停电事件的更多信息，经Clusteringformeremortals.com许可转载

Azure Outage Post Mortem第2部分

发生了什么？这是我们的Azure Outage Post Mortem第2部分

我之前的博客文章称，云到云或混合云可以让您与CSP可能遇到的任何问题隔离开来。但是，如果在中南部地区提供可用区，则可以避免由此自然灾害造成的大部分停机时间。微软发布了9月4日南中央停电的初步RCA。整个摘要中最重要的部分如下……

“尽管有现实的冗余，有一些情景，其中一个数据中心的冷却故障会影响受影响的数据中心的客户工作。”

这对你来说代表着什么？

如果您的应用程序都在同一个数据中心运行，那么您将来可能会遇到相同类型的中断。在微软的辩护中，这对你来说真的不应该是新闻。无论您是在Azure，AWS，Google还是自己的数据中心运行，这一直都是如此。未能提前计划将数据复制到不同的数据中心以及制定快速恢复应用程序的计划只是缺乏您的计划。Microsoft未发布确切的可用区位置。如果你相信这张地图发表在这里，你可能会猜到它们可能相距2-10英里。 除了最极端的情况之外，在可用区之间复制数据应该足以用于数据保护。某些应用程序（如SQL Server）内置了复制技术。但是，对于广泛的应用程序，操作系统和数据类型，请研究块级复制SANless群集解决方案。SANless集群解决方案传统上用于多站点集群。但是，相同的技术也可以在可用区，区域或混合云中的云中使用，以实现高可用性和灾难恢复。无论是Azure，AWS还是Google，实施跨越可用区的SANless群集都是一个非常简单的过程，只需要合适的工具。作为宰蓝式停电事件的一部分，这里有一些资源可以帮助您入门。循序渐进：在Azure中配置跨越可用区的文件服务器群集如何在Google Cloud Platform中构建SANless SQL Server故障转移群集实例MS SQL Server v.Next在具有复制和高可用性的Linux上#Azure #Cloud #Linux在AWS快速入门中的AWS SANless Linux群集中的#Azure资源管理器（ARM）SAN SANless SQL Server群集中部署Microsoft SQL Server 2014故障转移群集

Azure Outage Post Mortem的教训

如果您在Azure中，则可能还需要考虑Azure站点恢复（ASR）。ASR允许您将整个VM从一个Azure区域复制到另一个区域。ASR将实时复制您的虚拟机，并允许您随时进行无中断的灾难恢复测试。它支持大多数版本的Windows和Linux，并且相对容易设置。您还可以创建具有“多VM一致性”的复制作业。这意味着必须从完全相同的时间点恢复服务器，这些时间点可以放在此一致性组中，并且它们将具有完全相同的恢复点。实质上，如果您在单个区域中构建具有DataKeeper的SANless群集以实现高可用性，则DR有两个选项。一种是您可以将SANless群集扩展到不同区域中的节点，或者可以使用ASR复制一致性组中的两个节点。

有什么不同？

与ASR的权衡是RPO和RTO不如使用SANless多站点群集那么好。虽然它很容易配置并适用于任何应用程序。小心点 如果您的应用程序定期超过10 MBps的磁盘写入活动，ASR将无法跟上。此外，基于Storage Spaces Direct的群集无法使用ASR进行复制，并且在Azure中使用时通常缺乏良好的DR策略。管理磁盘发布后的一段时间，ASR直到大约一年后才完全支持它们。对于许多希望使用ASR的人来说，对托管磁盘的全面支持是一个很大的障碍。幸运的是，从2018年2月开始，ASR完全支持托管磁盘。但是，刚刚引入了另一个问题。随着可用区的引入，ASR再次落后于时代。它们目前不支持已部署在可用区中的VM。

无论如何我继续尝试了。似乎可以配置复制，我能够进行测试故障转移。

我使用ASR从中美到东2复制SQL1和SQL3，并进行了测试故障转移。除了没有将VM放置在美国东部的AZ中之外，它似乎也有效。[/ caption]我希望在Ignite会议上找到更多有关此限制的信息。虽然这种限制并不像Managed Disk那样重要。 因为可用区尚未广泛使用。因此，希望ASR能够获得对可用区的支持，因为其他区域点亮了可用区，并且它们被更广泛地采用。

了解有关Azure Outage Post Mortem的分析的更多信息，经过Clusteringformeremortals.com的许可转载

Azure Outage Post-Mortem第1部分

Azure Outage Post-Mortem

关于上周发生的Azure Outage，第一次官方Post-Mortems开始出现在微软上面。第一个Azure Outage Post-Mortem专门解决Azure DevOps中断问题（以前称为Visual Studio Team Service或VSTS）。它为我们提供了一些关于中断的广度和深度的额外见解。它证实了停电的原因。它还让我们深入了解了微软在快速恢复在线状态时所面临的挑战。此外，它暗示了微软可能会考虑在未来更好地处理这种情况的一些特性/功能。正如我在上一篇文章中提到的，Azure中推出的新可用区等功能可能会最大限度地减少此次中断的影响。在验尸中，微软确认了我之前所说的内容。

我们正在努力改进处理数据中心故障的主要解决方案是可用区，我们正在探索异步复制的可行性。

其他预防措施

在可用区域跨越更多区域推出唯一的灾难恢复选项之前，您需要跨区域，混合云甚至跨云异步复制。目前可用的基于软件的#SANless群集解决方案将实现此类配置。 提供非常强大的RTO和RPO，即使在复制很远的距离时也是如此。借助SaaS / PaaS解决方案，您可以依靠云服务提供商（CSP）来实施具有铁的HA / DR解决方案。在这种情况下，似乎有一个非常重要的缺陷暴露。我们只能希望它能引导所有CSP仔细研究他们的SaaS / PaaS产品。以及解决可能存在的任何HA / DR差距。在此之前，消费者有责任了解风险。他们需要尽其所能来降低延长中断的风险，或者只是在风险得到解决之前选择不使用PaaS / SaaS。

RTO还是RPO？

验尸确实是问题的根源……你更重视什么，RTO或RPO？

我从根本上不想为客户决定是否接受数据丢失。我有客户告诉我他们会花费数据丢失来让一个大型团队再次快速生产，其他客户告诉我他们不希望任何数据丢失，并且等待恢复时间不长。

CSP不可能为客户做出决定。CSP不希望丢失客户数据，除非原始数据完全丢失且无法恢复。在这种情况下，近乎实时的异步副本与您在意外故障中获得的RPO一样好。然而，这次停电是否真的出乎意料而且没有任何警告？现代卫星图像和天气预报的改进给予了公平的警告，该地区将发生重大的天气相关事件。当我写这篇文章时，飓风佛罗伦萨正在美国东南部。如果数据中心位于路径中，请采取主动措施将工作负载移出受影响的区域。主动灾难恢复与反应式灾难恢复的好处很多。没有数据丢失，有足够的时间来解决意外问题。它还包括管理人力资源，使员工可以担心照顾家人，而不是工作。同样，制定主动的灾难恢复将是CSP代表其所有客户做出的艰难决定。跨地区的计划迁移将导致一定程度的停机。这个决定必须由客户掌握。从Azure Outage Post-Mortem中吸取教训，教育您的客户。

得到保护

那么您可以做些什么来保护您的业务关键应用程序和数据？让我们从Azure Outage Post-Mortem中汲取一些教训。采用基于软件的#SANless集群解决方案的跨区域，跨云或混合云模型将大大有助于解决您的HA / DR问题。此外，它还为基于云的IaaS部署提供了出色的RTO和RPO。除应用程序特定解决方案外，还有其他选项。基于软件的块级卷复制解决方案（如SIOS DataKeeper和SIOS Protection Suite）可复制所有数据，并为Linux和Windows平台提供数据保护解决方案。我的大儿子刚刚在罗格斯大学开始他的气象学本科学位。想象一下，人工智能（AI）和机器学习（ML）处理来自NOAA的天气相关数据的那一天。他们可以在暴风雨袭击前两天触发计划的灾难恢复迁移？我想我刚刚为他的硕士论文找到了一个完美的主题。或者更好的是，让他和他在WeatherWatcher LLC的聪明的朋友获得资金，为一家技术创业公司应用AI和ML来安排相关数据以控制主动灾难恢复事件。我认为我们正处于IT分析解决方案的尖端。我们可以应用先进的机器学习技术来减少确保关键应用程序服务交付的时间和精力。 SIOS iQ是该领域领先的解决方案之一。压扁舱口并做好准备。飓风季刚刚开始，我们已经开始疯狂骑行了。如果您想在Twitter @daveberm上讨论您的HA / DR策略，请与我联系。

在Azure跨可用区中配置文件服务器故障转移群集

New-Cluster -Name cluster1 -Node sql1，sql2 -StaticAddress 10.0.0.100 -NoStorage

测试群集

Add-ClusterFileServerRole -Storage“DataKeeper Volume E”-Name FS2 -StaticAddress 10.0.0.101

＃定义变量
$ ClusterNetworkName =“” 
＃群集网络名称（在更高的Windows Server 2012上使用Get-ClusterNetwork查找名称）
$ IPResourceName =“” 
#IP地址资源名称 
$ ILBIP =“” 
＃内部负载均衡器的IP地址（ILB）
导入模块FailoverClusters
＃如果您使用的是Windows Server 2012或更高版本：
Get-ClusterResource $ IPResourceName | Set-ClusterParameter -Multiple @ {Address = $ ILBIP; ProbePort = 59999; SubnetMask =“255.255.255.255”; Network = $ ClusterNetworkName; EnableDhcp = 0}
＃如果您使用的是Windows Server 2008 R2，请使用以下命令： 
#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59999 subnetmask = 255.255.255.255