Issue

Provisioning HII action fails if "Using UNC to Download drivers files" is left ticked, if it is unticked, it can finish successfully but defaults to the Core Server to download the drivers.

Receive the following error in the Provisioning UI:

Action Type=HII

FAILED

error:[80001803H]The action failed

Cause

Changes were made to LDDWNLD.DLL which is used to download the HII drivers.. After you upgrade the Core Server to a newer service pack, the PXE Representatives must be redeployed.

Resolution

Redeploy PXE representative and run Provisioning again.

This issue applies to LDMS 9.5 SP1 and is resolved in the latest service pack for LDMS 9.5

Issue:

Provisioning: Patch System action not working correctly when repairing a group

Resolution:

This is resolved in Service Pack 2 for LDMS 9.5.

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.

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.
• 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.
• 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.

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: imagex /unmount
   • 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 command:
   • imagex /unmount "C:\mountpath". Where mountpath is the mount path listed from the imagex /unmount command or the folders specified in step 1.
   • Ensure that each unmount command completes successfully
5. In Windows Explorer open the C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot directory.
   
6. Rename the exiting 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 The specified document was not found.

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.

Description

The Sysprep [GUIRunOnce] commands are conflicting or preventing Provisioning from running actions in the System Configuration stage.

LANDESK recommends NOT using the [GUIRunOnce] section. 

Instead, LANDesk recommends adding each command that would be in the [GUIRunOnce] section as a Provisioning action.

Cause

The Sysprep file is configured to autologon in the [GUIUnattended] section:

[GuiUnattended]
AdminPassword=*
EncryptedAdminPassword=No
AutoLogon=Yes
AutoLogonCount=1
TimeZone=10
OemSkipRegional=1
OemSkipWelcome=1

The Sysprep file is also configured to run commands in the [GUIRunOnce] section. One of them may even be a reboot. This could occur if a Sysprep.inf created by an OS Deployment script was used or if the [GUIRunOnce] was populated manually.

[GuiRunOnce]
Command0="c:\ldsleep.exe 30"
Command1="net use \\ld87\ldlogon admin /u:Caldor\admin"
Command2="cmd /q /c \\ld87\ldlogon\wscfg32.exe /F /NOUI /REBOOT /DONTSTARTSVCS"
Command3="net use \\ld87\ldlogon /d /y"

The Provisioning actions and the [GUIRunOnce] commands will run at the same time and this may cause a conflict or interrupt that prevents the Provisioning actions from completing.

The Provisioning System Configuration actions are trying to start, but the [GUIRunOnce] commands are conflicting with the Provisioning process.

This is especially problematic if the [GUIRunOnce] section contains a reboot command.

Resolution

To resolve this issue, do the following:

1. Comment out (or remove) the following lines from the [GUIRunOnce]: 

   AutoLogon=Yes
   AutoLogonCount=1

    
     
   The [GUIUnattended] section should now look as follows: 

   [GuiUnattended]
   AdminPassword=*
   EncryptedAdminPassword=No
   ;AutoLogon=Yes
   ;AutoLogonCount=1
   TimeZone=10
   OemSkipRegional=1
   OemSkipWelcome=1

    

2. Remove the entire [GUIRunOnce] section. 

3. Create a Provisioning action under the System Configuration section of the Provisioning template for each of the needed commands in the [GUIRunOnce] section that were just deleted.

LDMS version 9.50.0.530

Core Server 9.5 SP2

PXE-E53: no boot filename  received   -  when trying to PXE boot to upload a syspreped image in OOBE general mode for provisioning

Prepared the device and OSD as per these instructions:

http://community.landesk.com/support/docs/DOC-23248

BIOS was updated on the image machine before attempting to upload image

Windows PE on the core has the correct drivers for the NIC

I have tried the following:

• Update BIOS on PXE representatives
• Put the PXE rep on the same switch as the PXE booting machine
• Turned the firewall off on the core server, no firewall on the PXE rep, turned antivirus (symantec) off on the PXE rep
• Restarted the PXE services on the PXE reps
• Redeploy the PXE reps
• Recreated the PXE rep and redeployed
• Recreated the OSD capture script with the following command line parameter (LDMS put it in for me, I have no clue):

  RunBatch -1 H:\osd\IMAGEW~1 backall.bat 0 i:\%Computer - Device Name{6}%, STATUS FACILITY=3510, SYNC  

·         Update the entry on the PXE boot menu

