Successful Wireless Imaging

Article
2017-10-12

Question

_{Thursday, October 12, 2017 5:51 PM}

Figured I would post my findings for others who desire wireless imaging.
"Where there's a will, there's an IT guy to find a way."

After months of hunting and searching for solutions and coming up with nothing, I found a means of Task Sequence deployment over wireless and decided to share with the community. Note that I have yet to discover a means of PXE booting over wireless, but Task Sequence deployment on bootable devices is a good start.

The first step is export the wireless profile of your choice to an XML and save it for later—WPA2 is what we use for this hidden network. I called my exported profile “wifiprofile.xml”—original, I know.

Next you’ll mount the ISO for Windows 10 1607 (or newer) and extract the sources\image.wim and place it in your directory of choice for DISM work—mine is C:\TEMP and all commands referenced below will follow that convention.

I then create C:\TEMP\MOUNT and C:\TEMP\winre folders.

I have compiled information from various other sources across the internet that I wish I could cite, but here are the commands to execute in order to extract the WinRE.wim file (which supports wireless imaging), inject my wireless profile, then create a boot(able) image from that:

"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\dism.exe" /Mount-Image /ImageFile:C:\TEMP\install.wim /Index:1 /MountDir:C:\temp\mount

copy /y “C:\TEMP\mount\windows\windows\system32\recovery\winre.wim” C:\TEMP\

attrib -s -h C:\temp\winre.wim

Dism /Mount-Image /ImageFile:c:\temp\winre.wim /Index:1 /MountDir:C:\temp\winre

"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\dism.exe" /Mount-Image /ImageFile:c:\temp\winre.wim /Index:1 /MountDir:C:\temp\winre

attrib -R c:\temp\winre\windows\system32\winpeshl.ini

copy /y C:\temp\MOUNT\windows\system32\dmcmnutils.dll C:\temp\winre\windows\system32\

copy /y C:\temp\MOUNT\windows\system32\mdmpostprocessevaluator.dll c:\temp\winre\windows\system32\

copy /y C:\temp\MOUNT\windows\system32\mdmregistration.dll c:\temp\winre\windows\system32\

"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\dism.exe" /Unmount-Image /MountDir:C:\temp\MOUNT /discard

Now you can copy your wifiprofile.xml into the C:\temp\winre\windows\ folder which we will commit in the next few steps. You’ll see why we need to inject the wireless profile into the image—specifically in the Windows directory—In order to call on its variable location throughout the deployment. You will also want to take your system image and mount it in like manner to inject the wifiprofile.xml into its Windows directory.

Commit the changes:

"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\dism.exe" /Image:c:\temp\winre /Cleanup-Image /StartComponentCleanup /ResetBase

"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\dism.exe" /Unmount-Image /MountDir:C:\TEMP\winre /commit

"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\dism.exe" /Export-Image /SourceImageFile:c:\temp\winre.wim /SourceIndex:1 /DestinationImageFile:c:\temp\winpe-wifi.wim

I know it looks sloppy, but it works. You've just created a WiFi-enabled boot image and successfully loaded the WiFi profile into the %windir% folder. When you're all done you'll have a new "winpe-wifi.wim" that you can then load into SCCM.

Add the new boot image to SCCM but before you distribute it, edit the properties. You'll want to add any additional (wireless) drivers to your image here and configure a prestart command—the most important part!

The prestart command I use is:

cmd /c net start wlansvc & cmd /c netsh wlan add profile filename=%windir%\wifiprofile.xml & cmd /c netsh wlan connect profile=YOURs ssid=YOURs

The result of the above command is starting the WLAN service, importing the WiFi profile (from our variable location) then connecting to the provided WiFi network.

I then perform a "run command line" step of the above commands in the Task Sequence after every reboot which ensures we stay connected during the whole imaging process. NOTE: This is why your wifiprofile.xml MUST be in both you boot.wim and your image.wim in order to be called upon after WinRE has exited.

Using this process, the PC will cache the WinRE boot image while booted in Windows, reboot at the assigned time and connect to WiFi to run the Task Sequence. For devices that won't boot and need imaging from a cold start, I created an ISO of the Task Sequence Media (with just the boot image) with the unattended flag enabled and the same prestart command. Load that ISO onto a thumb drive and staff at remote campuses can boot to the thumb drive and the Task Sequence will being automatically over wireless.

I have tested this on a USB boot and from the desktop. OS upgrades or clean install-task sequences can be performed ether way. I won’t sugar-coat it, the process takes a while depending on the size of the task sequence. My standard deployment with all the bells and whistles takes 6 PCs 10 hours over wireless so ensure your maintenance windows are long enough to accommodate and your networking team isn’t planning any changes that night.

The key to success was using WinRE rather than WinPE as Windows Recover Environment supports wireless imaging for Surface Pro devices to restore from the cloud. The last task sequence step is to remove the wifiprofile.xml from %windir% as it is stored in plain text.

Not sure why Microsoft has made this so difficult but there it is, wireless imaging with SCCM.

All replies (29)

_{Monday, December 18, 2017 10:06 PM}

After further testing, I have verified that a Task Sequence (full OS deployment) can be deployed via-Wi-Fi from the OS by modifying the startnet.cmd within the WinRE boot image (detailed information on its location can be found here).

This file inherently calls on winpeshl.exe which loads its settings from the winpeshl.ini file, however, both files are reset after loading the boot image to the DP in SCCM. To make your customizations stick, distribute your boot.wim to the DP and a new WIM package will be created in the same folder (boot-PM1000057.wim, as an example). Mount THIS wim file, modify the startnet.cmd file, and replace the origional. SCCM will not wipe these changes because it won't know it's there--a greater understand of these processes can be found here.

