Tuesday, December 2, 2014

TFS 2013.4, Team Fields, Test Plan Work Item Definition, and the quest for the missing backlog

At my current assignment we upgraded to TFS 2013.4 from TFS 2013.2 last night. Everything went swimmingly as expected with the install and the upgrade but when we went to look at the backlogs a configuration error showed up.

TF400917: The current configuration is not valid for this feature. This feature cannot be used until you correct the configuration.


Details about the validation error appear below:
  • The following element contains an error: TypeFields/TypeField[type='Team']. TF400517: The value of this element is set to: MyCompany.TeamField. You must set the value to a field that exists in all of the work item types that are defined in Microsoft.TestPlanCategory. The field does not exist in the following work item types: Test Plan.

For fun, I did follow the link it provided for additional detail but when looking at the error message it seemed fairly clear as I've dealt with something similar in the past regarding Team Fields.  

It is important to note that we have customized our process template (every time I say this, Angela's blood pressure goes up a little bit ;)) and as such that provides certain challenges when we upgrade. 

By default, the included process templates use the Area Path as the way to define teams and their associated backlogs.  However, if you are using the Area Path for another purpose in organization or work items, Microsoft did us a solid by allowing us to define another custom field for storing team association.  

One thing learned in the past is that in order for the Team Field to work correctly, it must exist in all work item definitions.  In the past (2013.2) it seemed to only affect the visibility of the items vs. causing an actual exception.  That has apparently changed in the most recent releases as seen with the error above.  

To solve the issue simple export the work item definition for a Test Plan work item type with something similar to.

witadmin exportwitd /collection:http://myservername:8080/tfs/DefaultCollection /p:MyProject /n:"Test Plan" /f:"TestPlan.xml"  

From here, make the same modifications you have in other work item types assuming you've already made these modifications to other work item definitions and not the Test Plan definition.  

<FIELD name="Team" refname="MyCompany.TeamField" reportable="dimension" type="String"></FIELD>

And the same for displaying that in the work item window.

<CONTROL emptytext="<None>" fieldname="MyCompany.TeamField" label="Team" labelposition="Left" type="FieldControl"></CONTROL>

Last step is to save and import the modified Test Plan work item definition.

witadmin importwitd /collection://http://myservername:8080/tfs/DefaultCollection /p:MyProject /f:"TestPlan.xml"

Refresh TWA and your backlog should be available again!

Note:, You may find that test plans are not listed in TWA under the Test navigation hub. This is likely because a known team is not assigned to the Test Plan.  To correct, simply find the test plan ID (which you can get from MTM), search this work item ID in TWA, and assign the appropriate team in the team field we just designated.  Refresh again, and your plans are available!



Thursday, November 20, 2014

The perfect storm: Windows 2012, UAC, and silent [un]installs with MSI

Over the past few months I've done a lot of work with the Microsoft Installer (MSI) platform and in that time spent many sleepless nights trying to figure out how to get valuable debugging information from rather cryptic error messages.  As such I've been labeled as the go-to resource for solving such obscure issues.

Recently one of my colleagues approached me asking for assistance with an issue she was having when trying to uninstall and subsequently re-install an MSI package via Release Management.  When they would run msiexec from the command line as the same account as the deployment agent, the command was successful, however when the agent attempted to do so, it came back with this vague error:

Error 1601: Windows Installer is not accessible

Not the most useful error message, so we started doing some debugging looking for the usual suspects including group membership, local security policy, and even if there was a pending reboot. Everything was in order.  Next step, grab some more debugging/logging information from the uninstall process using the built in logging mechanisms.

msiexec /x {79C635ED-150B-4DE7-92D2-522E1EDC1BC5} /quiet /lvx* c:\logfiles\uninstall-ffi.log

NOTE: I specify a directory called logfiles on the root drive because the msiexec.exe program is being executed from the working directory c:\windows\syswow64 and would have attempted to write the log file to that directory which would fail because of rights assignment (and it's a bad practice). You may need to assign additional permissions to this directory so all users (or at least your deployment agent account) can write to it.

The log file produced more information but still somewhat cryptic.

=== Verbose logging started: 11/20/2014  12:25:40  Build type: SHIP UNICODE 5.00.9600.00  Calling process: C:\Windows\SysWOW64\msiexec.exe ===
MSI (c) (2C:F8) [12:25:40:388]: Resetting cached policy values
MSI (c) (2C:F8) [12:25:40:388]: Machine policy value 'Debug' is 0
MSI (c) (2C:F8) [12:25:40:388]: ******* RunEngine:
           ******* Product: {79C635ED-150B-4DE7-92D2-522E1EDC1BC5}
           ******* Action: 
           ******* CommandLine: **********
MSI (c) (2C:F8) [12:25:40:388]: Client-side and UI is none or basic: Running entire install on the server.
MSI (c) (2C:F8) [12:25:40:388]: Grabbed execution mutex.
MSI (c) (2C:F8) [12:25:40:403]: Failed to connect to server. Error: 0x80070005

MSI (c) (2C:F8) [12:25:40:403]: Note: 1: 2774 2: 0x80070005 
1: 2774 2: 0x80070005 
MSI (c) (2C:F8) [12:25:40:403]: Failed to connect to server.
MSI (c) (2C:F8) [12:25:40:403]: MainEngineThread is returning 1601
=== Verbose logging stopped: 11/20/2014  12:25:40 ===

Notice the line that says Failed to connect to server. Error: 0x80070005. Some research shows us this is often an access denied error across many Microsoft products but as to what access is unclear. If you look deeper into the recesses of how the Windows Installer works you will see there is a service that is invoked and runs under the highest privileged account it can [SYSTEM]. In order to connect to the service the user must have elevated access rights, which our user did, so what gives?

However, with all the modern security standards in place to make sure you are actually doing something you intend to do, Windows 2012 will enforce UAC no matter if you are an administrator or not.  When running a silent install/uninstall you do not see the prompt and in turn, the engine fails with the cryptic 1601 - 0x80070005 error.

While likely not the most elegant of fixes, disabling UAC [via registry] on these servers seems to do the trick. TechNet provides a download to make this even easier.

Once the key was modified, we attempted to publish a release through RM again and the error was gone and deployment moved forward!

Sunday, March 30, 2014

Transforming a software company - Part 1: Tripping out of the gate

Some of you may wonder, "Where the hell has this guy been the past few months?"  At the very least you may wonder why all my emails are signed with my blog that hasn't really been updated since November when I (re-)released Team Explorer Build Tree in conjunction with fellow developer Josh Rack.  That little development ended up getting me invited to work on the future versions of Community TFS Build Extensions with Mike Fourie and Terje Sandstrom.

That's not what has had me in the weeds the past few months.  No sir/ma'am, it's a way more complex story than that.  Now that there is a little time and to prevent Angela and Chris from constantly saying "you should blog this...", I am.  Grab your smoking jacket, relax in your favorite arm chair, pour a tall glass of your favorite beverage and saddle up for this epic $^%&* tale.

We landed a contract for a large product distributor to do a TFS implementation and Agile transformation project with responsibilities split between myself and fellow Polaris cohort Angela Dugan.  My responsibilities included (yet not limited to) infrastructure setup of TFS, source migration, and developer training.  Angela had a little bit more involvement in doing the Agile transformation to the organization as a whole and using TFS to assist in managing that process.  It was also a chance for me to hone in on my consulting skills by shadowing Angela and establish credibility within my own organization.   

That was the plan...

Prior to consulting I worked in the bureaucratic world of financial IT. Forms and approvals, and approvals to fill out forms that get more approvals to talk to the guy next to you about getting a VM for a couple days to test on.  That would take 3 months.  Real servers?  They were top of the line when purchased, outdated when finally delivered.

Maybe that's exaggerating a little but for those that have been dared to explore this part of the IT universe knows this to be a long and often very frustrating process.  Add in some consultant that demands to have equipment yesterday and raises hell until it's provided just makes it worse.  I didn't want to be hated immediately, there was plenty of time for that later.  

Trying to be the good consultant I had several communications with the development manager prior to my first on-site visit.  Knowing that there was a parent organization and some sort of data center, I assumed the organization had at least had some process to provisioning production level servers.  I sent specifications based on the demand they had specified and reiterated the importance of having these ready the day I walk in.  This included active directory accounts and the permissions I needed for each account.  Simple right?    

Finally game day arrives, I was scheduled to be on site 4 days for 3 weeks.  Kiss the wife and kids goodbye, pack the truck, and head out on an 8 hour drive (I'm not a fan of flying) to St. Cloud, Minnesota.  

I arrive about 10pm, check-in to the hotel and go to catch up on what I've missed while travelling through northern Wisconsin (where Edge network is the only type of data you can get).  

This is where the first problem arrives.  I've forgotten my power supply.  I also learned that universal power supplies work with everything except the Lenovo W5XX series.  Fortunately, my boss had one dropped shipped to the hotel, would be there first thing Tuesday.  I could survive one day going back and forth between sleep mode, I'm sure this organization had a PC I could use temporarily if needed. I would later find out it wouldn't matter.  

The development manager (also a consultant) was not local either.  However, he flew in on Monday morning and always arrived to the office a little bit later.  I was instructed to do the same.  Cool beans, I forgot socks anyways and who doesn't love browsing Walmart at 8am?  Even grabbed the complimentary continental breakfast from the hotel.  

Around 10, the development manager arrives, makes a short introduction, grabs a few employees, a notepad, sits down ready to write and asks "Ok, so what types of servers do we need?"  

"You're kidding right?", I awkwardly laugh.  

No one else laughs.


I come to find out it's no joke.  With a quick interrogation I have a slight glimmer of hope of actually getting servers provisioned and ready in a short time (they had a Hyper-V farm in a shared data center) but we have to find the contact that does said provisioning.  We do!  

Within moments all hope is shattered as I find out there are in fact forms to be filled out.  Not only that, the lead time on new virtual machines was 4 weeks (which was a bit ridiculous), the more ridiculous part was it really took 6.  Yes, Hyper-V machines.   

Panicking ensued.  The company we were contracting to happened to be purchasing the source code from a 3rd party and as part of the cut over wanted a company owned repository to keep code in.  

On top of the acquisition the organization had contracted out to another development company in Chicago to do future development until a full time staff could be ramped up to do all development internally.  They were starting the following week and currently had no where to share code.  We were about to bring development to a grinding halt and burn a lot of cash really fast.  Not on my watch you don't...  

"Alright, I have an idea..."

I recommended we migrate the purchased source code to TFService and use that to continue development in the short term.  It only required a Windows Live ID and everyone was willing to work with that.  At the same time, when the servers were finally provisioned and I had set up TFS locally, we would implement the TFS Integration Platform (TIP) to continuously replicate changes from TFService -> On Premises for both source control and work item tracking.  Once everything looked clear on the local configuration, we'd throw the switch and cut over.  

That's when the real joyride began.  

In the following posts I will be covering a number of topics from the details behind our migration, challenges with project management, proper (more importantly improper) tactics for agile software development, process template customization, lab management, release management, TFS Event Workflows, ClickOnce Deployment, SpecFlow, SalesForce integration with TFS, WiX, and much, much, more.  


Until then, get some rest, wash your jacket, subscribe to my feed and come back for more later.