Lets just rename that Team Foundation Server…………….

I have previously posted on the fun I had getting TFS running in our office. Well thus far it has been stable, other than some ‘user too stupid’ errors, and we have been fairly happy.

The next stage was to expose the TFS server out through our firewall to allow home working. This turned out to not be too bad (expect some posts on our experiences with ISA server soon) but raised an interesting issue.

As far as the Visual Studio Team clients were concerned the TFS server had the physical PC server name in all it’s URL e.g http://myserver:8080. This was not an issue with the office as it could be resolved, but a problem on the Internet. Now I suppose we could have put some host file entries to address this but I really wanted to get it working as http://tfs.mydomain.co.uk:8080.

So we created a new DNS entry (both internally and externally resolving to the correct IP address). Once this DNS entry was created, and the firewall setup I could connect to the TFS server and pull down a project list and check files in and out from home. But I was getting those damned little red crosses next to the documents, reports and could not open the project SharePoint sites.

On checking the URL to be used for these services I saw that they were all still pointing to http://myserver with various SharePoint or Reporting Service directories on the end. Firstly, I had not exposed the default SharePoint and Reporting Services ports via the firewall, but that was easy to fix. The real problem was using the old name, how to change these entries? I think the best option would have been to install the TFS with the full name in the first place! But I did not really want to do a reinstall.

So I had search around and found that in C:\Documents and Settings\[name]\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache\[GUID] directory there is a XML file RegProxyFileCache.xml. This contains the details used by the client and can be edited. I replaced the http://myserver entries with http://tfs.mydomain.co.uk. A snippet is shown below from around Line 250 of the file:

<RegistrationEntry>
     <Type>Reports</Type>
     <ChangeType>NoChange</ChangeType>
     <ServiceInterfaces>
           <ServiceInterface>
                 <Name>BaseReportsUrl</Name>
                 <Url>
http://tfs.mydomain.co.uk/Reports
</Url>
          </ServiceInterface>
          <ServiceInterface>
                 <Name>DataSourceServer</Name>
                 <Url>myserver</Url>
          </ServiceInterface>
          <ServiceInterface>
                 <Name>ReportsService</Name>
                 <Url>
http://tfs.mydomain/ReportServer/ReportService.asmx
</Url>
           </ServiceInterface>
       </ServiceInterfaces>
      <Databases />
      <EventTypes />
      <RegistrationExtendedAttributes />
      <ArtifactTypes />
 </RegistrationEntry>
<RegistrationEntry>
      <Type>Wss</Type>
       <ChangeType>NoChange</ChangeType>
       <ServiceInterfaces>
            <ServiceInterface>
                   <Name>BaseServerUrl</Name>
                   <Url>
http://tfs.mydomain.co.uk
</Url>
             </ServiceInterface>
         <ServiceInterface>
              <Name>BaseSiteUnc</Name>
              <Url>\\myserver\sites</Url>
        </ServiceInterface>
        <ServiceInterface>
              <Name>BaseSiteUrl</Name>
              <Url>
http://tfs.mydomain.co.uk/sites
</Url>
          </ServiceInterface>
          <ServiceInterface>
               <Name>WssAdminService</Name>
               <Url>
http://myserver:17012/_vti_adm/admin.asmx
</Url>
           </ServiceInterface>
 </ServiceInterfaces>
<Databases />
<EventTypes />
<RegistrationExtendedAttributes />
<ArtifactTypes />
</RegistrationEntry>

After this change is made on reloading Visual Studio the red crosses go away and the various features work.

However this does not answer the larger question of getting it set right in the first place for new clients, you don’t really want to have to edit each client config. I suspect making similar edits in the C:\program files\microsoft visual studio 2005 team foundation server\tf Setup\eleadservices.xml might do the trick but I have not confirmed this as yet.

I still hold with the comment that TFS is very much an ‘install it right first time’ sort of product.

Time to revisit Microserfs

I was given a copy of JPod by Douglas Coupland for Christmas, now I will not be adding anything to the range of reviews to say it is very much Microserf V2.0 – similar story but it is just that people seem not to work as hard (but are still in the office as they have little life outside work) and the strange things that occur to them are very strange indeed. In Microserf you could believe it could happen, but JPod, well it is going a bit far. Also I agree with the comments that this book it is rather self referential.

But that is not my point….

After reading JPod I decide to re-read Microserfs and what a strange experience that was. I was struck by the number of items touched on in this 1995 book as ‘hip and new’ that are now so main stream. In 1995, if my memory serves me, they were completely left field ideas, or at least were in the UK, I cannot speak for the west coast of the USA.

It did seem Douglas Coupland really had his finger on a the pulse – especially over the comment that Apple was in trouble as it had no Bill Gates type visionary at the helm – this was in the period before Steve Jobs came back to reinvent the company.

Anyway both books are great reads for you Geek book groups, see what you think about the historic cultural relevant of Microserfs for the 90s (that is assuming you can remember the 90s!) and whether JPob will be as account for the 00s?

Update on Virtual Server

Yesterday I posted about problems with accessing remotely the Virtual PCs from the Virtual Server console. It turns out the problem was domain name related. We had a different name on the internal DNS to that on the external side.

In effect the server was trying to call:

vmrc://virtualserver.mydomain.co.uk:5900/my pc

when we should have been calling

vmrc://virtualserver-external.mydomain.co.uk:5900/my pc

even though we had actually accessed the system via

http://virtualserver-external.mydomain.co.uk

This has been fixed by getting all our DNS entries in line.

Accessing Virtual Server via an ISA server

We have been moving over to ISA Server to allow better management of internet resources, one problem we have had is publishing our Virtual Server so our tele-workers can get remote access to the test systems.

The ISA application publish rule works fine to allow access to the main Virtual Server console page (can create, start stop PC etc) but if you click on a Virtual PC you get a no connection screen, so you cannot actually use the Virtual PC.

However I found a way round this problem. When you get the no connection screen, click the remote connect option on the top right you can enter the URL in the form

vmrc://virtualserver.mydomain.co.uk:5900/my pc

and assuming you have allowed the 5900 access through the ISA firewall it should work.

So it looks like the problem is that when you click the thumbnail of the PC to access it uses some other URL to the form shown above. I will try to find out why this is.

Look out for more posts on ISA on BM Bloggers as we get our teeth into it.

Opening of a new blog

As Black Marble is growing we have decided to split out our individual blogs, hence the opening of 'But it works on my PC!'.

BM Bloggers will remain an aggregate of all the various sub blogs, which will grow in number over time.