Developer Support Team Foundation Server https://review.docs.microsoft.com/archive/blogs/dstfs/feed.xml Tips, tricks, thoughts and experiences from the Microsoft Team Foundation Server global support team. Thu, 28 Feb 2019 18:37:26 GMT en-US hourly 1 Message in Test section of VSTS Team Project: "You can’t create test cases without a test plan. Click here to create a test plan." https://review.docs.microsoft.com/archive/blogs/dstfs/message-in-test-section-of-vsts-team-project-you-cant-create-test-cases-without-a-test-plan-click-here-to-create-a-test-plan Fri, 11 Aug 2017 22:33:26 GMT https://blogs.msdn.microsoft.com/dstfs/?p=2495 she was not seeing any there. Resolution: We had her go directly to a test plan\case URL that we knew was valid (obtained from one of her co-workers), like this: https://<Account>.visualstudio.com/<Team Project>/_testManagement?planId=193&suiteId=194&_a=tests. After she did that her Test section refreshed and her view matched that of her teammates. We speculate that the issue was created by invalid registry entries for the last selected test plan and plan filter query.  In this case going to a valid test plan URL refreshed the registry with the correct setting and showed the filter applied to the test plans. She was able to access the test hub home page afterward. HTH Trev      ]]> Troubleshooting connections from Eclipse + Team Explorer Everywhere to Visual Studio Team Services https://review.docs.microsoft.com/archive/blogs/dstfs/troubleshooting-connections-from-eclipse-team-explorer-everywhere-to-visual-studio-team-services Thu, 03 Aug 2017 21:29:23 GMT https://blogs.msdn.microsoft.com/dstfs/?p=2425 Today's post (his first!) comes from my Customer Service & Support colleague Manuel Galindo. Using Eclipse and Team Explorer Everywhere (TEE) to connect to Visual Studio Team Services (VSTS) from Windows is a common scenario but sometimes the normal installation does not work as expected. Sometimes the authentication is made in different ways - ADFS, Certificate SSO, Physical Credentials + PIN, etc. -  and the login is not successful. Here are the 2 potential workarounds for this issue:
  • Use OAuth Device Flow authentication
  • Manually obtain a VSTS Personal Access Token (PAT) for the VSTS account and store it in Windows Credential Manager as the account’s credential
 

Enable OAuth Device Flow authentication

To use OAuth Device Flow, you should enable it in the JVM that runs Eclipse IDE. 1. Add the following line to the bottom of the eclipse.ini file, which is located under the user profile folder in Windows (for example: C:\Users\USERNAME\eclipse\java-neon\eclipse): 
-DuserAgentProvider=none
2. Restart Eclipse and then try to connect to VSTS again. When you try to login, you will see a dialog window like this:                     3. Click the URL (https://aka.ms/devicelogin) and you will see a screen like the one below. Copy the code from Eclipse and and paste it into this dialog. Confirm the app, which should be Visual Studio Team Services, and then complete the login from the browser.  After you do, back in Eclipse you should click OK on the code dialog and then you will be logged in to \ connected to VSTS!          

Personal Access Token (PAT) in Windows Credential Manager

If you don't have PAT for your VSTS User ID yet, use a browser to connect to your VSTS account and create a PAT (see https://www.visualstudio.com/en-us/docs/setup-admin/team-services/use-personal-access-tokens-to-authenticate for details). If you're going to use the token with TEE, make sure you've created an All Scopes token. Copy the token into a text file, a OneNote, etc. so you can access it later (you won't be able to ever see it again inside VSTS). 1. Open Windows Control Panel and then open the Windows Credentials part of Credentials Manager:               2. Click "Add a generic credential":     3. Fill in the new Generic Credential as below with the following and then click OK to save it:
  • VSTS account domain
  • A user name. This can be anything really since we're using a PAT we don't need a specific name here
  • Your password, which is the PAT you generated earlier (and saved to OneNote, right? <g>)
