ConfigMgrFTW! https://home.configmgrftw.com For The Win Tue, 26 May 2020 21:52:52 +0000 en-US hourly 1 https://wordpress.org/?v=5.4.1 https://i1.wp.com/home.configmgrftw.com/wp-content/uploads/2016/12/cropped-ConfigMgrFTW-icon-big.png?fit=32%2C32&ssl=1 ConfigMgrFTW! https://home.configmgrftw.com 32 32 121688700 Cloud Management Gateway Choices https://home.configmgrftw.com/cloud-management-gateway-choices/ https://home.configmgrftw.com/cloud-management-gateway-choices/#comments Tue, 14 Apr 2020 13:22:18 +0000 https://home.configmgrftw.com/?p=7019 One way that a CMG is more complicated though is in the multiple possible requirements choices that you can use to fulfill the prerequisites. If you're not paying attention to the details in the official documentation, it's pretty easy to confuse the requirements, mistakenly conflate them, or miss an important condition.

The post Cloud Management Gateway Choices appeared first on ConfigMgrFTW!.

]]>
In most ways, a Cloud Management Gateway (CMG) in Microsoft Endpoint Configuration Manager (ConfigMgr) greatly simplifies any organization’s path to managing their Internet-connected Windows systems. Namely, you don’t have to worry about adding any on-premises infrastructure. You also don’t have to talk to the network or security folks (although you still probably should even if they aren’t your best friends).

One way that a CMG is more complicated though is in the multiple possible choices that you can use to fulfill the prerequisites. If you’re not paying attention to the details in the official documentation, it’s pretty easy to confuse the requirements, mistakenly conflate them, or miss an important condition.

The Choices

There are three sets or categories of choices detailed below with some possible interdependencies based on the choices. These choices are specific to system management and machine policies only.

Client Authentication and Authorization

There are three choices here for systems connecting from the Internet. As implied by the name, this provides authentication or authorization of the client systems by the CMG and the site. These are more or less documented at Certificates for the cloud management gateway – – Client authentication certificate.

  1. Unique, PKI-issued client authentication certificate on each system.
  2. Azure Active Directory (AAD) or Hybrid Azure Active Directory (HAAD) domain-joined systems.
  3. A ConfigMgr issued token (this is brand new in ConfigMgr 2002 and requires the 2002 client agent; see Token-based authentication for cloud management gateway).

A client agent only chooses one method at a time, but different clients can use different methods. If a specific client happens to fulfill multiple of the above requirements, the agent will prefer them in the order listed.

CMG Authentication

This enables authentication of the CMG by the clients and secures the communication channel between the two using HTTPS. This is done using a PKI-issued, server authentication certificate from one of two sources:

  1. A public certificate authority (CA).
  2. An internal CA.

There is no technical difference between these two choices; the only practical difference is that your clients will automatically trust a certificate issued from a public CA (assuming you use a reputable public CA that is).

Management Point Authentication of Clients

There are two choices here; each has different implications though. The choices here also facilitate secure communication between the Management Point (MP) and the CMG service in Azure (although each accomplishes this in a slightly different manner).

  1. An HTTPS MP with a PKI-issued, server authentication certificate from an internal CA.
  2. An HTTP MP configured with Enhanced HTTP (HTTP).

User policy is slightly different and not specifically included in the details presented above. For user policy requirements on CMG connected systems, AAD authentication of the user must occur which requires the device to be HAAD or AAD domain-joined. See Deploy user-available applications on Azure AD-joined devices for additional requirements for available, user-targeted deployments.

Interdependencies

There are some interdependencies for the above sets of choices so it’s not quite as simple as choosing one from each. The following table depicts these interdependencies.

MP AuthClient AuthCMG Auth
HTTPS MPAnyBoth
eHTTPAAD/HAAD domain-join
ConfigMgr Token
Both
CMG Auth Interdependancies

The above table is a simplified, CMG-specific version of the table at Communications between endpoints in Configuration Manager — Client to management point communication.

Frequently Asked Questions

Q. Does using eHTTP mean we don’t have to do anything on the clients?
A. No. At least not until you get your clients up to 2002 in which case they will be automatically issued a token. Until you get your clients to 2002, they will still need to be AAD/HAAD joined.

Q. Does using eHTTP mean we don’t need a trusted certificate on the CMG?
A. No. You must have a server authentication certificate for the CMG and it must be trusted by all systems involved. Using a certificate from a public CA is generally the easy button solution to this.

Q. How can you make clients trust a CMG certificate issued from an internal-PKI if they cannot connect to the internal network?
A. This is a question outside the scope of ConfigMgr, but one possibility is to use Intune. ConfigMgr + Intune = Better Together.

Q. What if my PKI is only publishing the CRL to Active Directory.
A. Stop using that PKI; it was poorly designed. Use one of the other two methods: AAD/HAAD domain-joined or token.

Q. What if my PKI is not publishing the CRL to the Internet.
A. There are multiple possible paths here and most are PKI dependent. The easiest is to disable CRL checking in ConfigMgr; check with your security folks if this is acceptable though.

Q. Should I switch away from using internally-issued certificates to AAD/HAAD joined or tokens?
A. Not necessarily. In the grand scheme of the Microsoft ecosystem, AAD/HAAD domain-joining your devices is a good thing though and is a requirement for a lot of other functionality including Hello for Business, Conditional Access, and Co-management.

Q. Is one of these methods more secure than the others?
A. That’s a question for your security folks. Using PKI-certs is generally considered more secure for most things, but if your PKI itself is poorly designed or is insecure, then so will ConfigMgr’s use of it. Microsoft has designed each method to be secure and each should be considered secure. Security isn’t an absolute though and each choice should be evaluated based on your organizational standards and policies.

Q: Does the CMG connection point require the client auth cert? 1Contributed by David Paunovic
A. That depends. If the MP is configured for HTTPS and the clients are using a PKI issued client auth cert, then yes. If the MP is configured for eHTTP or the clients are AAD/HAAD joined or tokens, then no.

Q. What if my devices can’t currently connect to my ConfigMgr site but everything is already configured; i.e., the CMG is up and operational, the MP is properly configured, and the clients have a PKI client authentication cert or are AAD/HAAD joined? How do I tell the clients to start using the CMG?
A. If you have a way to modify the registry, add the following values to HKLM\Software\Microsoft\CCM in the registry and restart the client agent:

  1. CMGFQDNs (string): FQDN of the CMG
  2. DisAllowCMG (dword): 0

Review the locationservices.log for details after setting these values.

Additional Referencesc

Footnotes   [ + ]

1. Contributed by David Paunovic

The post Cloud Management Gateway Choices appeared first on ConfigMgrFTW!.

]]>
https://home.configmgrftw.com/cloud-management-gateway-choices/feed/ 2 7019
Missing Update Folder Within an Update Package https://home.configmgrftw.com/missing-update-folder-within-update-package/ https://home.configmgrftw.com/missing-update-folder-within-update-package/#respond Mon, 03 Feb 2020 17:08:51 +0000 https://home.configmgrftw.com/?p=6993 I did some quick cleanup of the update packages in my lab the other day before running the Automatic Deployment Rules. Unfortunately, this appears to have deleted a source folder and distribution manager was all too happy to let me know that the update package1Update Packages are referred to as Deployment Packages in most places in the admin console, however, I refuse to refer to them as such as they have no direct connection to…

The post Missing Update Folder Within an Update Package appeared first on ConfigMgrFTW!.

]]>
I did some quick cleanup of the update packages in my lab the other day before running the Automatic Deployment Rules. Unfortunately, this appears to have deleted a source folder and distribution manager was all too happy to let me know that the update package1Update Packages are referred to as Deployment Packages in most places in the admin console, however, I refuse to refer to them as such as they have no direct connection to deployments in any way. Most of the built-in reports properly refer to them as Update Packages though. now had a missing update folder within its source location.

