Troubleshooting errors in lab management
Last updated: 12th May 2010
Welcome to the troubleshooting page for lab management in Visual Studio 2010. This is a repository of errors we have seen in different scenarios and the ways to fix it. You can either search for your error or browse by category. If your error is not on this list, please take a minute and report it to us by filing a bug.
Other useful links: Lab Management forum, TFS Best Practice Analyzer (with lab management checks)
You encountered an error in:
1. Setting up/configuring lab management
2. Managing and working with environments
3. Testing capability and running tests on the environment
4. Workflow capability and deploying application on the environment
5. Network isolation capability
1. Errors in setup and configuration
1.3. Networking problems when creating environments.
1.4. Errors in configuring test controller on a domain controller machine
1.7 TF26017 Unable to configure SCVMM server for Lab Management in TFS Admin console
1.8 TF255231 Unable to change SCVMM server for Lab Management in TFS Admin console
1.9 TF261007 Attach of Project collection fails if Lab Management is configured in source TFS
2. Errors in managing and working with environments
2.5. VM created from UK English locale template is still US English.
2.6. Clustered setup of hosts does not work with Lab Management.
2.7. Importing a virtual machine or template into lab management library fails.
3. Errors in testing capability and running tests
3.6. Test agent configuration fails with error 'Failed to apply user account changes'
3.7. Error in starting the test run: Build directory of the test run is not specified or does not exist
4. Errors in workflow capability and application deployment
4.2. Workflow capability status is stuck in 'Configuring' state forever
4.3. Issues with workflow capability and running workflows after Beta 2 to RC upgrade
5. Errors in network isolation capability
To-do
Details and troubleshooting steps
1. Errors in setup and configuration
Title |
1.1. When Team Foundation Server(TFS) and Virtual Machine Manager(VMM) Server are installed on the same computer, lab Management configuration fails if Network Service account is used as the Team Foundation Server Service account |
Version |
Beta 2, RC |
Operating Systems |
All |
Symptoms and impact |
Note: This issue is only applicable in a setup where TFS and VMM server are installed on the same computer.
Open TFS Admin Console Click on Configure Lab Management Type in SCVMM Server Click test Username/password dialog comes up. Type in the username and password.
The configuration is blocked because the username/password dialog used to insert the TFS Service account into VMM becomes stuck in an infinite loop.
|
Possible cause(s) |
Network Service accounts and local accounts are not supported in user roles in VMM – by design |
Resolution |
Change the TFS Service Account from Network Service to a Domain Account Before configuring Lab Management, change the Team Foundation Server system account from Network Service to a domain account that is a member of the Team Foundation Server Administrator Group. 1. Open the Team Foundation Administration Console and, in the left pane, click Application Tier. 2. In the right pane, click Change Account. 3. In the Update Service Account dialog, click Use a user account. 4. Type the username and password of a domain account that is a member of the Team Foundation Administrator Group. Make sure that the new account has permissions to access the Team Foundation Server logical data-tier. 5. Click OK. 6. In the left pane of the Console, click the Lab Management node and proceed with the configuration. |
Title |
1.2. Lab Management configuration is stuck when the account used to provision VMM server is also present as a local account |
Version |
Beta 2 |
Operating systems |
All |
Symptoms and impact |
1. Click configure lab Management in TFS Admin console 2. Type in SCVMM Server 3. Provide credentials of an account 1. Local user on the TFS Application Tier AND 2. Member of VMM admin role
Expected: TFS Svc account should be provisioned i.e. will be added into VMM admin role
Actual Lab configuration is blocked. Even when providing the correct username/password, the dialog returns with the message that "Ensure that you have sufficient privileges to connect to VMM Server"
|
Possible cause(s) |
If you have a .\account that is also a domain\account you will hit this issue. The account used to make connection to VMM was not fully qualified, so if there was a local account with the same name as well it would take precedence. |
Resolution |
1. Use an alternate account to provision VMM Server 2. Remove the local account which matches the account to provision VMM Server |
Title |
1.3. Networking problems when creating environments. |
Version |
RC, VS 2010 RTM |
Operating systems |
All |
Symptoms and impact |
1. Open Microsoft Test and Lab Manager, select Lab Center, and create a new virtual environment. Once you select Finish in the creation wizard, you get the following error: TF259115: Team Foundation Server could not find any suitable host to deploy the virtual machine: <name-of-vm>. More details: All the hosts in the host group had one or more of the following inadequacies: Host does not have the necessary network location(s) that are configured in Team Foundation Server or on virtual machine(s).
(OR)
2. Open Microsoft Test and Lab Manager, select Lab Center, and compose a new virtual environment. Within the machines tab, you notice the following error: This virtual machine does not meet networking requirements. Contact your administrator to ensure that at least one network adapter on the virtual machine meets the following requirements: a) The adapter is connected to a host network, whose location matches the one configured in Team Foundation Server. b) The adapter's network location matches the above location.
|
Possible cause(s) |
1. Every host that is part of SCVMM host group is verified for Lab Management readiness when you add that host group to be used for lab in TFS Administration Console. You may have added a host to an existing SCVMM host group, and haven't re-verified it in TFS Administration Console for Lab Management readiness. 2. You have a virtual machine in the library that is stamped with wrong network location. 3. You have a one-box setup, where an internal virtual network on that machine is used to simulate the lab network. |
Resolution |
To fix these problems, perform the following steps in order:
1. If you have a one-box setup, where everything is self-contained and an internal network is used to connect the virtual machines created by Lab Management, then you must run a command line tool to configure the use of internal network. Run the following command on TFS machine using administrator credentials from the C:\Program Files\Microsoft Team Foundation Server 2010\tools folder. Caution: Run this command only if you have a one-box setup.
tfsconfig lab /settings /networklocation:"Internal Network".
2. Go to each project collection in TFS Administration Console, select the lab management tab, select the host groups that you may have already added to that collection, and select 'Verify'. This will fix any hosts that haven't been verified for Lab Management readiness. In addition, if you have changed the network location using the command line tool (as described in step 1 above), this will re-verify the host based on the new network location.
3. For the virtual machine on which you see the failure, open the properties of that virtual machine using SCVMM. This could be a virtual machine in the library (if you encountered the failure during new environment creation) or a virtual machine on host (if you encountered the failure during composition of a virtual environment). Then, select the hardware properties of the virtual machine. Select each network adapter on the virtual machine, and clear the network location value.
Not all of the above conditions could exist in your situation. However, once you have gone through the above steps, you should be able to re-attempt the creation or composition of environment. |
Title |
1.4. Errors in configuring test controller on a domain controller machine |
Version |
Beta 2, RC |
Operating Systems |
All |
Symptoms and impact |
In the test controller configuration tool, you might see the following errors, when you install the test controller on a domain controller machine: 1. Failed to add Administrators group to TeamTestControllerAdmins groupThe configuration log file contains an exception “Could not add WinNT://BUILTIN/Administrators to group. exception: System.Runtime.InteropServices.COMException (0x8007056C): A new member could not be added to a local group because the member has the wrong account type.” 2. Additionally, if your service account is Network Service, you might see an error: “Failed to configure ACL” The configuration log file contains an exception “System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException: A new member could not be added to a local group because the member has the wrong account type” |
Possible cause(s) |
The domain controller machine has no local accounts or groups. This is not handled as a special case in the configuration tool. |
Resolution
|
1. For problem (1), ignore this error and close the configuration tool, as long as all other steps are successful. This is not a fatal error and does not affect the working of the test controller. 2. For problem (2), running test controller under ‘Network Service’ is not supported on a domain controller machine. Change the service account to a domain account and try again. |
Title |
1.5. tfsconfig tool reports the error: "There are two or more Team Project Collections named ‘<collection_name>’ registered in the system. Delete the duplicate collections and then try again." |
Version |
RC |
Operating Systems |
All |
Symptoms and impact |
The “tfsconfig lab” command is available for advanced users and provides functionality for advanced scenarios such as unconfiguring a collection etc. While most of this functionality is available via the UI few advanced scenarios are not. A few cases are not handled correctly in the tfsconfig lab commands and the following error is thrown on executing the command - “There are two or more Team Project Collections named ‘<collection_name>’ registered in the system. Delete the duplicate collections and then try again.” |
Possible cause(s) |
Lab commands which take the /collectionName parameter require that the collection name be unique within the Team Foundation Server. However in certain rare cases there could be multiple entries associated with a given collection name. This could be due to a. Failure during Team Project Collection creation and then reattempting to create a new Team Project Collection with the same name (which succeeds) b. Team Project Collection creation with the name of a collection that has been recently detached c. Changing the Team Foundation Server / Team Project Collection identifiers |
Resolution |
1. Open Team Foundation Administration Console 2. Select the “Team Project Collections” 3. Select the correct Team Project Collection 4. Select the “General” Tab 5. Click on “Stop Collection” 6. Click on “Edit Settings” 7. Rename the collection with an unique name and click “Save” 8. Click on “Start Collection” 9. Perform your operation using “tfsconfig lab” 10. Rename the Team Project Collection back to its original name and bring it back online i.e. repeat steps i-viii |
Title |
1.6. TF259015: Unable to configure network isolation (DNS Suffix) on TFS Admin Console ; Unable to detect DNS Suffix on a private network |
Version |
RC |
Operating systems |
All |
Symptoms and impact |
As part of configuring lab management using Team Foundation Admininstation Console, when you click 'Test' on Network Isolation tab, you see the following error:
TF259015: Team Foundation Server could not validate given DNS suffix. DNS Server reported the failure for this suffix : DNS Error Code : 10060. DNS Failure Message: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. Contact your network administrator and ensure that DNS server has a zone for this suffix that has been configured to accept dynamic updates.
The above sequence of steps is part of the setup guide to configure the valid DNS Suffix used in creating network isolated environments. |
Possible cause(s) |
1. Open command prompt with administrator privileges on the machine where the above error message observed. Run the command: Ipconfig /registerdns and observe if DNS registration has failed. To do so, open event viewer and check if there is a warning from source 'DnsApi' under Windows Logs -> System.
The warning gives you enough clues that you have inadequate ACL statements on your VLANs. Basically, ACL describes open/closed TCP/UDP ports for network communication between different VLANs on switch levels. If your private network is based on this model, many ports are closed by design within the same private network between different VLANs.
For more info look here: https://en.wikipedia.org/wiki/Vlan
|
Resolution |
1. If the cause of the problem is (1) above, then:
Add ACL statements to overcome the issue to allow TCP53 port needed for DNS registration. For eg (all values relative to your subnet) 9010 permit tcp 10.197.172.0 0.0.0.255 gt 1023 10.199.251.0 0.0.0.15 eq domain 8480 permit tcp 10.197.184.0 0.0.1.255 gt 1023 10.199.251.0 0.0.0.15 eq domain 8500 permit tcp 10.194.114.0 0.0.1.255 gt 1023 10.199.251.0 0.0.0.15 eq domain |
Title |
1.7 TF26017 Unable to configure SCVMM server for Lab Management in TFS Admin console |
Version |
RTM |
Operating systems |
All |
Symptoms and impact |
As part of configuring lab management using Team Foundation Administration Console, when you click 'Test' against SCVMM Server, you see the following error: TF260107: The Virtual Machine Manager does not have the service account <MachineName>\<AccountName> in the Administration role. Contact your VMM administrator and ask them to add this account in SCVMM Administration role. User is blocked from configuring Lab Management in TFS Admin Console |
Possible cause(s) |
1. The TFS Service account is not a member of VMM admin role. To verify: Open VMM admin conole --> Administration --> User Roles --> Administrators --> Members, Check if TFS Service account is present here. 2. TFS Service account is running as local admin account. |
Resolution |
1. In TFS Service account is not present in VMM admin role, manually add TFS Service account via VMM admin console () 2. If TFS is running under a local admin account, you need to change the TFS Service account to a domain account or Network Service because VMM doesn't support local accounts. Before configuring Lab Management, change the Team Foundation Server system account from Network Service to a domain account that is a member of the Team Foundation Server Administrator Group. 1. Open the Team Foundation Administration Console and, in the left pane, click Application Tier. 2. In the right pane, click Change Account. 3. In the Update Service Account dialog, click Use a user account. 4. Type the username and password of a domain account that is a member of the Team Foundation Administrator Group. Make sure that the new account has permissions to access the Team Foundation Server logical data-tier. 5. Click OK. 6. In the left pane of the Console, click the Lab Management node and proceed with the configuration. |
Title |
1.8 TF255231 Unable to change SCVMM server for Lab Management in TFS Admin console |
Version |
RC/RTM |
Operating systems |
All |
Symptoms and impact |
When you try to change the SCVMM server in TFS Admin Console (Application Tier à Lab Management) you get the following error: TF255231: The following name of the server running Virtual Machine Manager server name cannot be changed because resources are associated with it <VMMServerName>. Delete the host groups and library shares for each team project collection. Then try the operation again. Next when you try to remove host group/library shares from a project collection in TFS Admin Console (Team Project Collections à Lab Management) you get the following errors: TF254066: You must add at least one host group to the team project collection while configuring Lab Management. TF254067: You must add at least one library share to the team project collection while configuring Lab Management. User is blocked from changing the SCVMM server. |
Resolution |
In the following scenarios, you would like to change the SCVMM Server, when Lab Management is already configured
- Delete the Lab objects from each collection using Tfsconfig.exe lab /delete /collectionName: myCollection [Note: this deletes all the lab objects created using Microsoft Test Manager] - Change the VMM Server name in TFS Admin console(Application Tier à Lab Management) |
Title |
1.9 TF261007 Attach of Project collection fails if Lab Management is configured in source TFS |
Version |
RC [Fixed in Lab Management GDR] |
Operating systems |
All |
Symptoms and impact |
You have a TFS (say old_TFS) which has lab management configured and you are trying to de-attach a collection from old_TFS to a new TFS (say new_TFS) which doesn’t have Lab management enabled. The attach of project collection on new_TFS fails with the following error [Error] TF261007: Team Foundation Sever encountered the following internal error while trying to restore the application-level configuration values: Index (zero based) must be greater than or equal to zero and less than the size of the argument list. Try the attach operation again |
Resolution |
|
2. Errors in managing and working with environments
Title |
2.1. Importing a virtual machine template fails with the error: “VMM is unable to process one of the provided parameters for New-HardwareProfile. The parameter -NumLock was passed in with the following value "NULL". |
Version |
Beta 2 |
Operating Systems |
All |
Symptoms and impact |
When you store a VM template in the SCVMM library share, and then try to import it into the Lab Center of Microsoft Test and Lab Manager, you see the following error: “VMM is unable to process one of the provided parameters for New-HardwareProfile. The parameter -NumLock was passed in with the following value "NULL". |
Possible cause(s) |
Setting NumLock to 'False' in the hardware configuration of the virtual machine (in SCVMM) causes this problem. |
Resolution |
- Disable numlock on the VM you want to import. To do this, launch SCVMM Administration Console, go to Virtual Machine -> Properties-> HardwareConfiguration -> BIOS and uncheck ‘Numlock’ - Then try to import the virtual machine from Microsoft Test and Lab Manager again. |
Title |
2.2. Operations on virtual environments fail due to errors on physical host or library shares managed by SCVMM |
Version |
Beta 2, RC |
Operating Systems |
All |
Symptoms and impact |
Problem #1: Virtual environment operations such as "New virtual environment", "Deploy", "Store in Library", "Take Snapshot" fail. The error/failure reason for the virtual machine contains the string: "A Hardware Management error has occurred trying to contact server <host/library server name>" Problem #2: Virtual environment operations such as "New virtual environment", "Deploy", "Store in Library", "Take Snapshot" fail. The error/failure reason for the virtual machine contains the string: “VMM is unable to complete the request. The connection to the agent <host/libraryserver name> was lost. ”
Problem #3: Virtual environment operations such as "New virtual environment", "Deploy", "Store in Library” fail. The error/failure reason for the virtual machine contains the string: “Virtual hard disk < hard disk name> cannot be mounted on host <hostname> because it conflicts with other disks"
Problem #4: Virtual environment operations such as "Take Snapshot", "Restore to a snapshot", "Store Environment in Library" fail after a "Delete Snapshot" operation. The error/failure reason for the virtual machine contains the string: "The file "<complete location of avhd file>".avhd cannot be accessed because it is in use by another process on the <hostname>."
Problem #5: Virtual environment operations such as "New virtual environment", “Deploy environment from template” fail when the virtual machines in the environment are deployed on Windows Server 2008 SP2 hosts. The error/failure reason for the virtual machine contains the string: "This operation is now allowed in current state of Virtual machine..."
Problem #6: Virtual environment operations such as "New virtual environment", “Start” fail. The error/failure reason for the virtual machine contains one of these strings: a. The requested operation cannot be performed on a file with a user-mapped section open. (0x800704C8) b. VMName’ Microsoft Synthetic Ethernet Port (Instance ID{7E0DA81A-A7B4-4DFD-869F-37002C36D816}): Failed to Power On with Error 'The specified network resource or device is no longer available.' (0x80070037). c. The I/O operation has been aborted because of either a thread exit or an application request. (0x800703E3) |
Possible cause(s) |
Problems #1 and #2: This is an intermittent error occurring at the hosts or library server machines managed by the VMM server.
Problem #3: A disk might already be mounted on the host with the same signature. Or there might be a cache issue with VMM server. This issue is known to be caused more frequently if differential disks are used while creating virtual machines.
Problem #4: After deleting a snapshot, Merge operation happens in HyperV host. While the Merge operation is going on in the host, if we attempt new operations like Take snapshot/Restore to snapshot/Store environment in Library, this failure may occur in underlying VMM Server.
Problem #5: Virtual machines originally created on Windows Server 2008 R2 hosts and stored later in library cannot be deployed on Windows Server 2008 SP2 hosts. We get the following error in the ‘Fix Differencing Disk’ step of Create-VM operation : "This operation is now allowed in current state of Virtual machine..."
Problem #6: Can occur if Antivirus is installed on the host machine and it is scanning the files which the VMM /HyperV service is trying to access at the same time. |
Resolution |
To resolve problem #1, 1. Logon to the host/library server where the failure has occurred as depicted in the error message/failure reason.
a. winrm set winrm/config @{MaxTimeoutms="1800000"} b. Net Stop winrm c. Net Start winrm d. Net Start vmmagent The above commands set a higher value for a WinRM setting and restart the WinRM and VMM agent services for the new values to get reflected.
Winrm get winrm/config
To resolve problem #2,
a. winrm set winrm/config/Service @{MaxConcurrentOperations="200"} b. Net Stop winrm c. Net Start winrm d. Net Start vmmagent The above commands set a higher value for a WinRM setting and restart the WinRM and VMM agent services for the new values to get reflected.
Winrm get winrm/config
Note : The above resolution is valid ONLY if the Library Server/Host is at an operating system older than Windows Server 2008 R2. In Windows 2008 R2, the above settings are applied by default at installation time.
To resolve problem #3, 1. Restart the corresponding host mentioned in the failure reason (<hostname>) to un-mount the disk. 2. If the above solution does not solve the problem, then restart the VMM Server service.
To resolve problem #4, Wait for some time for the merge operation to get completed and then try the operation again.
To resolve problem #5, Make sure you have the QFE fix: https://hotfix/search.aspx?search=971677 on the Windows Server 2008 SP2 hosts to avoid this issue. Note: The above QFE will only work for VMs stored in library which do not have any snapshots on them. For VMs in library with snapshots, deploying the VM (originally created in Windows Server 2008 R2 host) on Windows Server 2008 sp2 host is not supported.
To resolve problem #6, Configure the real-time scanning component within your antivirus software to exclude the following directories and files: 1. Default virtual machine configuration directory (C:\ProgramData\Microsoft\Windows\Hyper-V) 2. Custom virtual machine configuration directories 3. Default virtual hard disk drive directory (C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks) 4. Custom virtual hard disk drive directories 5. Snapshot directories 6. Vmms.exe 7. Vmwp.exe More details at : https://support.microsoft.com/kb/961804 |
Title |
2.3. Virtual environment creation fails in the "Customization" step with error "Windows could not parse or process the unattend answer file for pass[specialize]. The settings specified in the answer file cannot be applied. The error was detected while processing settings for component [Microsoft-Windows-Shell-Setup]." |
Version |
Beta 2,RC |
Operating Systems |
Windows Vista, Windows 7, Windows Server 2008/R2 |
Symptoms and impact |
Creation of a virtual environment which contains atleast one virtual machine template fails. The environment goes to "Create Failed" state and the Virtual Machine ends up in Customization Failed state. When the owner of the environment logs on to the machine using the Microsoft Environment Viewer, he/she can see the following error message: "Windows could not parse or process the unattend answer file for pass[specialize]. The settings specified in the answer file cannot be applied. The error was detected while processing settings for component [Microsoft-Windows-Shell-Setup]."
|
Possible cause(s) |
This issue can occur if a wrong product key has been provided to the Virtual Machine Template while importing it using Microsoft Test Manager. |
Resolution |
Please make sure the product key provided to the source virtual machine template is right, for the version of the operating system. You can edit the template (from Lab Center -> Library -> Virtual Machines and templates) and enter the correct product key once more in case you are not sure about the correctness of the existing product key value residing in the template.
After the correct product key has been provided/updated in the Virtual Machine Template, creating new environments using the particular virtual Machine template will work fine. |
Title |
2.4. Virtual environment creation fails with error: "Memory requirement of the virtual machine(s) exceeds the available host resources. The placement policy for this host group is set to be conservative and hence virtual machines that are in stopped state are also accounted as consuming host resources." |
Version |
RC |
Operating systems |
All |
Symptoms and impact |
Virtual environment creation fails with the following error: "Memory requirement of the virtual machine(s) exceeds the available host resources. The placement policy for this host group is set to be conservative and hence virtual machines that are in stopped state are also accounted as consuming host resources." You can see this with any virtual environment, but you are more likely to see this error as part of TF260073 when you try to create a network-isolated environment, because all VMs should be deployed on a single host in a network isolated environment. |
Possible cause(s) |
By default, the SCVMM placement policy for VMs in virtual environments managed by lab is conservative. This means that the VMs in the stopped state on the host contribute to the capacity of VM deployment. (ex: total memory, CPU) |
Resolution |
1. Delete the old and unused environments on the host group, to free up resources. 2. Change the placement policy on the host group to aggressive: On your TFS machine, go to <TFS_Installation_Folder>\Tools and run the tfslabconfig command: TfsConfig.exe lab /settings /collectionName:<MyCollection> /hostGroup /edit /name:<MyHostGroup> /labenvironmentplacementpolicy:aggressive
Documentation can be found here: https://msdn.microsoft.com/en-us/library/dd547199(VS.100).aspx |
Title |
2.5. VM created from UK English template is still US English. |
Version |
Beta2, RC |
Operating systems |
All |
Symptoms and impact |
You prepare a golden virtual machine with Windows operating system using UK English settings (keyboard, locale, etc). You then store the VM as a template in SCVMM library. Then, you import it and create an environment out of it. The resulting virtual machine loses all the UK English settings and is created in US English settings.
|
Possible cause(s) |
An answer file is generated each time you creeate an environment from the template. The answer file created by SCVMM always uses US English settings. |
Resolution |
1. To workaround this, you have to first create an answer file manually. The specific settings that you need to set in the answer file are in the following two articles: https://www.msfn.org/board/lofiversion/index.php/t102558.html https://www.virtualizationadmin.com/articles-tutorials/microsoft-hyper-v-articles/general/managing-hyper-v-systemcenter-virtual-machine-manager-2008-part2.html 2. You have to use SCVMM to associate the answer file with your template. Once you do that, you might want to try deploying using VMM to make sure that the VM gets customized the way you wanted. 3. Once that is working fine, import the template into lab management. If you have already imported before doing the above, delete the imported entry using Microsoft Test manager, and then re-import after setting the answer file. |
Title |
2.6. Clustered setup of hosts does not work with Lab Management. |
Version |
Beta2, RC |
Operating systems |
All |
Symptoms and impact |
You configure Hyper-V hosts with clustering. When you try to create an environment on the hosts or store an environment into the library, you get the following error: "VMM is unable to process one of provided parameters for new-HardwareProfile. The parameter -HighlyAvailable was passed in with the following value "NULL"".
|
Possible cause(s) |
Host clustering is not supported with Lab Management. |
Resolution |
1. Use regularly configured hosts instead of clustered hosts for Lab Management. |
Title |
2.7. Importing a virtual machine into lab management library fails. |
Version |
Beta2, RC |
Operating systems |
All |
Symptoms and impact |
1. You prepare a virtual machine or template in SCVMM library. When you try to import that using Microsoft Test Manager, you get the following error: “Import failed, the specified owner is not a valid Active Directory Domain Services account. Specify a valid Active Directory Domain Services account and try again.” 2. When you check SCVMM job history, you notice that the Create Hardware job fails with Error 813.
|
Possible cause(s) |
1. The user account with which you are logged into Microsoft Test Manager is not a valid domain account. When you import a virtual machine or template from SCVMM into lab management, a new hardware profile object is created in SCVMM by lab management. The owner of this hardware profile is set to be the user currently logged into Microsoft Test Manager. 2. SCVMM cannot communicate with or lost trust with the domain controller. |
Resolution |
1. Verify whether the account with which you logged into Microsoft Test Manager is a valid domain user account. It could happen that you are logged into your client machine using a local account (instead of a domain account). If this is the case, log out and login as a domain user. 2. The user logged into Microsoft Test Manager belongs to a domain that is not trusted by SCVMM. Or, SCVMM cannot communicate with that domain controller. Verify if you can run the VMM Administration console on the SCVMM machine using the same domain user account. 3. You may have changed the domain of the machine that SCVMM is installed on. Even un-joining and rejoining the SCVMM machine to the same domain causes problems. You may have to uninstall (complete un-installation without data recovery option) and reinstall SCVMM. |
Title |
2.8. Restore snapshot on virtual environment fails with error: "TF259098: Team Foundation Server could not perform the following operation because of errors on one or more virtual machines: Restore snapshot. Resolve those errors, and then try the operation again" |
Version |
RC |
Operating systems |
All |
Symptoms and impact |
Restore snapshot on a lab environment fails with below error: TF259098: Team Foundation Server could not perform the following operation because of errors on one or more virtual machines: Restore snapshot. Resolve those errors, and then try the operation again. Exception occurred while querying the status of Data Exchange Service on virtual machine <machine_name> on host <host_name>. Inner error is Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) |
Possible cause(s) |
The issue will occur if the TFS Application Tier (AT) service account is not provisioned in the physical host's Administrators group. Most likely, you will face this problem when you add new physical hosts to your SCVMM host group, after you have configured the host group with lab management. |
Resolution |
Follow one of the two solutions below to fix the problem:
|
3. Errors in testing capability and running manual tests
Title |
3.1. Testing capability fails for the environment with the error "TF276055: The machine is not ready to run tests because of the following error: Unable to connect to the controller on <controller_name:6901>. The agent can connect to the controller but the controller cannot connect to the agent because of following reason: The server has rejected the client credentials. The logon attempt failed ." |
Version |
Beta 2, RC |
Operating Systems |
All |
Symptoms and impact |
The testing capability is not ready for the environment with the above error, as the test agent fails to communicate to the test controller.
In this case, following error will be observed in the logs of failing test agent. I, 3436, 4, 2009/11/12, 16:14:19.435, ASEEMB-TA8\QTAgentService.exe, AgentService: Failed to connect to controller. Microsoft.VisualStudio.TestTools.Exceptions.EqtException: The agent can connect to the controller but the controller cannot connect to the agent because of following reason: The server has rejected the client credentials. The logon attempt failed Server stack trace: at Microsoft.VisualStudio.TestTools.Controller.AgentMachine.VerifyAgentConnection(Int32 timeout) at Microsoft.VisualStudio.TestTools.Controller.AgentManager.BeforeConnectAgent(String agentName, String machineName, Boolean canPerformUITesting, IAgentService agentService) at Microsoft.VisualStudio.TestTools.Controller.ControllerConfiguration.ConnectAgent(String agentName, String machineName, Boolean canPerformUITesting, IAgentService agentService) at Microsoft.VisualStudio.TestTools.Controller.ControllerObject.ConnectAgent(String agentName, String machineName, Boolean canPerformUITesting, IAgentService agentService) at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs) at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext) 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.VisualStudio.TestTools.Controller.IControllerCallback.ConnectAgent(String agentName, String machineName, Boolean canPerformUITesting, IAgentService agentObject) at Microsoft.VisualStudio.TestTools.Agent.AgentService.ConnectToController(Boolean shouldThrow) |
Possible cause(s) |
1. [RC only] The test controller service is running under the same account as the one specified as the service account in lab management configuration for the project collection. You can verify this by opening the Team Foundation Administration Console -> Project Collection -> Lab Management -> Service Account.
Causes 2 and 3 apply only if you are not using the service account described above on a RC build.
2. The account under which test controller is running is not known to the test agent machine. ex1: The test controller is running under 'Network Service' account and the machine on which test agent is running is joined to a workgroup, and hence cannot authenticate the test controller. ex2: The test controller is running under a local machine account, and the corresponding shadow account (same username/same password) does not exist on the test agent machine.
3. The test controller is running under a local machine account which is shadowed on test agent machine, but while creation of this account on test agent machine, “User must change password at next logon” property was enabled.
This essentially means that the password for the shadowed account has actually expired and test controller cannot connect to test agent unless the password is changed or the account is recreated with this property unchecked.
3. [Beta 2 only] The test agent is running on windows XP machine in a workgroup and force guest policy is on. |
Resolution |
1. [RC only] To fix cause #1, either change the account under which test controller is running or the lab service account for the project collection. Then click on 'Repair Testing Capability' for the environment from Microsoft Test Manager to fix the problem.
In RC build, to fix causes 2 and 3, please use the lab service account mentioned above. It eliminates the need to create local accounts on the agent and controller machines.
2. If the test agent machine is joined to a work group (and not domain), then make sure the test controller service is running under a local account.
3. If the test controller service is running under a local account, make sure a user with the same user name/password exists on the test agent machine. Also check the properties of the account to make sure 'User must change password at next logon' is disabled. Else, if the test controller service is running under a domain account/Network Service account, make sure that the test agent is able to resolve this account.
4. [Beta 2 only] If the test agent is running in a machine with Windows XP, set the following registry key to turn off force guest policy using Regedt32, HKLM\System\CurrentControlSet\Control\Lsa and editing the forceguest value to 0. |
Title |
3.2. Test agent fails to start with the error "Could not register TCP channel: System.Net.Sockets.SocketException (0x80004005): Only one usage of each socket address (protocol/network address/port) is normally permitted " |
Version |
Beta 2, RC |
Operating systems |
Network isolated environments with machines running Windows XP |
Symptoms and impact |
The test agent fails to start on Windows XP virtual machine in a network isolated environment with the above error. The following stack trace is seen in the log file:
ASEEMB-SPEARHEA\QTAgentService.exe, AgentService: Could not register TCP channel: System.Net.Sockets.SocketException (0x80004005): Only one usage of each socket address (protocol/network address/port) is normally permitted at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress) at System.Net.Sockets.Socket.Bind(EndPoint localEP) at System.Net.Sockets.TcpListener.Start(Int32 backlog) at System.Net.Sockets.TcpListener.Start() at System.Runtime.Remoting.Channels.ExclusiveTcpListener.Start(Boolean exclusiveAddressUse) at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.StartListening(Object data) at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.SetupChannel() at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel..ctor(IDictionary properties, IServerChannelSinkProvider sinkProvider, IAuthorizeRemotingConnection authorizeCallback) at System.Runtime.Remoting.Channels.Tcp.TcpChannel..ctor(IDictionary properties, IClientChannelSinkProvider clientSinkProvider, IServerChannelSinkProvider serverSinkProvider) at Microsoft.VisualStudio.TestTools.Agent.AgentService.RegisterTcpChannel(String bindToSpecificAddress) E, 1880, 4, 2009/10/28, 07:05:57.868, ASEEMB-SPEARHEA\QTAgentService.exe, AgentService: Exception occurred while publishing AgentService object. Microsoft.VisualStudio.TestTools.Exceptions.EqtException: Could not register channel on port 6910. Only one usage of each socket address (protocol/network address/port) is normally permitted at Microsoft.VisualStudio.TestTools.Agent.AgentService.RegisterTcpChannel(String bindToSpecificAddress) at Microsoft.VisualStudio.TestTools.Agent.AgentService.CreateChannels(String bindToSpecificAddress) at Microsoft.VisualStudio.TestTools.Agent.AgentService.OnStart(String[] args) E, 1880, 4, 2009/10/28, 07:05:58.040, ASEEMB-SPEARHEA\QTAgentService.exe, AgentServiceBase: Exception occurred while starting AgentService. Microsoft.VisualStudio.TestTools.Exceptions.EqtException: Test agent service could not register with the test controller. Could not register channel on port 6910. Only one usage of each socket address (protocol/network address/port) is normally permitted at Microsoft.VisualStudio.TestTools.Agent.AgentService.OnStart(String[] args) at Microsoft.VisualStudio.TestTools.Agent.AgentServiceWrapper.OnStart(String[] args) at Microsoft.VisualStudio.TestTools.Agent.AgentServiceBase.OnStart(String[] args) I, 1880, 1, 2009/10/28, 07:05:58.681, ASEEMB-SPEARHEA\QTAgentService.exe, AgentServiceBase: exiting. |
Possible cause(s) |
This error seems to indicate that the socket on which test agent wants to listen is not available, probably because the old socket was not closed properly by the underlying layers. |
Resolution |
Restart the machine |
Title |
3.3. Test agent fails to connect to controller and fails with the error System.Net.Sockets.SocketException (0x80004005): A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 172.22.221.228:6901 |
Version |
Beta 2 |
Operating systems |
All |
Symptoms and impact |
Connection from test agent to controller fails and log file repeatedly contains this error:
System.Net.Sockets.SocketException (0x80004005): A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 172.22.221.228:6901 |
Possible cause(s) |
Firewall is blocking the connection.
The test controller adds a program exception in firewall exception list, which does not work if firewall service starts after the controller service is started because in that case firewall is not aware of the ports controller has opened. |
Resolution |
To confirm that firewall is indeed the problem in this case, can you please try doing the following. 1. Try telnet from your agent machine to controller machine (telnet 172.22.221.228 6901) and see whether the connection succeeds or not. If firewall is the problem, it will fail. 2. If telnet fails, then try restarting the controller service and/or try disabling the firewall. After this telnet should succeed and agent connection to controller should also work. 3. Add port exception for 6901 in your firewall on the test controller machine. |
Title |
3.4. Test agent connection to controller fails with the error TF267055: The machine is not ready to run tests because of the following error: Unable to connect to the controller on '<fully_qualified_machine_name>:6901'. The agent can connect to the controller but the controller cannot connect to the agent because of the following reason: Authentication failed on the remote side (the stream might still be available for additional authentication attempts). No authority could be contacted for authentication. |
Version |
Beta 2, RC |
Operating systems |
All |
Symptoms and impact |
Connection from test agent to controller fails and log file repeatedly contains this error:
Unable to connect to the controller on '<fully_qualified_machine_name>:6901'. The agent can connect to the controller but the controller cannot connect to the agent because of the following reason: Authentication failed on the remote side (the stream might still be available for additional authentication attempts). No authority could be contacted for authentication. |
Possible cause(s) |
The machine with the test agent has lost trust with the domain. To confirm this, try accessing a file share for agent machine from controller machine. |
Resolution |
Unjoin the agent machine from domain and rejoin it.
If you get the problem on network isolated environment then make sure that the machine is on workgroup or private domain. |
Title |
3.5. The test agent doesn’t start on a machine because one or more dependencies failed to start. You observe the following error in the lab center in MTLM: TF267066: Test agent is not running on the machine. Click on 'Try Again'. If that does not fix the error, then log in to the machine and make sure the 'Visual Studio Team Test Agent' service is running without any errors. |
Version |
Beta 2, RC |
Operating systems |
Windows XP, Windows Vista in workgroup |
Symptoms and impact |
The test agent service refuses to start on a client OS on a machine joined to workgroup. The following errors can be found in the System event log: o The Microsoft Visual Studio Test Agent 2010 service depends on the Anmeldedienst service which failed to start because of the following error: The operation completed successfully. o This computer is configured as a member of a workgroup, not as a member of a domain. The Netlogon service does not need to run in this configuration. |
Possible cause(s) |
The test agent is running under Network Service account and on a work group machine, it cannot start because 'Netlogon' service isnt running. |
Resolution |
Change the test agent to run under a user account (not Network service) using the Visual Studio Test Agent Configuration tool (launch from Start -> Microsoft Visual Studio 10.0) |
Title |
3.6. Test agent configuration fails with error 'Failed to apply user account changes' |
Version |
Beta 2 |
Operating systems |
Windows Vista, Windows 7, Windows 2008 - when logged in as a local user |
Symptoms and impact |
When the user logs in as a local user (ex: agentsvc) and tries to configure the test agent in Vista +, the configuration fails with the error: 'Failed to apply user account changes'
Here is the stack trace: E, 2009/11/20, 14:35:23.254, Got Exception : System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.UnauthorizedAccessException: Access is denied.
--- End of inner exception stack trace --- at System.DirectoryServices.DirectoryEntry.Invoke(String methodName, Object[] args) at Microsoft.VisualStudio.TestTools.Execution.ExecutionUtilities. AddUser(DirectoryEntry userToAdd, DirectoryEntry computer, String groupName) at Microsoft.VisualStudio.TestTools.ConfigCore.TestControllerHelper. AddUserAccount(ServiceAccount account, String groupName, String machineName, Boolean useRemoteName) at Microsoft.VisualStudio.TestTools.ConfigCore.TestControllerHelper. AddAgentAccountToControllerGroup(ServiceAccount agentServiceAccount, String controllerUri) at Microsoft.VisualStudio.TestTools.ConfigCore.AgentConfiguration. HandleUserAccountChangeForProcess(AgentConfigurationUpdatePack updatePack, DelegateStatusUpdate statusListener) at Microsoft.VisualStudio.TestTools.ConfigCore.AgentConfiguration. Configure (AgentConfigurationUpdatePack updatePack, DelegateStatusUpdate statusListener) at Microsoft.VisualStudio.TestTools.AgentConfigUI.AgentConfigUI. ConfigureWorker_DoWork(Object sender, DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker. OnDoWork(DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker. WorkerThreadStart(Object argument) E, 2009/11/20, 14:35:23.255, Failed to apply user account changes. |
Possible cause(s) |
On a Windows 7 machine, when you log in with a local user account, the test agent configuration tool fails to configure the user account (as seen in your case), when it tries to authenticate with the test controller. |
Resolution |
Here is the work around: · Enable the local ‘Administrator’ account on both the test agent and test controller machines (if it is disabled), and make sure the passwords match. · Log in to the test agent machine using the Administrator account. · Launch the test agent configuration tool. Make any changes to the configuration (auto logon, etc). Note that you can run the test agent as agentsvc– you just have to invoke the configuration tool as with .\Administrator · Hit on Apply Settings. Make sure that the configuration goes thru’ without errors. · If you have configured agent as an interactive process, log off and log in as the labsvc account for the agent to start. |
Title |
3.7. Error in starting the test run: Build directory of the test run is not specified or does not exist. |
Version |
Beta 2, RC |
Operating systems |
All |
Symptoms and impact |
When you start the automated test runs using Microsoft Test and Lab Manager or from the build-deploy-test workflow, the test run fails with the error: Build directory of the test run is not specified or does not exist. |
Possible cause(s) |
1. The account under which test controller is running does not have read permission on the build directory. (The build directory is same as the build drop location of build associated with this test run.) 2. The build directory corresponding to the build associated with the test plan does not exist. By default, only last 10 successful builds are archived. So, if an older build is associated with the test plan, it is likely to have been deleted. |
Resolution |
Make sure the build directory exists and the test controller service account has read permission on it. If the build is deleted, then go to the test plan properties (using Microsoft Test and Lab Manager) and update the build number associated with it. |
Title |
3.8. Testing capability fails for the environment with the error "TF276055: The machine is not ready to run tests because of the following error: Unable to connect to the controller on <controller_name:6901>. The agent can connect to the controller but the controller cannot connect to the agent because of following reason: A connection attempt failed because the connected party did not respond properly after a period of time, or established connection failed because connected host has failed to respond ." |
Version |
Beta 2, RC |
Operating systems |
All |
Symptoms and impact |
The testing capability is not ready for the environment with the following error, as the test agent fails to communicate to the test controller: |
Possible cause(s) |
This means that the connection from the test agent (running on the virtual machine) to the test controller works fine, but the connection from the test controller to the test agent does not work properly. Possible reasons are: 1. A firewall is blocking the connection from test controller to test agent.
2. If the virtual machine running the test agent is domain joined, it has lost the trust with the domain controller, possibly because you restored to an old snapshot and the machine password had renewed. To check this, log-off from the machine and try to login with a domain account. If this is the case, you will be blocked from logging in. |
Resolution |
1. Make sure the firewall exception for test agent service (or port 6910) is present on the test agent machine, for the network profile it is connected to. Another way to test this is to run: 'telnet <agentmachine> 6910' from the test controller machine and see if the connection is successful. If not, contact your system administrator and resolve problems with firewall.
2. Log in as local Administrator. Un-join the machine from domain and re-join it. Note: To avoid this problem with old snapshots, you can disable machine password expiry on your virtual machines before taking a snapshots. Find more information here: https://blogs.technet.com/askds/archive/2009/02/15/test2.aspx |
Title |
3.9. The test agent process fails to start with the error: Test agent is not configured with the current account |
Version |
Beta 2, RC |
Operating systems |
All |
Symptoms and impact |
The testing capability on a virtual environment fails with message : TF267066: Test agent is not running on the machine. Click on 'Try Again'. If that does not fix the error, then make sure the following service is running on the machine: Visual Studio Test Agent. Or, if you have configured the test agent to run as an interactive process, log in to the machine with the user account with which the test agent process is configured.; When you log in to the machine, you see the following error: "Test agent is not configured to run interactively under this account. Run the Test Agent Configuration Tool to change the interactive user account." |
Possible cause(s) |
The test agent is configured to run as an interactive process under a local user account - lets say .\localuser1. Then this VM is converted to a template, and the environment created out of this template. The setting for the machine name is retained from the state prior to templatizing the virtual machine. |
Resolution |
1. Confirm that you have logged in as the same user with which you configured the test agent process. 2. Re-configure the test agent using the Visual Studio Test Agent configuration tool |
Title |
3.10. TF267055: The machine is not ready to run tests because of the following error: Cannot connect to the controller on 'aseemb-tc.fareast.corp.microsoft.com:6901'. The lab service account available on this machine is not valid. Either the updated service account is not available on this machine or the service account is not updated on Team Foundation Server. Try to repair the testing capability and then wait several minutes. If you still observe this problem, contact your team project collection administrator. |
Version |
RC |
Operating systems |
All |
Symptoms and impact |
Testing capability is not ready and the machine level error message is showing the above message. |
Possible cause(s) |
Either the password of lab service account has expired or the account itself is not valid anymore.
Note that it may also happen that the password/account is updated on TFS (from Team Foundation Admin Console -> Lab Management Settings -> Service Account) but the machine is not updated and hence does not have the updated password/account.
|
Resolution |
1. Try repairing the testing capability (click on 'Repair testing capability') which will push the latest password/account onto the machine and see whether it works. 2. If step 1 did not work for you, it means that the password/account is not up-to-date on the TFS itself. Then please get in touch with your TFS administrator and ask them to update the lab service account password on TFS. 3. Once the account is updated on TFS, the TFS administrator should run 'TfsLabConfig UpdateServiceAccountOnDeployedEnvironments' command to update the password on all the existing lab machines. In that case, users are not expected to repair the testing capability individually. |
Title |
3.11. TF267055: The machine is not ready to run tests because of the following error: Cannot connect to the controller on '<test_controller_name>:6901'. Either the target name is incorrect or the server has rejected the client credentials. The logon attempt failed. |
Version |
Beta 2, RC |
Operating systems |
All |
Symptoms and impact |
Testing capability is not ready and the machine level error message is showing the above message. |
Possible cause(s) |
1. [RC Only]The lab service account is either not configured on the TFS or it is not yet pushed onto this lab machine.
2. The account under which test agent is running is not known to the test controller machine. Ex: The test agent is running under a local machine account, and the corresponding shadow account (same username/same password) does not exist on the test controller machine. Note: You need not do this if the lab service account is configured.
3. The test agent is running under a local machine account which is shadowed on test controller machine, but while creation of this account on test agent machine, “User must change password at next logon” property was enabled. This essentially means that the password for the shadowed account has actually expired and test agent cannot connect to test controller unless the password is changed or the account is recreated with this property unchecked.
|
Resolution |
1. [RC only] To fix cause #1, configure the lab service account for the project collection using Team Foundation Administration Console and then click on 'Repair Testing Capability' for the environment from Microsoft Test Manager to fix the problem.
In RC build, to fix causes 2 and 3, it is highly recommended to use the lab service account mentioned above. It eliminates the need to create local accounts on the agent and controller machines.
2. If the test agent service is running under a local account, make sure a user with the same user name/password exists on the test agent machine. Also check the properties of the account to make sure 'User must change password at next logon' is disabled. Else, if the test agent service is running under a domain account/Network Service account, make sure that the test controller is able to resolve this account. |
Title |
3.12. TF267055: The machine is not ready to run tests because of the following error: Unable to connect to the controller on '<test_controller_machine>:6901'. Permission denied because this operation can only be performed by members of machine group 'TeamTestAgentService' on machine '<test_controller_machine>' or by accounts having the 'create test run' permission on team project 'MyProject'. Ensure that the agent account has one of these permissions and then try again. |
Version |
RC |
Operating systems |
All |
Symptoms and impact |
Testing capability is not ready and the machine level error message is showing the above message. |
Possible cause(s) |
1. The lab service account is either not configured on the TFS or it is not yet pushed onto this lab machine.
2. The account under which test agent is running does not have permissions on the test controller. |
Resolution |
1. To fix cause #1, configure the lab service account for the project collection and then click on 'Repair Testing Capability' for the environment from Microsoft Test Manager to fix the problem.
To fix causes #2 as well, it is highly recommended to use the lab service account mentioned above. It eliminates the need to manage permissions for individual agent accounts .
2. Add the agent service account to 'TeamTestAgentService' group on the test controller machine or grant 'create test run' permissions to the service account on your team project. |
Title |
3.13. TF267056: The environment is not ready to run tests because Team Foundation Server could not complete the operation to update the following environment: <environment_name>, controller <controller_name>:6901. The test controller returned the following error: TF30063: You are not authorized to access https://<tfs_name>:8080/tfs/DefaultCollection. Make sure that the test controller is online, the firewall on the test controller is not blocking the connection, and the Team Foundation Server has required permissions to connect to the test controller |
Version |
Beta 2, RC |
Operating systems |
All |
Symptoms and impact |
Testing capability is not ready and the environment level error message is showing the above message. |
Possible cause(s) |
1. The password of the account under which the test controller service is running has expired.
2. The account under which test controller is running does not have permissions on the team foundation server. |
Resolution |
1. Try to restart the test controller service. If it fails to start because of logon failure error, then password of the account has expired. To fix it, do the following: - · Open test controller configuration tool and reconfigure the test controller using the latest password. · Go back to client machine on which you have opened MTM or environment viewer and repair the capability.
2. Open the test configuration tool and reconfigure the test controller. This tool will grant the required permissions on the team foundation server. (If you are not unable to do that, you can add the test controller service account to the "project collection test service accounts" group of your team project. |
Title |
3.14. Testing capability on an environment is ‘Ready’ but the test run execution fails and all the tests in the test run go to "Not Executed" state |
Version |
RTM |
Operating systems |
All |
Symptoms and impact |
If your test run execution fails and the tests go to ‘Not Executed state’, have a look at the test run logs (Test run view in Microsoft Test Manager -> View test run log) and check whether it has any error similar to the following one.
"02/23/2010 21:51:03" "Timestamp '2/23/2010 4:20:44 PM'; TestOutcome 'Warning'; Message 'Failed to queue tests for test run ‘account@machine 2010-02-23 08:19:20' on agent 'agentname': Exception has been thrown by the target of an invocation.'."
If yes, then check the test controller logs and see whether it contains an error similar to the following one.
E, 4080, 6, 2010/02/23, 08:20:44.223, VLM13323782\QTController.exe, ControllerExecution: Received exception calling QueueTests on agent <agent_name>: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.InvalidCastException: Object must implement IConvertible. at System.Convert.ChangeType(Object value, Type conversionType, IFormatProvider provider) at System.Runtime.Serialization.FormatterConverter.Convert(Object value, Type type) at System.Runtime.Serialization.SerializationInfo.GetValue(String name, Type type) at Microsoft.VisualStudio.TestTools.Common.SerializationHelper.GetField (Type fieldType, Object defaultValue) at Microsoft.VisualStudio.TestTools.Common.SerializationHelper.GetCollection[T]() at Microsoft.VisualStudio.TestTools.TestTypes.Unit.UnitTestElement..ctor (SerializationInfo info, StreamingContext context) --- End of inner exception stack trace ---
Server stack trace: at System.RuntimeMethodHandle._SerializationInvok (IRuntimeMethodInfo method, Object target, SignatureStruct& declaringTypeSig, SerializationInfo info, StreamingContext context) at System.Runtime.Serialization.ObjectManager.CompleteISerializableObject (Object obj, SerializationInfo info, StreamingContext context) at System.Runtime.Serialization.ObjectManager.FixupSpecialObject(ObjectHolder holder) at System.Runtime.Serialization.ObjectManager.DoFixups() at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize (HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage) at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage) at System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage (String objectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel securityLevel) at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage (IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, Stream& responseStream)
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.VisualStudio.TestTools.Agent.IAgentObject.QueueTests (TestRun run, FileCopyService fileCopyService, Dictionary`2 agentSettings) at Microsoft.VisualStudio.TestTools.Agent.RemoteAgentObjectWrapper. <>c__DisplayClass17.<QueueTests>b__16(IAgentObject agent) at Microsoft.VisualStudio.TestTools.Execution.RemoteObjectContainer`1. InvokeAsRemoteUser(Action`1 invoke) at Microsoft.VisualStudio.TestTools.Agent.RemoteAgentObjectWrapper.QueueTests (TestRun run, FileCopyService fileCopyService, Dictionary`2 agentSettings) at Microsoft.VisualStudio.TestTools.Controller.ControllerExecution.QueueTests (AgentMachine agent, AgentLoadDistributor loadDistributor, Int32 totalAgentCount) |
Possible cause(s) |
This error is observed if there is a mismatch in the version of test agent and test controller. If your test controller is RC version and test agent is RTM or vice versa, then you can observe this issue. |
Resolution |
Make sure the test agent and the test controller are of the same version and upgrade the necessary components (test agent or test controller) to RTM version. |
4. Errors in workflow capability and application deployment
Title |
4.1. The status of workflow integration capability is Ready, still lab workflow hangs in 'Waiting for workflow capability to be ready' step and does not continue. |
Version |
Beta 2 |
Operating systems |
All |
Symptoms and impact |
- The workflow capability on a virtual environment is ‘Ready’. When you queue a workflow to deploy an application on this environment, the workflow hangs forever in the ‘Waiting for workflow capability to be ready’ step. - At this stage, you cannot continue and do not know where the problem is. |
Possible cause(s) |
- One cause for this problem is that the firewall exceptions are not configured correctly on the virtual machine(s) in the environment, especially if the network connection you use belongs to ‘Public’ profile. |
Resolution |
- Connect to the virtual machine(s) in the environment using Microsoft Environment Viewer and check if the network profile is ‘Public’. - If yes, then launch firewall.msc and check 1. If the network type on the virtual machine(s) is "Public" and 'File and Printer sharing' firewall exception is enabled for public profile. The workaround is to either change the network type to "Private" or enable 'File and Printer Sharing' firewall exception. |
Title |
4.2. Workflow capability status is stuck in 'Configuring' state forever |
Version |
RC |
Operating systems |
All |
Symptoms and impact |
The workflow capability for the environment gets stuck in 'Configuring…' state. When you look at the detailed messages, the machine level message reads: "TF266026: Team Foundation Server is configuring the workflow capability on this virtual machine. If this message persists, click 'Repair Workflow Capability' and make sure the account under which the following service is running is a member of the Administrators group on the machine: Visual Studio Team Foundation Build Service Host." |
Possible cause(s) |
1. The following machines are not able to connect to each other using the fully qualified domain names: build agent, build controller and TFS 2. If the virtual machine running the build agent is domain joined, it has lost the trust with the domain controller, possibly because you restored to an old snapshot and the machine password had renewed. To check this, log-off from the machine and try to login with a domain account. If this is the case, you will be blocked from logging in. 3. IPSEC is enabled on your network, this is blocking the calls from the virtual machine (in a different domain or workgroup) to the TFS machine or to the build controller machine. |
Resolution |
Wait for about 5 minutes. If the message persists, as suggested in the message, do the following: a. Click 'Repair Workflow Capability' and see if it fixes the problem b. Log in to the virtual machine and make sure the build service is running either under the Local System account or an account that is local administrator. If these steps do not fix the problem, then do the following to fix this error: a. For cause #1, verify you have two way network connectivity between the build agent -> TFS and build agent -> build controller machines. Try pinging the other two machines from each of the machines, using fully qualified domain names for machines which are domain joined. If ping doesnt work, the cause might be a problem in your network connectivity or your DNS server cannot resolve the FQDN of the other machines. Contact your IT administrator to fix this problem. b. For cause #2, log in as local administrator. un-join the machine from domain and re-join it. Note: To avoid this problem with old snapshots, you can disable machine password expiry on your virtual machines before taking a snapshots. Find more information here: https://blogs.technet.com/askds/archive/2009/02/15/test2.aspx c. For cause #3, contact your IT administrator to enable IPSEC exception for your TFS machine and build controller machine. |
Title |
4.3. Issues with workflow capability and running workflows after Beta 2 to RC upgrade |
Version |
Beta 2 To RC upgrade |
Operating systems |
All |
Symptoms and impact |
1. When the build controller and TFS is upgraded from Beta2 to RC or from Beta2 to RTM, the status of workflow integration in active virtual environments will become "Unknown". This problem is not applicable for RC to RTM upgrade.
2. Build agent registration complains 'A build service host already exists for computer' post upgrade with the following error: "TF266030: The build service host for this virtual machine is not registered with Team Foundation Server. Click 'Try Again'. Additional Information: TF266014: The machine is not ready to run workflows because of the following Team Foundation Server error: A build service host already exists for computer <computer_name>. Specify a different computer name and try again.
3. Execution of a Lab end to end workflow definition which was created in Beta 2 fails post upgrade to RC or RTM, with the following error: TF215097: An error occurred while initializing a build for build definition \Beta2-21006.01\Muthuk-Beta2-BD: The build process failed validation. Details: Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "LabWorkflowParameters.TestParameters.RunTest = True". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "TestResults.PassedTests <> TestResults.TotalTests". 'TestResults' is not declared. It may be inaccessible due to its protection level. 'TestResults' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "(LabWorkflowParameters.BuildDetails.IsTeamSystemBuild = True AndAlso LabWorkflowParameters.BuildDetails.QueueNewBuild = True) Or (LabWorkflowParameters.DeploymentDetails.DeploymentNeeded = True)". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "String.Format("{0}", BuildDetail.BuildNumber)". 'BuildDetail' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "LabWorkflowParameters.DeploymentDetails.DeploymentNeeded = True". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "LabWorkflowParameters.DeploymentDetails.TakePostDeploymentSnapshot = True". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "String.Format("{0}_{1}", BuildDetail.BuildDefinition.Name, BuildDetail.BuildNumber)". 'BuildDetail' is not declared. It may be inaccessible due to its protection level. 'BuildDetail' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "String.IsNullOrEmpty(LabWorkflowParameters.DeploymentDetails.PostDeploymentSnapshotPath) = False". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "LabWorkflowParameters.DeploymentDetails.PostDeploymentSnapshotPath". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "String.IsNullOrEmpty(LabWorkflowParameters.DeploymentDetails.PostDeploymentSnapshotName) = False". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "String.Format("{0}_{1}", LabWorkflowParameters.DeploymentDetails.PostDeploymentSnapshotName, BuildDetail.BuildNumber)". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. 'BuildDetail' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "scriptDetails.AgentSpec". 'scriptDetails' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "LabWorkflowParameters.DeploymentDetails.Scripts". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "LabWorkflowParameters.EnvironmentDetails.RevertToSnapshot = True". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "LabWorkflowParameters.EnvironmentDetails.SnapshotName". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "LabWorkflowParameters.EnvironmentDetails.Disposition = Microsoft.TeamFoundation.Lab.Client.LabEnvironmentDisposition.Active". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. 'TeamFoundation' is not a member of 'Microsoft'. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "LabWorkflowParameters.EnvironmentDetails.HostGroupName". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "BuildDetail.TeamProject". 'BuildDetail' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "LabWorkflowParameters.EnvironmentDetails.LabEnvironmentName". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "LabWorkflowParameters.EnvironmentDetails.LabLibraryShareName". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "BuildDetail.TeamProject". 'BuildDetail' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "LabWorkflowParameters.EnvironmentDetails.HostGroupName". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "Microsoft.TeamFoundation.Build.Common.DeploymentInformationTypes.Deploy". 'TeamFoundation' is not a member of 'Microsoft'. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "String.Format("Lab environment: {0}", LabWorkflowParameters.EnvironmentDetails.LabEnvironmentName)". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "If(LabWorkflowParameters.EnvironmentDetails.Disposition = Microsoft.TeamFoundation.Lab.Client.LabEnvironmentDisposition.Active, LabWorkflowParameters.EnvironmentDetails.LabEnvironmentName, String.Format("{0}_{1}", LabWorkflowParameters.EnvironmentDetails.NewLabEnvironmentName, BuildDetail.BuildNumber))". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. 'TeamFoundation' is not a member of 'Microsoft'. 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. 'BuildDetail' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "LabWorkflowParameters.BuildDetails.IsTeamSystemBuild = True AndAlso LabWorkflowParameters.BuildDetails.QueueNewBuild = True". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "LabWorkflowParameters.BuildDetails.BuildUri". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "ChildBuildDetail.Uri". 'ChildBuildDetail' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "BuildDetail.TeamProject". 'BuildDetail' is not declared. It may be inaccessible due to its protection level. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "LabWorkflowParameters.BuildDetails.BuildDefinitionName". 'LabWorkflowParameters' is not declared. It may be inaccessible due to its protection level. |
Possible cause(s) |
1. #1 is caused by the changes in tracking workflow enabled lab environments in TFS database between Beta2 and RC/RTM.
2. #2 is due to a bug identified post Beta2 in upgrade steps.
3. #3 is caused by the changes in Lab process template LabDefaultTemplate.xml between Beta 2 and RC/RTM. |
Resolution |
1. To fix #1, upgrade the build agent on the machines in the virtual environment to RC and click 'Repair workflow capability.
2. To fix #2, run Build Agent registration script; LabProjectCollectionUpgradeAddition.ps1 available at https://blogs.msdn.com/lab_management/attachment/9960661.ashx after the upgrade. Follow the guidelines in Lab upgrade guidelines for running this script: https://blogs.msdn.com/lab_management/archive/2010/02/08/lab-management-2010-beta2-to-rc-upgrade-guide.aspx
3. To fix #3, replace (or reconcile) your Beta 2 Lab process templates with those that ship in the RC/RTM. Follow the TeamLab Upgrade blog guidelines to update your process template. https://blogs.msdn.com/lab_management/archive/2010/02/08/lab-management-2010-beta2-to-rc-upgrade-guide.aspx
|
Title |
4.4. Cannot connect to the Team Foundation Server at 'https://<tfs_machine>:8080/tfs/DefaultCollection'. The lab service account available on this machine is not valid. Either the updated service account is not available on this machine or the service account is not updated on Team Foundation Server. Try to repair the workflow capability and then wait several minutes. If you still observe this problem, contact your team project collection administrator. |
Version |
RC |
Operating systems |
All |
Symptoms and impact |
Workflow capability is not ready and the machine level error message is showing the above message. |
Possible cause(s) |
Either the password of lab service account has expired or the account itself is not valid anymore.
Note that it may also happen that the password/account is updated on TFS but the machine is not updated and does not have the updated password/account. |
Resolution |
1. Click 'Repair Workflow Capability' which will push the latest password/account onto the machine and see whether it works. 2. If step 1 did not work for you, it means that the password/account is not uptodate on the TFS itself. Then please get in touch with your TFS administrator and ask them to update the lab service account password on TFS using the Team Foundation Administration Console. 3. Once the account is updated on TFS, TFS administrator should run 'TfsLabConfig UpdateServiceAccountOnDeployedEnvironments' command to update the password on all the existing lab machines. In that case, users are not expected to repair the workflow capability individually. |
Title |
4.5. The build service is unable to connect to the following Team Foundation Server application-tier at 'https://<tfs_machine>:8080/tfs/DefaultCollection'. Exception type: Microsoft.TeamFoundation.TeamFoundationServerUnauthorizedException. Exception Message: TF30063 You are not authorized to access https://<tfs_machine>:8080/tfs/DefaultCollection |
Version |
Beta2/RC |
Operating systems |
All |
Symptoms and impact |
Workflow capability is not ready and the machine level error message is showing the above message. |
Possible cause(s) |
1. The lab service account is either not configured on the TFS or it is not yet pushed onto this lab machine.
2. The account under which build agent is running does not have permissions on the TFS. |
Resolution |
1. To fix #1, configure the lab service account for the project collection and then click on 'Repair Workflow Capability' for the environment from Microsoft Test Manager to fix the problem.
To fix causes #2 as well, it is highly recommended to use the lab service account mentioned above. It eliminates the need to manage permissions for individual agent accounts.
2. Add the build agent service account in 'Project Collection Build Service Accounts' group. Please note that this will grant permissions on the sources as well which are not required if you are using this build agent only for deployment. To remove those permissions, you can deny those permissions individually for each project (using Tf permission..) or use lab service account which will take care of this. |
Title |
4.6. Build-Deploy-Test workflow (created using lab template) fails with error “ There are no test cases matching the criteria specified. Use Microsoft Test Manager to view the test cases.” |
Version |
Beta 2, RC |
Operating systems |
All |
Symptoms and impact |
Running test cases using the build-deploy-test workflow (created using lab template) fails with the error: There are no test cases matching the criteria specified. Use Microsoft Test Manager to view the test cases. |
Possible cause(s) |
The issue occurs when are there no test cases within the selected suites applicable for the selected configuration. For instance, assume a test plan has 2 test configurations associated with it - 'C1' and 'C2'. In suite 'Suite1', there are 2 test cases for which only 'C1' is applicable. If 'C2 ' is selected in lab workflow parameter wizard (for the build definition), the above error occurs. |
Resolution |
Open the workflow parameter wizard from the build definition for build-deploy-test workflow. In the testing page, select a test configuration which has one or more test cases associated with it. You can use the test case list view under the 'Test' tab in Testing Center of Microsoft Test Manager to find the number of test cases applicable for a test configuration. |
Comments
Anonymous
January 10, 2012
Great doc.Anonymous
January 10, 2012
Great doc. , actually i'm going to set up Lab management in my org. ,Request you to update the doc. if any. and it would be great if you can help by sharing the detailed steps on how to set the environment, i'm requesting you to share it with us as l love to learn & follow the Masters advice.Anonymous
June 10, 2012
Cool, what I'd really like to see is what does work. That I have not been able to find. 80 hours into it, I'm going back to Jenkins.Anonymous
February 03, 2014
Hi Guys Actually I am trying to create a test environment in Microsoft Lab center but at final step when I click on verify,- first 2 verification's are passing but the remaining two are not at all passing and system is throwing the error as "Team Foundation sever has not responded to your request in the allowed time." I tried many times but I couldn't find where the problem is. Some one Please assist