An issue has occured recently in our environment where some computer models, in our case Dell Precision T7600 models, sometimes fail to join the domain during an imaging task sequence, but do not fail the task sequence until they get to the first “Install Applications” step in the sequence. Computers that fail in this way do not have a netsetup.log file where it should be, meaning the computer couldn’t even contact the domain to attempt to join. Further exploration of the log files on the failed client shows the following two clues:
[DJOIN.EXE] Unattended Join: NetJoinDomain failed error code is 
[DJOIN.EXE] Unattended Join: Unable to join; gdwError = 0x54b
No adapters found in environment. Performing global finalization only.
It turned out in our case that the task sequence was failing to join the domain because the network adapter was too slow to respond after the reboot. I’m not sure if this is due to the T7600’s dual network adapters or some other reason, but so far this is the only model that has shown this behavior in all the years we’ve been using SCCM. In addition, the problem is intermittent and does not always happen – sometimes the machines do succeed in joining AD.
The workaround for this problem is to add a “Join Domain or Workgroup” step in the task sequence (which can be found in the “Add > General” menu in the task sequence editor window) after the “Setup Windows and Configuration Manager” step, and add a delay between the two steps. I added a two minute delay, but that might be overkill. After making this small modification to the task sequence, every single computer completed the second domain join step and therefore finished the rest of the task sequence successfully. Here is what it should look like: Continue reading
I was recently tasked with putting together a GPU mining setup for a client with a $1500 budget and certain requirements. I am sharing the component list used for the build here so that anyone else with a similar budget and similar requirements can have an idea of what to select for their system.
This build allows for expansion of up to 6 total graphics cards. If your budget is lower, you can opt for a cheaper motherboard with less PCIe slots, a cheaper power supply with less wattage capacity, and maybe a different case.
Also keep in mind that there are better and higher quality components available, but for a higher price.
This setup can be used to mine Ethereum (ETH), Monero (XMR), Ethereum Classic (ETC), Zcash (ZEC), and any other cryptocurrency that uses a GPU mining algorithm.
Here is the parts list for this build: Continue reading
In the past I posted how to configure or clear the SCCM client cache using Powershell scripts, but that method required a separate script for each cache size you might want to set. This new script allows on-the-fly modification of the CCM Cache from a task sequence using a single SCCM package containing this new Powershell script.
To use this script, you will need to create a package in SCCM with the source contents containing this script. You do not need to create a program for the package. Make sure the package can be used by task sequences without being deployed. After distributing the package, just call it from a task sequence using a “Run Command Line” step referencing the package.
Assuming you save the script as “sccmCache.ps1”, any of these usage examples will work:
powershell -executionpolicy bypass -file sccmCache.ps1 -cacheSize 5120 -clearCache yes
powershell -executionpolicy bypass -file sccmCache.ps1 5120 clear
powershell -executionpolicy bypass -file sccmCache.ps1 -cacheSize 5120
powershell -executionpolicy bypass -file sccmCache.ps1 5120
powershell -executionpolicy bypass -file sccmCache.ps1 -clearCache yes
powershell -executionpolicy bypass -file sccmCache.ps1 clear
And here is the Powershell script:
I created this script for use with SCCM to allow easy creation of shortcuts during deployment for applications that do not create their own shortcut, or for portable applications that are not actually installed. The powershell script can be called upon from the “Run Command Line” step of a task sequence, and the script should be added as a Package to SCCM so that it can be referenced from the Package option inside the Run Command Line step.
This script generates shortcuts in the Public Desktop and the Start Menu. If a drive letter is specified in the path, it will be used. If no drive letter is specified in the path, the $env:SystemDrive variable will be used to figure out the drive letter based on the OS drive. If a URL is specified in the path, it will be used instead of a local path.
Here are some usage examples:
powershell -executionpolicy bypass -file generateShortcut.ps1 -name "Shortcut Name" -path "D:\test.txt"
powershell -executionpolicy bypass -file generateShortcut.ps1 "Shortcut 2" "Users\Administrator\Desktop\test.txt"
powershell -executionpolicy bypass -file generateShortcut.ps1 -name "Shortcut to Google" -path "https://www.google.com/"
Here is the full script:
I recently had to encrypt a Microsoft Surface Pro 4 using Bitlocker, and in our environment that means backing up the key to Active Directory. However, after the Surface was encrypted, running the “manage-bde -protectors -get C:” command showed it only had a TPM PCR Validation Profile, and was missing the Numerical Password ID that would be necessary in order to run adbackup on the protector. This was on Windows 10 Enterprise 1607.
When trying to add a new protector using the -RecoveryKey switch, there was an error saying “No pre-boot keyboard or Windows Recovery Environment detected. The user may not be able to provide required input to unlock the volume.” What’s even more puzzling is that this error occurred on just one of the Surface Pro 4’s, and the second one encrypted without a problem and had a Numerical Password ID as it should. As it turns out, this error message means the computer has no physical keyboard during pre-boot (even if the physical Surface keyboard is attached) even though that doesn’t matter for us since we’re not using a TPM pin to unlock the device.
The way to fix this is to make sure the following registry key exists with a value of 1. If it doesn’t exist, you will need to create it and set it to 1:
SCCM’s power configuration options allow setting a wakeup time for computers, but only for desktops. Currently SCCM has no option to enable wakeup for laptops. The idea behind this is that a laptop can be in a bag and so should not be woken up automatically, but it would still be nice to have an option to enable this if you know for sure that your laptops will not be inside a laptop bag during the wakeup time, such as laptops used in lab environments.
Setting a wakeup time for laptops can be accomplished with a PowerShell script and a Task Scheduler task. This can be deployed with SCCM as a package targeting your laptop collections.
The first part is to enable wake timers using Powershell. SCCM’s power configuration options for a device collection can enable wake timers but again only for desktops, with no option at all to allow wake timers for laptops. This script can work with or without having an SCCM power configuration set for the device. As the device switches between peak and non-peak hours and therefore applies different SCCM power configurations automatically, it will still keep wake timers turned on when configured with this script. Here is the script (this one is floating around the internet – I didn’t write it), and you can selectively enable or disable wake timers for DC (on battery) and AC power (plugged in) by changing the $AllowWakeTimersGUI value for SETDCVALUEINDEX and SETACVALUEINDEX:
If you need to clear the SCCM client cache or increase the cache size on individual clients, there are a few different ways to do it. One of the methods usually posted on a lot of blogs and forums is actually the wrong way to do it, because it requires restarting the CCMEXEC process on the client in order to update the new cache settings, which makes the task sequence used to deploy the script fail since CCMEXEC, which was running the deployment, has been terminated.
Here I will show you the right way to clear the CCM cache that does not require restarting the CCMEXEC process. This PowerShell script can be deployed with SCCM as a package or as part of a task sequence. Sometimes this method is preferable to using Right Click Tools, especially if you want to only change cache settings during application deployment, such as part of a task sequence that installs multiple large applications. Sometimes it doesn’t make sense to keep 30GB of installers cached on the computer and it’s better to just manually flush the cache after the installation completes.
Here is the script to clear the ccmcache: