We have a site that is connected to our network via VPN. That site currently has a small subnet available to them for imaging. There is a PXE rep and a Preferred server on the subnet, Provisioning works fine (they PXE boot and select the required template). We want to move them to a subnet with more available IP's for imaging (all they do is image) so all the required network (VPN, DHCP Scope, etc) changes were made. This change required us to change the IP address of the PXE rep and the Preferred Server. Now, on the 'new' network, we get an IP address from the new DHCP scope/subnet (same subnet as PXE and Preferred Server), we can PXE boot, authenticate, select the required template from the menu, but from that point forward, all we get is 'loading template, 1 of 40, 2 of 40, all the way until it fails at 40 of 40. Tried this numerous times, same result. Verified connectivity to the Core Server, the Preferred Server, name resolution, etc. All is good. The preferred server IP address ranges include both the old and new subnet's. We also verified all packages associated with the template were correct and even updated/refreshed the templates. Same result. Now, if we move everything back to the original subnet (VPN, DHCP Scope, IP address of PXE and Preferred server, etc), provisioning starts working again.

We worked briefly with LANDesk support on this issue, but needed to get the site back up and running ASAP so we reversed the network changes. The provisioning logs were reviewed by support/development but no obvious issue was found. The logs had errors like: 'Couldn't find task for computer XXXXXX' and 'unable to find template for computer XXXXXX'.

We now plan to bring up a second interface on the firewall with the new network, bring a second PXE rep and Preferred server to the site and configure on the new network to see if we can determine what the issue is. We can't take provisioning down again without knowing the changes will work.

Does anyone have thoughts or ideas of what might be going on? Once again, the new network checked out ok as far connectivity to the core, preferred and PXE.

Thanks!

We have begun to convert all of our existing OSD scripts into the newer Provisioning method.  I had a little trouble with the Image Capture but was able to get that to work.  We are now however stuck with the deployment of an image.  I'll outline what we are doing now and where the process seems to be failing.

Pre-OS Installation

     -Remove Partitions

          -Remove all partitions: disk = 0

OS Installation

     -Deploy Image

          -LANDesk Image2 V2

               -Default Parameters

     -Set Active

          -Make Bootable

               -Disk =0, Partition ID = 1, OS Partition ID = 2

Post-OS installation

     -Configure Target OS

              -Insert Provisioning Agent (CTOS)

     -Reboot/shutdown

          -Reboot (have attempted adding this and removing it as well)

     -Inject Script

          -Win 7 Current CL XML

               -Target: c:\unattend.xml (also tried d:\unattend.xml)

The part I'm getting stuck at and can't seem to continue on from is the Inject Script.  As soon as the Image is deployed I can't seem to see the drives or access them to write the unattend to.  It never shows up when the OS reboots.  When the OS does finish rebooting after the deployment it is still in sysprep mode.

Do I need to add a step to mount the drive after it's been imaged? Or am I missing something else entirely?  I've been going nuts with this for about 2 weeks now.  Thanks very much for anyones assistance on this one.

hi All,

The background image into the WinPE image is not working. The injection works correctly but the background image does not appear when the image is loaded onto the workstation.

Thanks,

Den

Made inactive until partner can test the script on the customer's site, current solution past lab tests.

Most likely resolution :

As discussed I have now resolved this issue and found out why this was not working.

The reason why this was not working was due to the changes Microsoft made to their winpe image wallpaper settings. In winpe 3 the default wallpaper was located here :

x:\windows\systme32\winpe.bmp

Which is what the LDMS console is designed to replace, But in winpe 4 the default wallpaper is loacted here:

x:\windows\systme32\winpe.jpeg

I have created a one time batch file which your customer should run as administrator on their core server. Once this has run , redeploy your PXE reps and this should resolve the issue.

Before running the script make backups of the following image files as a cautionary step:

C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\boot.wim

C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\boot_x64.wim

C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\bootMedia.wim

Problem:

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

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.

Applies to LANDesk Management Suite 9.5 SP1 and newer

Description

Hardware Independent Imaging allows drivers to be injected during the imaging process specific to the destination hardware. During hardware migration planning driver decisions must be made. In order to assist with that migration planning a preview option has been added to HII, enabling IT to review driver assignments prior to upgrading to a new OS.

