Quantcast
Viewing all 1803 articles
Browse latest View live

How To: Troubleshoot Provisioning Template Action Handlers

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
Windows 10 UpdateWindowTenUpdateHandler.log

 

 

Image may be NSFW.
Clik here to view.

"No BitLocker recovery options available" after restart from Vboot

Problem

The message "No BitLocker recovery options available" is shown on a computer after rebooting from the Vboot action in a provisioning template.

 

Cause

The Vboot action performs a BCDEdit to have the computer boot from the boot.wim file downloaded from the core.

Bitlocker in conjunction with TPM is specifically designed to prevent BIOS level threats to the Hard Drive and is working as expected when stopping Vboot

 

Solution

Before setting BCDEdit options you need to disable or suspend BitLocker and Secure Boot on the computer.

https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/bcdedit--set

 

Image may be NSFW.
Clik here to view.

Dell USB-C Network Dongle causing Duplicate Inventory Entries

Issue:

 

When Provisioning with a Dell USB-C Network Dongle you are getting Duplicate Device ID's in your Inventory

 

Cause:

 

The USB-C Network Dongle is designed to pass through the Internal Device MAC Address, without the correct drivers loaded into WinPE (How to add drivers to WinPE for Ivanti EPM OS Provisioning - How to add drivers to WinPE for Ivanti EPM OS Provisioning ) the device uses its own MAC Address. When loading into WinPE a mini scan runs which creates a basic Inventory entry with the USB-C Network Dongles MAC address. Then later when the device boots into Windows and the pass through begins to work the Agent is installed a second Inventory entries is created since it now has a different MAC Address.

 

Resolution:

 

If you load the correct drivers for the USB-C Network Dongle then the pass through functionality will work within WinPE Environment.

 

Information from Dell - The USB-C Network Dongle is designed to pass through the Device MAC Address, this only occurs if the correct drivers are loaded into the WinPE Environment

 

Additional Information about WinPE Drivers:

 

How To Test Drivers Compatibility Within Winpe

How to add drivers to WinPE for Ivanti EPM OS Provisioning

Windows Boot Manager appears after PXE Boot out of Provisioning Template

Some clients boot into the windows boot manager after booting them to WinPE through a provisioning template. I always need to press Enter to continue the boot process.

Has someone expirienced similar things? How can I skip this?

 

Image may be NSFW.
Clik here to view.

How to deploy User Profiles Using LANDESK Provisioning - Video

A video showing how to deploy a profile using a provisioning template.

Image may be NSFW.
Clik here to view.

Cannot Join Domain or install Agent in Windows 10

Hello All,

 

I cannot seem to get my windows 10 images to provision correctly.

 

We use ImageX in our environment. When I capture the image I used Sysprep with OOBE.

 

However when deploying the image, the task seems to stop at "Configuring Target OS" and stays "working". There is a cmd window that appears for a split second and then the machine reboots and loads into Windows and stops at the log in screen. Once I log in nothing happens. In our windows 7 images, the task window would appear after log in and continue running, adding to the domain and installing the agent.

 

There is an LDprovisioning folder in the C drive, however when clicking any .exe the whole folder disappears.

 

If I boot the machine back into PXE, it loads up the task again and finishes configuring the target OS task, then fails the "Add to domain" and "configure agent" tasks.

 

Also of note, the Device name prompter does not actually change the name of the machine. The original image name is retained despite the task saying it succeeded.

 

Any ideas as to what I am doing incorrectly? This same process works great with our windows 7 images, however I did not build those and the employee who did is no longer here.

 

Image may be NSFW.
Clik here to view.
provhist.PNG

Mac Netboot Gives Flashing ? Folder

Hello all!

 

I am in the process of setting up a Mac imaging environment for the first time and am running into some difficulties. I have been following the steps for the LANDESK 2017 version of MacOS deployment but so far have not been able to Netboot successfully. Holding down N on boot eventually takes me to a flashing ? folder and initiating a reset/netboot with the Ivanti Management Console just takes me to a black screen before rebooting into the OS. I am not sure what all information you need to help, or if I am even asking the right questions. Any help would be greatly appreciated!!

 

Thanks!

DC

Windows 7 installieren mit WIN PE10

Hallo,

ich versuche verzweifelt mit DSM 2016.2 Laptops mit einer NVMe-Festplatte unter Windows 7 zu installieren.

Ich habe per DSM ein Bootenvirnment WIN PE 10 erstellt. Windows 10 lässt sich auf dem Rechner problemlos installieren. Dann habe ich mit NTLite die besagten DLLs getauscht.

