Login/Register
Release Management Agent not connecting
Asked Answered
tfsrelease-managementms-release-management
U

3

1

I'm trying to connect a Deployment Agent to my Release Management server with TFS (all running Update 2).

The Release Management server is outside the network of the test environment servers. It can be reached over HTTP. The test environment is running behind a proxy. I've changed the configuration of the config files to make sure connecting through the proxy works by adding this:

<system.net>
    <defaultProxy enabled="true" 
                  useDefaultCredentials="true">       
                  <proxy usesystemdefault="True"
                         bypassonlocal="True"/>
  </defaultProxy>
</system.net>

I'm using Shadow Accounts to connect the Deployment Agent to the Release Management Server.

When I run the Deployment Agent configuration wizard, everything succeeds. The log file shows no errors. However, when scanning for a new server in the Release Management Client the server doesn't show up.

I've changed the logging to verbose and found the following information in the Deployment Agent log file:

9/3/2014 1:07:37 PM - Information - (3036, 5676) - Service is running under identity: <MACHINENAME>\<USERNAME>
9/3/2014 1:07:37 PM - Information - (3036, 5676) - Deployer service is starting.
9/3/2014 1:07:37 PM - Verbose - (3036, 5676) - HeartBeat: Sending HeartBeat
9/3/2014 1:07:37 PM - Verbose - (3036, 5676) - HeartBeat: Starting Configuration Tests.
9/3/2014 1:07:37 PM - Verbose - (3036, 5676) - Initializing cache for user <MachineName>\<UserName>.
9/3/2014 1:07:37 PM - Verbose - (3036, 5676) - Loading profile for user <MachineName>\<UserName>.
9/3/2014 1:07:37 PM - Verbose - (3036, 5676) - Initializing cache for user <MachineName>\<UserName>.
9/3/2014 1:07:37 PM - Verbose - (3036, 5676) - Loading profile for user <MachineName>\<UserName>.
9/3/2014 1:07:37 PM - Verbose - (3036, 5676) - Initializing cache for user <MachineName>\<UserName>.
9/3/2014 1:07:37 PM - Verbose - (3036, 5676) - Loading profile for user <MachineName>\<UserName>.
9/3/2014 1:07:37 PM - Verbose - (3036, 5676) - Initializing cache for user <MachineName>\<UserName>.
9/3/2014 1:07:37 PM - Verbose - (3036, 5676) - Loading profile for user <MachineName>\<UserName>.
9/3/2014 1:07:37 PM - Verbose - (3036, 5676) - Initializing cache for user <MachineName>\<UserName>.
9/3/2014 1:07:37 PM - Verbose - (3036, 5676) - Loading profile for user <MachineName>\<UserName>.
9/3/2014 1:07:37 PM - Verbose - (3036, 5676) - Initializing cache for user <MachineName>\<UserName>.
9/3/2014 1:07:37 PM - Verbose - (3036, 5676) - Loading profile for user <MachineName>\<UserName>.
9/3/2014 1:07:37 PM - Information - (3036, 5676) - HeartBeat: Communication Tests terminated. Results are: 
 Test 1 of 7 failed:
Communication with the Deployment Controller Web Service was not successful. The error received is: Object reference not set to an instance of an object.
Test 2 of 7 failed:
Communication with the database through the Deployment Controller Web Service was not successful. The error received during the test is: Object reference not set to an instance of an object.
Test 3 of 7 failed:
The account running this Windows Service is not a valid user in the Release Management Server. Please add the user and try again. For cross-domain scenarios using Shadow Accounts, add the local Shadow Account user to the Release Management Server. The error received during the test is: Root element is missing.
Test 5 of 7 failed:
Root element is missing.
Test 6 of 7 failed:
Root element is missing.
Test 7 of 7 failed:
The Deployer user (<MACHINENAME>\<USERNAME>) does not have access to the crypto store. On the server where the deployment agent is installed, navigate to this folder %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys and give read/write access to <MACHINENAME>\<USERNAME>.

