Office 15 Technical Preview, Visual Studio Beta, Windows 8 Customer Preview


2012 is going to be an exciting year where you can expect that your cheese will be moved if you are a Microsoft customer. There hasn’t been any word about release planning, roadmaps or whenever what bits will be available to you. What we do know is that a couple of weeks ago the Office Team started their Technical Preview program (, The Customer Preview for Windows 8 is mentioned to be released next week the 29th of February and today Jason Zanders, corporate vice president for the Visual Studio team in the Developer Division at Microsoft, announced in his blog Sneak Preview of Visual Studio 11 and .NET Framework 4.5 Beta the release of the beta for the 29th of Februari next week as well!

If you ask me, but who am I, we are heading to a BIG BANG this year. Will we see a year where for the first time most major Microsoft products will be released in a new version, Office, SharePoint, Exchange, Visual Studio, TFS, Windows (client and server) -and- SQL Server all in the same year?

Man, all engines are running full speed in Redmond, that’s for sure!

Axialis brings new set of Ribbon & Toolbar stock icons


If you have been reading my blog before you know I’m a big fan of Axialis’ product IconWorkShop. This tool integrates with Visual Studio and allows you to easily work with your icons in your project.

I know from my own experience that creating icons is pretty time consuming (even if you have the option of using great tools as IconWorkShop). To help you in that area Axialis now is providing you with a set of Ribbon and Toolbar stock icons so you can easily match and combine until you got the icon that you need.

If you think you are even slightly interested in buying the set I can help you a bit there as I received a small token of appreciation in the form of a discount offer for 30% off up to November the 20th <—Click!.

Let me know if you agree with me about the tools and the tools that –you- use to build the icons for your application.

WinDiff and other ‘old’ tools in Visual Studio 2010

It’s always nice when I try to find a certain tool and GooBinging for it and in the end showing me an old blogpost from …. me, myself and I, pointing in the right direction.

The blogpost in this case was:

WinDiff and other ‘old’ tools in Visual Studio 2008

It showed me where I could find some old tools I used before and occasionally need again.

The post is now three years old, but it still is ‘almost’ right. Just enough to give me the pointer to where to find what I was looking for. And as I’m pretty sure that I will go and search for it again in about three years from now I’ll do a repeat and update it a bit to fit the Visual Studio 2010 scenario.

Here we go!

Ever wondered where all your ‘old’ but favorite tools resided in Visual Studio 2010? Are they removed?

I needed a tool called WinDiff to see what is changed between two textfiles and that tool did work for me in most cases. There is however no menu item in Visual Studio 2010 as there used to be in early versions of Visual Studio.

Check out folder:

C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin or
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bin

That is, if you installed Visual Studio with the installations defaults and depending on how many bits your processor likes.

It appeared the tools are still there. Take a look at the other tools in the same location. I’m sure you will recognize a lot of them!

See you in three years for an update of this blogpost to reflect the new times!

Team Foundation Server 2010 on Port 80

Team Foundation Server 2010

Last week I had the situation where we wanted to use Team Foundation Server 2010 but IT locked down most of the required network options. Basically it came down to the fact that only the most basic form of Internet protocols were in place, i.e. http traffic on port 80.

First option … convince the IT guys to open other ports (8080) on the network. Hmm, tried it, been there, no option. These are the NO-guys!

So here we are, we have a Team Foundation Server installer that installs on port 8080 by default and a network on port 80. Wouldn’t it be an option to just reinstall and enter port 80 as the port to install Team Foundation Server on?

Well, no. The deployment in this case was a ‘small’ one (virtual) server installation with SharePoint, Reporting Services and TFS on the one box. And TFS just does not like it when there already is someone else (SharePoint) covering the standard 80 port.

So standing up a new instance on port 80 is not an option unless you decide to move all your other port 80 services to another box.

That leaves nothing else than either give up move into the virtual domain and accept that port 80 is not an option or to go on into the well known trial on error debugging mode and see how we can open things up on port 80!

Giving up obviously is for the weak of heart but not for me. So let’s do it!

What I did is to start off with the default installation using port 8080 and later on try to move it over to port 80. (I already tried installing on port 80 but this hit so many issues that I reverted everything back to the original status and settled for installing on port 8080)

OK, first let’s try to fix the issue where port 80 is already in use by SharePoint. From several earlier endeavors in network land I was aware of the Host Name feature where you use different names to identify several services on one port. What we do now is moving the default SharePoint http://<servername> to http://sp.<servername> but leave the service on port 80.

This step will be a bit different for TFS on SharePoint Services and TFS on SharePoint Server. I will highlight both options here.

For SharePoint Services go to the “SharePoint 3.0 Central Administration” tool and under Operations select “Alternate Access Mappings”

Click the “Alternate Access Mappings” and select “Edit Public URLs”

Select the  “Default Web” from the listbox in the top right corner and change the “Internet” textbox to http://sp.<yourdomainorserver>

Because your machines need to resolve the URL given here you should add the entries also to your DNS server. To test it I didn’t add the URLs to my DNS (especially as this is managed by the NO-guys) but added them temporary to the hosts file (c:\windows\system32\drivers\etc) on both the server as the client machine.

Let’s rewind and do it again for SharePoint Server 2010:

Open IIS, select the web entry that covers the SharePoint port 80 entry. Right click and select the Site Bindings option from the menu and edit the existing entry. Leave it all as it was except for the Host Name. Change the textbox to http://sp.<yourdomainorservername>

While you are at it in IIS now browse to the SharePoint Admin Site “SharePoint 2010 Central Administration” and under System Settings click on “Configure alternate access mappings”

Select the SharePoint – 80 web and change the default entry to http://sp.<yourdomainorservername> as well. (I guess you could do the same thing as with the SP Services option, to leave the default as is and change the Internet box to http://sp.<yourdomainorservername> but I must admit that I didn’t test that.

Now we can test to see if we can access SharePoint on http://sp.<yourdomainorservername>.

On your client PC this would not be an issue but when you try it on the server you’ll hit a security issue blocking the site. In order to resolve this next hurdle we will make some changes in the registry.

The steps for this are also described in Kb 896861: but I will present them here as well.

The first registry entry we are setting is setting the DisableStrictNameChecking registry entry to 1.

  1. Locate and click the following key in the registry:
  2. On the Edit menu, click Add Value, and then add the following registry value:Value name: DisableStrictNameChecking
    Data type: REG_DWORD
    Radix: Decimal
    Value: 1

Next setting the BackConnectionHostNames …

  1. In Registry Editor, locate and then click the following registry key:
  2. Right-click MSV1_0, point to New, and then click Multi-String Value.
  3. Type BackConnectionHostNames, and then press ENTER.
  4. Right-click BackConnectionHostNames, and then click Modify.
  5. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
  6. Quit Registry Editor, and then restart the IISAdmin service

In this case you will add http://sp.<yourdomainorservername>. Later on you will add http://tfs.<yourdomainorservername> to cover the TFS entry.

Registry entries done? Best thing to do here… reboot the server (You may get away with only doing an IISReset but if you want to be sure … reboot it).

Now you’ve rebooted, check the new SharePoint entry in your browser. Open up the browser and goto http://tfs.<yourdomainorservername>. If all goes well you now see the next picture.

TFS will be our next stop. This is where this exercise all started.

Instead of changing the Host Name here we will add a new Host Name and leave the 8080 entry intact. Right click in IIS the Team Foundation Server entry, select the Site Bindings option and click the Add button to add a new entry. Create a type http to All Assigned on Port 80 named http://tfs.<yourdomainorservername>. Now do another IISReset.

Next thing to do is get into TFS Administration Console and select the Application Tier and hit the “Change URLs” option.

Within the Change URLs dialog change the Notification URL to http://tfs.<yourdomainorservername> and make sure the Server URL is http://localhost:8080/tfs

You will notice that when you select the “Use : “ radiobutton and enters http://localhost:8080/tfs that after closing the dialog and reopen it will change back to the “Use Localhost” radio button. Just check on the Application Tier page that the server URL shows http://localhost:8080/tfs

Make sure this dialog shows you’re the both ports 80 and 8080.

So, now this should do the trick don’t you think? Let’s try it…. open http://tfs.<yourdomainorservername>/tfs in your browser

WTF!! Another error, will this never end?

Here we go again, solving another issue. What happens is that on the serverside TFS tried to resolve things to port 80 as your initial call was on port 80. Now you have to make clear to the server that it needs port 8080 internally.

In order to do this, edit the web.config file found at C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Access\Web

In the web.config you find the entry:

<!– <add name=”
http://server:8080″ /> –>

Change this to (note the slash tfs extension):

<add name=”
http://<servername>:8080/tfs” />

Save the web.config and do another IISReset (better safe than sorry) end retry testing your TFS site: enter http://tfs.<yourdomainorservername>/tfs

Yess, this time it worked as expected.

Once you have this in place you can try to connect to your new port 80 URL from within Visual Studio 2010.

By doing all this you should now be able to resolve your SharePoint site and TFS site on the single server by using a set of hostnames instead of ports:

– http://sp.<yourdomainorservername>
– http://tfs.<yourdomainorservername>

As far as I have seen so far everything is working like it should work. Reporting was already available on port 80 but you could decide to move this also to something like http://reporting.<yourdomainorservername>. I’m not yet in the position to also test if this all interferes with build services or test management so let me know if you hit on issues where moving to port 80 interferes.

Don’t forget to request for the two (or more in case you include reporting) DNS entries with the IT guys and remove the entries from the hosts files you created earlier to resolve the names.

For now I’m very happy to getting it all to work on port 80 to be able to work within our ‘locked down’ network! It turned out to be a very big article but I hope it will serve you as a reference to set up your own ‘port 80’ installation.

%d bloggers like this: