As far as I know there is no way to pass variables/environments
informations directly to wondows (WinPE) without (re)building the image and
including the configuration in it.
I've found that a simple way could help us without too many hacks.
Actually when we boot up we spawn an IP from the DHCP from our TFTP/Proxy
server.
The pxe configuration at the moment show something like this:
DEFAULT menu
LABEL menu
COM32 linux.c32 boot/wimboot
APPEND initrdfile=boot/windows-x64/bcd,boot/windows-x64/boot.sdi,boot/
windows-x64/boot.wim
Adding at the end of the PXE the variables in a commented way could be a
good alternative:
After that with a script that will be the same per any installation we will
contiune the installation.
We'll need a TFTP client (obviously) and a good dose of batch scripting.
I'm not that good on windows and I can use an hand.
With this configuration we will be able to installa machine behind NAT that
actually could not get the provision configration file.
Added powershell functionality to the boot.wim (130mb extra this could be a
problem).
this is a first draft.
I need actually to add curl (gnu so no problem here).
## START
# warning: this script has been written by a complete moron.
## Disable the firewall
Wpeutil disablefirewall > $null
## Set the path of curl (GPL distribuited)
$curl="x:\windows\system32\curl.exe"
## Get the MAC
$mac=$(Get-WmiObject win32_networkadapterconfiguration -Filter ipenabled=
"true"|select -expandproperty macaddress|select-object -first 1).Tolower()
## Optain the DHCP server (that is also the TFTP server)
$foremanproxy=$(Get-WmiObject Win32_NetworkAdapterConfiguration | ? {$_.
DHCPEnabled -eq $true -and $_.DHCPServer -ne $null} | select -expandproperty
DHCPServer>select-object -first 1)
## Change the mac to the format witht the dash instead of semicolons
$mac=$mac -replace ":", "-"
## Build the path to the pxelinux configuration
$tftp='tftp://' + $foremanproxy + '/pxelinux.cfg/01-' + $mac
## Build the commandline to retrive the TFTP
$command=$curl + ' ' + $tftp + ' -o pxeconf.tmp'
## Obtain the pxe configuration
iex $command
## Extract variables
# Getting URL
$URL=$(cat .\pxeconf.tmp|findstr.exe URL) -replace '.# URL=','' -replace ' ','';
## Place it in an environment
## Retrive the TOKEN
## Get the unattended script
$command=$curl + ' ' + $URL + ' -o unattended.xml'
iex $command
## END
Would be cool to reduce this script to a Batch so I won't need to add
PowerShell.
Thoughts? Impressions?
K.
Il giorno martedì 25 ottobre 2016 10:50:34 UTC+2, Andrea Cervesato ha
scritto:
···
>
> As far as I know there is no way to pass variables/environments
> informations directly to wondows (WinPE) without (re)building the image and
> including the configuration in it.
>
> I've found that a simple way could help us without too many hacks.
>
> Actually when we boot up we spawn an IP from the DHCP from our TFTP/Proxy
> server.
>
> The pxe configuration at the moment show something like this:
> DEFAULT menu
> LABEL menu
> COM32 linux.c32 boot/wimboot
> APPEND initrdfile=boot/windows-x64/bcd,boot/windows-x64/boot.sdi,boot
> /windows-x64/boot.wim
>
>
> Adding at the end of the PXE the variables in a commented way could be a
> good alternative:
> DEFAULT menu
> LABEL menu
> COM32 linux.c32 boot/wimboot
> APPEND initrdfile=boot/windows-x64/bcd,boot/windows-x64/boot.sdi,boot
> /windows-x64/boot.wim
>
> #VAR FOREMANURL "https://myforeman.url.domain.ext"
> #VAR AUTOPROVISION "https://myforeman.url.domain.ext
> /unattended/provision?token=0000000-0000-0000-0000-0000000000"
> #VAR HOSTNAME "MYHATEDWINMACHINE01"
> #VAR DOMAIN "windowsdomain01.local"
>
>
>
> After that with a script that will be the same per any installation we
> will contiune the installation.
> We'll need a TFTP client (obviously) and a good dose of batch scripting.
>
> I'm not that good on windows and I can use an hand.
>
> With this configuration we will be able to installa machine behind NAT
> that actually could not get the provision configration file.
>
> K.
>
I know this is a fairly old conversation; however, for the sake of helping others in this situation, I actually learned an easy way of passing a script to windows, the foreman way (making the winpe image even more generic).
This is my PXELinux template (the most important part, is where I download the script to peSetup.cmd):
<%#
kind: PXELinux
name: Windows default PXELinux
model: ProvisioningTemplate
oses:
- Windows
%>
DEFAULT menu
LABEL menu
COM32 linux.c32 boot/windows-<%= @host.arch %>/wimboot
APPEND **<%= foreman_url('script') %>@peSetup.cmd,**initrdfile=<%= @host.operatingsystem.bootfile(@host.arch,:bcd) %>,<%= @host.operatingsystem.bootfile(@host.arch,:bootsdi) %>,<%= @host.operatingsystem.bootfile(@host.arch,:bootwim) %>
I’ve found the file is copied to \Windows\System32\peSetup.cmd from where it can be executed (for now not the nicest location, but perhaps I could figure out how to change to path, previous attempts have failed so far)
I tested this using syslinux 6 and a slightly adapted version of the winPE image (compared to the original wimaging output).
I hope this might help others who have come across this situation (in which rebuilding winPE each time is not feasible).
@UXabre, I’d be super interested to get this working. However I keep getting errors.
Are you sure of the syntax of the APPEND line? The use of stars and the @peSetup.cmd right after the url (without space or operator) look a bit suspicious to me.
But yet, I don’t really know the syntax.
hey @Bernard_Landon, actually, looking back, the ** in front and after the peSetup.cmd inclusion was to indicate that this was the important part. In other words, the ** should be removed and it should work. However, this seems to work only on oVirt/RHV/KVM systems as this relies on HTTP to work in the PXE bootloader (which I’ve actually only learned a few months afterwards). To make this work on about any host, it’s wise to either use iPXE or lpxelinux.0 as a bootloader, both are equally easy to set-up IMO. The latter requires a minor change in the foreman-installer parameters to use this instead. The iPXE way will simply need some foreman UI set-up, in which you’ll first have to load iPXE and than chainload the default PXELinux, after which HTTP will become available.
Currently I’m not on my laptop, so I can’t go to much further into detail, however, if this is too vague, I can further elaborate tomorrow. Both of these solutions seem to work for me, depending on your situation, one of these might fit your use-case a bit better.
Let me know if this works, you need more help or which of these fits your need best (and for my reference, why one fitted better then the other)
Finally, sorry for the ambiguity I’ve introduced with the *
Small disclaimer: I’m just referencing these answers on problems I’ve encountered in the past, might be useful to share the errors as well. At the very least, others having the same issues might be directed here in the future;
Hi there!
Thank you so much for taking the time to write such a detailed answer. I
think I will indeed look into these options.
They sound pretty cool!
