راهنمای جامع پایش و نگهداری ویندوز سرور

در این مقاله می‌خوانید

نسخهٔ ویندوز سرور و چرخهٔ پشتیبانی
Event Log: کجا را نگاه کنیم
سیاست ممیزی: رویدادی که ثبت نشود، دیده نمی‌شود
Performance Counterها: CPU، رم، دیسک و شبکه
سرویس‌ها: توقف بی‌صدا
آپدیت و ریبوت معوق
فضای دیسک و پر شدن درایو C
گواهی‌ها، ساعت و سلامت دیسک
امنیت پایه: Defender، فایروال و گروه Administrators
چک‌لیست نگهداری منظم
پایش بر اساس نقش سرور
یک سناریوی آشنا: شبی که سرویس بالا نیامد
خودکار کردن پایش در دامین
منابع و مطالعهٔ بیشتر

در بیشتر شرکت‌های ایرانی که با آن‌ها کار کرده‌ام، ستون فقرات شبکه ویندوز سرور است: دو Domain Controller، یک فایل‌سرور، یک یا دو SQL Server، چند سرور IIS برای اپلیکیشن‌های داخلی، و احتمالاً یک سرور قدیمی که «نباید به آن دست زد». این سرورها معمولاً سال‌ها بی‌دردسر کار می‌کنند، و همین بی‌دردسری باعث می‌شود کسی سراغشان نرود تا روزی که یکی از آن‌ها بی‌صدا از کار بیفتد.

این راهنما دربارهٔ این است که روی ویندوز سرور دقیقاً کجا را نگاه کنید: کدام لاگ‌ها و کدام شناسه‌های رویداد، کدام Performance Counterها، کدام تنظیمات که آرام‌آرام خراب می‌شوند، و چه کارهایی را باید منظم انجام داد. اصول کلی پایش (لایه‌ها، بسامد و آستانه) را در راهنمای جامع پایش سرور نوشته‌ام؛ اینجا تمرکز روی جزئیات خاص ویندوز است. همهٔ دستورها با PowerShell 5.1 که پیش‌فرض Windows Server 2016 تا 2022 است کار می‌کنند.

نسخهٔ ویندوز سرور و چرخهٔ پشتیبانی

پیش از هر پایشی، بدانید سرورهایتان چه نسخه‌ای دارند. نسخه‌ای که پشتیبانی امنیتی‌اش تمام شده، هر ماه آسیب‌پذیری تازه‌ای پیدا می‌کند که دیگر وصله نمی‌شود. هیچ مقداری از پایش این را جبران نمی‌کند.

نسخه	پایان پشتیبانی گسترده (امنیتی)	وضعیت
Windows Server 2012 / 2012 R2	اکتبر ۲۰۲۳	بدون آپدیت امنیتی (مگر با قرارداد ESU)؛ بیشتر ابزارهای جدید هم دیگر رویش اجرا نمی‌شوند
Windows Server 2016	ژانویهٔ ۲۰۲۷	کمتر از یک سال تا پایان؛ برنامهٔ ارتقا را همین حالا شروع کنید
Windows Server 2019	ژانویهٔ ۲۰۲۹	پشتیبانی‌شده
Windows Server 2022	اکتبر ۲۰۳۱	پشتیبانی‌شده
Windows Server 2025	۲۰۳۴	نسخهٔ جدید

برای گرفتن فهرست نسخه‌ها از همهٔ سرورهای دامین، اگر ماژول ActiveDirectory نصب است:

Get-ADComputer -Filter 'OperatingSystem -like "*Server*"' -Properties OperatingSystem, LastLogonDate |
  Sort-Object OperatingSystem |
  Select-Object Name, OperatingSystem, LastLogonDate

ستون LastLogonDate را هم نگاه کنید: سروری که ماه‌هاست به دامین وصل نشده یا خاموش است، یا هنوز در گوشه‌ای کار می‌کند و کسی نمی‌داند.

Event Log: کجا را نگاه کنیم

Event Viewer ده‌ها لاگ دارد و بیشترشان برای پایش روزمره لازم نیستند. سه لاگ اصلی که باید بشناسید:

System: رویدادهای سیستم‌عامل، درایورها و Service Control Manager. خاموشی ناگهانی، خطای دیسک، سرویس متوقف و نصب سرویس جدید اینجاست.
Security: رویدادهای ممیزی (audit)، یعنی ورود، خروج، تغییر حساب و گروه، دسترسی به اشیا. فقط آنچه در سیاست ممیزی روشن کرده‌اید ثبت می‌شود.
Application: رویدادهای برنامه‌ها؛ SQL Server، IIS (بخشی)، ⁦.NET⁩ Runtime و Application Error.

علاوه بر این‌ها، لاگ‌های «Applications and Services Logs» برای نقش‌های خاص مهم‌اند؛ مثلاً Microsoft-Windows-Windows Defender/Operational برای آنتی‌ویروس و Directory Service روی DCها.

شناسه	لاگ و منبع	معنا	اقدام
41	System / Kernel-Power	سیستم بدون خاموشی تمیز ریبوت شد	برق، UPS، صفحهٔ آبی، hypervisor را بررسی کنید
6008	System / EventLog	خاموشی قبلی غیرمنتظره بود	همراه 41 بررسی شود
1074	System / User32	خاموشی یا ریبوت با درخواست یک کاربر یا پروسس	چه کسی و چرا؟ (مثلاً Windows Update)
7031، 7034	System / Service Control Manager	سرویس به‌طور غیرمنتظره متوقف شد	لاگ Application همان زمان را ببینید
7045	System / Service Control Manager	سرویس جدید نصب شد	اگر نصبی برنامه‌ریزی نشده بود، مشکوک است
4625	Security	ورود ناموفق	تعداد زیاد از یک آی‌پی یعنی حدس رمز
4720	Security	حساب کاربری جدید ساخته شد	با درخواست ثبت‌شده تطبیق دهید
4732	Security	عضو به گروه محلی امنیتی (مثل Administrators) اضافه شد	هر ادمین تازه باید توضیح داشته باشد
1102	Security	لاگ امنیتی پاک شد	تقریباً همیشه بحرانی
153، 129	System / disk، storport و مشابه	تلاش دوباره یا reset در I/O دیسک	مسیر ذخیره‌سازی، کابل، SAN یا دیسک را بررسی کنید

با Get-WinEvent و FilterHashtable می‌توانید سریع و بدون بار سنگین روی سرور جستجو کنید. Where-Object روی کل لاگ را فراموش کنید؛ روی لاگ امنیتی پر، دقیقه‌ها طول می‌کشد.

# Unexpected shutdowns and stopped services in the last 7 days
Get-WinEvent -FilterHashtable @{
  LogName   = 'System'
  Id        = 41, 6008, 7031, 7034, 7045
  StartTime = (Get-Date).AddDays(-7)
} | Select-Object TimeCreated, Id, ProviderName, Message | Format-List

# Count failed logons per source IP in the last hour
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-1)} |
  ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data |
    Where-Object Name -eq 'IpAddress' | Select-Object -ExpandProperty '#text' } |
  Group-Object | Sort-Object Count -Descending | Select-Object Count, Name -First 10

یک نکتهٔ مهم: اندازهٔ پیش‌فرض لاگ Security روی بسیاری از سرورها ۲۰ مگابایت است که روی DC یا سرور RDP پرترافیک گاهی کمتر از یک روز را نگه می‌دارد. وقتی حادثه‌ای را دو روز بعد بررسی می‌کنید، شواهد رفته‌اند. اندازه را بزرگ‌تر کنید:

wevtutil gl Security          # current settings
wevtutil sl Security /ms:1073741824   # 1 GB

سیاست ممیزی: رویدادی که ثبت نشود، دیده نمی‌شود

بسیاری از رویدادهای امنیتی مهم به‌طور پیش‌فرض ثبت نمی‌شوند. مهم‌ترینش رویداد 4688 (ایجاد پروسس) است که برای دیدن اجرای vssadmin delete shadows یا PowerShell مشکوک لازم است. وضعیت فعلی را ببینید:

auditpol /get /category:*
auditpol /get /subcategory:"Process Creation"