Requirements

• The client where the preview is being run must have an agent installed
• The client must be able to download the drivers.db3 file from the core server

Running HIIClient

1. Copy HIIClient.exe to the client from the core. The file can be found in the %LDMS_HOME%\landesk\files directory.
2. Run HIIClient with the appropriate preview options (See below).
3. Review the logs for driver assignment and detection found in the directory where HIIClient was run.
   1. HIIClient.log
   2. HIIPreview.log

HIIClient options

hiiclient [/?] [/uncpath] [/taskid <taskid>] [/preview | /previewall] [/os <os> /arch <architecture>]

/? - Shows standard help and syntax information

/uncpath - Specifies if HII should use unc based paths to drivers

/taskid - Specifies the <taskid> to use to ask for SWD snippet when processing packaged drivers

/preview - Specifies if HII should run in preview only mode.

/previewall - Specifies if HII should run in preview only mode with debug information.

/os - Only valid with both /preview and /arch.

          Specifies which OS the preview should be run for.

          Valid options are: winxp, win7, win8, server2003, server2008r2, server2012

          If not specified the currently detected OS will be used.

/arch - Only valid with both /preview and /os.  Specifies which architecture the preview should be run for.

          Valid options are: x86, x64.

          If not specified the currently detected Architecture will be used for the preview.

I currently have a PXE environment with LD9.5 SP1 and am unable to boot one of my Models of machine to the WinPE environment.

I have several other machines that are booting with no issue at all. HP 8530, 8540, 8560, 8570, 6000, VMWare Virtual Platforms so I'm fairly certain it's not my PXE machine itself, or lack of connectivity to it, or the boot.wim file.

Machine that does not work (Lenovo T440s)

I have disabled the following in the BIOS for the new machine:

     Secure Boot

     UEFI Boot (Enabled Legacy)

     Execution Prevention

     CSM Support (Enabled since UEFI is disabled)

What occurs is a little different from what other have already reported which is why I'm putting in the question.

Here is what happens.

F12 to enter Boot options

Select the NIC

NIC broadcasts MAC

Receives DHCP and sees PXE boot Representative

PXE boot options appear with correct modified timeout (so I know it's receiving information from the PXE rep)

I choose WinPE Menu (or Managed WinPE)

The Boot Server IP is shown (correctly)

The MTFTP flashes for a moment and disappears. 

The unit shows a blinking curser directly under the Boot Server IP: xx.xx.xx.xx Line

Unit hangs indefinitely and does not progress beyond this point.

Any assistance or ideas beyond this would be extremely helpful as I have been searching for a solution all day with very little to show for it.

LD9.5

patch LD95-CP_BASE-2013-0228.exe

OSD

ImageX

Ever since I applied this patch AND redeployed my PXE reps with the newest PXE update, I now have broken my .wim's with regards to SEP11. Within our image files, we have SEP 11 installed (unmanaged until its not). (after image is laid down)Once OOBE completes and you get logged in for the first time, you notice right away that the SEP client no longer functions (an error pops up stating the definitions are broken) and you notice that the SEP systray icon now has an error (where before this patch to the core, PXE rep deploy, it didn't occur). No, it's not because of network, connectivity to the network, etc.

In addition to this now nuisance, it also decided to re-create a new Program folder (god knows why); again, this is new since this patch. PROGR~2 ? WTF?

of course there's no fixing this broken SEP client install now. You have to run the Symantec Cleanwipe.exe tool to completely remove this debacle and re-install a clean version of SEP. (simply removing this from Add/Remove will not solve it). The client will no longer update definition files.

I thought I was crazy, and that this couldn't be the reason why, so I decided to go back and re-create a new OSD ImageX (took me 2 days), recaptured my image, re-deployed and the same result.

I then decided to re-build, yet again, another image, this time capturing it with ImageW v2. Redeploy that image, completes all normal steps, login for the first time and now SEP is normal, working as it should, unmanaged and clean. No extra program folders created. No issues.

So the question is why? What would have changed in that Core patch (besides changing PXE boot from Win7 winpe to a Win8 winpe), that would then later break SEP specifically?

No other applications seem to be affected by this core server patch.

