WhatIfPreference False<\/p>\n
What the $WhatIfPreference<\/b> variable does is flip the whatif <\/i>parameter to on, for every Windows PowerShell cmdlet that supports a whatif <\/i>switch. This means that every cmdlet that changes system state will no longer change system state by default. To illustrate, I am going to start an instance of Notepad. I will then use the Get-Process<\/b> to retrieve the process, and pipe it to Stop-Process<\/b>—and the Notepad process goes away. This is shown here:<\/p>\n
PS C:\\> $ErrorView = “CategoryView”<\/p>\n
PS C:\\> notepad<\/p>\n
PS C:\\> get-process notepad | Stop-Process<\/p>\n
PS C:\\> get-process notepad<\/p>\n
ObjectNotFound: (notepad:String) [Get-Process], ProcessCommandException<\/p>\n
Next, I change and use the whatif <\/i>parameter when calling the Stop-Process<\/b> cmdlet. The whatif <\/i>parameter, lets me know that it would stop an instance of the Notepad process, the one with the process ID of 6052, if the command ran without the whatif <\/i>parameter. I then use the Get-Process<\/b> cmdlet to confirm that the instance of Notepad with the process ID of 6052 still runs. These commands and associated output are shown here:<\/p>\n
PS C:\\> notepad<\/p>\n
PS C:\\> get-process notepad | Stop-Process -WhatIf<\/p>\n
What if: Performing operation “Stop-Process” on Target “notepad (6052)”.<\/p>\n
PS C:\\> get-process notepad<\/p>\n
<\/p>\n
Handles<\/span> NPM(K)<\/span> PM(K)<\/span> WS(K)<\/span> VM(M)<\/span> CPU(s)<\/span> ID ProcessName<\/span><\/p>\n 79 9 4220 8976 82 0.03 6052 notepad<\/p>\n As my student asked, what happens when I forget to use the whatif <\/i>statement? Well of course, the Notepad process goes away, and there is no prompt, no anything. There’s not even any sign that the process no longer runs. The only way to confirm that Notepad went away is to use Get-Process<\/b>. These commands and associated output are shown in the following figure.<\/p>\n The solution is to turn on the $WhatIfPreference<\/b>, which I do by setting the value to $true<\/b>:<\/p>\n $WhatIfPreference = $true<\/p>\n After the $WhatIfPreference<\/b> is set to $true<\/b>, any command that would change system state (and therefore any cmdlet that supports the whatif <\/i>switched parameter) runs with whatif, <\/i>and therefore does not actually execute the command, as shown here:<\/p>\n PS C:\\> $WhatIfPreference = $true<\/p>\n PS C:\\> notepad<\/p>\n PS C:\\> get-process notepad | Stop-Process<\/p>\n What if: Performing operation “Stop-Process” on Target “notepad (7840)”.<\/p>\n PS C:\\><\/p>\n This includes commands to create a new folder (because it makes a change to the system). This is shown here:<\/p>\n PS C:\\> md c:\\fso4<\/p>\n What if: Performing operation “Create Directory” on Target “Destination: C:\\fso4”.<\/p>\n PS C:\\> test-path c:\\fso4<\/p>\n False<\/p>\n If I want to execute a command that changes system state, I need to set the value for whatif <\/i>to false. When doing this, I must use $False<\/b>, and not simply false<\/b>:<\/p>\n PS C:\\> get-process notepad | Stop-Process -whatif:false<\/p>\n InvalidArgument: (:) [Stop-Process], ParameterBindingException<\/p>\n PS C:\\> get-process notepad | Stop-Process -whatif:$false<\/p>\n PS C:\\> get-process notepad<\/p>\n ObjectNotFound: (notepad:String) [Get-Process], ProcessCommandException<\/p>\n Keep in mind that forcing whatif <\/i>to $False<\/b> <\/i>is per command, so a subsequent call to a command that changes system state will execute the whatif <\/i>behavior unless I once again override the value. This is shown here:<\/p>\n PS C:\\> md c:\\fso4<\/p>\n What if: Performing operation “Create Directory” on Target “Destination: C:\\fso4”.<\/p>\n PS C:\\> md c:\\fso4 -WhatIf:$false <\/p>\n <\/p>\n Directory: C:\\ <\/p>\n <\/p>\n Mode<\/span> LastWriteTime<\/span> Length Name<\/span><\/p>\n d—- 11\/11\/2011 6:57 PM fso4<\/p>\n <\/p>\n PS C:\\> test-path c:\\fso4<\/p>\n True<\/p>\n The above commands and associated output are shown in the following figure.<\/p>\n After I close Windows PowerShell and open it up again, the value of the $WhatIfPreference<\/b> variable resets to $False<\/b>. I no longer have the added protection of the whatif <\/i>switch on by default. This appears in the following figure.<\/p>\n The solution, of course, is to add the $WhatIfPreference<\/b> to the Windows PowerShell profile. I have a number of Hey, Scripting Guy! Posts that talk about working with Windows PowerShell profiles<\/a> or adding items to profiles. I also have an excerpt<\/a> from my Windows PowerShell 2.0 Best Practices<\/i> book that covers the different Windows PowerShell profiles. You will need to decide if you want to enable the preference variable on workstations, servers, or nothing—or for just certain users. Personally, I do not have it enabled on any of my systems, but there have been a couple of times when it might have come in handy. For highly available systems, it might be a very good thing to implement.<\/p>\n <\/p>\n That is all there is to using the $WhatIfPreference <\/b>variable. Join me tomorrow for more Windows PowerShell stuff.<\/p>\n I invite you to follow me on Twitter<\/a> and Facebook<\/a>. If you have any questions, send email to me at scripter@microsoft.com<\/a>, or post your questions on the Official Scripting Guys Forum<\/a>. See you tomorrow. Until then, peace.<\/p>\n <\/p>\n Ed Wilson, Microsoft Scripting Guy<\/b><\/p>\n <\/b><\/p>\n<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" Summary: Learn how a simple change to a preference variable can help prevent accidental changes when using Windows PowerShell. Microsoft Scripting Guy Ed Wilson here. When I was teaching my Windows PowerShell Best Practices class out in Irvine, California, recently, I was talking to the class about the whatif parameter. I did my usual […]<\/p>\n","protected":false},"author":596,"featured_media":87096,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[51,144,3,4,45],"class_list":["post-12021","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-getting-started","tag-profiles","tag-scripting-guy","tag-scripting-techniques","tag-windows-powershell"],"acf":[],"blog_post_summary":" Summary: Learn how a simple change to a preference variable can help prevent accidental changes when using Windows PowerShell. Microsoft Scripting Guy Ed Wilson here. When I was teaching my Windows PowerShell Best Practices class out in Irvine, California, recently, I was talking to the class about the whatif parameter. I did my usual […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/12021","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/users\/596"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/comments?post=12021"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/12021\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media\/87096"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media?parent=12021"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=12021"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=12021"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"Image](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/29\/2019\/02\/4401.hsg-11-21-11-1.png\" "\\"Image")
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n