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.

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.

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)

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.

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

This document was formerly KB article 3469.

Description

If the WinPE image used for OS Deployment does not already contain a driver for certain hardware such as the network adapter or the SATA, SCSI, or IDE controller, a driver will have to be added to the WinPE image.

Before adding any storage drivers (SATA, SCSI, etc.) it is recommended that the following article also be consulted. The changes identified in the following article should be made prior to injecting drivers into WinPE: The specified document was not found.

Problems that are seen with both PXE and Vboot

• Blank boot menu. If the network adapter driver is not available in the WinPE image, the boot menu will be blank and a mini-scan will never be sent to the core server.
• After booting, the background screen appears and the device hangs loading network settings.This can be a problem with the network driver or an IRQ conflict with the network card and some other device. Update the network card driver and/or the driver of the conflicting device. In some instances this device was the video card and the correct video card driver resolved this issue.
• WinPE pops up an error "You must have administrator privileges" when a SATA controller driver is not detected.

Problems seen only during a PXE Boot

• The script completes successfully but an image is not actually captured.

If the SATA, SCSI, or IDE controller driver does not exist in the WinPE image, the disk will not be visible. This can be seen by opening a opening a command prompt and running the following commands:

diskpart
list disk

When PXE booting, a missing SATA, SCSI, or IDE controller driver will cause a script to process without capturing an image, however the task will still have a successful result.

Problems seen only during a Vboot

• After rebooting, the computer attempts to boot off the ldvpe1.img file but once WinPE is loading, the ramdisk will fail to create with the following error:

  Failed to create RAM disk
Cannot find ldvpe1.img

A missing SATA, SCSI, or IDE controller driver prevents a vbooted machine from finding the ldvpe1.img after loading. This also prevents the partition table from being set back to normal and the machine will enter a boot loop, where it continues to try to boot to WinPE and fails.

Resolution

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

LDMS 9.5

Please see the following article :How to Add Drivers to WinPE for LANDesk 9.5

LDMS 9

Please see the following article : How to add drivers to WinPE for LANDesk 9

LDMS 8.8

To add a driver to WinPE on LDMS 8.7 SP3, please follow the steps below.

As of 8.7 SP3, the LDMS Console wizard has been updated to be a driver management wizard, rather than just a wizard to add drivers. Through this wizard both SATA/SCSI/RAID and NIC drivers can be added and removed.

To launch the wizard, go to Tools | Distribution | OS Deployment in the console.

1. Click the Add Driver icon shown below.

 

2. Browse to the location of the PE Image to be modified. By default, the wizard points to: \\CORE\ldmain\landesk\vboot\ldvpe1.img.

 

3. Next, view the list of drivers to ensure  the driver to be injected is not already injected. If not, click Add.

   Note: If an added driver fails, it may be necessary to remove a similar driver that already exists.  For example, if you are adding a driver that is an update to the 3Com Etherlink 10/100 PCI, remove the existing one first.

 

4. Select whether the driver is for a SATA drive or NIC drive. For a NIC card, choose the Other Driver option.

 

5. Browse to the required files. This will include the .inf, the .sys, and any additional files such as a .cat, .dll, or .exe that are included in the driver.

 

6. Choose the additional space to be added to the WinPE image.

 

7. If the image is successfully updated, the following message will appear.

 

8. Verify that the driver has been injected by manually inspecting the driver list. Then, click Finish.

Once the image has been updated, it needs to be delivered to the PXE representatives. To do this, either re-deploy the PXE representative, or see the following article: The specified document was not found.

Issue:

How do you set up OSD to deploy a Windows 7 image with the LANDESK imaging tool (IMAGEW.EXE v2)?

How can an image be captured for use with OSD?

Resolution:

Quick Reference

The general overview of the steps required is outlined below. Continue reading for more detailed information.

1. Capture an image of Windows 7 for deployment.
2. Create an OSD script to deploy the Windows 7 image.
3. Add the OSD deployment script to the PXE Boot Menu.
4. Add drivers for Hardware Independent Imaging (HII).
5. PXE Boot a computer and Deploy the Windows 7 image.

