د یوې میاشتې آفلاین وروسته د ډومین باور پاتې راغی؟ لومړی وګورئ

یو لیپ ټاپ شپږ اونۍ د VPN څخه بهر وي، بیرته راځي، او کارن نشي کولی د ډومین حساب سره ننوځي. تېروتنه د باور اړیکې یادونه کوي، نو یو څوک د کمپیوټر حساب بیا تنظیموي، یا کارن په بشپړ تونل اړباسي، او ستونزه ورکه ښکاري. دواړو کړنو ثابته نه کړه چې څه مات شوي و. د Windows غړی کولی شي د معمول ماشین پټنوم له وقفې ډېر اوږد آفلاین پاتې شي او په اتوماتيک ډول باور له لاسه نه ورکوي، نو لومړی کار د رسیدو ناکامي له ریښتیني پټ راز ناسمونوالي څخه جلا کول دي.

تېروتنه باور ته ورته ښکاري، خو درې حالتونه سره ورته دي

کارن کولی شي د کیش شوو ډومین معلوماتو سره ننوځي, کاري سټیشن ممکن د ډومین کنټرولر ونه مومي، یا غړی او ډومین ممکن واقعا د کمپیوټر حساب په اړه سره نه یوځای شي. یوازې دریم په سخت معنا مات شوې باور اړیکه ده.

د AD تکرار روغتیا څلورمه کتنه ده، او دا د دې کاري سټیشن په اړه هېڅ نه ده. دا د ډومین کنټرولرونو ترمنځ موافقت بیانوي، او روغ تکرار ډشبورډ ثابتوي نه چې د دې ماشین ځایي راز د هغې کمپیوټر حساب سره سمون لري.

پیژندل شوې 30 ورځنې پیش فرض د بدلون تګلاره ده، د آفلاین پای نیټه نه. د Microsoft د ماشین-حساب پټنوم توضیح همغږی شوی بدلون بهیر بیانوي، او یوه اداره کولی شي بل وقفه تنظیم کړي.

د VPN آیکون د خوندي چینل په اړه هېڅ نه ثابتوي

اتصال باید د ډومین خدمتونو ته د رسیدو لپاره کافي ښه وي مخکې لدې چې هر ازموینه معنا ولري. دا پدې معنا ده چې ټاکل شوی ډومین DNS حل کوونکی، د موندلو وړ کنټرولر، د رسیدلو وړ تصدیق خدمتونه او د Kerberos لپاره کافي نږدې ساعت.

بشپړ تونل کولی شي دلته په بشپړ ډول سم ډیزاین وي. تقسیم شوي تونل ته تلل د روغ ډومین اړیکې شرط نه دی، او د هغې د شرط په توګه ګڼل تشخیص په معماري بدلون بدلوي. وګورئ کاري سټیشن واقعا کوم کنټرولر غوره کوي، او هغه نوم له تېروتنې سره وساتئ.

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

DNS سرور، حل شوی کنټرولر او د تېروتنې دقیق متن ولیکئ. د VPN کلاینټ چې د نښلیدو راپور ورکوي وایي تونل شته، نه دا چې د ډومین لاره کار کوي. کنټرولر چې د Kerberos پورټ ته ځواب وایي خو د لارښود پورټ ته نه، د اور دېوال موندنه ده، د باور نه.

د ترمیم مخکې غړی وازموئ

د مجاز Windows ډومین غړی په ماشین، Test-ComputerSecureChannel -Verbose د ماشین او ډومین ترمنځ د چینل یوازې لوستلو کتنه ده. هغه په هغه ماشین شرایطو کې چل کړئ چې تاسو څیړئ، نه د ډومین کنټرولر څخه، چې بله ونډه او بلې بیا رغولو مقررات لري. وتنه او د وتلو حالت ثبت کړئ نه د تېر یا ناکام کلمې. که cmdlet په هغه جوړښت کې نه وي، ماډل جلا ستونزه ده.

پایلې لا هم شرایط ته اړتیا لري. که ماشین نشي کولی ټاکل شوي کنټرولر ته ورسیږي یا هلته تصدیق شي، ناکامه ازموینه د دې خپلواکه ثبوت نه دی چې آفلاین پټنوم پای ته رسیدلی. اصلي تېروتنه او کارول شوی کنټرولر وساتئ، او کله چې لاره پیژندل شوې ښه شي ازموینه تکرار کړئ.

د پیښې شاوخوا د غړي او اړوند کنټرولر Netlogon پیښې سره ونښلوئ. د ماشین نوم، سرچینې پته، وخت او د حساب بدلون هر ثبوت وساتئ. د بل کارن بریالۍ ننوتنه، یا روغ کنټرولر ډشبورډ، د دې ماشین تبادله نشي کولی.

یوازې هغه اړیکه ترمیم کړئ چې تاسو ثابته کړې

کله چې اتصال باثباته شي او مدیر تایید کړي چې ترمیم مناسب دی، د cmdlet -Repair حالت د مجاز اسنادو سره د غړي کاري سټیشن لپاره یو ملاتړ شوی عملیات دی. دا اړیکه بدلوي، او دا بل یوازې لوستلو ازموینه نه ده.

د بدلون مخکې تصویب شوی ځایي بیا رغولو حساب او د مدیریت لاره چمتو وساتئ. ډومین کنټرولرونو بله بیا رغولو ونډه لري او دا بهیر باید هغوی د عادي کاري سټیشنونو په توګه ونه ګڼي. د ادارې د بیا رغولو بهیر وکاروئ پرځای لدې چې څو د بیا تنظیم وسایل په پرله پسې توګه چل کړئ او هیله وکړئ چې یو یې سم دی.

د ترمیم وروسته، نوې خوندي-چینل ازموینه او اصلي ډومین عملیات تایید کړئ. د کارن پروفایلونه او د اپلیکیشن حالت وساتئ، او لرې کول-بیا یوځای کیدل لومړی نه توضیح شوی عمل مه ګرځوئ.

کله چې ناکامي بیرته راځي څه وګورئ

که ناکامي بیرته راشي، د ورته حساب بیا تنظیمولو پرځای بیرته تګ، دوه ګونې هویت او د حساب بدلونونو وخت وګورئ. بیا رغول شوی عکس، سنیپ شاټ، کلون شوې ماشین هویت، یا بل ځای شوی کمپیوټر-حساب بیا تنظیمول ټول د څیړنې وړ دي.

په لنډمهاله توګه بریالی بیا تنظیم ګټور د بیا رغولو ثبوت دی، خو دا ثبوت نه دی چې وقفې وقفې VPN اصلي ناسمونوالی رامنځته کړ. بل پېښ به تاسو ته ووایي چې ایا لامل کله هم لرې شو.

کنټرولر، DNS سرور او د ازموینې وتنه ټیکټ کې ولیکئ. همدا ریکارډ ریښتینې باور ناکامي له هغه لیپ ټاپ څخه بیلوي چې ساده ډومین ونه موندل شو.