Restart Eclipse, which should automatically use the above configured PAT for authentication and connect you right up to VSTS.                ]]> Limit access to just Visual Studio Team Services using Azure Active Directory Premium https://review.docs.microsoft.com/archive/blogs/dstfs/limit-access-to-just-visual-studio-team-services-using-azure-active-directory-premium Thu, 27 Jul 2017 14:58:30 GMT https://blogs.msdn.microsoft.com/dstfs/?p=2375 You'll need:
  • An Azure subscription
  • AAD Premium (you can get a trial if you just want to try this out)
  • A VSTS account backed by the Premium AAD
  • An external user you can invite to your AAD \ VSTS (someone not native to the AAD)
  Here's how I set up a demo (pictures below, too):
  1. In Portal.Azure.com, enabled AAD Premium on ConditionalVSTS.onmicrosoft.com
  2. Created a native AAD user - ROOT@ConditionalVSTS.onmicrosoft.com - who was a global admin
  3. Invited SomeExternalDude@Outlook.com to the AAD and accepted that invite via mail at Outlook.com
  4. Back in Portal.Azure.com, created an AAD group named "B2B Users" and added SomeExternalDude@Outlook.com to it
  5. Logged into aka.ms/getvsts as ROOT@ConditionalVSTS.onmicrosoft.com and created a new VSTS account. Because I logged in there as a member ConditionalVSTS.onmicrosoft.com, my new VSTS was backed by that AAD when it was created.
  6. Logged into my VSTS as ROOT@ConditionalVSTS.onmicrosoft.com (the owner) and added SomeExternalDude@Outlook.com to it, on the Users Hub
  7. In a different browser (not another instance, but another software browser) I logged into VSTS as SomeExternalDude@Outlook.com successfully. This was just to confirm all was working up to this point.
  8. Back in AAD on Portal.Azure.com I set up a new Conditional Access Policy designed to permit SomeExternalDude@Outlook.com to *only* access VSTS. Screen shots below.
  9. With the Conditional Access Policy enabled, back in my VSTS browser instance as SomeExternalDude@Outlook.com I signed out and then tried to sign back in. Still worked.
At this point you might be wondering what's the point? Well, to see what happens when VSTS & Microsoft Azure Management are *not* included in the exceptions list for that Conditional Access Policy, edit it and remove them. The next time any member of the "B2B Users" group tries to log into a VSTS account backed by that AAD they'll see something like the message pictured below ("You don't have access to this"). You can use a variation on this process to let AAD groups into only VSTS, or let them into everything but VSTS. I hope you find this helpful. --TrevorH   References:                                
 

Azure AD Conditional Access Policy to let members of AAD group "B2B Users" access *only* VSTS

    ]]> How To Checkin Files To 2 TFVC Projects At The Same Time https://review.docs.microsoft.com/archive/blogs/dstfs/how-to-checkin-files-to-2-tfvc-projects-at-the-same-time Tue, 21 Mar 2017 19:29:44 GMT https://blogs.msdn.microsoft.com/dstfs/?p=2165 3/21/2017

Jeff here from the VSTS support team. Someone asked how to map 2 VSTS TFVC Projects so we can checkin files to both projects at the same time. They wanted to see how TFVC/VSTS shows 2 projects for the same checkin notification(in particular, the teamProjectIds field). We can easily see that with a Web Hook Service Hook when we link our VSTS account to RequestBin for checkin notifications. snap002056 snap002057 snap002058 Let’s connect to the first VSTS TFVC Project in Visual Studio: snap002059 And map it to a folder underneath a folder that will be the root for both the TFVC projects we are going to checkin changes together for. I added TFVC to the default path, so I know these TFVC projects are together. snap002060 Now let’s go to Source Control Explorer to map the second TFVC project: snap002061 snap002062 After we map it, we can create some files to get checked in. snap002063 snap002065 And then add them to Source Control: snap002064 snap002066 Here are the files waiting to be checked in: snap002067 snap002068 Here are the pending changes waiting to be checked in: snap002069 Here is the resulting checkin for those 2 files in 2 projects: snap002070 Here is the full XML for the checkin: "subscriptionId":"61a792ce-9ddc-40a5-811e-0640ab08800f","notificationId":1,"id":"6eb85409-f7b7-4fc0-bc4d-aac5bca1fb05","eventType":"tfvc.checkin","publisherId":"tfs","scope":"all","message":{"text":"VSTS Blog checked in changeset 8: VSTS-Blog - Double Checkin","html":"VSTS Blog checked in changeset <a href=\"https://vsts-blog.visualstudio.com/web/cs.aspx?pcguid=9a0adf58-227a-4bce-adc9-f5450850aad6&amp;cs=8\">8</a>: VSTS-Blog - Double Checkin","markdown":"VSTS Blog checked in changeset [8](https://vsts-blog.visualstudio.com/web/cs.aspx?pcguid=9a0adf58-227a-4bce-adc9-f5450850aad6&cs=8): VSTS-Blog - Double Checkin"},"detailedMessage":{"text":"VSTS Blog checked in changeset 8: VSTS-Blog - Double Checkin","html":"VSTS Blog checked in changeset <a href=\"https://vsts-blog.visualstudio.com/web/cs.aspx?pcguid=9a0adf58-227a-4bce-adc9-f5450850aad6&amp;cs=8\">8</a>: VSTS-Blog - Double Checkin","markdown":"VSTS Blog checked in changeset [8](https://vsts-blog.visualstudio.com/web/cs.aspx?pcguid=9a0adf58-227a-4bce-adc9-f5450850aad6&cs=8): VSTS-Blog - Double Checkin"},"resource":{"hasMoreChanges":true,"teamProjectIds":["0695931c-21c0-47e6-904c-add0c2d1527f","83416a37-d523-417c-93a2-b8bf6dee7e4b"],"changesetId":8,"url":"https://vsts-blog.visualstudio.com/_apis/tfvc/changesets/8","author":{"id":"d24ac5a3-ae7e-6858-8bff-2ae8420c64be","displayName":"VSTS Blog","uniqueName":"VSTS-Blog@outlook.com","url":"https://app.vssps.visualstudio.com/A958272a6-6094-4330-aaa1-23c3b9b80363/_apis/Identities/d24ac5a3-ae7e-6858-8bff-2ae8420c64be","imageUrl":"https://vsts-blog.visualstudio.com/_api/_common/identityImage?id=d24ac5a3-ae7e-6858-8bff-2ae8420c64be"},"checkedInBy":{"id":"d24ac5a3-ae7e-6858-8bff-2ae8420c64be","displayName":"VSTS Blog","uniqueName":"VSTS-Blog@outlook.com","url":"https://app.vssps.visualstudio.com/A958272a6-6094-4330-aaa1-23c3b9b80363/_apis/Identities/d24ac5a3-ae7e-6858-8bff-2ae8420c64be","imageUrl":"https://vsts-blog.visualstudio.com/_api/_common/identityImage?id=d24ac5a3-ae7e-6858-8bff-2ae8420c64be"},"createdDate":"2017-03-21T17:30:25Z","comment":"VSTS-Blog - Double Checkin"},"resourceVersion":"1.0","resourceContainers":{"collection":{"id":"9a0adf58-227a-4bce-adc9-f5450850aad6","baseUrl":"https://vsts-blog.visualstudio.com/"},"account":{"id":"958272a6-6094-4330-aaa1-23c3b9b80363","baseUrl":"https://vsts-blog.visualstudio.com/"}},"createdDate":"2017-03-21T17:30:29.0671123Z"} /Jeff Happy Developing!]]> Set Service Hooks permissions on existing projects” is failing with “ExtensionNotFound” https://review.docs.microsoft.com/archive/blogs/dstfs/set-service-hooks-permissions-on-existing-projects-is-failing-with-extensionnotfound Thu, 26 Jan 2017 01:42:46 GMT https://blogs.msdn.microsoft.com/dstfs/?p=2135 GIT clone SSH CI build issue in TFS 2015.3 https://review.docs.microsoft.com/archive/blogs/dstfs/git-clone-ssh-ci-build-issue-in-tfs-2015-3 Fri, 06 Jan 2017 11:23:03 GMT https://blogs.msdn.microsoft.com/dstfs/?p=2035 Issue: In TFS 2015.3, if you have setup a CI build defection for a GIT repository and if you clone the repository using SSH and then do a GIT push, the builds are not getting triggered. Error messages: There are no error messages generated. But, there is not CI build triggered as well. Diagnosis: Consider the following scenario.  
  • You have a TFS 2015.3 server, in which you have a GIT repository.
  • You have created a CI build definition for this repository.
  • You clone the GIT repository to your local folder, using the normal http or https clone. Then, you do some change and push the changes. You will notice a CI build is triggered.
  • Now, you clone the same GIT repository to your local folder, using the SSH clone ( steps here à https://www.visualstudio.com/en-us/docs/git/use-ssh-keys-to-authenticate).
  • Now, if you do some changes and then push it, no CI build will be triggered.
  Solution: This is a bug with TFS 2015.3 and it is fixed in TFS ‘15’. However, can use the below steps to resolve the issue in TFS 2015.3.  
  • Navigate to the path ‘C:\Program Files\Microsoft Team Foundation Server 15.0\Application Tier\Web Services\bin’ on your TFS application server.
  • Identify the file named ‘TeamFoundationSshService.exe.config’. Save a copy of the file in a separate location, as a backup.
  • Then, add the below lines in the file, within the tag <assemblyBinding>
<dependentAssembly> <assemblyIdentity name="Microsoft.Data.OData" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="5.6.0.0-5.6.4.0" newVersion="5.6.4.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="Microsoft.Data.Edm" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="5.6.0.0-5.6.4.0" newVersion="5.6.4.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Spatial" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="5.6.0.0-5.6.4.0" newVersion="5.6.4.0" /> </dependentAssembly>  
  • Go to ‘Services’ and restart the service named ‘Team Foundation Ssh Service’
  • If you have multiple TFS application server, you will have to perform the steps in all of them.
  • Do a fresh SSH clone and then make changes and push them and check if CI build is getting triggered.
Note: This is applicable only for closing GIT repository using ‘git clone ssh’. For any other issues, or if the issue is present even after applying the above steps, please open a support case with Microsoft. Written by: Sivarajaguru, Support Engineer, Team Foundation Server Support Team Reviewed by: Nitish Nagpal, Support Escalation Engineer]]> Test Management Warehouse Adapter – General issues and their resolutions https://review.docs.microsoft.com/archive/blogs/dstfs/test-management-warehouse-adapter-general-issues-and-their-resolutions Wed, 28 Dec 2016 19:42:29 GMT https://blogs.msdn.microsoft.com/dstfs/?p=2015 TFS warehouse is a critical component of On-Prem TFS reporting stack as it enables reporting based on common dimensions across different stages in the Team Project lifecycle. Data in the TFS warehouse flows from collection databases through a set of adapters. In TFS 2015 Update 3, we fixed key performance issues in Test Management Warehouse Adapter to make it more reliable and fast. However, SQL performance depends a lot on the data shape and size of the store and you could still face issues when the warehouse is updated. Such issues generally surface during warehouse rebuild or if the adapter hasn’t run for a long period and a lot of data has to be processed into warehouse. The focus of this blog post is on diagnosing general timeout issues with Test Management Warehouse adapter and on their resolutions. Note that while the resolutions mentioned in this blog post will help fix the adapter timeout issues, it is strongly recommended to avoid the problem itself by getting rid of unwanted\old test management data with help of test results data retention which is available in TFS 2015 RTM and newer versions.

Note: Test Management Warehouse adapter works on SQL Server Rowversion logic. Since last sync, if there is any change in a test management record in collection database, it will sync the change to warehouse. In TFS 2017 RTM, the schema of multiple test management tables has been revamped to optimize on storage space and performance. During upgrade to TFS 2017 RTM, the existing test management data gets migrated to the new schema causing change in the rowversion associated with almost all the test management records in collection databases. Test management adapter sees this as a new change and tries to sync all the records again to warehouse which can be time consuming. At present no warning is shown to the user during pre-upgrade steps about this behavior. It will be fixed in newer versions of TFS. To avoid this it is recommended to sync warehouse fully before starting the upgrade. This scenario has been handled and will not cause migrated rows to sync again to warehouse.

Common timeout issues with test management adapter & their resolutions

Test artifacts get synced to warehouse in batches. Batch size for a test artifact is configurable and can be increased (or decreased) to process more (or less) data in a single iteration. While processing more data in a single batch is desirable as it will reduce the number of iterations required to sync whole data and hence should enhance adapter’s performance, it may not turn out that way as higher batch size will increase SQL transaction size which in turn will consume more CPU and memory thus leading to thrashing and overall system performance degradation. On the other hand having a very small batch size will increase the number of iterations required to process whole data which can be very time consuming. Thus batch size should be set to an optimal value which will cause less iterations and also keep memory and CPU requirements under check. For test management adapter, timeout generally occurs when current batch of data under processing is leading to large SQL transaction size. Workaround is to reduce appropriate batch size temporarily till adapter processes the data fully once. After that, batch size can be reset back to the default value. Batch sizes for different test artifacts are stored as key value pairs in warehouse database. Batch size key is different for each test artifact. Appropriate batch size key needs to be tweaked depending upon the artifact being processed during timeout. For a batch size key, selection of appropriate batch size value is an iterative process. It is recommended to reduce this value by an order of 10 at a time and retry test management adapter processing till it succeeds. E.g.: 1000, 100, 10, 1. Note that test management adapter batch size settings will not affect other adapters in any way. Thus test management adapter timeout issues resolution is a two-step process:
  1. Select appropriate batch size key to be reduced: Can be determined by looking at the stack trace. Check section ‘Test Management adapter timeout scenarios’ for details
  2. Set batch size value: Check section ‘SQL queries to set test management adapter batch size value’ for details
Note: During adapter timeout, following error message is received: Exception Message: TF246018: The database operation exceeded the timeout limit and has been cancelled. Verify that the parameters of the operation are correct. (type DatabaseOperationTimeoutException) Steps to obtain error message and stack trace are available in attached file: DiagnosticInformation.zip

Test Management adapter timeout scenarios

1. Timeout during test results processing Typical stack trace: at Microsoft.TeamFoundation.TestManagement.Warehouse.WarehouseResultDatabase.QueryTestResults(SqlBinary watermark, Int32 limit, ProcessRowCallback resetCallback, ProcessMappingDataCallback dataCallback, ResolveIdentities resolveIdentitiesCallBack) …Resolution: Reduce test results processing batch size (default = 2000) at Microsoft.TeamFoundation.TestManagement.Warehouse.TeamTestWarehouseAdapter.QueryForResults(WarehouseResultDatabase wrd, SqlBinary waterMark, Int32 limit) … Batch Size Key: /Adapter/Limit/TestManagement/FactTestResult 2. Timeout during test point processing Typical stack trace: … at Microsoft.TeamFoundation.TestManagement.Warehouse.WarehouseResultDatabase.QueryTestPointData(SqlBinary watermark, SqlBinary endWatermark, int limit,                                     IEnumerable<IdToAreaIteration> areaIterationMap, ProcessRowCallback deletedCallback, ProcessMappingDataCallback addedCallback, ResolveIdentities resolveIdentitiesCallBack) at Microsoft.TeamFoundation.TestManagement.Warehouse.TeamTestWarehouseAdapter.QueryForTestPoints(WarehouseResultDatabase wrd, SqlBinary waterMark, Int32 limit) … Resolution: Reduce test point processing batch size (default = 10000) Batch Size Key: /Adapter/Limit/TestManagement/FactTestPoint 3.  Timeout while processing deletes Typical stack trace: ... Microsoft.TeamFoundation.Warehouse.WarehouseDataAccessComponent.DestroyResults(String projectId String data ResultDeletionFormat format Int32 limit)   at Microsoft.TeamFoundation.TestManagement.Warehouse.TeamTestWarehouseAdapter.ProcessRunDeletes(IWarehouseDataAccessComponent dac ObjectTypes objectType)   at Microsoft.TeamFoundation.TestManagement.Warehouse.TeamTestWarehouseAdapter.DeleteTcmObject(IWarehouseDataAccessComponent dac ObjectTypes objectType Boolean deleteResults) … Resolution: Reduce test run deletion batch size (default = 10) Batch Size Key: Adapter/Config/TestManagement/RunDeleteBatchSize

SQL queries to set test management adapter batch size value

Following are the set of queries to achieve this. Execute them against the warehouse database. Note: These settings will not affect ongoing test management warehouse job processing if any. They will come into effect from next invocation of the adapter. DECLARE @PropertyScope NVARCHAR(256) = NULL –-NULL implies that property is applicable for all collections. --SET it to collection GUID for a particular collection. --To obtain Collection GUID, run following query against TFS Configuration database: --SELECT HostId as CollectionGuid, Name as CollectionName FROM tbl_ServiceHost DECLARE @BatchSizeKey NVARCHAR(256) = <Select appropriate batch size key. Check section Test Management adapter timeout scenarios for details> DECLARE @BatchSize INT = 0 -- Dump current settings for backup (Save this for reverting back later) -- If query returns 0 rows, it means default value is in use. Hence at the end   -- this key can be deleted to restore the default setting EXEC [dbo].[prc_PropertyBag_Get] @Property_Scope = NULL, @Property_Key = @BatchSizeKey, @Property_Value = @BatchSize OUTPUT SELECT @BatchSize SET @BatchSize INT = 100 --Set batch size to an appropriate value lower than the default. --It is recommended to reduce this by an order of 10 at a time and retry completing the --test management adapter processing. E.g.: 1000, 100, 10, 1 --Update batch size for the job step EXEC [dbo].[prc_PropertyBag_Set] @Property_Scope = NULL, @Property_Key = @BatchSizeKey, @Property_Value = @BatchSize -- DO THIS AFTER RESOLVING ISSUE: -- After the warehouse full processing is complete, subsequent processing is incremental   -- only. We can now revert batch size to factory settings (run this if all is well) -- Run this query on the warehouse to see the batch size configurations potentially set --- as workaround EXEC [dbo].[prc_PropertyBag_Get] @Property_Scope = NULL, @Property_Key = @BatchSizeKey, @Property_Value = @BatchSize OUTPUT SELECT @BatchSize -- For the ones identified in the last query, use the query below to delete them and -- reset to factory settings. EXEC [dbo].[prc_PropertyBag_Delete] @Property_Scope = NULL, @Property_Key = @BatchSizeKey Tip: Supported only in TFS 2015 Update 3 and newer versions In case there is no requirement to report on code coverage data, then it can be turned off (default is ON) completely in the test adapter by executing following query against warehouse database: INSERT INTO _PropertyBag VALUES(NULL, '/Adapter/Config/TestManagement/CodeCoverageProcessingEnabled', 'false') –‘true’ to enable Above query will disable code coverage processing for all the collections. To disable it for specific collections, run following query for each collection: INSERT INTO _PropertyBag VALUES(‘Collection Guid’, '/Adapter/Config/TestManagement/CodeCoverageProcessingEnabled', 'false') --‘true’ to enable Collection Guid can be obtained by running following query against TFS Configuration database: SELECT * FROM tbl_ServiceHost Value of ‘HostId’ column is the collection GUID for a collection Note that, running above queries will not affect code coverage data in the collection databases. It will simply stop code coverage data sync in the warehouse. It can be turned on any time by executing above queries with value: ‘true’. Also note that these settings will not affect ongoing test management warehouse job processing if any. They will come into effect from next invocation of the adapter. For any other issues with test management warehouse adapter, capture diagnostic data as mentioned in attached file DiagnosticInformation.zip and contact Microsoft support team.

Important points regarding warehouse rebuild

  1. In several warehouse issues reported by users, we found that during event of a warehouse job failure, they trigger warehouse rebuild hoping that it will resolve the problem. While it might work but it is not a recommended solution as it can take considerable time to sync whole data and the job can fail again with same problem. In such cases if it is a timeout issue with test management warehouse adapter then follow the resolution mentioned in this blog else reach out to Microsoft support team.
  2. It is often a confusion on whether to rebuild warehouse during TFS upgrade - whether to an RTM version or to an update. Note that if a rebuild is required then it gets triggered  automatically during upgrade. User doesn’t need to initiate it explicitly.
Written and Reviewed by: Shyam Gupta diagnosticinformation]]> VSTS Test runs reporting inconsistent count of tests run with each build https://review.docs.microsoft.com/archive/blogs/dstfs/vsts-test-runs-reporting-inconsistent-count-of-tests-run-each-build Wed, 21 Dec 2016 17:16:13 GMT https://blogs.msdn.microsoft.com/dstfs/?p=1997 Issue: While executing unit tests as a part of CI, we see issues with the count in build results page. In our scenario we had C# tests as well as Gulp tests and after the build completes successfully we found that test results in build summary page do not give the exact count of the tests executed which is 184[111 C# tests and 73 gulp tests] but the values are 2 x C# tests + JS unit tests a Cause: The vstest task automatically publishes the results. The additional publish task just publishes the duplicate results from the vstest task. Each task in build is independent and so ultimately the build results takes the aggregation results from each step. Solution: Removing the publish test results task should not cause this issue. Written by: Deepak Kumar Mishra, Support Engineer Reviewed by: Deepak Mittal, Escalation Engineer]]> TFS Reporting database backup fails with TFS Backup tool https://review.docs.microsoft.com/archive/blogs/dstfs/tfs-reporting-database-backup-fails-with-tfs-backup-tool Mon, 12 Dec 2016 13:46:34 GMT https://blogs.msdn.microsoft.com/dstfs/?p=1976 Issue Details: Reportserver and Reportservertempdb backup with TFS backup tool fails with the following errors. TF400981: Failed to backup the Reporting Services encryption key. You can try using RSKEYMGMT command to backup the encryption key ikey Cause It was due to the implementation of firewall infrastructure which did not allow WMI Queries which is being used by TFS backup tool in the background. Troubleshooting:
  1. We took backup of encryption key as mentioned in the warning message but this did not help.
  2. So we took a debug view trace and got the following COM exception:00000799             157.66336060     [4692] [Verbose@14:25:37.059] Caught COMException attemping WMI connect(). The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)                            00000800             178.42982483     [4692] [Verbose@14:25:58.106] Caught COMException attemping WMI connect(). The RPC server is unavailable. (Exception from HRESULT: 0x800706BA) 00000798             136.35156250     [4692] [Verbose@14:25:16.028] Caught COMException attemping WMI connect(). The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)           
  3. This helped in identifying that this issue is mainly due to blocking of the WMI requests in the background.
  4. We checked and found that the Microsoft firewall was off but on digging deeper found that there was a third party firewall hardware available in this case which blocked all requests.
