I've checked that the TeamCity user has access to the network share in question.
All packages from the public NuGet feed are found correctly while packages available on the network share are not.
We use the network share when building via Visual Studio with the exact same path without a problem.
I've tried using "file://ratchet/NuGetRepository" but that doesn't make a difference.
TeamCity log entries and screenshot of the build step configuration shown below:
NuGet command: E:\BuildAgent01\plugins\nuget-agent\bin\JetBrains.TeamCity.NuGetRunner.exe E:\BuildAgent01\tools\NuGet.CommandLine.DEFAULT.nupkg\tools\NuGet.exe restore E:\BuildAgent01\work\95323b7041b60513\MySolution.sln -Source https://nuget.org/api/v2/ -Source \\ratchet\NuGetRepository\
Was able to solve this by specifying the fully qualified name of the network share, e.g. \\ratchet.hq.local\NuGetRepository.
Since the accepted answer did not provide a solution for my setup, I'd like to post what did allow TeamCity to access my network share.
First, a very important note: TeamCity Build Agent may either run as a Windows service or directly in command prompt. For my machine, this had the following consequences:
When run as a Windows service, the build agent was logged in as LocalSystem. For our network share, my machine's credentials were not given permissions.
Note: while this SO thread indicates that the network share can be configured to allow the machine's LocalSystem account to have permission, this was NOT an option for me.
When run in command prompt, the build agent will use the security context of whoever runs it (for me, it was my domain user). Again, for our network share, all domain users are given permissions.
The quick solution was to simply run the build agent in command prompt and call it a day; however, I did really want to run the build agent as a Windows service, since I think it is a cleaner approach.
Here's my solution:
First, I needed to grant my domain user the privilege to log on as a service. This is needed to run the service with my domain user's security context. I navigated to User Rights Assignment within Local Security Policy:
Control Panel -> Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment
Next, I added my domain user to the Log on as a servcie setting. For this, I made sure to include the domain with my user name.
Now that my domain user's security context can be used when starting a service, I navigated to Services (services.msc), located TeamCity Build Agent, and edit its properties:
Now, when relaunching the TeamCity Build Agent Windows service, it would be able to access the network share since it was using the security context of my domain user. I can now access the Nuget repository on our shared drive and keep the build agent running in the background.
You can include the package sources in NuGet.targets file. Just find the commented lines and add your path.
<PackageSource Include="https://nuget.org/api/v2/" />
<PackageSource Include="\\ratchet\NuGetRepository\" />
Related
We are trying to setup Release (continuous deployment) from our VSTS in the cloud. After the build is done, the Hosted Agent VS2017 tries to deploy the artifacts to the target server.
Firstly, it failed because our firewall blocked the target server from receiving the artifact (a .zip containing all the stuff). In fact, if I connect to the server via RDP and try to download the artifact from a browser, it's blocked.
Our security team temporarily disabled this firewall rule, and it worked (this also means the hosted agent has line of sight for the target server). Now, they don't want this rule off, they would like to know what is the User Account that tries to download/publish the artifact from the hosted agent, so they would allow the download of the .zip only for that specific user. I'm not sure if it's the same account which runs the service in the Host Agent, or if it's Network Service (therefore the own target server credentials), os some other account.
How do I know what user account should be granted rights in our firewall to download anything?
Use the Windows Machine File Copy task, you can provide a username/password to use for copying the files.
However, it uses RoboCopy over SMB to copy the files. As a result, it's probably going to be safer to set up a private agent within your network that has line-of-sight to the target servers, rather than opening up holes in your firewall a whole slew of ports.
I am using visualstudio.com Teams Services to build and deploy an ASP.NET website to two Azure VMs.
I have a build which on completion triggers a release to my two servers in a deployment group. When you configure a Deployment Group for Visual Studio Team Services you create an agent that by default runs as NT AUTHORITY\SYSTEM.
If I publish my build artifacts to Azure (the server option) then everything works fine and deployment succeeds to both my VMS. However when using a file-drop I get the following error:
The artifact directory does not exist:
\\MACHINE1\drop\RRStore\20170517.20. It can happen if the password of
the account NT AUTHORITY\SYSTEM is changed recently and is not updated
for the agent.
This is basically saying MACHINE2 cannot access \\MACHINE1\drop due to permissions. In windows I can bring up this folder just fine, but since the agent is running as NT AUTHORITY\SYSTEM it cannot access it.
I want to use a filedrop because my website is about 250MB (although in the meantime I am using the 'publish to server' option and deploying via team services.)
I am unclear how to give permissions to the file drop though as the agent is running as SYSTEM. I am running as a WORKGROUP and giving permissions to 'Everyone' does not seem to work.
What is the correct way to configure access to a VSTS drop folder so that the deployment agent can access it?
Few possible options:
Set up a domain (I tried doing this but then I need a new network interface and it sounds klunky)
Continue using teamservices to deploy the artifacts (or reduce the website size!)
Save to a storage account, but again I'm not sure how to configure that.
Run as a different user account
I have similar problems when deploying with VSTS. Instead I chose to:
Run VSTS agent on the deployment group VM as a local user with limited access.
Impersonate the account on the deployment group VM to test its access to the drop folder.
Save/cache a different credential to access the drop folder if applicable.
(So the sensitive information stays on the VM.)
The cached credentials can be a different local user account created on the drop server just for this purpose.
Grant the local user access to various parts of the file system explicitly to limit access permission of this VSTS agent service runner account.
This should work in most cases. In fact, this same way is used in my VSTS, Jenkins and TFS instances. This should prevent you from setting up a domain to solve this problem.
This may not be the best practice, but at least it should get you started in the right direction.
In VSTS I have a release definition, which needs to run a PowerShell script as administrator.
The release agent is configured to run as an account, which is a local administrator and has the required permissions, but UAC is restricting those permissions, unless PowerShell is executed "as administrator".
Can I run PS as admin from VSTS without disabling UAC completely on the server?
I don't think there is a way to do that using PS task. Can you try "Run PS on target servers" and provide admin creds. You will need to provide the machine name of the agent (so this is not ideal) as an input to the task. That might not require UAC. We will file this as a feature request.
I ran into this same problem. To fix it I did this (YMMV):
I uninstalled the Azure DevOps agent
Verified that the agent user was an admin
Reinstalled the Azure DevOps agent
When I originally installed the agent, the user the agent was running as was not an admin (I added that user to the Builtin\Administrators group after I installed the agent). I'm not sure if that caused a problem, but uninstalling/reinstalling solved it for me.
I do not think that the Inline or Path options are the issue. Maybe installing an Agent in the Deployment Environment Machine, assigning in the installation process the credentials of a user you are sure has administrative privileges on the SharePoint farm could help you. Then in VSTS verify that the agent is Online and working in the Deployment Group Section.
We got around not being able to use elevated Powershell commands by creating a light .Netcore Worker service with http request capability running in an elevated service privilege state. You can send a Invoke-RestMethod command from a regular Powershell YML task and it will trigger your custom logic on the other end of the ASP controller. We use it to remove Appx packages before re-installing for our Unit tests. The repo is located at, AzureAdmin
My build agents are not starting after I change the properties credentials to the domain account from the network service. I done this because the network service account cannot write to my drop folder.
Each time I add the network service to the drop folder share, it appears then disappears.
http://msdn.microsoft.com/en-us/library/bb778394.aspx I followed this but some steps are different, i have xp and it doesn't show the share tab so i go through security tab
So I guess I'm asking two questions here;
Agents are not starting after changing credentials.
Network service not able to write to the drop folder.
Thanks in advance
Yes, Network Service won't have permissions to write to a drop location. That's pretty standard. You need to be using a domain account.
The TFS Build Service will need to run as a domain user so it can write to the drop location.
The domain account for the build agent will need to be in the TFS Project Collection group for build service accounts (internal to TFS). I can't remember what it's actually called but you need to be a collection administrator to update it.
The domain account will also need some login as batch/service permissions but that should be done automatically when you reconfigure the service. Do you use the TFS Admin console to reconfigure the agent or did you just set the credentials on the service? (You should use the TFS Admin console).
I have been maintaining an installation for a while but I am not really an expert. now I've been asked to come up with a solution for this:
Our software is always sold together with a computer as it has to be run in a very controlled environment. The installer needs administrative privileges to be executed. So far we had two different users, one with administrative rights and other one without. Our custumer service login as Administrator, install the software and restart the machine so that the user can access as a normal user.
Now we want the user to be able to install the software themselves but we don't want them to have access as an administrator because they can modify things it shouldn't be modified.
So, is there any way to programmatically raise the user privileges during the installation and afterwards lower them back? The installer is made using InstallShield but we use vbscript to check some pre-requisites.
Check out CPAU. It allows you to create an encrypted command that will run the installation as administrator.
EDIT: This is a more comprehensive list of like tools.
If you are looking for a toolkit to do this kind of thing, well, Microsofts MSI technology has this built in: Administrator access is required to install the initial MSI file, additional patches (MSPs I think) are digitally signed by the original MSI and are thus deemed safe - users can install them without requiring administrator elevation.
You can do the same thing: As part of your administrative install, install a service. The service can create a named pipe - that you explicitly give user ACLs to - or even just a socket or monitor a drop off folder that allows the user level code to communicate with the service code (running with SYSTEM or configured access). The service can then use its SERVICE or configured account level permissions to either impersonate an administrator, or do other tasks on the behalf of the user without EVER giving the user any kind of elevated permission - even temporarily.