This is a follow-up on document http://community.landesk.com/support/docs/DOC-28279. As indicated in that document, options 66 and 67 in the DHCP Scope Options should not be used. However... what if this really really really is your only option?
DHCP Scope Options and WinPE
As described in the document referenced above, after the client receives the PXE answer it needs to go to the next step, which is to download a boot environment. This is where DHCP options 66 and 67 come in. Option 66 tells the PXE booted client what the Bootserver is and option 67 the Bootfile that needs to be loaded.
This removes all flexibility of the LANDesk PXE menu, as we can only download the WinPE boot file, without the variable (WinPE menu/Managed WinPE/Provisioning) passed on by PXE booting.
So, how do we handle this...
First let's set the DHCP Scope options.
Option 66 is pretty self-explanatory, this is the bootserver aka the server that hosts your PXE representative (basically, the host of the TFTP server). Use the IP address of the PXE representative here.
Option 67 is the relative path to the bootfile, in case of the LANDesk PXE representative this is x86pc\undi\provwin\startrom.0 The path is relative to the root of the TFTP server. You can basically reference any of the startrom.0 paths under the UNDI path.
This will boot WinPE on the device that PXE boots. You can reference any of the startrom.0 files because the startnet.cmd in the boot.wim WinPE file won't receive the code generated by PXE menu boot that tells it to go into Provisioning/WinPE menu or Managed WinPE mode. The result is a running WinPE, without any OSD menu/provisioning menu.
If we want to use Provisioning or automatically load the OSD menu, we need to edit the startnet.cmd in the boot.wim file. To do this, mount the boot.wim file in the Program Files (x86)LANDesk\Managementsuite\landesk\vboot map on the Core Server. Open the startmenu.cmd in the \windows\system32 map in the mounted wim file. Find the following lines:
set /a option = %errorlevel%
@rem option refer to boot option: @rem -2 means in provisioning vboot (not in winpe2.0) @rem -1 means not in winpe2.0 @rem 1 means pxemenu @rem 2 means managed pxeboot @rem 3 means provisioning winpe
Replace the %errorlevel% in the first line by the number matching the startup type you need, for example, provisioning = 3:
REM ------CHANGES NEEDED FOR DHCP SCOPE OPTION 67----
REM set /a option = %errorlevel%
set /a option = 3
@rem option refer to boot option: @rem -2 means in provisioning vboot (not in winpe2.0) @rem -1 means not in winpe2.0 @rem 1 means pxemenu @rem 2 means managed pxeboot @rem 3 means provisioning winpe
REM ------END OF CHANGES---
Save the startnet.cmd file and unmount the boot.wim file, committing the changes.
Re-deploy your PXE representative(s). The Boot.wim file will now load simulating Provisioning was chosen in the PXE menu.
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
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.
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
All needed files are copied to C:\ldprovisioning directory on the client machine
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
Troubleshoting 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.
Open a new console in WinPE.
Check to make sure that the C: drive is accessible.
Change to the C: drive and look around. Does it look like the image was put down correctly?
If you deployed:
Windows XP
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.
Check the cmdlines.txt in C:\sysprep\$OEM$\ and make sure it contains a line for ldprovisioning.cmd
Verify that ldprovisioning.cmd is in C:\sysprep\$OEM$\
Windows Vista/2008/7
Change to C:\ldprovisioning directory. Verify the ldprovisioning.cmd is in the folder and the folder is populated. It should contain over 20 files.
Verify that the unattend.xml exists in C:\Windows\Panther
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:
Once the machine completes the mini-setup section, it will boot into the final OS. As the machine boots up, 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:
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
This issue is characterized by selecting an OSD script from within the PXE Boot Menu inside WinPE, the Boot Menu window disppearing, 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:
On the core server, go to the log directory. This is located at the following path <Install Drive>:\Program Files\LANDesk\ManagementSuite\logs or can also be accessed via UNC share at <coreservername>\ldlog.
Once in the log directory, it is reccomended to sort by Date Modifed, with most recent at the top.
The log file will be named CJ-OSD-<scriptname>-<timestamp>.log
If there is a log file, open it with a text editor, such as notepad or word.
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.
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:
On the core, pull up the Start > Run window
In the field, type or paste the following command and then hit enter:
Once the service is installed, start the service and then try the OSD process again.
If there is not a C:\Program Files\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 furhter assistance.
Verifying the PXE.amsx Web Service functionality
Open the CoreWebServices.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 succesfully with client mac address 000C29461DD1, script GUID bc6a8a9c-3edc-4845-83fb-5e1cceb60b71
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:
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)
Click on the GetObjIDFromMACAdress link in the web site.
On the MAC Address field, enter in the mac with no spaces or dashes.
Click on the "Invoke" button to process.
The following return should be displayed:
NOTE: The number encased by > < is the object ID and corresponds to the machine's ID assigned by Inventory.
If this process fails, then there is most likely a missing record. Ensure that the Inventory contains the MAC address associated with a machine record.
Will the RunScript function start the job by manually putting in the MAC Address and ScriptGUID? (Note: This must be run locally from the Core Server)
Click on the RunScript link in the website.
On the indicated fields, input the MAC Address and the script GUID.
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"
Enable the OSD Web Tracing by doing the following:
Edit the web.configfile 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.
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)
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 applicance 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:
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
Another machine in the database has the IP address assigned to the machine in WinPE. Custjob.exe is targeting that device.
The inventory scan had not yet processed the ip address from the miniscan. This could be because the inventory service is stopped or hung.
Duplicate devices (two machines with the same MAC Address) in the database.
Core cannot contact the Agent on UDP port 9595. (Firewall, or other filtering device is blocking this port.)
Under Configure | Services | Custom Jobs, the Discovery setting may be set to TCP only. WinPE only responds to UDP.
DNS can be in a state where the client can resolve the Core Server but the Core Server cannot resolve the agent workstation.
NIC driver may not be entirely functioning properly.
Name resolution problems may prevent the core from targeting the machine by DNS name.
Resolutions
Start or restart the inventory service.
Search for the IP address that WinPE has. If another device has this IP address, delete that inventory record.
That device may show up twice in the database. Delete all devices with that MAC Address. See community article 1569 for assistance with this.
Open UDP port 9595 between the Core Server and the Agent workstation.
Go to Configure | Services | Custom Jobs and set the Discovery to try both UDP and TCP.
Go to Configure | Services | Custom Jobs and check the box to Disable DNS/WINS Lookup.
Make sure the Core Server can ping the Agent workstation by name and IP.
Update the NIC driver In the WinPE image.
Make sure the Core Server and PXE reps are running the same version of software.
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.
Verify that the core is processing mini scans. Check Configure | Services | Inventory | Advanced | Ignore mini scans. This value needs to be set to 0
After installing SP4, all provisioning templates with Software Distribution actions fail.
A provisioning template can be created and contain software distribution packages along with other actions. All actions in the provisioning template will succeed but all software distribution actions will fail
When software distribution tasks are peformed outside of a provisioniong template via a scheduled task, they complete without issue.
Below is the error that the LANDesk Provisioning Agent produces. The error is the same for all software distribution packages in the provisioning templates.
action index=8238 type=Distribute_software
FAILED
error:[80000000H]An unknown error occurred. If the problem persists, contact the LANDesk administrator.
Resolution:
1. Contact LANDesk Technical Support to obtain patch LD90-SP4-CP_BASE-2013-0401.
2. Install the patch on the Core Server.
Note: The patch only has to be installed on the Core Server to resolve the issue. Clients will not beed to be updated.
It has been noticed by some customers that an issue is occuring with Imagew V2 in SP2 regarding an error that states the file NTLDR is missing. This occurs after the image has successfully deployed and rebooted from PE.
Cause
The version of imagew in 8.8 SP2 (2.1.5) seems to have a problem with correctly setting the MBR for XP machines.
Resolution
If Windows Vista is not the target OS, use the attached version of Imagew (2.0.6).
1. Download the attached version of Imagew.
2. On the core, browse to the <InstallDrive>\Program Files\LANDesk\ManagementSuite\osd\imaging\2.0 folder.
3. Rename or delete the current Imagew file (version 2.1.5).
If using just the WINPE you never see the WINPE script menu following the F8 menu. This happens more at remote sites with a slow links back to the Core, but can happen on any network with slow links or heavy network traffic.
Cause
pxemenustart.exe is being run before the Core has received and processed the most recent miniscan containing the IP address of the machine.
Resolution
Edit the startnet.cmd file, in the ldvpe1.img file with WinImage (http://www.winimage.com/), to run ldsleep with a wait of 5 or 10 right before the wait4ip command. The startnet.cmd file is found in the ldvpe1.img file at \i386\system32. See below for an example:
REM wait to get a valid IP X:\ldclient\ldsleep 10 \ldclient\wait4ip /t 180 if %errorlevel% gtr 0 goto fail
After you have edited the startnet.cmd and reinjected it to the the ldvpe1.img file you will need to redeploy the PXE reps.
When attempting to image machines recieving "ERR_Fail",-1918091007 -1918091007 breaks down to 3500:16641 Error message as seen in the log "0019BBDBCFB8","ERR_Fail",-1918091007,0:00:02,4/15/2008 5:57:41 PM,4/15/2008 5:57:43 PM,"sdclient /f /o /dest="X:\LDClient\diskinfo.exe" /p="http://10.10.10.X/landesk/files/diskinfo.exe", STATUS"
Cause
The RAM Drive(x drive) does not have enough free space left
Resolution
Increase the amount of free space in ldvpe1.img file and redeploy All PXE Rep's and try the OSD deployment again.
When PXE booting an E74 is given and no F8 menu appears. Error: "PXE-E74 bad or missing pxe menu and or prompt information". Also, the PXE F8 menu does not come up. The proxy IP indicates the correct address. Re-deploying the PXE representative does not resolve the problem. Installing PXE rep on another machine does not resolve the issue.
Causes
The PXE rep installation software is corrupt.
Port 69 Traffic is blocked to the PXE Representative
The PXE Agent embedded in the firmware of the NIC is handling DHCP option 43 incorrectly
The BIOS and NIC firmware have a limited capacity for PXE Boot Menu options. This has been seen on a number of computers including:
Lenovo machines with BIOS 3.11 or later
Resolution
Disable some PXE Boot Menu options
It has been found that some updated versions of BIOS from some manufacturers do not properly handle large PXE boot menus
It is recommended to remove the LinuxPE and DosPE options, as they are normally not used
Obtain a new osdrep.msi installation package from LANDesk Support.
Copy the osdrep.msi file into the C:\Program Files\LANDesk\ManagementSuite\landesk\files folder.
Run the PXE Rep deployment script on the target machine.
Enable traffic on port 69 to the PXE Representative
This would be configured in the client firewall, or possibly a switch on the network
DHCP Options 43 and 60 should not be used when using LANDesk to PXE boot
Options 43 and 60 should not be configured on the DHCP server when using LANDesk PXE boot as they will conflict with the information and data sent to the client from the PXE representative. See below for step is resolving this.
Windows Server 2003
Open DHCP on Windows 2003 Server
Go to -> Scope -> Scope Options
Right click and choose Scope Options and choose Configure Options
Uncheck either option 060 and option 043 (they are not be needed)
DHCP Configuration when using LANDesk PXE Boot
When neither option 60 nor option 43 is set, PXE clients will wait until a PXE server contacts them. The LANDesk PXE representative will listen to DHCP discovery packets sent by PXE clients and answer at the same time as the DHCP server does. The LANDesk PXE and LANDesk PXE MTFTP services on the PXE representatives handle the requests made by clients attempting to PXE Boot.
In order to support PXE clients on a network, the DHCP server is usually configured in one of the following three modes:
Option 60 not set, Option 43 not set
Option 60 set to 'PXEClient', Option 43 not set
Option 60 set to 'PXEClient', Option 43 set
When neither option 60 nor option 43 is set, PXE clients will have no clue where the PXE server is, and they will therefore wait until a PXE server contacts them. In this mode, the PXE server must listen to DHCP discovery packets sent by PXE clients and answer at the same time as the DHCP server does.
When option 60 is set to 'PXEClient', it means that the DHCP server knows where the PXE server is. If option 43 is not set, the PXE server is on the same computer as the DHCP server (same IP address). If option 43 is set, PXE clients must decode option 43 to know how to reach the PXE server.
In most situations, option 43 does not need to be setup, because the PXE server will either listen to DHCP discovery packets (DHCPProxy), or be on the same computer as the DHCP server. However, if the PXE server is on a separate subnet (it cannot listen to DHCP discovery packets), or if there are several PXE servers on the same subnet, option 43 is the only viable solution in order to instruct PXE clients on what to do.
For more information on PXE boot errors please see:
WinPE Image fails, shows device as "off" and the IP Address is 0.0.0.0 This has been reported on the following models: Dell Optiplex 745 Dell GX60
Cause
Previous Cause (Before 8.7 SP2) This is common before 8.7 SP2 as often the miniscan would run simultaneous to the DHCP request. The miniscan would scan and see a 0.0.0.0 address, but the NIC would already have the IP Address and be available. This was resolved by adding a wait4ip.exe utility in 8.7 SP2. Current cause (8.7 SP2 and later) Unknown. Some devices have sent in a 0.0.0.0 address even though wait4ip.exe is in place and working. However, this is extremely rare.
Resolution
If on 8.7 SP1 or earlier, do the following:
Update the Core Server is updated to the Latest Service pack.
Uninstall and reinstall all PXE Representatives with the PXE Rep from the latest service pack.
If 8.7 SP3 or Later is installed already, do one of the following:
Run the mini-scan again manually from within WinPE by opening a command prompt and running this command:
Startnet.cmd
OR, modify the startnet.cmd to give wait4ip.exe more time to run by following the steps below on the core:
1. Using WinImage, open the LDVPE1.img file located in the landesk\vboot folder.
2. Inside the i386\system32 folder, locate and extract the startnet.cmd file.
3. In the startnet.cmd file, locate the wait4ip line and add the following line immediately before the wait4ip line:
When machines are attempting to PXE boot they are failing with error; **
BOOT SERVER IP: x.x.x.xMFTP...PXE-T00 Undefined error code, or PXE-T01 Undefined error codePXE-E36: Error received from TFTP serverPXE-M0F: Exiting (NIC Manufacturer) PXE ROM.
This is being caused by the PXE Representative attempting to redirect the Client machine to a PXE Rep in another subnet for file download. Currently there are only two solutions;
1) Remove all PXE Representatives except the one you are attempting to use.
2) Disable the Multicast option for the MTFTP service on the PXE Representative.
There is only one supported option for disabling Multicast on the MTFTP server. Disabling Multicast on the MTFTP server will not have a significant effect on the process of imaging machines even if using the Multicast option in the script or template.
Instructions for how to manually disable Multicast (this will need to be performed on all PXE Representatives);
1) On PXE Rep, go to C:\Program Files\LANDesk\PXE\System, double click to run PxeConfig.exe.
2) Right click "Boot Server", then click "Configure Boot Server..", select the "MTFTP Options" tab, and un-check the Multicast option checkbox.
3) Restart both LANDesk PXE services on the PXE Rep and boot into WinPE
Download the updated DOS Boot Images and copy them to the core server.
1. Open CoreServer\Program Files\LANDesk\Managementsuite\LANDesk\Files\DOSUNDI.1 with Winimage.
2. Extract the file STARTENV. BAT from the root of the boot image. This can be done by dragging it to the desktop.
3. Open the STARTENV.BAT and change SET COREHOST= [YourCoreServer] to SET COREHOST=[coreserver ip address]
4. Save the modified STARTENV.BAT file and re-inject into the root of the image. Remember to save the image after injecting the new STARTENV.BAT file.
5. Using WinImage, navigate to the \NET directory of the image.
6. Extract the LMHOSTS file from the image
7. Edit the LMHOSTS file with notepad and add entries for ANY server that will be referred to in OSD tasks
Example:
# x.x.x.x This entry is the core server where the image utility is stored
# x.x.x.x This entry is for an image store other than the core server
8. Save the LMHOSTS file, and re-inject into the \NET directory of the DOSUNDI.1 image. Remember to save after injecting
9. Make the same changes listed above to CoreServer\Program Files\LANDesk\Managementsuite\LANDesk\Files\BOOTMENU.1
NOTE: Do not forget to update the BOOTMENU.1 file with the same changes. A DOS PXE Boot uses the BOOTMENU.1 as the boot image, and the name resolution issues must be fixed here as well.
Adding Drivers to the boot images
1. Download the manufacturer driver(s) from the appropriate vendor
2. On the core server, open the \Program Files\LANDesk\Managementsuite\LANDesk\Files\DOSUNDI.1 boot image using Winimage.
3. Navigate to the \NET directory of the image. Extract the net.zip file from the image
4. Open net.zip with preferred tool (WinZip, WinRar, etc.) and add the *.DOS driver file downloaded from the vendor
5. Save the changes to NET.ZIP and inject back into the \NET directory of the boot image
6. Navigate to the \NET directory of the image. Extract the nic.txt file from the image
7. Copy nicinfo.exe from [Your_Core_Server]\ldmain\landesk\vboot directory to a machine with desired NIC running Windows.
This will generate a file "dosnic.ini" in the same directory as the executable with the vendor and PCI device information of the network card.
8. Open the nic.txt and verify the information returned in the nicinfo.ini is listed. If not, add the vendor and/or deviceid following the existing
format.
9. Save the nic.txt file and inject into \net directory of the DOSUNDI.1 boot image using the Winimage utility.
10. Make the same changes listed above to CoreServer\Program Files\LANDesk\Managementsuite\LANDesk\Files\BOOTMENU.1
NOTE: DRIVER WILL NOT BE USED IF MAPPING DOES NOT EXIST IN NIC.TXT
Note that the Intel Universal NDIS Driver (UNDI) is loaded. If a manufaturer specific driver was desired and the undi driver still
loaded, double check the steps above.
Note: Re-deploy PXE representatives for changes to take effect
When attempting to PXE boot, the following error appears:
PXE-E53: No boot filename received
Also,
PXE Boot fails.
No F8 option is recieved by clients.
Unable to PXE Boot machines.
Unable to network boot machines.
Cause
Possible causes:
No PXE representatives are deployed
Deployed PXE Representative is turned off.
PXE representative is not in same broadcast domain as target machine.
Firewall on PXE representative is blocking requests from target machine.
PXE services are not running.
Windows Deployment Services (WDS) are installed on the PXE representative.
Resolution
Possible steps for resolution:
Ensure that a PXE rep is on and is deployed in the same broadcast domain as the target machine.
Ensure that no firewall is blocking requested packets from PXE booted machines.
Ensure PXE services are running. The two services are "LANDesk(R)PXE Service" and "LANDesk(R) PXE MTFTP Service". If they are running, restart the services.
Redeploy the PXE Representative.
If PXE services repeatedly stop on PXE representatives, download and install the latest service pack on the core, then remove and redeploy PXE representatives.
Disable the Windows Deployment Services (WDS) on the PXE representative.
Note: The PXE Representative may need to be rebooted if the services are running, the firewall is off, but it still does not respond.
For more information on PXE boot errors please see:
Applies to LANDesk Management Suite 8.8 and newer.
Description
This document is intended to show the versions of WinPE used in each version of LANDesk Management Suite. The goal is to facilitate getting the correct drivers for the WinPE version being used.
Note: In LANDesk Management Suite 9.5, the 64-bit version of WinPE is included to add support for UEFI devices.
Resolution
LANDesk Management Suite 9.5 SP1 with BASE 1017 patch
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:
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.
Once in the log directory, it is recommended to sort by Date Modified, with most recent at the top.
The log file will be named CJ-OSD-<scriptname>-<timestamp>.log
If there is a log file, open it with a text editor, such as notepad or word.
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.
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:
On the core, pull up the Start > Run window
In the field, type or paste the following command and then hit enter:
Once the service is installed, start the service and then try the OSD process again.
If there is not a C:\Program Files (x86)\LANDesk\Shared Files folder on the core server, please contact LANDesk Technical Support for further assistance.
If the LANDesk Management Agent service is installed and running and a service restart did not resolve the issue, please follow these additional troubleshooting steps:
Verifying the Inventory Record
OSD needs an inventory of the device being imaged in order to create the task and begin logging. New machines that have not been inventoried before will be listed by its MAC address in the Device Name column in the console.
If there is no inventory record for that device, restart the inventory service and reboot the client and try imaging again. If still no inventory record appears for the device please contact LANDesk Technical Support for further assistance.
Verifying the PXE.amsx Web Service functionality
Open the CoreWebServices.dll.log located in the log directory on the core server. The log should contain lines that are similar to those listed below:
RunScript: started with client mac address 000C29461DD1, script GUID bc6a8a9c-3edc-4845-83fb-5e1cceb60b71 RunScript: completed successfully with client mac address 000C29461DD1, script GUID bc6a8a9c-3edc-4845-83fb-5e1cceb60b71
Note: Each script has an associated GUID. The GUID is contained in the Script (Located in the ManagementSuite\Scripts directory). This must match in the PXEMENU table in the database in order for the script to be associated properly.
Line in Script: GUID=71e307da-bb27-46ab-ac8d-ef9641f3139f
Entry in Database:
Can the LANDesk PXE.asmx web page be accessed? (Note: This must be run locally on the Core Server
Open a web browser on the core and type/paste the following address:
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)
Click on the GetObjIDFromMACAddress link in the web site.
On the MAC Address field, enter in the mac with no spaces or dashes.
Click on the "Invoke" button to process.
The following return should be displayed:
NOTE: The number encased by > < is the object ID and corresponds to the machine's ID assigned by Inventory.
If this process fails, then there is most likely a missing record. Ensure that the Inventory contains the MAC address associated with a machine record.
Will the RunScript function start the job by manually putting in the MAC Address and ScriptGUID? (Note: This must be run locally from the Core Server)
Click on the RunScript link in the website.
On the indicated fields, input the MAC Address and the script GUID.
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"
Enable the OSD Web Tracing by doing the following:
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.
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)
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:
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
Another machine in the database has the IP address assigned to the machine in WinPE. Custjob.exe is targeting that device.
The inventory scan had not yet processed the ip address from the miniscan. This could be because the inventory service is stopped or hung.
Duplicate devices (two machines with the same MAC Address) in the database.
Core cannot contact the Agent on UDP port 9595. (Firewall, or other filtering device is blocking this port.)
Under Configure | Services | Custom Jobs, the Discovery setting may be set to TCP only. WinPE only responds to UDP.
DNS can be in a state where the client can resolve the Core Server but the Core Server cannot resolve the agent workstation.
NIC driver may not be entirely functioning properly.
Name resolution problems may prevent the core from targeting the machine by DNS name.
Resolutions
Start or restart the inventory service.
Search for the IP address that WinPE has. If another device has this IP address, delete that inventory record.
That device may show up twice in the database. Delete all devices with that MAC Address. See community article 1569 for assistance with this.
Open UDP port 9595 between the Core Server and the Agent workstation.
Go to Configure | Services | Custom Jobs and set the Discovery to try both UDP and TCP.
Go to Configure | Services | Custom Jobs and check the box to Disable DNS/WINS Lookup.
Make sure the Core Server can ping the Agent workstation by name and IP.
Update the NIC driver In the WinPE image.
Make sure the Core Server and PXE reps are running the same version of software.
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.
Verify that the core is processing mini scans. Check Configure | Services | Inventory | Advanced | Ignore mini scans. This value needs to be set to 0
