SUP – Tech-Coffee https://www.tech-coffee.net Tue, 16 Feb 2016 13:11:29 +0000 en-US hourly 1 https://wordpress.org/?v=5.2.11 65682309 SCCM Software Update PART 5 – Best practices https://www.tech-coffee.net/sccm-software-update-part-5-best-practices/ https://www.tech-coffee.net/sccm-software-update-part-5-best-practices/#comments Mon, 10 Mar 2014 18:40:13 +0000 https://www.tech-coffee.net/?p=233 SCCM Software Update PART 1 – Introduction to SCCM and WSUS SCCM Software Update PART 2 – Software Update Point configuration SCCM Software Update PART 3 – Automatic Deployment Rules SCCM Software Update PART 4 – Create deployment packages manually SCCM Software Update PART 5 – Best practices   To conclude the SCCM Software Update ...

The post SCCM Software Update PART 5 – Best practices appeared first on Tech-Coffee.

]]>
  • SCCM Software Update PART 1 – Introduction to SCCM and WSUS
  • SCCM Software Update PART 2 – Software Update Point configuration
  • SCCM Software Update PART 3 – Automatic Deployment Rules
  • SCCM Software Update PART 4 – Create deployment packages manually
  • SCCM Software Update PART 5 – Best practices
  •  

    T3D successful business man with a laptop and arms upo conclude the SCCM Software Update subject, I will present some SCCM software update best practices to manage Micorosft updates in production environments.

    Subscribes to news site about updates and security

    It is important to be aware about the last updates (often the second Tuesday of the month) but also the last security issue. Sometime an emergency update is released by Microsoft to fix a vulnerability so it is necessary to patch quickly and to reduce the risk to be attacked. There are many solutions to make a technology watch: RSS (ex: Microsoft bulletin), Twitter (@msftsecresponse: #security #updates) or Microsoft Security Bulletin Notification. A good source for security purpose is the CERT (sorry it is a French link J).

    Create standard baselines

    All your system should be set on the same way to ease management and find the issue. That means that systems should be based on the same image installation, same Operating System (as much as possible) and application version and so on. Same baseline should be gathered in the same SCCM collection to ease software updates.

    Create a pre-production to validate updates

    Updates should be tested before the installation on production environment. Make sure to have a pre-production environment reflect the production environment. That means that pre-production environment contains every operating system and applications that you have on production. So when Tuesday patches are released, first update pre-production environment and test that everything is ok for one or two weeks.

    Create packages with pre-determined criteria

    To ease the management of update packages, create them with pre-determined criteria such as products, languages, classification and release date. This avoids to reconfigure update packages every month.

    Create collections for each Operating System version

    Organize collections by operating system ease update packages management. In this way make an update package containing every update for the related operating system and apply it to the collection. So every month, update this update package with new updates (view next point).

    Reuse update packages when possible

    To limit the number of update packages and so ease management, you should reuse deployment packages most of the time. So in a perfect world, you should have one update package per operating system version (including service pack), and one per application (example: SQL Server, System Center DPM etc.).

    Create an emergency procedure

    Sometime Microsoft releases a security update outside of Tuesday patch process because a 0-day vulnerability has been discovered for example. That happens one or two times per year. A process to make an emergency patching for this case should exist. Usually the emergency update should take a short time such as 10 to 15 days for pre-production and production environment patching.

    Enforce a deadline to install updates

    I recommend to enforce install updates when the deadline is reached. However I don’t suggest to force servers restart. I recommend that because everyone knows a colleague that will never install updates because he does not give a damn! With enforcing install updates on deadline, this administrator will have to be aware about updates.

    The post SCCM Software Update PART 5 – Best practices appeared first on Tech-Coffee.

    ]]>
    https://www.tech-coffee.net/sccm-software-update-part-5-best-practices/feed/ 5 233
    SCCM Software Update PART 4 – Create deployment packages manually https://www.tech-coffee.net/sccm-software-update-part-4-create-deployment-packages-manually/ https://www.tech-coffee.net/sccm-software-update-part-4-create-deployment-packages-manually/#respond Sun, 09 Mar 2014 16:16:54 +0000 https://www.tech-coffee.net/?p=223 SCCM Software Update PART 1 – Introduction to SCCM and WSUS SCCM Software Update PART 2 – Software Update Point configuration SCCM Software Update PART 3 – Automatic Deployment Rules SCCM Software Update PART 4 – Create deployment packages manually SCCM Software Update PART 5 – Best practices Now that we have created an Automatic ...

    The post SCCM Software Update PART 4 – Create deployment packages manually appeared first on Tech-Coffee.

    ]]>
  • SCCM Software Update PART 1 – Introduction to SCCM and WSUS
  • SCCM Software Update PART 2 – Software Update Point configuration
  • SCCM Software Update PART 3 – Automatic Deployment Rules
  • SCCM Software Update PART 4 – Create deployment packages manually
  • SCCM Software Update PART 5 – Best practices
  • Now that we have created an Automatic Deployment Rule and so deploy an update package, I will do the same thing manually. In this example I will create a deployment package for System Center Operation Manager 2012R2 with February 2014 updates. Steps to make and deploy an update package are:

    1. Filter with some criteria updates
    2. Select filtered updates and create a Software Update Group
    3. Deploy this Software Update Group (and so on same wizard create deployment package)

    Filter updates

    On this screen, click on Add Criteria and choose relevant criteria. In my case I select Product and Date Released or Revised.

    As below screenshot, I select System Center 2012 R2 – Operation Manager product and updates released last month.

    Create software update group

    Once your updates are filtered, select and right click on them. Click on Create Software Update Group.

    On the next screen, type a name and a description for the Software Update Group.

    Open Software Update Groups menu. The previous Software Update Groups is here. Note that those are created by Automatic Deployment Rule are also here.

    Create a deployment package to deploy Updates

    Right click on your Software Update Group and select deploy.

    Once Deploy Software Updates wizard is opened, you can fill in the fields. Note that all settings are the same as those of the Automatic Deployment Rule.

    On Deployment Settings screen, choose the type of deployment (Required or Available) and the logs detail level.

    On scheduling screen, set the software available time and the deadline. I set my deadline 7 days after that the software is available.

    On User Experience screen, set the client behavior about notification and deadline. On the below example, when deadline is reached, updates are installed but the server is not restarted automatically.

    On Alerts screen, specify if you want to create Configuration Manager alert. Then if you use Operation Manager on your environment you should Disable Operation Manager alerts while software updates run. You can also generate alerts on Operation Manager when updates failed.

    Then configure the behavior about clients on slow network boundary (slow link) and fallback source.

    On Deployment Package, you can create a new update package or add updates to an existing deployment package. Choose a package source to store update binaries.

    Next set a distribution point.

    On Download Location, specify where download update binaries.

    On Language Selection screen, select in which language you want download updates.

    On Summary screen, you have the resume of the configuration. Note that you can save the deployment settings as a template.

    The next screen can take time because SCCM downloads updates.

    To finish, the package is created and deployed.

    As you can see on below screenshot, the previous selected updates are deployed.

    The post SCCM Software Update PART 4 – Create deployment packages manually appeared first on Tech-Coffee.

    ]]>
    https://www.tech-coffee.net/sccm-software-update-part-4-create-deployment-packages-manually/feed/ 0 223
    Software Update with SCCM PART 3 – Automatic Deployment Rules https://www.tech-coffee.net/software-update-sccm-part-3-automatic-deployment-rules/ https://www.tech-coffee.net/software-update-sccm-part-3-automatic-deployment-rules/#comments Sat, 08 Mar 2014 19:24:08 +0000 https://www.tech-coffee.net/?p=185 SCCM Software Update PART 1 – Introduction to SCCM and WSUS SCCM Software Update PART 2 – Software Update Point configuration SCCM Software Update PART 3 – Automatic Deployment Rules SCCM Software Update PART 4 – Create deployment packages manually SCCM Software Update PART 5 – Best practices In this part I will create an ...

    The post Software Update with SCCM PART 3 – Automatic Deployment Rules appeared first on Tech-Coffee.

    ]]>
  • SCCM Software Update PART 1 – Introduction to SCCM and WSUS
  • SCCM Software Update PART 2 – Software Update Point configuration
  • SCCM Software Update PART 3 – Automatic Deployment Rules
  • SCCM Software Update PART 4 – Create deployment packages manually
  • SCCM Software Update PART 5 – Best practices
  • In this part I will create an Automatic Deployment Rule to update Windows Server 2012 R2. As a reminder, Automatic Deployment rule enables to create update package automatically according to some criteria such as release date, classification or language. The scheduler for creating update package can be fine-grained configured. It is possible for example to create update package automatically every second Tuesday of each month. Once the package is created, it is automatically deployed to deployment point and servers perform updates on their maintenance period. This update method should not be used on complex environment as Hyper-V cluster or Exchange infrastructure. These examples of environment need orchestrator to avoid downtime of services.

    Create an automatic deployment rule

    To create Automatic Deployment Rule open SCCM console, go to Software Library and right click on Automatic Deployment Rule and click on New:

    So I create an Automatic Deployment Rule called « Baseline – W2012R2 » with the Patch Tuesday template. The current configuration can be saved as a template at the end. Each time a package is created, SCCM create automatically a new Software Update group. If the other option is chosen, a unique Software Update Group is created and updates are added to it. That means each time an update package is deployed, it will contain all updates even those that are already deployed. For Tuesday patching, I recommend to create new Software Update Group.

    On deployment settings, specify if you want use Wake-on-LAN (useless on servers because at 99% of the time there are always switch on). Next select the desire logs detail level and the behavior about license agreements.

    On software updates screen, set the criteria for choosing the updates that will be added to update package. In my example I choose updates that match these criteria:

    • Release or revised on last month.
    • Updates target Windows Server 2012 R2.
    • Updates have to be English language.
    • Updates have to be Critical updates or Definition Updates or Security Updates or Rollups or a simple update.

    On evaluation schedule, specify when run the rule to make an update package. On my example, I run the rule every second Wednesday of each month (in France updates are available Wednesday because time difference).

    030814_1916_SoftwareUpd5

    On deployment schedule, specify the update package available time and the installation deadline. Mostly these settings should be configured regarding company security policies.

    On user experience screen, set the behavior on clients side. Specify notifications level to display on Software Center, the behavior when the deadline is reached and you can suppress restart on specific devices such as server.

    Alerts screen is really useful when Operation Manager monitor IT Infrastructure. It is possible to disable monitoring on servers that will be updated and generates alerts if an update fails. Also a report can be generated on Configuration Manager.

    Downloads settings screen enables to configure clients’ behavior for downloading when there are on a slow link (slow site boundaries in SCCM language). For this type of clients, you can specify a fallback distribution point

    On deployment package screen, you create your update package. It is necessary to specify a package source: this is the path where update binaries are stored. A folder can’t be used for more than one package source. If a deployment package already exists, you can select it.

    On distribution points screen, specify SCCM distribution points where the deployment package will be sent.

    On download location screen, select the source of downloading updates.

    Then select the languages downloaded …

    To finish confirm settings. Note that you can Save as Template your Automatic Deployment rule.

    Once your Automatic Deployment Rule is created, it appears in the menu. On the same line, you can see the last error. Here the rule has run without error.

    After that Automatic Deployment Rule has run, the update package is created and is deployed.

    Then Software Center on clients can install updates on maintenance period. Note that you can install manually updates.

    The post Software Update with SCCM PART 3 – Automatic Deployment Rules appeared first on Tech-Coffee.

    ]]>
    https://www.tech-coffee.net/software-update-sccm-part-3-automatic-deployment-rules/feed/ 9 185
    SCCM Software Update PART 2 – Software Update Point configuration https://www.tech-coffee.net/part-2-software-update-point-configuration/ https://www.tech-coffee.net/part-2-software-update-point-configuration/#comments Fri, 07 Mar 2014 21:01:32 +0000 https://www.tech-coffee.net/?p=136 SCCM Software Update PART 1 – Introduction to SCCM and WSUS SCCM Software Update PART 2 – Software Update Point configuration SCCM Software Update PART 3 – Automatic Deployment Rules SCCM Software Update PART 4 – Create deployment packages manually SCCM Software Update PART 5 – Best practices Add Software Update Point in SCCM hierarchy ...

    The post SCCM Software Update PART 2 – Software Update Point configuration appeared first on Tech-Coffee.

    ]]>
  • SCCM Software Update PART 1 – Introduction to SCCM and WSUS
  • SCCM Software Update PART 2 – Software Update Point configuration
  • SCCM Software Update PART 3 – Automatic Deployment Rules
  • SCCM Software Update PART 4 – Create deployment packages manually
  • SCCM Software Update PART 5 – Best practices
  • Add Software Update Point in SCCM hierarchy

    First, connect to SCCM, open Administration panel and select Site Configuration -> Servers and Sites System Roles. On the below screenshot, VMSMS01.fabrikam.com is my Primary Site with WSUS installed but not configured (I stopped myself just after configuring the WSUS database). This is SCCM that set parameters on WSUS.

    Figure 1: Servers and Site System Roles overview

    So I right click on the VMSMS01.fabrikam.com server and I select Add Site System Roles. The goal is to add Software Update Point and configure WSUS service.

    Figure 2: Choose server on which role will be installed

    Figure 3: Set a proxy if necessary

    Once you have chosen the server where will be added SUP and after configured proxy, it’s necessary to specify the role to add. I think you have an idea of which role to select … Tadaa: Software Update Point.

    Figure 4: Add Software Update Point role

    My WSUS installed is set to answer on 443 port because I have a PKI in my lab with auto-enrollment. So I can test the communication between SCCM and WSUS with SSL. If you have not configured WSUS with SSL, don’t select checkbox Require SSL communication to the WSUS server.

    Figure 5: Configure how to connect to WSUS service

    Next step asks you to configure credentials to connect to WSUS server. This step is needed in a production environment to specify a special account to communicate between WSUS and SCCM.

    Figure 6: Set credentials with right on WSUS service

    Next, it is the configuration of WSUS. You will retrieve the same step when you are configuring WSUS. First you have to specify the source of synchronizing Microsoft update. My WSUS is the first WSUS on my lab so I select Synchronize from Microsoft Update. If you have an upstream server, please select the other option.

    The WSUS report parameter should be configured with the first option in 95% of time because SCCM doesn’t use these reports. These last are created on client computers for Windows Update services and SCCM doesn’t use them.

    Figure 7: Set synchronization source settings

    Such as classical configuration of WSUS, you have to set how often synchronization occurs. Because I have no requirement on my lab, I leave the default settings.

    Figure 8: set how often synchronization occur

    To understand next step it is necessary to make a point about superseded update.

    Suppose that an update (called U1) fix Internet Explorer 11 on December 2013 and another update (called U2) fix same product released on January 2014. U2 is a cumulative update that contains also U1. In this example, U1 is superseded by U2.

    So on supersedence rules, you have to configure the behavior of update that are superseded. Like previous step, I have no requirement on my lab so I leave the default settings.

    Figure 9: Configure behavior about superseded update.

    For my lab, I download all classifications because I will sort when I will make my updates packages.

    Figure 10: Software update classifications

    WSUS needs to synchronize once a time to have a more recent product catalog. This is why Windows Server 2012R2 doesn’t appear.

    Figure 11: Products to synchronize

    Figure 12: language to synchronize

    Figure 13: Confirm settings

    Figure 14: End of SUP configuration

    Verify the good configuration

    In this section, I verify that SUP configuration is correct. The first place to be is the monitoring view on Software Update Point Synchronization Status. This status provides information about the last synchronization with WSUS.

    Figure 15: WSUS synchronization monitoring

    Figure 16: SCCM logs files

    To debug an issue, the best way is to open logs files. All these files are in %INSTALLFOLDER%\Microsoft Configuration Manager\Logs

    The file WSUSCtrl.log contains information about WSUS synchronization (c.f Figure 17)

    Figure 17: WSUSCtrl content

    The above screenshot presents a successfully configuration and synchronization with WSUS.

    Figure 18: Update catalogs on SCCM

    When the synchronization with WSUS is finished, updates appear in the Software update menu.

    The post SCCM Software Update PART 2 – Software Update Point configuration appeared first on Tech-Coffee.

    ]]>
    https://www.tech-coffee.net/part-2-software-update-point-configuration/feed/ 4 136