I'm using SCCM with MDT integration, added a 'run command line' task to run this script. Initially it was failing saying 'expected Then at line [whatever]'. I threw in few Thens and it was happy, but now it fails saying.

D:_SMSTaskSequence\WDPackage\scripts\Config-DisableWindowsStoreUpdates.wsf(45, 4) WshShell.RegDelete: Invalid root in registry key "HKEY_LOCAL_MACHINE\NewOS\Microsoft\Windows\CurrentVersion\WindowsStore\WindowsUpdate\AutoDownload".

It fails here:

If oEnvironment.Item("_SMSTSInWinPE") = "true" Then
	oShell.RegDelete "HKEY_LOCAL_MACHINE\NewOS\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsStore\WindowsUpdate\AutoDownload"  

I cannot work this out. I get the same thing if I try and run the script on my standard Win10 box, even if I manually create the key.

Any ideas?

Microsoft has announced the deprecation of the Azure AD Graph service, ending support for the Azure AD, Azure AD Preview, and MS Online PowerShell modules. These functions should be migrated to the Microsoft Graph PowerShell SDK (Microsoft.Graph).

In addition, newer versions of the Graph SDK has changed some syntax. For example, a common use of the Graph SDK was to connect to the Graph SDK Beta endpoint by using "Select-MgProfile." This function no longer exists and the Microsoft Graph Beta PowerSehll SDK (Microsoft.Graph.Beta) has been created with new cmdlets containing "Beta" in the name. Lastly, old Intune-related modules like Intune-PowerShell-SDK are no longer maintained. Again, in favor of the Graph SDK/Graph Beta SDK modules.

With that in mind, we have several useful scripts that should be reviewed for updates. We need to determine whether they can point to the v1.0 endpoint or the Beta endpoint and thus, the Graph or Graph Beta SDK. Currently tracking the following scripts:

• - Get-AzureADAuditLogs-MgModule.ps1
• - Windows Autopilot Automation.ps1
• - Create-P2PTestWin32Applications.ps1
• - ForceSyncOnAllWindowsDevices-MgModule.ps1
• - Update-Win32AppAssignmentsForDO.ps1
• - WorkWithPowerShellScriptsInIntune.ps1
• - New-DriverAndFirmwarePolicyPerModel.ps1

Please add additional scripts in the comments below if I've missed them. Additionally, feel free to create a Pull Request if you already have updated versions of these scripts.

Additional Reading:
Important: Azure AD Graph Retirement and Powershell Module Deprecation

Just like 2005 and 2008 before it, VCRedist version 2010 was declared end of life (since June 2020, see link).
Please consider commenting out the relevant sections of the script.

https://github.com/DeploymentResearch/DRFiles/blob/master/Scripts/Export-WindowsServer2019WIMfromISO.ps1

Line 12 should be $WIMFolder instead of $WIMPath which is never defined.

Scenario 1 (works):
When using the Download Package Content task in a task sequence, if you reference a package directly through the task sequence using this task, OSDDownloadDownloadPackages variable gets set, and CM finds and downloads the correct version of the package.

Scenario 2 (does not work):
When using the Download Packaget Content task in the task sequence, and you set OSDDownloadDownloadPackages variable through a this script during the task sequence, OSDDownloadDownloadPackages is set correctly, however SCCM does not find the correct version of the package.

This is causing issues with 1E Nomad, as it is trying to download the package stored in OSDDownloadDownloadPackages, version 0. instead of the correct version of the package.

Native CM seems to be able to figure this out, but it is not working for alternate downloaders.

Hi Johan

RE: Install-MicrosoftVisualC++x86x64.wsf

Is there a way to make this compatible with both MDT and SCCM - Or maybe an easy way to switch between the two via commenting?

I had an issue while installing on Server 2016 using MDT: The x64 2013 rebooted immediately after installation, causing the TS not to continue since the reboot was not initiated by the TS.
To fix the issue, i added the following line;
Line 367: sArguments = "/quiet /norestart"

Looks like 2017 is missing from the script as per:
https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads

Does it make sense to add something like this to the Get-DriverPackages.ps1 script to handle Lenovo machines since they use a different naming convention for wmic csproduct get name?

If (((Get-CimInstance -ClassName win32_computersystemproduct -Namespace root\cimv2).Vendor) -eq "LENOVO")
        {
            
           $script:Model = (Get-CimInstance -ClassName win32_computersystemproduct -Namespace root\cimv2).Version
        }
        Else
        {

           $script:Model = (Get-CimInstance -ClassName win32_computersystemproduct -Namespace root\cimv2).Name 

        }

x86 installs seem to be working, but the x64 installs are being completely ignored. The only changes I have made is the 2017 file name changes, as suggested in #11

Replaced Visual C++2017 with Visual C++ 2019 as it is binary compatible with 2015 and 2017.
Included issue #19 fix from @baardhermansem to silently install 2013 and newer ones
Pull request #21

In the task sequence for DC01,does this script change the domain name in the Authorize DHCP step in the State Restore node?
Thanks agian for this.

#starting 192 row
oLogging.CreateEntry oUtility.ScriptName & ": About to install " & sSetupFile2013x86, LogTypeInfo
iRetVal = oUtility.RunWithHeartbeat("""" & sSetupFile2015x86 & """ " & sArguments)

Must be the same year, I think.

Hello gurus!

Just wanted to let you know that the script for installing VS needs a modification on below lines:

sSetupFile2017x86 = oUtility.ScriptDir & "\Source\VS2017\mu_visual_cpp_redistributable_for_visual_studio_2017_version_15.3_x86_11100229.exe" sSetupFile2017x64 = oUtility.ScriptDir & "\Source\VS2017\mu_visual_cpp_redistributable_for_visual_studio_2017_version_15.3_x64_11100230.exe"

They should become:
sSetupFile2017x86 = oUtility.ScriptDir & "\Source\VS2017\vc_redist.x86.exe" sSetupFile2017x64 = oUtility.ScriptDir & "\Source\VS2017\vc_redist.x64.exe"

Since that's their name now on the URL you specify in your script:
https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads

There is a typo in line 183 of the Install-MicrosoftVisualC++x86x64.wsf script that lists the 2013 file instead of the 2015:
oLogging.CreateEntry oUtility.ScriptName & ": About to install " & sSetupFile2013x86, LogTypeInfo

Should be:

oLogging.CreateEntry oUtility.ScriptName & ": About to install " & sSetupFile2015x86, LogTypeInfo

Using the Bunny's ImageFactory to build an 1803 image. I am calling Config-DisableWindowsStoreUpdates.wsf in the same manner as illustrated here
but registry changes do not stick. Indeed I can pause the TS in WinPE and make the changes manually. I can see the "c:\windows\system32\config\software" file's modified date is updated but if I mount the hive manually once again the registry values are not present from either the script or my manual changes. To be sure I also check again once in full Windows and they are not there.

Does anybody find that Config-DisableWindowsStoreUpdates.wsf is working with 1803?

Could you add a link to your Deployment Research Blog?