Activation tool to use Windows OEM Key from BIOS

A simple tool to extract and use the Windows activation key from BIOS.
The tool will extract the key Windows Management Instrumentation Command-line.
The key extracted will be install and activated using Windows Software Licensing Management Tool.

Tool is command-line based.

Can be used with your favorite client management tool

Unified Extensible Firmware Interface (UEFI)

Unified Extensible Firmware Interface

For many years BIOS has been the industry standard for booting a PC. BIOS has served us well, but it is time to replace it with something better. UEFI is the replacement for BIOS, so it is important to understand the differences between BIOS and UEFI. In this section, you learn the major differences between the two and how they affect operating system deployment.

Introduction to UEFI

BIOS has been in use for approximately 30 years. Even though it clearly has proven to work, it has some limitations, including:

  • 16-bit code
  • 1 MB address space
  • Poor performance on ROM initialization
  • MBR maximum bootable disk size of 2.2 TB

As the replacement to BIOS, UEFI has many features that Windows can and will use.

With UEFI, you can benefit from:

  • Support for large disks. UEFI requires a GUID Partition Table (GPT) based disk, which means a limitation of roughly 16.8 million TB in disk size and more than 100 primary disks.
  • Faster boot time. UEFI does not use INT 13, and that improves boot time, especially when it comes to resuming from hibernate.
  • Multicast deployment. UEFI firmware can use multicast directly when it boots up. In WDS, MDT, and Configuration Manager scenarios, you need to first boot up a normal Windows PE in unicast and then switch into multicast. With UEFI, you can run multicast from the start.
  • Compatibility with earlier BIOS. Most of the UEFI implementations include a compatibility support module (CSM) that emulates BIOS.
  • CPU-independent architecture. Even if BIOS can run both 32- and 64-bit versions of firmware, all firmware device drivers on BIOS systems must also be 16-bit, and this affects performance. One of the reasons is the limitation in addressable memory, which is only 64 KB with BIOS.
  • CPU-independent drivers. On BIOS systems, PCI add-on cards must include a ROM that contains a separate driver for all supported CPU architectures. That is not needed for UEFI because UEFI has the ability to use EFI Byte Code (EBC) images, which allow for a processor-independent device driver environment.
  • Flexible pre-operating system environment. UEFI can perform many functions for you. You just need an UEFI application, and you can perform diagnostics and automatic repairs, and call home to report errors.
  • Secure boot. Windows 8 and later can use the UEFI firmware validation process, called secure boot, which is defined in UEFI 2.3.1. Using this process, you can ensure that UEFI launches only a verified operating system loader and that malware cannot switch the boot loader.


UEFI Version 2.3.1B is the version required for Windows 8 and later logo compliance. Later versions have been released to address issues; a small number of machines may need to upgrade their firmware to fully support the UEFI implementation in Windows 8 and later.

Hardware support for UEFI

In regard to UEFI, hardware is divided into four device classes:

  • Class 0 devices. This is the UEFI definition for a BIOS, or non-UEFI, device.
  • Class 1 devices. These devices behave like a standard BIOS machine, but they run EFI internally. They should be treated as normal BIOS-based machines. Class 1 devices use a CSM to emulate BIOS. These older devices are no longer manufactured.
  • Class 2 devices. These devices have the capability to behave as a BIOS- or a UEFI-based machine, and the boot process or the configuration in the firmware/BIOS determines the mode. Class 2 devices use a CSM to emulate BIOS. These are the most common type of devices currently available.
  • Class 3 devices. These are UEFI-only devices, which means you must run an operating system that supports only UEFI. Those operating systems include Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2. Windows 7 is not supported on these class 3 devices. Class 3 devices do not have a CSM to emulate BIOS.

Windows support for UEFI

Microsoft started with support for EFI 1.10 on servers and then added support for UEFI on both clients and servers.

With UEFI 2.3.1, there are both x86 and x64 versions of UEFI. Windows 10 supports both. However, UEFI does not support cross-platform boot. This means that a computer that has UEFI x64 can run only a 64-bit operating system, and a computer that has UEFI x86 can run only a 32-bit operating system.

How UEFI is changing operating system deployment

