New Tool: Get the Latest Windows 10 Cumulative Updates!

TL;DR – Programmatically get the latest Windows 10 Cumulative Updates!

Got a request from someone on an internal e-mail Distribution list recently, asking how to find out the latest Windows 10 (or Windows Server 2016) Cumulative Update.

Normally you can find these updates by going to this Microsoft KB article, then finding the right Operating System Version. Then you use the KB article number to go to Windows Update, and find the correct download link, then download the file.

I wanted to update this for another project, so I took it as a challenge to code in PowerShell.

New Tool

For this tool, I placed the source code up on GitHub.com, in a new gist. A gist is just a file that can be edited, version controlled, and shared out publicly on the GitHub.com site.

Given a Windows Version (build number), and a couple other search strings, will programmatically determine what the correct download links are for this Windows 10 (or Windows Server 2016).Â

The output can also be piped into BITS so you can just download locally.

Example

Get the links for the latest Windows 10 Version 1703 Updates:

getupdates1.PNG

 

Additionally we can also download the files using the BITS command Start-BITSTransfer

downloadupates1.PNG

 

Source

 

 

 

Decrypting the HP BIOSConfigUtility64.exe password

First off, for those of you who asked, I did leave 1E last week, off to try new things. Thought I’d take some time off during May, and then look for new opportunities. The future is wide open :^)

In the mean time, I did come across this post today about decrypting passwords with the BIOSConfigUtility64.exe utility.

https://www.serializing.me/2016/10/15/hpqpswd-encrypted-passwords-decryption/

And reminded me of some work I did recently at 1E on their BIOS 2 UEFI toolset. The HP tool did set off some red flags for me, the tool was able to take a plaintext password and put the encrypted value in a *.bin file without asking for an encryption key!?!? How did it do that? I figured it was because the tool stored the encryption key for the password within the executable itself. That’s not optimal (it’s unsecure), but not uncommon.

So I spent some time trying to reverse engineer the process, “link -dump /imports” revealed several cryptographic calls like CryptImportKey(), and with some time using trusty WinDBG.exe, I was able to locate the key. I wondered if HP would try to hide the key, but it was there in plain sight. I wrote a test program, but in my case I didn’t write a tool to decrypt the password, I wrote a tool to perform the encryption.  My thoughts were to provide a centralized password storage mechanism for HP, Dell and Lenovo, and I wondered if the HP toolset was a good starting point. 1E didn’t go down that route but the reverse engineering the HP tool was interesting.

It does bring up an interesting ethical dilemma for Engineers like myself. Something that you see on the news whenever someone discovers a new vulnerability in an OS, or Web Browser: Do you keep the vulnerability secret, or do you tell the public, knowing that some Black Hat could use the vulnerability to write an exploit and expose sensitive data?  In my case, I decided not to reveal the exploit, but Duarte chose to reveal it. Who is right?

I guess the only thing I can say is this is a good learning opportunity to discuss security/encryption of secrets like passwords. If you are an IT administrator, be weary of tools that can encrypt data magically without an encryption key, it’s not magic, they are encrypting the data with *something* and it’s possible the key is stored locally in an unsecure fashion. Better to store the passwords in a more secure location, with a more secure encryption, and then convert to the HP Password at the “Last-Minute” when preforming the actual task sequence.

This is a similar problem with other tools that “appear” to encrypt data, but store the data in a manner that *can* be easily extracted. Like the AdministratorPassword field in the unattend.xml file, and the Password in the SysInternals AutoLogon.exe tool. Both tools store passwords in an easily recoverable fashion. I’ve seen too many administrators fall for the illusion that these are secure, they are not.

-k

Hope to see many of you at MMS MOA in May 2017!!! I’ll be there.

Supermicro vs No_Drv

TL;DR – A NO_DRV driver is a driver package that doesn’t contain a driver binary. It uses the driver from another package (typically an in-box Microsoft driver).

Server Woes

One of my servers, a SuperMicro 5038A-IL has been locking up on me. I’ve been able to use the machine for the most part for the past year, but the upshot is that I can’t upgrade the machine from one Windows version to another. 22% of the way through WinRE (or sometimes WinPE), the machine has a hard Freeze, and won’t respond to mouse movement or keyboard. I’ve tried kernel debugging, hardware swaps, nothing works. My experience tells me this is a hardware problem. Time to escalate to SuperMicro support.

