Solved

How do I configure WSUS and SCCM to work together?

Posted on 2010-11-18
4
4,855 Views
Last Modified: 2013-11-21
I have a server configured to just run SCCM '07 SP2, and this server also has WSUS installed as was required for the installation of SCCM '07. I'm finding that using SCCM to update client Pc's is VERY cumbersom and inconvenient for me as I have to: manually download updates, add them to update lists, sync the updates with the distribution servers, and then schedule the install to the clients. My questions are the following:

1) Is there a manual that walks you through configuring SCCM and WSUS to work together? GPO settings, etc?

2) Right now my client Pc's are still configured to update from Microsoft's website b/c I can't keep up with all the updates. I'd like to point my client Pc's to my WSUS/SCCM server and have them update via that rather then hitting the Microsoft website. I'm confused about how SCCM works with WSUS; would I still need to manually download updates, add them to update lists, sync the updates with the distribution servers, and then schedule the install to the clients, or will the clients just contact my SCCM server and update automatically?

3) What about bandwidth usage in regards to remote clients at remote locations hitting the SCCM/WSUS server? I dont want 200 Pc's trying to download updates over one connection and flodding that connection.


I'd REALLY rather have SCCM handle EVERYTHING, and not have to deal with two consoles, and two different pieces of software. I think I'm making this more complicated then it needs to be, but right now I'm so confused.

Thank you!
0
Comment
Question by:DonaldWilliams
  • 3
4 Comments
 
LVL 8

Expert Comment

by:MarkieS
Comment Utility
There's a beautiful walkthrough here...

http://myitforum.com/cs2/blogs/cstauffer/archive/2008/11/13/patch-management-directions-for-sccm.aspx

A plain text with pretty pictures good guide!

cheers
0
 
LVL 8

Assisted Solution

by:MarkieS
MarkieS earned 150 total points
Comment Utility
Sorry hit submit before I was ready!!

1 - There's a beautiful walkthrough here...

http://myitforum.com/cs2/blogs/cstauffer/archive/2008/11/13/patch-management-directions-for-sccm.aspx


2 - The walkthrough explains the WSUS/SCCM receipe.  Basically you never  touch the WSUS console again. Using SCCM you search for all updates released in the last month.  A single click - then select the updates you want to deploy - all of them if you're not fussy.  Then add them to a deployment.  It can be as simple of as complex as you want it to be.

3 - Bandwidth Throttling and BITS is controlled by the Client Agent properties under site settings - You can throttle bandwidth down to 1kbps if you need to.  That plus the use of maintenace windows (No downloads between the hours of 9am and 5pm) gives a versatile manageable control over your network usage.

good luck
0
 
LVL 8

Expert Comment

by:MarkieS
Comment Utility
Additionally - You can use the built in reports to give you a list of updates that machines on your network are asking for but you havent deployed yet!  That's very handy...
0
 
LVL 4

Accepted Solution

by:
fr0nk earned 350 total points
Comment Utility
Hello everybody,

There are a LOT of different approaches for handling Updates with SCCM.
I'll show you my way and let you decide wether it is helpful or not.

Again, there are possibly hundreds of more possibilities of how to do it.

1. How does WSUS work with SCCM and my agents?
1.1 Client side:
First of all: When you enable the appropriate software update client component the client will create a LOCAL GPO and tries to apply it. However, if there's any GPO in your domain that is applying any different setting, the client will complain about it in the WUAHandler.log with the string:
Group policy settings were overwritten by a higher authority (Domain Controller)

1.2: WSUS:
The WSUS Server will be configured by SCCM. Don't temper with it. Don't configure or use any computer groups in it. Just never open the console.
The WSUS Server will connect to windowsupdate.microsoft.com and download a .CAB file containing the available updates published by microsoft according to your settings of the Software Update Point. I'll come to that later.
The WSUS server will then notify the SCCM server that a new .CAB file has been received.

