We have TFS 2017 in premise setup hosted on our internal network. Lets call that tfs.OurInternalDomain.com
TFS application and its build controllers and agents are all hosted on our internal n/w.
Our production servers are hosted on a separate domain (data center) for security reasons.
I am trying to deploy TFS Build artifacts [files and folders] from within our internal n/w onto our production server using TFS Release management definition.
I am able to copy the files using "Copy files from" task onto a folder on our production server (which is on a separate domain) from our internal n/w using a separate ID with $(AdminLogin) and $(Password). This userID is a local admin on the production server. TFS services are running under a separate ID on our domain.
These are the variables for task: "Copy files from"
Source=$(System.DefaultWorkingDirectory)/$(BuildDefinitionName)/$(BuildArtifactName)
Machines=$(ServerOneOnSeparateDomain)
Admin Login=$(AdminLogin)
Password=$(Password)
Destination Folder=$(BuildDropLocation)
So far so good.
Next task is to run a powershell script on the target machine and that is where the build agent on our internal n/w is not able to execute the powershell script. I used both -http and https protocol. Below is the error log when http was selected.
Executing the powershell script: D:\TFS2017Build\Agent1\tasks\PowerShellOnTargetMachines\1.0.41\PowerShellOnTargetMachines.ps1
Deployment started for machine: '<ServerOneOnSeparateDomain>.com:5985'
##[debug]Deployment logs for Deployment operation on <ServerOneOnSeparateDomain>:5985
##[debug]Permission denied while trying to connect to the target machine <ServerOneOnSeparateDomain> on the port:5985 via power shell remoting. Please check the following link for instructions: https://go.microsoft.com/fwlink/?LinkID=390236System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server <ServerOneOnSeparateDomain> failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090311 occurred while using Kerberos authentication: There are currently no logon servers available to service the logon request.
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
Below is output when I execute winrm on production server:
winrm quickconfig
WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
Is there a way to fix this such that we do not disturb the existing TFS architecture of having the TFS Application, Build controller and agents hosted on the InternalDomain and be able to execute a powershell script on a separate domain? If not, is there any other way to fix this?
My end objective is to be able to deploy code to production via TFS that is hosted on our internal n/w.
I may provide more details if required.
According to this part error info:
##[debug]Permission denied while trying to connect to the target machine <ServerOneOnSeparateDomain> on the port:5985 via power shell remoting. Please check the following link for instructions: https://go.microsoft.com/fwlink/?LinkID=390236System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server <ServerOneOnSeparateDomain> failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090311 occurred while using Kerberos authentication: There are currently no logon servers available to service the logon request.
Permission denied The account used here must have permission to connect via power shell remoting.
To establish a PSSession or run a command on a remote computer, the user must have permission to use the session configurations on the remote computer.
By default, only members of the Administrators group on a computer have permission to use the default session configurations. Therefore, only members of the Administrators group can connect to the computer remotely.
To allow other users to connect to the local computer, give the user Execute permissions to the default session configurations on the local computer.
The following command opens a property sheet that lets you change the security descriptor of the default Microsoft.PowerShell session configuration on the local computer.
Set-PSSessionConfiguration Microsoft.PowerShell -ShowSecurityDescriptorUI
If that fails try adding the source to the TrustedHosts of the remote machine. You can read how here http://technet.microsoft.com/en-us/library/hh847850.aspx.
If you want to use https, you need Configure WinRM to listen on 5986.
More detail info please refer below similar issue and tutorial:
Release Management Error - Permission denied while trying to connect
to the target machine
Configuring WinRM over HTTPS to enable PowerShell remoting
Related
Trying to setup a simple AzureVMFileCopy task from the VSTS Release. I have already done the following steps:
Execucted Enable-PSRemoting
Setup the WinRM listener with self signed certificate and opened the Port 5986 over HTTPS for WInRM
Configured the Inbound firewall rule to allow traffic on port 5986 and 5985 as well.
In the VSTS task, tried giving the username using different conventions - Domain/username, .\username, username
In VSTS task, enabled copy prerequisites.
Configured the VSTS Agent on the VM to run in "interactive mode" and used the administrator user account. Have tried to configure using Service Account as well with the same administrator account.
Interesting thing is that the files are copied in the VSTS Agent _work folder but the final copy to target folder gives "Access is Denied".
Have tried verifying the connection using Enter-PSSession but that also gives the same error.
Here is the exception I get:
System.Management.Automation.Remoting.PSRemotingTransportException:
Connecting to remote server devocxdbvm.westeurope.cloudapp.azure.com
failed with the following error message : Access is denied
Any basic element I may be missing ?
Screenshot of the Azure File Copy Task
I experienced this same issue setting up a build machine for VSTS, fix for me was Method 2 here:
https://support.microsoft.com/en-us/help/896861/you-receive-error-401-1-when-you-browse-a-web-site-that-uses-integrate
which is to add the following registry key:
In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Right-click Lsa, point to New, and then click DWORD Value.
Type DisableLoopbackCheck, and then press ENTER.
Right-click DisableLoopbackCheck, and then click Modify.
In the Value data box, type 1, and then click OK.
Restart the VM
I believe (can't find where I read this now) that this was introduced by a security update to windows so may change again in future.
We have been working on setting up thebuild definition on the on Premise TFS 2015 server, however are stuck with the proxy issue that’s coming while running a build task (Azure powershell). The build task actually makes a call out to Azure to add an authenticated account to be used for Azure cmdlets, but however getting blocked by the proxy server as seen below. We need a way to pass current user credentials to the Azure Powershell cmdlets, any help would be appreciated.
Error Message
Network Access Message: The page cannot be displayed
Technical Information (for Support personnel)
Error Code: 407 Proxy Authentication Required. The ISA Server requires authorization to fulfill the request. Access to the Web Proxy filter is denied. (12209)
IP Address: some IP address
Date: 17/03/2017 09:03:58 [GMT]
Server: ..com
Source: proxy
Tried putting [System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials in the custom PowerShell script to be run as the task, however it gets blocked before entering the custom script. Basically, before running the custom script, Azure PowerShell build task tries to run Add-AzureRmAccount which makes a call out to Azure to add an authenticated account to be used for Azure cmdlets where it gets blocked by the proxy.
Finally, had to go to the basics, we switched to simple PowerShell task instead of Azure PowerShell for doing the initial handshake and passing the default credentials to the proxy.
Here's the link to the detailed workaround.
I am using VSTS (Visual Studio Team Services, formerly known as Visual Studio Onine) for continuous deployment to an Azure VM using an Azure File Copy task in my build definition.
The problem I am having is that I have an ACL setup on the Azure VM that is only allowing connections from my office for Remote Powershell.
With the ACL in place, the Azure File Copy task fails with an error like "WinRM cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that the firewall exception for the WinRM service is enabled and allows access from this computer." With the ACL removed, everything works.
To be clear, this is not a problem with WinRM configuration or firewalls or anything like that. It is specifically the ACL on the VM that is blocking the activity.
So the question is, how can I get this to work without completely removing the ACL from my VM? I don't want to open up the VM Powershell endpoint to the world, but I need to be able to have the Azure File Copy task of my build succeed.
You can have an on-premises build agent that lives within your office's network and configure things so that the build only uses that agent.
https://msdn.microsoft.com/library/vs/alm/release/getting-started/configure-agents#installing
Azure File Copy Task need to use WinRM Https Protocol, so when you enable the ACL, the Hosted Build Agent won't be able access to the WinRM on Azure VM and that will cause Azure File Copy Task fail.
When copying the files from the blob container to the Azure VMs,
Windows Remote Management (WinRM) HTTPS protocol is used. This
requires that the WinRM HTTPS service is properly setup on the VMs and
a certificate is also installed on the VMs.
There isn't any easy workaround for this as I know. I would recommend you to setup your own build agent in your network that can access to Azure VM WinRM.
I am setting up an integration tests build where I am just trying to start up a windows service.
I have used the InvokeProcess command to run the powershell scripts which just does the following
Start-Service ServiceName
The script fails when I run the build process but when I executed the same script outside TFS it works. I get the following error in TFS logs
Start-Service : Service 'ServiceName (ServiceName)' cannot be started due to the following error: Cannot open ServiceName
service on computer '.'.
Then I tried changing the way I am starting the service and used SC.exe with parameters "Start ServiceName" in the InvokeProcess and I get Access Denied error in TFS as follows:-
SC start ServiceName.
[SC] StartService: OpenService FAILED 5:
Access is denied.
I am using Network Service account to run the build.
After searching a while, I have come to the conclusion that I have to run the InvokeProcess with elevated privileges but I don't know how would I do that with in TFS.
Any help is much appreciated.
We run our build agent as a custom service account and give that domain account admin access on the servers we deploy to.
I have resolved the issue by adding Network Service account to the administrator group. I might not go with this solution as it seems wrong to assign administrative rights to Network Service account but I don't know how to assign Service Start/Stop permissions to Network Service without adding this account to Administrator group.
In short, I agree with the answer that a custom service account must be used to run the build with appropriate privileges.
We have a SQL server (Name: SQL) that launches an SSIS job with proxy credentials (a service account), consisting of multiple steps.
One of these steps require files to be put in a local folder on a remote machine (Name: VM) and execute a program that securely copies these files to a service on the net. I have successfully ran both PowerShell and WinRM commands to do this (as administrator), but I need to find a way to run them without being an admin on SQL.
All of these steps work fine, when the service account is a local administrator of both SQL and VM. However, we do not want the service account to be a local admin on SQL.
The command I run is:
Invoke-Command -ComputerName vm.fqdn -ScriptBlock {E:\Share\ThirdParty\FTP_Admin\FtpUpload.bat}
I found a google post suggesting I need to give access to the root/CIIV2 namespace. I gave the service account full control and restarted the WinRM service.
When it fails (NOT running as administrator), the security log gets populated with 4656 event ID's.
Any idea what I can try? Been stumped on this for a while.
Here is the link on the Microsoft technet forums:
http://social.technet.microsoft.com/Forums/en-US/ITCG/thread/70a5a870-b911-4b1a-9c68-e7d91142e511
Long story short - ensure the server has been patched to post SP1 (Server 2008 R2) at least if you are running into these problems.
By default, only administrators have access to the (default) runspace you are connecting to:
On the vm.fqdn, try running:
set-pssessionconfiguration -Name microsoft.powershell -ShowSecurityDescriptorUI
and grant full control to the service account. Restart the WinRM service (just confirm when asked).