And the most ridiculous packaging award of the day goes to…

CPC who managed to send two resistor-capacitor balances for LED lights, which as about 1cm in size

in a box as shown here

image

Other than loads of that inflatable packing material there was a huge CPC catalogue, with the interesting sticker

image

So an online electronics company, that provides free shipping (a really good thing when the components were only a couple of £s), chose to also send a very heavy catalogue that they know is out of date, when I have already used their quick and easy web site.

You have to wonder why?

‘TF400499: You have not set your team field’ when trying to update Team Settings via the TFS API

I have recently been automating TFS admin processes such as creating a new team within an existing team project. The TFS team is now our primary means we use to segment work so we need to create new teams fairly often, so automation makes good sense.

As far as I can see, there are no command line tools, like TF.EXE or WITADMIN.EXE, to do most of the team operations. They are usually browser based. So I have been using PowerShell and the TFS API for the automation.

I hit the problem that when trying to save the team’s backlog iteration, iteration paths etc. for a newly created team using  the SetTeamSettings method. I was seeing

Exception calling "SetTeamSettings" with "2" argument(s): "TF400499: You have not set your team field."
At C:\Projects\tfs2012\TFS\PowerShell\Set-TfsTeamConfig.ps1:37 char:1
+ $configSvc.SetTeamSettings($configs[0].TeamId , $configs[0].TeamSettings)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : SoapException

This was strange as I had previously tested my PowerShell script file with hard coded values to update an existing team without error. When I inspecting the parameters being passed all looked OK, I had set a value for the team field and the read only property defining where to store the team data was correct (into the AreaPath).

After far to long I realised the problem was I had set the team field to the correct value e.g. ‘My project\My team’, but I had not created this area path before trying to reference it. Once I had created the required area path my scripted worked as expect.

So the TF400499 error is a little confusing, it does not mean ‘not set’ but ‘not set to a valid value’

Moving from Ubuntu to Mint for my TEE demos

I posted a while ago about the problems with DHCP using a Hyper-V virtual switch with WIFI and an Ubuntu VM, well I never found a good solution without hard coding IP addresses.

I recently tried using Mint 15 and was please to see this did not suffer the same problems, it seems happy with DHCP over Hyper-V virtual switches. I think I will give it a go a do a while for any cross platform TEE demos I need for a while.

Update: Just noticed that I still get a DHCP problem with Mint when I connect to my dual band Netgear N600 router via 2.4Ghz, but not when I use the same router via 5Ghz. I just know I am not at the bottom of this problem yet!

Where did that email go?

We use the TFS Alerts system to signal to our teams what state project build are at. So when a developer changes a build quality to ‘ready for test’ an email is sent to everyone in the team and we make sure the build retention policy is set to keep. Now this is not the standard behaviour of the TFS build alerts system, so we do all this by calling a SOAP based web service which in turn uses the TFS API.

This had all been working well until we did some tidying up and patching on our Exchange server. The new behaviour was:

  • Email sent directly via SMTP by the TFS Alert system  worked
  • Email sent via our web service called by the TFS Alert system disappeared, but no errors were shown

As far as we could see emails were leaving our web service (which was running as the same domain service account as TFS, but its own AppPool) and dying inside our email system, we presumed due to some spam filter rule?

After a bit of digging we spotted the real problem.

If you look at the advanced settings of the TFS Alerts email configuration it points out that if you don’t supply credentials for the SMTP server it passes those for the TFS Service process

image

Historically our internal SMTP server had allowed anonymous posting so this was not an issue, but in our tidy it now required authentication, so this setting became important.

We thought this should not be an issue as the TFS service account was correctly registered in Exchange, and it was working for the TFS generated alert emails, but on checking the code of the web service noticed a vital missing line, we were not setting the credentials on the message, we were leaving it as anonymous, so the email was being blocked

using (var msg = new MailMessage())
            {
                msg.To.Add(to);
                msg.From = new MailAddress(this.fromAddress);
                msg.Subject = subject;
                msg.IsBodyHtml = true;
                msg.Body = body;
                using (var client = new SmtpClient(this.smptServer))
                {
                    client.Credentials = CredentialCache.DefaultNetworkCredentials;
                    client.Send(msg);
                }

            }

Once this line was added and the web service redeployed it worked as expect again