--- title: "Set-ExecutionPolicy for Managing PowerShell Execution Policies" description: "Learn all about PowerShell execution policies, various scopes, contexts, how to use Get-ExecutionPolicy and Set-ExecutionPolicy." canonical: "https://adamtheautomator.com/set-executionpolicy/" --- # Set-ExecutionPolicy for Managing PowerShell Execution Policies > Learn all about PowerShell execution policies, various scopes, contexts, how to use Get-ExecutionPolicy and Set-ExecutionPolicy. Source: https://adamtheautomator.com/set-executionpolicy/ --- ATA Learning Tap to hide [ ATA Learning ](/) * [Home](/) * [Tutorials](/tutorials/) * [Instructors](/author/) * [Advertising](/advertising/) * [Recommended Resources](/resources/) * [About Adam](/about-adam/) Search for: * [](https://twitter.com/adbertram) * [](https://github.com/Adam-the-Automator) * [](https://www.linkedin.com/company/adam-the-automator-llc) * [](/feed/) ![Set-ExecutionPolicy for Managing PowerShell Execution Policies](https://adamtheautomator.com/wp-content/uploads/2021/03/PowerShell-Execution-Policies_-Understanding-and-Managing.jpg) # Set-ExecutionPolicy for Managing PowerShell Execution Policies [![](https://secure.gravatar.com/avatar/c14b031fe4a12b0e3f4d1e112e37261df83921ddc370cdafbad2a614e36f0cf4?s=192&d=mm&r=g)Chaitanya](https://adamtheautomator.com/author/chaitanya-g/)16 March 202111 min. read Categories: [IT Ops](/category/it-ops/) Tags:[PowerShell](/tag/powershell/) Table of Contents * [What is an Execution Policy?](#what-is-an-execution-policy) * [Execution Policy Scopes](#h-execution-policy-scopes) * [Execution Policy Types](#h-execution-policy-types) * [Unrestricted](#h-unrestricted) * [Bypass](#h-bypass) * [Undefined](#h-undefined) * [RemoteSigned](#h-remotesigned) * [AllSigned](#h-allsigned) * [Restricted](#h-restricted) * [How the RemoteSigned Policy Works](#h-how-the-remotesigned-policy-works) * [Understanding and Querying NTFS Data Streams](#h-understanding-and-querying-ntfs-data-streams) * [Execution Policy Precedence](#h-execution-policy-precedence) * [Working with Execution Policies](#h-working-with-execution-policies) * [Getting Currently-Assigned Policies](#h-getting-currently-assigned-policies) * [Changing Execution Policies](#h-changing-execution-policies) * [Using Set-ExecutionPolicy](#h-using-set-executionpolicy) * [Running Set-ExecutionPolicy Without Prompts](#h-running-set-executionpolicy-without-prompts) * [Setting PowerShell Execution Policy via Registry](#h-setting-powershell-execution-policy-via-registry) * [Setting PowerShell Execution Policy via Group Policy](#h-setting-powershell-execution-policy-via-group-policy) * [Create the Group Policy Object](#h-create-the-group-policy-object) * [Assign the Group Policy Object](#h-assign-the-group-policy-object) * [Locking Down Local Policy Changes](#h-locking-down-local-policy-changes) * [Bypassing the Execution Policy Completely](#h-bypassing-the-execution-policy-completely) * [Using the -ExecutionPolicy Bypass Parameter](#h-using-the-executionpolicy-bypass-parameter) * [Reading Scripts and Executing Raw Code](#h-reading-scripts-and-executing-raw-code) * [Conclusion](#h-conclusion) Have you ever downloaded a PowerShell script, ran it, and run into the infamous error message below? If so, you need the Set-ExecutionPolicy cmdlet and this tutorial! Not a reader? Watch this related video tutorial! **_Not seeing the video? Make sure your ad blocker is disabled._** ![PowerShell Script Execution Disabled Error](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T083807.529.png) PowerShell Script Execution Disabled Error In this post, you’re going to learn about PowerShell execution policies and how to manage them with the `Set-ExecutionPolicy` cmdlet. By the end of this post, you’ll know not only to run scripts but how to use execution policies too! > _This tutorial was written with Windows PowerShell in mind, and all demonstrations were performed with Windows PowerShell. Execution policies are not unique to Windows PowerShell, and they operate very similarly in PowerShell 6+. But, if you’re working with PowerShell 6+, you may find small differences in behavior._ ## W**hat is an Execution Policy?** If you’ve ever run into the error described above, you’ve encountered an execution policy. PowerShell execution policies are a security mechanism to protect your system from running malicious scripts. Execution policies don’t prevent you from running PowerShell code in the console as a shell but _script_ execution. > _Microsoft says an execution policy isn’t technically a “security” measure but more of a gate you can open and close. After all, you can bypass a defined execution policy easily, as you’ll learn later._ Execution policies are based on _trust_. If you trust a script, chances are, it’s not malicious. Execution policies don’t typically prevent script execution of _all_ scripts. Their primary purpose (most notably when configured more strictly) is to ensure you trust the script you’re running is [cryptographically-signed with a certificate](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_signing). Related:[Managing X.509 Certificates (For Mortals)](https://adamtheautomator.com/x509-certificates/) ## **Execution Policy Scopes** As you’ve learned, execution policies restrict script execution, but PowerShell can execute scripts in many different contexts. PowerShell executes scripts under a user’s logged-in context or a global machine context, via scheduled tasks running as SYSTEM or within the scope of a single open PowerShell console. To accommodate all of these contexts, PowerShell has five different contexts or _scopes_ you can define an execution policy. * **MachinePolicy** – This scope is limited to a single computer. It affects all users who log onto that computer, and an Active Directory group policy object sets it. When defined, it takes precedence over all other scopes. * **LocalMachine**. This is the default scope that affects all computer users and is stored in the **HKEY\_LOCAL\_MACHINE** registry subkey. When you set an execution policy using `Set-ExecutionPolicy`, this scope is the default. > _The execution policy for LocalMachine is stored in the registry key HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\PowerShell\\1\\ShellIds\\Microsoft.PowerShell._ * **UserPolicy** – The _UserPolicy_ scope affects only a single user on a computer, and an Active Directory group policy object sets it. You cannot change this policy with `Set-ExecutionPolicy`. * **CurrentUser**. The _CurrentUser_ policy scope sets the execution policy only for the current user and is stored under the _HKEY\_CURRENT\_USER_ registry hive. You cannot change this policy with `Set-ExecutionPolicy`. > _The execution policy for CurrentUser is stored in the registry key HKEY\_CURRENT\_USER\\SOFTWARE\\Microsoft\\PowerShell\\1\\ShellIds\\Microsoft.PowerShell._ * **Process** – This scope defines the execution policy for a single PowerShell session for a single user. The _Process_ execution policy scope is the most granular execution policy you can define. Unlike other execution policies, this policy is saved in an environment variable called `PSExecutionPolicyPreference` rather than the registry. ## Execution Policy Types Execution policies have various “security levels.” These levels dictate how strict the execution policy is. For example, you can have an execution policy in place that essentially does nothing; it’s disabled, but, on the other hand, an execution policy can completely disable script execution. Let’s cover each of the ways you can configure an execution policy’s security level from least to most restrictive. ### Unrestricted The least restrictive policy is one that does not affect at all; it’s _Unrestricted_. _Unrestricted_ execution policies are essentially disabled. Users can run all scripts regardless of trust when an execution policy is _Unrestricted_. ### Bypass Like the _Unrestricted_ type, an execution policy set to _Bypass_, blocks nothing. While _Bypass_ and _Unrestricted_ have a similar effect, the _Bypass_ execution policy type isn’t technically a type at all. It skips a defined execution policy entirely. ### Undefined Although not commonly used, you can essentially remove an execution policy by setting it to _Undefined_. When you set an execution policy to _Undefined_, PowerShell completely removes any assigned execution policies from the assigned scope. On non-Windows computers, the execution policy is always set to _Unrestricted_ and cannot be changed. > _When all scopes are set to Undefined, PowerShell essentially treats all scopes as Restricted._ ### RemoteSigned As you read earlier, execution policies are all about trust earned via a digital signature on scripts. PowerShell also takes into account where that script came from. Was it created on your local computer or from some random person on the Internet? Scripts built somewhere other than your local computer should not be inherently trusted. This is why PowerShell provides the _RemoteSigned_ execution policy. The _RemoteSigned_ execution policy enforces that all scripts are written somewhere other than your local computer to be cryptographically-signed. > _You can override this execution policy to some degree for files downloaded from the Internet using the_ [`Unblock-File` cmdlet](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/unblock-file). _Get more information on this behavior a little later in the How the RemoteSigned Policy Works section._ For Windows Server, _RemoteSigned_ is assigned as the default policy. ### AllSigned If you’d like to ensure all PowerShell scripts are cryptographically-signed, set the execution policy to _AllSigned_. Like _RemoteSigned_, this execution policy takes the signing requirement a step further and enforces _all_ scripts are signed before execution. > _Even if you have the AllSigned execution policy set, you can still get around the execution policy by bypassing it, as you’ll learn later._ ### Restricted The most restrictive execution policy is _Restricted_. When an execution policy is to _Restricted_, absolutely no scripts can execute; regardless of they’re trusted or not. This policy essentially disables script execution completely. Also, unlike the less restrictive types, the _Restricted_ type ensures PowerShell formatting and configuration files (PS1XML), module script files (PSM1), and PowerShell profiles cannot execute. All Windows clients, by default, are set to a _Restricted_ execution policy. > _Technically, Microsoft defines a seventh execution policy called Default, but the type is essentially another label for RemoteSigned (Windows Server) and Restricted (Windows Clients)._ ## How the RemoteSigned Policy Works One particular scenario to point is how the _RemoteSigned_ execution policy works. This execution policy (as you’ve learned) prevents scripts from running that have been created somewhere other than your local computer. But how does PowerShell know the script was created elsewhere? Data streams. ### Understanding and Querying NTFS Data Streams Whenever you create a file on an [NTFS file system](https://www.datto.com/blog/what-is-ntfs-and-how-does-it-work), NTFS applies an _alternate data stream_ (ADS) attribute to the file. An ADS has two file attributes: _$Data_ and _zone.Identifier_. PowerShell uses the _zone.Identifier_ attribute to identify whether a PowerShell script file created somewhere else. Unlike other attributes like _Compressed_ or _Read Only_, ADS attributes are hidden in File Explorer. But, by using PowerShell, you can inspect these data streams. Run the `Get-Item` cmdlet using the path to the script and the `Stream` parameter as shown below. In this example, _Hello World.ps1_ was written on the local computer. Notice the only attribute assigned to the `Stream` property is `$DATA`. There is no ADS attribute. ```powershell Get-Item '.\Hello World.ps1' -Stream * ``` ![ADS Stream output for local file](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T084544.215.png) ADS Stream output for local file Now, run the same command on a script downloaded from the Internet. Notice now `Get-Item` returns another object completely with a `Stream` of `Zone.Identifier`. ![ADS Stream output for PowerShell file downloaded from internet](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T084633.361.png) ADS Stream output for PowerShell file downloaded from internet Once you know a file has an ADS, you can then use the `Get-Content` command to discover the [zone](https://docs.microsoft.com/en-us/troubleshoot/browsers/ie-security-zones-registry-entries). The zone defines where the file came from. ```powershell Get-Content .\Get-CertDetails.ps1 -Stream zone.identifier ``` `Get-Content` will return a `ZoneId` value which represents the zone the file came from. ![Zone ID Value](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T084736.638.png) Zone ID Value Possible zone values are: ```powershell Zone ID Zone ------- --------------------- 0 My Computer 1 Local Intranet Zone 2 Trusted sites Zone 3 Internet Zone 4 Restricted Sites Zone ``` ## Execution Policy Precedence As covered above, many different execution policies exist at once. All of these execution policies, when combined, dictate the settings of your current session. When you have multiple execution policies in effect, you must have precedence. Policy precedence is the order in which PowerShell applies different policies set at different scopes. Some execution policies have higher priority than others. When you run `Get-ExecutionPolicy -List`, you will find all execution policies currently in effect ordered from lowest priority to highest. For example, since _MachinePolicy_ has a lower priority, the _LocalMachine_ and _CurrentUser_ policies will override it. ![Get-ExecutionPolicy cmdlet output](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T084829.072.png) Get-ExecutionPolicy cmdlet output ## Working with Execution Policies Enough understanding the background of execution policies, let’s now dig into how to work with them! To work with PowerShell’s execution policies, you have two commands at your disposal `Get-ExecutionPolicy` to discover currently-defined policies and `Set-ExecutionPolicy` to set new policies. ### Getting Currently-Assigned Policies Before you can begin changing execution policies, you need to learn what you’re working with. To do that, you’ve got the `Get-ExecutionPolicy` command. This command enumerates all of the currently-assigned policies on a computer. When you directly run the `Get-ExecutionPolicy` command on a PowerShell console with no parameters, it will show the execution policy set for your current PowerShell session. ![Get-ExecutionPolicy cmdlet output](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T084922.662.png) Get-ExecutionPolicy cmdlet output To see the execution policy set to a scope, specify the `Scope` parameter using the scope name you’d like to see the results for. ```powershell Get-ExecutionPolicy -Scope Process Get-ExecutionPolicy -Scope LocalMachine ``` ![Get-ExecutionPolicy cmdlet with scope parameter output](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T085001.810.png) Get-ExecutionPolicy cmdlet with scope parameter output To view all scopes and their execution policies, use `List` parameter as shown below. ```powershell Get-ExecutionPolicy -list ``` ![Get-ExecutionPolicy cmdlet displaying all scopes](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T085034.146.png) Get-ExecutionPolicy cmdlet displaying all scopes ### Changing Execution Policies Once you know what execution policies are currently assigned, you can change them too. To change the policy on a single computer, you have the `Set-ExecutionPolicy` command at your disposal. But, if you’re in an organization, you’ll want to change policies in bulk. If that’s the case, you always have Group Policy if you’re in an Active Directory domain. ## Using Set-ExecutionPolicy Let’s first cover how to change policies with the `Set-ExecutionPolicy` command. To do so, open up PowerShell as administrator. Related:[How to Run PowerShell as Administrator](https://adamtheautomator.com/powershell-run-as-administrator/) Now run the `Set-ExecutionPolicy` command with a single parameter (`ExecutionPolicy`) providing the name of the execution policy. ```powershell Set-ExecutionPolicy -ExecutionPolicy RemoteSigned ``` PowerShell will then ask if you’d like to change the execution policy. If you do, type **Y** or **A** and hit **Enter**. ![Change Execution Policy](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T085158.989.png) Change Execution Policy Some PowerShell commands need to run multiple other tasks to operate. If in the example above you enter `Y`, PowerShell may prompt you to continue for each step. If you press `A`, it will continue for all the subsequent steps. ### Running `Set-ExecutionPolicy` Without Prompts By default, when you run `Set-ExecutionPolicy`, it will prompt you whether or not you want to change the execution policy. You can skip this prompt by adding the `Force` parameter to your command. Using the `Force` parameter will suppress all confirmation prompts. ```powershell Set-ExecutionPolicy RemoteSigned -Force ``` ![Output of Set-ExecutionPolicy command when Force Parameter is used](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T085500.569.png) Output of Set-ExecutionPolicy command when Force Parameter is used ## Setting PowerShell Execution Policy via Registry Since most execution policies are stored in the registry (excluding _Process)_, you can also change policies directly via the registry. To change execution policies via the registry: 1. Open up the Windows Registry Editor (_regedit_) or your choice of registry editing tool. Related:[How to Use PowerShell to Get a Registry Value](https://adamtheautomator.com/powershell-to-get-a-registry-value/) 2\. Navigate to the execution policy scope’s registry key you’d like to change. **LocalMachine** – _HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\PowerShell\\1\\ShellIds\\Microsoft.PowerShell_ **CurrentUser** – _HKEY\_CURRENT\_USER\\SOFTWARE\\Microsoft\\PowerShell\\1\\ShellIds\\Microsoft.PowerShell_ 3\. Right-click on the registry key and create a new string value called _ExecutionPolicy_. 4\. Double-click on the newly-created _ExecutionPolicy_ string value and enter desired execution policy name (_Restricted_, _RemoteSigned_, _AllSigned_, _Unrestricted,_ or _Undefined_). 5\. Create another string value in the same key called _Path_. The _Path_ string value represents the path to the PowerShell engine. Ensure the _Path_ value is _C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe_ which points to the Windows PowerShell engine. ![Registry path for ExecutionPolicy in registry for current user](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T085653.368.png) Registry path for ExecutionPolicy in registry for current user The _CurrentUser_ execution policy overrides a _LocalMachine_ policy. If you have a _CurrentUser_ policy set in the registry and try to change the execution policy via `Set-ExecutionPolicy`, which, by default, sets the policy at the _LocalMachine_ scope, PowerShell will return an error shown below. ![Execution Policy Permission Denied](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T085741.217.png) Execution Policy Permission Denied ## Setting PowerShell Execution Policy via Group Policy If you are in an organization with Active Directory, you’re not going to want to go around to all of your Windows machines and run the `Set-ExecutionPolicy` cmdlet. Instead, you can manage policies in bulk with Group Policy. Related:[What is Group Policy and How Does it Work?](https://adamtheautomator.com/what-is-group-policy/) To manage execution policies via GPO: ### Create the Group Policy Object 1. Open up the Group Policy Management application on a domain controller or on your domain-joined workstation. ![Group Policy Management Console](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T090329.880.png) Group Policy Management Console 2\. Expand **Domains** —> **** —> **Group Policy Objects**. ![Select Group Policy Objects node](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T090425.845.png) Select Group Policy Objects node 3\. Right-click on **Group Policy Objects** and click **New**. 4\. Give your GPO a name. In this tutorial, the GPO is called _PowerShell Execution Policy_. ![Create new Group Policy Object](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T090533.586-1.png) Create new Group Policy Object 5\. Right-click on the newly-created GPO and click **Edit**. 6\. Navigate to _Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Windows PowerShell_. ![Navigate to the setting in Group Policy Object](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T090639.883.png) Navigate to the setting in Group Policy Object 7\. Open the setting in the right window pane, open the **_Turn on Script Execution_** setting. ![Turn on Script Execution Policy](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T090724.787.png) Turn on Script Execution Policy 8\. In the **Turn on Script Execution** box, Select the **Enabled** option. You can now select any one of the options shown below: 9\. Now change the **Execution Policy** to your desired policy. * **Allow only signed scripts** – Allows all scripts execution when a trusted publisher signs them. * **Allow local scripts and remote signed scripts** – Allows local scripts to run but scripts that are downloaded from the internet should be signed by a trusted publisher. * **Allow all scripts** – Allows all scripts to run. ![List Execution Policy](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T090822.858.png) List Execution Policy ### Assign the Group Policy Object Once you have the GPO created, it’s time to assign it to your target computers. To do that, you must assign the GPO to an Active Directory Organizational Unit (OU). > _If, instead of creating a new GPO, you edited an existing GPO, that GPO has already probably already been assigned to an OU._ 1. In **Group Policy Management**, navigate to your OU of choice by going to **Domains** —> **** —> ****. 2\. Right-click on the OU and select **Link an Existing GPO…** ![Link an Existing GPO...](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T091010.591-1.png) Link an Existing GPO… 3\. Select the GPO just created (**PowerShell Execution Policy**) and click **OK**. ![Select the GPO](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T091106.024-1.png) Select the GPO You should now see the GPO assigned to the OU as shown below. ![Link the Group Policy Object](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T091255.219-2.png) Link the Group Policy Object At this point, you can either wait for the defined [Group Policy refresh interval](https://social.technet.microsoft.com/wiki/contents/articles/31623.modify-group-policy-refresh-interval-for-computers.aspx) or run the _gpupdate_ command on a target computer to force a refresh. Related:[Understanding the GPUpdate Command \[In Depth\]](https://adamtheautomator.com/gpupdate/) ### Locking Down Local Policy Changes Once a GPO is in effect that changes the execution policy, local users can no longer change the policy via the local PowerShell console. If they try, they will receive an error, as shown below. ![Error on trying to changing execution policy manually](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T091441.548.png) Error on trying to changing execution policy manually ## Bypassing the Execution Policy Completely As mentioned earlier, an execution policy isn’t necessarily meant to be a security measure. Why? Because you can completely bypass it if you’d like in a few different ways. ### Using the `-ExecutionPolicy Bypass` Parameter Unlike the other execution policies, the _Bypass_ policy is typically set not in the PowerShell console but passed to the _powershell.exe_ engine run as administrator. For example, to run a script called _Hello World.ps1_ completely skipping any execution policy, invoke _powershell.exe_, use the `Bypass` parameter and provide the file path as shown below. ```powershell powershell.exe -executionpolicy bypass -file '.\Hello World.ps1' ``` ![ByPass Execution Policy using bypass execution policy](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T091533.621.png) ByPass Execution Policy using bypass execution policy ### Reading Scripts and Executing Raw Code You can also get around any execution policy by first reading the contents of a script and then passing that contents directly to the PowerShell engine. Doing so, runs each command individually and not as a whole script at once. As you can see below, the execution policy is set to _Restricted,_ but by reading the script and passing it to _powershell.exe_, it still works. > _This approach is similar to opening a script in a PowerShell editor like PowerShell ISE or Visual Studio Code, selecting a line and pressing F8._ ```powershell Get-Content '.\Hello World.ps1' | powershell.exe -noprofile ``` ![Alternative way to Bypass Execution Policy](https://adamtheautomator.com/wp-content/uploads/2021/03/Untitled-2021-03-08T091632.353.png) Alternative way to Bypass Execution Policy ## Conclusion By now you should know all there is to know about PowerShell execution policies. Even though they’re not technically a security measure, you should still manage them in your organization according to organizational policies. Share this article [Share on X](https://twitter.com/intent/tweet?url=https%3A%2F%2Fadamtheautomator.com%2Fset-executionpolicy%2F&text=Set-ExecutionPolicy%20for%20Managing%20PowerShell%20Execution%20Policies)[Share on Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fadamtheautomator.com%2Fset-executionpolicy%2F)[Share on LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fadamtheautomator.com%2Fset-executionpolicy%2F) ## Related Posts ![](https://adamtheautomator.com/wp-content/uploads/2026/06/26995-troubleshoot-dns-issues-powershell-codex.webp) ### [Troubleshoot DNS Issues with PowerShell](/troubleshoot-dns-issues-powershell/) Troubleshoot DNS issues with PowerShell by testing name resolution, DNS client settings, cache entries, and network connectivity in a repeatable workflow. ![](https://adamtheautomator.com/wp-content/uploads/2025/10/image_2025-10-24_095322075.png) ### [Migrating from PowerShell 6 to 7.5: Breaking Changes/New Features](/migrating-powershell-6-to-7-5/) Migrate from PowerShell Core 6 to 7.5: breaking changes, features, and testing tips. ![](https://adamtheautomator.com/wp-content/uploads/2025/06/featured-image-6.png) ### [How to Add Timeouts to Pester Tests with PowerShell Runspaces](/pester-test-timeout-runspaces/) Prevent Pester tests from hanging indefinitely using PowerShell runspaces. Learn to handle variable scoping, module loading, TestDrive access, and stream capture challenges with timeout protection. ## Categories * [IT Ops](/category/it-ops/) * [Cloud](/category/cloud/) * [DevOps](/category/devops/) * [Home Ops](/category/home-ops/) * [Information Security](/category/infosec/) * [Software Development](/category/software-development/) ## Site * [Home](/) * [Tutorials](/tutorials/) * [Instructors](/author/) * [Advertising](/advertising/) * [Recommended Resources](/resources/) * [About Adam](/about-adam/) Copyright 2026© ATA Learning | [Privacy Policy](/privacy/)