作为最后一篇，主要介绍下余下的八个模块，在脚本中，

GetUUID
GetLanIp
GetOSVersion

以上三个模块是脱离于场景值之外的，内网IP=GetLanIP，获取系统版本=GetOSVersion，GetOSVersion是通过WMIObject获取的，这倒算是中规中矩，但是LanIP就有点意思了，可以看到笔者并没有使用ipconfig去做格式化，而是剑走边锋的选择了System.Net.Dns作为获取内网IP，这是.Net的一种写法（是的，PowerShell是支持.Net的），其中GetHostAddresses可以直接获取到多个DNS属性下的主机IP，再通过AddressFamily进行InterNetwork过滤，确实比直接通过ipconfig要优雅多了，同时精准率会高很多（毕竟在有直通WanIP的情况，通过ipconfig去获取存在误差），这也算是这个工具的一个小彩蛋吧。

也就是说无论在场景1还是场景2，以上三个模块都会执行，UUID属于CVM的一种特殊标识，在Windows Server运维里并没有太大用处（主要用于云API调用时可以从内部获取UUID做校验），而GetLanIP与GetOSVersion就有点作用了，DHCP冲突、内网IP设置有误都可以通过这里看得出来，如果你获取日志后出来的LanIP是169.x.x.x那就证明获取不到IP而系统采用默认环回地址了。

1，来聊下场景1里：GetSyinfo，挺有意思的，通过systeminfo获取了很多信息，systeminfo其实是个非常有用的命令，在补丁经常导致crash的年代，这个命令可以精准获取到所有打的KB（补丁包），同时Systeminfo其实是““我的电脑”右键“属性”的缩影，包含性能信息，在使用云厂商的服务时，这里也可以用作配置对比，在日志收集工具里，它是这么实现的：

          "——————————以下 QCloud Windows 默认产品ID————————————
                      WS2K12R2DC：00253-50000-00000-AA442
                       WS2K12R2Sta：00252-70000-00000-AA535
                       WS2K8R2ENP：00486-001-0001076-84927
    
    " | Out-File -Append ".\$Dirfilename\$Logfilename"
    systeminfo | Out-File -Append ".\$Dirfilename\$Logfilename"

2，可以看到，特意加了默认产品ID在上面，我在想，一个排查故障的收集产品ID对于Windows Server相关故障有什么帮助呢？产品ID在WIndows Server里除了标识这是个什么系统外，还起到了选择License的作用，这个选择License其实就是购买Windows Server时用来匹配License类型的，简单来说就是在激活Windows Server时起到至关重要的因素，不同于Linux，Windows Server存在商用授权费用问题，通常云厂商都会构建一套KMS（Key Manage Server）来管理License（通常是一个带有激活上限的Key），服务器通过1688端口去连接KMS服务器，然后取得授权（一定周期内），所以1688链接会定时去与KMS做“互动”（检查License情况），所以一个Windows Server 云服务器激活失败可能出现的情况是：

1 与KMS的1688端口不通
2 KMS服务器地址设置错误
3 产品ID存在问题（被某些安全软件或者激活工具篡改）

3，当激活不成功不同的os也会出现不同的症状：

1 WS2k8r2:黑屏并提示
2 WS2k12+ 定时关机

4，所以，这就是产品ID在这里的作用所在（如果可以把KMS服务器地址/端口情况也收集了那就完美解决激活问题了），你还真别笑，国内云厂商激活问题出现次数并不在少数（虽然是个非常基础的问题）。

5，接下来，来聊聊Windows Event Log的四大金刚，在日志提取工具里是通过wevtutil实现，这是个常见日志收集命令，这里就不详述，这里就借助四大金刚来聊聊日志的使用：

GetAPLog $startDate $endDate $start $end
GetSYLog $startDate $endDate $start $end
GetSeLog $startDate $endDate $start $end
GetSetLog $startDate $endDate $start $end

• GetAPLog

 Application日志，也就是应用程序日志，Windows Server把所有的应用级别（用户态）程序出现的问题默认都放在这里，比如你的应用程序调用**某某dll失败或者注册表**写入失败只要你遵循微软开发规则，基本日志都会出现在这里，所以会看到围绕着应用程序出现的性能/功能问题都会体现在这里，当你的环境或者你的客户怀疑应用出现问题（微软系应用），你应该第一时间考虑这里，笔者以前在搞私有云Demo时GUI上经常出现拒绝访问之类的问题，通常GUI上不会给你太多信息，而在日志里会体现出来，这里一般关注**详细信息与时间：**

• GetSYLog

System日志，系统相关组件以及包括子系统都会在这里记录，IO重置/系统事件/内部错误等等，通常出现性能问题，宕机问题都可以在这里找到一定蛛丝马迹。比如来自TS的连接会话上限就可以知道你为什么无法登录这个系统了：

• GetSeLog

GetSeLog，主要对应得是获取security日志，这里主要记录得是安全类得日志，对标Linux的audit，但是比audit稍弱的地方是针对文件级别的审计监控没有Linux那么遍历，因为蹩脚的转义经常不知道安全日志里所云何物，除了常规的账户相关动作（登入/登出/修改密码/被锁定等），还可以通过GPO（组策略）来控制审计，通过gpedit.msc进行设置：

开启这个之后，相关文件系统的操作记录就会被记录下来，当然关于审计策略光学就可以学上4节课，大家可以灵活应用。

• GetSetLog

Setup日志，主要记录了补丁/软件安装的记录（有通过注册表才会触发），笔主经常遇到的是云主机因为一次性选择更新太多下载与安装产生的性能风暴导致系统异常，那么通过这里可以查到，如果系统异常时event也出现问题，这里可能会为空，所以一般也会看wsus的更新日志（云厂商一般通过wsus进行下发补丁，WSUS分为上下游，这里的知识可以通过微软KB库了解）：

---

聊到这里，深度解读了腾讯云所提供的“WIndows Server 日志收集工具”到底是个什么鬼，那么对于Windows Server运维者来说究竟有什么更好的运维手段呢？

且听笔者一句劝，无论是Windows还是Linux抑或是Unix都是大部分理论是相同的，与其与人争吵对比这几个平台之类的差异，不如好好研究下底层的各个子系统，如果您熟悉Windows Server（不知道看完这五篇后您还有没有这个自信）那就继续深度去学习，而不是停留在使用桌面版就觉得已经“精通”了这个庞大的系统，作为一个系统运维从业者，如果为了平台而去争论其实是彰显无知。希望借助这五篇文章，您能够多少明白一些学习的路线，也要明白”我不懂Windows/Linux“这一句话是多么的苍白无力，系统无国界，希望您成为一个无界工程师。

在解析到最后一句后，我翻到前面准备关闭脚本IDE，赫然发现脚本头的标注：

<#    
    ===========================================================================
     Created with:     PowerShell
     Created on:       2017/5/22 16:11
     Update time：    2018/6/4 22:55
     Created by:       statli
     Organization:     Tencent-QCloud
     Projectname:   QCloudStatusCheck
     Version:         1.4.4
    ===========================================================================
#>

现在，能理解，作为腾讯云扫地大爷的良苦用心吗？

P.S:链接为1.4.4版的Windows Server 日志收集工具下载

QCloud_Windows_Status_Check_Script