Resolution:
  1. WMI uses ports 135 and also the range of ports between 49152-65535.
  2. We opened port 135 and 49154 which was identified by network monitoring and this resolved the backup issue. It might happen that some other ports from the mentioned range might be used by WMI where this solution might not work. In that case the recommended approach is to make sure that WMI uses only one port by configuring it as mentioned in the following article: https://msdn.microsoft.com/en-us/library/bb219447(v=vs.85).aspx
 Written by: Deepak Mishra, Support Engineer  Reviewed by: Nitish Nagpal, Support Escalation Engineer]]> Fatal problem when pushing huge repository to TFS GIT https://review.docs.microsoft.com/archive/blogs/dstfs/fatal-problem-when-pushing-huge-repository-to-tfs-git Mon, 12 Dec 2016 07:34:22 GMT https://blogs.msdn.microsoft.com/dstfs/?p=1956 Deepak Kumar Mishra, Support Engineer, EMEA TFS Team, brings this knowledge experience while working with one of his customers and this important piece of information might help a lot of users who are using Git repos in tfs and face issue while performing a push operation. Issue Description: A Customer is trying to push an 18GB Git repository in TFS 2015 Update 3. It worked locally to a local server - but we cannot get it to push to our global TFS server. While pushing the repository via SSH, we get the following errors in a Linux machine: [xxxx@servername]$ grep tfs .git/config url = ssh://tfs. servername:22/tfs/collection/teamproject/_git/repo [xxxx@servername]$ git push Counting objects: 95405, done. Delta compression using up to 4 threads. Compressing objects: 100% (24474/24474), done. Writing objects: 100% (95405/95405), 18.15 GiB | 8.34 MiB/s, done. Total 95405 (delta 68425), reused 95401 (delta 68421) remote: Analyzing objects... (95405/95405) (3030021 ms) fatal: The remote end hung up unexpectedly fatal: The remote end hung up unexpectedly   Cause: This is a bug in TFS related to SSh which will be fixed in upcoming release. Our SSH framework times out the connection if there is no communication for over 5 minutes. If pushing a massive repo, the server could do over 5 minutes of work ‘silently’, leading to a connection drop. The workaround is to make the initial push over https and then switch to SSH. Troubleshooting and Resolution: 1.The size of the repository was big and so we tried to reduce the size first by using the following commands. git gc --prune=now --aggressive git repack -adf then push time git gc --prune=now --aggressive; time  git repack -adf ; time git push         The command failed with the following errors:                 fatal: The remote end hung up unexpectedly fatal: The remote end hung up unexpectedly 2. Then we tried to do a push with Http first and decided to do the next clone and push via SSH. This gave the following error regarding certificate as HTTPS was configured in this case. fatal: unable to access 'https://tfs.servername/tfs/collection/teamproject/_git/repo/ ': Peer certificate cannot be authenticated with known CA certificates 3. So we informed customer that they were using using a self-signed certificate to allow HTTPS in TFS on-premises They need to permanently add the HTTPS certificate as “trusted” on the machine and ignore the self-sign check for git by using the flag  git -c http.sslVerify=false 4. Then We checked and found that the push operation worked as expected by using Https. [[xxxx@servername]$ git -c http.sslVerify=false push Counting objects: 95405, done. Delta compression using up to 4 threads. Compressing objects: 100% (24499/24499), done. Writing objects: 100% (95405/95405), 18.54 GiB | 4.79 MiB/s, done. Total 95405 (delta 68399), reused 95401 (delta 68395) remote: Analyzing objects... (95405/95405) (3894107 ms) remote: Storing packfile... done (2695635 ms) remote: Storing index... done (936 ms) To 'https://tfs.servername/tfs/collection/teamproject/_git/repo/  * [new branch]          master -> master 5. Finally we were able to do the next clone and then push by using SSH Written by: Deepak Kumar Mishra, Support Engineer Reviewed by: Nitish Nagpal, Support Escalation Engineer ]]>