در دامین، سیاست ممیزی را با GPO در مسیر Computer Configuration ← Policies ← Windows Settings ← Security Settings ← Advanced Audit Policy Configuration تنظیم کنید، نه با auditpol روی تک‌تک سرورها؛ GPO بعد از مدتی تنظیم دستی را بازنویسی می‌کند. برای ثبت خط فرمان کامل در 4688، تنظیم «Include command line in process creation events» در مسیر Administrative Templates ← System ← Audit Process Creation را هم روشن کنید.

زیردسته	تنظیم پیشنهادی	رویدادهای کلیدی
Logon	Success و Failure	4624، 4625
Account Lockout	Failure	4625 (با وضعیت قفل)
User Account Management	Success و Failure	4720، 4722، 4724، 4726
Security Group Management	Success	4728، 4732، 4756
Process Creation	Success	4688
Audit Policy Change	Success	4719
Security System Extension	Success	4697 (نصب سرویس در لاگ امنیتی)

Performance Counterها: CPU، رم، دیسک و شبکه

ویندوز صدها شمارندهٔ کارایی دارد. برای پایش روزمره ده‌دوازده‌تا کافی است. Get-Counter بدون ابزار اضافه آن‌ها را می‌خواند:

Get-Counter -Counter @(
  '\Processor(_Total)\% Processor Time',
  '\System\Processor Queue Length',
  '\Memory\Available MBytes',
  '\Memory\Pages/sec',
  '\LogicalDisk(*)\% Free Space',
  '\LogicalDisk(*)\Avg. Disk sec/Read',
  '\LogicalDisk(*)\Avg. Disk sec/Write',
  '\PhysicalDisk(*)\Current Disk Queue Length',
  '\Network Interface(*)\Bytes Total/sec'
) -SampleInterval 5 -MaxSamples 3

شمارنده	چه می‌گوید	مقدار نگران‌کننده (تقریبی)
% Processor Time	مصرف کل CPU	بالای ۹۰٪ به‌طور پایدار
Processor Queue Length	نخ‌های منتظر CPU	پایدار بیش از ۲ برابر تعداد هسته
Available MBytes	رم آزاد قابل استفاده	کمتر از ۵٪ رم کل یا چند صد مگابایت
Pages/sec	خواندن و نوشتن صفحه از دیسک	بالا و پایدار، همراه با رم آزاد کم
Avg. Disk sec/Read و Write	تأخیر هر عمل دیسک	پایدار بیش از ۰٫۰۲ ثانیه (۲۰ میلی‌ثانیه) روی SSD یا SAN
Current Disk Queue Length	درخواست‌های منتظر دیسک	پایدار بالا، همراه با تأخیر زیاد
Bytes Total/sec	ترافیک کارت شبکه	نزدیک به ظرفیت کارت برای مدت طولانی

اشتباه رایج دربارهٔ رم: مدیرانی که SQL Server را با ۹۵٪ مصرف رم می‌بینند و نگران می‌شوند. SQL Server عمداً هرچه رم پیدا کند برای buffer pool می‌گیرد. برای SQL Server به‌جای درصد رم، max server memory را درست تنظیم کنید و به Available MBytes سیستم‌عامل نگاه کنید. پایش عمیق خود SQL Server (کوئری کند، بکاپ، رشد فایل log) موضوع جدایی است که DBMug برایش ساخته شده.

سرویس‌ها: توقف بی‌صدا

یکی از رایج‌ترین حادثه‌ها این است: سرویسی (مثلاً SQL Server Agent یا یک سرویس اپلیکیشن داخلی) بعد از آپدیت و ریبوت بالا نمی‌آید و تا صبح که کاربران زنگ بزنند کسی نمی‌فهمد. دو کار انجام دهید. اول، سرویس‌های اصلی هر سرور را با نام پایش کنید. دوم، به‌طور عمومی سرویس‌های Automatic را که اجرا نمی‌شوند بررسی کنید:

Get-CimInstance Win32_Service -Filter "StartMode='Auto' AND State<>'Running'" |
  Where-Object Name -notin 'sppsvc','gupdate','RemoteRegistry','MapsBroker','edgeupdate' |
  Select-Object Name, DisplayName, State, ExitCode

