<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="https://www.w3.org/2005/Atom" xmlns:sy="https://purl.org/rss/1.0/modules/syndication/" xmlns:dc="https://purl.org/dc/elements/1.1/" xmlns:content="https://purl.org/rss/1.0/modules/content/" xmlns:wfw="https://wellformedweb.org/CommentAPI/" xmlns:slash="https://purl.org/rss/1.0/modules/slash/"
  version="2.0">
  <channel>
    <title>Sam Roberts's TechNet Blog</title>
    <atom:link
      href="https://docs.microsoft.com/archive/blogs/samroberts/feed.xml"
      rel="self"
      type="application/rss+xml" />
    <link>https://docs.microsoft.com/archive/blogs/samroberts/feed.xml</link>
    <description>ConfigMgr, PowerShell &amp;amp; More</description>
    <lastBuildDate>Wed, 17 Apr 2019 03:32:31 GMT</lastBuildDate>
    <language>en-US</language>
    <sy:updatePeriod>hourly</sy:updatePeriod>
    <sy:updateFrequency>1</sy:updateFrequency>
    <item>
      <title>Configuration Manager Content Update Automation</title>
      <link>https://docs.microsoft.com/archive/blogs/samroberts/configuration-manager-content-update-automation</link>
      <pubDate>Mon, 18 Dec 2017 06:42:06 GMT</pubDate>
      <dc:creator><![CDATA[Sam_Roberts]]></dc:creator>
      <guid
        isPermaLink="false">https://blogs.technet.microsoft.com/samroberts/?p=235</guid>
      <description><![CDATA[I recently encountered a challenge at one of my customers where the content library on the...]]></description>
      <content:encoded><![CDATA[I recently encountered a challenge at one of my customers where the content library on the distribution points had become corrupted.  The result was that we had to update the content of every package, application, driver, image etc. in order to correct the issue in the content library.  If you have ever had to do this before you know that this can be a very time consuming activity depending on how much content you have and the size of the environment.  My solution was to write a PowerShell script to do the heavy lifting for me.  You can download the script below.

The script is designed to maintain a specified number of packages updating at all times.  I didn't want to overwhelm the site or queue up too many updates in case something higher priority needs to be updated.  The script will check for how many content updates on in an "In Progress" state and try not to exceed the number specified.  If the script determines that content can be updated it will update packages based off of a list of PackageIDs specified in a text file.  After updating the packages the script will wait for a specified number of minutes.  After the wait period it will again check for the number of packages in progress and update more content if below the threshold.  The script will continue until it has updated all packages in the file.

Its important to note that the InProgressThreshold parameter only applies to content that is targeted to a number of distribution points greater than the value in the TargetThreshold parameter.  This option was created for large scale distribution where pull DPs may be in use and where there are a some sites that have slower network connections.  If this does not apply to you I would recommend either setting the TargetThreshold parameter to a value higher than the number of DPs you have or set InProgressThreshold to 0.

Download Here &gt;&gt; <a href="https://msdnshared.blob.core.windows.net/media/2017/12/Update-SCCMContent_1.0.zip">Update-SCCMContent_1.0</a>

-----------------------------------------------------------------------------------

NAME
Update-SCCMContent.ps1

SYNOPSIS
Updates Configuration Manager content based on a list of PackageIDs.

&nbsp;

SYNTAX
.\Update-SCCMContent.ps1 [-SiteCode] &lt;String&gt; [-InputFile] &lt;String&gt; [-InProgressThreshold] &lt;Int32&gt; [-TargetThreshold] &lt;Int32&gt; [[-MaxConcurrent] &lt;Int32&gt;] [[-Delay] &lt;Int32&gt;] [&lt;CommonParameters&gt;]

&nbsp;

DESCRIPTION
Using a text file containing a list of PackageIDs this script will gradually update content
while attempting to maintain a specified number of packages in the distribution queue.
Progress will be logged to a file name content_update_yyyymmdd_hhmmss.log in the user's
local AppData temp folder.

&nbsp;

PARAMETERS
-SiteCode &lt;String&gt;
The Configuration Manager site code. (example: L01)

Required? true
Position? 1
Default value
Accept pipeline input? false
Accept wildcard characters? false

-InputFile &lt;String&gt;
Path to a text file containing a list of PackageIDs to update.

Required? true
Position? 2
Default value
Accept pipeline input? false
Accept wildcard characters? false

-InProgressThreshold &lt;Int32&gt;
The number of packages with content distribution in progress. This will be used to help
determine when more updates will occur. This only applies to content that is targeting
a number of distribution points greater than or equal to the value of the TargetThreshold
parameter.

Required? true
Position? 3
Default value 0
Accept pipeline input? false
Accept wildcard characters? false

-TargetThreshold &lt;Int32&gt;
The InProgressThreshold value will only apply to content that is targeting at a number
of distribution points greater than or equal to this value.

Required? true
Position? 4
Default value 0
Accept pipeline input? false
Accept wildcard characters? false

-MaxConcurrent &lt;Int32&gt;
The number of content updates to run concurrently. If not specified the default is 5.

Required? false
Position? 5
Default value 5
Accept pipeline input? false
Accept wildcard characters? false

-Delay &lt;Int32&gt;
Number of minutes to delay between update cycles. If not specified the default is 15.

Required? false
Position? 6
Default value 15
Accept pipeline input? false
Accept wildcard characters? false

&lt;CommonParameters&gt;
This cmdlet supports the common parameters: Verbose, Debug,
ErrorAction, ErrorVariable, WarningAction, WarningVariable,
OutBuffer, PipelineVariable, and OutVariable. For more information, see
about_CommonParameters (https://go.microsoft.com/fwlink/?LinkID=113216).

INPUTS

OUTPUTS

-------------------------- EXAMPLE 1 --------------------------

PS C:\&gt;.\Update-SCCMContent.ps1 -SiteCode L01 -InputFile .\packageids.txt -InProgressThreshold 15 -TargetThreshold 100 -MaxConcurrent 25 -Delay 15

&nbsp;]]></content:encoded>
    </item>
    <item>
      <title>Create ConfigMgr Configuration Items from Group Policy Object</title>
      <link>https://docs.microsoft.com/archive/blogs/samroberts/create-configmgr-configuration-items-from-group-policy-object</link>
      <pubDate>Mon, 19 Jun 2017 22:00:43 GMT</pubDate>
      <dc:creator><![CDATA[Sam_Roberts]]></dc:creator>
      <guid
        isPermaLink="false">https://blogs.technet.microsoft.com/samroberts/?p=17</guid>
      <description><![CDATA[I have been asked by customers if it is possible to use ConfigMgr to monitor compliance of Group...]]></description>
      <content:encoded><![CDATA[I have been asked by customers if it is possible to use ConfigMgr to monitor compliance of Group Policy settings.  The short answer has always been yes but it is not easy.  If you had to manually identify all the registry keys associated with a GPO and create the individual CI rules this process could takes hours if not days for larger policies.  This script simplifies the process and queries for the values and creates the CIs in a matter of seconds.  I have seen similar scripts however many of the others still require user to create a .POL file for the script to ingest then import a .CAB file into ConfigMgr.  This script fully automates the process.
<h1><strong>What Does it Do?</strong></h1>
This script uses both the Configuration Manager and Active Directory PowerShell modules to query for registry keys associated with Group Policies then create the Configuration Items for each of the registry values.  I have updated the script to include a few options on how this gets done.

First, the script will either query for a single group policy or utilize a Resultant Set of Policy to determine applicable policies for a specified system.  To enable the Resultant Set of Policy (RSOP) option include the 'ResultantSetOfPolicy' parameter and specify the system to run RSOP against using the 'ComputerName' parameter.  Leveraging the Active Directory PowerShell module and the Get-GPResultantSetOfPolicy command the script will run an RSOP on a specified system and export the results to a temporary file.  The file is then searched to determine what group policies are applied to the system and what the link order is for those policies.  This will be used to determine what order the group policy data is queried to simulate their link order.  If the 'ResultantSetOfPolicy' option is not used this step is skipped and the script will query only for the one group policy specified.

To get a list of registry keys associated with the group policies the Get-GPRegistryValue command is used to query for the specified group policies.  The full key path, key name, value and data type are all stored in an array.  When the 'ResultantSetOfPolicy' option is used the group policies will be queried starting with the policy that would be applied last.  As each additional policy is queried the script will check to see if that registry key has already been stored with another value.  If the registry key is already present, the additional occurrence of that key will be skipped since the policy that is last applied would over write the lower policies.  If the 'ResultantSetOfPolicy' option is not used the script will only query for the one policy specified.

Once the script has successfully queried for all the associated registry keys and values it utilized the Configuration Manager PowerShell module to create the Configuration Item definition files in xml format.  This will include a setting and rule for each of the registry keys of supported data type (binary values are not supported by DCM).  You can specify the severity of non-compliant settings as well as remediation of non-compliant items using command line parameters.

The final step is to import the Configuration Item definition file into Configuration Manager.  By default, this is done automatically, creating a CI with settings and rules for all associated registry values.  If you do not wish to have this automatically created you can use the 'ExportOnly' parameter which will save the data to a .cab file which can later be manually imported into Configuration Manager.

In my tests, this script can query for and create a CI with over 200 registry values in under 20 seconds.
<h1><strong>How to Use the Script</strong></h1>
This script must be executed from a system that has access to both the GroupPolicy and ConfigurationManager PowerShell modules.  The GroupPolicy module is installed with the Remote Admin Tools and the ConfigurationManager module is installed with the ConfigMgr Admin Console.  Additionally, if the 'ResultantSetOfPolicy' option is used the user must have remote admin access to that system.  Extract the .ZIP file and execute the PowerShell script via a PS console.

<strong>Download Here</strong> &gt;&gt; <a href="https://msdnshared.blob.core.windows.net/media/2017/11/Convert-GPOtoCI_1.2.6.zip">Convert-GPOtoCI_1.2.6</a>
<h4><strong>Parameters:</strong></h4>
<ul>
 	<li><strong>GroupPolicy</strong> [optional] - This is enabled by default and will make the script query only for one specified group policy.</li>
 	<li><strong>GpoTarget</strong> [required unless ResultantSetOfPolicy option is used] - Name of group policy object</li>
 	<li><strong>ResultantSetOfPolicy</strong> [optional] - Utilizes a resultant set of policy to determine the set of applied GPOs.  Cannot be used in conjunction with the GroupPolicy option.</li>
 	<li><strong>ComputerName</strong> [required when ResultantSetOfPolicy is used] - Name of system to run RSOP on.</li>
 	<li><strong>DomainTarget</strong> [required] - Fully qualified domain name</li>
 	<li><strong>SiteCode</strong> [required] - ConfigMgr site code</li>
 	<li><strong>Remediate</strong> [optional] - Enable configuration item to remediate non-compliant settings</li>
 	<li><strong>Severity</strong> [optional] - Sets the severity of non-compliant items.  (None, Informational, Warning or Critical)</li>
 	<li><strong>ExportOnly</strong> [optional] - Exports the Configuration Item to a CAB file to be manually imported</li>
 	<li><strong>Log</strong> [optional] - Writes all discovered registry keys and their related GPO name to a file.</li>
</ul>
<strong>Example 1:</strong>

.\Convert-GPOtoCI.ps1 -GpoTarget "Windows 10 Settings" -DomainTarget contoso.com -SiteCode T01

<strong>Example 2:</strong>

.\Convert-GPOtoCI.ps1 -GpoTarget "Windows 10 Settings" -DomainTarget contoso.com -SiteCode T01 -Remediate

<strong>Example 3:</strong>

.\Convert-GPOtoCI.ps1 -GroupPolicy -GpoTarget "Windows 10 Settings" -DomainTarget contoso.com -SiteCode T01 -Severity Warning

<strong>Example 4:</strong>

.\Convert-GPOtoCI.ps1 -ResultantSetOfPolicy -ComputerName lab-srv-test01 -DomainTarget contoso.com -SiteCode T01

<strong>Example 5:</strong>

.\Convert-GPOtoCI.ps1 -GpoTarget "Windows 10 Settings" -DomainTarget contoso.com -SiteCode T01 -ExportOnly

<strong>Tested On:</strong>

Configuration Manager vNext 1706

&nbsp;

<strong>Download Here</strong> &gt;&gt; <a href="https://msdnshared.blob.core.windows.net/media/2017/11/Convert-GPOtoCI_1.2.6.zip">Convert-GPOtoCI_1.2.6</a>

&nbsp;

&nbsp;
<h2>Change Log</h2>
<strong>v 1.1.1 </strong>(7/12/2017)
<ul>
 	<li>Added -ExportOnly switch that will export the Configuration Item data to a .CAB file instead of automatically creating the CIs.  This file can be used to import the CI into ConfigMgr.</li>
</ul>
<strong>v 1.2.1</strong> (7/17/2017)
<ul>
 	<li>Added -ResultantSetOfPolicy parameter to enable to script to run RSOP against a system to determine the applied group policies then query for all registry keys associated with the applicable policies and settings.</li>
</ul>
<b>v</b><strong> 1.2.3</strong> (9/18/2017)
<ul>
 	<li>Added the -Log switch that will log all discovered registry keys and their related Group Policy object to a file named gpo_registry_discovery_mmddyyyy.log in the scripts root directory.</li>
</ul>
<strong>v 1.2.4</strong> (9/18/2017)
<ul>
 	<li>Fixed bug where registry values were always being logged to file even when the -Log switch was not set.</li>
</ul>
<strong>v 1.2.6</strong> <strong></strong>(11/6/2017)
<ul>
 	<li>Bug fixes.</li>
 	<li>Allow for creation of User Policy based CIs.</li>
</ul>
&nbsp;

&nbsp;]]></content:encoded>
    </item>
  </channel>
</rss>