Andrew Lynes' WebLog

SharePoint 2007 Protocols and Ports

2007-06-04T03:44:00Z

In researching how to deploy MOSS into a customer's data centre, I needed to find out exactly what and how was being communicated between the various MOSS servers. Surprisingly, Microsoft.com is a bit light on details, although there is a reasonable "security hardening" document available on TechNet.

The winner for me was this post from Joel Oleson. It's short, to the point, and answers the obvious questions.

Installing the TFS Process Template Editor

2007-05-28T02:37:00Z

After an extended absence, I returned to ~~hacking~~ customising TFS Process Templates today. Last time I dabbled in this space, the Process Template Editor was a standalone application. It's now part of the excellent Team Foundation Power Tool. One problem... I installed the Power Tool and couldn't find the Editor anywhere. After a quick look around, I learned I needed to install Domain-Specific Language Tools for Visual Studio 2005 Redistributable Components. No problemo... but still no Editor. I then repaired the Power Tool... but still no Editor. It was only after an uninstall/reinstall cycle of the Power Tool did the Editor appear on the Team menu of Visual Studio.

The moral of the story... RTFM and install the DSL Tools before the Power Tool.

Iisapp.vbs: IIS application query script

2007-05-03T05:22:00Z

Perhaps I've been living under a rock, but today I was shown a neat script for IIS 6 that displays the process IDs and related application pools for all IIS worker processes. The script is "iisapp.vbs". It's just the trick when trying to discover which rogue web application is actually chewing up my resources (in conjunction with Performance Monitor and/or Task Manager). More info can be found on TechNet.

For the infrastructure people out there, this is probably nothing new. For devs like me, we probably don't spend enough time on TechNet to pick up nuggets such as this.

Microsoft Certifications - Are they worth it?

2007-02-17T00:50:00Z

It's that time of year where I really need to move on my training objectives I set out at the beginning of year. In a rush of blood, I decided to update my .NET certifications to the latest and greatest. One question that comes up in discussions from time to time is whether it's worth the effort.

In the best tradition of consultants, my response to this question is that "it all depends". Personally I don't see any point in going through the certification process simply to get a few letters after your name. I've interviewed enough people over the years with the Microsoft alphabet stapled to their resume who couldn't answer basic real world questions. Instead, the real goal of certification is to learn something. Of course in order to learn something, you may actually have to look at the exam material over a period of time rather than cram it in the night before. Although both strategies may see you certified, it is usually pretty clear in an interview/work situation who has actually tried to improve their skills. So, if you're prepared to put in a bit of effort and learn something, I think certifications are worth it. However, if your goal is to be locked in a room for two hours to stare at a computer and eat lollies, you'd be better off staying at home and playing Age of Empires.

For anyone still reading, my main tip for successfully getting certified is to go ahead and book the exam/s. Having a deadline is a great motivator to get on with it.

Finally, for those that haven't looked for a while, the Microsoft Press training kits for the new MCPD and MCTS exams are now available from your favourite online bookstore.

You need to do a root cause analysis

2007-01-29T06:04:00Z

A couple of days before Christmas, I found myself in the emergency department of my local hospital with an Atrial Fibrillation. Think of it as feeling like you're running a marathon while you're lying still. To correct the problem, my doctor decided to knock me out and zap me to "reboot" my system. This parallel with my day job obviously struck a chord. Apparently just after I was sedated, I informed her that she needed to do a root cause analysis. Her response was something like "I think he needs more". Let's just say that the nurses were still laughing 10 minutes later when I woke up (with a normal rhythm).

This experience revealed to me how important getting to the bottom of a problem is (well at least in my mind). Many of the systems we build are used by large numbers of people. When they fail, these users have to live with the consequences. In the Windows world, we have this nasty habit of rebooting a server to "fix" a problem. A lot of the time this works and the phones stop ringing, but the chances are that the problem will come back. Some people write this off as "typical Windows". It's not! A .NET application running on Windows Server 2003 should be rock solid. If it isn't, something is definitely wrong and should be investigated.

I'm not about to start a masterclass on application diagnostics, but it's amazing what you can learn if you take the time to look. Windows itself can tell you a lot about an application through its various logs. That said, I still believe that adding some well considered instrumentation and exception management to an application is the best way to understand an application's runtime behaviour. If you put this in from day one, all the better.

Unfortunately we can't just add some instrumentation to produce Andrew 2.0 and find out why I needed jump-starting. But at least I'm looking.

ASP.NET AJAX Ships

2007-01-24T08:00:00Z

This is great news. I've been waiting on this one for a while. I'm currently pondering what one of my major customer's application delivery methods might be in the future. This is another option to throw into the mix.

Details can be found at AJAX : The Official Microsoft ASP.NET AJAX Site and Scott Guthrie's blog.

First Canberra VSTS User Group Meeting

2007-01-24T02:52:00Z

