A supported task execution handler was not found

If you're getting "A supported task execution handler was not found. The task does not carry an implementation that is compatible with your current operating system 'Windows(X86)'. Contact the task author for more details." error in your build or release pipelines in Azure DevOps, then it's most likely because you have a 32 bit version of the agent installed on 64 bit operating system. When that happens Agent.OSArchitecture build variable is mistakenly set to 32 instead of 64. To fix this issue, just install 64 bit version of the agent instead. That should fix the issue.

Hope this helps.

Migrating from TFS to Azure DevOps from behind a corporate proxy

If you're behind a corporate proxy and trying to migrate TFS to Azure DevOps using tfsmigrator.exe command, then most likely your tfsmigrator prepare command might fail with "AAD Timeout Exception" exception. This error means that the requests to AAD to find the matching AAD identities for users in your collection timed out. TfsMIgrator troubleshooting guide has a number of solutions that you can try to mitigate the issue. Depending on your environment those solutions might not work. At the moment, another possible solution is missing from this troubleshooting guide. This is what this blog post is about.

Another reason for AAD Timeout Exception is that you're running behind a corporate proxy. If you are using an outbound proxy for connecting to the Internet, the following setting in the C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config file must be added. This text must be entered at the bottom of the file. In this code, represents the actual proxy IP address or host name.

<system.net>

<defaultProxy>

<proxy

usesystemdefault="true"

proxyaddress="http://<PROXYADDRESS>:<PROXYPORT>"

bypassonlocal="true"

/>

</defaultProxy>

</system.net>

 

So, update your machine.config file, re-launch your command line and try tfsmigator prepare command one more time. It should work this time. Hope this helps.

Create Azure VM without a Public IP using Azure CLI

You really shouldn't create Azure virtual machines with public IP addresses unless you need it to communicate with outside world. Instead use VPN or ExpressRoute to connect to the virtual machine using private IP address. To create Azure VM without a public IP address using Azure CLI use the following command:

az vm create --resource-group TEST --name TESTVM --public-ip-address ""

Yes, just use empty quotes to create your VM without a public IP address. If you do not specify --public-ip-address option then Azure CLI will create a new public IP address and assign it to your VM.

Another gotcha is that the above-mentioned command only works if you run in in the command line or bash. If you're running your Azure CLI commands from within PowerShell, then you need to wrap empty quotes one more time. So the command will look as such:

az vm create --resource-group TEST --name TESTVM --public-ip-address '""'

Apparently, PowerShell swallows empty quotes and never passes them to Azure CLI command, so if you don't wrap the quotes again in PowerShell window, you will end up a virtual machine with a public IP address, which is frustrating.

Hope this helps.

P.S. : If you need your virtual machine to have a public IP address, please do not forget to secure that VM using network security group and such…

 

The Podcast

ObjectSharp started doing a podcast here is the first one.

The ObjectSharp Podcast: Episode 001

Cosmos DB: Everything you wanted to know about Microsoft Azure’s NoSQL Offering

Azure DevOps

VSTS gets a new look and name.

This morning Microsoft announced Azure DevOps, the next edition of VSTS. What’s different? It has a new look with better navigation. And you can pick and choose what parts you would like to use, getting the extra stuff you don’t use out of your way.

Select from

Azure PipelinesAzure pipelines – Previously Build & Release

Azure BoardsAzure Boards – Previously the Work hub (Backlogs and Boards)

Azure ArtifactsAzure Artifacts – Previously Packages (Nuget and NPM server)

Azure ReposAzure Repos – Git repos (TFVC is still supported too)

Azure Test PlansAzure Test Plans – Previously the Test hub (Test plans, Configurations etc)

Or use them all together for that wonderful integrated experience you only get from Azure DevOps.

Go hear for more explanation and a quick demo from Donovan Brown DevOps Manager 

VSTS and External Vendors

I thought I would try my hand at creating demo videos or specific topics around VSTS. One topic I get asked a lot is how to give VSTS access to an external Vendor so we can assign work items to them, yet keep them from seeing everything else.

Here is my first shot at such a Demo Video.

Configure TFS Search in Multi-Application Tier Scenario

If your TFS environment has multiple load balanced application tiers, then it's recommended to configure TFS Search (aka. ElasticSearch) on a separate server. That way you have a dedicated machine to index your TFS content. See https://docs.microsoft.com/en-ca/vsts/project/search/administration?view=vsts#separate-server for more information.

But, in some cases, dedicating a separate server just for search might be an overkill or inefficient. If you want to configure TFS search to run on one of the existing TFS application tiers, do the following:

If you're starting fresh:

  1. Setup Search (ES) using the Configure-TFSSearch.ps1 ("%Program Files%\Microsoft Team Foundation Server 2018\Search\zip\Configure-TFSSearch.ps1") script in one of the application tier servers. For example, App1 server.
  2. Configure Search suing the remote search option (even though search was setup in the same machine as AT) and use the http://{App1}:9200 URL.
  3. Make sure http://{App1}:9200 is accessible from all application tier servers.

