שירותי ניהול Windows Server

מה חושף ניהול Windows Server?

ניהול Windows Server מסתיר לעיתים קרובות תקלות קריטיות עד שמשתמשים מתחילים לאבד גישה. כשקוראים לנו לדומיין של 400 מכונות שבו חצי מהמשתמשים פתאום לא יכולים להתחבר — זה לא היפותטי. הסיבה היא שכפול שבור בין בקרי דומיין: repadmin /showrepl מחזיר Access is denied, netlogon.log מלא ב-NO_CLIENT_SITE, וה-PDC נגמר לו המקום בדיסק — SYSVOL הפסיק לסנכרן דרך DFS-R. הניסיון שלנו מראה: 80% מהתקלות האלה ניתנות למניעה על ידי ביקורת שוטפת. אנחנו מבטיחים שאחרי העבודה שלנו, התשתית מפסיקה להיכשל ברגע הכי גרוע, וזמן ההתאוששות הממוצע יורד מ-6 שעות ל-15 דקות.

רוב הבעיות מאובחנות לא נכון. סימפטום: משתמש לא יכול להתחבר. רפלקס ראשון: אתחול DC או איפוס סיסמה. הסיבה האמיתית היא בדרך כלל אחת משלוש.

שכפול — repadmin /replsummary יראה אם יש פיגור בין שותפים. אם Delta (h:m:s) הוא יותר משעה — משהו כבר שבור. סיבה נפוצה היא שספקית האינטרנט משנה MTU בקישור ה-VPN בין אתרים, מה שגורם לפיצול של מנות Kerberos. repadmin /showrepl * /csv > repl.csv וניתוח ב-Excel חושף דפוסים מהר יותר מאשר GUI.

SYSVOL ו-GPO — DFS-R משכפל SYSVOL בין בקרי דומיין מאז Windows Server 2008 R2, כמתואר ב-Microsoft’s Active Directory Replication Model. אם ב-DC אחד dfsrdiag pollad מחזיר שגיאה ו-Get-DfsrState מראה Error, משתמשים באתר הזה מקבלים מדיניות מיושנת או לא מקבלים בכלל. gpresult /h report.html על המכונה הבעייתית מראה מיד איזה DC סיפק את המדיניות.

אתרים ו-Subnets — רשת משנה שלא מופתה ב-Active Directory Sites and Services אומרת שהלקוח מחפש את ה-DC הקרוב באמצעות אלגוריתם שאולי ישלח אותו לקצה השני של המדינה. התוצאה: התחברות לוקחת 40 שניות, ו-nltest /dsgetdc:domain מחזיר DC מעיר אחרת.

איך להימנע מקונפליקטים של GPO בארגונים גדולים?

מבנה GPO שטוח הוא שורש רוב בעיות הניהול. כשלארגון יש 150 מדיניויות מחוברות לשורש הדומיין, כל אחת מכילה 5 הגדרות ממנהלים שונים — זה חוב טכני שיכה בכל עדכון Windows.

ארכיטקטורה עובדת בנויה על העיקרון לרשת רק כלפי מטה, לחסום רק כחריג:

• ברמת הדומיין — רק הגדרות אבטחה של סיסמה ונעילה (אל תיגעו ב-Default Domain Policy, צרו אחת נפרדת)
• ברמת OU של האתר — הגדרות ספציפיות למיקום: פרוקסי, סיומות DNS, מדפסות
• ברמת OU של תפקיד (Workstations, Servers, Laptops) — תוכנות, ניהול צריכת חשמל, שומר מסך
• ברמת OU של משתמשים — מיפוי כוננים, סקריפטים של התחברות, הפניית תיקיות

Group Policy Results דרך gpmc.msc הוא חובה לכל פתרון בעיות. gpresult /scope computer /v מראה את הרשימה המלאה של מדיניויות שהוחלו וסוננו עם הסיבה לסינון. אם מסנן WMI לא עובד, זה נראה כאן.

בעיית RSOP: כששתי מדיניויות מתנגשות, זו עם מספר הסדר הגבוה יותר (נמוך יותר ברשימת הקישור של OU) מנצחת. זה לא מובן מאליו, ושם מופיעות הגדרות "בלתי מוסברות" על מכונות. כדי למנוע הפתעות, אנחנו תמיד בודקים GPO חדשים דרך gpresult על OU פיילוט לפני פריסה לייצור.

AppLocker במצב Audit לפני Enforce הוא חובה. ראיתי מצב שבו אחרי הפעלת Enforce, נמצא ש-30% מיישומי העסק רצו מ-%TEMP% והיו נחסמים.

