Configuration Manager Blog

Config Mgr maintenance tasks - Powershell to Document, Disable and Re-enable for site upgrades

sethprice — Tue, 17 Jul 2018 14:26:15 GMT

When running an in-place upgrade to System Center Configuration Manager you should document the status and disable maintenance tasks so they will not run during the site upgrade. https://docs.microsoft.com/en-us/sccm/core/servers/deploy/install/upgrade-to-configuration-manager In a small environment with one or two sites this is pretty easy and can be documented using Powershell or even a screen shot. After the site upgrade is complete the maintenance tasks can be re-enabled. In a large environment that has more sites you may want to look at automating the process of documenting current status, disabling tasks, and then re-enabling after the upgrade is complete. This script can be run from the CAS, primary site server or any system with the Configuration Manager console installed, it will perform the following actions: 1) Document and disable all maintenance tasks When the script is run with no parameters it will document current maintenance task status in an xml file and disable maintenance tasks in all Configuration Manager sites. File Location: C:\CM-MaintenanceTasks-$date.xml Now that all maintenance tasks have been documented and disabled we can schedule and complete the Configuration Manager upgrades for all sites. Once the upgrade is complete we can use the script to re-enable the maintenance tasks based on documented values in the CM-MaintenanceTasks-$data.xml file 2) Re-enable all site maintenance tasks Run script with parameter -enabletasks 1 Example: .\CMMaintenance.ps1 -enabletasks 1 This will open a file explorer window to allow you to choose the xml file to import. Choose the xml file that was created in step 1 by opening C:\CM-MaintenanceTasks-$date.xml. When executed the script will re-enable maintenance tasks based on the documented status of the task in the xml file. The script can be downloaded here: https://gallery.technet.microsoft.com/scriptcenter/Disable-and-Re-enable-38ae7514 Thanks to Kevin Kasalonis for assistance with the idea and script https://blogs.technet.microsoft.com/cmpfekevin/

Automating collection of Configuration Manager client logs

sethprice — Wed, 16 Aug 2017 07:24:08 GMT

Automating the Collection of Configuration Manager Client Logs Configuration Manager client logs are useful in troubleshooting many types of client issues including client installation, client health, software update installation, hardware inventory, and client policy. In many cases the administrator assisting with troubleshooting client issues does not have direct access to the systems with the required logs. This increases the time required to troubleshoot client issues, especially when multiple clients are involved or when clients are across multiple time zones. The following is a way for the Config Manager administrator to automate the collection of the client logs. The Configuration Manager client logs are stored in several folders, one for client logs, and one for client installation logs. The client installation log folder is located on the system drive under Windows\ccmsetup\logs. The client logs folder is normally located on the system drive under Windows\ccm\logs, however this location may be different in some situations. You can get the location of the client logs by running the following powershell command: Get-itemproperty “hklm:\software\Microsoft\ccm\logging\@global” | select –expandproperty Logdirectory In order to automate the collection of the client logs we need to create a shared folder to copy the logs to, and a ConfigMgr package to deploy to clients. In a small environment creating a single share location may be fine, however, in larger multi-site environments we would want to reduce WAN traffic as much as possible when copying client log files. One possibility is creating the shared folder on the ConfigMgr management point assigned to the client. Each client would then copy log files to its associated management point instead of a single location across a WAN link. We can get the clients management point by running the following powershell command: (get-ciminstance –namespace root\ccm\locationservices –class sms_mpinformation).MP[0] Now that we have the location of the client logs and a location to create the shared folders, we can begin to automate log collection. Client logs will be collected by deploying a package that runs a powershell script on the client. The required shared folders can be created by using compliance settings in ConfigMgr. By using compliance settings we can ensure that any new management point installed will automatically have the required share created. Creating the required shared folders using compliance settings Note: If you would rather import the configuration item and baseline into Configuration Manager using an exported CAB file it is attached below. If you import the configuration item and baseline skip to step number 2 below. Compliance-Import To manually create the configuration item and baseline follow these instructions 1. Create the Configuration Item and Configuration Baseline Create a new configuration item named CM-ClientLogShare

a. Select all versions of Windows

b. On the Specify settings for this operating system click New…

c. Provide a Name for the setting Setting type: Script Data type: Integer

d. Add the discovery and remediation scripts and click OK Discovery Script: (Script Language: Windows Powershell)

Discovery

Remediation Script: (Script Language: Windows Powershell)

Remediation

Note1: The log share created in the remediation script is created on the E:\ of the management point server. To change this location modify variable $Sharepath in the remediation script above. Note2: The discovery and remediation scripts will create an Event Log “ConfigMgr” on the management point servers as shown below: This can be used to troubleshoot discovery and remediation script execution. e. On the Specify compliance rules for this operating system page click New… Provide a name for the compliance condition Under Selected setting: Choose the setting created in the last step Rule type: Value Under setting must comply with the following rule: The value returned by the specified script: Equals 1 Select check boxes for: Run the specified remediation script when the setting is noncompliant Report noncompliance if this setting instance is not found f. Complete the Create Configuration Item Wizard g. Create a configuration baseline for deployment Provide a name for the configuration baseline Under Configuration Data, add the configuration item created in the last step 2. Create a collection and deploy the configuration baseline This collection will contain all the Configuration Manager servers with the Management Point role installed To create the collection use the following query criteria:

Verify the newly created collection contains the expected management point servers

a. Deploy the configuration baseline to the management point collection created in step 2 In the ConfigMgr console under Assets and Compliance > Compliance Settings > Configuration Baselines, right click the CCM Client Log Share baseline and click deploy Verify the baseline is selected Select Remediate noncompliant rules when supported Select Allow remediation outside the maintenance window Under Select the collection for this configuration baseline deployment, choose the collection created in step 2 Configure a schedule for how often the compliance rule should run Click OK b. Verify the shared folder is created on the management point servers after the compliance rule has run Folder Name: Client Logs Share Name: Clientlogs Share permissions: Domain Computers (Change, Read) Administrators (Full Control) NTFS permissions: Creator Owner (Special) System (Full Control) Administrators (Full Control) Users (Read and Execute) 3. Create and deploy the package to copy client log files When deployed to a device collection this package will execute a script that completes the following: Note: This script uses the command Compress-Archive which requires powershell 5

Creates a zip file containing the client log directories
Copies the zip file to the shared drive on the clients associated management point
Removes the zip file on the client

Follow these steps to create the package: a. Create a powershell script named ArchiveCCMLogs.ps1 with the following content: ArchiveCCMLogs b. Create a new package with source files, ArchiveCCMLogs.ps1 will be in the source file location for the packageCreate a program for the new package: c. Create a program for the new package: d. Command line: %WINDIR%\Sysnative\WindowsPowerShell\v1.0\powershell.exe -executionpolicy bypass -file ArchiveCCMLogs.ps1

Configure to run with administrative rights (Whether or not a user is logged on)

e. Distribute the package to your distribution points f. Create a new deployment collection with no members, deploy this package to the collection as either required, or available g. Add clients to the deployment collection to collect client logs Note: Once the client updates policy and executes the script, the client logs will be on the share associated with the system’s management point.

PE Peer Cache Custom Reporting - Examples

sethprice — Wed, 29 Jun 2016 16:48:24 GMT

PE Peer Cache – Custom Reporting Examples PE Peer Caching is a new feature in Configuration Manager which expands on the capabilities of Branch Cache. During an OSD deployment it allows the machine to pull content from other systems on the local subnet. PE Peer Cache supports local content for OS images, Driver Packages, Packages and Programs, and Boot Images. In a large network environment it may be difficult to identify and track both subnets where Peer Cache will provide a benefit, and the best client options for enabling Peer Cache content sources in that subnet. Some of the considerations in this decision would include: Enabling Peer Cache on subnet:

Number of workstation on subnet
Network location (Connection speed to DP in boundary group)

Enabling a client as a Peer Cache source

Client OS
CCM client version (Does it support Peer Cache)
Network Connection type (Wired vs Wireless)
System chassis type
- Example –Chassis type = 3,6, or 7 (Desktop, Mini Tower, or Tower)
- This would exclude systems types you may not want to use as a content source such as laptops, notebooks, hand helds and All in One systems.
Available system drive space

Here are a few examples of creating custom reports to assist with managing Peer Cache. ***Report requirements*** Hardware inventory classes Hardware inventory will need to be configured to collect the following WMI classes:

Root\ccm\softmgmtagent (CacheConfig) Specifically class ‘Size’ (This is required to get the CCM cache size on systems)
Root\ccm\policy\machine\actualconfig (CCM_SuperPeerClientConfig) Specifically class ‘CanBeSuperPeer’
System Enclosure (Win32_SystemEnclosure) –Chassis Types
Logical Disk (SMS_LogicalDisk) -Free Space (MB)

AD System Discovery will need to be modified to add the following AD Attribute “OperatingSystem” Report Example 1 PE Peer Cache Candidate Dashboard Zip file attached below contains:

Report RDL file
Report Screenshot
SQL query for report

PeerCacheDashboard This report lists the AD sites and the number of subnets associated with each site. Expanding the site and specific subnet will provide details on the client count in that site and the number of Peer Cache content source candidates. The details of the client in that site are listed and color coded for Peer Cache candidate status. Green = (Peer Cache is already enabled) Blue = (System meets to criteria to be recommended as a Peer Cache candidate) Gray = (System does NOT meet criteria for Peer Cache candidate) In this report the client system must meet the following criteria to be displayed in BLUE for Peer Cache capable. Note- The data used for candidate criteria is based on hardware inventory. Based on hardware inventory configuration this data may or may not be current (Default hardware inventory is 7 days)

OS version (Like %Windows% NOT like %Server%)
Ethernet connection (Adaptertype0) = ‘Ethernet 802.3’
IPAddress0 like ‘%.%.%.%’ (Not Null)
Free space on system drive is > 45 GB
CCM Client is Active
Client version is 5.00.8325.1000 or later
Chassis type in (3,6,7) – Desktop, Min Tower, or Tower

Note: The attached report will not list Server operating systems but I do have them enabled for display in the example report screenshot. Report Example 2 PE Peer Cache Enabled Clients Zip file attached below contains:

Report RDL file
Report Screenshot
SQL query for report

PeerCacheEnabled This report lists all systems that have the Peer Cache client enabled and system details such as chassis type, free system drive space, CCM cache size, client status, Client version, OS name, AD site, and default gateway.