I have got a couple of comments about not being able to get things to work. Unfortunately I have not had time to dive deep into why this may be so. It may well be because the description is flawed, for which I apologize.

A few observations:

• Concerning NUnitTFS: apart from different arguments, it also seems like the functionality is different. Using the newest version I get the following error:

  However, using a previous (alpha) version all works as expected:

  

• If you forget to define the endpoints in the NUnitTfs.exe.config-file you will get an error similar to the following:
• Download the xaml and NUnitTFS I have used and try it out.

Using the InvokeProcess component (from the Toolbar) it should be possible to integrate any external tool into the workflow.

First step is to install TFS 2010. The following will describe how to install it on Windows Server 2008 and SQL Server 2008. However, the steps are the same for Windows Server 2008R2 and SQL Server 2008 R2.

I will not go into great details of how to install the server products. There are already great guides available on the web, so please drop me a mail og reach me on twitter if you require assistance with this part of the process.

Install Windows Server 2008 (Enterprise) on a server and apply Service Pack 2 (SP2).

Create a User named, e.g. TFS and add this user to the Administrators group.

Install SQL Server 2008 (Enterprise Edition) with all components. I’ve also selected to install the Business Intelligence Development Studio, which will allow me to create TFS Reports.

Install Reporting Services in Native mode, but select the option of NOT configuring the Reporting Services now. Do not install it in SharePoint Integrated mode.

Add the TFS user as Login to the SQL Server just installed.

Install WSS (Windows Sharepoint Services) 3.0 and Service Pack 2. Do not run the Configuration Wizard at the end.

At this point you should be able to see the default SharePoint site at http://localhost.

Open the SQL Server Reporting Services Configuration Tool and configure the Reporting Services now.

The tool will take you through the configuration step by step and will allow you to specify User, Create database etc. When asked for user credentials specify the User created earlier.

When configuring the Database keep the default setting to Native Mode when asked for Report Server Mode.

When the configuration has completed it should be possible to see the Reporting Service Portal and Web Service, e.g.  on http://localhost/Reports and http://localhost/ReportServer.

Now it is time to install TFS. Initiate the installation and select the features you wish to install, most likely all but the Team Foundation Server Proxy.

You properly need to restart the server during the installation – after all this is Microsoft – but otherwise the installation should run smoothly.

Once done, press the Configure buton, to launch the Configuration Tool. Select the configuration appropriate to your needs. I selected the Standard configuration for this lab.

When asked for the Service Account, enter the user you created previously.

If you are not able to pass all the verification checks, just correct then and re-run the verification. Once all is green, you should be able to complete the configuration.

If you want to read more about TFS, check out the blog posts by Richard Banks and Ewald Hofman.

You now have a running TFS, but we are far from finished. To finish what we set out to do we now have to create and modify a build configuration.

A disclaimer: the following example will have some hardcoded values. The correct way to do things would be to create a custom action, put it in TFS and refer this, but this I will leave
for another post.

In order to run our unit tests using xUnit and publish the results, we need to copy to items to the TFS server: xUnit and NUnitTFS.

I placed then in C:\Tools\. Do not put any spaces in the folder names; this will make your life easier later on.

A little tweaking is most likely required of the configuration of NUnit. You need to ensure that the client endpoints are set correctly in the config-file. By default they point to http://teamfoundation.

First step is to create a copy of the DefaultTemplate.xaml file, rename it to something – I called mine xUnitTemplate.xaml – and add it to TFS.

Open the new template in Visual Studio.

We need two arguments, one for the path to the xUnit console and one for the path to the NUnitTFS.exe.

Select Arguments and click Create Argument.

Create the two arguments: xUnit and TFSPublish.

Click the Arguments to close the list.

Select Variables and create one called XUnitResult. This will contain the output from one of the new processes we create.

Note the Variable Type and Scope.

Now scroll down into the processes and locate the If Statement called If Not Disable Tests and the Sequence called Run Tests.

We want to delete the content of the Run Tests sequence and enter our own. Easiest way to do this is right click on Run Tests and select Delete. This will leave you with something like the following

Now from the Toolbox find the Sequence (located under Control Flow) and drop one on the Then box. Rename it to Run Tests.

Add an Invoke Process to the Sequence and name it Invoke xUnit Console.

The reason for the red exclamation marks is that we need to configure the new control. Open the properties and set the following:

• Arguments: “xUnit.Test.dll /silent /nunit results.xml” (including quotes)
• FileName: xUnit
• Result: XUnitResult
• WorkingDirectory: outputDirectory

As you can see we here have a hard coded value, namely the name of the assembly containing the unit tests. “It can be easily seen” as we used to say at University, when the math proof was too easy, so I will leave this as a small home assignment to you, my dear reader

You also want to add two activities to output the build messages and build errors (if any).

