I'm trying to download and run a PowerShell script (from blob storage) using the Run Powershell artifact on an existing VM in Azure DevTest labs.
I get the following error and I assume I am doing something stupid.
& : The term './script.ps1' is not recognized as the name of a cmdlet,
function, script file, or operable program. Check the spelling of the name, or
if a path was included, verify that the path is correct and try again.
At line:1 char:3
+ & ./script.ps1
+ ~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (./script.ps1:String) [], Comman
dNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
Here is my setup...
I have also tried the JSON array syntax, which gave the same result, and an invalid URL which gave a 404 error so it seems as if it is downloading my script but then failing to find it.
Below is info I wrote a while back.
Few items to note:
Folder structure is not supported as of this writing. Therefore, script needs to be at the root of the container
Ensure your blob is public
First you will need your file in Azure storage. Once uploaded in your container, click the file to get to its properties and copy the URL field.
As an example, I have created the following Run.ps1 script file and uploaded it to storage as a blob:
param ( [string]$drive = "c:\" )
param ( [string]$folderName = "DefaultFolderName" )
New-Item -Path $drive -Name $folderName -ItemType "directory"
Now, while adding the 'Run PowerShell' artifact to the VM, we provide the following information:
File URI(s): URL field copied from earlier step. (eg. https://myblob.blob.core.windows.net/mycontainer/Run.ps1)
Script to Run: Name of the PS1 script, (eg. Run.ps1)
Script Arguments: Arguments as you would write them at the end of your command (eg. -drive "d:\" -folderName "MyFolder")
Related
I always have the following error when I install a virtual machine
launch failed: Failed to resize instance image - error executing powershell command. Detail: Resize-VHD : �������������̵Ĵ�С��
ϵͳ��������C:\WINDOWS\system32\config\systemprofile\AppData\Roaming\multipassd\vault\instances\krun\ubuntu-20.04-serv
er-cloudimg-amd64.vhdx���Ĵ�С��
�������������̵Ĵ�С��
ϵͳ��������C:\WINDOWS\system32\config\systemprofile\AppData\Roaming\multipassd\vault\instances\krun\ubuntu-20.04-serv
er-cloudimg-amd64.vhdx���Ĵ�С: ��һ����������ʹ�ô��ļ������������ʡ� (0x80070020)��
����λ�� ��:1 �ַ�: 1
Resize-VHD -Path C:/WINDOWS/system32/config/systemprofile/AppData/Roa ...
+ CategoryInfo : ResourceBusy: (:) [Resize-VHD], VirtualizationException
+ FullyQualifiedErrorId : ObjectInUse,Microsoft.Vhd.PowerShell.Cmdlets.ResizeVhd
Background
In my case, I changed the location of my multipass instance locations by following this post here. I then created a folder on my drive where I wanted the instances to be stored.
After doing so, multipass launch failed with your exact same error. After trying reboots, uninstall/reinstall multipass, etc. - I finally tried renaming the folder where I wanted to store my multipass instances, and this worked.
Apparently, if your destination multipass folder includes a space, some part of the script fails.
Workaround / Fix
When specifying a multipass instance destination:
MULTIPASS_STORAGE -Value "<path>"
Make sure there are NO SPACES in the "<path>" you have provided.
Hope this helps.
You have to add the HyperV module to powershell in "Turn Windows features on or off", if you don't check this the checkbox, "Resize-VHD" won't work and will fail the multipass launch.
The direct command is:
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Management-PowerShell
When using msdeploy to deploy an IIS app to a remote server, using the Web Deploy On Demand (tempagent) feature, I am getting this error:
./myApp.deploy.cmd : Error: Unable to get the remote environment variable 'WindowsDirectory' on the computer
'myserver.mydomain.com'.
At line:1 char:1
+ ./myApp.deploy.cmd /T /M:$target /U:$username /P:$ ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (Error: Unable t...com'.:String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
Error: The object invoked has disconnected from its clients. (Exception from HRESULT: 0x80010108 (RPC_E_DISCONNECTED))
Error count: 1.
I'm using the auto-generated deploy script that gets created by the Package target in msbuild. I'm running in the directory that all those artifacts live. This is my script to run that script:
$target = 'myserver.mydomain.com'
$username = 'myusername'
$password = 'mypassword'
./myApp.deploy.cmd /T /M:$target /U:$username /P:$password /G:true
This is the script that is generated by the .cmd script, the same exact error happens if i run it directly:
SetParameters from:
"C:\Users\MaxCadmin\Desktop\Package\myApp.SetParameters.xml"
You can change IIS Application Name, Physical path, connectionString
or other deploy parameters in the above file.
-------------------------------------------------------
Start executing msdeploy.exe
-------------------------------------------------------
"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -source:package='C:\Users\MaxCadmin\Desktop\Package\myApp.zip' -dest:auto,computerName="myserver.mydomain.com",userName="myusername",password="mypassword",includeAcls="False",tempAgent="true" -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -setParamFile:"C:\Users\MaxCadmin\Desktop\Package\myApp.SetParameters.xml" -whatif
Info: Using ID 'bce210a0-29f9-4859-8fc2-f308c6ce5e72' for connections to the remote server.
I'm using the tempagent feature so that I don't have to go install Web Deploy on all my targets, and keep them all updated to the same version. I much prefer the prospect of using the Temp Agent, removing the need for any special configuration of the targets at all. I've confirmed that my target in this case does not have Web Deploy installed on it.
I believe it's the Temp Agent that is throwing the disconnect error at the end of the error message. I'm more concerned about the error regarding the inability to get the remote variable.
For what it's worth, I went on the remote server and created that env variable, with the value matching
that of windir, which is C:\Windows, and proved to myself that it was present in a new shell. But it didn't change the error at all.
I'm working on a powershell port of Lesspass using Visual Studio Code on Linux Mint.
Test were working nicely from the IDE as of today.
From VSCode
Now When I'm on a test file and hit F5 to run the test I got:
PS ~/projects/Lesspass/Lesspass> ~/projects/Lesspass/Lesspass/src/Password.tests.ps1
Unable to find type [Pester.OutputTypes].
At ~/.local/share/powershell/Modules/Pester/4.6.0/Functions/PesterState.ps1:8 char:9
+ [Pester.OutputTypes]$Show = 'All',
+ ~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (Pester.OutputTypes:TypeName) [], RuntimeException
+ FullyQualifiedErrorId : TypeNotFound
The Describe command may only be used from a Pester test script.
At ~/.local/share/powershell/Modules/Pester/4.6.0/Functions/Describe.ps1:234 char:9
+ throw "The $CommandName command may only be used from a Peste ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (The Describe comman\u2026Pester test script.:String) [], RuntimeException
+ FullyQualifiedErrorId : The Describe command may only be used from a Pester test script.
From makefile
However when running my test with make test it works. The task is:
.PHONY: test
test:
pwsh -Command 'Invoke-Pester -EnableExit (Get-childItem -Recurse *.tests.ps1).fullname'
I think your issue is likely the fact that you are attempting to call a pester test script on it's own rather than via the Invoke-Pester Command.
I think that if you change your call to Invoke-Pester -Script ~/projects/Lesspass/Lesspass/src/Password.tests.ps1 your error may go away.
The reason is that *.tests.ps1 files do not, on their own, know how to set up all of the background plumbing required to handle a test run. Invoke-Pester does a lot of set up before test files are run, and calling a test script directly with F5 skips that setup.
If you want to be able to press F5 to kick off a test run, what many PowerShellers do in VSCode is create a debug_entry.ps1 file on the local system, and in that file put the command Invoke-Pester -Script ~/projects/Lesspass/Lesspass/src/Password.tests.ps1. Then when you want to start a run, you switch tabs to your debug_entry.ps1 file and hit F5 and your debug script makes the correct call for you. It has the side benefit of the fact that any debugging break points you have set either in the tests file, or in the code you are testing should then be respected as well.
I also think I should also point out that in your make test script, you are using Get-ChildItem to explicitly get all of the test file paths manually and pass them to Invoke-Pester. This is not necessary. Invoke-Pester by default will always search either your current working directory, or any path that you give to it recursively to find all test files available.
For instance from the output of Get-Help Invoke-Pester is the following snippet
By default, Invoke-Pester runs all *.Tests.ps1 files in the current directory
and all subdirectories recursively. You can use its parameters to select tests
by file name, test name, or tag.
This snippet from the output of Get-Help Invoke-Pester -Examples demonstrates Invoke-Pester's ability to search sub directories of a given directory, not necessarily the current working directory for tests to run
-------------------------- EXAMPLE 11 --------------------------
PS > Invoke-Pester -Script C:\Tests -Tag UnitTest, Newest -ExcludeTag Bug
This command runs *.Tests.ps1 files in C:\Tests and its subdirectories. In those
files, it runs only tests that have UnitTest or Newest tags, unless the test
also has a Bug tag.
So in your case it would probably be easier and cleaner to change your make call to
pwsh -Command 'Invoke-Pester -EnableExit
That's assuming that your build system will set the current working directory to the root folder of your project.
I am following https://learn.microsoft.com/en-us/azure/iot-dps/tutorial-group-enrollments
this article to create a group enrollment and add devices to that. I have completed the first two steps i.e
prepare the environment
Create a device enrollment entry
While doing the simulate the device step. It is showing that
"{deviceName}-public.pem file and include this value as your Client Cert. Open your {deviceName}-all.pem file ".
I am not able to find the two .pem files. Where can I find these files and how to generate those files?
Can somebody please help me in solving this issue.
I am getting following error although I have set the path in System variable
In "prepare the environment" part, there is a step 4:
Use the following Certifcate Overview to create your test certificates.
you will create all the certificates you will need.
For device certificate created in this step:
Step 4 - Create a new device
Where can I find these files and how to generate those files?
If you use PowerShell and for example, use "x509devicetogroup" as the device name in the following command:
New-CACertsDevice x509devicetogroup
You will get the following certificates in your working folder:
Here x509devicetogroup-public.pem and x509devicetogroup-all.pem files are what you need.
Update:
If you get the following error when using PowerShell to create certificates:
openssl : The term 'openssl' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At D:\Sample\azure-iot-sdk-c\tools\CACertificates\ca-certs.ps1:367 char:5
+ openssl pkcs12 -in $newDevicePfxFileName -out $newDevicePemAllFil ...
+ ~~~~~~~
+ CategoryInfo : ObjectNotFound: (openssl:String) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : CommandNotFoundException
Add a variable named "OPENSSL_CONF" to system environment variables:
Add a new system path variable points to OPENSSL bin directory like this:
I am trying to automatically publish all the projects of my .NET solution using the DeplyOnBuild=true argument (according to this answer )
I typed this command in the PowerShell:
msbuild mysolultion.sln /p:Configuration=Debug;DeployOnBuild=true;
But I get the following error message :
The term 'DeployOnBuild=true' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:59
+ msbuild mysolution.sln /p:Configuration=Debug;DeployOnBuild=true <<<< ;
+ CategoryInfo : ObjectNotFound: (DeployOnBuild=true:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
I am not sure what I am doing wrong.
PowerShell is interpreting everything after your first semicolon as a separate command.
You need to use quotes:
MSBuild example.sln /p:"Configuration=Debug;DeployOnBuild=true;"
Or use separate /p parameters:
MSBuild example.sln /p:Configuration=Debug /p:DeployOnBuild=true