Anschließend sann starte ich die Windows7-Installation mit besagtem Bootenvironment. Die Festplatte wird noch partitioniert, aber danach bleibt die Installation mit einem Fehler stehen. Das Config-package bringt eine Fehlermeldung. Das Windows 7-Image müsste funktionieren, da ich dieses mit einem WINPE10 von einem USB-Laufwerk auf die Hardware installiert bekomme.

Hat mir jemand evl. eine Schritt-für-Schritt-Anleitung was ich genau machen muss?

Wie kann ich setup.exe manuell starten bzw. wo finde ich logfiles um den Fehler einzugrenzen.

 

Bin für jede Rückmeldung dankbar.

Gruß Andreas


Slipping Ivanti Agent into MDT

Hi,

 

We do not want to use the entire Ivanti imaging process but are trying to install the Ivanti agent during the MDT task sequence and have it trigger the System Configuration portion of an OS Provisioning Template to install an Application Bundle of default apps.

 

Is there any known way to accomplish this?

Image may be NSFW.
Clik here to view.

No Boot Device Found after exiting WinPE

When Imaging machines with UEFI enabled i am running into a problem after rebooting from WinPE. the first reboot does not see the hard drive. If you check BIOS before it attempts to boot there is not option for the hard drive or windows boot manager under the UEFI options. After it fails to boot, BIOS then registers the harddrive and the machine will boot into windows and complete the OSD template.

Issue: Unable to obtain a lock on drive C:

Overview

During provisioning while deploying or capturing you may get the following error. Most commonly this error occurs when deploying an image but can occasionally occur during capture as well.

 

Image may be NSFW.
Clik here to view.
UnableToObtainLockonC.PNG

 

Cause

As the error indicates ImageW is unable to lock the C drive because the volume is in use by an application or by the OS.

 

Solution / Workaround

You can overcome this issue by forcing the dismount of the volume. You will need to add an additional command to the command line parameters in your deploy or capture image action within your template. The switch is /fd. The /fd needs to be placed after the /rb:0 switch. Below is an example.

 

Image may be NSFW.
Clik here to view.
Template.PNG

 

*** Important ****

Do not use the validate button after making the changes. The validate button resets the command line back to default and will remove the /fd switch.

 

More information

More information about the fd switch is found below.

