At last!  We can start talking about some of the cool new stuff in Visual Studio 11.  As many of you know, I have been busily working on Guidance that also has finally shipped!  Anywhere, where are some useful links to directly download both Windows 8 and Visual Studio 11!

http://blogs.msdn.com/b/visualstudio/
http://blogs.msdn.com/b/b8/archive/2012/02/29/welcome-to-windows-8-the-consumer-preview.aspx

Something else of note, with TFS11, there is a new version called TFS 11 Express, which is free for up to 5 users!  The users have to be “named” users, but it does provide a way to play with the product, without purchasing in.

-=-
Below is a list of all of the newly published Guidance, for your reference.  Many are still applicable to 2010 and 2008.

http://blogs.msdn.com/b/visualstudioalm/archive/2012/02/29/welcome-to-visual-studio-11-alm-rangers-readiness-beta-wave.aspx

The link above provides a link to the ALM Rangers page that has the release information.

I can be found listed as a contributor in several materials from these groups:

Visual Studio Architecture Tooling Guide
Visual Studio Lab Management Guide
Team Foundation Server Process Template Customization Guide
Team Foundation Server Upgrade Guide (reviewer)

Lately, we have been doing a lot of changes to our internal processes... something we noticed lately is that it would be useful to track the build-breakages seperately from bugs.  While they are bugs, they tend to require different attention that "regular" bugs (priority-wise, and sometimes even staff-wise).

Ultimately, we decided to treat a build failure as a different work item type so that it doesn't clutter the bug reporting and management that we do on a day-to-day basis.  As such, the simpliest way to do this was to clone the 'bug' work item type to make a 'build failure' Work Item Type. 

1. Export the Bug WorkItem Type

2. Rename the XML File exported to BuildFailure.xml

3. Modify the BuildFailure.xml to have a new Name/Description

<WORKITEMTYPE name="Build Failure"> <DESCRIPTION>Describes a failure that occurs during the Build and Build Verification Processes.</DESCRIPTION>

4. Import the new Work Item Type

5. Update your build process template, locate this snippet of code (in my template it was at about line 250)

<mtbwa:InvokeForReason DisplayName="Create Work Item for non-Shelveset Builds" Reason="Manual, IndividualCI, BatchedCI, Schedule, ScheduleForced, UserCreated"> <mtbwa:OpenWorkItem AssignedTo="[BuildDetail.RequestedFor]" Comment="["This work item was created by TFS Build on a build failure."]" CustomFields="[New Dictionary(Of String, String) From { {"System.Reason", "Build Failure"}, {"Microsoft.VSTS.TCM.ReproSteps", "Start the build using TFS Build"}, {"Priority", "1"}, {"Severity", "1 - Critical"} }]" DisplayName="Create Work Item" Title="[String.Format("Build Failure in Build: {0}", BuildDetail.BuildNumber)]" Type="["Bug"]" /> </mtbwa:InvokeForReason>

    Change the work item type to be 'Build Falure', or whatever name you specified in Step 3 above.

6. Update the Categories to indicate that Build Failure is a type of Category. 

• Export your categories

witadmin exportcategories /collection:%Collection% /p:%Project% /f:"C:\categories.xml"

• Modify the resulting categories.xml file as follows:

<CATEGORY name="Bug Category" refname="Microsoft.BugCategory"> <DEFAULTWORKITEMTYPE name="Bug" /> <WORKITEMTYPE name="Build Failure" /> </CATEGORY>

• Import the update category list

witadmin importcategories /collection:%Collection% /p:%Project% /f:"C:\categories.xml"

I generally place some of the more common commands in a batch file, then have another that sets up the target.  In this case, the target-setting batch file would have contents like this: 

Set Collection=http://TFSServer:8080/tfs/MyProjectCollection 
Set Project=MyProject

You can create a query that returns work items by category, for example after you have performed the above steps, a query that would return all of the Build Failures and bugs would look like this:

After we started using this for a while, we decided to change the Assigned To field so that it could contain the value of Not Assigned.  We also changed the Transition to the Resolved state to set the Assigned to to Not Assigned; the default behavior was to set it to the creator, but this would set it to the TFS Build Service Account, and that user is not part of the 'assignable' users.  We'll probably come back and revist this at a later time...

