This article describes the new features and changes in the OS Provisioning tool in LANDESK Management Suite 9.6.

The focus on changes for OS Provisioning in LDMS 9.6 has been geared towards simplifying the process.

The older "OSD" product has been removed from the product and has been fully replaced by the Provisioning product.

LANDESK Provisioning takes the previous OSD concepts and extends them even further  LANDESK Provisioning offers true end-to-end Provisioning of a device from a "Bare Metal" metal state (No Operating System installed) to completely imaged, software installed, domain joined, LANDESK Agent installed, etc.

OSD is gone?  What happens now?

There is no upgrade process for existing OSD Scripts.    It will be necessary to create provisioning templates to perform the previous imaging tasks that OSD did.  Remember, Provisioning is not just for deploying images.  It can be used to distribute software, patch systems, execute scripts, etc.

The beauty of Provisioning is that you can chain an endless array of actions together.

New!   Simplified template creation process

LDMS 9.5 and subsequent service packs simplified the Provisioning templates and consolidated previously complex actions.

LDMS 9.6 furthers this by include simple template creation "wizards" to build a template foundation.

Creating a capture job has been simplified down to 5 steps within a single dialog:

1. Select “Capture Template” under “New Template”
2. Select “Capture template”
3. Select “Capture Image”
4. Name the template and give it a description.
5. Enter image file storage location.

Similarly, LDMS 9.6 has simplified creating a Deploy Image template into a single dialog:

New!  "Smart Partitioning" actions

There are two new partitioning actions that are referred to as "Smart Partitioning" actions.

Auto Assign Partitions

• Assigns standard drive letters to OS and Boot partitions
• This action discovers the OS partition and possible separate boot partitions and automatically assigns them standard driver letters.

• Action results: 
  
  Windows 7 and higher with separate boot partition including all UEFI:

OS Partition will be mounted as C:

Boot partition will be mounted as S:

         Windows XP and Windows 7 and higher with a separate boot partition:

OS/Boot partition will be mounted as C:

Create default partitions

• Assigns the default partitions for either UEFI or BIOS based computers.
• This action creates standard partitions as recommended for Microsoft operating systems (Windows 7 and newer)
• This prepares the disk for use with ImageX or other file based imaging tools.  The action will detect UEFI and BIOS based computers and configure the partitions.  Sector based imaging tools such as ImageW do not need this action.
• OS partition will be mounted as C:
• Boot Partition will be mounted as S:

LANDESK Provisioning takes advantage of the new "self-organizing" multicast.  This and other improvements to the software distribution model provide drastically improved imaging and software deployment speeds.

New!  "Installed Mapped Software" action

LANDESK Management Suite 9.6 offers a new "smart migration" feature that allows you to use your Software License Monitoring data to install or reinstall software as part of an imaging and system migration solution.  IProducts can be linked to packages, and in turn called as a group through a single "Install Mapped Software" action.

In addition any standard LANDESK query can be created as a "product" within the Software Licensing Monitoring tool.    An example of the use of this would be if you wanted to install software on laptops only, you could create a LANDESK query that would return results for only laptops.

"Smart migration" can also be used to upgrade or change software:

Examples:

Upgrade example: Map Office® 2010 to Office® 2013

Change software example: Map iTunes® to VLC Media Player

New!  "Device Name Prompter" action

This action changes the %ldhostname% variable to what is typed in.  This is to be run before an inject script action.  When the "Device Name Prompter" action runs it will pop up a windows asking the operator to enter the desired computer nam.e

Improved!   PXE Boot option configuration

• PXE Boot options have been moved from the "Configure Services" menu.  They are now located in the OS Provisioning tool under the "Preboot" dropdown.
• Changes made to the PXE boot options take effect immediately, no need to redeploy a PXE representative.  The client makes a web service call to download the F8 PXE Boot menu options.

New!   Disconnected Provisioning

This new option allows you to deploy templates from a thumb drive.

To create, put in the USB device,  right click the template, and choose  “Create disconnected template”.    (USB thumb drive will be formatted) .  The template will deploy the image, do CTOS,  install the agent (Self-contained.exe) and attempt any other action that does not require a core connection.

With connection to the core, Distribute Software, Patch System and other core-dependent actions will succeed.

New!   "Launch Template" action

This new action is used in migration scenarios for migration from one computer to another computer.  This action utilizes machine to machine mapping.  The actions from the launched template are not included into the sections of the current template, it is run entirely just after the first template.

Improved!   Change  Changes to the "Wait" action

• You can now cancel a provisioning “Wait” action.  Previously you had to wait until the timeout, or until the file existed that the Wait action was set to wait for.
• Wait actions are often used in troubleshooting to give someone a chance to into the command prompt in Windows PE to manipulate or view the file system or registry.

Improved!   Various Enhancements

• Better resizing of Template UI
• Ability to copy and paste from template  to template.
• Multiple templates can be open simultaneously
• Defaults to Windows PE for Boot Environment and Windows for Target OS rather than "
• Auto-naming of actions
• Action name and description shows on Client UI.
• History auto-refreshes.
• Wait UI can be cancelled.

Issue

Drivers listed as unsigned are not getting installed in HII.

Cause

Installing unsigned drivers only works when HII runs in WinPE.  In WinPE, HII calls DISM to install the drivers and passes the /forceunsigned switch in the DISM command line if you've selected this option.  However, DISM does not allow installing drivers in a live Windows environment so HII running in Windows does not use DISM.  Windows API is used instead, and Windows API does not provide a way to install unsigned drivers. 

Resolution

Install unsigned drivers during the WinPE pass of HII.  It may be necessary to make manual driver assignments to ensure the unsigned drivers are selected during the WinPE pass.  This document describes how to do so:

About HII Driver Selections

If you are running HII in WinPE but unsigned drivers are still not installing, check the DISM command line: 

1. Pull the DISM command, including switches, out of the hiiclient log in WinPE (x:\ldprovision\hiiclient.log):
   
2. Ensure /forceunsigned is included in the command line.
3. If it is not included, recreate your template and ensure that you check the box to Force unsigned drivers to install:

Additional Information

The failure of DISM to install drivers is logged here:

DISM relies on the driver .INF to know what files to install.   The .INF typically will have references to a .CAT file, a .SYS file, etc.   If any of the files referenced in the .INF are missing, DISM will fail, typically with an Error 2.

More information on troubleshooting HII can be found in these documents:

HII driver assignments:  Device Make or Model is not showing up in HII

HII is ignoring driver assignments

How to manage drivers using the HII tool

This article applies to LANDESK Management Suite 9.5

Issue:

When running a scheduled task to deploy the PXE Representative it fails.

Workaround:

The PXE Representative can be manually installed by following these steps:

1. Push the "PXE Representative Removal" script to the PXE representative and then reboot the PXE representative once removal is complete.
2. Copy OSDREP.MSI from the core under Managementsuite\landesk\files to the PXE Representative.
3. Manually run OSDREP.MSI on the PXE Representative.
4. Verify that the LANDesk(R) PXE MTFTP Service and LANDesk(R) PXE Service are both installed and started.
5. On the PXE representative, verify that within Program Files (x86)\LANDesk\PXE\System\images\ there are four folders:

   Boot, EFI, IA32 EFI, and x86pc

6. If missing files, the OSDREP.MSI may be corrupt. Obtain a clean copy of the OSDREP.MSI from an LDMS installer or Service Pack installation package.

Reviewed 7/30/2015

Problem

You are preparing to provision a new device model and need to setup HII driver detection.  Hardware Independent Imaging (HII) is an action you can add to a Provisioning template.  HII scans the target machine and identifies the hardware ID of all devices.  It then matches these hardware ID's to drivers in the HII driver library.  Once a match is made, the driver is copied to the device's hard drive and stored in the LD Driver Store (C:\Windows\lddriverstore).  HII then calls on DISM (if running in WinPE) or Windows API (If running in Windows) to actually install all the drivers.

HII allows you to use one OS image with multiple devices containing multiple hardware modules and still install appropriate drivers for each model.  It is important to note that HII does not actually install any drivers.  It's function is to first detect hardware IDs and match up drivers with matching Hardware IDs, and then copy said drivers into the driver store on the target device.  DISM or Windows API is relied upon to perform the actual installation.

Solution

In order to populate HII drop-down menus with the make and model for the new device, follow this article:

HII driver assignments: Device Make or Model is not showing up in HII

1. Run your provisioning template on the new device without including any HII action.  We want to see which devices are installed using default Windows drivers and which devices require HII drivers to install. 
   1. After the provisioning template runs and the device boots to Windows, look in Device Manager and identify the devices which are not installed.  There will probably be fewer devices than expected.
   2. Download drivers for these devices and manually install them.  Make a note if which drivers install successfully.
   3. On your core, copy these drivers into the HII library folders and rebuild the library:
      
      
   4. It is advisable to only add drivers to your HII library that are necessary for each make and model.  Adding unnecessary drivers increases the scan time when running HII and also could result in unexpected drivers being assigned
      1. Remember that HII matches drivers based on the Hardware ID.  Multiple drivers can have the same Hardware ID.  By keeping the HII library clean of unnecessary drivers we reduce the chance of an unexpected driver being matched and passed to the OS to install.
   5. Run your template again including HII actions.  In most cases all drivers will install properly.  If you identify that different drivers than expected are being installed, first determine if there is any effect to operation.  If the different drivers work fine, then there is no need to take further action.  If you do need a different driver to install, then go back to HII and assign that driver to the make, model and hardware device in question.

More Information

In your provisioning template, you can check a box to install unsigned drivers.  DISM is used to install unsigned drivers and DISM only runs during the WinPE pass of HII.  Unsigned drivers will not install during the Windows pass of HII:

Issue: Unsigned drivers not working in Hardware Independent Imaging (HII)

To add a driver to the HII driver store, you need the .inf file for the driver.  This is the file HII uses to populate the driver information.  Copy the .inf file and any other applicable files (.sys etc.) to the driver library.  If your driver is an .exe or other install package, try unpacking it with 7Zip or similar to locate the .inf file.  If no .inf is available for your hardware, you can create a software distribution package for the file and then assign this package in HII:

HII will only install Driver Packages during the Windows pass of HII.  It will not install driver packages during the WinPE pass. 

Reviewed 7/29/2015

Problem

After provisioning a device and deploying drivers via HII, the device bluescreens during boot.

More Information

When a device bluescreens during initial boot after provisioning it is sometimes related to a driver.  This type of BSOD is more difficult to troubleshoot since memory dump logs are not generated during boot.

For more information on Hardware Independent Imaging (HII) in general see these documents:

About LANDESK Hardware Independent Imaging (HII)

How to: Setup and configure initial HII Driver library, or setup HII for a new device make and model

About HII Driver Selections

HII driver assignments:  Device Make or Model is not showing up in HII

HII is ignoring driver assignments

Solution

We need to determine whether the BSOD was caused by drivers, and if so what driver(s) caused the bluescreen.  To do this:

1. Attempt to boot the device in Safe Mode.  In most cases, the device will still bluescreen when booting to safe mode.
   1. If you are able to boot into safe mode, look at the following logs:

      Setupapi.offline.log	Driver failures during the Component Specialization sub-phase of the Setup specialize phase.
      C:\Windows\Logs\DISM\dism.log	General DISM log
      hiiclient.log	Log generated during HII driver assignment

   2. These logs may give an indication of which driver is responsible for the BSOD
2. If unable to access the OS, the next step is to remove HII from your provisioning template and run the template on the device again.
   1. This will install the base OS and it should boot up without BSOD.  If the BSOD still occurs then you will need to investigate a cause other than drivers.
   2. Open Device Manager and look at which devices remain uninstalled.  Install these devices manually, making careful note of which drivers install successfully without issue.
   3. On the core, copy these good drivers to your HII driver library and build the library.  Assign these same drivers to the devices they install.  This should ensure that known good drivers are assigned for these devices and should eliminate the BSOD.
      1. If feasible, you should remove other drivers for this model from your HII library if they are not needed to install devices for this or any other model.  This lessens the chance that a bad driver will be selected for other devices.

Issue

Provision.log on the core server is filled with these linesfor Unable to find template for computer IDN 11108.

The log is similar to this one:

ERROR ProvisioningService 3/29/2011 7:29:38 AM : Unable to find template for computer IDN 11108
VERBOSE ProvisioningService 3/29/2011 7:29:49 AM : GetTaskXML, SIDS:
VERBOSE ProvisioningService 3/29/2011 7:29:49 AM : MACAddress: BC305BCFDFB4
VERBOSE ProvisioningService 3/29/2011 7:29:49 AM : SerialNumber: J68B8P1
VERBOSE TemplateFinder 3/29/2011 7:29:49 AM : >>GetTemplateForServer,computerIDN 11108
DEBUGGING TemplateFinder 3/29/2011 7:29:49 AM : >>GetProvisioningTaskForComputer.computerIdn 11108
INFO TemplateFinder 3/29/2011 7:29:49 AM : No task found. Check task with Done status.
ERROR TemplateFinder 3/29/2011 7:29:49 AM : couldn't find task for computer 11108

Resolution

In some rare circumstances the provisioning process ''forgets'' to remove that line from the actions.ini file and so the client calls the web service method GetTemplateForServer on the core server to ask to the core "what I should do?"

The provisioning for this machine is already terminated (or canceled) and so the core replies ''I do not know" and writes it in the log.

The solution is the following:

Stop the LANDESK services on the device and start them again.

Access the client identified with the Computer ID that is ''spamming'' the log

1. Launch CMD.EXE as administrator.
2. Issue the commands:
   

   CD "C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\"
   NOTEPAD actions.ini

   
   a. Launch CMD.EXE as administrator
   b. Issue the following commands:
   

   CD "C:\ProgramFiles (x86)\LANDesk\Shared Files\cbaroot\"
   NOTEPAD actions.ini

