בעית GPO errors : 1030,1058 פתרון!

[tomer65538]

בעית GPO errors : 1030,1058 פתרון!

שלום לכם, לאחר ייסורים רבים, הצלחתי לתקן את הבעיה. אני מציין את זה כאן כדי שבאם תישאלו שוב על ידי מישהו שאלה כמו : the computer policy settings aren't working, but user policy settings does תוכלו להפנות אותו למה שאני רושם כאן, שכן אינני מאחל לאף אחד את מה שעברתי אז למעשה הבעייה דיי פשוטה. מדווח ליוזר ב EVENT LOG שגיאה בסגנון ACCESS DENIED. בעצם הרשאות הן NTFS והן SHARE נכונות והבעיה נובעת ממקור אחר. מסתבר שאותו מחשב שמתחבר לדומיין לא מצליח להכנס לתיקיה כי שרת ה DNS שהוגדר לו הוא לא נכון. לכאורה, מה קל העניין? כולם יודעים שצריך לשים את ה DNS של הסרבר בהגדרות TCP/IP. אבל הבעיה, אצלי לפחות, נבעה משרת DNS נוסף שיש לי. יש לי ראוטר עם אייפי 172.16.0.1 שמשרת כשרת DNS. המחשב שמחובר לדומיין בטעות קיבל את הכתובת שה-DNS נתן לו - השגוי. למעשה ב-DNS שכן היה צריך להגדיר (זה של השרת שלנו) יש A RECORD ששמו (same as parent folder) וזה כל ההבדל. אם תנסו לאבחן תקשורת, באמצעות ping למשל בין הקליינט הבעייתי שלנו לשם הדומיין המלא, אתם לא תקבלו את השרת שלכם אלא משהו אחר (במקרה שלי - 172.16.0.1) ובעצם - התיקיה SYSVOL בה מאוחסנים GPO - בלתי נראית לקלינט! כי הוא בעצם מנסה לפנות לשרת שמשויך לדומיין (שוב, במקרה שלי - 172.16.0.1) כשלמעשה, אם היה מוגדר לו שרת DNS נכון, היה פונה לשרת שלי 172.16.1.35. מה שיצר את הבילבול אצלי זה שהשרת DNS הזה של הראוטר כן מכיר במחשבים כך שלא חשבתי בכלל לבדוק DNS, זאת סתם טעות במבט לאחור של מתחיל, אבל אני בטוח שיש עוד כמה שזה קרה להם. במחשבה שנייה דבר אחד לא ברור לי... איך זה ש user gpo settings כן עבדו, ו computer gpo settings לא..

 

[antidot]

זהו פתרון עקום (וחלקי בלבד)

נתחיל מזה שהשגיאה יכולה להגרם מעוד אלף סיבות אחרות שונות ומשונות ולא רק בגלל הגדרות DNS לא נכונות. בכל מקרה, במקרה הספציפי שלך, הבעיה נובעת מהעובדה שהDNS של הנתב שלך לא מכיר את dns zone של AD בגלל שהzone לא רשום בregistrar ורק אצלך. מהסיבה הזאת הנתב לא מסוגל לבצע name resolution עבור שמות מתחם בzone של AD. הדרך הנכונה היא להפנות את הלקוחות LAN לשרת DNS של AD ובשרת DNS של AD להגדיר שרת חיצוני (או את הDNS של הנתב) כ forwarder. בכל מקרה, יש למנוע חפיפה של zone name שעליו אחראי הDNS של הנתב לבין הzone עליו אחראי הDNS של AD. הגדרת A record במקרה שלך תפתור חלקית את הבעיה, אבל תצפה לתופעות לוואי בגלל שהתחנות לא יוכלו לבצע name resolution של SRV records שמוגדרים בDNS של AD (ועבורם הנתב לא יודע לבצע name resolution ) הפניה לSYSVOL באמת מתבצעת לפי domain.name.com\sysvol\\, אבל מדובר בנוסף במנגנון של DNS מייקרוסופטי שמציג רשימה של כתובות IP תוך שימוש בsort-order: הכתובת שהלקוח מקבל אמורה להיות של DC הקרוב ללקוח (ואני פוסח כאן על המנגנון של LDAP ping לפיו מתבצע האיתור של הDC הקרוב). בכל מקרה, תדאג שהתחנות יקבלו את הDNS של השרת בלבד ובשרת תגדיר שרת DNS של הספק שלך כforwarder. הDNS של הנתב מיותר לגמרי במקרה שלך ורק יכול לגרום לתקלות.

 

[tomer65538]

אני לא יכול לכבות אותו. זה כולה רשת

ביתית ואני מקים AD בשביל להתנסות בכל מני דברים לקראת הבחינה...

 

[ezaton]

אז תחליף את שירות ה- DHCP

בשירות שירוץ מה- AD שלך, ושיכלול הגדרות רשת *מתאימות* ונכונות עבורך, כולל הפנייה ל- DNS. פירושו, אגב, שאתה צריך לכבות את ה- DHCP של הנתב, לתקופה. תמיד תוכל להחזיר אותו חזרה לחיים, כשה- AD שלך יעלם מהאופק.