I had this nagging problem on one instance where the Excel dashboards on a TFS 2010 instance would not bring up the data.

Here is how I fixed it (hopefully) someone else will benefit. There could be more than one reason for this error to manifest. In my case the following is what I did.

1. Log into your SharePoint 2010 server with admin credentials
2. Open SharePoint Central Administration
3. Open Application Management
4. Click Manage Service Applications (under Service Applications)
5. Click Secure Store Service (not the proxy)
6. Check on the SSS “Target Application ID”
7. Then click on “Set Credentials”.
8. Make sure the “Windows User Name” and “Windows Password” are the correct ones. Usually it appears blank. In my case I set it to the domain TFSService account and password.
9. Restart the IIS Server and then go back to the Project portal and refresh OR launch the portal from the Team Project node in Team Explorer.
10. This fixed it.

So, before you virtualize a workload you should have an understanding of what that workload looks like on a physical machine first and part of that understanding involves storage interaction.  I/O intensive workloads like SQL require some planning.  SQL even has a tool that can be used to simulate workloads on storage, which you can find in this link:= http://support.microsoft.com/kb/231619 

Some of the other relevant links to Virtualizing SQL are here:

http://www.microsoft.com/sqlserver/en/us/solutions-technologies/mission-critical-operations/consolidation-and-virtualization.aspx 

OK. Now coming to some of the salient points, SQL virtualization needs careful consideration of the storage systems you are using and its I/O characteristics. Some of the main considerations are as below.

• Use fixed-size disks. Defrag your volumes before creating the VHDs
• Use SCSI Virtual adapters for data disks attached to Virtual Machines
• Use pass-through disks for the best performance and for LUNs > 2TB
• Do *NOT* use snapshots in a production environment
• Use high speed storage configurations
  • High speed SATA\SAS drives (10,000 rpm or greater)
  • Use drives that support command queued I/O.
  • Use RAID 0+1 configurations with as many disks as feasible in the RAID configuration to distribute I/O

• Use MPIO configurations for storage
• Use the highest speed NICs for iSCSI storage
• Do NOT store system files (e.g. pagefile) on storage used by Hyper-V
• Test storage I/O configurations before deploying Virtual Machines
• Follow operating system Performance Tuning guidelines
• If you are running Anti-Virus software in the Parent partition, exclude either Hyper-V processes (vmms.exe or vmwp.exe) for Hyper-V file types (.vhd, .avhd, .vfd,.vsv, .bin and .xml )
• When using CSV LUNS, place virtual machine operating system files and data on different volumes
• And last (but not the least) consult your storage vendor.

1. For .NET 3.5 I took earlier in the fiscal year

2. For TFS 2010 Administration and Configuration I took recently.

Definitely feels good.

This attachment cleanup tool can be downloaded from the link below.

http://visualstudiogallery.msdn.microsoft.com/3d37ce86-05f1-4165-957c-26aaa5ea1010/ 

For some of the customers who use the advanced capabilities of TFS 2010, such as collecting diagnostic data from the Test runs, they come up with the issue of quick build up the TFS Database disk space. Depending on the volume of diagnostic data collected with each build, this can reach critical threshold levels very quickly.

Some of the general advice is as follows:

1. Decide if you must collect diagnostic data always.
2. If you must, then chose whether you or your team will benefit by collecting a subset of the possible types of diagnostic data, instead of all of it.

   The following types of data are collected for the full gamut, though this list is not completely exhaustive.

   TRX: for TRX files = Unit Test Results
   TR_: for intermediate TRX files = Unit Test Results
   iTrace: for IntelliTrace files = IntelliTrace/Historical Debugger files
   WMV/XESC/TRMX: for Windows Media Encoder or Expression Encoder Video files = Microsoft Test Runner video recordings
   XML: for Action Log, System Information files = Microsoft Test Runner action logs
   EVT: for Event Logs
   COV: for Code coverage files
   DLL/PDB files.

3. As you can see above this can quite quickly increase space consumption in the table tbl_attachmentContent for the collection under which you are running the build.

As it stands now, one has to do some amount of juggling and figuring out, where the right balance is with respect to collecting diagnostic data. There is no real prescriptive solution other than to arrive at the correct balance. The balance is a mixture of factors:

