Protected Users ਵਾਲੇ ਲੈਪਟਾਪ ਨੂੰ ਸਾਈਨ-ਇਨ ਤੋਂ ਪਹਿਲਾਂ VPN ਕਿਉਂ ਚਾਹੀਦਾ ਹੈ

ਲੈਪਟਾਪ, ਚੱਲਦਾ ਖਾਤਾ ਅਤੇ ਹੋਟਲ ਨੈੱਟਵਰਕ ਮਿਲ ਕੇ ਸਾਈਨ-ਇਨ ਦਾ ਅਜਿਹਾ ਚੱਕਰ ਬਣਾਉਂਦੇ ਹਨ ਜਿਸ ਨੂੰ ਕੋਈ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਤੋੜ ਨਹੀਂ ਸਕਦੀ। ਖਾਤਾ Protected Users ਵਿੱਚ ਹੈ, ਜੋ Windows ਨੂੰ ਉਹ ਪਰਖਕ ਸੰਭਾਲਣ ਤੋਂ ਰੋਕਦਾ ਹੈ ਜੋ ਵਰਤੋਂਕਾਰ ਨੂੰ ਆਫ਼ਲਾਈਨ ਪਰਮਾਣਿਤ ਕਰਨ ਲਈ ਲੋੜੀਂਦਾ ਹੁੰਦਾ। «ਪਹਿਲਾਂ ਸਾਈਨ ਇਨ ਕਰੋ, ਫਿਰ ਟਨਲ ਜੋੜੋ» ਵਰਗੀ ਕੋਈ ਵੀ ਯੋਜਨਾ ਦਾ ਕ੍ਰਮ ਉਲਟਾ ਹੈ, ਅਤੇ ਸੁਰੱਖਿਆ ਠੀਕ ਉਹੀ ਕਰ ਰਹੀ ਹੈ ਜਿਸ ਦਾ ਵਾਅਦਾ ਕੀਤਾ ਹੈ। ਅੱਗੇ ਦਿੱਤਾ ਗਿਆ ਸਮਰਥਿਤ Windows ਹੋਸਟ ਉੱਤੇ ਰਵਾਇਤੀ Active Directory ਖਾਤਾ ਮੰਨਦਾ ਹੈ।

ਸੁਰੱਖਿਆ ਅਸਲ ਵਿੱਚ ਕੀ ਹਟਾਉਂਦੀ ਹੈ

ਆਮ ਤੌਰ ’ਤੇ Windows ਪਰਖਕ ਕੈਸ਼ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਡੋਮੇਨ ਖਾਤਾ ਡੋਮੇਨ ਕੰਟਰੋਲਰ ਦੇ ਉਪਲਬਧ ਨਾ ਹੋਣ ’ਤੇ ਵੀ ਸਾਈਨ ਇਨ ਕਰ ਸਕੇ। Protected Users ਖਾਤੇ ਲਈ ਇਹ ਰੋਕਦਾ ਹੈ, ਜੋ ਆਫ਼ਲਾਈਨ ਡੋਮੇਨ ਸਾਈਨ-ਇਨ ਨੂੰ ਭਰੋਸੇਯੋਗ ਨਾ ਬਣਾਉਣ ਦੀ ਥਾਂ ਸੰਭਾਵਨਾ ਵਜੋਂ ਹਟਾ ਦਿੰਦਾ ਹੈ।

ਇਹ ਪੁਰਾਣੇ ਕੈਸ਼ ਦੀ ਆਮ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ, ਅਤੇ ਆਮ ਉਪਾਅ ਇੱਥੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੇ। ਵਾਰ-ਵਾਰ ਆਨਲਾਈਨ ਸਾਈਨ ਇਨ ਕਰਨਾ, ਫਿਰ ਪਾਸਵਰਡ ਬਦਲਣਾ ਜਾਂ ਕੈਸ਼ ਕੀਤੇ ਸਾਈਨ-ਇਨਾਂ ਦੀ ਗਿਣਤੀ ਵਧਾਉਣਾ ਸਮਰੱਥਾ ਵਾਪਸ ਨਹੀਂ ਲਿਆਏਗਾ, ਕਿਉਂਕਿ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਕਾਰਵਾਈ ਉਹ ਪਰਖਕ ਨਹੀਂ ਬਣਾਉਂਦੀ ਜਿਸ ਨੂੰ ਨੀਤੀ ਸੰਭਾਲਣ ਤੋਂ ਇਨਕਾਰ ਕਰਦੀ ਹੈ। ਖਾਤਾ ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ ਵਿਵਹਾਰ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਡਿਜ਼ਾਈਨ ਮੰਨਦਾ ਹੈ ਕਿ ਜਦੋਂ Windows ਪੁੱਛਦਾ ਹੈ ਤਾਂ ਨੈੱਟਵਰਕ ਮੌਜੂਦ ਹੈ। ਲੱਛਣ ਨੂੰ ਕੈਸ਼ ਨੁਕਸ ਮੰਨਣਾ ਉਹ ਰਾਹ ਹੈ ਜਿਸ ਰਾਹੀਂ ਟੀਮਾਂ ਉਹ ਪਰੋਫ਼ਾਈਲ ਮੁੜ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ ਕਦੇ ਟੁੱਟੀ ਨਹੀਂ ਸੀ।

