September patches for Azure DevOps Server and Team Foundation Server

Erin Dormier

This month, we are releasing fixes for security vulnerabilities that impact TFS 2015, TFS 2017, TFS 2018, and Azure DevOps Server 2019.

CVE-2019-1305: cross site scripting (XSS) vulnerability in Repos

CVE-2019-1306: remote code execution vulnerability in Wiki

Here are the versions impacted:

Azure DevOps Server 2019 Update 1 Patch 1

If you have Azure DevOps Server 2019 Update 1, you should install Azure DevOps Server 2019 Update 1 Patch 1.

Verifying Installation

To verify if you have this update installed, you can check the version of the following file: [INSTALL_DIR]\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Search.Common.dll. Azure DevOps Server 2019 is installed to c:\Program Files\Azure DevOps Server 2019 by default.

After installing Azure DevOps Server 2019.1 Patch 1, the version will be 17.153.29226.8.

Azure DevOps Server 2019.0.1 Patch 3

If you have Azure DevOps Server 2019, you should first update to Azure DevOps Server 2019.0.1. Once on 2019.0.1, install Azure DevOps Server 2019.0.1 Patch 3.

Verifying Installation

To verify if you have this update installed, you can check the version of the following file: [INSTALL_DIR]\Application Tier\Web Services\bin\Microsoft.TeamFoundation.Framework.Server.dll. Azure DevOps Server 2019 is installed to c:\Program Files\Azure DevOps Server 2019 by default.

After installing Azure DevOps Server 2019.0.1 Patch 3, the version will be 17.143.29226.4.

TFS 2018 Update 3.2 Patch 7

If you have TFS 2018 Update 2 or Update 3, you should first update to TFS 2018 Update 3.2. Once on Update 3.2, install TFS 2018 Update 3.2 Patch 7.

Verifying Installation

To verify if you have this update installed, you can check the version of the following file: [TFS_INSTALL_DIR]\Application Tier\Web Services\bin\Microsoft.TeamFoundation.WorkItemTracking.Web.dll. TFS 2018 is installed to c:\Program Files\Microsoft Team Foundation Server 2018 by default.

After installing TFS 2018 Update 3.2 Patch 7, the version will be 16.131.29226.5.

TFS 2018 Update 1.2 Patch 6

If you have TFS 2018 RTW or Update 1, you should first update to TFS 2018 Update 1.2. Once on Update 1.2, install TFS 2018 Update 1.2 Patch 6.

Verifying Installation

To verify if you have this update installed, you can check the version of the following file: [TFS_INSTALL_DIR]\Application Tier\Web Services\bin\Microsoft.TeamFoundation.Server.WebAccess.Admin.dll. TFS 2018 is installed to c:\Program Files\Microsoft Team Foundation Server 2018 by default.

After installing TFS 2018 Update 1.2 Patch 6, the version will be 16.122.29226.6.

TFS 2017 Update 3.1 Patch 8

If you have TFS 2017, you should first update to TFS 2017 Update 3.1. Once on Update 3.1, install TFS 2017 Update 3.1 Patch 8.

Verifying Installation

To verify if you have a patch installed, you can check the version of the following file: [TFS_INSTALL_DIR]\Application Tier\Web Services\bin\Microsoft.TeamFoundation.Server.WebAccess.Admin.dll. TFS 2017 is installed to c:\Program Files\Microsoft Team Foundation Server 15.0 by default.

After installing TFS 2017 Update 3.1 Patch 8, the version will be 15.117.29226.0.

TFS 2015 Update 4.2 Patch 3

If you have TFS 2015, you should first update to TFS 2015 Update 4.2. Once on Update 4.2, install TFS 2015 Update 4.2 Patch 3.

Verifying Installation

To verify if you have a patch installed, you can check the version of the following file: [TFS_INSTALL_DIR]\Application Tier\Web Services\bin\Microsoft.TeamFoundation.Framework.Server.dll. TFS 2015 is installed to c:\Program Files\Microsoft Team Foundation Server 14.0 by default.

After installing TFS 2015 Update 4.2 Patch 3, the version will be 14.114.29226.0.