a) Deciding upon the correct set of data to collect.

b) Deciding when to collect. Should collection be part of a daily build? Should it be part of CI build? And so on.

c) Setting a scheduled task to go and cleanup the attachments on a regular basis.

Below I show a sequence to help understand the phenomenon. The following is a screen shot of the tbl_AttachmentContent table prior to invoking a build which contains tests that collect some data. The important data is of course the DataSpace which is 105.664 MB (Note that this is for a minimalistic demo and your specific instance might most probably have the data at another number).

I have created a simple ClasssLibrary and configured a few unit tests for the library.

I also created a build definition which includes the tests I created to be run as part of the build.

In my test settings file, I have turned on some level of collection, though not all of it. Depending on the nature of the application and as well as the anticipated level of data that the team feels that needs collecting, you might select a few OR even all of it (or close). This is where one needs to exercise caution and judgment in collection. Do you need some OR all of it?

After firing this build which also runs the tests, the size of the tbl_attachmentContent has gone up, as you can see below. As you can see the row count has increased to 182 from 167 and as well as the size has increased from 105.664MB to 105.727MB. This is only a small bump in this demo, due to the nature of my sample. But in most cases this bump could easily be a GB and more. It all depends on your test runs and the configuration you have for collecting the data.

The above is when the tests pass. Now if the tests fail, then more data gets gathered and stored, as you can see below when the tests fail. In this case I failed the tests and the row count has increased to 224 and the size has grown a lot more to 149.117 MB.

Now that the table has been shown to grow, let us proceed to see how to delete the data and reclaim space.

Here is where one would use the Test Attachment Cleanup tool. This tool is by default installed in the folder: C:\Program Files (x86)\Microsoft\Test Attachment Cleaner. This is available for download from: http://visualstudiogallery.msdn.microsoft.com/3d37ce86-05f1-4165-957c-26aaa5ea1010/ 

To run this tool fire up a command prompt and run it. Prior to this your team needs to carefully consider what you wanted deleted. There are several sample settings file in the “Sample Settings” folder.

For this demo I have adopted to delete all of the attachments that were created later to a particular point in time. That is all of the data created by the Build that ran the tests will be deleted.

Here is my settings file:

Basically any data that was collected after 5/30/2011 will be deleted.

The tool can be run with a preview mode, which will show all of the stuff that will get deleted without actually being deleted.

Here are the contents of the output1.txt which shows what will be deleted.

As you can see for a minimalistic test run I had done, there is so much of data collected. One can easily understand how for an involved test run, the amount of data collected will be quite huge. Make sure to view the preview data and confirm these are the things you want deleted.

Now to actually delete, one has to change the mode to “delete” as follows.

Once deleted, you can view the output file to see what was deleted.

Also going back to the collection database, and seeing the properties of the table, one can see that the size and row count had been reduced.

Running a query off of the tbl_attachmentContent table one can see there are no rows past the deletion criteria date of 2011-5-30 that we had set.

Also there are several other options possible. All of these are dealt with in the various samples settings file available as part of the download.

Finally if you prefer you can also set this to run a regularly scheduled NT Task to run periodically. It is also possible to make it as part of a Build by setting up a custom task in your build workflow.

This attachment cleanup tool can be downloaded from the link below.

http://visualstudiogallery.msdn.microsoft.com/3d37ce86-05f1-4165-957c-26aaa5ea1010/ 

For some of the customers who use the advanced capabilities of TFS 2010, such as collecting diagnostic data from the Test runs, they come up with the issue of quick build up the TFS Database disk space. Depending on the volume of diagnostic data collected with each build, this can reach critical threshold levels very quickly.

Some of the general advice is as follows:

1. Decide if you must collect diagnostic data always.
2. If you must, then chose whether you or your team will benefit by collecting a subset of the possible types of diagnostic data, instead of all of it.

   The following types of data are collected for the full gamut, though this list is not completely exhaustive.

   TRX: for TRX files = Unit Test Results
   TR_: for intermediate TRX files = Unit Test Results
   iTrace: for IntelliTrace files = IntelliTrace/Historical Debugger files
   WMV/XESC/TRMX: for Windows Media Encoder or Expression Encoder Video files = Microsoft Test Runner video recordings
   XML: for Action Log, System Information files = Microsoft Test Runner action logs
   EVT: for Event Logs
   COV: for Code coverage files
   DLL/PDB files.

3. As you can see above this can quite quickly increase space consumption in the table tbl_attachmentContent for the collection under which you are running the build.

As it stands now, one has to do some amount of juggling and figuring out, where the right balance is with respect to collecting diagnostic data. There is no real prescriptive solution other than to arrive at the correct balance. The balance is a mixture of factors:

a) Deciding upon the correct set of data to collect.

b) Deciding when to collect. Should collection be part of a daily build? Should it be part of CI build? And so on.

c) Setting a scheduled task to go and cleanup the attachments on a regular basis.

Below I show a sequence to help understand the phenomenon. The following is a screen shot of the tbl_AttachmentContent table prior to invoking a build which contains tests that collect some data. The important data is of course the DataSpace which is 105.664 MB (Note that this is for a minimalistic demo and your specific instance might most probably have the data at another number).

I have created a simple ClasssLibrary and configured a few unit tests for the library.

I also created a build definition which includes the tests I created to be run as part of the build.

In my test settings file, I have turned on some level of collection, though not all of it. Depending on the nature of the application and as well as the anticipated level of data that the team feels that needs collecting, you might select a few OR even all of it (or close). This is where one needs to exercise caution and judgment in collection. Do you need some OR all of it?

After firing this build which also runs the tests, the size of the tbl_attachmentContent has gone up, as you can see below. As you can see the row count has increased to 182 from 167 and as well as the size has increased from 105.664MB to 105.727MB. This is only a small bump in this demo, due to the nature of my sample. But in most cases this bump could easily be a GB and more. It all depends on your test runs and the configuration you have for collecting the data.

Now that the table has been shown to grow, let us proceed to see how to delete the data and reclaim space.

Here is where one would use the Test Attachment Cleanup tool. This tool is by default installed in the folder: C:\Program Files (x86)\Microsoft\Test Attachment Cleaner. This is available for download from: http://visualstudiogallery.msdn.microsoft.com/3d37ce86-05f1-4165-957c-26aaa5ea1010/ 

To run this tool fire up a command prompt and run it. Prior to this your team needs to carefully consider what you wanted deleted. There are several sample settings file in the “Sample Settings” folder.

For this demo I have adopted to delete all of the attachments that were created later to a particular point in time. That is all of the data created by the Build that ran the tests will be deleted.

Here is my settings file:

Basically any data that was collected after 5/30/2011 will be deleted.

The tool can be run with a preview mode, which will show all of the stuff that will get deleted without actually being deleted.

Here are the contents of the output1.txt which shows what will be deleted.

As you can see for a minimalistic test run I had done, there is so much of data collected. One can easily understand how for an involved test run, the amount of data collected will be quite huge. Make sure to view the preview data and confirm these are the things you want deleted.

Now to actually delete, one has to change the mode to “delete” as follows.

Once deleted, you can view the output file to see what was deleted.

Also going back to the collection database, and seeing the properties of the table, one can see that the size and row count had been reduced.

Running a query off of the tbl_attachmentContent table one can see there are no rows past the deletion criteria date of 2011-5-30 that we had set.

Also there are several other options possible. All of these are dealt with in the various samples settings file available as part of the download.

Finally if you prefer you can also set this to run a regularly scheduled NT Task to run periodically. It is also possible to make it as part of a Build by setting up a custom task in your build workflow.

This question has come up a few times, so I thought I might as well blog. How to connect to Team Foundation Server from the Test Management console.

You are connecting from MTM to TFS and you get the following error.

Unable to connect to the server <YourServerName>. Check that the server name is correct and that you have access to the server.

First check if your server version is 2010 or not. You cant use MTM to connect to a 2008 TFS Server. Assuming it is a 2010 Server, then you can carry out some of the steps below to get connected from MTM to TFS 2010.

Say for instance this is your TFS instance that you had connected to from Visual Studio Team Explorer Client.

So you go to the MTM Console and try to add the Server as follows, and click on Add.

