Quantcast
Channel: Ivanti User Community : Document List - OS Deployment and Provisioning
Viewing all 639 articles
Browse latest View live

Provisioning: Patch System action not working correctly when repairing a group

$
0
0

Description:

LDMS 9.5 SP1

 

Provisioning: Patch System action not working correctly when repairing a group

 

Workaround:

Create an "execute file" action to execute vulscan.exe as in following document:

http://community.landesk.com/support/docs/DOC-30334

 

Resolution:

This will be resolved in Service Pack 2 for LDMS 9.5

 

Defect # 95026


UEFI boot with x86 Image

$
0
0

Hello,

 

we want to deploy x86 windows 7 Image on new HP devices with UEFI enabled bios.  Problem: with UEFI enabled, PXE automaticaly loads boot_x64.wim which is not able to install drivers in HII with DISM to x86 Images. I don't see any possibility to boot the x86 wim (boot.wim) on UEFI. I tried, to rename boot_x64 to boot.wim but get an error (winload.efi not available).

 

regards

Alex

 

 

 

The scenario doesn't work by design, as per Microsoft specifications:

 

http://technet.microsoft.com/en-us/library/hh290675%28v=ws.10%29.aspx

http://technet.microsoft.com/en-us/library/hh825186.aspx

WinPE hang due to port 38293 shutdown after selecting an OSD script from the Boot Menu

$
0
0

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

 

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"

 

 

Causes

 

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

Core can send UDP packages to client machine, and client machine can send UDP packages to core server too, The below screenshot is the correct screenshot, if UDP packages only can send from core to client, the client machine will be treated as off status:


port38293.png

 

 

 

Resolutions

 

Open UDP port 38293 between the Core Server and the client machine.

UEFI network boot PXE error: PXE-E21: Remote boot cancelled

$
0
0

Environment

 

LANDesk Provisioning
Target machine booting in UEFI mode

 

Problem/Issue/Symptoms

 

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

 

PXE-E21.png

 

Solution

 

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 machine is associated to a provisioning task on the core.


The error PXE-E21 appears when the machines not associated to a provisioning task on the core.

 

LANDesk submitted an enhancement request to the UEFI Forum regarding this issue. Once they add the support needed, LANDesk will be able to support the PXE menu for the devices booting vin 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 BIOS mode.

Best Known Method for using OSD with Mac OS X in 9.5

$
0
0

This document is intended to assist LANDesk® Management Suite users with the deployment of images to a Mac OS X device.

LANDesk Imaging Stops Working After Enabling FIPS 140-2.pdf

Troubleshooting LANDesk Provisioning

$
0
0

Troubleshooting LANDesk Provisioning

Troubleshooting - Core Side

View histories for failures or error messages

View provisioning.log located in
CoreServer\ldlogon\provisioning folder for template execution messages

View PXE Rep deployment and prov_schedule log files in the
CoreServer\ldmain\log folder

 

Troubleshooting – Target Machine

 

WinPE

 

 

 

View the launch.log in X:\ldprovision folder for provisioning loading status

View ldProvision.log in X:\ldprovision folder for error messages and XML content

View Output.txt in c:\ldprovision folder for application error messages only if app hangs

 

LinuxPE

 

 

 

Use Alt + F2 to toggle to command prompt

View /var/log/messages for errors loading LinuxPE

View /var/log/taskmaster.log for errors load provisioning

View /var/log/provisioning.log for template errors and XML content

Windows Target device

View ldProvision.log in WinDir\Temp folder for error messages and XML content

View run##.tmp in WinDir\Temp folder for template execution messages

Linux Target device

View ldProvision.log in /tmp folder

 

Troubleshooting – PE Manual Execution

Load new console in PE and change to ldprovision folder X:\ldprovision – PXE, Z:\ldprovision – Boot Media

Launch provisioning by executing ldprovision.exe

ldProvision command-line options:

 

-c[corename] or IP

-d debug (Note: no space should be used after -c and the core server name)

-f task XML file name

-h help

-m mode 1-3 (1=default)

-t download directory

-s run as daemon (Linux only)

-v version (NOTE: This is lower case v)

-V # (1-255) Verbose logging (NOTE: This is capital V)

 

Example: ldprovision –c mycore –t x:\ldclient -V 255     

 

Troubleshooting – OS Manual Execution

 

Windows OS

Using target that has ld agent installed, map drive to or copy contents of
CoreServer\ldlogon\provisioning\windows from core to local folder

Execute ldprovision as shown in PE manual execution, note log files are placed in windir\temp

 

Linux OS

Using target that has ld agent installed, mount point to or copy contents of
CoreServer\ldlogon\provisioning\linux from core to local /tmp folder

Execute ldprovision as shown in PE manual execution, note log files are placed in var/log---

