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).
Related
As the Azure DevOps admin at my organization I want to automate our standards for Service Connection security--but I'm at a standstill because I can't seem to make straight forward changes to Project level Service Connection security manually via the ADO web portal.
Specifically, if I go to an ADO Project, go to Service Connections under Project Settings, and open up the Security page for it, I see a number of "Assigned" groups, each of which I can change and save the Role of (i.e. to Administrator, Creator, Reader, or User). All's fine and dandy there. However, if I "+Add" a user/group, it defaults to "Inherited" Access and when I change and save to a role other than the original one I added it with, the changes don't take. Likewise, there's no way to remove any user/group that's been added.
Has anyone else run into this issue? And if so what's the solution? And why are new users at the project level being marked as "inherited" and if they're inheriting from somewhere, from where?
Tried adding a new user at the ADO Project Service Connection Security level. Tried changing user Role. Changes don't take. Can't remove user.
I am setting up an Amazon Workspace instance, and need to provide the user with a password to log in. The invite email only contains the registration code.
How do I set up a user password to enable the user to login into Amazon workspace only (no console access)?
I am creating an AmazonWorkspace from a custom bundle, and adding a user to Simple AD.
Individual workspaces created in Amazon WorkSpaces are assigned to, and used by, individuals who are defined in a Directory.
From Manage Directories for Amazon WorkSpaces:
Amazon WorkSpaces uses a directory to store and manage information for your WorkSpaces and users. You can use one of the following options:
AD Connector — Use your existing on-premises Microsoft Active Directory. Users can sign into their WorkSpaces using their on-premises credentials and access on-premises resources from their WorkSpaces.
Microsoft AD — Create a Microsoft Active Directory hosted on AWS.
Simple AD — Create a directory that is compatible with Microsoft Active Directory, powered by Samba 4, and hosted on AWS.
Cross trust — Create a trust relationship between your Microsoft AD directory and your on-premises domain.
If you have your own Active Directory, then use it. If you do not have Active Directory, the simplest option is to choose Simple AD, which is a Active Directory-compatible Samba service. (Charges apply)
The user is selected when the WorkSpace is created. Amazon WorkSpaces will send a registration code to the end user. The end user then uses an Amazon WorkSpaces client to connect with the service. They provide the Registration Code to configure the client (once only), then login with their AD credentials.
To set the user password for AmazonWorkspace, set user password on the WorkMail application for that user. Directory service manages users for both AmazonWorkspaces and WorkMail, and the password is shared across.
The user must exist, but can be disabled. Email address can be anything, in my case users do not use AWS email.
Users defined in IAM are not visible from AmazonWorkspaces and WorkMail. If a user has console, S3, ec2, etc.. access in addition to Workspace, they would need to be defined separately in IAM and Directory.
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.
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\" />
Actually I need to access to another folder at different server at the same network. I am planing to generate a kind of active directory user to work with the web server and my data server. How can I add it to my IIS 8?
I can't find any link to add access to Authentication section at IIS.
appreciate any help.
Ok I found solution! Simple as few click!!!
you can do it with following my Guid:
Select Application Pool at IIS8
Right click on the related pool and select advanced Setting
Find Identity under Process Model section
Set your credential at Custom account section.
it is done and don't forget to recycle the application pool and restart your web services.