“Post converted to PDF and attached for Migration.

More details available here: https://community.ivanti.com/docs/DOC-71280”

“Post converted to PDF and attached for Migration.

More details available here: https://community.ivanti.com/docs/DOC-71280”

“Post converted to PDF and attached for Migration.

More details available here: https://community.ivanti.com/docs/DOC-71280”

“Post converted to PDF and attached for Migration.

More details available here: https://community.ivanti.com/docs/DOC-71280”

Link to the video: How to import export provisioning template.mp4

If creating disconnected template failed and the CTOS and ldprovision folder on the USB drive are empty, you will need to create prefer server for your core server, and you could create multiple entries for core server hostname, IP address, and FQDN name.

I have been trying to get better control with what is copied over using the USMT template that was setup for us when first starting to use the End Point Manager. By "better control" I mean the following

     1. Exclude the Administrator and Public profiles from copying over

     2. Exclude certain program files from transferring from "C:" and "C:\Program Files (x86)"

My attempts to do this consist of the following

     1. Include this syntax in the "command line parameters" within the capture and restore templates

          /ue:*\* /ui:testuser

          /ue:*\Public /ue:*\Administrator /ui:testuser

          Note: Testuser is a domain account and imports properly. Also, I have tried many variations (inverting the /ui and /ue triggers etc.) on this type of syntax. I am also familiar with the notion "/uel" supersedes "/ui" supersedes "/ue"

     2.  I have included the following type of lines in the MigExclude.xml file within the USMT on our core server and it doesn't ever seem to make a difference. I look at the log and it continues to process items I enter exclusions for with the following format.

          <pattern type="File">C:\Program Files (x86)\K-Lite Codec Pack\* [*]</pattern>

          <pattern type="File">C:\Python27\* [*]</pattern>

          etc. etc. etc.

LD9, Win 7, Sysprep headache

See attachment for details

Hoping someone could help fix this. I've created a new image and did changes, updates, etc while in audit mode. I then sysprep it with oobe and generalize. Image deploys fine but when it finishes I'm always at the oobe screen, landesk client doesn't install or finish correcty. Should I be sysprep differently or am I missing something else in general?

Unattend.xml Attached.

LanDesk 8.8 with DOS PE (Ghost)

Tangent Vita KX All-in-One PC

RTL8168/8111 Family Gigabit Ethernet Adapter (ven=10EC "Realtek dev=8168 "RTL8168/8111 Family Gigabit Ethernet Adapter" drv="rtend")

It appears our brand new series PCs will not PXE Boot. This problem is unique to this model as we are not having problems with our dozen or so different models of HP desktops and laptops. It receives the following error and appears not to recieve an IP when viewed under LD Management:

• Intel UNDI PXE-2.1 (build 082) Covered Patients... etc
• Realtek PCI Express Gigabit Ethernet Controller Series v2.25 (090106)
• Client MAC ADDR: 00 06 EF 09 11 3B  GUID: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFF
• PXE-E53: No Boot Filename received PXEM0F: Exiting PXE ROM error “PXE-E53 No boot file found”.

It appears driver related however I have updated the DOS driver on the server (with the latest provided by the vendor who claims no problems with other PXE customers) following the process described here with no change in the results:

• http://community.landesk.com/support/docs/DOC-1581

I have linked below a similar experience someone had with this exact same integrated NIC chip:

• http://www.deploymentforum.com/Community/Forums/tabid/124/forumid/24/tpage/1/view/topic/postid/4373/Default.aspx#4373

I have also included a post from LanDesk’s Forum as well addressing this however our service is running and the imaging works for all other models:

• http://community.landesk.com/support/message/13834#13834

Any thoughts would be appreciated.

How to Troubleshoot Self-Electing PXE Services

LANDesk Targeted Multicast Service

The LANDesk Targeted Multicast Service (TMCSVC.exe) is responsible for all PXE Elections.  When a device is elected, the TMC Service running on that device will install both PXE services and will keep all PXE files up to date including boot.wim and netboot files.  It will check for updated files on the core according to the set polling frequency (15 minute default).  TMCSVC.exe uses multicast packets to poll it's subnet.  These packets do not need to leave the subnet so it is usually not necessary to allow multicast traffic on your routers, but any local firewalls, endpoint security or similar products must allow multicast.

PXE Rep Scoring

When determining which device will be elected as the PXE rep, a scoring process takes place.  This is an automatic process that happens in the background.  However, you can influence the score of individual machines by modifying this registry key:

HKLM|SOFTWARE|Wow6432Node|LANDesk|ManagementSuite|WinClient|CSEP

The keys are not there by default so create any missing keys.

Set the PXE_SVC_SCORE dword to a numerical value.  Configuring this reg key will set the starting point used to calculate the score of the device for the PXE Rep election.

The higher you set this value the more likely the device will be elected as the PXE Rep.  A value of 25 is usually sufficient, and 100 will essentially lock that machine in as the PXE Rep.

When is this useful?

PXE Service is giving "Subnet Error"

Reference Issue: PXE Service is giving "Subnet Error"

PXE Service is "Crippled"

If the CSEP registry key specified above also contains a "PXE_SVC_CripReason" string, this indicates the PXE Service has determined that it is 'crippled' and is informing CSEP that it cannot act as the PXE Rep.  Common causes for this crippled state would be failure to download the boot.wim or netboot files.

To solve this issue, troubleshoot the failure indicated in the dword.

Multiple NICs or WiFi-only Devices

A device with more than one NIC or a device with only WiFi will not be elected as PXE Rep, even if it scores higher than other devices.

Other Common Issues

• Device is elected, but PXE services will not run?
  • Make sure the Certificate for this device is approved.  Devices without an approved cert may still be elected, but the services will be prevented from running.
    • Pre-SU2 there is no warning or logging about this condition so it is vital to check Client Access on the core and approve certs:
      
    • After SU2 is applied, you will see a message indicating the elected device does not have an approved certificate in Self-Electing PXE Services.  Devices in this condition will be allowed to function as a PXE Rep for one hour.  After the hour expires, a new PXE rep will be elected.

Relevant Log Files

Tmcsvc.log

• C:\ProgramData\LANDesk\Log\tmcsvc.log
• The Targeted Multicast Service on the client handles all elections
• When a device is elected for the first time TMCSVC installs the LANDesk PXE Service and LANDesk PXE MTFTP Service
  
  These services will remain installed, but inactive, if the PXE election changes
• TMCSVC is responsible for starting and stopping the services whenever elections take place

Note: Restarting the LANDesk Targeted Multicast Service on the PXE rep will cause the rep to go through the election process.

SelfElectController.log

• C:\ProgramData\LANDesk\Log\SelfElectController.log
• This log contains more information on elected devices

PXEsvc.log

• C:\ProgramData\LANDesk\Log\pxesvc.log
• Enumerates the PXE Service install process, Boot.wim and Mac NBI download process and communication with the core server

Note: Restarting the LANDesk PXE Service on the PXE rep will cause the rep to attempt to download the boot wim and NBI files.

Pxemtftp.log

• This is not used during the election process but enumerates the file transfer of the boot.wim and NBI files to clients as they perform a network boot.

I have two devices that work with our 2016 core but one does not work with the new 2017 core. With the computer shown to the right, it states that  X:\ldprovision\ldprovision_x64.exe is not compatible with the Windows you're running.

Any thoughts?

I have Landesk 2016 with a golden Windows 10 v.1803 image. I have a request from another IT member to convert it to .pvm format. Can that be done? If so, what would be the best way to do this?

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 to be 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\LANDESK\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 upthe .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 another 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. Copy the cert from the server (ex:6d7g84c9.0) from the server directory (C:\Program Files (x86)\LANDESK\Shared files\cbaroot\certs) to your offline boot.wim diretory (%offlinefolder%\cba8\cbaroot\certs\) be sure to delete the old cert. Note: This step ensures you don't receive mapped drive failures within Provisioning.
12. 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. IMPORTANT: It is absolutely necessary to close all Explorer windows related to the bootwim mount directory before running the unmount commands. Failure to do so will cause your commit to fail due to files still being in use.
    
    
13. 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.

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

15. At this point, the PXE clients will need to download the updated boot wims. If you are running EPM 2016.3 or higher, you will need to wait around 15 minutes for the the wim files to automatically update on the PXE rep.
16. Once the boot.wims are updated (you can compare the date/time/size of the boot wims on the PXE rep to the updated wims on the core to make sure that they match), re-test the issue and make sure everything is now working.

1. If your core is on 2016.0 or older, it is necessary to re-deploy the PXE representatives, as the .WIM files on the PXE Representatives do not automatically update. 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.
2. In the LANDESK Management Suite console, go to the Distribution tool group and then go to the OS Deployment tool.
3. From the OS Deployment tool expand the "All Other Scripts" section.
4. Right-click "PXE Representative Deployment" and select "Schedule".
5. The "Scheduled Tasks" tool should open and the newly created task should be highlighted.
6. 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.

Over the last year or so I've been trying to resolve the issue of supporting PXE Boot clients with a mix of UEFI and Legacy BIOS devices. I believe that I have resolved my issues. I currently have this implemented and it works very well. I have documented the solution and have submitted it here. I have tested this solutions on 9.5 SP3 through 2016. Feel free to critique, correct, or provide your own input.

Provisioning Template Process: Online vs Offline Compared

Ivanti Endpoint Manager Provisioning functions through the creation of Provisioning Templates.  By default, the device being provisioned will download the template itself and all related files during the provisioning process.  Sometimes it may be desirable to provision offline devices or devices that do not have a direct network connection to the core server.  In such cases, you can build a Disconnected Provisioning Template that can be deployed via DVD disk or USB drive.

Startnet.cmd

When a provisioning template begins, the startnet.cmd script is executed.  This script sets up the WinPE environment for OS Provisioning.  A sample script is attached to this document, and can also be viewed within your Boot.wim or in WinPE itself.  In WinPE it's located here:

x:\windows\system32\startnet.cmd

Offline Check

One section of the script executes a utility called OfflineCheck.  OfflineCheck scans all the mounted volumes looking for offline_task.xml.  Offline_task.xml is essentially the offline version of the template and actions to be executed, and should only exist in offline templates.  If the file doesn’t exist it is assumed that this is not an offline template and provisioning proceeds in online mode.

When Online

The startnet.cmd script is running in online mode and tries to resolve the Core Server's IP address.  If it fails to resolve, the template fails.  If it's able to resolve the IP it next attempts to ping the core by name.  If this fails, the template will still continue.  The startnet.cmd script then continues with standard actions such as an inventory miniscan, starting the remote control client, and eventually provisioning.

When Offline

All of the online processes are skipped and the device begins provisioning according to the offline_task.xml.

Troubleshooting

On occasion an offline template may run in online mode.  To troubleshoot this, we will want to compare the startnet.cmd script in WinPE with a known good copy such as the attached.  Next, check to see the offline_task.xml exists.  Its possible the Offline Provisioning Media did not create successfully or was modified post creation.

If all the above looks correct, watch the execution of the startnet.cmd script when WinPE first loads with the assumption that some action within is failing.  This process will generate an offlinecheck.log that is fairly verbose and should identify the problem.  One common failure is when copying some files to the ramdisk (X: drive).

In extreme cases you could mount the boot.wim and modify the startnet.cmd script to remove the “@echo off” from the beginning, in order to get better visibility to exactly where it is failing.

I keep getting the error "This kind of driver cannot be added" when trying to add a Dell TouchPad driver into WinPE.

This is the file I have. I uploaded it and assigned it in HII but I also want it in WinPE. thanks!!

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?

Hello,

We receive new Dell optiplex 7060, but we have problem to image them with Landesk 2017.

I have no problem with others models of Dell (laptop and workstation)

I have install the good network driver and he start my template without problem.

the problem is after installig the new OS. The PC restarts, but he don't find the disk and start again on the network

He makes many tries on 2 PCs  : Disk on AHCI, on Raid, start on UEFI only, start on Legacy, nothing happends correctly.

On my PC, the Windows Manager Boot disappears f I was on UEFI mode...

I don't see where the problem is.

Has someone the same probleme ? How to solve it ?

Thanks a lot for your comeback

Stéphane

PXE boot fails at getting the BOOT.SDI file.

LANDESK PXE and LANDESK PXE MTFTP services will not stay running on the PXE representative.

CauseThe TFTP block size for the subnet is too big.

Solution

1. Open the Self-electing subnet services tool in the LANDESK Console.

2. Click on PXE service on the left side.

3. Right-click the subnet for the PXE representative and select the Service settings option.

4. In the PXE Settings window, change the TFTP block size to 1456 for ia32 and x64 then save it.

5. Reinstall the LANDESK Agent on the PXE representative.

6. If this resolves the issue, you can try higher settings for the block size to see what works on the subnet. The higher the block size the faster the client will download files from the PXE representative.