In the properties, set the Message to stdOutput and errOutput respectively.

We are almost done. Add a second Invoke Process under the newly created and name it e.g. Publish xUnit Results.

Set the Argument to the following:

String.Format(“-n {0} -t {1} -p ”"{2}”" -f {3} -b “”{4}”" “,
“results.xml”,
BuildDetail.TeamProject,
BuildSettings.PlatformConfigurations(0).Platform,
BuildSettings.PlatformConfigurations(0).Configuration,
BuildDetail.BuildNumber)

And the FileName to TFSPublish  and WorkingDirectory to outputDirectory and lastly add two output handlers as above.

Save the template and check it in.

Next step is to create a new build definition that uses the new template.

Open the Team Explorer, right click on Builds and select New Build Definition.

Set the name to something meaningful

And the Trigger to Continuous Integration

In Workspace, ensure that the folders you wish to include are active. Here we only got one.

Under Build Defaults set the Build controller and the drop  folder. For this test I have just shared a drive on my TFS server.

Under Process we need to set the Build process template. Click on Show Details to expand the panel.

Click on New to  set the new template we have created earlier.

Select the Select an  existing XAML file and click on Browse…

Select the template we just created and press OK.

Press OK again to  get back to the initial screen (still under Process).

Under 4. Misc you  should see the two arguments we created. Enter the values as shown below.

If you are still seeing a yellow exclamation mark, it may be because you have to set the Configurations to build under 1. Required | Items to Build.

To test that this is actually working, create a solution and  add a class library to hold your unit tests. Remember to name the library  xUnit.Test (or rather ensure that the assembly is named xUnit.Test.dll).

When you check in the test, the new build should commence.

And when done the result is shown:

I made two small tests: one that would pass and one that would  not.

If you create a TFS report looking at the test runs (using ReportBuilder), you can see something like the following:

We are done!

A few things to note:

• To get TFS to compile and run the tests using xUnit, I create a solution folder (e.g. called Lib) on the same level as my projects and add all the xUnit files to this folder. I then reference xunit.dll from this folder.
• NUnitTFS seems to have changed from  the Alpha version, where it was possible to give an argument “-v”. This is not  longer possible with newer versions.
• Be sure that the process running the build has access to the drop location.

This blog post will describe the different steps required to create a small SQL Cluster with two nodes. The following is assumed:

• You have a domain controller. Mine is running Windows Server 2008, but you can use an earlier version if you wish to have a small footprint.
• You have installed Windows Server 2008 R2 on three servers. Two will be used for the cluster nodes and one as shared storage. All three servers have been joined to the domain and preferable been given a static IP-address.

Until Windows 8 I am running my lab using VirtualBox from Oracle. This allows me to run 64-bit virtual machines on my Windows 7 laptop, without having to boot into WS2008.

In summary we will construct the following:

• Two SQL2008R2 nodes running on WS2008R2
• One WS2008R2 server used as shared storage.

First thing to do is to create a Windows cluster. I use iSCSI and install the Microsoft iSCSI Software Target 3.3 on the storage box. There are other options. The important thing is, that you cannot create a SQL cluster, if the nodes are not able to see the same disk.

Run the install to unpack the files. This will open a web-page (index.htm). Select Install.

Accept all the default values and the install is completed swiftly.

Start the Microsoft iSCSI Software Target console.

Select the iSCSI Target node, right click and select Create iSCSI Target.

Enter a name for the iSCSI target and alternatively a description. Note, that the name cannot contain spaces.

In the iSCSI Initiators Identifiers dialog, press the Advanced button.

Enter the IP-address of the two nodes on which the SQL cluster will be installed.

Finish the target setup.

Right click the newly created iSCSI Target and select Create Virtual Disk for iSCSI Target.

Set location and size of virtual disk and finish the wizard. Upon completion you should see the newly created vdisk under the iSCSI target.

Next step is to connect the just created storage with the two cluster nodes.

On one of the nodes, open the Control Panel and select iSCSI Initiator.

If you see the following dialog

just select Yes.

Enter the IP-address of the Storage box and press Quick Connect.

You should now see the storage server under Discovered targets.

Go to the Volumes and Devices tab a press Auto Configure.

You should now see an entry under Volume List.

Click OK to close the iSCSI configuration.

Go to the second node and repeat the above steps.

Open the Server Manager and go to Storage and Disk Management. You should see the disk here.

Now go back to the first node, set the disk online and initialize it. This step will ensure that the disk is visible in the Cluster Manager when assigning disks.

We now have the foundation to setup a Windows Cluster. Next step is to enable clustering on both nodes. Start the Server Manager on each node, select Features and Add Feature.

Check the Failvoer Clustering click Next and complete the setup.

On one of the nodes go to Start -> All Programs -> Administrative Tools and select Failover Cluster Manager.

Select Create a Cluster in the middle of the page.

