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.

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.

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:

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:

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 ObjectSharp Podcast: Episode 001

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.

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.

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:

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.

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.

Cleanup the index data and remove/uninstall the ElasticSearch service.

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

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

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.

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.

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:

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.