SCCM + SUP and non-Windows specific updates

[DaaT]

Hi,

 

First of all, thanks for your SCCM guides, they've been a great help. I'm doing my 2nd SCCM installation (first was on a separate forest only for building 2008/2012 servers), this one I'm hoping will be used to deploy software, windows updates and WDS. I did an installation on a lab environment, specifically for testing the software deployment part, however for the Windows updates I'm doing this on the live side, though only pointing to one small OU (only 1 desktop and 1 laptop in it) through the AD System Discovery, so no issues with affecting everyone else.

 

I've set up he SUP for Windows updates, with the SUG and collections (though no ADRs), so my question isn't directly related to that. I'm wondering what's the best way to deploy updates for other products other than Windows? For example, in our current WSUS, we have other products selected such as SQL Server, Exchange, Visual Studio, etc. Is it going through WSUS instead of SCCM? Still use SCCM?

 

Thanks in advance,

Dan

 

 

[Peter van der Woude]

Those updates can also be deployed via ConfigMgr. In the software update component properties you can configure which products it has to sync. These products will be same as you can deploy via a standalone WSUS. Also, keep in mind that the software update point is still using WSUS to sync the metadata of all the updates.

[DaaT]

Hi Peter, thanks for your reply.

 

I am aware I can choose other products in the SUP configuration and I've done so (and they've been listed after the SUP's initial sync and are ready for downloading). But since we have to deploy the Windows updates to the respective collections (Win 7 updates for the Win 7 device collection and so forth), my question was more of how to deploy all of those other updates (SQL, Exchange, etc, etc).

 

With WSUS you just select the products, it downloads the updates and the client's WUAUCLT picks them up.

 

Hope I was able to explain what I meant

 

Thanks once again,

Dan

[Peter van der Woude]

You can deploy those other updates the same as you deploy your operating system updates. Simply download the updates to a package, add them to a update group en deploy that group.

[DaaT]

Ah right, create one big SUG for, let's say, "All Other Updates" (since I have SUGs for Windows 7 and several Windows Server editions) then put all remaining updates into that SUG and Deployment Package. Now to find a search criteria that let's me exclude all of the Windows xxxxx updates already in SUGs

 

Thanks for the help Peter.

 

Dan

[Peter van der Woude]

That's indeed one possibility. Just keep in mind that you shouldn't add more then a 1000 updates to one update group / deployment / package.

[DaaT]

Wasn't aware of that limit, thanks, however I just checked and the highest I have is 817 in one of the SUGs.

 

As I mentioned in my previous post, I ended up creating a "All Other Product Updates" SUG, using the 'add criteria' option to add those other products (and saved the search criteria for next time ) and got the updates that way.

[DaaT]

A related question, if you don't mind Peter. That "All Other Product Updates" SUG I created and then deployed, several updates (48 to be precise) that show as 'required' aren't being installed, most being Office 2010 updates. I deployed to All Systems (though atm only 2 Windows 7 machines are using this server for updates). Of the 48, 23 weren't installed on the 2 clients and the other 25 only on one of the clients. They were deployed a couple of days ago, but no go with the installation. If I do an online check through the one of the desktop's control panel Windows Update, I get those updates listed.

 

Also, which settings takes precedence, regarding the updates installation? The one in the Windows Update control panel on the clients, or those set up on the SCCM server?

 

Thanks once again.

 

Edit: Found the glitch that was preventing the other updates from being seen and installed by the 2 clients. I was in SCCM comparing the Deployment Packages and noticed the one for all other updates wasn't in the DP (which was odd since I thought I'd followed the exact same process for all of the Deployment Packages/SUGs). I distributed the content and some time after both clients saw the updates. Spotted what seems like a bug in relation to the updates being installed, on a couple of them, Software Center reports the installation as Failed, but after all are installed, those two are also listed as Installed.

[Peter van der Woude]

Also, keep in mind that you can also look at the client log files for more information about the errors.

[DaaT]

True, thanks Peter.

 

Any thoughts on my question "which settings takes precedence, regarding the updates installation? The one in the Windows Update control panel on the clients, or those set up on the SCCM server"? Let's say the Windows Update control panel says one thing, but I want the desktops to install updates only on a Friday night, would I need to change the group policy or change something in SCCM, like create a maintenance window?

 

Thanks.

[Peter van der Woude]

The ConfigMgr client uses local policies and an agent to scan and deploy updates on the scheduled time.