Capture an image of Windows 7 for deployment

For information on capturing a Windows 7 image see: How to Capture a Windows 7 image with OSD in LANDESK® Management Suite 9.0 SP2

Create an OSD script to deploy the Windows 7 image

1. Open the Operating System Deployment (OSD) tool in the LANDESK Console by selecting Tools | Distribution | OS Deployment.

2. In the OSD tool, right-click All OSD Scripts and select the New Windows PE Configuration option.

3. Select the Deploy Image option and click OK.

4. On the General page, enter a name and a description for the capture script. Then click on Methods and credentials.

5. On the Methods and credentials page, select the Classical download option.

6. Check the box for Image uses SysPrep and Use Hardware-independent Imaging (HII).

7, Enter a domain user and password for a user that has access to the imaging tool and to the image share where the image is stored.

8. Click on Image type and path.

9. On the on Image type and path page, select LANDESK Imagew V2 from the Select the image type drop-down list.

10. Enter the UNC path to the image to be deployed.

11. Enter the UNC path to the imaging tool. The path shown is the default location for the imaging tool.

12. Specify the partition which is the System or C drive. With a default install of Windows 7, the System partition is 2 because Windows 7 creates a 100 MB partition as the first partition.

13. Click on SysPrep options.

14. On the SysPrep options page, select Windows 7 from the Select a Windows product drop-down list.

15. Make sure the Use existing SYSPREP file as a template box is unchecked.

16. Click on Image settings under the SysPrep options.

17. On the Image settings page, select the appropriate time zone from the Time zone drop-down list.

18. Enter the Volume license key.

19. Enter the Name and Organization if desired.

20. Click on Network credentials.

21. On the Network credentials page, Select the Domain radio button and enter the domain the computer will join.

22. Specify a domain user and password that can join the computer to the domain.

23. Check the box for Add device to an Active Directory OU and specify the OU if the computers will be added to a specific OU.

24. Click on Naming convention.

25, On the Naming convention page, check the box for First attempt to get and use existing computer names from the Inventory database if desired.

26. Modify the other options as desired.

27. Click on Hardware-independent imaging.

In SP3, the only option available is to check the box Using UNC to copy driver files. Without this box checked, the drivers will be downloaded using HTTP. The following steps are for SP2:

28. On the Hardware-independent imaging page, select the Auto Detect option.

29. Uncheck the box Using UNC to copy driver files.

30. Click on LANDESK agent.

31. On the LANDESK agent page, enter the UNC path to the Core Server's LDLOGON share which is where WSCFG32.EXE is located.

32. Enter a domain user and password that has access to the LDLOGON share of the Core Server.

33. Click Save.

34. Click OK.

Add the OSD deployment script to the PXE Boot Menu

1. In the LANDESK Console, select Tools | Distribution | PXE Boot Menu.

2. In the OSD tool, click the OSD deployment script and drag it to the PXE Boot Menu tool and drop it on the PXE Boot Menu. If the LANDESK tools are tabbed, drag the OSD script to the PXE Boot Menu tab which will activate the PXE Boot Menu tool so that the script can be dropped on the menu.

3. Click the Update button.

Add drivers for Hardware Independent Imaging (HII)

For information on adding drivers for HII in 9.0 SP2 see: LDMS Version 9 HII Quick Start Guide

Add all drivers for all computers that the drivers are not already included in the captured image.

For 9.5 and 9.0 SP3 see: Hardware Independent Imaging (HII)

PXE Boot a computer and Deploy the Windows 7 Image

1. PXE boot the computer. Follow the computer manufacturers instructions on how to PXE Boot the computer. This requires configuring the BIOS settings to do a Network boot.

2. Press F8 when the option comes up when the computer is booted. The PROXY IP address should be the IP address of the PXE Representative for the subnet.

3. Select WinPE Menu in the list and press enter.

4. Wait for WINPE to load and for the PXE Boot Menu to come up.

5. Select the OSD deployment script (Deploy_Windows_7_Image) that was created previously and click OK.

6. Wait for the image to deploy. When the deployment is complete, the computer will restart and run through the sysprep process. During the sysprep process the computer will restart several times.