• No (WDS) is present on the PXE representative.

Not sure what else to try

Landesk 9.5 SP2

Any computer I set in the assign driver window, the devices show in left hand column but highlighting any of then does no bring up anything in Right hand column.

An example, I setup Dell 755 windows xp x86.  The devices show in left column. I highlight the audio device and nothing shows in right column. I had installed a audio driver in the Driver Database so wouldn't it find that driver?

Maybe I'm not understanding this whole process.

RDPed into the Core Server.

When dragging OSD scripts to the PXE Boot Menu, the icon never changes to the plus so it cannot be dropped on the menu.

Added the /admin  switch at the end of the server name when starting the RDP session.

Applies to LANDESK Management Suite 9.0 SP4 and later

Issue

The following error occurs when booting into Windows PE:

WinPE boot error "resolving core server name (%mycoreserver%)........"

Cause

• This normally occurs when the ALL.REG file within the BOOT.WIM does not contain the Core Server name or it needs changed to FQDN.
• If CORENAME.TXT and ALL.REG get modified manually and a later patch, service pack, or upgrade updates the boot.wim or boot_x64.wim, the CORENAME.TXT and ALL.REG will need to be updated again.

Resolution

The following steps will be taken on the core server:

• Mount the .WIM files that are used to create the Windows PE boot environment
• Modify the CORENAME.TXT and ALL.REG files that are used to specify the core server name for Windows PE
• Commit the changes made to the .WIM files so that the boot.wim and boot_x64 .WIM files contain the changes made
• Update the PXE Representatives with the newly changed .WIM files

These steps follow:

1. Create a new directory you will eventually mount your 32-bit .WIM file to.   Example: C:\bootwim
2. Create a new directory you will eventually mount your 64-bit. WIM file to.   Example: C:\boot_x64wim)
3. From a command prompt change to the \Program Files (x86)\LANDESK\ManagementSuite\vboot directory.
4. Type the following command to mount the Boot.wim file:
   
   This will mount the 32-bit boot.wim file that contains the 32-bit Windows PE environment used with computers booting to a Legacy 32-bit bios:
   

   dism /mount-wim /wim-file:boot.wim /index:1 /mountdir:c:\bootwim

            This will mount the 32-bit boot.wim file that contains the 32-bit Windows PE environment used with computers booting to a Legacy 32-bit bios.
   
   
5. Type the following command to mount the boot_x64.wim file:
   

   dism /mount-wim /wim-file:boot_x64.wim /index:1 /mountdir:c:\boot_x64wim

            This will mount  the 64-bit boot_x64.wim file that contains the 64-bit Windows PE environment used with computers booting to a UEFI bios.
   
   
6. Change to the Temp subdirectory under C:\bootwim\ you created in Step 1.
7. Save your changes to the CORENAME.TXT file.
   

   CORENAME.TXT will simply contain one line with the name of the core server.   This can be changed to FQDN or IP address to suit the needs of your environment.

8. Change to the WINDOWS\SYSTEM32  subdirectory under c:\bootwim and edit the file ALL.REG in Notepad or other text editor.
9. Modify the line that says "CoreServer"="[Corename]" and change the core name to FQDN or IP address as suits your needs.
10. Save your changes to the ALL.reg file.
11. Repeat steps 6-9 for the boot_x64.wim
    
    Now it is necessary to commit the changes made in the C:\bootwim and C:\boot_x64wim directories to save them into the .WIM files.  This is done by using the DISM (Deployment Image Servicing and Management) tool with the switch "/commit-wim" to save the changes to the images we mounted in steps 4 and 5. 
    
    
12. Type the following command to unmount the boot.wim and commit (save) the changes:
    

    dism /unmount-wim /mountdir:c:\bootwim /commit
    This will commit (or save) the changes to the boot.wim made in modifying the CORENAME.TXT and ALL.REG.

13. Type the following command to unmount the boot_x64.wim and commit (save) the changes:
    

    dism /unmount-wim /mountdir:c:\boot_x64wim /commit
    This will commit (or save) the changes to the boot_x64.wim made in modifying the CORENAME.TXT and ALL.REG

