התקנת RRAS נכשלת כי שירות RemoteAccess נתקע

התקנת התפקיד נעצרת בשגיאה כללית ויומן האירועים לא מציע כמעט דבר לעבוד איתו. בשרתים שבהם זה קורה, החלק החסר אינו באשף כלל: שירות Remote Access אינו יוצא ממצב Starting לעולם. תפקיד שאינו יכול להשלים את האתחול שלו נכשל שוב בכל ניסיון, ולכן השירות קודם והאשף אחריו. תיקון זכות הכניסה אורך דקות, והתקנה חוזרת של התפקיד לא.

התחילו בשירות, לא באשף התפקיד

פתחו שורת פקודה מוגברת וקראו את תצורת השירות לפני שנוגעים בתפקיד. שני ערכים חשובים: סוג ההפעלה והחשבון שתחתיו רץ השירות. התקנה ברירת מחדל רושמת את השירות להפעלה אוטומטית ומעוכבת תחת Network Service.

אם הסטטוס עומד על Starting ולא על Running, השירות ממתין למשהו שהוא אינו יכול להשיג, וזכות הכניסה היא המועמדת הרגילה. המתנה ארוכה יותר לא עוזרת, משום שההפעלה כבר נכשלה באופן שמנהל בקרת השירותים מדווח עליו כממתין. עצרו את השירות בצורה נקייה וקראו שוב את התצורה שלו. לאחר מכן הסתכלו על ניסיון ההפעלה של השירות ביומן האירועים, כי שם מופיע שם החשבון לצד הכשל.

אשף התפקיד מדווח רק שהאתחול נכשל, ולכן בדיוק האבחון של השירות צריך לבוא ראשון.

קראו את זכות הכניסה לפני התקנה מחדש

Network Service זקוק לזכות הכניסה כשירות כדי להתחיל. חשבונות מובנים מקבלים אותה בדרך כלל באמצעות חברות בקבוצה, וקו בסיס מוקשח או רענון מדיניות עלולים לקחת אותה. מדיניות קבוצה מנצחת ברענון הבא, ולכן הענקה ידנית עלולה להיעלם שוב בלי אזהרה.

ייצאו את מדיניות האבטחה המקומית ו קראו את הרשומה במקום לסמוך על ה-GUI. זה משאיר לכם קובץ להשוואה אחרי רענון, וזו הדרך היחידה לדעת אם השינוי שרד. אם הרשומה ריקה או משמיטה את החשבון, מצאתם את התקלה. תעדו איזה אובייקט מדיניות מגדיר אותה, כי האובייקט הזה הוא שזקוק לתיקון הקבוע.

secedit /export /cfg C:\Windows\Temp\secpol-export.inf
Select-String -Path C:\Windows\Temp\secpol-export.inf -Pattern SeServiceLogonRight
sc.exe qc RemoteAccess
Get-Service RemoteAccess | Format-List Name, Status, StartType

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

הלוך ושוב של החשבון שכותב מחדש את התצורה

קיצור דרך מתקן את תצורת הכניסה של השירות בלי לערוך את המדיניות ביד: שנו את החשבון, החילו, ואז החזירו אותו עם שדות סיסמה ריקים.

ההלוך ושוב כותב מחדש את רשומת השירות ומעניק שוב לחשבון את הזכות שהוא צריך. זה מעקף ולא תיקון של שורש הבעיה, ולכן מקומו ביומן השינויים עם תאריך לצידו. במקום שבו קו בסיס מנהל את השרת, התיקון הנכון הוא להוסיף את החשבון להקצאת הכניסה כשירות באותו קו בסיס. עשו זאת קודם כשאפשר, והשתמשו בהלוך ושוב רק כדי לשחרר התקנה שתקועה אחרת.

sc.exe config RemoteAccess obj= "NT AUTHORITY\LocalService" start= demand
Start-Service RemoteAccess
sc.exe config RemoteAccess obj= "NT AUTHORITY\NetworkService" start= delayed-auto
Start-Service RemoteAccess

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

התקינו את התפקיד והוכיחו שהוא מותקן

כשהשירות פועל, הוסיפו את התפקיד שוב וכללו את תת-התכונה של VPN שאתם באמת מתכוונים להשתמש בה. התפקיד הכללי לבדו לא נותן לכם נקודת קצה VPN עובדת.

Install-WindowsFeature DirectAccess-VPN -IncludeManagementTools
Get-WindowsFeature RemoteAccess, DirectAccess-VPN, Routing
Get-Service RemoteAccess

ודאו שתת-התכונות מדווחות Installed ולא Available, ואז פתחו את המסוף והשלימו את התצורה הראשונית לפני שמישהו אחר נוגע במכונה. אם המסוף עדיין טוען שהשירות אינו פועל, חזרו לבדיקת השירות במקום להסיר את התפקיד.

רשמו מה שיניתם

הבחירות הראשונות של האשף קובעות כללי חומת אש, הקצאת כתובות והאם השרת מצפה לממסר DHCP. קומץ לקוחות מנקודה לאתר אינו זקוק לצורה של נקודת קצה מאתר לאתר. החליטו על התפקיד, על מאגר הכתובות, על שיטת האימות ועל מקור התעודה לפני שלוחצים. ניחוש כאן מייצר שרת שמותקן נקי ולעולם אינו מקבל חיבור.

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