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

સમગ્ર પેકેજની આર્કિટેક્ચર પૂછો, પછી તેને મશીન પર ચકાસો.

ઇમ્યુલેશન જે ભાગ આવરી લેતું નથી

Arm પર Windows વપરાશકર્તા મોડમાં રહે ત્યાં સુધી x86 અને x64 એપ્લિકેશનોને ઇમ્યુલેશન દ્વારા ચલાવી શકે છે. કર્નલ મોડના ઘટકોને એ વર્તન મળતું નથી: ડ્રાઇવર Arm64 માટે બનેલો હોવો જોઈએ જેથી તે બિલકુલ લોડ થાય. Microsoft આ સીમા દસ્તાવેજ કરે છે, અને VPN ક્લાયન્ટ સામાન્ય રીતે ત્યાં જ હોય છે, કારણ કે તેમાંથી ઘણા વર્ચ્યુઅલ નેટવર્ક એડેપ્ટર કે ફિલ્ટર ડ્રાઇવર ઇન્સ્ટોલ કરે છે.

તેથી પેકેજ કાર્યકારી ઇન્ટરફેસ બતાવી શકે છે અને તેમ છતાં નકામું હોઈ શકે છે. નિષ્ફળતા ગુમ થયેલ એડેપ્ટર, શરૂ ન થતી સેવા કે ક્યારેય સ્થપાય નહીં તેવી ટનલ તરીકે દેખાય છે. પાયલોટ અટકવો જોઈએ તે બિંદુ એ જ છે. સાઇન-ઇન સ્ક્રીન કાર્યકારી ડેટા માર્ગનો પુરાવો નથી.

માઇગ્રેશન નક્કી કરતી ત્રણ શરતો

પહેલી પેકેજ છે. x64 બિલ્ડ અને Arm64 બિલ્ડ બંનેને 64-બિટ કહેવાય છે અને તે બદલી શકાય તેવા નથી, તેથી ફક્ત Windows 64-બિટ તરીકે વર્ણવાયેલ ડાઉનલોડ Arm ઉપકરણ વિશે કંઈ સાબિત કરતું નથી. તે આર્કિટેક્ચર માટે વેન્ડરનું સમર્થિત ઇન્સ્ટોલર જ એકમાત્ર સ્વીકાર્ય પ્રારંભ બિંદુ છે.

બીજી બાકીના જરૂરી ઘટકો છે. ઉપકરણ સ્થિતિની ચકાસણી, બ્રાઉઝર-આધારિત પ્રમાણીકરણ સહાયકો અને સ્માર્ટ-કાર્ડ મિડલવેર — દરેકની પોતાની આર્કિટેક્ચર જરૂરિયાત હોઈ શકે છે, અને ફક્ત ટનલની સફળતા સંસ્થાની ઍક્સેસ નીતિ પૂરી થઈ છે તે દર્શાવતી નથી.

ત્રીજી ગેટવે અને તેના સમર્થિત ક્લાયન્ટ સમૂહ છે. મંજૂર ક્લાયન્ટ પાસે Arm બિલ્ડ ન હોય તો, બીજો ક્લાયન્ટ ફક્ત ત્યાં જ સ્વીકાર્ય છે જ્યાં ગેટવેનો માલિક તે ક્લાયન્ટનો પ્રોટોકોલ, તેની પ્રમાણીકરણ પદ્ધતિ અને તેની નીતિ વર્તણૂકને સમર્થન આપે છે. Windows નું અંતર્નિર્મિત VPN પ્રોફાઇલ ફક્ત બંનેને IPsec કહેવાય છે તે કારણે માલિકીના ક્લાયન્ટનો વિકલ્પ બની શકતું નથી.

ઉપકરણ પર આર્કિટેક્ચર વાંચો

મશીન શું છે તે નિશ્ચિત કરો, પછી પેકેજે ખરેખર કયા ડ્રાઇવર ઇન્સ્ટોલ કર્યા તે જુઓ. યાદી બનાવવામાં એક મિનિટ લાગે છે અને "64-બિટ" નો અર્થ શું છે તે અંગેની દલીલ અટકાવે છે.

Get-CimInstance Win32_OperatingSystem | Select-Object OSArchitecture
$env:PROCESSOR_ARCHITECTURE
pnputil /enum-drivers | Select-String -Pattern 'vpn|tap|wintun' -Context 0,3
Get-NetAdapter | Format-Table Name,InterfaceDescription,DriverProvider

જો એડેપ્ટર યાદી ક્લાયન્ટ માટે કંઈ બતાવતી નથી, અથવા ડ્રાઇવર એન્ટ્રી આર્કિટેક્ચર અસંગતતા જણાવે છે, તો માઇગ્રેશન ત્યાં જ અટકે છે. જૂના કન્ટેનરમાં Arm64 ડ્રાઇવર નાખવું એ વેન્ડર સમર્થન આપે તેવી બાબત નથી, અને સુસંગતતા મોડ સેટિંગ્સ x64 કર્નલ ડ્રાઇવરને રૂપાંતરિત કરતા નથી.

ઇન્સ્ટોલ થયેલ આવૃત્તિને વેન્ડરની Arm માટેની સમર્થિત યાદી સાથે સરખાવો, અને જો ઇન્સ્ટોલર વેન્ડરને બદલે આંતરિક રિપોઝિટરીમાંથી આવ્યું હોય તો તફાવત નોંધો.

કાર્યભાર મંજૂર કરો, લોગિન સ્ક્રીન નહીં

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

ખાનગી DNS, જરૂરી રૂટ અને સરનામાં પરિવારો, નેટવર્ક ફેરફાર પછી પુનઃકનેક્શન અને નિર્દિષ્ટ ડિસ્કનેક્ટેડ સ્થિતિ સમાવો. ક્લાયન્ટ અને ઘટકોની આવૃત્તિઓ પરિણામ સાથે નોંધો, કારણ કે આગલું અપડેટ ફરીથી એ જ પ્રશ્નો પૂછશે.

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

સંબંધિત લેખો