3. Remove the line where the provisioning is referenced.
   It should be something similar to this one:
   

   "landesk.provisioning=C:\ldprovisioning\LaunchLdprovisionAsUser.exeC:\ldprovisioning\ldProvision.exe-c PEBLNDSK01 -t C:\ldprovisioning-w 15 -r 20"

4. Save the file.
5. Open the file again with Notepad to be sure that the modification has been saved.
6. Reboot the machine

Introduction

Provisioning is one of the many features of LANDesk Management Suite. Often due to an incorrect configuration or other different type of issues, provisioning fails.

If provisioning uses WinPE to deploy actions defined within the previously scheduled template and it fails before the OS is deployed, the user may decide to look at the provisioning logs in WinPe to identify the problem which causes the failure.

Environment

LANDesk Management Suite (Provisioning through WinPE)

Review Date

30/07/2015

Assumptions

This document will not explain how to configure and boot into WinPE. It is assumed that the user has already scheduled a template and that the template failed before booting in the OS.

It is also assumed that the provisioning template is configured in order to keep the provisioning folder during the deployment.

How to:

To collect provisioning logs in WinPE in order to troubleshoot an issue.  If the failure occurs after booting into the Operating System, the logs will be located into the root location of the selected hard drive eg: C:\ldprovision .

Step by step

1. When the failure occurs, please click on the green button located at the bottom left hand side of the screen.
2. Select the option “New Console”

  3. Afterward, please write in the console the following command: “cd /ldprovision”

  4. In this folder will be presents all the logs files generated during the provisioning process.

          For e.g. If you need to take vision of the ldprovision.log, please use the command:“/ldprovision/ldprovision.log”

If support asked you to provide the provisioning logs please collect of the content of the ldprovision folder.

Note: If the system has already booted into the Operating System, the logs will be located into the root folder of the drive. E.g. C:\ldprovision

For more information about troubleshooting provisioning, please refer to this page : https://community.landesk.com/support/docs/DOC-23470#jive_content_id_Troubleshooting_this_Component

Reviewed 7/31/2015

For the most part, Windows 10 can be provisioned in the same manner as Windows 7 or Windows 8.  One common issue we have run into when sysprepping Windows 10 is an error related to Metro Apps.  A known issue with sysprep is that removing or updating built-in Windows Store apps causes Sysprep to fail.  When you install Windows 10 and log in as a user, some Metro apps are configured for your user account and this can cause sysprep to fail. 

The resolution is to remove these metro apps.  You can do so by following these steps:

1. Open powershell running as an administrator
2. Run the following commands:
   

   Import-Module Appx

   Import-Module Dism

3. Run this command to list installed metro apps:

   Get-AppxPackage -AllUser | Format-List -Property PackageFullName,PackageUserInformation

4. Next, review the setuperr.log located at C:\Windows\System32\Sysprep\Panther.  This log should show the package full name for the metro app causing the sysprep error.  Copy this package full name.
5. In Powershell, run this command:
   

   Remove-AppxPackage -Package <packagefullname>

6. Re-run sysprep.  It is possible you will get the same failure again, but for a different metro app.  Repeat steps 4 and 5 to remove additional metro apps that cause failures
7. When all necessary apps have been removed Sysprep should succeed.  Move on with the next step in the provisioning process.

See Microsoft Support for more information:

https://support.microsoft.com/en-us/kb/2769827

Reviewed 7/31/2015

The basic process for provisioning a Windows 10 device is no different than any other Windows OS, with a couple of exceptions that will be discussed below.  Here are the general steps you will follow.

Capture the Image

1. Create a capture image template in Operating System Provisioning.  Give the template a name and specify the UNC path where you will store the image.  Be sure to specify the image name with a .tbi extension as well.
   
2. Right-click the newly created template and select Edit.  Add or remove template actions as needed.  Generally, the template actions added by default are acceptable:
   
3. Before you capture the image you should prep the device with any apps or configurations that you desire to make according to the needs of your company.
4. You should also install the LANDesk Agent on the device and run an inventory scan.  This will ensure that this device's details exist in the LANDesk database and can be selected from the HII Dropdown menus.  See this doc for more info:
   HII driver assignments:  Device Make or Model is not showing up in HII
   1. Before running the capture, you should uninstall the LANDesk agent.  We do not recommend capturing your image with the LANDesk agent installed as it can cause issues with duplicate ID's down the road.
5. When everything is set up for the capture, run sysprep on the device.  Select the sysprep options that work in your environment and with your unattend.xml script.  If you are using the included LD_Default_Unattend.xml as your unattend script, then we suggest selecting OOBE and Generalize when you sysprep the device:
   
6. Run the capture template on the Win 10 device.  You can do this by adding the device as a bare metal server and scheduling the template against the bare metal server, or by network booting the device and pressing F8 to boot into WinPE, then choosing your template manually.
   
   

Known Issue

In our internal testing, we have identified a common issue running sysprep in Windows 10.  See this document for more info and the resolution:

"A fatal error occurred while trying to sysprep the machine" When running Sysprep during Windows 10 Provisioning

If you are imaging a UEFI tablet device, please follow these steps:

How to Provision a UEFI Tablet using ImageW

Deploy the Image

1. Create a Deploy Image template in OS Provisioning.  Give it a name and point it to the newly captured .tbi file.  Select your agent configuration, check the box for HII if you will be using HII, and select your unattend script:
   
   
2. Once created, edit your template and configure the template actions as necessary for your company:
   
3. Run the deploy template on the Win 10 device.  You can do this by adding the device as a bare metal server and scheduling the template against the bare metal server, or by network booting the device and pressing F8 to boot into WinPE, then choosing your template manually.
   
   

Purpose

This document contains the Image for Windows (ImageW) User manual. This is provided from TeraByte Unlimited. This can be useful when customizing Provisioning commands with the ImageW.exe tool in LDMS.

http://www.terabyteunlimited.com/downloads/ifw_en_manual.pdf

Applies to LANDESK Management Suite 9 SP3 and newer

Description

OSD.Upgrade.exe is run during the installation of a LANDESK Service Pack or any LANDESK patch that updates the WinPE image (boot.wim). It is responsible for configuring the image to function on a specific Core Server and migrating WinPE drivers from the boot.wim.bak into the new boot.wim. If OSD.Upgrade.exe fails, one or more of these steps may not be completed. This document will walk through re-running the OSD.Upgrade.exe installation step on the core server.

During the Service Pack or patch installation there may be a failure with the OSD.Upgrade.exe process. The install error may be similar to CommonCore.inf: (0xFFFFFFFF) OSD.Upgrade.exe,60000.  Review the osd.upgrade.exe log file found in C:\Program Files (x86)\LANDESK\ManagementSuite\log to get more specific information about the error. If desired the osd.upgrade.exe.log file can be renamed prior to running osd.upgrade.exe again to make current errors easier to find.