ਟਨਲ ਡੈਸਕਟਾਪ ਤੋਂ ਪਹਿਲਾਂ ਕਿਉਂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ

Windows ਜਿਸ ਪਲ ਮੰਗ ਕਰਦਾ ਹੈ, ਉਸੇ ਪਲ ਜੰਤਰ ਨੂੰ ਡੋਮੇਨ ਪਰਮਾਣਿਕਰਨ ਤੱਕ ਪਹੁੰਚਣਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਹ ਕਿਸੇ ਵੀ ਵਰਤੋਂਕਾਰ ਸੈਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਹੈ। ਜੋ VPN ਕਲਾਇੰਟ ਡੈਸਕਟਾਪ ਦਿਖਣ ਤੋਂ ਬਾਅਦ ਹੀ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਉਹ ਨਵੇਂ ਸਾਈਨ-ਇਨ ਨੂੰ ਉਸ ਰਾਹ ਦੀ ਉਡੀਕ ਕਰਾਉਂਦਾ ਹੈ ਜੋ ਕਦੇ ਨਹੀਂ ਆਉਂਦਾ। ਨਿਰਭਰਤਾ ਮਸ਼ੀਨ ਦੀ ਹੈ, ਅਜੇ ਲੌਗ ਇਨ ਨਾ ਕੀਤੇ ਵਰਤੋਂਕਾਰ ਦੀ ਨਹੀਂ।

ਐਂਡਪੌਇੰਟ ਅਤੇ ਪਛਾਣ ਮਾਲਕਾਂ ਨਾਲ ਸਹਿਮਤ ਸਮਰਥਿਤ ਪਹਿਲਾਂ-ਲੌਗਇਨ ਪ੍ਰਬੰਧ ਵਰਤੋ। ਕੰਪਿਊਟਰ ਪ੍ਰਮਾਣਪੱਤਰ ਨਾਲ ਪਰਮਾਣਿਤ Always On VPN ਜੰਤਰ ਟਨਲ ਤਦ ਯੋਗ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਪ੍ਰਬੰਧਿਤ ਜੰਤਰ ਉਸ ਤੈਨਾਤੀ ਦੀਆਂ ਪੂਰਵ-ਸ਼ਰਤਾਂ ਪੂਰੀਆਂ ਕਰਦਾ ਹੈ। ਵਿਕਰੇਤਾ ਦਾ ਸਮਰਥਿਤ ਸਾਈਨ-ਇਨ ਸਕਰੀਨ ਏਕੀਕਰਨ ਦੂਜਾ ਬਦਲ ਹੈ। ਸਵੈਚਲਿਤ ਟ੍ਰਿਗਰ ਵਾਲਾ ਆਮ ਵਰਤੋਂਕਾਰ ਪਰੋਫ਼ਾਈਲ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਨਹੀਂ, ਕਲਾਇੰਟ ਇੰਟਰਫ਼ੇਸ ਵਿੱਚ ਭਾਵੇਂ ਕਿੰਨਾ ਹੀ ਸਮਾਨ ਦਿਸੇ।