Here’s an excerpt of the relevant portion of the distmgr.log on the primary site server:

Snapshot processing content with ID 16816292 … SMS_DISTRIBUTION_MANAGER 1/26/2020 8:52:59 PM 5556 (0x15B4)
The source directory \\cm301.lab300.configmgrftw.com\ConfigMgr\Content\Updates\AllWorkstationUpdates\88bb4359-0d2a-4a21-a055-4c7290ab1bf1 doesn’t exist or the SMS service cannot access it, Win32 last error = 2
Failed to take snapshot of one or more contents in package 30000021

So where to start with only a single, seemingly random ID of 88bb4359-0d2a-4a21-a055-4c7290ab1bf1 (the missing folder) which does not match the format of any IDs associated with updates as shown in the admin console? SQL Management Studio and a little bit of SQL of course.

Step 1: Find the Content ID

After a little bit of hunting around, I found a view associated with content that contained IDs that matched the format of 88bb4359-0d2a-4a21-a055-4c7290ab1bf1. A quick query confirmed this ID was in that view and was even associated with the package in question (30000021):

SELECT *
FROM vCI_ContentPackages
WHERE Content_UniqueID like '88bb%'

Step 2: Find the Update’s CI

The next step is to find the CI of the update associated with this content ID (16816292).

SELECT *
FROM v_UpdateContents
WHERE Content_ID = '16816292'

Step 3: Find the Update from the CI

Next, I found the actual update based on the two CIs returned.

SELECT *
FROM v_UpdateCIs
WHERE CI_ID = '16821322'
  OR CI_ID = '16865076'

Step 4: Review the Update’s Details

The final part of the discovery process here was to click on the SDMPackageDigest for each row to show the XML that defines the CI. The second CI shown above is for the update group (which was easily deduced when I reviewed the XML). The XML for the first CI listed the update that I needed to re-download. Here’s an excerpt:

<DesiredConfigurationDigest xmlns="http://schemas.microsoft.com/SystemsCenterConfigurationManager/2009/07/10/DesiredConfiguration">
  <SoftwareUpdateBundle AuthoringScopeId="Site_4AD729D7-A567-4F7A-85F6-C811A18D52E9" LogicalName="SUM_1ccbf8d2-e571-44a9-bbfe-b9bef824cd4a" Version="200">
    <Annotation xmlns="http://schemas.microsoft.com/SystemsCenterConfigurationManager/2009/06/14/Rules">
      <DisplayName Text="Update for Microsoft Silverlight (KB4481252)" />

Step 5: Delete the Update from the Package and Re-download

The final step here was to re-download the content for the update (KB4481252). Initially, I tried simply right-clicking on the update in the admin console, selecting Download, and then completing the download wizard. This doesn’t work because ConfigMgr thinks the update is already downloaded and so the wizard finishes successfully but without actually re-downloading the update. Thus, I opened the update package’s membership, selected the update, and deleted it from the package.

After deleting the update from the update package, I went back to the All Software Updates node, found the update, right-clicked on it, selected Download, and finished the download wizard. Once this finished, I updated the package on the lab distribution points and all was right with my update packages again. Don’t you love a happy ending? (I’m not going to link to a happy ending video here though as I’m afraid to search for that phrase.)

Footnotes   [ + ]

1. Update Packages are referred to as Deployment Packages in most places in the admin console, however, I refuse to refer to them as such as they have no direct connection to deployments in any way. Most of the built-in reports properly refer to them as Update Packages though.

The post Missing Update Folder Within an Update Package appeared first on ConfigMgrFTW!.

]]>
https://home.configmgrftw.com/missing-update-folder-within-update-package/feed/ 0 6993
Boundary and Boundary Group Import and Export https://home.configmgrftw.com/boundary-and-boundary-group-import-and-export/ https://home.configmgrftw.com/boundary-and-boundary-group-import-and-export/#respond Tue, 17 Dec 2019 22:03:17 +0000 https://home.configmgrftw.com/?p=6956 Five simple PowerShell one-liners to export and import boundaries and boundary groups from and to a Configuration Manager site.

The post Boundary and Boundary Group Import and Export appeared first on ConfigMgrFTW!.

]]>
Sadly, Microsoft Enterprise Manager Configuration Manager (ConfigMgr) has no built-in methods to export or import boundaries and boundary groups. This shortcoming is reasonably easy to address with PowerShell though, so I did a quick search on the web and found a bunch of examples for boundaries but none for boundary groups (I didn’t look that much though). What I found though were longer, custom scripts that only provided export capabilities. Not liking these and thinking I could do better, I set out to create my own set of PowerShell one-liners for these tasks.

Boundaries

Import and export for boundaries are super simple using the built-in ConfigMgr cmdlets. Run these one-liners on any system with the console installed on it if you load the ConfigMgr PowerShell module first and switch to the provider for your site. If you don’t know how to do this manually, launch PowerShell directly from the ConfigMgr console using the Connect via Windows PowerShell main menu option.

Export

The following one-liner exports the name/description, the value, and the boundary type for all boundaries using the Get-CMBoundary cmdlet and saves it to a CSV at the specified location.

Get-CMBoundary | Select-Object -Property DisplayName,Value,BoundaryType | Export-CSV -Path <path>\<file>.csv -NoTypeInformation

Import

Import is as easy as export using the following one-liner and the same CSV that the above export one-liner creates. This one-liner loops through the items in the CSV and calls New-CMBoundary for each. Easy peasy.

Import-CSV -Path <path>\<file>.csv | ForEach-Object { New-CMBoundary -Name $_.DisplayName -Type $_.BoundaryType -Value $_.Value }
Keep in mind that there is no graceful error handling here, so if the boundary already exists, you’ll get a standard, all in red, PowerShell error.

Boundary Groups

Boundary groups are a little more involved because the built-in cmdlets don’t list the site system associated with the boundary group and use a separate cmdlet to add boundaries to a boundary group. As with the boundary import and export one-liners above, run these one-liners on any system with the console installed on it if you load the ConfigMgr PowerShell module first and switch to the provider for your site.

Export

This long one-liner extracts the name, site assignment site code, member boundary names, and names of associated site systems and then saves all of that to a CSV at the specified location.

Get-CMBoundaryGroup | Select-Object -Property Name,DefaultSiteCode,@{Name = 'Boundaries'; Expression = { (Get-CMBoundary -BoundaryGroupName $_.Name).DisplayName -join ';'}}, @{Name='SiteSystems'; Expression = { ( (Get-WmiObject -ComputerName <SMSProvider> -Namespace root\sms\site_<sitecode> -Class SMS_BoundaryGroupSiteSystems -Filter "GroupID='$($_.GroupID)'").ServerNALPath | ForEach-Object { ($_ -split '\\\\')[2].trim('\\') }) -join ';' }} | Export-CSV -Path <path>\<file>.csv -NoTypeInformation

So, what does this crazy looking one-liner do? Let’s break it down.

  • Get-CMBoundaryGroup
    Gets all of the boundary groups.
  • Select-Object
    Extracts certain properties including two calculated properties.
  • @{Name = 'Boundaries'; Expression = { (Get-CMBoundary -BoundaryGroupName $_.Name).DisplayName -join ';'}}

    The first calculated property gets the boundaries associated with the current boundary group, extracts their display names, and then joins them into a single string with a semi-colon separator.
  • @{Name='SiteSystems'; Expression = { ( (Get-WmiObject -ComputerName <SMSProvider> -Namespace root\sms\site_<sitecode> -Class SMS_BoundaryGroupSiteSystems -Filter "GroupID='$($_.GroupID)'").ServerNALPath | ForEach-Object { ($_ -split '\\\\')[2].trim('\\') }) -join ';' }}

    The second calculated property uses WMI to get the site systems associated with the boundary group (from the SMS_BoundaryGroupSiteSystems class). The ServerNALPath attribute stores the site systems; this attribute is processed using a split and trim to get the actual server name and then joined into a single string with a semi-colon separator.
