I have an image and I have sysprepped it (audit mode)

I have created the PE capture and it is available in my PXE boot.

Problem is it is trying to capture the whole disk instead of just the Windows Installtion.

Anyone know where I am going wrong?

It's Windows 7 64 bit image : Landesk 9.0.3.281

Thanks

Info about my environment

1) Image: Win 8.1 x64

2) LDMS Version: 9.6

3) PXE deployed with 9.6 support

I've followed the instructions already listed at How to run Provisioning tasks on a UEFI device

I couldn't believe I was having so much trouble getting this to work. So after a call to LDMS and talking to Nick, he discovered that by creating my device via Bare Metal it was assigning the core's IP address to the device and hence why UEFI PXE booting was not working.

The workaround? A simple and quick one liner done from the core's command prompt

"D:\Program Files (x86)\LANDesk\ManagementSuite\barescan.exe" -v name=DEVICENAME mac=DEVICEMAC  (note, to grab the mac I simply put the machine into legacy, waiting for the F8 Menu to come up and grabbed the mac from there. Just don't forget to put it back to UEFI)

While not ideal, its a temp workaround for us. Since this is a dev environment it's not major, but it's keeping up from rolling prod to 9.6 until this can be fixed.

Anyways, hope this helps someone else out there, and if you are having this problem, please let LANDESK know! Apparently I was the 1st customer to call this issue in. The more customers who report, the quicker this can get fixed.

Working with a new team in a new environment and getting them to move away from machine based images and move more to provisioning model for imaging.

The environment has LandDesk in place.  Doing some quick reading LanDesk can support provisioning for system imaging which I think is far superior to build images based on computer models.

My question to the LanDesk pros out here, how much time do you think an experienced tech should require to complete a fully provisioned configuration?  I think 50 man hours(totally being lenient).

Any feedback from the community is much appreciated

I've asked Mr. Google about this, but he hasn't been very helpful. 

I've created my thin base image of Win7 x64 Enterprise and generalize it before capture.  I have steps in the System Configuration phase that set the registry keys for pointing updates to our WSUS server.

I just recently noticed that updates are off after the template has finished.  A simple click of the button will turn them on, but that leaves it up to the technician to ensure that is done.

I went back to my base image vm and the updates are turned on before generalization, but when I generalize the vm, sysprep appears to be turning it off before shutting the vm down for capture.

I am running 9.5 SP2 and am planning on moving to 9.6 soon, but this doesn't seem to be a problem with LD.  Am I missing a reg key that turns them on?  Below are the registry settings that are being made in my template:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://windowsupdate.WSUSServer.com"
"WUStatusServer"="http://windowsupdate.WSUSServer.com"

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"AUOptions"="4"
"NoAutoRebootWithLoggedOnUsers"=dword:00000001
"NoAutoUpdate"=dword:00000000
"RescheduleWaitTime"=dword:00000001
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:0000000c
"UseWUServer"=dword:00000001
"NoAUAsDefaultShutdownOption"=dword:00000001

Hi all,

Running into a funky issue.  I have a 9.6 Core up and running (fresh install on Server 2012).  I used the nice new "Capture Template" available.  This is quite handy, but I'm running into an issue.

By default, the Dell Venue ships with 6 Partitions (that's right, 6).  After pre-populating a record in the new Core with the MAC address (serial number did not seem to work as the unique ID), and ensuring that the UEFI Network Stack was enabled on the Venue (in the BIOS/UEFI menus, still getting a grasp on what to call them now), I was able to boot to PXE on the Venue and the Prov Capture began (yay!)

The issue is, this Venue is running the Atom processor and the Dock only has a 10/100 NIC.  I'm using Imagew v2 and the capture was going to take about 2.5 hours to complete so I all but gave up, until I realized it wasn't only capturing the used data on each partition.  It was attempting capture of all 50GB of the Windows partition (only about 15GB are used on the partition).  I looked at the command lines of my capture scripts under 9.5 SP2 and they look the same, minus the /UY which just tells the imaging program to continue with no prompts.

Has anyone run into this?  I'd love to capture a hardware-specific reference image of one of these but it would be almost useless if it will take 2.5 hours to capture and potentially another 2.5 to re-deploy (haven't got that far yet).

Is anyone deploying Win 8.1 and have any insight?  Or more specifically doing tablet devices with multiple partitions?  This particular venue is UEFI only (no legacy boot ROMs) if that helps.  Thanks.

Getting a failure on installing a provisioning agent for 9.6. It is my first task after CTOS and I am using the "configure agent" action with telling it to use the self contained and it is the first task under "system configuration". The error is 1603 but i see nothing that explains that failure.

From the confighandler.log

2014-10-09 20:17:10(3676-3680) ConfigHandler.exe:Doing install of self contained agent.

2014-10-09 20:17:10(3676-3680) ConfigHandler.exe:Agent Path: \\"EDITED"

2014-10-09 20:17:10(3676-3680) ConfigHandler.exe:Attempting self contained agent install.

2014-10-09 20:17:10(3676-3680) ConfigHandler.exe:Checking for local version of \

2014-10-09 20:17:10(3676-3680) ConfigHandler.exe:Will attempt Peer Download.

2014-10-09 20:17:10(3676-3680) ConfigHandler.exe:Will attempt Preferred Server Download.

2014-10-09 20:17:10(3676-3680) ConfigHandler.exe:Destination describes an existing folder copying source file to it.

2014-10-09 20:19:30(3676-3708) ConfigHandler.exe:Download COMPLETE. Downloaded from \\"EDITED"

2014-10-09 20:19:30(3676-3708) ConfigHandler.exe:Destination path: C:\ldprovisioning\"EDITED"

2014-10-09 20:19:31(3676-3680) ConfigHandler.exe:going to execute C:\ldprovisioning\"EDITED"

2014-10-09 20:19:55(3676-3680) ConfigHandler.exe:system() return 1603

If I choose to let it continue all my software deployment tasks fail. However the last task of configure agent with the "production" agent is successful.

Hi All,

From reading other posts in this forum, it seems that Provisioning now supports this, but I am having trouble getting started. Specifically...

1. PXE booting with UEFI enabled times out with no message and returns to the boot menu (I have been able to boot from media)

2. How do you create the System and MSR partitions? How big should they be? What goes on these?

3. Deploying the OS to a GPT partition using DISM produces an "Error: 5 Access Denied" error.

I'm sure that after getting past these initial stages, I will have more questions. Any help will be appreciated.

We are running LD 9.5 SP2 with the 2014-0417 component patch. PXE Reps have been updated.

Thanks.

Pete

Purpose:

After making any change to the boot.wim, or after applying any major LANDESK patch on the Core Server, PXE Representatives should be redeployed.

Solution:

You have three methods to accomplish this. Your end goal is simply to replace all of the *boot*.wim files on the PXE Representatives so that they match what you have on the Core Server

Method #1: Schedule the PXE Representative Deployment script(9.5 or earlier) or Dist Package(9.6) and target your PXE Representatives.

Method #2: Copy over and replace all of the *boot*.wim files from your "...LANDesk\ManagementSuite\landesk\vboot" folder on your Core to your PXE Rep's "...LANDesk\ManagementSuite\landesk\vboot" folder.

Method #3: The following script will do Method #2 for you. Script to Update the WinPE image on PXE representatives

Problem:

We run a build template. During Inject Provisioning the following error is obtained

error:[80001003H)Can't create file c:\ldprovisioning\vcredist_x86.exe.

Cause:

The name of the core in the boot.wim needs to be changed to FQDN. Depending on your environment, you may need it to be netbios name or IP address.

Resolution:

The following steps will allow you to mount and edit your actual boot.wim image

1. Mount boot.wim with imagex using the /mountrw option.
     a. Create a new folder - c:\temp\mount - and close the window
     b. Open a CMD window and browse to C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot
     c. Verify that the window with the "temp\mount" folder you created is closed
     d. Run the following command;

          imagex /mountrw "C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\boot.wim" 1 c:\temp\mount

2. open up the "temp\mount" folder and change the core name in both of the following files
     a. C:\temp\mount\temp\CORENAME.TXT

          
     b. C:\temp\mount\Windows\System32\ALL.REG

         
3.. There are 3 options to choose from for the value you are changing in both of these locations (Unless you use a CSA or Gateway appliance, then there are only two options).
     a. Netbios name (simple name or hostname) of your coreserver. I.E. MyCoreName
     b. Fully Qualified Domain Name (FQDN) I.E. MyCoreName.MyDomain.com
     c. IP address. I.E. 10.10.10.20 (***if you have a CSA or Gateway appliance this is not an option for you, DO NOT use IP address in this location***)
4. Now you need to commit the changes and unmount the image.
     a. Make sure to close out the .TXT and .REG files and close any and all windows to C:\temp\mount\
     b. Run the following command in the CMD window from C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot;

         imagex /unmount /commit c:\temp\mount

5.Re-deploy the PXE Representatives in order for these changes to take effect.

Has anything successfully PXE booted their Surface Pro 3?

Surface Pro 3 - all updates

Official MS Surface Ethernet adapter

PXE Rep on same subnet (confirmed working with other computers)

When I attempt, I hold down volume down, tap power. It goes into PXE mode, then release volume down when Surface logo pops up. It then states it's looking for IP over IPv4, then switches to looking for IP over IPv6, then boots into Windows.

I've read elsewhere it will say to press enter if you want to boot into Windows PE, but I never get that.

I've tried turning safeboot off, no luck

Any help would be appreciated. .

Hi there,

I asked my networking colleague to include the "LANDesk(R) PXE Service" to the monitoring. He said, that the brackets are a problem for Nagios, but found a way to escape them with a special character. He says that it still does not work. --> No services matching ^LANDesk(R) PXE Service found : CRITICAL.

Can someone help or does anyone have this included in the monitoring?

Thanks for you help!

Environment

LANDESK Management Suite 9.6

Review Date

October 2014

Issue

• Provisioning is not aware of the scheduled task settings available for software distribution such as the the option to run the package installation from source.
• A device installing a software during a provisioning process will always try to download the distribution package locally before running the installation.
• Delivery methods are not used any more in LANDESK Management Suite 9.6.

How to

To avoid the target device downloading the installation files locally, we can set up a script that will run the package from a mapped network drive rather than from a UNC share.

Setting up our provisioning template to map a drive with a correspondent letter associated before running the software distribution will make the target device downloading a few bytes script and running the installation without downloading the package locally.

Step by Step

1. Define a drive letter suitable for both the Core Server and the target devices to be used for the network drive mapping

2. On a test client device, map the drive letter pointing to the software source or to a preferred server that has the same content replicated

3. On a test client device, verify that the installation of the package manually running the installer while pointing to the network drive just mapped, using the options you defined for your distribution package

4. On the Core server, create a script using the same command tested on the client device

5. On the Core server, create a batch file distribution package pointing to the script just created

6. On the Core server, while configuring your provisioning template, set up an action to map drive to preferred server, using the same letter defined at point 1

7. In the same provisioning template, after having mapped the designed drive letter to a preferred server, distribute the software package created at point 5

8. Schedule the provisioning template targeting a test device and verify that the package installation succeed without the client device downloading the files on the local file system

I noticed in 9.6, ImageX shows the progress of laying the image down.

Any chance we can replace whatever piece does this in 9.5 SP2 (or is it fixed in 9.5 SP3)?

Issue

• Booting a machine in UEFI mode in a network segment with an active PXE representative doesn't make the machine loading WinPE.
• The PXE menu doesn't appear.
• The machine reports the error PXE-E21: Remote boot cancelled
  
  

Solution

1. This can be caused by having duplicate MAC addresses listed in the inventory.   These can be found by creating a custom Column Set for the All Devices view and sorted by MAC Address.  

2. UEFI is still not compliant with the PXE menu specifications, therefore booting a machine in UEFI mode via PXE for provisioning works only when the device is associated to a provisioning task on the core.

The error PXE-E21 appears when the device is not associated to a provisioning task on the core.

LANDesk submitted an enhancement request to the UEFI Forum regarding this issue. Once they add the support needed, LANDesk will be able to support the PXE menu for the devices booting in UEFI mode as well.

At the moment, the only way to have the PXE menu functionality on a device booting in UEFI mode is setting it up to boot in Legacy BIOS mode.

We are seeing all of our images fail like clockwork at the "Install Provisioning Agent" action with a return error code of 1603 (MSG_ERROR_INSTALL_FAILURE).   I've turned on logging, and sure enough it's all going pear shaped during that action.

From the ldprovision log I can cull the following information:

2014-10-13 19:53:09(2788-2792) ldProvision.exe:*********  Begin an action - Configure_agent

2014-10-13 19:53:09(2788-2792) ldProvision.exe:Do EnvironmentCheck

2014-10-13 19:53:09(2788-2792) ldProvision.exe:Is WinPE Action=0, Is WinPe Environment=0

2014-10-13 19:53:09(2788-2792) ldProvision.exe:Report might reboot status to core.

2014-10-13 19:53:09(2788-2792) ldProvision.exe:Call web service SetActionStatus()

2014-10-13 19:53:09(2788-2792) ldProvision.exe:Start TryallWebService Attempt:0.

2014-10-13 19:53:10(2788-2792) ldProvision.exe:End TryallWebService Attempt:0. ExitCode:0

2014-10-13 19:53:10(2788-2792) ldProvision.exe:Session Data: <variables/>

2014-10-13 19:53:10(2788-2792) ldProvision.exe:Create process (C:\Program Files (x86)\LANDesk\Shared Files\httpclient.exe) with args (  -f "C:\ldprovisioning\ConfigHandler.exe" http://<CORE>/LdLogon/Provisioning/windows/ConfigHandler.exe)

2014-10-13 19:53:12(2788-2792) ldProvision.exe:Process exit code:0

2014-10-13 19:53:12(2788-2792) ldProvision.exe:The file (C:\ldprovisioning\ConfigHandler.exe) was successfully downloaded

2014-10-13 19:53:12(2788-2792) ldProvision.exe:Download handler ok.

2014-10-13 19:53:12(2788-2792) ldProvision.exe:Launching action handler [ConfigHandler.exe] with parameters ["]

2014-10-13 19:53:12(2788-2792) ldProvision.exe:handler launched.

2014-10-13 20:00:05(2788-2792) ldProvision.exe:Reporting action status: 5 to core

2014-10-13 20:00:05(2788-2792) ldProvision.exe:Call web service GetStatusString()

2014-10-13 20:00:05(2788-2792) ldProvision.exe:Start TryallWebService Attempt:0.

2014-10-13 20:00:05(2788-2792) ldProvision.exe:End TryallWebService Attempt:0. ExitCode:0

2014-10-13 20:00:05(2788-2792) ldProvision.exe:StatusString = The action failed.

2014-10-13 20:00:05(2788-2792) ldProvision.exe:Call web service SetActionStatus()

2014-10-13 20:00:05(2788-2792) ldProvision.exe:Start TryallWebService Attempt:0.

2014-10-13 20:00:06(2788-2792) ldProvision.exe:End TryallWebService Attempt:0. ExitCode:0

2014-10-13 20:00:06(2788-2792) ldProvision.exe:End of action - Configure_agent

2014-10-13 20:00:06(2788-2792) ldProvision.exe:Last action failed

2014-10-13 20:00:06(2788-2792) ldProvision.exe:**********************************  End processing actions  **********************************

2014-10-13 20:00:06(2788-2792) ldProvision.exe:ldProvision ended

I followed the thread to the ConfigHandler log, which tells me pretty much the same thing.

2014-10-13 19:53:12(1756-3056) ConfigHandler.exe:Got core name: <CORE>

2014-10-13 19:53:12(1756-3056) ConfigHandler.exe:Got config tool: wscfg32.exe

2014-10-13 19:53:12(1756-3056) ConfigHandler.exe:Got configuration file: Windows Provisioning Agent

2014-10-13 19:53:12(1756-3056) ConfigHandler.exe:Got user: <CORE>\ldadmin

2014-10-13 19:53:12(1756-3056) ConfigHandler.exe:password is not variable, encrypted

2014-10-13 19:53:12(1756-3056) ConfigHandler.exe:Mapping Drive

2014-10-13 19:53:12(1756-3056) ConfigHandler.exe:Going to connect

2014-10-13 19:53:12(1756-3056) ConfigHandler.exe:Going to decrypt password

2014-10-13 19:53:12(1756-3056) ConfigHandler.exe:going to try and connect to [] \\<CORE>\ldlogon with <DOMAIN>\ldadmin

2014-10-13 19:53:12(1756-3056) ConfigHandler.exe:going to execute \\<CORE>\ldlogon\wscfg32.exe /f /L /NOUI /NOREBOOT /C="Windows Provisioning Agent.ini"

2014-10-13 20:00:05(1756-3056) ConfigHandler.exe:system() return 1603

I can ping the CORE from this machine after it fails, but I understand that using the FQDN is best practice.   Based on the logs, it's not using the FQDN.   Could this be the source of the problem, and if so where should I make the change?  I've been through the Provisioning template and can't see any point where I only have the CORE listed.  The same goes for the Windows Provisioning Agent.   I've also rebuilt the agents, to no effect.

Any ideas?

Problem

In some situations it may be desirable to initiate a Provisioning task client side, without booting into WinPE.

Example: Launching a deploy profile Provisioning template.

Steps

• Create a directory on the client to contain the ldprovision.exe
  • C:\ldprovision
• Download/copy ldprovision.exe to the client machine.
  • Example location on Core: "C:\Program Files\LANDesk\ManagementSuite\ldlogon\provisioning\windows\ldProvision.exe"
  • Example destination on client: C:\ldprovision\ldProvision.exe
• Launch ldProvision.exe as the Local System Account
  • How to open a command prompt running as Microsoft's "Local System" account
• ldProvision.exe will begin downloading prerequisites
• When ldProvision.exe is ran as the Local System Account, it will present the Provisioning GUI which allows users to authenticate to the Core, and select templates.

Note: If ldProvision.exe is ran as any account other than Local System, it will present a command line interface.

Though this interface will allow users to authenticate to the core in the same manner as the GUI, its menu is not navigatable, as the directional keys/arrows act as escape commands.

Currently we are using Ghost as our main deployment tool for the OS Deployment tasks in provisioning.

The standard syntax that is added when selecting Symantec from the dropdown for Image Type is:

-clone,mode=load,src=I:\Image_File_Name.gho,dst=1 -sure -auto

I prefer a couple of additional switches & commands in the line, so I often edit this after it is created to add the necessary switches.

Is there a way to change the command line template so I can have the commands I use in the syntax by default when building the task?  Is this stored in a file somewhere?

currently on 9.5 but moving to 9.6 soon...

Thanks!

Problem

While attempting to create an image backup, you receive the following error message:

Unable to write data to file

An error message will also appear in the INF.log file. The exact error message will vary depending on the cause and the destination device. Several examples are shown below:

Error writing to \\SERVER\share\Backup-w2-0x1-S400-2010-12-24-1954.TBI (Buf:05440000 CurFP:0 Bytes:4096 Err:8h)
Error writing to \\server\share\catchweb.TBI (Buf:01950000 CurFP:93918820352 Bytes:59392 Err:5AAh)

This problem can affect all types of devices, but typically occurs with removable drives and NAS/Network devices.

Cause

Caching issues, file locking issues, and insufficient system resources can cause this problem.

Solution

Adjust Cache Settings (Image for Windows)

To change the cache settings Image for Windows uses, use the/po:nparameter (if running Image for Windows from the command line) or thePerfOpt=noption in the[Options]section ofIFW.INI (if running Image for Windows interactively). This option is used to manually control various file caching options of Image for Windows and Windows itself. The settings can have an impact on the overall performance and can be used to fix some driver-based problems as well.

The values forncan be as follows and combined using addition:

For example, users saving to an iPod and receiving the error "Unable to write data to file" should use the/po:0(orPerfOpt=0) option.

Network users may find some combination of values work better than what Image for Windows determines to use itself.

Note:Full details on configuringIFW.INIcan be found in theImage for Windows User Manual.

File Locking Issues (Samba)

If you receive this error when saving to a Samba share, it may be necessary to adjust the file locking settings to resolve it. Particularly, thestrict locking(disabled by default) andoplocks(enabled by default) settings may need to be disabled. If it's not desirable to completely disable oplocks, it may also work to disable them for the specific share being used or for the file type involved (e.g.veto oplock files = /*.tbi/).

Insufficient System Resources

The problem being caused by insufficient system resources is more likely to happen on older operating systems (e.g. Windows NT Server 4.0, Windows Server 2000, etc.). The specific error code can be found in the Image for Windows log file and is reported as a hex number (in the examples shown above, the error codes are 8h and 5AAh). Convert the error code to decimal (e.g. errors 8 and 1450) and look it up using this link:System Error Codes

The following Microsoft KB article may also be helpful in tracking down the specific issue:
Backup program is unsuccessful when you back up a large system volume

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.

Problem

Hardware Independent Imaging (HII) selected the "wrong" driver.

Cause

HII reads the devices on a machine, and gathers their corresponding Hardware IDs. Then drivers are read from the HII Library and a comparison checks for any drivers that list a DeviceID that matches the device Hardware ID of the machine. All selections are based off of vendor provided information. If there is a driver mismatch, this stems from the Hardware or Driver listing incorrect ID values.

Information

These steps outline how to manually verify the driver selections that occured.

Gather HIIPreview.log

Locate Hardware IDs

Locate Driver Device IDs

The Driver HII Found Should Not Be Used

Gather HIIPreview.log

• Begin by running HII PreviewAll.
  • The linked document provides switches to run with HIIClient.exe. Running with /PreviewAll will generate the HIIPreview.log we require.
• The HIIPreview.log file will list each Device in sections like this:

Hardware device discovered. Device number 86:
Device name: UART Controller
Primary device ID: ACPI\VEN_8086&DEV_0F0A&REV_0006
Additional device ID: ACPI\VEN_8086&DEV_0F0A
Additional device ID: ACPI\80860F0A
Automatically detected INF match discovered using device id ACPI\80860F0A.
Matching File: Elitepad_1000_G2_x64_win81\chipset\intel\122722\Drivers\UART\iaiouart.inf
Additional device ID: *80860F0A
Additional device ID: ACPI\80860F0A
Additional device ID: 80860F0A

Locate Hardware IDs

• Open Device Manager
  • Right click Computerand choose Manage, navigate to Computer Management | System Tools | Device Manager
  • Alternatively from a run box enter devmgmt.msc
    
• The Device name the HIIPreview.log will be the name of the device as displayed under Device Manager

Example: The excerpt listed earlier shows

Device name: UART Controller

• Right click the device and choose Properties.

• Within the device's proprerties, click the Details tab
• Under Property, select Hardware Ids from the drop down list

• The Hardware Ids listed in the device Properties are shown in the HIIPreview.log

Example: From the excerpt listed earlier the hardware ids were listed as:

Primary device ID: ACPI\VEN_8086&DEV_0F0A&REV_0006
Additional device ID: ACPI\VEN_8086&DEV_0F0A
Additional device ID: ACPI\80860F0A
Additional device ID: *80860F0A
Additional device ID: ACPI\80860F0A
Additional device ID: 80860F0A

• The line that lists 'match discovered' will identify what Hardware ID was found to be a match against that listed by the driver.

Example: From the excerpt listed earlier the 'match discovered' was:

Automatically detected INF match discovered using device id ACPI\80860F0A.

At this point the Hardware IDs have been identified and verified in the HIIPreview.log. Now we can compare them against the ids the driver indicates it is applicable for.

Locate Driver Device IDs

• Navigate to the HII Driver Repository
  • This can be found by navigating to Tools | Distribution | HII Driver Management | Build Library, the path listed will indicate where the drivers are stored

• The line in the HIIPreview.log that lists 'Matching File' will identify what driver was selected.

Example: From the excerpt listed earlier the 'Matching File' was:

Matching File: Elitepad_1000_G2_x64_win81\chipset\intel\122722\Drivers\UART\iaiouart.inf

In the HII Driver Repository, navigate to the listed Matching File

Example: "\\96-CORE3\ldmain\landesk\files\drivers\Elitepad_1000_G2_x64_win81\chipset\intel\122722\Drivers\UART\iaiouart.inf"

• Open the drivers .inf file in a text editor
• The .inf file will list information about what hardware it is applicable to

Example:

;For XP and later
[Intel.NTamd64]
; DisplayName Section DeviceId CompatibleId
; ----------- ------- -------- ------------
%iaiouart.DeviceDescE6%= iaiouart_Inst, ACPI\80860F0A, ACPI\INT33BC

• The DeviceId will indicate what Hardware ID it applies to

Example: From the excerpt listed above:

DeviceId
--------
ACPI\80860F0A

• The DeviceId the .inf file lists will match at least one of the Hardware IDs we found for the device earlier.

HII performs the steps outlined here automatically. When HII selects a driver, it has found that a driver's .inf file has a DeviceId that matches one of the computers device's Hardware IDs. These values are defined by their vendors, not by LANDESK.

The Driver HII Found Should Not Be Used

There are situations where a driver that is chosen may not be desirable such as the driver is causing compatibility issues.

The selection was made because the driver's vendor listed in its .inf file that it should be paired to the machines hardware that has a matching Hardware Id.

There are 2 options available in this situation.

1. Work with the driver/hardware vendor to troubleshoot the compatibility issues.
   • This would be the ideal solution, as it would correct the problem at its root. However, it may prove difficult and/or time consuming to work through multiple vendors to achieve this.
2. Assign/Disable drivers in HII Manager.
   • Because it may be impractical to work through the driver/hardware vendors to correct the compatibility issues, HII Manager allows for assigning or disabling specific drivers to hardware.