There are many things that affect operating system deployment as soon as you run on UEFI/EFI-based hardware. Here are considerations to keep in mind when working with UEFI devices:

  • Switching from BIOS to UEFI in the hardware is easy, but you also need to reinstall the operating system because you need to switch from MBR/NTFS to GPT/FAT32 and NTFS.
  • When you deploy to a Class 2 device, make sure the boot option you select matches the setting you want to have. It is common for old machines to have several boot options for BIOS but only a few for UEFI, or vice versa.
  • When deploying from media, remember the media has to be FAT32 for UEFI, and FAT32 has a file-size limitation of 4GB.
  • UEFI does not support cross-platform booting; therefore, you need to have the correct boot media (32- or 64-bit).

WSUS clients may fail during synchronization and log the following errors: 0x8024400D

Issue: WSUS clients may fail during synchronization and log the following errors: 0x8024400D

Cause: Too much rubbish in WSUS database eg. Lots and lots of expired and superseeded updates. No cleanup or maintenance has been done for a loong time.


Execute a maintenance CleanUp on the WSUS Server. Most of the 0x8024400D are due to a high quantity of updates on the server, even declined, expired, or superseded. This causes that the client WU Engine cannot finish processing all the information, and cannot pass to the Evalutation phase of the update process.


-Run Decline-SupersededUpdates.ps1 (Can also be found at – in the Archive folder). If the base Operating System is Windows 2008 R2 of further there should not be any problem to run it on Powershell 2.0


Open a Powershell windows as Administrator

Execute the next cmdlet in order to be able to execute non-signed scripts: Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Execute the script using the next syntax: .\Decline-SupersededUpdates.ps1 -UpdateServer FQDNoftheWSUSserver -Port xx -SkipDecline

Example: .\Decline-SupersededUpdates.ps1 -UpdateServer wsus.domain.local -Port 8530 -SkipDecline


After the process finishes we need to run the WSUS Cleanup:

From WSUS Console, go to Options, and open WSUS Cleanup Wizard

– Select only the 4th and 5th option: Expired Updates and Superseded Updates

– After the process finishes, run the Wizard again, just selecting the 1st Option: Unused updates and update revisions.

You might have to run this multiple times, untill it stops giving timeout errors – in case you got A LOT of expired and superseded updates – I’ve put up a script to perform this task instead. – see this post:

  • Check if the affected clients are running Windows 7 – 32 bit version.

In this case, we will need to ensure that they have at least the WU Agent revision from June 2015:                               (You can download it from Here: )

  • – Clean the bloated update cache on the affected clients:

From a CMD as Administrator execute:

Net stop AppIDSvc

net stop wuauserv

net stop cryptsvc

ren %windir%\SoftwareDistribution %windir%\SoftwareDistribution.old

ren %systemroot%\system32\catroot2 oldcatroot2

Delete, in the registry: the PingID, SUSClientID and the AccountDomainSID values from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate

Then execute:

net start AppIDSvc

net start wuauserv

net start cryptsvc

wuauclt /resetauthorization /detectnow

Join Mac OS X to Active Directory

Simple script to join a Mac to domain






# Enable SSH

echo “Enabling SSH”

systemsetup -setremotelogin on

launchctl load -w /System/Library/LaunchDaemons/ssh.plist

# Add computer to Active Directory

echo “Adding computer to Active Directory”

dsconfigad -preferred $HOST -domain $DOMAIN -u $ADUSERNAME -p $ADPASS

Installing .NET Framework 3.5 with MDT 2013 the simple way

In my case I need to automate the installation of .NET 3.5 within a MDT 2013 build and capture task sequence for Windows 8.1

In the State restore add a step to set the WindowsSource Path
The Windows Source will be located within the Operating Systems folder on your Deployment Share

  1. Add a Set Task Sequence Variable step
    1. Type Task Sequence Variable: WindowsSource
    2. Type Value for your source files: %deployroot%\Operating Systems\Windows 8.1 x64 Enterprise VL\Sources\SXS

Set Task Sequence Varable

  1. Add a Install Roles and Features step
    1. Select your Operating System within the step
    2. Mark .NEt Framework 3.5 (Includes .NET 2.0 and 3.0)

