Hi,
I have a PS script to connect Microsoft-Teams, the PS script is working fine in windows-legacy compatability. After I migrated the process to windlows compatability, the PS script is not working.
Error Message:
Invoke Power Shell: The ‘Connect-MicrosoftTeams’ command was found in the module ‘MicrosoftTeams’, but the module could not be loaded. For more information, run ‘Import-Module MicrosoftTeams’
1 Like
Tried that method mentioned on the thread. Not working.
Hi. I’m stuck on this, also.
In this thread
Invoke powershell cant import module - Help - UiPath Community Forum
they say the solved it by
“adding this line before the Import-Excel and it works for me
Import-Module ImportExcel -Force”
But I wonder how he “added this line”. I’m using another “Invoke Power Shell” activity but I’m getting different errors. For instance, I don’t know how to pass a “paramater without a parameter name”, like this “ImportExcel”.
I’ve tried it in several ways, but all them throw some or another error.
For instance, checking and unchecking the “isScript” check.
Using both the “Parameters” collection and the “PowerShellVariables” collection for passing parameters. By the way, I don’t get the difference amongst them.
The “Input”, as “A collectoin of PSObject”, I don’t know how to use that, either.
When trying the Parameters with “Force” as a parameter name and “MicrosoftTeams” (which is the module I’m trying to import) as the value, it complains about not being the proper type.
The forum is dead. Noone is replying since weeks ago.
My “Connect-MicrosoftTeams” Invoke Power Shell suddenly stopped working in every script I had it properly working until last week. No changes were made and in every script I had it working.
Running it from command line works fine, as always.
There’s absolutely NO WAY to catch the execution of the PS call, so there’s no way to debug this in case it’s my fault.
Changing the output type of the ativity still ERASES every input parameter so you have to manually SET UP the activity again every time you make a change.
This is like a very bad joke.
After I finally got this working, now that I converted my Windows-Legacy project to a plain “Windows” only, I’m experiencing this problem again. It suddenly says “the command is not recognized”. There’s supposed to be a “knowledge base” post linking here, but that’s barely understandable.
Hi @pere
Please try this workaround until we fix this for good:
This snippet above will run your script via the local machine PowerShell instead of the one that comes from the PowerShell SDK that comes with the System package.
Hi,
I’m trying to test the workaround above. Having to enclosure everything inside a .ps1 file is a nightmare, specially when I have several Invoke Power Shell activities that only call one command or cmdlet. I’ve done a couple of attempts of calling just a command, like “install-PackageProvider” + its parameters; however, it complains about not being recognized as a name of cmdlet, function, script file or executable and blah. I’m having trouble finding the documentation for the right syntax for this call. Can anyone point me in the right direction? What I’m exactly trying is
"Set-ExecutionPolicy Unrestricted -Scope CurrentUser
$powershell32 = $env:SystemRoot + '\SysWOW64\WindowsPowerShell\v1.0\powershell.exe'
& $powershell32 'Install-PackageProvider -Name NuGet -Force'"
Instead of
"Set-ExecutionPolicy Unrestricted -Scope CurrentUser
$powershell32 = $env:SystemRoot + '\SysWOW64\WindowsPowerShell\v1.0\powershell.exe'
& $powershell32 -file 'C:\work\myScript.ps1'"
Could it be something like
"Set-ExecutionPolicy Unrestricted -Scope CurrentUser
$powershell32 = $env:SystemRoot + '\SysWOW64\WindowsPowerShell\v1.0\powershell.exe'
& $powershell32 -command 'Install-PackageProvider -Name NuGet -Force'"
or some other syntax?
As noone replied for weeks and I already found the proper syntax for calling commands, I’m sharing it here in case anyone finds herself in the same situation (note I switched to the 64-bit version):
"$powershell64 = $env:SystemRoot + '\System32\WindowsPowerShell\v1.0\powershell.exe'
& $powershell64 -Command {Connect-MicrosoftTeams}"
@loginerror and whoever else who is reading,
After solving all the mistakes and headaches with the syntax that prevented me from getting this working, finally all was in vain, as the context amongst calls is not being kept. That is, any other MicrosoftTeams package related command that is called after Connect-MicrosoftTeams (which provides a dialog for authenticating) is gonna complain about “You must call the Connect-MicrosoftTeams cmdlet before calling any other cmdlets.”.
This is exactly the same behaviour as the other “workaround” (to call it something) the staff provided, that was using the “Start Process” activity to start PowerShell and then launch commands or scripts in a similar way.
There’s no workaround I’m aware of to overcome the problems when running PS “natively” through the activity, so I can’t use UiPath with Windows non-legacy projects.
Hi @pere
Would you mind attaching a sample project zip, including your script (just please replace the sensitive data with dummy placeholders).
We are actually working on improving both the activity and the documentation right now, and all your feedback is being actively taken on board.
This is why having a sample project zip would be really helpful, for two reasons:
- we could have a look at what viable workarounds we can provide right now with the current System package version 23.10.2
- we could validate that the fixes that we’re working on solve your problem
There you go.
I wonder if this was really necessary. A project with merely three activities (one Assign, that could be avoided, an Invoke Power Shell connecting to Microsoft Teams and another one calling a script using Get-Team. Exactly what I described in my previous comments. You could have tried by yourself and you would have seen that it doesn’t work. Oh well.
blankProjectTeams.zip (30.1 KB)
1 Like
There you go again.
This is what started it all. A project with only one activity, with only one Invoke Power Shell call to “Install-Module”, which triggers the infamous
System.Management.Automation.CmdletInvocationException: Cannot process argument transformation on parameter ‘CallerPSCmdlet’. Cannot convert the “System.Management.Automation.PSScriptCmdlet” value of type “System.Management.Automation.PSScriptCmdlet” to type “System.Management.Automation.PSCmdlet”. —> System.Management.Automation.ParameterBindingArgumentTransformationException: Cannot process argument transformation on parameter ‘CallerPSCmdlet’. Cannot convert the “System.Management.Automation.PSScriptCmdlet” value of type “System.Management.Automation.PSScriptCmdlet” to type “System.Management.Automation.PSCmdlet”. —> System.Management.Automation.ArgumentTransformationMetadataException: Cannot convert the “System.Management.Automation.PSScriptCmdlet” value of type “System.Management.Automation.PSScriptCmdlet” to type “System.Management.Automation.PSCmdlet”. —> System.Management.Automation.PSInvalidCastException: Cannot convert the “System.Management.Automation.PSScriptCmdlet” value of type “System.Management.Automation.PSScriptCmdlet” to type “System.Management.Automation.PSCmdlet”. at System.Management.Automation.LanguagePrimitives.ThrowInvalidCastException(Object valueToConvert, Type resultType)
at System.Management.Automation.LanguagePrimitives.ConvertNoConversion(Object valueToConvert, Type resultType, Boolean recurse, PSObject originalValueToConvert, IFormatProvider formatProvider, TypeTable backupTable)
at System.Management.Automation.LanguagePrimitives.ConversionData1.Invoke(Object valueToConvert, Type resultType, Boolean recurse, PSObject originalValueToConvert, IFormatProvider formatProvider, TypeTable backupTable) at System.Management.Automation.LanguagePrimitives.ConvertTo(Object valueToConvert, Type resultType, Boolean recursion, IFormatProvider formatProvider, TypeTable backupTypeTable) at System.Management.Automation.ArgumentTypeConverterAttribute.Transform(EngineIntrinsics engineIntrinsics, Object inputData, Boolean bindingParameters, Boolean bindingScriptCmdlet) --- End of inner exception stack trace --- at System.Management.Automation.ArgumentTypeConverterAttribute.Transform(EngineIntrinsics engineIntrinsics, Object inputData, Boolean bindingParameters, Boolean bindingScriptCmdlet) at System.Management.Automation.ParameterBinderBase.BindParameter(CommandParameterInternal parameter, CompiledCommandParameter parameterMetadata, ParameterBindingFlags flags) --- End of inner exception stack trace --- at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception) at System.Management.Automation.Interpreter.ActionCallInstruction2.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.Interpreter.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.LightLambda.RunVoid1[T0](T0 arg0)
at System.Management.Automation.PSScriptCmdlet.RunClause(Action`1 clause, Object dollarUnderbar, Object inputToProcess)
at System.Management.Automation.PSScriptCmdlet.BeginProcessing()
at System.Management.Automation.Cmdlet.DoBeginProcessing()
at System.Management.Automation.CommandProcessorBase.DoBegin()
— End of inner exception stack trace —
at System.Activities.Statements.Throw.Execute(CodeActivityContext context)
at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
at System.Activities.ActivityInstance.Execute(ActivityExecutor executor, BookmarkManager bookmarkManager)
at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
nouSetup.zip (36.6 KB)
1 Like
Thank you. This helps a lot.
However, I have some unfortunate news. I would have hoped to be able to provide a quick workaround, but I cannot due to the way the PowerShell SDK and how it currently behaves.
Having said so - the upcoming System 23.12 activity package will offer you a way to choose which PowerShell to use, and we have already verified that this indeed works for the Connect-MicrosoftTeams command.
For now, the way you worked around the issue is the closest to the working example, minus having the Connect-MicrosoftTeams as a separate invoke. As you already found out, I believe you will have to do the authentication within the core script to get this working for now.
2 Likes
Thanks a lot for helping, @loginerror . At least this gives hope and helps me putting my current work on hold and switch to another task in the meantime. I’ve also had a meeting with your support staff, so they have taken a deeper, like look into the problems I’m experiencing and we are keeping in touch in the hopes they can provide a sort of solution in the following days.
I really appreciate your efforts and I understand this sort of things may happen, but it’s good to know that you are taking the right steps to address it.
Best regards,
Pere
1 Like
Hi again and sorry for bothering, @loginerror,
Is there any scheduled release date for the abovementioned 23.12 System activity package? Does the .12 mean that it’s gonna released in December?
Thanks
Hi again,
@loginerror, we have already past mid December and no further news regarding this. I realized a few days ago I got Studio 2023.10.2 Community Edition update.
Any scheduled date?
We should be releasing the next community version 2023.12 (with System 23.12) in the coming days.
The 2023.10.2 is just a patch version with some bug fixes.
1 Like
Hi!
I noticed a few minutes ago that an update for the UiPath.System.Activities, v23.12.0-preview, showed up. I installed it and now the Invoke Power Shell activity is finally showing a drop-down menu to choose from different “instances” of PowerShell:
During my first tests, though, it confuses me that calling the $PsHome with whichever of the three available options shows that the “executable” path is exactly the same:
C:\Users\Admin.nuget\packages\system.management.automation\7.2.15\runtimes\win\lib\net6.0
Is this the expected behaviour? From the options, and as my system PowerShell is v5.1, I assumed that the “PowerShell 5.1 (32-bit)” and “PowerShell 5.1 (64-bit)” were the system ones, while the “7.2.15 (64-bit)” one was another one provided by yours in your package. Is this the case? Shouldn’t the 5.1 versions then display the system’s PS path when calling $PsHome (C:\Windows\System32\WindowsPowerShell\v1.0 and C:\Windows\SysWOW64\WindowsPowerShell\v1.0, for 32 and 64 bit, respectively)? Am I wrong or right in my assumptions?
Finally, as a suggestion, couldn’t the option be a bit more descriptive? For instance, instead of “Execution Mode”, something like “PowerShell Executable” and then, in the drop-down, display like an “(internal)” or “(system)” after the “PowerShell XX.X (XX-bit)” part?
1 Like
You need to fix once and for all that bug with the activies involving not recognizing changes in the activities properties, man. That way the whole UiPath Studio is UNUSABLE. And it’s not a thing of this activity because it’s an alpha and blah. IT HAPPENS ACCROSS THE WHOLE PROJECT(S):
I restarted Studio, created a NEW Invoke Power Shell activity, three of them, each for a different version of PowerShell, each of them inviking the “$PsHome” command. Each of them returned a different path:
“C:\Windows\SysWOW64\WindowsPowerShell\v1.0” → for the 5.1 32-bit version.
“C:\Windows\System32\WindowsPowerShell\v1.0” -Z for the 5.1 64-bit version.
“C:\Users\Admin.nuget\packages\system.management.automation\7.2.15\runtimes\win\lib\net6.0” → for the 7.2.15 64-bit version.
So my assumptions / theory about the drop-down options where right; it was simply Studio buggy behaviour what was masking it.
You have dozens of bug reports regarding Studio not taking changes in activity properties. You can’t simply always “erase the activity and put it there again”.
And I would have saved half an hour writing the previous message and this one.
lrtetala
Anil_G
ashokkarale
SorenB
jast1631
kian.ng
mateuszmacheta
adext
Pierre_MOLs
alex87