But it works on my PC!

The random thoughts of Richard Fennell on technology and software development

TF246062: Two or more database are in conflict when upgrading to TFS 2010

Whist upgrading a TFS2010 Beta2 server to RTM I saw the following error when I ran the verify step of the upgrade.

TF246062: Two or more databases are in conflict because they are each designated as the owners of the following schema: Framework. The schema is for the host with the following name and ID: CollectionName, 8aace481-2471-49c8-da74-77ee3da4ce29. The databases with this conflict are: Data Source=SQLInstance1;Initial Catalog=Tfs_CollectionName;Integrated Security=True, Data Source=SQLInstance1;Initial Catalog=Tfs_Production_CollectionName;Integrated Security=True. You must specify one and only one database owner for the schema in the searchable SQL Server instances for this deployment of Team Foundation Server.

This error is caused because you have two Team Project Collection (TPC) DBs with the same unique GUID. So how can this happen and where do these GUIDs come from?.

When you create a TPC it gets a GUID. It keeps this GUID if you disconnect it from a TFS server and move it to another server. The only time this GUID can change is if you clone the TPC. When the cloned TPC DB is attached, the TFS spots it is a clone of a TPC is already hosts and issues a new GUID.

So how did I get two DBs with the same GUID? The answer is that prior to the upgrade some tests had been done using another TFS server to see if the client wished to do an in-place upgrade or disaster recovery style one onto new hardware. When doing a DR style upgrade the server does not issue a new GUID, as the TPC is unique to the new server, this server knows nothing of the original TFS server. This meant, as the two server shared a SQL cluster, that we had two copies of the same DB (but with different names) on the same SQL instance, so when the TFS upgrade program asked for the DBs by GUID it got back two DBs, hence the error.

The fix was to delete the Db created during the previous tests.

Note: You can see a similar effect if for any reason you replicate any of the TFS Dbs on a single SQL instance, such as to make a second copy of the warehouse DB for some special reporting purpose.

How little do you have to do to run a VS/TFS2008 build on a TFS2010 server?

As do many people I have a good number of TFS2008 style builds for legacy applications. I will, in the end, move these over to VS2010 and hence upgrade their build formats to the new 2010 workflow based one, but for now it would be nice to be able to run them with the minimum of effort. To this end I have done some work to see the minimum I can get away with to allow these builds to run, the aim being to leave the build box as close to a virgin TFS2010 one as possible.

Basic Setup
My basic build system was

  • Windows Server 2008 32bit with SP2
  • TFS 2010 build

A VS2010 Test
Just to make sure all was OK, I created a basic VS2010 MVC2 project with it’s default tests. I then create a default build for this. This failed as my build machine did not have the targets to build a web application. I copied the directory

C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications

up from a development PC to the build box and tried again. The build still failed as it was missing MVC2 assemblies, I downloaded the AspNetMVC2_VS2008.exe installer to get these assemblies on my build box. Once this was all done the build worked and the tests passed

A VS2008 Test
So I knew I had a 2010 build system that could build and test a 2010 solution. I next took an existing VS2008 solution’s build, this build had been upgraded as part of the TFS2008->2010 server upgrade. The build failed completely. This was not surprising as as well as being for a different version of VS I knew that was missing a number of custom build tasks.

First I had to install all the custom tasks, for me this was

Once all these imports were present the build tried to compile, and failed with the error.

