Whilst setting up new a new SC-VMM based lab environment I managed to find some new ways to fail above and beyond the ones I have found before.

We needed to build a new environment for testing CRM application, this needed to have its own DC, IIS server and a CRM server. The aim was to have this as a network isolated environment, but you have to build it first as the various VMs.

So we did the following

  • On the Hyper-V hosts managed by our SC-VMM server create 3 new VMs connect to our corporate LAN
  • Install the OS on the three VMs
  • Make one of the a DC for dev.local
  • Join the others to the DC’s domain dev.local (they are not joined to our corporate domain)
  • On the IIS box add the web server role
  • On the CRM box install Microsoft CRM

So we now have a three box domain that does what we want, but it is not network isolated. We could have used the features of SC-VMM to push these VMs into the library and hence import into the Lab Management library. However we choose to make sure we could connect to them first as an environment.

So first I tried to create a standard environment, not using SC-VMM. I had to create a local hosts file on the PC running MTM, but once this was done I could verify the environment, so all was OK. I did not actually create it.

Next I tried to create a SC-VMM based environment and this is where I hit a problem. I was basically trying to do something I have done before with all our pre-lab management test VMs, wrapper existing VMs in an environment. When I tried to do this the verification failed, saying I could not connect to any of the VMs. First we made sure file sharing was enable, firewalls were not blocking etc. All to no effect.

To cut a long story short I had a number of issues, mostly down to the reuse of names

  • The SC-VMM VM names for the VMs (e.g. LabDC) did not match the actual host name (DevDC). I had to rename the VM in SC-VMM to match the name of the host in the operating system (I am still unsure if this is a red herring and not really that important, but I think it is good practice anyway)
  • We had to have a hosts file on the MTM box with the fully qualified names for the three boxes (not just the server name). Not that this hosts entry (or could be DNS if you want) is only needed until the environment is built

192.168.200.102 devcrm.dev.local
192.168.200.103 deviis.dev.local
192.168.200.104 devdc.dev.local

  • The name DevDC has been used on another VM that was being run on one of our developers Windows 8 Hyper-V setup. This was causing problems when MTM tried to resolve the machine name via SMB (Netbios, IP resolution was fine). Switching off this other VM fixed this, we only spotted it by using Wireshark on the PC running MTM (note you have to run the installer in Win7 compatibility mode to get it to work with Windows 8)
  • When entering the login details for development domain when creating the new environment in MTM  the user ID had to be entered as administator@dev.local and not devadministrator

Once this was all done I could verify my environment and create it, the TFS agent was installed, but did not connect to the test controller. This is exactly as expect as details in my previous post.

I now have a few choices

  • If I don’t want to network isolate it I can install a Test Controller in the domain
  • I can save each of the three VMs into the SC-VMM library via MTM and create an isolated environment.

So I hope this helps you avoid some of the problems I have seen, I just wish that the MTM environment creation step gave out a better log file so i don’t have to second guess it or use wireshark.