I am trying to create a build agent in Visual Studio 2015. I have TFS 2015, and Visual Studio 2015 installed on my Windows 8 laptop. This is for my learning. I have been following the steps in link:
However, after Step 6, the command line complains that I do not have appropriate permissions.
My user I am logged in as has Admin rights on the box, is part of the Agent Pool Administrators and Agent Pool Service Accounts.
After the build agent is created, it has a Red color next to it showing offline. I am not sure how or have been unsuccessful in turning it to green.
Thoughts?
Thank you.
Sam
You likely need to run the agent with admin privileges. You may need to start CMD as admin before attempting to run ConfigureAgent.
Check the account that is running your build agent service to see whether this account belongs to Build Agent Service Accounts group.
Related
Original question here:
Windows Authentication doesn't work with IIS Express 10
At my workplace, we do development on a production network, meaning we have a regular, restricted account and an "admin" account, which has greater rights. We recently had a hardware refresh where we went from Windows 7 to Windows 10, and VS 2013 to VS 2017.
Under the old system, I could log in with my regular account, run VS 2013 as my admin account, and I was able to build and run my web application just fine in Firefox.
This does not work under Windows 10. When I try running VS 2017 under my admin account while logged into my regular account, windows authentication fails, giving me either 401.1 or 401.2 errors. The only way I have been able to get everything working is to log into my admin account and run it from there. This isn't the preferred way to do things. So, is there any way to do what I want to do in Windows 10 and VS 2017?
After cloning a 2010 TFS server, upgrading the clone's OS to 2012R2, upgrading SQL Server to 2012 SP2 (11.0.5343), uninstalling TFS 2010, and upgrading to TFS 2013 with update 5, we are running into issues starting the Build Service on the clone.
I've removed the agents and build controllers referencing the other original server through Manage Build Controllers, in Visual Studio 2013.
I've tried to use the TFS 2013 upgrade wizard and it fails when attempting to start the build service so I tried to unconfigure: "tfsconfig.exe setup /uninstall:TeamBuild" and reconfigure through the TFS 2013 upgrade wizard but it yielded the same result.
The TFS database server, Build Server, controller, and agent are located on the same box
For measure, I've even deleted the agents, controllers, and Unregistered and Registered the Build Service in the Team Foundation Server Administration Console as both the batch account used on the original server but that failed so to rule out authentication, I used my domain account (I'm a Local Admin, SQL Server Admin, and TFS Admin) but still had the same result with both accounts.
The Windows event log states “Service cannot be started. The handle is invalid”.
I'm not sure what else could be missed does anyone have any pointers?
There were over 100 Microsoft patches/updates applied over the weekend and the issue went away. Microsoft confirmed that the issue was related to the OS, not the TFS configuration or installation/upgrade.
Thanks for all your suggestions. Hopefully this will help someone else out if they are in the same situation and spinning wheels to find the answer. Keep your systems as up to date as possible!
Try to remove build service by going to Team Foundation Server Administration Console, select server name, and click Remove Feature, to remove build service feature, then re-configure it.
I have TFS 2013 Update 3 installed on a machine and I'm trying to configure the TFS Build service on another machine on the same domain. The registration of the build service completes successfully but the service, controller, and build agents go into an endless start/stop/restart loop. The event viewer on the build machine gives the following error in the Build Services Operational log:
Build machine 'x' lost connectivity to message queue tfsmq://buildservicehost-18/.
Reason: TF30063: You are not authorized to access http://tfs2013:8080/tfs/defaultcollection.
Things I have tried:
Both NetworkService account and a domain account for the build configuration
Unregistering/re-registering the build service
Uninstalling TFS on build machine and reinstalling
Creating a fresh server 2012 install, installing TFS build component on it
The domain account I tried to use was in the build service account group for the collection and I've even tried putting it in the admin group. I also tried running it as my own domain account which is a tfs admin and domain admin account. All with the same results. The fact that this occurred on 2 different machines, one with a completely fresh everything install leads me to believe the problem is on the TFS application tier itself but I have no idea where to go from here. Visual studio is able to connect to TFS just fine for all users.
It sounds like you have a TFS 2012 server that you are trying to connect a TFS 2013 build agent to. This is not a supported configuration.
It is recommended that your build Agents version of TFS matched the version on the server. This does not mean that you can't build with any version of MSBuild or VS that you want on that agent. That's configuration.
I ended up resolving this by doing the following:
Detach Collection
Backup Collection as a precaution
Uninstall TFS 2013 from the App Tier (which is also the Data Tier)
Re-install TFS 2013 and configure it for single server like it was without creating a collection
Attach the existing collection
Uninstall TFS on the build server
Re-install TFS on the build server and configure the service, controller, and agents.
This worked fine and didn't cause me to lose anything. I still don't understand why I was having problems in the first place but my only guess is that it was some type of remnant from doing a migration based upgrade from TFS 2010.
My Visual Studio 2010 issues following error when I try to map application to use local IIS:
A larger image can be viewed here:
http://img717.imageshack.us/img717/8323/errorvi.jpg
I run VS2010 as administrator and I have installed (I guess) all necessary services and IIS features.
What could be the reason?
Updated:
Having looked at the error message again, when you say you run as administrator, are you running as an account that a member of the Administrators group or the real Administrator?
If it's an account that's a member of the administrators group then you still need to right click and "Run As Administrator".
Ok. Every time when I reinstalled IIS it suddenly started to work. Then, next day issue reoccured. There was an issue with domain group policy, it turned out that some services were getting disabled with PC reset.
I am trying to set up remote debugging from my development machine into a production environment running in a virtual machine, but no matter what I do I get the following error:
Unable to connect to the Microsoft
Visual Studio Remote Debugging Monitor
named . The
Visual Studio Remote Debugger on the
target computer cannot connect back to
this computer. Authentication failed.
Please see Help for assistance.
This is my setup:
Host Machine:
Windows 7 Professional x86
Visual Studio 2010 Ultimate
Virtual Machine:
Windows 7 Professional x86
Both computers are on the same domain, with the same username and password. The firewall on the remote computer is turned off and the firewall on the host is on, but turning it off produces the same error. The accounts on both machines are members of the Administrators group and running both msvsmon and visual studio as administrator or either/or produces the same result. When I put the server name in the qualifier field in "attach to process" and click refresh, I can see the log on the remote machine saying that the host is connected but that is followed immediately by the above error. Lastly, and this may be the most important piece of information, when the authentication fails, I get an entry in the even log that states that a user account was locked out:
A user account was locked out.
Subject:
Security ID: SYSTEM
Account Name: MyHostComputerName$
Account Domain:
DomainWhichBothMachinesAreOn
Logon ID: 0x3e7
Account that was locked out:
Security ID:
MyHostComputerName \ MyUsername
*(which is identical on both machines)* Account Name:
MyUserName
Additional Information:
Caller
Computer Name: MyVirtualMachineName
I have read seemingly every tutorial, help ticket and random bit of information regarding this problem and remote debugging in general and tried just about every "quick fix". I would be very appreciative of any ideas. I can provide any additional information if needed. Thanks in advance.
"MyHostComputerName \ MyUsername" seems to indicate the VM service is trying to authenticate with a local user, not the domain user
have you created the same user & password as local accounts on both systems?
http://msdn.microsoft.com/en-us/library/ms164725.aspx
I had this same problem running VS 2010 Pro on Windows 7 Pro accessing Remote Debugger 2010 on Windows 2008 R2. I had created identical accounts on the server running the debugger and on my domain. I was running under my identical accounts both visual studio and remote debugger with administrator rights and with the firewall turned off. on both systems.
the error I got was "... the visual studio remote debugger on the target computer cannot connect back to this computer ..." I found this issue with both VS 2010 and VS 2005 so I knew it was an issue with my system
SOLUTION - add a local user account to your system running visual studio as a domain account won't work (you can run visual studio under the domain account, you just need the local account to be present with admin rights assigned).
I know this answer is for an old thread but there are a number of threads out there on this issue with no solution.
Go to target computer (that you want to debug remotely), open windows explorer and visit computer from which you are debugging. It will prompt for username password. Enter credentials for account that exist on both computers and has relevant permission. After it authenticates you will be able to use remote debugger.
My config was BOTH COMPUTERS IN WORKGROUP.
In my case when adding mu local computers credentials to remote host problem solved.
The credential is the workaround for the case when you have a "domain admin computer with vs studio" machine trying to remote debug a "non domain admin computer" machine from different domains.