איך לייעל IIS תחת עומס צעד אחר צעד?

IIS ברירת מחדל אחרי התקנה משתמש ב-DefaultAppPool עם .NET CLR 4, 32-bit מושבת, ו-Integrated pipeline. לרוב היישומים זו התחלה נורמלית, אבל תחת עומס נוצרות בעיות.

תרחיש נפוץ: היישום עובד, אבל כל כמה שעות משתמשים רואים timeout של 5–10 שניות. סיבה: מיחזור AppPool ברירת מחדל מופעל ב-1740 דקות (29 שעות). במהלך המיחזור, בקשות חדשות ממתינות לתהליך העובד החדש. פתרון:

1. בטלו מיחזור מתוזמן או עברו למיחזור מבוסס צריכת זיכרון (למשל, ב-80% זיכרון פרטי).
2. הפעילו 32-bit — התהליך הישן לא מת עד שהחדש מתחיל.
3. הגדירו Failed Request Tracing (FREB) — כלל עבור Integrated pipeline לוכד מעקב מלא, כולל זמן בכל מודול של ה-pipeline. זה מגלה לעיתים קרובות ש-4 מתוך 5 שניות מבוזבזות ב-overlappedRecycleOnSchedule או ב-HttpModule מותאם עם קריאות DB סינכרוניות.
4. לאוטומציה של פריסה, השתמשו ב-Failed Request Tracing transformations וב-timeTaken > 5000ms — עריכה ידנית של IsapiModule על מספר שרתים מובילה מהר לסטיית תצורה.

ביצועים תחת עומס — FREB הראה ש-90% מהזמן בוזבז ב-web.config — קריאה סינכרונית ל-MS SQL. שכתבנו את המודול לאסינכרוני, הפעלנו MSDeploy והגדלנו את מגבלות הזיכרון הפרטי של ה-pool. זמן התגובה ירד פי 4, ה-timeouts נעלמו. הלקוח חסך $45,000 בשנה על ידי ביטול זמן השבתה והפחתת זמן עיבוד בקשות ב-200 שעות בחודש.

Hyper‑V ו-WSUS: שכבת התשתית

Hyper‑V בייצור דורש הגדרת רשת נכונה. SET (Switch Embedded Teaming) במקום LBFO עבור מארחי Hyper‑V הוא לא רק המלצה — זו דרישה ש-RDMA ו-SR‑IOV יעבדו נכון. applicationHost.config מראה אם RDMA מופעל. אם לא, והמתאם תומך, הפעילו דרך ManagedEngine.

Live Migration ללא אחסון משותף דרך SMB Direct עובד משמעותית מהר יותר מאשר על פרוטוקול רגיל. תצורה: overlappedRecycle ו-SET.

WSUS — מקור נוסף לכאב. Get-NetAdapterRdma ב-IIS מוגדר כברירת מחדל ל-1.8 GB זיכרון פרטי. בתשתית עם 500+ לקוחות, ה-pool קורס כל הזמן. פתרון: הסירו את המגבלה או העלו אותה ל-4–8 GB, הפעילו 64-bit ל-pool, והריצו את Enable-NetAdapterRdma כדי לנקות עדכונים מיושנים. Set-VMHost -VirtualMachineMigrationEnabled $true ו-Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos דרך PowerShell מהיר יותר מאשר GUI.

MS SQL: מה לבדוק לפני שהכל קורס

WsusPool עם פילטר על wsus cleanup wizard הוא המקום הראשון כשמשתמשים מתלוננים על איטיות במסד הנתונים. Get-WsusProduct מראה על מה SQL Server ממתין: Invoke-WsusServerCleanup -CleanupObsoleteUpdates — בעיות דיסק, sys.dm_exec_requests — מקביליות, blocking_session_id > 0 — חסימות.

Maintenance Plan דרך SQL Server Agent עבור sys.dm_os_wait_stats ו-PAGEIOLATCH_SH קבועים הוא המינימום. עבור מסדי נתונים גדולים, שקלו את Ola Hallengren's SQL Server Maintenance Solution — חינמי, גמיש, מוכח בזמן. העלות של זמן השבתה לא מתוכנן של SQL יכולה לעלות על $20,000 לשעה בסביבות מסחר אלקטרוני.

מה כלול בעבודה (תוצרים)

איך העבודה בנויה

משימה טיפוסית — ביקורת ותיקון שכפול AD עם אופטימיזציה של מבנה GPO — לוקחת בין 3 ל-7 ימי עסקים. תשתית מלאה שנבנית מאפס (DC, WSUS, חוות IIS, קלאסטר Hyper‑V) לוקחת 3–6 שבועות תלוי בהיקף.