A common cause for this issue can be that one of the .WIM files is already mounted from a prior process or through manual intervention by an administrator.

Common Errors and Resolution

• Error: "Access Denied"
  • Errors referring to access denied indicates that a folder path in the boot.wim is too long. Often this path will be for a driver that was injected into the WinPE image. There are two option for correcting this error. The first option is to just start with a clean boot.wim and add the necessary drivers after completing the OSD.Upgrade.exe process. In LDMS 9 Service Pack 3 the WinPE boot environment requires Windows 7 32-bit drivers. Updating those drivers is a manual process so starting with a clean boot.wim may be a good option. The second option would be to mount the backup of the boot.wim (boot.wim.bak) and rename the directories in the InstalledDrivers directory to use shorter names. After completing one of these options follow the steps outlined below to re-run OSD.Upgrade.exe.
• Error: "CommonCore.inf: (0xFFFFFFFF) OSD.Upgrade.exe,60000"
  • This is a general error indication. Review the log for additional errors.
  • Check to make sure the boot.wim is not mounted on the Core server.
• Error: "DirectoryNotFoundException"
  • Errors referring to a .0 or an mpkg package indicate that a .0 file has been extracted to a sub-folder of the ldlogon folder. DO NOT delete any .0 files from the root of ldlogon. Navigate to the directory specified in the log (i.e. C:\Program Files (x86)\LANDESK\ManagementSuite\ldlogon\mac) and delete the .0 file. To prevent additional errors when re-running OSD.Upgrade.exe delete any additional .0 files that are found in sub-folders of the ldlogon folder leaving only the .0 files in the root of ldlogon. Follow the steps below to re-run OSD.Upgrade.exe.
  • Errors referring an ALL.REG file indicate that the wim file was still mounted when osd.upgrade.exe tried to execute. This is most likely due to errors in the previous attempt at running OSD.Upgrade.exe. Review the log and correct and additional errors found before following the steps below to re-run OSD.Upgrade.exe.
• Error Non-fatal error: FilterUnload failed, hr=0x801f0013
  • This is normal and does not indicate a problem. Continue reviewing the log file for additional errors.
• Error: System.ComponentModel.Win32Exception
  • You are running the process as a restricted user. Either log in as an administrative user or right click OSD.Upgrade.exe and select run as administrator.
    • Make sure that you are either logged directly into the core server or using Remote Desktop with a /admin switch as a full administrator.
      
• Error System.IO.IOException: Element not found.
  • This error indicates that there is still a wim file mounted. Review the log for additional errors prior to this error. Follow steps below to re-run the OSD.Upgrade.exe process.
• Error System.UnauthorizedAccessException
  • This error indicates either that there is still a wim file mounted, or that the bootmedia.wim.bak already exists. Bootmedia.wim.bak can be deleted as long as bootmedia.wim exists. Review the log for additional errors and then follow the step below to re-run OSD.Upgrade.exe.
• Error WAIK is not installed
  • This is normal and does not indicate a problem. Waik should have been uninstalled prior to upgrade. If Waik is installed, uninstall it. Continue reviewing the log file for additional errors.
• Error: Upgrade fails at HII step. Log will display RollingLog : HII: Setting driver repository path to "\\LDCoreName\ldmain\landesk\files\drivers" 08/05/2015 12:03:10 INFO 8732:1 RollingLog : HII: Initial driver file count to process:
  • In the \\LDCoreName\ldmain\landesk\files\drivers directory will be a db3 and db3 bak file. Rename the file to db3.old and db3 bak.old. Quit out of the installer and re-open and start install again.
• Error: "CommonCore.inf: (0xFFFFFFFF) OSD.Upgrade.exe,90000"
  • Download Streams from Microsoft (https://technet.microsoft.com/en-us/sysinternals/bb897440.aspx). Go into properties of Streams an unblock the application. Run Streams against the folder the LANDESK installer was extraced to and run Streams against the folder LANDESK is being installed to (ie, \Program Files\LANDESK). Make sure LANDESK installer is being run locally (not networked drive), you are upgrading the machine locally (not RDP) and run the installer as Administrator.
    

Preparing to Re-Run OSD.Upgrade.exe

After reviewing your errors and completing the steps above perform the following steps:

1. Start an administrator command prompt (right click the command prompt and select run as administrator).
2. From the command prompt navigate to C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot.
3. Run the following command:
   
   DISM.EXE /Get-MountedWimInfo
   
   • The command should list all images that are currently mounted. There are instances however where a mounted image will not be listed. Check for the existence of the folder original_boot_wim and/or new_boot_wim in the C:\Users\logged in user \AppData\Local\Temp\imgtmp\ directory.
     
     
4. For each image listed and all folders found in the imgtmp directory listed in step 1, run the following commands:
   
   
   • DISM.EXE /Unmount-Wim /mountdir:"c:\path to dir(s) found in previous step" /discard  Where mountdir is the mount path listed from the dism.exe /Get-MountedWimInfo command or the folders specified in step 3.
   • DISM.EXE /Cleanup-Wim
   • Ensure that each unmount command completes successfully
   • Any errors that DISM may encounter will be logged in the %windir%\Logs\DISM directory.  (For further information see Understanding Failures and Log Files)
5. In Windows Explorer open the C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot directory.
   
6. Rename the existing boot.wim to boot.wim.bad.
7. Copy the backup boot.wim (the one from prior to upgrading) from C:\Program Files (x86)\LANDesk\ManagementSuite\backup\PatchName\ to the C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot directory.
   • If access denied errors occurred with drivers and a clean boot.wim file is desired, use the file listed in step 9 below.
8. Rename the restored boot.wim file in the vboot directory to boot.wim.bak.
9. Copy the boot.wim file from the installation package \image directory to the \vboot directory. You should now have a boot.wim and boot.wim.bak (either your backup or an additional copy from the patch) file in the vboot directory.
10. Run the OSD.Upgrade.exe from C:\Program Files (x86)\LANDesk\ManagementSuite\. This should take a few minutes to complete. If it exits quickly it is likely that there are additional errors.
11. Review the OSD.Upgrade.exe log found in C:\Program Files (x86)\LANDesk\ManagementSuite\logs to see if any additional errors were encountered. If additional errors were encountered, you must resolve each one and after resolving re-run OSD.Upgrade.exe.
12. If this still does not resolve the issue check "HKLM\SOFTWARE\Microsoft\WIMMount\Mounted Images" and remove any values in the key.

After OSD.Upgrade.exe has completed successfully you need to redeploy your PXE reps. Instructions for PXE deployment can be found at How to deploy PXE Representatives(step-by-step screenshots)

When a client machine boots into WinPE open a console to confirm the upgrade. The  version shown in the console should be 6.1.7601 or higher.

Issue:

It is failing when trying to copy the image file to the USB drive.
Following is in the provisioning.log file with xtrace enabled on the Console computer:
ERROR BootMediaHelper  8/3/2015 3:06:08 PM  : Error Mapping drive, lddwnld returned: 100003
ERROR PActionOffline  8/3/2015 3:06:08 PM  : Could not copy image file: \\ps-ldms-us\Images\SvrStd_2012R2_16gb.tbi

Solution:

1. Make sure the image file is captured so the files for the image are no bigger than 2 GB each. Use the /max:2GB switch when capturing the image with IMAGEWv2.
2. Install SP2 and the LD96-CP_BASE-2015-0722 patch or newer on the Core Server and Console computer.
3. Install the LANDESK Agent on the Remote Console computer if it is not already installed.

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 device, it could be related to NIC or BIOS firmware

Resolution for TFTP Service not started or needs 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 Representive 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

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 bind 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.
• Possily the network card driver on the clients need 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)

