What to do when SSRS 2012 is not happy with port 443 or 80

Leave a reply

During our upgrade from TFS 2012 to TFS 2013 a couple of weeks ago we ran into problems upgrading SSRS 2008 to SSRS 2012. The only thing I was able to do to fix it, was uninstall 2008 and then install 2012.

However after that it seemed that SSRS 2012 was unable to register on port 80 or 443. Even though this used to work fine. At first I though Sharepoint (which runs on the same ports on the same machine) might be the problem, and was the one not playing nice with SSRS. However after some digging I found out that the URL registrations created by SSRS 2008 were not correctly removed during the uninstall.

To see if you are facing the same problem, open an elevated command prompt and type:

netsh http show urlacl

This should give a list of all registered URL’s on the system (this might be more than you know). In my case the following URL’s were present:

http://+:80/ReportServer
https://+:443/ReportServer
http://+:80/Reports
https://+:443/Reports

To remove these from the list you should run the following command from the elevated command prompt for each of these URL’s:

netsh http delete urlacl url=https://+:443/Reports

After that, just run the SSRS 2012 configuration wizard and let that do its regular job.

Updating DBML via drag/drop in Visual Studio 2012 not working

Leave a reply

I don’t usually work with Linq 2 SQL DBML’s anymore, but today I had to work on a project that still used them. I needed to update some tables, so I removed them as I always do, and then tried to drag/drop them from the Server Explorer.

But not today…. today Visual Studio decided that the Server Explorer would not allow me to even begin dragging a data connections table, let alone dropping it on the DBML.

After some creative googling I found out that the problem was with the file called dsref80.dll. This file is located in the following folder on an x64 machine: “C:Program Files (x86)Common FilesMicrosoft SharedVisual Database Tools”. On my machine it had the following version:

Thats right, it says Visual Studio 2013 Preview (something I had already removed due to some other problems I had a couple of weeks ago). So the uninstall of Visual Studio 2013 Preview had left this file lying around. Causing Visual Studio 2012 to panic and not load it, which in turn breaks the drag/drop action of a Table object from Server Explorer to my DBML surface.

You could probably fix this issue by manually removing this file and then running a Visual Studio 2012 repair. But this is a somewhat time-consuming endeavour. So I opted for the fast route which goes as follows:

– Find a machine with Visual Studio 2012 installed that never had the Visual Studio 2013 Preview installed.
– Copy the dsref80.dll from that machine to your own machine, overwriting the 2013 one.
– I didn’t even have to restart VS or reload the DBML, drag/drop worked again instantly.

The version of the correct file showed as follows:

Editing ‘Changed By’ and ‘Changed Date’ fields using the TFS API

Leave a reply

A while ago I ran into a problem while developing an application that uses the TFS API to create Work Items from requirements from some other application. I wanted to maintain as much of the info that was available in the original source in the new work items. This means I wanted to edit the Changed By and Changed Date fields.

To accomplish this you have to bypass some validation rules the TFS API has in place. To do this, you have to instantiate the work item store in the following way:

var workItemStore = new WorkItemStore(collection, WorkItemStoreFlags.BypassRules);

This is however, not all, as I soon found out when I was presented with the following error, even when I didn’t even edit the Changed By and Changed Date fields:

TF26212: Team Foundation Server could not save your changes. There may be problems with the work item type definition, or a conflicting work item type definition change may require a refresh on your client. Restart your client application and try again, or contact your Team Foundation Server administrator.

With the inner exception giving me some more error numbers to google:

TF237165: Team Foundation could not update the work item because of a validation error on the server. This may happen because the work item type has been modified or destroyed, or you do not have permission to update the work item.

It turns out that you need some special permissions to be able to use the BypassRules flag. Your account needs to be in the Project Collection Service Accounts group (or the Team Foundation Service Accounts). There are plenty of reasons that it is not a good idea to put regular users in this group, therefor it is not possible to add users to these service groups using Web Access or the Administration Console.

The only way to do so is with the help of the TFSSecurity.exe command line tool. For instance if you want to add your user account to the Team Foundation Service accounts group, use the following:

TFSSecurity.exe /g+ “Team Foundation Service Accounts” “[DOMAIN]UserName” /server:https://<server>:<port>/tfs

Break down team barriers and reduce cycle times to deliver continuous value

Leave a reply

One of our solution architects came up to me the other day and asked the following question:

“Our team is using TFS and doing ALM(ish) for a while now. How can I convince the rest of our company we should introduce it to all our application/product development efforts. Preferably in one catchy sentence or phrase on which I can build a presentation that is specific to our company and that does not need a 90 slide presentation to be understood.”

If you create and ship software you are already doing ALM. I’m talking about ALM 2.0 here if you will, the improved kind. The one with all those fancy things like an actual lifecycle :-).

At that moment I could not think of something from the top of my head. But the question intrigued me, so I decided to do a bit of Google-ing/Bing-ing/DuckDuckGo-ing. And it turns out there is quite a nice catchy sentence on the Microsoft ALM home page (which I made the title of this post).

I think its good because of the following things:

– It does not specify a discipline. Which I think is important if you want the entire company in on this. It just conveys something for all of us.
– It does not specify continuous- deployment/delivery. Lets face it, there is so much focus on these two terms that you would think no one made software for non connected devices anymore. Continuous value can be achieved without continuous- deployment/delivery.
– It does not specify a certain barrier. Of course bad communication is a popular one to mention, but focussing on this only makes the problem worse. Also good to know we want to get rid of the barriers of course.
– It does not specify a software development methodology. Don’t mention these things in a session where you want your company to see the value of ALM. If you use [insert your favourite SDM here] even as an example there is always someone who thinks: “If we have to use [insert your favourite SDM here] to do ALM, I’m not going to do ALM.”
– It does not mention the ALM tool. First you have to convince people to want to do an ALM approach. Then convince them [your favourite ALM tool] is the best tool for your company.

