Monday, October 23, 2006

Restore Team Foundation Server (TFS 2005) Database

Have you noticed the disparity about backup procedures documentation and how much information one can find about restoring from those backups?

What I am going to provide here is not new information: I just hope that this post will come up in some searches, therefore sparing some frustration.

Recently we had a bad day with our TFS database server, we decided to cut or losses and restore to the previous day's backups. Little we knew...

You will find comprehensive instructions on how to restore (http://msdn2.microsoft.com/en-us/library/ms252458.aspx or http://blogs.msdn.com/vstsue/articles/511396.aspx), you will diligently perform all the steps, fire up the servers, connect using Visual Studio and everything will seem to work properly. Until a week later when all of a sudden you will open a project you didn't touch for a while and when checking out an aspx page you'll see that it contains XML code. Or you'll find C# code belonging to another project into a DataSet XSD.

What happened? This happened: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=251122&SiteID=1.

Yes, there is a cache in the TFS Application server, and restoring the databases without manually deleting the cache ("%Program Files%\Microsoft Visual Studio 2005 Team Foundation Server\Web Services\VersionControl\Data") leads to bad, bad things.

Friday, August 4, 2006

Virtual PC and connectivity problems

You have worked on several projects, often at the same time, with each client requiring a different configuration, you like to experiment and possibly implode servers, and you like to "undo" your detonations, you like to keep your laptop tidy and store everything away in its nice virtual world, you like to test your deployment in a complicated scenario, and you can do it all in one laptop, they give you two boxes and you immediately find yourself with six IP addresses, in short: you love virtual machines.

However "virtualized hell" has plenty of hidden surprises: I am sure you have already encountered a total loss of virtual disk, like me, but what about network connectivity?

One nice day after lunch you will start a virtual machine that was working perfectly fine in the morning and find out that you cannot connect to anywhere. The symptoms are as follows:

  • You have set your VPC to use one of the NICs of the host.
  • You get a "This connection has limited or no connectivity" message on the network connection in the VPC.
  • When you open the network connection status window you see that
    you have sent several packets but received zero. Zip. Nada.
  • Your host machine is connected to a corporate network.
  • Your host machine works fine.

If all of the above is true, chances are that the network administrators just modified something on your switch port, either because they are implementing new policies or, more likely, because you have been flagged as a dangerous individual, and expect security to show up soon.

The reason for this is that network administrators generally don't like people who connect homemade bridges to their sacred corporate network, and they often implement port-level security on the switch.

This setting can be configured to the max, but often it translates into just one noticeable restriction: it allows only one MAC address per port.

For example, on a Cisco switch the following is the configuration of a typical non-secure port:

  • Interface GigabitEthernet3/28
  • switchport access vlan 110
  • switchport mode access
  • load-interval 30
  • storm-control broadcast level 10.00

And this is what you don’t want to have to deal with:

  • Interface GigabitEthernet3/26
  • switchport access vlan 110
  • switchport mode access
  • switchport port-security
  • switchport port-security aging time 1
  • switchport port-security violation restrict
  • switchport port-security aging type inactivity
  • load-interval 30
  • storm-control broadcast level 10.00

Note that in my case the violation clause was set to "restrict", meaning that the switch will ignore anything that is not coming from your one and only MAC on your ethernet segment. So your host can communicate with the switch, because that's the first MAC that the switch sees on the port, but the VPC is ignored. Other options are:

  • switchport port-security violation protect - Just drops packets.
  • switchport port-security violation restrict - Like protect but it increments the SecurityViolation counter. When you reach the maximum somebody is going to notice it.
  • switchport port-security violation shutdown - Puts the port into the error-disabled state immediately and sends an SNMP trap notification. Somebody is going to notice immediately.

Port security can also be configured to allow only a specified MAC, in which case you are in even more trouble because VPC MACs tend to change frequently if you play with the VMC files. Note that this applies to Microsoft Virtual PC and Virtual Server, all versions, and VMware as well,
actually it applies to things that haven't been invented yet, because it doesn't matter which virtualization software you use, it is the dual MAC that creates the issue.

In short: if you are experiencing network connectivity issues from a VPC and you tried everything else, then:

  • If you are legit you can ask your network administrator to check
    and maybe remove the port-security setting on your port.
  • If you are not legit then you should buy yourself a cheap router and happily NAT your way into virtualized hell. Unless, of course, you need not external access, and can do with the local NAT option of the VPC or a loopback, as described in the VPC guy's blog.