Upgrade your drivers

OK I should have seen this one coming, I call up support, and the first thing they ask me to do is make sure I have the latest Network and System Drivers.

  1. WinRE doesn’t use Network, so this isn’t a problem.
  2. System Drivers sure! Let’s download and check to see I have the latest stuff.

ftp://ftp.supermicro.com/driver/Intel_INF/Skylake_Series_Chipset/Chipset_v10.1.2.80.zip

No_Drv

I open the driver package, and take a look. Wait a minute, I don’t see any *.sys files, only *.inf and *.cat files.

sys – These are the compiled drivers, usually written in c/c++.
inf – These are the install files, typically there is at least one of these.
cat – This is the digial signature, signed by Microsoft to verify the source of the driver.

How can there be no driver in the driver package? Let’s look

[Version]
...
CatalogFile=Skylake.cat
...
[INTEL.NTamd64]
...
%PCI\VEN_8086&DEV_191FDesc%=Needs_NO_DRV,PCI\VEN_8086&DEV_191F

[Needs_NO_DRV]
Include=machine.inf
Needs=NO_DRV
Oh, NO_DRV, now I recall, this is an old trick. The device above DEV_191F doesn’t actually require a device driver, it’s transparently handled by Windows. But Windows doesn’t give it a descriptive name, just a generic name. So companies like Intel can provide this pack so you can give some devices more descriptive names in the Device Manager. The intel driver above points to an entry in the machine.inf driver already on the machine.
From:   “PCI Standard ISA bridge”
To:   “Intel(R) C226 Series Server Advanced SKU LPC Controller – 8C56”
That’s all it does, It doesn’t affect the operation of the OS or the hardware. Just the name! Sometimes this is helpful if you need to quickly identify a device, but, yes it’s mostly used for vanity, so I never load them on my machines.
So… I responded to SuperMicro, and confirmed I was using the latest drivers from intel. :^)

 

Formatting a removable USB drive with 2 partitions

TL;DR – Starting with Windows 10 Insider Preview Build 14965, you can format any “Removable” USB Flash Drive with more than one partition. Perfect for installation of large (over 4GB) WIM files on UEFI machines!

 

Hey all, back from a week at the Microsoft MVP summit, a Week in the UK, and a week in Arizona.

A few weeks ago at the Microsoft MVP summit, an engineering manager with the Windows Product group made an offhand comment about formatting a removable USB drive with two partitions. This took several of us by surprise, because historically, this hasn’t been supported widely without converting to a Fixed disk or something.

Mike Terrill (and Mike Niehaus) already beat me to the punch with some posts, but I wanted to share my results. :^)

The Background

Why is this important? Well as I mentioned in another blog post, as more and more people are booting to UEFI, on USB flash drives formatted with Fat32, with WIM images over 4GB in size, that causes a problem because Fat32 can’t hold files over 4GB in size.

Another solution would be to use the Rufus tool to split a USB drive into multiple partitions with a hidden fat32 partition. However, the problem here is that the hidden partition uses a special UEFI app that is not signed, so it won’t work on UEFI machines with Secure Boot enabled.

This has become even more interesting since Windows Server 2016 came out, with a base WIM image for standard Server SKU that is over 4GB in size. Hum…

The Hardware

20161126_200856.jpg

I tested on several different USB makes using my Windows 10 (version 1607) laptop. Some would allow me to create a 2nd partition on a removable Flash Drive, others would not giving me an error:

DISKPART> create part pri

No usable free extent could be found. It may be that there is insufficient 
free space to create a partition at the specified size and offset. Specify
different size and offset values or don't specify either to create the maximum 
sized partition. It may be that the disk is partitioned using the MBR disk
partitioning format and the disk contains either 4 primary partitions, (no
more partitions may be created), or 3 primary partitions and one extended
partition, (only logical drives may be created).

Mostly the older and/or cheaper drives didn’t work, but most of the newer and/or name brand drives did work.

Finally I narrowed it down to two different models, both my favorites:

Then I tested against three Operating Systems: Windows 10 Version 1607, Windows 10 Preview, and Windwos 7.0 SP1. All using Diskpart to create multiple partitions.

The script

Diskpart.exe –>

sel disk 1
clean
create part pri size=450
format quick fs=fat32
assign
create part pri
format quick fs=ntfs
assign
exit