Modifying the free space in WinPE - LDMS 9 and LDMS 95

$
0
0

In LANDesk Managment Suite 8.8, there was a button in the OSD tool that allowed you to manage the free space in the WinPE image. However, in LANDesk Management Suite 9 and 9.5, no such button exists. Because of the change to WinPE 2.1 and the associated change to a .wim file, this task must be accomplished another way. The steps below are dependant on the OS running on the machine where you are editing the boot.wim, for simplicity's sake it is best to modify the boot.wim on a device with Windows 7, Server 2008 R2, or later, and then copy it back to the core if needed.

 

Important Note: Any increase in size of the free space inside the WinPE image requires that the corresponding space be available in RAM on the client machine. For example, a machine with only 512MB RAM WILL NOT load a WinPE image that is set to use 512MB of scratch space. The total space needed is approximately 365 MB plus free space. In WinPE Scratch Space can be set to 32, 64, 128, 256, or 512 MB.
Windows 7\Server 2008 R2 or Later Method:
  1. Create the following folder structure C:\Mount\Bootwim
  2. Copy \Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\boot.wim to the C:\Mount\ folder.
  3. Open a CMD prompt as an Administrator.
  4. Use DISM to mount the boot.wim:
    1. DISM /Mount-Wim /WimFile:C:\Mount\Boot.wim /index:1 /MountDir:C:\mount\bootwim
  5. Use DISM to increase the Scratch Space (This example increases it by 256MB):
    1. DISM /image:C:\mount\bootwim /Set-ScratchSpace:256
  6. Use DISM to commit the change, and unmount the image:
    1. DISM /Unmount-Wim /MountDir:C:\mount\bootwim\ /Commit
  7. Copy the modified boot.wim from C:\Mount\boot.wim to \Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\boot.wim.
  8. Update the PXE representatives. You can use the script from this article: Updating the WinPE image on PXE representatives
Windows XP\Server 2003 Method:
What you need:

A machine with Windows AIK installed

Access to \\<CORE>\ldmain\files\vboot\boot.wim

 

Note: This process involves modifying the boot.wim, or the WinPE image. For more information about mounting and editing the boot.wim or WinPE image please see: How to manually modify the boot.wim WinPE image in LDMS 9

 

What to do (Overview)

To increase the free space, or scratch space as it is called, you need to mount the boot.wim image, open the registry and modify the following key:

HKLM\SYSTEM\ControlSet001\Services\FBWF\WinPECacheThreashold (REG_DWORD) and set it to the desired number. Acceptable values are 32 (default for WinPE <=4), 64, 128, 256 and 512. Then commit the changes to the WinPE image and update the PXE reps with the new image.

 

What to do (Step-by-step)

 

  • Open a command prompt on the machine that has Windows A IK installed
  • Create a new folder on the root of C: named mount (C:\mount)
  • Navigate to the folder containing imagew. In my case it was in C:\Program Files\Windows AIK\Tools\x86.
  • Run: imagex.exe /mountrw "<Path to boot.wim>\boot.wim" 1 c:\mount
  • Run: regedit.exe
  • Inside regedit, select the HKEY_LOCAL_MACHINE hive, then select "Load hive"
  • Navigate to C:\mount\Windows\System32\config and select the file SYSTEM. See graphic below. (Note: DO NOT select the SYSTEM txt file or the SYSTEM.SAV file)

 

Regedit - Mount Hive.png

 

  • Enter a name to reference the freshly loaded hive. For example, WinPE
  • Navigate through the hive to \ControlSet001\Services\FBWF\WinPECacheThreshold
  • Create a new REG_DWORD value named WinPECacheThreshold
  • Set the new REG_DWORD to the value desired. Allowed values are 32 (default), 64, 128, 256, 512. (20, 40, 80, 100, 200 in hex)

 

Add Reg_Dword.png

  • Once the value is set, select the key that you loaded the hive into, for example WinPE and then select File -> Unload hive. Close regedit
  • Run the following at the command prompt to commit the changes to the WinPE image: imagex.exe /unmount /commit c:\mount
  • Update the PXE representatives. You can use the script from this article: Updating the WinPE image on PXE representatives

 

Once this is done, you can reboot any clients back into WinPE and you should see the corresponding increase in free space.

 

Important Note: Any increase in size of the free space inside the WinPE image requires that the corresponding space be available in RAM on the client machine. For example, a machine with only 512MB RAM WILL NOT load a WinPE image that is set to use 512MB of scratch space. The total space needed is approximately 365 MB plus free space.

How to create image capture script based partitions

$
0
0

Create image capture script

 

 

a. Open the LDMS console. Click Tools > Distribution >OS Deployment

OSD1.PNG

b. Right click on All OSD/Profile Migration Scripts and select a new script based on the imaging environment you will use.

