I was trying to deploy my site using TFS release definition. For hosting the the site I am using MSDeploy Package Sync. Everything is fine but my hosted machine was in VPN so its showing below error while deploying throw TFS:
[error]System.Management.Automation.RemoteException: More Information: Could not connect to the remote computer ("developeriis"). Make sure that the remote computer name is correct and that you are able to connect to that computer. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_DESTINAT .
Same was working from my local machine which was connected to VPN. My question where should I add VPN details in TFS release definition?
There isn't a way to add the vpn details in TFS release definition. Seems you need to add the Hosted Agent machine to your VPN, obviously it's not available.
As a workaround you can try to deploy your own private agents that locates on your local machine or any other VMs within your VPN.
Then try to use the Private Agent for the deployment.
You can reference this thread:
Deploy from Visual Studio Team Services to on-prem IIS - VPN connect
Related
I'm new to Jenkins, i've build the dotnet application in jenkins using microsft publish command now i want to move the exe of the application from local system (where jenkins is installed) to a actual server. how to do it? how can i move code from my local system to server. Can anyone please guide me.
One way is to zip the exe and manually deploy it on server i want to automate it.
I believe you're looking to:
Deploy your application to an Azure Virtual machine
And also automate the process
For #1: I would highly recommend using Visual Studio to publish your app to the Azure VM from your local machine for ad-hoc deployments, unless you have a hard dependency on using Jenkins.
For #2: There are a few ways in which you can do this. Here are some great resources to refer:
Deploy to a Windows Virtual Machine
Migrate an ASP.NET Web application to an Azure Virtual Machine
Deploy your ASP.NET app to Azure virtual machines by using Azure DevOps Starter
Here is another detailed blog that walks one through the CI/CD setup using Azure DevOps.
Microsoft Visual Studio Team Foundation Server - Version 16.131.28106.2
Agent.OS Windows_NT
Agent.OSVersion 6.3.9600
Agent.Version 2.136.1
My TFS build agent is not identifying Visual Studio 2017(Enterprise) as a capability while running as a service(under a service account on my primary domain). That same agent does identify Visual Studio 2015 as a capability while running as a service under the same account as above.
I've updated the agent, removed and reconfigured the build agent in question, restarted the agent-service, and restarted the OS. I did notice that when this agent is first configured, the capability is briefly identified while the agent runs under the individual running the configure script, but when the agent switches over to running under the service account, the VS2017 capabilities disappear.
After noticing this, I gave the service account in question read and execute privileges on the root Windows install dir, 'Program Files (x86), and all directories and files associated with the VS2017 install, but this didn't help.
If I run a different build agent interactively(same version as listed above), VS2017 is identified as a capability, so I'm assuming there is something I need to do in regards to the service account I'm attempting to use.
For good measure, within the Visual Studio build task, I tried using the 'latest' option and the 'Visual Studio 2017' options. I also tried adding '/p:VisualStudioVersion=15.0' to the MSBuild args for this task.
Update: I also tried explicitly specifying the capabilities directly in the 'User-Defined' section, and I tried adding the capabilities through the use of environment variables on the agent host.
Have you ensured that the service account user is added as the role service account on the pool the agent is running on?
Also ensure that the service account is able to do the following in these Local Security Policies: "logon as a service", "act as part of the operating system", "Manage auditing and security log"
I can't say that this will be able to solve your problem, but I just know that these are necessary in the setups I handle.
You could also for quick and easy test add you service account as an administrator on the machine and test if it finds VS 2017 then. If it does, then you know you need to set some specific groups and permissions.
I recently installed TFS 2015 on a new machine. I want to configure the same machine as our build server but i have massive trouble doing this. I neither can configure the new vNext-system nor can i configure an "old-style" xaml build server. As the build account i want to use the NT AUTHORITY\Network Service. For the xaml configuration i set "Execute service as" to NT AUTHORITY\Network Service and use the same account for the connection to the team foundation server.
But when i add a new controller and want to browse to custom assemblies, i get a "service unavailable" error. So i decided to test without the custom assemblies, added an build agent and created a new build-definition for a simple test project. I added a build to the queue and wait. Nothing happenend (in the build window) until after about 50 seconds an error was shown in the build window: Service Unavailable (Typ VssServiceResponseException).
Same for the new vNext builds. I downloaded the agent.zip from the web-frontend, opened the powershell and started configuring the build-agent. After waiting some minutes, the configuration aborted with.... service unavailable.
So i decided to test something different : instead of using the FQHN, i used localhost and - tataaa - it starts the agent, which is also shown green in the web-frontends agent-tab. So i created a new vNext-Build-Definition and added it to the queue, but it does not start, but shows the message : "waiting for console output from an agent".
So i decided to test it on a different pc : i downloaded the agent to my laptop and installed it, configuring the agent with it's FQHN. Without any problems the agent was started and i was able to start and run a build.
So the question is : Why am i'm not able to configure the build service on the tfs. I guess it has something to do with permissions, but i don't now, what permissions the network service account should have. I also tried it with a local account, but with the same result.
Any hints are very appreciated. Thanks in advance.
BTW: I can ping the FQHN from the command-line.
This is the output, after trying to add a vNext-agent via the powershell.
UPDATE:
I used the the servers IP-address instead of its name and it suddenly worked.
Take XAML build for example, to configure a Team Foundation Build Service, you must be a member of both the Windows Administrators security group on the server on which you are configuring Team Foundation Build Service and the Project Collection Administrators group on TFS.
According to the second paragraph, you can configure build controller and add build agent. Before queuing a build, you need to make sure the build controller and agent are in Ready status, sometimes relevant services are not yet fully available when you newly configure them or restart them.
Also, you may try to remove build service feature, and reconfigure it, to see whether you can solve the issue.
The project I am on is using TFS Build in conjunction with Web Deploy to handle the deployments of the web site and service to the servers. We also have a windows service that needs to be deployed to the server as well.
My question is: Is there a way to deploy the Windows Service to the Web Server from the TFS Build server?
The other issue I have is that the service needs to be stopped before it can be deployed. I have tried to modify the Build Configuration file, but could not manage to get it to work.
Thanks.
Options:
If you install TFSBuildagent service on the web server and grant the user which runs the service Admin rights on the web server, then you can create a new build definition just for the deployment/installation. This is fairly simple and straight forward, but this would only work when you have limited number of web servers (who wants to install TFS BUild agent on all 2000 servers) and only work in the non-prod environment. This is how we are doing it for non-prod deployments, I have created a build definition which is just for deployment, which takes care of all the things like stopping services etc.
If the user which runs the TFSBuild Service on the build server have enough rights on the web server then you can use psexec or powershell to run your commands remotely. Read the below links: 1. PSEXEC
Powershell Remote commands
What did you do to stop the service in your build configuration file? Does the user have enough rights?
There is no inbuilt activity/process which can help you run scripts on remote machines in TFS build workflow.
Step 1 for you is to identify how you are going to run scripts on the remote machine, as mentioned above you can either use PSEXEC or Powershell (though running PowerShell on remote computers may be a little more complicated to set up).
Step2, write the actual scripts to do the work, stop services, install MSI etc.
Step3, Edit your current build defintion - create a new custom activity or make use of InvokeProcess activity from within your build definition to invoke the script that you have created in Step 2. InvokeProcess Activity
I'm working on automating our build process using Team Foundation Build 2010. When our TFS Server was installed, whomever installed it didn't install the Build Configuration Services so this node is missing from the TFS Admin Console. I'm pretty sure I know the answer to this but I wanted to check in case I'm missing something. I'm also asking because the TFS Server is a production server and my supervisors do not want to install anything on this server. Can the Build Services be installed on another machine or VM and still have the Build Configuration Node appear in the TFS Admin Console? I know the Build Controller as well as the Build Agent can be installed on another machine or VM. I just wanted to get clarification on the "Build Configuration Services" piece. Thank you
Absolutely! This is actually a very typical scenario. I don't normally recommend for people to install the build services on any of the application tier servers. When you install only the build features, the TFS Administration Console will show only the build features.
By installing it on separate machines, you can create a build farm of a build controller with multiple build agents. It scales very well.
Build servers would be considered "production" servers in my opinion as well. They don't have the same disaster recovery or monitoring requirements though. If a build machine dies, just image another one and add it to the pool. This is essentially how the elastic build service for the Team Foundation Service (aka TFS Preview) currently works. They get destroyed after each use.