Environment:

LDMS 9.6

Review Date:

9/15/2014

Error Message:

DrvLoad: Unable to load X:\InstalledDrivers\...\e1d6432.inf (Error 0x80070002)

Problem:

When WinPE is attempting to load a driver, it fails.

Cause:

When going through an OSD or Provisioning task , WinPE uses drvload.exe to access drivers. If drvload.exe is unable to load a driver successfully for use, different actions can fail, including making network connections which are required for performing OSD and Provisioning tasks.

Solution / Workaround:

• Load the drivers' .inf file onto a thumb drive and attach to the machine that is booting into WinPE.
• Identify the thumb drives assigned drive letter
  • Open a New Console

• Type diskpart then press Enter.

• Type list volume then press Enter. This will dislay assigned drive letter.

• Identify the drive letter for the thumb drive.
• Type exit and press Enter.

• Next try mounting the driver from the thumb drive using the command: X:\Windows\System32\drvload.exe [usbDriveLetter]:\[path_to_driver]\[driver_name].inf

Example: The driver in this example is located on the root of C:\

X:\Windows\System32\drvload.exe C:\e1c6432.inf

• If the driver is compatible, the console will display: DrvLoad: Successfully loaded [usbDriveLetter]:\[path_to_driver]\[driver_name].inf

Example:

DrvLoad: Successfully loaded C:\e1c6432.inf

• If the driver is not compatible, the console will display an error.

Note: The error may vary.

Example:

DrvLoad: Unable to load c:\BadDriver.inf (Error 0xe0000100)

• If manually attempting to use drvload.exe to load a driver fails, this must be corrected before OSD or Provisioning tasks can work.

Possible Causes of a Failure

• The test may have selected the wrong file.
• Dependent files may be missing that are needed as a reference by the *.inf file.
  • .dll, .cab, .sys files may be dependencies for the driver. Try adding them if available.
• The driver file added may be corrupted. Try re-downloading and testing.
• The driver selected may be incorrect. Try a different driver.
  • Windows Blue drivers have been seen to work in some circumstances where Windows 8.1 x86 drivers did not.

Initializing the network stack after installing NIC drivers

• It is a common requirement to add NIC drivers to the boot.wim image so WinPE is able to get an IP address and communicate on the network
• After loading a NIC driver successfully, you need to initialize the network stack so that it uses the driver and obtains an IP address
  • You can do this simply by running netcfg –WinPEfrom the command line

Purpose

This article outlines how to add a Provisioning only user. This will provide rights to Provision devices, while restricting access to other features of the program.

Steps

• Add the user to the LANDesk Management Suite Group on the LDMS Core

• Add the user into User Management in the LDMS Core

• Assign the Provisioning role to the user

• Reset IIS

The user should now have access to access Provisioning Templates through WinPE.

Error Logging In

If the user is not setup correctly, it may fail during login with this message:

The user name or password specified is not correct. Provide new credentials.

If login fails too many times, it will fail with error:

error:[800001509H]The user name or password specified is not correct. Provide new credentials.

If a user is unable to log into the WinPE menu, their login failure will be logged in the IIS log:

C:\inetpub\logs\LogFiles\W3SVC1\u_ex150813.log

2015-08-13 16:54:19 10.14.130.58 POST /LANDesk/ManagementSuite/Core/Provisioning.Secure/ProvisioningSecure.asmx - 443 evdomain\BadCredentials

10.14.130.56 - - 401 1 64 625

If the steps above are all set, and the issue persists, the IIS error code can be reviewed for additional information.

Applies to all versions of LANDESK Management Suite

Question:

How to manually install a PXE representative with a USB key?

You may want to create a PXE representative on a distant managed device on another site, for example. And unfortunately the connecion to reach this site is poor or unreliable.

Answer:

The steps to install the files and services necessary to run a PXE representative via USB key on this managed device:

1. Copy the following files from the Core to the PXE Rep as per below.
   
   IMPORTANT!
   PLEASE NOTE: Some files when copied across also need to be renamed. EXAMPLE from below pxeboot.0 is renamed to startrom.0
   
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\files\bootmenu.1, C:\Program Files (x86)\LANDesk\LDClient\bootmenu.1"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\files\bstrap.0, C:\Program Files (x86)\LANDesk\LDClient\bstrap.0"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\files\dosundi.1, C:\Program Files (x86)\LANDesk\LDClient\dosundi.1"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\bootmenu.0, C:\Program Files (x86)\LANDesk\LDClient\bootmenu.0"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\dosundi.0, C:\Program Files (x86)\LANDesk\LDClient\dosundi.0"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\bcd.dat, C:\Program Files (x86)\LANDesk\LDClient\bcd"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\bcd_x64.dat, C:\Program Files (x86)\LANDesk\LDClient\bcd_x64"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\bcd_ia32.dat, C:\Program Files (x86)\LANDesk\LDClient\bcd_ia32"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\boot.sdi, C:\Program Files (x86)\LANDesk\LDClient\boot.sdi"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\boot.wim, C:\Program Files (x86)\LANDesk\LDClient\boot.wim"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\boot_x64.wim, C:\Program Files (x86)\LANDesk\LDClient\boot_x64.wim"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\bootx64.efi, C:\Program Files (x86)\LANDesk\LDClient\bootx64.0"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\bootia32.efi, C:\Program Files (x86)\LANDesk\LDClient\bootia32.0"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\bootmgr.exe, C:\Program Files (x86)\LANDesk\LDClient\bootmgr.exe"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\pxeboot.0, C:\Program Files (x86)\LANDesk\LDClient\startrom.0”
   
   
2. Place the file osdrep.msi into a share drive on the managed device (i.e. the future PXE Representative computer)
   NOTE: FInd the osdrep.msi on the Core Server on the folder "C:\Program Files (x86)\LANDesk\ManagementSuite\ldmain\landesk\files"
   
   
3. Run the following command from your managed device on CMD

"C:\Program Files (x86)\LANDesk\LDClient\sdclient.exe" /p="\\<YOURPXEREPNAME>\<YOURSHARENAME>\osdrep.msi" /msi /N /An /Ac

EXAMPLE: C:\Program Files (x86)\LANDesk\LDClient\sdclient.exe /p="\\W2K12DC\c$\osdrep.msi" /msi /N /An /Ac

