locked
Troubleshooting Guide for Visual Studio Test Controller and Agent

    דיון כללי

  • Troubleshooting Guide for Visual Studio Test Controller and Agent

    This guide is to help troubleshoot connection issues between Visual Studio Test Controller and Agent as well as remote test execution issues. It gives an overview of main connection points used by Test Controller and Agent and walks through general troubleshooting steps. In the end it provides a list of common errors we have seen and ways to fix them, and a description of tools that can be useful for troubleshooting as well as how to obtain diagnostics information for test execution components.

    We would like to use this guide as running document, please reply to this post to add your comments.

    1. Who should read this

    You should read this guide if:
    • You experience a problem configuring remote Test Agent/Controller, such as:
      • Remote test run fails for unclear reason. This fails for both remote execution and remote collection.
      • Test Agent cannot connect to Test Controller.
    • You want to get diagnostics information to report an issue in Agent/Controller to Microsoft.
    • You want to understand what can potentially break Test Agent/Controller.

    2. Remote Test Execution: connection points

    The following diagram illustrates main connection points between Test Controller, Agent and Client. It outlines which ports are used for incoming and outgoing connections as well as security restrictions used on these ports.

    The technology used to connect remote test execution components is .Net Remoting over Tcp ports. For incoming connections, by default, Test Controller uses Tcp port 6901 and Test Agent uses port 6910. The Client also needs to accept incoming connection in order to get test results from Controller, and, by default, it is using random port for that. For information on how to configure incoming ports, refer to the Tools section in Appendix. For outgoing connections random Tcp ports are used. For all incoming connections Test Controller authenticates calling party and checks that it belongs to specific security group.

    All connectivity issues can be divided into 2 main groups: network issues and security/permission issues.

    2.1. Network/Firewall issues (mainly implied by .Net Remoting technology):

    • Controller :
      • Listens on TCP port 6901 (can be configurable to use different port).
      • Needs to be able to make outgoing connection to Agents and to the Client.
      • Needs incoming “File and Printer sharing” connection open.
    • Agent:
      • Listens on TCP port 6910 (can be configurable to use different port).
      • Needs to be able to make outgoing connection to Controller.
    • Client:
      • Needs to be able to accept incoming calls. Usually you would get Firewall notification when Controller tries to connect to Client 1<sup>st</sup> time. On Windows 2008 Server the notifications are disabled by default and you would need to manually add Firewall exception for Client program (devenv.exe, mstest.exe, mlm.exe) so that it can accept incoming connections.
      • By default, random TCM port is used for incoming connections. If needed, the incoming port can be configured (see the Tools section in Appendix).
      • Needs to be able to make outgoing connection to Controller.

    2.2. Permissions

    There are two scenarios which are different by how Test Controller is operating, and the permissions used by Controller differ depending on the scenario:

    • Test Controller runs as standalone: physical environments (VS2008 or VS2010).
    • Test Controller is connected to TFS server: virtual environments (VS2010 only).

    2.2.1. Permissions: Test Controller not connected to TFS server:

    • To run tests remotely, Client user must belong to either TeamTestControllerUsers, or TeamTestControllerAdmins, or Administrators local group on Controller machine.
    • To manage Controller/Agent, Client user must belong to TeamTestControllerAdmins or Administrators local group on Controller machine.
    • Agent service account must belong to either TeamTestAgentService or Administrators local group on Controller machine.
    • Controller service account must belong to either TeamTestControllerUsers or Administrators local group on Controller machine.
    • Service accounts with empty/no passwords are not supported.

    2.2.1. Permissions: Test Controller not connected to TFS server:

    Coming soon.

    2.3. Connection Points: Summary

    Review of the connections gives high level picture of what can fail in Test Controller/Agent connectivity. At this point you can already have a clear idea which requirement is not met for your specific scenario. Next section provides step-by-step troubleshooting.

    3. Step-by-step troubleshooting

    Let’s walk through general troubleshooting procedure for Test Controller/Agent connection issues. For simplicity we’ll do that in step-by-step manner.

    Before following these steps you may take a look at Known Issues section in the Appendix to see if your issue is one of known common issues.

    The troubleshooting is based on the key connection points and in essence involves making sure that:

    • The services are up and running.
    • Permissions are set up correctly.
    • Network connectivity/Firewall issues.

    There are two scenarios which are different by how Test Controller is operating, and troubleshooting steps differ depending on the scenario; hence we will consider each scenario separately:

    • Test Controller runs as standalone: physical environments (VS2008 or VS2010).
    • Test Controller is connected to TFS server: virtual environments (VS2010 only).

    3.1. Step-by-step troubleshooting: VS2008 or VS2010 physical environments

    Pre-requisites. Make sure you have necessary permissions.

    • Depending on what you need to troubleshoot, you may need Administrator permissions on Agent and/or Controller machines.

    Step 1. Make sure that the Controller is up and running and Client can connect to Controller.

    • Use Visual Studio or Microsoft Test Manager (see Tools section above) to view Controller status.
    • If you can’t connect to Controller, make sure that Controller service is running:
      • On Controller machine (you can also do that remotely) re/start controller service (see Tools section in Appendix).
    • (if you still can’t connect) On Controller machine make sure that it can accept incoming connections through Firewall
      • Open port 6901 (or create exception for the service program/executable).
      • Add Firewall Exception for File and Printer Sharing.
    • (if you still can’t connect) make sure that the user you run the Client under has permissions to connect to Controller:
      • On Controller machine, add Client user to the TeamTestControllerAdmins local group.
    • (if you still can’t connect) On Client machine make sure that Firewall is not blocking incoming and outgoing connections:
      • Make sure that there is Firewall exception for Client program (devenv.exe, mstest.exe, mlm.exe) so that it can accept incoming connections.
      • Make sure that Firewall is not blocking outgoing connections.
    • (if you still can’t connect)
      • VS2010 only: the simplest at this time is to re-configure the Controller:
        • On Controller machine log on as local Administrator, run the Test Controller Configuration Tool (see Tools section above) and re-configure the Controller.
        • All steps should be successful.
    • (if you still can’t connect) Restart Controller service (see the Service Management commands section in Tools section above)

    Step 2. Make sure that there is at least one Agent registered on Controller.

    • Use Visual Studio (Manage Test Controllers dialog) or Microsoft Test Manager (see Tools section in the Appendix) to view connected Agents.
    • If there are no Agents on the Controller, connect the Agent(s).
      • VS2010 only:
        • On Agent machine log in as user that belongs to TeamTestAgentServiceAdmins.
        • On Agent machine open command line and run the Test Agent Configuration Tool (see Tools section in the Appendix).
        • Check ‘Register with Test Controller’, type controller machine name and click on ‘Apply Settings’.
      • VS2008 only:
        • In Visual Studio (Manage Test Controllers dialog) click on Add Agent.
        • You may need to restart the Agent service.

    Step 3. Make sure that Agent is running and Ready (for each Agent)

    Agent status can be one of: Ready/Offline (temporary excluded from Test Rig)/Not Responding/Running Tests.

    • Use Visual Studio or Microsoft Test Manager (see Tools section in the Appendix) to check Agent status.
    • If one of the Agents is not shown as Ready, make sure that Agent service is running:
      • On Agent machine (you can also do that remotely) re/start Agent service (see Tools section in the Appendix).
    • (if Agent is still not Ready)
      • VS2010 only: the simplest at this time is to re-configure the Agent:
        • On Agent machine log on as local Administrator and run the Test Agent Configuration Tool (see Tools section in the Appendix) and re-configure the Agent.
        • All steps should be successful.
    • (if Agent is still not Ready)
      • If Agent is shown as Offline, select it and click on the Online button.
      • On Agent machine make sure that agent service can accept incoming connections on port 6901 (if Firewall in on, there must be Firewall exception either for the port or for the service program/executable).
      • Make sure that Agent service account belongs to the TeamTestAgentService on the Controller.
        • On Controller machine use Computer Management->Local Groups to add Agent user to the TeamTestAgentService group.
        • Restart services: Stop Agent service/Stop Controller service/Start Controller service/Start Agent service.
      • Make sure that Agent machine can reach Controller machine (use ping).
      • Restart Agent service (see the Service Management commands section in Tools section above).

    Step 4. If all above did not help, it is time now to analyze diagnostics information.

    • (VS2010 only) Agent/Controller services by default log errors into Application Event Log (see Tools section in the Appendix).
      • Check for suspicious log entries there.
    • Enable tracing – see Diagnostics section above.
      • Get trace for the components involved in your scenario, some/all of:
        • Controller
        • Agent
        • Client
        • Test Agent/Controller Configuration Tool
      • Make sure that Controller/Agent service accounts have write access to trace files.
      • Check for entries starting with “[E”.

    Step 5. Take a look at Known Issues section in the Appendix to see if your issue is similar to one of those.

    Step 6. Collect appropriate diagnostics information and send to Microsoft (create Team Test Forum post or Microsoft Connect bug).

    3.2. Troubleshooting Guide: TFS/virtual environments (VS2010 only)

    Coming soon.

    3.3. Step-by-Step Troubleshooting: Summary

    This concludes the troubleshooting steps. If this guide was not helpful in resolving your issue, let us know.

    4. References

    The following is a list of useful information sources related to Test Agent/Controller troubleshooting.

    Appendix 1. Tools

    The following tools can be useful for remote execution/Agent/Controller troubleshooting:

    • Visual Studio: Premium (VS2010 only), Team Test Edition (VS2008 only).
      • Manage Test Controllers dialog (Main menu->Test->Manage Test Controllers): see status of Controller and all connected Agents, add/remove Agents to Controller, restart Agents/the whole test rig, bring Agents online/offline, configure Agent properties.
      • Note: on VS2008 this dialog is called Administer Test Controllers.
    • Run tests remotely:
      • VS2008: update Test Run Configuration to enable remote execution (Main Menu->Test->Edit Test Run Configurations->(select run config)->Controller and Agent->Remote->provide Test Controller name), then run a test.
      • VS2010: update Test Settings to use remote execution role (Main Menu->Test->Edit Test Settings -> (select test settings)->Roles->Remote Execution), then run a test.
    • Microsoft Test Manager (VS2010 only)
      • Lab Center->Controllers: see status of Controller and all connected Agents, add/remove Agents to Controller, restart Agents/the whole test rig, bring Agents online/offline, configure Agent properties. Note that Lab Center only shows controllers that are associated with this instance of TFS.
    • Test Controller Configuration Tool (TestControllerConfigUI.exe, VS2010 only):
      • It is run as last step of Test Controller setup.
      • You can use it any time after setup to re-configure Controller. The tool has embedded diagnostics which makes it easier to detect issues.
      • The tool is located by default in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE.
    • Test Agent Configuration Tool (TestAgentConfigUI.exe, VS2010 only):
      • It is run as last step of Test Agent setup.
      • You can use it any time after setup to re-configure Agent. The tool has embedded diagnostics which makes it easier to detect issues.
      • The tool is located by default in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE.
    • Diagnostics information
      • Both Agent and Controller can be configured to trace diagnostics information (from errors to verbose) to Application Event Log or trace file. Clients can also be configured to trace (from errors to verbose) to trace file.
      • Tracing can be enabled via .config file or registry (VS2010 only), registry wins. Choose the method that is more convenient for your scenario.
      • Enable tracing via .config file(s):
        • One of the advantages of using config files is that you can enable tracing for each component independently and using trace settings specific only to this component.
        • For Controller Service/Agent Service/Agent Process, you need the following sections in the corresponding .config file (qtcontroller.exe.config, qtagentservice.exe.config, qtagent.exe.config, qtagent32.exe.config which by default are located in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE):
          • Inside the <appSettings> section:

            <add key="CreateTraceListener" value="yes"/>

          • Inside the <configuration> section (note: “Verbose” is equivalent to “4”):

            <system.diagnostics>
              <switches>
                <add name="EqtTraceLevel" value="Verbose" />
              </switches>
            </system.diagnostics>

          • Trace files (by default these are created in the same directory as where controller/agent service/process is located, C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE):
            • Controller: vsttcontroller.log
            • Agent Service: vsttagent.log
            • Agent Process: VSTTAgentProcess.log
            • Important: please make sure that the location is writable by controller/agent service/process.
        • For Client, add the following section to appropriate .config file (devenv.exe.config, mstest.exe.config, mlm.exe.config):
          • Inside the <configuration> section (note: “Verbose” is equivalent to “4”):

            <system.diagnostics>
              <trace autoflush="true" indentsize="4">
                <listeners>
                  <add name="EqtListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="C:\EqtTrace.log" />
                </listeners>
              </trace>
              <switches>
                <add name="EqtTraceLevel" value="Verbose" />
              </switches>
            </system.diagnostics>

          • Trace file: trace will go to the file specified by the initializeData attribute.
            • Important: please make sure that the location is writable for the user you run devenv/mstest under.
      • Enable tracing via registry (VS2010 only):
        • One of the advantages of using registry is that you can enable tracing for all components using just one setting, you don't have to modify multiple configuration files.
        • Create a file with the following content, rename it so that it has .reg extension and double click on it in Windows Explorer:

          Windows Registry Editor Version 5.00
          [HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\EnterpriseTools\QualityTools\Diagnostics]
          "EnableTracing"=dword:00000001
          "TraceLevel"=dword:00000004
          "LogsDirectory"="C:\"

        • Notes:
          • In case of Test Controller/Agent services the HKEY_CURRENT_USER is the registry of the user the services are running under.
          • TraceLevel: 0/1/2/3/4 = Off/Error/Warning/Info/Verbose.
          • LogsDirectory is optional. If that is not specified, %TEMP% will be used.
          • Trace file name is <Process name>.EqtTrace.log, e.g. devenv.EqtTrace.log.
      • Tracing from Test Controller Configuration Tool and Test Agent Configuration Tool:
        • To get trace file, click on Apply, then in the “Configuration Summary” window on the view log hyperlink in the bottom.
      • SysInternals’ DebugView can also be used to catch diagnostics information.
    • Application configuration files
      • Controller, Agent and Client use settings from application configuration files:
        • Controller service: qtcontroller.exe.config
        • Agent service: qtagentservice.exe.config
        • Agent process: qtagent.exe.config (neutral/64bit agent), qtagent32.exe.config (32bit agent).
        • VS: Devenv.exe.config.
        • Command line test runner: mstest.exe.config.
        • By default these files are located in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE.
      • How to configure listening ports:
        • This may be useful in the following scenarios:
          1. Default ports used by Controller/Agent/Client can be used by some other software.
          2. There is firewall between controller and client. In this case you would need to know which port to enable in the firewall so that Controller can send results to the Client.
        • Controller Service: qtcontroller.exe.config:

          <appSettings><add key="ControllerServicePort" value="6901"/></appSettings>

        • Agent Service:

          <appSettings><add key="AgentServicePort" value="6910"/></appSettings>

        • Client: add the following registry values (DWORD). The Client will use one of the ports from this range for receiving data from Controller:

          HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\VisualStudio\10.0\EnterpriseTools\QualityTools\ListenPortRange\PortRangeStart HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\VisualStudio\10.0\EnterpriseTools\QualityTools\ListenPortRange\PortRangeEnd

    • Service Management commands
      • UI: Start->Computer->Right-click->Manage-> Services and Applications->Services
        • § Visual Studio Test Controller
        • Visual Studio Test Agent
      • Command line: net start/net stop: use to start/stop Agent/Controller
        • net start vsttcontroller
        • net start vsttagent
    • Windows Firewall
      • Start->Control Panel->Windows Firewall.
    • IP Security Policy
      • Start->Run->rsop.msc (on both Agent and Controller machines)
      • Go to Computer configuration->windows settings->security settings->ip security policies
      • Check if there are any policies that may prevent connections. By default there are no policies at all.
    • Computer Management
      • Local Groups
        • Start->Computer->Manage->Local Users and Groups->Groups.
      • Event Log (Application)
        • Start->Computer->Manage->Event Viewer->Windows Logs->Application.
    • Ping
      • You can use ping to make sure that general TCP/IP network connectivity works.
    • Telnet
      • You can use telnet to check that you can connect to Agent/Controller, i.e. Firewall is not blocking, etc.
        • telnet <ControllerMachineName> 6901
        • telnet <AgentMachineName> 6910
    • Visual Studio Team System – Test Forum.
    • Microsoft Connect – report bugs/suggestions.

    Appendix 2. Known issues

    The following is a list of known issues and suggested resolutions for them.

    2.1. The message or signature supplied for verification has been altered (KB968389)

    Symptom: Agent cannot connect to Controller.

    Affected scenarios: Windows XP/Windows 7 connecting to Windows 2003 Server.

    Additional information:

    • EventL Log (Agent): The message or signature supplied for verification has been altered.
    • Trace file (Agent) contains:

      I, <process id>, <thread id>, <date>, <time>, <machine name>\QTAgentService.exe, AgentService: The message or signature supplied for verification has been altered.
      I, <process id>, <thread id>, <date>, <time>, <machine name>\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: An error occurred while processing the request on the server: System.IO.IOException: The write operation failed, see inner exception. ---> System.ComponentModel.Win32Exception: The message or signature supplied for verification has been altered
      at System.Net.NTAuthentication.DecryptNtlm(Byte[] payload, Int32 offset, Int32 count, Int32& newOffset, UInt32 expectedSeqNumber)
      at System.Net.NTAuthentication.Decrypt(Byte[] payload, Int32 offset, Int32 count, Int32& newOffset, UInt32 expectedSeqNumber)
      at System.Net.Security.NegoState.DecryptData(Byte[] buffer, Int32 offset, Int32 count, Int32& newOffset)
      at System.Net.Security.NegotiateStream.ProcessFrameBody(Int32 readBytes, Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
      at System.Net.Security.NegotiateStream.ReadCallback(AsyncProtocolRequest asyncRequest)
      --- End of inner exception stack trace ---
      at System.Net.Security.NegotiateStream.EndRead(IAsyncResult asyncResult)
      at System.Runtime.Remoting.Channels.SocketHandler.BeginReadMessageCallback(IAsyncResult ar)
      Server stack trace:
      at Microsoft.VisualStudio.TestTools.Controller.AgentMachine.VerifyAgentConnection(Int32 timeout)

    Root cause: You installed KB968389 either via Windows Update or manually.

    Resolution: uninstall KB968389 from Start->Control Panel->Programs and Features->View Installed Updates.

    2.2. Controller/Agent in untrusted Windows domains or one is in a workgroup and another one is in domain.

    Symptom: Agent cannot connect to Controller.

    Affected scenarios: Test Controller and Agent are not in the same Windows domain. They are either in untrusted domains or one of them is in a domain and another one is in a workgroup.

    Additional information:

    • Trace file (Agent) contains:

      W, <process is>, <thread id>, <date>, <time>, <mMachine name>\QTController.exe, Exception pinging agent <agent name>: System.Security.Authentication.AuthenticationException: Authentication failed on the remote side (the stream might still be available for additional authentication attempts). ---> System.ComponentModel.Win32Exception: No authority could be contacted for authentication
      Server stack trace:
      at System.Net.Security.NegoState.ProcessReceivedBlob(Byte[] message, LazyAsyncResult lazyResult)
      at System.Net.Security.NegotiateStream.AuthenticateAsClient(NetworkCredential credential, ChannelBinding binding, String targetName, ProtectionLevel requiredProtectionLevel, TokenImpersonationLevel allowedImpersonationLevel)
      at System.Net.Security.NegotiateStream.AuthenticateAsClient(NetworkCredential credential, String targetName, ProtectionLevel requiredProtectionLevel, TokenImpersonationLevel allowedImpersonationLevel)
      at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.CreateAuthenticatedStream(Stream netStream, String machinePortAndSid)
      at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)

    Root cause: Due to Windows security, Agent cannot authenticate to Controller, or vice versa.

    Resolution:

    • The simplest is to use Workgroup authentication mode:
      • Mirror user account on Controller and Agent: create a user account with same user name and password on both Controller and Agent machine.
      • Use mirrored user account to run Controller and Agent services under this account.
      • If you are using VS2010 RC+ version (i.e. RC or RTM but not Beta2), add the following line to the qtcontroller.exe.config file under the <appSettings> node:

        <add key="AgentImpersonationEnabled" value="no"/>

    • Restart Controller/Agent services (see Tools section in the Appendix).
    • Make sure there is no IP Security Policy that prevents the connection (see IP Security Policy under Tools section in the Appendix).
      • By default for domain machines Windows uses domain (Kerberos) authentication, but if it fails it will fall back to workgroup (NTLM) authentication. This behavior can be and often is altered by IP Security policies, for instance, there could be a policy to block connections from machines which do not belong to the domain.
    • Restart or re-configure Controller and Agent.

    Thanks,
    Michael Koltachev,
    Visual Studio Team Test

    יום חמישי 25 מרץ 2010 19:06

כל התגובות

  • I've tried to configure VS2010 (RTM) as per your guide, to restrict the range of ports used to communicate with the controller:

    HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\VisualStudio\10.0\EnterpriseTools\QualityTools\ListenPortRange\PortRangeStart

    HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\VisualStudio\10.0\EnterpriseTools\QualityTools\ListenPortRange\PortRangeEnd

    After setting the key range and attempting to initiate a load test, the test remains in a pending state. Checking netstat output, the client is listening on a random selection of ports and the controller is left with connections showing SYN_SENT on matching ports (i.e. the connection is being blocked by the firewall as its not using the restricted range I set in the registry).

    I resorted to using Process Monitor to check VS is getting the values from the registry but it appears they aren't being read. Filtering on 'ListenPortRange' I see the following:


    RegOpenKey    HKU\S-1-5-21-1447049342-4221093051-35256453-1016\Software\Microsoft\VisualStudio\10.0_Config\EnterpriseTools\QualityTools\ListenPortRange    NAME NOT FOUND    Desired Access: Read

    RegOpenKey    HKU\S-1-5-21-1447049342-4221093051-35256453-1016\Software\Microsoft\VisualStudio\10.0_Config\EnterpriseTools\QualityTools\ListenPortRange    NAME NOT FOUND    Desired Access: Read

    RegOpenKey    HKU\S-1-5-21-1447049342-4221093051-35256453-1016\Software\Microsoft\VisualStudio\10.0_Config\EnterpriseTools\QualityTools\ListenPortRange    NAME NOT FOUND    Desired Access: Read

    Assuming there was an error in the guide, I created the keys as shown above and tried again to start a test.

    RegOpenKey    HKU\S-1-5-21-1447049342-4221093051-35256453-1016\Software\Microsoft\VisualStudio\10.0_Config\EnterpriseTools\QualityTools\ListenPortRange    SUCCESS    Desired Access: Read

    RegOpenKey    HKU\S-1-5-21-1447049342-4221093051-35256453-1016\Software\Microsoft\VisualStudio\10.0_Config\EnterpriseTools\QualityTools\ListenPortRange    SUCCESS    Desired Access: Read/Write

    RegOpenKey    HKU\S-1-5-21-1447049342-4221093051-35256453-1016\Software\Microsoft\VisualStudio\10.0_Config\EnterpriseTools\QualityTools\ListenPortRange    SUCCESS    Desired Access: Delete

    I checked the registry and as Process Monitor reported, the key had been deleted! Working on the assumption that there was an obscure bug at work, I removed delete permissions from the key for my user account and tried again.

    RegOpenKey    HKU\S-1-5-21-1447049342-4221093051-35256453-1016\Software\Microsoft\VisualStudio\10.0_Config\EnterpriseTools\QualityTools\ListenPortRange    SUCCESS    Desired Access: Read

    RegOpenKey    HKU\S-1-5-21-1447049342-4221093051-35256453-1016\Software\Microsoft\VisualStudio\10.0_Config\EnterpriseTools\QualityTools\ListenPortRange    SUCCESS    Desired Access: Read/Write

    RegOpenKey    HKU\S-1-5-21-1447049342-4221093051-35256453-1016\Software\Microsoft\VisualStudio\10.0_Config\EnterpriseTools\QualityTools\ListenPortRange    ACCESS DENIED    Desired Access: Delete

    RegOpenKey    HKU\S-1-5-21-1447049342-4221093051-35256453-1016\Software\Microsoft\VisualStudio\10.0_Config_5980 \EnterpriseTools\QualityTools\ListenPortRange    NAME NOT FOUND    Desired Access: Read

    RegOpenKey    HKU\S-1-5-21-1447049342-4221093051-35256453-1016\Software\Microsoft\VisualStudio\10.0_Config_5980 \EnterpriseTools\QualityTools\ListenPortRange    NAME NOT FOUND    Desired Access: Read

    RegOpenKey    HKU\S-1-5-21-1447049342-4221093051-35256453-1016\Software\Microsoft\VisualStudio\10.0_Config_5980 \EnterpriseTools\QualityTools\ListenPortRange    NAME NOT FOUND    Desired Access: Read

    So it appears the delete is denied but the client then attempts to read the key from a newly created key branch. This new branch exists in the registry for as long as the test is open in VS and is deleted on close.

    Environment is VS2010 RTM, Windows 7x64, running as a non-admin user. Same behaviour is observed if running VS with elevated permissions (i.e. start VS with runas).

    יום שישי 07 מאי 2010 16:52
  • Mark, thank you for letting us know about this issue.

    The keys under HKCU\Software\Microsoft\VisualStudio\10.0_Config is HKLM VS registry detoured, VS copies the values from HKLM and then uses them from 10.0_Config, when HLKM values change it is supposed to refresh values under 10.0_Config by copying them from HKLM. It seems that this does not always work. So, please try the following:

    - close VS

    - delete the HKCU\Software\Microsoft\VisualStudio\10.0_Config and everything else staring from 10.0_Config

    - start VS

    - try to repro

    Thanks,

    Michael

    יום ראשון 09 מאי 2010 06:55
  • Hi Michael,

    As suggested, I've deleted all 10.0_Config branches, ensured the HKLM keys are correct and tried again. The only ListenPortRange lookups that occur are:

    RegOpenKey    HKU\S-1-5-21-1447049342-4221093051-35256453-1016\Software\Microsoft\VisualStudio\10.0_Config\EnterpriseTools\QualityTools\ListenPortRange    NAME NOT FOUND    Desired Access: Read

    RegOpenKey    HKU\S-1-5-21-1447049342-4221093051-35256453-1016\Software\Microsoft\VisualStudio\10.0_Config\EnterpriseTools\QualityTools\ListenPortRange    NAME NOT FOUND    Desired Access: Read

    RegOpenKey    HKU\S-1-5-21-1447049342-4221093051-35256453-1016\Software\Microsoft\VisualStudio\10.0_Config\EnterpriseTools\QualityTools\ListenPortRange    NAME NOT FOUND    Desired Access: Read

    Same occurs whether using a standard or admin user account.

    יום שני 10 מאי 2010 10:41
  • The log entries are a bit strange: if that was your accout, they should say HKCU. What's the S-1-5-21-1447049342-4221093051-35256453-1016 accout? I guess the fix is to change registry of that account.

    Thanks,
    Michael

    יום שלישי 11 מאי 2010 14:13
  • The log is from running VS under my user account, whereas Process Monitor has to be run as administrator, so the access shows up as HKU rather than HKCU. If I run VS as admin, Process Monitor shows HKCU as expected.
    יום רביעי 12 מאי 2010 10:45
  • I guess the best workaround would be add these registry settings under HKCU\10.0_Config rather than recommended HKLM. Meanwhile I'll try to repro this on my installation.

    Thanks,
    Michael

    יום רביעי 12 מאי 2010 18:37
  • As mentioned in my first post, I tried exactly that but the keys were read and then deleted.
    יום חמישי 13 מאי 2010 20:13
  • Mark, I realized that VS mirrors HKLM\...\10.0 registry into HKCU\...\10.0_Config only for 3 first levels off 10.0. This is sort of edge case. Anyhow, the solution recommened by VS Platform is to use .pkgdef files rather than registry. Please do the following:

    1) Close VS

    2) Create my.pkgdef file under C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\my\ with the following content:
    [$RootKey$\EnterpriseTools\QualityTools\ListenPortRange]
    "PortRangeStart"=dword:00000400
    "PortRangeEnd"=dword:00000401

    3) Start VS

    4) Start regedit.exe and check if new values are now under (32 bit registry) HKCU\...\10.0_Config\EnterpriseTools\QualityTools\ListenPortRange. If they are not there, close VS, remove the 10.0_Config node and start VS again.

    Note that the name of the file and directory does not really matter, what is important that:

    A) The file has extension .pkgdef

    B) It's under C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions directory (could be in a subdirectory of it).

    Let me know how this worked!

    Thanks,
    Michael

    יום שישי 14 מאי 2010 22:20
  • Worked! Many thanks Michael, much appreciated.
    שבת 15 מאי 2010 13:41
  • Running into an issue when I try to configure the 2010 test agent. I'm running on VMWare ESX virtual machines and during the configuration process I'm losing network connectivity when it attempts to Install the Network Emulation driver:

    Configured ACL successfully
    Enabled auto logon for user XX\XXXX successfully
    Installing the Network Emulation driver...

    I can't seem to get to the logs to determine what's going on. Ideas?

     

    יום שלישי 08 יוני 2010 21:01
  • (bump) Still seeing the same issue on VMWare ESX virtual machines...any ideas?

    יום שני 26 יולי 2010 16:56
  • Still having the VMWare issue. Any workarounds?
    יום שלישי 03 אוגוסט 2010 15:34
  • (bump)
    יום שני 09 אוגוסט 2010 14:22
  • (bump)
    יום שני 16 אוגוסט 2010 12:22
  • (weekly bump)  - given that we're still experiencing the problem what next steps can we take to get this issue resolved and working?

    יום שני 23 אוגוסט 2010 12:00
  • (weekly bump). We still have this issue/problem. We've called PSS they say it is a VMWare issue. We called VMWare they say it is a MSFT issue. We had a conference call with both and the issue is currently unresovled/waiting to hear back from PSS. We've spent over $500 between the 2 support calls and no resolution.
    יום שני 30 אוגוסט 2010 15:10
  • Hi.

    Sounds really fantastic..but still having some coding and mailware issues,howe to rectify them.

     

    seeking for help.

     

    thanks:

    Alfred

    יום חמישי 02 ספטמבר 2010 06:06
  • I would like to add a few things.

     

    Windows server 2008R2 (and likely other UAC enabled os's)

    - start position is incorrect, one gets regardless of all settings: "RPC server is unavailable" (this might be due to domain gpo's i expected, but actually not)

    - this is fixed by running VS2010 "run as administrator"

    - then one gets "you do not have the appropriate permissions to perform this action"

    - then adding to the testcontrollermachine\teamtestcontrolleradmins group, AND requiring restart of VS2010 with "run as administrator" WILL allow you to connect.

     

    Never would have got there without this post though. So thanks a million.

     

    I would like to point out that the "RPC server is unavailable" message is an exceptionally poor way to communicate UAC denial of process elevation / admin privileges. I do acknowledge that the problem from a .net point of view is that your code is never called, when require admin privileges is set in manifest or similar fashion.

    For the VS2010 team, I would recommend pre-running somehow a manual check for local process admin and elevation rights, and only then trying the actual operation

    ps. for anyone who wants to test if your code is called when requiring elevation, create a console app, add -> new item -> application manifest file. Then open your app.manifest, add requireAdministrator (links and code below). Then set your main function to console.writeline something, i prefer something like "I like sheep, they are fluffy when clean!". Then run your app as non-admin from a command prompt. Depending on your local gpo settings (our workstations deny all elevation from normal users) you may or may not get "access denied", this might not be what you expected. (gpedit.msc -> computer configuration -> windows settings -> security settings -> local policies -> security options -> many different User Account control settings.) In my case running as admin the "behavior of the elevation prompt for admin or standard users -> automatically deny elevation requests. So. In the end, your code is never called, and thus debugging this might be a "bit" tricky. Since this way of requiring admin rights is considered "the way" to do it, and all manual ways to do stuff like this is bound to fail (administrators might be named differently as a group, even sid's might be changed and the builtin admin blocked etc).

    [http://msdn.microsoft.com/en-us/library/bb756929.aspx]

    <requestedExecutionLevel
    level="asInvoker|highestAvailable|requireAdministrator"
    uiAccess="true|false"/>



    All the good names were idd in use.
    יום חמישי 28 אפריל 2011 06:46
  • I am also running my VS2010 machines, my test controller and 2 test agents, all on windows 2008 r2 x64 std edition full install, on VMWare.

    I am running on old 4.0.1a esx servers, updating to 4.1 is too much of a hassle. Even though we purchase all our vmware work externally.

    Basically I am running a standard full SP1 now (this worked the same with 2008r2 x64 with all auto updates and no SP1 as well), vmware has no additional patches beyond what was available at 4.0.1a update time.

    I also have default installs of vmware tools, AND, be sure to check "synchronize time with host" as the controller + agents require time accuracy between them I would guess.

    This might not help you as such, but at least with this environment it does work.


    All the good names were idd in use.
    יום חמישי 28 אפריל 2011 06:51
  • Detailed and informative, thanks
    יום שני 02 אפריל 2012 07:49
  • I set up a Visual Studio load test solution ("Using Visual Studio Load Tests in Windows Azure Roles") and after the deployment, the controller would not appear in the Manage Test Controllers list.

    The solution was to reboot the Azure controller role.

    יום חמישי 30 אוגוסט 2012 18:53
  • I set up a Visual Studio load test solution ("Using Visual Studio Load Tests in Windows Azure Roles") and after the deployment, the controller would not appear in the Manage Test Controllers list.

    The solution was to reboot the Azure controller role.


    I am unable to see the controller under the manage test controllers list after the deployment to the azure platform. I also tried rebooting the azure controller role but that did not work too. I am able to ping so connection is  not a problem. Let me know if I need to do some settings under visual studio.
    יום שני 03 ספטמבר 2012 19:49
  • You may need an admin account on your development machine with the same username and password as the account used to run the test controller. Run VS  as this user or from this user's account and the controller may show up.

    יום שלישי 04 ספטמבר 2012 22:29