Issue

• WINPE is failing to load drivers that have been injected.
• WINPE is corrupt and needs to rebuild it.
• Need to create a new BOOT.WIM.
• BOOT.WIM file is missing from the Managementsuite\LANDesk\VBOOT folder on the Core Server.

Resolution

1. MOVE all of the following files on the Core Server to a Temp folder as a backup if they exist:
   • Managementsuite\BOOT.WIM.BAK
   • Managementsuite\BOOTMEDIA.WIM.BAK
   • Managementsuite\BOOT_x64.WIM.BAK
   • Managementsuite\LANDesk\VBOOT\BOOT.WIM.BAK
   • Managementsuite\LANDesk\VBOOT\BOOTMEDIA.WIM.BAK
   • Managementsuite\LANDesk\VBOOT\BOOT_x64.WIM.BAK
   • Managementsuite\LANDesk\VBOOT\BOOT.WIM
   • Managementsuite\LANDesk\VBOOT\BOOTMEDIA.WIM
   • Managementsuite\LANDesk\VBOOT\BOOT_x64.WIM
2. Copy BOOT.WIM and BOOT_x64.WIM from the Managementsuite\LANDesk\VBOOT\Clean folder to the Managementsuite\LANDesk\VBOOT folder on the Core Server.
3. In Windows Explorer, right-click OSD.UPGRADE.EXE in the Managementsuite folder on the Core Server and select the "Run as administrator" option. This will open a command prompt window that will stay open until it is finished.
4. When OSD.UPGRADE.EXE finishes, inject any required NIC or Disk Controller drivers into WINPE through the LANDESK Console.
5. For 2016 and older versions, redeploy all PXE representatives. For 2016.3 and newer versions, wait for the PXE reps to automatically download the BOOT.WIM and BOOT_x64.WIM files from the Core Server.

• Description
• What to Expect from Conditionals
• Adding Conditionals to a Template
• Utilizing Conditionals in conjunction with Public Variables

Description

This document is intended to cover the newly added feature of Conditionals in LANDESK Provisioning. Conditionals are best used to consolidate templates, allowing flexibility for:

• Multiple Images
• Software Distribution
• Disk Configuration
• Hardware Types
• BIOS Architecture

What to Expect from Conditionals

• Conditionals in LANDESK provisioning use "If and Else" arguments to determine multiple outcomes for a template.
• Stacking of multiple "if" conditionals is allowed. LANDESK will address all "if" conditionals one at a time.
• "Else" conditionals will only apply to the "if" conditional directly preceding it.
• Conditionals can be used at any point in the provisioning template, in any section.
• Custom scripts can be used in conjunction with Conditionals.
  • A successful script (return 0) will result in an "if" conditional being executed.
  • A non-successful script (not return 0) will result in LANDESK skipping past the associated conditional, or moving on to a corresponding "else" conditional.

Adding Conditionals to a Template

In this case, a default Deploy Template will be customized using Conditionals. To create such a template, browse to Tools>Provisioning. In the Operating System Provisioning tool, clickNew Template>Deploy Template.

Fill out the required fields and clickCreate.Should look something like this:

Right Clickany of the actions, and selectAdd Condition> If or Else

Utilizing Conditionals in conjunction with Public Variables

In LANDESK 2016, a new action type was introduced called Compare Variable. This action is extremely useful when using conditionals in provisioning. The following is an example of where to use this new feature:

We have an Image for Laptops and an Image for Desktops. How do we utilize both images in one Template?

This scenario will use the same template created above. The first step in using conditionals is to find a characteristic that LANDESK can use to differentiate between devices. LANDESK Inventory yields a different value for Desktops and Laptops.

For this example, we have "Chassis Type" recorded as NoteBook and Mini Tower. These values can be used as conditional arguments using Public Variables.

To add "Chassis Type" to public variables, open the Operating System Provisioning tool and select theTools drop-down list from the toolbar. Then select Public Variables.

Select Add. Enter any Search Value that seems fitting - needs to be one word. The Type will be set to "Database value." The replacement value will be set to the entry in inventory; "Computer"."System"."Chassis Type"

SelectOK.

Open the properties of the base template created above and right click the OS installation section from the Action List. Select Add Condition> If.

Right click the newly created condition and select Add Action. Select Compare Variable in the "Type" drop-down list. Select the variable created above in the "Variable" drop-down list and enter Mini Tower in the blank space. Click Apply.

Right Click OS installation once more and select Add Action. Select Deploy Image from the drop-down list, name the action appropriately, and click OK. Fill out the action properties to deploy the desktop image.

Now do the same with the Notebook image, only this time use an Else conditional. It should look something like this:

How To Configure PXE services in LDMS 2016.3 or higher

What's new in LDMS 2016.3?

After upgrading to LDMS 2016.3 you may find PXE booting is not working as expected.   In 2016.3 LANDesk introduces Self-Electing PXE Services which is a major change and improvement to the way PXE representatives are deployed.  LANDesk will automatically elect and manage PXE reps for each subnet.  No longer will you need to manually deploy and remove PXE reps via Software Distribution packages.  While this new method has many advantages over the previous method, it will require some configuration before PXE booting will work properly.

You will notice that ALL Windows agents have a C:\Program Files (x86)\LANDESK\PXE folder (<18MB), also you will notice that if an agent has ever been elected as the PXE Rep it will have the LANDESK PXE Service, and LANDESK PXE MTFTP service installed. However, if the client is not the acting PXE Rep they will not be running. This is to facilitate the Self-Electing Services management of the PXE Rep on a given subnet. Once a device becomes a PXE Rep it will automatically download the boot.wim (~315MB) and boot_x64.wim (~420MB) files. These files will remain on the client even if a new PXE Rep is elected and this client is no longer acting as the subnet's PXE Representative. This can equate to around 750MB of disk space on current and previous PXE Reps.

Also in 2016.3 the NetBoot services offered by the LANDESK PXE Rep have been greatly improved for better more consistent performance. For information about how to configure PXE Representative to offer NetBoot Images to Macinstosh clients as well please see Configuring PXE to Deliver NetBoot Services in LANDESK 2016.3

Self-Electing Subnet Services

For the purpose of this guide we are dealing with the PXE Service section of SESS and we will focus on that aspect.

Self-Electing PXE Services

When configured and enabled, your managed clients will automatically elect a PXE representative in each subnet.  If the elected PXE rep is turned off, damaged or stops responding, a new PXE representative will automatically be elected, usually within 1-2 minutes.  The necessary PXE software is now included with the standard agent install, but is turned off by default.  As you setup PXE services, you will determine which devices are available to be used as PXE reps and which subnets allow PXE booting, and then LANDesk will take over and automatically elect a PXE rep in each subnet.  LANDesk can dynamically reassign additional PXE reps if the previous PXE rep stops functioning.

Configuration

To setup Self-Electing PXE Services, we will configure Client Connectivity settings as well as the PXE Service within Self-Electing Subnet Services.

Client Connectivity

• You will notice a new menu in Client Connectivity agent settings called Self-electing subnet services.  Select the PXE service submenu and check the box to Enable PXE service:
  
• This setting is where you will specify which devices are allowed to be selected as PXE reps.  When this setting is enabled, all devices to which this client connectivity setting applies might at some time be elected as the PXE rep. 
  
  If you wish to exclude devices from being elected as the PXE rep, you will assign them a different Client Connectivity setting, in which the checkbox is NOT checked.

Self-electing PXE Service

• On the core navigate to Configuration -> Self-electing subnet services -> PXE Service:
  
• Within this new dashboard you will configure whether PXE booting is allowed on a subnet by subnet basis.  When a particular subnet is enabled, and when Client Connectivity settings for devices in that subnet allow it, Self-Electing PXE Services will elect and manage PXE reps automatically
• You can view the state of each subnet and view which device is currently elected as the PXE rep

PXE Settings

• This is where you can customize PXE boot options on a subnet by subnet basis.  Select the subnet you wish to configure, and then click the "service settings" button on the toolbar:
  
• In the window that opens, you can configure Polling frequency, TFTP block size, allowed or denied devices by MAC address, and download source and bandwidth settings for the WIM:
  

Polling Frequency

• This setting determines how often the elected PXE rep on the subnet should check for updated settings and WIM files.  The default is 15 minutes.  If you change your boot.wim be aware the PXE rep will not 'see' the change until it polls for changes again

TFTP block size

• This setting allows the wim files to be downloaded much more quickly, especially the boot_x64.wim.  The default size is 16384 for ia32 and 65464 for x64
  
  Be aware that some systems, particularly VMWare, require a block size of 1456, and your WIM images will not download if this setting is configured for a larger block size

Allowed and Denied

• Allowed specifies that the list of provided MAC addresses are the only devices on the subnet allowed to PXE boot
• Denied means all devices not on the list, but on the subnet, will PXE boot

WIM Downloader Settings

• In this section you can allow the WIM images to be downloaded from Peer, Preferred Server, and Source, or any combination of the three
• The WIM image must be available on the peer or preferred server and it must pass a hash check before it can be downloaded
• You may also elect to limit the WAN or LAN bandwidth used when downloading the WIM.  This is a selection of how much available bandwidth to use, not how much total bandwidth

Troubleshooting Self-Electing PXE Services

For some common troubleshooting steps and log information please see this document:
How to Troubleshoot Self-Electing PXE Services

Description

This document lists the new features that have been added to Windows Provisioning in LANDESK 2016.3. It also includes a PDF document that provides more details on the various changes.

New in 2016.3

• Self Electing Services PXE Representative (CSEP PXE)
  • How to configure Self Electing PXE services in LDMS 2016.3 or higher
• Control the values Provisioning uses to identify devices during provisioning tasks.
  • MAC Address
  • Serial number
  • AMT GUID
• Compare Variables in Real Time.
• Always PXE Boot UEFI Devices*
• Anonymous Login for Provisioning Templates in WinPE*

Error message:

The error message is located in the agent install log (C:\ProgramData\LANDesk\Log\wscfg32.log). The last message in the log will look like so:

Tue, 12 Sep 2017 09:32:59 INI:  EXEC49=C:\Program Files (x86)\LANDesk\LDClient\SCSDiscovery.exe, /Output Silent SystemDiscovery /NoFile, NOWINDOW + INSTALLONLY

Tue, 12 Sep 2017 09:32:59 Starting process: C:\Program Files (x86)\LANDesk\LDClient\SCSDiscovery.exe /Output Silent SystemDiscovery /NoFile

The agent install will be hung from that point on.

Cause:

SCSDiscovery.exe Is used to determine if the device is vPro capable. The device may not be ready to run that EXE and it may not have access to the DLL's it needs to determine vPro functionality. This is usually because the OS is booting up for the first time and goes through additional configuration on the initial boot.

Solution / Workaround:

Add a 200 second wait (This time can be adjusted as needed) as the first action is System Configuration. This will allow the OS to go through it's initial configuration/OS setup. In general, it's a good idea to put a wait at the beginning of System Configuration to allow the OS enough time to boot properly.

Hello All,

I cannot seem to get my windows 10 images to provision correctly.

We use ImageX in our environment. When I capture the image I used Sysprep with OOBE.

However when deploying the image, the task seems to stop at "Configuring Target OS" and stays "working". There is a cmd window that appears for a split second and then the machine reboots and loads into Windows and stops at the log in screen. Once I log in nothing happens. In our windows 7 images, the task window would appear after log in and continue running, adding to the domain and installing the agent.

There is an LDprovisioning folder in the C drive, however when clicking any .exe the whole folder disappears.

If I boot the machine back into PXE, it loads up the task again and finishes configuring the target OS task, then fails the "Add to domain" and "configure agent" tasks.

Also of note, the Device name prompter does not actually change the name of the machine. The original image name is retained despite the task saying it succeeded.

Any ideas as to what I am doing incorrectly? This same process works great with our windows 7 images, however I did not build those and the employee who did is no longer here.

Hi,

is there any way to restrict the download to a certain OS?

Regards

Marco

LDMS 9.6 SP3

Hi, I get this error while trying to provision a machine.

Any ideas?

Best.

I don't know where to report this as a bug, however, it is a pretty big one. So we use conditions (If/Else) to determine if software gets installed on a machine. What I have found is if you put one condition such as computer name ends in -00 or the explicit computer name the conditions work like they should. However if you put conditions to say computer name is between computer-00 and computer-50, the provisioning skips over it as if it doesn't meet the condition. It also does not work if you say computer name is greater than computer-00. so we had to create queries and set prerequisites in order to make sure only the machines licensed for the software got it.

Are USB 3 drivers the only reason that a second pass of HII is necessary during the System Configuration phase of Provisioning?  Will injecting USB 3 drivers into our WinPE boot image eliminate the need for a second pass?

I ask because the second pass is very hit or miss.  There are times when devices completely freeze during the process, where we have to manually reboot several times to get it to complete, if it does at all.  I would say that the second pass is only successful about 75% of the time when provisioning.  It also adds about 5-10 minutes to the provisioning process and I want to eliminate it if I can.

We are using EPM 2017.3 SU3

Thanks in advance for any advice.

Hi all, I'm looking for some documents for capturing and deploying an Ubuntu 16.04 on Ivanti Management Console. Could anyone can help me? Thank you.

has anyone else had the issue when performing provisioning tasks even though the task box is unchecked where it says to stop if task fails, the task fails and the provisioning stops. I then have to relaunch the ldprovision.exe to get it to continue. sometimes the tasks just stop responding and I have to reboot and relaunch ldprovision to get it to finish. This has been an ongoing problem since 2017.1. No one seems to really have an answer. It seems as if the connection from the task to the computer just stops. It is random. It is not always the same task. Surely this is working as designed?

Description

When PXE Booting you receive an error before booting into WinPE.

- TFTP Boot Issues

- PXE-032 Error

- NBD failing to load (freezes)

Cause

Starting in Windows 10 1709 build windows firewall has been updated to Windows Defender Firewall.

If you have your firewall enabled and you used to be able to PXE Boot it was because the PXE Services was set as an exception.

Solution

Windows 10 1709 requires that you specify the open ports for PXE into the Inbound Rules if you have your Windows Firewall enabled.

Ports used by LANDESK Management Suite - Full List

Open Windows Defender Firewall.

1. Test disabling it to see if this resolves your issue with PXE Booting. If it does then continue to add the Specific Ports into the Firewall Inbound Rules.

2. Windows Defender Firewall	Inbound / Outbound Rules

   
   
   
3. You can use the following document to reference Ports that LANDesk uses - Ports used by LANDESK Management Suite - Full List
   
   

4. General Tab	Advanced Settings	UDP Ports 67, 68, 69, 1758, 1759 and 4011

Issue

PXE Boot fails with a "TFTP TIMEOUT" error. This can also present as the following errors:

• PXE T04
• PXE-E36
• PXE-E32
• PXE Error M0F

Cause

• The most likely cause is that the LANDESK PXE MTFTP service is not running or needs to be restarted on the PXE Representative:
• VPN software has changed the MTU setting in the registry on the PXE Representative causing TFTP to fail.
• A network device in the network is dropping or malforming network packets.
• There may not be enough PXE representatives for the incoming network boot traffic.   Add more PXE representatives per subnet.
• If this is happening on only one device or one model of a device, it could be related to NIC or BIOS firmware

Resolution for TFTP Service not started or needs to be restarted

1. Open the Services applet on the PXE Representative (through Control Panel or type "services.msc" from the Run line"

2. Check the status of the LANDESK PXE TFTP service.   If it is not running, start it, if it is already running, restart it.

Resolution for PXE Representative MTU size

On the PXE Representative, do the following:

1. Open Regedit
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
3. Search for "MTU" and select "Match whole string only".
4. There will be an MTU value for each network interface
5. Verify that the value is set to 1500
6. The PXE Representative may need to be rebooted

You can also confirm the setting by running the command:

netsh interface ipv4 show subinterfaces

Value at 1500 in Registry for both screenshots but command shows the values are different for the LAN interface.

If you see MTU show a different number than 1500 you will need to run the following command:

netsh interface ipv4 set subinterface “Local Area Connection” mtu=1500 store=persistent

Other Considerations

• What are the specifications of the computer that is hosting the PXE rep?
• What Operating System is the PXE rep running?
• Is this server hosting any other connections?
• How many total network connections does the PXE rep show as active?   It's possible the connection limit could be full.
• What is the memory and CPU utilization?  Is it getting bogged down by something?
• Does he have any sort of security software on the server that may be analyzing incoming connections and thus slowing down the requests?
• Are there other boot servers or software that may be handling boot requests and causing a mix-up?
• Are the routers configured to forward all the traffic correctly?   Are all of the same clients served by one router?
• MTFTP runs on port 69.  Is there anything that could be interfering with that?
• What type of hardware are the clients?   It is always possible that this is an issue with a particular model or a few various models from a certain vendor.
  • Are there clients that work or not completely random?
  • Is the BIOS current?
  • Is there a firmware update for the NIC available that isn't applied?
  • Search for similar issues with that/those models of computers?
• There have been reports that this patch (http://support.microsoft.com/kb/953230) can cause issues with PXE and TFTP.
• Does the PXE rep have multiple network cards?   If so, is the binding order correct on them so that the ethernet NIC is first?  If they are teamed try breaking the team and setting only one card as active and check the binding.
• Possibly the network card driver on the PXE rep needs updating.
• Possibly the network card driver on the clients needs updating.
• This article may be helpful in understanding DHCP Options relating to PXE: http://www.experts-exchange.com/Networking/Misc/A_2978-PXEClient-what-is-it-for-Can-I-use-PXE-without-it.html
• Is there anything in the event viewer on the PXE rep that could be a clue?  Check system and application log.
• Is there anything that could be causing an IP address conflict with the PXE server?

More information on PXE boot errors:

PXE Boot errors and descriptions.

How to troubleshoot LANDESK PXE boot:

Troubleshooting PXE boot (OSD)

Problem

The message "No BitLocker recovery options available" is shown on a computer after rebooting from the Vboot action in a provisioning template.

Cause

The Vboot action performs a BCDEdit to have the computer boot from the boot.wim file downloaded from the core. Bitlocker in conjunction with TPM is specifically designed to prevent BIOS level threats to the Hard Drive and is working as expected when stopping Vboot.

Solution

Before setting BCDEdit options you need to disable or suspend BitLocker and Secure Boot on the computer. https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/bcdedit--set

Issue

When Provisioning with a Dell USB-C Network Dongle you are getting Duplicate Device ID's in your Inventory

Cause

The USB-C Network Dongle is designed to pass through the Internal Device MAC Address, without the correct drivers loaded into WinPE (How to add drivers to WinPE for Ivanti EPM OS Provisioning - How to add drivers to WinPE for Ivanti EPM OS Provisioning ) the device uses its own MAC Address. When loading into WinPE a mini scan runs which creates a basic Inventory entry with the USB-C Network Dongles MAC address. Then later when the device boots into Windows and the pass through begins to work the Agent is installed a second Inventory entries is created since it now has a different MAC Address.

Resolution

If you load the correct drivers for the USB-C Network Dongle then the pass through functionality will work within WinPE Environment.

Information from Dell - The USB-C Network Dongle is designed to pass through the Device MAC Address, this only occurs if the correct drivers are loaded into the WinPE Environment

Additional Information about WinPE Drivers:

How To Test Drivers Compatibility Within Winpe

How to add drivers to WinPE for Ivanti EPM OS Provisioning

Issue

Provisioning stops and to resume an HP USB to Ethernet adapter has to be removed and reinserted.

HP USB 3.0 to Gigabit RJ45 Adapter 829834-001

https://support.hp.com/hk-en/document/c04883825

RESOLUTION

Disabled the automatic driver update function of the HP USB 3.0 to Gigabit RJ45 Adapter 829834-001 using an HP Flash Disable Tool

ftp://ftp.hp.com/pub/softpaq/sp76501-77000/sp76691.exe

ftp://ftp.hp.com/pub/softpaq/sp76501-77000/sp76691.html

TITLE: HP Flash Disable Tool

VERSION: 1.0 REV: A PASS: 1

DESCRIPTION: This package provides HP Flash Disable Tool for supported models running a supported operating system. This applet disables the automatic driver update function of the supported accessories connected to the system. This accessory-specific applet may be needed in certain PXE environments that require automatic driver installations to be disabled.

PURPOSE: Routine

SOFTPAQ FILE NAME: SP76691.exe

SOFTPAQ MD5: 697d018d1ce7d5139cec47987041b7c3

SUPERSEDES: None

EFFECTIVE DATE: July 15, 2016

CATEGORY: Utility-Tools

SSM SUPPORTED: Yes

PRODUCT TYPE(S): Port Replicators;Cable Adapters

HARDWARE PRODUCT MODEL(S):

OPERATING SYSTEM(S):

Microsoft Windows 10 32

Microsoft Windows 10 64

Microsoft Windows 7 Enterprise 32 Edition

Microsoft Windows 7 Enterprise 64 Edition

Microsoft Windows 7 Home Basic 32 Edition

Microsoft Windows 7 Home Basic 64 Edition

Microsoft Windows 7 Home Premium 32 Edition

Microsoft Windows 7 Home Premium 64 Edition

Microsoft Windows 7 Professional 32 Edition

Microsoft Windows 7 Professional 64 Edition

Microsoft Windows 7 Starter 32 Edition

Microsoft Windows 7 Ultimate 32 Edition

Microsoft Windows 7 Ultimate 64 Edition

Microsoft Windows 8 32 Edition

Microsoft Windows 8 64 Edition

Microsoft Windows 8.1 32 Bit

Microsoft Windows 8.1 64 Bit

LANGUAGE(S): Global

DEVICES SUPPORTED:

HP USB 3.0 to Gigabit LAN Adapter (N7P47AA)

HP USB-C to RJ45 Adapter (V7W66AA)

HP USB-C to RJ45 Adapter (V7W66UT)

PREREQUISITES:

HOW TO USE:

1. Download the file by clicking the Download or Obtain Software button and saving the file to a folder on your hard drive (make a note of the folder where the downloaded file is saved).

2. Double-click the downloaded file and follow the on-screen instructions.

3. Go to the folder where the file was unbundled, double-click the FW_UPGRADE.exe file, and follow the on-screen instructions.

Problem:

You will see an error under Self-Electing Subnet Services for the "Current State" which will show "Subnet Error"

To review the cause of this error you will need to go to the PXE Rep / Client that is running PXE Services and open the Registry. Navigate to the following key:

HKLM|SOFTWARE|Wow6432Node|LANDesk|ManagementSuite|WinClient|CSEP

PXE Service "Subnet Error" (Boot.wim)	PXE Service "Subnet Error" (NBI / Netboot Image)

Log files to reference for Information about PXE:

Logs are located on the PXE Client - C:\ProgramData\LANDesk\Log\

PXESVC.Log

PXEMTFTP.Log

TMCSVC.Log

SelfElectController.Log

Sometimes its best to enable Xtrace logging to get more information from the logs - How to enable Xtrace Diagnostic Logging - https://community.ivanti.com/docs/DOC-32532

Resolution:

How to Fix issue with Boot.wim/Boot_x64.wim :

You will first want to make sure that the Boot.wim/Boot_x64.wim is copied to the PXE Rep in the following directory: C:\Program Files (x86)\LANDesk\PXE\System\images\Boot

If the file is not located here we should review the PXE Logs to find out why the Boot.wim & Boot_x64.wim are not being copied over. You can also try to manually copy the files from the core server from \\%corename%\ldmain\landesk\vboot\

How to Fix issue with Netboot Image:

Navigate to OS Provisioning by going to Tools - Provisioning - OS Provisioning from your Console.

Click on "Preboot" drop down and select "Manage NetBoot Image Mappings"

Manage NetBoot Image Mappings	Mac NetBoot Image Mappings

Browse to the location of your NBI (NetBoot Image file) and select it. Click Apply

How To

In this scenario, we have several NEW machines including different models to be provisioned and we need to deploy a different image according to the model. This scenario will show us how to collect the model of the computer in the registry within WinPE environment which will be reported back to the Core Server in the temporary inventory of this machine.

We will then use this value in the inventory to create some conditions in the provisioning template to deploy 1 image or another based on this value.

Step by Step

     Step 1: Create a batch file with the following code

FOR /F "tokens=3*" %%a IN ('reg query "HKLM\HARDWARE\DESCRIPTION\SYstem\BIOS"  /V SystemProductName  2^>nul') do miniscan.exe /send="Custom Data - Model = %%a %%b"

     NOTE: This code is designed to collect the device model name from a registry key, and then use miniscan.exe available in WinPE to report a custom data back to the Core Server to be available on the inventory of the device being provisioned.

     Step 2: Save this batch file onto a share folder

     NOTE: I called it "\\<CORESERVER>\TEST_SOFTWARE\SystemProductName.bat"

     Step 3: Go on your provisioning template and go in "OS Installation section"

          a. Add a first action of "Download Preferred Server" to download the batch file created in Step 1 into WinPE.

               NOTE: Do not forget to specify the Read credentials for the corresponding Preferred server (In my example, I defined a preferred server called "10.1.1.210")

          b. Add a second action "Execute File" to execute the batch file

          c. Now the value appears in the inventory of the new device:

          d. We can use an "if conditional" action to deploy one or another image depending on this inventory data:

          NOTE: see How to use Conditionals in LANDESK 2016 Provisioning to know how to use the conditionals (In this article, it actually explains how to deploy an image based on an inventory value, but for a computer which was already existing on the Core Server, hence the inventory data were already there).

Provisioning Template Process: Online vs Offline Compared

Ivanti Endpoint Manager Provisioning functions through the creation of Provisioning Templates.  By default, the device being provisioned will download the template itself and all related files during the provisioning process.  Sometimes it may be desirable to provision offline devices or devices that do not have a direct network connection to the core server.  In such cases, you can build a Disconnected Provisioning Template that can be deployed via DVD disk or USB drive.

Startnet.cmd

When a provisioning template begins, the startnet.cmd script is executed.  This script sets up the WinPE environment for OS Provisioning.  A sample script is attached to this document, and can also be viewed within your Boot.wim or in WinPE itself.  In WinPE it's located here:

x:\windows\system32\startnet.cmd

Offline Check

One section of the script executes a utility called OfflineCheck.  OfflineCheck scans all the mounted volumes looking for offline_task.xml.  Offline_task.xml is essentially the offline version of the template and actions to be executed, and should only exist in offline templates.  If the file doesn’t exist it is assumed that this is not an offline template and provisioning proceeds in online mode.

When Online

The startnet.cmd script is running in online mode and tries to resolve the Core Server's IP address.  If it fails to resolve, the template fails.  If it's able to resolve the IP it next attempts to ping the core by name.  If this fails, the template will still continue.  The startnet.cmd script then continues with standard actions such as an inventory miniscan, starting the remote control client, and eventually provisioning.

When Offline

All of the online processes are skipped and the device begins provisioning according to the offline_task.xml.

Troubleshooting

On occasion an offline template may run in online mode.  To troubleshoot this, we will want to compare the startnet.cmd script in WinPE with a known good copy such as the attached.  Next, check to see the offline_task.xml exists.  Its possible the Offline Provisioning Media did not create successfully or was modified post creation.

If all the above looks correct, watch the execution of the startnet.cmd script when WinPE first loads with the assumption that some action within is failing.  This process will generate an offlinecheck.log that is fairly verbose and should identify the problem.  One common failure is when copying some files to the ramdisk (X: drive).

In extreme cases you could mount the boot.wim and modify the startnet.cmd script to remove the “@echo off” from the beginning, in order to get better visibility to exactly where it is failing.