Quantcast
Channel: Ivanti User Community : All Content - OS Deployment and Provisioning
Viewing all 1803 articles
Browse latest View live

Error: "The user name or password specified is not correct" when authenticating in the Provisioning client UI

$
0
0

Issue

 

Receiving the error "The user name or password specified is not correct.   Provide new credentials" when authenticating using the Provisioning Client UI.

 

FailedAuth.JPG

 

Cause

 

First, double-check that the credentials used are correct and that they have not been typed in incorrectly.  If the core server is installed on Server 2008 R2, it is likely that the Basic Authentication feature of IIS 7 was not installed.

 

Resolution

To install the Basic Authentication component for IIS 7 on Server 2008 R2, follow the steps below on the Core Server:

 

  1. On the taskbar, click Start, point to Administrative Tools,  and then click Server Manager.
  2. In the Server Manager hierarchy pane, expand Roles,  and then click Web Server (IIS).
  3. In the Web Server (IIS) pane, scroll to the Role  Services section, and then click Add Role Services.
  4. On the Select Role Services page of the Add Role  Services Wizard, select Basic Authentication, and then click Next.
    basicAuthentication_setup_1.jpg
  5. On the Confirm Installation Selections page, click Install.
  6. On the Results page, click Close.

 

For more information on Basic Authentication, refer to the following link:

 

http://technet.microsoft.com/en-us/library/cc772009%28WS.10%29.aspx


How to Deploy an Image to Multiple Computers Using Multicast

$
0
0

This document describes how to deploy an image to multiple computers using multicast.

 

LANDESK Provisioning can take advantage of a feature called "self-organizing multicast".  Please review this presentation to learn more about this feature.

 

The following are the steps that you need to take to ensure that multicast is being used so that you can efficiently deploy images to multiple devices while saving both bandwidth and time.

 

 

 

Create a template

 

Template.jpg

 

  1. Open the OS Provisioning tool from within the Provisioning tool group.
  2. Either go to "My templates" and then "All my templates" to create a template only you are going to be using or go to "Public" and then "All public templates" to create a template others can use.
  3. After highlighting one of those groups click on the "New Template" drop-down above the "Provisioning templates" tree.
  4. Select "Deploy Template"
    DeployTemplate.jpg
  5. Give your template a name.
  6. Select the type of image you will be using. 

    Choices are:

    • LANDESK ImageW V2
    • Symantec
    • ImageX
    • Other  (Note: When using other you must have a tool that supports command line options.  When selecting "Other" you will need to provide those command line options for LANDESK Provisioning to process.

  7. Enter the full path and filename for your image or browse to and select it.
  8. Select an Agent Configuration name if you want a specific LANDESK Agent Configuration to be installed after deploying the image.
  9. Check the box for Hardware Independent Imaging if you have that setup and want to deploy an image to differing hardware.  For further information about Hardware Independent Imaging, start here.
  10. If you have sysprepped your image in order for it to be an unattended install select the drop-down under "Script Name" and select an unattend file and click "Create"

 

You will then see your newly created image in the right-hand pane of the Operating System Provisioning tool.

 

Ensure that your default Distribution and Patch setting has the Multicast option selected

 

  1. Within the "Configuration" tool group select the "Agent Settings" tool.
  2. Go to "All Agent Settings" and look at the properties for the default Distribution and Patch setting.   This is the setting that will have the green checkbox next to it.
    The other option is to make a setting your default setting by going to the Properties of the setting and in the lower left select "Set as default"
  3. Under the "Network Settings" section in the right-hand pane check the box next to "Use Multicast and then click "Save".

    UseMulticast.jpg

Distribute the Deploy Image template to client computers

 

  1. Back in the "OS Provisioning" tool within the "Provisioning" tool group right-click the newly created template and select "Schedule Template"
    This will cause the Scheduled Tasks tool to open with the newly created template highlighted.
  2. Drag the desired computers to the newly created task.  These computers will need to have been turned on and will need to have attempted to network boot so that their mac addresses have been sent to the core server.
    If this has happened the MAC addresses should show up in the list of computers.
  3. Right-click the task and select "Properties".
  4. Go to the "Schedule Task" section and choose when you would like to start the task and then click "Save".

How to distribute software using "Run from source" OS Provisioning

$
0
0

Issue

 

How to installed software using "Run from source (execute on share)".

 

Resolution

 

  1. Open the Agent Settings Tool under the Configuration or Security and Compliance tool groups.
  2. Select Distribution and Patch Settings under the section you want to modify (Either My Agent Settings, Public Agent Settings or All Agent Settings.
  3. Under Distribution-only settings select Download Options.
  4. Select the "Run From Source" download option.
  5. If including the Distribute Software action in an "end to end" Provisioning Template (Installing the OS, followed by the agent, etc) you will need to assign the configured Distribution and Patch Setting to the Agent Configuration you are including in your template.

 

RunFromSource.jpg

Failed to download (C:\ldprovisioning\SDClientHandler.sig)

$
0
0

When using provisioning packages for complex software deployments, I am seeing an issue where some of the devices are failing to install any of the software packages that I have included in the template.  After closer inspection, I can see that none of the files for the software packages in the template are being downloaded, so when it tries to execute, it fails immediately.  I found an error in the ldprovisioning.log file -> Failed to download (C:\ldprovisioning\SDClientHandler.sig) <- that appears to be the issue, but I'm not sure how to go about resolving this.  Wondering if anyone else has seen this, or has any ideas how to troubleshoot further?  LDMS 2016.3 SU3

 

2017-11-07 16:41:00(8660-4724) ldprovision.exe:Looking for existing file (C:\ldprovisioning\SDClientHandler.sig)

2017-11-07 16:41:00(8660-4724) ldprovision.exe:Entering downloadbyproxy.

2017-11-07 16:41:00(8660-4724) ldprovision.exe:Create process (C:\Program Files (x86)\LANDesk\Shared Files\httpclient.exe) with args (  -f "C:\ldprovisioning\SDClientHandler.sig" http://mylandeskserver.com/LdLogon/Provisioning/windows/SDClientHandler.sig)

2017-11-07 16:41:01(8660-4724) ldprovision.exe:Waiting for process result: 0.

2017-11-07 16:41:01(8660-4724) ldprovision.exe:Process exit code:-1

2017-11-07 16:41:01(8660-4724) ldprovision.exe:Failed to download (C:\ldprovisioning\SDClientHandler.sig)

2017-11-07 16:41:01(8660-4724) ldprovision.exe:Informational: No sig file downloaded.

2017-11-07 16:41:01(8660-4724) ldprovision.exe:Done with download handler.

2017-11-07 16:41:01(8660-4724) ldprovision.exe:Launching action handler [SDClientHandler.exe] with parameters ["]

2017-11-07 16:41:04(8660-4724) ldprovision.exe:handler launched.

2017-11-07 16:41:04(8660-4724) ldprovision.exe:End of action - Distribute_software

2017-11-07 16:41:04(8660-4724) ldprovision.exe:Reporting action status: 5 to core.

Ivanti 2017.3 Provisioning problem with map/unmap drive to preferred server

$
0
0

HI All

 

After Upgrade from Ivanti 2017.1 to Ivanti 2017.3

We have a problem with Map / Unmap drive to preferred server

 

 

map1.jpg

 

 

map2.jpg

 

map3.jpg
Previously everything worked

There are no errors in the log
do you have any idea?

 

Thank you for reply..

Robert

Error: "68" during deploy image action in Ivanti Provisioning

$
0
0

Issue

 

When running a provisioning template, the template fails on the Deploy Image action.

 

This occurs in Windows PE when running imagew.exe.

 

The error is "68".

The full error is "-2147477501".

 

Error as seen in Windows PE:

 

The ldprovision.log file on the client (X:\ldprovision\ldprovision.log in WinPE) will show this error:

 

2008-02-15 21:32:19(692-696) ldProvision:Launching action handler http://DeployImageHandler.exe with parameters

2008-02-15 21:32:26(1500-1988) DeployImageHandler.exe:execute failed with 68


The following error is seen in the Provisioning History in the LDMS console when viewing the history for the device:

 

 


Cause


The disk driver has not been fully loaded and/or the hard drive is still locked when the imaging command is run.

 

Resolution

 

  • Add a Wait action before the Deploy Image action.
  • Start with 30 seconds.
  • If that is not enough to fix the problem, gradually increase the wait time until the issue is resolved.

Issue: Ivanti Antivirus or Policy Invoker Services not installing during OSD imaging

$
0
0

Issue

 

Ivanti Antivirus or Policy Invoker Service is not installing with the agent during the sysprep process on OS deployment

 

Cause

 

The network drive to the LDLogon folder is being deleted before the Agent installation completes.

 

Resolution

 

  1. The file that needs to be edited is a XML file, so execution may vary depending on how your computer is configured to handle viewing XML files. The instructions are written as if you need to manually find the file and open it with notepad.
  2. Browse to <coreserver>\LDmain\LANDESK\files
  3. Locate the .XML file with the name of your OSD deployment script.
  4. Open the .XML with notepad.
  5. Locate the and change the following as shown.

 

 

<SynchronousCommand>  <CommandLine>net use \\core90v2\ldlogon /d /y</CommandLine>  <Description />  <Order>6</Order>  </SynchronousCommand>
- <SynchronousCommand>  <CommandLine>cmd /q /c del /q c:\ldiscan.cfg</CommandLine>  <Description />  <Order>76</Order>  </SynchronousCommand>

 

Note: If you do a regular edit on the script and save the script, it will overwrite the .ini and .inf file and put the command3 line back in.  So if you have to modify the script, make sure that you do the advance edit on the script when you finish and remove the command3 line again.

Error: PXE-E74 bad or missing PXE menu and or prompt information

$
0
0

Issue

The following error occurs when attempting PXE boot:

PXE-E74 bad or missing PXE menu and or prompt information

           

 

This issue can be caused by a variety of different problems.  The following describes these different scenarios, causes, and resolutions.

 


 

 

ProblemCauseSymptoms and Resolution

PXE Representative has an outdated Ivanti EPM Agent.

Ivanti EPM agent is not at the correct version.The correct agent version matching the PXE Representative installation and the Core Server version

BIOS has bad network boot agent code

BIOS with Intel Boot Agent(IBA) versions 1.3.36 through 1.3.50 do not allocate enough memory space for the PXE menu to be loaded on the client computer.

This is the most common cause of this PXE-E74 issue.


Computers that customers reported experiencing this issue:

VendorModels
DellLatitude E3400 / E4300 / E7240, E7440, Optiplex 780
Lenovox200, T410, T500/W500
HP / CompaqMini 5103 Netbook
PanasonicCF-31

Symptoms: Only specific models of computer are unable to PXE boot.

 

Resolution:  Upgrade or downgrade BIOS.  Contact device vendor for further information.

 

BIOS with IBA prior to 1.3.36 or a BIOS with IBA after 1.3.51 should address this issue.


Some vendors have not provided an updated BIOS to fix the issue, while other vendors have. 
If a vendor has not provided a BIOS that fixes the issue if possible the BIOS should be downgraded. 
If an update is provided that may fix the issue, a BIOS upgrade may be necessary.

PXE Representative installation is incomplete or corrupted

The PXE representative installation may have been incomplete causing missing directories or folders, or those files may have become corrupt.  The following graphic illustrates the folder and files that should exist under \Program Files (x86)\LANDESK\PXE:

(Run "tree /f" from this folder to compare results)

      PXEFileTree.jpg
Click graphic to view full size.

Symptoms:  All computers on the same subnet will not PXE boot.  Or if using more than one PXE rep on a subnet, all computers going to specific (bad) PE Representative will fail.

Resolution: Reinstall the PXE Representative.

  1. Verify which PXE representative clients are attempting to boot from by looking for the PXE representative IP Address on the BIOS boot screen on the client.
  2. Delete existing PXE Representative Deployment task.
  3. Schedule new PXE Representative Deployment task.

Ports blocked to the PXE  Representative

 

During the network boot process, all file transfer requests are initiated to port 69 which services the TFTP (Trivial File Transfer Protocol).


If this port is blocked, requests to the TFTP Service on the PXE representative will fail.

Symptoms: All computers on the same subnet will not PXE boot. Or if using more than one PXE rep on a subnet, all computers going to specific (bad) PE Representative will fail.

 

Resolution: Check network environment to ensure that proper ports are available.

    • UDP Port 67 (DHCP)
      Port used by the DHCP Server to receive requests.
    • UDP Port 68 (PXE Client)
      Port used by the client for DHCPDiscover to DHCP Server
    • UDP Port 69 (TFTP)
      Port that PXE Rep receives TFTP requests from.
    • UDP Port 4011 (PXE / ProxyDHCP)
      Like port 67 on the DHCP server, but for PXE rep to respond to DHCPDiscover with further DHCP  information for the network booting process.

Incorrect DHCP options are  configured

DHCP PXE Boot options 43 and 60 should not be enabled on the DHCP Server.  The PXE Representative (ProxyDHCP) is designed to intercept the DHCPDISCOVER request from the client and in tandem with the  DHCP server offer a reply.  The DHCP server will reply with a DHCP offer with basic information such as IP Address, Subnet, DNS Server, etc.  The PXE Representative will then also give a DHCP offer with further information regarding network boot details.

Symptoms: Typically in this scenario, all computers will not be able to PXE boot that get their IP address from that DHCP server.

 

Resolution: Remove options 43 and 60 from the DHCP Server.

 

The DHCP server is typically configured in one of the following ways.

 

  • Option 60 not set.  Option 43 not set.
  • Option 60 set to 'PXEClient'.  Option 43 not set.
  • Option 60 set to 'PXEClient'.  Option 43 set.

 

When neither option 60 nor option 43 is set, PXE clients do not have information where the PXE server is, and will wait until a PXE server contacts them.  The PXE Representative listens to DHCP discovery packets sent by PXE clients and offers a DHCPOFFER response in tandem with the DHCP Server.

 

When option 60 is set to 'PXEClient', the DHCP server contains information about where the PXE representative is.  If option 43 is not set, the PXE server and the DHCP server are at the same IP Address.
If option 43 is set PXE clients must decode option 43 to know how to reach the PXE server.

 

In most situations, option 43 does not need to be set up, because the PXE server will either listen to DHCP discovery packets (DHCPProxy), or be on the same computer as the DHCP server. However, if the PXE server is on a separate subnet (it cannot listen to DHCP discovery packets), or if there are several PXE servers on the same subnet, option 43 is the only viable solution in order to instruct PXE clients on what to do.

Multiple PXE Representatives on the subnet or other 3rd party PXE solution on subnet

If there are multiple PXE Representatives on the same subnet a conflict can occur.  Similarly, if a 3rd-party PXE solution is present, this can also cause failure

Symptoms: Clients will intermittently fail PXE booting or will always fail to PXE boot.

 

Resolution: The following query can be created to find the IP address of all PXE Representatives (or the query can be modified to return other criteria if so desired)


How to: Create an Ivanti EPM Query to find all PXE Representatives

  • A Wireshark network capture can be performed to ensure all BOOTP (Network boot) traffic is coming from the expected sources.

Incorrect Permissions in IIS for folder

The \LANDESK\ManagementSuite\LANDESK\Files directory on the core server does not have the proper rights assigned to the IUSR account.  This is required for proper operation.

Symptoms: All clients receive the PXE-E74 error.


Resolution: Ensure that the local IUSR account on the Core Server has rights to the  \LANDESK\ManagementSuite\LANDESK\Files directory.  In addition, ensure that Group Policy has not restricted the rights for IUSR as a whole.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


For more information on PXE boot errors please see:

PXE Boot errors and descriptions.

 

For more information on troubleshooting PXE boot please see:

Troubleshooting PXE boot (OSD)


How to add drivers to WinPE for Ivanti EPM OS Provisioning

$
0
0

Description

 

In order to perform imaging in Ivanti Endpoint Manager, the WinPE image used during the imaging process must contain drivers for devices such as the network adapter or hard drive controller.

 

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.

 

Resolution

 

First, note the driver versions that are required for each version of Windows PE.

 

The following document should be consulted to see which version of PE is used in each version of Management Suite: About Windows PE versions used in Ivanti Endpoint Manager

 

  • From the console go to Tools > OS Deployment
  • On the Operating System Provisioning window select the Preboot dropdown
  • select Manage Drivers in WinPE Image.

2015-03-11 08_26_15-RD Tabs 64.jpg

  • 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.
    • Others would be used to modify bootmedia.wim

2015-03-11 08_45_04-RD Tabs 64.jpg

  • The image file will be processed to open the WinPE image and gather the list of drivers currently in the WinPE image file.
  • Select add or remove to manage drivers.
    • 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.

2015-03-11 08_51_13-RD Tabs 64.jpg

  • 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 the 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.
    • For LDMS 9.6 and 9.6 SP1 are using WinPE 5.0 based on Windows 8.1.    Windows 8 drivers should be used in this case.

2015-03-11 08_52_32-RD Tabs 64.jpg

  • After the necessary drivers have been added, select Finish and the drivers will be injected into the image.
  • After the image has completed processing it is necessary to update existing PXE representatives.

 

 

Additional Resources

Issue: OSD.Upgrade.exe error during installation

$
0
0

Description

 

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

 

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

 

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

 

Common errors and description

 

  • Error: "Access Denied"

    • Errors referring to access denied indicates that a folder path in the boot.wim is too long. Often this path will be for a driver that was injected into the WinPE image. There are two option for correcting this error. The first option is to just start with a clean boot.wim and add the necessary drivers after completing the OSD.Upgrade.exe process. In LDMS 9 Service Pack 3 the WinPE boot environment requires Windows 7 32-bit drivers. Updating those drivers is a manual process so starting with a clean boot.wim may be a good option. The second option would be to mount the backup of the boot.wim (boot.wim.bak) and rename the directories in the InstalledDrivers directory to use shorter names. After completing one of these options follow the steps outlined below to re-run OSD.Upgrade.exe.

  • Error: "CommonCore.inf: (0xFFFFFFFF) OSD.Upgrade.exe,60000"

    • This is a general error indication. Review the log for additional errors.
    • Check to make sure the boot.wim is not mounted on the Core server.
      • The way to check this is running "dism /get-MountedWiminfo" from command prompt. This will show if wim's are mounted and where.
      • Check the OSD.Upgrade.exe.log file for any missing files. Then give it those missing files in the path that it is looking for them.
        • example: "09/06/2016 10:22:53 INFO  9680:1     RollingLog : File C:\Program Files\LANDesk\ManagementSuite\\ldlogon\provisioning\windows\Microsoft.VC90.CRT.manifest does not exist"
  • Error: "DirectoryNotFoundException"

    • Errors referring to a .0 or an mpkg package indicate that a .0 file has been extracted to a sub-folder of the ldlogon folder. DO NOT delete any .0 files from the root of ldlogon. Navigate to the directory specified in the log (i.e. C:\Program Files (x86)\LANDESK\ManagementSuite\ldlogon\mac) and delete the .0 file. To prevent additional errors when re-running OSD.Upgrade.exe delete any additional .0 files that are found in sub-folders of the ldlogon folder leaving only the .0 files in the root of ldlogon. Follow the steps below to re-run OSD.Upgrade.exe.
    • Errors referring an ALL.REG file indicate that the wim file was still mounted when osd.upgrade.exe tried to execute. This is most likely due to errors in the previous attempt at running OSD.Upgrade.exe. Review the log and correct and additional errors found before following the steps below to re-run OSD.Upgrade.exe.

  • Error: "Non-fatal error: FilterUnload failed, hr=0x801f0013"

    • This is normal and does not indicate a problem. Continue reviewing the log file for additional errors.

  • Error: "System.ComponentModel.Win32Exception"

    • You are running the process as a restricted user. Either log in as an administrative user or right click OSD.Upgrade.exe and select run as administrator.
      • Make sure that you are either logged directly into the core server or using Remote Desktop with a /admin switch as a full administrator.

  • Error: "System.IO.IOException: Element not found"

    • This error indicates that there is still a wim file mounted. Review the log for additional errors prior to this error. Follow steps below to re-run the OSD.Upgrade.exe process.

  • Error: "System.UnauthorizedAccessException"

    • This error indicates either that there is still a wim file mounted, or that the bootmedia.wim.bak already exists. Bootmedia.wim.bak can be deleted as long as bootmedia.wim exists. Review the log for additional errors and then follow the step below to re-run OSD.Upgrade.exe.

  • Error: "WAIK is not installed"

    • This is normal and does not indicate a problem. WAIK should have been uninstalled prior to upgrade. If WAIK is installed, uninstall it. Continue reviewing the log file for additional errors.

  • Error: "CommonCore.inf: (0xFFFFFFFF) OSD.Upgrade.exe,90000"

    • Download Streams from Microsoft (https://technet.microsoft.com/en-us/sysinternals/bb897440.aspx). Go into properties of Streams an unblock the application. Run Streams against the folder the Ivanti EPM installer was xtraced to and run Streams against the folder LANDESK is being installed to (ie, \Program Files\LANDESK). Make sure the Ivanit EPM installer is being run locally (not networked drive), you are upgrading the machine locally (not RDP) and run the installer as Administrator.

 

  • Issue: Upgrade fails at HII step

    • Log will displayRollingLog : HII: Setting driver repository path to "\\LDCoreName\ldmain\landesk\files\drivers" 08/05/2015 12:03:10 INFO 8732:1 RollingLog : HII: Initial driver file count to process:
    • In the \\LDCoreName\ldmain\landesk\files\drivers directory will be a db3 and db3 bak file. Rename the file to db3.old and db3 bak.old. Quit out of the installer and re-open and start install again
      .

Preparing to Re-Run OSD.Upgrade.exe

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

 

  1. Start an administrator command prompt (right click the command prompt and select run as administrator).
  2. From the command prompt navigate to C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot.
  3. Run the following command:

    DISM.EXE /Get-MountedWimInfo
    • The command should list all images that are currently mounted. There are instances however where a mounted image will not be listed. Check for the existence of the folder original_boot_wim and/or new_boot_wim in the C:\Users\logged in user \AppData\Local\Temp\imgtmp\ directory.

  4. For each image listed and all folders found in the imgtmp directory listed in step 1, run the following commands:

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

 

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

 

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

OSD.Upgrade.exe.log

How to change the WinPE wallpaper

$
0
0

Issue

 

The WinPE wallpaper can be changed to allow for branding or customization.

 

Resolution

 

The WinPE wallpaper can be modified using the following steps:

 

  1. From the Ivanti Endpoint Manager Console to Tools > OS Provisioning
  2. From the Preboot drop-down select the icon Change WinPE Wallpaper
    ChangeWallpaper.jpg
  3. Browse to the bitmap file that will be used as the wallpaper.
  4. Check the boxes (32-bit and/or 64-bit) to specify the image file(s) that the wallpaper will be changed in.
  5. Click Ok

ChangeWallaper2.jpg

How To: Troubleshoot Provisioning Template Action Handlers

$
0
0

Description

This document is intended to explain provisioning action handlers so that failures seen in individual actions within a provisioning template can quickly be found and corrected.

 

Core Logs

Logs on the core will help with why a task is not starting, but do not provide a lot of detail about why a certain action failed.

 

The following are the core logs:

 

  • %LDMS_HOME%\log\prov_schedule.exe.log
  • %LDMS_HOME%\log\provisioning\provisioning.log

 

Client Logs

Device logs can be found in the following locations on the client:

 

  • x:\ldprovision
  • systemdrive:\windows\temp

Note: When troubleshooting Ivanti EPM Provisioning, it is helpful to turn off removal of the client provisioning folder.

 

Steps to disable removal of the client provisioning folder

 

1. Right-click desired provisioning template and go to "Properties".

2. In the left-hand pane, select "Options" and uncheck the box next to "Remove Client Provisioning folder".

 

Understanding Action Handler Flow (Client)

Each action that is run in a provisioning template is done by an action handler. An action handler may launch multiple other action handlers as part of its task. These other tasks could be considered to be child actions. The deploy image action in 9.5 and higher is an example of this. The Deploy Image action hander may automatically download the appropriate tool for imaging using a Download Action handler. The Deploy Image action then maps a drive to the network location where the image file is using the Map to Preferred Server action handler. Finally it will complete its own job of deploying the image using itself. The launch of each of the additional action handler used by deploy image will be logged in the DeployImageHandler.log along with the result code from the additional handler.

 

This sample DeployImageHandler.log shows the launch of two additional action handlers (DownloadHandler.exe and maptopreferredhandler.exe) as well as the exit codes for those handlers.

 

ExecuteCmd DownloadHandler.exe /source="http://mycore/ldlogon/provisioning/windows/imagew.exe" /dest="x:\ldprovision\imagew.exe"

created process, file handle 60 with non-readonly parameter

Process Exit Code: 0

Verifying file was successfully downloaded.

The file (x:\ldprovision\imagew.exe) was successfully downloaded

Getting free drive letter

Free drive letter: f

ExecuteCmd maptopreferredhandler.exe /path="\\mycore\images\win7.tbi" /driveletter=f /pathisfile

created process, file handle 68 with non-readonly parameter

Process Exit Code: 0

 

 

If a failure occurred in either of the additional actions (DownloadHandler and maptopreferredhandler) launched by deployimage the errors would be shown in the DeployImageHandler.log with a corresponding exit code. Zero indicates the task succeeded. If a failure occurred the DeployImageHandler.log may not contain enough detail to determine the root cause of the failure. Instead the log from the additional action handler (DownloadHandler.log or maptopreferredhandler.log) should be reviewed. The additional action handler may even launch its own child handlers before returning so those logs may also need to be reviewed.

 

If the failure seen in the DeployImageHandler.log was an error mapping the drive to the image, the MaptoPreferredHandler.log would provide additional details about the failure. Sometimes the error will be spelled out. Other times only an error code will be shown. The error codes shown will often correspond to the windows error codes listed at http://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=vs.85).aspx. This allows a simple lookup to get additional information about the failure. Viewing the primary action handler log and following the failure through to the action handler log where the failure actually occurred will save time and frustration while troubleshooting provisioning templates.

 

Action Handler Logs

 

Provisioning ActionAction Handler Log (Client)
Capture ImageCaptureImageHandler.log
Capture ProfileCaptureProfileHandler.log
Configure AgentConfigHandler.log
Configure Target OSConfigTargetOSHandler.log
Control ServiceServiceControlHandler.log
Copy FileCopyFileHandler.log
Create DirectoryManageDirectoryHandler.log
Delete FileDeleteFileHandler.log
Deploy ImageDeployImageHandler.log
Deploy ProfileDeployProfileHandler.log
Distribute SoftwareSDClientHandler.log
Download FileGetFileHandler.log
Download from Preferred ServerDownloadHandler.log
Execute FileExecuteHandler.log
Hardware-Independent ImagingHIIHandler.log
Inject ScriptInjectScriptHandler.log
Install Mapped SoftwareMappedSoftwareHandler.log
Install ServiceServiceInstallHandler.log
Join DomainJoinDomainHandler.log
Map/Unmap DriveSmbShareHandler.log
Map/Unmap Drive to Preferred ServerMaptoPreferredHandler.log
Map Software to SLM TableMappedSoftwareHandler.log
PartitionPartitionHandler.log
Patch SystemPatchHandler.log
Reboot/ShutdownLDProvision.exe.log
Replace TextReplaceTextHandler.log
Scripted InstallClientActionHandler.log
Uninstall ServiceServiceRemoveHandler.log
Unzip FileUnzipHandler.log
Update RegistryRegUpdateHandler.log
WaitWaitHandler.log
Windows RefreshWindowsRefreshHandler.log

 

 

Error: PXE-E21: "Remote boot canceled" when PXE booting

$
0
0

Issue

 

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

PXE-E21.png

Solution

 

  1. This can be caused by having duplicate MAC addresses listed in the inventory.   These can be found by creating a custom Column Set for the All Devices view and sorted by MAC Address.
  2. UEFI is still not compliant with the PXE menu specifications, therefore booting a machine in UEFI mode via PXE for provisioning works only when the device is associated to a provisioning task on the core.


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

 

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

 

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

Issue: Provisioning and OSD fail after enabling FIPS on the core server

$
0
0

Issue

 

After enabling FIPS on the core server, Provisioning templates stop working.

 

If you select a Provisioning template to execute, it will attempt to run but will fail with error 80001803H

 

Cause

 

This issue occurs after enabling FIPS 140-2 on a core server. When FIPS 140-2 is enabled, a new SHA1 cert is generated on the core and replaces the old MD5 core cert.

 

The WINPE image does not get updated automatically with the new cert and thus communication from a client being imaged is refused by the core server.

 

Resolution

 

On the core server, do the following steps:

 

  1. Navigate to \Program Files (x86)\LANDESK\ManagementSuite
  2. Run "OSD.UPGRADE.EXE"

 

This will update BOOT.WIM, BOOTMEDIA.WIM, and BOOT_X64.WIM and inject the newer SHA-1 certificates into the Boot Images.

About Ivanti Support for Unattend.XML

$
0
0

Question:

 

I am attempting to use an Unattend.xml as part of my Ivanti EPM Provisioning job.

 

What support does Ivanti offer for troubleshooting or customizing my unattend.xml?

 

Answer:

 

Ivanti provides a sample unattend.xml either on the Ivanti community or bundled with the product as a service to our customers to give them a starting point.

 

Customizing the UNATTEND.XML to cover the customer environment will be necessary in most cases.

 

Troubleshooting or customizing the UNATTEND.XML file is not covered within the scope of LANDESK Support.

 

It is recommended to use Microsoft Windows System Image Manager to create an UNATTEND.XML file.

 

For more information on the Microsoft Windows System Image Manager, refer to the following Microsoft Technet Article:

http://technet.microsoft.com/en-us/library/cc766347(v=ws.10).aspx

 

Microsoft documentation or contacting Microsoft support is advised for assistance with the UNATTEND.XML

 

See the following Microsoft article:

http://technet.microsoft.com/en-us/library/cc748874(v=ws.10).aspx

Does anyone know this fix for this?

$
0
0

2017-11-10 16:38:40(2856-2828) ldProvision.exe:The file (C:\ldprovisioning\ApplyDrivers_x64.exe) was successfully downloaded

2017-11-10 16:38:40(2856-2828) ldProvision.exe:Looking for existing file (C:\ldprovisioning\ApplyDrivers_x64.sig)

2017-11-10 16:38:40(2856-2828) ldProvision.exe:Entering downloadbyproxy.

2017-11-10 16:38:40(2856-2828) ldProvision.exe:Create process (C:\Program Files (x86)\LANDesk\Shared Files\httpclient.exe) with args (  -f "C:\ldprovisioning\ApplyDrivers_x64.sig" http://xxxxxx/ldlogon/provisioning/windows/ApplyDrivers_x64.sig)

2017-11-10 16:38:40(2856-2828) ldProvision.exe:Waiting for process result: 0.

2017-11-10 16:38:40(2856-2828) ldProvision.exe:Process exit code:-1

2017-11-10 16:38:40(2856-2828) ldProvision.exe:Failed to download (C:\ldprovisioning\ApplyDrivers_x64.sig)

2017-11-10 16:38:40(2856-2828) ldProvision.exe:Informational: No sig file downloaded.

ldprovison.exe This app can't run on your PC

$
0
0

LDMS 9.6 SP3

 

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

 

20170112_101206.jpg

 

 

Any ideas?

Best.

Default unattend.xml why two time sysprep

$
0
0

Dear collegues. I'm starting these provisioning phases with landesk. Befor capturing an image i do sysprep and i turn my pc off.

( I start this command C:\Windows\System32\Sysprep\sysprep.exe /oobe /shutdown /generalize /unattend: C:\Windows\System32\Sysprep\sysprep.xml ,In sysprerp.xml  i do the "copyprofile ) .

During the deploy image I use the default LD_default_unattend.xml  of landesk.

why does the unattend file again show the sysprep command if one launches it before turning off the pc?

 

___________________________part of the unattend file I do not understand_______________________

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 wcm:action="add">

          <Order>1</Order>

          <Path>c:\windows\System32\sysprep\sysprep.exe /oobe /generalize /reboot </Path>

        </RunSynchronousCommand>

      </RunSynchronous>

    </component>

  </settings>

  <settings pass="generalize">

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

      <PersistAllDeviceInstalls>true</PersistAllDeviceInstalls>

    </component>

  </settings>

________________________________________________________________________________
I attach the unattend file by default.

 

Can I add the copyprofile to the LD_default_unattend.xml file? Must the sysprerp part remain in LD_default_unattend.xml?

Thank you
Simone

HII Driver Provisioning Conundrum

$
0
0

Hello all,

 

We are using Ivanti Management Console 10.1.10.287 to provision images to our brand new Dell 7480s. They were mistakenly shipped to us with win7 instead of win10.

 

Unfortunately our WinPE image does not have the network driver for these new models and once booted in PXE will not get an IP address.

 

No worries! This article shows me exactly what to do.

 

Issue: IP Address Cannot Be Acquired by WinPE for Some DELL Models During Provisioning

 

However I have found that the new model 7480 is not listed in my available models under HII Driver Management because I have never ran an inventory scan on these machines.

 

How to assign all drivers for a specific model in the HII Driver Management tool.

 

"5. In the Assign window, select the Make, Model, OS and Architecture from the drop-down lists for the computer that drivers will be assigned.

Note: If the Make or Model is not available to select then this model has not had an inventory scan run on it with the LANDESK Agent installed and this will need to be done before drivers can be assigned. If the Device Manager looking pane on the left side is blank after selecting the Make, Model and OS then this model has never had this OS installed and an inventory scan run on it which will need to be done before drivers can be assigned."

 

 

Well... These machines were mistakenly shipped to us with Win7 instead of Win10. I need to install Win10 with our image here to even install the Landesk Agent and run an inventory scan.

But I can't do that because I can't add the driver to my WinPE image.

 

See the circle of failure here?

 

Has anyone come across this issue before or have a workaround?

Ivanti 2017.3 Provisioning problem with map/unmap drive to preferred server

$
0
0

HI All

 

After Upgrade from Ivanti 2017.1 to Ivanti 2017.3

We have a problem with Map / Unmap drive to preferred server

 

 

map1.jpg

 

 

map2.jpg

 

map3.jpg
Previously everything worked

There are no errors in the log
do you have any idea?

 

Thank you for reply..

Robert

Viewing all 1803 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>