9/3/2014 1:07:37 PM - Information - (3036, 5676) - HeartBeat: HeartBeat timer is started.
9/3/2014 1:07:37 PM - Error - (3036, 5676) - Object already exists.
: \r\n\r\n   at System.Security.Cryptography.CryptographicException.ThrowCryptographicException(Int32 hr)
   at System.Security.Cryptography.Utils._CreateCSP(CspParameters param, Boolean randomKeyContainer, SafeProvHandle& hProv)
   at System.Security.Cryptography.Utils.CreateProvHandle(CspParameters parameters, Boolean randomKeyContainer)
   at System.Security.Cryptography.Utils.GetKeyPairHelper(CspAlgorithmType keyType, CspParameters parameters, Boolean randomKeyContainer, Int32 dwKeySize, SafeProvHandle& safeProvHandle, SafeKeyHandle& safeKeyHandle)
   at System.Security.Cryptography.RSACryptoServiceProvider.GetKeyPair()
   at Microsoft.TeamFoundation.Release.Data.Helpers.CryptoHelper.GenerateKeySet(String containerName)
   at Microsoft.TeamFoundation.Release.DeploymentAgent.Services.Deployer.DeploymentEventFetcherBase..ctor(Double interval, String dnsName, String serverIpAddress, Action`3 deploymentProcessor, String cryptoContainerName)
   at Microsoft.TeamFoundation.Release.DeploymentAgent.Services.Deployer.DeploymentEventFetcher..ctor(Double interval, String dnsName, String serverIpAddress, Action`3 deploymentProcessor)
   at Microsoft.TeamFoundation.Release.DeploymentAgent.Services.Deployer.DeploymentEventFetcher..ctor(Double interval)
   at Microsoft.TeamFoundation.Release.DeploymentAgent.Service.OnStart(String[] args)
9/3/2014 1:07:42 PM - Verbose - (3036, 5676) - Initializing cache for user <MachineName>\<UserName>.
9/3/2014 1:07:42 PM - Verbose - (3036, 5676) - Loading profile for user <MachineName>\<UserName>.
9/3/2014 1:07:42 PM - Verbose - (3036, 5676) - Initializing cache for user <MachineName>\<UserName>.
9/3/2014 1:07:42 PM - Verbose - (3036, 5676) - Loading profile for user <MachineName>\<UserName>.
9/3/2014 1:07:42 PM - Verbose - (3036, 5676) - Initializing cache for user <MachineName>\<UserName>.
9/3/2014 1:07:42 PM - Verbose - (3036, 5676) - Loading profile for user <MachineName>\<UserName>.
9/3/2014 1:07:42 PM - Error - (3036, 5676) - Object reference not set to an instance of an object.: \r\n\r\n   at Microsoft.TeamFoundation.Release.Data.Model.SystemSettings.LoadXml(Int32 id)
   at Microsoft.TeamFoundation.Release.Data.Model.ModelFactory.Load[T](Int32 id)
   at Microsoft.TeamFoundation.Release.DeploymentAgent.Services.Deployer.HeartBeat.SetNewInterval()
   at Microsoft.TeamFoundation.Release.DeploymentAgent.Services.Deployer.HeartBeat.TimerElapsed(Object sender, ElapsedEventArgs e)
9/3/2014 1:08:04 PM - Information - (3036, 5840) - Deployer service is stopped.

The log file shows all communication checks fail. What is going wrong?

UPDATE

After removing the key f92439b4a629bc3a41a69e308c... from the MachineKeys folder the permission error disappears. However, my Deployment Agent can still not connect to the server. This is what the log file shows:

9/8/2014 8:37:40 AM - Information - (2712, 292) - Service is running under identity: <machinename>\<username>
9/8/2014 8:37:40 AM - Information - (2712, 292) - Deployer service is starting.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - HeartBeat: Sending HeartBeat
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - HeartBeat: Starting Configuration Tests.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - Initializing cache for user <machinename>\<username>.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - Loading profile for user <machinename>\<username>.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - Initializing cache for user <machinename>\<username>.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - Loading profile for user <machinename>\<username>.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - Initializing cache for user <machinename>\<username>.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - Loading profile for user <machinename>\<username>.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - Initializing cache for user <machinename>\<username>.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - Loading profile for user <machinename>\<username>.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - Initializing cache for user <machinename>\<username>.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - Loading profile for user <machinename>\<username>.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - Initializing cache for user <machinename>\<username>.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - Loading profile for user <machinename>\<username>.
9/8/2014 8:37:40 AM - Information - (2712, 292) - HeartBeat: Communication Tests terminated. Results are: 
 Test 1 of 7 failed:
Communication with the Deployment Controller Web Service was not successful. The error received is: Object reference not set to an instance of an object.
Test 2 of 7 failed:
Communication with the database through the Deployment Controller Web Service was not successful. The error received during the test is: Object reference not set to an instance of an object.
Test 3 of 7 failed:
The account running this Windows Service is not a valid user in the Release Management Server. Please add the user and try again. For cross-domain scenarios using Shadow Accounts, add the local Shadow Account user to the Release Management Server. The error received during the test is: Root element is missing.
Test 5 of 7 failed:
Root element is missing.
Test 6 of 7 failed:
Root element is missing.

9/8/2014 8:37:40 AM - Information - (2712, 292) - HeartBeat: HeartBeat timer is started.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - Initializing cache for user <machinename>\<username>.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - Loading profile for user <machinename>\<username>.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - Initializing cache for user <machinename>\<username>.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - Loading profile for user <machinename>\<username>.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - Initializing cache for user <machinename>\<username>.
9/8/2014 8:37:40 AM - Verbose - (2712, 292) - Loading profile for user <machinename>\<username>.
9/8/2014 8:37:40 AM - Information - (2712, 292) - Deployment: Deployment Event Fetcher timer is started.
9/8/2014 8:37:40 AM - Information - (2712, 292) - Cleanup: Cleanup Service timer is started.
9/8/2014 8:37:45 AM - Verbose - (2712, 292) - Initializing cache for user <machinename>\<username>.
9/8/2014 8:37:45 AM - Verbose - (2712, 292) - Loading profile for user <machinename>\<username>.
9/8/2014 8:37:45 AM - Verbose - (2712, 292) - Initializing cache for user <machinename>\<username>.
9/8/2014 8:37:45 AM - Verbose - (2712, 292) - Loading profile for user <machinename>\<username>.
9/8/2014 8:37:45 AM - Verbose - (2712, 292) - Initializing cache for user <machinename>\<username>.
9/8/2014 8:37:45 AM - Verbose - (2712, 292) - Loading profile for user <machinename>\<username>.
9/8/2014 8:37:45 AM - Error - (2712, 292) - Object reference not set to an instance of an object.: \r\n\r\n   at Microsoft.TeamFoundation.Release.Data.Model.SystemSettings.LoadXml(Int32 id)
   at Microsoft.TeamFoundation.Release.Data.Model.ModelFactory.Load[T](Int32 id)
   at Microsoft.TeamFoundation.Release.DeploymentAgent.Services.Deployer.HeartBeat.SetNewInterval()
   at Microsoft.TeamFoundation.Release.DeploymentAgent.Services.Deployer.HeartBeat.TimerElapsed(Object sender, ElapsedEventArgs e)

I have created shadow accounts and this setup is working when I install the agent on an Azure virtual machine and use the same credentials as I'm using in this scenario. I suppose the problem has something to do with the proxy configuration at the customers site.

Unabridged answered 3/9, 2014 at 11:29 Comment(8)
The Deployer user (<MACHINENAME>\<USERNAME>) does not have access to the crypto store. On the server where the deployment agent is installed, navigate to this folder %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys and give read/write access to <MACHINENAME>\<USERNAME>. – Polyzoan
I've already done that. – Unabridged
Did you add the Shadow Account as a user in RM ? – Xanthus
@JohannBlais yes, the shadow account is added to RM I have the feeling that it has something to do with the proxy Other servers are running fine – Unabridged
On the deployer box, navigate to this folder %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys and delete the key that looks like - f92439b4a629bc3a41a69e308c.... Post this, reconfigure the deployment agent with credentials that have read/write access as mentioned by @JustTFS. – Selfidentity
@Selfidentity I've removed the key and reconfigured the Agent. The permission error is gone but the agent still can't connect. Any ideas? – Unabridged
Have you tried to connect with that account from the agent server to the RM server with IE? – Beguine
@MrHinsh IE web access works Currently mailing with product group They can't find it either Will post update when available – Unabridged
U
1