Make sure to replace [sitecode] with your site’s three character site code and [SMSProvider] with the name of the site system hosting your SMS Provider (which is usually the primary site server, but not always).

Import

Import is a two-step process that first imports the boundary group and then adds the boundaries to that boundary group. You can do these two steps using a single, complex, and long one-liner, but I decided to break it up into two smaller one-liners.

This first one-liner loops through the specified CSV file and creates the boundary groups using the New-CMBoundaryGroup and Set-CMBoundaryGroup cmdlets.

Import-CSV -Path <path>\<file>.csv | ForEach-Object { New-CMBoundaryGroup -Name $_.Name; if($_.DefaultSiteCode) { Set-CMBoundaryGroup -Name $_.Name -DefaultSiteCode $_.DefaultSiteCode }; if($_.SiteSystems) { Set-CMBoundaryGroup -Name $_.Name -AddSiteSystemServerName ($_.SiteSystems -split ';')} }

This one-liner is fairly straight-forward but does contain a couple of embedded if statements that conditionally call the Set-CMBoundaryGroup cmdlet because the New-CMBoundaryGroup cmdlet doesn’t handle blank values.

Keep in mind that there is no graceful error handling here either so if the boundary group already exists, you’ll get a standard, all in red, PowerShell error.

This second one-liner once again loops through the specified CSV file and adds the boundaries to the boundary groups using the Add-BoundaryToBoundaryGroup cmdlet.

Import-CSV -Path <path>\<file>.csv | ForEach-Object { foreach($boundary in ($_.Boundaries -split ';')) { Add-CMBoundaryToGroup -BoundaryGroupName $_.Name -BoundaryName $boundary } }

The only complexity with this one-liner is that the Add-BoundaryToBoundaryGroup cmdlet only takes a single boundary at a time and so must be called for each boundary in the data file.

Summary

There you have five easy one-lines for complete boundary and boundary group import and export for backup and restore, migration, simple kicks, or whatever your purpose. Yes, these could all be made into scripts of their own or combined into one larger, master script, but part of the beauty of PowerShell is that you don’t have to, but you can if you want to.

The post Boundary and Boundary Group Import and Export appeared first on ConfigMgrFTW!.

]]>
https://home.configmgrftw.com/boundary-and-boundary-group-import-and-export/feed/ 0 6956
Building a Windows 7 Image (Revisited) https://home.configmgrftw.com/building-a-windows-7-image-revisited/ https://home.configmgrftw.com/building-a-windows-7-image-revisited/#comments Mon, 25 Nov 2019 04:44:45 +0000 https://home.configmgrftw.com/?p=6944 This is a follow-up to a previous post: Building a Windows 7 Image. Why you may ask? Well, mainly for testing. If you are moving off of Windows 7 to Windows 10 finally, rapidly building Windows 7 is important for testing. Or, maybe you’re just unlucky enough to still have to deploy Windows 7. Either way, here are the updated items to slipstream into the base Windows 7 Service Pack 1 WIM image to have…

The post Building a Windows 7 Image (Revisited) appeared first on ConfigMgrFTW!.

]]>
This is a follow-up to a previous post: Building a Windows 7 Image.

Why you may ask? Well, mainly for testing. If you are moving off of Windows 7 to Windows 10 finally, rapidly building Windows 7 is important for testing. Or, maybe you’re just unlucky enough to still have to deploy Windows 7. Either way, here are the updated items to slipstream into the base Windows 7 Service Pack 1 WIM image to have a nearly fully up to date image ready for deployment using your favorite WIM deployment tool.

What You’ll Need

I don’t know of any other applicable, one-off updates as these have all been incorporated into the monthly rollups to my knowledge. Unfortunately, the .NET Framework 4.7.1 and Windows Management Framework 5.1 cannot be directly injected so these must come after the image is deployed if necessary.

What’s Next

  1. Prepare a working folder on a system running with the ADK installed and where DISM is available.
  2. Download all of the updates listed above and place them into the working folder All of the files except the Internet Explorer 11 download are MSU files. I highly suggest placing the updates in sub-folders named for the update’s title for organizational purposes. What you call these folders and if you actually create them is up to you though.
  3. Mount the Windows 7 Service Pack 1 media and copy the image.wim file from the sources sub-directory to the working folder. image.wim is the largest file and easy to find if you sort by size. Alternatively, use a tool like 7-zip to simply extract this file.
  4. (Optional) Rename image.wim to something meaningful like Win7-SP1-Ent-x64-media-Nov2019.wim. Note that nov2019 in the file name reflects when we are updating the image so that you can distinguish it from past builds and know when you created it.
  5. (Optional) Create a subfolder of the working folder called Images. Move the .wim file to the Image sub-folder.
  6. Using the command line, extract the Internet Explorer 11 files to the working folder or a sub-folder of the working folder: IE11-Windows6.1-x64-en-us.exe /x:<path_to_working_folder>/<subfolder>
  7. Create batch file with the below code in the working folder; call it Win7Image-Update.bat.
  8. Run the batch file from the command line or PowerShell:

    Win7Image-Update.bat <path_to_WIM_file><path_to_empty_folder> [WhatIf].

    Specify the location to the base image and an empty folder to mount the WIM to (note that the batch file does not check to see if this folder is empty but DISM will). You can also specify WhatIf as the third parameter to see what the batch file will do.

    Example: Win7Image-Update.bat .\Images\Win7-SP1-Ent-x64-media-Nov2019.wim F:\Mount

    Make sure to enclose paths with spaces in double-quotes.
@ECHO OFF
SETLOCAL EnableDelayedExpansion

IF [%1]==[] GOTO USAGE
IF [%2]==[] GOTO USAGE

IF EXIST %1 (
    GOTO PROCESS
) ELSE (
    GOTO FILENOTFOUND
)

:PROCESS
IF NOT [%3]==[WhatIf] ( 
    ECHO Processing ...
    SET WHATIF=0
) ELSE (
    ECHO Processing in WhatIf mode ...
    SET WHATIF=1
)

SET IMAGEPATH=%~1
SET MOUNTPATH=%~2
IF %MOUNTPATH:~-1%==\ SET MOUNTPATH=%MOUNTPATH:~0,-1%

SET IE11PREREQS=2533623 2639308 2670838 2729094 2731771 2786081 2834140 2882822 2888049
SET IE11=IE-Win7 IE-Hyphenation-en IE-Spelling-en
SET WINDOWS7=4474419 3020369 3125574 4490628 4523206 4525235
SET IECU=4525106
SET DOTNET=4019990 4507004

SET UPDATES=IE11PREREQS IE11 WINDOWS7 IECU DOTNET

SET ALLFOUND=1

FOR %%H in (%UPDATES%) DO (
    SET UPDATELIST=!%%H!
    CALL :CHECKUPDATES
)

IF [%ALLFOUND%]==[0] GOTO UPDATESNOTFOUND

ECHO All update were found. Beginning installation.
ECHO.
pause

ECHO Mounting WIM image at '%~1'
ECHO -------------------------------------------------------------------------------
IF [%WHATIF%]==[1] ( 
    ECHO dism /mount-wim  /index:1 /wimfile:"%IMAGEPATH%" /mountdir:"%MOUNTPATH%"
 ) ELSE (
    dism /mount-wim  /index:1 /wimfile:"%IMAGEPATH%" /mountdir:"%MOUNTPATH%" 
 )