Give it some time for search to index the TFS content.

   

If you already have search configured:

  1. Cleanup the index data and remove/uninstall the ElasticSearch service.
  2. Backup TFS Configuration database then delete the '%SearchPlatformConnectionString\%' entries from TFS configuration database. Obviously, be careful when making changes directly to the database. In the TFS Configuration DB, run the following query:
    SELECT * FROM [Tfs_Configuration].[dbo].[tbl_RegistryItems] where ChildItem like '%SearchPlatformConnectionString\%'

    You should see the RegValue entries as http://localhost:9200. Modify these registry values to http://{App1}:9200
  3. Configure Elastic Search using the Configure-TFSSearch.ps1 ("%Program Files%\Microsoft Team Foundation Server 2018\Search\zip\Configure-TFSSearch.ps1") script in one of the application tier servers again
  4. Cleanup all collection DB tables as mentioned here.
  5. Re-configure Search using the remote search option (even though search was setup in the same machine as AT) and use the http://{App1}:9200 URL.
  6. Make sure http://{App1}:9200 is accessible from all application tier servers.

This approach will re-index the collections again.

Hope this helps.

Error During TFS Search Configuration

If you're experiencing "VS403185: An unknown error has occurred during Search configuration" error when configuring search using TFS configuration wizard, then most likely you have attempted to configure search to run using a domain account. At this point, when using TFS Configuration wizard, search can only be configured to run as to run as NT AUTHORITY\NETWORK SERVICE. So, change the search service account to NT AUTHORITY\NETWORK SERVICE and things should go back to normal.

Obviously, you can still configure search in TFS 2018 with custom credentials for Elastic Search. You just need to configure search separately from application tier configuration. So, uncheck the Search configuration checkbox option in the TFS Configuration wizard and proceed. Once the TFS is configured, go to the Search tab and proceed with its configuration using custom credentials.

How to secure an external Vendors Access to VSTS/TFS

A lot of customers I work with have external vendors. They would like those vendors to have their own backlog of work we can assign to them. However they don’t want them to be able to see all the other work items, and sometimes Builds or Releases.

You can use Stakeholder access level. But sometimes that is too restrictive.

If you want them to have Basic or better access but limit their view.

  • Create a Team for the vendor and add all vendor resources to the team. If they don’t need a backlog and will just run queries for their work. you can just create a Group instead of a Team.
  • Make sure someone at your company is the team administrator.
  • From the Team project navigate to Control Panel -> Work -> Areas
  • Select the Main node in the Areas that is named after the Team Project
  • From the ellipsis context menu select security
  • Add the Team to this dialog and select Deny for all the items in the list

image

  • Save changes
  • Navigate to the node you want this vendor to be able to access work items for and select security
  • Select the External Vendor Group

image

  • Change their permissions for Edit work items in this node and View work items in this node to Allow.
  • Now this group can only see work items under the Area External Vendor

To make sure they can’t see Builds and Releases.

  • Navigate to Builds and click on the Security button at the top of the build list.
  • Set View Build definition and View Builds to Deny
  • For releases navigate to Releases and click the ellipses next to All Release definitions
  • Set View release definition and View release to Deny

image

image

Redirecting TFS traffic from /tfs to / root site

A while back I wrote a blog post on how to get rid of /tfs in TFS URL. Now, I would like to expand on that blog post and write about how to redirect TFS traffic from /tfs to / root of the site once you got rid of /tfs from the URL. To do that you need to do the following:

  1. Install URLRewrite module from https://www.iis.net/downloads/microsoft/url-rewrite
  2. Add the following section to the web.config of the TFS server

    <rewrite>

      <rules>

                <clear />

                <rule name="Redirect HTTP to HTTPS" enabled="true" stopProcessing="true">

                    <match url="(.*)" ignoreCase="true" />

                    <conditions logicalGrouping="MatchAll" trackAllCaptures="true">

                        <add input="{HTTPS}" pattern="off" />

                        <add input="{HTTP_HOST}" pattern="([^/:]*?):[^/]*?" />

                    </conditions>

                    <action type="Redirect" url="https://TFSURL.FQDN/{R:1}" appendQueryString="false" />

                </rule>

                <rule name="Redirect TFS traffic" stopProcessing="true">

                    <match url="tfs\/(.*)" />

                    <action type="Redirect" url="https:// TFSURL.FQDN /{R:1}" appendQueryString="false" />

                </rule>

      </rules>

    </rewrite>

 

First rule is redirecting all traffic to HTTPS, and second rule redirects all /tfs traffic to / root site of the TFS. If you don't have HTTPS, then simply remove the first rule and replace HTTPS with HTTP in the second. Obviously, replace TFSRUL.FQDN with your TFS public URL.