【问题标题】:Querying Windows Update Errors using PowerShell Get-WinEvent or Get-WMIObject使用 PowerShell Get-WinEvent 或 Get-WMIObject 查询 Windows 更新错误
【发布时间】:2017-10-14 15:06:54
【问题描述】:

尝试使用 Get-WinEvent 创建一个简单的 Windows 更新错误查询(尽管我更喜欢查询 WMI 对象以与 SCUP 一起使用):

get-winevent -logname System| Where-Object {$_.ProviderName -eq "Microsoft-Windows-WindowsUpdateClient"}

这似乎在大多数情况下都有效。但是,它只返回信息事件而不是错误。这些是否位于其他地方,如果是,我将如何查询它们?对于某些背景,在我的环境中大约 10% 的 Windows 10 机器上发生了特定的更新失败(缺少程序集文件),我想针对它来部署解决方案。

使用 Get-WinEvent 的解决方案很好,但如果可能,我更喜欢使用 Get-WMIObject。

【问题讨论】:

  • 更新:Get-WinEvent -Logname "Microsoft-Windows-WindowsUpdateClient/Operational" 返回我寻求的信息。我想现在的问题是:它位于 WMI(命名空间/类)中的什么位置?

标签: powershell event-handling event-log error-log get-winevent


【解决方案1】:

您可以像这样使用 Win32_NTLogEvent

Get-WmiObject Win32_NTLogEvent |?{($_.LogFile -eq 'System') -and ($_.SourceName -eq 'Microsoft-Windows-WindowsUpdateClient') }

注意:您可以使用 Type 进一步过滤,它会告诉您有关信息或错误或警告的信息。

希望对你有帮助。

【讨论】:

  • 这个查询基本上完成了我已经在做的事情。似乎无法解决我面临的核心问题,即 Microsoft-Windows-UpdateClient 源中类型为“错误”的事件未出现在查询中。当我查看此日志下的事件查看器时,会出现错误。但是,在 PowerShell 中查询时,它们不会。
  • @WKJ:它带有你一直在请求的 wmiobject
【解决方案2】:

我找不到任何实际说明这一点的东西,但它看起来像 Get-WinEvent 默认情况下只返回信息消息。如果你想看到另一个,那么你需要告诉它返回那些。一种方法是使用-FilterHashtable

Get-WinEvent -FilterHashtable @{LogName='System';Level=1,2}

这将只返回警告和错误。

1 - 错误

2 - 警告

4 - 信息

您可以查看枚举 [System.Diagnostics.EventLogEntryType] 以了解我从哪里得到这些数字。

Looking at MS你可以看到哈希表过滤器支持什么..

LogName=<String[]>
ProviderName=<String[]>
Path=<String[]>
Keywords=<Long[]>
ID=<Int32[]>
Level=<Int32[]>
StartTime=<DateTime>
EndTime=<DataTime>
UserID=<SID>
Data=<String[]>
*=<String[]>

如果您的 WMI 查询有类似的问题,那么您可以这样做

Get-WmiObject -class Win32_NTLogEvent -filter "(logfile='Application') AND (type='error')" 

你可以找到一些切题的例子here

【讨论】:

    【解决方案3】:

    编写 WMI 查询(这会覆盖奇怪的事件类型过滤器):

    Get-WmiObject -Query "Select * from Win32_NTLogEvent" |?{(($_.LogFile -eq 'System') -and ($_.Type -in ("Error", "Warning"))) -and ($_.SourceName -eq 'Microsoft-Windows-WindowsUpdateClient') }
    

    【讨论】:

      【解决方案4】:

      好的,所以在做了一些额外的研究之后,我偶然发现了this website,它为我遇到的问题提供了一些线索。从本质上讲,虽然大多数(如果不是所有)Windows 事件都记录在 C:\Windows\System32\Winevt\logs 文件夹中,但默认情况下并非所有 Windows 事件都在 WMI 中复制.

      在 PowerShell 中,Get-WinEvent 在查询其事件数据时似乎使用上述文件夹,而 Get-EventLog 使用 Win32_WinNTLogEvent WMI类。

      在我最初的问题中,我提到我无法使用 Get-WinEvent 查询 Windows 更新错误事件。这是因为我指向的是 System 日志文件,它不包含信息。 Microsoft-Windows-WindowsUpdateClient/Operational 日志文件(文字路径为 C:\Windows\System32\Winevt\logs\Microsoft-Windows-UpdateClient%4Operational.evtx)包含此信息,因此可以使用类似于以下内容的方式简单地更改我的查询:

      Get-WinEvent -logname "Microsoft-Windows-WindowsUpdateClient/Operational" | Where-Object {$_.LevelDisplayName -eq "Error"}
      

      为了使用 Win32_NTLogEvent WMI 类查询 Get-WinEvent 返回的相同数据,必须首先修改注册表。同样,我在此答案中发布的链接更详细地描述了该过程,但基本上我执行了以下注册表模式:

      Windows Registry Editor Version 5.00
      
      [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-WindowsUpdateClient/Operational]
      "File"="%SystemRoot%\\System32\\Winevt\\Logs\\Microsoft-Windows-WindowsUpdateClient%4Operational.evtx"
      "Primary Module"="Microsoft-Windows-WindowsUpdateClient/Operational"
      "Microsoft-Windows-WindowsUpdateClient/Operational"=hex(2):25,00,53,00,79,00,73,00,74,\
        00,65,00,6d,00,52,00,6f,00,6f,00,74,00,25,00,5c,00,73,00,79,00,73,00,74,00,\
        65,00,6d,00,33,00,32,00,5c,00,77,00,65,00,76,00,74,00,61,00,70,00,69,00,2e,\
        00,64,00,6c,00,6c,00,00,00
      

      注意:末尾的“Microsoft-Windows-WindowsUpdateClient/Operational”扩展字符串 (REG_EXPAND_SZ) 指向 %SystemRoot%\system32\wevtapi.dll

      修改注册表后,我可以查询到错误事件如下:

      Get-WmiObject -query "SELECT * FROM Win32_NTLogEvent WHERE LogFile='Microsoft-Windows-WindowsUpdateClient/Operational' AND Type='Error'"
      

      考虑到 Windows Update 错误应该可能默认出现在 Win32_NTLogEvent WMI 类中(啊,Microsoft),这有点痛苦。不过,这基本上解决了我的问题。

      还有一点需要提及。上面的网站指出,在编辑注册表后,您可以立即查询新事件。我必须先重启我的机器。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2018-11-14
        • 1970-01-01
        • 2019-06-15
        • 1970-01-01
        • 1970-01-01
        • 2015-11-23
        • 1970-01-01
        相关资源
        最近更新 更多