In a wireless situation, when winpeshl.exe loads, no network is available which results in an immediate failure.

By modifying startnet.cmd to FIRST call on your %windir%\connect.bat (as mentioned in the initial post), the network will have been established and winpeshl.exe will proceed by locating its policy.

I have also modified my connect.bat to initialize all network adapters (which loads the unconventional wireless drivers), load the wireless profile, connects to the wireless and finally tries pinging the DP. If the ping fails, a loop retries the script until the DP can be contacted. I do this because the wireless would connect a moment too slow and the task sequence would fail.

I also changed the prestart command to simply call on this batch file with %windir%\connect.bat and it's periodically called on during the TS after each reboot.

This modified script is as follows:

%windir%\System32\wpeinit.exe -InitializeNetwork

net start wlansvc
netsh wlan add profile filename=%windir%\wifiprofile.xml

:loop
  ping ip.of.the.dp
  IF %ERRORLEVEL% equ 0 goto :connected
  netsh wlan add profile filename=%windir%\wifiprofile.xml 
  netsh wlan connect name=YOURSSID ssid=YOURSSID | echo Connecting to YOURSSID
  ping localhost -n 7 >nul
goto :loop

:connected
ping localhost -n 7 >null
exit

I will be continually adding to this post (even if no one ever replies) to keep folks informed of my struggles and triumphs since I cannot find anyone else documenting their attempts. I'll keep the info flowing in case others want to try a similar strategy in their organization.

Cheers!

_{Thursday, March 1, 2018 3:14 PM}

Hi Joseph,

Thanks for your detailed report! It helped me a lot to get where I am now. I searched a lot until I found your report, that is finally helpful!

I've successfully built a wifi-enabled winpe, added it as base image to MDT and edited MDTs Unattend_PEx64.xml to run connect.bat before trying to connect to the deployment share.

Installation of a ready built image through a task-sequence of MDT works until after the oobe, where at some point it complains that it can't find the deployment share. Running connect.bat by hand and clicking retry solves this, but i need an automatic solution for this.

Do you have a point for me to look for to get that working?

Thanks for sharing your insight

Markus

Edit: From the logs it looks like "State restore" is the problem. If I understand that correctly, it immediatly calls ZTINicConfig, and that will check for the availiable DeploymentShare. Adding a Task to the sequence right at the start of state restore did not help. It won't be executed

_{Thursday, March 1, 2018 5:07 PM}

Could you provide a screenshot of your task sequence? You can see from my attached screenshot that I call the connect.bat after every reboot. You will also notice that I have a separate "Join Domain" step down below. I found the "apply network settings" step did not reliably join the device to the domain, resulting in inaccessible file shares.

I also updated this thread with some pertinent changes to ease the pain of building the image. See above and let me know if you can provide a screenshot..

_{Thursday, March 1, 2018 5:13 PM}

Ease the pain of building your image and enhance the reliability of wireless imaging by creating the following files to be injected into the WinRE.wim (automatically) during distribution in SCCM.

Winpeshl.exe – cold/network/media boot

Create a txt file in

C:\Program Files\Microsoft Configuration Manager\OSD\bin\x64\

Name it winpeshl.ini and add the following lines:

[LaunchApps]

%windir%\connect.bat

%SYSTEMDRIVE%\sms\bin\x64\TsBootShell.exe

TsBootShell.ini – cold/network/media/Software Center (from OS) boot

Create a txt file in

C:\Program Files\Microsoft Configuration Manager\OSD\bin\x64\

Name it TsBootShell.ini and add the following lines:

[Shell]

OrgName=

EnableDebugShell=true

Run=%windir%\prestart.cmd

These files are injected into the image during distribution to the DP—no matter what image you have.

Refer here for an understanding of the boot process and the significance of these files. During a boot from a Task Sequence Media or PXE, the boot process starts with the winpeshl.exe. If no network adapters are ready by the time winpeshl.exe finishes execution, the TS will fail. The winpeshl.ini with connect.bat line in there starts wpeinit.exe –InitializeNetwork and starts the wlansvc, enabling a functional network interface. Once our connect.bat has established a ping to our DP, winpeshl launches the TsBootShell.exe.

The auto-generated TsBootShell.ini typically has one command in it to run tsmbootstrap.exe and kick off the GUI and/or proceed with policy retrieval (if unattended). So we replace that line with run=%windir%\prestart.cmd and our prestart is ALMOST exactly the same as our connect.bat:

Prestart.cmd:

%windir%\System32\wpeinit.exe
-InitializeNetwork

net start wlansvc

netsh wlan add profile filename=%windir%\wifiprofile.xml

:loop

 
ping IP.of.Your.DP

IF %ERRORLEVEL% equ 0 goto :connected

netsh wlan add profile filename=%windir%\wifiprofile.xml 

netsh wlan connect name=YOURSSID ssid=YOURSSID 
 
ping localhost -n 7 >nul

goto :loop
:connectedping localhost -n 7 >null
Run=X:\sms\bin\x64\TsmBootstrap.exe /env:WinPE /configpath:%CONFIGPATH%

The exit command is removed and the last line is the magic that points back to the task sequence initialization that we skipped in the TsBootShell.ini.

Mount the Windows.wim that is to be deployed: Add the connect.bat and the wifiprofile.xml to the Windows directory.

WHY???
This redundant step exists because when a device boots into WinRE from the OS it skips the winpeshl.exe phase of the boot sequence. This is done because an answer file is generated during the “reboot into PE” step of the Task Sequence and it believes it has all the info necessary to initialize the network and proceed with imaging. However, it is not sophisticated enough to initialize the wlansvc because that service does not exists in a typical WinPE boot disk (remember, this is a WinRE boot disk which does have the wireless service stack). So when a PC reboots from the OS into the Win Pre-installation Environment (Win Recovery Environment) and skips the winpeshl.exe and goes straight to TSBootShell.exe, our prestart.cmd will connect to the wireless THEN fire off the task sequence.

_{Tuesday, March 6, 2018 12:33 PM}

Thanks again Joseph!

I'm currently not using SCCM but plain MDT, but your answer helped anyway. Booting into WinPE/Re with wifi works flawlessly now - the problem to reconnect to the deployment-share after oobe (i think thats how the 'Hello, we are preparing windows for you'-screens are called) of the deployed OS.

The Wizzard at some point there tell me, that there is no connection. I then open up taskmgr, exec a cmd and start connect.bat - after that tell the wizzard to retry and everything goes on.

I traced that down to the LiteTouch.wsf Function ValidateDeployRootWithRecovery. I think I need some kind of wpeinit.ini-hack to execute before liteTouch. Or I need to get my head into wsf scripting to fire the connect.bat from inside the LiteTouch.wsf

The DomainJoin is also not working atm - but I think the other step is the first to fix. See my attached TaskSequence [no image atm, wasnt able to upload] - Basically a plain "Standard Client Task Sequence", with the connect-to-wifi step added where I found reboots to take place.

_{Tuesday, March 6, 2018 4:28 PM}

I think this might point you in the right direction:

"The trick is delaying the LiteTouch.wsf from trying to execute the next task before network connectivity is available... [Read More]"

Let me know you findings, please! I am very interesting in maintaining this post for anyone trying to master wireless imaging in their organization.

On a side note, following my own documentation I assisted a "partner" organization with implementing this solution in their SCCM environment and with little variation they were able to replicate my work are now successfully imaging 10-20 Surface Pro devices at a time over wireless.

_{Wednesday, March 7, 2018 6:25 PM}

I was now successful, running a cloning task-sequence with plain mdt via wifi. Only for initial WinPE-Boot I used pxe via wds to kick off the WinPE-Boot (only because of lack of usb boot-media).

My steps were:

generate a wifi enabled winPE/RE-Image using your steps above
adapt your connect.bat to call "wpeutil.exe InitializeNetwork" instead of wpeinit, as the latter will kick of the task-sequence immediately
Adapt winpeshl.ini to fire up connect.bat before starting the task-sequence
inject connect.bat, winpeshl.ini and wifiprofile.xml into the winPE-Image with MDTs 'WinPE customization -> extra directory to add' feature
inject connect.bat and wifiprofile.xml in C:\Windows of the captured, to-be-deployed Windows-Image by mounting it with dism
Add some 'connectToWifi'-Steps into the task sequence
Adapt LiteTouch.wsf to connect to wifi before trying to connect to the deploymentshare inside of ValidateDeployRootWithRecovery (see [1])

As it stands now, I'ts running. Step 7 was the key to success - as some stuff simply failed at ZTINicConfig, trying to validate the nic configuration by connecting to the deployment share, what obviously won't work without wifi. As that is in place now, I think that Step 6 is redundant - the connection will always be already established whenever such a task is run. I will do further tests to verify that - but for the moment I'm happy with the current state.

Step 7 could maybe also be replaced by a custom FirstStartCommand in unattend.xml - I only recently figured out that I configured that wrong when it wasn't working. That would allow to do the whole process without adapting the scripts of MDT by hand. I will also experiment with that in near future.

The failed domain-join was due to missconfigured LAN, it didn't even work to join by hand. Once that was fixed, joining was flawlessly during wifi-cloning.

Thanks for your effort documenting that - let's hope others will find this usefull when they come accross the problem. The www is full of questions regarding this process, but none of the sparse answers are actually complete.

[1]

Function ValidateDeployRootWithRecoveryDim...

Set oShell = CreateObject("WScript.Shell")
oShell.run "%windir%\connect.batIf oUtility.ValidateConnectionEx(...)

_{Thursday, April 11, 2019 1:19 PM}

I know this is kind of old now, but you have left out some details here. You allude to a connect.bat that all mention of previously have been removed.

Also, what is the difference between your startnet fix and a prestart command with the same lines? It seems redundant. If one should be removed, is it the prestart command?

Edit: I think I get it after reading and re-reading. But a single full guide to this entire process is kind of needed at this point.

_{Thursday, April 11, 2019 5:44 PM}

This redundant step exists because when a device boots into WinRE from the OS it skips the winpeshl.exe phase of the boot sequence. This is done because an answer file is generated during the “reboot into PE” step of the Task Sequence and it believes it has all the info necessary to initialize the network and proceed with imaging. However, it is not sophisticated enough to initialize the wlansvc because that service does not exists in a typical WinPE boot disk (remember, this is a WinRE boot disk which does have the wireless service stack). So when a PC reboots from the OS into the Win Pre-installation Environment (Win Recovery Environment) and skips the winpeshl.exe and goes straight to TSBootShell.exe, our prestart.cmd will connect to the wireless THEN fire off the task sequence.

Okay when I do this on a boot.wim for usb media, it just shuts down because tsbootshell gets rid of the task sequence thing coming up. If I use stock tsbootshell, it will load but won't have wifi. I can then run connect.bat manually and get it going.

I didn't use the exact scripts you did for prestart with the looping, I just had it try to ping for 30 seconds. Is that screwing it up or is there something else?

_{Thursday, April 11, 2019 6:53 PM}

By request, I have recompiled the information above into one unified guide. Glad to know this resource is still proving useful!

Summary: Obtain a WinRE.wim image from a Windows 10 ISO version 1607 or newer which supports the wireless network stack. Create a wireless profile in XML format. Create a script to call and connect to the wireless profile stored in XML format.
Modify the built-in network management scripts used by SCCM/MDT for the Pre-Installation Environment (Recovery Environment, in this case).Commit wireless drivers necessary to connect the WinRE image via WLAN.Modify OS image and Task Sequence steps to accommodate wireless connectivity.

Step 1The first step is to export the wireless profile of your choice to an XML and save it for later—WPA2 on a hidden network is what we use for our organization. The exported network profile is titled “wifiprofile.xml”. This file will reside in the boot image and in the system image to be deployed.

**Step 2
**Create a batch file called connect.bat as follows:

%windir%\System32\wpeinit.exe -InitializeNetwork

net start wlansvc
netsh wlan add profile filename=%windir%\wifiprofile.xml

:loop
  ping IP.of.the.DP
  IF %ERRORLEVEL% equ 0 goto :connected
  netsh wlan add profile filename=%windir%\wifiprofile.xml 
  netsh wlan connect name=YOURSSID ssid=YOURSSID | echo Connecting to YOURSSID
  ping localhost -n 7 >nul
goto :loop

:connected
ping localhost -n 7 >null
exit

Note that the above script is designed that, if the ping fails, the loop retries the connection until the DP can be contacted. This is because wireless is unreliable at times and if it connects a moment too slow (or not at all) the task sequence will fail all together.

Step 2.1
Both the wifiprofile.xml and the connect.bat need to be in the OS image prior to deployment in the C:\Windows\ Directory.

**Step 3
**Next, you’ll need to mount an ISO for Windows 10 1607 (or newer) and extract the sources\image.wim and place it in the directory you use for DISM/image management—mine is C:\TEMP and all commands referenced below will follow that convention.

Create the C:\TEMP\MOUNT and C:\TEMP\winre folders.

Next execute the following commands in order to extract the WinRE.wim file (which supports wireless imaging), inject the wireless profile, then create a boot(able) image from that:

"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\dism.exe" /Mount-Image /ImageFile:C:\TEMP\install.wim /Index:1 /MountDir:C:\temp\mount

copy /y “C:\TEMP\mount\windows\windows\system32\recovery\winre.wim” C:\TEMP\

attrib -s -h C:\temp\winre.wim

Dism /Mount-Image /ImageFile:c:\temp\winre.wim /Index:1 /MountDir:C:\temp\winre

"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\dism.exe" /Mount-Image /ImageFile:c:\temp\winre.wim /Index:1 /MountDir:C:\temp\winre

attrib -R c:\temp\winre\windows\system32\winpeshl.ini

copy /y C:\temp\MOUNT\windows\system32\dmcmnutils.dll C:\temp\winre\windows\system32\

copy /y C:\temp\MOUNT\windows\system32\mdmpostprocessevaluator.dll c:\temp\winre\windows\system32\

copy /y C:\temp\MOUNT\windows\system32\mdmregistration.dll c:\temp\winre\windows\system32\

"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\dism.exe" /Unmount-Image /MountDir:C:\temp\MOUNT /discard

Now you can copy your wifiprofile.xml and your connect.bat into the C:\temp\winre\windows\ folder which we will commit in the next few steps.

**Step 4
**We are going to enable this image to support a Task Sequence (full OS deployment) over WiFi Via-SCCM Client on the OS.

The two following files we are about to create are automatically injected by SCCM during the distribution of the content (the WinRE.wim image) which is why they are stored in C:\Program Files\Microsoft Configuration Manager\OSD\bin\x64\ and not manually loaded into the WinRE.wim image. Failing to create these files will cause the task sequence to fail.

Step 4.1
Winpeshl.exe – cold/network/media boot
Create a txt file inC:\Program Files\Microsoft Configuration Manager\OSD\bin\x64\
Name it winpeshl.ini and add the following lines:

[LaunchApps]

%windir%\connect.bat

%SYSTEMDRIVE%\sms\bin\x64\TsBootShell.exe

**
Step 4.2**

TsBootShell.ini – cold/network/media/Software Center (from OS) boot

Create a txt file inC:\Program Files\Microsoft Configuration Manager\OSD\bin\x64\
Name it TsBootShell.ini and add the following lines:

[Shell]
OrgName=
EnableDebugShell=true
Run=%windir%\prestart.cmd

You can refer to this for a better understanding of the boot process and the significance of these files. Here is a brief summary: During a boot from a Task Sequence Media or PXE, the boot process starts with the winpeshl.exe. If no network adapters are ready by the time winpeshl.exe finishes execution, the TS will fail. The winpeshl.ini calls the connect.bat which initializes the network and starts the wlansvc, enabling a functional network interface. Once our connect.bat has established a ping to our DP, winpeshl launches the TsBootShell.exe.

The auto-generated TsBootShell.ini typically has one command in it to run tsmbootstrap.exe and kick off the GUI and/or proceed with policy retrieval (if unattended). Which is why we replace that line with “run=%windir%\prestart.cmd” and our prestart is nearly the exact same as our connect.bat

**Step 4.3
**Open C:\temp\winre\windows\prestart.cmd and modify it as follows:

%windir%\System32\wpeinit.exe -InitializeNetwork

net start wlansvc
netsh wlan add profile filename=%windir%\wifiprofile.xml

:loop
  ping 192.168.0.10
  IF %ERRORLEVEL% equ 0 goto :connected
  netsh wlan add profile filename=%windir%\wifiprofile.xml 
  netsh wlan connect name=YOURSSID ssid=YOURSSID | echo Connecting to YOURSSID
  ping localhost -n 7 >nul
goto :loop

:connected
ping localhost -n 7 >null

Run=X:\sms\bin\x64\TsmBootstrap.exe /env:WinPE /configpath:%CONFIGPATH%

The exit command is removed, and the last line points back to the task sequence initialization that we skipped in the TsBootShell.ini.

This redundant step exists because when a device boots into WinRE from the OS it skips the winpeshl.exe phase of the boot sequence. This is step is skipped because an answer file is generated during the “reboot into PE” step of the Task Sequence and the TS believes it has all the info necessary to initialize the network and proceed with imaging. However, it is not sophisticated enough to initialize the wlansvc because that service does not exist in a typical WinPE boot disk (remember, this is a WinRE boot disk which does have the wireless service stack). The result is when a PC reboots from the OS into the Win Pre-installation Environment (Win Recovery Environment) and skips the winpeshl.exe and goes straight to TSBootShell.exe, our modified prestart.cmd will connect to the wireless THEN fire off the task sequence.

So far, we have created/modified the following files:

C:\temp\winre\windows\wifiprofile.xml

C:\temp\winre\windows\connect.bat

C:\temp\winre\windows\prestart.cmdC:\Program Files\Microsoft Configuration Manager\OSD\bin\x64\winpeshl.ini

C:\Program Files\Microsoft Configuration Manager\OSD\bin\x64\TsBootShell.ini

Step 5

Now we can commit the changes to the WinRE.wim:

"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\dism.exe" /Image:c:\temp\winre /Cleanup-Image /StartComponentCleanup /ResetBase

"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\dism.exe" /Unmount-Image /MountDir:C:\TEMP\winre /commit

"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\dism.exe" /Export-Image /SourceImageFile:c:\temp\winre.wim /SourceIndex:1 /DestinationImageFile:c:\temp\winpe-wifi.wim

You've just created a WiFi-enabled boot image and successfully loaded the WiFi profile into the %windir% folder. When you're all done you'll have a new "winpe-wifi.wim" that you can then load into SCCM.

**Step 6
**Add the new boot image to SCCM but before you distribute it, edit the properties. You'll want to add any additional (wireless) drivers to your image here and configure a prestart command—the most important part!

The prestart command I use is:

cmd /c net start wlansvc & cmd /c netsh wlan add profile filename=%windir%\wifiprofile.xml & cmd /c netsh wlan connect profile=YOURs ssid=YOURs

The result of the above command is starting the WLAN service, importing the WiFi profile (from our variable location) then connecting to the provided WiFi network.

Step 7Configure a "run command line" Task Sequence step with the above commands after every reboot. This will keep the device connected throughout the entire imaging process. NOTE: This is why your wifiprofile.xml MUST be in both the boot.wim and the OS image.wim in order to be called upon after WinRE has exited.

**Step 8
Using this process, the PC will cache the WinRE boot image while booted in Windows, reboot at the assigned time and connect to WiFi to run the Task Sequence. For devices that won't boot and need imaging from a cold start, I created an ISO of the Task Sequence Media (with just the boot image) with the unattended flag enabled and the same prestart command above. Load that ISO onto a thumb drive and staff at remote campuses can boot to the thumb drive and the Task Sequence will automatically kickoff and complete over wireless.
**

I have tested this on a USB boot and from the desktop. OS upgrades or fresh-install task sequences can be performed ether way. I won’t sugar-coat it; the process takes a while depending on the size of the task sequence. My standard deployment with all the bells and whistles takes 6 PCs roughly 3 hours over wireless so ensure your maintenance windows are long enough to accommodate and your networking team isn’t planning any changes that night.

The key to success was using WinRE rather than WinPE as Windows Recover Environment supports wireless imaging for Surface Pro devices to restore from the cloud.

**Step 9
**The last task sequence step during OS deployment is to remove the wifiprofile.xml from %windir% as it **is **stored in plain text.

**Step 10
**Have a drink!
Not sure why Microsoft has made this so difficult but there it is, wireless imaging with SCCM.

_{Saturday, April 13, 2019 5:32 PM}

Thanks for the compilation. Formatting leaves just a little to be desired, but I think I will copy and make my own reference document so I appreciate it.

Maybe I didn't wait long enough, but the prestart.cmd didn't bring up the task dialogue. I will try it again later.

Also, for those of us worker bees unable to make changes to SCCM's reference versions of the ini files, those files can be modified by mounting the resulting wim that sccm creates after distributing. I forget their locations, maybe sms or system32, but not hard to find. Not as fun as having SCCM do this for us, but it works.

_{Monday, April 15, 2019 6:10 PM}

Also, for those of us worker bees unable to make changes to SCCM's reference versions of the ini files, those files can be modified by mounting the resulting wim that sccm creates after distributing. I forget their locations, maybe sms or system32, but not hard to find. Not as fun as having SCCM do this for us, but it works.

Indeed, this method was mentioned in post number 2:

This file inherently calls on winpeshl.exe which loads its settings from the winpeshl.ini file, however, both files are reset after loading the boot image to the DP in SCCM. To make your customizations stick, distribute your boot.wim to the DP and a new WIM package will be created in the same folder (boot-PM1000057.wim, as an example). Mount THIS wim file, modify the startnet.cmd file, and replace the original. SCCM will not wipe these changes because it won't know it's there--a greater understand of these processes can be found here.

Mounting the distributed WIM is the method I used prior to discovering that one could simply create the winpeshl.ini, TsBootShell.ini, and startnet.cmd files for SCCM to inject automatically. It's much easier to have it handled by SCCM and provides consistency no matter what images you use. Either way, both methods work.

Please feel free to provide any other references or guides you can find. Interestingly, most of the other (equally convoluted) guides I have found were published in mid 2018, 6+ months after this was posted.
What I do know is that the above steps have worked for 3 different organizations using SCCM or MDT (both integrated and independently). At the very least I hope the information can guide admins to a potential solution that works for their organization.

Thanks for your contribution!
Cheers!

_{Tuesday, April 16, 2019 8:47 PM}

I can't get usb media to work right, or have a boot wim that works for both usb media and software center. Any ideas?

