There are a lot of things to consider when using SCCM to deliver software updates. This document covers:
- Active directory computer groups
- Maintenance Windows
- Software Updates Deployment Collections
- Selection of Software Updates Classifications and Products
- Automatic Deployment Rules
- Software Update Groups and Software Updates Packages
- Client Settings
- Periodic Maintenance of your SCCM updates environment
Active Directory Consideration
If you do not want
the requirement of SCCM console access for people to change maintenance windows
then you will want to set up Active Directory Computer Groups for your
maintenance windows. This will allow
your service desk or server administrators or a CMDB product like ServiceNow or
Tivoli to move computers in and out of maintenance windows without the need for
the console or bothering an SCCM administrator to move them.
It is recommended
that you create a selection of maintenance window computer groups from which
your organization may choose. Be sure
that some are during the day (because there are servers that do most of their
work at night) and that there is a nice, broad selection of windows throughout
the week/weekend.
It is recommended
that you name these maintenance windows very similar to the names used in
SCCM. Use 24hour time annotation rather
than AM/PM. For all naming conventions
it is recommended that the broadest term be on the left moving toward the
narrowest term on the right.
Here is an example
of a good naming convention:
CG-MWSU-06FRI-2000-0000
This breaks down
to:
CG = Computer Group
- this is for organizing your own Active Directory. You may already have a convention for
designating object types within your AD.
This item type is the broadest term in our name.
MW = Maintenance
Window - this is less broad than CG because it defines what the CG is used for.
SU = Software
Updates - there are different types of maintenance windows used in SCCM;
software updates, task sequence, standard deployments. So this defines what the MW is used for.
06 = this is
strictly for sorting the days of the week so that things lay out nicely for
human viewing in the console. 01=Sun,
02=Mon and so on.
FRI = human
readable day of week corresponding to the aforementioned number. This helps to reduce human error by removing
the necessity to calculate the day of the week every time someone goes to make
a change.
2000-0000 = The
actual window, in this case 8pm to midnight.
4hrs is the recommended window length.
By creating AD Computer Groups for your maintenance windows you will enable the ability to delegate the management of the maintenance windows to persons or automation that knows nothing about SCCM. That capability may become very valuable to you in the future even if it is not something that you currently need.
Maintenance Windows
Within SCCM you
should create a folder named "Maintenance Windows". Create *ALL* maintenance windows
within this folder. *NEVER*
assign a maintenance window to any collection outside of this folder. The reason for being so emphatic about locating
all of your MWs within this folder is that maintenance windows are
additive. This means that if you place a
computer into a collection that has a MW of 8pm to midnight on Fri and you also
place that computer into a collection with a MW of midnight to 4am on Sat then
the computer effectively has a MW of 8pm Fri to 4am Sat. That's all well and good but now imagine
trying to figure out what the effective MW of a computer is if you have
assigned MWs to collections throughout your SCCM environment. It is imperative, for your own sanity, that
you keep all of your MWs in one place.
Within your
"Maintenance Windows" folder create a folder called "Software
Updates MWs" and put all of your software updates maintenance windows
within that. Do the same for Task
Sequences and General maintenance windows.
Do not mix types, again, for your own sanity.
It is recommended
that you name these maintenance windows very similar to the names used in
AD. Use 24hour time annotation rather
than AM/PM. For all naming conventions
it is recommended that the broadest term be on the left moving toward the
narrowest term on the right.
Here is an example
of a good naming convention:
MWSU-06FRI-2000-0000
This breaks down
to:
MW = Maintenance
Window
SU = Software
Updates
06 = numerical day
of week for sorting in the console.
FRI = human
readable day of week
2000-0000 = The
actual window in 24hr time. 4hrs is the
recommended window for software updates.
Populate your maintenance window collections by creating the collection's query for the attribute class "System Resource" and the attribute "System Group Name" is equal to your AD computer group name. Note that Active Directory Group Discovery needs to be enabled within SCCM in order for this to work. Also remember to exclude your manual update collection as you create your MW collections.
Manual Update
collection - almost every organization has a few computers, usually servers,
that they wish to ensure only get deployed manually. Create a collection for manual
installations. A suggested name would be
something like "MWSU-Manual".
As you create your software updates maintenance windows set them to
explicitly "exclude" members of this manual update collection so that
these computers never end up in a maintenance window that automatically
installs updates.
Do not put workstations into software updates maintenance windows. You control when updates begin to deploy to workstations but you will want to allow them to install at any time so that workstations that are off overnight and whatnot will still get the updates at their next opportunity after your specified start time.
Software Updates Deployment Collections
Once you have your maintenance
windows created it is time to create the collections to which you will actually
(mechanically) assign the software updates deployments. These collections will include all of your
maintenance windows collections and your manual collection.
In the root of your
Device Collections container in SCCM create a folder named Software Updates
Deployments. This will house your normal
deployment collections but you will also want to place into this folder any "one-off"
software updates deployment collections such as zero-day deployments or
manually created deployments.
Create at least the
four collections in green, if your organization wants a more staged approach
then also create the two in orange.
These are named with a suggested naming convention where any collection
that is going to be targeted with a deployment starts with DEP:
o DEP -
SU - Workstation Test - Populate this collection with workstations
that will receive software updates first, before you send them to the rest of
your organization. You will deploy to
this collection the first week that software updates get released from the
manufacturer (Microsoft). Include your
manual collection here so that the administrators of those computers can
install on whatever schedule they wish, early or late. Be sure to exclude the manual installation
collection just in case there are workstations that are "sensitive".
o DEP -
SU - Workstation Pilot - Populate this collection with your pilot
workstations. Workstations should not
use maintenance windows (at least not for software updates) so no need to add
maintenance windows collections. Be sure
to exclude the manual installation collection just in case there are
workstations that are "sensitive".
o DEP -
SU - Workstation Standard - Because all of your other workstations have
already been targeted by the time you are deploying "standard" you
can just include "All Workstations" in this collection. Be sure to exclude the manual installation
collection just in case there are workstations that are "sensitive".
o DEP -
SU - Server Test - Populate this collection with servers that
will receive software updates first, before you send them to the rest of your
organization. You will deploy to this
collection the first week that software updates get released from the
manufacturer (Microsoft). Include your
manual collection here so that the administrators of those computers can
install on whatever schedule they wish, early or late.
o DEP -
SU - Server Pilot - Populate this collection with your pilot
servers. You will deploy to this
collection the week after software updates get released from the manufacturer
(Microsoft).
o DEP - SU - Server Standard - Because all of your other workstations have already been targeted by the time you are deploying "standard" you can just include "All Servers" in this collection. Be sure to exclude the manual installation collection.
Software Updates Classifications and Products
You are almost
ready to create some rules to deploy the software updates but before you can do
that you need to decide exactly what will go into the deployments. Use software inventory to help you decide on
the products that you need for your organization. Including products that do not exist in your
organization or items that SCCM will not distribute as software updates will
simply waste your storage space.
Set up the
classifications and products in the Site System Role for the Software Update
point.
Be sure to select,
at a minimum the classifications Critical Updates, Security Updates, Update
Rollups, and Updates. Also, if your
organization has Microsoft Surface devices, be sure to check the checkbox for
Microsoft Surface drivers. From the
products be sure to select Windows 10, Windows 10 version 1903 and later, and
Windows 10 LTSB (if you have LTSB in your environment). Select any Windows Server versions that you
have in your environment as well.
Finally use your software inventory information to select other products
that exist in your organization.
See Software Updates Classifications and Products for more information.
Automatic Deployment Rules
Now that you have
your deployment collections created and your products selected it is time to
create the deployments. In order to
fully automate the process you will create the following ADRs (again naming
convention using least specific on left to most specific on right):
Here is the basic
template for your ADRs. The specifics
for your six different deployment types are below after the template settings.
Basic Template
General:
Software Update Group = Create new
Enable = Enable the
deployment after the rule is run
Deployment
Settings:
Detail Level =
Success and error messages
License Agreements
= Automatically deploy all software updates found by this rule and approve any
license agreements
Software Updates:
Software Updates Property
Filters:
·
Date Released or Revised: Last 45 days
·
Is Deployed: No
·
Superseded: No
·
Update Classification: "Security Updates,
Security Updates, Update Rollups, and Updates"
Click on the
preview button to see what this will do before you continue.
Evaluation
Schedule:
Run the rule on a
schedule: Customize
·
Monthly
·
Every 1 month
·
The Second Tuesday
·
Be sure the time at the top is a time late enough
in the day that Microsoft should have already released any updates by that time
(suggest after 3pm PST)
Deployment
Schedule:
Time based on:
Client local time
Software Available
time: As soon as possible
Installation
Deadline: 2 days (this sets the deadline to Thursday at the time of day set in
the evaluation schedule).
User Experience:
User
notifications: Show in software center
and show all notifications
Deadline
Behavior:
Software Updates
Installation: unchecked
System Restart (if
required): unchecked
Deadline Restart
Behavior:
Servers: Checked
Workstations:
Unchecked
Alerts:
Generate an alert
when this rule fails: checked
Generate an alert
when the following conditions are met: checked
Client compliance
below the following percent: 80
Offset from the
deadline: 14 days
Operations Manager
Alerts: leave both unchecked unless you have SCOM
Download Settings:
Using different
distribution point:
Deployment Options:
Do not install software updates (prevents network WAN swamping if a remote DP
is down).
Default boundary
group:
Deployment Options:
Do not install software updates (prevents network WAN swamping if a remote DP
is down).
Check both check boxes. This will ensure that clients can get updates regardless of DP status and metered connections are not really a thing anymore. If you have ADSL lines, satellite uplinks, or other metered connections then you might want to uncheck that box.
ADR-Workstation-Test
General:
Description = Week
1 - Deploy to test, early adopters, and manual installations.
Collection = DEP -
SU - Workstation Test
Deployment
Schedule:
Software Available
time: As soon as possible
Installation
Deadline: 2 days (this sets the deadline to Thursday at the time of day set in
the evaluation schedule).
Deployment Package:
(use one of the two following choices)
No deployment
package. This is great for the modern
workplace with many people mobile and/or working from home. It removes the requirement for them to
connect to the on-premises network (physically or via vpn) to get updates but
you are still able to control the manifest of which updates they will receive.
Download Settings:
Check both check boxes. This will ensure that clients can get updates regardless of DP status and metered connections are not really a thing anymore. If you have ADSL lines, satellite uplinks, or other metered connections then you might want to uncheck that box.
ADR-Workstation-Pilot
General:
Description = Week
2 - Deploy to pilot and dev.
Collection = DEP -
SU - Workstation Pilot
Deployment
Schedule:
Software Available
time: 7 days
Installation
Deadline: 0
Deployment Package:
(use one of the two following choices)
No deployment
package. This is great for the modern
workplace with many people mobile and/or working from home. It removes the requirement for them to
connect to the on-premises network (physically or via vpn) to get updates but
you are still able to control the manifest of which updates they will receive.
Download Settings:
Check both check boxes. This will ensure that clients can get updates regardless of DP status and metered connections are not really a thing anymore. If you have ADSL lines, satellite uplinks, or other metered connections then you might want to uncheck that box.
ADR-Workstation-Standard
General:
Description = Week
3 - Deploy to the entire organization.
Collection = DEP -
SU - Workstation Standard
Deployment
Schedule:
Software Available
time: 14 days
Installation
Deadline: 0
Deployment Package:
(use one of the two following choices)
No deployment
package. This is great for the modern
workplace with many people mobile and/or working from home. It removes the requirement for them to
connect to the on-premises network (physically or via vpn) to get updates but
you are still able to control the manifest of which updates they will receive.
Download Settings:
Check both check boxes. This will ensure that clients can get updates regardless of DP status and metered connections are not really a thing anymore. If you have ADSL lines, satellite uplinks, or other metered connections then you might want to uncheck that box.
ADR-Server-Test
General:
Description -=Week
1 - Deploy to test, early adopters, and manual installations.
Collection = DEP -
SU - Server Test
Deployment
Schedule:
Software Available
time: As soon as possible
Installation
Deadline: 0 days
Deployment Package:
(use one of the two following choices)
If you do not
already have a package for the year, create one.
Select a deployment
package: Select your deployment package for the year
User Experience:
Deadline Restart
Behavior:
Servers: Unchecked
Deployment Package:
(use one of the two following choices)
If you do not
already have a package for the year, create one.
Select a deployment
package: Select your deployment package for the year
Download Settings:
Uncheck the check
box for downloading from Microsoft. You
don't want servers going direct to Microsoft.
They should always be connected to your infrastructure.
ADR-Server-Pilot
General:
Description = Week
2 - Deploy to pilot and dev.
Collection = DEP -
SU - Server Pilot
Deployment
Schedule:
Software Available
time: 7 days
Installation
Deadline: 0 days
Deployment Package:
(use one of the two following choices)
If you do not
already have a package for the year, create one.
Select a deployment
package: Select your deployment package for the year
User Experience:
Deadline Restart
Behavior:
Servers: Unchecked
Deployment Package:
(use one of the two following choices)
If you do not
already have a package for the year, create one.
Select a deployment
package: Select your deployment package for the year
Download Settings:
Uncheck the check
box for downloading from Microsoft. You
don't want servers going direct to Microsoft.
They should always be connected to your infrastructure.
ADR-Server-Standard
General:
Description = Week
3 - Deploy to the entire organization.
Collection = DEP -
SU - Workstation Standard
Deployment
Schedule:
Software Available
time: 14 days
Installation
Deadline: 0 days
Deployment Package:
(use one of the two following choices)
If you do not
already have a package for the year, create one.
Select a deployment
package: Select your deployment package for the year
User Experience:
Deadline Restart
Behavior:
Servers: Unchecked
Deployment Package:
(use one of the two following choices)
If you do not
already have a package for the year, create one.
Select a deployment
package: Select your deployment package for the year
Download Settings:
Uncheck the check box for downloading from Microsoft. You don't want servers going direct to Microsoft. They should always be connected to your infrastructure.
Software Update Groups and Software Updates Packages
The Automatic
Deployment Rules will create Software Update Packages and Software Update
Groups. The Software Update Group is
basically a manifest of which updates should be accessible to a specific group
of computers (the computers to which the SUG is deployed). The Software Update Group does not actually
contain the binaries/software of the update, that is in the Software Updates Package.
There is a major
difference in how SCCM deals with Software Updates Packages and any other type
of package. You do not deploy Software
Updates Packages themselves, but rather you deploy the Software Updates Group
(the manifest). When the client begins
to apply updates it does not download the entire Software Updates Package but
rather downloads only those updates from the Software Updates Package that
apply to it. That is the big difference,
any other type of package must download the entire package.
This does not mean
that you can allow your Software Updates Packages to grow to unlimited
size. The size of the Software Updates
Packages will still contribute to slowing things down if they grow too large
because they still must be transferred to Distribution Points and the clients
must search through them for the updates.
It is recommended
that you roll up your updates periodically into quarterly and/or yearly
packages. In the Automatic Deployment
Rules section, all of the examples are using a yearly package so in that case
you would need to create a new package each year.
You must maintain your Software Updates Groups and Packages by removing expired and superseded updates periodically. Failure to do so will cause sometimes updates to fail. See the Periodic Maintenance section for instructions on how to clean up your Software Updates Groups and Packages.
Client Settings
Below are the
Client Settings that I most typically recommend. Note that though these are typical they are
not universal. You must set these in a
way that works for you and your business.
For example the BITS throttling window in these typical settings would
not work at all for a global company that has almost equal usage 24 hours a
day.
Background Intelligent Transfer Service (BITS)
Throttling window
start time:
1hr prior to your normal start of business
Throttling window
end time:
1hr after your normal start of business
Maximum transfer
rate during throttling window (Kbps): 10 (this is so low because BITS is client side,
not server side, so even this low one could theoretically swamp a WAN link).
Allow BITS
downloads outside the throttling window: Allow
Maximum transfer
rate outside the throttling window (Kbps): Unlimited
Client cache settings
Configure
BranchCache:
Yes
Enable BranchCache:
No
Maximum BranchCache
cache size (percentage of disk): 10
Configure client
cache size:
Yes
Maximum cache size
(MB): 10240
Maximum cache size
(percentage of disk): 5
Enable as peer
cache source: Yes
Port for initial
network broadcast (default UDP 8004): 8004
Port for content
download from peer (default TCP 8003): 8003
Minimum duration before cached content can be removed (minutes): 1440
Client policy
Client policy
polling interval (minutes): 60
Enable user policy
on clients:
Yes
Enable user policy
requests from internet clients: Yes
Enable user policy
for multiple user sessions: No
Cloud services
Allow access to
cloud distribution point: Yes if CDP exists, No if it does not
Automatically
register new Windows 10 domain joined devices with Azure Active Directory: Yes
Enable clients to
use a cloud management gateway: Yes
Compliance settings
Enable compliance
evaluation on clients: Yes
Schedule compliance
evaluation:
Every 1 Hour
Enable User Data
and Profiles:
No (but this is becoming more and more common)
Computer agent
User notifications
for required deployments:
Deployment deadline
greater than 24 hours, remind user every (hours): 24
Deployment deadline
less than 24 hours, remind user every (hours): 4
Deployment deadline
less than 1 hour, remind user every (minutes): 15
Default Application
Catalog website point: Support ends for the application catalog roles
with version 1910.
Add default
Application Catalog website to Internet Explorer trusted sites zone: Yes
Allow Silverlight
applications to run in elevated trust mode: No (This setting must be Yes for users to use
the application catalog.)
Organization name
displayed in Software Center: OrganizationName
Use new Software
Center:
Yes
Enable
communication with Health Attestation Service: Yes
Install permissions: All Users
Suspend BitLocker
PIN entry on restart: Always
Additional software
manages the deployment of applications and software updates: No
PowerShell
execution policy: Bypass
Show notifications
for new deployments: No (this is the annoying "There is new
software available")
Disable deadline
randomization:
No
Grace period for
enforcement after deployment deadline (hours): 8
Enable Endpoint
analytics data collection: No (if you are using Endpoint Analytics you
likely are enrolling via Intune, not here).
Computer restart
Configuration
Manager can force a device to restart: Yes
Specify the amount
of time after the deadline before a device gets restarted (minutes): 120
Specify the amount
of time that a user is presented a final countdown notification before a device
gets restarted (minutes): 15
Specify the
frequency of reminder notifications presented to the user, after the deadline,
before a device gets restarted (minutes): 15
When a deployment
requires a restart, show a dialog window to the user instead of a toast notification: Yes
When a deployment
requires a restart, allow low-rights users to restart a device running Windows
Server:
Yes
Delivery Optimization
Use Configuration
Manager Boundary Groups for Delivery Optimization Group ID: Yes
Enable devices
managed by Configuration Manager to use Microsoft Connected Cache servers for
content download: Yes
Endpoint Protection
Manage Endpoint
Protection client on client computers: No/Yes depending on if company uses MEP
Install Endpoint
Protection client on client computers: No/Yes depending on if company uses MEP
Allow Endpoint
Protection client installation and restarts outside maintenance windows: Yes
For Windows
Embedded devices with write filters, commit Endpoint Protection client
installation (requires restarts): Yes
Suppress any
required computer restarts after the Endpoint Protection client is installed: No
Allowed period of
time users can postpone a required restart to complete the Endpoint Protection
installation (hours): 120
Disable alternate
sources for the initial definition update on client computers: No
Enrollment
Polling interval
for mobile device legacy clients: 60
Polling interval
for modern devices (minutes): 60
Allow users to
enroll mobile devices and Mac computers: Yes
Enrollment profile:
Allow users to
enroll modern devices: Yes
Modern device
enrollment profile:
Hardware inventory
Enable hardware
inventory on clients: Yes
Hardware inventory
schedule:
Every 1 Days
Maximum random
delay (minutes): 90
Maximum custom MIF
file size (KB):
512 (adjust as necessary if MIFs start failing due to size)
Hardware inventory
classes:
Keep defaults
Collect MIF files: Yes
Metered internet connections (these are not common)
Client communication
on metered internet connections: Allow
Power management
Allow power
management of devices: Yes
Allow users to
exclude their device from power management: Yes
Allow network
wake-up:
Yes
Enable wake-up
proxy:
No
Remote tools
Enable Remote
Control on clients, and Firewall exception profiles: Yes
Users can change
policy or notification settings in Software Center: No
Allow Remote
Control of an unattended computer: Yes
Prompt user for
Remote Control permission: Yes
Prompt user for
permission to transfer content from shared clipboard: No
Grant Remote
Control permission to local Administrators group: Yes
Access level
allowed:
Full Control
Permitted viewers
of Remote Control and Remote Assistance: <unconfigured>
Show session
notification icon on taskbar: Yes
Show session
connection bar:
No
Play a sound on
client:
Beginning and end of session (default)
Manage unsolicited
Remote Assistance settings: Yes
Level of access for
Remote Assistance: Full Control
Manage Remote
Desktop settings: Yes
Allow permitted
viewers to connect by using Remote Desktop connection: Yes
Require network
level authentication on computers that run Windows Vista operating system and
later versions:
Yes
Software Center
Select the user
portal:
Software Center
Select these new
settings to specify company information: Yes
Company name: Enter
the organization name that users see in Software Center.
Color scheme for
Software Center: Click Select Color to define the primary color used by
Software Center.
Select a logo for
Software Center: Click Browse to select an image to appear in Software Center.
The logo must be a JPEG, PNG, or BMP of 400 x 100 pixels, with a maximum size
of 750 KB. The logo file name shouldn't contain spaces.
Hide unapproved
applications in Software Center: No (hiding removes ability to request approval)
Hide installed
applications in Software Center: No (hiding removes reinstall/repair ability)
Hide Application
Catalog link in Software Center: Yes (Application Catalog is obsolete)
Software Center tab
visibility:
Leave Defaults
Configure default
views in Software Center:
Default application
filter: All
Default application
view: Tile view
Software deployment
Enable software
inventory on clients: Yes
Schedule software
inventory and file collection: Every 7 Days
Inventory reporting
detail:
Full details
Inventory these
file types:
.exe, .dll
Name: *.exe and
*.dll
Location:
%systemdrive%
Exclude encrypted
and compressed files: Yes
Exclude files in
the Windows folder: Yes
Collect files: None - use this
very sparingly, it can really explode your storage usage.
Set Names: Leave default
Software Metering
Software inventory
tells you which software exists on the computer. Software metering tells you
when and how often the software is used.
The most common usage of metering is to recover licenses for software
that is installed but not used. To that
end you don't need to create rules for every piece of software, only those
where the usage actually matters. For
example usage of Notepad++ doesn't matter but usage of Visio does. So don't kill yourself creating rules for
everything, just the important items.
Enable software
metering on clients: Yes
Schedule data
collection:
Every 7 days
§ Never enable the
automatic rule creation as it just makes a mess. Microsoft has never gotten this right since
SMS 1.0.
§ Just use a wildcard
for the version (*) as SCCM will automatically determine the version for you
anyway and by using a wildcard you won't have to change your rule for every
version.
§ Original file name
is not necessary, ignore it.
§ Only use language
if you have the same software in multiple languages, otherwise use a wildcard
(*).
§ Select "All
Clients" for "Apply this software metering rule to the following
clients". If you aren't wanting to
meter your clients then why are your clients then why are you creating the
rule?
Software updates
Software update
scan schedule:
Every 1 Day
Schedule deployment
re-evaluation:
Every 7 Days
Allow user proxy
for software update scans: No
When any software
update deployment deadline is reached, install all other software update
deployments with deadline coming within a specified period of time: Yes (this helps
to reduce the number of times per month that you irritate your users)
Period of time for
which all pending deployments with deadline in this time will also be installed: 7 Days (only
irritate the users for software updates once per week)
Allow clients to
download delta content when available: Yes (reduces the amount of data used to
download updates)
Port that clients
use to receive requests for delta content: 8005 (default)
If content is
unavailable from distribution points in the current boundary group, immediately
fallback to a neighbor or the site default: No
Enable management
of the Office 365 Client Agent: Yes
Enable installation
of software updates in "All deployments" maintenance window when
"Software Update" maintenance window is available: No (we prefer
keeping these deployments segregated so that if there is a problem it is easier
to troubleshoot)
Specify thread
priority for feature updates: Not Configured
Enable third party
software updates: Yes
Enable Dynamic
Update for feature updates: Yes
State Messaging
State message
reporting cycle (minutes): 15 minutes (default)
User and device affinity
User device
affinity usage threshold (minutes): 2880 minutes (default)
User device
affinity usage threshold (days): 30 days (default)
Automatically
configure user device affinity from usage data: Yes
Allow user to
define their primary devices: Yes
Periodic Maintenance
In order to keep
your windows updates infrastructure healthy there is some maintenance that you
should perform periodically. How
frequently you do these things is up to you but quarterly is recommended and no
less frequently than annually.
Remove expired and
superseded updates from software updates groups -
1.
Look at the list of Software Updates Groups for
any that have a yellow icon, double-click on the software update group to see
its "Membership" (all software updates that are included in the SUG).
2.
If the columns are not already visible, add
columns for Expired and Superseded in your console view.
3.
Sort the updates by "Expired"
4.
Multi-select all expired updates (hold shift and
click on them).
5.
Right-click on any selected update and select
"Edit membership" from the context menu.
6.
Remove the updates from all software updates
groups
7.
Sort the updates list by "Superseded"
and repeat steps 4-6 for the superseded updates.
8.
Repeat steps 1-7 until there are no more SUGs
with yellow icons.
Roll up updates
into quarterly/annual Software Updates Packages
1.
adsf
No comments:
Post a Comment