14. At this point it is necessary to re-deploy the PXE representatives, as the .WIM files reside on the PXE Representatives.  When the targeted devices do a network boot they are directed to their PXE representative for their subnet and download the associated .WIM file that will then be their Windows PE environment.  The following steps detail this.
15. In the LANDESK Management Suite console, go to the Distribution tool group and then go to the OS Deployment tool.
16. From the OS Deployment tool expand the "All Other Scripts" section.
17. Right-click "PXE Representative Deployment" and select "Schedule".
18. The "Scheduled Tasks" tool should open and the newly created task should be highlighted.
19. Add the PXE representatives to the task and start the task.
    
    Note: If you already have a PXE Representative Deployment task created, you can just re-use that one to re-push the PXE representative.
    
    

    If the BOOT.WIM and BOOT_X64.WIM files were updated by a patch, service pack or upgrade, these steps will need to be done again.

    
    
    
    
    
    

One of the most common uses of Provisioning is to extend the capacities and functions of imaging or new device deployments to include the installation of the OS as well as configuration settings and software installations. In order to bridge the gap between WinPE and the new OS, LANDESK uses a process called Configure Target OS (abbreviated as CTOS). This is a separate action that needs to be added to the template for a template that installs an image, and is included as part of the Scripted Install action. This article covers the function and troubleshooting of the Configure Target OS action

Configure Target OS overview

The Configure Target OS (CTOS) action is available only in the Post-OS installation section of the provisioning template. It needs to be the final action in the template before the System Configuration section, no actions can come after the CTOS action. The CTOS prepares the device to resume provisioning after the client boots into the target OS, then restarts the device, leaving WinPE and allowing the computer to boot normally. In order for the CTOS action to work, the image that was deployed to the client MUST be sysprepped.

The Configure Target OS takes advantage of a few Microsoft technologies in order to resume when the device completes booting into the target OS (Windows XP, 2003, 2008, 7, 8, 8.1, 2012). Files are injected to the root of the OS drive (C:\ldprovision) and commands are added to the appropriate files such that they are run during the mini-setup just prior to booting into the target OS.

Windows XP/2003

1. All needed files are copied to C:\sysprep\i386\ldprovision directory on the client device. The C:\sysprep\i386 directory must exist and be accessible
   
   Note: Sysprep is responsible for creating the i386 folder.  If the folder is not getting created, you can get around the issue by creating a new action in the script, putting the action in front of the CTOS action, that creates this folder.  If this folder does not exist it will cause the failure of any additional action after CTOS runs and reboots the client.
   
   
2. The cmdlines.txt file in the OEM folder on the client device is created or modified. A line is added to call ldprovisioning.cmd. Windows will run cmdlines.txt at the end of the mini-setup, calling ldprovisioning.cmd.

Windows 7, 8, 8.1, 2008, 2012

1. All needed files are copied to C:\ldprovisioning directory on the client device.
2. The unattend.xml is modified and commands are added to call ldprovisioning.cmd from the C:\ldprovisioning directory.

LDProvision.cmd

When run, ldprovisioning.cmd installs the basic LANDESK CBA agent in C:\Program Files\LANDESK\LDClient and configures it as a service to start on OS boot. It also modifies the actions.ini file in C:\Program Files\LANDESK\Shared Files\cbaroot to contain a line pointing to C:\ldprovision\ldprovision.exe with the needed command line options. The actions.ini file is used by the LANDESK CBA agent as instructions when starting, so the commands contained therein are run when the service starts.

Troubleshooting Configure Target OS

Troubleshooting the CTOS action can be especially difficult. Because of the nature of the operation and how it works, LANDesk must give up control to the Windows installation processes for a time, and then resume afterwards. This can sometime make it difficult to determine where the problem is occurring. The problem can be in WinPE trying to copy and modify files, it can be somewhere in the mini-setup of the OS, and it can be after the OS has completed all setup tasks and has fully booted.

The first step to troubleshoot the CTOS action is to determine where in the process the failure is occurring. The CTOS action will not always get marked as failed. Often provisioning just fails to continue through the rest of the template.

WinPE

This is where it is most likely to see an actual failure of the template. Usually this means something could not be copied correctly or modified. The device will stay in WinPE after the template fails so troubleshooting can be done in the exact condition the device is in when it fails.

1. Open a new console in WinPE.
2. Check to make sure that the C: drive is accessible.
3. Change to the C: drive and look around. Does it look like the image was put down correctly?

If you deployed:

     Windows XP/2003

1. Change to C:\sysprep directory. Verify that the I386 directory exists. Look to see if the ldprovision folder was created and populated

   1. Note: Sysprep is responsible for creating the i386 folder.  If the folder is not getting created, you can get around the issue by creating a new action in the script, putting the action in front of the CTOS action, that creates this folder.  If this folder does not exist it will cause the failure of any additional action after CTOS runs and reboots the client.  This also prevents the $OEM$ directory from being created in the i386 folder.
      

2. Check the cmdlines.txt in C:\sysprep\$OEM$\ and make sure it contains a line for ldprovisioning.cmd
3. Verify that ldprovisioning.cmd is in C:\sysprep\$OEM$\

     Windows 7, 8, 8.1, 2008, 2012

1. Change to C:\ldprovisioning directory. Verify the ldprovisioning.cmd is in the folder and the folder is populated. It should contain over 20 files.
2. Verify that the unattend.xml exists in C:\Windows\Panther
3. Verify that the commands calling ldprovisioning.cmd exist in the unattend.xml for the platform (x86, amd64, ia64) you have deployed.

Sometimes all of these will be correct and ready to go, but the device will remain in WinPE. Usually there is not a failure of the task. It is possible that the reboot command didn't run correctly but everything else did. To verify this, simply restart the client and observe the results.

Between WinPE and Windows

After the client reboots out of WinPE it will boot off the hard drive into the target OS. Because the image was sysprepped, it will go through a mini-setup process. If no sysprep file was provided, it will prompt for a number of items such as the computer name, user names, time zone, product key, etc before completing the booting process into the target OS.  LANDesk has no control over this process and is not running at all. Near the end of the mini-setup process Windows executes the commands that LANDesk added during the CTOS action. For Windows XP and 2003 the mini setup executes the commands in the cmdlines.txt at then end of the sysprep steps. For Windows Vista, 2008 and 7 the commands are exeucted during the Specialize pass in the unattend.

Windows XP/2003

The important file here is the cmdlines.txt This file should contain the call to ldprovisioning.cmd. It is here that LANDesk is again introduced into the process. When cmdlines.txt is executed it runs ldprovisioning.cmd from the same directory, which prepares the device to resume provisioning after the whole mini-setup process is complete.

Windows 7, 8, 8.1, 2008, 2012

Sections are added to the unattend.xml in the Specialize section. This is a special section of the unattend.xml that can also be used for things like setting the home page for Internet Explorer, etc. In this section, the RunSynchronousCommand action is added calling ldprovisioning.cmd from C:\ldprovisioning\. The section of the unattend will look roughy like the following:

<settings pass="specialize" xmlns="" wasPassProcessed="true">
    <component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <RunSynchronous>
            <RunSynchronousCommand action="add">
                <Description>LANDesk Provisioning Install</Description>
                <Order>1</Order>
                <Path>cmd /c %systemdrive%\ldprovisioning\ldprovisioning.cmd</Path>
            </RunSynchronousCommand>
        </RunSynchronous>
    </component>
</settings>

In Windows

Once the device completes the mini-setup section, it will boot into the final OS. As the device boots up, it runs the LANDesk Management Agent service that was installed by ldprovisioning.cmd. As part of the startup process, the LANDesk Management Agent will run the commands in the actions.ini file. The actions.ini file was also modified by ldprovisioning.cmd to contain the following command

C:\ldprovisioning\ldprovision.exe -c <CORE>

Troubleshooting Tip: If you would like to get extra logging for problems you are seeing later in the template, open this file BEFORE the device completes the boot after the mini-setup and change it to the following:

C:\ldprovisioning\ldprovision.exe -c <CORE> -V 255 -L C:\<LOG FILE>

       Note: the -V is a capital V and is case sensitive

Once ldprovision.exe starts, it queries the core server for the next action in the template, and provisioning will continue with the actions in the System Configuration section.

───────────────────────────────────────

See also CTOS action fails after reboot.

Hi there,

I have an issue when multicasting OS images using PXE/WinPE. If I previously choose a MDR manually in the LDMS console for multicasting the OSD/PXE task, then the image deployment works all right as expected. But if instead there is not a previously manually selected MDR for the task then the multicast task fails as soon as it starts even a MDR shows as been selected in the interactive core server multicast task .

Moreover, if I choose manually a MDR for the PXE/WinPE OSD deployment task and when the selected MDR node starts receiving the OS image from the Core Server and simultaneously multicasting the OS image to the rest of the selected client nodes, if then I disconnect the current MDR node, then the process instead of selecting a new MDR by a initiated automatic election, the task fails and none of the other client nodes is selected as an alternate MDR.

Any ideas?    

I'm trying to add profile migration to my master prvovisioning template that I have been using for months and already works pretty much flawlessly. I have tried using the new Profile Capture action in 9.5 but it fails every time. I have also tried using the templates from here http://community.landesk.com/support/docs/DOC-9459.I have included these templates in my master template and the profile capture works fine and then when it gets to the map image tool section of my master template it fails saying that a variable does not exist. This is a variable that I defined in the public variables long ago and if I remove the profile capture and run my master template alone without making any other changes it works fine. I also get the variable does not exist error if I leave the restore template included in the master template and run it. It errors on the very frist step of the restore profile. I can run the restore on its own without making any changes to the variables and it works fine.

Basically I can run each of the templates individually and they work exactly as expected, but when I include them together it seems to cause predefined public variables to no longer work. I haven't seen this mentioned, so I don't know if this is a common issue or not. I would like to run this as one big task rather than have to run three separate tasks.

Has anybody had any sucess provisioning a Lenovo Thinkpad Tablet2 device? We're running 9.5 SP2, and I cannot get it to boot from a Provisioning Boot medium writen to a USB stick. The tablet is 32bit UEFI, it seems the slightest hint of anything 64bit on the boot medium causes it to fail.

Is there anyway of forcing 32bit only when creating the \ldmain\landesk\vboot\bootmedia.wim file?

Issue

When attempting to PXE boot, the following error appears:

PXE-E53: No boot filename received

• PXE Boot fails.
• No F8 option is recieved by clients.
• Unable to PXE Boot machines.
• Unable to network boot machines.

Cause

• No PXE representatives are deployed.
• Deployed PXE Representative is turned off.
• PXE representative is not in the same broadcast domain as target machine.
• Firewall on PXE representative is blocking requests from target machine.
• PXE services are not running.
• Windows Deployment Services (WDS) are installed on the PXE representative.
• Another service on the server is using port 67

Resolution

• Update BIOS on device
• Ensure that a PXE representative is on and is deployed in the same broadcast domain as the target machine.
• Ensure that no firewall is blocking requested packets from PXE booted machines.
• Ensure PXE services are running.  The two services are "LANDESK® PXE Service" and "LANDESK® PXE MTFTP Service".
  If they are running, restart the services.
• Redeploy the PXE Representative.
• If PXE services repeatedly stop on PXE representatives, download and install the latest service pack on the core, then remove and redeploy PXE representatives.
• Disable the Windows Deployment Services (WDS) on the PXE representative.
• Run the "nestat -abn" command to find the service which is using port 67 and disable/reconfigure this service.

Note: The PXE Representative may need to be rebooted if the services are running, the firewall is off, but it still does not respond.

More information on PXE boot errors:

PXE Boot errors and descriptions.

How to troubleshoot PXE boot:

Troubleshooting PXE boot (OSD)

Hi All,

I have an issue I can't explained.

I a mtrying to deploy Microsoft Silverlight 5.1 exe in a provisining task at the System config STEP.

This package distribution failed with internal status -1917516206.

What is really strange to me is that : if I try to deploy the package after the provisionning task has failed from a scheduled task then it is succesfully deployed!

I havent reboot the the computer, or didn't do anything on it.

Have you any idea that can explain why my package distribution failed in the provisionning?

I use Landesl Management Suite 9.5 SP3.

Cheers

Hi, I got an error "The operation failed as no adaptor is in the state permissible for this operation" "IP address 127.0.0.1 waiting for IP address...." when provisioning with a HP 8200Elite SFF desktop PC.  I downloaded and injected the latest Vista 32-bit driver from the Intel website and it still wouldn't work.  Please help.

Applies to LANDESK Management Suite version 9.5, 9.5 SP1 and newer

How to Manage Drivers in WinPE for LANDESK Management Suite 9.5

Description

In order to perform imaging in LANDESK Management Suite the WinPE image used during the imaging process must contain drivers for devices such as the network adapter or hard drive controller.

In LDMS 9.5 additional drivers for Intel network cards, Intel hard drive controllers, and Intel USB3 have been included in the WinPE image for convenience.

The drivers for the WinPE image should match the version of the network boot image file being used (32-bit for boot.wim and 64-bit for boot_x64.wim), not the OS being deployed.

For adding drivers in LANDESK Management Suite 9.0 see How to add drivers to WinPE for LANDESK 9.0

Additional information about the WinPE version and required driver versions for each version of LANDESK Management Suite can be found at
WinPE Version Information by LANDESK Management Suite Version

Resolution

To manage drivers to the WinPE image for 9.5 use the following steps.

1. From the console go to Tools > Distribution > OS Deployment.

2. On the Operating System Deployment screen select “Manage the drivers in the WinPE Image.

3. Select the WinPE Image that you want to manage drivers in. The default selection (boot.wim) is the WinPE image used for 32-bit vBoot and PXE.

4. To manage drivers in the 64-bit WinPE image select "Others (For user specific image)" option. Browse and select the boot_x64.wim in the vboot directory where the default boot.wim is located.

5. The image file will be processed to open the WinPE image and gather the list of drivers currently in the WinPE image file.

6. Select add or remove to manage drivers.  Note: Drivers that were included by Microsoft in the WinPE image cannot be removed. If the driver list is blank it indicates that the image file is mounted by another process and must be un-mounted before drivers can be added.You can do this by typing imagex /unmount in the command line. If nothing unmounts or this does not resolve the issue, check console.exe.log for an error in deleting a temporary file. (Path example, C:\Users\ldadmin\AppData\local\Temp\2\imgtmp\Apply) Navigate to this file and rename it. The image should open now and you should see all of the drivers and be able to add them as well.

7. When adding a driver a driver name must be provided. Using a name that easily identifies the driver and hardware is recommended for ease of use as additional drivers are added and removed. Browse to the location of the INF for the driver. Note: The driver must match version of the OS in the WinPE image, not the OS being deployed. The driver for the boot.wim must be a Windows 7 32-bit driver. The driver for the boot_x64.wim must be a Windows 64-bit driver.

Note: For LDMS 9.5 SP1 with later component patches, WinPE has been updated to version 4.0 based on Windows 8, and in Service Pack 2 it is updated to WinPE 5.0 based on Windows 8.1.    Windows 8 drivers should be used in this case.

8. After the necessary drivers have been added, select Finish and the drivers will be injected to the image.

9. After the image has completed processing it is necessary to update existing PXE representatives. Instructions on updating PXE representatives can be found atThe specified document was not found.

The PXE boot Menu is hanging on IP. The network of Lenovo laptop is Intel PRO/1000 LAN Adapter Software but it doesn't have a vista version. i tried W7 it didn't work. I've tried to inject Vista driver from Intel website it didn't worked.

I need to Capture image prior to deploy it on 74 laptops and i'm blocked.

May you please help?

Hello, Windows 7 provisioning has been working perfectly until I decided to recreate my base image.  Here’s the process and issues.  I installed Windows 7 from a desktop with” AHCI” driver enabled in the bios.  I installed the Microsoft standard AHCI driver and ran sysprep OOBE generalized without the unintended.xml file.  Captured the image with OS deployment NOT provisioning.  As a test, I deployed to the same desktop that I created the image with provisioning and the OS keeps rebooting.  It boots up fine when I switch from AHCI to IDE in the system bios.  It also works if I captured the image without syspreping it first.  I have use the same desktop created a working image in the past so not sure what got changed.  My current version is LDMS 9.5 SP1. Please help.

I am able to capture and image and deploy an image using ImageX but after the image is deployed we end up with 2 OS boot options. Is there a command that we need to add to the advance script so it will olny have one and will just boot directly to the OS?

Here is my Advance script

Task=8

ScriptName=RCASBaseImageX

ScriptDescription=RCASBaseImageX

MCast=0

FallBackNIC=

UseFallBackNIC=FALSE

ImageUserName=imageadmin

ImageDomain=schools

ImagePassword=1082BD11EEDD8F0594052707226

ImageToolType=4

ImageUNC=\\tclandesk\rcas\Images\Uploads\RCASBase.wim

ToolUNC=\\landesk1\ldmain\osd\imaging\imagex.exe

Partition=1

ImageToolCmd=cmd /c RunBatch -1 h:\osd\imaging imagex.exe /apply i:\Images\Uploads\RCASBase.wim 1 C:, STATUS FACILITY=3513, SYNC

ImageToolCmdsFile=\\LANDESK1\LDMAIN\LANDESK\FILES\RCASBaseImageX.txt

IsSysPrepImage=0

ConfigAdvancedMCast=0

UseWOL=FALSE

WOLSeconds=120

DiscoveryType=0

MaxTMCThreads=5

MinTMCSleep=1

MaxTMCSleep=200

BANDWIDTH_WAN=100

BANDWIDTH_LAN=100

SubrepTTL=14

TargetTTL=2

[OWNER]

GUID=e8eb0e49-b848-4205-8ed4-9c26f2771ab1

OSDPLUG=TRUE

DESCRIPTION=RCASBaseImageX

NAME=RCASBaseImageX

TYPE=WinPE

[JOBPARAM]

ABORT_ON_CMD_FAILURE=1

TASK_COMPLETION_ENABLED=FALSE

[MACHINES]

REMEXEC0=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/bootfile.exe" /disableclientqueue

REMEXEC1=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/tlibr16.dll" /disableclientqueue

REMEXEC2=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/tlibr32.dll" /disableclientqueue

REMEXEC3=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/lddefrag.exe" /disableclientqueue

REMEXEC4=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/cicfgmgr.vxd" /disableclientqueue

REMEXEC5=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/cindis.vxd" /disableclientqueue

REMEXEC6=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/copyfile.exe" /disableclientqueue

REMEXEC7=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/tokreplw.exe" /disableclientqueue

REMEXEC8=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/boot.img" /disableclientqueue

REMEXEC9=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/ChangeBCD.exe" /disableclientqueue

REMEXEC10=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /dest="%LDMS_CLIENT_DIR%\BCD" /p="http://%CUSTJOBHOSTIP%/landesk/vboot/BCD.dat" /disableclientqueue

REMEXEC11=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/files/bcdedit.exe" /disableclientqueue

REMEXEC12=<qt/>%LDMS_CLIENT_DIR%\ChangeBCD<qt/> <qt/>%LDMS_CLIENT_DIR%\bcdedit.exe<qt/> <qt/>%LDMS_CLIENT_DIR%\BCD<qt/>

REMEXEC13=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /dest="C:\boot.wim" /p="http://%CUSTJOBHOSTIP%/landesk/vboot/boot.wim" /disableclientqueue

REMEXEC14=<qt/>%LDMS_CLIENT_DIR%\copyfile.exe<qt/> <qt/>%LDMS_CLIENT_DIR%\boot.img<qt/> <qt/>%LDMS_CLIENT_DIR%\BCD<qt/> \boot\BCD

REMEXEC15=<qt/>%LDMS_CLIENT_DIR%\lddefrag.exe<qt/> <qt/>%LDMS_CLIENT_DIR%\boot.img<qt/>, STATUS

REMEXEC16=<qt/>%LDMS_CLIENT_DIR%\bootfile.exe<qt/> %LDMS_CLIENT_DIR%\boot.img /keep /bootunsafe, ASYNC

BEGINWINPE=TRUE

REMPING17=WINPE, TIMEOUT=1800

REMEXEC18=diskpart /s X:\LDClient\rmvol.txt

REMEXEC19=ldrun drvmap.exe schools\imageadmin 1082BD11EEDD8F0594052707226 I: """\\tclandesk.schools.rcas.org\rcas""", STATUS FACILITY=3513

REMEXEC20=ldrun drvmap.exe schools\imageadmin 1082BD11EEDD8F0594052707226 H: """\\LanDesk1.schools.rcas.org\ldmain""", STATUS FACILITY=3513

REMEXEC21=ldrun sdclient /f /o /dest="X:\LDClient\LDPathExist.exe" /p="http://%CUSTJOBHOSTIP%/landesk/files/LDPathExist.exe" /disableclientqueue, STATUS

REMEXEC22=ldrun LDPathExist.exe """I:\Images\Uploads\RCASBase.wim""", STATUS

REMEXEC23=ldrun LDPathExist.exe """H:\osd\imaging\imagex.exe""", STATUS

REMEXEC24=diskpart /s X:\LDClient\wipeDisk0.txt

REMEXEC25=cmd /c format /Y /FS:NTFS /Q /V:C-DRIVE c:

REMEXEC26=ldrun cmd /c RunBatch -1 h:\osd\imaging imagex.exe /apply i:\Images\Uploads\RCASBase.wim 1 C:, STATUS FACILITY=3513, SYNC

REMEXEC27=ldrun sdclient /f /o /dest="X:\LDClient\diskinfo.exe" /p="http://%CUSTJOBHOSTIP%/landesk/files/diskinfo.exe" /disableclientqueue, STATUS

