Event Broker PowerShell plug-in problem: Operation faulted: A parameter cannot be found that matches parameter name 'pdb'

Assigned to Tony.

Hi Bob,

Those parameters are only for the known-valid parameters of the powershell Import-Module function.

I would suggest instead using the PowerShell Script operation, executing the "DEEWR.Requests.Today" script with:

& "\\EDMGT051\D$\Scripts\FIM.ScriptBox\FIM Object Visualizer\Reports\DEEWR.Requests.Today.ps1" -pdb "<your_pdb_input>" -pdbinstance "<your_pdbinstance_input>"

Reassigned for confirmation.

Alternatively, the same can be achieved with the PowerShell Execute plugin with the parameters:

-ArgumentList "<your_pdb_input>","<your_pdbinstance_input>"

Thanks heaps Tony ... perhaps it's just me, but it wasn't obvious that the "known-valid parameters" were the only supported ones ... makes sense now, but perhaps the doco could be clearer here?

Tony - I opted for your second suggestion as that is easier to read when configuring the plug-in ... particularly since the UNC file path gets validated this way. However I have found that when I call the script in the way you suggested I am not having the script's default parameters overridden. The other way is working, so I'm running with that ... but can you spot what is wrong with the way I am using the ArgumentList idea?

-ArgumentList "localhost", "EDMGT053", "FIMSQL"

When I run this against an updated version of the PowerShell script (see attached) you can see that it doesn't override the $FIMService parameter the way it does with the other plug-in, since I get the following error:

System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at http://rubbish:5725/ResourceManagementService/Enumeration that could accept the message

Since I can't upload the updated PS1 script, the first line of the script is now as follows:

Param([string]$FIMService = "rubbish", [string]$FIMDbServer = "EDMGT053", [string]$FIMDbServerInstance = "FIMSQL")

Tony - also there's quite a difference in the way you've specified the your first option using the PowerShell Script plug-in and the example that shows when you click on the Script textbox on the Event Broker UI. Your example above works ... but the format specified in the plug-in UI does not (i.e. what does the "& " prefix achieve which makes yours work?). Perhaps the UI hint text needs to be brought into line with your suggestion ... specifically with longish UNC paths.

Hey Bob,

With regards to your first question about overriding default parameter values in the PowerShell execute operation, it appears that this can't be achieved; this lies with the actual script being used by that operations - namely sitting on-top of the Import-Module cmdlet see http://technet.microsoft.com/en-us/library/dd819454.aspx.

The PowerShell Execute and Script operations have been implemented to make using PowerShell scripts easier to use, but in situations where the particular CmdLet being decorated by the operation isn't sufficient - in this case Import-Module -, then it's necessary to drop back to the PowerShell script, which executes actual PowerShell Scripts themselves.

Which leads on-to the reason for the '&' character in the second option; It's the PowerShell call operator, and it was required in your situation see. http://technet.microsoft.com/en-us/library/ee176949.aspx.

The documentation for the PowerShell execute operation was updated on Friday to address some of your concerns with confusing descriptions.

Thanks.

The three powershell operations (Script/Function and Execute are going to be merged into the one PowerShell Script operation).

This is to cut down on the confusion that is coming out of the separation between these parts.

When function and execute are turned into script operations on upgrade, the underlying script will be plainly visible.

This added transparency should help with issues like this, where options on the underlying modules weren't explicitly supported through the UI.