ECHO.

FOR %%H in (%UPDATES%) DO (
    SET UPDATELIST=!%%H!
    CALL :INSTALLUPDATES
)

ECHO Unmounting WIM image at '%MOUNTPATH%'
ECHO -------------------------------------------------------------------------------
IF [%WHATIF%]==[1] ( 
    ECHO dism /unmount-wim /mountdir:"%MOUNTPATH%" /commit
) ELSE (
   dism /unmount-wim /mountdir:"%MOUNTPATH%" /commit 
)
ECHO.

GOTO END

:CHECKUPDATES
FOR %%a in (!UPDATELIST!) DO (
   ECHO %%a
   SET FOUND=
   FOR /R .\ %%G IN (*%%a*.msu,*%%a*.cab) DO (
      SET FOUND=%%G
   )
   IF [!FOUND!]==[] (
       ECHO Not found: %%a
       SET ALLFOUND=0
   )
)
GOTO :EOF

:INSTALLUPDATES
ECHO -------------------------------------------------------------------------------
FOR %%a in (%UPDATELIST%) DO (
   ECHO %%a
   SET FOUND=
   FOR /R .\ %%G IN (*%%a*.msu,*%%a*.cab) DO (
      IF [%WHATIF%]==[1] ( 
          ECHO dism /image:"%MOUNTPATH%" /add-package /packagepath:"%%G"
      ) ELSE (
         dism /image:"%MOUNTPATH%" /add-package /packagepath:"%%G" 
      )
      SET FOUND=%%G
   )
   IF [!FOUND!]==[] ECHO Not found: %%a
)
ECHO.
GOTO :EOF

:USAGE
ECHO Usage:  %~nx0 ImageFilename MountDirectory [WhatIf]
EXIT 1

:FILENOTFOUND
ECHO The file '%~1' was not found.
EXIT 2

:UPDATESNOTFOUND
ECHO.
ECHO Some updates were not found. Exiting.
ECHO.
EXIT 2

:END

What the Batch File Does

  1. Defines the updates in five variables. The values in the five variables are search strings used to search all subfolders for the updates. The search strings are mostly KB article numbers as these are contained in all of the filenames except for the main Internet Explorer filenames. Note also that all of the updates except the main Internet Explorer installation file are MSU files; the main Internet Explorer installation file is a CAB file.
  2. Finds and checks for the existence of all of the necessary updates using the values defined in the five variables regardless of which sub-folder the updates are in.
  3. Mounts the image.
  4. Installs the updates in the order defined in the five variables. Keep in mind that the order of the updates is very important; it took me a few hours of trial and error to find the correct order.
  5. Unmounts the image.

Now What

Well, that’s up to you. You can pick up in step 3 of the previous Building a Windows 7 Image article or deploy the WIM with whatever tool you’d prefer.

Summary

Is this all overkill for Windows 7? Yes. But if you’re testing your upgrade or migration to Windows 10, re-building systems with Windows 7 rapidly is important.

Is using a batch file for this kind of crazy? Kind of. It works well though. Feel free to re-write it in PowerShell if you prefer. I thought about it a few times as I was writing it but ended just sticking with the batch file. There are a few things that would certainly have been easier and more succinct in PowerShell, but it works quite well as a batch also.

Kind of like Monty Python and the Holy Grail, Windows 7 ain’t dead yet.

The post Building a Windows 7 Image (Revisited) appeared first on ConfigMgrFTW!.

]]>
https://home.configmgrftw.com/building-a-windows-7-image-revisited/feed/ 1 6944
Four Types of Wake-on-Lan https://home.configmgrftw.com/four-types-of-wake-on-lan/ https://home.configmgrftw.com/four-types-of-wake-on-lan/#respond Fri, 25 Oct 2019 03:33:20 +0000 https://home.configmgrftw.com/?p=6914 There are four types of Wake on Lan (WoL) currently in System Center Configuration Manager (ConfigMgr/SCCM). Each operates differently and must be accounted for at the network level for them to work.

The post Four Types of Wake-on-Lan appeared first on ConfigMgrFTW!.

]]>
There are four types of Wake on Lan (WoL) currently in System Center Configuration Manager (ConfigMgr/SCCM). Each operates differently and must be accounted for at the network level for them to work.

The Magic Packet

I won’t go into much detail on WoL in general other than to define what a magic packet is. If you need or want to know more about WoL in general, then the Wake-on-LAN Wikipedia article in a great place to start.

As the name implies, the magic packet is where the magic happens. In all WoL cases, the magic packet is a specially crafted frame at the data link layer containing the MAC address of the targeted system. The network delivers this frame to the targeted system, which, if configured to do so, wakes up and resumes operation.

The first two types of wake-up in ConfigMgr send magic packets based on required deployment deadline times to the systems in the collection targeted by the deployment. You set the option to send a WoL magic packet on the deployment. As noted, this is only applicable to required deployments. There is no built-in ad-hoc method to initiate these methods.

1. Subnet-Directed Broadcast

This is the first type of WoL in ConfigMgr and is the traditional WoL method. With this method, the primary site server sends a subnet-directed broadcast to the IP subnet where the targeted system was last known to be online. It’s important to know that in this case, it’s up to the network to deliver the magic packet to the subnet; ConfigMgr just initiates the process. Thus, the network must be configured to allow subnet-directed broadcasts. If it’s not, then there is not a thing that ConfigMgr can do about it.

Subnet-direct broadcast-based WoL is by far the simplest and most effective method in well-connected networks that allow subnet-directed broadcasts. Other network traffic has the potential to use subnet-directed broadcasts, including malicious distributed denial of service attacks (DDOS), however. For this reason, many networks have disabled subnet-directed broadcasts altogether.

2. Unicast

This is the second standard-type of WoL built into ConfigMgr. With unicast WoL, the ConfigMgr primary site server sends the magic packet directly to the targeted client using that client’s IP Address. The main limitation with unicast-based WoL is that for the network to deliver the magic packet (or any packet for that matter) to a targeted system, the network must know the targeted system’s MAC address. The router closest to the target system typically caches the MAC address in that router’s Address Resolution Protocol (ARP) cache. The ARP cache has a limited lifetime, though (15 minutes by default generally). Thus, if the site server sends a magic packet using unicast to a targeted system that has not been on the network in more than the timeout, the network does not know how to deliver the magic packet to the intended target system and drops it.

A ConfigMgr site cannot use both unicast and subnet-directed broadcast WoL simultaneously; you must configure the site to use one or the other.

3. Wake-up Proxy

A somewhat recent addition to ConfigMgr is wake-up proxy. This WoL type uses peers to proxy unicast WoL magic packets sent from the primary site server. There is no direct way to invoke wake-up proxy; it supplements the unicast WoL method (there’s no reason to use wake-up proxy if subnet directed broadcasts work in the environment).

Peer systems, called managers, assume the MAC address of other systems on the same subnet that go to sleep, hibernate, or power-down. Because the MAC address is still alive and available on the subnet, the network can deliver the magic packet to the manager that assumed the MAC address. This side-steps the significant restriction with ARP cache timeouts, as noted for standard unicast WoL above. Managers then send a magic packet on the local subnet where the sleeping system can pick it up and subsequently wake up.

There are two notable problems with wake-up proxy, both are network-related (it’s always the network):

  • Network switch ports that your endpoints connect to do not allow multiple MAC addresses.
  • Network switches restrict or do not allow rapid or frequent MAC addresses movement from one network switch port to another. This is often called MAC-flapping. 

In both cases, the network shuts down the port on the network switch. This, in turn, causes other peers on the network to assume the MAC addresses of systems on the switch ports that are shut down and a downward spiral of the network slowly shutting down ensues.

If you want to enable wake-up proxy, talk to your networking folks first.

Note that wake-up proxy isn’t specific to ConfigMgr or ConfigMgr initiated WoL magic packets. Managers send magic packets if they receive any traffic for the sleeping system that the sleeping system may have been listening for.

4. Client Notification

The final and newest WoL method in ConfigMgr uses client notification. If you are unfamiliar with client notification, then it’s past time to learn about it. See Fast Channel for System Management for detailed information. Unlike the first three methods, this method is unrelated to deployments, and you can only initiate it ad-hoc.

Similar to wake-up proxy, this method uses a peer on the local subnet of the targeted system. When you initiate wake-up using client notification, ConfigMgr chooses an online peer in the targeted system’s current subnet1 Clients send IP address information to ConfigMgr using heartbeat discovery, which is sent every seven days by default. I generally recommend changing this to at least daily in most environments. . The site then sends a request to that peer using client notification, and the peer, in turn, broadcasts a WoL magic packet to the local subnet where the sleeping system can pick it up and subsequently wake up.

Client notification elegantly side-steps all of the problems with the other three wake-up types. Unfortunately, as noted, it is only available as an ad-hoc action currently (as of 1906).

Summary

WoL in ConfigMgr isn’t perfect but it can work well with proper planning and coordination with your network team. Also, keep in mind that you must enable WoL in the firmware of managed systems as ConfigMgr cannot do this for you since it is a hardware-specific configuration. ConfigMgr will, however, automatically enable WoL in the NIC driver.

For more details on WoL in ConfigMgr, see the following official documents:

Footnotes   [ + ]

1. Clients send IP address information to ConfigMgr using heartbeat discovery, which is sent every seven days by default. I generally recommend changing this to at least daily in most environments.

The post Four Types of Wake-on-Lan appeared first on ConfigMgrFTW!.

]]>
https://home.configmgrftw.com/four-types-of-wake-on-lan/feed/ 0 6914
Command Synchronicity https://home.configmgrftw.com/command-synchronicity/ https://home.configmgrftw.com/command-synchronicity/#comments Sat, 17 Aug 2019 19:59:48 +0000 https://home.configmgrftw.com/?p=6875 Although Synchronicity is one one of the best songs ever from one of the best bands ever, this post isn’t about Gordon Sumner, Stewart Copeland or Andy Summers. This post is about two myths that folks insist on perpetuating and need stamping out: synchronous and asynchronous command execution in Windows. These come up in System Center Configuration Manager (ConfigMgr/SCCM) for two main reasons: Application-based Deployment Type Detection Methods and simple batch file usage. The “Problem”…

The post Command Synchronicity appeared first on ConfigMgrFTW!.

]]>
Although Synchronicity is one one of the best songs ever from one of the best bands ever, this post isn’t about Gordon Sumner, Stewart Copeland or Andy Summers. This post is about two myths that folks insist on perpetuating and need stamping out: synchronous and asynchronous command execution in Windows. These come up in System Center Configuration Manager (ConfigMgr/SCCM) for two main reasons: Application-based Deployment Type Detection Methods and simple batch file usage.

The “Problem”

Detection methods enable ConfigMgr to validate application installation at various times including at deployment. The ConfigMgr client agent evaluates the defined detection methods as soon as the given installation (or uninstallation) command-line is finished executing. The problem comes in when the process launched by this command-line doesn’t perform the actual installation but instead spawns a child process and exits without waiting for the child process to finish and leaves this new child process to perform the installation. The client agent has no knowledge of the child process or that it was spawned. All that the client agent knows is that the initially launched process has exited. Based on this, the client agent evaluates the detection methods which evaluate to false because the spawned process is still working on the installation. The client agent then sets the Application installation status to failed with the well-known error code of 0x87D00324.

Rerunning the deployment soon after the deployment will most likely result in a successful detection because, by the time you are able to rerun it, the spawned process has finished its work.

The First Myth and Wrong Answer

When this occurs, folks go searching the web (right answer) but end up finding posts that use the start command with a /wait parameter (wrong answer). The help text for the wait option of the start command sounds like it’s the solution though: “Start application and wait for it to terminate.” The problem here is that the wait option suffers from the exact same short-coming described above for the ConfigMgr client agent: it has no knowledge of a spawned child process or even that a child process was spawned. Thus, just like the ConfigMgr client agent, the start command with the wait option cannot wait on something it knows nothing about.

The Second Myth

Similar to the first myth, many folks creating batch files for use with ConfigMgr use start /wait for every one of the commands within the batch file. While not specifically harmful, this is completely unnecessary because batch files already wait for one command to complete before executing the next listed command.

Note that process and command are generally used interchangeably in this post and while there are technical differences, for purposes of this post they are synonymous as commands (and command-lines) lead directly to processes in what is described.

Synchronous and asynchronous commands

So what does this all have to do with synchronicity or rather synchronous and asynchronous commands?

Synchronous

Batch files are synchronous command processors meaning that they process commands in order, one by one and wait for each command to exit before moving to the next command; aka, synchronously. This is all by design and thus using start /wait in batch files is redundant and adds zero value. Without help, batch files always execute commands synchronously.

The ConfigMgr client agent is also a synchronous command processor in that it launches a single command and waits for that command to exit. Additionally, Windows Installer processes .msi file synchronously because MSIs are just “fancy” scripts.

.exe-based installers are also just compiled scripts in many cases and thus are typically synchronous. This, however, is not always the case as .exe’s have no restriction on what they can or cannot do regardless of their purpose in life.

Asynchronous

Spawning a child process and then not waiting for its exit is asynchronous command-execution. This is not what batch files do however unless they use another command, like start (without the /wait option) to spawn a child process asynchronously.

As noted above, asynchronous command execution is possible and not all that uncommon with some .exe-based installers. Even some .msi-based installers spawn child processes asynchronously using custom actions.

If a command called in a batch file, .exe, or .msi, asynchronously launches another process, then asynchronous execution has occurred; this, however, is outside the control or visibility of the caller. Once again, this is exactly what happens with the ConfigMgr client agent when a called command asynchronously launches another child process to perform the actual installation work. There is no direct or built-in way to know about or control asynchronous command execution from called processes in batch files or in ConfigMgr. Start /wait adds zero value here as it’s in the same boat without control or visibility into spawned processes.

To visualize a typical call chain, the following diagram depicts the asynchronous launch of a child process from a called process. The caller, be it a batch file or the ConfigMgr agent, has no control or visibility of the launched child process.

Call Chain

The Proof

This is all easily shown with a simple, primary batch file and a couple of VBScript files (I chose VBScript because it was the easiest method in this case but I could have used many other tools as well).

The Scripts

The batch file (batch.bat)

@Echo "Batch start"

@cscript.exe //NoLogo "%~dp0vbs1.vbs"

@Echo "Batch middle"

@cscript.exe //NoLogo "%~dp0vbs2.vbs"

@Echo "Batch end"

VBScript #1 (vbs1.vbs)

MsgBox "VBScript 1"

VBScript #2 (vbs2.vbs)

MsgBox "VBScript 2 start"

Set shell = WScript.CreateObject("WScript.Shell")
shell.Run "%windir%\notepad.exe", 1, false

MsgBox "VBScript 2 end"

Script Description

  • The Batch file simply calls both VBScripts intermingled with some console output.
  • VBScript #1 displays a simple message box
  • VBScript #2 does the following:
    • Displays a simple message box.
    • Asynchronously executes Notepad.exe.
    • Displays another simple message box.

