I'm trying to configure a new install of Team Foundation Server Express. The problem I'm having is that when I run a build that outputs to a drop folder I get the error
An error occurred while copying diagnostic activity logs to the drop location. Details: Access to the path '\\c$\drops\Test Application\Test Application_20130206.9\Logs' is denied.
If I disable the drop folder the build runs fine.
The drop folder is located on the same machine as TFS. I've given full control of that folder to the NETWORK SERVICE account. Are there any additional accounts that need access to this folder or any additional steps I need to take to allow drops?
Thanks!
Related
Trying to run NuGet.exe pack on a .csproj with a .nuspec file.
Everything works fine locally. I've got NuGet.exe checked in alongside the sources. This particular NuGet package does not have any dependencies on any other NuGet package listed in the .nuspec file (and even if it did, they would be available in source control). I expected for NuGet.exe to just run on the build machine without trying to interact with anything on the web.
There is a NuGet.config file checked into the root folder of the source tree, but the command line commands run on the build machine appear to be ignoring it. The version appears to be 2.6.40619.9041 (on my local machine, the same nuget.exe that is checked into version control).
On the build machine, it was initially failing with the "consent" error, below:
Package restore is disabled by default. To give consent, open the Visual Studio Options dialog, click on Package Manager node and check 'Allow NuGet to download missing packages during build.' You can also give consent by setting the environment variable 'EnableNuGetPackageRestore' to 'true'.
This seemed odd because in this particular example, there are no packages to restore. I'm trying to build a package that does not have any other package dependencies. To get past this error, I started running it (in MSBuild Exec task) by forcing the EnableNuGetPackageRestore environment variable, like this:
Command="(set EnableNuGetPackageRestore=true) & $(NuGetExe) pack $(NuGetSpecFile) $(NuGetPackArgs)"
The next error from the build machine build log, after getting past the consent issue, is this:
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 168.62.224.25:443
That IP address is the address for nuget.org.
It appears as though nuget.exe is trying to do something like auto-update itself or some other task.
Q1: Is there any way to disable this behavior? If it is the auto-update, can I prevent this with some sort of command line option.
Q2: Although the nuget docs site lists -ConfigFile as a valid parameter for "nuget pack" it won't accept it. Is that parameter supposed to work?
Q3: If all else fails, how do I get NuGet.exe to look at our internal ProGet server (to which it could have access) instead of trying to look at nuget.org (to which access is blocked)?
Umm, I had checked in the NuGet.exe "bootstrapper" instead of the actual program.
Once I checked in the version found at %LOCALAPPDATA%\NuGet it stopped trying to reach out to the web.
I keep getting this error everytime I try to setup TFS plublishing with my Azure Cloud Services Account:
Unable to find AzureContinuousDeployment.11.xaml
And links to this post:
http://blogs.msdn.com/b/bharry/archive/2012/06/07/announcing-continuous-deployment-to-azure-with-team-foundation-service.aspx
I had removed the BuildProcessTemplates folder to another path inside TFS. I just restored it to "$//BuildProcessTemplates" just like the article said, but I keep getting the same error from the Windows Azure Management portal.
The publishing templates haven't been modified.
OK so apparently, I needed at least one Build Configuration defined in the "Builds" section of Team Explorer for this to work.
I added a new configuration called TEMP and directed the process template xaml to the root folder.
Once that was configured I went back to the Azure Management Site, retried the "Setup TFS Publishing" option and everything worked fine.
I have a problem with TFS2012 builds which I can't seem to figure out nor find any solution for.
Setup:
Separate SQL server, separate TFS Application server (TFSAT01 / WinSvr08R2) and separate build machine (TFSBLD01 / Win7x64).
Drop share created on TFSAT01 - R/W acess granted to the two computers in our domain: TFSAT01$ and TFSBLD01$ (According to #8 http://msdn.microsoft.com/en-us/library/bb778394.aspx)
The build controller is configured on the TFS app. server TFSAT01.
The build agents are running on the build machine TFSBLD01.
Problem:
My CI build does complete and does copy all binaries to the drop share.
But I keep getting one error under Other Errors and Warnings in the build output window which says: "An error occurred while copying diagnostic activity logs to the drop location. Details: Access to the path '\TFSAT01\Drops\PRODUCT-CI\PRODUCT-CI_20130211.16\Logs\ActivityLog.xml' is denied.". The ActivityLog.xml is indeed written and I can access it.
Any ideas to why I get this error even though it seems that the share is configured with the proper access rights?
Note:
I can get around this error by specifying a user-account for the build agent to use (also with R/W access rights to the drop share) - but I would rather if I could stick with the default NetworkService credentials used by the build controller and agents.
Adding in resolution based on discussion in the comments
The build controller account needs to have R/W permissions on the drop location. The TFSAT01$ account was provisioned here while the build controller was configured as network service. Since these are not really the same account providing R/W permissions to NT AUTHORITY\NETWORK SERVICE is the required fix.
The build controller must run under the same account which has R/W permissions on drop location. I recommend to use same user account for build agents and build controller.
On TFS build controller, right click on the XAML Build Configuration > [your build service]
Click on "Stop the service"
Click "change" button under Run service as: section
Use a user who has access to both TFS repository & the drop location.
p.s. using TFS 2015
Running TFS 2010
I am trying to do a proof of concept, having batch files run as part of the build process. I have an 'invokeProcess' in my build seqeunce which runs a batch file. When I run the build, it 'partially succeeds' and then shows an 'access denied' error on the batch file.
Thoughts? Honestly I'm not even sure how to diagnose what user it is trying to run under.
Is your build server different than your TFS server? In our environment, our build server runs all the windows services that execute the builds. Those builds are executed under the context of the user id that the build service is configured to start with.
To execute a batch file, you not only need to give permissions to the batch file itself, but you also need to grant rights to the cmd.exe file (since this will execute a new command line process) as well as any executables your batch file may call.
Try running procmon (http://technet.microsoft.com/en-us/sysinternals/bb896645) and execute your build again - it will show you exactly what files the system is denying access to.
Have you verified that the service account that is the identity for the build service has access to the batch location? You can find the service account in the TFS Administration Console (available on your TFS Server)
I have a separate server that runs tfs build.
I created an account that will run the tfs build service.
I am getting an error because it says it can't access the drop folder.
what permissions do I have to give the tfs build service account? I believe it has to be apart of some tfs specific groups?
Update
I decided just to use the tfsservice account on the domain...
I added the TFSService account using LogonAs for the TFSBuild service, I am getting a 'could not start team foundation build service on local computer' Error 5 access is denied.
I am using mydomain/tfsservice as the account name.
Since the build is actually finishing except the final copy task, simply add the TFSBuild account to the drop location's folder for full control. This will expose the smallest portion of the fs as possible.