You get this response, wondering what you did wrong.

Then you add the “TFS” at the end as follows:

And voila you are connected. And it lists you the Project Collection to pick and the Team Project to pick underneath it  as follows:

Click on the project you want to work on, and it should take you to the screen and you are on your way.

Sometimes you will get errors not connecting to the TFS Server. Most often this is due to wrong Server URL you specified. In such cases also try the method below.

The other way to connect from MTM to TFS: MTM command line

If you go the MTM installation folder, you can connect to TFS directly by using the command line invocation of MTM.

The easiest way to get to the correct Server URL that MTM needs is to go the Team Explorer in Visual Studio and copy and paste from there. See below for the Server Url in the properties window from where you C&P.

MTM is installed in the C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE folder, if you installed on the C:\ drive. So go to that in a command prompt and invoke MTM as follows: (contains two / switches /s for Server and /p for project – your might vary based on your URL and Project Collection)

This should take you to the screen for selecting a Test Plan if you already had one, or to add a new one if non existed for the Team Project that you had chosen, and you should be good to go.

Not only that, once you got the command-line working, you can convert it into a Desktop Shortcut and or a Taskbar item and always keep it ready to launch if you work with MTM a lot.

In my case the string I used for shortcut is exactly the same as in the command window. Please see below:

Basically you have to fill up the /s and the /p parameter arguments to MTM.

This question has come up a few times, so I thought I might as well blog. How to connect to Team Foundation Server from the Test Management console.

You are connecting from MTM to TFS and you get the following error.

Unable to connect to the server <YourServerName>. Check that the server name is correct and that you have access to the server.

First check if your server version is 2010 or not. You cant use MTM to connect to a 2008 TFS Server. Assuming it is a 2010 Server, then you can carry out some of the steps below to get connected from MTM to TFS 2010.

Say for instance this is your TFS instance that you had connected to from Visual Studio Team Explorer Client.

So you go to the MTM Console and try to add the Server as follows, and click on Add.

You get this response, wondering what you did wrong.

Then you add the “TFS” at the end as follows:

And voila you are connected. And it lists you the Project Collection to pick and the Team Project to pick underneath it  as follows:

Click on the project you want to work on, and it should take you to the screen and you are on your way.

Sometimes you will get errors not connecting to the TFS Server. Most often this is due to wrong Server URL you specified. In such cases also try the method below.

The other way to connect from MTM to TFS: MTM command line

If you go the MTM installation folder, you can connect to TFS directly by using the command line invocation of MTM.

The easiest way to get to the correct Server URL that MTM needs is to go the Team Explorer in Visual Studio and copy and paste from there. See below for the Server Url in the properties window from where you C&P.

MTM is installed in the C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE folder, if you installed on the C:\ drive. So go to that in a command prompt and invoke MTM as follows: (contains two / switches /s for Server and /p for project – your might vary based on your URL and Project Collection)

This should take you to the screen for selecting a Test Plan if you already had one, or to add a new one if non existed for the Team Project that you had chosen, and you should be good to go.

Not only that, once you got the command-line working, you can convert it into a Desktop Shortcut and or a Taskbar item and always keep it ready to launch if you work with MTM a lot.

In my case the string I used for shortcut is exactly the same as in the command window. Please see below:

Basically you have to fill up the /s and the /p parameter arguments to MTM.

This question has come up a few times, so I thought I might as well blog. How to connect to Team Foundation Server from the Test Management console.

Say for instance this is your TFS instance that you had connected to from Visual Studio Team Explorer Client.

So you go to the MTM Console and try to add the Server as follows, and click on Add.

You get this response, wondering what you did wrong.

Then you add the “TFS” at the end as follows:

And voila you are connected. And it lists you the Project Collection to pick and the Team Project to pick underneath it  as follows:

Click on the project you want to work on, and it should take you to the screen and you are on your way.

Sometimes you will get errors not connecting to the TFS Server. Most often this is due to wrong Server URL you specified. In such cases also try the method below.

The other way to connect from MTM to TFS: MTM command line

If you go the MTM installation folder, you can connect to TFS directly by using the command line invocation of MTM.