IMPORTANT   Give sufficient time for the install to finish, it can take up to 15 minutes depending on performance.

Purpose

This document will outline getting started with provisioning a tablet using UEFI Unified Extensible Firmware Interface (UEFI) firmware.

.

Table of Contents

• Affected Platform
• Assumptions
• Samples and Information
• Tablet Requirements
  • Recommendation
• Disclaimer
• Steps
  • Get Doc/Dongle MAC address
    • Running GetMAC
    • Check Provisioning.log
    • Use Wireshark
  • Add Client Adapter as Bare Metal Server
  • Install Windows with GPT
  • Sysprep
  • Add Drivers to HII Library
  • Add Adapter Network Driver to Boot.wim
  • Capture Image
  • Create Deploy Image Template
  • Deploy Image

Affected Platform

• LDMS Core: 9.6 SP1

Assumptions

• LANDESK Management Core is installed and activated
• User is familiar with Basic OS Provisioning Capture and Deployment
• User is familiar with Basic HII use

Samples and Information

This document will use an HP Elitepad 1000 G2

as its sample tablet. The steps outlined here are for reference only. Different tablets will have unique driver packages and hardware information, but the process outlined should still be applicable.

Tablet Requirements

• This document is specific to UEFI based tablets/computers.
  • Though this document is not designed to address BIOS machines directly, the information can still be used as a guideline.
• The steps outlined here assume the tablet is not currently managed by the LDMS Core (i.e. there is no inventory record for the device)
• An Ethernet doc or Ethernet dongle
  • Provisioning via Wi-Fi is not supported
• Drivers for the Device
• Network Driver for Adapter

    Recommendation

• Vendor Whitepapers on Operating System Deployment (OSD) for the specific device
  • Though the steps outlined here will be general enough to be use-able for most UEFI tablets/computers, often times vendor whitepapers on the topic can shed light on known issues you may run into during imaging the device.

Example: Operating System Deployment to the HP ElitePad 1000 with MDT and ConfigMgr

Disclaimer:

This document is intended as an example only and is offered "as is" without warranty of any kind. This document makes use of 3rd party software (Wireshark, Microsoft Sysprep). LANDESK does not support nor endorse any 3rd party programs.

Steps

Get Doc/Dongle MAC address

    Running GetMAC

• With the client hooked up to the adapter, boot into Windows and open a command prompt window.
• In command prompt run getmac
• The physical address will indicate known MAC addresses

Note: More than one physical address may be identified. If uncertain which is specific to the adapter, use one of the other methods of identification.

 

 

    Check Provisioning.log

• Attempt to network boot the client.
  • This will cause the client to communicate with the PXE rep and subsequently check the Core for known provisioning tasks.
• On the LDMS Core open the log file: \\{LDMS-CORE}\ldmain\log\provisioning\provisioning.log
  • Example: "C:\Program Files\LANDesk\ManagementSuite\log\provisioning\provisioning.log"
• The first line in the log will list the MAC address of the adapter
  • VERBOSE    ProvisioningService        2/11/2015 8:20:21 AM    : >>GetProvisioningBootOption, clientMacAddress=000C293C7ABD

    Use Wireshark

• Install Wireshark on the LDMS PXE rep and begin a network capture
• Attempt to network boot the client.
  • This will cause the client to communicate with the PXE rep.
• In Wireshark, apply the Bootp filter
• Locate the DHCP Discover entry from your client
• Expand Bootstrap Protocol (Discover)
• Locate Client MAC Address, this is the adapters MAC Address

Add Client Adapter as Bare Metal Server

If a device PXE boots, and does not have a scheduled, started Provisioning task on the LDMS Core, it will receive a menu option which allows a user to decide whether to boot into WinPE.

(screenshot from client using BIOS)

Devices that utilize UEFI are unable to make use of the menu option by design. Because of this limitation, Provisioning a UEFI device requires the Provisioning task be scheduled on the LDMS Core.

.

When the client PXE Boots, it will broadcast its boot request information, including who it is (identified by its mac address).

If the PXE rep receives a DHCP Discover packet that contains PXE sub-options, it will communicate with the LDMS Core, and query to find if there are any Scheduled Provisioning Tasks for the device based off of its mac address.

We see this analysis on the core in the provisioning.log. (\\{LDMS-CORE}\ldmain\log\provisioning\provisioning.log)

• If the LDMS core does find a scheduled and started Provisioning task, it will inform the PXE rep what options it should send to the requesting client, and boot directly into WinPE.
• If the LDMS core does not find a scheduled and started Provisioning task for the requesting mac address, it will respond to the PXE rep indicating it should issue the F8 Boot Menu option. This is what we do not want for UEFI devices.

In order to schedule a Provisioning task for the client, there must first be a record on the LDMS Core to assign to the task. If the device already was managed by the LDMS core, you could use the existing device record in inventory. If however the device is not a managed device we need to add it into inventory as a Bare Metal Server

.

• On the LDMS Core, click Network View | Configuration | right click Bare Metal Server | choose Add Devices

• In the Add a bare metal server window, click Add.

• In the Bare Metal Server window that opens, enter
  • Name - something that will identify what the bare metal server is associated with
    • Since more than one tablet may use the adapter, I have named the bare metal server TabletAdapter.
  • Identifier Type - MAC Address
  • Identifier - The adapters MAC address we obtained earlier

• Click Add to commit the New Server Identifier

• Click OK to commit the new Bare Metal Server
• In the Add a bare metal server window we see the newly added bare metal server. Click OK.

• The Bare Metal Server list now contains the TabletAdapter we added. We will be able to assign this 'device' to scheduled provisioning jobs later.

Notes & Warnings

• Names cannot contain spaces, or most special characters. If you have invalid characters you will receive this prompt -

The computer name is invalid. Type a new name consisting of only alphanumeric characters and certain special characters such as - and _. A computer name can't contain any of the following characters:  `~!@#$%^&*()+[]{}\\|'\",<>/?.

• If you enter a Name, and click OK without first selecting Add it will not commit the change and you will receive this prompt.

To add a new bare metal server, you must specify at least one server identifier.

• MAC addresses must be alphanumeric only (no special characters such as : or - ). If the address includes any of these, you will receive this prompt.

The format of the MAC address is invalid.

Install Windows with GPT

We need an image of Windows configured for use on tablets. Since the tablets we are working with are UEFI, we must take some special considerations when configuring the OS so it will work on the devices. This includes configuring Windows to use the GUID Partition Table (GPT) as defined by Windows.

"When you deploy Windows® to a UEFI-based PC, you must format the hard drive that includes the Windows partition by using a GUID partition table (GPT) file system. " - Configure UEFI/GPT-Based Hard Drive Partitions

Note: When selecting the OS to be used on your device, it is advisable to verify vendor recommendations through published white papers specific to the device. For our sample tablet, the vendor has recommended use of Windows 8.1.

