ટનલ દ્વારા શેર ખોલવાથી ભૂલ 2240 આવે છે, અને પહેલી વૃત્તિ રાઉટિંગ તપાસવાની હોય છે. નંબર તેના કરતાં વધુ ચોક્કસ છે. Windows જણાવે છે કે એકાઉન્ટ આ વર્કસ્ટેશનથી લોગઓન કરી શકે નહીં, જે એક એકાઉન્ટ વિશેનું નીતિ નિવેદન છે, પહોંચ વિશેનું નિવેદન નહીં.

ભૂલ નંબર ટિકિટમાં રાખો. તે તપાસને એક લક્ષણ અને એક ઘટના સુધી મર્યાદિત કરે છે.

2240 ખરેખર શું દર્શાવે છે

નેટવર્ક મેનેજમેન્ટ ભૂલ યાદી 2240 ને NERR_InvalidWorkstation તરીકે ઓળખે છે, આ નામ શબ્દશઃ વાંચવા જેવું છે. એકાઉન્ટ માન્ય લોગઓન કમ્પ્યુટરોના સમૂહ સુધી મર્યાદિત છે, અને ઓળખપત્ર રજૂ કરતું મશીન તેમાં નથી. તે વ્યાખ્યામાં ટનલ, ફાઇલ શેર કે પાસવર્ડનો ઉલ્લેખ નથી. લક્ષણ એકાઉન્ટ પર રહે છે અને લોગઓનનો પ્રયાસ થાય ત્યારે મૂલ્યાંકન પામે છે.

એ જ કુટુંબના બીજા નંબરો બીજું કંઈક દર્શાવે છે. માન્ય લોગઓન કલાકોનું ઉલ્લંઘન અલગ કોડ છે, અને ખોટો પાસવર્ડ પણ. બધાને એક્સેસ સમસ્યા તરીકે જાણ કરવાથી ઓપરેટિંગ સિસ્ટમે હમણાં જ આપેલી ચોકસાઈ વેડફાય છે.

પ્રતિબંધ એકાઉન્ટ પર રહે છે, તેથી તે ઓળખ જ્યાં પણ પ્રમાણિત થાય ત્યાં જાય છે. જે વપરાશકર્તા દરરોજ ઓફિસમાં કામ કરે છે અને લેપટોપ ઘરે લઈ જાય છે, તેને તે ફક્ત ત્યારે જ મળે છે જ્યારે મશીનનું નામ બદલાય છે, અને તેથી જ કોઈ પેટર્ન ઓળખે તે પહેલાં નિષ્ફળતા મહિનાઓ સુધી VPN સમસ્યા જેવી લાગી શકે છે.

બે સંબંધિત હકીકતો તેને સમજાવતી નથી. NAT ઉપકરણ એકાઉન્ટના લક્ષણને સ્પર્શ કર્યા વિના અવલોકિત સ્રોત સરનામું બદલી શકે છે, અને DNS પ્રત્યયનો ફેરફાર ટૂંકું નામ સુધારી શકે છે જ્યારે લોગઓન પ્રતિબંધ બરાબર જ્યાં હતો ત્યાં જ રહે છે. બંનેને બાકાત કરવા યોગ્ય છે, અને એક પણ લક્ષણ વાંચવાનો વિકલ્પ નથી.

પહેલાં નિષ્ફળ લોગઓન રેકોર્ડ વાંચો

ફાઇલ સર્વરે કઈ ઓળખ પ્રમાણિત કરી અને કયા મશીને તે રજૂ કરી તે નક્કી કરો. ડોમેન એકાઉન્ટ, સમાન ટૂંકા નામવાળું સ્થાનિક એકાઉન્ટ અને અલગ VPN એકાઉન્ટ એકબીજાના બદલે વાપરી શકાય તેવા નથી, અને ચોક્કસ એકાઉન્ટ ખબર ન હોય ત્યાં સુધી ભૂલનો અર્થ નથી.

સુરક્ષા લોગ એકાઉન્ટ અને કૉલ કરતા વર્કસ્ટેશનના નામ સાથે પ્રયાસ નોંધે છે, અને પ્રતિબંધ બરાબર એ જ જોડી સામે મૂલ્યાંકન પામે છે:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-2)} |
  Select-Object TimeCreated,Message | Format-List
Get-ADUser -Identity jdoe -Properties LogonWorkstations |
  Select-Object SamAccountName,LogonWorkstations

