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.
Related
I am testing a TFS 2015 to TFS 2018 upgrade. My environment includes one database server, one TFS app server, and one TFS build server. I was able to upgrade the app tier without any issues. It's been awhile since I've done this, but I assume I just run the TFS upgrade installer again on the build server and it will give me the option to update the build agent? I didn't see anything for it when I ran the upgrade on the app server.
We recently migrated from VS 2008 to VS 2013 including a set of setup projects. One of the setup projects is meant to install a web application. It has one custom action that is meant to check the connection to the database. The code of the custom action has not been touched during the migration and the .msi works perfectly when generated from VS 2008. When I built the .msi from VS 2013 it works perfectly well when installing on our local development server, and throw an error saying that it cannot connect to the db when rolling out in the clients environment.
I'd really appreciate if anyone can point me into direction of search here. I know that I'm passing a correct connection string, and .msi generated from VS 2008 can connect to that db from the same server.
Visual Studio custom actions that are installed for Everyone will run with the local system account. Connecting to a SQL DB will often fail because the DB doesn't allow the system account to connect, or because the DB is on a network share and the system account has no network privileges.
So it could fail because of the security settings of the DB or because the DB is on a network, and it may be nothing to do with the server. It might also connect if the install runs with a Just me setting because the custom actions then will run with the installing user's credentials. There may also be issues with architecture because servers are 64-bit and the 32-bit subsystem is optional, and you didn't say whether you install was x64 or your custom action code.
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’m doing a VSS to TFS upgrade for my team. We have configured the TFS server, now I’m trying to create a Team project on the server from my local VS2013 and I get an error as in the attached picture.
I have Farm administrator rights on SharePoint site, Full admin access to the Collection where I’m trying to create the Team project, Content Manager Rights on the Reports Folder.
I have cleared the TFS cache on my local as well.
Can you please help me out if I’m missing anything?
If you configured TFS to have Reports, it tries to create a folder in Reporting Services and populate with some pre-canned reports.
The error says that it is not able to find the machine with Reporting Services. Review the configuration at the console, if you can ping the machine, if port 80 (or another if you changed default) is reachable.
I have been using Visual Studio to deploy a Web Service to Azure; downloaded my publish profile to enable that and it was working fine for the past few weeks.
Today I tried to deploy an update and now all my deployments fail with the following:
17:25:03 - Preparing deployment for WindowsAzure1 - 25/03/2013 17:24:53 with Subscription ID 'xxx' using Service Management URL 'https://management.core.windows.net/'...
17:25:03 - Connecting...
17:25:04 - Object reference not set to an instance of an object.
17:25:04 - Deployment failed with a fatal error
I'm not sure what's failing here; is this saying it's unable to connect to the Service Management URL?
Last week I installed an SSL certificate on Azure and now I'm not seeing the option to download my publish settings. I know it used to be there but isn't now. Does having an SSL prevent me from somehow connecting to the management page?
Edit
Before leaving work I removed the certificate but when I then checked for the PublishProfile it was still not showing.
The PublishProfile is not available for any of the other users attached to the subscription - so I don't think it's related to my login.
Edit 2
A bit more drastic; I've now tried deleting my storage and service, to start from scratch. I created a new publishsettings file by removing the subscriptions already imported into Visual Studio and then following the link to "Sign in to download credentials". Next I created a new service and storage in Azure and tried to publish but the deployment still fails when connecting with
Object reference not set to an instance of an object
I have no idea what else I could try or what could be wrong, or where to look to find out.
I got the same error today. Why it wasn't working was because I hadn't uploaded the certificate in the managementportal prior to the publish.
After adding the certificate, everything worked just fine!
You can read more here: http://www.amido.co.uk/mark-omahoney/publishing-in-windows-azure-object-reference-not-set-to-an-instance-of-an-object/
The best way to solve above problem is to download the latest PublishSettings from Azure Management Portal and then use it with Visual Studio. This way your connection to Windows Azure Management Portal from local machine will be verified and validated. Once you have the basic connection working then you can publish your application to specific Windows Azure Service.
Also you can log into your Azure Management Portal and remove all old management certificates which are added in previous publishsettings download attempts.
The problem, in my case, was that my solution Cloud project had the thumbprint of the SSL certificate I'd uploaded in its ServiceDefinition.csdef and ServiceConfiguration.Cloud.cscfg. In my first edit I said that I'd removed the certificate from Azure, but hadn't then removed it from the project files; commenting them out allowed me to publish from Visual Studio again.
I'm not sure why this happened though, I had uploaded the certificate to Azure and was able to connect to my service on https in FireFox so the SSL was "working".
Web Deploy v3.6 BETA3 was released that fixes this issue. To resolve this error, you can download the Web Deploy beta and patch your VS2013 installation. http://azure.microsoft.com/blog/2014/08/11/web-deploy-3-6-beta-released/
Test Validate Connection once you installed the above Web Deploy. If it works, then fine else you can modify the proxy settings used by msbuild.exe (msbuild.exe.config) and check you can now publish from behind a proxy with Web Deploy.
Regards,
Logesh Shan
I think the certificate got corrupt. Deleting the solution .suo file and the .ccproj.user file in my Azure project did it for me.