Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the twentyseventeen domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /var/www/html/wp-includes/functions.php on line 6121
Run Script – SCCMOG – Deployment Blog

Windows 10 Configure User Experience Offline – MDT SCCM OSD -VBScript

So currently I am working on an Government Education site comprising of just under 40 schools. There was a requirement to remove/hide Microsoft’s Edge browser from the image being rolled out to the users. The reasoning behind this is down to a monitoring tool used by the education department that does not support Edge and therefor policies would be broken…

Anyway I hunted around on our favourite resource for a solution that would not break the image entirely by removing one of it core features.

Eventually I found these 4 registry keys that did the trick:

KEY: HKEY_LOCAL_MACHINE\NewOS\Microsoft\Windows\CurrentVersion\Explorer
Name: DisableEdgeDesktopShortcutCreation 
Value: 1
KEY: HKEY_LOCAL_MACHINE\NewOS\Policies\Microsoft\MicrosoftEdge\Main
Name: PreventFirstRunPage
Value: 1
KEY: HKEY_LOCAL_MACHINE\NewOS\Policies\Microsoft\MicrosoftEdge\Main
Name: AllowPrelaunch 
Value: 0
KEY: HKEY_LOCAL_MACHINE\NewOS\Policies\Microsoft\MicrosoftEdge\TabPreloader\AllowTabPreloading
Name: AllowTabPreloading 
Value: 0

Next was to figure out how to inject these into my reference image before  it was laid onto the VM for automated customisation. So I remembered a great script by Johan Arwidmark I use all the time for turning off Appx package updates during a reference image capture task  sequence (can break sysprep if allowed).

Anyway after a bit of modification to load the Software registry hive offline instead this is what I came up with. There is also some commented out portions here that may come in handy:

Github: Config-Win10-Offline-UE.wsf

MDT Setup

  • First download the script and save it into you deployment share “Scripts” folder:
J:\<YOUR_DEPLOYMENT_SHARE>\Scripts\Config-Win10-Offline-UE.wsf
  • Then Open up your chosen Task Sequence in MDT and just before the “Inject Drivers” step under the “Post Install Group” and a new “Run Commmand Line Step”.
  • Name it for example:  Configure User Experience
    Then use the following command line:
cscript.exe "%SCRIPTROOT%\Config-Win10-Offline-UE.wsf"

Example:

Configure-User-Environment-Offline-VBscript-Example
Configure-User-Environment-Offline-VBscript-Example

SCCM Setup

  • For SCCM you must be using the MDT integration (if you’re not… Start now!), you can make it work without it but I will not cover that here.
  • Find your current MDT Toolkit Package that is associated with the Task Sequence you would like to configure power settings in.
  • Open the “Source” location of your toolkit package, then open the scripts folder.

  • Once inside the scripts folder copy the “Config-Win10-Offline-UE.wsf” into it. Now, update the Package in ConfigMgr.
  • Next we need to add the step to the task sequence. It must go after a “Use Toolkit Package” step and before your Driver injection step in the task sequence. (If you have a reboot remember to add another use “Toolkit package”.)

Create a new “Run Command Line Step” and add the below command.

cscript.exe "%deployroot%\scripts\Config-Win10-Offline-UE.wsf"

And that is it. Your ConfigMgr or MDT Task sequence is now setup to configure the user environment before the machine boots!

Anyway as always, script is provided as is and if you do mod it, there is a line to add your name.

Bulk Discover Client Versions

So this morning I was checking up on the status of some client upgrades after installing the latest 1710 hotfix. WMI on each machine had updated to reflect the latest client versions, however most machines hadn’t reported back to ConfigMgr so they were still listed as the older version. Being impatient, I wrote a script that I could use with SCCMs ‘Run Script‘ feature (available as a pre-release feature from version 1706) that would scrape WMI on each machine locally and report back the client version… simple, but awesome!

The script is as follows:

#############################################################
#
#  Author: Jack O'Connor
#  Website: https://github.com/JackOconnor21
#  Modified By: Your name here...
#  Description: Simple script to use on a local machine or via SCCMs
#     'run script' feature to find the client version of a machine
#     in the event SCCM has not yet updated the machine records.
#  
#  Edit the $CurrClientVer variable to reflect the latest client version
#  which is what we will test against.
#
##############################################################

$CurrClientVer = "5.00.8577.1115"
$MyClientVer = (Get-WMIObject -Namespace root\ccm -Class SMS_Client).ClientVersion

If ($MyClientVer -eq $CurrClientVer) {
    Write-Host "Up to date" -ForegroundColor Green
} Else {
    Write-Host "Out of date ($MyClientVer)" -ForegroundColor Red
}

The idea is you add the new client version number into the $CurrClientVer and the script will check WMI on each machine and match the client version against that – if it matches then we get an “Up to date” output, but if it does not we get an “Out of date” output followed by the actual client version on that machine.

You can run this script on any collection you like, I chose to run it on my “System Health | Clients Active” collection, which gave me the feedback pictured below.

 

 

 

 

 

Copyright 2016 SCCMOG | All Rights Reserved