Skip to main content

Written by Brian Mason.

January 2018 Meeting Notes

Workflows + Managing Risk = Automation!

Notes taken by Andy Kreienkamp, edited by Brian Mason

Updated with link to slides

Topics: Secure Communication, Client Health, Server Groups, and Data Warehousing

 

How to secure SCCM communication on TLS 1.2?

  • PKI architecture...start by asking what your PKI footprint looks like. What type of infrastructure is already in place?
  • First off, know that CM can go fully to TLS 1.2.  Documentation here.
  • Need 3 SHA-2 certs (can be identified by the versioning in the template)
    • Web server cert (IIS)
    • Distribution point cert
    • Client authentication cert
      • *NOTE* documentation says to use Server 2003 compatibility settings--only use this for Windows server 2008. Server 2012 and newer can use Server 2012 compatibility settings
  • IIS
    • When assigning security, it's best to have a security group containing all machines that need to talk to SCCM via IIS that you can add permissions to
  1. Duplicate templates for each 3 types
  2. Create a cert from the new templates
  3. Go to each machine that needs a cert, Certlm.msc > Personal > Certificates > Request Certificates
  • If it works for a bit but then stops, make sure you have a CRL!
  1. Open IIS, Default Web Site, Bindings > https (to add the cert)
  • Distribution Point
    • Distribution Point cert needs to be exported with a private key for HTTPS only
    • Administration > Site Configuration > Servers and Site System Roles > Distribution Point > Properties
    • This cert should only be put here, then LEAVE IT ALONE
  • Client Authentication
    • Not much to say on this one
  • App Catalog services.  These must go to HTTPS for TLS 1.2.

Are you HTTPS-ready?

    • Not ready? Cert's expired OR don't have a Cert
  • Create a package that'll run this program on each client
    • Then, create a PowerShell script that targets certain strings in the log file, and use that to create a configuration baseline.
  • Sites > Properties > "Use PKI Client cert when available" = Checked
    • "Clients check the CRL for site systems" = Checked if the client can always reach the CRL--if the client can't reach the CRL, this will cause problems!
  • When switching a site to HTTPS only, all MPs will reinstall!
  • OSD - your boot image needs the certificate
  • WSUS also needs a cert for HTTPS, and to select "Require SSL" in SSL Settings in IIS, and to run wsusutil.exe /configuressl <servername>

Why HTTPS on SCCM?

  • HTTPS is the gateway to lots of other things, including Internet-based client management!
  • Can help manage better compliance of off-prem computers (out-of-band management) -- IBCM (Internet-Based Client Management) or CMG (Cloud Management Gateway, everyone seems stoked about CMG)
  • Note the the support limit is currently 6K clients per gateway.  Larger companies can expect some cost.

Making sure the client works on HTTPS:

Restarting the agent and view traffic in some logs:

  1. ClientIDManagerStartup.log: first handshake with the Management Point
    1. Look for "Client is registered", if not registered, your problem is here
  1. LocationServices.log
  • . StatusCode = 0
  1. CCMMessaging.log
  2. PolicyAgent.log
  • . Look for HTTPS communication after running Machine Policy

PFE FAQ

  1. Upgrade Analytics / Upgrade Readiness! Free? How to get it set up in our environment?
  1. We don't have azure, we don't have OMS
    • This component of OMS is free, even though OMS is paid
        1. Can use a 'demo mode' to populate false data to give an idea of what you can do with upgrade readiness
  1. Basic telemetry is the required level
  2. Upgrade Readiness tells you all the devices that won't have a problem, so you can deploy win10 upgrade right to a collection of them--as well as the devices that will have a problem

