locked
Release Management xcopy deployer failure over http

    Question

  • Hi Everyone,

    My environment is the following:
    - Release Management for Visual Studio 2013 configured inside the domain.
    - The Deployer agent is running on a remote machine in the cloud.
    - The Drop Location Access on the server configuration is set to Through Release Management Server over HTTP(S).
    - I have setup the shadowing account: Same user name and same password in both machines (Rel Management and deployer).
    - The deployer service is running using the local account created for shadowing.
    - My release workflow contains only 1 step : An xcopy to a destination directory (c:\remotedrops).

    When I execute the release, I get the error: 
    "After 0 file(s) transferred successfully, file \"<filename>\" was unsuccessful".

    In the event viewer, in the deployer machine,  I found the following error event log:
    The remote server returned an error: (404) Not Found
    There was no endpoint listening at "http://<url>:<port>/FileTransferService.svc/mex that could accept the message. This is often caused by an incorrect address or SOAP action.

    From the deployer machine, if I launch a browser and enter http://<url><port>/FileTransferService.svc/mex ; after authenticating, I do get a 404.
    The same address however (without the mex at the end) http://<url>:<port>/FileTransferService.svc/ returns fine and I can even see the WSDL.

    Any idea on what's going on?

    Thank you

    P.S: I have checked this post (http://social.msdn.microsoft.com/Forums/en-US/6a0563f6-1692-47f6-9909-8f423e661ab8/release-management-xcopy-deployer-failure-over-https-after-0-files-transferred-successfully?forum=tfsbuild), but it does not answer my question.



    • Edited by Elextra Thursday, April 17, 2014 10:04 AM
    Thursday, April 17, 2014 9:58 AM

Answers

  • Hi Charles,

    Thank you for your response.
    Just FYI: a Local deployment works perfectly fine and so is my ghosting configuration. I.e: Deployment machine Release Management machine both locally in the domain. The xcopy works!

    Turns out, and hope you are sitting for this, that it's the length of the username that did the trick. (I am using the same user for both runing the releasemanager, the agent and the tfs connection)

    Let me elaborate on this (for those interested):
    I turned on all the possible logs in IIS and Release Management, and in one of the logs, I noticed how ReleaseManagement was deleting that famous directory I was talking about above in my post (59b80ec6-8ceb-4474-8312-289cc62096a1) from the %TMP% directory after it had failed to do the copy onto the deployment machine. And the path to that directory was something like c:\users\tfsrel~3\....\59b80ec6-8ceb-4474-8312-289cc62096a1 (my user name at this point was tfsrelmgr)
    So, by some miracle inspiration, I decided to shorten that name to less than 8 characters and I used RMAgent instead.
    I got the same error again: c:\users\rmagen~3\....\ANOTHER GUID

    Finally, out of options, I decided to cut it even shorter to a username with 3 characters. Sure enough, I worked the first time.

    Nasty bug!!! that cost me over a week of work !!!
    • Marked as answer by Elextra Tuesday, April 22, 2014 5:56 PM
    Tuesday, April 22, 2014 5:56 PM

All replies

  • Update: Got further, but still not working

    Turns out the web.config for the releasemanagement was configured to work using HTTPS. I changed it to be http (<security mode="TransportCredentialOnly">).

    Unfortunately, still not working. I am having another error in the event viewer log in the deployer machine. I have tried fiddling it and I have also pasted my results below:

    event viewer error log

    Message: Invalid path: \r\n\r\n
    Server stack trace: 
       at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter)
       at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
       at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
       at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

    Exception rethrown at [0]: 
       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
       at Microsoft.TeamFoundation.Release.Data.FileTransferServiceRef.IFileTransferService.DownloadFile(DownloadRequest request)
       at Microsoft.TeamFoundation.Release.Data.FileTransferServiceRef.FileTransferServiceClient.DownloadFile(String& FileName, Stream& FileByteStream)
       at Microsoft.TeamFoundation.Release.DeploymentAgent.Services.Deployer.FileDownloader.Download(String serverfilePath, String serverTempPath, String destinationFolder)
    Category: General
    Priority: -1
    EventId: 0
    Severity: Error
    Title:
    Machine: DEPLOYER
    Application Domain: DeploymentAgent.exe
    Process Id: 1676
    Process Name: C:\Program Files (x86)\Microsoft Visual Studio 12.0\Release Management\bin\DeploymentAgent.exe
    Win32 Thread Id: 1720

    Fiddler results (The failing correspond request):

    <s:Body>
    <DownloadRequest xmlns="http://www.microsoft.com">
    <FileName>59b80ec6-8ceb-4474-8312-289cc62096a1\favicon.ico</FileName>
    </DownloadRequest>
    </s:Body>

    Corresponding Response:

    <s:Fault><faultcode xmlns:a="http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher">a:InternalServiceFault</faultcode><faultstring xml:lang="en-US">Invalid path</faultstring>
    <detail><ExceptionDetail xmlns="http://schemas.datacontract.org/2004/07/System.ServiceModel" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><HelpLink i:nil="true"/><InnerException i:nil="true"/>
    <Message>Invalid path</Message><StackTrace>   at Microsoft.TeamFoundation.Release.Services.FileTransferService.DownloadFile(DownloadRequest request)&#xD;
       at SyncInvokeDownloadFile(Object , Object[] , Object[] )&#xD;

    What is 59b80ec6-8ceb-4474-8312-289cc62096a1 ? Should be the Build drop location. Favicon.ico is indeed my first file inside of this drop location. I tried, just for the heck of it, to remove favicon.ico and sure enough, the next time I run the release, I got the error on the next file in the drop directory, and this time with another GUID in front of it.

    I am hopping someone else stumbled upon this problem before!! 

    Thank you

    • Edited by Elextra Thursday, April 17, 2014 5:59 PM
    Thursday, April 17, 2014 5:57 PM
  • Hi Elextra,

    Based on the description, I'd like to to confirm several things with you:

    • Whether the two machines in the same domain. What's the source and destination machine in the deployment? Does's  the shadow account have sufficient permission to access the destination server?
    • Do you ever deploy successfully with the Release Management?
    • Why you use HTTP but not HTTPS?

    You can try the following methods to see if the issue can be resolved:

    1. Refer to  Release Management user guide to check  whether you configure Release Management correctly

    2. Have a try to deploy on the same machine to check whether the deployment is fine

    3. The drop location access over HTTPS, you can change the config file to use HTTPS to have a try

    4. On the destination machine, check whether the port that used for communication is available

    5. Whether check the firewall rules on the machines

    Please try the methods that I mentioned above. And elaborate more details if the issue still exist. Thanks for your understanding.

    Best regards,


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, April 21, 2014 4:42 PM
    Moderator
  • Hi Charles,

    Thank you for your response.
    Just FYI: a Local deployment works perfectly fine and so is my ghosting configuration. I.e: Deployment machine Release Management machine both locally in the domain. The xcopy works!

    Turns out, and hope you are sitting for this, that it's the length of the username that did the trick. (I am using the same user for both runing the releasemanager, the agent and the tfs connection)

    Let me elaborate on this (for those interested):
    I turned on all the possible logs in IIS and Release Management, and in one of the logs, I noticed how ReleaseManagement was deleting that famous directory I was talking about above in my post (59b80ec6-8ceb-4474-8312-289cc62096a1) from the %TMP% directory after it had failed to do the copy onto the deployment machine. And the path to that directory was something like c:\users\tfsrel~3\....\59b80ec6-8ceb-4474-8312-289cc62096a1 (my user name at this point was tfsrelmgr)
    So, by some miracle inspiration, I decided to shorten that name to less than 8 characters and I used RMAgent instead.
    I got the same error again: c:\users\rmagen~3\....\ANOTHER GUID

    Finally, out of options, I decided to cut it even shorter to a username with 3 characters. Sure enough, I worked the first time.

    Nasty bug!!! that cost me over a week of work !!!
    • Marked as answer by Elextra Tuesday, April 22, 2014 5:56 PM
    Tuesday, April 22, 2014 5:56 PM