#PSTip Be cautious with profile customizations and PowerShell Workflow

When working with Windows PowerShell Workflow, there are things to be aware of which can break workflow from working. One such thing is customizations made in the PowerShell profile.

Let’s start by defining an example workflow we can work with:

workflow Get-RemoteService {

    Get-Service -PSComputerName $PSComputerName

}

When invoking the workflow I got the following errors on my computer:

PS [3]: Get-RemoteService -PSComputerName srv1
WARNING: The binding of default value ‘True’ to parameter ‘Keep’ failed: Cannot bind p
arameter ‘Keep’ to the target. Exception setting “Keep”: “The Wait and Keep parameters
cannot be used together in the same command.”
Cannot find drive. A drive with the name ‘Scripts’ does not exist.
+ CategoryInfo : ObjectNotFound: (Scripts:String) [], ParentContainsErr
orRecordException
+ FullyQualifiedErrorId : DriveNotFound
+ PSComputerName : [localhost]

What is going on here? Lets start by looking at the warning:Cannot bind parameter 'Keep' to the target.

This one is hard to track down without knowing that workflow actually uses PowerShell jobs under the hood. The -Wait and -Keep parameters mentioned in the warning message is available on the Receive-Job cmdlet. The two parameters belongs to different parameter sets, and can not be used together. In my case I had the following defined in my PowerShell profile:

$PSDefaultParameterValues.Add("Receive-Job:Keep",$True)

To verify this was causing the problem I removed Receive-Job from $PSDefaultParameterValues and re-ran the workflow:

$PSDefaultParameterValues.Remove("Receive-Job:Keep")
Get-RemoteService -PSComputerName srv1

This resolved the warning:

 PS [5]: Get-RemoteService -PSComputerName srv1
Cannot find drive. A drive with the name 'Scripts' does not exist.
+ CategoryInfo : ObjectNotFound: (Scripts:String) [], ParentContainsErr
orRecordException
+ FullyQualifiedErrorId : DriveNotFound
+ PSComputerName : [localhost]

For the second error, we can see an error regarding the Scripts: drive. This is a PSDrive defined in my PowerShell profile, which is the current location in my PowerShell session. Since workflow runs in its own runspace, the drive cannot be found.

After changing the current directory to C: which is also available to the workflow runspace, the workflow runs without issues.

cd c:
Get-RemoteService -PSComputerName srv1

The easiest way to exclude profile customizations from breaking a workflow is by launching powershell.exe/powershell_ise.exe with the -NoProfile switch. If the workflow then runs without issues, you should start looking at your PowerShell profile to see what might be interfering with workflow.

About the author: Jan Egil Ring

Jan Egil works as a Lead Architect at Crayon, Norway. He mainly works with automation, and has a strong passion for PowerShell. He has been working with Microsoft infrastructure products such as Windows Server & System Center since the early 2000s. In the recent years the focus has been more and more related to cloud technologies in Microsoft Azure and hybrid environments. He is a multiple-year recipient of Microsoft Most Valuable Professional Award for his contributions in the Windows PowerShell and Cloud & Datacenter Management technical communities. He speaks regularly at user groups and conferences, such as Nordic Infrastructure Conference (NIC), PowerShell Conference Europe and PowerShell Summit. He is a co-organizer of Azure User Group Norway as well as the MTUG (Microsoft Technology User Group) Script Club which focuses mainly on PowerShell. You can follow him on Twitter @JanEgilRing.

Related Posts