We had a great turnout this morning. Thanks to everyone that attended. If you haven't had enough of me, attached is my slide deck (as an mht file) on "Migrating VS2003 Users to TFS Source Control". For those that couldn't make it, this outlines some of the experiences I had on a recent migration project. I've blogged about the content in the past, but now you can take it home.

Renaming/Nuking TFS Fields

2007-01-24T02:40:00Z

Last week I found myself creating a custom work item and needed to add a few new fields to TFS. That wasn't anything special in itself, but when I decided to change the names of my new fields (I'm blonde after all), things became more interesting. It turns out that TFS can only have one field for a specific friendly name. That sounds obvious, but when we also provide a "ReferenceName" that has a distinct namespace feel about it, I thought I could get away with it. Wrong!

Fortunately there's a neat tool that ships with TFS to rename fields (and other stuff). Check out witfields.exe. You won't use it all that often, but it's good to know it's there.

Application Portfolios

2006-12-13T07:37:00Z

Recently I joined a newly formed Enterprise Architecture team. I've never been in on the ground floor before, so it's an interesting experience. One thing that kept coming up in our planning discussions was a need to list/record the application assets we have, who owns them, their dependencies etc. We have a lot of products at Microsoft (and a lot of internal e-mails about them). Somewhere in amongst this, I was sure I had been told Microsoft had entered this space. It turns out we did in the form of Microsoft Office Project Portfolio Server.

Application Portfolio Management is a huge topic with widely varying opinions about what features are required in a tool. Side-stepping all of that, if some of the things I've listed above would be useful for you, why not have a look at Project Portfolio Server?

Canberra VSTS User Group

2006-12-13T06:59:00Z

Just in case you missed it... Check out Nils' blog.

It looks like I'm going to be one of the first ~~bunnies~~ to present. Hmmmm, where to start? I think Grant and I should be able to come up with something from our recent migration gig. We're 2.5 months on from going live now, so we've got a pretty good idea what worked and what didn't.

So do you need a development environment for TFS?

2006-12-01T02:00:00Z

One of the great things about TFS is that you can place the "crown jewels" of your development activities in a single safe location. The consequence for me is that I'm somewhat paranoid about using a production TFS installation for TFS R&D activities. For example, should I install a process template provided by a third party on my production server simply to have a look at it? IMO, absolutely not!

It's not to say you can't use your production TFS installation for some R&D work. Where I get sensitive is where this work requires changes that can't be confined to a single team project. At my current site, planning for replacing a CruiseControl/NANT build solution with Team Build is being undertaken using a team project on the production TFS installation. It's nicely contained, and TFS is being used as intended... to support development. However, having looked at one or two commercial process template offerings which require me to run MSIs on the TFS servers, there is no way I would put these anywhere near production (Why do software houses still get MSIs wrong?).

Where does that leave us? In short, you will probably need somewhere to try new TFS "things" independently of production. Virtual machines are the obvious solution, however if you plan migrate a lot of source from VSS into TFS, I would recommend that you get yourself some physical hardware. This allows you to iron out migration issues in a semi-realistic fashion before you involve the production installation (see some of my previous posts on the problems of repeating a migration over and over on the same TFS installation). Regardless of the choice, you will need to consider how you're going the license the development TFS installation (development is production for TFS after all). For low usage (which should normally be the case), the Workgroup Edition of TFS may fit the bill. I'm actually a fan of both approaches. I use VMs to "play" and a physical development installation to implement the next round of TFS changes. If Humpty-Dumpty has a big fall, at least he won't take out all my (or my customer's) source and developer productivity with him.

So how do you find time to manage TFS?

2006-10-16T15:51:00Z

TFS is a large product. Not a day goes by for me without discovering something new. With this size and complexity comes the potential for a significant administrative burden. Create a team project here, assign some permissions there, and the poor TFS administrator will be run off their feet. Sound familiar? IMO, this type of administrative model, while seemingly attractive, goes against the spirit of TFS. It isn't called Team Foundation Server for nothing

Developers have earned a reputation for being "cowboys" and in many cases, not without reason. This alone causes organisations to control access by developers to resources of any type. TFS is often no exception. However, I believe that TFS is a development tool that is best left up to the development teams to administer. But before you pack your bags to join me on the commune, this does not mean that everyone is made a TFS Administrator. The key is a well thought-out process of delegation. That is, rather than lock everything down so tight that the TFS administrator has to do everything, figure out what you can safely outsource to the users.

Safely outsource? Is that possible? Here are a few thoughts:

Remember that you can't permanently delete items from source control. This means that any "mistakes" can generally be undone. You may therefore get away with granting more access to source control by default than you may have initially thought.
Let the owner of a team project look after it. Sure, Project Administrators can delete the project, but if you're truly worried about that (given that you have to go out of your way to actually torch a team project), you probably have the wrong people on the payroll!
Do you really need to be the one that creates all the areas for a team project? One option is to allow a group of users to create sub-areas beneath a node of your choosing. If it gets out of hand, all your reports can still work against the node you initially created.
Don't fall into the trap of managing TFS security by assigning rights to individuals. Always use groups of some description. Where this isn't feasible, outsource it.
Don't try to keep secrets. Granting read-only access to everything by everyone by default can save a lot of administrative time. Besides, not hiding anything is great for communication!

Now for the words of warning... Keep your TFS Administrators (and Project Administrators for that matter) down to as few people as possible. These users can really wreak havoc (I guess I'm about to be booted off the commune). Finally, keep your IT Pros (and DBAs) away from TFS. Trust me, they can't just "tweak" it to make it better. Don't get me wrong, IT Pros are absolutely essential to the delivery of good software. However, we sometimes have different opinions on how to achieve it.

The Road to TFS - Experience from the Field (Part 3)

2006-10-10T13:59:00Z

So one week on, how did it pan out? In short, not bad... not bad at all.

We had about 100 users come on board on Day 1. We saw a reasonable amount of load on the TFS servers for about 4 hours, as users populated their workspaces. After that (and subsequent days), things tapered off quite nicely. We regularly see 50% spikes on the DT CPU, but these generally don't last more than a second or two. The AT seems to basically have its feet on the table.

That said, we did run into one hitch with the MSSCCI provider. We found that creating a new branch doesn't cause the provider to prompt for binding information. It simply sticks with the original, which is definitely not what we want. There is a workaround (namely to rip the binding info out of the branched project files etc), but it ain't pretty. I'm sure this will be sorted in a future release.

Looking back, we had a comparatively smooth ride, even though we targetted VS2003 users. For anyone considering such an upgrade, I'd recommend you go for it. Just remember to plan and practice everything.

The Road to TFS - Experience from the Field (Part 2)

2006-10-04T12:35:00Z

This is a follow-up to my last post where I'll talk about the highlights and lowlights of our TFS deployment project.

So how were the requirements met?

Yes, we used VSSConverter. It turns out that that it's quite a resilient tool. We managed to import over 162,000 files with their respective histories, even with a few server issues (more on this later). The whole process was completed in under 12 hours.
VS2003 integration was delivered via the MSSCCI Provider for TFS.
We actually continued using CruiseControl and NAnt for the .NET 1.1 build server. We did investigate moving to Team Build, but we decided our efforts could be better spent elsewhere. This did however require us to rewrite the version control integration code used by the build solution.
In order to handle the security requirements, we created a customised Process Template for the VSS database in question and generated both TFS groups and TFS areas for each resource being secured. By default, developers were granted read-only access to Version Control and only picked up read/write access to a resource through membership of the resource-specific group. We did some creative stuff with XSLTs to generate the Process Template from a VSS directory structure. Group membership was seeded from another database and is managed on an on-going basis via a simple website (that was part of the original central build solution).

And what didn't work as expected? Well, there were a few bumps along the way...

Repeated trial migrations (of the same VSS database) got slower and slower. With help from PSS, it appears that reapplying the same label over and over causes inefficiencies. We had a lot of labels (added by the central build solution), so this hurt us bad! Fortunately we were able to torch our TFS database and move on. The moral of the story is get yourself a development TFS server and be prepared to restore it to a clean state on a regular basis.
We encountered out of memory issues on the Application Tier. This seems to have been related to the first issue, but we still got a couple on a clean TFS database. In the end, VSSConverter coped with this and finished its work successfully.
The MSSCCI Provider prompted for a username and password at first use, which was a potential show-stopper because we almost exclusively use SmartCards for workstation access. This was traced to our TFS boxes being in a different forest to the clients and could be avoided through some client-side config.

So how did it pan out? You'll need to read my next post to find out.

The Road to TFS - Experience from the Field (Part 1)

2006-09-30T11:33:00Z

In this post, I'll outline the TFS deployment project I've been working on over the last 2 months (as part of a dedicated team). Future posts will cover some of the bumps we've run into along the way.

Here's the story... The source for one of my customer's major applications lives in a single SourceSafe database that's grown to about 2.5GB. There are over 100 users of this database and a significant portion of them rely on it for most of their day-to-day work. There have been instances where it has become corrupted resulting in an outage and some nervous moments as it was restored from backup. To spice things up, some of the developers are located 400km away in Sydney.

Given that TFS has a fairly well documented migration path from VSS, maybe this is nothing special. We did however have to deal with a few complications:

VS2003 is still being used for all development and that wasn't about to change.
A central build server based on CruiseControl and NAnt is being used and was intimately linked to VSS.
The security requirements are non-trivial and needed to be successfully mapped to TFS.

If any of this sounds familiar, you might be interested in my next post. There I'll talk about our approach to getting TFS to deliver on these requirements. We're actually going live this weekend, so by the end of the week, I'll also be able to comment whether we were successful.