VBScript #2 uses the Run method of the WScript.Shell COM Object whose third parameter defines whether the script should wait on the return of the called process — synchronous execution — or whether it should continue on without waiting — asynchronous execution.

Script Execution

Below is a detailed description that you can easily reproduce for yourself using the above-provided scripts or you can watch the embedded video.

  1. Call batch.bat from the command-line.
  2. Batch start is shown in the command window (from batch.bat).
  3. vbs1.vbs is called by batch.vbs. batch.bat does not proceed until vbs1.vbs exits.
  4. VBScript 1 is shown in a dialog box. (from vbs1.vbs). vbs1.vbs does not proceed and neither does batch.bat.
  5. User clicks OK in the VBScript 1 message box, vbs1.vbs exits and control is returned to batch.bat.
  6. Batch middle is shown in the command window (from batch.bat).
  7. vbs2.vbs is called by batch.vbs. batch.bat does not proceed until vbs2.vbs exits.
  8. VBScript 2 start is shown in a dialog box (from vbs2.vbs). vbs2.vbs does not proceed and neither does batch.bat.
  9. User clicks OK in the VBScript 2 start message box.
  10. notepad.exe is launched asynchronously. Because the Run method launches notepad.exe asynchronously, vbs2.vbs proceeds without waiting for notepad.exe to exit. noteapd.exe can be closed at any time or completely left alone without any impact to the execution of vbs2.vbs or batch.bat. batch.bat has no knowledge of or control over notepad.exe.
  11. VBScript 2 end is shown in a dialog box (from vbs2.vbs). vbs2.vbs does not proceed and neither does batch.bat.
  12. User clicks OK in the VBScript 2 end message box, vbs2.vbs exits and control is returned to batch.bat.
  13. Batch end is shown in the command window (from batch.bat).
  14. batch.bat ends.
  15. notepad.exe may or may not be still running at this point. batch.bat had no knowledge of or control over notepad.exe.
Script Execution

This shows the synchronous command execution of a batch file and how a called, synchronous command, may, in turn, call an asynchronous command that is not visible to or controlled by the batch file and may or may not still be executing at the time the batch file ends.

Script Execution using start /wait

So what if we modify batch.bat to use start /wait to call our VBScripts?

@Echo "Batch start"

@start /wait cscript.exe //NoLogo "%~dp0vbs1.vbs"

@Echo "Batch middle"

@start /wait cscript.exe //NoLogo "%~dp0vbs2.vbs"

@Echo "Batch end"

Nothing changes because as noted previously, start /wait has no knowledge of or control over asynchronously spawned processes (notepad.exe in this case) that were spawned by called commands. Thus, the 15-step description above for batch.bat‘s execution is exactly the same with or without start /wait and is not a solution for the spawned process detection method problem. Below is a video showing what happens when we add start /cmd — it’s pretty boring though as it’s nearly the same as the above video (without the annotations). start /wait also launches new windows (these are clipped in the video) as well so you see these pop-up, but other than that, it’s exactly the same behavior.

Solutions

There are a couple of straight-forward solutions here, one is quite simple but isn’t very elegant. For simple applications though, this simple solution may be enough. The other is also fairly simple but requires a bit of investigation and testing which may not really be necessary if you are satisfied with the simple solution.

Simple

The simple solution is to insert the command-line into a batch file and then add a timeout after the command-line. Place the batch file in the source directory along with the source files and call the batch files instead of the command-line.

"%~dp0mycommand.exe" /option1:abc /option2:xyz /switch
timeout /T 120 /NOBREAK

Basically, this runs the command-line and then sits waiting for a pre-determined amount of time (120 seconds in this example). The presumption is that any asynchronously spawned processes will be finished by the time the timeout ends. In many cases, this simple solution works just fine without any overhead and only adds a small amount of time to the deployment process. Of course, we are making a big assumption that the time we wait is sufficient. There many things that could influence this so that even after this time, the asynchronously launched process may not actually be finished yet. Only testing will help you identify a suitable timeout here.

Not So Simple

This solution also involves a simple batch file but instead of waiting a predetermined amount of time, waits until a specific process ends. for this, the process to watch is the asynchronously launched process of course. You need to use a tool like Process Monitor to discover what the name of this process is though so that you can insert its name into the batch file.

"%~dp0mycommand.exe" /option1:abc /option2:xyz /switch

:WaitLoop
timeout /t 10
tasklist | find /i "AynchProcessName" &amp;&amp; goto :WaitLoop

Note that this code is more or less directly from Reddit user /u/AllWellThatBendsWell in the post titled Unity installer doesn’t wait to finish.

Clearly, this solution is much more elegant as it removes the uncertainty of a predetermined timeout value and instead waits for the exit the asynchronously spawned process. Tasklist is quite flexible and there are other ways to determine which process to wait on. Unfortunately, parent process IDs are not available in tasklist otherwise this task could become very dynamic using tasklist.

These are by no means the only possible solutions, just the two simplest solutions that I could come up with that also work. Using PowerShell, VBScript or your automation tool of choice, I’m sure that you could come up with equivalent versions, variations, or even better solutions. The key here is understanding the problem and pitfalls in the first place so that you can properly address it.

Conclusion

start /wait is more or less useless for system administration. I’m sure someone will come up with a good example of its usefulness somewhere, but waiting for asynchronously launched commands ain’t one them.

Batch files synchronously execute commands.

Finally, as usual, do not believe everything written on the Internet and do not blindly follow code examples on the Internet either. Learn what they do, get rid of commands, functions, subroutines, etc. that aren’t needed, and when in doubt … test it! Watch the video below for a related chuckle — one of my favorite commercials of all time. Au revoir.

The post Command Synchronicity appeared first on ConfigMgrFTW!.

]]>
https://home.configmgrftw.com/command-synchronicity/feed/ 2 6875
UI++ 2.11.1.2 and Startup Script 1.83 https://home.configmgrftw.com/ui-2-11-1-2-and-startup-script-1-83/ https://home.configmgrftw.com/ui-2-11-1-2-and-startup-script-1-83/#comments Wed, 24 Apr 2019 00:18:49 +0000 https://home.configmgrftw.com/?p=6858 Updated versions of both UI++ and the ConfigMgr Startup Script are now ready for download and use.

The post UI++ 2.11.1.2 and Startup Script 1.83 appeared first on ConfigMgrFTW!.

]]>
Updated versions of both UI++ and the ConfigMgr Startup Script are now ready for download and use.

The post UI++ 2.11.1.2 and Startup Script 1.83 appeared first on ConfigMgrFTW!.

]]>
https://home.configmgrftw.com/ui-2-11-1-2-and-startup-script-1-83/feed/ 2 6858
UI++ 2.11.1.1 Production Ready! https://home.configmgrftw.com/ui-2-11-1-1-product-ready/ https://home.configmgrftw.com/ui-2-11-1-1-product-ready/#comments Fri, 01 Mar 2019 02:55:12 +0000 https://home.configmgrftw.com/?p=6832 Just released: 2.11.1.1! Mainly bug fixes. Check it out here: UI++ Also remember that for support, suggestions, hints, samples, discussions, or whatever concerning UI++, please visit the forums.

The post UI++ 2.11.1.1 Production Ready! appeared first on ConfigMgrFTW!.

]]>
Just released: 2.11.1.1! Mainly bug fixes.

Check it out here: UI++

Also remember that for support, suggestions, hints, samples, discussions, or whatever concerning UI++, please visit the forums.

