Microsoft look to be moving to a cumulative approach to updates with Windows 7 and 8.1 which seems to be similar to what they have already done for Windows 10.
Single Cumulative Updates instead of multiple individual patches moving forward. Better late than never I guess… 😉
See the full blog post on TechNet:
Just a heads up – after wasting the best part of a day trying to figure out what was wrong it turns out that Language Packs for Windows 10 are release specific and only seem to work with the corresponding release of Windows.
What this means is that Language Packs for Windows 10 1511 won’t install offline via MDT when creating a reference image using 1607 Windows 10 media.
1511 Language Packs only work with 1511 media and NOT 1607 media.
Need to wait for 1607 Language Packs to be released then eh… 😉
It can be useful to have a PowerShell script which runs as a Windows Scheduled task to perform otherwise manual tasks. Being a lazy bugger I like to automate as many boring, shitty tasks as I can so PowerShell and Scheduled Tasks are my friends…
A good example of this would be if you needed to run a cleanup of WSUS to remove declined, superseded, expired updates etc.
The script I want to run looks like the following:
Cleans up WSUS on local server
PowerShell.exe -ExecutionPolicy ByPass -File WSUSCleanup.ps1
Author: Jonathan Conway
# Set WSUS port number (standard is 8530 on Windows Server 2012 R2 but can be customised)
$WSUSPortNumber = 8530
# Connect to local server using PowerShell
Get-WsusServer -Name $env:computername -PortNumber $WSUSPortNumber
# Perform required cleanup commands
Get-WsusServer | Invoke-WsusServerCleanup -CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates -DeclineExpiredUpdates -DeclineSupersededUpdates | `
Out-File -FilePath C:\Tools\Scripts\wsuscleanup.log
In order to run this as a Scheduled Task in Windows I’d need to run it as SYSTEM (NT AUTHORITY\SYSTEM) – change the “Configure for:” section at the bottom to match the OS you’re using as well, for compatibility purposes.
Configure a Trigger – once a week should be more than enough for this particular task.
The action should be configured to “Start a Program” which would be as per the command line example below (example assumes you have a script called WSUSCleanup.ps1 located in a folder called “C:\Tools\Scripts”):
PowerShell.exe -ExecutionPolicy ByPass -File C:\Tools\Scripts\WSUSCleanup.ps1
It should end up looking a bit like this:
And that’s about it – should run as per the Trigger Schedule.
A customer recently had a requirement to deploy a PowerShell script to configure a setting for App-V 5.0.
Normally I’d do this with a Batch file called “Configure.cmd” containing the code displayed below. This works for the majority of tasks:
PowerShell.exe -ExecutionPolicy Bypass -File ".\PowerShellScriptFileName.ps1"
As usual, I tested the deployment before adding into SCCM by using psexec running under the System context (i.e. the same context that SCCM deployments run under) with the command below. One the command prompt is open you can run the required installer as the System context:
psexec /s cmd.exe
This completed successfully and made the configurations that I’d wanted. Bosh. Bloody awesome I thought…
On this occasion however I needed to reconfigure a 32-bit application (App-V 5.0) on a 64-bit operating system (Windows 7 x64).
This doesn’t play well when deployed via SCCM is seems and ends up running using the SysWOW64 redirection – the result in my case was that registry changes were made by the PowerShell cmdlet in the Wow6432Node area of the registry.
In order to get around this I discovered a new concept to me called “Sysnative” which is a virtual directory and special alias that can be used by applications/scripts to access the 64-bit “System32” folder – which is exactly what I wanted to happen in this instance for my script to produce the required result.
Therefore to use this you need to change the location that PowerShell is called from to %WinDir%\Sysnative (you can’t see it in Windows Explorer btw – but trust me, this little bugger does indeed exist):
%WinDir%\Sysnative\windowsPowershell\v1.0\Powershell.exe -ExecutionPolicy Bypass -File ".\PowerShellScriptFileName.ps1"
Once changed to reference the correct PowerShell.exe my script punted out the desired results. Fucking Magic 🙂
RoboCopy is used as a tool to copy folders but it can also be used to copy single files if required.
This is handy if you’re copying a large file (such as an ISO or WIM image) and want some sort of feedback from a command prompt on how it’s progressing (not something that happens with xcopy or copy).
Say you want to copy a file called BigFile.iso from the root of the C:\ Drive to the root of the E:\ drive you could use the following command
robocopy C:\ E:\ BigFile.iso
Recently a customer wanted the ability to be able to rebuild Windows XP machines (!) via SCCM 2012 R2 by just adding machines into a rebuild collection.
This doesn’t work out of the box with the version of WinPE that ships with SCCM so to get it to work you need to create a custom Boot image based on WinPE 3.1, add it into ConfigMgr and associate it with the Windows XP Task Sequence – this allows WinPE to pre-stage onto the local disk and for the machine to successfully reboot into it.
The following code can be added into a Batch File and executed as an Administrator to automate the creation of the Boot Image and add the required components.
echo # REMOVE DIRECTORY IF IT EXISTS
RD C:\TEMP\WinPE\LegacyWinPEx86 /S /Q
echo # CREATE X86 WINPE FOLDER STRUCTURE
CALL "C:\Program Files\Windows AIK\Tools\PETools\copype.cmd" x86 C:\TEMP\WinPE\LegacyWinPEx86
echo # COPY WIM FILE TO ISO\SOURCES DIRECTORY AND RENAME AS BOOT.WIM
COPY C:\TEMP\WinPE\LegacyWinPEx86\winpe.wim C:\TEMP\WinPE\LegacyWinPEx86\ISO\sources\boot.wim
echo # MOUNT THE BOOT.WIM FILE IN THE MOUNT DIRECTORY
Dism /Mount-Wim /WimFile:C:\TEMP\WinPE\LegacyWinPEx86\ISO\sources\boot.wim /index:1 /MountDir:C:\TEMP\WinPE\LegacyWinPEx86\mount
echo # ADD OPTIONAL COMPONENTS TO WINPE IMAGE
Dism /image:C:\TEMP\WinPE\LegacyWinPEx86\mount /Add-Package /PackagePath:"C:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\winpe-wmi.cab"
Dism /image:C:\TEMP\WinPE\LegacyWinPEx86\mount /Add-Package /PackagePath:"C:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\winpe-scripting.cab"
Dism /image:C:\TEMP\WinPE\LegacyWinPEx86\mount /Add-Package /PackagePath:"C:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\winpe-wds-tools.cab"
Dism /image:C:\TEMP\WinPE\LegacyWinPEx86\mount /Add-Package /PackagePath:"C:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\winpe-hta.cab"
Dism /image:C:\TEMP\WinPE\LegacyWinPEx86\mount /Add-Package /PackagePath:"C:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\winpe-mdac.cab"
echo # SET SCRATCH SPACE TO 128MB
Dism /Set-ScratchSpace:128 /Image:C:\TEMP\WinPE\LegacyWinPEx86\mount
echo # ADD ANY REQUIRED DRIVERS TO THE IMAGE
Dism /Image:C:\TEMP\WinPE\LegacyWinPEx86\mount /Add-Driver /Driver:C:\TEMP\WinPE\Drivers /Recurse
echo # UNMOUNT IMAGE AND COMMIT CHANGES
Dism /Unmount-Wim /MountDir:C:\TEMP\WinPE\LegacyWinPEx86\mount /Commit
WinPE 1.0 [Windows XP] [5.1.2600.x] [First version of WinPE]
WinPE 1.1 [Windows XP SP1] [5.1.2600.x]
WinPE 1.2 [Windows Server 2003] [5.2.3790.x]
WinPE 1.5 [Windows XP SP2] [5.1.2600.x] [Windows PE 2004]
WinPE 1.6 [Windows Server 2003 SP1] [5.2.3790.x] [Windows PE 2005]
WinPE 2.0 [Windows Vista] [6.0.6000.x]
WinPE 2.1 [Windows Server 2008] [6.0.6001.x]
WinPE 2.2 [Windows Server 2008 SP2] [6.0.6002.x]
WinPE 3.0 [Windows 7] [6.1.7600.x] [Windows AIK 2.0]
WinPE 3.1 [Windows 7 SP1] [6.1.7601.x] [Windows AIK Supplement for Windows 7 SP1]
WinPE 4.0 [Windows 8] [6.2.9200.x] [Windows ADK 8.0]
WinPE 5.0 [Windows 8.1] [6.3.9300.x] [Windows ADK 8.1]
WinPE 5.1 [Windows 8.1 Update 1] [6.3.9600.x] [Windows ADK 8.1 Update]
WinPE 10.0.10586 [Windows 10] [1511 – 10586.104] [Windows ADK 10.1.10586.0]