Client Health

  • Iffy client health directly leads to poor compliance. How should you handle this?
  • There are some built-in client health tools in SCCM with limited functionality
  • Biggest offender: Active Discovery System Discovery!
    • Disabled items can cause problems. Start with AD sanitization!
  • Dsquery computer -inactive [number of weeks]
  • Filter stale computer records from Discovery:
    • AD System Discovery Properties:
      • Only discover computers that have logged on in a given period of time (90, 120 days, etc)
  • DNS Scavenging - maybe this can be enabled in your environment? Discuss with your team
  • Client Status Settings
  • Maintenance Tasks to help purge your system of inactive/dead/retired devices
    • Delete Aged Discovery Data
    • Delete Inactive Client Discovery Data
    • Delete Obsolete Client Discovery Data
  • Ccmeval.exe and Ccmeval.xml, resulting in ccmevalresult.log, ccmevaltask.log and ccmeval.log (check this on clients, maybe with a Configuration Baseline?)
    • There is a client eval scheduled task on all clients, runs every day at midnight
  • Consider modifying ccmeval to run more or less frequently (CCMEVALINTERVAL)
  • Consider disabling auto-remediation on servers (registry settings NotifyOnly-True, SendAlways-True)
  • Client Status Reports in Monitoring > Reporting
  • V_r.system table in CM DB, look for things like "obsolete"
  • Custom client health collection
  • Other Tools:
    • PFE Client Health tool ($$)
    • Jason Sandys' startup script
    • Anders Rodland's client health
    • Adaptiva's client health
  • Use SCCM to filter noise from AD!
    • In SCCM - Create a device collection with all managed systems (criteria: has an SCCM Agent), then create device collections with unwanted data and exclude them from your all managed systems collection. PFE Client Health tool (talk to your TAM if you want this). Make your deployments to this, rather than full collections with bad client records to see your compliance go up. Self-healing!
      • Example: create a device collection for all computers where Task Scheduler isn't running, then deploy a program to it that starts Task Scheduler.
      • Example: Export GPOs into CABs, and have SCCM look at the output locations to turn those into Configuration Items to monitor GPO compliance/reporting

CM CB - Server Groups

  • What is it?
    • It's a prerelease feature--NOTE! Prerelease features are 100% supported in production, and are fully production ready. Prerelease means they're still being developed at a faster pace.
    • Can be used for complex software update scenarios
    • Can be used for traditional configmgr software update deployment
    • It can be used for tons of stuff, as long as it uses the software update engine
  • Why use them?
    • Can specify a % of computers in a collection to allow updates simultaneously
    • Can specify the order that computers will update in
    • Can include an optional takedown (Node Drain Script) and a resume (Node Resume Script) script for operations the machines will take before and after shutdown
    • Automate those 'special' systems that until now needed manual patching!
    • 'Locking'--the server checks to see if it can patch yet. If yes, then a Lock is enabled and it will process the patches. If no, tries again later, until it can achieve a Lock and begin the patching
  • How does it work?
    • 1. CLient recieves policy indicating that its part of a server group
    • 2. Client attempts to install software update, requesting a Lock
    • 3. MP queries site database to determine if Lock is available. Also checks client install priority (if applicable)
    • 4. Client either receives a Lock/priority status and proceeds to install update OR retries until a Lock/priority status becomes available
  • DEMO!
    • 1. Enable Server Groups in features
    • 2. Create a device collection containing clients/servers
    • 3. Configure Server Group settings
      • Simultaneous updates or maintenance sequence
      • Node Drain Script
      • Node Resume Script
      • Script timeout
    • 4. Check box indicating that "all devices in this collection are part of the same server group"
    • To demo, create a Drain script that creates a log file called "start" and a Resume script that creates a log file called "end." Kick off an update installation on two machines simultaneously, and watch the log folders to see one machine complete before the next one begins. You can observe the Lock states in UpdatesDeployment.log on a client machine.
  • How does the MP determine whether it can send a Lock?
    • Query the site DB:
      • Select * from system_disc where name0 = '<clientname>'
        • Collect SMS unique Identifier (GUID)
      • Exec spgetlockstate N'<GUID>'
        • Lock States
          • 0 = nothing
          • 1 = trying to get a Lock
          • 2 = released Lock
          • 3 = script error
      • Select * from DeploymentMutex
  • Lock stuck? Right click device collection, Release All Locks

CM CB - Data Warehouse

  • A supported way to offload your Site DB without relying on DB replication (which can cause problems)
  • SSRS can run reports against both your Site DB and your Data Warehouse
  • Install Data Warehouse service point on one of the servers in your site
    • Input the server you want to offload to, the DB name, and how often to sync data
    • Note: The Data Warehouse won't actually be created until your first sync!
  • Can run some built-in SCCM reports on the Data Warehouse (Monitoring > Reporting > Reports > Data Warehouse)
  • To manually sync, delete the regkey DWSS Services.msc > ConfigMgr Data Warehouse Synchronization Service
  • Set verbose logging in C:\Program FIles\SMS_DWSS\Microsoft.ConfigMgrDataWarehouse.exe.XML
  • A nice bonus is that you can set your CM maintenance tasks back to prune CM's DB, but keep the DW DB for long term data.

 

  • Created on .