OSD2.PNG

c. Select capture image. Give the script a name and a description.

OSD3.PNG

d. Specify the credentials to be used

OSD4.PNG

e. Specify the image information. If you will use LANDesk's imaging tools, choose LANDesk ImageW V2 for the Image type. Enter the UNC path where you will capture the image. For the path to the imaging application, use \\coreservername\ldmain\osd\imagew 2

Replace "coreservername" with the name of your core server. Replace "imagingtool" with imagew.exe (for Windows PE) or image.exe (for DOS).

OSD5.PNG

f. Right click on the OSD script and click advance edit

OSD8.PNG

 

g. Click Use editor button

OSD9.PNG

h. Copy and paste this line, and modify OSD script as below:

OSD10.PNG

 

i. If using the PXE Boot Menu, it is necessary to drag the script from the scripts folder to the PXE Boot Menu folder under the PXE Boot Menu section. This places the script in the bootmenu.cfg file.

NOTE: for LANDesk 8.8 and newer, it is adviced that you use the "Image Type" of "LANDesk ImageW V2", this will require the path to be altered for the image application in the last line of the script to reflect the correct path.  For version 9, it is "\\Coreservername\ldmain\osd\imagew 2\imagew.exe"

 

OSD6.PNG

OSD7.PNG

 

To open this screen select Tools | Distribution | PXE Boot Menu. Once this screen is open, drag the script to the PXE Boot Menu folder. After the script is copied to the PXE Boot Menu, click the Update button which refreshes the bootmenu.cfg file stored on the core.

Provisioning Task failing after try 40 of 40

$
0
0

Problem

The provisioning task is failing to load. It will attempt to load the template and retry for 40 attempts and then the job hangs and the PC stays in the WinPE screen or brings back the template section window.

 

Logs on the core may indicate a few different errors:

In prov_schedule.exe.log:

     In LDMS 8.8 this log is at \\core\ldmain\ in LDMS 9 it will be at \\core\ldmain\log

Template is not flattened, will attempt to flatten.
Flattening  template failed.

In provisioning.log:

     In LDMS 8.8 and LDMS 9 this log is at \\core\ldmain\log\provisioning. It may be necessary to enable additional logging.

 

 

Unable to find the history task

or

Unable to find template for computer idn ###

Causes and Resolutions

 

First, make sure that the latest service pack and the latest miniroll-up are applied to the core.

 

Scheduler service being stopped
  • If the scheduler service is not running, provisioning jobs will not start.
  • DCOM errors can causing the scheduler service to stop.

Resolution

  • Change the service to run as a domain admin and started the  scheduler service. Once this is done, the provisioning task should work.
  • Reset the password for the admin account that was running the LANDesk and LANDesk1 COM+ objects. This prevents the scheduler service from failing which prevents the provisioning template from running.
Current Provisiong Task in Progress on Selected Machine
  • If a provisioning task has already been assigned to the machine in question, the task will fail. If you review the provision.log file on the core you will see a line "Computer is Busy with another task {taskID}"