A common scenario for Windows XP was to make a master image on a system, sysprep it, create the image, and build on that master image for the next version of that image. Windows 7 made this difficult as you can only sysprep (better said, re-arm the license of) a system only 3 times.

Easiest way probably is to use a Virtual Machine and snapshot it right before sysprep. That way you can restore to right before the re-arm and build on that.

Alternatively, you can use sysprep referencing an unattend.xml file with an entry telling sysprep to skip the re-arm,

for example: sysprep.exe /oobe /generalize /unattend:"c:\unattend.xml" /quit

This unattend.xml file should contain at least the following:

<settings pass="generalize">

<component name="Microsoft-Windows-Security-SPP" 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">

<SkipRearm>1</SkipRearm>

</component>

</settings>

Make sure to delete this xml before the unattended setup runs during deployment because it might interfere with the settings you inject during OSD.

Or, instead of using the XML, set the skip re-arm in the image with the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\SoftwareProtectionPlatform\SkipRearm. Note that the image does not retain this value, it gets reset after doing the sysprep.

Windows will skip the re-arm, but during the OSD process you can run the re-activation which will make the MAK or KMS key still unique to that device.

Oh no, I read this to late and already used my 3 times...

Don't worry, as mentioned bove, Windows 7 out-of-the-box can re-arm only 3 times, but if accidentally that happens to you, you can still recover the image and run the sysprep.

Running slmgr.vbs /dlv lets you check the re-arm counter. If it's 0 and you sysprep you will generally receive errors in the setupact.log and setuperr.log files like these:

Error [0x0f0073] SYSPRP RunExternalDlls:Not running DLLs; either the machine is in an invalid state or we couldn’t update the recorded state, dwRet = 31

Error [0x0f0082] SYSPRP LaunchDll: Failure occurred while executing 'C:\Windows\System32\slc.dll, SLReArmWindows', returned error code -1073425657

Error [0x0f0070] SYSPRP RunExternalDlls: An error occurred while running registry sysprep DLLs, halting sysprep execution. dwRet = -1073425657

Error [0x0f00a8] SYSPRP WinMain: Hit failure while processing sysprep generalize providers; hr = 0xc004d307

To remedy this, do the following

Open regedit and look for:

HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\SysprepStatus\CleanupState\

Set to value: 2

HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\SysprepStatus\GeneralizationState\

Set to value: 7

Than (this step isn't always necessary but it's better to include it anyway in your procedure):

msdtc -uninstall (wait a few seconds)

msdtc -install (wait a few seconds)

Reboot the system.

Now you can run sysprep again, but, don't forget to apply the things you learned in the first half of this document.

Issue

Imaging a device with a LANDESK Management Agent installed can cause the devices that receive the image to overwrite each other in the database.

Cause

LANDESK inventory looks at a Unique ID/Device ID when inserting the scan. This ID is created when the agent installed on the device.

Resolution

It is strongly recommended that the LANDESK agent not be included in an image.  The recommended way to install the LANDESK Agent with imaging is to use LANDesk Provisioning and include a Configure Agent action in your provisioning template.  Besides causing duplicate devices, the LANDESK agent is often updated and adding it to the image will quickly cause your image to be outdated. 

If the agent must be included in an image or Non-Persistent VDI image, the unique identifiers must be deleted out of the registry prior to the capture of the image.  Before creating an image of the machine do the following:

LANDesk Mangement Suite 9.0 and later

1. Install the LANDESK agent, then STOP all LANDESK related services
2. Delete the following Registry Keys for 32bit clients:

          HKLM\SOFTWARE\Intel\LANDesk\CommonApi\UniqueID
          HKLM\SOFTWARE\LANDesk\CommonApi\UniqueID

          HKLM\SOFTWARE\LANDesk\Inventory\LogonHistory\Logons
          HKLM\SOFTWARE\LANDesk\ManagementSuite\WinClient\SoftwareMonitoring\MonitorLog contents

          Delete the following Registry Keys for 64 bit clients:

          HKLM\SOFTWARE\Wow6432Node\Intel\LANDesk\CommonApi\UniqueID

          HKLM\SOFTWARE\Wow6432Node\LANDesk\CommonApi\UniqueID

          HKLM\SOFTWARE\Wow6432Node\LANDesk\Inventory\LogonHistory\Logons

          HKLM\SOFTWARE\Wow6432Node\LANDesk\ManagementSuite\WinClient\SoftwareMonitoring\MonitorLog contents

     3. On Windows XP delete C:\Documents and Settings\All Users\Application Data\LANDESK (delete the entire directory and subdirectories)

     4. On Windows 7, 8, and 8.1 delete C:\ProgramData\LANDesk (delete the entire directory and subdirectories)

     5. From the command line (as administrator) in the \LDCLIENT directory run the following