Add the two nodes to the list of servers that should be included in the cluster.

In the next step one can run a verification report. It will take some time to complete the report, but I recommend that it is done to avoid any needless frustration later on.

Give the cluster a name and an IP address.

Press Next and finish the setup.

To complete the setup the disk from before needs to be allocated or assigned to the cluster. Select Storage in the tree to the left and click Add a disk to the right.

This should display something similar to the following:

Press OK to continue.

So far so good. We now have the foundation on which we can install SQL Server.

SQL Sever 2008 R2 requires the .NET Framework 3.5. If you have not already done so, add it to your servers using the Server Manage and Add Feature.

On the node that “owns” the shared disk, run the installation. I know that it is not really correct to talk about ownership as it is the service that owns the resource and not the node itself, but I think you get the picture.

From the Installation Center, select Installation and then the second option New SQL Server failover cluster installation. The third option will be used to add node(s) to the cluster, once it has been set up.

Continue through the dialogs until the Setup Support files are installed. Once this has completed a “report” is run to identify any issues. There should be no Red Lights, and only Yellow of no importance or  that can be rectified later, e.g. the network binding order.

On the Feature Selection page, select the features that should be installed and press Next.

On the Instanced Configuration page, a SQL Server Network Name must be specified. This is the “virtual” name applications will use to connect to.

Accept the default values for the Cluster Resource Group and the Cluster Disk Selection.

On the Cluster Network Configuration specify an IP-address.

Continue through the setup until the Database Engine Configuration.

Supply the information for the Account Provisioning. On the Data Directories tab it can be seen that the shared or clustered drive has been selected. If you had multiple disks in your cluster and had selected them in the Cluster Disk Selected step, it would here be possible to place the data one one disk and the logs on another. For this test-lab all is installed on the same disk.

Continue with the configuration and end by pressing the Install button.

At this point it would be a good idea to get a cup of coffee as the installation might take some time.

Eventually something like this should be displayed

We have now configured and installed the first node in our failover SQL Cluster and we now just have to add the second node and we are done.

Start the install from the second node, select the Installation menu item, and as previous noted, select the third menu option Add node to a SQL Server failover cluster.

As before the installation process will begin by installing a number of setup files.

On the Cluster Node Configuration screen select the cluster to join.

Continue through the rest of the setup and press Install at the end.

If all goes well, the completion screen will be displayed.

That’s it! We now have a two node SQL failover cluster.

Well, not this time around.

Before you begin the installation of the SQL cluster, you can run some verifying tests of the Windows cluster. These were all green. During the SQL installation process all the Setup Support Rules are checked, and these were also all green.

The actual installation completed, but at the very end I got the following error:

Looking in the event log, the following error could be seen:

Cluster network name resource ‘SQL Network Name (BJSQCON)’ failed to create its associated computer object in domain ‘xxxx.com’ for the following reason: Unable to create computer account.

The text for the associated error code is: Access is denied.

“Access is denied”. This sounds like an AD problem, but the installing user should have all the required access rights (this at least according to the infrastructure team).

After some investigation I opened the (advanced) properties in AD for the computer object of the SQL cluster (sorry for the black; client confidentiality)

What was missing was the computer object for the Windows cluster, here shown after being added.

So after having pre-staged the AD, I removed the SQL node from the cluster and tried the installation again and this time all went fine.

Interested parties can read more about Failover Cluster setup and pre-staging here http://technet.microsoft.com/en-us/library/cc731002(WS.10).aspx#BKMK_steps_precreating

It was about 900 tables and a couple of terabytes of data. Before I came onsite, the client had extracted the data from DB2, a process which alone took a couple of days.

Was I was presented with was the following: one file for each table containing INSERT INTO statements for each row to be inserted into SQL. The largest file was about 2 GB, the smallest one a few K. Due to time constraints it was not possible to re-extract the data into a format there e.g. BULK INSERT or SSMI could be used.

The client had tried to import one of the larger ones – around 1.3 GB with about 3.2 million lines – using the command utility OSQL. After 14 hours we stopped the process.

My first thought was to insert explicit transactions into the files getting a structure of something like this:

BEGIN TRANSACTION
INSERT INTO …
…
INSERT INTO …
COMMIT TRANSACTION

I wrote a small utility which would transform the original files into the above structure given the overall size of the file and maximum allowed batch size, e.g. lines in each transaction.

This did not really help at all. The aforementioned file still took ages.

As we were running out of time, a request was made to upgrade the SQL server from 2 to 4 cores and to 16 GB Ram. This of course did not solve our import problem, but at least we got some more juice to play with.

I next made two changes, which turned out to solve the problem:

1. Used SQLCMD instead of OSQL
2. Split input files up into smaller chunks

SQLCMD was introduces with SQL Server 2005. It is using OLE DB and not ODBC for connectivity and it is 64 bit. Both of these will of course speed up performance.