પહેલો આદેશ નિષ્ફળતા અને સર્વરને મળેલી વર્કસ્ટેશન શબ્દમાળા દર્શાવે છે, અને બીજો એકાઉન્ટ પરની માન્ય યાદી દર્શાવે છે. ક્લાયન્ટના પોતાના કમ્પ્યુટરનું નામ જ સર્વરે નોંધ્યું છે એમ માનવાને બદલે બંનેની સરખામણી કરો. લોગમાં ખોટું લાગતું નામ સામાન્ય રીતે ઉપયોગી શોધ છે, કારણ કે તે એ મશીનનું નામ આપે છે જેની સાથે સર્વર ખરેખર વાત કરે છે એમ માને છે. પ્રતિબંધ એ જ માન્યતા સામે ચકાસાય છે.

VPN ગેટવેનું નામ ઉમેરશો નહીં કારણ કે ટ્રાફિક તેમાંથી પસાર થાય છે. ગેટવે પ્રમાણિત કૉલર નથી, અને તેને યાદીમાં ઉમેરવાથી કંઈ બદલાતું નથી પણ એકાઉન્ટ સમીક્ષા મુશ્કેલ બને છે.

પ્રતિબંધને સૌથી નાના વ્યાપમાં સુધારો

જો મશીનને પરવાનગી આપવી જોઈએ, તો બરાબર એ જ એન્ટ્રી એકાઉન્ટની વર્કસ્ટેશન યાદીમાં ઉમેરો અને બાકીનું બધું જેમ છે તેમ રહેવા દો. જો નહીં, તો સાચો જવાબ મંજૂર મશીન છે, પ્રતિબંધ દૂર કરવો નહીં, કારણ કે પ્રતિબંધ એ મર્યાદિત કરવા માટે છે કે આ ઓળખપત્ર ક્યાં વાપરી શકાય.

બલ્ક સંપાદનો અહીં સામાન્ય છે અને સામાન્ય રીતે ખોટા છે. લાંબી માન્ય મશીન યાદીવાળું એકાઉન્ટ એ એકાઉન્ટ છે જેનો પ્રતિબંધ અર્થ ગુમાવી ચૂક્યો છે.

ઓળખ વહેંચાયેલી છે કે નહીં તે જાણવું પણ ઉપયોગી છે. જ્યારે ઘણા લોકો ઘણા લેપટોપથી એક સેવા એકાઉન્ટ વાપરે છે, ત્યારે વર્કસ્ટેશન યાદી ત્યાં સુધી વધે છે જ્યાં સુધી નીતિ અર્થહીન ન બને, જે ડિઝાઇન સમસ્યા છે, વહીવટી નહીં.

આગલું પરિણામ વાંચો, તેની ગેરહાજરી નહીં

મંજૂર ફેરફાર પછી ઇચ્છિત એકાઉન્ટ સાથે નવી વિનંતી કરો અને શું થાય તે નોંધો. અલગ ભૂલ પ્રગતિ છે, કારણ કે તે પાછલી પુનરાવર્તન કરવાને બદલે આગલા તબક્કાનું નામ આપે છે.

DFS પાથ ઘણા સર્વરો અને ઘણા એક્સેસ નિર્ણયો લાવી શકે છે. એક એકાઉન્ટ લક્ષણ સાફ કરવાથી તેમાંથી એક નક્કી થાય છે. રેફરલ લક્ષ્યો હજી પણ પહોંચી શકાય તેવા હોવા જોઈએ, અને તેમાંથી દરેક પરના શેર અને ફાઇલસિસ્ટમ પરવાનગીઓએ હજી પણ એકાઉન્ટને સ્વીકારવું જોઈએ. આગલી ભૂલને પણ એ જ રીતે પાર કરો, પહેલા સુધારાએ બધાને આવરી લીધા એમ માનવાને બદલે.

Windows વર્કસ્ટેશન પ્રતિબંધની જાણ કરે ત્યારે VPN પ્રોફાઇલ ફરી બનાવવાનું કે પાસવર્ડ રીસેટ કરવાનું કોઈ કારણ નથી. Microsoftની નેટવર્ક ભૂલોની યાદી બરાબર આ કારણસર ખુલ્લી રાખવા જેવી છે: કોડ તમને કહે છે કે કંઈપણ સ્પર્શ કરતાં પહેલાં કયું લક્ષણ તપાસવું.

સંબંધિત લેખો