The Results:

                                 SanDisk           Transcend
Windows 7 SP1 Build 7601           Pass               Fail
Windows 10  Version 1607           Pass               Fail
Windows 10 Preview 14965           Pass               Pass   

I was able to format my SanDisk into multiple partitions using Windows 7 and beyond.

But I was not able to format the Transcend drive into multiple partitions using Windows 7 or Windows 10 Version 1607, but I was able to partition into multiple partitions on the new Windows 10 Insider Preview 14965.

That’s new!

I haven’t done enough testing using the removable flash drives on older machines, to see if the partitions are still visible, but the results look promising for a start.

Update #1 – 11/28/16:

Found out today that the reason that my SanDisk Extreme disk worked on Windows 7 and Windows 10 1607 may be because the removable Flash disk is reported as “Fixed” rather than “Removable” to the OS. Link.

Update #2 – 11/28/16:

I noticed that when taking the “removable” disk formatted with 2 partitions from Windows 10 Preview 14965 over to Windows 10 Version 1607, only the first partition was visible. As a work around I tried moving the main NTFS partition first and the Fat32 partition second.

sel disk 1
clean
create part pri
shrink desired=450
format quick fs=ntfs
assign
create part pri
format quick fs=fat32
assign
exit

Install Windows 7 in UEFI

I’m here at the Minnesota Management Summit at the Mall of America.

We got some exciting stuff going on here at 1E around Windows 10 and security features like Secure Boot and Device Guard, and I’ve have been digging into the details of BIOS and UEFI.

The big challenge in this space is helping clients and customers who are currently running Windows 7 to upgrade to Windows 10 with Secure Boot, If you rolled the UEFI firmware back to CSM/BIOS mode, then your machine can’t leverage the super cool Windows 10 In-Place Upgrade functionality to upgrade from Windows 7 to Windows 10. Instead, we will need to perform a wipe and reload on the machine. Stay tuned to 1E for more information this week on BIOS to UEFI.

This all happens when you get a machine that supports UEFI and Secure Boot (Say a machine with a Windows 8, Windows 8.1 or Windows 10 Logo), and you want to install Windows 7. Windows 7 can’t work with UEFI and Secure Boot, because Windows 7 isn’t a supported Secure Boot operating System. Windows 7 does support UEFI, however you may have some more problems getting Windows 7 loading in UEFI, so we may need to add some CSM components, in a “Hybrid Mode” to load. For many IT departments, Getting Windows 7 to load with UEFI is hard, so they load in BIOS mode instead.

Moving forwards, We are now have a new recommendation:

“Install new Computers for Windows 7 in UEFI mode without Secure Boot!” [1] [2]

[1] – May require an updated BIOS

[2] – May require CSM “Hybrid Mode” not full BIOS mode.

The advantage here, is that if/when it becomes necessary to migrate to Windows 10 and leverage the security features of Windows 10, all we need to do is run the standard Windows 10 In-place upgrade task sequence for SCCM/OSD or MDT.  Don’t fall into the CSM/BIOS trap!  :^)

OEM Specific settings

Now, honestly, we have had some problems getting Windows 7 running on a pure “UEFI” implementation, instead we have found out that you must enable *some* legacy aspects of CSM, but not the full CSM mode. We call this “UEFI Hybrid” mode, after the name HP gave this mode (see below).

So how would this look on various machines? Well, we can go into the BIOS and change the settings

Dell

  • “LegacyoRom” set to “enable”
  • “ActiveBootList” set to “UEFI”

Lenovo

  • “UEFI/Legacy Boot” set to “Both”
  • “UEFI Priority […]”  = “UEFI First”
  • “CSM Support”  = “YES”

HP

  • “Boot Mode”  = “UEFI Hybrid (with CSM)”

Hopefully this should help you move forwards to Windows 10, yet still deploy Windows 7 for your existing needs.

-k

Fix for Windows 1511 ADK bug

First off, yes, I have a new job working for 1e! I’m super excited, and I should have posted something about it, but I’ve been super busy. My first day on the job was at a customer site in Dallas, and I’ve been on the go ever since, working on this and that (stay tuned :^).

As many of you may have known, there has been a pretty big bug in the Windows 10 Version 1511 ADK, it’s caused all kinds of interop problems with Configuration Manager. Well Microsoft released a fix today! KB3143760. Yea!