Resolution:

  1. Determine the TaskID from the log, Go to your Core and delete that task.
  2. Delete client from database
  3. PXE boot client, or run a manual inventory scan from the device
    1. A Manual scan can be initiated from WinPE by running X:/Windows/System32/Startnet.cmd from a command prompt
  4. Run the provisioning task
    Corrupt Template
    • A corrupt template can prevent correct scheduling. One cause if this is if a template is imported, the drop down boxes are not filled in as they were pointing to objects from the previous core. For example, Software Distribution actions do not have a package specified. Same with Configure Agent actions. Also any actions with scripts will have this issue.
    • Another way to determine if your template is not configured properly is by reviewing the Provisioning.log on the core. If you see the following:
    INFO    PROV_SCHEDULE        8/18/2011 5:06:50 PM     : Action LANDesk.Provisioning.Business.PAction_Distribute_software
    INFO    PROV_SCHEDULE        8/18/2011 5:06:50 PM     : Got package ID 60, requesting snippet
    INFO    PROV_SCHEDULE        8/18/2011 5:06:50 PM     : Requesting snippet for packageId 60
    INFO    PROV_SCHEDULE        8/18/2011 5:06:50 PM     : Requesting SWD snippet with task IDN 2214, package ID 60
    ERROR    PROV_SCHEDULE        8/18/2011 5:06:50 PM     : Exception encountered trying to get snippet (LANDesk.ManagementSuite.SoftwareDistribution.Business.PackageNotFoundException): This package has been deleted.
    ERROR    PROV_SCHEDULE        8/18/2011 5:06:50 PM     : GetSoftwareSnippet failed

       

      Resolution:

      • Recreate the template, or make sure that all dropdown boxes and options are configured in the template and all included templates.
      • If you are getting the error where you are unable to get the Software Snippet, you will need to go into your Provisioning Template and make sure that all software packages are available and working. Determine which package is failing and resolve the software package. Save your template and retry the provisioning task.

       

      Template is trying to perform an invalid action
      • Error when attempting to save template
      • Cannot save changes to the template . Verify that the template name you have chosen is not already used by another template. Database Error.

        Resolution:

        • If you are adding included templates to a main template you will want to start with adding the included templates one at a time until you find the problem template. Then address the specific of that template and what it is doing. Try to recreate a new template that duplicates the problem template and see if you get any errors while saving the template.
        • Here is a situation that a customer came across.
        • The problem template was one to Update Registry action item and the Registry Operation of Import File. Because the file that was being imported was a combination of different registry export files, and remarked out descriptions had been added to the file, the template would return error: "Cannot save changes to the template . Verify that the template name you have chosen is not already used by another template. Database Error." The initial problem came from the fact that the original template did save when maybe it should not have, which caused the provisioning task to fail and the Prov_Schedule.exe.log file to show "Flattening template failed". Once we isolated the issues with the remarked out lines in the reg file and removed them, the template saved and the provisioning task worked properly.
          The real resolution came after adding the included templates to the main template one at a time until we found the problem template. The problem template was one to Update Registry action item and the Registry Operation of Import File. Because the file that was being imported was a combination of different registry export files, and remarked out items had been entered, the template would return error: "Cannot save changes to the template. Verify that the template name you have chosen is not already used by another template. Database Error." The initial problem came from the fact that the original template did save when it should not have, which caused the provisioning task to fail and the Prov_Schedule.exe.log file to show "Flattening template failed". Once we isolated the issues with the remarked out lines in the reg file and removed them, the template saved and the provisioning task worked properly.
          In my customers environment, having the remarked out comments failed, but in my lab the customers reg file worked fine. After getting the reg file to import and save, we found that the script failed on the reg file when trying to run the reg file. What we discovered is that in his situation, the header in the reg file that says: "Windows Registry Editor Version 5.0" was causing it to fail, but I was unable to duplicate any of his problems in my lab. This seems to be a unique situation and may or may not apply to other customers that are having the 40 of 40 retries issue.

         

        LANDesk is trying to find a provisioning task from a failed distribution
        • The provisioning log will show  "Unable to find the history task"

        Resolution:

      1. Delete client from database
      2. PXE boot client, or run a manual inventory scan from the device
      3. Run the provisioning task

       

      To many PXE Reps to update with the Provisioning information for the device
      • If there are a large number of PXE representatives in the environment, this error will occur as the core tries to update them all with the needed information. If it cannot complete in time for the 40 retries, the task will not start. However, if you keep waiting the template may start.

      Resolution:

      • Reduce the number of PXE reps and remove all PXE Reps that are not active.

       

      How to Troubleshoot WinPE hanging after selecting an OSD script from the Boot Menu.

      $
      0
      0

      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.

       

      A visual representation of this process is attached as a flowchart below:

       

      Step 1 - 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:

       

      10-10-2013 12-26-25 PM.jpg

       

      • 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:

       

      PXEasmx.bmp

       

       

      • 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:

       

       

       

       

      ObjID.bmp

       

      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:

       

      For 8.7 Core

      "C:\Windows or WINNT\Microsoft.NET\Framework\v1.1.4322\aspnet_regiis.exe -i"

      For 8.8 Core

      "C:\Windows\Microsoft.NET\Framwork\V2.2.50727\aspnet_regiis.exe -i"

       

      • Enable the OSD Web Tracing by doing the following:

       

      1. Edit the web.config file in C:\ProgramFiles\LANDesk\LANDesk\ManagementSuite\LANDesk\ManagementSuite\Core\Core.WebServices so that the line "<trace enabled="false"" reads "<trace enabled="true"" and restart the WWW Publishing service.

      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. (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 port 9595 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

      Unable to add devices to the bare metal server view.

      $
      0
      0

      The first thing to check when this happens is to look at the Inventory Server Service to make sure that it is running.  Any entry in the console for Bare Metal devices will need the Inventory Service running in order to insert the device into the database.

       

      - If the Inventory Service is in a state of "Starting", then there is a problem and the core may need to be rebooted to resolve.  If this does not resolve the problem with the Inventory Service starting, there may be an issue with the database or with connectivity to the database.

       

       

      Possible workaround if the Inventory Service is running:

      You can run barescan.exe from the managementsuite directory.

      barescan.exe -v name=test mac=123456789aac

       

      When using the command line method for testing if the following error was displayed:

      unable to create ScanDirEmitter connection to core server:"CORE SERVER NAME"

       

      Resolution:

       

      • To resolve this issue the following steps were taken:
        Needed to add the non LDMS Administrator account to the LDSCAN folder with the following Security permissions
        Modify, Read & Execute, List Folder Contents, Read, Write

       

      • Determine what is causing the Inventory Service to not start.  (You may need to contact the Inventory Support Team to resolve)
        Once the Inventory Service will start the Bare Metal devices will show up in the database.

      How to turn on logging for the LANDesk PXE service.

      $
      0
      0

      Issue:

      How to turn on logging to get a PXEMTFTP.LOG file for troubleshooting the PXE representative.

       

      Solution:

      There is a registry key “PxeMtftp_DebugOutToFile_On” under HKLM\Software\INTEL\PXE on the PXE representative.
      Change the value data to 1, then the restart LANDesk(R) PXE MTFTP Service on the PXE machine.
      The Log file pxemtftp.log can be found in c:\program files\LANDesk\PXE\System.
      On a 64bit Machine it will be under HKLM\Software\Wow6432Node\Intel\PXE

      Troubleshooting 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 core logs are found at ManagementSuite\logs\prov_schedule.exe.log and ManagementSuite\logs\provisioning\provisioning.log.

       

      Client Logs

      Device logs can be found either at x:\ldprovision or at systemdrive:\windows\temp.


      Understanding Action Handler Flow (Client)

      Each action that is run in a provisioning template is done by an action handler. A 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 MaptoPreferred action handler. Finally it will complete its own job of deploying the image using itself. The launch of each of the addition 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) 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 additonal 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 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
      Replace TextReplaceTextHandler.log
      Scripted InstallClientActionHandler.log
      Uninstall ServiceServiceRemoveHandler.log
      Unzip FileUnzipHandler.log
      Update RegistryRegUpdateHandler.log
      WaitWaitHandler.log

      CTOS action fails after reboot

      $
      0
      0

      Environment:

      LDMS 90, SPx

      LDMS 95 , SPx

       

      Description:

      You are experiencing an issue with provisioning whereby the devices get to the CTOS action, they reboot into Windows ok but provisioning fails to continue.

       

      Provisioning.log would show the following:

      /Provisioning/windows/ProvisionGUI.exe)

      2013-11-12 14:15:12(1300-1876) ldProvision.exe:Process exit code:2

      2013-11-12 14:15:12(1300-1876) ldProvision.exe:Create process (C:\Program Files (x86)\LANDesk\Shared Files\httpclient.exe) with args (  -f "C:\ldprovisioning\provcomm.dll" http://LDMS/LdLogon/Provisioning/windows/provcomm.dll)

      2013-11-12 14:15:33(1300-1876) ldProvision.exe:Process exit code:2

      2013-11-12 14:15:33(1300-1876) ldProvision.exe:download prerequisite files OK

      2013-11-12 14:15:33(1300-1876) ldProvision.exe:Unable to load action configuration file; using default action configuration

      2013-11-12 14:15:33(1300-1876) ldProvision.exe:Running in Daemon mode.

      2013-11-12 14:15:33(1300-1876) ldProvision.exe:Provision Mode = PROVISION_MODE_CORE_SID

      2013-11-12 14:15:48(1300-1876) ldProvision.exe:Start TryallWebService Attempt:0.

      2013-11-12 14:16:09(1300-1876) ldProvision.exe:End TryallWebService Attempt:0. ExitCode:2

      2013-11-12 14:16:21(1300-1876) ldProvision.exe:Start TryallWebService Attempt:1.

      2013-11-12 14:16:43(1300-1876) ldProvision.exe:End TryallWebService Attempt:1. ExitCode:2

      2013-11-12 14:16:56(1300-1876) ldProvision.exe:Start TryallWebService Attempt:2.

      2013-11-12 14:17:17(1300-1876) ldProvision.exe:End TryallWebService Attempt:2. ExitCode:2

      2013-11-12 14:17:31(1300-1876) ldProvision.exe:Failed to call web service. exitCode=2

      2013-11-12 14:17:31(1300-1876) ldProvision.exe:Caught exception in main: code=80001500H, file=.\ProvisioningWebSvc.cpp, line=933

       

      Cause:

      httpclient is not able to resolve the Core name

       

      Resolution:

       

      Edit the boot.wim file and look for file corename.txt (should be in \temp folder).

      Edit that file and replace the hostname by FQDN

      Commit the change and try again.


      Provisioning Action fails

      $
      0
      0

      Description:

      Customer is trying the run Vulscan in a provisioning template using Executer file action

      Customer is using the following parameters he saw in a custom script:

      /repair "group=LDMS950-FR_v418" /maintEnable=false /AgentBehavior=LDMS950-FR_v1003

      vulscan1.PNG

      vulscan2.PNG

       

      Issue:

      The action fails with the follwoing error "PATH NOT FOUND"

      vulscan3.PNG

       

      Resolution:

      Removed quotation marks in the command line around group to make it

      /repair group=LDMS950-FR_v418 /maintEnable=false /AgentBehavior=LDMS950-FR_v1003

       

      IT IS FIXED IN 9.5 SP2

      WINPE Menu option does not work on new computers or new BIOSes.

      $
      0
      0

      Problem:

      Selecting the WINPE Menu option in the F8 menu fails with a MTFTP timeout error.

      Selecting the WINPE Menu option in the F8 menu is stuck at Boot Server IP and never loads WINPE.

      Selecting the Managed WINPE option in the F8 menu fails with a MTFTP timeout error.

      Selecting the WINPE Provisioning option in the F8 menu works.

       

      Cause:

      New BIOSes have broken the tftp multicast option that WINPE Menu and Managed WINPE options use.

       

      Solution:

       

      Obtain the latest BIOS update from your hardware vendor.  

       

      As an example, Lenovo has released Bios Version 2.59 for various models that fixes this issue. 

      (See http://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/g1uj27uc.txt)

       

      If your vendor does not yet have the latest Intel remote boot update within their bios, contact them and request that they update the BIOS to include this.

       

      This was a defect introduced in newer versions of BIOS and should be remedied by the hardware vendor.

       

      An alternative is to back-rev the  BIOS to an earlier version prior to when this defect was introduced, however this should be done with caution.

       

      The issues lies with the MTFTP (Multicast TFTP) portion of the remote boot agent.   As a workaround, the usage of MTFTP within the LANDesk PXE Representative can be disabled:

       

      In order to do this:

       

      1. Set the following registry key to 0 on all PXE reps:

      32-bit OS on PXE rep:

      HKLM\SOFTWARE\Intel\PXE\Mtftpd\MCAST_ENABLE


      64-bit OS on PXE rep:

      HKLM\SOFTWARE\Wow6432Node\Intel\PXE\Mtftpd\MCAST_ENABLE

       

      2. Restart the LANDesk PXE and LANDesk PXE MTFTP services on the PXE representative.

      Provisioning template with at least one distribution action fails to start.

      $
      0
      0

      Issue:

      Removing the distribution action(s) from the template resolves the issue.

      Provisioning template fails almost immediately when started.

       

      Cause:

      Push Delivery Method was selected which is not allowed with provisioning templates.

       

      Solution:

      Select a Policy or Policy-Supported Push Delivery Method when running or creating provisioning template tasks.

      Deploy OS using OSD Deployment Script Menu by USB insteading of PXE server

      $
      0
      0

      The background of this project

      Because there is no DHCP in LV reseller, and the network is limitted less than 100M, Most of the files need to put in local Usb drive in advance, if needed, deployment os will access these files from local Usb drive, not download these files from core server.

       

      The request from LV reseller

      Boot client machine into WinPE through Usb drive insteading of Pxe Rep
      Provide OSD deployment script menu
      Provide UI to input the static IP address and mask, gateway to setup network in WinPE
      Add driver
      Provide UI to select different location to rename the computername by this section
      Add the client machine into LVMH AD automatically
      Can deploy agent to client machine, and install antivirus program and active the Operating System.

       

      LV门店没有DHCP,只能通过窄带跟核心服务器通讯,因此需要把image等超过100M的文件都放到本地U盘,部署操作洗头膏时用到这些文件都从本地读取,LV门店的需求如下:

      *U盘启动门店终端
      *进入landesk pe
      *提供界面手工输入IP地址
      *选择部署脚本
      *开始进行系统部署
      *加载驱动程序
      *重启后再次提供UI界面人工输入IP地址
      *提供UI,选择国家和地区(根据国家选择,决定机器名前缀 如CN-)
      *自动加入LVMH AD
      *自动部署landesk客户端,卡巴防病毒,激活win7系统

       

      Configuration steps:

       

      1. Create bootable USB drive:
      1.1 Login Win Console to create bootable USB drive,please refer to following screenshot:usb.png
      1.2 Update boot.wim:
        Copy boot.wim to local drive ,for example d:\lv,Use the following command to extract boot.wim:
        dism /mount-wim /wimfile:d:\lv\boot.wim /index:1 /mountdir:d:\lv\mount
        1.2.1 Replace d:\lv\mount \windows\system32\startnet.cmd
        1.2.2 Copy netsh.hta to d:\lv\mount
        1.2.3 shutdown all the folder and program which accessed mount folder, Use the following command to repackage boot.wim:
        dism /unmount-wim /mountdir:d:\lv\mount /commit
      1.3 Copy the following files to U drive:
        1.3.1 Copy boot.wim to u drive’s boot folder             
        1.3.2 Copy netsh.hta to u drive’s root folder
        1.3.3 Copy image file to u drive’s root folder
        1.3.4 Copy the following files to U drive’s root folder:
         AssignDrvC.txt

         …..

         AssignDrvH.txt
        
      2.    Configure OSD Script
      2.1 Create OSD Script, Delete the following command:
        diskpart /s X:\LDClient\rmvol.txt
      2.2.Modify the following command to rename the computer name
        REMEXEC39=ldrun tokreplw C:\unattend.xml COMPUTERNAME=%Location%%System - Serial Number%
        REMEXEC40=ldrun x:\Location.bat
      2.3 Modify the following command to update the location of image files’ s location:
        REMEXEC25=ldrun h:\IMAGE_~2\LD9.5\imagew.exe /r /o /d:0 /f:"""z:\WIN7_X~1.TBI""" /rb:0
      2.4 Configure the IP address for the Operation system:
        REMEXEC46=cmd /c xcopy /y /e x:\netshOS.bat C:\
      2.5 The other thing need to do is configuring xml file:
        you can find the location to configure this commander here:
        Pre-boot commands-> Enter ‘RunOnce’ commands……
        After configure successfully, we need to adjust this command to the first one, It will be the last one by default:
           <FirstLogonCommands>
          <SynchronousCommand>
            <CommandLine>c:\netshOS.bat</CommandLine>
            <Description></Description>
            <Order>1</Order>
          </SynchronousCommand>

       

      3. Deployment on the client machine:
      3.1 Configure the BIOS settings:
        Boot from Usb drive
      3.2 Boot the client machine from Usb drive
        Client machine will boot into WinPE through Usb drive, Please input IP address and mask and Gateway etc, please refer to the following screenshot:IP.PNG
      3.3 After the OSD Deployment Script Menu pop up, Please choose the related OSD script to run, if it execute successfully, the operation system can be deployed to client machine successfully.

      Troubleshooting Configure Target OS action in Provisioning template

      $
      0
      0

      One of the most common uses of Provisioning is to extend the capacities and functions of imaging or new machine deployments to include the installation of the OS as well as a number of configuration settings and software installations. In order to bridge the gap between WinPE and the new OS LANDesk uses a process called Configure Target OS. This is a separate action that needs to be added to the template for a template that installs an image, and is included as part of the Scripted Install action. This article covers the function and troubleshooting of the Configure Target OS action

       

      Configure Target OS overview

      The Configure Target OS (CTOS) action is available only in the Post-OS installation section of the provisioning template. It needs to be the final action in the template before the System Configuration section. No actions can come after the CTOS. The CTOS prepares the machine to resume provisioning after the client boots into the target OS, then restarts the machine, leaving WinPE and allowing the computer to boot normally. In order for the CTOS action to work, the image that was deployed to the client MUST be sysprepped.

       

      The Configure Target OS takes advantage of a few Microsoft technologies in order to resume when the machine completes booting into the target OS (Windows XP, 2003, Vista, 2008, 7). Files are injected to the root of the OS drive (C:\ldprovision) and commands are added to the appropriate files such that they are run during the mini-setup just prior to booting into the target OS.

       

      Windows XP/2003

      1. All needed files are copied to C:\sysprep\i386\ldprovision directory on the client machine. The C:\sysprep\i386 directory must exist and be accessible.

          Note: Sysprep is responsible for creating the i386 folder.  If the folder is not getting created, you can get around the issue by creating a new action in the script, putting the action in front of the CTOS action, that creates this folder.  If this folder does not exist it will cause the failure of any additional action after CTOS runs and reboots the client.

      2. The cmdlines.txt file in the OEM folder on the client machine is created or modified. A line is added to call ldprovisioning.cmd. Windows will run cmdlines.txt at the end of the mini-setup, calling ldprovisioning.cmd.

       

      Windows Vista/2008/7

      1. All needed files are copied to C:\ldprovisioning directory on the client machine
      2. The unattend.xml is modified and commands are added to call ldprovisioning.cmd from the C:\ldprovisioning directory

       

      LDProvision.cmd

      When run, ldprovisioning.cmd installs the basic LANDesk CBA agent in C:\Program Files\LANDesk\LDClient and configures it as a service to start on OS boot. It also modifies the actions.ini file in C:\Program Files\LANDesk\Shared Files\cbaroot to contain a line pointing to C:\ldprovision\ldprovision.exe with the needed command line options. The actions.ini file is used by the LANDesk CBA agent as instructions when starting, so the commands contained therein are run when the service starts

       

      Troubleshooting Configure Target OS

      Troubleshooting the CTOS action can be especially difficult. Because of the nature of the operation and how it works, LANDesk must give up control to the Windows installation processes for a time, and then resume afterwards. This can sometime make it difficult to determine where the problem is occuring. The problem can be in WinPE trying to copy and modify files, it can be somewhere in the mini-setup of the OS, and it can be after the OS has completed all setup tasks and has fully booted.

       

      The first step to troubleshoot the CTOS action is to determine where in the process the failure is occuring. The CTOS action will not always get marked as failed. Often provisioning just fails to continue through the rest of the template.

       

      WinPE

      This is where it is most likely to see an actual failure of the template. Usually this means something could not be copied correctly or modified. The machine will stay in WinPE after the template fails so troubleshooting can be done in the exact condition the machine is in when it fails.

      1. Open a new console in WinPE.
      2. Check to make sure that the C: drive is accessible.
      3. Change to the C: drive and look around. Does it look like the image was put down correctly?

      If you deployed:

           Windows XP

        1. Change to C:\sysprep directory. Verify that the I386 directory exists. Look to see if the ldprovision folder was created and populated

            Note: Sysprep is responsible for creating the i386 folder.  If the folder is not getting created, you can get around the issue by creating a new action in the script, putting the action in front of the CTOS action, that creates this folder.  If this folder does not exist it will cause the failure of any additional action after CTOS runs and reboots the client.  This also prevents the $OEM$ directory from being created in the i386 folder.

        2. Check the cmdlines.txt in C:\sysprep\$OEM$\ and make sure it contains a line for ldprovisioning.cmd
        3. Verify that ldprovisioning.cmd is in C:\sysprep\$OEM$\

           Windows Vista/2008/7

        1. Change to C:\ldprovisioning directory. Verify the ldprovisioning.cmd is in the folder and the folder is populated. It should contain over 20 files.
        2. Verify that the unattend.xml exists in C:\Windows\Panther
        3. Verify that the commands calling ldprovisioning.cmd exist in the unattend.xml for the platform (x86, amd64, ia64) you have deployed.

       

      Sometimes all of these will be correct and ready to go, but the machine will remain in WinPE. Usually there is not a failure of the task. It is possible that the reboot command didn't run correctly but everything else did. To verify this, simply restart the client and observe the results.

       

      Between WinPE and Windows

      After the client reboots out of WinPE it will boot off the hard drive into the target OS. Because the image was sysprepped, it will go through a mini-setup process. If no sysprep file was provided, it will prompt for a number of items such as the computer name, user names, time zone, product key etc. before completing the booting process into the target OS. LANDesk has no control over this process and is not running at all. Near the end of the mini-setup process Windows executes the commands that LANDesk added during the CTOS action. For Windows XP and 2003 the mini setup executes the commands in the cmdlines.txt at then end of the sysprep steps. For Windows Vista, 2008 and 7 the commands are exeucted during the Specialize pass in the unattend.

       

      Windows XP/2003

      The important file here is the cmdlines.txt This file should contain the call to ldprovisioning.cmd. It is here that LANDesk is again introduced into the process. When cmdlines.txt is executed it runs ldprovisioning.cmd from the same directory, which prepares the machine to resume provisioning after the whole mini-setup process is complete.

       

      Windows Vista, 2008 and 7

      Sections are added to the unattend.xml in the Specialize section. This is a special section of the unattend.xml that can also be used for things like setting the home page for Internet Explorer, etc. In this section, RunSynchronousCommand action is added calling ldprovisioning.cmd from C:\ldprovisioning\. The section of the unattend will look roughy like the following:

      <settings pass="specialize" xmlns="" wasPassProcessed="true">
          <component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
              <RunSynchronous>
                  <RunSynchronousCommand action="add">
                      <Description>LANDesk Provisioning Install</Description>
                      <Order>1</Order>
                      <Path>cmd /c %systemdrive%\ldprovisioning\ldprovisioning.cmd</Path>
                  </RunSynchronousCommand>
              </RunSynchronous>
          </component>
      </settings>

       

      In Windows

      Once the machine completes the mini-setup section, it will boot into the final OS. As the machine boots up, it runs the LANDesk Management Agent service that was installed by ldprovisioning.cmd. As part of the startup process, the LANDesk Management Agent will run the commands in the actions.ini file. The actions.ini file was also modified by ldprovisioning.cmd to contain the following command

       

      C:\ldprovisioning\ldprovision.exe -c <CORE>

       

      Troubleshooting Tip: If you would like to get extra logging for problems you are seeing later in the template, open this file BEFORE the machines competes the boot after the mini-setup and change it to the following:

       

      C:\ldprovisioning\ldprovision.exe -c <CORE> -V 255 -L C:\<LOG FILE>

       

             Note: the -V is a captial V and is case sensitive

       

      Once ldprovision.exe starts, it queries the core server for the next action in the template, and provisioning will continue with the actions in the System Configuration section

      Viewing all 639 articles
      Browse latest View live


      Latest Images

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