تنظیم Recovery سرویس (زبانهٔ Recovery در services.msc یا sc.exe failure) هم کمک می‌کند سرویس بعد از crash خودش دوباره بالا بیاید. ولی این جای پایش را نمی‌گیرد: سرویسی که هر شب crash می‌کند و خودش برمی‌گردد، مشکلی دارد که باید بدانید.

sc.exe failure MyAppService reset= 86400 actions= restart/60000/restart/60000/""/0
sc.exe qfailure MyAppService

آپدیت و ریبوت معوق

سروری که آپدیت را نصب کرده ولی ریبوت نشده، هنوز آسیب‌پذیر است؛ فایل‌های جدید تا ریبوت جایگزین نمی‌شوند. سه جای رجیستری ریبوت معوق را نشان می‌دهد:

$pending = @(
  Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
  Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
  [bool](Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager' -Name PendingFileRenameOperations -ErrorAction SilentlyContinue)
)
"Reboot pending: $($pending -contains $true)"

مورد سوم (PendingFileRenameOperations) گاهی توسط نرم‌افزارهای دیگر هم پر می‌شود و همیشه به معنای آپدیت ویندوز نیست. تاریخ آخرین آپدیت نصب‌شده را هم ببینید:

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 HotFixID, Description, InstalledOn

اگر آخرین آپدیت بیش از دو ماه پیش است، یا Windows Update خراب است یا کسی عمداً آپدیت را متوقف کرده و فراموش کرده. هر دو را باید بدانید.

فضای دیسک و پر شدن درایو C

پر شدن C روی ویندوز سرور بسیار رایج است و معمولاً سه مقصر دارد: پوشهٔ WinSxS و کش آپدیت، لاگ‌های IIS در C:\inetpub\logs\LogFiles که هیچ‌وقت پاک نمی‌شوند، و پروفایل‌های کاربری روی سرورهای RDP. پاک‌سازی امن:

# Component store cleanup (safe; never delete WinSxS by hand)
Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore
Dism.exe /Online /Cleanup-Image /StartComponentCleanup

# IIS logs older than 30 days
Get-ChildItem 'C:\inetpub\logs\LogFiles' -Recurse -Filter *.log |
  Where-Object LastWriteTime -lt (Get-Date).AddDays(-30) | Remove-Item -WhatIf

پارامتر -WhatIf را بعد از اطمینان بردارید. هرگز فایل‌های داخل C:\Windows\WinSxS یا C:\Windows\Installer را دستی پاک نکنید؛ نتیجه‌اش سروری است که دیگر آپدیت نمی‌گیرد یا نرم‌افزارهایش حذف نمی‌شوند.

گواهی‌ها، ساعت و سلامت دیسک

سه چیز که آرام خراب می‌شوند و ناگهان دردسر می‌سازند:

گواهی‌ها. گواهی IIS، RDP، LDAPS یا گواهی داخلی اپلیکیشن که منقضی شود، سرویس را از کار می‌اندازد. فهرست گواهی‌های نزدیک به انقضا در مخزن LocalMachine\My:

Get-ChildItem Cert:\LocalMachine\My |
  Where-Object NotAfter -lt (Get-Date).AddDays(30) |
  Select-Object Subject, NotAfter, Thumbprint

ساعت. در دامین، اختلاف ساعت بیش از ۵ دقیقه (پیش‌فرض Kerberos) باعث شکست احراز هویت می‌شود. سرورهای عضو ساعت را از DC می‌گیرند و DC دارندهٔ نقش PDC Emulator باید از منبع بیرونی معتبر بگیرد. اشتباه رایج این است که PDC Emulator ماشین مجازی است و ساعتش را از میزبان Hyper-V یا VMware می‌گیرد و میزبان خودش ساعت غلطی دارد.

w32tm /query /status
w32tm /query /source
w32tm /monitor

سلامت دیسک فیزیکی. روی سرورهای فیزیکی، Get-PhysicalDisk وضعیت سلامت و عملیاتی را از دید ویندوز نشان می‌دهد. روی سرورهایی با کنترلر RAID سخت‌افزاری، ویندوز فقط دیسک مجازی را می‌بیند و باید ابزار سازنده (مثلاً iDRAC یا iLO) را هم پایش کنید.

Get-PhysicalDisk | Select-Object FriendlyName, MediaType, HealthStatus, OperationalStatus, Size

امنیت پایه: Defender، فایروال و گروه Administrators

سه وضعیت که باید هر روز درست باشند و اغلب بی‌آنکه کسی بفهمد خراب می‌شوند:

# Microsoft Defender status
Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled,
  AntivirusSignatureAge, AntivirusSignatureLastUpdated

# Firewall profiles
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction

# Local administrators
Get-LocalGroupMember -Group Administrators

فایروالی که «موقتاً برای تست» خاموش شده و دیگر روشن نشده، در شبکه‌هایی که دیده‌ام تقریباً قاعده است تا استثنا. همین‌طور حساب‌هایی که «فقط برای نصب» به Administrators اضافه شدند و سال‌ها ماندند. اگر آنتی‌ویروس دیگری (ESET، Kaspersky و…) نصب است، دقت کنید که برخلاف ویندوز کلاینت، Defender روی ویندوز سرور خودبه‌خود کنار نمی‌رود؛ باید آن را حذف یا در حالت Passive بگذارید تا دو موتور با هم تداخل نکنند، و از آن به بعد وضعیت همان محصول دیگر را پایش کنید.

چک‌لیست نگهداری منظم

پایش خودکار مشکل را خبر می‌دهد، ولی برخی کارها باید منظم و با دست انجام شوند. این فهرستی است که برای مشتری‌هایمان پیشنهاد می‌کنم:

بازه	کار
روزانه	نگاه به هشدارهای باز، سرورهای آفلاین، بکاپ شب گذشته
هفتگی	مرور ورودهای ناموفق و آی‌پی‌های مبدأ، روند فضای دیسک، سرویس‌هایی که crash کرده‌اند
ماهانه (پس از Patch Tuesday)	نصب آپدیت در پنجرهٔ نگهداری، ریبوت، بررسی بالا آمدن سرویس‌ها
ماهانه	بازبینی اعضای Administrators و Domain Admins، گواهی‌های نزدیک به انقضا
فصلی	آزمون بازیابی بکاپ، مرور نرم‌افزارهای نصب‌شده و پورت‌های باز، برنامهٔ ارتقای نسخه‌های قدیمی

پایش بر اساس نقش سرور

چک‌های بالا برای همهٔ سرورها مشترک‌اند. ولی هر نقش، نقطه‌های ضعف خودش را دارد و چند چک اضافه می‌خواهد:

Domain Controller. اگر DC بیمار باشد، همه‌چیز بیمار است: ورود کاربران، GPO، DNS داخلی. تکرار (replication) بین DCها را دست‌کم هفته‌ای یک بار بررسی کنید. DCی که بیش از tombstone lifetime (پیش‌فرض ۱۸۰ روز در جنگل‌های جدید) تکرار نکرده باشد، دیگر قابل برگرداندن به جنگل نیست و باید پاک و از نو ساخته شود.

repadmin /replsummary
repadmin /showrepl * /csv | ConvertFrom-Csv | Where-Object 'Number of Failures' -gt 0
dcdiag /q          # only errors
Get-Service NTDS, DNS, Netlogon, KDC, W32Time | Select-Object Name, Status

فایل‌سرور. علاوه بر فضای درایو داده، تعداد نشست‌ها و فایل‌های باز نشان می‌دهد چه کسی به چه چیزی وصل است؛ هنگام حملهٔ باج‌افزار، همین فهرست نشان می‌دهد رمزگذاری از کدام کلاینت می‌آید.

Get-SmbSession | Select-Object ClientComputerName, ClientUserName, NumOpens
Get-SmbOpenFile | Group-Object ClientComputerName | Sort-Object Count -Descending

سرور IIS. Application Poolی که به‌خاطر خطاهای پشت‌سرهم (Rapid-Fail Protection) متوقف شده، خطای 503 به کاربر می‌دهد در حالی که سرویس W3SVC «در حال اجرا» است. پس فقط پایش سرویس کافی نیست:

Import-Module WebAdministration
Get-ChildItem IIS:\AppPools | Select-Object Name, State
# Rapid-fail events are logged in System by WAS, e.g. event 5002
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WAS'; StartTime=(Get-Date).AddDays(-1)} -ErrorAction SilentlyContinue

یک سناریوی آشنا: شبی که سرویس بالا نیامد

بگذارید یک الگوی تکراری را تعریف کنم که در چند شرکت با جزئیات کمی متفاوت دیده‌ام. سه‌شنبهٔ پس از Patch Tuesday، آپدیت‌ها شب نصب می‌شوند و سرور اپلیکیشن ساعت سه بامداد ریبوت می‌شود. سرویس اپلیکیشن به سرویس SQL Server روی سرور دیگری وابسته است، و چون SQL هم در همان شب ریبوت شده و دیرتر بالا آمده، سرویس اپلیکیشن در شروع خطای اتصال می‌گیرد و متوقف می‌ماند. ساعت هشت صبح کاربران زنگ می‌زنند.

در Event Log همه‌چیز ثبت شده بود: رویداد 1074 برای ریبوت به دست Windows Update، رویداد 7000 یا 7034 برای شکست سرویس، و خطای اتصال در لاگ Application. ولی هیچ‌کدام کسی را خبر نکرد. سه تغییر کوچک این حادثه را بی‌اثر می‌کند: پایش سرویس اپلیکیشن با نام و هشدار پیامکی، تنظیم Recovery سرویس برای تلاش دوباره پس از یک دقیقه، و جدا کردن زمان ریبوت سرور پایگاه داده و سرور اپلیکیشن. مورد اول در پنج دقیقه انجام می‌شود و بیشترین اثر را دارد.

خودکار کردن پایش در دامین

همهٔ دستورهای بالا را می‌شود در یک اسکریپت PowerShell جمع کرد و با Task Scheduler اجرا کرد. برای پنج سرور این کار شدنی است؛ برای پنجاه سرور، نگه‌داری اسکریپت‌ها، جمع کردن خروجی‌ها و ساختن هشدار از آن‌ها خودش یک پروژه می‌شود. اینجاست که یک ابزار پایش با agent معنا پیدا می‌کند.

اگر از ServerMug استفاده می‌کنید، بیشتر چک‌های این مقاله (رویدادهای امنیتی، سرویس‌ها، آپدیت و ریبوت معوق، Defender، فایروال، گواهی‌ها، ساعت و سلامت دیسک) بدون اسکریپت انجام می‌شوند. روش نصب سنسور در نصب سنسور روی ویندوز سرور آمده است، و برای اینکه سرورهای تازهٔ دامین خودبه‌خود پایش شوند، پخش با GPO را ببینید. هر چکی که در فهرست نیست (مثلاً اندازهٔ یک صف یا وضعیت یک جاب) را می‌توانید به‌صورت چک سفارشی با اسکریپت PowerShell اضافه کنید.

با هر ابزاری که کار می‌کنید، یک چیز را فراموش نکنید: پایش ویندوز سرور فقط CPU و رم نیست. بیشتر حادثه‌های جدی که دیده‌ام از جاهایی شروع شدند که نمودار ندارند: سرویسی که بالا نیامد، گواهی‌ای که منقضی شد، ادمینی که کسی اضافه‌اش نکرده بود.

منابع و مطالعهٔ بیشتر

رویدادهایی که باید پایش شوند (Microsoft Learn) — فهرست رسمی مایکروسافت از شناسه‌های رویداد امنیتی با درجهٔ اهمیت.
مستندات Get-WinEvent — همهٔ پارامترها و مثال‌های FilterHashtable و FilterXPath.
Performance Monitor در ویندوز سرور — ابزار رسمی برای دیدن و ثبت Performance Counterها.
چرخهٔ عمر Windows Server 2022 — تاریخ‌های دقیق پشتیبانی؛ صفحه‌های مشابه برای نسخه‌های دیگر هم هست.