I am setting up a load test controller and agents. I followed these guidelines:
Installing and Configuring Visual Studio Agents and Test and Build Controllers
Walkthrough: Using a Test Controller and Test Agents in a Load Test - Setting up the load test to use the controller.
Setting up the controller and agents was quite straightforward. Both of these services run under a local user named "LoadTest" which is member of the local Administrators group.
As the next step, Create a new Test Setting that Uses the Test Controller and Test Agents and Data and Diagnostic adapters, I added a new "Test Settings" file to the solution items of my Visual Studio 2010 solution. Thereby I fail when trying to define the controller to be used in the Roles tab:
I entered "localhost:6901" as the controller, then a warning icon appeared to the right. If I hover over that, it says:
Cannot connect with controller 'localhost'. If the controller service is not started you may be able to start it by clicking the restart rig button.
The following error was received:
You do not have the appropriate permissions to perform this action.
I am running Visual Studio in my personal user account, which is different to the user that runs the test controller ("LoadTest"). But I reckon that this should be the normal usage scenario. Further, me as well as the "LoadTest" user are members of the administrators group.
Can anybody tell me why this wouldn't work?
I found the "Troubleshooting Guide for Visual Studio Test Controller and Agent" which says:
2.2.1. Permissions: Test Controller not connected to TFS server:
To run tests remotely, Client user must belong to either TeamTestControllerUsers, or TeamTestControllerAdmins, or Administrators local group on Controller machine.
To manage Controller/Agent, Client user must belong to TeamTestControllerAdmins or Administrators local group on Controller machine.
Agent service account must belong to either TeamTestAgentService or Administrators local group on Controller machine.
Controller service account must belong to either TeamTestControllerUsers or Administrators local group on Controller machine.
Service accounts with empty/no passwords are not supported.
Even though my personal user account already is in the local Administrators group, this seems not to suffice though. So I added the user to the TeamTestControllerUsers group, too, and that fixed it.
Related
I'm trying to setup continuous deployment via the Aure Portal.
When doing this via the VSTS account (let's call it "VSTS Account A") which is owned by the same account owner as Azure, everything works fine.
In this case I'm trying to configure continuous deploymenet from source code held in another VSTS account (let's go with Account B).
The Azure account owner is not the Account B owner but is an admin (member of Organization Administrators) for Account B. The owner is also listed explicitly as a member of at least one project within Account B.
The problem is that when it commes to configuring "Deployment source" within the app service section, Account B is not listed as an option to choose from.
I've followed various links (e.g. part 4 of this page) about linking the VSTS account with an Azure account but still no joy. There are a couple of problems here:
The Azure classic portal has a New button within the Visual Studio Team Services section but when I choose Link To Existing, I get the following message:
Make sure you’re the account owner. If you are, maybe your account is
linked to another Azure subscription or connected to another Azure
Active Directory
Account B is not linked to another Azure Subscription or Azure AD.
The new portal doesn't even have an option to attempt to link a different account, plus the menu link says "Team Services Account Preview" so whether the Preview status has something to do with it, I don't know.
I'd have thought this would be a relatively common use case, has anyone had any joy setting up something similar?
I was finally able to choose the relevant account by making the VSTS principal a co-admin in the Azure account which contains the web app, signing in as that user and changing the directory to use from the the user dropdown menu (top-right). Note, the user account in question is already an administrator for a different Azure account, just to complicate matters further. I only had the option to change the directory once the user was a member of multiple directories.
So I finally got it configured and committing code to the specified branch was triggering a deploy. However, it transpires that setting up continuous deployment from within Azure gives you limited scope and I got constant errors which were not straightforward to fix.
I ended up getting it working properly by following these instructions:
Build: https://www.visualstudio.com/en-us/docs/build/apps/aspnet/ci/build-aspnet-4
Deploy: https://www.visualstudio.com/en-us/docs/build/apps/cd/deploy-webdeploy-webapps
Configuring it all from within VSO gives you a lot more clarity about what's actually happening.
When doing the initial setup, I had to go through an authentication step with the Azure account I was trying to deploy to and that process launches a pop-up window which was getting blocked so I missed it at first.
The initial build and deploy were fine but I was getting a build error when being triggered from a code commmit. This is because the Build Definition --> Variables --> BuildConfiguration value was set back to Release even though I set it to the correct value for my project when doing the initial configuration. Once I updated that, the next commit triggered the build which in turn created the artifact which in turn triggered the deploy which went through fine.
Googler from the future here, I had the same problem and came across a really good article called "DevOps: Connecting VSTS to Azure by Ken Muse" enter link description here
This worked like a charm for me from the first try!
Since we had moved TFS Application Tier to a different server the TFS builds have stopped working. Whenever I try to start a build it fails with the following error:
TF215097: An error occurred while initializing a build for build
definition \My\Build: TF214007: No build was found with the URI
vstfs:///Build/Build/8320. Either the URI does not exist, or NT
AUTHORITY\NETWORK SERVICE does not have permission to access it.
The set up is following:
Server TFSAT contains the TFS Application Tier and a build controller. Server TFSBUILD contains a build agent and a build service running under NT AUTHORITY\NetworkService account. The build agent uses build controller on server TFSAT.
I have already triple-checked that the network service account TFSBUILD$ belongs to the team project collection's group Project Collection Build Service Accounts.
Also I have already tried to open the URL vstfs:///Build/Build/8320 on the server TFSBUILD which results in starting a Visual Studio instance and giving the error: The provided argument vstfs:///Build/Build/8320 must contain a query parameter named url which contains the full qualified URL to the Team Project Collection.
I have also tried to create a fresh new build and run this one - the same issue.
Has anyone got a clue what might be set up wrongly? I could not find any additional permission that should be granted to the build service account (standard network service account in my case).
Please notice that I am quite a newbie when it comes to setting up TFS. Thank you in advance for any hints.
First, please make sure you have followed the correct operation in Move Team Foundation Server from one environment to another.
To narrow down the issue you can:
Try to restart the build service on the build controller and
agent and queue another build.
Use another build account not NT AUTHORITY\NETWORK SERVICE and try
again.
If you still get the error, try to use below workaround: delete the old build control and agent. Create a new one. Note: you may have to edit all build definitions to point to the new control and agent.
I added the TestController user which belongs to appropriate security groups. After that I click test and see that it's ok.
Now I click Apply Settings and it finishes saying that:
Failed to configure TFS Team Project Collection.
Failed to remove this test controller from TFS Team Project Collection.
Failed to clear load test database configuration.
So the final result is that settings (user and password) are not applied.
The point is that in my scenario I don't need to stick Controller to TFS. That's why I didn't set any settings in the Team Project Collection section (as well as in the Load testing section). So why does the program warn me about all that stuff?
This could be a bug in the cleanup. Cleanup of previous configurations is done before attempting to start a fresh configuration. Did you configure this machine earlier against a tfs or with other settings?
You can try to unconfigure the controller via the commandline before configuring it again.
testcontrollerconfig.exe delete
You will find this exe in the install path. Run the command from an admin command prompt and then try your configuration again.
We have one server with a build controller, one server with a test agent and one server with Visual Studio 2010 Ultimat installed. When we queue a test to build on the controller and run on the agent, the test (cuit) builds and runs on the controller.
The agent is connected to controller and everything seems connected and fine. There has to be one small detail we are missing or some configuraten that is wrong. We have tried to add a new agent on the controller and the "test agent status" on the agent is online and connected to the controller. The drop folder is accessible from all servers with the finished builds inside.
Any thoughts would be appreciated.
Bjørn
Add to your solution *.testsettings and set in roles tab remote execution and enter the name of the agent.
In the build definision set the *.testsettings under run settings.
We are looking to create a test TFS 2010 server based on our live instance.
One method which has been suggested is to clone the Team Project Collection (TPC) onto to another server - as detailed in this existing answer but I think there are a few additional steps?
In order to get the cloned TPC's GUID reset, I take it we would have to first reattach the cloned TPC in the admin console on the original server then detach, move and reattach on to test Server/TFS instance.
We are not running Sharepoint/WSS but would there be additional config work required on the test server with SSRS - in order for new projects to be created against the cloned TPC?
Are there additional using diffrent AD accounts for services or can all of that be resolved within the admin console on the new server?
Both servers will running on VMWare and on the same domain but different AD accounts would be used on the two servers to help prevent any unwanted interactions between the TFS instances.
I will recommended convert your TFS to virtual environment P2V using SCVMM, see this article,
http://mohamedradwan.wordpress.com/2011/06/23/converting-my-physical-domain-controller-to-a-virtual-machine-p2v/