Recently we have acquired the licenses to use the System Center 2012 R2 Suite. With this also comes SCCM.

At this moment we don’t have a real update policy in place.

Servers are updated in regular intervals by hand in weekends. Mostly a few days after patch Tuesday, but sometimes the gap is a bit bigger.

Clients are updated by the users themselves in most cases (as in updates download and install automaticly, users need to reboot).

So as far as policies go we can mostly start from scratch.

We want to structure this procedure with SCCM now that we have the licenses to use it in our new Licensing Agreement.

I have installed SCCM now, but my experience with the program is limited. I have looked at quite a few guides and such but those are mostly examples for Lab deployments. Which work ok when I tested them but they also leave open some questions.

Now my questions are as follows, are there any good deployment guides for SCCM in a production scenario.

My main questions are how to setup the software update groups in the best way and deployments and which products to sync to software update point

Do I need to sync categories like “developer tools, runtimes and redistributables”, Windows Defender, MS Security Essentials (a small amount of systems have this installed still as a backup AV scanner, as some machines do not connect often enough to our Deep Security when on business trip), Silverlight and small applications like these. Or will Applications like these still connect through windows update even If I do not sync them to SCCM.

Also, if I start out deployment to a “pilot” group of machines with let’s say only the Windows 2008 R2 and Windows Server 2012 (R2) updates. Will those machines still grab the other updates they need, or will those applications not be updates till those applications are also synced to SCCM.

As for the Software update groups. Is it advised to split these into OS and Application categories and make a Monthly ADR per Application together with the baseline with all updates up to now, or would it be better to make groups per year (for all the updates in the past to create a baseline, as they won’t fit into one big software update group) and then use monthly ADR’s groups with all the updates stuffed into one monthly group. Are there any best practice scenario’s available for this, screenshots would be a huge plus.

I'll provide the limited amount of information I have on this topic in hopes that it helps you at least a little. We are using ADR to push out only Windows updates and Endpoint Protection definitions. The process I used is generally divided into two steps: 1) create and deploy a baseline for Windows and EP to run once, 2) create and deploy bi-weekly updates (for Windows) or daily (for EP) to run on a schedule.

﻿INSTALL WSUS

The first step to setting up updates is to install WSUS on the server. There are plenty of guides out there that will explain how to do that. So, I won't go into too much detail about this step. The only thing I want to pass along is that you SHOULD NOT CONFIGURE WSUS after the install. You will be configuring WSUS via SCCM SUP (Software Update Point).

﻿INSTALL SOFTWARE UPDATE SITE SYSTEM ROLE

Next, install the Software Update Site System Role. This is step is only meant to get meta-data about the available updates. What updates actually are installed is handled later. Think of this step as your SCCM being seated at a restaurant and being handed a menu.

Navigate to Configuration Manager Console -> Administration -> Site Configuration -> Sites. Right-click the site that you wish to add the role to and select "Add Site System Roles". A wizard by the same name should appear.

- On the General screen choose the appropriate server and site code, if needed and supply the appropriate credentials to install the role.

- On the Proxy screen, provide proxy information as needed. In the System Role Selection screen choose "Software Update Point".

- On the Sync Source screen, choose where to (or not at all) sync your updates from. If you are just starting with updates, then chose the option to sync from MS.

- On the Sync Schedule screen, enable a schedule if you want (I highly recommend you do). The frequency of the sync is up to you, but keep the frequency in mind for future steps. Have SCCM alert you if the sync fails, if you want.

- On the Supersedence Rules screen, I have the superseded updates set to immediately expire. Again, your environment might dictate that superseded updates be available for some time after they have been superseded.

- On the Classifications screen, choose what type of updates to sync. I have Critical, Definition, and Security. You will most likely not need all of the classifications and choosing all of the classifications is an inefficient use of your sync cycle.

- On the Products screen, choose the appropriate products to sync updates for. Since I'm only only doing Windows and Endpoint Protection updates, those are the only products I have selected.

Complete the installation by going through the Summary, Progress, and Completion screens.

