For large organizations, having your CM servers including SUPs at a central location with high bandwidth connection is the optimum design.   However, they (SUPs) may sometimes cause network saturation within the remote branches or pockets with low bandwidth connectivity.   This happens when clients either move from one site to another (requesting a full scan), or when they fail repeatedly and try to connect to another SUP from the SUP list within your site and perform a full scan.   The way to safely control this is to leverage QOs within your environment.   But if QOs is not available, to quickly get this under control is to temporarily apply bandwidth limitation on your SUPs servers until the full scan jobs are gone.   Here's a quick POSH to remotely apply limitation on your WSUS Administration web sites (SUPs).

The default value of maxBandwidth is 4294967295.   Here below, i'm setting the SUPs to a really low value, 100k.   Play around with that number and see what the acceptible value is for your environment to avoid scan failures at the same time being network friendly at the time of the saturation.  

invoke-command -computername (Get-Content "C:\SUPServerList.txt") -scriptblock {Import-module WebAdministration ; Set-ItemProperty 'IIS:\Sites\WSUS Administration' -name limits.maxBandwidth 100000}

 

After upgrading your CM12 Primary site(s) to Windows Server 2012 R2, you may experience the following issues.

1.  You may not be able to access the console after the upgrade.  Check SMS Admins permission to the Primary site's WMI's root/SMS and root/SMS/Site_XXX.

SMS Admins group should have the following:

    • Root/SMS
      • Enable Account
      • Remote Enable
    • Root/SMS/Site_XXX
      • Executable Methods
      • Provider Write
      • Enable Account
      • Remote Enable

 

2.  Your MPs may experience issues moving files to its Primary site’s inbox folders after upgrading your Primary site to Server12 R2.   Overtime, if this is unnoticed, you would see your clients become inactive in the console.   You may see similar errors below in your MPFDM.log.

mpfdm

 

The only fix we have found so far that’s effective is to add the MPs in local\admins group of that Primary site that’s been upgraded.

 

Ever get tired of having to login remotely to DRACs and clearing the logs that way?   Here's a quick POSH for doing the same, but saves a lot of time.  Gotta love invoke-command :).   I suppose you could use PSEXEC too, but that's so 80s. :)

 

For clearing Individual servers example

Invoke-Command -Computername MYSERVER01 -ScriptBlock {omconfig system esmlog action=clear}

 

Or by group or list of servers Example

Invoke-Command -Computername (Get-Content "C:\ServerList.txt") -ScriptBlock {omconfig system esmlog action=clear}

 

 

 

It is generally recommended to use shared SUSDB In your CM12 environment when you have multiple SUPs (Software Update Points) in a single primary site. Thus, have you ever had the need to switch from using SUPs with their own SUPDBs to shared SUPDB?   We did this simply to avoid the clients in failed state for long periods and to avoid that network cost.   Below is the script that I put together to switch from using non-shared SUPDB to shared SUPDB on our SUPs>

This script pretty much follows the general guideline of setting up your SUPs with shared SUPDB.   However, since we had already had it set in place where our SUPs were already using their own SUPDBs, so this will uninstall WSUS off your existing SUP or remove the role (windows feature) so that it can reset which DB it’s pointing to.   Then it follows it up with post configuration to put things back, and to where your SUPs are pointing to that single or common shared WSUS Database.

General guideline of installing multiple SUPs with Shared SUPDB.

  1. Prepare the Database server, create the share (WSUSContent) and create the WSUS group that has access to the share
  2. Install the first SUP with WSUS pointing to the common SUPDB and move its content to a Central\shared location (copy content)
  3. Install the subsequent SUPs with WSUS pointing to the common SUPDB and move its content to a Central\shared location (-skip copy)

 

Here’s what the menu prompt looks like:

SUPDB

 

Quick breakdown of what each above does:

DB option

  • Creates the WSUSContent directory and shares it out
  • Then it creates the local WSUS Content group

SUP1

  • Removes the role and adds it back
  • Runs the post configuration using WSUSUTIL and points to the remote SUPDB
  • Runs the post configuration using WSUSUTIL and moves the content
  • Adds the SUP1 computername to WSUS Administrators group that has access to the content
  • Sets the Virtual Content access to use a service account (Change user and pass in this the script)

SUPX

  • Removes the role and adds it back
  • Runs the post configuration using WSUSUTIL and points to the remote SUPDB
  • Runs the post configuration using WSUSUTIL and moves the content with -skipcontent
  • Adds the SUP1 computername to WSUS Administrators group that has access to the content
  • Sets the Virtual Content access to use a service account (Change user and pass in this the script)

Lastly, this creates a log in the same folder you run this script under. $scriptname.log.

Again, use this at your own risk! But I hope it helps! J

 

NOTES:

  • Script only supports Windows Server 2012 and/or Windows Server 2012 R2
  • The WSUSDB server also holds the WSUSContent share here as well. You can change that in the script if you’d like J. And it obiously requires IIS on the SUPDB J
  • Run this script locally on the box you are working on. You will need to run this on the remote database server first to prep the DB. Then run it on the SUP1, SUP2 SUP3 and so on, following the guideline above.
  • Pay attention to the variables that are set above the script.   And it is domain aware, so change the variables in there according to domain environments you have. This is really useful for folks that have Lab and production environments. So you only make one script change and it applies to both for consistency.

JInstall-SUPSharedDB.zip

 

 

 

 

Ever used ADRs (Automatic Deployment Rules) functionality in CM12?  Use it!  Granted, the search engine in there could use some work, but it's probably the best feature that was added in CM12!   I have to give my buddy Mason credit for this, for he has a lot to do with this addition :).

Anyway, we leverage ADRs in our environment for simply downloading the Monthly patches. Then we just turn around and add these downloaded patches to our Monthly patching groups with a deployment set to it. Well ok, we’ve automated the monthly downloads, now I kind of wanted to automate the group membership addition step here, for managing and patching our own servers. Well, how do we do that without having to recreate the patch deployment to our servers or kicking off the patch installs on our servers right away and impacting them?   Granted we have maintenance windows set for them, but we still wanted to tightly control this process and set the deployment deadline time appropriately in the future. So the answer is, we set the Update deployment to our Pilot collection first (to avoid impact), then add the newly downloaded patches from the ADRs to our group. Then modify the existing deployment’s deadline time later when pilot servers are validated.

So the POSH script below is what I had put together for this process.   So after the ADRs are done downloading, intent is to run this script and here’s what it does:

  1. Loads the CM12 PS module and connects to the CAS
  2. Sets or points the existing deployment to our pilot collection
  3. Then it grabs the downloaded updates from the ADR groups, and add them to our Software Update Group

NOTE: You can change that Pilot collection to an Empty collection, for added safety measures.  And this also ensures that itanium updates are not added. For every now and then, those clowns get added in our group somehow. So this should avoid that. Oh, this would also go hand in hand with my other script/posting “Posh to remove expired and/or superseded updates from a CM12 Software Update Group”.

Use it at your own risk! :)

Set-CMUpdateGroupDep.zip

  • 1
  • 2