NARRATOR: Hello all and welcome to our talk
on "What's changed and what you need to know,
about on-premises Windows Update management."
My name is Arianna Carley, and I'll be your narrator today.
And we have three special speakers come
and present some topics that are interesting to you
if you care about what you need to know
about keeping your organization protected and productive.
If you look at our agenda today,
we are going to cover
how you can ensure your environment stays secure
and upcoming changes
that will simplify the management of deploying
Servicing Stack Updates
with the monthly latest cumulative update
from either WSUS or Catalog
as well as how you can test out these changes today.
So, stay tuned as we flip over to Ritvik Raj
and his discussion on
how you can keep your environment secure
by converting from HTTP to HTTPS
as well as some changes that are coming
to how to secure your HTTP WSUS environment.
Now, on to you Ritvik.
Thanks Arianna.
So, to ensure your WSUS infrastructure
is as secure as it can be,
Microsoft strongly recommends using TLS or SSL protocol
between your computers and your WSUS servers.
The Microsoft Upgrade system, including WSUS,
relies on two types of content:
update payloads and update metadata.
Update payloads are the data files
that contain the updates themselves.
Update metadata is all the information
that the Microsoft Update system
needs to know about the update,
including which updates are available,
which computers each update can be applied to, where
to retrieve the payload for each update.
Both types of content are crucial,
and they both need to be protected
in order to keep your computers secure.
Update payloads are protected against modification
by multiple means, including digital signature checks
and cryptographic hash verifications.
HTTPS provides a proper chain of custody,
which the client uses to prove that the data is trusted.
When a client computer is receiving updates
directly from the Microsoft update,
the client computer receives the update metadata
directly from the Microsoft servers.
This metadata is always transmitted
by HTTPS to prevent tampering.
When you use WSUS or Config Manager
to manage your organization's update,
the update metadata travels from the Microsoft server
to your client computers via a chain of connections.
All these connections need to be protected.
Your WSUS connects with the Windows Update server
and receives update metadata.
These connections always use HTTPS,
and the HTTPS security features
guard the metadata against tampering.
We have multiple WSUS servers arranged in a hierarchy.
The downstream servers receive the update metadata
from the upstream servers.
Here, you have a choice:
You can use HTTP or HTTPS for these metadata connections,
but choosing to use HTTP is very dangerous:
It breaks the chain of trust.
Using HTTPS enables the WSUS server
to prove that it trusts the metadata it receives
from the upstream WSUS server.
Your client computers receive update metadata
from a WSUS server.
Again, you have a choice:
You can use HTTP or HTTPS for these connections.
However, using HTTPS enables the client device to prove
that it trusts the metadata it receives
from the WSUS server.
So, in order to maintain the chain of trust
and prevent attacks on your client computers,
you must make sure
that all of the metadata connections
within your organization-
the connections between the upstream
and the downstream WSUS servers
and the connections between the WSUS server
and your client computers-are defended against attacks.
And to do that, we highly recommend
that you configure your WSUS network
to protect these connections using HTTPS.
That said, for those of you who are utilizing HTTP,
it is worth noting as of the September 2020
security patch update,
in order to keep the clients inherently secure,
we are no longer allowing HTTP-based internet servers
to leverage user proxy by default for detecting updates.
This means that the detection for updates
will fail when HTTP-based intranet servers
that rely on a proxy are used
without a configured system proxy.
If you need to leverage
user proxy for detecting updates
while using an HTTP-based intranet server
despite the vulnerabilities it presents,
you must configure the proxy behavior
to allow user proxy to be used as a fallback
if detection using system proxy fails.
This change does not impact the customers
who have, per Microsoft recommendation,
secured their WSUS server with TLS or SSL protocol,
thereby using the HTTPS-based intranet servers
to keep the system secure.
That said, if a proxy is required,
we recommend configuring a system proxy
to ensure the highest level of security.
Thank you. Over to you Arianna.
Thanks Ritvik.
Now that we have covered how to secure your WSUS servers,
let's listen to Asish as he explains to us
the upcoming changes about deploying monthly updates,
including changes on how you deploy Servicing Stack Updates,
also known as SSUs, and the latest cumulative update,
or LCU, with WSUS in Catalog.
Asish, on to you.
Thank you, Arianna.
Admins using WSUS or Catalog
have previously had to deploy the SSU to outlined
prior to deploy that month's corresponding LCU.
With this change, admins do not have to worry about this
as the SSU and LCU come as a single package to the device,
and their deployments are currently orchestrated
on the client.
Now, the SSU and LCU are provided together
as part of the LCU KB to WSUS and Catalog.
Admins simply have to apply the LCU
and will get the SSU applied correctly, if necessary.
For those using Config Manager version 2002
or later, you will likely have already started
to notice the benefit of having
the SSU automatically orchestrated
to be installed prior to the LCU.
This change will impact both IT admins as well as end users.
Admins, you will note that
rather than having multiple KB articles-
one for the SSU and one for the LCU-
you will now have to look at a single article
for the content of both the LCU and the SSU.
Additionally, when determining what to deploy,
you will only save one monthly cumulative update
in both WSUS and Catalog
and do not have to worry about the orchestration
between the SSU and LCU.
The payload you are approving will contain both
as well as the orchestration
to ensure they are applied on the device
in the correct order.
For your end users, they will now see
only a single update in their Windows Update settings,
and this will be the same window
end users connecting directly to Windows Update see today.
Control Panel will also show a single KB.
This will, however, continue to display
both the SSU and LCU separately
but will only show a version number with the SSU
to make it clear that it is not an update
that action can be taken upon.
This will appear the same
as if it was any other feature on demand,
also known as FoDs.
To learn more, check out the recently released blog
announcing the simplification of SSU deployment
and beginning of a single monthly update.
Thank you. Over to you, Arianna.
Thanks Asish.
So, are you interested in checking out these changes
and recommendations now?
What about testing out
the upcoming Windows 10 features update version 20H2?
Or, maybe the cool enablement package technology
with which it will be shipped?
Well, let's listen
as Shailja walks through how exactly
you can go about testing all of these changes and more
now. Shailja, on to you.
Thank you, Arianna.
In order to preview the WSUS,
you will first want to open up your WSUS server.
Then, you will open up
"Software Update Point Component Properties"
and select "Product" tab.
From there, you will want to select
the "Windows Insider Pre-Release" box.
This box was added back in August 2019,
when we first enabled prerelease updates for 1909.
It is extremely important that you check this box
or no preview updates will pop up later on
in your list of Windows 10 updates.
Once you have added the Windows Insider Pre-release product,
you will want to follow the same process you use
to deploy any other Windows 10 feature update.
Once you have pulled up the list of Windows 10 updates,
you will need to refresh
to ensure that the prerelease updates show up.
From there, you will simply select
the appropriate Windows 10 prerelease update.
The best part about this is that
for validating 20H2 to prerelease and WSUS,
you will not only have the option
to download the full feature update
from the prerelease product category,
but you will also be able
to test out the enablement package experience
for devices already on Windows 10 version 2004.
The devices on 2004 will move to 20H2
in less time, more akin to a quality update.
Imagine, restarting in 5 minutes or less!
To test out this functionality,
you can also update to 2004,
and then take the applicable
Windows Insider Pre-release Publisher 20H2.
To learn more,
check out the links that we have
as part of additional resources
at the end of this presentation.
In addition to making 20H2 preview bills available on WSUS,
we also publish the same prerelease versions
to Windows Update,
where you can manage with Windows Update for Business
and Azure Marketplace
to enable you to set up a virtual machine.
Finally, you can go
to the Windows Insider Preview Downloads page
to enable you to have access to the ISOs, if so needed.
Thank you. Back to you, Arianna.
Thanks Shailja.
We hope you've enjoyed this talk
and have a better understanding
with how to secure you WSUS servers,
understand the changes coming regarding
how we are going to be shipping
one cumulative update pro OS servicing release,
and have the know-how
to go about testing all this functionality
and more before it's ever even released.
As you can see,
there is a variety of resources that you can look at
to actually learn more about any of these topics.
Thanks again for listening!