To split up the files into smaller chunks I found a small utility called TextFileSplitter. The utility is free to use and comes with both a UI and command line interface.

Writing a small CMD-files automated the process of splitting up the largest files into chunks of 100K lines each.

SET INPUT=C:\Input
SET OUTPUT=C:\Output
SET LINES=100000

FOR %%F IN (%INPUT%\*.*) DO TextFileSplitterConsole -i=%%F -o=%OUTPUT% -splitstrategy:ls:%LINES%

Once we had the smaller files I started three other “CMD-file processes” to execute all the INSERT INTO statements using SQLCMD.

All in all it took a couple of hours for the splitting and inserting of data.

End result: happy client.

You should be careful not to over do it, though, as it can spoil the good synergies you have with your colleagues. However, let’s be honest: working from home is a good thing. You save the transportation, you can spend the morning with your kids and open the door for the plumber, should she decide to swing by.

I came across the following guidelines of what to do and what to avoid, if you are so lucky that you can work from home:

1. Do not leave your cell phone at home if you leave the house to go shopping or eat lunch.
2. Pick up your phone – also if you are in the bathroom.
3. Arrange some short phone meetings with people at work. They hate your guts because you are working from home and this will show them your commitment to your work – also when you are working from home.
4. Avoid long and complex mail threads with your boss to early in the day as this may result in a call where you have to answer the question of where you are (even if you have been granted permission to work from home, then do not remind your boss of this).
5. Do not drink alcohol early in the day, just because you are home. This also includes beer for lunch.
6. Remember to send the long e-mail with lots of attached spreadsheets that your colleagues have been waiting several weeks for. This serves two purposes: 1) It demonstrates that you are in fact doing something and 2) You can be sure no one will react to what you have sent. It is far to complex and takes to much time to read so you get some peace and quiet.
7. Do not leave your Elvis Costello album playing on the stereo with the volume turned to full throttle when you talk on the phone to your colleagues.
8. Do not take the phone when you sleep. Let it wake you up. Splash then some cold water in your face. Then call back and say you were in the middle of something important. It may well be your colleagues are looking straight through you, but it was worth the try.
9. Try to reach your boss very late in the day, but be absolutely sure he has left the office. This is the kind of attitude a boss likes. You are so engaged in your work, that you did not consider your boss might have left for the day when you called.
10. Dress properly – do not work in your underwear. People will know. No one knows why, but people know if you are talking to them only wearing your undies or g-string.

They could not be more wrong!

The reality is, that all you see is the airport and your hotel, which is often located right next to the airport, hence there is nothing to do in the evenings and you don’t event see the city you are in through a cab window – or get the change to visit the bars and restaurants in the evening. One airport looks pretty much like the next and hotel food is just not that interesting.

In my everyday life I am an “Information Technology Professional” … which is code for I know a bit more about computers than a box of rocks. During my professional career I have done quite a lot of business related travels. The following are some survival trips to make your experiences more pleasant and efficient.

The first thing you should do especially if you travel a lot is sign up with all the reward programs that airlines, hotels and maybe car rental services offer. If possible try to pick a (few) favorites and stay with those. A lot of companies will let you keep the frequent flier miles; I have gotten a lot of free plane ticket on this account. One thing is for sure: if you travel a lot and don’t sign up for these programs, you are plain stupid.

My second advise would be to never check bags with an airline. Take a course in “how to fit all your baggage into one suitcase without ruining your shirts and suits” if you have to (or ask your wife to do your packing). I have several times lost my bag and trust me, it is no fun. On a site note, you might want to memorize the location of the nearest store selling menswear at your destination, if you can’t manage with only carry-on. This reminds me of a time where I was flying into Zurich, lost my bag, and with less than an hour to my meeting ran into a department store and asked a clerk – a most distinguished older gentlemen – for a dark suit, a tie, two shirts (french cuffs), some underwear, socks and a pair of black dressshoes. He looked at me and said: Have you lost your suitcase, Sir?

These days security in airports can be a nightmare, so dress comfortably. I try to wear slip on shoes (sneaker) as these can quickly be taken on and off if required.

Sleep, sleep and more sleep. Make sure to get plenty of sleep before, during, and after your trip.

Try to eat resonably and stay hydrated.

Bring reading material like books or magazines or do like me: stack up your Kindle.

Use Skype. I have for a long time used Skype to keep contact with the folks at home. It is just more fun seeing the person you talk to than just hearing them and then it is cheaper too.

Delays in travel are inevitable. Try to be nice to the airline or travel employees. Even though they might be dorks, screaming at them won’t get you anywhere. Remember that you are only late, when your trip is over, and you are actually late. Instead open your Kindle and bury yourself in your favorite book.

The last but properly most important thing about business travels is having an understanding spouse.