Initial docs release
@@ -0,0 +1,69 @@
|
||||
---
|
||||
title: M365 Apps/Office
|
||||
nav_order: 8
|
||||
prev_url: /appsscriptvariables.html
|
||||
prev_label: Apps Script Variables
|
||||
next_url: /drivers.html
|
||||
next_label: Drivers
|
||||
parent: UI Overview
|
||||
---
|
||||
# M365 Apps/Office
|
||||
|
||||

|
||||
|
||||
FFU Builder uses the Office Deployment Toolkit (ODT) to install Office. In the `.\FFUDevelopment\Apps\Office` folder you'll find two files:
|
||||
|
||||
* `DownloadFFU.xml`
|
||||
* `DeployFFU.xml`
|
||||
|
||||
## DownloadFFU.xml
|
||||
|
||||
`DownloadFFU.xml` is responsible for the download of Office. It's invoked by `setup.exe /download .\DownloadFFU.xml` during the build process. It defaults to downloading the current channel 64-bit version of Office matching the current OS language to `C:\FFUDevelopment\Apps\Office`.
|
||||
|
||||
`DownloadFFU.xml` contents:
|
||||
|
||||
```
|
||||
<Configuration ID="efa6df21-a106-428e-8eaa-d89a5dda6030">
|
||||
<Add SourcePath="C:\FFUDevelopment\Apps\Office" OfficeClientEdition="64" Channel="Current">
|
||||
<Product ID="O365ProPlusRetail">
|
||||
<Language ID="MatchOS" />
|
||||
</Product>
|
||||
</Add>
|
||||
</Configuration>
|
||||
```
|
||||
|
||||
If you want to modify the language, you'll need to change the language ID to the language you wish to download and install.
|
||||
|
||||
For more information about deploying languages see: [Overview of deploying languages for Microsoft 365 Apps - Microsoft 365 Apps Microsoft Learn](https://learn.microsoft.com/en-us/microsoft-365-apps/deploy/overview-deploying-languages-microsoft-365-apps)
|
||||
|
||||
## DeployFFU.xml
|
||||
|
||||
`DeployFFU.xml` is responsible for customizing the installation of Office. If you don't provide a custom XML, it will default to using what's in `DeployFFU.xml`. The default configuration will install the 64-bit current channel version of Office with Word, Excel, Powerpoint. Below is what's currently in `DeployFFU.xml`:
|
||||
|
||||
```
|
||||
<Configuration ID="efa6df21-a106-428e-8eaa-d89a5dda6030">
|
||||
<Add OfficeClientEdition="64" Channel="Current">
|
||||
<Product ID="O365ProPlusRetail">
|
||||
<Language ID="MatchOS" />
|
||||
<ExcludeApp ID="Access" />
|
||||
<ExcludeApp ID="Lync" />
|
||||
<ExcludeApp ID="Publisher" />
|
||||
<ExcludeApp ID="Bing" />
|
||||
<ExcludeApp ID="Teams" />
|
||||
<ExcludeApp ID="Outlook" />
|
||||
</Product>
|
||||
</Add>
|
||||
<Property Name="SharedComputerLicensing" Value="0" />
|
||||
<Property Name="FORCEAPPSHUTDOWN" Value="FALSE" />
|
||||
<Property Name="DeviceBasedLicensing" Value="0" />
|
||||
<Property Name="SCLCacheOverride" Value="0" />
|
||||
<Updates Enabled="TRUE" />
|
||||
<Display Level="None" AcceptEULA="TRUE" />
|
||||
</Configuration>
|
||||
```
|
||||
|
||||
## Copy Office Configuration XML
|
||||
|
||||
If you want to include your own custom XML file for office, check **Copy Office Configuration XML** and browse to the location of your custom XML file. The path to your custom Office configuration XML file is stored in the `OfficeConfigXMLFile` parameter. This file gets added to the `.\FFUDevelopment\Apps\Office` folder and is referenced in the `.\FFUDevelopment\Apps\Orchestration\Install-Office.ps1` file.
|
||||
|
||||
{% include page_nav.html %}
|
||||
@@ -0,0 +1,23 @@
|
||||
title: FFU Builder
|
||||
description: Build and deploy Windows FFU images
|
||||
remote_theme: just-the-docs/just-the-docs@v0.10.1
|
||||
plugins:
|
||||
- jekyll-remote-theme
|
||||
- jekyll-seo-tag
|
||||
- jekyll-sitemap
|
||||
|
||||
search_enabled: true
|
||||
|
||||
# Because you’ll publish as a project site at /FFU
|
||||
baseurl: "/FFU"
|
||||
|
||||
callouts:
|
||||
note:
|
||||
title: Note
|
||||
color: purple
|
||||
tip:
|
||||
title: Tip
|
||||
color: green
|
||||
warning:
|
||||
title: Warning
|
||||
color: yellow
|
||||
@@ -0,0 +1,145 @@
|
||||
<!-- docs/_includes/head_custom.html -->
|
||||
<style>
|
||||
/* Layout: remove Just-the-Docs "centered narrow" constraints on wide screens */
|
||||
@media (min-width: 50rem) {
|
||||
.main {
|
||||
max-width: none !important;
|
||||
}
|
||||
}
|
||||
|
||||
@media (min-width: 66.5rem) {
|
||||
.side-bar {
|
||||
width: 16.5rem !important;
|
||||
min-width: 16.5rem !important;
|
||||
}
|
||||
|
||||
.side-bar+.main {
|
||||
margin-left: 16.5rem !important;
|
||||
}
|
||||
}
|
||||
|
||||
/* Readability: wider column + slightly larger, less-thin text */
|
||||
@media (min-width: 66.5rem) {
|
||||
.main-content {
|
||||
max-width: 1100px;
|
||||
}
|
||||
}
|
||||
|
||||
@media (min-width: 90rem) {
|
||||
.main-content {
|
||||
max-width: 1280px;
|
||||
}
|
||||
}
|
||||
|
||||
/* Typography: approximate Microsoft Learn (Segoe UI Variable + regular body + semibold headings) */
|
||||
body,
|
||||
.main-content {
|
||||
font-family: "Segoe UI Variable Text", "Segoe UI Variable", "Segoe UI", system-ui, -apple-system, "Helvetica Neue", Arial, sans-serif;
|
||||
-webkit-font-smoothing: antialiased;
|
||||
-moz-osx-font-smoothing: grayscale;
|
||||
text-rendering: optimizeLegibility;
|
||||
}
|
||||
|
||||
.main-content {
|
||||
margin-right: auto;
|
||||
margin-left: auto;
|
||||
font-size: 1rem;
|
||||
/* 16px-ish, closer to Learn */
|
||||
line-height: 1.6;
|
||||
font-weight: 400;
|
||||
|
||||
/* Just-the-Docs defaults body text to a mid-grey; make it closer to Learn */
|
||||
color: #242424;
|
||||
}
|
||||
|
||||
.main-content p,
|
||||
.main-content li {
|
||||
line-height: 1.65;
|
||||
}
|
||||
|
||||
.main-content h1,
|
||||
.main-content h2,
|
||||
.main-content h3 {
|
||||
font-weight: 600;
|
||||
letter-spacing: -0.01em;
|
||||
}
|
||||
|
||||
.main-content code,
|
||||
.main-content pre code {
|
||||
font-size: 0.95em;
|
||||
}
|
||||
|
||||
/* Images: make it obvious they're zoomable (opt-out via class="no-zoom") */
|
||||
.main-content img:not(.no-zoom) {
|
||||
cursor: zoom-in;
|
||||
}
|
||||
|
||||
/* Right-side page TOC (desktop only) */
|
||||
@media (min-width: 66.5rem) {
|
||||
.main-content-wrap.has-page-toc {
|
||||
display: grid;
|
||||
grid-template-columns: minmax(0, 1fr) 16rem;
|
||||
column-gap: 2rem;
|
||||
align-items: start;
|
||||
}
|
||||
|
||||
.main-content-wrap.has-page-toc .main-content {
|
||||
grid-column: 1;
|
||||
}
|
||||
|
||||
.page-toc {
|
||||
grid-column: 2;
|
||||
position: sticky;
|
||||
top: 5.5rem;
|
||||
max-height: calc(100vh - 6.5rem);
|
||||
overflow: auto;
|
||||
padding-left: 1rem;
|
||||
border-left: 1px solid #eeebee;
|
||||
font-size: 0.875rem;
|
||||
}
|
||||
|
||||
.page-toc__title {
|
||||
font-weight: 600;
|
||||
color: #27262b;
|
||||
margin-bottom: 0.75rem;
|
||||
}
|
||||
|
||||
.page-toc__list {
|
||||
list-style: none;
|
||||
padding-left: 0;
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
.page-toc__item {
|
||||
margin: 0.4rem 0;
|
||||
}
|
||||
|
||||
.page-toc__item--h3 {
|
||||
padding-left: 0.75rem;
|
||||
}
|
||||
|
||||
.page-toc__link {
|
||||
color: inherit;
|
||||
text-decoration: none;
|
||||
display: block;
|
||||
padding: 0.125rem 0 0.125rem 0.75rem;
|
||||
border-left: 3px solid transparent;
|
||||
}
|
||||
|
||||
.page-toc__link:hover {
|
||||
text-decoration: underline;
|
||||
}
|
||||
|
||||
.page-toc__link.is-active {
|
||||
font-weight: 600;
|
||||
color: #1a1a1a;
|
||||
border-left-color: #2563eb;
|
||||
}
|
||||
}
|
||||
</style>
|
||||
|
||||
<meta name="ffu-right-toc" content="{% if page.right_toc == false %}false{% else %}true{% endif %}">
|
||||
|
||||
<script src="{{ '/assets/js/vendor/medium-zoom.min.js' | relative_url }}" defer></script>
|
||||
<script src="{{ '/assets/js/image-zoom.js' | relative_url }}" defer></script>
|
||||
<script src="{{ '/assets/js/page-toc.js' | relative_url }}" defer></script>
|
||||
@@ -0,0 +1,17 @@
|
||||
<!-- docs/_includes/page_nav.html -->
|
||||
<div class="d-flex flex-justify-between mt-6">
|
||||
{% assign prev_url = include.prev_url | default: page.prev_url %}
|
||||
{% assign prev_label = include.prev_label| default: page.prev_label | default: 'Home' %}
|
||||
{% assign next_url = include.next_url | default: page.next_url %}
|
||||
{% assign next_label = include.next_label| default: page.next_label | default: 'Next' %}
|
||||
|
||||
{% if prev_url %}
|
||||
<a class="btn btn-outline" href="{{ prev_url | relative_url }}">← {{ prev_label }}</a>
|
||||
{% else %}
|
||||
<span></span>
|
||||
{% endif %}
|
||||
|
||||
{% if next_url %}
|
||||
<a class="btn btn-blue" href="{{ next_url | relative_url }}">{{ next_label }} →</a>
|
||||
{% endif %}
|
||||
</div>
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: Applications
|
||||
nav_order: 4
|
||||
prev_url: /updates.html
|
||||
prev_label: Updates
|
||||
next_url: /winget.html
|
||||
next_label: Install Winget Applications
|
||||
parent: UI Overview
|
||||
has_toc: false
|
||||
---
|
||||
# Applications
|
||||
|
||||

|
||||
|
||||
Applications can be installed in three different ways:
|
||||
|
||||
* Winget (using an AppList.json file)
|
||||
* Bring Your Own Applications (using files you provide - can also be used to run command lines with or without content)
|
||||
* Apps Script Variables (key/value pairs used in conjunction with a PowerShell script to install custom applications)
|
||||
|
||||
{% include page_nav.html %}
|
||||
@@ -0,0 +1,138 @@
|
||||
---
|
||||
title: Apps Script Variables
|
||||
nav_order: 7
|
||||
prev_url: /byoapps.html
|
||||
prev_label: BYO Applications
|
||||
next_url: /M365appsoffice.html
|
||||
next_label: M365 Apps Office
|
||||
parent: Applications
|
||||
grand_parent: UI Overview
|
||||
---
|
||||
# Apps Script Variables
|
||||
|
||||

|
||||
|
||||
Apps Script Variables are key value pairs that are used to create a hashtable that is passed to the `BuildFFUVM.ps1` script (stored in the `$AppScriptVariables` parameter as a hashtable). At build time, `BuildFFUVM.ps1` will export the `$AppsScriptVariables` hashtable to an `AppsScriptVariables.json` file in the `$OrchestrationPath` folder (`$AppsPath\Orchestration`). You can also manually create your own `AppsScriptVariables.json `file and place it in the `$AppsPath\Orchestration` folder.
|
||||
|
||||
In the VM, the `Orchestrator.ps1` file will call `Invoke-AppsScript.ps1` if `AppsScriptVariables.json` exists. `Invoke-AppsScript.ps1` must be modified to handle your variables.
|
||||
|
||||
`Invoke-AppsScript.ps1` has the following commented example of how to modify the file:
|
||||
|
||||
```
|
||||
# Example of how to use the AppsScriptVariables hashtable to control script execution
|
||||
|
||||
# Note: The UI saves the values as strings, so if you type true for a value, it'll save to the config file as a string, not boolean
|
||||
|
||||
# Example: Check if a variable named 'foo' is set to string 'bar' and run a script accordingly
|
||||
# if ($AppsScriptVariables['foo'] -eq 'bar') {
|
||||
# Write-Host "Foo would have installed"
|
||||
# }
|
||||
# else {
|
||||
# Write-Host "Foo would not have installed"
|
||||
# }
|
||||
|
||||
# Example: Check if a variable named 'Teams' is set to string 'true' and run a script accordingly
|
||||
# if ($AppsScriptVariables['Teams'] -eq 'true') {
|
||||
# Write-Host "Teams would have been installed"
|
||||
# }
|
||||
# else {
|
||||
# Write-Host "Teams would not have been installed"
|
||||
# }
|
||||
```
|
||||
|
||||
## Why use Apps Script Variables?
|
||||
|
||||
This allows for you to create a dynamic task sequence via a PowerShell script with simple if statements to run apps, commands, etc. This is all driven by your `FFUConfig.json` file. For example, the following `FFUConfig.json` file contains an AppsScriptVariables hashtable of foo and vmwaretools like the screenshot above. If you build servers that require vmware tools, you may set the value to true. However there may be situations where you don't need vmwaretools installed. If that's the case, you set vmwaretools to false. This allows for your `Invoke-AppsScript.ps1` file to stay the same and all you have to do is adjust the variables.
|
||||
|
||||
```
|
||||
{
|
||||
"AdditionalFFUFiles": [],
|
||||
"AllowExternalHardDiskMedia": false,
|
||||
"AllowVHDXCaching": false,
|
||||
"AppListPath": "C:\\FFUDevelopment\\Apps\\AppList.json",
|
||||
"AppsPath": "C:\\FFUDevelopment\\Apps",
|
||||
"AppsScriptVariables": {
|
||||
"foo": "bar",
|
||||
"vmwaretools": "true"
|
||||
},
|
||||
"BuildUSBDrive": false,
|
||||
"CleanupAppsISO": true,
|
||||
"CleanupCaptureISO": true,
|
||||
"CleanupDeployISO": true,
|
||||
"CleanupDrivers": false,
|
||||
"CompactOS": true,
|
||||
"CompressDownloadedDriversToWim": false,
|
||||
"CopyAdditionalFFUFiles": false,
|
||||
"CopyAutopilot": false,
|
||||
"CopyDrivers": false,
|
||||
"CopyOfficeConfigXML": false,
|
||||
"CopyPEDrivers": false,
|
||||
"CopyPPKG": false,
|
||||
"CopyUnattend": false,
|
||||
"CreateCaptureMedia": true,
|
||||
"CreateDeploymentMedia": true,
|
||||
"CustomFFUNameTemplate": "{WindowsRelease}_{WindowsVersion}_{SKU}_{yyyy}-{MM}-{dd}_{HH}{mm}",
|
||||
"Disksize": 53687091200,
|
||||
"DownloadDrivers": false,
|
||||
"DriversFolder": "C:\\FFUDevelopment\\Drivers",
|
||||
"DriversJsonPath": "C:\\FFUDevelopment\\Drivers\\Drivers.json",
|
||||
"FFUCaptureLocation": "C:\\FFUDevelopment\\FFU",
|
||||
"FFUDevelopmentPath": "C:\\FFUDevelopment",
|
||||
"FFUPrefix": "_FFU",
|
||||
"InjectUnattend": false,
|
||||
"InstallApps": true,
|
||||
"InstallDrivers": false,
|
||||
"InstallOffice": false,
|
||||
"InstallWingetApps": false,
|
||||
"ISOPath": "",
|
||||
"LogicalSectorSizeBytes": 512,
|
||||
"MaxUSBDrives": 5,
|
||||
"MediaType": "Consumer",
|
||||
"Memory": 4294967296,
|
||||
"OfficeConfigXMLFile": "",
|
||||
"OfficePath": "C:\\FFUDevelopment\\Apps\\Office",
|
||||
"Optimize": true,
|
||||
"OptionalFeatures": "",
|
||||
"OrchestrationPath": "C:\\FFUDevelopment\\Apps\\Orchestration",
|
||||
"PEDriversFolder": "C:\\FFUDevelopment\\PEDrivers",
|
||||
"Processors": 4,
|
||||
"ProductKey": "",
|
||||
"PromptExternalHardDiskMedia": true,
|
||||
"RemoveApps": false,
|
||||
"RemoveFFU": false,
|
||||
"RemoveUpdates": false,
|
||||
"ShareName": "FFUCaptureShare",
|
||||
"Threads": 5,
|
||||
"UpdateADK": true,
|
||||
"UpdateEdge": true,
|
||||
"UpdateLatestCU": true,
|
||||
"UpdateLatestDefender": true,
|
||||
"UpdateLatestMicrocode": false,
|
||||
"UpdateLatestMSRT": true,
|
||||
"UpdateLatestNet": true,
|
||||
"UpdateOneDrive": true,
|
||||
"UpdatePreviewCU": false,
|
||||
"USBDriveList": {},
|
||||
"UseDriversAsPEDrivers": false,
|
||||
"UserAppListPath": "C:\\FFUDevelopment\\Apps\\UserAppList.json",
|
||||
"Username": "ffu_user",
|
||||
"Verbose": false,
|
||||
"VMHostIPAddress": "192.168.1.169",
|
||||
"VMLocation": "C:\\FFUDevelopment\\VM",
|
||||
"VMSwitchName": "External",
|
||||
"WindowsArch": "x64",
|
||||
"WindowsLang": "en-us",
|
||||
"WindowsRelease": 11,
|
||||
"WindowsSKU": "Pro",
|
||||
"WindowsVersion": "25H2"
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
Example command line to run with vmwaretools set to false and foo set to foo. This will create the `AppsScriptVariables.json` file in the Orchestration folder with the updated values of `foo=foo` and `vmwaretools=false` without the need to modify the config file.
|
||||
|
||||
`.\BuildFFUVM.ps1 -configFile 'C:\FFUDevelopment\config\FFUConfig.json' -appsScriptVariables @{foo='foo'; vmwaretools='false'}`
|
||||
|
||||
|
||||
|
||||
{% include page_nav.html %}
|
||||
@@ -0,0 +1,22 @@
|
||||
(function () {
|
||||
'use strict';
|
||||
|
||||
function InitImageZoom() {
|
||||
if (window.mediumZoom === undefined) {
|
||||
return;
|
||||
}
|
||||
|
||||
window.mediumZoom('.main-content img:not(.no-zoom):not([src$=".svg"])', {
|
||||
margin: 24,
|
||||
background: 'rgba(0,0,0,0.80)',
|
||||
scrollOffset: 0
|
||||
});
|
||||
}
|
||||
|
||||
if (document.readyState === 'loading') {
|
||||
document.addEventListener('DOMContentLoaded', InitImageZoom);
|
||||
return;
|
||||
}
|
||||
|
||||
InitImageZoom();
|
||||
})();
|
||||
@@ -0,0 +1,258 @@
|
||||
(function () {
|
||||
'use strict';
|
||||
|
||||
function IsRightTocEnabled() {
|
||||
var meta = document.querySelector('meta[name="ffu-right-toc"]');
|
||||
if (meta && meta.content && meta.content.toLowerCase() === 'false') {
|
||||
return false;
|
||||
}
|
||||
|
||||
return true;
|
||||
}
|
||||
|
||||
function GetHeadings(container) {
|
||||
var headings = container.querySelectorAll('h2, h3');
|
||||
var results = [];
|
||||
|
||||
for (var i = 0; i < headings.length; i++) {
|
||||
var heading = headings[i];
|
||||
|
||||
if (heading.classList.contains('no_toc')) {
|
||||
continue;
|
||||
}
|
||||
|
||||
var id = heading.getAttribute('id');
|
||||
if (!id) {
|
||||
continue;
|
||||
}
|
||||
|
||||
var text = (heading.textContent || '').trim();
|
||||
if (!text) {
|
||||
continue;
|
||||
}
|
||||
|
||||
results.push({
|
||||
level: heading.tagName.toLowerCase(),
|
||||
id: id,
|
||||
text: text
|
||||
});
|
||||
}
|
||||
|
||||
return results;
|
||||
}
|
||||
|
||||
function BuildToc(headings) {
|
||||
var nav = document.createElement('nav');
|
||||
nav.className = 'page-toc';
|
||||
nav.setAttribute('aria-label', 'On this page');
|
||||
|
||||
var title = document.createElement('div');
|
||||
title.className = 'page-toc__title';
|
||||
title.textContent = 'In this article';
|
||||
nav.appendChild(title);
|
||||
|
||||
var list = document.createElement('ul');
|
||||
list.className = 'page-toc__list';
|
||||
|
||||
for (var i = 0; i < headings.length; i++) {
|
||||
var item = headings[i];
|
||||
|
||||
var li = document.createElement('li');
|
||||
li.className = 'page-toc__item page-toc__item--' + item.level;
|
||||
|
||||
var a = document.createElement('a');
|
||||
a.className = 'page-toc__link';
|
||||
a.href = '#' + item.id;
|
||||
a.textContent = item.text;
|
||||
|
||||
li.appendChild(a);
|
||||
list.appendChild(li);
|
||||
}
|
||||
|
||||
nav.appendChild(list);
|
||||
return nav;
|
||||
}
|
||||
|
||||
function SetActiveTocLink(toc, activeId) {
|
||||
if (!toc) {
|
||||
return;
|
||||
}
|
||||
|
||||
var links = toc.querySelectorAll('.page-toc__link');
|
||||
for (var i = 0; i < links.length; i++) {
|
||||
var link = links[i];
|
||||
var href = link.getAttribute('href') || '';
|
||||
var isActive = ('#' + activeId) === href;
|
||||
|
||||
if (isActive) {
|
||||
link.classList.add('is-active');
|
||||
|
||||
/* Keep the active item visible inside the TOC panel */
|
||||
try {
|
||||
link.scrollIntoView({ block: 'nearest' });
|
||||
} catch (e) {
|
||||
link.scrollIntoView();
|
||||
}
|
||||
} else {
|
||||
link.classList.remove('is-active');
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
function SetupScrollSpy(main, toc, headings) {
|
||||
if (!main || !toc || !headings || headings.length < 1) {
|
||||
return;
|
||||
}
|
||||
|
||||
var headingElements = [];
|
||||
for (var i = 0; i < headings.length; i++) {
|
||||
var el = document.getElementById(headings[i].id);
|
||||
if (el) {
|
||||
headingElements.push(el);
|
||||
}
|
||||
}
|
||||
|
||||
if (headingElements.length < 1) {
|
||||
return;
|
||||
}
|
||||
|
||||
var activeId = null;
|
||||
var ticking = false;
|
||||
var lockActiveUntilMs = 0;
|
||||
|
||||
function IsNearBottomOfPage() {
|
||||
var thresholdPx = 24;
|
||||
var scrollY = window.scrollY || window.pageYOffset || 0;
|
||||
var viewportBottom = scrollY + window.innerHeight;
|
||||
var pageHeight = Math.max(document.documentElement.scrollHeight, document.body.scrollHeight);
|
||||
|
||||
return viewportBottom >= (pageHeight - thresholdPx);
|
||||
}
|
||||
|
||||
function GetCurrentHeadingId() {
|
||||
/* If we're at the bottom, force the last heading active (Learn-like behavior) */
|
||||
if (IsNearBottomOfPage()) {
|
||||
return headingElements[headingElements.length - 1].getAttribute('id');
|
||||
}
|
||||
|
||||
/* Choose the heading closest to the top "activation line" */
|
||||
var activationLine = 16;
|
||||
var current = null;
|
||||
|
||||
for (var i = 0; i < headingElements.length; i++) {
|
||||
var rectTop = headingElements[i].getBoundingClientRect().top;
|
||||
|
||||
if (rectTop <= activationLine) {
|
||||
current = headingElements[i];
|
||||
continue;
|
||||
}
|
||||
|
||||
if (null === current) {
|
||||
current = headingElements[i];
|
||||
}
|
||||
|
||||
break;
|
||||
}
|
||||
|
||||
if (null === current) {
|
||||
current = headingElements[0];
|
||||
}
|
||||
|
||||
return current.getAttribute('id');
|
||||
}
|
||||
|
||||
function Update() {
|
||||
ticking = false;
|
||||
|
||||
if (Date.now() < lockActiveUntilMs) {
|
||||
return;
|
||||
}
|
||||
|
||||
var currentId = GetCurrentHeadingId();
|
||||
if (!currentId || currentId === activeId) {
|
||||
return;
|
||||
}
|
||||
|
||||
activeId = currentId;
|
||||
SetActiveTocLink(toc, activeId);
|
||||
}
|
||||
|
||||
function OnScrollOrResize() {
|
||||
if (ticking) {
|
||||
return;
|
||||
}
|
||||
|
||||
ticking = true;
|
||||
window.requestAnimationFrame(Update);
|
||||
}
|
||||
|
||||
window.addEventListener('scroll', OnScrollOrResize, { passive: true });
|
||||
window.addEventListener('resize', OnScrollOrResize);
|
||||
|
||||
/* Update immediately and also when clicking TOC links */
|
||||
toc.addEventListener('click', function (evt) {
|
||||
var target = evt.target;
|
||||
if (!target || !target.classList || !target.classList.contains('page-toc__link')) {
|
||||
return;
|
||||
}
|
||||
|
||||
var href = target.getAttribute('href') || '';
|
||||
if (href.charAt(0) !== '#') {
|
||||
return;
|
||||
}
|
||||
|
||||
var id = href.substring(1);
|
||||
if (!id) {
|
||||
return;
|
||||
}
|
||||
|
||||
/* Prevent scrollspy from immediately overriding the clicked section */
|
||||
lockActiveUntilMs = Date.now() + 800;
|
||||
|
||||
activeId = id;
|
||||
SetActiveTocLink(toc, activeId);
|
||||
});
|
||||
|
||||
Update();
|
||||
}
|
||||
|
||||
function InitRightToc() {
|
||||
if (!IsRightTocEnabled()) {
|
||||
return;
|
||||
}
|
||||
|
||||
var main = document.querySelector('.main-content main');
|
||||
if (!main) {
|
||||
return;
|
||||
}
|
||||
|
||||
var headings = GetHeadings(main);
|
||||
if (headings.length < 2) {
|
||||
return;
|
||||
}
|
||||
|
||||
var wrap = document.querySelector('.main-content-wrap');
|
||||
var content = document.querySelector('.main-content');
|
||||
if (!wrap || !content) {
|
||||
return;
|
||||
}
|
||||
|
||||
if (wrap.querySelector('.page-toc')) {
|
||||
return;
|
||||
}
|
||||
|
||||
wrap.classList.add('has-page-toc');
|
||||
|
||||
var toc = BuildToc(headings);
|
||||
wrap.appendChild(toc);
|
||||
|
||||
SetupScrollSpy(main, toc, headings);
|
||||
}
|
||||
|
||||
if (document.readyState === 'loading') {
|
||||
document.addEventListener('DOMContentLoaded', InitRightToc);
|
||||
return;
|
||||
}
|
||||
|
||||
InitRightToc();
|
||||
})();
|
||||
@@ -0,0 +1,822 @@
|
||||
---
|
||||
title: Build
|
||||
nav_order: 9
|
||||
prev_url: /drivers.html
|
||||
prev_label: Drivers
|
||||
next_url: /monitor.html
|
||||
next_label: Monitor
|
||||
parent: UI Overview
|
||||
---
|
||||
# Build
|
||||
|
||||

|
||||
|
||||
The Build tab is where the magic happens
|
||||
|
||||
## FFU Development Path
|
||||
|
||||
The FFU Development path (`$FFUDevelopmentPath`) is the root path of where most other paths are derived. The default is `$PSScriptRoot`, which is the location the script is currently running from and can be changed to another location from within the UI.
|
||||
|
||||
If you want to download and test new releases, or want to create a new FFUDevelopment folder without modifying your existing one, you can always download the source files and put them in another location.
|
||||
|
||||
The recommendation is to run from `C:\FFUDevelopment` and in most cases the path shouldn't need to be changed.
|
||||
|
||||
## Custom FFU Name Template
|
||||
|
||||
Controls the `-CustomFFUNameTemplate` parameter. This allows you to define a custom naming convention for the captured FFU file using placeholders that are replaced at build time.
|
||||
|
||||
If left blank, the default FFU naming convention is used.
|
||||
|
||||
### Available Placeholders
|
||||
|
||||
| Placeholder | Description | Example |
|
||||
| -------------------- | ---------------------- | ------------------------------------------------------------------------------ |
|
||||
| `{WindowsRelease}` | Windows release number | `10`, `11`, `2016`, `2019`, `2022`, `2025` |
|
||||
| `{WindowsVersion}` | Windows version | `1607`, `1809`, `21h2`, `22h2`, `23h2`, `24h2` |
|
||||
| `{SKU}` | Windows edition | `Home`, `Pro`, `Enterprise`, `Education`, `Standard`, `Datacenter` |
|
||||
| `{BuildDate}` | Month and year | `Nov2025` |
|
||||
| `{yyyy}` | 4-digit year | `2025` |
|
||||
| `{MM}` | 2-digit month | `11` (for November) |
|
||||
| `{dd}` | 2-digit day | `28` |
|
||||
| `{HH}` | Hour in 24-hour format | `14` (for 2 PM) |
|
||||
| `{hh}` | Hour in 12-hour format | `02` (for 2 PM) |
|
||||
| `{mm}` | 2-digit minute | `09` |
|
||||
| `{tt}` | AM/PM designator | `AM` or `PM` |
|
||||
|
||||
### Examples
|
||||
|
||||
**Basic template with date and time:**
|
||||
|
||||
```
|
||||
{WindowsRelease}_{WindowsVersion}_{SKU}_{yyyy}-{MM}-{dd}_{HH}{mm}
|
||||
```
|
||||
|
||||
Result: `Win11_24h2_Pro_2025-11-28_1425.ffu`
|
||||
|
||||
**Template with static text (e.g., indicating Office is installed):**
|
||||
|
||||
```
|
||||
{WindowsRelease}_{WindowsVersion}_{SKU}_Office_{yyyy}-{MM}-{dd}_{HH}{mm}
|
||||
```
|
||||
|
||||
Result: `Win11_24h2_Pro_Office_2025-11-28_1425.ffu`
|
||||
|
||||
**Simple template with build date:**
|
||||
|
||||
```
|
||||
{WindowsRelease}_{WindowsVersion}_{SKU}_{BuildDate}
|
||||
```
|
||||
|
||||
Result: `Win11_24h2_Pro_Nov2025.ffu`
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> The `.ffu` extension is automatically appended if not included in the template.
|
||||
|
||||
## FFU Capture Location
|
||||
|
||||
The FFU Capture Location sets the `-FFUCaptureLocation` parameter that determines where completed `.ffu` images are written. By default it points to `$FFUDevelopmentPath\FFU`, and the build script creates the folder automatically if it does not already exist.
|
||||
|
||||
When apps are installed in a VM, the host converts this folder into a temporary SMB share using the **Share Name** and **Username** fields. The capture WinPE environment maps that share as drive `W:` and streams the captured image directly into this folder. When the build finishes, the share and local account are removed, but the FFU files remain unless a cleanup option deletes them.
|
||||
|
||||
Choose a path on fast storage with plenty of free space—the directory must be local to the host running `BuildFFUVM.ps1`, and large captures can easily exceed 25–30 GB. This location also feeds other options such as **Copy Additional FFU Files**, **Build USB Drive**, and **Remove FFU**, so keeping all finished images here keeps those workflows simple.
|
||||
|
||||
## Share Name
|
||||
|
||||
The Share Name sets the `-ShareName` parameter that defines the name of the temporary SMB share created during the FFU capture process. The default is `FFUCaptureShare`.
|
||||
|
||||
During the build, the host creates an SMB share that points to the **FFU Capture Location** and grants access to the temporary local user account defined in **Username**. The capture WinPE environment maps this share as drive `W:` using `net use` and streams the captured FFU image directly to it.
|
||||
|
||||
When the build completes, the share is automatically removed along with the temporary user account, leaving only the captured FFU files behind in the FFU Capture Location.
|
||||
|
||||
## Username
|
||||
|
||||
The Username field sets the `-Username` parameter that `BuildFFUVM.ps1` uses when creating the temporary SMB share user. The value becomes a local standard user account that is granted Full Control on the **FFU Capture Location** share (default C:\FFUDevelopment\FFU) so the capture WinPE session can copy the FFU over `net use `. The default `ffu_user` account name works for most scenarios, but you can supply any other local account name that meets your organization's policies.
|
||||
|
||||
When the build starts, the script ensures the account exists, rotates its password to a randomly generated GUID, and grants it access to the share. The Capture WinPE environment maps drive `W:` with those credentials, then writes the captured image directly into the FFU Capture Location.
|
||||
|
||||
After the build finishes, the share is removed and the temporary account is deleted, leaving only the FFU files stored in the capture folder.
|
||||
|
||||
## Threads
|
||||
|
||||
Controls the `-Threads` parameter, which sets the number of parallel threads used for concurrent operations throughout FFU Builder. The default value is **5**.
|
||||
|
||||
### Operations Affected by Threads
|
||||
|
||||
The Threads value applies to the following parallel operations:
|
||||
|
||||
| Operation | Description |
|
||||
| -------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
|
||||
| **Winget Application Downloads** | When downloading multiple Winget applications, each application download runs as a parallel task |
|
||||
| **BYO Application Copy** | When copying multiple Bring Your Own (BYO) applications to the Apps folder, each copy operation runs in parallel |
|
||||
| **Driver Downloads** | When downloading drivers for multiple device models, each driver download and extraction runs as a parallel task |
|
||||
|
||||
### Recommended Values
|
||||
|
||||
| Threads | Use Case |
|
||||
| -------------- | ------------------------------------------------------------------------- |
|
||||
| **1** | Minimal system impact; useful for troubleshooting or low-resource systems |
|
||||
| **5** | Default; balanced performance for most systems |
|
||||
| **8-10** | Higher concurrency for systems with fast storage and network connections |
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> Setting a higher thread count may improve download times but will increase resource utilization. If you experience stability issues or resource constraints, try reducing the thread count.
|
||||
|
||||
### Validation
|
||||
|
||||
The UI validates that the Threads value is a valid integer greater than or equal to 1. If an invalid value is entered, it automatically resets to **1**.
|
||||
|
||||
## BITS Priority
|
||||
|
||||
Controls the `-BitsPriority` parameter, which determines the priority level for Background Intelligent Transfer Service (BITS) downloads. The default value is **Normal**.
|
||||
|
||||
If you want faster downloads, change the priority to Foreground. Normal priority will significantly slow down downloads since BITS treats non-Foreground downloads as synchronous and queues each download. This means multiple driver or winget application downloads will go much slower than using Foreground. Normal is default as per Microsoft best practice guidance for using BITS.
|
||||
|
||||
## Build USB Drive
|
||||
|
||||
The following sub-options control how the USB drive is created
|
||||
|
||||
### Allow External Hard Disk Media
|
||||
|
||||
Controls the `-AllowExternalHardDiskMedia` parameter. When checked, allows the use of drives identified as "External hard disk media" via the WMI class `Win32_DiskDrive`. The default is **unchecked**.
|
||||
|
||||
Most USB thumb drives are identified by Windows as "Removable Media" and work with the default settings. However, faster USB drives—such as portable SSDs or high-speed USB 3.x drives—may be identified as "External hard disk media" instead. If you want to use these faster drives for imaging, enable this option.
|
||||
|
||||
{: .warning-title}
|
||||
|
||||
> Warning
|
||||
>
|
||||
> Enabling this option may expose external hard drives attached to your machine to the USB imaging process. To prevent accidental data loss, use the **Prompt for External Hard Disk Media** option (enabled by default when this option is checked) to confirm which drive to use before formatting.
|
||||
|
||||
### Prompt for External Hard Disk Media
|
||||
|
||||
Controls the `-PromptExternalHardDiskMedia` parameter. When checked, prompts for user confirmation before using any drive identified as "External hard disk media". The default is **checked** when **Allow External Hard Disk Media** is enabled.
|
||||
|
||||
This option is only available when **Allow External Hard Disk Media** is checked.
|
||||
|
||||
When enabled, the build process will:
|
||||
|
||||
1. Display a table listing all detected external hard disk media drives, including drive name, serial number, partition style, and status.
|
||||
2. Prompt you to select which drive to use for imaging.
|
||||
3. Only create a USB drive on the selected drive.
|
||||
|
||||
When disabled, the script will not prompt and can use multiple external hard disk drives simultaneously, similar to how removable USB drives function. This is useful for automated or batch imaging scenarios but increases the risk of accidental data loss.
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> If you do not want to be prompted each time, you can disable this option after verifying that only your intended imaging drives are connected.
|
||||
|
||||
### Select Specific USB Drives
|
||||
|
||||
When checked, enables manual selection of specific USB drives for imaging. The default is **unchecked**.
|
||||
|
||||
This option is only available when **Build USB Drive** is checked.
|
||||
|
||||
When enabled, a **Check USB drives** button and a list view appear. Click **Check USB drives** to scan for connected USB drives. The list displays all detected drives with the following information:
|
||||
|
||||
| Column | Description |
|
||||
| ------------------- | ----------------------------------------------------- |
|
||||
| **Select** | Checkbox to include or exclude the drive from imaging |
|
||||
| **Model** | The model name of the USB drive |
|
||||
| **Unique ID** | A unique identifier for the drive |
|
||||
| **Size (GB)** | The total capacity of the drive in gigabytes |
|
||||
|
||||
Select one or more drives by checking the checkbox in the **Select** column. Only selected drives will be formatted and used for imaging when the build completes.
|
||||
|
||||
Use the **Select All** checkbox in the column header to quickly select or deselect all drives.
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> If **Select Specific USB Drives** is unchecked, the build process will automatically use all discovered USB drives.
|
||||
|
||||
### Copy Autopilot Profile
|
||||
|
||||
Controls the `-CopyAutopilot` parameter. When checked, copies the contents of the `.\FFUDevelopment\Autopilot` folder to the `Autopilot` folder on the Deployment partition of the USB drive. The default is **unchecked**.
|
||||
|
||||
This option is only available when **Build USB Drive** is checked.
|
||||
|
||||
This leverages the Autopilot for existing devices json file. It's not recommended to use this method any longer as devices enrolled via this method are enrolled as personal instead of corporate.
|
||||
|
||||
### Copy Unattend.xml
|
||||
|
||||
Controls the `-CopyUnattend` parameter. When checked, copies the architecture-appropriate unattend XML file from `.\FFUDevelopment\Unattend` to an `Unattend` folder on the Deployment partition of the USB drive. The default is **unchecked**.
|
||||
|
||||
This option is only available when **Build USB Drive** is checked.
|
||||
|
||||
When enabled, the build process copies:
|
||||
|
||||
- **unattend_x64.xml** (for x64 builds) or **unattend_arm64.xml** (for arm64 builds) → renamed to **Unattend.xml** on the USB drive
|
||||
- **prefixes.txt** (if present) → copied alongside the unattend file
|
||||
|
||||
During deployment, `ApplyFFU.ps1` detects the `Unattend` folder and uses these files to customize the device name and apply other Windows settings during OOBE.
|
||||
|
||||
#### Device Naming
|
||||
|
||||
Device naming can be done from PE. The way this works is by leveraging an unattend.xml file to either take input from the user at imaging time or read a list of prefix values and append the serial number of the device. There are some major benefits to doing this:
|
||||
|
||||
1. Total deployment time is reduced if naming is set at FFU deployment time since there is no additional reboot done during OOBE.
|
||||
2. Reduces the need for multiple provisioning packages or autopilot profiles. This means you can use a single PPKG or autopilot profile.
|
||||
|
||||
#### Prompt for Device Name
|
||||
|
||||
If you want to be prompted for the device name, simply check **Copy Unattend.xml.** This tells the build script to copy the appropriate architecture unattend_arch.xml file from the `C:\FFUDevelopment\Unattend` folder to the `.\unattend` folder on the deploy partition of the USB drive.
|
||||
|
||||
#### Device Naming with prefixes.txt
|
||||
|
||||
If a `prefixes.txt` file exists in the `Unattend` folder and there are multiple prefixes in the file, the deployment script prompts the technician to select a prefix from the file. The prefix is combined with the device's serial number to create the computer name. If there is a single prefix, the technician is not prompted and the script will automatically select that prefix.
|
||||
|
||||
For example, with a prefix of `CORP-` and a serial number of `ABC123`, the resulting computer name would be `CORP-ABC123` (truncated to 15 characters if necessary).
|
||||
|
||||
Sample `prefixes.txt` content:
|
||||
|
||||
```plaintext
|
||||
CORP-
|
||||
STORE-
|
||||
KIOSK-
|
||||
```
|
||||
|
||||
{: .warning-title}
|
||||
|
||||
> Warning
|
||||
>
|
||||
> If using a provisioning package or autopilot json file, DO NOT specify a name in either of these. They will overwrite the name you have specified in the unattend.xml.
|
||||
|
||||
#### Creating Your Unattend Files
|
||||
|
||||
The `.\FFUDevelopment\Unattend` folder includes sample files you can customize:
|
||||
|
||||
| File | Description |
|
||||
| -------------------------------- | ------------------------------------------ |
|
||||
| **SampleUnattend_x64.xml** | Example unattend file for x64 systems |
|
||||
| **unattend_x64.xml** | Active unattend file used for x64 builds |
|
||||
| **unattend_arm64.xml** | Active unattend file used for arm64 builds |
|
||||
| **SamplePrefixes.txt** | Example prefixes file for device naming |
|
||||
|
||||
Copy and customize the sample files to create your own `unattend_x64.xml`, `unattend_arm64.xml`, and `prefixes.txt` files.
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> The unattend file must contain a `<ComputerName>` element in the `Microsoft-Windows-Shell-Setup` component for device naming to work. See the sample files for the correct structure.
|
||||
|
||||
### Copy Provisioning Package
|
||||
|
||||
Controls the `-CopyPPKG` parameter. When checked, copies the contents of the `.\FFUDevelopment\PPKG` folder to the `PPKG` folder on the Deployment partition of the USB drive. The default is **unchecked**.
|
||||
|
||||
This option is only available when **Build USB Drive** is checked.
|
||||
|
||||
#### How It Works
|
||||
|
||||
1. **During Build**: The build process copies all `.ppkg` files from `.\FFUDevelopment\PPKG` to the USB drive.
|
||||
2. **During Deployment**: When `ApplyFFU.ps1` runs, it detects the `PPKG` folder and the provisioning packages within it.
|
||||
- If **multiple** `.ppkg` files are found, the technician is prompted to select which package to apply.
|
||||
- If **one** `.ppkg` file is found, it is automatically selected.
|
||||
3. **Application**: The selected provisioning package is copied to the root of the USB drive, where Windows picks it up during OOBE and applies the settings.
|
||||
|
||||
### Copy Additional FFU Files
|
||||
|
||||
Controls the `-CopyAdditionalFFUFiles` parameter. When checked, allows you to select existing FFU files from the FFU Capture Location to copy to the USB drive alongside the newly built FFU. The default is **unchecked**.
|
||||
|
||||
This option is only available when **Build USB Drive** is checked.
|
||||
|
||||
#### How It Works
|
||||
|
||||
When enabled, an **Additional FFU Files** panel appears below the checkbox with the following controls:
|
||||
|
||||
| Control | Description |
|
||||
| ----------------------- | ----------------------------------------------------------------------------------------------- |
|
||||
| **Refresh** | Scans the FFU Capture Location folder for existing `.ffu` files and populates the list |
|
||||
| **FFU Name** | The filename of the FFU file |
|
||||
| **Last Modified** | The date and time the FFU file was last modified, useful for identifying the most recent builds |
|
||||
|
||||
The list displays all `.ffu` files found in the FFU Capture Location (default `.\FFUDevelopment\FFU`). Click on individual rows to select which FFU files you want to include on the USB drive. Selected files are highlighted in the list.
|
||||
|
||||
#### Use Cases
|
||||
|
||||
- **Multiple device configurations**: Copy different FFU files for different windows/application configurations (e.g., different versions of windows, different application stacks) to a single USB drive, allowing technicians to choose during deployment.
|
||||
- **Previous builds**: Include a known-good FFU from a previous build alongside the new build as a fallback option.
|
||||
- **Multi-architecture imaging**: Include both x64 and arm64 FFU files on the same USB drive for mixed-architecture environments.
|
||||
|
||||
#### Command Line Usage
|
||||
|
||||
When running `BuildFFUVM.ps1` from the command line with `-CopyAdditionalFFUFiles $true` and no `-AdditionalFFUFiles` parameter specified, the script displays an interactive prompt listing all available FFU files in the capture folder. You can:
|
||||
|
||||
- Enter numbers separated by commas (e.g., `1,3,5`) to select specific files
|
||||
- Enter `A` to select all available files
|
||||
- Press **Enter** to skip and not include any additional files
|
||||
|
||||
Example command line usage with pre-selected files:
|
||||
|
||||
```powershell
|
||||
.\BuildFFUVM.ps1 -configFile .\config\FFUConfig.json -CopyAdditionalFFUFiles $true -AdditionalFFUFiles @("C:\FFUDevelopment\FFU\Win11_24h2_Pro_Nov2025.ffu", "C:\FFUDevelopment\FFU\Win11_24h2_Enterprise_Nov2025.ffu")
|
||||
```
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> The newly captured FFU from the current build is always copied to the USB drive. Additional FFU files selected here are copied in addition to the new FFU.
|
||||
|
||||
### Max USB Drives
|
||||
|
||||
Controls the `-MaxUSBDrives` parameter, which sets the maximum number of USB drives to build in parallel. The default value is **5**.
|
||||
|
||||
This option is only available when **Build USB Drive** is checked.
|
||||
|
||||
When building USB drives, the script processes multiple drives concurrently to speed up imaging. This setting controls how many drives are formatted and copied to simultaneously.
|
||||
|
||||
## Compact OS
|
||||
|
||||
Controls the `-CompactOS` parameter. When checked, the Windows image is applied using compressed files. The default is **checked**.
|
||||
|
||||
### How It Works
|
||||
|
||||
When enabled, the build script uses the `-Compact` switch with `Expand-WindowsImage` when applying the Windows image to the OS partition. This compresses Windows system files using Compact OS compression, which reduces the disk footprint of the operating system. On an x64 image, space savings is ~3.5-4GB.
|
||||
|
||||
### Benefits
|
||||
|
||||
| Benefit | Description |
|
||||
| ------------------------------- | ---------------------------------------------------------------------------------------------------- |
|
||||
| **Reduced Disk Space** | Windows files are stored in a compressed state, saving several gigabytes of storage |
|
||||
| **Smaller FFU Size** | The captured FFU file is smaller because the OS partition contains compressed files |
|
||||
| **Faster Deployment** | Smaller FFU files transfer more quickly to USB drives and deploy faster to target devices |
|
||||
| **No Performance Impact** | Modern CPUs decompress files faster than they can be read from storage, so performance is maintained |
|
||||
|
||||
### When to Disable
|
||||
|
||||
You may want to disable Compact OS in the following scenarios:
|
||||
|
||||
- **Windows Server builds**: The script automatically disables Compact OS for Windows Server operating systems because the Windows Overlay Filter (wof.sys) is not included in Server SKUs
|
||||
- **Troubleshooting**: If you experience issues with specific applications that are incompatible with compressed files
|
||||
- **Maximum performance requirements**: In rare cases where every CPU cycle matters
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> Compact OS is automatically disabled when building Windows Server images, regardless of this setting. The script detects Server operating systems and applies the Windows image without compression.
|
||||
|
||||
## Update ADK
|
||||
|
||||
Controls the `-UpdateADK` parameter. When checked, the script checks for and installs or updates to the latest Windows ADK and WinPE add-on before starting the build. The default is **checked**.
|
||||
|
||||
### How It Works
|
||||
|
||||
When enabled, the build process performs the following checks before starting:
|
||||
|
||||
1. **Version Check**: Queries the [Microsoft ADK installation page](https://learn.microsoft.com/en-us/windows-hardware/get-started/adk-install) to determine the latest available ADK version
|
||||
2. **Compare Versions**: Compares the installed ADK and WinPE add-on versions (if present) against the latest available version
|
||||
3. **Update if Needed**: If an older version is detected:
|
||||
- Uninstalls the existing Windows ADK
|
||||
- Uninstalls the existing WinPE add-on
|
||||
- Downloads and installs the latest Windows ADK with Deployment Tools feature
|
||||
- Downloads and installs the latest WinPE add-on
|
||||
|
||||
### Features Installed
|
||||
|
||||
When installing or updating the ADK, the following features are included:
|
||||
|
||||
| Component | Feature ID | Description |
|
||||
| ---------------------------------- | ---------------------------------------------- | --------------------------------------------------------------- |
|
||||
| **Windows Deployment Tools** | `OptionId.DeploymentTools` | Includes DISM, Oscdimg, and other deployment-related tools |
|
||||
| **WinPE Environment** | `OptionId.WindowsPreinstallationEnvironment` | Windows Preinstallation Environment used for capture and deploy |
|
||||
|
||||
### Installation Location
|
||||
|
||||
The ADK is installed to the default location: `C:\Program Files (x86)\Windows Kits\10`
|
||||
|
||||
### When to Disable
|
||||
|
||||
You may want to disable Update ADK in the following scenarios:
|
||||
|
||||
- **Offline or air-gapped environments**: When internet access is not available to download the latest ADK
|
||||
- **Controlled ADK versions**: When you need to maintain a specific ADK version for compatibility or compliance reasons
|
||||
- **Faster builds**: When you have already verified you are running the latest ADK version and want to skip the version check
|
||||
|
||||
{: .warning-title}
|
||||
|
||||
> Warning
|
||||
>
|
||||
> If Update ADK is disabled and the Windows ADK or WinPE add-on is not installed, the build will fail. Ensure you have manually installed the required components before disabling this option.
|
||||
|
||||
### Manual ADK Installation
|
||||
|
||||
If you prefer to manually install the ADK, visit:
|
||||
|
||||
[Download and install the Windows ADK](https://learn.microsoft.com/en-us/windows-hardware/get-started/adk-install)
|
||||
|
||||
You must install both:
|
||||
|
||||
- Windows Assessment and Deployment Kit (with Deployment Tools feature)
|
||||
- Windows PE add-on for the Windows ADK
|
||||
|
||||
## Optimize
|
||||
|
||||
Controls the `-Optimize` parameter. When enabled, FFU Builder runs the Windows ADK version of DISM to optimize the captured `.ffu` file:
|
||||
|
||||
- `DISM /Optimize-FFU /ImageFile:<path-to-ffu>`
|
||||
|
||||
This post-processing step typically takes a few minutes and is intended to make FFU images faster to deploy and easier to deploy to differently-sized disks (by allowing the Windows partition to expand or shrink during apply).
|
||||
|
||||
**Default:** Enabled (`-Optimize $true`)
|
||||
|
||||
### When to Disable
|
||||
|
||||
You may want to disable Optimize (`-Optimize $false`) if you are troubleshooting, or if you want to skip the extra post-processing time.
|
||||
|
||||
{: .warning-title}
|
||||
|
||||
> Warning
|
||||
>
|
||||
> If you plan to deploy the same FFU to devices with different storage sizes (especially smaller disks), keep `-Optimize` enabled. Non-optimized FFUs are more likely to require additional partition management during deployment.
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> FFU Builder also performs a separate “optimize VHDX before capture” step. That VHDX optimization is independent of `-Optimize`, so you may still see “Optimizing VHDX before capture…” even when `-Optimize` is disabled.
|
||||
|
||||
## Allow VHDX Caching
|
||||
|
||||
Controls the `-AllowVHDXCaching` parameter. When enabled, FFU Builder caches the base VHDX it creates in `$FFUDevelopmentPath\VHDXCache` and writes a matching `*_config.json` file alongside it. On later builds, if a cached VHDX exists that matches your selected Windows settings and update set, the script reuses it to avoid re-applying the base image and integrating updates again.
|
||||
|
||||
**Default:** Disabled (`-AllowVHDXCaching $false`)
|
||||
|
||||
### Cache Matching
|
||||
|
||||
A cached VHDX is reused only when the cache metadata matches your current build inputs, including:
|
||||
|
||||
- Windows release, version, and SKU
|
||||
- Logical sector size (512 vs 4096)
|
||||
- Optional features selection
|
||||
- The exact set of update payload file names downloaded for that run (SSU/CU/.NET/etc.)
|
||||
|
||||
### Disk Usage and Cleanup
|
||||
|
||||
VHDX caching trades disk space for speed. The `VHDXCache` folder can grow over time as you build different combinations. Periodically check the folder and remove old cached vhdx and config json files as necessary.
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> To force a full rebuild, delete the contents of `$FFUDevelopmentPath\VHDXCache` (or disable **Allow VHDX Caching**) and run the build again.
|
||||
|
||||
## Create Capture Media
|
||||
|
||||
Controls the `-CreateCaptureMedia` parameter.
|
||||
|
||||
When enabled, FFU Builder creates WinPE capture media that is used during VM-based builds (when apps are installed in the VM). FFU Builder attaches this media to the VM and adjusts boot order so the VM can reboot into WinPE and automatically capture the FFU to your **FFU Capture Location**.
|
||||
|
||||
The capture media uses the parameter values from `VMHostIPAddress`, `ShareName`, `UserName`, and `CustomFFUNameTemplate` and inserts them into `CaptureFFU.ps1` which is what is responsible for capturing the FFU from the guest VM to the Host.
|
||||
|
||||
**Default:** Enabled (`-CreateCaptureMedia $true`)
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> This option is only relevant when **Install Apps** is enabled. If **Install Apps** is enabled, the build forces `-CreateCaptureMedia` to `$true` because capture media is required to capture an FFU from the VM.
|
||||
|
||||
{: .tip-title}
|
||||
|
||||
> Tip
|
||||
>
|
||||
> If you just need to re-create media, you can use the `Create-PEMedia.ps1` script to regenerate the capture or deploy ISO using `Create-PEMedia.ps1 -Capture $true` or `CreatePEMedia.ps1 -Deploy $true`.
|
||||
|
||||
## Create Deployment Media
|
||||
|
||||
Controls the `-CreateDeploymentMedia` parameter.
|
||||
|
||||
When enabled, FFU Builder creates WinPE deployment media that is used to deploy an FFU image to a physical device. This media contains the WinPE environment and deployment scripts needed to boot a target machine and apply the FFU image.
|
||||
|
||||
The deployment media is saved as an ISO file at `$FFUDevelopmentPath\WinPE_FFU_Deploy_x64.iso` (or `WinPE_FFU_Deploy_arm64.iso` for ARM64 builds). This ISO can then be used with the **Build USB Drive** option to create bootable USB media for physical deployments.
|
||||
|
||||
**Default:** Enabled (`-CreateDeploymentMedia $true`)
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> If you only need to capture FFUs from VMs and do not plan to deploy to physical devices, you can disable this option to save time during the build process. However, most scenarios require deployment media for the final step of applying the FFU to target hardware.
|
||||
|
||||
{: .tip-title}
|
||||
|
||||
> Tip
|
||||
>
|
||||
> If you just need to re-create media, you can use the `Create-PEMedia.ps1` script to regenerate the capture or deploy ISO using `Create-PEMedia.ps1 -Capture $true` or `CreatePEMedia.ps1 -Deploy $true`.
|
||||
|
||||
## Inject Unattend.xml
|
||||
|
||||
Controls the `-InjectUnattend` parameter. When checked, copies the architecture-specific unattend XML file from `.\FFUDevelopment\unattend` into the Apps ISO so it's baked into the FFU during the VM build process. The default is **unchecked**.
|
||||
|
||||
This option is only available when **Install Apps** is checked.
|
||||
|
||||
### How It Works
|
||||
|
||||
When enabled, the build process:
|
||||
|
||||
1. Determines the correct unattend file based on the target architecture:
|
||||
* **unattend_x64.xml** for x64 builds
|
||||
* **unattend_arm64.xml** for arm64 builds
|
||||
2. Creates an `Unattend` folder inside `.\FFUDevelopment\Apps` if it doesn't exist
|
||||
3. Copies the architecture-specific unattend file to `.\FFUDevelopment\Apps\Unattend\Unattend.xml`
|
||||
4. Includes the unattend file in the Apps ISO, making it available to sysprep during the VM build
|
||||
|
||||
The unattend file is then used by sysprep during the specialize phase and/or other OOBE phases when the FFU is deployed.
|
||||
|
||||
### Creating Your Unattend Files
|
||||
|
||||
Modify the architecture-specific unattend file in the `.\FFUDevelopment\unattend` folder:
|
||||
|
||||
| File | Description |
|
||||
| ---------------------------- | ----------------------------------- |
|
||||
| **unattend_x64.xml** | Unattend file used for x64 builds |
|
||||
| **unattend_arm64.xml** | Unattend file used for arm64 builds |
|
||||
|
||||
{: .warning-title}
|
||||
|
||||
> Important
|
||||
>
|
||||
> Keep the file names with the architecture suffix (e.g., unattend_x64.xml). The script handles renaming the file to `Unattend.xml` when copying it to the Apps folder.
|
||||
|
||||
### When to Use This Option
|
||||
|
||||
This option is primarily intended for scenarios where:
|
||||
|
||||
* You are **not using the USB drive** to deploy the FFU and use other deployment methods (e.g., network deployment, disk cloning, etc)
|
||||
* You want the unattend configuration **baked directly into the FFU** rather than applied at deployment time
|
||||
|
||||
### Limitations
|
||||
|
||||
| Limitation | Description |
|
||||
| --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **No prefixes.txt support** | Unlike the**Copy Unattend** option for USB drives, this method does not support `prefixes.txt` for dynamic device naming based on serial numbers |
|
||||
| **Fixed configuration** | The unattend settings are baked into the FFU at build time and cannot be changed at deployment time |
|
||||
| **Requires VM to be built** | This option only works when**Install Apps** is `$true` because the unattend file is included in the Apps ISO |
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> Most users should continue using the **Copy Unattend** option via the USB drive, which provides more flexibility including support for `prefixes.txt` device naming. Use **Inject Unattend.xml** only when you won't be using the USB drive for deployment.
|
||||
|
||||
{: .tip-title}
|
||||
|
||||
> Tip
|
||||
>
|
||||
> If you're using this option, you can disable **Build Deploy ISO** to save time during the build process since the deployment ISO is not needed when you're not using the USB drive method.
|
||||
|
||||
## Verbose
|
||||
|
||||
Controls the `-Verbose` common parameter. When checked, enables detailed verbose output during the build process. The default is **unchecked**.
|
||||
|
||||
In prior builds it was necessary to enable `-verbose` output to track in real-time the build process if you didn't have `cmtrace.exe` or some other log-monitoring tool. With the UI, you can now watch the build in real-time using the monitor tab. Enabling verbose shouldn't be necessary but is available for those who wish to use it.
|
||||
|
||||
# Post-Build Cleanup
|
||||
|
||||
## Cleanup Apps ISO
|
||||
|
||||
Controls the `-CleanupAppsISO` parameter. When checked, the Apps ISO file is automatically deleted after the FFU has been successfully captured. The default is **checked**.
|
||||
|
||||
During the build process, when apps are being installed, the script creates an `Apps.iso` file in the FFU Development Path (e.g., `.\FFUDevelopment\Apps.iso`). This ISO contains the contents of the `.\FFUDevelopment\Apps` folder—including application installers, Office deployment files, and orchestration scripts—and is mounted to the VM during the build to install applications.
|
||||
|
||||
### When to Disable
|
||||
|
||||
You may want to disable Cleanup Apps ISO in the following scenarios:
|
||||
|
||||
* **Debugging app installations**: When troubleshooting application installation issues and you want to manually inspect the ISO contents
|
||||
* **Multiple builds with same apps**: If you're running consecutive builds with identical app configurations and want to reuse the existing ISO to save time (the script will recreate it if missing)
|
||||
* **Archival purposes**: When you need to retain a copy of the exact Apps ISO used for a specific FFU build
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> The Apps ISO is only created when applications are configured for installation. If no apps are being installed in the FFU, this option has no effect. Keeping this option enabled helps conserve disk space by removing temporary build artifacts.
|
||||
|
||||
## Cleanup Capture ISO
|
||||
|
||||
Controls the `-CleanupCaptureISO` parameter. When checked, the WinPE capture ISO file is automatically deleted after the FFU has been successfully captured. The default is **checked**.
|
||||
|
||||
It's recommended to keep this checked as each new build re-creates the local username account (e.g. `ffu_user`) and its password. If you were to retain the capture ISO from a previous build, it'd be using an old password and the capture would fail.
|
||||
|
||||
## Cleanup Deploy ISO
|
||||
|
||||
Controls the `-CleanupDeployISO` parameter. When checked, the WinPE deployment ISO file is automatically deleted after the FFU has been successfully captured. The default is **checked**.
|
||||
|
||||
During the build process, when **Build Deploy ISO** is enabled, the script creates a `WinPE_FFU_Deploy.iso` file (e.g., `.\FFUDevelopment\WinPE_FFU_Deploy.iso`). This ISO contains a customized Windows PE environment used to deploy captured FFU images to target devices. The deployment ISO is typically copied to a bootable USB drive along with the FFU files for field deployment.
|
||||
|
||||
### When to Disable
|
||||
|
||||
You may want to disable Cleanup Deploy ISO in the following scenarios:
|
||||
|
||||
* **Creating deployment media separately**: When you want to create USB deployment drives at a later time (e.g. using `.\FFUDevelopment\USBImagingToolCreator.ps1`)
|
||||
* **Testing in Hyper-V**: When deploying FFU images to Hyper-V VMs for testing, you can attach the deploy ISO directly to a VM as a DVD drive
|
||||
|
||||
## Cleanup Drivers
|
||||
|
||||
Controls the `-CleanupDrivers` parameter. When checked, the contents of the Drivers folder are automatically deleted after the FFU has been successfully captured. The default is **unchecked**.
|
||||
|
||||
During the build process, when drivers are configured for installation, the script downloads and extracts driver packages into manufacturer-specific subfolders within the Drivers folder (e.g., `.\FFUDevelopment\Drivers\HP`, `.\FFUDevelopment\Drivers\Dell`). These drivers are then injected into the FFU during the build.
|
||||
|
||||
### When to Enable
|
||||
|
||||
You may want to enable Cleanup Drivers in the following scenarios:
|
||||
|
||||
* **Conserving disk space**: Driver packages can be large (several gigabytes per manufacturer), and removing them after a successful build frees up storage
|
||||
* **Ensuring fresh drivers**: When you want each build to download the latest available drivers rather than reusing previously downloaded versions
|
||||
* **Single-use builds**: When building an FFU for a one-time deployment and you don't need to retain the driver files
|
||||
|
||||
### When to Disable
|
||||
|
||||
You may want to keep Cleanup Drivers disabled in the following scenarios:
|
||||
|
||||
* **Multiple builds with same drivers**: If you're running consecutive builds targeting the same hardware models, keeping drivers avoids re-downloading them each time
|
||||
* **Debugging driver issues**: When troubleshooting driver injection problems and you want to manually inspect the downloaded driver contents
|
||||
* **Offline builds**: When building in an environment with limited or no internet access, retaining drivers allows reuse across builds
|
||||
* **Bring Your Own Drivers:** When you download and bring your own set of drivers from another source and don't want FFU Builder to remove them
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> Only the contents within the Drivers folder are removed—the folder itself is preserved. If no drivers were downloaded during the build, this option has no effect.
|
||||
|
||||
## Remove FFU
|
||||
|
||||
Controls the `-RemoveFFU` parameter. When checked, all FFU files in the FFU Capture Location are automatically deleted after the build completes successfully. The default is **unchecked**.
|
||||
|
||||
During the build process, the captured FFU image is written to the FFU Capture Location (e.g., `.\FFUDevelopment\FFU`). This option removes all `.ffu` files from that folder after the build finishes, including any previously captured FFU files that may exist in the folder.
|
||||
|
||||
### When to Enable
|
||||
|
||||
You may want to enable Remove FFU in the following scenarios:
|
||||
|
||||
* **USB-only workflow**: When you're using **Build USB Drive** to copy the FFU directly to a USB drive and don't need to retain the FFU file on the host machine
|
||||
* **Conserving disk space**: FFU files can be very large depending on what you're installing, and removing them after copying to USB frees up storage
|
||||
* **Automated build pipelines**: When running automated builds where the FFU is immediately transferred to another location (such as a network share or deployment server) and no longer needed locally
|
||||
|
||||
### When to Disable
|
||||
|
||||
You may want to keep Remove FFU disabled in the following scenarios:
|
||||
|
||||
* **Archival purposes**: When you want to retain captured FFU images for future deployments or as a backup
|
||||
* **Multiple USB drives**: When you need to create additional USB deployment drives at a later time
|
||||
* **Testing and validation**: When you want to test the FFU in Hyper-V or other environments before deploying to physical hardware
|
||||
|
||||
{: .warning-title}
|
||||
|
||||
> Warning
|
||||
>
|
||||
> This option removes **all** FFU files in the FFU Capture Location folder, not just the FFU from the current build. If you have previously captured FFU files stored in this folder that you want to keep, do not enable this option or move those files to a different location before building.
|
||||
|
||||
## Remove Apps Folder Content
|
||||
|
||||
Controls the `-RemoveApps` parameter. When checked, application content in the Apps folder is automatically deleted after the FFU has been successfully captured. The default is **un****checked**.
|
||||
|
||||
During the build process, application content accumulates in several subfolders within the Apps folder (e.g., `.\FFUDevelopment\Apps`):
|
||||
|
||||
| Folder | Contents |
|
||||
| ----------- | ------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `Win32` | Winget source applications and Bring Your Own Apps content copied using the**Copy Apps** button or manually copied |
|
||||
| `MSStore` | Microsoft Store applications downloaded via Winget |
|
||||
| `Office` | Microsoft 365 Apps installer files downloaded by the Office Deployment Tool |
|
||||
|
||||
Additionally, the `WinGetWin32Apps.json` orchestration file in `.\FFUDevelopment\Apps\Orchestration` is removed. This file is automatically regenerated at build time based on downloaded applications.
|
||||
|
||||
When this option is enabled, the cleanup process removes:
|
||||
|
||||
* The entire `Win32` folder and its contents
|
||||
* The entire `MSStore` folder and its contents
|
||||
* The Office download subfolder (`Office\Office`) and the `setup.exe` file within the `Office` folder
|
||||
|
||||
### When to Enable
|
||||
|
||||
You may want to keep Remove Apps Folder Content enabled in the following scenarios:
|
||||
|
||||
* **Conserving disk space**: Downloaded application installers can consume significant storage, and removing them after a successful build frees up space
|
||||
* **Ensuring fresh downloads**: When you want each build to download the latest available application versions rather than reusing previously downloaded content
|
||||
* **Single-use builds**: When building an FFU for a one-time deployment and you don't need to retain the application files
|
||||
|
||||
### When to Disable
|
||||
|
||||
You may want to disable Remove Apps Folder Content in the following scenarios:
|
||||
|
||||
* **Multiple builds with same apps**: If you're running consecutive builds with identical application configurations, keeping the downloaded content avoids re-downloading applications each time
|
||||
* **Debugging app installations**: When troubleshooting application installation issues and you want to manually inspect the downloaded content
|
||||
* **Offline builds**: When building in an environment with limited or no internet access, retaining downloaded applications allows reuse across builds
|
||||
* **Preserving Bring Your Own Apps**: When you've manually copied application content into the `Win32` folder and don't want FFU Builder to remove it
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> Only the application content subfolders are removed—the `Apps` folder itself and configuration files such as `AppList.json` and `UserAppList.json` are preserved. If no applications were configured for the build, this option has no effect.
|
||||
|
||||
## Remove Downloaded Update Files
|
||||
|
||||
Controls the `-RemoveUpdates` parameter. When checked, downloaded Windows updates and application update payloads are automatically deleted after the FFU has been successfully captured. The default is **unchecked**.
|
||||
|
||||
During the build process, update files are downloaded to specific locations within the `FFUDevelopment` folder:
|
||||
|
||||
| Folder | Contents |
|
||||
| ----------------- | ---------------------------------------------------------- |
|
||||
| `KB` | Windows Cumulative Updates (CU) and .NET Framework updates |
|
||||
| `Apps\Defender` | Microsoft Defender definition updates |
|
||||
| `Apps\Edge` | Microsoft Edge browser installer |
|
||||
| `Apps\MSRT` | Malicious Software Removal Tool updates |
|
||||
| `Apps\OneDrive` | Microsoft OneDrive installer |
|
||||
|
||||
When this option is enabled, the cleanup process removes the entire `KB` folder and the specific update subfolders within the `Apps` directory.
|
||||
|
||||
### When to Enable
|
||||
|
||||
You may want to keep Remove Downloaded Update Files enabled in the following scenarios:
|
||||
|
||||
* **Conserving disk space**: Windows Cumulative Updates can be several gigabytes in size, and removing them after a successful build frees up significant storage
|
||||
* **Ensuring latest updates**: When you want each build to download the absolute latest available updates rather than potentially reusing older cached versions
|
||||
|
||||
### When to Disable
|
||||
|
||||
You may want to disable Remove Downloaded Update Files in the following scenarios:
|
||||
|
||||
* **Multiple builds**: If you're running consecutive builds, keeping the downloaded updates avoids re-downloading large Cumulative Update files each time
|
||||
* **Offline builds**: When building in an environment with limited or no internet access, retaining downloaded updates allows reuse across builds
|
||||
* **Testing and validation**: When you want to manually inspect the update files that were included in the build
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> Only the update-specific subfolders are removed-the `Apps` folder itself and other application content (unless **Remove Apps Folder Content** is also selected) are preserved.
|
||||
|
||||
## Restore Defaults
|
||||
|
||||
Use this to restore FFU Builder to its default state. When clicked:
|
||||
|
||||
- A confirmation dialog lists what will be removed before anything is deleted.
|
||||
- Generated JSON files are removed (`config\FFUConfig.json`, `Apps\AppList.json`, `Apps\UserAppList.json`, `Drivers\Drivers.json`).
|
||||
- Capture, Deploy, and Apps ISO files are deleted.
|
||||
- Downloaded artifacts are cleared: Apps payloads (Win32, MSStore, Office downloads), update folders under Apps (Defender, Edge, MSRT, OneDrive), driver downloads, and all `.ffu` files in the FFU capture folder.
|
||||
- UI list views (drivers, apps, Winget search results, AppScript variables) are cleared and all controls are reset to their default values.
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> VHDX cache and any custom config files in the `FFUDevelopment\config` folder, and `Drivers\DriverMapping.json` will remain. DriverMapping.json is retained because you may have made custom changes to it and we want to retain those.
|
||||
>
|
||||
> If you want to keep any content prior to restoring defaults, copy it out first.
|
||||
|
||||
## Save Config File
|
||||
|
||||
Saves all current UI selections to a JSON file so you can reload the same settings later or run `BuildFFUVM.ps1` from the command line with `-configFile` (e.g. `BuildFFUVM.ps1 -configFile C:\FFUDevelopment\config\FFUConfig.json`)
|
||||
|
||||
### How it works
|
||||
|
||||
- Collects the full UI state (paths, toggles, driver/app selections, build options) into a single JSON.
|
||||
- Defaults the save location to `FFUDevelopmentPath\config` and suggests `FFUConfig.json` as the file name. You can browse and pick a different file name or folder.
|
||||
- Creates the `config` folder if it does not exist and confirms the save when finished.
|
||||
|
||||
## Load Config File
|
||||
|
||||
Loads a previously saved configuration JSON and repopulates the UI.
|
||||
|
||||
### How it works
|
||||
|
||||
- Click **Load Config File** to browse for a JSON file (for example, `FFUDevelopment\config\FFUConfig.json`).
|
||||
- The UI updates with everything from the file: paths, checkboxes, build options, driver/app selections, and USB settings.
|
||||
- Supplemental files referenced in the config (Winget `AppList.json`, BYO `UserAppList.json`, `Drivers.json`) are also imported if they exist. Missing helper files are treated as optional and noted for you.
|
||||
- If the file is empty, unreadable, or invalid JSON, the load is stopped and an error message is shown.
|
||||
|
||||
## Build FFU
|
||||
|
||||
Use **Build FFU** to run `BuildFFUVM.ps1` with the current UI selections.
|
||||
|
||||
### What happens when you click Build FFU
|
||||
|
||||
- The UI gathers all current settings and saves them to `FFUDevelopment\config\FFUConfig.json`, and launches `BuildFFUVM.ps1 -configFile` pointing to that file in a background job. `FFUConfig.json` persists between builds and is read on each opening of `BuildFFUVM_UI.ps1` so you can continue where you left off on each new run.
|
||||
- The window switches to the **Monitor** tab so you can watch progress in real time.
|
||||
- The progress bar shows overall completion
|
||||
- When the job finishes, the button returns to **Build FFU** and the UI is ready for the next run.
|
||||
|
||||
### Cancelling a Build
|
||||
|
||||
The Build FFU button will change to Cancel while a build is running. Cancelling will do the following:
|
||||
|
||||
- The UI stops the background build job and kills any child processes so DISM, downloads, and other tools exit.
|
||||
- The in-progress download is always removed to avoid partial or corrupt content.
|
||||
- You’re prompted to decide whether to remove other items downloaded during this run. Selecting **Yes** removes only this run’s downloads. Any previously downloaded content stays in place.
|
||||
- When cleanup is finished, the Cancel button reverts to Build FFU and a new build can begin
|
||||
|
||||
{% include page_nav.html %}
|
||||
@@ -0,0 +1,98 @@
|
||||
---
|
||||
title: Bring Your Own Applications
|
||||
nav_order: 6
|
||||
prev_url: /winget.html
|
||||
prev_label: Install Winget Applications
|
||||
next_url: /appsscriptvariables.html
|
||||
next_label: Apps Script Variables
|
||||
parent: Applications
|
||||
grand_parent: UI Overview
|
||||
---
|
||||
# Bring Your Own Applications
|
||||
|
||||

|
||||
|
||||
Bring Your Own Applications allows you to run any command line you want in the virtual machine to include in your FFU to install an application, run a script, etc. As the name implies, you'll provide the content, command line, arguments, and additional exit codes.
|
||||
|
||||
All applications are stored in the `$AppsPath` parent folder which defaults to `C:\FFUDevelopment\Apps`. Winget source applications and BYO Apps that you select Copy Apps are stored in `$AppsPath\Win32`. MSStore source apps from Winget are stored in `$AppsPath\MSStore`.
|
||||
|
||||
At build time, an `Apps.iso` file is created of the `$AppsPath` folder. This ISO gets mounted to the VM. It shows up in the VM as the `D:\` drive. When creating your command line or arguments, you must make sure to reference `D:\`.
|
||||
|
||||
## Name
|
||||
|
||||
The name of the application. The name is also used when selecting **Copy Apps** to copy apps from a source location to the `$AppsPath\Win32\<Name>` folder (e.g. `C:\FFUDevelopment\Apps\Win32\Google Chrome`)
|
||||
|
||||
## Command Line
|
||||
|
||||
This is the full path to the command line to install the application, script, or to run a command. If the content was included in the `$AppsPath` this should start with `D:\` (e.g. `D:\Win32\Mozilla Firefox\Mozilla Firefox_136.0.3_Machine_X64_exe_en-US.exe`)
|
||||
|
||||
For MSI applications, this should only include msiexec. The rest of the command line will be specified in arguments.
|
||||
|
||||
## Arguments
|
||||
|
||||
These are the command line arguments for the application. Using the Mozilla Firefox example above, the arguments would be `/S /PreventRebootRequired=true`.
|
||||
|
||||
For MSI applications, this will include `/i` and the full-path to the MSI file plus any additional command line parameters (e.g. `/i "D:\Win32\Google Chrome\Google Chrome_134.0.6998.178_Machine_X64_wix_en-US.msi" /quiet /norestart`)
|
||||
|
||||
## Source
|
||||
|
||||
This is an optional parameter. This is the local source to the content. It is used by the Copy Apps button to copy from the source location to the `$AppsPath\Win32\<Name>` folder. If you don't use the **Copy Apps** button, then you must put the conent in the `$AppsPath` folder manually.
|
||||
|
||||
## Additional Exit Codes
|
||||
|
||||
This is an optional parameter. Enter a comma-separated list of additional success exit codes if necessary.
|
||||
|
||||
## Ignore all non-zero exit codes
|
||||
|
||||
If checked, any non-zero exit code will be considered a success.
|
||||
|
||||
## Save UserAppList.json
|
||||
|
||||
When you're done adding your apps, you must save the `UserAppList.json` file to your `$AppsPath` folder. If you click **Copy Apps**, the `UserAppList.json` file is also saved. The `UserAppList.json` is used by the FFU Builder Orchestrator in the VM to know what to install and when based on the priority of the application.
|
||||
|
||||
Below is the `UserAppList.json` of Chrome and Firefox using the example above.
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"Priority": 1,
|
||||
"Name": "Google Chrome",
|
||||
"CommandLine": "msiexec",
|
||||
"Arguments": "/i \"D:\\Win32\\Google Chrome\\Google Chrome_134.0.6998.178_Machine_X64_wix_en-US.msi\" /quiet /norestart",
|
||||
"Source": "C:\\temp\\source\\Google Chrome",
|
||||
"AdditionalExitCodes": "",
|
||||
"IgnoreNonZeroExitCodes": false
|
||||
},
|
||||
{
|
||||
"Priority": 2,
|
||||
"Name": "Mozilla Firefox",
|
||||
"CommandLine": "D:\\Win32\\Mozilla Firefox\\Mozilla Firefox_136.0.3_Machine_X64_exe_en-US.exe",
|
||||
"Arguments": "/S /PreventRebootRequired=true",
|
||||
"Source": "C:\\temp\\source\\Mozilla Firefox",
|
||||
"AdditionalExitCodes": "",
|
||||
"IgnoreNonZeroExitCodes": false
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
## Import UserAppList.json
|
||||
|
||||
You can import a saved `UserAppList.json`
|
||||
|
||||
## Edit Application
|
||||
|
||||
When you select a single application you can select the **Edit Application** button. This allows you to edit the application information and update the application.
|
||||
|
||||
## Copy Apps
|
||||
|
||||
If the application source is provided, click **Copy Apps** to copy the application content to the `$AppsPath\Win32` folder (e.g. `C:\FFUDevelopment\Apps\Win32\<Name>`). Network shares are supported. When clicking **Copy Apps** the `UserAppList.json` file is automatically created.
|
||||
|
||||
## Remove Selected
|
||||
|
||||
Removes the selected applications from the list view. Click **Save UserAppList.json** to save the application list.
|
||||
|
||||
## Clear List
|
||||
|
||||
The **Clear List** button will clear the list view of what’s currently in it. It will not clear the `UserAppList.json` file if it exists.
|
||||
|
||||
{% include page_nav.html %}
|
||||
@@ -0,0 +1,410 @@
|
||||
---
|
||||
title: Drivers
|
||||
nav_order: 9
|
||||
prev_url: /M365appsoffice.html
|
||||
prev_label: M365 Apps Office
|
||||
next_url: /build.html
|
||||
next_label: Build
|
||||
parent: UI Overview
|
||||
---
|
||||
# Drivers
|
||||
|
||||

|
||||
|
||||
FFU Builder supports adding drivers directly to the FFU file at build time, or adding them as folders on your USB drive which can be serviced offline after the FFU has been applied to your device.
|
||||
|
||||
The UI allows you to download the drivers prior to build and/or create a `Drivers.json` file which can be used to automatically download the drivers at build time. This allows for flexibility in downloading drivers whenever you need them. It supports downloading multiple driver models at once in parallel.
|
||||
|
||||
## Drivers Folder
|
||||
|
||||
This is the location where drivers are downloaded to, or where you'll manually copy drivers to. The default is `.\FFUDevelopment\Drivers`
|
||||
|
||||
## PE Drivers Folder
|
||||
|
||||
Path to the folder containing drivers to be injected into the WinPE deployment media. Default is `.\FFUDevelopment\PEDrivers`.
|
||||
|
||||
## Drivers.json Path
|
||||
|
||||
Path to a JSON file that specifies which drivers to download. Default is `.\FFUDevelopment\Drivers\Drivers.json`
|
||||
|
||||
## Download Drivers
|
||||
|
||||
FFU Builder can download drivers from the following OEMs:
|
||||
|
||||
* Dell
|
||||
* HP
|
||||
* Lenovo
|
||||
* Microsoft
|
||||
|
||||
Clicking the **Download Drivers** exposes a **Make:** drop down which lists the above four OEMs and a **Get Models** button
|
||||
|
||||
Clicking **Get Models** downloads the list of models from the selected OEM.
|
||||
|
||||
The **Model Filter** box allows you to type in a string to filter on the model. The filter should match on any portion of text in the model name.
|
||||
|
||||
The model column lists the model name and the System ID (for Dell and HP) or the Machine Type (for Lenovo) in parenthesis. The SystemID/Machine Type values are required to know exactly which set of drivers to download for your model. There typically is a lot of overlap, and sometimes the drivers for the various SystemID/MachineTypes for the same model might be exactly the same, it's still best to grab the SystemID/MachineType before downloading drivers.
|
||||
|
||||
To get the System ID:
|
||||
|
||||
**HP**
|
||||
|
||||
* BIOS/UEFI: Either under Main or System Information (it's going to be different depending on the model) you're looking for the **System Board ID** and it should be a four-character code.
|
||||
* PowerShell:`(Get-CimInstance -Namespace 'root\WMI' -Class MS_SystemInformation).BaseboardProduct`
|
||||
|
||||
**Dell**
|
||||
|
||||
* BIOS/UEFI: I'm not sure if it's possible to get the System ID from the BIOS/UEFI. I seem to recall in some BIOS screenshots that System SKU is listed in some BIOS/UEFI implementations, but it may not be consistent.
|
||||
* PowerShell: `(Get-CIMInstance -ClassName "MS_SystemInformation" -NameSpace "root\WMI").SystemSku`
|
||||
|
||||
or
|
||||
|
||||
```
|
||||
[string]$OEMString = Get-WmiObject -Class "Win32_ComputerSystem" | Select-Object -ExpandProperty OEMStringArray
|
||||
$ComputerDetails.FallbackSKU = [regex]::Matches($OEMString, '\[\S*]')[0].Value.TrimStart("[").TrimEnd("]")
|
||||
```
|
||||
|
||||
**Lenovo**
|
||||
|
||||
To find the Machine Type for Lenovo devices, check the bottom/back of the device for the MTM field and capture the first four characters.
|
||||
|
||||
* BIOS/UEFI: Look for MTM and grab the first four characters
|
||||
* PowerShell: `(Get-CIMInstance -ClassName "MS_SystemInformation" -NameSpace "root\WMI").SystemProductName`
|
||||
|
||||
You can multi-select different models within the same make, or mix and match different makes. The screenshot below shows different Dell, HP, Lenovo, and Microsoft models selected
|
||||
|
||||

|
||||
|
||||
## Save Drivers.json
|
||||
|
||||
After selecting the drivers you want to download, clicking **Save Drivers.json** will prompt you for a location to save the `Drivers.json` file to. The `Drivers.json` file is responsible for telling `BuildFFUVM.ps1` what drivers to download during the build process.
|
||||
|
||||
Below is an example of `Drivers.json`:
|
||||
|
||||
```
|
||||
{
|
||||
"HP": {
|
||||
"Models": [
|
||||
{
|
||||
"Name": "HP EliteBook 865 16 inch G11 Notebook PC",
|
||||
"SystemId": "8d03"
|
||||
}
|
||||
]
|
||||
},
|
||||
"Dell": {
|
||||
"Models": [
|
||||
{
|
||||
"Name": "Dell Pro Max Desktops Dell Pro Max Micro FCM2250,Dell Pro Max Micro XE FCM2250",
|
||||
"CabUrl": "https://downloads.dell.com/FOLDER13898125M/1/Dell_Pro_Max_Desktops_0D14.cab",
|
||||
"SystemId": "0D14"
|
||||
}
|
||||
]
|
||||
},
|
||||
"Lenovo": {
|
||||
"Models": [
|
||||
{
|
||||
"Name": "Lenovo 300w Yoga Gen 4",
|
||||
"MachineType": "82VN"
|
||||
}
|
||||
]
|
||||
},
|
||||
"Microsoft": {
|
||||
"Models": [
|
||||
{
|
||||
"Name": "Surface Pro for Business (11th Edition)",
|
||||
"Link": "https://www.microsoft.com/download/details.aspx?id=108013"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Import Drivers.json
|
||||
|
||||
Import Drivers.json allows you to import a previously saved Drivers.json file. The models in the Drivers.json file will show up in the list view pre-selected. This will allow you to select additional models and save an updated version of Drivers.json, or to download the selected models by clicking Download Selected.
|
||||
|
||||
## Download Selected
|
||||
|
||||
Download Selected will download the selected models to the Drivers Folder path (default .\FFUDevelopment\Drivers). Drivers will download the the .\FFUDevelopment\Drivers\Make\Model folder. Download select also interacts with the Compress Driver Model Folder to WIM checkbox which will download and compress the drivers to WIM.
|
||||
|
||||
If you've previously downloaded a driver model and want to compress it to a WIM, you can check he Compress Driver Model Folder to WIM checkbox and click Download Selected again. This will skip the download and compress the driver folder to a WIM file.
|
||||
|
||||
Download Selected leverages BITS and the BITS Priority can be controlled by the BITS Priority drop down on the Build tab. If driver downloads via the UI feel slow, change BITS Priority to Foreground to speed them up.
|
||||
|
||||
## Clear List
|
||||
|
||||
Clears the list view of the previous model list
|
||||
|
||||
## Install Drivers to FFU
|
||||
|
||||
Install Drivers to FFU will recursively add the drivers in the FFUDevelopment\Drivers folder to the FFU file.
|
||||
|
||||
It's recommended to only include a single model's drivers in the FFU. This is because dism will add the drivers to the drivers store in the FFU and any additional models that aren't necessary will bloat the drivers store, using up disk space.
|
||||
|
||||
If you're dealing with multiple models, it's recommended to select Copy Drivers to USB drive instead.
|
||||
|
||||
## Copy Drivers to USB drive
|
||||
|
||||
Copy Drivers to USB drive will copy the drivers to the .\Drivers folder on the deploy partition of the USB drive (e.g. D:\Drivers\Make\Model)
|
||||
|
||||
If you're manually copying drivers to the .\FFUDevelopment\Drivers folder, you must copy them to the FFUDevelopment\Drivers\Make\Model folder (e.g. FFUDevelopment\Drivers\Lenovo\Lenovo 300w). Prior releases referenced using just .\FFUDevelopment\Drivers\Model, however for better organization and consistency, the code has been updated to require the make folder.
|
||||
|
||||
## Compress Driver Model Folder to WIM
|
||||
|
||||
Enabling this checkbox compresses the driver model folder to a WIM file after each model finishes downloading (or when an existing model is detected). Every `Drivers\<Make>\<Model>` directory is captured into a single `<Drivers folder>\<Make>\<Model>.wim` using DISM with `Compress:Max`, which dramatically reduces the space required on your USB drive.
|
||||
|
||||
1. Select the models you need, check **Compress Driver Model Folder to WIM**, then click **Download Selected**. Fresh downloads are extracted as usual and immediately compressed into their companion `.wim`.
|
||||
2. If the model already exists, the download phase is skipped and only the compression runs, so you can rebuild the `.wim` whenever you refresh the folder contents.
|
||||
|
||||
By default the extracted folder is deleted after a successful capture so that the `.wim` becomes the canonical artifact. When **Use Drivers Folder as PE Drivers Source** is also checked, the UI keeps the folder in place, writes a `__PreservedForPEDrivers.txt` marker, and lets WinPE driver harvesting reuse the loose INF set.
|
||||
|
||||
Additional guidance:
|
||||
|
||||
- `DriverMapping.json` is updated to reference the `.wim`, so `Copy Drivers to USB drive`, `BuildFFUVM.ps1 -CopyDrivers`, and the WinPE `ApplyFFU.ps1` flow mount the compressed archive automatically.
|
||||
- Watch the Drivers tab status column or `FFUDevelopment_UI.log` for DISM progress and troubleshooting details per model.
|
||||
- Ensure the volume hosting `FFUDevelopment\Drivers` has enough free space for both the source folder and the resulting `.wim`.
|
||||
- Only applies to drivers from Dell, HP, Lenovo, or Microsoft that are specified in the Drivers.json file. It will not compress models you manually copy to the Drivers folder.
|
||||
|
||||
## Copy PE Drivers
|
||||
|
||||
When **Copy PE Drivers** is enabled, drivers will be injected into the WinPE deployment media. This ensures that WinPE has the necessary drivers to recognize hardware components like storage controllers, network adapters, and input devices during FFU deployment.
|
||||
|
||||
By default, drivers are sourced from the **PE Drivers Folder** (default `.\FFUDevelopment\PEDrivers`). You can manually place drivers in this folder, and they will be injected into the WinPE media during the build process.
|
||||
|
||||
### Use Drivers Folder as PE Drivers Source
|
||||
|
||||
When **Copy PE Drivers** is checked, an additional sub-option becomes visible: **Use Drivers Folder as PE Drivers Source** .
|
||||
|
||||
When this option is enabled, the script bypasses the PE Drivers Folder and instead dynamically builds the WinPE driver set from the main **Drivers Folder**. The script scans all available drivers in the Drivers folder, parses their INF files, and copies only the essential driver types needed for WinPE, including:
|
||||
|
||||
* System devices
|
||||
* SCSI, RAID, and NVMe controllers
|
||||
* Keyboards
|
||||
* Mice and other pointing devices
|
||||
* Human Interface Devices (HID) for touch support
|
||||
|
||||
This eliminates the need to maintain a separate, manually curated `PEDrivers` folder and ensures that WinPE has the necessary drivers based on what you've already downloaded for your target devices.
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> If the PE Drivers folder already contains content when using this option, it will be cleared before the new driver set is copied in.
|
||||
>
|
||||
> Some drivers may fail to be added during injection, which is expected behavior and can be safely ignored.
|
||||
>
|
||||
> Network adapters are not included when using the drivers folder as PE drivers source, so if you're using WDS or another network-based solution to copy your FFU and you've modified ApplyFFU.ps1, it's best to not use the **Use Drivers Folder as PE Driver Source** option and just copy in your required PE Drivers to the PE Drivers folder.
|
||||
|
||||
## DriverMapping.json
|
||||
|
||||
`DriverMapping.json` is an automatically generated file that maps hardware identifiers (like System IDs or Machine Types) to specific driver packages. This file enables the WinPE deployment script (`ApplyFFU.ps1`) to automatically detect your device hardware and apply the correct drivers without manual intervention.
|
||||
|
||||
### How it gets created
|
||||
|
||||
`DriverMapping.json` is created and updated automatically when you download drivers using the **Download Selected** button on the Drivers tab of the UI, or when drivers are downloaded during the FFU build. Each time you successfully download drivers for a model, the file is updated with the mapping information for that model.
|
||||
|
||||
### Automatic Driver Selection During Deployment
|
||||
|
||||
When you deploy an FFU using the WinPE media, `ApplyFFU.ps1` looks for `DriverMapping.json` on the USB drive at `D:\Drivers\DriverMapping.json` (where D: is your USB deploy partition). If found, the script:
|
||||
|
||||
1. Detects the hardware identifiers of the current device (System ID, Machine Type, etc.)
|
||||
2. Searches `DriverMapping.json` for a matching entry
|
||||
3. Automatically selects and applies the correct driver package
|
||||
4. Falls back to manual driver selection if no match is found
|
||||
|
||||
### Required Fields by Manufacturer
|
||||
|
||||
Each entry in `DriverMapping.json` contains different required fields depending on the manufacturer:
|
||||
|
||||
**All Manufacturers:**
|
||||
|
||||
* **Manufacturer** – The OEM name (e.g., "Dell", "HP", "Lenovo", "Microsoft")
|
||||
* **Model** – The full model name as it appears in the driver download catalog
|
||||
* **DriverPath** – The relative path to the driver folder or WIM file on the USB drive under the Drivers folder (e.g., "Dell\\\Dell Latitude 7490" or "HP\\\HP EliteBook 865 16 inch G11 Notebook PC.wim").
|
||||
|
||||
Relative paths are used since we don't know the drive letter of the USB drive when the `DriverMapping.json` file is created. And since this uses json, the double backslash is intentional since the first slash is an escape character.
|
||||
|
||||
**Dell:**
|
||||
|
||||
* **SystemId** – The System SKU identifier (e.g., "0819", "0D14"). This is the primary matching field used during deployment. To find your Dell System SKU via PowerShell, run: `(Get-CIMInstance -ClassName "MS_SystemInformation" -NameSpace "root\WMI").SystemSku`
|
||||
|
||||
**HP:**
|
||||
|
||||
* **SystemId** – The System Board ID, a four-character code (e.g., "8d03", "83D2"). This is the primary matching field used during deployment. To find your HP System Board ID via PowerShell, run: `(Get-CimInstance -Namespace 'root\WMI' -Class MS_SystemInformation).BaseboardProduct`
|
||||
|
||||
**Lenovo:**
|
||||
|
||||
* **MachineType** – The first four characters of the MTM (Machine Type Model) field (e.g., "82VN", "21JD"). This is the primary matching field used during deployment. To find your Lenovo Machine Type via PowerShell, run: `(Get-CIMInstance -ClassName "MS_SystemInformation" -NameSpace "root\WMI").SystemProductName`
|
||||
|
||||
**Microsoft:**
|
||||
|
||||
* No additional fields required beyond Manufacturer, Model, and DriverPath. Matching is performed based on the normalized model name.
|
||||
|
||||
### Example DriverMapping.json
|
||||
|
||||
Below is an example of `DriverMapping.json` with entries for multiple manufacturers:
|
||||
|
||||
```
|
||||
[
|
||||
{
|
||||
"Manufacturer": "Dell",
|
||||
"Model": "Dell Latitude 7490",
|
||||
"DriverPath": "Dell\\Dell Latitude 7490",
|
||||
"SystemId": "0819"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "Dell",
|
||||
"Model": "Dell Pro Max Desktops Dell Pro Max Micro FCM2250,Dell Pro Max Micro XE FCM2250",
|
||||
"DriverPath": "Dell\\Dell Pro Max Desktops Dell Pro Max Micro FCM2250,Dell Pro Max Micro XE FCM2250.wim",
|
||||
"SystemId": "0D14"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "HP",
|
||||
"Model": "HP EliteBook 865 16 inch G11 Notebook PC",
|
||||
"DriverPath": "HP\\HP EliteBook 865 16 inch G11 Notebook PC.wim",
|
||||
"SystemId": "8D03"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "Lenovo",
|
||||
"Model": "Lenovo 300w Yoga Gen 4",
|
||||
"DriverPath": "Lenovo\\Lenovo 300w Yoga Gen 4",
|
||||
"MachineType": "82VN"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "Microsoft",
|
||||
"Model": "Surface Pro for Business (11th Edition)",
|
||||
"DriverPath": "Microsoft\\Surface Pro for Business (11th Edition)"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
## Bring Your Own Drivers
|
||||
|
||||
If you manage models that aren't from Dell, HP, Lenovo or Microsoft, or you want to use different drivers from what FFU Builder downloads, you can copy your own drivers to the `.\FFUDevelopment\Drivers` folder using the `.\FFUDevelopment\Drivers\Make\Model` format, or simply change the Drivers Folder path to the location of your drivers content.
|
||||
|
||||
You can also manually create your own DriverMapping.json file for the following makes/manufacturers
|
||||
|
||||
| Manufacturer | Match Field | WMI Class | Property |
|
||||
| ------------------------------- | ----------- | ------------------------------------------- | ----------------------------------------------- |
|
||||
| **Dell** | SystemId | `MS_SystemInformation` (via `root\WMI`) | `SystemSku` |
|
||||
| **Dell** (fallback) | SystemId | `Win32_ComputerSystem` | `OEMStringArray` (parsed for bracketed value) |
|
||||
| **HP** | SystemId | `MS_SystemInformation` (via `root\WMI`) | `BaseBoardProduct` |
|
||||
| **Lenovo** | MachineType | `Win32_ComputerSystem` | `Model` |
|
||||
| **Microsoft** | Model | `Win32_ComputerSystem` | `Model` |
|
||||
| **Panasonic Corporation** | SystemId | `MS_SystemInformation` (via `root\WMI`) | `BaseBoardProduct` |
|
||||
| **Viglen** | SystemId | `Win32_BaseBoard` | `SKU` |
|
||||
| **AZW** | SystemId | `MS_SystemInformation` (via `root\WMI`) | `BaseBoardProduct` |
|
||||
| **Fujitsu** | SystemId | `Win32_BaseBoard` | `SKU` |
|
||||
| **Getac** | SystemId | `MS_SystemInformation` (via `root\WMI`) | `BaseBoardProduct` |
|
||||
| **Intel** | Model | `Win32_ComputerSystem` | `Model` |
|
||||
| **ByteSpeed** | Model | `Win32_ComputerSystem` | `Model` |
|
||||
| **Other** (default) | Model | `Win32_ComputerSystem` | `Model` |
|
||||
|
||||
**Notes:**
|
||||
|
||||
* Match Field is the name of the field in the `DriverMapping.json` file (e.g. SystemID, MachineType, Model)
|
||||
* SystemId is a catch-all term for a unique identifier, however each manufacturer calls this something different and stores them in different places within WMI
|
||||
* The Dell (fallback) is used for models where the systemSKU isn't available and the OEMStringArray is parsed via Win32_ComputerSystem
|
||||
* The `MS_SystemInformation` class is queried from the `root\WMI` namespace
|
||||
* Unless noted, the other WMI classes use the `root\cimv2` namespace
|
||||
* All identifiers are normalized to uppercase for matching
|
||||
* ByteSpeed systems with "NUC" in the model name are re-mapped to Intel and use `BaseBoardProduct` instead
|
||||
* For manufacturers that aren't listed, the default behavior is to use the `Win32_ComputerSystem` `model` string
|
||||
|
||||
Below is an example `DriverMapping.json` that includes the additional manufacturers. Note that the model and systemID information is made up and is used only as an example to show how to format the file. You'll need to collect the model or system ID from the locations in the table above and include it in your custom `DriverMapping.json` file. Each entry includes both a WIM and drivers folder for each manufacturer. If you want to include driver WIM files for manufacturers other than Dell, HP, Lenovo, or Microsoft, you'll need to manually compress the drivers folder to a WIM file.
|
||||
|
||||
```
|
||||
[
|
||||
{
|
||||
"Manufacturer": "Panasonic",
|
||||
"Model": "Toughbook CF-33",
|
||||
"SystemId": "CF-33LEHAGT1",
|
||||
"DriverPath": "Panasonic\\CF-33.wim"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "Panasonic",
|
||||
"Model": "Toughbook FZ-55",
|
||||
"SystemId": "FZ-55DZ0KVM",
|
||||
"DriverPath": "Panasonic\\FZ-55"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "Viglen",
|
||||
"Model": "Genie Desktop Pro",
|
||||
"SystemId": "VGN-GDP-2024",
|
||||
"DriverPath": "Viglen\\GeniePro"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "Viglen",
|
||||
"Model": "Omnino Mini",
|
||||
"SystemId": "VGN-OMN-M1",
|
||||
"DriverPath": "Viglen\\OmninoMini.wim"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "AZW",
|
||||
"Model": "SER5 Pro",
|
||||
"SystemId": "SER5-5800H",
|
||||
"DriverPath": "AZW\\SER5Pro.wim"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "AZW",
|
||||
"Model": "U59 Mini PC",
|
||||
"SystemId": "U59-N5095",
|
||||
"DriverPath": "AZW\\U59"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "Fujitsu",
|
||||
"Model": "LIFEBOOK U9312",
|
||||
"SystemId": "FPCM52921",
|
||||
"DriverPath": "Fujitsu\\LIFEBOOK-U9312"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "Fujitsu",
|
||||
"Model": "ESPRIMO D7010",
|
||||
"SystemId": "D3644-A1",
|
||||
"DriverPath": "Fujitsu\\D7010.wim"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "Getac",
|
||||
"Model": "F110 G6",
|
||||
"SystemId": "F110G6",
|
||||
"DriverPath": "Getac\\F110G6.wim"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "Getac",
|
||||
"Model": "B360 Pro",
|
||||
"SystemId": "B360PRO",
|
||||
"DriverPath": "Getac\\B360Pro"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "Intel",
|
||||
"Model": "NUC13ANHi7",
|
||||
"DriverPath": "Intel\\NUC13"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "Intel",
|
||||
"Model": "NUC12WSHi5",
|
||||
"DriverPath": "Intel\\NUC12.wim"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "ByteSpeed",
|
||||
"Model": "Tera 2450",
|
||||
"DriverPath": "ByteSpeed\\Tera2450.wim"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "ByteSpeed",
|
||||
"Model": "Celeritas X1",
|
||||
"DriverPath": "ByteSpeed\\CeleritasX1"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "Acer",
|
||||
"Model": "TravelMate P214-53",
|
||||
"DriverPath": "Acer\\TMP214"
|
||||
},
|
||||
{
|
||||
"Manufacturer": "ASUS",
|
||||
"Model": "ExpertBook B5402CVA",
|
||||
"DriverPath": "ASUS\\B5402.wim"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
{% include page_nav.html %}
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: Hyper-V Settings
|
||||
nav_order: 1
|
||||
prev_url: /ui_overview.html
|
||||
prev_label: UI Overview
|
||||
next_url: /windows_settings.html
|
||||
next_label: Windows Settings
|
||||
parent: UI Overview
|
||||
---
|
||||
# Hyper-V Settings
|
||||
|
||||

|
||||
|
||||
## VM Switch Name
|
||||
|
||||
Drop down of detected VM Switches. There's also an **Other** option which allows you to specify a VM Switch Name. The other option is useful in scenarios where the machine you're running the UI from isn't going to be the machine where you plan to build the FFU from.
|
||||
|
||||
## VM Host IP Address
|
||||
|
||||
IP address of the selected Hyper-V switch that will be used for FFU capture. The UI will auto-detected this based on the VM Switch that was selected.
|
||||
|
||||
If `$InstallApps` is set to `$true`, this parameter must be configured.
|
||||
|
||||
## Disk Size (GB)
|
||||
|
||||
Size of the virtual hard disk for the virtual machine. Default is a 50GB dynamic disk. You may want to increase the size if you're installing many apps.
|
||||
|
||||
## Memory (GB)
|
||||
|
||||
Amount of memory to allocate for the virtual machine. Recommended to use 8GB if possible, especially for Windows 11. Default is 4GB.
|
||||
|
||||
## Processors
|
||||
|
||||
Number of virtual processors for the virtual machine. Recommended to use at least 4. Default is 4.
|
||||
|
||||
## VM Location
|
||||
|
||||
Default is `$FFUDevelopmentPath\VM`. This is the location of the VHDX that gets created where Windows will be installed to.
|
||||
|
||||
## VM Name Prefix
|
||||
|
||||
Prefix for the generated VM. Default is _FFU.
|
||||
|
||||
## Logical Sector Size
|
||||
|
||||
Uint32 value of 512 or 4096. Useful for 4Kn drives or devices shipping with UFS drives. Default is 512.
|
||||
|
||||
There is some error-handling in the script that will call out mismatch issues with logical sector size. Unfortunately you will need to create a new FFU with the correct logical sector size as you can't convert a previously created FFU. Most should be fine with 512, but lower-end devices that used to ship with eMMC drives have now shifted to using UFS.
|
||||
|
||||
{% include page_nav.html %}
|
||||
|
After Width: | Height: | Size: 73 KiB |
|
After Width: | Height: | Size: 384 KiB |
|
After Width: | Height: | Size: 185 KiB |
|
After Width: | Height: | Size: 131 KiB |
|
After Width: | Height: | Size: 236 KiB |
|
After Width: | Height: | Size: 292 KiB |
|
After Width: | Height: | Size: 283 KiB |
|
After Width: | Height: | Size: 293 KiB |
|
After Width: | Height: | Size: 291 KiB |
|
After Width: | Height: | Size: 281 KiB |
|
After Width: | Height: | Size: 282 KiB |
|
After Width: | Height: | Size: 1.3 MiB |
|
After Width: | Height: | Size: 142 KiB |
|
After Width: | Height: | Size: 44 KiB |
|
After Width: | Height: | Size: 24 KiB |
|
After Width: | Height: | Size: 60 KiB |
|
After Width: | Height: | Size: 129 KiB |
|
After Width: | Height: | Size: 357 KiB |
|
After Width: | Height: | Size: 123 KiB |
|
After Width: | Height: | Size: 126 KiB |
|
After Width: | Height: | Size: 124 KiB |
|
After Width: | Height: | Size: 27 KiB |
|
After Width: | Height: | Size: 169 KiB |
|
After Width: | Height: | Size: 149 KiB |
|
After Width: | Height: | Size: 20 KiB |
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: Home
|
||||
nav_order: 0
|
||||
next_url: /prerequisites.html
|
||||
next_label: Prerequisites
|
||||
---
|
||||
# Using Full Flash Update (FFU) files to speed up Windows deployment
|
||||
|
||||
What if you could have a Windows image (Windows 10/11 or Server) that has:
|
||||
|
||||
- The latest Windows cumulative update
|
||||
- The latest .NET cumulative update
|
||||
- The latest Windows Defender Platform and Definition Updates
|
||||
- The latest version of Microsoft Edge
|
||||
- The latest version of OneDrive (Per-Machine)
|
||||
- The latest version of Microsoft 365 Apps/Office
|
||||
- The latest drivers from any of the major OEMs (Dell, HP, Lenovo, Microsoft) (yes, the latest, not some out of date enterprise CAB file from years ago)
|
||||
- Winget support so you can integrate any app available from Winget directly in your image
|
||||
- ARM64 support for the latest Copilot+ PCs
|
||||
- The ability to bring your own drivers and apps if necessary
|
||||
- Custom WinRE support
|
||||
|
||||
And the best part: it takes **less than two minutes to apply the image**, even with all of these updates added to the media. After setting Windows up and going through Autopilot or a provisioning package, total elapsed time ~10 minutes (depending on what Intune or your device management tool is deploying).
|
||||
|
||||
The Full-Flash update (FFU) process can automatically download the latest release of Windows 11, the updates mentioned above, and creates a USB drive that can be used to quickly reimage a machine.
|
||||
|
||||
{% include page_nav.html %}
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: Prerequisites
|
||||
nav_order: 1
|
||||
prev_url: /
|
||||
prev_label: Home
|
||||
next_url: /quickstart.html
|
||||
next_label: Quick Start
|
||||
---
|
||||
# Prerequisites
|
||||
|
||||
## Recommendations
|
||||
|
||||
If possible, use an unmanaged Windows 11 or Windows Server machine. In some environments we see security software (AV, EDR, Firewall, etc.) get in the way and cause issues with FFU Builder successfully completing a build.
|
||||
|
||||
### Disk space
|
||||
|
||||
FFU Builder creates a 50GB dynamic VHDX disk by default which can be configured larger if that's not big enough. When the latest updated Windows media is installed to the VHDX, the VHDX size by itself will be about 15GB or so. If you service the media with the latest CU, that could grow the VHDX by double (~30GB in this case). If you install Office, additional applications, drivers, etc. the VHDX can get large quick. The FFU capture process will compress the size significantly, but between the VHDX size, the Windows media, the application and driver source content, the captured FFU, WinPE, etc. you can easily have over 100GB of used space.
|
||||
|
||||
So err on the side of having more free disk space. **Recommended to have at least 100GB free disk space**.
|
||||
|
||||
## Enable Hyper-V
|
||||
|
||||
Follow the guide linked below to install Hyper-V on Windows client or Server
|
||||
|
||||
[Install Hyper-V in Windows and Windows Server \| Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/Install-Hyper-V?tabs=gui&pivots=windows)
|
||||
|
||||
## Install PowerShell 7
|
||||
|
||||
PowerShell 7 is required as of releases 2507+ onward.
|
||||
|
||||
[Installing PowerShell on Windows - PowerShell \| Microsoft Learn
|
||||
](https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-windows)
|
||||
|
||||
Recommended to use winget to install
|
||||
|
||||
`winget install --id Microsoft.PowerShell --source winget`
|
||||
|
||||
If you can't use winget, [download the MSI](https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-windows#installing-the-msi-package)
|
||||
|
||||
**Do not** use the Windows Store version as it has some [known limitations](https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-windows?view=powershell-7.5#known-limitations)
|
||||
|
||||
## Create Hyper-V Switch
|
||||
|
||||
Once Hyper-V has been enabled and you have rebooted, create either an external or internal switch. An external switch is preferred, but an internal switch can be used.
|
||||
|
||||
## Download and Extract the Latest Release
|
||||
|
||||
If you haven't [downloaded the latest release yet, do so](https://github.com/rbalsleyMSFT/FFU/releases)
|
||||
|
||||
Once downloaded, extract the zip file to `C:\FFUDevelopment`. You can use another location, just be sure set your FFUDevelopmentPath to the new location (e.g. `D:\FFUDevelopment`).
|
||||
|
||||
After extraction, you most likely will need to unblock the files as they'll be tagged with the mark of the web. In PowerShell run:
|
||||
|
||||
`dir "C:\FFUDevelopment" -Recurse | Unblock-File`
|
||||
|
||||
Replace `C:\FFUDevelopment` with the path you extracted the files to.
|
||||
|
||||
## Running BuildFFUVM_UI.ps1
|
||||
|
||||
Either run Terminal as Admin, making sure to select PowerShell, not Windows PowerShell, or PowerShell 7.5+ as Admin and run `C:\FFUDevelopment\BuildFFUVM_UI.ps1`
|
||||
|
||||
If all went well, you should see the FFU Builder UI
|
||||
|
||||

|
||||
|
||||
{% include page_nav.html %}
|
||||
@@ -0,0 +1,276 @@
|
||||
---
|
||||
title: Quick Start
|
||||
nav_order: 2
|
||||
prev_url: /prerequisites.html
|
||||
prev_label: Prerequisites
|
||||
next_url: /ui_overview.html
|
||||
next_label: UI Overview
|
||||
---
|
||||
# Quick Start
|
||||
|
||||
This is the quick start guide to getting started with FFU Builder. If you're new, start here to build your first FFU.
|
||||
|
||||
After following this guide, you will have a USB drive with an FFU that contains the following:
|
||||
|
||||
* Windows 11 25H2 (with your choice of architecture, language, SKU, and media type)
|
||||
* The latest
|
||||
* Windows and .NET Cumulative Updates
|
||||
* Defender definitions, platform updates, and Windows Security Center application update
|
||||
* Microsoft Edge
|
||||
* Microsoft OneDrive
|
||||
* Malicious Software Removal Tool (MSRT)
|
||||
* Microsoft 365 Apps (Current Channel)
|
||||
* Winget Applications (Optional)
|
||||
* Company Portal
|
||||
* Drivers (Optional)
|
||||
* In some cases drivers aren't necessary and you can get away with Windows Update providing drivers. We'll go over how to add drivers via the UI for Microsoft, HP, Lenovo, or Dell devices
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Follow the [prerequisites](/FFU/prerequisites.html) documentation before getting started.
|
||||
|
||||
## Hyper-V Settings
|
||||
|
||||
Click the Hyper-V Settings tab
|
||||
|
||||
You should be able to keep these settings at the defaults. For VM Switch Name and VM Host IP Address, you'll want to make sure the switch you created in the prerequisites section is listed. FFU Builder should automatically figure out the IP address of the swtich for you.
|
||||
|
||||
One setting you might need to set is the Logical Sector Size. 512 is the default and that's what most physical disks use today. However 4kn drives and UFS drives use 4k sector sizes, which would require you to select 4096. For now, select 512. If you have issues during deployment, there is error logging that will tell you if you need to set to 4096 on your device.
|
||||
|
||||
## Windows Settings
|
||||
|
||||
Click the Windows Settings tab
|
||||
|
||||
If you keep ISO Path blank, FFU Builder will download the ESD file that the Windows Media Creation Tool uses. Most people should leave this blank since the Media Creation Tool media ESD file is now kept up to date as of Windows 11 25H2 (it's usually updated 2-3 days after patch Tuesday). This reduces the need to service the media and saves time and disk space.
|
||||
|
||||
Change the Windows language to the one of your choosing.
|
||||
|
||||
Change the Windows SKU to either Home or Pro depending on what your physical device(s) shipped with. This is due to how activation works by Windows. If you match the media type and SKU with what the device shipped with, then Windows will activate using the key in the firmware. In most scenarios, selecting Pro and Consumer will be what you want.
|
||||
|
||||
Leave the other settings as is. There should be no need to provide a product key unless you're providing your own Windows ISO.
|
||||
|
||||
## Updates
|
||||
|
||||
Keep the defaults
|
||||
|
||||
## Applications (optional)
|
||||
|
||||
Click the Applications tab
|
||||
|
||||
In this quick start we'll be installing the winget published version of the Company Portal application. This is optional, but it's a common application that IT admins like to install that use Intune to manage their devices. If you want to use something else, feel free to replace Company Portal with another app.
|
||||
|
||||
You can also provide your own applications instead of, or in conjunction with, winget applications, however this guide will keep things simple and opt for using winget.
|
||||
|
||||
Check Install Winget Applications
|
||||
|
||||
Click Check Winget Status
|
||||
|
||||
In the Winget Search box search for Company Portal
|
||||
|
||||
If you see multiple applications, select the msstore source version of the Company Portal application (FFU Builder doesn't allow the winget source application to install due to how the application is packaged). Make sure to click the check box.
|
||||
|
||||
Click the Save AppList.json button
|
||||
|
||||
This will save an AppList.json file in your C:\FFUDevelopment\Apps folder and should look like this:
|
||||
|
||||
```json
|
||||
{
|
||||
"apps": [
|
||||
{
|
||||
"name": "Company Portal",
|
||||
"id": "9WZDNCRFJ3PZ",
|
||||
"source": "msstore",
|
||||
"architecture": "NA",
|
||||
"AdditionalExitCodes": "",
|
||||
"IgnoreNonZeroExitCodes": false
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> The AppList.json file is what controls winget application downloads during the FFU build process. You might also notice that you can download the application by clicking the Download Selected button. That will do a point in time download of the selected applications via winget and will also update the AppList.json file. At build time the BuildFFUVM.ps1 script will check the AppList.json file and will check if the apps exist. If they do, it will skip downloading the applications.
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> If your build machine isn't joined to Microsoft Entra, it will prompt you to authenticate twice to download any msstore source application. First for the application, and the second for the license file. This happens for each msstore source application. If this becomes annoying, you can run the FFUBuilder UI on an Entra joined machine (or hybrid joined) and download the apps you need and copy the Apps folder into the Apps folder on your build machine.
|
||||
|
||||
{: .tip-title}
|
||||
|
||||
> Tip
|
||||
>
|
||||
> To download winget applications with the msstore source, [you need one of the following rights on your account: Global Administrator, User Administrator, or License Administrator](https://learn.microsoft.com/en-us/windows/package-manager/winget/download#:~:text=The%20EntraID%20account%20used%20for%20authentication%20to%20generate%20and%20retrieve%20a%20Microsoft%20Store%20packaged%20app%20license%20file%20must%20be%20a%20member%20of%20one%20of%20the%20following%20three%20Azure%20roles%3A%20Global%20Administrator%2C%20User%20Administrator%2C%20or%20License%20Administrator.)
|
||||
|
||||
## M365 Apps/Office
|
||||
|
||||
FFU Builder uses the Office Deployment Tool to download and install Microsoft 365 Apps.
|
||||
|
||||
The default configuration will install the 64-bit current channel version of Office with Word, Excel, Powerpoint. It will download the currently installed language of the operating system (i.e. uses MatchOS for language), which is fine for most people, however if you need to specify the correct language, you'll need to make some modifications to the XML files.
|
||||
|
||||
Check the [M365 Apps/Office UI Overview page](/FFU/M365appsoffice.html) that explains the XMLs used in detail.
|
||||
|
||||
## Drivers
|
||||
|
||||
FFU Builder makes it easy to add drivers from the four major OEMs (Dell, HP, Lenovo, Microsoft). The difference between FFU Builder and other solutions is that FFU Builder tries to use the latest drivers from the OEM, not out-dated driver packages/CABs. This makes things somewhat more complicated to develop, but should make for a better experience where you have the most secure, up to date set of drivers available. It won't handle firmware/BIOS updates as Windows doesn't allow for servicing those types of updates.
|
||||
|
||||
**Bring Your Own Drivers**
|
||||
|
||||
You're also free to bring your own drivers instead of relying on using the drivers provided by FFU Builder. If you prefer the OEM cabs, you can download them and copy them to the `C:\FFUDevelopment\Drivers\<Make>\<Model>` folder where make is the name of the OEM and Model is the name of the model.
|
||||
|
||||
**WinPE Drivers**
|
||||
|
||||
FFU Builder also supports adding PE drivers. You can either copy your PE Drivers to the `C:\FFUDevelopment\PEDrivers` folder, or use the Drivers Folder as the PE drivers source. If you use the Drivers folder as the PE drivers source, the build script will find the appropriate driver class GUIDs for WinPE from the `C:\FFUDevelopment\Drivers` folder and copy them into the `C:\FFUDevelopment\PEDrivers` folder, overwriting what's currently in the PEDrivers folder.
|
||||
|
||||
For the purposes of this quick start, we'll use an HP EliteBook 850 G8 as the example model.
|
||||
|
||||
Click the Drivers tab and click the Download Drivers checkbox.
|
||||
|
||||
In the Make drop down, select HP and click Get Models. This may take 10-30 seconds to download the HP PlatformList.cab file and parse it. Once the file has been downloaded and parsed, the model listview will be populated with all of the HP models. Dell has a similar experience with downloading and parsing its Catalog XML file. Microsoft parses some webpages to generate a SurfaceDriverIndex.json
|
||||
|
||||
In the Model Filter text box, enter 850. This will filter down to all models that contain 850 in the model name. The model name column will list the model name and the system ID in parenthesis. The system ID is important because it's that value that is used at deployment time to automatically select which drivers to install if you've chosen to copy drivers to the USB drive instead of including them in the FFU file.
|
||||
|
||||
Select **HP EliteBook 850 G8 Notebook PC (8846)**
|
||||
|
||||
{: .tip-title}
|
||||
|
||||
> Tip
|
||||
>
|
||||
> If you need to manage multiple models, it's best to select **Copy Drivers to USB drive.** This will keep the FFU file small and allow FFU Builder to automatically select the right drivers at deployment time (based on the system information queried via WMI).
|
||||
>
|
||||
> If you select Install Drivers to FFU, you bloat the driver store with drivers you don't need, creating a larger FFU file and wasting disk space on the physical device. It's best to use this option when building an FFU for a single model.
|
||||
|
||||
To find the SystemID for HP, you can check BIOS/UEFI, or you can use PowerShell:
|
||||
|
||||
```powershell
|
||||
(Get-CimInstance -Namespace 'root\WMI' -Class MS_SystemInformation).BaseboardProduct
|
||||
```
|
||||
|
||||
Check **Copy Drivers to USB drive** (even though we're doing a single model in this quick start, most people will likely be managing many different models. The expectation is that most should be using **Copy Drivers to USB drive** in their workflows)
|
||||
|
||||
Your view should look like this:
|
||||
|
||||

|
||||
|
||||
At this point, you can either Save the Drivers.json file or click Download Selected. Clicking Save Drivers.json will save the Driver model information to the Drivers.json file which will be used at build time to download the drivers. Clicking Download Selected will download the drivers right now. This can be useful for testing without having to go through an entire build, or good for airgapped environments where you can download what you need from the internet on one network, and bring that over to the airgapped network.
|
||||
|
||||
For this quick start, click **Save Drivers.json** and save the file to the `C:\FFUDevelopment\Drivers` folder.
|
||||
|
||||
## Build
|
||||
|
||||
Click the Build tab
|
||||
|
||||
On the Build tab, click **Build USB Drive.**
|
||||
|
||||
Depending on your USB drive, it might be a removable drive or external hard disk media. If you're using a fast USB SSD, it's likely that Windows treats that drive as an external hard disk. If that's the case, you might need to click **Allow External Hard Disk Media.** If you do, you may also want to uncheck **Prompt for External Hard Disk Media.** This option is in place to prevent external hard disks from automatically being formatted when building the USB drive. If you don't have any external hard disks connected to your build machine, then it's safe to uncheck the **Prompt for External Hard Disk Media** option.
|
||||
|
||||
Another safety measure is **Select Specific USB Drives**. When you check **Select Specific USB Drives** a list view will pop up with a **Check USB drives** button. Clicking the **Check USB Drives** button will show all connected USB drives (removable or external hard disks). Select which drives you want.
|
||||
|
||||
**Device Naming**
|
||||
|
||||
Device naming can be done from PE. The way this works is by leveraging an unattend.xml file to either take input from the user at imaging time or read a list of prefix values and append the serial number of the device. There are some major benefits to doing this:
|
||||
|
||||
1. Total deployment time is reduced if naming is set at FFU deployment time since there is no additional reboot done during OOBE.
|
||||
2. Reduces the need for multiple provisioning packages or autopilot profiles. This means you can use a single PPKG or autopilot profile.
|
||||
|
||||
**Prompt for Device Name**
|
||||
|
||||
If you want to be prompted for the device name, simply check **Copy Unattend.xml.** This tells the build script to copy the appropriate architecture unattend_arch.xml file from the `C:\FFUDevelopment\Unattend` folder to the `.\unattend` folder on the deploy partition of the USB drive.
|
||||
|
||||
**Specifying Multiple Name Prefixes**
|
||||
|
||||
If you have multiple device name prefixes for different locations or device use cases, or even a single prefix, you can specify a prefixes.txt file in the `C:\FFUDevelopment\unattend` folder. If the prefixes.txt file is detected and a single prefix is listed, the device will just use that prefix and append the serial number of the device. If there are multiple prefixes listed in the prefixes.txt file, you will be prompted to select which prefix you want to name the device and the serial number will be appended to that prefix. If you want a dash in the name, include the dash in the prefix (e.g. if ABCD- is in the prefixes.txt file, the device name will be ABCD-SerialNumber).
|
||||
|
||||
{: .warning-title}
|
||||
|
||||
> Warning
|
||||
>
|
||||
> If using a provisioning package or autopilot json file, DO NOT specify a name in either of these. They will overwrite the name you have specified in the unattend.xml.
|
||||
|
||||
**Post Build Cleanup**
|
||||
|
||||
Leave the Post Build Cleanup section at the defaults
|
||||
|
||||
Your Build tab should look something like this:
|
||||
|
||||

|
||||
|
||||
Click **Build FFU**
|
||||
|
||||
Depending on your internet speed, speed of your build machine, etc. this will take some time (probably at least 20 minutes). After clicking Build FFU, you'll be automatically moved to the Monitor tab.
|
||||
|
||||
## Monitor
|
||||
|
||||

|
||||
|
||||
The monitor tab parses the `C:\FFUDevelopment\FFUDevelopment.log` file. If you'd like to use CMTrace or another tool to monitor the log, feel free. The monitor tab has some similar functionality to CMTrace. If you click off the last line of the log in the monitor tab it will stay on that line, allowing you to read what you have selected instead of the log autoscrolling. You can also copy one or multiple lines by selecting a line and shift+clicking the last line you want to select and hitting ctrl+c to copy the lines.
|
||||
|
||||
Now sit back, relax, and watch FFU Builder do its magic. You should see a VM pop up after everything is downloaded and Windows has been installed to the VHDX file (it may not if Hyper-V manager wasn't previously open). If you don't see a VM pop up, you can open up Hyper-V manager and look for a VM with a name that starts with **_FFU-.**
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> Don't interact with the VM (e.g. don't click into the PowerShell window that's orchestrating the install of the updates, apps, etc). The whole process should be completly automated with no user interaction necessary. If you click into the PowerShell window while it's working, you may get PowerShell into "select" mode. If this happens, the PowerShell window will look like it's "stuck." That's because clicking into a cmd/PowerShell window while something is in process and you're in select mode waits for you to exit select by hitting Enter.
|
||||
|
||||
## Post Build
|
||||
|
||||
Once the build is complete, you should have a USB drive with two partitions: Boot and Deploy.
|
||||
|
||||
The Boot partition is the WinPE Deployment media. It'll look like this:
|
||||
|
||||

|
||||
|
||||
The Deploy partition is where the FFU file, the Drivers folder, and Unattend folders should be.
|
||||
|
||||

|
||||
|
||||
The Drivers folder will have an HP folder, a DriverMapping.json and Drivers.json file.
|
||||
|
||||

|
||||
|
||||
The DriverMapping.json file is what's used to do automatic driver matching during deployment. FFU Builder will read this file and match on the SystemID to know which driver folder to apply. Since there's only a single driver folder in this example, the file is fairly simple to understand. When you have multiple models and OEMs, the file gets a bit more complex.
|
||||
|
||||
The DriverMapping.json should look like this:
|
||||
|
||||
```json
|
||||
{
|
||||
"Manufacturer": "HP",
|
||||
"Model": "HP EliteBook 850 G8 Notebook PC (8846)",
|
||||
"DriverPath": "HP\\HP EliteBook 850 G8 Notebook PC (8846)",
|
||||
"SystemId": "8846"
|
||||
}
|
||||
```
|
||||
|
||||
The HP EliteBook 850 driver folder should be populated with the various driver categories:
|
||||
|
||||

|
||||
|
||||
And the Unattend folder should have an unattend.xml file with the following content:
|
||||
|
||||
```xml
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<unattend xmlns="urn:schemas-microsoft-com:unattend">
|
||||
<settings pass="specialize">
|
||||
<!--<ComputerName> must be in the first Component Element "Microsoft-Windows-Shell-Setup" . Do not change the order or remove it -->
|
||||
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
|
||||
<ComputerName>MyComputer</ComputerName>
|
||||
</component>
|
||||
<!--Place addtional Components Elements and settings below here. -->
|
||||
</settings>
|
||||
</unattend>
|
||||
```
|
||||
|
||||
Now you're ready to deploy the FFU to your device.
|
||||
|
||||
## Deployment
|
||||
|
||||
Deployment should be fairly straight forward: boot off the USB device, get prompted for a device name, and the deployment of the FFU and drivers should happen automatically.
|
||||
|
||||
If you have any questions or run into any issues, [open a discussion in the Github repo](https://github.com/rbalsleyMSFT/FFU/discussions).
|
||||
|
||||
{% include page_nav.html %}
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: UI Overview
|
||||
nav_order: 3
|
||||
prev_url: /prerequisites.html
|
||||
prev_label: Prerequisites
|
||||
next_url: /hyperv_settings.html
|
||||
next_label: Hyper-V Settings
|
||||
has_toc: false
|
||||
---
|
||||
# UI Overview
|
||||
|
||||

|
||||
|
||||
The user interface has 9 distinct tabs for easy navigation.
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: Updates
|
||||
nav_order: 3
|
||||
prev_url: /windows_settings.html
|
||||
prev_label: Windows Settings
|
||||
next_url: /applications.html
|
||||
next_label: Applications
|
||||
parent: UI Overview
|
||||
---
|
||||
# Updates
|
||||
|
||||

|
||||
|
||||
## Update Latest Cumulative Update
|
||||
|
||||
Controls the `-UpdateLatestCU` parameter. When set to `$true`, will download and install the latest cumulative update for Windows.
|
||||
|
||||
## Update .NET
|
||||
|
||||
Controls the `-UpdateLatestNet` parameter. When set to `$true`, will download and install the latest .NET framework update for Windows.
|
||||
|
||||
## Update Defender
|
||||
|
||||
Controls the `-UpdateLatestDefender` parameter. When set to `$true`, will download and install the latest Windows Defender definitions, Defender platform, and Windows Security app update.
|
||||
|
||||
## Update Edge
|
||||
|
||||
Controls the `-UpdateEdge` parameter. When set to `$true`, will download and install the latest Microsoft Edge browser.
|
||||
|
||||
## Update OneDrive (per-machine)
|
||||
|
||||
Controls the `-UpdateOneDrive` parameter. When set to `$true`, will download and install the latest OneDrive and install it as per-machine instead of per-user.
|
||||
|
||||
## Update Microsoft Software Removal Tool (MSRT)
|
||||
|
||||
Controls the `-UpdateLatestMSRT` parameter. When set to `$true`, will download and install the latest Windows Malicious Software Removal Tool.
|
||||
|
||||
## Update Latest Microcode (for LTSC/Server 2016/2019)
|
||||
|
||||
Controls the `-UpdateLatestMicrocode` parameter. When set to `$true`, will download and install the latest microcode updates for applicable Windows releases (e.g., Windows Server 2016/2019, Windows 10 LTSC 2016/2019) into the FFU.
|
||||
|
||||
## Update Preview Cumulative Update
|
||||
|
||||
Controls the `-UpdatePreviewCU` parameter. When set to `$true`, will download and install the latest preview cumulative update for Windows.
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> The UI will only allow one of **Update Latest CU** or **Update Preview CU** to be checked to prevent both being applied.
|
||||
|
||||
{% include page_nav.html %}
|
||||
@@ -0,0 +1,147 @@
|
||||
---
|
||||
title: Windows Settings
|
||||
nav_order: 2
|
||||
prev_url: /hyperv_settings.html
|
||||
prev_label: Hyper-V Settings
|
||||
next_url: /updates.html
|
||||
next_label: Updates
|
||||
parent: UI Overview
|
||||
---
|
||||
# Windows Settings
|
||||
|
||||

|
||||
|
||||
## Windows ISO Path
|
||||
|
||||
Path to Windows 10/11 ISO file. If left blank, FFU Builder will download the latest version of Windows 10 or 11 from the Media Creation Tool.
|
||||
|
||||
{: .tip-title}
|
||||
|
||||
> Tip
|
||||
>
|
||||
> Should I provide my own ISO, or let FFU Builder download the media
|
||||
>
|
||||
> It's recommended to use the latest updated ISO from Visual Studio Downloads, or the Media Creation tool. See the Media Type section below for a better understanding of business and consumer media and how it impacts Subscription Activation.
|
||||
|
||||
## Windows Release
|
||||
|
||||
Integer value of 10 or 11. This is used to identify which release of Windows to download. Default is 11.
|
||||
|
||||
## Windows Version
|
||||
|
||||
String value of the Windows version. Default is `25H2`. If an ISO is not specified, this drop down is disabled. If an ISO is specified, you can select from the drop down which version of Windows you're installing. The Windows version is used in quite a few different scenarios (HP driver downloads, VHDXCaching, MCT media downloads, FFU file naming, and cumulative update downloads), so it's important you specify the correct Windows Version.
|
||||
|
||||
## Windows Architecture
|
||||
|
||||
String value of `x86`, `x64`, or `arm64`. Depending on the Windows release and Windows version, the UI will only specify the supported architecture types for a specific Release/Version combo.
|
||||
|
||||
## Windows Language
|
||||
|
||||
String value in language-region format (e.g., `en-us`). This is used to identify which language of media to download. Default is `en-us`.
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> These are the supported languages that can be used with the `-WindowsLang` parameter when downloading the Windows MCT\ESD file
|
||||
>
|
||||
> ar-sa
|
||||
> bg-bg
|
||||
> cs-cz
|
||||
> da-dk
|
||||
> de-de
|
||||
> el-gr
|
||||
> en-gb
|
||||
> en-us
|
||||
> es-es
|
||||
> es-mx
|
||||
> et-ee
|
||||
> fi-fi
|
||||
> fr-ca
|
||||
> fr-fr
|
||||
> he-il
|
||||
> hr-hr
|
||||
> hu-hu
|
||||
> it-it
|
||||
> ja-jp
|
||||
> ko-kr
|
||||
> lt-lt
|
||||
> lv-lv
|
||||
> nb-no
|
||||
> nl-nl
|
||||
> pl-pl
|
||||
> pt-br
|
||||
> pt-pt
|
||||
> ro-ro
|
||||
> ru-ru
|
||||
> sk-sk
|
||||
> sl-si
|
||||
> sr-latn-rs
|
||||
> sv-se
|
||||
> th-th
|
||||
> tr-tr
|
||||
> uk-ua
|
||||
> zh-cn
|
||||
> zh-tw
|
||||
|
||||
## Windows SKU
|
||||
|
||||
Edition of Windows 10/11/LTSC/Server to be installed.
|
||||
|
||||
{: .note-title}
|
||||
|
||||
> Note
|
||||
>
|
||||
> The following SKUs are supported
|
||||
>
|
||||
> Home
|
||||
> Home N
|
||||
> Home Single Language
|
||||
> Education
|
||||
> Education N
|
||||
> Pro
|
||||
> Pro N
|
||||
> Pro Education
|
||||
> Pro Education N
|
||||
> Pro for Workstations
|
||||
> Pro N for Workstations
|
||||
> Enterprise
|
||||
> Enterprise N
|
||||
> Enterprise 2016 LTSB
|
||||
> Enterprise N 2016 LTSB
|
||||
> Enterprise LTSC
|
||||
> Enterprise N LTSC
|
||||
> IoT Enterprise LTSC
|
||||
> IoT Enterprise N LTSC
|
||||
> Standard
|
||||
> Standard (Desktop Experience)
|
||||
> Datacenter
|
||||
> Datacenter (Desktop Experience)
|
||||
|
||||
## Media Type
|
||||
|
||||
String value of either `business` or `consumer`. This is used to identify which media type to download if not providing an ISO. Default is `consumer`
|
||||
|
||||
{: .tip-title}
|
||||
|
||||
> Tip
|
||||
>
|
||||
> Recommendation on media type to use
|
||||
>
|
||||
> Windows media comes in two types: business or consumer.
|
||||
>
|
||||
> Windows media can be obtained from a few different sources: Volume Licensing Service Center (VLSC – now available at admin.microsoft.com), Microsoft Visual Studio Downloads, or the Windows Media Creation Tool.
|
||||
>
|
||||
> The `BuildFFUVM.ps1` script will allow you to pass whichever type of media you want from whatever source you want using the -ISOPath parameter; however, **it’s recommended that you use consumer media**, not business/VL. This is because Subscription Activation will fail if the media is mismatched from the key in the firmware.
|
||||
>
|
||||
> If you plan on using a MAK or KMS to activate, you can use media from VLSC, but if you expect the device to activate automatically and upgrade to Enterprise or Education SKUs via Subscription Activation, you must use consumer media. To use a MAK/KMS key to activate, you must provide the -`ProductKey XXXXX-XXXXX-XXXXX-XXXXX-XXXXX` parameter.
|
||||
|
||||
## Product Key
|
||||
|
||||
Product key for the Windows edition specified in WindowsSKU. This will overwrite whatever SKU is entered for WindowsSKU. Recommended to use if you want to use a MAK or KMS key to activate Enterprise or Education. If using VL media instead of consumer media, you'll want to enter a MAK or KMS key here.
|
||||
|
||||
## Optional Features
|
||||
|
||||
A list of optional features that you can enable for the version of Windows you're installing (e.g. netfx3; TFTP).
|
||||
|
||||
{% include page_nav.html %}
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
title: Install Winget Applications
|
||||
nav_order: 5
|
||||
prev_url: /applications.html
|
||||
prev_label: Applications
|
||||
next_url: /byoapps.html
|
||||
next_label: BYO Applications
|
||||
parent: Applications
|
||||
grand_parent: UI Overview
|
||||
---
|
||||
# Install Winget Applications
|
||||
|
||||

|
||||
|
||||
## Check Winget Status
|
||||
|
||||
Installing Winget applications requires that both the winget CLI and Microsoft.Winget.Client PowerShell module to be installed. Minimum required version of both the CLI and PowerShell module is 1.8.1911.
|
||||
|
||||
Click **Check Winget Status** to validate the versions of both the CLI and PowerShell module. If older than the minimum required version, will be updated to the latest version.
|
||||
|
||||

|
||||
|
||||
After validating Winget status, you'll be able to search winget for applications. The larger the result set, the longer it will take for the list view to be populated. For example, if searching for **win**, the UI might appear to hang while it searches for apps with a name or id of **win** due to 669 results being returned and processed. Instead, if you search for **windows app**, 13 results are returned within a few seconds.
|
||||
|
||||
The UI allows for multi-selection of applications
|
||||
|
||||

|
||||
|
||||
You can also change the architecture, add additional exit codes, or ignore exit codes completely.
|
||||
|
||||
## Architecture
|
||||
|
||||

|
||||
|
||||
FFU Builder supports x86, x64, arm64, and x86/x64 (both) for applications in the winget source repository. For apps in the msstore source repository, the architecture cannot be changed. In most cases, x64 will be what you want, however in some cases the combo of x86 and x64 will be necessary. This might be due to runtimes (.NET, Visual C++) where an application is expecting both x86 and x64 runtimes.
|
||||
|
||||
## Additional Exit Codes
|
||||
|
||||
You can provide a comma separated list of additional exit codes if your application doesn't exit with 0. Some apps may exit with a non-zero exit code.
|
||||
|
||||
## Ignore Exit Codes
|
||||
|
||||
If you know your application exits with some random exit code or simply don't care to populate a list of approved exit codes, check the box to ignore exit codes and FFU Builder will ignore the exit code and continue on.
|
||||
|
||||
## Download Status
|
||||
|
||||
FFU Builder allows you to download applications prior to deployment. When clicking the Download Selected button, the Download Status column tracks the status of the download and outputs success, or in the case of an error, the reason why the download may have failed.
|
||||
|
||||
## Save AppList.json
|
||||
|
||||
FFU Builder leverages a number of json files to tell the `BuildFFUVM.ps1` script what to do during deployment time. `AppList.json` controls the Winget application download and installation.
|
||||
|
||||
The `AppList.json` file gets created when clicking **Download Selected**, or clicking the **Save AppList.json** file. The default path for the `AppList.json` file is `$AppsPath\AppList.json`
|
||||
|
||||
An example of the `AppList.json` file:
|
||||
|
||||
```json
|
||||
{
|
||||
"apps": [
|
||||
{
|
||||
"name": "Windows App",
|
||||
"id": "Microsoft.WindowsApp",
|
||||
"source": "winget",
|
||||
"architecture": "x64",
|
||||
"AdditionalExitCodes": "",
|
||||
"IgnoreNonZeroExitCodes": false
|
||||
},
|
||||
{
|
||||
"name": "VLC media player",
|
||||
"id": "VideoLAN.VLC",
|
||||
"source": "winget",
|
||||
"architecture": "x64",
|
||||
"AdditionalExitCodes": "",
|
||||
"IgnoreNonZeroExitCodes": false
|
||||
},
|
||||
{
|
||||
"name": "Snagit 2025",
|
||||
"id": "TechSmith.Snagit.2025",
|
||||
"source": "winget",
|
||||
"architecture": "x64",
|
||||
"AdditionalExitCodes": "",
|
||||
"IgnoreNonZeroExitCodes": false
|
||||
},
|
||||
{
|
||||
"name": "Company Portal",
|
||||
"id": "9WZDNCRFJ3PZ",
|
||||
"source": "msstore",
|
||||
"architecture": "NA",
|
||||
"AdditionalExitCodes": "",
|
||||
"IgnoreNonZeroExitCodes": false
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Import AppList.json
|
||||
|
||||
If you have a previously saved `AppList.json` you want to use or modify, you can import an `AppList.json` file.
|
||||
|
||||
## Download Selected
|
||||
|
||||
As mentioned in the Download Selected section above, FFU Builder allows you to download applications prior to deployment. When clicking the Download Selected button, the Download Status column tracks the status of the download and outputs success, or in the case of an error, the reason why the download may have failed. By default it will download five applications at a time. This is controlled by the
|
||||
|
||||
Apps are downloaded to `.\FFUDevelopment\Apps\Win32\<AppName>` or `.\FFUDevelopment\Apps\MSStore\<AppName>` depending on the winget source value. Each application will have the app installation files and a yaml manifest file. For Win32 applications, FFU Builder parses the yaml file to grab the silent install switches needed for silent application installation at build time.
|
||||
|
||||
{: .tip-title}
|
||||
|
||||
> Tip
|
||||
>
|
||||
> When downloading msstore source applications, Microsoft requires applications to be downloaded with a license file (the Winget PowerShell module doesn't allow the option to skip downloading the license like the winget CLI does). This requires authentication via Entra ID. If using a device joined to Entra and signed in with your Entra ID, SSO will bypass the need to re-authenticate to download the app and license file. If the machine you are running FFU Builder on is not joined to Entra ID, you will be prompted twice to download the application and the license file.
|
||||
>
|
||||
> It's recommended that if you are downloading a lot of msstore source applications, do it from a machine that's joined to Entra ID.
|
||||
|
||||
## Clear List
|
||||
|
||||
The Clear List button will clear the list view of what's currently in it. It will not clear the AppList.json file if it exists.
|
||||
|
||||
{% include page_nav.html %}
|
||||