The .CAB file contains the following information:
- Which update for which OS / App and wich Platform
- Is this update superseeded by any other update (means: does any other cumulative update contain this very one?
- Where to download the .exe (Win Server 2003 / XP) / .msu (Vista / 2k8)

1.3: Software update point component:
The software update point component is the one that talks with the WSUS server and evaluates the .CAB files provided by WSUS.

2. How does the Updates get to my SCCM?
Inside SCCM you have the appropriate Software Updates-Hive.
Although SCCM is _using_ WSUS to get the .CAB files (and therefore the information which updates are availible), it will use its own deployment mechanism.
That means:
YOU will have to
- Download the updates
- Assign the Updates to Packages
- Put the Packages on a DP
- Advertise the updates against a collection. The Advertisement in this case is named "Update Deployment" but is basically doing the same as an advertisement: Establishing a connection between the updates (programs) and a collection.

3. HOW do I do that in the best way
At all of my customers I'm using the following strategy:
INITIAL SETUP:
1. I let SCCM synchronize with WSUS
2. I create a baseline. This means: Everything until NOW.
3. Please consider: NEVER put more than 500 updates in one package. Reason: When you have a multiple site hierarchy, the packet replication will use a LOT of ressources since every Package is simply a folder that needs to be converted to a PKG file, (hopefully binary differentially replicated) and extracted at the destination site. The extraction will ALWAYS take place at the installation folder of SCCM in the inboxes. There is no way to change that location! If you install SCCM on C:\ you could EASILY fill up your root partition.
4. Consider a package as a folder. When a client wants only one update that is inside a huge package it DOESN'T download the whole package. Just that one update. The Package ist just the distribution mechanism for the packages itself.
4. Create a search folder.
Use the following query: Required 1 or 2 or 3 or 4 or 5 or 6 or 7 or 8 or 9
WHY? Simple: The search folder is doing a substring match. So: 10 Clients that require the package will match, since "1" matches. 120 also, etc. But 0 won't match. Obviously you don't need that particular update, so there's no need to waste any effort to it.
Select all updates inside the search folder and choose: Download -> Into Package. Create a new one.
Name that Package for example: Microsoft_Baseline_Win7_32Bit_NOV_2010
This will be your baseline.

5. Now you create the deltas to this baseline: I create new packages every 3 months (to stay below 500 updates / package) due to the above-mentioned replication issue. Name them:
Microsoft_Patches_Win7_32Bit_2010_Q1
Microsoft_Patches_Win7_32Bit_2010_Q2
Microsoft_Patches_Win7_32Bit_2010_Q3
Microsoft_Baseline_Win7_32Bit_2010_Q4
Microsoft_Patches_Win7_32Bit_2011_Q1
and so on.


When you create a Deployment Management (it's the same as an advertisement) you direct it against a collection. Create the appropriate collections, according to the Baseline

IMPORTANT:
When you're using OSD, you CAN allow the Task Sequence to install updates. But there's NO classification. Either ALL or NONE. Be aware of that.
This is the very reason i DON'T use the Task Sequence update process.
I have a Build and Capture Task Sequence that installs every published update since NOW and creates a image. I deploy this image in a second process. WITHOUT installing any updates.
This has the following nice effect:
The update installations take a long time. When I build and capture a OS this is done only once.
The next time I deploy the resulting image, there are no patches to be installed. Therefore: a way more rapid deployment time.
 
Hope that helps :-)

0

Featured Post

Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

Join & Write a Comment

Remote Apps is a feature in server 2008 which allows users to run applications off Remote Desktop Servers without having to log into them to run the applications.  The user can either have a desktop shortcut installed or go through the web portal to…
Restoring deleted objects in Active Directory has been a standard feature in Active Directory for many years, yet some admins may not know what is available.
This tutorial will walk an individual through locating and launching the BEUtility application and how to execute it on the appropriate database. Log onto the server running the Backup Exec database. In a larger environment, this would generally be …
This tutorial will show how to configure a new Backup Exec 2012 server and move an existing database to that server with the use of the BEUtility. Install Backup Exec 2012 on the new server and apply all of the latest hotfixes and service packs. The…

763 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now