ਉਸ ਰਾਹ ਨੂੰ ਡੋਮੇਨ ਲਈ ਨਾਮ ਹੱਲ, ਪਹੁੰਚਯੋਗ ਡੋਮੇਨ ਕੰਟਰੋਲਰ ਅਤੇ ਉਹ ਪਰਮਾਣਿਕਰਨ ਪਰੋਟੋਕੋਲ ਚਾਹੀਦੇ ਹਨ ਜੋ ਖਾਤਾ ਵਰਤ ਸਕਦਾ ਹੈ, ਅਤੇ «ਜੁੜਿਆ» ਸੂਚਕ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਨਹੀਂ ਦਿੰਦਾ। ਇਸ ਦੇ ਰੂਟ ਅਤੇ ਫਿਲਟਰ ਪਛਾਣ ਸੇਵਾਵਾਂ ਲੈ ਜਾਣ ਅਤੇ ਲੋੜੀਂਦਾ ਨਾ ਹੋਣ ਵਾਲਾ ਹੋਰ ਕੁਝ ਨਹੀਂ, ਕਿਉਂਕਿ ਉਹ ਅਗੇਤਰ ਸੂਚੀ ਹੀ ਉਹ ਸਤਹ ਹੈ ਜੋ ਚੋਰੀ ਹੋਇਆ ਲੈਪਟਾਪ ਕਿਸੇ ਦੇ ਲੌਗ ਇਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪਾ ਲੈਂਦਾ ਹੈ। ਵਰਤੋਂਕਾਰ ਟਨਲ ਲਈ ਲਏ ਵੰਡੇ ਟਨਲ ਦੇ ਫੈਸਲੇ ਜੰਤਰ ਟਨਲ ’ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੇ, ਇਸ ਲਈ ਦੋਵਾਂ ਦੀ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਸਮੀਖਿਆ ਕਰੋ।

ਪਹੁੰਚਯੋਗਤਾ ਪਰਮਾਣਿਕਰਨ ਅਨੁਕੂਲਤਾ ਨਹੀਂ ਹੈ

ਟਨਲ ਪੈਕਟ ਨੂੰ ਬਿਲਕੁਲ ਠੀਕ ਢੋ ਸਕਦੀ ਹੈ ਪਰ ਡੋਮੇਨ ਪਰਮਾਣਿਕਰਨ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਜੋ ਤੰਤਰ ਅਜ਼ਮਾਇਆ ਜਾ ਰਿਹਾ ਹੈ ਉਹ ਖਾਤਾ ਵਰਤ ਨਹੀਂ ਸਕਦਾ। ਜਿਸ ਡੋਮੇਨ ਵਿੱਚ ਸਮੂਹ ਦੀਆਂ ਪਾਬੰਦੀਆਂ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ, ਉੱਥੇ ਮੈਂਬਰਾਂ ਲਈ NTLM ਉਪਲਬਧ ਨਹੀਂ ਅਤੇ Kerberos ਨੂੰ AES-ਅਨੁਕੂਲ ਖਾਤਾ ਅਤੇ ਸੰਰਚਨਾ ਚਾਹੀਦੀ ਹੈ। ਪੈਕਟ ਦਾ ਰਾਹ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਇਸੇ ਲਈ ਡੋਮੇਨ ਕੰਟਰੋਲਰ ਨੂੰ ਸਾਫ਼ ping ਸਾਈਨ-ਇਨ ਚੱਲਣ ਦਾ ਸਬੂਤ ਨਹੀਂ ਹੈ।

ਦੋ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਪ੍ਰਣਾਲੀਆਂ ਵੀ ਚੱਲ ਸਕਦੀਆਂ ਹਨ। VPN ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਨਾਲ ਪਰਮਾਣਿਤ ਹੋ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕਿ Windows ਨੂੰ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਡੋਮੇਨ ਲੌਗਆਨ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਪਹਿਲੀ ਦੀ ਸਵੀਕ੍ਰਿਤੀ ਦੂਜੀ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ। «VPN ਜੁੜ ਗਈ» ਅਤੇ «ਵਰਤੋਂਕਾਰ ਸਾਈਨ ਇਨ ਹੋ ਗਿਆ» ਵੱਖਰੇ ਨਿਰੀਖਣ ਹਨ, ਅਤੇ ਇੱਕ ਠੀਕ ਕਰਨ ਦਾ ਅਰਥ ਦੂਜਾ ਨਹੀਂ।

ਪਰਮਾਣਿਕਰਨ ਦੇ ਸਬੂਤ ਪੜ੍ਹੋ