REMEXEC28=ldrun sdclient /f /o /dest="X:\LDClient\assvol2.txt" /p="http://%CUSTJOBHOSTIP%/landesk/files/assvol.txt" /disableclientqueue, STATUS

REMEXEC29=ldrun sdclient.exe /f /o /dest="x:\ldclient\RMVOLLETTER.TXT" /p="http://%CUSTJOBHOSTIP%/landesk/files/RMVOLLETTER.TXT" /disableclientqueue

REMEXEC30=ldrun tokreplw X:\LDClient\assvol2.txt partition=1

REMEXEC31=diskpart /s X:\LDClient\RMVOLLETTER.TXT

REMEXEC32=diskpart /s X:\LDClient\assvol2.txt

REMEXEC33=ldrun sdclient.exe /f /o /dest="x:\ldclient\fixvista.bat" /p="http://%CUSTJOBHOSTIP%/landesk/files/FixVista.bat" /disableclientqueue

REMEXEC34=ldrun sdclient.exe /f /o /dest="x:\ldclient\fixntfs.exe" /p="http://%CUSTJOBHOSTIP%/landesk/files/fixntfs.exe" /disableclientqueue

REMEXEC35=ldrun sdclient.exe /f /o /dest="x:\ldclient\bcdedit.exe" /p="http://%CUSTJOBHOSTIP%/landesk/files/bcdedit.exe" /disableclientqueue

REMEXEC36=ldrun sdclient.exe /f /o /dest="x:\cba8\FixWindows.exe" /p="http://%CUSTJOBHOSTIP%/landesk/files/FixWindows.exe" /disableclientqueue

REMEXEC37=ldrun x:\cba8\FixWindows.exe 1

REMEXEC38=cmd /c copy /y X:\LDClient\guid.pds C:\LDISCAN.CFG

REMEXEC39=ldrun tokreplw C:\LDISCAN.CFG DEVICEID=%Computer - Device ID%

REMEXEC40=ldrun tokreplw C:\LDISCAN.CFG IMAGEPATH=\\tclandesk.schools.rcas.org\rcas\Images\Uploads\RCASBase.wim

REMEXEC41=ldrun x:\Windows\system32\bcdboot.exe C:\Windows

REMEXEC42=ldrun diskinfo extend_last_partition

REMEXEC43=ldrun reboot, timeout=2

Applies to LANDESK Management Suite 9.0 and newer.

Description

This document is intended to show the versions of WinPE used in each version of LANDESK Management Suite. The goal is to facilitate getting the correct drivers for the WinPE version being used.

Note: In LANDESK Management Suite 9.5, the 64-bit version of WinPE is included to add support for UEFI devices.

Resolution

LANDESK Management Suite 9.5 SP2 with BASE 0214 patch

• The WinPE version is updated to 5.0.
• WinPE 5.0 requires Windows 8.1 driver (32 bit).
• For additional information on managing drivers in LANDesk Management Suite 9.5 please see How to Add Drivers to WinPE for LANDesk 9.5.

LANDESK Management Suite 9.5 SP1 with BASE 1017 patch

• The WinPE version is updated to 5.0.
• For additional information on managing drivers in LANDesk Management Suite 9.5 please see How to Add Drivers to WinPE for LANDesk 9.5.

LANDESK Management Suite 9.5 (with HP ElitePad Integration Update and/or the BASE 0228A patch) - 9.5 SP1

• The WinPE version is updated to 4.0.
• WinPE 4.0 requires Windows 8 drivers (NDIS 6.3).
• WinPE 4.0 does include a generic NDIS driver so a specific NIC driver may not be required.
• For additional information on managing drivers in LANDesk Management Suite 9.5 please see How to Add Drivers to WinPE for LANDesk 9.5.
• Client devices must have processor support for PAE/NX/SSE2 in order to boot into WinPE 4.0.

LANDESK Management Suite 9.0 SP3 - LANDesk Management Suite 9.5 without Service Pack

• The WinPE version is updated to 3.1.
• WinPE 3.1 requires Windows 7 drivers (NDIS 6.2).
• For additional information on managing drivers in LANDesk Management Suite 9.5 please see How to Add Drivers to WinPE for LANDesk 9.5
• For additional information on managing drivers in LANDesk Management Suite 9.0 please see How to add drivers to WinPE for LANDesk 9

The following Microsoft document describes what NDIS driver versions are required for each OS:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff567893(v=vs.85).aspx