InstallRoles step MDT

Is it that simple? Yes!

NOTE: If you want to use a Run Command Line to install it, you could use something like this: DISM.exe /online /enable-feature /featurename:NetFX3 /All /Source:”%deployroot%\Operating Systems\Windows 8.1 x64 Enterprise VL\Sources\SXS” /LimitAccess

Intel NUC adding the missing SMBIOS information

Today I encountered the Intel NUC (NUC5i3RYH).

The task was simple, Add Drivers to WinPE & Create Driver Package for Windows 8.1

Unfortunately, the Intel NUC (NUC5i3RYH) was missing vital SMBIOS information ;(

The System Management BIOS (SMBIOS) defines access methods and data structures for BIOS that stores information on specific computers.

Example SMBIOS categories include:

  • Manufacturer
  • Product Name
  • Version
  • Serial Number
  • System SKU Number
  • System family
  • Chassis Asset Tag

I ran the following commandline: wmic csproduct get *

The result concluded that all information (except the SMBIOS GUID) was missing.

In my case, I needed the Product Name to match the actual model number – The info is needed to apply a specific driver package for the model using Configuration Manager or MDT

The Product Name can be verified using commandline: wmic csproduct get name

When assigning drivers from the task sequence in Configuration Manager or MDT I usually use:

SELECT * FROM Win32_ComputerSystem WHERE Model LIKE “%TYPE%”

or for Lenovo

SELECT * FROM Win32_ComputerSystemProduct WHERE Version LIKE ‘%TYPE%’

So what to do?

Intel has released a tool to modify the bios: Intel® Integrator Toolkit (download:

Using the tool is pretty simple:

  1. Download and Install Intel® Integrator Toolkit
  2. Start the tool
  3. Select download and customize bios in the wizard
  4. Choose your model from the list
  5. Select your BIOS
  6. Click Download and customize
  7. In the SMBIOS tab add the info you need
  8. Click Save
  9. In File Menu, click Create BIOS Install Package
  10. Save your EXE file
  11. Now run the file on the model you need to update with the information – it works from within Windows or from Windows PE.

After the reboot you will need to confirm the BIOS upgrade.

The added information is now available for use

Windows 10 – Windows Updates troubleshooting

If you experience problems with Windows Updates and need to debug on the actual process, WindowsUpdates.log has always been a good place to start……… but not on Windows 10

According to Microsoft these steps are relevant only for the January Tech Preview of Windows 10.

Windows Update uses Event Tracing for Windows (ETW) to generate diagnostic logs. This method improves performance and reduces disk space usage. However, the logs are not immediately readable as written. To decode the resulting ETL files and create a log that you can read, follow these steps.

  1. Download the public symbols by following the directions here. Install these symbols to a directory such as C:\symbols.
  2. Download the Tracefmt.exe tool by following the instructions here.
  3. Open a command prompt with administrative rights.
  4. Create a temporary folder, such as %systemdrive%\WULogs.
  5. Locate the directory that contains Tracefmt.exe, as downloaded and installed in step 2. Then, copy Tracefmt.exe to %systemdrive%\WULogs.
  6. Run the following commands at a command prompt, in the order presented:
    • cd /d %systemdrive%\WULogs
    • copy %windir%\Logs\WindowsUpdate\* %systemdrive%\WULogs\
    • tracefmt.exe -o windowsupate.log <each windows update log delimited by space> -r c:\Symbols

For example, the last line might resemble the following:

tracefmt.exe -o windowsupate.log Windowsupdate.103937.1.etl Windowsupdate.103937.10.etl -r c:\Symbols

Lucky for us, we don’t always need to dig deep – there is a deprecated logfile we can use for now (January Tech Preview) WindowsUpdate_AU_deprecated.log

Advanced Installer

For many years I’ve been working with Wise Package Studio, the best tool ever for application repackaging projects. Since Wise Package Studio is End of life – announced in December 2011. Now seemed like a good time to find a new tool, Flexera Admin Studio seemed like the obvious choice, but is rather expensive (still a great tool)

In some cases Orca ( would get the job done, but still would take a long time

I remembered coming across Advanced Installer at TechEd NA, so decide to have a look at the tool

There is a free trial from the website and also a free version:

Advanced Installer comes in multiple versions, I choose to test the Architect version, mainly because it had the following features highlighted

  • Repacker
  • App-V
  • SCCM
  • MSI Quick-Edit

My test of the product was a great success !

Today I will recommend this product to my customers looking to repackage or edit MSI’s, it has a nice and intuitive interface, much like Wise Package Studio had 😉

Have a look at some of the videos from Advanced Installer on YouTube:



Application repackaging – Active Setup & Windows Installer Repair

If you repackage or deploy applications you need to know about Active Setup and Windows Installer Repair

The best methods are documented first, but also other alternative ways.

Method I

Active Setup Method:

This is one of the best practices in MSI Packaging which uses the native Active Setup behavior of Windows and Windows Installer HKCU keys repair techniques.

One should follow these specific steps while using this method:

  1. Make sure all HKCU keys in the MSI Package that we are creating are under structured component names like CurrentUser, CurrentUser1, etc.
  2. The Package author should be able to judge and set the key path for that Component properly.
  3. As per Microsoft Component guidelines, make sure the components containing HKCU keys are as few in count as possible, for example only one component (CurrentUser) with all HKCU keys with best key path set is the best practice.
  4. Create the following registry keys under the main hive:
  1. HKLMSoftwareMicrosoftActive SetupInstalled Components{GUID of the MSI}
  2. ComponentID=PackageName_ComponentName
  3. StubPath=[SystemFolder]msiexec.exe /fu {Product Code of the MSI} /q
  4. Version=ProductVersion

The principle of Active Setup behavior is when a new user logs on for the first time, then the Active Setup will perform a checksum between HKLMSoftwareMicrosoftActive SetupInstalled Components{GUID of the MSI} and HKCUSoftwareMicrosoftActive SetupInstalled Components{GUID of the MSI}; and if the GUID is not present under HKCU, then it performs all actions which are under that main hive (StubPath, Version) and populates the GUID under HKCU. The main Advantage of Active Setup is it performs an action only once per User with the Checksum behavior by matching the entries under HKLM and HKCU.

Method II

Active Setup Method:

This method can be used for both MSIs and Non-MSIs

Create a silent SMS script or Wise Script (for eg:-Script.exe) which will create the needed HKCU registry entries for the application. Then place that EXE in the Application [INSTALLDIR] in your MSI Pkg or Executable binary memory.

Then create the following additional registry entries in the MSI Package or within the Script whichever is applicable:

HKLMSoftwareMicrosoftActive SetupInstalled Components{GUID or AppName}





The Active Setup performs the regular checksum (comparison of entries under) HKLM and HKCU and if the respective unique GUID or AppName is not present under HKCU hive, then it will perform all actions (StubPath, Version) and populates the GUID or AppName under HKCU hive too. This is only once per user — for the first time — to populate HKCU hive.

Method I and method II use the Active Setup feature, and One should understand the advantages of one over the other. Method I requires source resiliency to populate HKCU keys, where as method II does not require this as the Script.exe does everything.

Method I and method II can be used in any scenarios like if Advertised entry points are present or NOT present.

Method III

Windows Installer repair method

Typically the body of the script will be;

Check for the existence of a Flag key under
HKCUSoftwareCompany NameApplications{ProductName][productversion]

If the key exists then quit else initiate the Windows Installer repair to populate HKCU keys:

Msiexec /fu {Product Code of the MSI} /q


And edit and create registry key (Basically a Flag Key which can be any key which your firm adopts)
* XYZ= Name of the organization Company
And keep this script exe in HKLMSoftwareMicrosoftWindowsCurrentVersionRun.

One should keep in mind that the /p switch can also be used to repair files (populate) user-specific data (Profile data) with the following syntax:

Msiexec /fup {Product Code Of the MSI) /q


Method IV

Silent empty exe with valid shortcut:

Create a silent empty exe and its Advertised shortcut and place both of them in the Application [INSTALLDIR]. And use them as entry points to trigger healing to populate HKCU keys.