ipxe Anywhere Planning and Deployment Guide 2Pint Software 10/8/15

Transcription

1 ipxe Anywhere Planning and Deployment Guide 2Pint Software 10/8/15

2 1 Contents Introduction... 5 About ipxe... 5 Main ipxe Anywhere Components... 6 Detailed ipxe Anywhere Component Info PXE... 7 ipxe Network Boot Program (NBP)... 7 IIS Server for file access... 7 ipxe Anywhere Web-Service... 7 ipxe Anywhere SQL Database(s)... 7 ipxe Anywhere SQL Reporting Service Web Site... 7 BranchCache for OSD Toolkit... 7 Security... 8 Authentication... 8 Certificates... 8 Code Signing... 8 Secure Boot... 8 Using the ImageTrust capabilities... 8 Custom Certificates... 8 How it Works... 9 Planning With or without the ipxe Anywhere Web-Service DHCP vs IPHelpers DHCP Options vs ProxyDHCP PXE Mode of operation The 2PXE Request Handlers Microsoft ConfigMgr Request Handler PowerShell Request Handler Installation and Configuration Pre-Requisites Configuring IIS & BranchCache for the 2PXE Server Install and configure IIS/BranchCache on the 2PXE Server Install IIS and BranchCache Roles and Features Interactive Installation PowerShell Installation... 18

3 2 IIS/BranchCache Configuration IIS Configuration Create Virtual Folder Virtual Directory - PowerShell Installation MIME Types in IIS MIME Type Configuration via PowerShell BranchCache Configuration Content Server Configuration BranchCache Client Configuration Client Hash Version Configuration Generating WinPE Images for ConfigMgr ConfigMgr Distribution Point ConfigMgr Security Allow Access to create ConfigMgr State Messages Ensuring access to the boot files Allowing Access to the ConfigMgr SQL Database PXE Service Install Licensing Manual Installation Command Line Install Installation on an X86 machine: Installation on an X64 machine: Mandatory MSI Properties Optional MSI Properties PXE Post Installation Configuration Installation Files Service The RemoteInstall Folder PXE Windows Event log Adding Boot Images PXE Service Configuration Pint.2PXE.Service.exe.config Valid Configuration Combinations Firewall Considerations The following steps explain the UDP and TCP ports that are used during image deployment:... 41

4 3 Adding firewall port for HTTP Traffic PXE PowerShell Request Handler PowerShellExtension.ps1 Sample Script Troubleshooting Running the Service Interactively for Troubleshooting & Testing Errors & Issues Failing with an invalid boot.bcd file Failing to find the boot.sdi file Connection Reset 0f0a Not enough RAM in target computer Slow first boot with PowerShell Further Reading... 54

5 4 Typical Network Transfer and Transfer Speed Typical Boot Process Take it for a spin Boot via PowerShell to WDS style menu & TFTP DL Booting an ipxe VESA Compliant System Boot via PowerShell to ipxe menu Boot via ConfigMgr to ipxe menu of all available Task Sequences Boot via ConfigMgr directly from the DP via HTTP and BranchCache over a 128/512 link in seconds! Other System Management Tools Other Quick Install Guides Quick Install for MS ConfigMgr Quick Install for the PowerShell Request Handler... 64

6 5 Introduction ipxe Anywhere is a network booting solution using the open source ipxe network boot firmware. 2Pint Software adds the Anywhere which consists of a proxydhcp/tftp/http server called 2PXE, and a further (optional) Web Service component called ipxe Anywhere which adds extra functionality. These server components make ipxe sing and dance by communicating with, and reporting on the ipxe client software. 2Pint Software has also funded the implementation of a Microsoft BranchCache client into the ipxe software itself, and that is still part of the open source ipxe which is available to everybody. See it like our sacrifice to the PXE gods. About ipxe ipxe is the leading open source network boot firmware. It provides a full PXE implementation enhanced with additional features such as: Boot from a web server via HTTP HTTP supports BranchCache V1 & V2 boot from an iscsi SAN boot from a Fibre Channel SAN via FCoE boot from an AoE SAN boot from a wireless network boot from a wide-area network boot from an Infiniband network control the boot process with a script You can use ipxe to replace the existing PXE ROM on your network card, or you can chainload into ipxe to obtain the features of ipxe without the hassle of reflashing. ipxe is free, open-source software licensed under the GNU GPL (with some portions under GPLcompatible licenses), and is included in products from several network card manufacturers and OEMs. ipxe can be downloaded here:

7 6 Main ipxe Anywhere Components #!ipxe 2PXE Server: proxydhcp & TFTP This is your replacement for WDS that runs on any system that has the.net Framework and offers a full proxydhcp and TFTP server. Detects what to boot, like WDS with PXE Service Point. Used to load ipxe or standard Windows Boot Loaders. This is what responds to the PXE boot. ipxe Network Boot Program The open source ipxe boot loader is used to boot over HTTP and to take the appropriate actions from a low level boot. It can show menus, boot to iscsi and includes a Microsoft BranchCache client. This is custom version tailored for ipxe Anywhere. For a full list of übercool ipxe capabilities please visit: ipxe Anywhere Web Service This is the Web Service that the ipxe Network Boot Program communicates with in order to display menus, boot to WinPE, boot to iscsi etc. The service is hosted as a traditional win32 service and doesn t require IIS. The web service connects to the ipxe Anywhere Database if available. ipxe Anywhere Database This is a database used for reporting and storing boot data. It can provide real time boot data, boot statistics as well as historic data analysis. Runs on any MS SQL including SQL Express Editions. Figure 1 ipxe Anywhere Main Components

8 7 Detailed ipxe Anywhere Component Info This sections gives a little more background on the ipxe Anywhere components. 2PXE The 2PXE Service is a proxydhcp server that responds to the initial PXE request. It has a proxydhcp, TFTP and HTTP service built in to it. Don t confuse the 2PXE Web Service with the ipxe Anywhere web service, they are different animals. The ipxe Anywhere Web Service is the big brother of the 2PXE web service. The 2PXE Service is typically your entry point to the PXE booting method as this is the service that would parse your request. ipxe Network Boot Program (NBP) This is core essence of ipxe Anywhere. A specially configured customized version of the open source ipxe solution tailored to work with the ipxe Anywhere server environment. Things that are enabled as a part of the default ipxe build are BranchCache etc. Other things are IIS Digest Authentication etc. More on this later in this document. Having BranchCache enabled in a NBP enables you to load WinPE from peer BranchCache systems that have WinPE in their local cache. IIS Server for file access An IIS (or other BranchCache capable web service) is used for ipxe Anywhere to download content over HTTP and to support BranchCache hash generation. ipxe Anywhere Web-Service (Optional) This is an optional Web Service that the ipxe Network Boot Program talks to, if configured by 2PXE. This server talks HTTP with the client and SQL to the SQL DB (optional). It is used for extended functionality such as BIOS updating, interacting with Microsoft MDT, creating custom ipxe menus etc. Please refer to the separate documentation for that component. ipxe Anywhere SQL Database(s) (Optional) This database stores info about PXE booted computers and their capabilities. This database can be hosted on SQL Express if necessary as traffic to this database is very small. ipxe Anywhere SQL Reporting Service Web Site (Optional) Connected to the ipxe Anywhere Web Service Database is a SQL Reporting Services Instance used for pulling reports. BranchCache for OSD Toolkit This nifty toolkit enables BranchCache in the Windows Pre-Installation Environment (WinPE), and also for non-branchcache enabled systems like the Windows Professional family. This is needed for integrating BranchCache and also BITS, but most importantly it adds the ipxe Anywhere WinPE client into the WinPE images which is required to get Microsoft ConfigMgr booting to work ok. By enabling BranchCache in a resource intensive process like OSD, more systems on the network will share the load, ensuring a fast and effortless deployment without hogging system resources from other computers or the network.

9 8 Security Unlike most network booting products, ipxe Anywhere can be made 100% secure and protect any sensible data by using a mixture of technologies. Authentication Before allowing the network boot, a user can be authenticated against a central repository like Active Directory on premises or Azure. The credentials can be either sent as clear text protected by SSL certificates or using Digest Authentication for non SSL capable servers. Using SSL ensures that there is no way unauthenticated users can access any media containing username or passwords. Unlike most network booting systems, the password can be provided at boot time, before loading any large image, freeing up boot time and making the system even more secure. Certificates All HTTP traffic can be secured using SSL. ipxe supports the HTTPS protocol, which allows you to encrypt all communication with a web server and to verify the server's identity. Code Signing ipxe also supports code signing, which allows you to verify the authenticity and integrity of files downloaded by ipxe. Secure Boot The ipxe Boot Loader now supports Secure Boot, which is a feature of UEFI that only allows certain Operating Systems to be loaded. Using the ImageTrust capabilities The imgtrust command only prevents ipxe from directly executing an untrusted image. For example: when executing a Linux kernel image, imgtrust will prevent the execution of an untrusted kernel image, but will not prevent the use of an untrusted initrd. If you want to ensure that any additional images (such as an initrd) are also trusted, then you must explicitly verify them using the imgverify command. Image Trust ensures that the data has not been tampered with. When using BranchCache this offers no additional security as the image integrity is verified by BranchCache itself. Custom Certificates We can support the use of third party certificates (Not ipxe nor 2Pint Software) certificates. Contact us at support@2pintsoftware if you require this.

10 Deployed Operating System WinPE Environment ipxe Environment Bare Metal 2Pint 9 How it Works A machine requesting PXE boot will be picked up by the network boot server. The server will parse the request and send the corresponding boot file (BIOS or EFI) to the client. This file is very small and the handles low bandwidth situations really well. Once the ipxe NBP is downloaded it will contact the 2PXE Web Service to get the right action to execute. Lack of action will cause the NBP to exit out and continue the boot order. Once an action is detected the server will send back the corresponding boot script to the client. The client will then execute this script, which typically involves loading a high level OS over HTTP. When the system needs to load the Windows PE boot image, it can transfer the content from local BranchCache peers instead of copying it from the server. The diagram below shows a typical ipxe Anywhere setup, integrating with Microsoft ConfigMgr. The 2PXE Server component replaces the Windows Deployment Server (WDS) and PXE Service Point (PSP) components on a Distribution Point in ConfigMgr. It connects to the ConfigMgr database in order to retrieve the available deployments for a system, and dynamically builds a boot menu which is returned to the client system. DHCP Request DHCP Offer TFTP of ipxe (undionly/snponly) Powershell Undionly.kpxe Snponly.efi Wimboot.bin Boot.bcd Boot.wim Variables.dat 2PXE Server Install.wim HTTP BC file Download Boot Info BITS/HTTP With BranchCache ConfigMgr Power BI & PowerMap Powershell ipxe Anywhere DB Power BI & PowerMap ipxe Anywhere Web Service Figure 2 A typical ipxe Anywhere implementation

11 10 Planning With or without the ipxe Anywhere Web-Service 2PXE can operate on its own without the need for the ipxe Anywhere Web Service. It will then do all the heavy lifting itself. There is of course extra functionality that you get from ipxe Anywhere like logging, reporting, and a host of other options limited only by the imagination! Think of it like some heavy artillery that you can call on when you need it. Some examples of things that you could do are ; integrating with the MDT database, checking and upgrading the BIOS version before OS install, presenting a special technician menu with tons of diagnostic tools etc the list goes on. Because ipxe Anywhere is driven by a PowerShell scripting interface, the sky s the limit. The following high level schematic shows the different setup by just using 2PXE compared to integration it with ipxe Anywhere Web Service. 2PXE (proxydhcp/tftp/http Server) 2PXE (proxydhcp/.. Server) ipxe Anywhere Database ipxe Anywhere Web Service DHCP HTTP TFTP DHCP TFTP HTTP HTTP PXE Client PXE Client DHCP vs IPHelpers 2PXE can be booted using any kind of DHCP server, without using the built in proxydhcp server, but that might not work well in all configurations. In order to manage this effectively when having both BIOS and UEFI machines we recommend using a smart DHCP server like ISC for Linux or Microsoft DHCP 2012 or later for Microsoft environments. We only support using DHCP options when using the 2PXE HTTP Web Service for communication between PXE booting computer and the 2PXE server. If your DHCP server is not smart enough to respond with the right info you can still use 2PXE, just use IP helpers to manage the boot requests instead. DHCP Options vs ProxyDHCP Oh, this is a big debate. The Microsoft people only supports proxydhcp. Why? That s up to you to decide. Reasons to use DHCP options to control network boot:

12 11 1. Smaller footprint to deploy 2. Might require DHCP changes that can be hard to tweak and test depending on vendor of DHCP 3. No need to talk to the network team Reasons not to use DHCP options to control the network boot: 1. No ability to use DHCP to set the right boot loader 2. Ability to control which machine to send PXE offers to 3. Easily allow different boot options to different clients 4. No need to talk to the DHCP team When using DHCP options there is no way for the ipxe NBP to detect the options values from the PXE service point. This will make the embedded script default to HTTP as the transfer mechanism, so ensure you are using the 2PXE Web Service. Note: The topic of DHCP configuration for PXE booting is so complex it requires its own document. So we wrote one Using DCHP To Control PXE Booting for BIOS and EFI Clients Figure 3 shows how a Microsoft DHCP server giving out Option #66 and #67 can be used to boot a computer with ipxe. DHCP Client Option # 67 = Filename Option 66 = ServerName Option #66 is translated to SIADDR field in the DHCP packet by Microsoft DHCP. Option #66 is not really used. PXE Client

13 12 Figure 4 depicts a PXE boot using the 2PXE DHCP Proxy DHCP Server DHCP Client Proxy DHCP Server (2PXE) PXE Client

14 13 2PXE Mode of operation 2PXE can operate in two different modes: 1. ConfigMgr 2012 Integration allows Microsoft ConfigMgr customers to use ipxe to boot the boot media directly from the Distribution Point itself. 2. PowerShell Extension allow non ConfigMgr customers to boot to WinPE files over HTTP or TFTP, to use ipxe for the HTTP downloads and also use TFTP with regular images. In this next section we will explain each of the two options and where they should be installed. The 2PXE Request Handlers The 2PXE service operates two service request handlers. They can both run in parallel, although this is not recommended. Microsoft ConfigMgr Request Handler This request handler contacts the Configuration Manager Site server in order to determine the boot action. In order to enable the ConfigMgr integration, the 2PXE service must be installed on a ConfigMgr Distribution Point. You can create a new Distribution Point if you do not want to install it on your main distribution points. This is the recommended approach. You only need one small VM Distribution Point with the WinPE boot images distributed to it to cover the entire enterprise boot needs (when using ipxe with http and BranchCache.) There are two modes of operation for the Configuration Manager Handler: Using SQL to contact the Site Server Using HTTP to contact the Site Server via the ConfigMgr Management Point (MP) The HTTP/MP method has the upside of being HTTP traffic but the downside of only returning one boot action per client, just like the WDS PXE Service Point, so it s a bit crap, really.. The SQL method is faster (as the MP way is behind the scenes executing more or less the same SQL), and also works fairly well over slow connections as it s very little data being pulled over the wire. The SQL method only works with the ipxe Boot loaders. The SQL method also automatically deals with multiple computers sharing the same Ethernet USB dongle and multiple machines with the same UUID (SMBIOS_GUID). PowerShell Request Handler The PowerShell extension allows you to control the boot order, i.e. querying or feeding other data sources with information. The integration is managed by two PowerShell scripts in the installation directory. One script is for dealing with the initial request, determining if the machine should boot at all. This will be executed several times during the boot process, depending on the DHCP client of the PXE capable device. This script is called PowerShellExtensionAllowBoot.ps1. The other script PowerShellExtensionBootImages.ps1 takes over when the machine has booted to ipxe. This is typically executed once, but can be executed several times if ipxe loaders are not used. The following diagram shows a non-configmgr setup of ipxe Anywhere using the PowerShell Request Handler

15 Deployed Operating System WinPE Environment ipxe Environment Bare Metal 2Pint 14 DHCP Request DHCP Offer TFTP of ipxe (undionly/snponly) HTTP BC file Download WDS + IIS Undionly.kpxe Snponly.efi Wimboot.bin Boot.sdi Boot.bcd Boot.wim Boot Information Boot Instructions/Actions SQL reporting Status/Info Powershell Actions 2PXE Web Service Request Data/Info/Content Power BI & PowerMap BITS/HTTP/SMB With BranchCache Install.wim Your File/Web/Server For full details on how to install and configure the 2PXE service and handlers, please refer to the Installation and Configuration section of this document.

16 15 Installation and Configuration Pre-Requisites Common Prerequisites The following items must be installed and configured on the 2PXE Server regardless of which handler you will be using (ConfigMgr or PowerShell) IIS/BranchCache should be installed The.NET Framework 4.0 or above must be installed Configuring IIS & BranchCache for the 2PXE Server This section describes the basic steps required to install and configure Microsoft BranchCache for use with the 2PXE server. The ipxe Boot Program now includes a BranchCache client, that is, it s a consumer of BranchCache content from other peers on the same subnet. So, in the most common scenario, ipxe can retrieve the WinPE image from peers on the local subnet via http/branchcache during the boot process, which of course saves WAN bandwidth utilization. Install and configure IIS/BranchCache on the 2PXE Server The 2PXE Server will also be the BranchCache Content Server. BranchCache will be configured in Distributed Mode, which means that all the local Windows BranchCache clients will act as a distributed cache from which content can be retrieved by any other BranchCache client on the same subnet. BranchCache will also be configured for HTTP transfers (it can also use the SMB protocol but ipxe does not use this), so IIS is also a requirement. IIS and BranchCache can be installed in one session using the steps below. Install IIS and BranchCache Roles and Features You can install the required roles and features using PowerShell, or interactively using the Server Manager Wizards, here are both methods. Interactive Installation In Server Manager, click Manage, and then click Add Roles and Features. The Add Roles and Features wizard opens. Click Next. In Select Installation Type, ensure that Role-based or feature-based installation is selected, and then click Next. In Select destination server, ensure that the correct server is selected, and then click Next. In Select server roles, select Web Server (IIS), then click Next

17 16 You will see the following pop-up message, click on Add Features

18 17 You will then be presented with the following choices. Select the options exactly as shown above: Http Errors Static Content Digest Authentication

19 18 Windows Authentication IIS Management Console Click Next, and you will move onto the Features selection page. Select BranchCache, as shown below Click Next, and you re almost done! Check the Confirmation Screen and if you have selected all of the required Roles and Features, click Install to complete the installation. PowerShell Installation Of course, here at 2Pint we love PowerShell because it saves us time. You can install IIS and BranchCache using the following one-liner command. Boom! Add-WindowsFeature Web-Server, Web-Http-Errors, Web-Static-Content, Web-Digest- Auth, Web-Windows-Auth, Web-Mgmt-Console, BranchCache IIS/BranchCache Configuration IIS Configuration Create Virtual Folder

20 19 Once installed as per the instructions above, you need to create a Virtual Directory, from which your WinPE Boot Images can be retrieved via HTTP. This should be the %PROGRAMDATA%\2 Pint Software\2PXE\RemoteInstall folder. Open up IIS Manager, via the Server Manager Tools menu, select the Default Web Site, and from the right-click context menu select Add Virtual Directory as shown below.

21 20 In the Add Virtual Directory dialog, enter an alias for your folder (we ve named it Reminst but you can name it whatever you like). Browse to the folder where your boot images are stored, and click on OK. Virtual Directory - PowerShell Installation Of course, there s always an easier way. To create the same Virtual Directory using PowerShell, simply execute the following command. New-WebVirtualDirectory -Site "Default Web Site" -Name Reminst - PhysicalPath C:\ProgramData\2Pint Software\2PXE\Remoteinstall MIME Types in IIS IIS will not return file types that are not added to the site configuration. Add MIME types for the boot files (.bin,..bcd,.wim,.ttf,.fon,.efi,.com,.n12,.kpxe,.sdi) either via the GUI or through the cmdline. Set the files to Application/Octet-Stream Open Internet Information Services (IIS) Manager: In the Connections pane, go to the site, application, or directory for which you want to add a MIME type. In the Home pane, double-click MIME Types In the MIME Types pane, click Add... in the Actions pane.

22 21 In the Add MIME Type dialog box, add the file name extension and MIME type, and then click OK. MIME Type Configuration via PowerShell Automate it! The following PowerShell will register the necessary MIME types for ipxe and its associated boot files and fonts. #Set the MIME types for the ipxe boot files, fonts etc. # wimboot.bin file add-webconfigurationproperty //staticcontent -name collection #EFI loader files add-webconfigurationproperty //staticcontent -name collection #BIOS boot loaders add-webconfigurationproperty //staticcontent -name collection #BIOS loaders without F12 key press add-webconfigurationproperty //staticcontent -name collection #For the boot.sdi file add-webconfigurationproperty //staticcontent -name collection

23 22 #For the boot.bcd boot configuration files add-webconfigurationproperty //staticcontent -name collection #For the winpe images itself add-webconfigurationproperty //staticcontent -name collection #for the ipxe BIOS loader files add-webconfigurationproperty //staticcontent -name collection #For the UNDIonly version of ipxe add-webconfigurationproperty //staticcontent -name collection #For the boot fonts add-webconfigurationproperty //staticcontent -name collection BranchCache Configuration Content Server Configuration Once BranchCache is installed, we need to create the Hashes for the Boot files and images so that the BranchCache client can retrieve the boot images locally if possible. We do this on the 2PXE server. IMPORTANT: If your WinPE Boot Images are cached on Windows 7 systems, we need to tell the BranchCache content server to create V1 (Windows 7) hashes. If your WinPE Boot Images are cached on Windows 8/10 systems, we need to tell the BranchCache content server to create V2 (Windows 8/10) hashes. If you create both V1 AND V2 hashes (which is the default), the BranchCache client in ipxe will try to use the V2 hashes. If there are only Windows 7 clients locally, ipxe will not be able to retrieve content from them, as V2 hashes cannot be used to get V1 content. Got that? Good.. To do this, we can use PowerShell. Simply execute the following Publish-BCWebContent Path C:\ProgramData\2Pint Software\2PXE\Remoteinstall Recurse UseVersion n* * Use 1 or 2 here depending on which version of Windows your clients are using. Using the Recurse switch tells BranchCache to create hashes for files in all the subfolders of \RemoteInstall BranchCache Client Configuration Next we need to configure the Windows desktop systems for BranchCache. The easiest way to do this is to use Group Policy, although for testing purposes you can also configure individual systems as required using PowerShell or Netsh.exe commands.

24 23 BranchCache Client Group Policy Configuration To create a Group Policy object and configure BranchCache modes Open Group Policy Management In the Group Policy Management console, expand the following path: Forest: example.com, Domains, example.com, Group Policy Objects, where example.com is the name of the domain where the BranchCache client computer accounts that you want to configure are located. Right-click Group Policy Objects, and then click New. The New GPO dialog box opens. In Name, type a name for the new Group Policy object (GPO). In the Group Policy Management console, ensure that Group Policy Objects is selected, and in the details pane right-click the GPO that you just created. Click Edit. The Group Policy Management Editor console opens. In the Group Policy Management Editor console, expand the following path: Computer Configuration > Policies > Administrative Templates: Policy definitions (ADMX files) retrieved from the local computer, Network, BranchCache. Click BranchCache, and then in the details pane, double-click Turn on BranchCache. The policy setting dialog box opens. In the Turn on BranchCache dialog box, click Enabled, and then click OK. To enable BranchCache distributed cache mode, in the details pane, double-click Set BranchCache Distributed Cache mode. The policy setting dialog box opens. In the Set BranchCache Distributed Cache mode dialog box, click Enabled, and then click OK. We then need to configure firewall settings for the BranchCache clients. Configure Windows Firewall with Advanced Security Inbound Traffic Rules In the Group Policy Management console, right-click the BranchCache client computers GPO that you created previously. Click Edit. The Group Policy Management Editor console opens. In the Group Policy Management Editor console, expand the following path: Computer Configuration, Policies, Windows Settings, Security Settings, Windows Firewall with Advanced Security, Windows Firewall with Advanced Security LDAP, Inbound Rules. Right-click Inbound Rules, and then click New Rule. The New Inbound Rule Wizard opens. In Rule Type, click Predefined, expand the list of choices, and then click BranchCache Content Retrieval (Uses HTTP). Click Next. In Predefined Rules, click Next. In Action, ensure that Allow the connection is selected, and then click Finish. Important

25 24 You must select Allow the connection for the BranchCache client to be able to receive traffic on this port. To create the WS-Discovery firewall exception, again right-click Inbound Rules, and then click New Rule. The New Inbound Rule Wizard opens. In Rule Type, click Predefined, expand the list of choices, and then click BranchCache Peer Discovery (Uses WSD). Click Next. In Predefined Rules, click Next. In Action, ensure that Allow the connection is selected, and then click Finish. Important You must select Allow the connection for the BranchCache client to be able to receive traffic on this port. BranchCache Client Command Line Configuration Windows 7 netsh br set service MODE=Distributed This will configure the BranchCache service in distributed mode and also configure the Windows Firewall in one go neat! Windows 8/10 You can also use the above, or PowerShell. Enable-BCDistributed is all you need to setup the client in BranchCache distributed mode. Client Hash Version Configuration Once the BranchCache desktop clients are all setup, you need to decide how to configure them for hash retrieval. Here s the logic to help you decide. If your server is WS2008R2 It will only serve up V1 hashes so you need to set the clients to use V1 If your server is WS2012, you need to decide based on the client base. Mostly Windows 7 Clients If your desktops are mostly Windows 7 (with some Windows 8 or 10), you should set the clients to only use V1 hashes. Mostly Windows 8 or 10 clients but with some Windows 7. You should still use V1 hashes All Windows 8 or above Use V2 hashes no changes required as the server will automatically create V2 hashes if requested. Configure desktop clients hash version Group Policy for V1 hashes, set the Configure Client BranchCache Version Support policy to : Windows Vista with BITS 4.0 installed, Windows 7, or Windows Server 2008R2 For V2 hashes, set the policy to: Windows 8

26 25 Using PowerShell (on Windows 8 or above), simply execute Enable-BCDowngrading and the client will be forced to request only V1 hashes. For a Microsoft ConfigMgr implementation there are two main prerequisites that must be in place. 1. WinPE Boot images which have been prepared for booting using ipxe according to this guide 2. A functioning ConfigMgr Distribution Point to which the WinPE Boot images have been distributed 3. ipxe Anywhere specific security configuration Generating WinPE Images for ConfigMgr In order to use the ConfigMgr integration you have to generate the boot images with the BranchCache for OSD tool BranchCache WinPE Generator.exe. This will ensure that: 1. The BranchCache client into the boot images, you are not required to use BranchCache, but then why wouldn t you? 2. Adding BITS into WinPE image, again not required but offers many advantages. 3. Adding the ipxe WinPE Client into the image a. This is required for getting and setting the right info for the Task Sequence to start For more information on how to generate these WinPE images please refer to the BranchCache for OSD documentation. This is available here: ConfigMgr Distribution Point The ConfigMgr Distribution Point (DP) should ideally be dedicated to ipxe Anywhere PXE Booting. A small VM will suffice. If this is possible, also ensure that: The DP should be enabled as a HTTP Content server and IIS/BranchCache should be configured as described above. DO NOT install WDS or a PXE Service Point on this system, as it is not required. The 2PXE service replaces that functionality. ConfigMgr Security There are three settings required for working with ConfigMgr. Enabling SQL login for the Service account Enabling access for the generation of State Messages Ensuring files can be accessed during the boot process. Ensure access to the inboxes\auth\statesys.box for the service account. Ensure that HTTP downloads of the WinPE images from the DP is using anonymous security. Ensure you have right access to the SQL DB for the service account that runs 2PXE. If you are not using ConfigMgr then the only security related issue is to ensure that the boot URL returned from the PowerShell command is accessible with anonymous security.

27 26 Allow Access to create ConfigMgr State Messages State Messages are required so that the PXE Deployment Flag can be set when using mandatory deployments. Add the machine account of the Distribution Point that you are using as PXE point to the following local group on the ConfigMgr Site Server: SMS_SiteSystemToSiteServerConnection_Stat_CEN Figure 5 shows the local group for accessing the State Messages. This group is managed by ConfigMgr for accounts or machine accounts used for connecting remote site systems to the site server to report status. This will allow access to the Status Manager Inboxes. BETA NOTE In future releases we aim to remove this dependency by creating State Messages programmatically via the Management Point. Ensuring access to the boot files There are several different ways to ensure access to the boot files: 1. Enable Allow clients to connect anonymously on the Distribution Point where the boot files will be downloaded from. The boot files do not contain any harmful data, and if you are using PXE today they are accessible without user authentication via TFTP. Figure 6 shows the anonymous access setting on the Distribution Point object. In order to allow download from ipxe you need to enable the Allow clients to connect anonymously option.

28 27 Allowing Access to the ConfigMgr SQL Database 2PXE uses SQL as the fastest way to retrieve boot actions for a system. Add the service account (default the machine account of the Distribution Point) to the ConfigMgr_DViewAccess local group on the ConfigMgr Site Server. Members in this group have the required access for using distributed views against the ConfigMgr database. The account only requires read rights and can be further locked down if necessary. Figure 7 shows the local group for accessing SQL, the SQL reporting group provides sufficient SQL rights. 2PXE Service Install The installer is an MSI, which adds a Windows service for hosting the proxydhcp and the TFTP service. There is one installer for x86 and one for x64. Only pre-requisite is.net 4.0. Installation requires administrative rights, as does running the service as it creates BCD files which requires administrative rights. Licensing Licensing for ipxe Anywhere is provided via a Licensing.cab file which will be supplied to you. The license file will contain your company information and is used to validate the installation.

29 28 Figure 8 shows a dumb picture showing the content of the typical installation download. One x86 installer and one x64 installer plus a default license file. Manual Installation Start the installation by executing the correct installer (x64 for x64 systems). Ensure you have the License.cab available for the installer to access. The following Welcome dialog will appear After you click the Next button the license agreement page appears, click to agree the terms and conditions after you read through and agree to all the statements.

30 29 The next dialog is the Licensing dialog. Here you have to select the license file for the installer to continue. Click on the button to browse for the License.cab file. Browse and select a valid License.cab file and click Open The path to the license file will now be updated. NOTE: If you select an old expired license file the installer will continue but the 2PXE service will stop soon after starting. In this next dialog you have the several options. Select to use either the PowerShell or ConfigMgr Handler Select the method for connection to ConfigMgr (http or via MP) Unknown machine support Use the embedded boot.sdi in WinPE Use the ipxe Loaders Use HTTP for ipxe to 2PXE comms Next, configure the account under which you wold like the 2PXE service to run, either LocalSystem, or using a specific domain account. Note that this account must have the Logon as a Service right if it s a domain (or local user) account.

31 30 Next, you can choose a port for the 2PXE HTTP service. The default is 8050 but you can change that here. Click the Test Port button to test, and then click Next. If you are using the ConfigMgr handler, enter the server name of the server that hosts the ConfigMgr Database. If you are running 2PXE on that server, you can select (local). Click next to continue. The installer should then connect to that server and fill out the Database name for you. Check this, and if it s correct, click next to continue. Otherwise enter the correct name.

32 31 In this screen you can configure account that will be used to connect to the ConfigMgr Database from the 2PXE service. We recommend that you use the same account that you specified for the 2PXE service, but you can choose a separate account if you wish. Don t say we didn t warn you.. You are required to test the connection to verify that it has the correct rights before you can continue. Tell the installer where you want to install the 2PXE service, and click next. We re now ready to unleash 2PXE magic, so go ahead and click on Install, sit back and enjoy a cup of tea? The installer will go about its business, doing its thang as the kids would say. If you asked what it was doing it would say, Installing got it? Once completed, hit the Finish button to exit the installer. You are now done!

33 32 Command Line Install NOTE: Because there are many options to configure via the command line install, we have created a PowersShell Script to use as a wrapper for the MSI Install. Instructions for use are found in the PowerShell Files included in this release. The install can be configured through the following basic commands: Installation on an X86 machine: MSIEXEC /i "2Pint Software 2PXE Service (x86).msi" CABSOURCE= C:\Temp\License.cab INSTALLTYPE= 2 SERVICE_USERNAME=<domain>\<username> SERVICE_PASSWORD=<password> REMOTEINSTALL_PATH=C:\RemoteInstall /l* C:\Temp\2PXE.installation.log Installation on an X64 machine: MSIEXEC /i "2Pint Software 2PXE Service (x64).msi" CABSOURCE= C:\Temp\License.cab INSTALLTYPE= 2 SERVICE_USERNAME=<domain>\<username> SERVICE_PASSWORD=<password> REMOTEINSTALL_PATH=C:\RemoteInstall /l* C:\Temp\2PXE.installation.log The above examples are bare minimum examples. You may want to configure more properties during install, and we have included a reference of all the MSI properties below. Mandatory MSI Properties CABSOURCE=<Full path to License.cab> Full path to where you have your license.cab file INSTALLTYPE="N 1 is PowerShell integration, 2 is with MS ConfigMgr Integration SERVICE_USERNAME= LocalSystem or "domain\username" if you want to use a domain account SERVICE_PASSWORD= xxxxxxxx Can be skipped if SERVICE_USERNAME is LocalSystem) Optional MSI Properties CONFIGMGRSQL= 1 1 to enable a SQL connection to the ConfigMgr DB, 0 to use HTTP via the Management Point (no menu) If CONFIGMGRSQL is set to 1 the following parameters must be set RUNTIME_DATABASE_LOGON_TYPE=WinAuthCurrentUser "WinAuthCurrentUser" uses Integrated Security. "SqlAuth" if using SQL Accounts. ODBC_SERVER= myserver.domain.local RUNTIME_DATABASE_NAME=CONFIGMGR_xxx CONFIGMGR_<SITECODE> FQDN of the ConfigMgr Database Server ConfigMgr Database Name, typically REMOTEINSTALL_PATH= <path to remote install folder> Media folder for the service where computers will boot from DEBUGLOG_PATH="C:\MyLogfiles\2PXE.log" Path to the logfile

34 33 DEBUGLOG= 1 1 to enable and 0 to disable verbose logging POWERSHELLSCRIPTALLOWBOOT_PATH Path to the PowerShell extension script for boot requests. POWERSHELLSCRIPTIMAGES_PATH Path to the PowerShell extension for image selection. RUN_ON_DHCP_PORT Specifies if the service should respond on DHCP port - 1 or 0 RUN_ON_PXE_PORT Specifies if the service should respond on PXE port - 1 or 0 RUN_TFTP_SERVER Specifies if the built-in TFTP Server should be started - 1 or 0 RUN_HTTP_SERVER Specifies if the built-in HTTP WCF Server should be started EMBEDDEDSDI="1" for more info F12TIMEOUT= 10000" deployments in milliseconds. Use an embedded boot.sdi image. See full documentation F12 prompt timout for ipxe loaders for non mandatory IPXELOADERS= 1" # Use ipxe Boot Loaders 1 to enable and 0 to disable. If 0 2PXE will use Windows boot loaders UNKNOWNSUPPORT= 1" Machine support in ConfigMgr PORTNUMBER= 8050" 1 for enable (default) 0 to disable - enables Unknown 2PXE Http Service Port by default POWERSHELLSCRIPTALLOWBOOT_PATH= c:\myscripts" for.ps1 scripts POWERSHELLSCRIPTIMAGES_PATH="c:\myscripts".ps1 scripts Set only if using custom path location Set only if using custom path location for INSTALLFOLDER="C:\MyInstallPath" ENABLESCCMMENUCOUNTDOWN="10000" selcted (in Millisecs) Default is C:\Program Files\2pint Software Countdown for menu timeout if nothing is ENABLESCCMMANDATORYCOUNTDOWN="30000" Countdown for Mandatory deployments - the deployment will be executed after this expires (in Millisecs) SCCMREPORTSTATE="1" Instructs 2PXE to send SCCM state messages for mandatory deployments. 1 to send, 0 to not send. WIMBOOTPARAMS="gui" command line for wimboot. Possible parameters are: gui, pause, pause=quiet, rawbcd, index=x For details see: ENABLEIPXEANYWHEREWEBSERVICE="0 IPXEANYWHEREWEBSERVICEURI="<url>" NOT ENABLED IN THIS RELEASE NOT ENABLED IN THIS RELEASE

35 34 2PXE Post Installation Configuration Installation Files The 2PXE service can be installed to any location, but we recommend it to be installed in the default directory. Once the service is installed, the following files should be present in the installation folder: Main Service Executable 2Pint.2Pxe.Service.exe Configuration File 2Pint.2Pxe.Service.exe.config Main DLL 2Pint.2Pxe.dll License file License.cab License file License.nfo extracted from License.cab 3x Microsoft.net dependency dll s 2x PowerShell scripts for managing the PowerShell Extension Readme.txt End User License Agreement file Boot folder with ipxe boot loader files & wimboot binary Important: Ensure that the License.nfo file has been created and that the license information inside the file looks correct by opening it up in notepad. Service The Windows Installer file will install a service called 2PXE which it will also start during the install. Typical failures to start can be that the license file is wrong, or that something is using the ports that 2PXE is trying to use. The RemoteInstall Folder The RemoteInstall directory is created in the ProgramData folder. Under the 2Pint Software\2PXE folder as per below: Note: These files are left behind after an uninstallation of 2PXE, but can be removed if the PowerShell removal script is used.

36 35 Inside the RemoteInstall folder you have more folders with default and temporary files. These files are managed by the service and normally don t require any fiddling with. Figure 9 shows the root of the RemoteInstall directory used for hosting the boot files used by the TFTP transfer. The only file that requires attention is the Sources, where the WinPE boot images are accessed from. Images needs to be copied there to allow booting. If you are using the PowerShell extension with regular Windows Boot Loaders the Sources folder is where you place your boot images. 2PXE Windows Event log 2BPXE creates a Windows Event log at startup of the service, unless it already exists. Note: This log is not removed as a part of the uninstallation. The log is located under the Application and Services Logs in the Event Viewer. Adding Boot Images Important:The ConfigMgr integration handles its own Boot Image process and requires no configuration of boot images. If you installed the 2PXE server with ConfigMgr integration you can skip this section. When using PowerShell or the default Windows PXE providers in 2PXE you must provide the boot images manually or in a scripted fashion. The only rules there are: 1. Boot images have to end with.wim 2. They have to be present in a sub-folder directly under Sources folder 3. The image index booted has to be 1, i.e. the first image is booted 4. They have to be x86 or x64 at the moment, contact us for IA/ARM support 2PXE supports a range of WinPE 3.1 (Windows 7 SP1) to WinPE 6 (Windows 10) without any issues. If you are looking for IA and ARM support please support@2pintsoftware.com To add images, simply copy them into a sub-folder of the Sources folder, using a filename as the identifier of the image. The actual.wim file can have any name. The pictures below in the Adding

37 36 local images section shows 2 images, XXX12345 and XXX12346 both files are called boot.wim, but the folder name is used by 2PXE to reference the boot images in the menu. The exception to this is when you are adding boot images from a URL. Then they cannot be in a folder, they should be under the root of the BOOT_URL parameter. So then you can name your boot.wim to Start WinPE x86.wim and the name returned from your PowerShell should be Start WinPE x86. The URL encoding is done automatically. Once the images have been copied to the correct location, restart the 2PXE Service.

38 37 2PXE Service Configuration All 2PXE Service configuration is done through the application.config file (2Pint.2PXE.Service.exe.config) which is located in the 2PXE installation folder. Changes are not reflected until the service is restarted so please remember to start and stop after changes are made. Note: Copying from word can bring the wrong type of quote signs, so don t copy the quote signs into the config file. 2Pint.2PXE.Service.exe.config The 2Pint.2PXE.Service.exe.config file has the following for configuration options, not all settings work together, so some basic logic needs to be applied. See the table at the end of this section. EnablePowerShellExtension Enables the PowerShell Extension, allow control of the boot process via the PowerShell script specified in the PowerShellExtenstionScript below. This will move over the boot object to PowerShell which will return the correct actions for the machine booting via the PowerShell script. Value: 0 to disable and 1 to enable. EnableSCCMExtension Enables the SCCM Extension, can be used in conjunction with the PowerShell Extension. This requires the service to be installed on a SCCM Distribution Point and that you have access to the Site Server via the correct group membership. Value: 0 to disable and 1 to enable. EnableSCCMSQLConnection Specifies to use a SQL connection to the ConfigMgr Database and boots the boot.wim images directly from the DP. If you don t use this option 2PXE will use HTTP to get the boot request just like the ConfigMgr PXE Service Point and can only return one boot image per client. So SQL connection is recommended for ConfigMgr integration. Then you get the full fancy menu Value: 0 to disable and 1 to enable. ConfigMgrSQLConnectionString Connection string to the ConfigMgr database. This is used when the SQL Connection is used by setting the EnableSCCMSQLConnection value set to 1. To allow access to the DB, add the machine account of the 2PXE server to the local group ConfigMgr_DViewAccess on the site server. Or define a separate login if you want to. The format of the string is a typical.net connection string URI so port and other items can be specified. For more information please refer to: Value: "Data Source=<ServerName>;database=<DatabaseName>;Integrated Security=True" EnableSCCMUnknownMachinesSupport Support unknown machine support in SCCM. On/Off. Simple as that. Imagine if all settings were this easy? Value: 0 to disable and 1 to enable.

39 38 EnableSCCMMenuCountdown Sets the countdown for when only non-mandatory (optional) task sequences are targeting the computer. After countdown the computer exits to next boot device on the computer. A value of 0 (zero) disables this feature and the menu will prompt until a task sequence is selected. Value in milliseconds but keep the value above 1000 otherwise it might fail. Value: 0 to disable and boot last deployed mandatory TS and above 1000 to enable and wait 1 second, 3000 waits for 30 seconds etc. EnableSCCMMandatoryCountdown Sets the countdown when one or multiple mandatory task sequence deployments are targeting the computer. A value of -1 (minus one) disables this feature and the menu will prompt until a task sequence is selected. A value of 0 (zero) disables this feature and the computer will boot the mandatory task sequence targeted deployment with the highest deployment creation time, just like ConfigMgr does with the PXE Service Point. Value in milliseconds, zero or -1. Value: 0 to disable and boot last deployed targeting mandatory TS and above 1000 to enable, set to -1 to disable completely and prompt the user for selection. SCCMReportState Instructs 2PXE to send state messages to ConfigMgr for mandatory deployments. 1 to send, 0 to not send. Set this to 0 when using a Rubicon step in the task sequence to set the PXE flag. Value: 0 to disable and 1 to enable. EnableiPXEBootLoaders Specifies to use ipxe boot loaders instead of any Windows boot loader. When used ipxe boots the boot.wim images directly from the DP, when using SCCM and from HTTP server when using the PowerShell or default request handler. ipxe uses HTTP instead of TFTP from the RemoteInstall Directory. Value: 0 to disable and 1 to enable. ipxef12prompttimeout How long is the timout for the F12 notification for ipxe loaders for non-mandatory deployments in milliseconds. E.g = 10 seconds Value: nnnnnnn milliseconds UseEmbeddedBootSDI Specifies to use an embedded boot.sdi image inside the boot.wim file under the \sms\boot\boot.sdi folder. This is always present in ConfigMgr images, so then 2PXE always uses embedded boot.sdi file regardless of this setting. For non-configmgr installations, you may use a default WinPE image, and this file is not present unless added. If you cannot add this file to the boot.wim make sure this value is set to "0". Value: 0 to disable and 1 to enable. wimbootparams Specifies the command line to wimboot, possible paramteres are: gui, pause, pause=quiet, rawbcd, index=x For details see: Value: gui

40 39 EnableiPXEAnywhereWebService Specifies to use ipxe Anywhere Web Service. Value: 0 to disable and 1 to enable. ipxeanywherewebserviceuri Specifies the address port to the ipxe Anywhere Web Service. Please see the ipxe Anywhere Web Service information on how to configure this. Value: ipxe.webservice.local:8051 RemoteInstallPath Specifies the path to the RemoteInstall folder that contains boot files and images. It will be created if it doesn't already exist. You should always enter a local path, and can use environment variables. Sub-directories Boot, Tmp and Sources must be present immediately below this folder or they will be created by the service, so ensure you specify a path to which the service account has access. Value: %PROGRAMDATA%\2Pint Software\2PXE\Remoteinstall PowerShellExtensionAllowBootScript Specifies the path to the PowerShell script that manages reply to the client, if any. Note that this script does not return the boot image itself, and that this script can run multiple times per boot of each client. This will only return true or false and then the initial loader will contact the PXE server again with architecture info etc. It will not be created if it doesn't already exist. You should always enter a local path, or use environment variables for a local path. Value: %PROGRAMDATA%\2Pint Software\2PXE\PowerShellExtensionAllowBoot.ps1 PowerShellExtensionBootImagesScript Specifies the path to the PowerShell script that manages reply, boot files and images. It will not be created if it doesn't already exist. You should always enter a local path, or use environment variables. Value: %PROGRAMDATA%\2Pint Software\2PXE\PowerShellExtensionBootImages.ps1 EnableDebugLog Set EnableDebugLog to "1" to enable logging to the file specified in DebugLogPath. Value: 0 to disable and 1 to enable. DebugLogPath This log will be fairly verbose, so remember to set it to "0" to switch it off afterwards. Errors and warnings will always be logged to the 2PXE event log. Ensure that the service account has access to the path if no log is appearing. Value: "%PROGRAMDATA%\2Pint Software\2PXE\2PXE.log" RunHttpServer 2PXE has a built-in Web Service for ipxe integration. You can switch it off by setting the value to "0" below, for instance if you have your own ipxe Anywhere Web Service server this is not needed. The HTTP WCF service only allow access to files under the RemoteInstall directory, and cannot transfer files outside this location. Value: 0 to disable and 1 to enable.

41 40 RunOnHttpPort Sets the port for the 2PXE http WCF service to a unique value. Value: "8050" or any other value. RunOnDhcpPort By default, 2PXE answers on both the DHCP (67) port and PXE (4011) port. You can control this by setting the values to "0" for off or "1" for on below, for instance if this machine also acts as a DHCP server. Value: 0 to disable and 1 to enable. RunOnPxePort By default, 2PXE answers on both the DHCP (67) port and PXE (4011) port. You can control this by setting the values to "0" for off or "1" for on below, for instance if this machine also acts as a DHCP server. Value: 0 to disable and 1 to enable. RunTftpServer 2PXE has a built-in TFTP server, written by Jean-Paul Mikkers. You can switch it off by setting the RunTftpServer value to "0" below, for instance if you have your own TFTP server. Value: 0 to disable and 1 to enable. TftpFilter These are the folders beneath RemoteInstallPath that the TFTP server will serve files from. Specify one or more relative wildcard paths separated by semi-colon. Value: "boot\*;\tmp\*;\boot\*;tmp\*;\sources\*;sources\*" TftpBlockSize Tweak the values below to decrease image download times. Note that PXE BIOS, routers and other network equipment may limit these settings further. Set TftpBlockSize to 512, 1024, 1456, 2048, 4096, 8192 or Default value is Value: 4096 to set the block size to TftpWindowSize Tweak the values below to decrease image download times. Note that PXE BIOS, routers and other network equipment may limit these settings further. Set TftpWindowSize to the number of packets to send without waiting for acknowledgement. Maximum is 32, default is 1. Value: 16 to set to the recommended value of 16 which works on most HW. Valid Configuration Combinations The following list can be used to find supported and unsupported configuration combinations in this beta release, green indicating the really supported scenarios that we would like people to test: Enable PowerShell Extension Enable SCCM Extension Enable SCCMSQL Connection Enable ipxe BootLoaders Run http Server No Yes Valid Configuration

42 41 Yes Yes, but http is not used Yes No No No Yes, but http not used No Firewall Considerations The 2PXE and ipxe Anywhere web service both potentially requires changes to the firewall configurations. 2PXE uses the following protocols for booting WinPE images: Dynamic Host Configuration Protocol (DHCP) Pre-Boot Execution Environment (PXE) Trivial File Transfer Protocol (TFTP) Hyper Text Transfer Protocol (HTTP) The following table outlines the User Data Protocol (UDP) and Transmission Control Protocol (TCP) network ports that are used during the process. You can modify the values that have an asterisk (*) by using the instructions in this manual. What UDP TCP DHCP & TFTP 67*, 69, 4011*, Random 1 2PXE HTTP Traffic 8050* ipxe Anywhere 8051* The following steps explain the UDP and TCP ports that are used during image deployment: 1. The client performs a network boot. 2. 2PXE uses DHCP ports and TFTP to download the binary files. For TFTP and DHCP, you need to enable ports 67, 69, and The TFTP and multicast servers use ports in the range through by default. 3. In accordance with RFC 1783 ( the client chooses random UDP ports to establish the session with the server. If you are using a non- Microsoft firewall, you may need to use an application exception for TFTP on the 2PXE Server. 4. PXE Client downloads the configured boot loader using TFTP. 1 Random ports from through 65000*, to establish a session with the server for TFTP

43 42 5. The client downloads Windows PE, typically over HTTP or TFTP. and boots to the Windows Deployment Services client. This download also uses the same TFTP ports as mentioned previously or using HTTP directly from the 2PXE server or from the ConfigMgr DP or any other configured HTTP server. 6. If reporting is enabled, the PXE client will try to communicate over to the ipxe Anywhere Web Service.

44 43

45 44 %ProgramFiles%\2Pint Software\2PXE\2Pint.2pxe.Service.exe

46 45

47 46 Adding firewall port for HTTP Traffic

48 47 2PXE PowerShell Request Handler This integration is managed by two PowerShell scripts in the installation directory. One script is for dealing with the initial request, determining if the machine should boot at all. This will be executed several times during the boot process, depending on the DHCP client of the PXE capable device. This script is called PowerShellExtensionAllowBoot.ps1. The other script PowerShellExtensionBootImages.ps1 takes over when the machine has booted to either the WDS style loader or ipxe. This is typically executed once, but can be executed several times if ipxe loaders are not used. All the session information can be retrieved from the $SessionData variable. PowerShellExtension.ps1 Sample Script A sample extension script is present in the install directory, it s hardcoded to return images in the XXX12345 folder and the XXX12346 folder.

49 48 In the beginning of the script you need to get the variable from the boot request, using a param($sessiondata) entry: param($sessiondata) You can then use the $SessionData variable in order to get more data about the boot: $mac = $SessionData.ComputerIdentifier.MacAddress $guid = $SessionData.ComputerIdentifier.SMBios_Guid $arch = $SessionData.ComputerIdentifier.architecture #arch can have any of the following values: # IntelX86Pc # NecPc98 # EfiItanium # DecAlpha # ArcX86 # IntelLeanClient # X64 # EfiBc # EfiXscale # EfiX86X64 # EfiX86 $BootObject = new-object 2Pint.2pxe.RequestHandlers.Powershell.BootObject #You can end the request here by setting PSShouldboot to $false $BootObject.PSShouldBoot = $true $BootObject.PSBootForce = $true #Only used for ipxe Booting, set the URL to a location where wimboot.bin and your WinPE.wim boot files are located #When the 2PXE web service is running this value overrides the local images and the PSBootURL is used if specified. $BootObject.PSbootURL = " When booting with ipxe boot loaders the image name is the full file name without the file ending.wim. When using regular Windows boot loaders it is the folder name in the Images folder. To return boot images create a PowerShell hash table and set the BootObject.PSBootImage to this item. So if you are using regular boot loaders you would set the image like this: $bootimages $bootimages.add("<folder name>") Set the boot object to what your image hash-table $BootObject.PSBootImage = $bootimages Always return the object to the invoker by having the last line of the script returning this: $BootObject So if the folder name under the Sources folder is "XXX12345" you would set this, the real boot.wim can be anything you want it to be: $bootimages.add("xxx12345"," You can of course use the architecture variable for automating the right image selection, use if statements or any other standard PowerShell logic to determine the right boot image. A sample statement could look like the following: $bootimages #Selection of boot image per architecture type #Note that MOST BIOS x86 machines can run X64 today if ($arch -eq "IntelX86Pc" -or $arch -eq "X64" ) {

50 49 #return only x86 boot images $bootimages.add("xxx12345","x86") $bootimages.add("xxx12346","x64") } elseif ($arch -eq "EfiX86") { $bootimages.add("xxx12345","x86") } elseif ($arch -eq "EfiX86X64" -or $arch -eq "EfiBc") { #Return boot images for X64 EFI. $bootimages.add("xxx12346","x64") } If you are using ipxe you need to also define the architecture manually and the name is not a folder name, instead it s the WinPE file without the.wim extension. $bootimages $bootimages.add("my first boot.wim file","x64") $bootimages.add("my second boot.wim file","x86") $bootimages.add("my third boot.wim file","x86") $bootimages.add("my fourth boot.wim file","x86") $bootimages.add("my fifth boot.wim file","x86") #Set the boot object to what your image hash-table $BootObject.PSBootImage = $bootimages #Always return the object to the invoker $BootObject The variables for MAC, UUID and Architecture can be used to determine which images should be booted. In the initial request it s not guaranteed that system architecture correctly determines the actual hardware capabilities of the device. Typically the way to deal with this is to load the wdsnbp.com file for BIOS machines and the wdsmgfw.efi for EFI capable machines. This file is then loaded and detects the right capabilities of the system and responds accordingly. You can also use the MAC address with a filter to filter out certain Hardware models, even though this is not entirely reliable as hardware changes over time. Booting the initial boot loaders first of course adds constraints on bandwidth and overall system boot time, so for really poor bandwidth situations (128-56K) we don t recommend this model, it s then better to use the DHCP option to direct to the right boot ipxe boot loader and then let ipxe determine the CPU capabilities.

51 50 Troubleshooting Running the Service Interactively for Troubleshooting & Testing You can run the service directly from either a console or starting it by executing the executable from Windows Explorer. Ensure that the service is stopped before doing this. This starts the service in a command prompt window, allowing for simple troubleshooting as you can see the boot request roll through the window. When running in interactive mode all debug logging will be pushed to the console window. This will greatly help when you run into issues or want to showcase the technology. Please note that the console will run under the user executing it and not the service account (SYSTEM by default) which could lead to access violations. Note that boot speed can also be greatly reduced as the printing to console will take longer than the actual actions. We recommend that this mode is only used for testing or troubleshooting and is best utilized while booting a single sysem. As an example, the following screen shows the executable being run in interactive mode, failing to bind to HTTP.SYS as the port is being used by another process. Figure 10 shows the 2PXE service running interactively, failing to bind to the HTTP port (due to the service already running). Errors & Issues There are many things that can go wrong in 2PXE. If the machine is not booting it s likely that you have set a configuration that is invalid. Check the valid configuration options and if you can t find the issue enable debug logging and send us the log after trying to boot an image. Please include any PowerShell scripts as well as the.config file in the . the files to support@2pintsoftware.com or use our online forums.

52 51 Note: Don t forget to add all the files to a.zip folder otherwise the might get caught in a spam or antivirus filter. Failing with an invalid boot.bcd file When bootmgr.exe cannot find or read the BCD file: File: \Boot\BCD Status: 0xc000000f Info: An error occurred while attempting to read the boot configuration data. Likely casued by: The Failing to find the boot.sdi file Status: 0xc000000f Info: The boot selection failed because a required device is inaccessible. Likely caused by: 1. Not finding the boot.sdi file as it s not included in the image while the UseEmbeddedBootSDI setting is set to 1. Figure 11 shows the 0xc000000f error caused by a missing boot.sdi file. Connection Reset 0f0a6095 When the connection port is not answering: Likely cause, you have enabled ConfigMgrSQL integration but not enabled the HTTP server. This is not a supported scenario at the moment. Enable the 2PXE HTTP server by setting the RunHttpServer config value to 1.

53 52 Not enough RAM in target computer The following can occur if the target machine does not have enough RAM. Make sure that machines booted with 2PXE has at least 1024 MB of RAM. (More can be needed if the image contains x64 WinPE with.net framework and a large number of drivers.) Slow first boot with PowerShell Since the PowerShell script generates the BCD files on the fly, unless already created the first initial boot can timeout and go into retry mode as the creation of the BCD file takes too long. This is typically the case when not using the HTTP server and having the ipxe Boot Loaders enabled.

54 53 Depending on how many image BCD files are being returned it can take a retry or two before the machine is prompted with a menu or booting to an image. The second attempt will not go into retry as the BCD files will be reused. Since starting and stopping the service causes the temporary files to be cleaned out this is likely to happened in labs where starts and stops of the service is common. To avoid this, enable the HTTP service in the configuration file.

55 54 Further Reading Typical Network Transfer and Transfer Speed For a typical EFI boot, without the optional boot fonts, a total of 314KB of data is transferred per booting device. A 99,9% reduction from the standard TFTP protocol. All data sizes in Kilobytes. Note that the file version sizes are averages as some builds might include debug information and/or troubleshooting tools like nslookup and ping etc. File Name Size Hash size Purpose snponly.efi 150 N/A EFI ipxe bootloader, using UNDI, can t be use BranchCache as its the start of the process undionly.kpxe 75 N/A BIOS ipxe bootloader, using UNDI, can t be use BranchCache as its the start of the process WimBoot 35KB 1KB WinPE boot loader Boot.bcd 12KB N/A Typically about +8KB per added Boot Scripts 1-2KB N/A Auto generated Variable.dat 22KB N/A Transferred using TFTP from ConfigMgr binaries in WinPE Windows PE MB KB Size depends on drivers, optional components etc. The total transfer of data is then typically the ipxe boot loader, then wimboot (hashed or not) and the boot.bcd file + some ipxe scripts to hold it all together. Then we transfer the hash of the WinPE image which then does the TFTP download using TFTP. Transfer Kilo Bytes Comment Total BIOS WAN transfer with BranchCache Total EFI WAN transfer with BranchCache ~275KB ~350KB Reduction in percentage of WAN traffic -99.9% Yeah, it s that awesome! The following speeds have been noted in our labs downloading over a poor link, with BranchCache support 5 clients serving the WinPE image and on GigaBit network without BranchCache. The test speeds are with EFI capable devices and for downloading a 300MB WinPE image only. Bandwidth Up/Down/%Packet Loss Speed (mm:ss) Reduction from TFTP 56/33.6 Kb 2% (Modem) 02:00 Are you kidding me? 128/512 Kb 2% (ISDN/DSL Type) 00:30 Keep dreamin baby!

56 Mb/s (Typical T1) 00:10 Still aint happening! 10Mb/s 1% Loss 00:07 On a sunny day? Right! 100Mb/s 0,5% Loss 00:07 About 10 mins 1Gb/s 0% Loss with BranchCache 00:06 Down 1-5 mins 1Gb/s 0% Loss without BranchCache 00:02 Down 1-5 mins 10Gb/s 0% Loss without BranchCache Less than 1s Typical Boot Process A typical boot process using ipxe as the boot loader looks like the following: 1. Client starts, 2. Initiate the on board PXE ROM 3. PXE ROM requests an DHCP with HW capabilities in DHCP request a. Typically Option 60 and Option 97 is used for architecture management 4. DHCP Servers (Proxy DHCP or/and DHCP) responds with right filename depending on HW capabilities in the requesting DHCP package 5. PXE ROM merges DHCP with possible proxy DHCP response(s) according to the PXE standard, and developers interpretation of that standard. 6. PXE ROM initiates transfer of boot file using TFTP of file specified in merged DHCP offer (ipxe) a. Note: DHCP is not actually booting from DHCP Option #66 in DHCP, in the case of a Microsoft DHCP server it translates the IP address in DHCP Option #66 to an IP address into the SIADDR field of DHCP. If you are using a non-microsoft DHCP server you need to ensure it sends the SIADDR field of the 2PXE server. 7. TFTP of the boot loader finish 8. PXE ROM loads ipxe 9. ipxe initializes and does a whole lot of magic before launching the embedded script. 10. Embedded script checks that all seems to be in order and then process the logic. 11. ipxe contacts the ipxe Anywhere web service if this has been configured in the 2PXE configuration file. It does determine this by: a. Check DHCP option 175 for ipxe Web service if DHCP Option #175 is present b. Contact the boot server if DHCP Option #175 present c. For information on the ipxe process with the ipxe Anywhere Web Service please refer to the ipxe Anywhere Web Service documentation. 12. In the case of a missing 175 the ipxe client contacts the 2PXE server directly 13. ipxe sends up heaps of info about the client to the 2PXE Web Service 14. 2PXE process the data and depending on the configuration settings it executes a PowerShell script or talks to the ConfigMgr Database for boot actions. 15. A boot script is sent down to the client which executes it 16. ipxe executes the script and loads transfers the corresponding files listed in the boot script 17. Client downloads required files using HTTP with BranchCache support from the source

57 56 a. Wimboot as the kernel b. Boot.sdi as the NTFS virtual drive is included in the boot.wim image c. Optional boot fonts are used from the boot.wim image d. Bcd file is created dynamically by the 2PXE service e. WinPE boot.wim file 18. The WimBoot kernel boots the downloaded WinPE image using the bcd data 19. WinPE Client boots WinPE and executes the ipxe Anywhere WinPE Client who starts the WinPEShl.exe which starts the custom process or the ConfigMgr task sequence engine. Take it for a spin So what do the new wheels look like? Here are a few snapshots of what we can do. In the scale of coolness starting from not so cool going to ubercool. Boot via PowerShell to WDS style menu & TFTP DL Figure 12 shows the PXE ROM initiating the boot process. Figure 13 show the PXE ROM doing an TFTP download of the WDSMGFW.EFI file from the server with ip

58 57 Figure 14 shows the screen where the Windows boot loaders detects the architecture and does additional proxydhcp discovery. Figure 15 shows the prompt for user interaction by pressing the ENTER key after a valid boot image has been detected. If there was a mandatory deployment there would be no ENTER prompt and the machine would boot automatically.

59 58 Figure 16 shows the boot menu presented after several (two in this case) boot images have been returned.

60 59 Booting an ipxe VESA Compliant System Machines that support the ipxe VESA FrameBuffer support switch to 1024x768 resolution and show a background image. Virtual machines like VirtualBox and VMWare supports this. Hyper-v do not support this feature. Note: This feature is not yet available in EFI, but will be very soon!

61 60 Boot via PowerShell to ipxe menu Figure 17shows the 2Pint Software splash screen that indicates that the ipxe boot loaders are being used. Figure 18 shows the ipxe client requesting a DHCP address, this will be removed in later releases of ipxe as it's only in there to ensure that EFI loaders have access to an IP address. Cached DHCP info is currently not handed over to the ipxe client.

62 61 Figure 19 shows the menu presented when two optional boot image have been detected by 2PXE. Figure 20 shows the HTTP download of an image returned from the PowerShell script. Boot via ConfigMgr to ipxe menu of all available Task Sequences Figure 21 shows the menu when a single optional boot entry has been detected by the 2PXE server.

63 62 Boot via ConfigMgr directly from the DP via HTTP and BranchCache over a 128/512 link in seconds! In this scenario we have enabled ConfigMgr integration and enabled SQL connecting together with the ipxe boot loaders as well as the 2PXE HTTP WCF service. Figure 22 shows the HTTP download of an image directly from the ConfigMgr Distribution Point. Figure 23 shows the ConfigMgr prompt since the preferred advert setting is set. Other System Management Tools Other ipxe Anywhere can get the right boot actions from other systems by a few different ways: 1. Configure the 2PXE PowerShell scripts to talk to the other system. 2. Configure the ipxe Anywhere Web Service to talk to the other system directly. For more information on this please contact support@2pintsoftware.com