I've just had two occurrences of windows 7 stalling an execution until I hit enter on the command prompt/powershell. Afterward execution seems to continue as expected. First was an batch file of copy commands like. Copy //host/file2010-1.xml localfolder/01/ copy //host/file 2010-2.xml localfolder/02/ One file seemed to be taking ages. Another simple solution would be to use: Read-Host -Prompt 'Press any key to continue or CTRL+C to quit' I believe this is a better solution to the currently accepted answer because the requirement of hitting enter on the keyboard. I don't believe hitting enter will accept.
I originally included this as a small bonus section at the end of my other post about fixing the issue of not being able to run a PowerShell script whose path contains a space, but thought this deserved its own dedicated post. Last year: the nightmare soundtrack download for mac.
When running a script by double-clicking it, or by right-clicking it and choosing Run With PowerShell or Open With Windows PowerShell, if the script completes very quickly the user will see the PowerShell console appear very briefly and then disappear. If the script gives output that the user wants to see, or if it throws an error, the user won't have time to read the text. We have 3 solutions to fix this so that the PowerShell console stays open after the script has finished running:
1. One-time solution
Open a PowerShell console and manually run the script from the command line. I show how to do this a bit in this post, as the PowerShell syntax to run a script from the command-line is not straight-forward if you've never done it before.
Powershell Bypass Press Any Key To Continue
The other way is to launch the PowerShell process from the Run box (Windows Key + R) or command prompt using the -NoExit switch and passing in the path to the PowerShell file.
For example: PowerShell -NoExit 'C:SomeFolderMyPowerShellScript.ps1'
2. Per-script solution
Add a line like this to the end of your script:
I typically use this following bit of code instead so that it only prompts for input when running from the PowerShell Console, and not from the PS ISE or other PS script editors (as they typically have a persistent console window integrated into the IDE). Use whatever you prefer.
I typically use this approach for scripts that other people might end up running; if it's a script that only I will ever be running, I rely on the global solution below.
3. Global solution
Adjust the registry keys used to run a PowerShell script to include the –NoExit switch to prevent the console window from closing. Here are the two registry keys we will target, along with their default value, and the value we want them to have:
The Desired Values add the –NoExit switch, as well wrap the %1 in double quotes to allow the script to still run even if it's path contains spaces.
If you want to open the registry and manually make the change you can, or here is the registry script that we can run to make the change automatically for us:
You can copy and paste the text into a file with a .reg extension, or just download it here.
Simply double-click the .reg file and click OK on the prompt to have the registry keys updated. Now by default when you run a PowerShell script from File Explorer (i.e. Windows Explorer), the console window will stay open even after the script is finished executing. From there you can just type exit and hit enter to close the window, or use the mouse to click the window's X in the top right corner.
If I have missed other common registry keys or any other information, please leave a comment to let me know. I hope you find this useful.
Happy coding!
If you are using a FIDO2 Security Key, such as a YubiKey, you may have run into the issue that you cannot use it to authenticate with your Azure AD account using PowerShell:
As you can see, the needed Sign in with a security key option is missing here.
This is because PowerShell still uses the older Active Directory Authentication Library (ADAL) when prompting for Azure AD credentials. That login prompt is actually rendered using Internet Explorer, and IE will likely never have support for WebAuthN, the protocol that FIDO2 logon requires.
So we have four options:
This option works with FIDO2, but a web-based shell has its limitations.
This post explains the last option.
What is Device Authorization Grant Flow
The Device authorization grant flow is usually used when you need to sign in on 'input-constrained devices', such as IoT devices and printers. In this case, we can view PowerShell as a 'device'. The sign in flow is initiated on the device, but the user needs to visit a web page (on any device with a browser that hopefully supports WebAuthN) to complete the sign in. Once the user has signed in, the device (or PowerShell window) can get the needed access tokens and refresh tokens.
Initiate the Device Authorization Grant Flow
Run this code in the PowerShell window you want to sign in to Azure AD:
Note: You do not need to register any new app in Azure AD for this to work since we are using the well-known ClientID for Azure AD PowerShell. You do not have to add any custom values for your tenant either, since we use the Common endpoint. This means that you will automatically be redirected to the tenant the user belongs to when signing in.
A code will be shown that you need to enter at the following web page to continue the sign in:
Besides https://microsoft.com/devicelogin, you can also use http://aka.ms/devicelogin. Both will redirect you to https://login.microsoftonline.com/common/oauth2/deviceauth.
Enter the code in the prompt:
Sticker book 2 fantasy world cup. As you can see, we are now signing in on a remote device or service.
Be aware that this sign in method can be misused in phishing attempts. Only enter codes you generated yourself!
You can sign in using your regular account name and password, but to sign in using a FIDO2 key, click on Sign-in options:
Powershell Press Any Key To Continue
Now we can use our FIDO2 key to authenticate:
Once authentication is successful, you can close the page in the web browser. The next step (obtaining tokens) will happen in the PowerShell window:
Powershell Press Any Key To Continue Command
Obtain the tokens
Again, no customization is needed for this script block. We are re-using the device_code from the DeviceCodeRequest we made earlier.
Add a line like this to the end of your script:
I typically use this following bit of code instead so that it only prompts for input when running from the PowerShell Console, and not from the PS ISE or other PS script editors (as they typically have a persistent console window integrated into the IDE). Use whatever you prefer.
I typically use this approach for scripts that other people might end up running; if it's a script that only I will ever be running, I rely on the global solution below.
3. Global solution
Adjust the registry keys used to run a PowerShell script to include the –NoExit switch to prevent the console window from closing. Here are the two registry keys we will target, along with their default value, and the value we want them to have:
The Desired Values add the –NoExit switch, as well wrap the %1 in double quotes to allow the script to still run even if it's path contains spaces.
If you want to open the registry and manually make the change you can, or here is the registry script that we can run to make the change automatically for us:
You can copy and paste the text into a file with a .reg extension, or just download it here.
Simply double-click the .reg file and click OK on the prompt to have the registry keys updated. Now by default when you run a PowerShell script from File Explorer (i.e. Windows Explorer), the console window will stay open even after the script is finished executing. From there you can just type exit and hit enter to close the window, or use the mouse to click the window's X in the top right corner.
If I have missed other common registry keys or any other information, please leave a comment to let me know. I hope you find this useful.
Happy coding!
If you are using a FIDO2 Security Key, such as a YubiKey, you may have run into the issue that you cannot use it to authenticate with your Azure AD account using PowerShell:
As you can see, the needed Sign in with a security key option is missing here.
This is because PowerShell still uses the older Active Directory Authentication Library (ADAL) when prompting for Azure AD credentials. That login prompt is actually rendered using Internet Explorer, and IE will likely never have support for WebAuthN, the protocol that FIDO2 logon requires.
So we have four options:
This option works with FIDO2, but a web-based shell has its limitations.
This post explains the last option.
What is Device Authorization Grant Flow
The Device authorization grant flow is usually used when you need to sign in on 'input-constrained devices', such as IoT devices and printers. In this case, we can view PowerShell as a 'device'. The sign in flow is initiated on the device, but the user needs to visit a web page (on any device with a browser that hopefully supports WebAuthN) to complete the sign in. Once the user has signed in, the device (or PowerShell window) can get the needed access tokens and refresh tokens.
Initiate the Device Authorization Grant Flow
Run this code in the PowerShell window you want to sign in to Azure AD:
Note: You do not need to register any new app in Azure AD for this to work since we are using the well-known ClientID for Azure AD PowerShell. You do not have to add any custom values for your tenant either, since we use the Common endpoint. This means that you will automatically be redirected to the tenant the user belongs to when signing in.
A code will be shown that you need to enter at the following web page to continue the sign in:
Besides https://microsoft.com/devicelogin, you can also use http://aka.ms/devicelogin. Both will redirect you to https://login.microsoftonline.com/common/oauth2/deviceauth.
Enter the code in the prompt:
Sticker book 2 fantasy world cup. As you can see, we are now signing in on a remote device or service.
Be aware that this sign in method can be misused in phishing attempts. Only enter codes you generated yourself!
You can sign in using your regular account name and password, but to sign in using a FIDO2 key, click on Sign-in options:
Powershell Press Any Key To Continue
Now we can use our FIDO2 key to authenticate:
Once authentication is successful, you can close the page in the web browser. The next step (obtaining tokens) will happen in the PowerShell window:
Powershell Press Any Key To Continue Command
Obtain the tokens
Again, no customization is needed for this script block. We are re-using the device_code from the DeviceCodeRequest we made earlier.
You now have a valid access token in the variable $Token that can be used to authenticate when using Connect-AzureAD. Note that the variable $TokenRequest also contains refresh_token and id_token, if you want to use them.
Connect to Azure AD
Powershell Press Enter To Continue
When using the Connect-AzureAD cmdlet with an access token, you also need to specify the username you used to authenticate and the TenantId. You can find your TenantID using PowerShell:
or by going to :
Now we are ready to connect to Azure AD:
Now you should be able to run commands from that module, like this one to get the first group:
What if I need to use the Microsoft Graph?
That will also work, but you need to change $Resource variable in the first script block to the Service Endpoint of Microsoft Graph ('https://graph.microsoft.com/”) and repeat the process.
Then you should be able to run queries against the Microsoft Graph, like this one to get the first group:
How about Exchange Online?
For this to work, you need to change both the $Resource and the $ClientID variables in the first script block to:
When you sign in, you will see that you are signing in to Microsoft Exchange Online Remote PowerShell:
After you obtain the token you need to create a new credential object based on your username and the token:
Now you can connect to Exchange Online using these commands:
Powershell Press Any Key To Continue Ise
Thanks
Big thanks to Stefan Schörling (@stefanschorling) for pointing me in the right direction and to Simon Wahlin for his writeup about Device login flow for MS Graph access.