"clientdbutil.exe /create"

     6. Verify that a new database, (LDClientDB.db3) was created in the same path as you deleted above

See Community discussion for additional tips and information:

http://community.landesk.com/support/message/61210

Environment

LANDESK Management Suite 9.5

Issue

• Scheduling a provisioning template with a policy distribution method makes the task starting as a push.
• Starting a provisioning task for the devices that did not succeed makes the task running for all the target machines.
• Starting a provisioning task for the devices that did not try to run the task makes the task running for all the target machines.
• Starting a provisioning task for the devices waiting or currently working makes the task running for all the target machines.

Cause

These features are not available at the moment for provisioning tasks, as they work only as a push and for all the machines attached to the scheduled task.

Items such as "Start now for computers that did not try the task" doesn't work, as well as selecting other delivery methods.

Basically a task run will act like "Start now" for any clients, and any additional runs prior to the current provisioning task will queue up the clients to run the provisioning task again.

In addition changing the delivery method will either fail, or will have no effect.

Resolution

An enhancement request can be opened to request the feature to be implemented in a future release of the LANDESK Management Suite at the following address:

http://community.landesk.com/support/community/enhancementrequests/ldms

Environment

LANDESK Management Suite 9.5

Problem/Issue/Symptoms

- Booting a UEFI machine via PXE fails, reporting the following error message: winload.efi file is missing or contain errors

- The PXE boot tries to load WinPE 32 WIM image from the Representative (BIOS mode) rather than the 64 bit one (UEFI mode)

Cause

- The PXE Representative has not been updated with the latest Service Pack or component patch installed on the Core Server

- The PXE Representative installation file is not updated on the core

Solution

Verify that your Core server is running at least the version 9.5 of the Management Suite.
To verify the version and the patch level of your Core follow this article: How to identify the patch level on the LDMS core server?
Redeploy the PXE Representative to make sure he runs the same version as the core: Update or remove PXE representative

If this the problem persists, make sure the following file on the is the same as the one from a fresh Core installation at the same version.
If needed, replace the file with the one taken form the fresh installation and redeploy the PXE Representative:

%LDMS_HOME%\landesk\files\osdrep.msi

Applies to LANDesk Management Suite 9 SP3 and greater

HIIClient is the client-side portion of hardware-independent imaging (HII) in LANDESK Management Suite. HIIClient.exe is run on target machines, identifies the correct drivers for the device, then downloads and installs the drivers. It is stored on the LANDESK Core server and downloaded as needed by client machines in Windows PE during a deployment job.

HIIClient Options

There is only one option for HIIClient, which is what download method to use. HTTP or UNC. By default, running HIIClient with no switches will use HTTP to download the HII Driver Database and the necessary drivers. To have HIIClient use UNC instead, add /UNCPath to the command. This option can also be configured in the OSD script or Provisioning action by checking the box. This will cause HIIClient to get the database and drivers from a UNC share.

The exact shares that are used are the ones configured in the HII Driver Repository Manager. Preferred Servers can be used, but the shares and paths must match. For example, if the HII Driver Repository is configured as \\fileserver\share\drivers, then the Preferred Server must have the replicated files at \\preferredserver\share\drivers. HIIClient will not "fall back" to another method if the configured method (UNC or HTTP) is not available.

HIIClient Process

Download HII Driver Library