Disclaimer: I am by no means an ALM guru (yet)

Sharepoint Foundation: Event ID 5586 – Unknown SQL Exception 2812 occurred.

Leave a reply

So i’m back from a 4 week vacation only to find out TFS and sharepoint were still running fine. Well, except for the error message from the title appearing in my event logs. I think it was always there, I just never got around to fixing it until now.

The full error message is a bit to verbose to dump here (lots of TSQL logging). But the full message is as follows:

Unknown SQL Exception 2812 occurred. Additional error information from SQL Server is included below. Could not find stored procedure ‘proc_UpdateStatisticsNVP’.

Apparently a Sharepoint Foundation update failed to add this stored procedure to all databases. After reading this post. I figured I just turn off usage and health data collection, however that did not stop the events from being logged every night.

So I decided to continue with the fix described in the following article (which is also quoted in the previous one). Fair warning though; you should probably not fiddle with the Sharepoint databases in this manner (Microsoft is probably less eager to help you fix problems caused by fiddling) unless you know what you are doing (or don’t care if it fails horribly I guess).

 

Things I fixed today #5

Leave a reply

I’ve planned myself one of those problem fixing days again. And I started off with an easy one:

A critical Sharepoint event log entry that said: The Execute method of job definition Microsoft.SharePoint.Administration.SPSqmTimerJobDefinition etc.

Luckily I was not the only one with this problem. Ian Anker wrote this up in his blog way better then I ever can. So here is a link:

http://ianankers.wordpress.com/2011/08/19/sharepoint-2010-the-execute-method-of-job-definition-microsoft-sharepoint-administration-spsqmtimerjobdefinition-threw-an-exception-event-id-6398/

Team Foundation Server 2012 Update #2 installation

Leave a reply

I decided to upgrade our production instance of Team Foundation Server 2012 with Update #2 fairly fast after its release since we are starting a new sprint on monday and we have been waiting for some of the new features.

I had done some research beforehand, and Update #1 installation went without any problems whatsoever so I felt fairly confident that it would be quite easy this time around as well. Ofcourse I checked if all my automatic back-ups had run, and that was the case.

I started the installation and file copied fine, but then I started the upgrade wizard and was greeted by the message described in the following connect bug report: http://connect.microsoft.com/VisualStudio/feedback/details/780985

Luckily I had my documentation in order and could use the work around no problem. But no “Next, next, next” installation as promised. Also this bug was reported in CTP #4 and didn’t get fixed for the RTM…. BAD MICROSOFT

So before you upgrade, make sure you write down the settings you need for the upgrade procedure:

– SQL server name
– Analysis server name
– Reporting server name
– Reporting server accounts

Things I fixed today #4

Leave a reply

Issue 4: SignTool stopped working

After a recent reinstall of my developer machine I received errors when compiling projects that use SignTool in the Post-build event to sign the built assembly with an authenticode certificate.

This is because the CAPICOM SDK is deprecated and won’t work out of the box with x64 versions of Windows. Also there is probably a better way to sign your assemblies (which I should research some time) these days, but since we have quite some build machines and legacy projects using this method it seemed best to get things working again.

I found the answer here:

http://www.peppercrew.nl/index.php/2011/02/windows-7-x64-signtool-error-signtool-requires-capicom-version-2-1-0-1-or-higher/

In short:
– Download the CAPICOM SDK from Microsoft
– Install it.
– Copy the capicom.dll to your SysWOW32 folder.
– Register it using the regsvr32.exe in that same folder.

Things I fixed today #3

Leave a reply

Issue 3: Problems accessing TFS’s Analysis Server from Excel

One of my co-workers wanted to use the “Create Report in Microsoft Excel” feature from the Team Explorer in Visual Studio 2012. However, once Excel had started, he was presented with the following error:

TF208056: An error occurred while the command was accessing the Analysis Services database Tfs_analysis on the server xxxxxx.

This happens because my co-worker’s machine is located in another domain, and the server name was not a FQDN server name. To fix this, I had to change the TFS Reporting configuration and set the SQL Server property to the FQDN.

First go to the TFS Administration console on your server:

Go to Reporting and then click the Edit button. You will be presented with a dialog stating that the jobs will be disabled. When you click Ok, the actual configuration screen appears:

Go to the Analysis Services tab and enter the FQDN of the SQL Server. You will have to enter the password for the data access account before you can hit the Ok button. After you hit Ok please be patient because it might take a few minutes before the dialog will disappear. After it has disappeared you should start the warehouse and analysis jobs again with the button on the TFS Administration page described above.

It can take a while before the change is visible on all clients.

Things I fixed today #2

Leave a reply

Issue 2: Another Event log Error on our TFS production server

This was also a Sharepoint issue one a bit easier to solve though. The error was:

Load control template file /_controltemplates/SearchArea.ascx failed: ‘Microsoft.SharePoint.WebControls.SearchArea,Microsoft.SharePoint,Version=12.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c’ is not allowed here because it does not extend class ‘System.Web.UI.UserControl’.

After some research I found out that the SearchArea.ascx file was left behind because we upgraded from WSS 3.0 to Sharepoint Foundation 2010. Renaming the file on disk to SearchArea.ascx_old stopped the errors from popping up. I guess you could probably remove it, but after that first issue, I didn’t want to tempt fate any more than I had to.

And now to lunch.