The post UI++ 2.11.1.1 Production Ready! appeared first on ConfigMgrFTW!.

]]>
https://home.configmgrftw.com/ui-2-11-1-1-product-ready/feed/ 2 6832
What Automatic Deployment Rules Actually Do https://home.configmgrftw.com/what-automatic-deployment-rules-actually-do/ https://home.configmgrftw.com/what-automatic-deployment-rules-actually-do/#respond Fri, 01 Feb 2019 20:15:11 +0000 https://home.configmgrftw.com/?p=6800 A common point of confusion for folks just starting with System Center Configuration Manager (ConfigMgr or SCCM) is exactly what Automatic Deployment Rules (ADRs) do. What ADRs Don’t Do The first thing to note about ADRs is they don’t directly deploy updates. Thus, if you are troubleshooting an update install issue on a single client, troubleshooting an ADR is meaningless and unrelated. Validating that an ADR evaluated successfully and that the update package is successfully…

The post What Automatic Deployment Rules Actually Do appeared first on ConfigMgrFTW!.

]]>
A common point of confusion for folks just starting with System Center Configuration Manager (ConfigMgr or SCCM) is exactly what Automatic Deployment Rules (ADRs) do.

What ADRs Don’t Do

The first thing to note about ADRs is they don’t directly deploy updates. Thus, if you are troubleshooting an update install issue on a single client, troubleshooting an ADR is meaningless and unrelated. Validating that an ADR evaluated successfully and that the update package is successfully distributed to all necessary distribution points is certainly something to validate when troubleshooting, but those are not client side issues. Clients know nothing about ADRs or their evaluation.

What ADRs Do

There are three things and only three things that an ADR does:

  • Create or update an update group.*
  • Create or update update deployments on that update group.*
  • Download and add updates to the update package referenced in the ADR.

* Create if you choose for the ADR to create a new update group one each time it is evaluated; update existing if you choose to reuse the same update group.

In the case of reusing update groups, there is a link between an ADR and the update group it creates, however, this link is not persistent. Simply updating an ADR doesn’t change or update the linked update group, its update deployments, or the reference update package. That only happens at the time that an ADR is evaluated and then only if the criteria specified in the ADR results in a change to the update group.

Update Packages

Update packages are called deployment packages in the console but I refuse to call them that as they have nothing to do with deployments.

ADR Troubleshooting

When it comes to ADR troubleshooting, there is one log to rule them all: ruleengine.log. Ruleengine.log is on the site server of course because clients don’t know anything about ADRs.

This log has everything in it including details about update downloads. As usual, if you are looking for issues in this log, read the log, don’t just look for yellow or red lines. Also, if a line is red or yellow, read the line again as some of the completely normal, non-failure messages in this log have the trigger keywords within them; e.g., error.

ADR Tips

  • Space your ADR evaluations out so that they don’t run at the same time or on top of each other. This will spread out the load and eliminate the possibility of database and download contention issues which do occasionally occur.
  • Set the available offset time for all deployments to at least one or two hours (or more depending on your infrastructure). This gives the newly downloaded content a chance to get to your distribution points before clients start requesting it.
  • Use multiple deployments. If you have multiple ADRs that have the exact same update criteria specified that are intended to go to different collections (for a phased deployment), collapse these ADRs and use multiple deployments instead.
  • Don’t use the Required attribute unless you absolutely have to in order to control network bandwidth usage. The Required attribute is a lagging, reactive indicator. If a product is in-scope to be updated by ConfigMgr, be proactive and deploy all possible applicable updates for those products.
  • Use the Custom Severity attribute to filter out unwanted updates. Manually set unwanted updates to Low Custom Severity and then include only the other custom severities (None, Moderate, Important, Critical) in the update criteria.
  • Decline unwanted updates directly in WSUS manually or using a script. This has the added benefit of pruning the WSUS update catalog used by clients and ConfigMgr which in turn has many benefits including expiring the updates in ConfigMgr. Common updates to decline this way include the following:
    • Itanium
    • Beta
    • Version Next
    • Windows 10 versions not in the environment or unsupported
    • SharePoint

The post What Automatic Deployment Rules Actually Do appeared first on ConfigMgrFTW!.

]]>
https://home.configmgrftw.com/what-automatic-deployment-rules-actually-do/feed/ 0 6800
Software Updates and Automatic Deployment Rules in ConfigMgr https://home.configmgrftw.com/software-updates-and-automatic-deployment-rules-in-configmgr/ https://home.configmgrftw.com/software-updates-and-automatic-deployment-rules-in-configmgr/#comments Wed, 30 Jan 2019 01:57:45 +0000 https://home.configmgrftw.com/?p=6774 Configuring Automatic Update Rules (ADRs) in System Center Configuration Manager (ConfigMgr or SCCM) comes up often in the forums and at customers as there is no one, clear-cut way to configure them. Here’s a run-down of what I normally recommend and configure: How Many ADRs Use one ADR per product category or product; e.g., Workstation OS updates, Server OS updates, Office updates, and Other updates OR Windows 7 Updates, Windows 10 Updates, Windows Server 2012 Updates, etc. If…

The post Software Updates and Automatic Deployment Rules in ConfigMgr appeared first on ConfigMgrFTW!.

]]>
Configuring Automatic Update Rules (ADRs) in System Center Configuration Manager (ConfigMgr or SCCM) comes up often in the forums and at customers as there is no one, clear-cut way to configure them. Here’s a run-down of what I normally recommend and configure:

How Many ADRs

  • Use one ADR per product category or product; e.g., Workstation OS updates, Server OS updates, Office updates, and Other updates OR Windows 7 Updates, Windows 10 Updates, Windows Server 2012 Updates, etc.
  • If you are still managing Windows Server 2008 or 2008 R2, then a generic product category won’t work for these as there are way too many updates for a single update group to contain1Update groups, for performance reasons, can only contain 1,000 updates; this is enforced by the console but not necessarily the SDK.. In this case, you’ll have to use an ADR for each product, multiple even depending on the classifications that you include.
  • The following screenshot shows how simple it truly can be.
Example ADR List Using Product Categories

How Often Should ADRs be Evaluated

  • Monthly for most ADRs. The only class of updates that are issued more frequently, in general, is Endpoint Protection and Windows Defender definition updates; these should be evaluated at least once a day.
  • Any more frequently than monthly will quickly become a burden to test, a burden on your end-users, and a burden to maintain.
  • This, of course, does not include one-off zero-day or other high-priority updates.

When Should ADRs be Evaluted

  • For non-definition ADRs, anytime after 1000 US Pacific Time (UTC -7/8) on the second Tuesday of the month which is when Microsoft schedules the main, monthly publishing of the WSUS catalog.
  • For definition ADRs, I recommend 0600 and 1800 every day.
  • I strongly recommend that you wait at least 12 hours after 1000 US Pacific Time though to account for delays or other issues that are not uncommon with the publishing of the catalog. As of ConfigMgr 1802, setting an offset from the second Tuesday is possible as shown in the following screenshot2Always keep in mind that at least twice a year, the second Wednesday occurs before the second Tuesday during a month.. This is useful for the delay as described or for those folks in the eastern hemisphere where 1000 US Pacific Time is the next day already (or both).
Custom ADR Evaluation Schedule for 1200 US Central Time (UTC -5/6) on the Day After Patch Tuesday

How Many Software Update Groups

  • Use one software update group per ADR.
  • Reuse update groups each month.

What Criteria Should Each ADR Use

  • Each ADR should filter on a set of products within a category or a single product.
  • Each ADR can also filter on classification and language as appropriate3Note though that Windows 10 and Server 2016/2019 Cumulative Updates (CUs) aren’t always of one classification. To deploy all CUs for these products, you need to include the Updates, Security Updates, and Critical Updates classification..
  • Each ADR should exclude superseded updates.
  • ADRs should not filter on the Required attribute or any dates. Resulting software update groups should contain all updates for a product category or product. Anything less is reactive instead of proactive and security needs to be proactive. Using these attributes also leaves the door open for a new system to enter the environment needing an update no longer deployed or for an update to be removed on an existing system. In both cases, systems will be unpatched with no immediate action enforced to apply the update.
    • With products updated using CUs, this is largely moot as there won’t ever be any more than a single non-superseded update anyway.
    • For products with traditional update models, this does mean more disk space usage. That’s an easy trade-off though as security should easily override any disk space concerns or costs.
  • The following screenshot shows how simple the criteria should be.
The Criteria for the All Workstation Updates Product Category Based ADR

How Many Update Packages

  • Use a single update package4These are called Deployment Packages in the console but I refuse to call them that because they have nothing to do with deployments. for each ADR. This creates some separation and organization to the update binaries. Which package an update is in isn’t explicitly important because the clients don’t really care — clients can download an applicable update from any package available to them as there is no connection to the update group or deployment used to assign the update to a client.
  • Having some separation is beneficial though for content distribution purposes or if you encounter package integrity issues. It also allows you to selectively distribute update packages to different DPs depending on the clients using that DP; e.g., not distributing server updates to DPs not servicing any server OS client systems.

How Many Deployments Per ADR

  • Use multiple deployments on each ADR to create deployment phases as needed5Many folks missed and/or still don’t know that as of 1602, multiple deployments can be configured on each ADR. This enables an ADR to create and update multiple, separate deployments on the software update group linked to it..
    • Each deployment should target a collection representing a separate phase
    • Enable the deployments for test or pilot phases.
    • Disable the deployments for production phases. This creates an explicit “gate” requiring an administrator to flip the deployment to enabled each month after they perform a quality check of the update group, the deployments, and the status of the updates in the update group.
  • Alternatively, use a single deployment to target a “master” collection of systems where actual update deployment times are dictated by maintenance windows applied to collections containing a subset of the membership of the “master” collection.
    • This approach is typically best used with servers as guaranteeing that user systems are ever on during any defined maintenance window is difficult if not impossible.
    • The following screenshot shows a simple example of this. The red arrow indicates the master collection where the deployment is targeted. The green arrows indicate the sub-collections that are limited to the “master” collection and contain a subset of the members of the master collection; maintenance windows are applied to these sub-collections to control when update deployments are enforced by the clients in these collections.
Master and Sub-collections for Software Updates

What About Manual Clean-up

  • There’s none required.
  • ADRs will effectively auto-groom their connected update groups every time they run; i.e., they will remove expired and superseded updates automatically while adding new updates released since the last time that the ADR ran6In reality, update groups are completely cleared out each time the ADR runs and only updates that meet the ADRs update criteria and added. The end effect is thus as described: all superseded and expired updates are removed from the update groups automatically. 7If the evaluation of an ADR would result in no changes in the membership of an update group, then no action is actually taken..
  • Expired updates that are no longer deployed will also be removed from update packages and update package source locations automatically by the update catalog synchronization cycle after seven days8A bonus here as of ConfigMgr 1810 is that any updates that ConfigMgr flips to expired will be declined directly within WSUS thus effectively removing them from the WSUS catalog..

Two (Small) Drawbacks

Update Deployment Time Tracking

  • By reusing the same update groups every month, you lose the ability to explicitly track when an update was deployed. In most organizations, this is not an issue as the month an update was released is also when it was deployed.
  • Unfortunately, the built-in reports don’t filter on the date released so if you are are interested in this, then you’ll either have to write your own reports or better yet, use one of the awesome sets released by the community including those by Gary Simmons.
  • If your organization truly cares about the exact month or time when an update was deployed, there’s no way to explicitly track this in the current version of ConfigMgr (although I’ve been bugging the product team about this for a while now).
  • By not reusing update groups, i.e., creating new update groups every month, you do (kind of) get all of this because you will have update groups for each month. In reality, though, there’s no guarantee that updates weren’t added to or removed from these update groups after the fact, so I’d honestly say this is questionable at best until the product group adds definitive tracking.

No Deploy Period

  • Using a single set of ADRs and update groups for each product or product category as described above results in a period of time where no updates will be deployed at all. This is the period between when the ADRs run each month and when they become required. Depending on your update cycle, this could be as little as a few days (and thus not a big deal) or it can be as long as a few weeks. The longer that this no deploy period lasts, the shorter the actual deploy period lasts as well which will certainly impact overall compliance and is thus undesirable.
  • Why does this happen? When the ADR runs, it resets the available and deadline times on all deployments to something in the future and thus, nothing is currently deployed anymore (except to maybe your test collections).
  • If you have a large deployment cycle where this significant no deploy period will be impactful (anything more than a week would certainly be impactful IMO), then doubling the number of ADRs and software update groups will address this shortcoming without a lot of additional overhead or work.
    • Basically, you create two ADRs for each product or product category. Both sets are exactly as noted above except that each runs bi-monthly: specifically one runs in odd months, and one runs in even months thus leap-frogging over each other every month.
    • The ADRs for the same product or product group use the same update package thus nothing additional is required as far as disk space or network goes.
    • The n-1 ADR will contain compliance information of all previous updates and continue to deploy all previous updates.

Advantages

  • Simple and well organized.
  • Minimum clutter with the fewest possible update groups and ADRs.
  • Self-cleaning. No monthly, quarterly, or annual clean-up of any kind.
  • Comprehensive and proactive.

Disadvantages

  • You’ll need more disk space and there will possibly be some additional bandwidth requirements. This is an easy trade-off IMO though in the name of security.
  • No others that I know of.

Hints

  • Use a script to create your ADRs particularly if you go for the two ADR approach9My scripts for this (among other things) are located on GitHub — the Build-CMDefaultConfig.ps1 in the Build folder which in turn uses the CMDefaultConfig.json configuration file..
  • Always check the status of your ADRs and the distribution of the update packages as failures in either of these are the most common root causes of issues with software updates (besides WSUS being old and decrepit).
  • Use multiple methods as needed. There’s no rule that says you have to do it all one way.

Footnotes   [ + ]

1. Update groups, for performance reasons, can only contain 1,000 updates; this is enforced by the console but not necessarily the SDK.
2. Always keep in mind that at least twice a year, the second Wednesday occurs before the second Tuesday during a month.
3. Note though that Windows 10 and Server 2016/2019 Cumulative Updates (CUs) aren’t always of one classification. To deploy all CUs for these products, you need to include the Updates, Security Updates, and Critical Updates classification.
4. These are called Deployment Packages in the console but I refuse to call them that because they have nothing to do with deployments.
5. Many folks missed and/or still don’t know that as of 1602, multiple deployments can be configured on each ADR. This enables an ADR to create and update multiple, separate deployments on the software update group linked to it.
6. In reality, update groups are completely cleared out each time the ADR runs and only updates that meet the ADRs update criteria and added. The end effect is thus as described: all superseded and expired updates are removed from the update groups automatically.
7. If the evaluation of an ADR would result in no changes in the membership of an update group, then no action is actually taken.
8. A bonus here as of ConfigMgr 1810 is that any updates that ConfigMgr flips to expired will be declined directly within WSUS thus effectively removing them from the WSUS catalog.
9. My scripts for this (among other things) are located on GitHub — the Build-CMDefaultConfig.ps1 in the Build folder which in turn uses the CMDefaultConfig.json configuration file.

The post Software Updates and Automatic Deployment Rules in ConfigMgr appeared first on ConfigMgrFTW!.

]]>
https://home.configmgrftw.com/software-updates-and-automatic-deployment-rules-in-configmgr/feed/ 23 6774