As we go full-speed ahead into the summer months, the ConfigMgr product team has released yet another technical preview version. Without a doubt, this release is chock-full of exciting features. There are brand new PowerShell cmdlets, and useful OS deployment features, new client settings, and infrastructure improvements. Perhaps the most exciting feature is the ability to toggle a primary site between active/passive when setup correctly.
PowerShell Wizardry
There are 925 cmdlets that made it into TP1706 which is 21 more than we saw in TP1705. Last month I explained the script you need to run to get a count of the ConfigMgr cmdlets in each build as well as compare the difference. You can read that post here. The following list are the new cmdlets for this build and are OS deployment heavy, with only a few outliers:
Get-CMTSStepInstallUpdate
Get-CMTSStepPartitionDisk
Get-CMTSStepRunPowerShellScript
Get-CMTSStepSetupWindowsAndConfigMgr
Remove-CMTSStepInstallUpdate
Remove-CMTSStepPartitionDisk
Remove-CMTSStepRunPowerShellScript
Remove-CMTSStepSetupWindowsAndConfigMgr
Get-CMCorpOwnedDevice
New-CMTSPartitionSetting
New-CMTSStepInstallUpdate
New-CMTSStepPartitionDisk
New-CMTSStepRunPowerShellScript
New-CMTSStepSetupWindowsAndConfigMgr
Remove-CMCorpOwnedDevice
Set-CMIosEnrollmentProfileAssignment
Set-CMTSStepInstallUpdate
Set-CMTSStepPartitionDisk
Set-CMTSStepRunPowerShellScript
Set-CMTSStepSetupWindowsAndConfigMgr
Set-CMWirelessProfileHide Task Sequence Progress
You’re probably thinking: “Hey, I could already decide whether or not the end user saw any task sequence progress”, and you’re right. But what if I told you that you can be even more granular and toggle progress on and off in many places throughout the sequence? This preview build gives us the new TSDisableProgressUI variable which can be set to true (hide progress) or false (show progress). This is especially useful to evil admins everywhere, but good admins can use it too. The variable is useful for hiding/showing important sequence progress. In this example, I have chosen to hide the progress of a pre-flight check:
Changes to Windows Update for Business Policies
Admins can now create and deploy Windows for Business (WUfB) Policies in a node where previous interaction would cause the console to crash. In Software Library / Windows 10 Servicing / Windows Update for Business Policies, select “Create a New Policy” by right clicking anywhere in the workspace and select “Create Windows Update for Business Policy”. There is also a button on the ribbon within the workspace for the same action. When the wizard opens, give the policy a unique name. In the Deferral Policies page, you can granularly control the delaying of both feature and quality updates by branch readiness, date range, or a specific date.
When the policy is created, there is a button on the ribbon for deploying it, or you can right click the policy and select “Deploy”. I have already created a device collection that holds all of the computers I would like to set the policy for, which I select in the Deploy Windows Update for Business Policy wizard. There is also a checkbox that when selected allows for remediation to happen outside of maintenance windows if that is allowed in your organization.
A final, yet interesting note is that you can also view the XML configuration for your policy after it is created by selecting the View XML Definition button on the ribbon:
Scripting Magic
The Twitter community is very excited about this feature and there is no lack of tweets about it. This feature allows an admin to run approved scripts against collections. The scripts can be imported or created and can only be run against Windows client PCs. There are several other things to keep in mind when creating and deploying the scripts and you can read about it in the Capabilities in Technical Preview 1706 for System Center Configuration Manager document for this release.
To test the feature, I created a device collection and added PCs that I wanted to run the script against. I decided to enable the Hyper-V role by PowerShell script since I didn’t want to manually enable it on each client. In Software Library / Scripts, right click anywhere in the workspace and click “Create Script”.
In the script language drop down, the only thing that is currently available is PowerShell. Again, you can either import a script or create one. I opted to create one.
Once the script is created, it needs to be approved which is done in the same workflow. Simply click the script and click the “Approve” button in the ribbon.
Within the approval wizard, you can either approve or deny (or revoke approval) of a script and add comments, which is great from a change management perspective.
Once the script is approved, navigate to Assets and Compliance / Device Collections and find your collection you created. Note: you can only run a script against a collection from the top view, meaning you can open a collection and run from there. When you find the collection, right click it and pick “Run Script”.
In the Run Script wizard, you will have the opportunity to deploy any approved script (and against any collection) – so proceed with caution.
The script runs in near real-time and can be monitored from Monitoring / Script Status. However, that workspace remained empty for me and I was never able to view status from there. I did find what I was looking for in Monitoring / Client Operations. Here, you can view scripts that have completed and expired or scripts that are in progress. After I deployed my script, I could see the result of the action in the graph.
The script is expired; I can safely assume that it will not retry for the devices that are offline. Since this is simply a tech preview feature, I’m satisfied with that for now.
Interesting Findings
There is support for moving a Distribution Point between sites with this release however it can’t be tested due to the hard limit of one Primary Site per tech preview installation. This will be an interesting feature to see in production as the current way of migrating a Distribution Point requires quite a bit of disk space.
The Primary Site has gone “HA” or High Availability meaning there is a failover option. This is useful in a disaster recovery scenario as well as other scenarios such as needing to failover to a server in Azure in your organization’s patch Tuesday window. Currently there is a hard requirement of remote SQL which has many MVPs and local SQL enthusiasts dismayed. There seems to be word coming from the Microsoft System Center Configuration Manager product team that this is only a temporary requirement.
This release has also brought improvements to boundary groups for software update points. Boundary groups are a large headache and the best practice is to simplify them, and use as few as possible in your environment. With that being said, there are improvements to how clients fallback to other software update points configured for their boundary group to minimize the time it takes before a client can find another.
For the full list of documented features, you can read the release notes on TechNet.