After spending about a week working on some client issues, I was finally able to resume working on configuring a Lab environment to use multiple Isolated Networks for CI Builds (more on that in another future post once I am satifsfied I have it working properly).  When I restarted the Lab Environment (which was working last week), I received errors indicating that the TFS service account was now somehow invalid.

Much to my dismay, I spent several hours trying to figure out what the happened.  After searching around in all the usual places, I had come up empty.  I could tell it was going to be a long night...

Before I explain how I corrected this issue, a little additional background will probably be helpful.  The Hyper-V hosts in this particular environment are in a separate domain, lets call it 'XPServerFarm', and the "normal" servers all run in a separate domain; lets call it 'business.local'.  There is a two-way full trust between the two domains.  I suspect that it is a pretty normal configuration, although it does provide some challenges sometimes when it comes to permissions.

Reading the error message details, it looked to me like the TFS Service account did not have permissions on the host, I signed onto the host that has the VMs on it, and checked the local administrators group.  The account was in it.  Lots of things went through my mind at this point; but I'll refrain from sharing some of those thoughts and instead focus on some of the things I tried. 

Testing this involved shutting down the lab environment, and starting it multiple times; each time waiting for the environment to "settle" into a final state, often times this can take as long as 10 minutes depending on what is configured on the various lab VM machines.

I removed the account from the administrators group and re-added it; I don't know what I expected, but there was no change in the behavior.  I looked at the server and it had been running for about 70 days; I decided that I would reboot it (this server is only for testing so why not?); again no change.  Honestly, I really didn't expect the behavior to change...  Then I opened up Active Directory FSMO for XPServerFarm, which also happened to be the server that these VMs were on, and verified that the Trust itself was still intact.

At this point I was starting to get concerned... perhaps the problems were because it was on the AD FSMO, but I continued down the path of the verifying account issue itself.  Finally, I decided to log into the server as the TFS service account... there had to be something I was missing, configuration-wise, but why would it show up now?  I Remote Desktop-ed directly to the Hyper-V host computer and...

I reconnected as a local administrator on the Hyper-V host. Sure enough, the time had drifted to be about 12 minutes difference between the two domains.  Interestingly I had previously setup the time synchronization but apparently there was a problem.  I checked the configuration, and I found that the Time Remaining was 0 when I used the command

w32tm /query /peers

I waited a bit, and executed the command again... no change.  I updated the Time Service on the Hyper-V host as follows. I decided to include the details because I ran into an issue here as well (nothing is ever easy).

I unregistered the the time service using this command:

w32tm /unregister

Then I rebooted. When the host came back up, I re-registered the time service using this command

w32tm /register

Followed by attempting to start the time service 

Net start w32time

I could not get the service to start.  I was getting an error indicating that there was some sort of SID issue because the processes running in the svchost were using incompatible SIDs.  System Error 1290. I hunted around the internet and found some nonsense posts about changing the tapiserver's registry entry... instead I looked at all of the registry entries and discovered that they were all running with the same type of account (LocalSystem, LocalService or NetworkService); so that obviously wasn't it.  I rebooted because I remembered reading somewhere that that way svchost initializes itself includes some sort of registration for the processes running inside svchost.exe.  After rebooting, the time service started, and the problems were gone.

Now, I configured the time service to use the same time servers as the Business.Local domain using these commands

W32tm /config /syncfromflags:manual /manualpeerlist:”0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org”
W32tm /config /reliable:yes
Net stop w32time
Net start w32time

Once completed, I issues these commands on both servers to make sure everything was working correctly.  

W32tm /config /update
W32tm /resync
Net stop w32time
Net start w32time

After waiting a few minutes, the time on the servers synced up and I was ready to continue. I went back to Lab Management Center and tried starting the environment.  After a period of time, the environment settled with this status:

After clicking Repair Testing Capability on the pull-down menu associated with the Testing Capabilities, I waited and was eventually greeted with a happy environment once again.