If you get a message in the Windows 10 Action Center saying “Finish installing device software” with a red/white cross and a UAC symbol on then it’s likely that a driver is missing, a driver needs some software installed or that Windows needs your permission to resolve one of these actions (hence the UAC symbol).
In can be an absolute bastard to figure out which device/driver is causing this issue but one way to track it down is to click to allow the install to complete and then look in the file:
Look for Finish-Install actions (typically they will be the latest entries in the log file if you’ve just clicked to complete the action immediately before looking) and that should lead to you to identifying the troublesome device. Back of the net.
If you’re looking to improve the performance (quite significantly in my experience) of Trivial File Transfer Protocol/TFTP (in other words to improve the download speed of your SCCM boot images to your clients from the DP) you can add some registry keys on the server hosting the PXE-enabled Distribution Point to achieve this.
The two keys required (and the values I suggest using) are:
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\SMS\DP" -Name RamDiskTFTPBlockSize -PropertyType DWord -Value "16384"
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\SMS\DP" -Name RamDiskTFTPWindowSize -PropertyType DWord -Value "8"
Once the keys have been added, restart the “Windows Deployment Service Server” service and that’s you finished. 🙂
One caveat with this change is that it can also adversely affect performance and in some cases even break PXE altogether (as I found out with my Hyper-V 2012 R2 VM’s – VM’s stopped working completely while physical hardware zipped along like shit off a stick) so some tweaking of the values may be required depending on your environment. Basically one size does not fit all with this change.
Can’t find any proper information on SCCM CB but it looks like this is a supported change from looking at this TechNet post: link
UPDATE 30/09/2016 – some much better detail and testing results for this TFTP optimisation provided by Jörgen Nilsson on the excellent ccmexec.com website – link
To quickly see which drive letters/volumes are available from a command prompt you can use wmic to get a quick summary.
The following command will give you the information you need:
wmic logicaldisk get description,name
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 🙂