Once HIIClient.exe is downloaded and run on the client machine a web call is made to the Core server to find out the location of the HII Driver Repository and the HII Driver Database. With that information, the HII Driver Database is downloaded locally to the client. The database can be downloaded from a Preferred Server as long as it is available and current on the Preferred Server. The download process will communicate with the original HII Repository source only to verify that the file on the Preferred Server matches the original. if the file on the preferred server doesn't match the original, the download process will download from the original HII Repository source only, if there are a lot of client connections, the source server can't afford the network workload, so we need to disable the matching mechanism. Here is the steps for disabling matching mechanism:

Add the registry value in WinPE:

REMEXEC53=reg add HKLM\Software\LANDesk /f /v hii_db3_noverify /t REG_DWORD /d 1

Now the download process will download the HII Repository from preferred server directly, not the source server.

Detect Everything

HIIClient will then detect everything that is needed to find the right drivers. The OS must be installed on the device, but doesn't have to be running or ever run. HIIClient should be run right after the image is deployed. HIIClient will identify which version of Windows is installed (XP-2008) and where it is installed. It will also determine which architecture has been installed, x86 (32-bit) or x64 (64-bit). This determination is based on what OS has been installed, not what any of the hardware is capable of. This means that if Windows 7 x86 has been installed on an x64 processor, HIIClient will correctly determine that Windows 7 x86 drivers should be used.

Once the basic OS information has been determined, HIIClient will obtain a list of all hardware devices connected to the client. This information will include the Hardware Device ID and all Compatible IDs. These IDs are used to match the hardware to specific device drivers.

Match Drivers

When HIIClient has downloaded the HII Driver Database and gathered all the necessary information about the client and all connected devices, HIIClient uses this information to match devices to drivers. In order for a driver to match, it must have information about the right hardware or compatible ID.

As each match is found, it is ranked as to suitability. A driver will have a higher rank if it exactly matches the hardware ID than it would if the match is to a compatible ID, or if the match is more generic. For example, a driver that matches a specific network card would be ranked higher than another driver that matches the network card's compatible ID or matches part of the hardware ID. While both drivers might work, LANDesk uses this ranking to find the best driver available for the device.

The ranking system used by HIIClient is very similar to the system used by Windows and should produce the same results. This ranking system also means that newer, or updated drivers will be considered a better match than old drivers so the newer drivers will be used. It is not absolutely necessary to remove old drivers when an updated driver is added to the HII Driver Repository

After the drivers have been matched and ranked, only the best or highest ranked driver will be downloaded. HIIClient uses the database to determine exactly which files (drivers and supporting files) are needed. Only those files are downloaded. The downloaded drivers are placed on the system drive in \Windows\LDDriverStore.

Installing the Drivers

When the drivers are all downloaded, HIIClient will install the drivers. The steps taken to install the drivers will vary slightly based on which operating system is installed on the client

Windows XP

Windows XP does not have an "offline" method to install drivers, so HIIClient will only manually install the Mass Storage Driver (MSD) so that the machine will boot. For the rest of the drivers, HIIClient will add the appropriate information to the registry that will allow Windows to find the drivers during the normal process of installing drivers on first boot.

Windows 7, 8, 8.1, 2008, and 2012

For Windows Vista, 7 and 2008, HIIClient will use a tool called DISM to install the drivers. DISM (Deployment Image Servicing and Management) is a tool from Microsoft that allows the manipulation of "offline" images. In this case, the image has been deployed to the disk, but isn't running so it is considered offline. HIIClient will use DISM to install all of the downloaded drivers while still in WinPE.

Note: DISM will not work for Microsoft Windows Vista unless it has SP1. Any Windows Vista images that will be deployed should be updated to Windows Vista SP1 before deploying and using HII.

Logs

HIIClient will log information about the process in the HIIClient.log file. This log file can be found in WindowsPE and can be consulted if needed. It will be found in either X:\Windows\System32 or X:\LDProvisioning depending on how it was run. DISM also creates a log and it should be available at X:\Windows\Logs.

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.

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.

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.  This means it will open up the .wim image file and allow access to it through a directory.
   

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

5. Type the following command to mount the boot_x64.wim file:
   
   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.   
   

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

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.

    
    
    
    
    
    

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