24 comments

Discussion is closed. Login to edit/delete existing comments.

  • t shirai 0

    I applied “Azure DevOps Server 2019 Update 1 Patch 1”, but the “Microsoft.TeamFoundation.Framework.Server.dll” file was not changed and remained at “17.153.29207.5”.
    The following four files have been changed to “17.153.29226.8”.Is it correct?
    “Microsoft.VisualStudio.Services.Search.ReSearch.Core.dll””Microsoft.VisualStudio.Services.Search.Common.dll””Microsoft.VisualStudio.Services.Search.Indexer.dll””Microsoft.VisualStudio.Services.Search.Platforms.SearchEngine.dll”

    • Erin DormierMicrosoft employee 0

      Thanks for this feedback, you are absolutely correct. I just updated the post.

  • MICHAEL SCHORR 0

    Is there a possibility to automatically update Azure DevOps Server for example via WSUS?

    • Erin DormierMicrosoft employee 0

      Hi Michael,

      We don’t do automatic updates of Azure DevOps Server or TFS due to the complexities of configurations. For example, there may be multiple ATs and load balancers that need to be upgraded simultaneously.

      • Vital Koshalew 0

        Hi Erin,

        Please consider adding automatic updates in the nearest future. There is always an option to disable automatic updates for any reason: complex environment or otherwise. For example, Sharepoint/SQL reporting server deployments can be really complex, but that has never been a reason not to provide updates through WSUS.

        This article describes a remote code execution vulnerability. This is a major security issue. What is the recommended process for server administrators to stay secure with Azur DevOps Server installed? Follow the blog?

        • Kibel, Reinaldo 0

          Erin, I heard the challenge however I agree with Michael, the process of upgrade is painful now… and with any “Azure” branded product the expectation is a simple, clean, robust upgrade process. what will it take to remove these barriers you listed?

  • Matthieu Penant 0

    Any chance the documentation part of the Azure Dev Ops API gets adressed in a future sprint? 
    For those of us that rely on the API, the struggle is real, as the stacking github issues can testify : https://github.com/MicrosoftDocs/vsts-rest-api-specs/issues .

    • Whitney JenkinsMicrosoft employee 0

      Hi Matthieu, 

      Thanks for reaching out. We’re always working to address user feedback on our docs. As of right now, we publish incremental improvements to our REST API documentation each sprint. If there are any particular github issue in the repo linked above that need immediate consideration, please add a comment to the issue. This will help us with prioritizing fixes. 

      Best,

      Whitney 

      • Matthieu Penant 0

        Thanks a lot Whitney! I’ll ping you in the issue on GH.

  • Stanton, Andrew 0

    @Erin Dormier – Any chance that the build history that was deleted without warning or authorization is going to get restored? Also all the version numbers that were broken due to that “streamlining” get fixed?   The engineer working the feedback ticket does not seem to understand the risk this creates for your customers, even when painstakingly explained. Per his (push off) request, I opened a support request to have the history restored and the questions the support rep is asking are the kind one would get when the the source is trying to push-off or delay and hope the problem goes away. The only thing that the pipeline’s dev team agreed to fix was a bug in the settings UI related to this feature that still isnt fixed despite that feedback item indicating otherwise (and this defect ought to have been caught by by anyone testing the new feature). Meanwhile more of your customers are discovering all thier build numbers are reset and they are issuing programs and packages with different code and old version numbers. My only recourse was to make a utility that marks every build as retain indefinitely.
    I would have contacted you or the other AzDo PM’s directly, but all I can find on here are what look like non-work contact addresses.

    • Erin DormierMicrosoft employee 0

      Hi Andrew,

      I’m following up with my team to find out what’s going on. Stay tuned.

      • Andrew Stanton 0

        @Erin Dormier In case you are getting stonewalled or only half the facts, here is the Azure case: 119090124000098 and the devcomm issue

  • Daniel Steiner 0

    after installing Azure Devops Server 2019 Update 1 Patch 1 I noticed that it takes a lot more resources than previous version. I found a bug report that Azure Devops Server 2019 Update 1 uses more resources than RTM and therefore I uninstalled Azure Devops Server 2019 Update 1 via Control Panel (as well as the databases in the SQL Server) and installed Azure DevOps Server 2019 RTM followed by installation of 2019.0.1 which both version did require less resources than Update 1 installation.

    I than wanted to install Patch 3 for 2019.0.1 but the patch failed with the message that if found the correct TFS 2019.0.1 but also found patch 2019 Update 1 Patch 1 17.153.29226.8 and downgrade patching is not possible.

    How can I install Patch 3 for Azure DevOps 2019.0.1 ?

    or when will the fix against high resource for Update 1 be available ?

    • Erin DormierMicrosoft employee 0

      Hi Daniel,

      The fix for the high resources is planned to be available in November. If you would like a private fix earlier, please send me a mail at egeaney@microsoft.com.

      I’m following up with my team to help with the patch installation problem you’re having.

      Thanks,
      Erin

      • Erin DormierMicrosoft employee 0

        Here is the info on the patch installation:
        The patch checks to make sure that a later version of the patch hasn’t been installed by looking in the registry for the version of the patch that is currently installed. When they uninstalled Update 1 the Update 1 patch info wasn’t removed because it wasn’t written by the MSI. So when the 2019.0.1 patch looked in the registry, it found the Update 1 patch and said that a later version was installed. The customer can delete the HKLM\SOFTWARE\Microsoft\TeamFoundationServer\17.0\PatchVersion value and they will be able to install the 2019.0.1 patch.

      • Daniel Steiner 0

        after applying the private fix on a single server installation the memory usage went down from 9.5GB to 7.6GB for a single collection with one empty project.
        After creating 2 work items and connecting from various VisualStudio version the memory usage increased by 1GB mainly used by the elasticsearch process running on the same server.

        Azure Devops Server should offer a builtin option to configure the memory usage of elasticsearch as this process consumes up-to 50% of the memory which can affect the Azure Devops Server performance due to memory pressure.

        • Erin DormierMicrosoft employee 0

          Hi Daniel,

          Thank you for the feedback. I have passed this along to our team that works on Search.

  • super tang 0

    Hi Erin,

    I installed TFS 2018 Update 3.2 Patch 7 for our TFS server 2018, but unfortunately, the version still is 16.131.28601.4 (Tfs2018.Update3.2).
    According to your blog, the version should be 16.131.29226.5 if succeed .
    Checked the patch log. No useful message there.
    Thanks.

  • Jacob Konopacki 0

    I am seeing the following issues when trying to apply Azure DevOps Server 2019.0.1 Patch 3:

    Zipping “C:\Program Files\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.TeamFoundation.Framework.Server.dll” into “C:\Program Files\Azure DevOps Server 2019\Backup\2019-11-18_14-25-55.zip”
    Error patching files: System.UnauthorizedAccessException: Access to the path ‘C:\Program Files\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.TeamFoundation.Framework.Server.dll’ is denied.
    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
    at System.IO.File.InternalDelete(String path, Boolean checkHost)
    at Microsoft.TeamFoundation.AzureDevOpsPatch.AzureDevOpsPatch.UpdateFiles(Logger log)

    Please help!

    • Wil Wilder Apaza Bustamante 0

      this comment has been deleted.

    • Jacob Konopacki 0

      Help! Anyone?

      • Gloridel MoralesMicrosoft employee 0

        Hi Jacob, try the following:
        • First thing to try is to stop IIS before running the patch. Run “iisreset stop”, run the patch exe and then run “iisreset start”. This will solve the problem if the issue is IIS holding the file open.
        • The other thing that can hold the file open is virus scanners. You can exclude the “C:\Program Files\Azure DevOps Server 2019” folder from virus scans.

        • Jacob Konopacki 0

          Hi Gloridel,

          First sorry for the delay…its been crazy at work and thank you for your inputs.

          I tried both approaches and I am still getting the same error…any other ideas?

          • Bhombal, Rehan 0

            Hi Jacob,

            Where you able to resolve this? I am facing the same issue.
            Also do you know the location of log files.

            Rehan

Feedback usabilla icon