ਇੱਕੋ ਕੋਸ਼ਿਸ਼ ਲਈ ਘਟਨਾਵਾਂ ਕਲਾਇੰਟ ਅਤੇ ਡੋਮੇਨ ਕੰਟਰੋਲਰ ਦੋਵਾਂ ਤੋਂ ਇਕੱਠੀਆਂ ਕਰੋ, ਸਿਰਫ਼ ਇੱਕ ਪਾਸਿਓਂ ਨਹੀਂ। Protected Users ਦੇ ਲੌਗ Applications and Services Logs\Microsoft\Windows\Authentication ਹੇਠ ਹਨ, ਅਤੇ ਕੁਝ ਵੀ ਦਰਜ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਬੰਧਕ ਨੂੰ ਲੌਗ ਚਾਲੂ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ। ਸਮੇਂ ਦੀਆਂ ਮੋਹਰਾਂ ਨੂੰ ਟਨਲ ਦੇ ਆਪਣੇ ਕਨੈਕਸ਼ਨ ਲੌਗ ਨਾਲ ਮਿਲਾਓ, ਕਿਉਂਕਿ ਕ੍ਰਮ ਦੀ ਗਲਤੀ ਦੋਵਾਂ ਪਾਸਿਓਂ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਨੁਕਸ ਵਾਂਗ ਦਿਸਦੀ ਹੈ।

ਹੇਠਾਂ ਪਹਿਲਾ ਆਦੇਸ਼ ਜੰਤਰ ਵੱਲੋਂ ਦਿਖਾਏ ਹਰ ਪਰਮਾਣਿਕਰਨ ਲੌਗ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਬਲੌਗ ਪੋਸਟ ਵੱਲੋਂ ਨਾਮ ਦਿੱਤਾ ਨਹੀਂ, ਮੌਜੂਦ ਲੌਗ ਪੜ੍ਹਦੇ ਹੋ। ਦੂਜਾ ਨਾਮ ਜਾਣਨ ਤੋਂ ਬਾਅਦ ਹਾਲੀਆ ਐਂਟਰੀਆਂ ਪੜ੍ਹਦਾ ਹੈ। ਪਰਮਾਣਿਕਰਨ ਪੈਕੇਜ, ਖਾਤਾ ਅਤੇ ਫੇਲ ਹੋਣ ਦੀ ਸ਼ਰਤ ਲੱਭੋ, ਕਿਉਂਕਿ ਗੈਰਹਾਜ਼ਰ ਨੈੱਟਵਰਕ ਰਾਹ ਅਤੇ ਰੱਦ ਕੀਤਾ ਤੰਤਰ ਵੱਖਰੇ ਸਬੂਤ ਛੱਡਦੇ ਹਨ ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ VPN ਸਮੱਸਿਆ ਹੈ। ਜੇ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਬਾਅਦ ਟਨਲ ਉੱਪਰ ਆਈ, ਤਾਂ ਉਹ ਐਂਟਰੀਆਂ ਕੁਝ ਵੀ ਕਹਿਣ, ਕ੍ਰਮ ਗਲਤ ਸੀ।

Get-WinEvent -ListLog *Authentication*
Get-WinEvent -LogName Microsoft-Windows-Authentication/Operational -MaxEvents 20

ਠੰਢੇ ਬੂਟ ਤੋਂ ਹੱਦ ਸਾਬਤ ਕਰੋ

ਪਰਖ ਸਾਈਨ ਆਉਟ ਜਾਂ ਹੁਣੇ ਬੂਟ ਹੋਈ ਹਾਲਤ ਤੋਂ ਸੀਮਿਤ ਖਾਤੇ ਨਾਲ ਚਲਾਓ, ਅਤੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਲੇ ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਬਹਾਲੀ ਰਾਹ ਖੁੱਲ੍ਹਾ ਰੱਖੋ। ਪਹਿਲਾਂ ਹੀ ਚੱਲ ਰਹੇ ਡੈਸਕਟਾਪ ’ਤੇ ਪਰਖ ਜ਼ਰੂਰੀ ਕੋਡ ਰਾਹ ਦਾ ਕੋਈ ਵੀ ਹਿੱਸਾ ਨਹੀਂ ਵਰਤਦੀ, ਅਤੇ ਇਹੀ ਅਗਲੇ ਰੀਬੂਟ ਤੱਕ ਟਿਕੀ ਸੁਧਾਰ ਬਾਰੇ ਬਹੁਤੀਆਂ ਰਿਪੋਰਟਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ। ਫਿਰ ਚਾਰ ਕਦਮ ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਪੂਰੇ ਕਰੋ।

1. ਕੋਈ ਸਾਈਨ ਇਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜੰਤਰ ਡੋਮੇਨ ਕੰਟਰੋਲਰ ਲੱਭ ਸਕਦਾ ਹੈ ਦੀ nltest /dsgetdc:corp.example.com ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ।
2. ਡੋਮੇਨ ਸਾਈਨ-ਇਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਫਿਰ klist ਨਾਲ ਪੁੱਛੋ ਕਿ ਟਿਕਟ ਮਿਲੀ ਵੀ ਸੀ ਜਾਂ ਨਹੀਂ।
3. ਜੰਤਰ ਜੋ ਪਰਮਾਣਿਕਰਨ ਲੌਗ ਦਰਜ ਕਰਦਾ ਹੈ ਉਸ ਨੂੰ ਉੱਪਰਲੇ ਦੋ ਆਦੇਸ਼ਾਂ ਨਾਲ ਪੜ੍ਹੋ, ਅਤੇ ਪੈਕੇਜ ਤੇ ਫੇਲ ਹੋਣ ਦੀ ਸ਼ਰਤ ਨੋਟ ਕਰੋ।
4. ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਬਹਾਲੀ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਅਜੇ ਵੀ ਸਾਈਨ-ਇਨ ਸਕਰੀਨ ਤੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਕਿਉਂਕਿ ਹੱਦ ਪਰਖ ਫੇਲ ਹੋਣ ’ਤੇ ਵਾਪਸ ਆਉਣ ਦਾ ਇਹੀ ਇੱਕੋ ਰਾਹ ਹੈ।

ਦਿੱਤੇ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਨਾਲ ਫ਼ਾਈਲ ਸ਼ੇਅਰ ਖੋਲ੍ਹਣਾ ਵੀ ਆਫ਼ਲਾਈਨ ਇੰਟਰਐਕਟਿਵ ਲੌਗਆਨ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਇਸ ਲਈ ਇਹ ਉੱਪਰਲੇ ਕਿਸੇ ਵੀ ਕਦਮ ਦਾ ਬਦਲ ਨਹੀਂ ਹੈ। ਜੇ ਸੰਸਥਾ ਨੂੰ ਸੱਚਮੁੱਚ ਕਨੈਕਸ਼ਨ ਤੋਂ ਬਿਨਾਂ ਸਾਈਨ-ਇਨ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਜਵਾਬ ਹੈ ਜਾਣ-ਬੁੱਝ ਕੇ ਚੁਣਿਆ ਅਨੁਕੂਲ ਖਾਤਾ ਅਤੇ ਐਂਡਪੌਇੰਟ ਡਿਜ਼ਾਈਨ। ਖਾਤੇ ਨੂੰ ਸਮੂਹ ਵਿੱਚੋਂ ਕੱਢਣਾ, ਜਾਂ ਹਰ ਲੈਪਟਾਪ ’ਤੇ ਇੱਕ ਅਣਸੀਮਿਤ ਐਮਰਜੈਂਸੀ ਲੌਗਇਨ ਰੱਖਣਾ, ਪਛਾਣ ਨੀਤੀ ਦਾ ਫੈਸਲਾ ਹੈ ਜੋ VPN ਬਦਲਾਅ ਤੁਹਾਡੇ ਵੱਲੋਂ ਨਹੀਂ ਲੈ ਸਕਦਾ।

Protected Users ਦਸਤਾਵੇਜ਼ ਪਰਖਕ ਦੇ ਵਿਵਹਾਰ ਅਤੇ ਉਹਨਾਂ ਡੋਮੇਨ ਪਾਬੰਦੀਆਂ ਦੋਵਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ’ਤੇ ਇਹ ਡਿਜ਼ਾਈਨ ਨਿਰਭਰ ਹੈ। ਕਿਸੇ ਦੇ ਸਫ਼ਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬਹਾਲੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਯੋਜਨਾ ਬਣਾਓ, ਕਿਉਂਕਿ ਠੰਢੇ-ਬੂਟ ਦੀ ਪਰਖ ਹੀ ਇੱਕੋ ਥਾਂ ਹੈ ਜਿੱਥੇ ਇਸ ਦਾ ਅਭਿਆਸ ਹੁੰਦਾ ਹੈ।