Well I opened up KB3143760, and yikes! The instructions are a bit dry. Mount this, patch that, watch out for the data streams!

I needed to patch my local Windows 1511 ADK installation because I’m working on a SCCM+MDT Refresh scenario, and I don’t want to uninstall the 1511 ADK. Perfect timing, if only there was a way to automate this..

Repair-1511ADK.ps1

Here is a link to a PowerShell script I wrote to auto-magically patch your WinPE files!

https://onedrive.live.com/redir?resid=5407B03614346A99!158500&authkey=!AHWArN5C7FyRPIY&ithint=file%2cps1

This script will:

  • Download the patch (no need to go through the E-Mail process)
  • Take care of all the stream issues (really I don’t use IE/Edge, so no security streams)
  • Auto extract the patch contents
  • Mount the wim file
  • Patch the appropriate dat files
  • Fix the permissions
  • Dismounts the WIM
  • Cleans up all left over files

So, for example, if you wanted to patch all of the WinPE Wim files in the ADK directory (before importing them into SCCM), you can run the following command:

get-childitem 'C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\*.wim' -recurse | .\Repair-1511ADK.ps1 -verbose

Lately, when programming in PowerShell, I have taken the “write-host considered harmful” rule to heart, so by default, there is *NO* std console output. Instead, I redirect most information output to “verbose”, so if you want to see what is happening in the background, use the -verbose switch.

-k

Hopefully, moving forwards, this will be the *last* time I place a new script up on OneDrive, really I should be moving towards something more… modern… like GitHub.

MDT package now on Chocolatey.org ready for Windows 10!

Been a while since I posted, I’ve been busy with Surface, Windows 10, and other Kits. But my chocolatey package just got approved, so I thought I would share.

I’ve been following the progress of PowerShell’s OneGet, and http://Chocolatey.org for a while now, and thought it was time to stick my toes in and create a package for public use. MDT seemed like a great start.

As you may already know OneGet is a new feature of PowerShell, included in Windows 10 and available through WMF 5.0 that allows for the installation of packages over the internet. Chocolatey is one of the back-end providers, with a great collection of apps ready for installation.

With the recent release of MDT 2013 Update 2, it seemed like a great opportunity to practice my packaging skills. Eventually I created a PowerShell script to auto generate the chocolatey package (not shown here), it would download the MSI files, and extract out the MSI Product Code and Checksum values. You can see the code generated on the Chocolatey MDT page.

Now to install MDT on Windows 10 (or Windows Server 2016), we can run the commands:

set-executionpolicy RemoteSigned; 
Install-Package -Name MDT -ProviderName Chocolatey `
-ForceBootstrap -Force -Verbose

How it works

First step we need to do on clean machine is to set the execution policy:

set-executionpolicy RemoteSigned

Chocolatey has some PowerShell scripts that run in the background, so we need to allow PowerShell to run these commands with the Set-ExecutionPolicy command. Most Powershell users run this command anyways, so it’s not that uncommon.

Then we install the package using the PowerShell 5.0 “Install-Package” cmdlet built into Windows 10:

Install-Package -Name MDT -ProviderName Chocolatey

We must specify the “-ProviderName Chocolatey” parameter the fist time we call Install-Package so the chocolatey Provider is installed, MDT is only known to Chocolatey at this time.

Install-Package will prompt us to confirm installation of the chocolatey provider, we can skip this with the -ForceBootStrap parameter. Additionally, Install-Package will also ask for confirmation before installing MDT, and we can sip the confirmation with the -Force Paramater.

I like to see what is going on the background, so I add the -verbose parameter, and my screen fills with yellow:

Capture

We can see Install-Package downloading MicrosoftDeploymentToolkit2013_x64.msi from the Microsoft web servers.

ADK

The Windows 10 ADK package has also been uploaded to Chocolatey, but hasn’t been officially approved yet, so when you try to run the “windows-ADK” package it will install the older Windows 8.1 version. We can force the Windows 10 ADK to install with a version parameter. Additionally, the default version of the “Windows-ADK” package does not install USMT, so to install everything we will need the “windows-adk-all” package (which is a lot of stuff, sorry).

install-package -ProviderName Chocolatey -Name Windows-ADK-All `
-force -Verbose -MinimumVersion 10.1.10586.0

More information:

https://chocolatey.org/packages/MDT

-k