﻿SYNC YOUR UPDATE OPTIONS

﻿Back to the analogy of the restaurant, this is where your SCCM server is looking through the items on the dinner menu and deciding what to order.

Navigate to Software Library -> Overview -> Software Updates -> All Software Updates. Right-click and choose to sync updates. This step will take some time, depending on what updates you've chosen. Check the wsyncmgr.log and wcm.log to keep tabs on the progress.

﻿SET UP ADRs

﻿Once SCCM has finished cataloging all of the updates. You will want to start the creation of an ADR for the types of updates you want to do. This is where the two step process I mentioned earlier comes into play. Obviously a lot of Windows updates have come out in the past. So, the first update cycle your clients do could be huge. Also, some client might have some updates A and B while others have updates C and D while still others have none. Your Windows environment could be a complete mess from an update perspective. So, you need to get everyone on an equal footing before you try to push out monthly updates. This is called the baseline. I prefer to create baselines for each product while allowing each baseline to consist of various classifications. To create a baseline:

- On the General screen, give your ADR a name such as "Win7 Baseline" and a meaningful description such as "Windows 7 updates as of 1.29.2015". Do not choose a template. Assign the ADR to a collection (probably a small test group like a lab or some sort; target collections can be changed later when you are confident that the baseline works as you'd like it to). Set the ADR to Add to an existing Software Update Group (SUG) when the rule is run. This will allow the end-of-year baseline roll-up to use the same SUG instead of creating a new one (mostly just for neatness-sake; more on end-of-year roll-up later). A SUG will be created with this ADR and whether a new SUG is created or not when the rule is run again is decided at this step. Decide whether you want a deployment to be enabled after a successful run of the rule. Note that this is only happens (AFAIK) when a rule pulls down new updates. This is important to know for the incremental updates we will be setting up next.

- On the Deployment Settings screen, choose the configuration that you prefer here. I do not use WoL since my environment is mostly Bootcamped Mac Minis.

- On the Software Updates screen, choose what updates will be downloaded. If you recall, during the setup of the Software Update Point, you chose what types of updates for various products to sync. This screen in the ADR will tell the SCCM server to go through that sync list and actually download updates that match the filters. To continue the restaurant analogy, this is where your SCCM has looked through the menu and is actually ordering items. Choose the appropriate filter and give a value to it. For example, if you want updates that only apply to WIndows 7, check the Product box, click <items to find>, and check the Windows 7 value in the Search Criteria box. You can then click preview to see what updates the sync has available for the given criteria. For incremental update ADRs, the Date Released or Revised filter will come in handy. This allows you to tell the ADR to collect updates that were only released or revised during a given, relative time period (e.g. the last 7 days).

- On the Evaluation Schedule screen, you will decide how often this rule will run. Since this is our baseline, do not run this rule of a schedule. We will instead be running this rule manually both the first time and at each end-of-year roll-up (again, I'll get to end-of-year roll-ups later). For the incremental updates, provide a schedule that will not be more frequent than whatever you set the Software Update Point sync schedule to be. Otherwise your ADR will poll your Software Update Point before the Software Update Point has a chance to re-sync with MS or an up-stream server.

- On the Deployment Experience screen, you will decide when your clients will be able to get these updates. If you have a strict maintenance schedule, then set a specific deployment and deadline time. Otherwise, the ASAP option for availability time will work just fine. Set the Deadline time for however long you want to give your client systems to do the install. Similar to the "Evaluation schedule frequency to the Software Update Point sync" idea, it is not wise to set your Deadline to longer than the combined Evaluation and Availability schedules or you might experience update-backup, where updates from the previous ADR have not completed their installation when a current ADR run is coming down the pipe.

- On the User Experience screen, decide what notifications will appear as well as whether or not to allow installation of the updates and system restarts outside of the set maintenance window values for the collection you are deploying to. Since I have my updates to be available ASAP and since most of my users turn their computers off after work hours, I set the installation (not the restart) to happen outside of defined maintenance windows. This ensures that the updates will get installed but will keep the system from interrupting my users to reboot. Also, choose the type of system to suppress the reboot on. Since we have been using Windows 7 as an example so far, this setting really isn't necessary. The last option has to do with Windows Embedded. Use your best judgment here.

- On the Alerts screen, configure these items as you see fit. This seems rather self-explanatory.

- On the Download Settings screen, choose what your clients will do if the network is slow (most likely WAN clients), whether the client will use a fallback source, whether the client will share content with others on the same subnet (can greatly reduce network traffic), whether the client will use MS Updates as a last resort, and whether or not to allow downloads of the content after the Deadline if the internet connection is metered (money-saving option).

- On the Deployment Package screen, you will set up the deployments of the results of the updates chosen to be in each SUG. This is very similar to a deployment of an item from the Application Management section of the Software Library. If this is the first time you've set up updates, you will need to create a new deployment package. Give the package a name, description, and network share source-folder. You should also be given the option to distribute the content if you choose to create a new deployment (basic SCCM methodology: Create, Distribute, Deploy).

- On the Download Location screen, choose the source of the download (internet or up-stream server). This is where the network share from the previous screen will receive its updates.

- On the Language screen, you should know what to do here.

- Finish the wizard by reviewing the information in the Summary screen, watching the Progress screen, and confirming the Completion page. You can watch the progress of the downloading of the updates by navigating to the network share and watching the folders as they are created.

RUN THE BASELINE MANUALLY

﻿Since the purpose of the baseline is to get everyone at the same starting point for incremental upgrades, we would not want the baseline to run of a schedule. Normally a baseline is only run once a year or so, depending on how often you want to do the end-of-year roll-up of your updates. So, we will need to manually run the baseline once to get the ball rolling. Navigate to Software Library -> Overview -> Software Updates -> Automatic Deployment Rules. Select the baseline ADR, right-click, and click the option to Run the ADR.

WATCH THE MAGIC HAPPEN (a little slowly)

At this point, all of the dominoes should start to fall. Your ADR will query your SUP for information about available updates based on the filters you set the ADR to use. The SUP will download the eligible updates for the ADR. The associated SUG should be created if needed and should place those updates into the associated SUG (found in Software Update Groups) by downloading them to the supplied network share location. Because the ADR caused files to actually be downloaded, the ADR should enable the deployment of the associated package (found in Deployment Packages). Your client systems will poll for policy changes whenever they do and will receive instructions to process the updates from the deployment group of the SUG, generated by the ADR. Ta-da.

CREATE AND RUN THE INCREMENTAL ADR

﻿So, a few days have passed and all of your systems have reached baseline level. You are now ready to create your incremental update ADR. Feel free to use the templates at the beginning of the ADR creation wizard for these. This is the ADR that will go out on a regular schedule to collect updates and deploy them. Unlike the baseline, this ADR will be updating on a schedule. So, you will need to add the "Released or Revised On" filter to the Software Updates screen of this ADR. Otherwise, SCCM will get all updates that match the other filters regardless of time, essentially creating a new baseline. Also, it is wise to allow this ADR to create new SUGs each time it is run, as this allows you to easily find what updates were deployed and when. Because each product releases updates on a different schedule, I recommend creating ADRs for each product type.

For example, MS does Patch Tuesday for Windows updates but Endpoint Protection definitions can be released at any moment. So, creating an ADR to do both incrementally is inefficient, as you would either miss EP definition updates if you went with the Patch Tuesday frequency or you would query your SCCM update catalog for Patch Tuesday updates unnecessarily with daily requests.

Here's another thing about incremental ADRs. If your schedule is too frequent, they may run but not create a SUG for the first few times. The reason for this is because your ADR queried SCCM for updates that were released in a given timeframe. If no updates match that description, then there are no updates to group. If there are no updates to group, then no SUG will be created.

I TOLD YOU I WOULD GIVE YOU MORE INFO ABOUT END-OF-YEAR ROLL-UPS

﻿To best understand this idea, let me describe your ADR situation after a year. You had the baseline that you ran a year ago with all of the updates that existed from that point in time back to the first release of updates for your product. Also, you have, for example, 12 incremental SUGs because you chose an increment ADR frequency of once a month. Now, let's say you deploy a new machine to you organization. For it to be updated, it would need to process the baseline and each of the 12 incremental SUGs. Instead of letting it process each of these separately, you can roll-up the SUGs into the baseline for the next year. To do that simply, delete the SUGs for that past year and re-run the baseline ADR. Since the baseline ADR does not have a time-based filter on it, it should pull down all of the updates that were in the incremental SUGs into one neat package.

8 Replies

Greater minds than mine will answer most of your questions as I to am fairly new to this monster. Tech net has been a huge resource for me (along with the guys who are faithfull to help onn the forums) and its right at you finger tips at the root of configuration manager. Good luck

I'll provide the limited amount of information I have on this topic in hopes that it helps you at least a little. We are using ADR to push out only Windows updates and Endpoint Protection definitions. The process I used is generally divided into two steps: 1) create and deploy a baseline for Windows and EP to run once, 2) create and deploy bi-weekly updates (for Windows) or daily (for EP) to run on a schedule.

﻿INSTALL WSUS

The first step to setting up updates is to install WSUS on the server. There are plenty of guides out there that will explain how to do that. So, I won't go into too much detail about this step. The only thing I want to pass along is that you SHOULD NOT CONFIGURE WSUS after the install. You will be configuring WSUS via SCCM SUP (Software Update Point).

﻿INSTALL SOFTWARE UPDATE SITE SYSTEM ROLE

Next, install the Software Update Site System Role. This is step is only meant to get meta-data about the available updates. What updates actually are installed is handled later. Think of this step as your SCCM being seated at a restaurant and being handed a menu.

Navigate to Configuration Manager Console -> Administration -> Site Configuration -> Sites. Right-click the site that you wish to add the role to and select "Add Site System Roles". A wizard by the same name should appear.

- On the General screen choose the appropriate server and site code, if needed and supply the appropriate credentials to install the role.

- On the Proxy screen, provide proxy information as needed. In the System Role Selection screen choose "Software Update Point".

- On the Sync Source screen, choose where to (or not at all) sync your updates from. If you are just starting with updates, then chose the option to sync from MS.

- On the Sync Schedule screen, enable a schedule if you want (I highly recommend you do). The frequency of the sync is up to you, but keep the frequency in mind for future steps. Have SCCM alert you if the sync fails, if you want.

- On the Supersedence Rules screen, I have the superseded updates set to immediately expire. Again, your environment might dictate that superseded updates be available for some time after they have been superseded.

- On the Classifications screen, choose what type of updates to sync. I have Critical, Definition, and Security. You will most likely not need all of the classifications and choosing all of the classifications is an inefficient use of your sync cycle.

- On the Products screen, choose the appropriate products to sync updates for. Since I'm only only doing Windows and Endpoint Protection updates, those are the only products I have selected.

Complete the installation by going through the Summary, Progress, and Completion screens.

﻿SYNC YOUR UPDATE OPTIONS

﻿Back to the analogy of the restaurant, this is where your SCCM server is looking through the items on the dinner menu and deciding what to order.

Navigate to Software Library -> Overview -> Software Updates -> All Software Updates. Right-click and choose to sync updates. This step will take some time, depending on what updates you've chosen. Check the wsyncmgr.log and wcm.log to keep tabs on the progress.

﻿SET UP ADRs

﻿Once SCCM has finished cataloging all of the updates. You will want to start the creation of an ADR for the types of updates you want to do. This is where the two step process I mentioned earlier comes into play. Obviously a lot of Windows updates have come out in the past. So, the first update cycle your clients do could be huge. Also, some client might have some updates A and B while others have updates C and D while still others have none. Your Windows environment could be a complete mess from an update perspective. So, you need to get everyone on an equal footing before you try to push out monthly updates. This is called the baseline. I prefer to create baselines for each product while allowing each baseline to consist of various classifications. To create a baseline:

- On the General screen, give your ADR a name such as "Win7 Baseline" and a meaningful description such as "Windows 7 updates as of 1.29.2015". Do not choose a template. Assign the ADR to a collection (probably a small test group like a lab or some sort; target collections can be changed later when you are confident that the baseline works as you'd like it to). Set the ADR to Add to an existing Software Update Group (SUG) when the rule is run. This will allow the end-of-year baseline roll-up to use the same SUG instead of creating a new one (mostly just for neatness-sake; more on end-of-year roll-up later). A SUG will be created with this ADR and whether a new SUG is created or not when the rule is run again is decided at this step. Decide whether you want a deployment to be enabled after a successful run of the rule. Note that this is only happens (AFAIK) when a rule pulls down new updates. This is important to know for the incremental updates we will be setting up next.

- On the Deployment Settings screen, choose the configuration that you prefer here. I do not use WoL since my environment is mostly Bootcamped Mac Minis.

- On the Software Updates screen, choose what updates will be downloaded. If you recall, during the setup of the Software Update Point, you chose what types of updates for various products to sync. This screen in the ADR will tell the SCCM server to go through that sync list and actually download updates that match the filters. To continue the restaurant analogy, this is where your SCCM has looked through the menu and is actually ordering items. Choose the appropriate filter and give a value to it. For example, if you want updates that only apply to WIndows 7, check the Product box, click <items to find>, and check the Windows 7 value in the Search Criteria box. You can then click preview to see what updates the sync has available for the given criteria. For incremental update ADRs, the Date Released or Revised filter will come in handy. This allows you to tell the ADR to collect updates that were only released or revised during a given, relative time period (e.g. the last 7 days).

- On the Evaluation Schedule screen, you will decide how often this rule will run. Since this is our baseline, do not run this rule of a schedule. We will instead be running this rule manually both the first time and at each end-of-year roll-up (again, I'll get to end-of-year roll-ups later). For the incremental updates, provide a schedule that will not be more frequent than whatever you set the Software Update Point sync schedule to be. Otherwise your ADR will poll your Software Update Point before the Software Update Point has a chance to re-sync with MS or an up-stream server.

- On the Deployment Experience screen, you will decide when your clients will be able to get these updates. If you have a strict maintenance schedule, then set a specific deployment and deadline time. Otherwise, the ASAP option for availability time will work just fine. Set the Deadline time for however long you want to give your client systems to do the install. Similar to the "Evaluation schedule frequency to the Software Update Point sync" idea, it is not wise to set your Deadline to longer than the combined Evaluation and Availability schedules or you might experience update-backup, where updates from the previous ADR have not completed their installation when a current ADR run is coming down the pipe.

- On the User Experience screen, decide what notifications will appear as well as whether or not to allow installation of the updates and system restarts outside of the set maintenance window values for the collection you are deploying to. Since I have my updates to be available ASAP and since most of my users turn their computers off after work hours, I set the installation (not the restart) to happen outside of defined maintenance windows. This ensures that the updates will get installed but will keep the system from interrupting my users to reboot. Also, choose the type of system to suppress the reboot on. Since we have been using Windows 7 as an example so far, this setting really isn't necessary. The last option has to do with Windows Embedded. Use your best judgment here.

- On the Alerts screen, configure these items as you see fit. This seems rather self-explanatory.

- On the Download Settings screen, choose what your clients will do if the network is slow (most likely WAN clients), whether the client will use a fallback source, whether the client will share content with others on the same subnet (can greatly reduce network traffic), whether the client will use MS Updates as a last resort, and whether or not to allow downloads of the content after the Deadline if the internet connection is metered (money-saving option).

- On the Deployment Package screen, you will set up the deployments of the results of the updates chosen to be in each SUG. This is very similar to a deployment of an item from the Application Management section of the Software Library. If this is the first time you've set up updates, you will need to create a new deployment package. Give the package a name, description, and network share source-folder. You should also be given the option to distribute the content if you choose to create a new deployment (basic SCCM methodology: Create, Distribute, Deploy).

- On the Download Location screen, choose the source of the download (internet or up-stream server). This is where the network share from the previous screen will receive its updates.

- On the Language screen, you should know what to do here.

- Finish the wizard by reviewing the information in the Summary screen, watching the Progress screen, and confirming the Completion page. You can watch the progress of the downloading of the updates by navigating to the network share and watching the folders as they are created.

RUN THE BASELINE MANUALLY

﻿Since the purpose of the baseline is to get everyone at the same starting point for incremental upgrades, we would not want the baseline to run of a schedule. Normally a baseline is only run once a year or so, depending on how often you want to do the end-of-year roll-up of your updates. So, we will need to manually run the baseline once to get the ball rolling. Navigate to Software Library -> Overview -> Software Updates -> Automatic Deployment Rules. Select the baseline ADR, right-click, and click the option to Run the ADR.

WATCH THE MAGIC HAPPEN (a little slowly)

At this point, all of the dominoes should start to fall. Your ADR will query your SUP for information about available updates based on the filters you set the ADR to use. The SUP will download the eligible updates for the ADR. The associated SUG should be created if needed and should place those updates into the associated SUG (found in Software Update Groups) by downloading them to the supplied network share location. Because the ADR caused files to actually be downloaded, the ADR should enable the deployment of the associated package (found in Deployment Packages). Your client systems will poll for policy changes whenever they do and will receive instructions to process the updates from the deployment group of the SUG, generated by the ADR. Ta-da.

CREATE AND RUN THE INCREMENTAL ADR

﻿So, a few days have passed and all of your systems have reached baseline level. You are now ready to create your incremental update ADR. Feel free to use the templates at the beginning of the ADR creation wizard for these. This is the ADR that will go out on a regular schedule to collect updates and deploy them. Unlike the baseline, this ADR will be updating on a schedule. So, you will need to add the "Released or Revised On" filter to the Software Updates screen of this ADR. Otherwise, SCCM will get all updates that match the other filters regardless of time, essentially creating a new baseline. Also, it is wise to allow this ADR to create new SUGs each time it is run, as this allows you to easily find what updates were deployed and when. Because each product releases updates on a different schedule, I recommend creating ADRs for each product type.

For example, MS does Patch Tuesday for Windows updates but Endpoint Protection definitions can be released at any moment. So, creating an ADR to do both incrementally is inefficient, as you would either miss EP definition updates if you went with the Patch Tuesday frequency or you would query your SCCM update catalog for Patch Tuesday updates unnecessarily with daily requests.

Here's another thing about incremental ADRs. If your schedule is too frequent, they may run but not create a SUG for the first few times. The reason for this is because your ADR queried SCCM for updates that were released in a given timeframe. If no updates match that description, then there are no updates to group. If there are no updates to group, then no SUG will be created.

I TOLD YOU I WOULD GIVE YOU MORE INFO ABOUT END-OF-YEAR ROLL-UPS

﻿To best understand this idea, let me describe your ADR situation after a year. You had the baseline that you ran a year ago with all of the updates that existed from that point in time back to the first release of updates for your product. Also, you have, for example, 12 incremental SUGs because you chose an increment ADR frequency of once a month. Now, let's say you deploy a new machine to you organization. For it to be updated, it would need to process the baseline and each of the 12 incremental SUGs. Instead of letting it process each of these separately, you can roll-up the SUGs into the baseline for the next year. To do that simply, delete the SUGs for that past year and re-run the baseline ADR. Since the baseline ADR does not have a time-based filter on it, it should pull down all of the updates that were in the incremental SUGs into one neat package.

I would have provided screen shots, but that would have made my post even longer. I'll see what I can do after lunch and will probably just provide you with a Google Drive share of all of the pictures instead of trying to post them here.

EDIT: Actually, I might just make a how-to here on Spiceworks for this.

Thanks for the long and detailed reply, there seems to be alot of usefull tips and information in your post, especially about the ADR and the yearly roll-up. Really Appreciate the information.

At the momentI already have the WSUS role (not configured), the SUP and my old lab test running.

I think now my biggest questions that remains is:

What will happen if i make a baseline and ADR for let’s say Windows 2012 R2. I make sure there is compliance with the baseline and I enable the ADR.Now this server is running Windows 2012 R2 and MS SQL server.

If my baseline is only Server 2012 R2 and I didn’t make any baselines and rules yet in SCCM for SQL server. Will it still get the SQL updates from Windows Update, or will it stop updating SQL server until I also make a baseline and ADR for SQL server. I ask this because I might want to deploy SCCM “slow and steady” and not go all in at once :)

And also if i need to make rules for stuff like "silverlight", "Deploymenttools, redistributables", and Windows Defender and the likes, of it its best practise not to make rules for that in SCCM.

We do not use Endpoint protection so i do not have to make rules for that as we have our Trend Micro Deep Security as AV/Anti malware and more.﻿

Regarding your SQL server, I would suggest making an ADR for each product. That would mean having a separate ADR for Server 2008 R2, one for Server 2012, one for Server 2012 R2, etc. Since SQL Server is in the product list with the option to choose SQL Server 2008 R2, SQL Server 2012, or SQL Server 2014, I can assume that updates for Server 2012 R2 (for example) are only for Server 2012 R2; updates for SQL Server 2012 are only for SQL Server 2012, etc. So, in addition to making ADRs for each of your OS products, I believe that best practice would dictate that you also make separate ADRs for SQL, for Exchange, for Office, for Defender, etc. By separating your products into different ADRs, you have a much more modular system, allowing you to stop updates for SQL (for example) without disrupting updates to your servers.

Regarding Silverlight, I know that the SCCM Application Catalog (accessible via the Software Center) runs on Silverlight. So, you would want to keep that relatively up-to-date. Now, whether you need to stay on the most up-to-date version is another question, one that I am afraid I have no answer for.

Lastly, regarding Development Tools and Redistributables, I have no opinion on this. I looked at each of the possible criteria for updates and did not see either of those items. So, I am a bit uncertain as to what you are looking for exactly.

the ADR's are pretty clear to me now also, together with the baseline.

As regarding to the developer tools, redistributables and such, those are not in the severity categorie's, but in the product catalogue, from my inventory i have seen that some servers have those redistributables installed, so i'm wondering if i don't select them in the product catalogue to sync, but MS rolls out a update for them, will they still get the update from the normal windows update, or is SCCM like "ok, you didnt select that product, so you will never see the updates".

Same with lets say that if i a make a collection of lets say windows 2012 R2 servers, and link and deploy the "2012 R2" SUP to that collection, but one of those servers is also a SQL 2012 Server and i didn't make the SQL 2012 baseline and ADR yet, because i wan't to make sure that the servers are compliant with the 2012 R2 updates before i start rolling out other products trough SCCM. Will that server stop getting the SQL 2012 updates until i link the SQL 2012 baseline and ADR because SCCM will control all the updates, or will SCCM see that it only controls the "2012 R2" updates for that server, and still get SQL 2012 updates "normal" windows update.

I am checking this to see if i need to make all the product baselines and ADR's at once, and then switch totally to SCCM controlled updates, or if i can implement SCCM "slow and steady" and not have any security risks due to maybe missing critical patches.

From what I understand, SCCM Software Update Point works directly with WSUS to do updates. As a result, you can pretty much view SCCM Software Update Point as a means of managing WSUS. One of the steps I recall in a full WSUS implementation is enabling a GPO from your DC that keeps users from manually running Windows Update on their systems. Failure to enable this GPO would allow the user to manually run updates whenever he or she prefers. In case you want to see the GPO I am referring to, it can be found in User Configuration -> Admin Templates -> Start Menu and Taskbar -> "Remove links and access to Windows Update".

Because this GPO exists, I believe that it is possible to run WSUS in an environment where the user could still manually initiate an update cycle on a system. Since SCCM uses WSUS to do updates, I would say that as long as you don't enable the GPO to disable user access to Windows Update, you should be able to roll this out slowly.