C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets(133,11): error MSB4064: The "Retries" parameter is not supported by the "Copy" task. Verify the parameter exists on the task, and it is a settable public instance property.
C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets(131,5): error MSB4063: The "Copy" task could not be initialized with its input parameters.  [c:\builds\Moorcroft Website\Debt Collection

I spent a lot of time fiddling here, if I replaced my

C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets

with one form my PCs V9.0 directory all was OK, but then I found this post that sugested to just removed the offending parameters in the targets file, they are just retry and timouts! Once I did this the build attempted to compile the solution (and I checked it still worked for my VS2010 MVC2 solution).

I now got another set of missing assemblies errors. This was due to the lack of MVC1 on the build box, this was downloaded and installed

So now my MVC1 web site built, but the associated test project failed. This was because the V9 of Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll could not be found, the build box had V10. To address this I changed the assembly reference in the test project from the GAC to a copy of the assembly I included under source control, so it could be pulled to the build server.

Everything now built. However the tests did not run. There was an error that MStest could not be found. I edited the tfsbuild.proj to add the path to the MSTest file

PropertyGroup>
    <!-- TEST ARGUMENTS
     If the RunTest property is set to true, then particular tests within a
     metadata file or test container may be specified here.  This is
     equivalent to the /test switch on mstest.exe.

     <TestNames>BVT;HighPriority</TestNames>
    -->
    <TestToolsTaskToolPath>C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE</TestToolsTaskToolPath>
  </PropertyGroup>

If I looked at the build log I could see that MSTest now ran, and I could see all my 100+ test, but they all failed and were not published to the TFS server. I copied the .TRX results file local from the build box and opened it in VS2010. I could then see that all the test failed because the Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll could not be seen. I am not sure it is great solution but I just dropped a copy into the same directory as MSTest.exe C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE. The other option I could think of would be to put it in the GAC.

Once this was done most of the test executed and passed Ok, but some still did not. Again checking the .TRX file, as it still did not publish the results, was due to problems with TestContext. It seems the V9 assembly passes TestContext parameters in a different way to the V10 one. The test that passed did not have any TestContext declared. So as I did not need TestContext for these tests I just commented them out.

All my test now ran, past, and the results were publish. The problem was if a test failed the results were not published, but this seems to be a know issue so nothing I can do about that now.

So I now have build that mostly work, probably well enough for now. I have not need to install VS2008 or VS2010 on the build box which is nice. Just have to see how well the build holds up in production.

TF31002: Altering the URL that your TFS 2010 Web Client uses to talk to the AT

The Web Client for TFS 2010 (what was called Team System Web Access TSWA) is now installed as a core part of the Application Tier. It is no longer a separate install as it was in previous versions. This means it is easy to implement, it is just there by default. However, this can raise some problems if intend to expose to TFS AT via a firewall to the Internet, or use an alias for your TFS AT. This is because, by default, the Web Client uses it’s host server name as the AT name to connect to, it assumes the AT is local.

So for example, if you install your AT on SERVER1 you can set the server so that it responds to calls to the name TFS.DOMAIN.COM (after suitable DNS registration and disabling of local loopback checks on the server). So all your TFS clients should be able to access the server via http://tfs.domain.com:8080/tfs. However if a user tried to access the sever via Web Client URL of http://tfs.domain.com:8080/tfs/web they will get an error that that the inferred local AT (http://server1:8080/tfs) cannot be resolved (from where they are outside the firewall.

image

TF31002: Unable to connect to this Team Foundation Server: https://server1/tfs. Team Foundation Server Url: https://server1/tfs. Possible reasons for failure include: - The name, port number, or protocol for the Team Foundation Server is incorrect. - The Team Foundation Server is offline. - The password has expired or is incorrect. Technical information (for administrator): The request failed with HTTP status 404: Not Found.

This is easily addressed edit the C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Access\Web\web.config file and explicitly name the AT to be used for the web client. This is in the block

<tfServers>
     <!-- <add name="
http://server:8080" /> -->
</tfServers>

Note here the sample URL is wrong, when you are done it should look something like

<tfServers>  
  <add name=
http://server1:8080/tfs /> -
</tfServers>

Interestingly this fixes the issue on the screen shot above for the lower instance of the error, but not, the upper one. However that is enough to get you into the client and you don’t see the error after that.

Hanging Humax PVT9200T PVR

Recently my Humax PVT9200T has started to hang. When I started it up, within a minute or two (usually much less) the picture froze. Prior to this it had been working fine for the six months I had owned it. This seems to be a common problem for the PVT9200T of late, there is much talk of a patch on the way.

For me the immediate solution seems to have been simpler; I just reset it to factory defaults and let it rescan the channels. It has now been working fine for a couple of days. Maybe this simple solution will help other owners of the PVT9200T

TF50609 error when creating a new team project in TFS 2010

After upgrading a TFS 2010 RC server (which was previously upgraded from Beta1 to Beta2) to RTM I hit a problem when trying to create a new team project. The error I saw was

Event Description: TF30162: Task "GroupCreation1" from Group "Groups" failed
Exception Type: Microsoft.TeamFoundation.Client.PcwException
Exception Message: TF50609: Unable to retrieve information for action ADMINISTER_TEST_ENVIRONMENTS, it does not exist.

A quick search shows this is a known problem with TFS 2010 Beta 1 to Beta 2 upgrades, strange it did not show itself on our servers until we when to RTM. Grant Holiday provides the solution for Beta 1 to Beta 2, but the command line required for RTM is slightly different to the one he had to use. The fix involves using both the parts of this post, the TF50660 is a symptom of the underling TF237091 error

  • Make sure you have exported a good working process template from another TPC
  • Delete all the old (Beta 2 process templates) from problem TPC
  • ALSO delete the new RTM process templates, in my case MSF Agile V5 (if you don’t do this and then reload the template the witadmin edit seems to have no effect)
  • Run the witadmin command (note no /P: option that Grant mentions and it is dimension not dim at the end)

witadmin chnagefield /collection:http://myserver:8080/tfs/myprojectcollection /n:Microsoft.VSTS.TCM.AutomationStatus /reportingtype:dimension

  • Import the known good process template (if you had tried to do this before the witadmin edit you would have got the error ‘TF237091: Actual reporting settings for the field Microsoft.VSTS.TCM.AutomationStatus are different from those specified in the XML. Changing these settings is prohibited.’
  • You should now be able to create new team projects
  • You need to repeat this for each TPC you have that shows the problem

TF261007 error message when attaching a collection

Whist moving Team Project Collections (TPC) from our old TFS2010 Beta/RC server to new production hardware I got a TF261007, exactly as detailed in Marcel de Vries post. However, I was in the better position than he was as I still had full access to my original server, so I thought I could go back, re-attached the TPC on the old server, run the command

tfsconfig lab /delete /collectionName:MyCollection /External

re-detach and all would be OK.

This was not the case, you still get the same problem as TF261007. It seems that if you have a TPC what has ever been on a TFS 2010 RC server with Lab Management configured then it can only be moved to a new server that also has Lab management configured, or at least SCOM VMM console installed and pointed at VMM Host.

I checked this with Microsoft and was told it is a known issue with the Lab Management RC and will be fixed in the RTM, for now there is no other workaround other than the one Marcel detailed.

Setting the display value in databound combo boxes on Access 2010 web forms

When you drop a combo box on a Access 2010 web form and databind to a query or table with a value column and display column (e.g. the query select id, description from table1) you don’t get what you would expect. It shows just the value e.g. a set of integers in the combo.

This is not the case if you are using a standard Access client form. the wizard that gets run sort it all out for you, and if it does not, you just set the ‘Bound Column’ property to sort it out.

On web forms the fix is simple, but not obvious.

  1. Databind the combo as you normal do to the query/table.
  2. Go to the combo’s properties format tab
  3. Set the column count to 2
  4. Set the column widths to 0cm;2cm (basically hide the first column and show the second)

image

Once this is done it work fine

More on my Vodafone 403 errors – an explanation at least

The next chapter of the ongoing saga. I had the 403 errors again today when using my phone as a modem to test out firewall. As I was in the office I had time to call Vodafone support. As expect I had to speak to a succession of people:

  • Person 1 – call centre advisor, passed me straight onto ‘support’
  • Person 2 – support advisor but seem lost when I spoke about web protocols, I think it was more ‘making a phone ring’ support
  • Person 3 – 2nd line support, success, as soon as I explained my problem they said ‘yes that happens’.

The problem is down, as I had suspected, to congestion in their WAN network (not the 3G network, though the density of cells is a factor). When you try to use HTTP Vodafone route a request to their authentication server to see if your account is allow to connect to the site. By default they block a list of adult/premium web sites (this is service you have switched on or off with your account). The problem is at busy times this validation service is overloaded and so their systems get no response as to whether the site is allowed, so assume the site you asked for is restricted and gives the 403 error. Once this happens you seem to have to make new 3G data connection (reset the phone, move cell or let the connection time out) to get it to try again.

I have now had the restricted service removed from my account, we will see if this help. I fear it will not as any connection still has to ask the authentication server if the site is restricted even if my account is set to restrict no sites.

So it seems that volume of smartphones is really hurting Vodafone's internal network. They seem to have the 3G/Edge capacity, shame they have not got enough server wan/capacity to back it up yet.

What I don’t understand is why this has taken me so long to get a sensible answer. Can’t they publish a statement on this problem on their support forums or web site?

Upgrading from Office 2010 RC to RTM

I got this commonly seen version error when I tried to upgrade my RC version of Office 2010 to RTM

Setup is unable to proceed due to the following error(s):
Microsoft Office 2010 does not support upgrading from a prerelease version of Microsoft Office 2010. You must first install any prerelease versions of Microsoft Office 2010 products and associated technologies. Correct the issue(s) listed above and re-run setup.

I had already removed by RC Office and Visio. Turns out the problem was I had the Outlook Hotmail Connector (Beta) installed too. Once this was removed the install worked fine.

Notes from our TFS 2010 upgrade

Got time today to start our proper internal TFS 2010 rollout. This involves linking up the new TFS to our SharePoint 2010 farm and merging in the contents from 2008 TFS and 2010 RC servers.

All went fairly well, our SharePoint farm caused a few problems with its rather nice redirection feature. This  allows you to gradually move SharePoint content from an older server to a new one. A page is requested from the new server, if it is there it is used, if it is not the content on the old server is used. This caused a couple of problems during the install of TFS that content was not on the new SharePoint server so it redirected to the old one. However, the correct response was that the content was not there and TFS need to install or configure it. Once we realised this was going on there were no major issues with the TFS 2010 installation.

So we had a nice new TFS 2010 install. The next task was to move over content from the 2008 server. Our 2008 server was virtualised so I snaphot’d it, made sure we had a good SQL backup and did an in-place upgrade, and this is where I hit a problem. Our new TFS 2010 install and the 2008 were using the same central SQL server. Our new TFS 2010 install had created a TFS_Configuration DB, I had had the option to put in prefix such as TFS_2010_Configuration but decided I did not need it. This choice came back to bite me. When you do an in-place upgrade of 2008 to 2010 it rolls up all the old TFS DBs into the new structure, creating a new DB, with you guess it, the name TFS_Configuration. If you are doing a new install you can alter this DB name, but this is not the case for a upgrade, you have to use the standard name. So I was a bit stuck. The solution was to:

  1. take my new TFS 2010 server temporarily off line
  2. rename the TFS_Configuration DB
  3. do the in-place upgrade on the new 2008 server to 2010, so it creates as new TFS_Configuration DB
  4. detach the newly upgraded Team Project Collection on the TFS admin console
  5. take my upgraded TFS 2008 server off line
  6. rename its TFS_Configuration DB (if really confident you could delete it)
  7. rename the original TFS_Configuration DB back
  8. restart the main TFS 2010 server
  9. attached the upgraded TPC in the TFS admin console

Simple really !