(/fd Use this option to force dismounting a volume (partition) that can't be locked for backup when PHYLock or VSS is not used. Using this option will invalidate all opened handles to the volume, which may result in lost data. Image for Windows will attempt to lock the volume after forcing the dismount.)

 

ImageW manual.

http://www.terabyteunlimited.com/downloads/ifw_en_manual.pdf

Issue: PXE boot stops at downloading the BOOT.SDI file.

Issue:

PXE boot fails at getting the BOOT.SDI file.

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

 

Cause:

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

Image may be NSFW.
Clik here to view.

How to configure Self Electing PXE services in LDMS 2016.3 or higher

How To: Configure PXE services in LDMS 2016.3 or higher

KNOWN ISSUE: Manually configured PXE reps from older LDMS versions must be removed prior to installing the 2016.3 agent.  For more information see the following document:
Issue with Self-Electing PXE Services in LDMS 2016.3

What's new in LDMS 2016.3?

 

After upgrading to LDMS 2016.3 you may find PXE booting is not working as expected.   In 2016.3 LANDesk introduces Self-Electing PXE Services which is a major change and improvement to the way PXE representatives are deployed.  LANDesk will automatically elect and manage PXE reps for each subnet.  No longer will you need to manually deploy and remove PXE reps via Software Distribution packages.  While this new method has many advantages over the previous method, it will require some configuration before PXE booting will work properly.

 

You will notice that ALL Windows agents have a C:\Program Files (x86)\LANDESK\PXE folder (<18MB), also you will notice that if an agent has ever been elected as the PXE Rep it will have the LANDESK PXE Service, and LANDESK PXE MTFTP service installed. However, if the client is not the acting PXE Rep they will not be running. This is to facilitate the Self-Electing Services management of the PXE Rep on a given subnet. Once a device becomes a PXE Rep it will automatically download the boot.wim (~315MB) and boot_x64.wim (~420MB) files. These files will remain on the client even if a new PXE Rep is elected and this client is no longer acting as the subnet's PXE Representative. This can equate to around 750MB of disk space on current and previous PXE Reps.

If you have disk space concerns with some devices, or wish to prevent any device from acting as PXE Rep, assign to them a different client connectivity setting with PXE Services in their default (disabled) state.

Also in 2016.3 the NetBoot services offered by the LANDESK PXE Rep have been greatly improved for better more consistent performance. For information about how to configure PXE Representative to offer NetBoot Images to Macinstosh clients as well please see Configuring PXE to Deliver NetBoot Services in LANDESK 2016.3

 

Self-Electing Subnet Services

 

For the purpose of this guide we are dealing with the PXE Service section of SESS and we will focus on that aspect.

For more information on Self-Electing Subnet Services in general please see this help document.

 

Self-Electing PXE Services

 

When configured and enabled, your managed clients will automatically elect a PXE representative in each subnet.  If the elected PXE rep is turned off, damaged or stops responding, a new PXE representative will automatically be elected, usually within 1-2 minutes.  The necessary PXE software is now included with the standard agent install, but is turned off by default.  As you setup PXE services, you will determine which devices are available to be used as PXE reps and which subnets allow PXE booting, and then LANDesk will take over and automatically elect a PXE rep in each subnet.  LANDesk can dynamically reassign additional PXE reps if the previous PXE rep stops functioning.

 

Configuration

 

To setup Self-Electing PXE Services, we will configure Client Connectivity settings as well as the PXE Service within Self-Electing Subnet Services.

 

Client Connectivity

  • You will notice a new menu in Client Connectivity agent settings called Self-electing subnet services.  Select the PXE service submenu and check the box to Enable PXE service:
    Image may be NSFW.
    Clik here to view.
    Ashampoo_Snap_2016.10.19_16h56m20s_008_.png
  • This setting is where you will specify which devices are allowed to be selected as PXE reps.  When this setting is enabled, all devices to which this client connectivity setting applies might at some time be elected as the PXE rep. 
    If you wish to exclude devices from being elected as the PXE rep, you will assign them a different Client Connectivity setting, in which the checkbox is NOT checked.

 

Self-electing PXE Service

 

  • On the core navigate to Configuration -> Self-electing subnet services -> PXE Service:
    Image may be NSFW.
    Clik here to view.
    pxe.gif
  • Within this new dashboard you will configure whether PXE booting is allowed on a subnet by subnet basis.  When a particular subnet is enabled, and when Client Connectivity settings for devices in that subnet allow it, Self-Electing PXE Services will elect and manage PXE reps automatically
  • You can view the state of each subnet and view which device is currently elected as the PXE rep

 

PXE Settings

  • This is where you can customize PXE boot options on a subnet by subnet basis.  Select the subnet you wish to configure, and then click the "service settings" button on the toolbar:
    Image may be NSFW.
    Clik here to view.
    Ashampoo_Snap_2016.10.19_17h51m59s_009_.png
  • In the window that opens, you can configure Polling frequency, TFTP block size, allowed or denied devices by MAC address, and download source and bandwidth settings for the WIM:
    Image may be NSFW.
    Clik here to view.
    Ashampoo_Snap_2016.10.19_17h57m26s_010_.png

Polling Frequency

  • This setting determines how often the elected PXE rep on the subnet should check for updated settings and WIM files.  The default is 15 minutes.  If you change your boot.wim be aware the PXE rep will not 'see' the change until it polls for changes again

 

TFTP block size

  • This setting allows the wim files to be downloaded much more quickly, especially the boot_x64.wim.  The default size is 16384 for ia32 and 65464 for x64
    Be aware that some systems, particularly VMWare, require a block size of 1456, and your WIM images will not download if this setting is configured for a larger block size

Allowed and Denied

  • Allowed specifies that the list of provided MAC addresses are the only devices on the subnet allowed to PXE boot
  • Denied means all devices not on the list, but on the subnet, will PXE boot

WIM Downloader Settings

  • In this section you can allow the WIM images to be downloaded from Peer, Preferred Server, and Source, or any combination of the three
  • The WIM image must be available on the peer or preferred server and it must pass a hash check before it can be downloaded
  • You may also elect to limit the WAN or LAN bandwidth used when downloading the WIM.  This is a selection of how much available bandwidth to use, not how much total bandwidth

 

Troubleshooting Self-Electing PXE Services

For some common troubleshooting steps and log information please see this document:
How to Troubleshoot Self-Electing PXE Services

 

 

Provisioning Action: Agent Install Fails When Last Action In WSCFG32.Log Is Running SCSDiscovery.exe

Error message:

The error message is located in the agent install log (C:\ProgramData\LANDesk\Log\wscfg32.log). The last message in the log will look like so:

 

Tue, 12 Sep 2017 09:32:59 INI:  EXEC49=C:\Program Files (x86)\LANDesk\LDClient\SCSDiscovery.exe, /Output Silent SystemDiscovery /NoFile, NOWINDOW + INSTALLONLY

Tue, 12 Sep 2017 09:32:59 Starting process: C:\Program Files (x86)\LANDesk\LDClient\SCSDiscovery.exe /Output Silent SystemDiscovery /NoFile

The agent install will be hung from that point on.

 

Cause:

SCSDiscovery.exe Is used to determine if the device is vPro capable. The device may not be ready to run that EXE and it may not have access to the DLL's it needs to determine vPro functionality. This is usually because the OS is booting up for the first time and goes through additional configuration on the initial boot.

 

Solution / Workaround:

Add a 200 second wait (This time can be adjusted as needed) as the first action is System Configuration. This will allow the OS to go through it's initial configuration/OS setup. In general, it's a good idea to put a wait at the beginning of System Configuration to allow the OS enough time to boot properly.

 

Image may be NSFW.
Clik here to view.
WaitForMe_ImNotReadyQuiteYet.png

[Landesk] Problème déployement via Pxe, Ip reste local

Bonjour,

Nous utilisons Landesk 2016 pour déployer les Os Windows et applications, tout fonctionne correctement.

Dernièrement nous avons reçu de nouveaux ordinateurs portables Hp, nous avons suivi la procédure habituelle via le PXE.

Le début ce passe sans encombre mais la recherche de l'adresse Ip ne renvoi pas d'adresse de notre DHCP mais une IP en local.

Est-il possible que la carte réseau ne soit pas reconnu ? et qu'il faille mettre à jour le Win PE ?

 

Merci d'avance

 

Hello,

We use Landesk 2016 to deploy Windows OS and apps, everything works fine.

Recently we received new Hp laptops, we followed the usual procedure via the PXE.

The beginning goes smoothly but the search for the IP address does not return an address of our DHCP but an IP locally.

Is it possible that the network card is not recognized? and that it is necessary to update the Win PE?

 

thank you in advance

 

Ce message a été modifié par : david Faisant

Image may be NSFW.
Clik here to view.

LanDesk WinPE booting 32bit

Hello,

 

We are testing  Ivanti 2017.3 Console. We use provisioning for deploy computers. We have a problem with Windows 10 deploy that use the setup.exe unattend way to install. The problem is that USB stick load the 32bit version, so it's impossible for us installa a 64bit executable. We have some computer that are quite old, so we need to boot as "legacy" and not as UEFI (I'am told that if you use UEFI the WinPE switch to 64bit). Thanks a lot! F.