To fix the problem, you need to make sure that the credentials used to configure the Release Management server has modify permissions on C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys. You might have to take ownership of some of the files within that folder before you can grant yourself modify permissions.

It worked for me

Hi everyone, A quick update I found the solution to the problem. Its to do with the encryption files in the C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys. You need to specifically select the file that is used by Release Management within MachineKeys and apply full permissions to that file for the account thats being used for RM. If you do this at the folder level it doesn't recursively apply the permissions even if you tell it too. Believe that the SYSTEM account doesn't have permissions to the files in MachineKeys so when you try to change the permissions at the folder level it can't access those files during the process unless you manually override the security settings on the files individually. Hope this helps someone cause this has been driving me nuts!

Upheld answered 3/3, 2017 at 20:20 Comment(2)
Mostly accurate, so upvoted. But what I found was you have to specifically apply the Ownership, and select the box "Replace owner on subcontainers and objects". It will then apply the ownership change to the folder and its contents if you are logged in as an Admin to make the change. Then, you apply permissions to the folder and select to "Replace all child permissions with inheritable permissions from this object". This sets the permissions on the folder, and all files therein. You would do all of this to C:\Users\All Users\Microsoft\Crypto\RSA\MachineKeys, at least in Windows 7. – Peel
In Windows 2000, I believe it was something like C:\Documents and Settings\All Users\Local Settings\Application Data\Microsoft\Crypto\RSA\MachineKeys. – Peel
P
0

I cannot speak for the Release Management Agent, but anyone getting this error needs to understand it is related to cryptography and permissions and ownership of the MachineKeys folder - nothing to do with this RM, per se - as trying to use the RM is not the only thing that can cause this error to occur, as evidenced by the same problem manifesting from these ways, as well:

http://www.pettijohn.com/2010/05/cryptographicexception-during.html

https://social.msdn.microsoft.com/Forums/en-US/af5fec51-2e2d-4993-b383-a963bb941a95/rsacryptoserviceprovider-and-usemachinekeystore-gives-object-already-exists?forum=clr

Simply trying to run any code that invokes the RSACryptoServiceProvider will give the same error, if permissions/ownership is not set up properly - which it is not, by default:

The location where to set this up can be in several different places, and depending on the system:

Windows 7:
C:\Users\All Users\Microsoft\Crypto\RSA\MachineKeys (adjusting it here, only, worked for me)

C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys (user3137856's contribution)

Windows 2000:
C:\Documents and Settings\All Users\Local Settings\Application Data\Microsoft\Crypto\RSA\MachineKeys

You would navigate to the folder, as an Admin, to grant Ownership and permissions to the group you want. That group would be determined by whether you want just Administrators running your app, which means you want the local, computer-level Administrators group, or all users, in which case you want the domain-level Everyone group.

Either group you choose needs to have both Ownership of and Full Control rights to the folder, but also ownership and full control rights permissions on the files within it. It needs this propagated down from above.

You must therefore set the Ownership of the folder(s) to one of those 2 groups, but select "Replace owner on subcontainers and objects" when setting the Owner. This makes the files within have the correct Ownership, too.

Then, when you are applying permissions, right-click the folder, select Properties > Security tab > Advanced button > Change Permissions button > select the group, select "Replace all child permissions with inheritable permissions from this object", and click Edit. Then select every "Allow" checkbox, click OK on each dialog box all the way out. This will apply the permissions to both the folder and the files within.

Peel answered 7/3, 2017 at 22:12 Comment(0)
E
-1

My article http://www.msdevtips.com/2014/07/untrusted-domain-connectivity-in.html on the same topic. Verify each stpes and make sure that you have configured the shadow account correctly. I did released to Azure VM from my local server.

Episodic answered 12/9, 2014 at 9:20 Comment(1)
I wrote the same blog post ;) wouterdekort.blogspot.com/2014/07/… However, this doesn't work in this scenario and I can't figure out why – Unabridged

© 2022 - 2024 — McMap. All rights reserved.