I have two azure entities I'm trying to connect, a build agent running my nuget deployments and a VM (Windows Server 2012 R2) on which I'm trying to set up symbol hosting using SymStore.
From this page I am told to Grant full control permission to the build agent service account. How do I go about doing this? In the Publish Symbols build step, I can enter a URL to store the symbols, but I have no way of logging the build agent into the VM as the user that I've given full control permission to.
This setup is actually not possible; from the SymSrv docs: writes to an http-based symbol store are not possible.
It appears that the SymStore has to be on the same machine as the Azure build agent to give it full control permission. I happened to discover that NuGet will let me publish .pdbs, so I'm going to try that route instead.
Related
what I did;
I have my c# windows form application on Azure Repo and I created a build.
I assigned my physical test server to Azure DevOps under the Deployment groups page. And it is online.
I defined a release, I added an artifact that refers to the build pipeline from the Azure repo.
Now I want to transfer my windows form app release files to my physical test server (windows) under the Desktop folder and run. (also stop and delete previous app if it is already running)
For that, I tried to add a stage. But for the stage templates, I don't know which one to choose. There are deployment options for IIS and Azure services.
Bufre, I published my ASP.NET app using IIS website deployment. Worked fine. But how to do it for a desktop application? How to transfer and run?
I see a as a similar issue here, But I am new to YAML files and I could not produce.
Where to mention target physical path, which template to choose? Could you please advise on the steps?
You must install the DevOps agent on this server, then add it to the agent pool and then use any task that allows to install your app (depends on what kind of app you have). All tasks will be executed on the server directly, so you can use PowerShell, cmd or what ever.
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/pools-queues?view=azure-devops&tabs=yaml%2Cbrowser
I want to download ADLGen2 file to my local server using ADF.
I tried to set up self hosted integration run-time, but I am getting below error
the integration runtime (self-hosted) node has encountered an error during registration
The account through which I have logged into my azure portal and the account which has access on my local machine are completely different.
Azure Portal login : xyz_abc#gmail.com
Local machine login: officiallogin#companyname
Is the issue because of 2 completely different logins
Can you please let me know how to resolve this issue.
Thanks,
Raksha
When you say "The account through which I have logged into my azure portal and the account which has access on my local machine are completely different", make sure to uninstall and re-install the self-hosted integration runtime manually choosing the option2.
OR
You may try to uninstall the current self-hosted integration runtime. Maybe you can try the Option1. It will install and register the integration runtime automatically.
Reference: Create and configure a self-hosted integration runtime.
I am using TFS build process with the following MSBuild arguments:
/p:DeployOnBuild=True /p:PublishProfile=Development
The publish profile works when run from my machine in VS, but when it is run from the build server, it fails with this error:
Unable to create directory "\\10.21.8.24\w$\Connector". Access to the path '\\10.21.8.24\w$\Connector' is denied.
This is a FileSystem publish.
I tried specifying the permissions for the user account that the TFSBuildServiceHost service runs as on the target machine.
I've added full control on the entire W: drive, as well as I have created a share on the Connector folder and allowed the read & write access of this user to it.
Another thing I tried was stopping the web application in the IIS management console - but, the error still stays the same.
First, you could double check the account permissions by manually RDC that machine and try to access this \\10.21.8.24\w$\Connector folder using your TFS build service account, ensure this folder can be found and accessed successfully.
Also make sure the Connector folder is writable not Read Only.
Update
w$ is a Admin share.
As “Administrative shares” are defined all the default network shares
that can be accessed remotely only from network administrators. And
there are some firewall settings which may block the connection.
More details please take a look at this blog.
I am trying to configure Visual Studio Team Services with a Test Controller so I can use Azure VM's for my Lab Management.
I have created a new Azure VM (Windows Server 2012 R2) and installed the Test Controller on it. I've run the Test Controller Configuration tool and connected it to my Visual Studio Team Services Default Collection. The configuration tool doesn't show any errors and informs me that the controller is correctly configured.
On my local development machine I've launched MTM to create a new standard environment for the Azure VM. However, when I switch to the Controllers tab, I can see my TFSController but it is shown as offline with the following message:
'The test controller is currently unavailable. Ask your administrators
to connect to the test controller machine, launch the test controller
configuration tool, and re-configure ith with the correct Team
Foundation Server and team project collection. Alternatively, look at
the events in event viewer of the test controller machine to identify
the problem. Once the problem is resolved, click Refresh'.
The event log on the VM running the test controller doesn't show any errors. I've tried re-configuring the controller configuration with several combinations of credentials (local account, the username/password for the account that I use to logon to the VM and the same for the lab service account).
What am I doing wrong? Do I need to do something else because the Test Controller is running on an Azure VM?
It is not posible to connect a Test Controller/Agent to Azure DevOps or TFS 2018+. This is deprecated and a new solution using Azure Pipelines has been created.
You can then run tests directly from the Azure Test Plans page.
Find the full docs here: https://learn.microsoft.com/en-us/azure/devops/test/run-automated-tests-from-test-hub?view=vsts
Are you using same account on both controller and agent?
Use an account having admin rights on VM and proper access rights to the Visual Studio Team Services, to configure test controller and use same account to configure test agent.
That might work!!!!
Also ensure that Controller is running when you try to connect via agent.
I have two servers with TFS installed, one that runs the build service, and one that has the main repository. In order to have an account on a windows domain to run as the build service, what permissions do I need to give him in windows? I'm trying to use a newly created account, but am having registration issues, and I'm not sure if its windows permissions related or IIS related...
Thanks.
Two things.
The person configuring the build server - To perform this procedure, you must be a member of the Administrators group on the build machine and your Manage build resources permission must be set to Allow. For more information http://msdn.microsoft.com/en-us/library/ms181712.aspx#perms
Before a build machine can build projects in a given team project collection, you must configure the collection with the build service account for that build machine. First, you identify the account under which Team Foundation Build Service is running on the build machine. Then, on the application-tier server that hosts the collection, you add the account to the Project Collection Build Service Accounts group for that collection. http://msdn.microsoft.com/en-us/library/cc668757.aspx
It is strongly recommended that you use the service account rather than NT Authority\Network Service.
HTH
Cheers, Tarun
I think you can just use NT Authority\Network service