Image may be NSFW.
Clik here to view.

PXE Boot failing due to "TFTP", "PXE-032" or "NBD".

Description

When PXE Booting you receive an error before booting into WinPE.

- TFTP Boot Issues

- PXE-032 Error

- NBD failing to load (freezes)

 

Cause

Starting in Windows 10 1709 build windows firewall has been updated to Windows Defender Firewall.

 

If you have your firewall enabled and you used to be able to PXE Boot it was because the PXE Services was set as an exception.

 

Solution

 

Windows 10 1709 requires that you specify the open ports for PXE into the Inbound Rules if you have your Windows Firewall enabled.


Ports used by LANDESK Management Suite - Full List

 

Open Windows Defender Firewall.

  1. Test disabling it to see if this resolves your issue with PXE Booting. If it does then continue to add the Specific Ports into the Firewall Inbound Rules.
  2. Windows Defender Firewall

    Inbound / Outbound Rules

    Image may be NSFW.
    Clik here to view.
    WindowsFirewall.jpg
    Image may be NSFW.
    Clik here to view.
    WindowsFirewall1.jpg


  3. You can use the following document to reference Ports that LANDesk uses - Ports used by LANDESK Management Suite - Full List

  4. General TabAdvanced Settings

    UDP Ports 67, 68, 69, 1758, 1759 and 4011

    Image may be NSFW.
    Clik here to view.
    WindowsFirewall2.jpg
    Image may be NSFW.
    Clik here to view.
    WindowsFirewall4.jpg
    Image may be NSFW.
    Clik here to view.
    WindowsFirewall13.jpg

How to inject Inventory data during Provisioning or OSD

Description


To show how LANDESK can be used to recycle existing information from the LANDESK Database back into a newly re-imaged computer.

For this document, I chose to use the Windows "Description" inventory data, but the methodology could certainly be applied to any number of other useful pieces of Inventory data - the possibilities are endless!


Background


In a former environment, I used a VBScript for Device Name (NetBIOS/hostname) creation after OSD.  The PC naming convention is to use a 3-digit alpha code unique to each physical location, and the last six digits of the onboard Ethernet MAC address.  The alpha code is determined in VBScript by obtaining the IP address of the Ethernet adapter and matching the 2nd octet up to a string in a dictionary.

 

For example:

Arapahoe Ridge High School = ARH - network is 10.66.x.x - VBScript says if 2nd octet is 66 then device name will begin with ARH

Pioneer Elementary School = PIE - network is 10.67.x.x

Manhattan Middle School = MAM - network is 10.68.x.x

 

So device names end up being ARH3CF1BF, PIE789FAC, MAM82EF08, etc.

 

This naming convention is EXCELLENT when it comes to writing LANDESK scopes, queries, Active Directory automation, and custom scripts that must know the physical location of the computer.  This convention is TERRIBLE for actual identification of a single machine in the flock.

 

That is what Microsoft created the "Description" for, AKA the SRVCOMMENTvalue data in the HKLM\SYSTEM\CurrentControlSet\Lanmanserver\Parameters\ registry key.  Computers need a standardized network name that makes scripting easy, AND a Friendly-Name that is useful to us Humans.

Image may be NSFW.
Clik here to view.
desc.JPG
Image may be NSFW.
Clik here to view.
devdesc.JPG

 

When reimaging a whole lab like the BOH Library, it's time consuming to go around and re-describe each computer, especially when the description is the same as it was before.

 

_________________________________________________________________________________________________________________________________

 

HOW-TO for Provisioning (added September 13, 2011, tested on 9.0 SP2 and SP3)


Attached to this document is a Provisioning "Include" template for 9.0 SP2/SP3 - it greatly simplifies the Description injection over the Classic OSD method outlined in the next section.  It uses no INI or BAT files, requires no image modifications, and occurs in WinPE before an image ever boots up.

 

The Include template performs the following steps, and should be added to the Post-OS Installation phase at some point after the new OS image has been laid down to C: and the volume is writable:

 

Step 1 - Back up the SYSTEM registry hive to SYSTEM.BAK

Step 2 - REG.exe mounts the SYSTEM registry hive as OSDSYSTEM

Step 3 - REG.exe writes the new Description to the registry, using a Variable called "DeviceDescription" which references "Computer"."Description" from the DB

Step 4 - REG.exe unmounts the OSDSYSTEM registry hive.

 

That's it!  All you have to do is import the attached Include and include it in your Post-OS Installation phase of a Provisioning template.

 

 

HOW-TO for Classic OSD (tested on LDMS 8.8 SP3 and 9.0 SP2):

 

This is my old method for LANDESK 8.8 OSD and a Windows XP image, but it still works in LANDESK 9 and Windows 7.  Unlike the Provisioning Include method above, this process happens AFTER the image has been deployed, as part of the Sysprep routine.  It would be called during GuiRunOnce in WinXP, or during the Specialize phase as a RunSynchronousCommand in Win7.

 

Step 1 - In my \Drivers\Common\ directory that gets copied to each computer during my OSD driver injection routine (using CopyDrivers.exe), I created a DESCRIPTION.INI file.

 

               This file contains a single line with a variable called %DESC%

 

Step 2 - In my LANDESK OSD script, I added a line that runs:

 

TOKREPLW.EXE C:\DRIVERS\DESCRIPTION.INI DESC="%Computer - Description%"

 

               (NOTE:  Quotes around the LD database variable are critical since descriptions usually have spaces)

               This line reads the existing Description from the LD database and replaces the %DESC% variable in the INI file that lives on the freshly imaged drive

 

 

Step 3 - In my post-OSD batch file (called from GuiRunOnce) that runs after Windows Mini-Setup finishes and reboots, I added two lines:

 

SET /P DESCRIPTION=<C:\DRIVERS\DESCRIPTION.INI
REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters" /v srvcomment /t REG_SZ /d "%DESCRIPTION%" /f

 

               The first line uses SET /P to read the new string from DESCRIPTION.INI, set it as an environment variable

               The second line uses REG to write the string stored in the variable back to the Registry.

 

 

 

Voila!  Every time you reimage a computer, LANDESK can now recycle the current Description from the DB.

Happy LANDESKing everyone.

Image may be NSFW.
Clik here to view.

PXE Rep not Broadcasting - Can't PXE Boot

All-

 

I'm having some issues with PXE. The PXE rep, regardless of what elected client it is, is not broadcasting as a rep. Sometimes the appropriate services are running, sometimes they aren't and I restart them. Very very strange that this all of a sudden started happening in our environment (I'm not aware of any changes we have made). For about 2 months prior to this issue reappearing, PXE booting and imaging worked great.

 

The first time something like this happened, it resolved itself. When a client would boot and search for reps, it would find a rep but the elected rep would have a randomly generated IP on it's own subnet. This was due to our computers using Cisco Umbrella ODNS as a filtering and traffic monitoring solution. At some point between Cisco updating Umbrella endpoint software and the ivanti core being updated/upgraded to the most current version (2017.3 SU2), the PXE reps started functioning properly.

 

Some notable information:

ivanti 2017.3 SU2 running on Server 2016 Standard

Reps vary from desktop to laptop running Windows 7/Windows 10 version 1703 and 1709

All Dell Optiplex (7010, 5040, 7050) or Dell Latitude (E5480, E5470, E5450, E5440)

Verified Firewall ports are open and allowing traffic to the best of my abilities on both clients and network appliances

Made zero changes to the .wim boot file except update the background

I noticed the .wim images are not replicating with the updated image (followed the troubleshooting on the community with no avail)

Tried PXE reps with and without any security (all of our security products as well as none and dropping the firewall)

*I had noluck whatsoever finding the registry keys to change the score of a PXE rep so it was by happen-chance I was working with the right computers

 

Attached are all of the logs and information I could possibly think of. All help is welcome! I may end up opening a support ticket but thought I'd post on here first. If I remember any other details, I'll be sure to reply with them. Thanks!

 

-Jon

Image may be NSFW.
Clik here to view.

PXE Service is giving "Subnet Error"

Problem:

You will see an error under Self-Electing Subnet Services for the "Current State" which will show "Subnet Error"

Image may be NSFW.
Clik here to view.
Subnet_Error.jpg

 

To review the cause of this error you will need to go to the PXE Rep / Client that is running PXE Services and open the Registry. Navigate to the following key:

 

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

 

Registry Key on Client
HKLM|SOFTWARE|Wow6432Node|LANDesk|ManagementSuite|WinClient|CSEP
PXE Service "Subnet Error" (Boot.wim)PXE Service "Subnet Error" (NBI / Netboot Image)
Image may be NSFW.
Clik here to view.
Crip_Reason_Boot.wim.jpg
Image may be NSFW.
Clik here to view.
Crip_Reason_NetBoot.jpg

 

Log files to reference for Information about PXE:

Logs are located on the PXE Client - C:\ProgramData\LANDesk\Log\

PXESVC.Log

PXEMTFTP.Log

TMCSVC.Log

SelfElectController.Log

 

Sometimes its best to enable Xtrace logging to get more information from the logs - How to enable Xtrace Diagnostic Logging - https://community.ivanti.com/docs/DOC-32532

 

Resolution:

 

How to Fix issue with Boot.wim/Boot_x64.wim :

 

You will first want to make sure that the Boot.wim/Boot_x64.wim is copied to the PXE Rep in the following directory: C:\Program Files (x86)\LANDesk\PXE\System\images\Boot

Image may be NSFW.
Clik here to view.
PXE_Bootwim_Location_Agent.jpg

 

If the file is not located here we should review the PXE Logs to find out why the Boot.wim & Boot_x64.wim are not being copied over. You can also try to manually copy the files from the core server from \\%corename%\ldmain\landesk\vboot\

 

How to Fix issue with Netboot Image:

 

Navigate to OS Provisioning by going to Tools - Provisioning - OS Provisioning from your Console.

Click on "Preboot" drop down and select "Manage NetBoot Image Mappings"

 

Manage NetBoot Image MappingsMac NetBoot Image Mappings
Image may be NSFW.
Clik here to view.
Provisioning_ManageNetBoot.jpg
Image may be NSFW.
Clik here to view.
MAC_NetBoot_Image_Mappings.jpg

 

Browse to the location of your NBI (NetBoot Image file) and select it. Click Apply

Image may be NSFW.
Clik here to view.
Viewing all 1803 articles
Browse latest View live


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