• Description
  • How to check if your certificate is valid and matches the one on the core server
  • Identifying the Issue
    • No logging generated on the core
    • Missing LANDESK Management Agent service
    • Verifying the Inventory Record
    • Verifying the PXE.amsx Web Service functionality
    • Verifying the LANDESK Management Agent Service functionality
    • Machine shows "OFF"
      • Causes
      • Resolutions
    • In the event that the certificate files are not valid inside of the boot images

Description

This issue is characterized by selecting an OSD script from within the PXE Boot Menu inside WinPE, the Boot Menu window disappearing, and then no further pop ups or display windows occurring.

There are several causes for this behavior, and therefore, several possible solutions. This troubleshooting guide is centered around the issue of the OSD script failing to be initiated on the core server, or the OSD logs indicating that the machine is "OFF". If the OSD script indicates that it is launching at least one EXEC line against the target, then this troubleshooting guide can be skipped.

Possible Causes:

• Duplicate devices names in the database. 
  (Suggestion is to create a query based on target mac address and delete all instances that already exist in inventory)
• Miniscans being turned off for Inventory.
  (Under Configure Services > Inventory -> Advanced Settings the value for Ignore Mini Scans should be set to 0).
  

  If "Ignore Mini Scans" is set to 1", NO miniscans from the OSD client will be processed!   This must be set to 0.

• Core Server missing files in the \Program Files (x86)\LANDesk\Shared Files folder.
• Missing LANDesk Management Agent.
• No Inventory Record for target client (MAC address or full inventory record should exist)
• Certificate in boot image does not match certificate on core or certificate is damaged or missing.

How to check if your certificate is valid and matches the one on the core server

1. Use 7zip, Winzip or another compression tool to open \Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\boot.wim.
2. Navigate to the \cba8\cbaroot\certs\ folder.
3. Make sure the ".0" file is present, and matches the one found in your \Program Files (x86)\LANDesk\Shared Files\Keys\ folder on the Core Server.

Below is a visual representation of this a flowchart that diagrams this process:

           (Click for full size)

Identifying the Issue

To determine the troubleshooting path, it must first be determined how far the process is progressing. The fastest way to accomplish this is to determine if a CustJob log is being created. Follow the steps below to determine this:

1. On the core server, go to the log directory. This is located at the following path <Install Drive>:\Program Files (x86)\LANDESK\ManagementSuite\logs or can also be accessed via UNC share at <coreservername>\ldlog.

2. Once in the log directory, it is recommended to sort by Date Modified, with most recent at the top.

3. The log file will be named CJ-OSD-<scriptname>-<timestamp>.log

4. If there is a log file, open it with a text editor, such as Notepad or Word.

5. If the log file is similar to the one listed below, and indicates that the machine is OFF, then CBA is unable to contact the specified machine or CustJob has targeted an incorrect machine record.

"Machine","CbaStatus","ExitCode","Duration","Begin","End","Command"

"(OFF) XPSP2B","OFF","N/A","0:00:00","11/6/2008 12:19:28 PM","11/6/2008 12:19:28 PM","N/A"
; "Job Complete","0 Done","0 Failed","1 Off","0 Unknown"

 

If there is no log, then the process did not complete to the point of initiating CustJob to launch the OSD script. See below for actions.

First, verify that the following service are installed and running on the core server:

LANDESK Inventory Server

LANDESK Management Agent

If these services are running, it may be beneficial to restart these services. If the LANDESK Management Agent service is missing, go to the "No logging generated on the core" section below. Once restarted, reboot the machine into WinPE and select the script from the menu.  If the same behavior occurs, follow the indicated directions:

If there was no log file generated in the log directory on the core, go to the "No logging generated on the core" section below.

If there was a log and it indicated that the machine was OFF, go to the "Machine shows OFF" section below.

No logging generated on the core

The process to request a script to run on the client machine involves a series of processes to request, resolve and schedule the task from the client to the core server. The below steps will attempt to identify and resolve the issue related to these processes.

Missing LANDESK Management Agent service

If the core does not have a LANDESK Management Agent service, you can install this service by following the steps listed below:

1. On the core, pull up the Start > Run window

2. In the field, type or paste the following command and then hit enter:

"C:\Program Files (x86)\LANDESK\Shared Files\residentagent.exe" /register

Once the service is installed, start the service and then try the OSD process again.

If there is not a C:\Program Files (x86)\LANDESK\Shared Files folder on the core server, please contact LANDESK Technical Support for further assistance.

If the LANDESK Management Agent service is installed and running and a service restart did not resolve the issue, please follow these additional troubleshooting steps:

Verifying the Inventory Record

OSD needs an inventory of the device being imaged in order to create the task and begin logging.  New machines that have not been inventoried before will be listed by its MAC address in the Device Name column in the console.

If there is no inventory record for that device, restart the inventory service and reboot the client and try imaging again.  If still no inventory record appears for the device please contact LANDESK Technical Support for further assistance.

Verifying the PXE.amsx Web Service functionality

• Open the CoreWebServices.dll.log located in the log directory on the core server. The log should contain lines that are similar to those listed below:

RunScript: started with client mac address 000C29461DD1, script GUID bc6a8a9c-3edc-4845-83fb-5e1cceb60b71
RunScript: completed successfully with client mac address 000C29461DD1, script GUID bc6a8a9c-3edc-4845-83fb-5e1cceb60b71

Note: Each script has an associated GUID.  The GUID is contained in the Script (Located in the ManagementSuite\Scripts directory).   This must match in the PXEMENU table in the database in order for the script to be associated properly.

Line in Script: GUID=71e307da-bb27-46ab-ac8d-ef9641f3139f

 

Entry in Database:

• Can the LANDESK PXE.asmx web page be accessed? (Note: This must be run locally on the Core Server

• Open a web browser on the core and type/paste the following address:

http://localhost/LANDESK/ManagementSuite/Core/core.webservices/PXE.asmx

This should display the web page shown below:

• Will the GetObjIDFromMacAddress function resolve a Mac address to a Computer_Idn from the PXE.asmx web page?
  (Note: This must be run locally from the Core Server)

1. Click on the GetObjIDFromMACAddress link in the web site.

2. On the MAC Address field, enter in the mac with no spaces or dashes.

3. Click on the "Invoke" button to process.

4. The following return should be displayed:

NOTE: The number encased by > < is the object ID and corresponds to the machine's ID assigned by Inventory.

If this process fails, then there is most likely a missing record. Ensure that the Inventory contains the MAC address associated with a machine record.

Will the RunScript function start the job by manually putting in the MAC Address and ScriptGUID?
(Note: This must be run locally from the Core Server)

1. Click on the RunScript link in the website.

2. On the indicated fields, input the MAC Address and the script GUID.

3. Hit the Invoke button.

A CustJob window should launch on the core and start processing the script. You can also look to see if this process generates a log file in the log directory. If this process succeeds, then it indicates that IIS may be hung or not correctly processing SOAP requests.
Try running an "IISreset" command from Start > Run. You may also need to re-register ASP.NET on the core with the following command:

"C:\Windows\Microsoft.NET\Framwork\v4.0.30319\aspnet_regiis.exe -i"

• Enable OSD Web Tracing by doing the following:

1. Edit the web.config file in C:\Program Files (x86)\LANDESK\LANDESK\ManagementSuite\LANDESK\ManagementSuite\Core\Core.WebServices so that the line "<trace enabled="false"" reads "<trace enabled="true"" and restart the World Wide Web Publishing Service service.  (iisreset -restart also works)

2. The following URL may be used to pull up the Web Trace to track what requests are made to the OSD Web service on the core: (Note: This must be run on the LANDESK Core Server)

http://localhost/LANDESK/ManagementSuite/Core/core.webservices/trace.axd

• An http caching appliance will respond to the http requests made by the client. Due to the caching appliance responding, the client will not receive the subsequent lines of the script. Configure the caching appliance to not cache the http traffic from the Core Server.

Verifying the LANDESK Management Agent Service functionality

• Run script calls a local execute on the Core Server. The LANDESK Management Agent service must be running on the Core Server.

• To test the Management Agent service, run the following command line:

"C:\Program Files (x86)\LANDESK\Managementsuite\custjoblaunch.exe"

/objid=<object id of machine> /script="<script name without directory path>" /bootonly

For Example:

"C:\Program Files (x86)\LANDESK\Managementsuite\custjoblaunch.exe" 83 "DeployGhostImage.ini" /bootonly

If this does not launch the script, remove and re-install the LANDESK Management Agent service with the following commands:

Remove:

"C:\Program Files (x86)\LANDESK\Shared Files\residentagent.exe" /unregister

Install:

"C:\Program Files (x86)\LANDESK\Shared Files\residentagent.exe" /register

If these steps do not resolve the issue, please contact LANDESK Technical Support for further assistance.

Machine shows "OFF"

NOTE: When troubleshooting Inventory related issues, please ensure that you are logged in to the core console with a user that does not have any restricted scopes applied and that is allowed to view the Default All Machines scope.

Causes

1. Another machine in the database has the IP address assigned to the machine in WinPE.  Custjob.exe is targeting that device.

2. The inventory scan had not yet processed the ip address from the miniscan. This could be because the inventory service is stopped or hung.

3. Duplicate devices (two machines with the same MAC Address) in the database.

4. Core cannot contact the Agent on UDP port 9595 or port 38293. (Firewall, or other filtering device is blocking this port.)

5. Under Configure | Services | Custom Jobs, the Discovery setting may be set to TCP only.  WinPE only responds to UDP.

6. DNS can be in a state where the client can resolve the Core Server but the Core Server cannot resolve the agent workstation.

7. NIC driver may not be entirely functioning properly.

8. Name resolution problems may prevent the core from targeting the machine by DNS name.

Resolutions

1. Start or restart the Inventory Service.

2. Search for the IP address that WinPE has.  If another device has this IP address, delete that inventory record.

3. That device may show up twice in the database.  Delete all devices with that MAC Address.  See
   community article 1569 for assistance with this.

4. Open UDP ports 9595 and 38293 between the Core Server and the Agent workstation.

5. Go to Configure | Services | Custom Jobs and set the Discovery to try both UDP and TCP.

6. Go to Configure | Services | Custom Jobs and check the box to Disable DNS/WINS Lookup.

7. Make sure the Core Server can ping the Agent workstation by name and IP.

8. Update the NIC driver In the WinPE image.

9. Make sure the Core Server and PXE reps are running the same version of software.

10. Verify that the client miniscans are being received by the core server. Enable the Store Scans option in Configure | Service | Inventory | Advanced. Set the value to 1 and restart the Inventory service. Browse to the ldmain\ldscan\Storage directory and verify that .IMS files are being received when the client boots into WinPE.

11. Verify that the core is processing mini scans. Check Configure | Services | Inventory | Advanced | Ignore mini scans. This value needs to be set to 0.

In the event that the certificate files are not valid inside of the boot images

1. Navigate to \Program Files (x86)\LANDesk\ManagementSuite

2. Run "osd.upgrade.exe"

3. This will inject the proper core certificates into the boot images.

Hi All,

I have been setting up the OS deployment on our network. We are using Windows version 1803 and so far all has been working fine but once the imaging process gets to the setup phase it is having some problems with the Unattend.xml

I have used the template in the Knowledge articles and changed the relevant information but for some reason its not playing ball. On my last attempt at building it gave the attached error saying that the last line in the file was incorrect. This line was the </Unattend> closure.

Could someone have a check on the file we're using to ensure I have not missed something important as I am at a loss as to what is failing the process.

Thanks

So I have a test device in which I am testing all stages of deployment and for a while the Unattend file was failing and I couldnt get past the inject unattend file. I got that sorted and the machine provisioned correctly apart from it failed to install the LANDesk Agent. However now when I got to PXE boot the machine it just hangs for a second and then returns me back to the boot menu along with 1 beep.

I have tried this on multiple machines but once they have been provisioned once already I am unable to pxe boot them again. Does anyone have any idea what is going on?

SeanNye please add anything as a reply that I may have missed.

EPM 2017.3

Just a quick question regarding the Provisioning shares (Preferred Server):

When creating a Software Distribution share, IIS has to be configured (Virtual Directory) certain permissions etc.

Id it the same for a Provisioning share? meaning that I need to create a virtual directory, etc?

It's probably obvious but being Friday afternoon, I just can't find an answer or remember.

Any info is appreciated.

Best Regards.

Hi guys, I'm setting up some Ivanti preferred server from few months ago, everything is fine, but recently, when I transfer file from a replicator server to a preferred server, it lost files, for example: it copied 60GBs, then the day after, it lost 40GBs. Since I use a schedule to run a process, I cannot see a log after it failed. Do you guys have any idea or where to find all the logs of this process? Please help me, thank you in advance.
Btw: I tried to reach ivanti support but the template of support page is quite complicated, so I still cannot find a place where I can send an email

MaptoPreferredHandler.exe failing with error 100001, started this week. The MaptoPreferredHandler.log shows it is trying to use http:// for path which causes the failure. This only occurs on Win10, Win 7 works fine path used is UNC... Anyone have any ideas? Also Our Production core does not have this behavior and nobody is admitting to any changes.

Runnning LDMS 9.6 SP2 Sustaining Patch 1223I

2016-05-04 15:13:37(6448-6452) MaptoPreferredHandler.exe:******Mapping to: \\KOESAPPN150\LDShares

2016-05-04 15:13:37(6448-6452) MaptoPreferredHandler.exe:Drive letter = M

2016-05-04 15:13:37(6448-6452) MaptoPreferredHandler.exe:Mode - Require preferred server.

2016-05-04 15:14:05(6448-6452) MaptoPreferredHandler.exe:Could not map or unmap drive. Error code: 100001

2016-05-04 15:14:05(6448-6452) MaptoPreferredHandler.exe:End of Map Drive.  Path used: - http://ROCLDP4124.ekc1.ekc.kodak.com/LDShares/.

Issue

You try to add a "Change settings" action in a provisioning template. After selecting the agent settings you want to change, the "OK" button is not working and you are not able to validate this step.

This issue has been seen only in french and german versions of EPM. A bug has been created and the fix will be release as soon as possible.

Workaround

1. Open Tools > Configuration > Agent Settings.

2. Click on the calendar with the clock, top left, and choose Change settings.

3. Select the settings you want to change and save it.

4.. Go to Tools > Distribution packages

5. A new package has been created with name "Change settings".

6. Open your provisioning template.

7. Add an action "Distribute software".

8. Choose the package previously created

9. OK

Hello together!

I am currently trying to provision bare metal machines and have a problem with the way tasks are being activated.

Either I don't fully understand how tasks work or it's a bug.

Here is my problem:

Once I have added a bare metal machine by using the MAC as identifier, I drag it onto the OS deployment task. Then, I right-click the task and go to "run now - all".

I boot the machine via PXE and the deployment immediately starts.

Now I add another bare metal machine and drag it onto the deployment task as well. That new machine is now in waiting mode. When I click on "run now - devices that didn't try to run the task", the newly

created machine goes active and the currently running one is reverted to waiting and a second provisioning try is created in provisioning history, which leads to failure.

Am I doing something wrong or is it a bug? Or is there another way to start task for newly added devices?

Currently using 2018.1.

Any help is appreciated.

Regards,

Ray

We are running Ivanti EPM 2017.3 SU3.

We are deploying Windows 10 with no problem but I have now started to prepare our server estate to be deployed by EPM.

I have captured a syspreped Server 2016 image but when I come to deploy it to a test server if fails at teh CTOS stage.

Looking at it there seems to be an issue with it creating the CBA folder and copying the dll's over during hte ldprovision.cmd.

Any ideas why this would be if it wokrs fine on Windows 10?  (Basically the same kernel for Win10 and Server 2016)

Here's the situation:

Win 10 1709 -> Upgraded to 1803/also tried 1809

Ran the commands:

Get-AppxPackage -AllUser | Remove-AppxPackage

Get-AppxProvisionedPackage -Online | Remove-AppxProvisionedPackage

Also verified what I had left for apps by exporting this command:

Get-AppxPackage -AllUser | Where PublisherID -eq 8wekyb3d8bbwe | Format-List -Property PackageFullName,PackageUserInformation > C:\list.txt

I have gone through and removed each app specifically using the:

Remove-AppxPackage -Package [PackageName]

As well as:

Get-AppxProvisionedPackage -Online | where-object {$_.packagename -like "*packagename*"} | Remove-AppxProvisionedPackage

I have also turned off all windows features with the exception of Internet Explorer 11, because I need this app. Note: I managed to get this to work with 1809, once, and when I did, I turned off all features, and when I finally imaged the new 1809 on a device, I wanted to have Internet Explorer 11 to be included, or the feature to be turned on, or the application reinstalled. But, it's already installed, and the command to turn the feature on would require a RSAT install on the PC it gets to run the powershell module needed, which we didn't want to do.

I have ran the command in cmd:

msdtc -uninstall

msdtc -install

Made sure that SkipRearm located in: HLKM\SOFTWARE\Microsoft\Windows\Windows NT\CurrentVersion\SoftwareProtectionPlatform was set to "1".

Made sure that GeneralizationState located in: HKLM\SYSTEM\Setup\Status\SysprepStatus was set to "7".

Not sure what else I have done... it's been a wild ride, anyways, here's what I have left when I export that list:

Microsoft.AsyncTextService_10.0.17134.1_neutral__8wekyb3d8bbwe

Microsoft.ECApp_10.17134.1_neutral__8wekyb3d8bbwe

Microsoft.MicrosoftEdgeDevToolsClient_1000.17134.1.0_neutral__neutral_8wekyb3d8bbwe

Microsoft.MicrosoftEdge_42.17134.1.0_neutral__8wekyb3d8bbwe

And when I go through the sysprep Setupact.log, it looks like it breaks around:

SYSPRP ActionPlatform::LaunchModule: Failure occurred while executing 'Sysprep_Generalize_MountPointManager' from C:\Windows\System32\spmpm.dll; dwRet = 0x2

Any ideas?

The boot.wim and boot_x64.wim that ship with LDMS include the Threshold I RTM version of WinPE.  There have been two newer releases of WinPE since this version.  The current most up to date version is RedStone I / 1607.  New versions of WinPE are released every 6 months from Microsoft.

Some hardware such as the Surface Studios require this newer version in order to be PXE booted and provisioned.

Here are the steps to take to upgrade your boot files to a newer version of WinPE:

Step 1:

Download and install the latest version of the Windows ADK (or the version you need) from the below link to get Microsoft's release of the WinPE files that match the specific OS version:

Windows ADK downloads - Windows Hardware Dev Center

Step 2:

Run the Deployment and Imaging Tools Environment as administrator:

Step 3:

Download and run the following script from with-in the Deployment and Imaging Tools Environment CMD box that will prepare your WinPE files from Microsoft with the required modules for LDMS:

Create-WinPE.bat (attached to this document)

Step 4:

Take your prepared boot.wim and boot_x64.wim files from c:\winpe_x86 and c:\winpe_amd64 and copy them to this folder on your core:

Letter:\Program Files\LANDesk\ManagementSuite\landesk\vboot\clean\

*Note - backup the original files that are there incase you need to revert to the version that Ivanti ships with LDMS.

Step 5:

Backup your old production boot files.  Create copies of the files located at Letter:\Program Files\LANDesk\ManagementSuite\landesk\vboot and put them some where safe (step 6 will overwrite them).  However you must keep a copy of your old boot files here still.  Do not simply move them to another location.  Step 6 will be looking for these old boot files in order to migrate the HII drivers over to the new boot files, so if you rename them or move them instead of just making a copy of them - that step will not work completely.

Step 6:

On your core server launch an elevated command prompt and run:

This will upgrade your existing LDMS boot.wim and boot_x64.wim to now be RedStone I / 1607.

These updated files will be located at:

Letter:\Program Files\LANDesk\ManagementSuite\landesk\vboot

Additional notes:

- Bitlocker support is added via the Create-WinPE.bat script.  (can use manage-bde.exe with-in WinPE)

- PowerShell usage without requiring full path is additionally added.

EPM 2018.1

Shouldn't this work with the computer completely disconnected from the network?

As we are finding that newer machines are not supporting 32 bit winPE environments, we are being forced to move away from Legacy PXE booting.  We were using a portable thumb drive with a 64bit WinPE environment on it, but that USB has become corrupted and further attempts to recreate it using Landesk's built in function have only created unusable media.  So our next step is to attempt to create a UEFI PXE Boot environment.  However, when we attempt to PXE boot through UEFI, we cannot get an IP address.  I have seen many articles online talking about troubleshooting this, but nothing on how to set it up.  Can anyone point me in the right direction for setting up our network so we can use PXE in UEFI?

Thanks

Issue

• Some console users are configured with a specific role and scope assigned (They don't have the default "All devices" scope).
• Some technicians are not able to start a provisioning job from the template picker (40 out of 40 error).
• You want them to be able to schedule a template against a new bare metal device.
• However, even if they are able to create a new bare metal device, then they are not able to see them in the Management Console.
• How to resolve this without assigning to the user the right to see all the managed nodes?

Cause

The user does not have a valid scope to view bare metal devices or devices created by the provisioning template picker.

Resolution

1. Login to the Management Console with an administrative account

2. Create a new query with the following criteria:

Computer | Device ID = Unassigned

OR Computer | Type = Bare Metal Provision

3. Create a new scope from query and select the query created above.

4. Assign to the affected user (Or group) the right to see the new scope.

5. Verify that the user is now able to see the bare metal device they have created by having them close out of their open console and log back in (this will reload their assigned scopes and rights):

6. The technician should be able to see bare metal devices and associate those devices to a provisioning task.

When deploying my windows 10 image I get the error:

'Windows could not parse or process unattend answer file [C:\WINDOWS\Panther\unattend.xml] for pass [specialize]. The answer file is invalid.'

I don't get it i have succesfully used this unattend file previously for other images. Could there be a problem with the image i created it did something go wrong when the system went through the sysprep?

I have attached a copy of my unattend file if you could take a look and see if theres any issues with it?

much appreciated!

So I finally figured out my issue with Vboot and Dell Optiplex 5060. Turns out it is not actually a driver issue. It is a Dell Optiplex 5060 issue. If you enable legacy boot on the new Dell Optiplex 5060 computers, the WinPe for Landesk UEM will not work with an add in video card. It will work still for onboard Intel Graphics, just not a real video card. If you enable legacy boot on the 5060 and try to vboot with winpe, you will get a blank screen. Never before have we had this issue with Dell. But apparently they are fast tracking getting rid of Legacy boot options. What a nightmare.

What brought this about is we were still using legacy images. We are in the process of moving to UEFI images. So we were leaving Legacy as an option until we are fully moved to UEFI. So this has escalated our time table to move to UEFI fully.

seattleman1969

Migrated to document: How To: Deploy MBAM 2.5 SP1 on Windows 7 with LDMS 9.6 SP2

Hello,

Why at the time of integrating the drives during the provisioning, it integrates me of drivers of another other model, so when I assigned my drivers it was good?

Hello,

The USB is not detected on my different configuration. Yet the driver is well detected in HII. I have injected the USB drivers of the different configurations into my boot.wim, but that does not change anything. An idea ?

Best regards,

Alexandre

Bonjour,

Je souhaite provisionner des PC portables depuis un modèle déconnecté sur une clé USB.

Lorsque je lance l'opération de création de la clé j'obtiens un échec avec cette erreur dans le log :

J'ai fait l'essai avec 3 clés USB de 4 Go, 8 Go et 16 Go ainsi qu'un disque dur externe de 500 Go.

J'obtiens toujours le même log.

Merci pour votre aide.