Wireless Support WinRE 10 – Part One

It seems that many people need to be able to connect to a wireless network via WinPE. In addition, a large percentage of windows systems nowadays don’t have Ethernet port and many businesses are going “wireless only”. If you browse the Internet, you will find several guides/hacks successfully used to build a WinPE with wireless support. In this blog which has two parts, I will describe the way you can use the Windows 10 WinRE.wim image and an optional component (Feature Pack) called WinPE-WiFi-Package to provide support for adding wireless drivers to WinRE, and the ability to create/deploy images over wireless network connections. In the second part I will provide PowerShell script to automate process of creating WinRE with wireless support.

Windows RE (Recovery Environment) and Optional Components

This page provides the Optional Components Reference: https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufacture/desktop/winpe-add-packages–optional-components-reference

The default Windows RE image contains the following built-in optional components:

•WinPE-StorageWMI-Package (added to the base image in Windows 8.1 and Windows Server 2012 R2)
•WinPE-HTA (added to the base image in Windows 10)

In addition to the list of default ones, here is our hero – WinPE-WiFi-Package

Network/WinPE-WiFi-Package is used by Windows Recovery Environment (Windows RE). This package is included in the base winre.wim file. Note that this package is used by Windows RE only, and you won’t find it in Boot.wim or ADK WinPE.wim, or as an ADK Optional Component.

Windows RE location and Extraction

Windows RE is stored as WinRE.wim file on a device hard drive or SSD in Windows 7, 8/8.1 and 10.  Windows 7 normally saves it on the same partition/volume with Windows, while Windows 8 and 10 usually keep it on the hidden System Reserved partition that also contains boot files and Boot Configuration Data (BCD).

Therefore, the OS Windows 8, Windows 8.1, and Windows 10 will place WinRE.wim in the following locations:
• Single Partition Deployments – WinRE.wim placed on C: drive (Partition 1).
• BIOS with System Partition – WinRE.wim placed on the System Partition (Partition 1).
• UEFI with Recovery Partition – WinRE.wim will be placed on the Recovery Partition (4).
Note that a UEFI system will have an EFI System Partition (1), an MST Partition (2), Windows Partition (3), and Recovery Partition (4).

To get WinRE.wim from a computer installed with Windows OS, look into Windows\System32\Recovery folder, and if you do not see it there (make sure you are viewing Hidden, System OS files) please do the following:
– run command reagentc /info to find out if it is installed and where (and if existent/installed on OS)
– run reagentc /disable to put WinRE.wim back in Windows\System32\Recovery folder so you can copy it, and then run reagentc /enable to put it back.

Picture 01: WinRE.wim file location

To get WinRE.wim from a Microsoft download file, you need to convert an ESD file (the install.esd file is a Windows Electronic Software Download file located in Sources folder) into Install.wim file. The best way to extract WinRE.wim is to create a folder on your C: drive (example C:\ESD) and copy install.esd into this folder. Open Command Prompt as Administrator, get into C:\ESD folder and run the following commands:
– dism /Get-WimInfo /WimFile:install.esd (to get information on the ESD file and find index number that you need; in my example I choose Index 1 because it is a PRO version).









Picture 02: Using DISM to get info about Install.esd

– dism /export-image /SourceImageFile:install.esd /SourceIndex:1 /DestinationImageFile:install.wim /Compress:max /CheckIntegrity

Picture 03: export/convert ESD file into WIM file

Depending on your computer, the command takes from 10-20 minutes to finish. Mount the Install.wim file and copy WinRE.wim from the Windows\System32\Recovery folder. Regardless of the method used to find Winre.wim, please always make sure to use a version of the file compatible with the version and architecture of Windows for which WinRE is being repaired. For example, if you are repairing WinRE on a Windows 8 64-bit system you should use the Windows 8 64-bit Winre.wim file.

Customizing WinRE and Boot Options Menu

You can customize WinRE.wim by adding packages, languages, drivers, and custom diagnostic or troubleshooting tools. Note that the number of packages, languages, and drivers is limited by the amount of memory available on the PC, and Microsoft, for performance reasons, recommends that you minimize the number of languages, drivers, and tools that you add to the WinRE.wim image.

The customizations steps are as follows:

1. Use DISM to mount WinRE.wim (for example C:\mount).
2. Create the \Sources\Recovery\Tools folder in the WinRE mount folder.
3. Create an .xml file called WinREConfig.xml that describes the custom tool in the boot options menu.
4. Launch Notepad.exe and type the following:

For HTA Custom Tool WinREConfig.xml

For PowerShell Custom Tool WinREConfig.xml

Note the access level as Yes/No value. It specifies whether the imaging tool should be restricted to users with administrative privileges only from the Windows RE tools menu. This setting does not affect the Recovery control panel, which always requires administrative privilege.

5. Save the file using UTF-8 coding. Do not use ANSI. Save this file in \Sources\Recovery\Tools folder.
6. Copy the custom tool in the \Sources\Recovery\Tools folder of the mounted Windows RE image.
You can only add one custom tool to the WinRE boot options menus. This tool must have .EXE extension.

HTA Custom Tool

• mshta.exe
• ACBWinPEx64.hta

Powershell Custom Tool

• powershell.exe
• ACB-WinPEx64.ps1

Picture 04: Custom tool and apps in the Sources\Recovery\Tools folder; note that I’ve used ACBWinPEx64.hta and ACB-WinPEx64.ps1 from my blog WinPE 5.0 GUI (http://www.alexcomputerbubble.com/winpe-5-0-gui/).

If you choose to have PowerShell Tool you need to add WinPE-PowerShell Optional Component.

7. Use DISM to add drivers (wireless drivers and other needed drivers)
8. Use DISM to add apps that you will use in your Recovery Environment
9. Create/export wireless profile to be used in your Recovery Environment

netsh wlan export profile name=”WiFi_SID_Name” folder=D:\ key=clear
(This would result in exporting/creating profile saved in file D:\Wi-Fi-Name.xml where D: is the USB drive)

You could use a PowerShell script instead:

function Export-WlanProfile($ProfileFolder){ 
Exports WLAN profiles 
Export-WlanProfile -ProfileFolder C:\WinRE-Wireless\WLAN-Profiles 

 If((Test-Path $ProfileFolder -PathType Container)){
 try {
 $wlanProfileCollection = (netsh wlan show profiles) | 
 Select-String -Pattern "All User Profile" | 
 Foreach-Object {$_.ToString()} 
 $wlanProfileCollection | 
 Foreach-Object {$_.Replace(" All User Profile : ",$null)} 
 $wlanProfileCollection | 
 ForEach-Object {netsh wlan export profile $_ $XmlDirectory key=clear} 
 Write-Warning "Error exporting WLAN profile(s)!"
 Write-Warning "Error: $($_.Exception.Message)"
 [System.Windows.Forms.MessageBox]::Show("Folder does not exist!")
Export-WlanProfile -ProfileFolder C:\WinRE-Wireless\WLAN-Profiles

10. Use DISM to commit your customizations steps and unmount the WinRE image
11. Format you USB drive, make it bootable and add customized WinRE image
12. Once you boot your system into WinRE with wireless support you could use PE Network Manager – http://holger.reboot.pro/ to import profile for wireless network or you could type the following command:

net start wlansvc
netsh wlan add profile filename=D:\Wi-Fi-Name.xml

Microsoft, due to security considerations, recommends that that you disable networking when you don’t need connectivity. By default, networking is disabled in WinRE. You can turn on networking when you need it.


PowerShell – Export ACLs to Excel File

As an Administrator, you have to monitor how folders are being shared in your domain and manage permissions, making sure that your clients have appropriate access to files and directories. You know very well how Windows NT-based systems allows full control over security and file permissions, but there is no a built-in way to quickly view users’ accesses to a tree of directories on your network shared folder.

Running the Export-ACLToExcelFile.ps1 script

The script presented here provides a snapshot of the users/groups in my domain that have access to the Shared folders and exports ACLs and other info into an Excel Report file.

.SYNOPSIS Export-ACLToExcelFile.ps1 collects ACL info and exports result to an Excell File. 
.OUTPUTS One .xlsx file to record all ACLs on specified folder. 
.PARAMETER path (Mandatory) specifies the path to the network folder. 
.PARAMETER permission (Mandatory) specifies the AC Entries to be collected. 
 Export-ACLToExcelFile.ps1 -path \\ServerName\PathToFolderName -permission Default 
 Export-ACLToExcelFile.ps1 -path \\ServerName\PathToFolderName -permission Custom 
.DESCRIPTION Export-ACLToExcelFile.ps1 collects ACL info and exports result to Excell File. 
.NOTES Written by: Alex Dujakovic, Oct 2016 Requires PowerShell Version 3.0 
[Parameter(Mandatory=$True, Position=0)] 
[Parameter(Mandatory=$True, Position=1)] 

As you can see from the portion of the script’s code, it has two mandatory parameters: path and permission and you can run it by typing at the command prompt the following:

Export-ACLToExcelFile.ps1 -path \\ServerName\PathToFolderName -permission Custom

The script outputs an Excel Report file which has two tabs: “ACLs” and “Accounts List”. On the “ACLs” worksheet tab, each row in this report will display the following:  UNC Folder Path, ‘LastWriteTime’ attribute, Owner, Groups and Users, Permissions and the Inheritance property. The picture 1 displays the portion of the Excel Report file for the Z:\Tools folder.

Picture 1: display “ACLs” worksheet tab.

In addition to creating a snapshot for the selected folder, I use the Export-ACLToExcelFile.ps1 script as a tool for detecting the security holes and locking down the permissions. Note the two highlighted accounts in the picture 1, with Modify and Full Control access to the Z:\Tools\Transform\Samples folder; in my domain, I want only the security groups to have/control access to the network folders.

On the second tab, named “Accounts List”, there is a sorted list of the security groups and users found in the access control list (ACL).

aclgroupsandusersPicture 2: displays the list of groups/users accounts that are found in ACLs for the selected folder.

Please note that you do not see entries under Groups/Users as follows:

  • “Everyone”
  • “BUILTIN\Administrators”
  • “NT AUTHORITY\Authenticated Users”
  • “BUILTIN\Users”

The reason for this is the second script’s Parameter/Argument and its value “Custom”. As shown in the code below, I use the switch to list all the entries in ACL (“Default) or filter out entries listed above (“Custom”).


"Custom" {
   Switch ("$([string]$aclEntry.IdentityReference)"){
     "BUILTIN\Administrators" {}
     "Everyone" {}
     "NT AUTHORITY\Authenticated Users" {}
     "BUILTIN\Users" {}
     Default { 
      $intRow = $intRow + 1 
      # Account
      $finalWorkSheet.Cells.Item($intRow,4) = "$([string]$aclEntry.IdentityReference)"
      # Permission 
      $finalWorkSheet.Cells.Item($intRow,5) = "$([string]$aclEntry.FileSystemRights)"
      # Inheritance
        "TRUE"{$finalWorkSheet.Cells.Item($intRow,6) = "$([string]$aclEntry.IsInherited)"}
        "FALSE"{$finalWorkSheet.Cells.Item($intRow,6).Font.ColorIndex = 3
                $finalWorkSheet.Cells.Item($intRow,6) = "$([string]$aclEntry.IsInherited)"}

"Default" {
    $intRow = $intRow + 1 

    # Account
    $finalWorkSheet.Cells.Item($intRow, 4) = "$([string]$aclEntry.IdentityReference)"
    # Permission 
    $finalWorkSheet.Cells.Item($intRow, 5) = "$([string]$aclEntry.FileSystemRights)"
    # Inheritance  
        "TRUE"{$finalWorkSheet.Cells.Item($intRow,6) = "$([string]$aclEntry.IsInherited)"}
        "FALSE"{$finalWorkSheet.Cells.Item($intRow,6).Font.ColorIndex = 3
                $finalWorkSheet.Cells.Item($intRow,6) = "$([string]$aclEntry.IsInherited)"}
    } # End of Switch
   }  # End of foreach ACLs 

Depending on the number of subfolders, this script could run for a very long time and the progress bars are provided for you to follow the progress of a lengthy operation, as shown in the picture 3.

progressbar_aclPicture 3: showing progress bars for folder ACLs and sorting of ACL entries.
This script could be found in the download section – under PowerShell folder. It provides you with a snapshot of the Shared folders’ permissions, giving you a full view of your file system security settings; in addition, it is a solid tool for detecting security holes and locking down permissions where necessary.