In part 1 I promised to continue the configuration to allow running tests from TFS with Microsoft Test Center. In order to run tests cross domain, you need to have completed Part 1.
The best practices for work and production networks require some seperation between the networks. This is great for security, but can make using the tools in Visual Studio and TFS 2010 a problem. This post will show you how to use Lab Management and "no more no repro" bug data to get your job done easier and faster.
You are an administrator of the TFS project you want to connect to.
Warning: If you connect a test controller to TFS you may not be able to use it with Visual Studio in the future when you disconnect it. Disconnecting it will destroy any envronments you set up anyway. Be sure to have a dedicated controller for Visual Studio if you want to run tests directly from there. Connect Bug ID:585640
These instructions assume you don't have two way trust between the domains. If this is the case, you can still use lab management, but you won't be able to use SCVVM at all. You will be limited to "physical" environments. These can contain Virtual Machines and the setup isn't hard. You don't get the ability to roll test environments back, or create copies. However, it's well worth the benifits of rich debugging of automation failures.
Now you may start connecting test machines to the controller and adding them to environments in Lab Management. Assuming you have some test agents connected to the controller, this is how to set up an environment. (Automated deployment is out of scope for this post, the build controller needed can be put on the same edge machine using the same account.)
If you are planning on having several of environements, you may want to organize your test plans one per environment.
Your test will run and you can analyze the test results and log bugs with the rich debugging information. Bugs logged this way can be debugged in your Corperate environment without needing a connection to the test machines.