I am executing a powershell script on a target machine using Azure DevOps release pipeline (which uses PSSession) and I have got the following error:
2022-06-17T12:27:22.1621620Z ##[section]Starting: PowerShell Script - Backup Temp DB
2022-06-17T12:27:22.2530275Z ==============================================================================
2022-06-17T12:27:22.2530704Z Task : PowerShell on target machines
2022-06-17T12:27:22.2531137Z Description : Execute PowerShell scripts on remote machines using PSSession and Invoke-Command for remoting
2022-06-17T12:27:22.2531501Z Version : 3.200.0
2022-06-17T12:27:22.2531752Z Author : Microsoft Corporation
2022-06-17T12:27:22.2532172Z Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/deploy/powershell-on-target-machines
2022-06-17T12:27:22.2532638Z ==============================================================================
2022-06-17T12:29:58.1951592Z ##[error]Unable to create pssession. Error: 'Connecting to remote server NewDBServer.XYZ.local failed with the following error message : WinRM cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet. For more information, see the about_Remote_Troubleshooting Help topic.'
2022-06-17T12:30:19.4281448Z ##[error]The remote session query failed for NewDBServer.XYZ.local with the following error message: WinRM cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet.
2022-06-17T12:30:19.4694522Z ##[error]PSSession could not be created for Machine:'NewDBServer.XYZ.local:5986'
2022-06-17T12:30:19.5266279Z ##[section]Finishing: PowerShell Script - Backup Temp DB
what am I missing here?
Update 1:
I logged into the NewDBServer using the credentials that I mentioned in the DevOps and task. This is what I got:
Don't know how helpful it will be however I sent the protocol to HTTP instead of HTTPS. So port 5985 was used and there were no issues.
Related
I'd like to add an offsite Windows VM to Azure Arc for health monitoring. The VM is hosted by Vultr and runs Windows Server 2016 Standard Build 14393.
However, installing AzureConnectedMachineAgent.msi on the target VM fails with error code 1603. Installation log also contains this error:
Start-Service : Service 'Guest Configuration Extension service
WixQuietExec64: (ExtensionService)' cannot be started due to the following error: Cannot start
WixQuietExec64: service ExtensionService on computer '.'.
WixQuietExec64: At C:\Program Files\AzureConnectedMachineAgent\ExtensionService\GC\Modules\Exte
WixQuietExec64: nsionService\ServiceHelper.psm1:367 char:5
Any suggestions on how to fix this?
You may Check if the user with which you are logged into the VM have
sufficient permissions to start a system service
If you find the following in the
%ProgramData%\AzureConnectedMachineAgent\Log\himds.log or in installation logs :
time="2021-02-11T08:39:38-08:00" level=error msg="Cannot open event source: Azure Hybrid Instance Metadata Service."
You can verify the permissions by collecting the following registry
key from an impacted server.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomS
Mitigation can be to grant the permission to write to the
SECURITY_SERVICE_RID S-1-5-6 which would grant the required
permissions to the himds service account.
https://learn.microsoft.com/en-us/windows/win32/secauthz/well-known-sids.
If the registry key does NOT exist on the impacted VM, then this
resolution will NOT apply as there will be a separate root cause such
as AV interference.
If the root cause is not found here ,then a procmon trace needs to be
taken to analyze the root cause for the msi not being able to start a
service.
( In case a procmon trace has to be analyzed , please open an MS
Support ticket)
To get support for Windows Agent and extensions in Azure, the Windows
Agent on the Windows VM must be later than or equal to version
2.7.41491.911. However the cause for the failure of agent installation is different in this case.
You may also want to check %programdata%\ext_mgr_logs\gc_ext_telemetry.txt log which must have had an entry something like this :
<GCLOG>........ Not starting Extension Service since machine is an Azure VM</GCLOG>
Cause:
This can happen while attempting to install the agent on an Azure VM.This is an unsupported production scenario.One Should not be installing this agent on an Azure VM as it conflicts with the Azure Guest Agent and interferes with Azure VM management.
If one wishes to use an Azure VM simply for testing purposes then
they can follow the below document for guidance
https://learn.microsoft.com/en-us/azure/azure-arc/servers/plan-evaluate-on-azure-virtual-machine
I am trying to automate installing windows service using Azure DevOps pipeline. I installed Windows Service Manager from here: https://marketplace.visualstudio.com/items?itemName=MDSolutions.WindowsServiceManagerWindowsServiceManager and added it to the pipeline as a task. The windows service should be installed on the virtual machine where the pipeline is, so I provided "LocalSystem" as Run As Username, and nothing for password. The service was not installed with the following error:
Service ' (MyServiceName)' cannot be created due to the following error: The account name is invalid or does not exist, or the password is invalid for the account name specified
I tried also the credentials I use to get to the virtual machine, but it gave the same error. How can this be solved?
Added:
The service can be installed without problems using installutil.
Azure Devops: installing a Windows Service
You could try to use deployment groups to test, if you are using the private agent:
As the document state:
Service Name - The name of the Windows Service installed on the Deployment Group Target.
You could also refer to the similar thread for some more details.
I am trying to apply Azure Pipeline Agent artifact while creating an Azure VM from the pipeline using Azure Dev Test Lab Create VM Task.
I have provided all the valid values in the ARM Template(organization, pat, agent name, etc)
but the specified artifact is failed to apply. here is the exception info
Validating parameters
Preparing agent installation location
Checking for previously configured agent
Downloading agent package
Extracting agent package contents
Getting agent installer path
Installing agent
ERROR: Connecting to remote server localhost failed with the following error message : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig". For more information, see the about_Remote_Troubleshooting Help topic.
The artifact failed to apply.
Anyone has any idea on why I am getting this exception? please help me if you have any information
(401) Unauthorized
This means that your token is not be get and used correctly. Just for test purpose, you can create a PAT with Full access scope to see if this works.
You need to check whether your token is correctly converted to Base64String in the script.
$token = "{PAT}"
$token = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($token)"))
In addition, if you tried the above two points and the problem still exists, you can share your script sample in the question for further investigation.
After configuring WinRM before installing the artifacts, the issue is resolved.
I am trying to run a shell script using C# but I receive an error after waiting for a lot of time to execute the command.
I am callingRunCommand() method like:-
vmClient.RunCommand(runCommandInput);
The error received is:-
Long running operation failed with status 'Failed'. Additional
Info:'VM 'Linux-VM-Name' has not reported status for VM agent or
extensions. Verify the VM has a running VM agent and that it can
establish outbound connections to Azure storage. Please refer to
https://aka.ms/vmextensionlinuxtroubleshoot for additional VM agent
troubleshooting information.'
I am building a Release Pipeline on Azure DevOps. Part of my release is to copy a bunch of files to the Azure VM. As far as I understand, the target machine needs to have PowerShell 5986 port open.
I have a VM with port 5986 open (I verified that by invoking remotely some commands on this VM with "PowerShell on Target Machines" task).
I added "Windows Machine File Copy" task and filled fields:
- Source
- Machines
- Admin Login
- Password
- Destination Folder
In "Machines" field, I put IP of the target machine.
As a result of running the release, I'm getting an error:
Failed to Create PSDrive with Destination:
'\\11.11.11.11\C$\TargetDirectory',
ErrorMessage: 'The network path was not found' The network path was
not found
I also tried to put IP address with a port, in this form: 11.11.11.11:5986
Then, I got this error:
Cannot convert value "\23.97.151.221:5986" to type "System.Uri".
Error: "Invalid URI: The hostname could not be parsed."
Documentation (https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/windows-machine-file-copy?view=azure-devops) says that IP address with a port is allowed.
What's the issue here?
I was getting the exact same error while doing these:
Initially in my release pipeline, I had an agent job and I created a Windows machine file copy task under the job and filled in all details correctly. I set the Machines field with the public IP address of my target server (a Windows azure VM) and I always got this error you reported.
I tried to use the Azure file copy task instead but I was faced with another problem (error message: Unable to get FQDN for all resources in ResourceGroup: {resourceGroupName}) which I couldn't get to fix after a lot of efforts.
This is the solution that worked for me:
Instead of running an agent job, I ran a Deployment Group Job. With deployment groups, I didn't need an IP address to connect to my VM. Setting up a deployment group for your Azure VM is very simple and well explained here
I created a Windows Machine File Copy task under the Deployment Group job I added. I filled same details for the task except that instead of the IP address of the Windows VM, I entered the computer name in the Machines field and the file copy task ran successfully!
I hope this helps
The problem is because you can't use that task to copy files across Windows Domain boundary! That is to say, if you build on host A and want to copy files to host B, then A and B must be in the same Windows Domain, otherwise you'll get the error like
##[error]Failed to Create PSDrive with Destination: '\\your-server-name-or-ip\some\path', ErrorMessage: 'The network path was not found'
That is to say, if you're using a hosted agent, then you're not able to copy files with that task to any host you have, no matter it has a public IP or not, or a FQDN, because they are not in the same Windows Domain!
You have two options to work around it:
Use Azure File Copy task if your target is an Azure VM or Azure Storage
Use private hosted agent and make sure your target host and your private agent are in the same Windows Domain
Last but not least, the document should really make it clear! It wasted me a lot of time on solving the problem!
go to the destination folder, right-click the folder select properties,share option is there, click that one and share everyone option is there
The solution is to go to the target server and SHARE the directory where the files would be copied. In Windows, just go to Properties of the directory, Sharing tab, and Share it to the user which is used in the VSTS task.
The answer is pretty simple, the DevOps Tasks are actually running PowerShell on you VM and trying to create a PSDrive.
Try using the task mentioned in the screenshot below: