When – after setting the $ConfirmPreference variable to medium – executing a PowerShell cmdlet that could change the system state or configuration in some way (‘may involve a risk of losing data’) like Set-Item, PowerShell will perform the so-called confirmation action automatically, as follows:
PS C:\> $ConfirmPreference = 'medium' PS C:\> # This command creates an alias of "np" for Notepad. PS C:\> set-item -path alias:np -value c:\windows\notepad.exe Confirm Are you sure you want to perform this action? Performing the operation "Set Item" on target "Item: np Value: c:\windows\notepad.exe". [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):
And if you change the value of the built-in variable $ConfirmPreference to high (the default) the confirmation action will not be performed automatically, like so:
PS C:\> $ConfirmPreference = 'high' PS C:\> set-item -path alias:np -value c:\windows\notepad.exe PS C:\>
Following the rule that the confirmation action is only performed automatically when the ConfirmImpact value of a cmdlet (by default, Medium) is equal to or greater than the value of the $ConfirmPreference variable, your conclusion would be that the internally defined ConfirmImpact parameter of the Set-Item cmdlet must have been (albeit maybe implicitly) set to Medium by the developer who created that cmdlet.
But would it not be nice to at least know another way to determine a cmdlet’s internal ConfirmImpact value upfront, instead of finding it by trial-and-error? If you think so, please continue reading…
Let’s for example try to find the ConfirmImpact level of the Remove-ADUser cmdlet.
The general first step is to determine the full path of the .dll that contains the cmdlet for which we need to know the ConfirmImpact parameter. To find the path to the .dll that contains the source code for the Remove-ADUser cmdlet, enter the PowerShell statements (Get-Command RemoveADUser).DLL and you will see the following:
PS C:\> (Get-Command Remove-ADUser).DLL C:\Windows\Microsoft.Net\assembly\GAC_64\Microsoft.ActiveDirectory.Management\v4.0_188.8.131.52__31bf3856ad364e35\Microsoft.ActiveDirectory.Management.dll
Now that we know the path of the cmdlet’s .dll file I will discuss two ways to determine the desired ConfirmImpact parameter value, one by using the free Windows SDK tool ildasm.exe and the other by using a 14-day, fully functional free trial of .NET Reflector from Red Gate Software.
Using ildasm.exe, the free IL Disassembler
- Check if your computer contains the file <drive>\Program Files (x86)\Microsoft SDKs\Windows\v<something>\Bin\ildasm.exe and if not, download and install the free Microsoft Windows SDK for Windows 7 and .NET Framework 4
- Open either a Visual Studio Command Prompt or the Windows SDK Command Prompt, and enter the following code to generate a text file containing the so-called intermediate language (il) of the .dll concerned:
C:\> ildasm.exe C:\Windows\Microsoft.Net\assembly\GAC_64\Microsoft.ActiveDirectory.Management\v4.0_184.108.40.206__31bf3856ad364e35\Microsoft.ActiveDirectory.Management.dll output:c:\temp\il.txt
- Open the generated text file in e.g. notepad (first disable Word Wrap) and search for the desired cmdlet name omitting the dash or hyphen, so in our case RemoveADUser. The part to look for is indicated in green:
- Indicated in red you see the ConfirmImpact parameter has the value 03, which stands for High. The complete enum contains the following possible ConfirmImpact values None (00), Low (01), Medium (02) and High (03). More information about these enum values can be found on MSDN.
Keep in mind that the ConfirmImpact parameter is present (and meaningful) only when the SupportsShouldProcess parameter is set to true (01), indicated in blue. If the SupportsShouldProcess parameter is (set to false or) not present at all, no ConfirmImpact level is set either, indicating that the cmdlet concerned is considered harmless (example: Get-Item).
If the SupportsShouldProcess parameter is set to true (01) but the ConfirmImpact parameter is not set explicitly, the cmdlet’s ConfirmImpact level defaults to Medium (example: Set-Item).
Using the 14-day free trial of .NET Reflector
- Download and install a 14-day, fully functional free trial of .NET Reflector from Red Gate Software.
- In .NET Reflector, use File > Open Assembly… to load the .dll containing the cmdlet.
- Press the magnifying glass button in the toolbar (or use F3) to open the search box.
- Type RemoveADUser (so without the original the dash or hyphen) and in the appearing list of results double-click the item concerned. This looks as follows:
- The first line in the panel below the search results clearly states that the SupportsShouldProcess parameter is set to true and the long-sought-after ConfirmImpact parameter contains High. Other possible values are ConfirmImpact.Medium, ConfirmImpact.Low and ConfirmImpact.None.
Just as when using ildasm.exe tool, remember that the ConfirmImpact parameter is present (and meaningful) only if the SupportsShouldProcess parameter is set to true. Should SupportsShouldProcess parameter be set to false or not at all mentioned, no ConfirmImpact level is set either, meaning that this is a harmless cmdlet, like for instance Get-Item. In case the SupportsShouldProcess parameter is set to true but the ConfirmImpact parameter is not present, that cmdlet’s ConfirmImpact level defaults to Medium, with Set-Item as an example.