_{Tuesday, April 16, 2019 9:11 PM}

If you have the WinRE boot image configured as above, I would check to make sure the customization includes the prestart command as shown below. I also enable Command Line support to troubleshoot and investigate the logs, test pings, etc. You can bring up the command prompt during the initialization phase of the TS by pressing F8.

Additionally, when I create the task sequence media, I include the Prestart command:

cmd /c net start wlansvc & cmd /c netsh wlan add profile filename=%windir%\wifiprofile.xml & cmd /c netsh wlan connect profile=YOURs ssid=YOURs

If you see the command line appear just after the WinRE image is loaded, then you are off to a good start. You should see a command window box with a repeated attempt to connect to wireless and any errors displayed.

Things to look out for in the command box:
No such interface = You do not have the correct wireless drivers injected in the image. SCCM can do this for you: /en-us/previous-versions/system-center/configuration-manager-2007/bb680705(v=technet.10)
Cannot connect to wireless network specified in wifiprofile.xml = something is a miss with your wireless. Check that you can connect using the same prestart command from a working OS.
Cannot start wlansvc no service exists = You are likely using a WinPE image which does not support the wireless networking stack.

Can you provide some more details on where in the boot/load process the media is failing?
Cheers!

_{Friday, April 19, 2019 2:25 PM}

I will try to get back to you the next time I update things. I've got it working with a modified boot.wim, but can't recall exactly what I did.

I have another goal, and that's to avoid placing a wifi xml on the deployed images, and that makes things fairly tricky, but doable. For those who are like-minded, here is the basic idea:

After the format/partition step (if you include it), include a step to download a package either through the SCCM task step of downloading the package, or in MDT through something similar or a command. You can create a variable for the path to that package that includes the xml or use c:\smstasksequence\packages\packageID\xmlfile.xml

That will persist after first reboot, where you can call on it using a command to import and connect. I've gotten this to work, but I've also had weirdness in failing steps that indicate the connection does not always establish. I haven't figured out why it sometimes has issues, but it may have to do with hardware and drivers.

_{Monday, May 27, 2019 4:04 PM}

So what I found is that in SCCM to use drivers right they have to be loaded through the sccm interface and not just added through DISM. I can't wrap my head around why that is, but redistributing the boot image fixed device initialization after a winPE reboot.

Ever since that, this system has worked great. I don't even bother with non-wifi boot files anymore.

But I do have one question maybe you can answer. When I boot from the modified wim, the background is always just black. Is there a fairly easy way to set a background image for this?

Thanks

_{Monday, August 19, 2019 9:11 PM}

Hi Joseph, I have a requirement to integrate a wireless network to the wim of an image; Can this procedure support me to carry out this activity?

_{Friday, August 23, 2019 3:24 PM}

In lieu of an ever-changing industry, I have (again) recompiled the information above into one unified guide that is now tailored to the longevity of Windows 10 and SCCM. Since my original guide was written using a 1607 image, SCCM 1906 is no longer supporting that ADK version and, as such, my boot images were/are no longer useful. This recreated guide is future proof as it can be repeated for every Windows version forever (until the next one, I’m sure).

Summary: Obtain a WinRE.wim image from a Windows 10 ISO version that matches that of your ADK/PE on the SCCM server. Be sure the version of your SCCM Site supports the given PE version also. Create a wireless profile in XML format. Create a script to call and connect to the wireless profile stored in XML format. Modify the built-in network management scripts used by SCCM/MDT for the Pre-Installation Environment (Recovery Environment, in this case). Modify the WinRE.wim image to support the wireless network stack and modify OS image and Task Sequence steps to accommodate wireless connectivity.

Step 1 – Export Wireless Profile The first step is to export the wireless profile of your choice to an XML and save it for later—WPA2 on a hidden network is what we use for our organization. The exported network profile is titled “wifiprofile.xml”. This file will reside in the boot image and in the system image to be deployed.

Step 2 – Create files Create the following scripts/files and placed them in C:\TEMP\files on your SCCM server (or whatever your DISM working directory is). My working folders for DISM are as follows and all commands reference below will follow that convention:

C:\TEMP

C:\TEMP\boot

C:\TEMP\files

Script 1 – Connect.bat

%windir%\System32\wpeinit.exe -InitializeNetwork

net start wlansvc
netsh wlan add profile filename=%windir%\wifiprofile.xml

:loop
  ping IP.of.the.DP
  IF %ERRORLEVEL% equ 0 goto :connected
  netsh wlan add profile filename=%windir%\wifiprofile.xml 
  netsh wlan connect name=YOURSSID ssid=YOURSSID | echo Connecting to YOURSSID
  ping localhost -n 7 >nul
goto :loop

:connected
ping localhost -n 7 >null
exit

**Script/File 2 – winpeshl.ini **

[LaunchApps]

%windir%\connect.bat

%SYSTEMDRIVE%\sms\bin\x64\TsBootShell.exe

The exit command is removed, and the last line points back to the task sequence initialization that we skipped in the TsBootShell.ini.

Script/File 3 – TsBootShell.ini

Enables cold/network/media/Software Center (from OS) Wireless network boot

[Shell]
OrgName=
EnableDebugShell=true
Run=%windir%\prestart.cmd

Script 4 – prestart.cmd

%windir%\System32\wpeinit.exe -InitializeNetwork

net start wlansvc
netsh wlan add profile filename=%windir%\wifiprofile.xml

:loop
  ping 192.168.0.10 
  IF %ERRORLEVEL% equ 0 goto :connected
  netsh wlan add profile filename=%windir%\wifiprofile.xml 
  netsh wlan connect name=YourSSID ssid= YourSSID | echo Connecting to YourSSID
  ping localhost -n 7 >nul
goto :loop

:connected
ping localhost -n 7 >null

Run=X:\sms\bin\x64\TsmBootstrap.exe /env:WinPE /configpath:%CONFIGPATH%

Script 5 -- startnet.cmd

%windir%\connect.bat
wpeinit

Step 2 results:

The following 6 (six) files should be located in C:\TEMP\files on your SCCM server:

Connect.bat

Wifiprofile.xml

Winpeshl.ini

TsBootShell.ini

Prestart.cmd

Startnet.cmd

Step 3 – Extract the WinRE Image

Next, you’ll need to mount an ISO for Windows 10 and extract the sources\image.wim and place it in the directory you use for DISM/image management—mine is C:\TEMP and all commands referenced below will follow that convention.

Mount the Win10.iso associated with ADK version. Ensure SCCM version supports the Windows ADK version of the Windows 10 version.

Using 7zip, open the install.wim in D:\sources\install.wim

Copy the following item to C:\TEMP on your SCCM Server:

F:\sources\install.wim\10\Windows\System32\Recovery\Winre.wim

Step 4 – Preload the WinRE Image

The following commands mount the image, copies your files, then commits the changes to the image. Driver injection and additional customizations can be done in the SCCM console.

## Start of Command Line Tools – Command Prompt as Administrator ##

cd C:\TEMP\

"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\dism.exe" /Mount-Image /ImageFile:c:\temp\WinRE.wim /Index:1 /MountDir:C:\temp\boot


copy files\wifiprofile.xml C:\temp\boot\windows\

copy files\connect.bat C:\temp\boot\windows\ /y

copy files\prestart.cmd C:\temp\boot\windows\ /y

copy files\TsBootShell.ini C:\temp\boot\windows\ /y

copy files\winpeshl.ini C:\temp\boot\windows\System32\ /y

copy files\startnet.cmd C:\temp\boot\windows\System32\ /y


"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\dism.exe" /Image:c:\temp\boot /Cleanup-Image /StartComponentCleanup /ResetBase

"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\dism.exe" /Unmount-Image /MountDir:C:\TEMP\boot /commit

Step 5 – Copy files again.

The two following files we are about to create are *automatically *injected by SCCM during the distribution of the content (the WinRE.wim image) which is why they are stored in C:\Program Files\Microsoft Configuration Manager\OSD\bin\x64\ as well as manually loaded into the WinRE.wim image in the steps above. Failing to create these files will cause the task sequence to fail. The following commands place these files in the necessary locations to be injected into the image during distribution.

## Start of Command Line Tools ##

copy files\winpeshl.ini "C:\Program Files\Microsoft Configuration Manager\OSD\bin\x64\" /y

copy files\TsBootShell.ini "C:\Program Files\Microsoft Configuration Manager\OSD\bin\x64\" /y

These files also enable this image to support a Task Sequence (full OS deployment) over WiFi Via-SCCM Client on the OS so no cold-boot with USB media is necessary (for reimaging/upgrade).

Step 6 – Adding the boot image Add the newly modified boot image to SCCM but before you distribute it, edit the properties. You'll want to add any additional (wireless) drivers to your image here and configure a prestart command—the most important part!

The prestart command to use is:

cmd /c net start wlansvc & cmd /c netsh wlan add profile filename=%windir%\wifiprofile.xml & cmd /c netsh wlan connect profile=YOURs ssid=YOURSSID

The result of the above command is starting the WLAN service, importing the WiFi profile (from our variable location) then connecting to the provided WiFi network

Step 7 – Stay connected during the Task Sequence.

Both the wifiprofile.xml and the connect.bat need to be in the OS image prior to capturing. They need to be placed in the C:\Windows\ Directory. When building the reference image (as lightweight as it may be), be sure to prestage these files accordingly.

.
Step 7.2 – WiFi Reconnect Configure a "run command line" Task Sequence step that calls on the connect.bat after every reboot. This will keep the device connected throughout the entire imaging process. NOTE: This is why your wifiprofile.xml and connect.bat MUST be in both the boot.wim and the OS image.wim in order to be called upon after WinRE has exited.

Step 8 – Create Task Sequence Media

For devices that need a cold-boot image with no Ethernet connection, you will need to use a USB thumb drive or disk media.

While creating the Task Sequence Media, enable the prestart command and use the following:

netsh wlan add profile filename=%windir%\wifiprofile.xml & netsh wlan connect name=YOURSSID

You can then use a tool such as YUMI to load the ISO onto a thumb drive.

Step 10 – Test a Task Sequence Using this process, a PC will cache the WinRE boot image while booted in Windows, reboot at the assigned time and connect to WiFi to run the Task Sequence for remote reimaging from a main-to-satellite branch.

The key to success was using WinRE rather than WinPE as Windows Recover Environment supports wireless imaging for Surface Pro devices to restore from the cloud.

Step 10 – Clear sensitive data The last task sequence step during any of my OS deployments is to remove the wifiprofile.xml from %windir% as it **is **stored in plain text.

del %windir%\wifiprofile.xml

**Step 11 **Have a drink!

Not sure why Microsoft has made this so difficult but there it is, wireless imaging with SCCM (with future proofing).

_{Friday, August 23, 2019 3:35 PM}

Good morning,

I posted a revised version of the guide as a response to my original post (sorry about the formatting). I just recently had to rework the process for an upgrade to SCCM 1906 so I can confirm the process works for Windows 1903 on SCCM 1906 as well--this will likely assist in meeting your requirements!

Cheers!

-Joseph

_{Tuesday, October 22, 2019 5:34 PM}

Thank you sooo much for this!!!!

_{Tuesday, February 4, 2020 8:59 PM}

Boot Image Import Error - not 'finalized'

I've followed the steps to create the WinRE/PE Wifi wim, using Windows 10 1803 install.wim. When I try to import to SCCM is claims I cannot import as it is not 'finalized.' Is this an issue with 1803 vs SCCM ver? My default SCCM boot image is 10.0..14393.0. We are on SCCM 2012 1606

Thanks for this work. It will likely be a lifesaver for us.

_{Wednesday, February 5, 2020 10:18 PM}

You’re right, the version difference is the issue—it’s because your SCCM and ADK won’t support Win10_1803. Your default ADK is for Windows 10 1607 which means you need to update it and your SCCM version to match the Windows version you’re trying to deploy. In the summary I stated to “Obtain a WinRE.wim image from a Windows 10 ISO version that matches that of your ADK/PE on the SCCM server. Be sure the version of your SCCM Site supports the given PE version also.”

In short, upgrade to SCCM+ADK 1806 or newer to support the WinRE version you have or use a Windows 10 1607 ISO for the process. I had a similar issue when I used the 1607 image/ADK on our SCCM 1906 (which doesn’t support that far back /en-us/configmgr/core/plan-design/configs/support-for-windows-10)

Cheers!

_{Monday, July 6, 2020 4:37 PM}

Hi, I'm trying to get this to work after updating sccm.

I get it as far as it recognizing that the wlansvc has started, but ipconfig /all will not show an existing wifi adapter.

Now, on sccm, the way I did this was I replaced the data source wim with this wifi wim, and kept the drivers and such the same, then updated the distribution. I would think that it would then re-add all of my drivers back, I checked the list and they are all there. But I can't get it to show wifi adapters in ipconfig.

_{Monday, July 6, 2020 4:49 PM}

When I import the winre.wim, and go to edit, it won't let me access some of the tabs in sccm.

_{Monday, July 6, 2020 5:06 PM}

What is your Windows ADK and your ConfigMrg version(s)? I found the same behavior of the "disabled tabs" when my Boot.wim was no longer supported - you can check the support matrix I reference above here:
/en-us/mem/configmgr/core/plan-design/configs/support-for-windows-10

The only way I was able to fix this at the time was to Update Distribution Points with the "Reload this boot image with the current Windows PE Version from the Windows ADK" option selected. Ultimately, when jumping 2-3 Windows versions, I recommend grabbing your second-newest Windows ISO (1909 in this case) and recreating your Boot.wim since it will remain supported in ADK for the next few versions too.

After upgrading (uninstall old, install new) your ADK, just follow the guide above with 1909 and make sure your winpeshl.ini and TsBootShell.ini are where they're supposed to be before distribution.

_{Tuesday, July 7, 2020 12:30 PM}

Edit: Okay I think I have this solved but have to wait for boot to distribute etc. What seems to happen is it takes a full minute before the connection establishes. Going to try a longer timer.

Edit2: That's all it was. I didn't like the loop thing and I don't recall it taking this long in the past, but it's working after a minute so that's good enough. Thanks a lot for making and remaking this guide.

_{Wednesday, July 8, 2020 9:29 PM}

Hey that is good news! This behavior is why I use the ping -> Loop in my connect.bat - I would rather a client try (and try again) to connect than just have the process just fail and have to chase down issues that might not exist.

What I am really glad to hear is that this guide has helped fellow ITers like myself overcome a serious limitation of Windows Network imaging.

Cheers!

PS Coming soon is IEEE 802.11x authentication instead of the clear-text XML file (I am sure someone else already has something). I am working on this in conjunction with Task Sequence "reimaging" over an AlwaysOn VPN. We have "public" computers that get reimaged/upgraded with every Windows 10 version and they're out in the wild so implementing this process will be my next challenge. :)

_{Wednesday, July 15, 2020 8:39 PM}

Yeah, i really like this method of getting it all set up. Figuring out the VPN will def be a challenge.

_{Monday, July 20, 2020 6:00 PM}

First off, THANK YOU! I had been looking into this for awhile and stumbled across this post and it was very helpful in getting the wireless imaging setup on my systems.

I wanted to share one gotcha that I ran into when I first set it up and I didn't diagnose it properly at first. The imaging part was working for me, I could get all the way through my TS, but the computer wasn't joined to the domain at the end like it was supposed to be. I didn't find any errors in the smsts.log. Due to available time to work on it, I wasn't paying close attention while testing the TS (starting the imaging test as I was walking out the door type of thing). I thought I just couldn't find the issue preventing the domain join so I ended up adding a 'Join Domain or Workgroup" step and added a condition to only run it if it wasn't already joined (in case I had imaged over a wire).

Fast forward a few months and I was testing for the new Win10 release. I couldn't remember why I put the additional domain join step in and disabled it in the TS (the phrase "WTF was I thinking" came to mind several times). While testing the wireless with the new image, and paying closer attention, I noticed a delay during the "Setup Windows and Configuration Manager" step when Windows setup was at the "Getting ready" screen. Many hours and colorful metaphors later, I figured out what was happening. SCCM rebuilds the sysprep answer file (specified in the Apply Windows Image step) adding the domain join info (specified in the Apply Network Settings step) during the TS. When Windows setup was parsing the answer file, if there was no network connection, setup was hanging on the domain join and eventually timing out. I just saw the delay and focused on it, not waiting to see it timeout. The timeout error never showed up in smsts.log because the domain join process wasn't started by the TS, it was started by Windows setup (my misunderstanding at this is what caused most of the colorful metaphors). Once I realized what was happening, I re-enabled the secondary domain join and everything started working.

Now I get to remove all my "Apply Network Setting" steps so I don't have a long pause during Windows setup and add "Domain Join" steps for all of the OUs I have computers being put into. :(

Share via

Successful Wireless Imaging

Question

All replies (29)

Additional resources