Introducing Visual Studio Administrator Updates
During the month of April 2021, Visual Studio will start publishing administrator updates to Visual Studio 2017 and Visual Studio 2019 via Windows Server Update Services (WSUS) and the Microsoft Update Catalog. Enterprises will be able to then use standard deployment tools like Microsoft Endpoint Configuration Manager to easily roll out these updates throughout their organization. In order to take advantage of administrator updates, you’ll need to understand both what they are and how they’re intended to be used. You will also need to configure your client machines properly to recognize and accept them.
This blog post provides a high level summary of Visual Studio administrator updates. For further details, refer to the online documentation for how to enable administrator updates and then apply administrator updates.
Figure 1 – Example Microsoft Endpoint Configuration Manager UI displaying Visual Studio administrator updates
Administrator Update Characteristics
Visual Studio administrator updates will now be available whenever an update is released for any and all Visual Studio servicing versions that are under support. These updates contain information and instructions that a client machine can use to update itself to a particular version. Note that administrator updates for Visual Studio 2017 and 2019 do not actually contain the updated product bits themselves – rather the product bits are sourced from either the internet or from a network or private install cache. Also, the administrator updates can only be used to update an instance of Visual Studio already present on the client computer; applying these updates cannot be used to install a new instance of Visual Studio.
The title of each administrator update describes both the applicable version range of the update as well as the final version that will be applied. In the example above, the “Visual Studio 2019 version 16.9.0 to 16.9.4 update” will be applicable to any clients from versions 16.9.0 through 16.9.3, and it will update them to 16.9.4.
There are three types of Visual Studio administrator updates. Security updates deliver fixes to security vulnerabilities, feature updates contain significant new features and are denoted by an increase in the minor version number, and quality updates contain targeted servicing bug fixes to a particular minor version. The table below lists the key characteristics of administrator updates.
Table 1 – Characteristics of Visual Studio administrator updates
|Characteristic||Security updates||Feature updates||Quality updates|
|Available in the Microsoft Update Catalog||Yes||Yes||Yes|
|Available in WSUS||Yes (automatically)||Optional manual import||Optional manual import|
|Update Category||Security Updates||Feature Packs||Updates|
|SKU Applicability||All Visual Studio editions||Visual Studio Professional Visual Studio Enterprise (and the other SKUs used in enterprise environments)||Visual Studio Professional Visual Studio Enterprise (and the other SKUs used in enterprise environments)|
|Types of changes included as compared to the previous release on that baseline.||Security fixes Quality fixes||Feature changes Security fixes Quality fixes||Quality fixes|
Configuring client computers to receive administrator updates
A few things must be in place in order for the client machines to properly recognize and receive administrator updates.
First of all, the Visual Studio Client Detector Utility must be installed on the client machines. This utility has been included with all Visual Studio 2017 and Visual Studio 2019 updates since May 2020, and it is included in all administrator updates as a pre-requisite. This utility is also available to independently deploy from both WSUS and the Microsoft Update Catalog.
Secondly, the client computers must have a Visual Studio-specific “administrator update opt-in” registry key set. When the AdministratorUpdatesEnabled REG_DWORD key is set to 1, the client machine can accept the administrator updates. This step is necessary to make sure that the new administrator updates are not unintentionally or accidentally pushed out to unsuspecting client machines.
In order to minimize disruption to ongoing development activity, there are some configuration options available to Visual Studio users so they can assert some control or preference as to which administrator updates get applied to their machine. They can set the AdministratorUpdatesOptOut, key which will block any administrator updates from applying to the machine. They can also set the BaselineStickinessVersions2019 key which expresses a preference for remaining on a particular servicing baseline and prevents a higher administrator feature update from applying. Setting any of these keys requires admin access to the machine.
Lastly, keep in mind that the Visual Studio application must be closed in order for the administrator update to be successfully deployed to the client machine. If Visual Studio is open or if any files are being used, then the update will be cancelled.
For an exhaustive list of what the different client configuration options are and how to set them correctly, refer to the Understanding configuration options and Methods for configuring an administrator update sections in the Applying Administrator Updates online documentation.
Managing where the client machines get the updated product bits from
For many customers, client machines can download the updated product bits from the internet. Many enterprises however, choose to restrict internet access, allowing instead for client machines to install and update bits from an internal network layout location. To ensure that centrally deployed administrator updates can be applied using updated bits that are on an internal network location, the following conditions must be true before the administrator update can be successfully deployed:
- The client machine must have, at some point, already installed or updated from that network layout location. Either one of these actions would embed, on the client machine, a connection with that particular layout location.
- The network layout location (where the client is connected to) must be updated to contain the updated product bits that the administrator update wants to deploy.
Additional Information, Support, and Feedback
We hope that this solution will make it easier for enterprises to keep their organization updated with the latest security updates to Visual Studio.
Please refer to the following links to learn more about administrator updates:
- Enabling administrator updates
- Applying administrator updates
- Visual Studio Administrator Guide
- Visual Studio Product Lifecycle and Servicing
If you have questions and need answers, or if you want to report problems or feedback, please visit one of these places:
- Refer to the Troubleshooting Visual Studio installation and upgrade issues guidance.
- Ask questions to the community at the Visual Studio Setup Q&A Forum.
- Go to the Visual Studio support page, and check whether your issue is listed in the FAQ. You can also select the Support Link button for chat help.
- Provide feature feedback or report a problem to the Visual Studio team regarding this experience of applying administrator updates.
- Contact your organization’s technical account manager for Microsoft.
Great, yet another part involved in updating VisualStudio that’s designed to give us headaches and break in mysterious ways.
Please just fix what’s broken in vs_installer or throw that thing away and go back to what’s been used in VS2010 and earlier.
Sincerely, a frustrated user of VisualStudio offline layouts
I totally agree. VS offline / SCCM installation support is simply not working at all. Nobodys seems to know how to make it work. I’m at the point where I use scripts to change the state.json file for the installed instance.
This article has not information how the download of the installation sources from the Internet is supposed to work when using a proxy server. Also there is no information how to configure the system to use a network share instead.
I’ve been struggling with keeping our developer workstations up to date as we have multiple Visual Studio versions and none of them appear to take updates from WSUS. To date, I can only manually remote to each device, one at a time, and run the VS Installer and manually download and install the latest monthly update. It takes forever, and I can never get time on the developer workstations. I was so excited to see your blog post and I went through and set everything up as described but it still didn’t work. No updates were deemed applicable despite me having the update approved and downloaded in WSUS, and all our clients getting other Windows updates from WSUS. So I went back through the instructions and then I saw this….
You can’t use WSUS itself to deploy these updates; it must be used in conjunction with Configuration Manager.
Why can’t you support WSUS? You clearly support it in conjunction with SCCM, right? I have updated Windows, Office, Exchange, SQL, SharePoint, .NET, and on and on with just WSUS and no SCCM. And have done it perfectly for over a decade. Why on earth would Visual Studio be any different from an update standpoint? Does Microsoft just want us to suffer? Why the lack of consistency? Why the lack of appreciation for customers configurations? Please tell me this is only a temporary requirement (SCCM). Or please provide another option.
Yay! Yet another convoluted MS method of doing something. Now, if we have closed networks and want to centralize patching of VS we have to install SCCM. /s