I would like to know that is there any way to install the windows service on Azure environment? Or is there any alternate way of doing the same?
If I understand the question correctly what you need in Azure is a Worker Role, similar question on Stackoverflow: What's the concept of *worker role* in Windows Azure cloud?
Check out the this blog post 'Migrating Windows Service to Azure Worker Role'
http://blogs.msdn.com/b/joseph_fultz/archive/2010/04/02/migrating-windows-service-to-azure-worker-role-image-conversion-example-using-storage.aspx
Also look at the Windows Azure Training Kit for code & usage sample for Worker Roles in Azure
http://www.microsoft.com/download/en/details.aspx?id=8396
HTH
Another potential option is to use StartUp tasks to install a windows service in either a Web or a Worker Role.
Here is an MSDN article - although it seems a little short on the details.
How to Define Startup Tasks for a Role
Basically you will need to be sure that the installer is copied during the deployment and create a cmd file to execute the installer. Then add a Startup task element to the service definition XML file.
Couple of things to add along with the other answers:
You can install Services with Web or Worker Role through the Startup Task
Alternatively you can also run a process with elevated privilege through the Task Scheduler
Here are the steps to install a windows service on VM running Windows Server 2012 R2:
start your VM in Windows Azure Console and connect to it with Remote Desktop Connector
map your storage as a new drive in your VM:
net use z: \mystorage.file.core.windows.net\endoint /u:myusername verylongkeythatendswith==
Storage key can be found in your Azure Management Console -> Storages -> Manage Access Keys
copy all the necessary installation files to the mapped storage (copy&paste)
copy nssm to a local drive (not z: as it uses MAFS file system and that cannot be accessed with low-level windows API commands)
Create a .bat file with the following entries
set username=xxx
set password=yyy
call d:\nssm install "My service"
"%programfiles%\PathToService\myservice.exe" "-p 8677"
d:\nssm set "My service" ObjectName "%username%" "%password%"
sc failure "My service" actions= restart/60000/restart/60000/restart/60000 reset= 240
d:\nssm start "My service"
Username and password should be the ones you used to create the VM.
run the script. The service should be visible in your services list.
Enjoy!
PS : I used NSSM to simplify the service deployment.
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.
After a successful build using a hosted VS2017 agent, I'm trying to deploy on-prem using an local hosted agent which was setup using a domain account which should have sufficient permissions as it is in the local admin group. As I was digging around on this issue elsewhere, one user re-installed their agent using NTATHORITY\SYSTEM and it worked.
I d'ont really need to create or stop\start the website, just deploy the recent build artifact.
What permissions should I check or should I use another task?
019-04-06T21:03:10.3898646Z ERROR ( message:Configuration error
2019-04-06T21:03:10.3899503Z
2019-04-06T21:03:10.3899791Z Filename: redirection.config
2019-04-06T21:03:10.3900026Z 2019-04-06T21:03:10.3900293Z Line
Number: 0 2019-04-06T21:03:10.3900530Z 2019-04-06T21:03:10.3900852Z
Description: Cannot read configuration file due to insufficient
permissions 2019-04-06T21:03:10.3901076Z 2019-04-06T21:03:10.3901333Z
. ) 2019-04-06T21:03:10.8135484Z ##[error]Process 'appcmd.exe' exited
with code '5'.
An agent is running under a user. The error means that your user doesn't have permissions to read/modify the redirection.config file that is necessary to manage IIS.
You have multiple options to solve this.
Change the user were the agent is running under. In example: NTATHORITY\SYSTEM
Give permissions to the user were your agent is running under to the folder C:\Windows\System32\inetsrv\config. If you want to create app pools or websites etc, modify permissions are of course needed.
When we install Azure agent as a service(In Windows, search for 'Services' and look for something like Azure Pipelines Agent..), by default it is logged on as 'Network Service'. Change it to 'Local System' and the pipeline should be able to run IIS related tasks/commands.
From my local Windows command prompt, I can copy files to local Windows machines, and run commands on the local Windows machines with psexec. (For example, launching .bat files). I can also start/stop and query services on the Windows machines, for example with sc \machineIP query (servicename).
I am learning to be able to do the same thing with a stock Windows machine hosted in Azure.
Having created a stock Windows Server VM in Azure from the command line, what more must I do? Currently on the Azure VM, for testing, I have:
Turned off the Firewall
Disabled simple file sharing wizard
Shared C, with permissions for 'everyone'
Started 'remote registry' service
Added registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy with value of 1 (hex)
I am able to RDP to the machine without a problem, with the given public IP address, username, and password.
I note that I cannot access: \publicIP\c$
And psexec returns 'The network path was not found. Make sure the default admin$ share is enabled on (publicIP)' when running the command:
psexec.exe \\(publicIP) -u(username) -p (password) -i 1 cmd /c c:\runMe.bat
In the Azure portal, navigate into the resource group where your VM resides. Select the 'Network Security Group' profile used by your VM (eg, yourVMnameNSG) -> edit -> add inbound security rules.
eg:
Name: psexec
Source: any
Destination: any
Service: Custom (Any/135)
Action: allow
Repeat for required services
I'm trying to use the azure command line to start a vm:
azure vm start myvmnamehere
But it's telling me:
No deployments were found
I'm guessing that I need to specify the location "West US"?
azure vm start is going to start a virtual machine that you've already created, within a specific region. To do that, you'd first need to call azure vm create. You would first create your vm from an image in the gallery (and within a dns name, xxxxx.cloudapp.net). To see the images available to you, try running azure vm image list.
Also: don't forget to add --ssh or --rdp so you can have remote access, when calling azure vm create.
Jeff Wilcox blogged about this in more detail, here.