• Select a UEFI enable device to install and configure the GPT based image on.
  • How to setup a VM to use UEFI
  • If the following steps are performed on a device using BIOS instead of UEFI, it the GPT partitioning may be lost when Windows actually installs.
• Begin the Windows installation and stop at the Windows Setup screen

• At the Windows Setup screen, press Shift + F10 to open a command prompt

• Type: diskpart
• Press: Enter
  • This opens the windows diskpart command line tool
• Type: List Disk
• Press: Enter
• The results show detected disks on the computer. There is a column shown as GPT, which currently does not have a mark in it which indicates we are not using GPT on this disk currently.

Note: We need to select the disk that will have Windows installed to it. In our Diskpart output we see there is only Disk 0. You may have to adjust the following commands depending on your output.

Warning: The following commands will delete partition data from the drive. User assumes all liability when performing any actions contained within this document. Be certain you have selected the correct drive, there's no going back.

• Type: Select Disk 0
  
• Press: Enter
  • Output should show - Disk 0 is now the selected disk
• Type: Clean
• Press: Enter
  • Output should show - DiskPart succeeded in cleaning the disk
• Type: Convert GPT
• Press: Enter
  • Output should show - DiskPart successfully converted the selected disk to GPT format
• Type: List Disk
  
• Press: Enter
  • Output should show Disk 0 marked as GPT

• Type: Exit
  
• Press: Enter
  • This will Exit Disk Part.
• Close the Command Prompt window.
• Select Next to continue.
• Select: Install Now

• Select: Custom: Install Windows only (Advanced)

• Select: New

• In the Windows Setup prompt select OK

• There should be 4 partitions shown. Select Drive 0 Partition 4 (Primary) and select Next to finish installing.

Once installed, and inside windows, use DiskPart - List Disk to verify Disk 0 is still using GPT.

• If the DiskPart does not show that GPT is in use, retry the steps above and verify that the device is UEFI enabled.

More Info: How to perform a clean installation of Windows

Sysprep

With Windows installed and configured for our needs, the OS needs to be sysprepped to allow for use of the image among different machines.

Note:  OS Provisioning requires use of Sysprep to continue Provisioning commands after rebooting out of the WinPE environment and into Windows.

• On the machine with our configured Windows install,  run as admin  %WINDIR%\system32\sysprep\sysprep.exe
• In the System Preparation Tool use the following options
  • System Cleanup Action - Enter system Out-of-Box Experience (OOBE)
  • Generalize Check-box Checked
  • Shutdown Options - Shutdown

Note: We are using these options as outlined by Microsoft for preparing an image for deployment on other machines.

If you intend to transfer a Windows image to a different computer, you must run sysprep /generalize, even if the computer has the same hardware configuration. The sysprep /generalize command removes unique information from your Windows installation, which enables you to reuse that image on different computers. - What is Sysprep?

Once you select OK in the System Preparation Tool, the process will begin and shutdown the computer once finished. Since OOBE is in use, if you forget to configure something with the image prior to running sysprep and try to load back into Windows, you will have to go through the 'Welcome' screens before you can make your adjustments. Ensure everything is the way you intend prior to running Sysprep. Now that Windows is configured and sysprepped, it is ready to be captured to an image for later deployment.

Add Drivers to HII Library

Drivers specific to the device will be needed to allow full functionality once it has been imaged. Without utilizing HII to include tablet drivers, it is a common problem to end up without input drivers and not be able to use the touch-screen.

• Add device specific drivers to HII Library
• Rebuild Library

Related Documents:

About the LANDESK HII Driver Repository

About LANDESK Hardware Independent Imaging (HII)

About HII Driver Selections

Add Adapter Network Driver to Boot.wim

The tablet adapter will likely require a specific network driver that is not part of the default list of drivers contained within the Boot.wim. This driver is needed for the adapter to establish network communication with the PXE rep and Core during Provisioning.

• Extract the downloaded network driver and verify the presence of an .inf file
• On the LDMS Core click Tools | Distribution | OS Provisioning

• In the Operating system provisioning section select Preboot | Manage Drivers in WinPE Image

• In the Manage Drivers in Windows PE Image window, select the 32-bit or 64-bit boot.wim image and click Next
  • During the PXE boot process, the appropriate boot.wim file will be offered to the client. Depending on your tablets, it may be necessary to add drivers to the corresponding boot.wim file to prevent ending up loading a boot.wim that has no NIC driver.

• In the Add driver to Windows PE image click Browse

• In the Select the driver file window navigate to the extracted NIC drivers files, select the *.inf file, and click Open

• In the Add driver to Windows PE image the path to the *.inf file has been populated.
• Enter a Driver Name to indicate what driver it applies to and click Ok

• Verify the adapters NIC driver is listed in the Driver List
• Click Finish to commit the changes
  

After adding the adapters NIC driver, the boot.wim files will need to be redistributed to any PXE reps in use. This can be done 1 of 2 ways:

• Redeploy the PXE rep
• Manually copy/paste the boot.wim and boot_x64.wim to PXE reps
  • It is advisable to redeploy all PXE reps as it helps ensure no files are overlooked as oposed to the manual copy/paste process.

Capture Image

With the Windows Image configured, we are ready to capture.  The steps here outline basic, high-level configuration of a capture template to use ImageW.exe to obtain a .tbi file of the client device.

• On the LDMS Core click Tools | Distribution | OS Provisioning

• In the Operating system provisioning section select My Templates | All My Templates or Public | All Public Template

• Click New Template | Capture Template

• Fill out the Create Capture Image Template Window
  • Template Name - Provide a name for the Template that will identify it within the LDMS console
  • Template Description - Provide information about what this template will be used for
  • Image Type - LANDESK Image W V2
    • Other types are available for use. This document will utilize ImageW.
  • UNC Path to Image File - The Preferred server, share, Image name and extension.
    • When using ImageW the extension is .TBI
• Click Create
  

• Using the new template, capture the previously configured Windows Image.

Create Deploy Image Template

Now that the image has been captured to a .tbi file, we are ready to deploy to the tablet.  The steps here outline basic, high-level configuration of a deployment template.

• On the LDMS Core click Tools | Distribution | OS Provisioning

• In the Operating system provisioning section select My Templates | All My Templates or Public | All Public Template

• Click New Template | Deploy Template

• Fill out the Create Deploy Image Template Window
  • Template Name - Provide a name for the Template that will identify it within the LDMS console
  • Template Description - Provide information about what this template will be used for
  • Image Type - LANDESK Image W V2
  • UNC Path to Image File - The Preferred server, share, Image name and extension.
    • When using ImageW the extension is .TBI
  • Agent Configuration Name - The Agent that will be installed on the Tablet
  • Unattend Script - The Windows Unattend file to be used
    • For this example we will use the 9.6 default LD_Default_Unattend.xml
  • Target file name - C:\windows\panther\unattend.xml
    • This default path is automatically listed.
  • Use Hardware Independent Imaging - Checked
    • HII is necessary to make sure the tablet can be navigated once it is imaged. Without this, it is common for tablets to be missing input drivers.

