locked
Lab Deploy build fails with: Team Foundation Server could not deploy the following virtual machine

    Question

  • I'm pulling my hair out on this one. I have set up some nice blank VM's for my Lab, and i have created a build definition for deploying my application on it. Going to the right snapshot goes ok, but when the deployment scripts need to run things go bad.

    I have a VM called TC Windows XP, on which i need to install an MSI file. I use the following deployment scripts:

    TC Windows XP | cmd /c copy "$(BuildLocation)\TcePlugIn.msi" "c:\Tools"
    TC Windows XP | msiexec /package "c:\Tools\TcePlugIn.msi" /quiet

    My build always fails on the second command (first command works just fine) with the error: Team Foundation Server could not deploy the following virtual machine: TC Windows XP.

    I have tried many different things for that second part of the script:

    cmd /c msiexec /package "c:\Tools\TcePlugIn.msi" /quiet
    cmd /c msiexec /package "c:\Tools\TcePlugIn.msi" /passive
    cmd /c "c:\Tools\TcePlugIn.msi" /quiet
    etc.

    I even put the msiexec command in a batch file, and tried to run that.

    But all with the same result, why oh why is this error happening. And why isn't there any more info in the diagnostic error messages from the build?

    Running Deployment Script
    Initial Property Values
    MaximumAttemptsForNetUse = 0
    ScriptDetails = Virtual machine:  TC Windows XP AgentSpec:  Name=*, Tags=MachineName=TC Windows XP,EnvironmentName=TCE Configurator XPNL KS,TeamProject=TC Energy,TeamProjectHostGroup=All Hosts_TFS Lab FileName:  msiexec Arguments: /package "c:\Tools\TcePlugIn.msi" /quiet  WorkingDirectory:  EnvironmentVariables: BuildLocation=\\vbidev02.vanbeek.local\BuildOutputs\TC Energy\Configurator.Develop Nightly\Configurator.Develop Nightly_20120304.1 ComputerName_TC Windows XP=VSLM-80-01539af0-a3f4-4c91-b6d5-1f01d3231579.vanbeek.local InternalComputerName_TC Windows XP=VAN-34C9EFEAC0E 
    SharedLocationForNetUse = \\vbidev02.vanbeek.local\BuildOutputs\TC Energy\Configurator.Develop Nightly\Configurator.Develop Nightly_20120304.1
    ThrowOnError = True
    Running Script on virtual machine TC Windows XP: 
    Accessing the following location using the lab service account: VANBEEKLOCAL\TFSService, \\vbidev02.vanbeek.local\BuildOutputs.
    msiexec /package "c:\Tools\TcePlugIn.msi" /quiet
    Stopped accessing the following location using the lab service account: VANBEEKLOCAL\TFSService, \\vbidev02.vanbeek.local\BuildOutputs.
    Final Property Values
    MaximumAttemptsForNetUse = 0
    ScriptDetails = Virtual machine:  TC Windows XP AgentSpec:  Name=*, Tags=MachineName=TC Windows XP,EnvironmentName=TCE Configurator XPNL KS,TeamProject=TC Energy,TeamProjectHostGroup=All Hosts_TFS Lab FileName:  msiexec Arguments: /package "c:\Tools\TcePlugIn.msi" /quiet  WorkingDirectory:  EnvironmentVariables: BuildLocation=\\vbidev02.vanbeek.local\BuildOutputs\TC Energy\Configurator.Develop Nightly\Configurator.Develop Nightly_20120304.1 ComputerName_TC Windows XP=VSLM-80-01539af0-a3f4-4c91-b6d5-1f01d3231579.vanbeek.local InternalComputerName_TC Windows XP=VAN-34C9EFEAC0E 
    SharedLocationForNetUse = \\vbidev02.vanbeek.local\BuildOutputs\TC Energy\Configurator.Develop Nightly\Configurator.Develop Nightly_20120304.1
    ThrowOnError = True
     Team Foundation Server could not deploy the following virtual machine: TC Windows XP.
    Final Property Values
    MaxExecutionTime = 00:00:00
    MaxWaitTime = 00:05:00
    ReservationSpec = Name=*, Tags=MachineName=TC Windows XP,EnvironmentName=TCE Configurator XPNL KS,TeamProject=TC Energy,TeamProjectHostGroup=All Hosts_TFS Lab

    dimanche 4 mars 2012 15:32

Réponses

  • Thank you for both your replies. The problem was none of the above, but i did figure out what the solution was.

    I fixed it by running the msi installation (msiexec /package "c:\Tools\TcePlugIn.msi" /quiet) using psexec with credentials of a local user of the machine (the machine being a workgroup machine outside of our AD Domain). I was under the impression that the user the agents run as get administrative permissions on the machine, and that the lab service account gets the same permissions, but apparently it does not.

    The following snippet of the log shows that originally the lab service account was going to call the msiexec command:

    Accessing the following location using the lab service account: VANBEEKLOCAL\TFSService, \\vbidev02.vanbeek.local\BuildOutputs.
    msiexec
    /package "c:\Tools\TcePlugIn.msi" /quiet
    Stopped accessing the following location using the lab service account: VANBEEKLOCAL\TFSService, \\vbidev02.vanbeek.local\BuildOutputs.

    I could not find a setting to turn of this impersonation for commands that don't need/want this (maybe something to consider for future versions?).

    One thing to note if someone is going to use this solution: The user running psexec (VANBEEKLOCAL\TFSService in this case) needs to accept the EULA first, this can also be done by importing a registry key. I do this import in my build script as well, just before msiexec. The key is as follows:

    [HKEY_CURRENT_USER\Software\Sysinternals\PsExec]
    "EulaAccepted"=dword:00000001

    Hope this helps anyone else.


    • Marqué comme réponse Jeroen Vos lundi 12 mars 2012 07:39
    • Modifié Jeroen Vos lundi 12 mars 2012 07:40
    lundi 12 mars 2012 07:39

Toutes les réponses

  • Hello Jeroen,

    Have you installed TFS2010 SP1 on the TC WindowsXP VM? And as to my experience you need to apply the TFS2010 SP1 first in order to use the build agent on the VM.

    In addition, how do you create the TC WindowsXP VM? By using the .vhd template or creating it manually? If you creating it by using .vhd template, I think you need to use the build-in ones to make sure you can get the build goes well.

    Thanks.


    Vicky Song [MSFT]
    MSDN Community Support | Feedback to us

    jeudi 8 mars 2012 02:58
    Modérateur
  • I have seen this error occur when the deployment fails. I have some logging in my deployment so when it fails, I go back to the VM and look at the logs.

    The other thing which I have seen with Azure dev fabric deployment is that it doesnt work as is. You need to create a scheduled task and mark it to run with highest privileges. Then during deployment, you have to invoke the scheduled task. If your deployment might require higher privilrges since its an msi, scheduled task would be the way to go.

    Thanks,

    Anuj


    http://www.anujchaudhary.com

    vendredi 9 mars 2012 06:37
  • Thank you for both your replies. The problem was none of the above, but i did figure out what the solution was.

    I fixed it by running the msi installation (msiexec /package "c:\Tools\TcePlugIn.msi" /quiet) using psexec with credentials of a local user of the machine (the machine being a workgroup machine outside of our AD Domain). I was under the impression that the user the agents run as get administrative permissions on the machine, and that the lab service account gets the same permissions, but apparently it does not.

    The following snippet of the log shows that originally the lab service account was going to call the msiexec command:

    Accessing the following location using the lab service account: VANBEEKLOCAL\TFSService, \\vbidev02.vanbeek.local\BuildOutputs.
    msiexec
    /package "c:\Tools\TcePlugIn.msi" /quiet
    Stopped accessing the following location using the lab service account: VANBEEKLOCAL\TFSService, \\vbidev02.vanbeek.local\BuildOutputs.

    I could not find a setting to turn of this impersonation for commands that don't need/want this (maybe something to consider for future versions?).

    One thing to note if someone is going to use this solution: The user running psexec (VANBEEKLOCAL\TFSService in this case) needs to accept the EULA first, this can also be done by importing a registry key. I do this import in my build script as well, just before msiexec. The key is as follows:

    [HKEY_CURRENT_USER\Software\Sysinternals\PsExec]
    "EulaAccepted"=dword:00000001

    Hope this helps anyone else.


    • Marqué comme réponse Jeroen Vos lundi 12 mars 2012 07:39
    • Modifié Jeroen Vos lundi 12 mars 2012 07:40
    lundi 12 mars 2012 07:39