I prefer ImageX over ImageW, personally, but is this a conspiracy to force us to use ImageW?

Anyway, I just thought I'd share this with others, not so much as to get LANDesk to fix this (Lord knows it would be nice), but to hopefully see if others have seen this themselves.

Perhaps, we're the only group who puts SEP into an image and used OSD/ImageX while everyone else never sees this. I find it hard to think it's unique.

Thanks for listening to my frustration.

I have been slowly making progress in the Provisioning conversion of my current OSD scripting.

The slight caveats in the process have been getting me into trouble.

Currently, my process will Perform the following:

All Pre-OS installation steps

     -Remove Partitions

All OS installation steps

     -Deploy image

     -Set Active

     -Partition

All Post-OS installation steps

     -Inject Script

     -Execute file

     -Configure Target OS

Once the machine reboots into Windows and runs my unattend.xml it simply stops there.

I have the following steps afterwards that are not running.  I've not seem the drive map so I'm wondering if it's getting stuck there first.

System configuration

     -Map/unmap Drive

          Map a drive

          \\%corename%\osd

          i

     -Execute File

          i:\tools\win7drivers\copydrivers.exe

          /c

     -Execute File

          i:\tools\win7drivers\ldprep

          /path=c:\drivers

     -Copy Files

          i:\tools\win7drivers\8570Accel\*.*

          c:\installs\8570Accel

          Copy Subdirectories

     -Copy File

          i:\tools\setupcomplete.cmd

          c:\windows\setup\scripts\setupcomplete.cmd

     -Shutdown

          Reboot

          60

I have created a CSV file with some network information to import bare metal machines into the Core Server (9.5 SP1) using CSVimport. The resulting ims files are similar to this:

Network - NIC Address = 3C970E0$C34C

Network - TCPIP - Address = 192.168.030.011

Network - TCPIP - Subnet Mask = 255.255.255.000

Network - TCPIP - Subnet Broadcast Address = 192.168.030.255

Network - TCPIP - Default Gateway Address = 192.168.030.254

Device Name = VEGA

Network - TCPIP - Host Name = VEGA.xxx.xxx

The new bare metal registers are created into the inventory DB in the core server, but when I try to wake up any of these using the LDMS console they fail to wake up. Any ideas on why these imported bare metal machines fail to respond to the wake up commands from the console?. Other LDMS client nodes in the same subnet are able to be waken up quite happily from the console.

I just created a windows 8 master image using Landesk 9.5 sp1.  I created it on a 40GB partition and successfully deployed it however I need to make a change then, capture it and re-deploy it.  I am unable to shrink the volume down in order to capture it on the smallest partition possible.  Is there a way to do this so that I can update my images?

I understand the purpose of SysPrep for generalizing a machine, or deploying via a script or whatever.  But SysPrep refuses to run on OEM versions of Windows 7.  That being the case, is there some reason not to just skip the SysPrep and deploy multiple images anyway, and then just rename each computer using Control Panel?  I have heard that it is necessary to use SysPrep to change the SID of the target computer, and there does appear to be no other "approved" (by Microsoft) tool to do that, but why should it matter if the SID is the same on multiple computers?

I am running SP1 9.5. Since upgrading I have been noticing an increase of OSD scripts that when run aren't starting as well as scripts actually not showing up on the menu. On the PXE Boot menu configuration, I will see something I can equate to a placeholder, but the script name is no longer there.

Has anyone else been running into this since 9.5 SP1?

-Jonathan

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

Issue:

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

Resolution:

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

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

Hi,

I was using the provisioning boot media to boot devices and install OS and it was working fine until this morning.

Suddenly fthis morning I am not able to boot from provisioing media. I get "Bootmgr is missing" error when I boot using the provisioning boot media, but booting through PXE works.

I am sure we did not apply any patches.

Any help will be appreciated.

Thanks

I would like to pre stage about 1500 computers for provisioning and I would like to import those devices as a Bare Metal Server by importing a CVS file. What headers need to be used in the CVS and so on create a new Bare Metal Server? I would like to create the new Bare Metal Servers using the MAC address or the devices serial number. Also, as you import the devices can you set variables through the CVS file too such as a ComputerName variable?