• Click Create

The deploy image template will now be available for use.

Deploy Image

With the image captured, and the templates created, we are ready to deploy to the tablet.

• On the LDMS Core click Tools | Distribution | OS Provisioning

• In the Operating System Provisioning section, right click the Deployment Template | choose Schedule Template

• On the LDMS Core, click Network View | Configuration | Bare Metal Server
• Select the Tablet Adapter  Bare Metal Server and drag it onto the Deploy Template scheduled task
  • Alternatively right click the Tablet Adapter | choose Copy | right click the scheduled task | choose paste
• Expand the scheduled task and select All Devices to verify the Tablet Adapter is shown as assigned

• Right click the Scheduled Task and choose Start now | All

• The task will go from Pending to Active

• The task will go from Active to Pending and the Icon for the task will remain a Yellow Clock indicating it is started

• With the Tablet hooked to the adapter, network boot the device

Example: On the Elitepad this is done by hooking up a keyboard and pressing F12 while it powers on

As it completes the PXE Boot process, the device will be issued the Provisioning Information from the scheduled task and load directly into WinPE. The Provisioning task will lay down the captured image, then install drivers using HII. When CTOS runs and reboots the device into Windows, it will continue any configuration steps contained in the provisioning template. Provided the correct drivers were included in the HII Library, the device should have full functionality including touch screen capabilities. The scheduled task can now be restarted and used for other tablets that use the same adapter.

reviewed 8.10.2015

How To:  Use Unmanaged Device Discovery (UDD) for Rogue Device Detection

Disclaimer:  UDD was not designed to be used for this purpose.  UDD is capable of scanning for any device on your network and can fulfill the role of Rogue Device Detection, but such a configuration is non-standard and will not be supported by LANDesk support.  This is provided for informational purposes only.

For more information on using and setting up UDD please see these articles:

Device Discovery

Break Down of the Scanner for Unmanaged Device Discovery

Troubleshooting UDD (Unmanaged Device Discovery)

UDD can be configured to scan your network and identify any devices which are not managed by LANDesk.  UDD's primary purpose is to identify devices and provide a mechanism for targeting a LANDesk Agent install to these devices.  However, UDD can also identify devices on your network that do not belong.  There is no mechanism within UDD to determine if a device is valid or a rogue device - UDD will simply identify it.  It will then be up to you to determine if it's a rogue device or not.

If you are performing a UDD scan daily, you can review the UDD pane within LDMS and notice devices which do not belong.  This is a manual process.  You can also build a custom report or query which reports on UDD discovered devices, and  you can configure alerts when devices are reported.  Please note, LANDesk support cannot build or design custom reports and alerting for you.  If you need this work done you can engage professional services for an estimate.

With reporting and alerting in place, it is still up to you to determine if a device is benign or malicious. 

Updating WindowsPE Image

Any time that a driver is added to the WinPE image, or the WinPE image is modified in any way, those changes have to be transfered to all PXE representatives. Normally this is done by simply re-deploying the PXE representatives. However this can take up extra bandwidth and time. Attached are scripts that will simply copy the WinPE image from the core to the PXE representatives. There is a script for 8.8 and for 9. Simply download the script and save it to \\CORE\ldmain\scripts. Once there, it will appear with the All Other Scripts in the OSD tool with the PXE representative deployment scripts.

Note: This script WILL NOT install a PXE representative and should ONLY be run on clients that have already had the PXE representative deployed.

For LDMS 9.6 the process has changed- if you are on 9.6 or later, please follow these steps:

1. Open the script attached in this document, open up the ZIP file and then open the .ini file in a text editor.

2. Copy all the text/custom script data from that file.

3. Open up your core/console, go to Distribution > Manage Scripts.

4. Right-Click My Scripts and click New Custom Script.

5. Clear out all the information in the custom script template.

6. Paste the text from the .ini file

7. Name the Custom Script under Custom Script Name, "WinPE Update for PXE Representatives" or something like that.

8. Click Okay.

9. Once created- Right-click on the New Script and click "Schedule" and push the devices to your PXE representatives.

Date reviewed: 6/10/2015

Problem:

Your provisioning template is failing to inject the unattend.xml script correctly, or the unattend.xml is injecting but not being utilized by Windows.  You may see a failure of the Inject Script action, or it may show as successful but CTOS is not able to complete successfully and your template does not resume after the device reboots to the OS. 

Please note, it is beyond the scope of LANDesk technical support to build or troubleshoot the contents of your unattend.xml file.  We will troubleshoot issues where the unattend.xml is not injected or used by the OS.  See this Community document for more information:

LANDESK Support for Unattend.XML

For more information on troubleshooting CTOS, see this document:

How to troubleshoot the Configure Target OS (CTOS) action in Provisioning templates

Solution:

• Windows will look for unattend.xml files in several specific locations in a specific order.  This technet article lists the locations in order:
  Methods for Running Windows Setup
• If multiple unattend.xml files exist, Windows will use the first unattend.xml it locates and any others will be ignored.
• When preparing a device for image capture, you should delete any existing unattend.xml files on the hard drive to prevent the "wrong" unattend.xml from being used
  • If you have an existing image and it does contain an unattend.xml already, you can add a Delete File action to your template to delete it, prior to injecting the correct unattend.xml
  • If an existing unattend is found by Windows first, according to the locations it searches first, Windows will never locate and use the unattend.xml injected by LANDesk
• WinPE does not always assign the C: volume label to your OS partition by default.  This is a common point of failure.  If the inject script action puts the unattend on a drive that does not exist in WinPE it will fail.
  • In LDMS9.6 and later, you can add a Partition action to Auto assign partitions immediately after the Deploy Image action.  This partition action detects your OS partition and assigns the C: volume label automatically

• In LDMS9.5 and lower, you will need to use individual partition actions to set the OS partition to the C: volume. 
• Windows will search C:\Windows\Panther\ as one of the first locations.  This is a good location to inject the unattend.xml as it will be found first, before any conflicting unattend.xml files (if they exist) are located.  Configure this in the Inject Script action of your provisioning template

• To determine whether your unattend is injecting to the right location you can add a wait action to your Provisioning template right after the Inject Script action.  During this wait, open a console and review the logs.  This community document provides more information on reading WinPE logs:
  OS Provisioning - How to copy log files from WinPE and troubleshoot failing template actions
• The injectscripthandler.log will indicate which volume and file location the unattend.xml was injected to.
• From the console, run diskpart, and then list volume:
  
• Ensure the volume your unattend.xml is injecting to is the same as your OS volume.  If it is not, you can change the drive letter you inject the script to, or  you can add partition actions to change the volume letter of the OS partition. 
• Navigate the file system of your OS partition and validate that your unattend.xml file exists in the right location, and that no other unattend.xml files exist.  Running "dir /s unattend.xml" from the root of the OS partition will locate all unattend files that exist and show their location.