The easiest way to get to the correct Server URL that MTM needs is to go the Team Explorer in Visual Studio and copy and paste from there. See below for the Server Url in the properties window from where you C&P.

MTM is installed in the C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE folder, if you installed on the C:\ drive. So go to that in a command prompt and invoke MTM as follows: (contains two / switches /s for Server and /p for project – your might vary based on your URL and Project Collection)

This should take you to the screen for selecting a Test Plan if you already had one, or to add a new one if non existed for the Team Project that you had chosen, and you should be good to go.

Not only that, once you got the command-line working, you can convert it into a Desktop Shortcut and or a Taskbar item and always keep it ready to launch if you work with MTM a lot.

In my case the string I used for shortcut is exactly the same as in the command window. Please see below:

Basically you have to fill up the /s and the /p parameter arguments to MTM.

FunAnimalCards is an interactive application developed for toddlers to help them to explore and interactively discover animals and receive positive encouragement and feedback in the process of exploring. This is a free application.

Following are a few screen shots of the application.

The kid can discover what the animal is, and where to press among the various choices as well as the name of the animal spoken to him. This is just the first installment in this series. There are some more additions later on.

Enjoy the application, and let your kids have fun.This application is free. The ZUNE link to the application is:

zune://navigate/?phoneappid=33e04f85-f472-e011-81d2-78e7d1fa76f8

You can also search for it in the market place by the text “FunAnimalCards” and you should see it immediately.

One of our developers ( Remi )had passed this tip on how the TFS Application Tier cache settings are factored into the operations. Without this information some shops are left with the choice of just expanding disk space in a situation, where cache build up occurs but does not get cleared.

The following applies to the AT cache only (the real proxy is close but not identical as it does not have access to the TFS registry)

The TFS registry is the first place we look for settings:

·        /Service/VersionControl/Settings/FixedSizeBasedPolicy indicates a fixed size cache (in MB)

·        /Service/VersionControl/Settings/CacheLimitPercent is the alternative (i.e. % of the available disk space occupied rather than fixed size)

·        /Service/VersionControl/Settings/CacheDeletionPercent is how much of the cache should be deleted when the threshold is reached (think of it as hysteresis)

·        /Service/VersionControl/Settings/StatisticsPersistTime is how often the statistics file is saved to disk (not so interesting)

·        /Configuration/Application/DataDirectory indicates where the AT cache will live

We then validate those settings (or come up with default if not found).

·        If nothing is set, the default is CacheLimitPercent = 75%

·        If both CacheLimitPercent and FixedSizeBasedPolicy are set, FixedSizeBasedPolicy wins.

·        If CacheDeletionPercent is not set, it defaults to 20%

·        StatisticsPersistTime defaults to one hour (any value above one hour is acceptable).

·        DataDirectory can be overridden by adding a node in the web.config file like so (in which case it overrides the /Configuration/Application/DataDirectory setting):

<appSettings>

        <add key="applicationDatabase" value="Data Source=dbserverhere;Initial Catalog=Tfs_Configuration;Integrated Security=True;" />

        <add key="WorkItemTrackingCacheRoot" value="C:\Windows\Temp\TFTemp" />

        <add key="traceWriter" value="false" />

        <add key="traceDirectoryName" value="%TEMP%\\TFLogFiles" />

        <add key="applicationId" value="GUID here" />

        <add key="dataDirectory" value="E:\" />

    </appSettings>

Important considerations:

·        In an NLB environment, the TFS registry settings apply to ALL nodes, which is why the web.config settings take priority.

·        CacheLimitPercent is a bit misleading in that if you have a 100GB drive and 50GB of other

content, the TFS Cache can only use 50GB, so by default, the cleanup will occur when the cache reaches: (CurrentCacheSize + AvailableSpace) * (CacheLimitPercent / 100) = 50GB * .75  = 37.5 GB

·        The Cache Cleanup can take a long time (hours on a very large drive)  – so I would recommend changing the default Idle Time out on the Application pool to at least 60 minutes if you have a large cache and infrequent requests.

Caution: Be aware that doing this requires careful consideration and deliberate thought and proceed with systematic approach to tweaking the cache. I would try it on a test system OR change a few parameters (and not all at once) and iteratively reach a balanced approach.