Environment:

LANDesk Management Suite 9.5 (with HP ElitePad Integration Update and/or the BASE 0228A patch) or LANDesk Management Suite 9.5 SP1

Description:

After upgrading to 9.5 SP1 (or 9.5 with HP ElitePad Integration Update and/or the BASE 0228A patch), some software within a WIM image is not working properly anymore.

You might receive the following error when booting Windows 8 for the first time :

Error 1500. Another installation is in progress. You must complete that installation before continuing this one.

Example:

The mail icon in the Control Panel created by Microsoft Office is missing.

Cause:

The version of WinPE used by OSD/provisioning is version 4.0 instead of version 3.1 and Microsoft changed the way it formats partitions. The 8.3 file format is not active which causes some files from the WIM file not to be copied or to be corrupted when copied over to the hard drive.

Solution:

Format the drive using the following switches : format C: /fs:<FS> /q /s:enable /y

The /s:enable turns the 8.3 format back on and should resolve issues when files are copied over from the WIM to the partition.

Reference:

This document was generated from the following discussion: LDMS 9.5 SP1 PXE Rep Issue

Description:

After upgrading to 9.5 SP1 you noticed that when you edit a template that contains "distribute software" actions, the Packages information is lost.

You need to reselect packages.

Issue:

It seems to be linked to packages

Workaround:

1- Make an export of the packages.

2- Delete tasks that were linked to these packages

3- Delete the packages

4- Imported the packages back (from step 1).

Hi there,

I'm facing a critical issue with HII (LDMS 9.5 sp1) when adding new drivers for different computer models that I have tested and approved for these specific PC's models (Dell Latitude E6x40, DELL Precission T1700, T3610, T5610, T7610). Seems that some older computers with different models of hardware detects the new drivers as adequate for their components (let's say the chip set driver for a DELL optiplex 7010 or HPCompaq 8300), and then HII assign these new drivers to the old computers even to pc's that are from a different maker, for instance HII is assigning DELL drivers to HP computers.

The nightmare for me is that I don't know how to pinpoint what drivers has been assigned to each old computer and which one (or ones) are the offending drivers that produces the blue screen of death when the the new image boots up after HII injects the drivers to the old PC's models.

I have over 40 different PC models and makers in our environment and we add periodically new models. So now I face a difficult situation as every time I add new drivers for new PC's to the HII driver library I don't know what will happen to the existing models when a image is deployed and the HII injects the drivers. Up to now and after adding some new drivers I'm in a terrible situation because computers that were receiving OS images and drivers perfectly alright, and now these fails with the BSOD and I don't have a clue about which drivers are the offending drivers that are breaking the OSD process.

Any ideas about it? Any help will be welcome.  

Thanks!

We are looking into Hii for imaging moving forward.....I can't find a document explaining the process

Is there a lot of issues with 9.5 sp1 hii?  I've seen quite a few unanswered posts regarding blue screens and slowness....is it unstable?

Is there a way to import all HP/Dell Drivers

Hi all

I'm experiencing some problems with Provisioning with LANDesk 9.5 and WinPE 4.0

I have a HP DC7800, on which I try to install Windows 7.

I have a Provisioning task with as first step: Boot to Managed WinPE (Virtual Boot).

The pc currently runs Windows XP, so as soon as I shecdule the provisioning task, I can see the GUI in my Windows XP session.

The boot.wim is then copied to my C-drive and a little bit later the system reboots.

So far so good

Now, when the computer eboots, it loads the boot.wim. It says "Windows is loading files", but at the end, it stalls. I have let it run for 2 hours, but it hangs at a black screen.

When I reboot the computer and press F12 (PXE boot), the computer autmatically picks up the Provisioning task, boots to WInPE, and the task continues (!!).

So, at that point I can only think of the fact that my boot.wim from the landesk\vboot directory differs from the boot.wim that is on my PXE server. However, they are not. The boot.wim is the same date and size as my landesk\vboot\boot.wim

I've also tried to install Windows 7 on a HP 6005 Pro, and this works fine. No issues with WinPE.

Anyone who knows where this problem lies? Drivers should not be a problem, since I can use F12 to boot to WINPE just fine...

Thanks in advance!