TFS Transaction Marking on SQL Server AlwaysOn Data Tier

If you need to manually backup the Team Foundation Server – you might have several reasons for not using the OOB tool – you need to follow this walkthrough on MSDN.

What I’d like to share is a small script you might use while you have to backup your Team Foundation Server running on an AlwaysOn-backed Data Tier.

I created a hourly job in both nodes, running one minute prior to the Transaction Log Backup job, as it follows:

In our case, we backup the Primary Replica, so before initiating the transaction I check for the preferred Replica. If it is 1, it’s the primary, otherwise it is the secondary (2) or it is resolving (0), both cases where my job cannot run.

It might be a little bit overzealous, because if you run the very same job on a non-preferred Replica (the secondary in our case) you are going to get an execution error stating the databases are read-only, but better safe than sorry!

Why is my Incremental Analysis Database Sync going on forever?

Sometimes it happens...

 

And that’s just because I stopped it. Why does it happen?

 

The reason is pretty easy: if the job is running, but you have a network problem – an outage, like it happened to me – the TFS Job Agent might not report the state and it may goes on for hours, even if it has released all the resource locks.

 

You can safely stop the job by invoking the Web Service on the TFS Application Tier – you’ll need to set the SetAnalysisJobEnabledState to FullyDisabled first and then to Enabled in order to restart with the next scheduled job.

 

And remember – do NOT process the TFS_Analysis OLAP cube with SSMS, as it is not supported by the Microsoft CSS.

How did I learn to get on well with Git

Who knows me certainly know I am not the biggest…err…fan of Git

Thanks to Gian Maria and its continuous support on it I managed to understand how Git works and why it is so powerful. I am not saying it is “better than” something else – it is different and it has some pros and some cons.

So, it’s distributed. Distributed does not mean anarchist – it means distributed. If you want to have some sort of centralisation, go for a Remote. You can use it as a shared repository to be used like a central depot without losing any advantage of the DVCS concept.

When you commit something is different than when you push something. A commit is local, a push is toward a Remote.

A Git Fetch gets all the objects from the Remote which are not in your local repository. A Git Pull does more: it merges those files on your local repository, like a Get Latest Version.

Eventually – install SourceTree. It’s an amazing GUI tool with a fantastic branch visualisation tool.

Can’t refresh the TfsOlapReport connection? Have a look at the Trusted Data Providers…

You open the SharePoint Dashboard and you suddenly see this error:

An error occurred during an attempt to establish a connection to the external data source. The following connections failed to refresh. TfsOlapReport

Fair enough, something happened to the Excel Services. Does it? Actually not – and if you try opening that specific report you will see your local Excel refreshing the data and working as usual.

What happened?

That specific error is a generic refresh error in our case. I tried back and forth on all the usual suspects – SSAS permissions, SSS token in the file, SharePoint settings, even firewall ports – but nothing changed.

Suddenly I noticed some reports were working (the Burndown one for example) while this (Active Bugs by Priority) didn’t. So what?

Looking at the Connection String I saw the Burndown report had MSOLAP.3 as a provider, while the broken report was using MSOLAP.5…

A quick double check on the SharePoint server (Manage Excel Services Application –> Trusted Data Providers) brought to the solution: MSOLAP.5 was not listed as a Trusted Data Provider.

Once I added MSOLAP.5 to the list everything worked as expected again and the reports were correctly showing.