I'm attempting to Provision a machine here in our new LDMS9 environment and I'm having an issue with resolving our core server name. Any suggestions on this?

Hi All,

Just been working out the new feature of being able to assign a setup based install package to a hardware component that was introduced in v9.5 SP1 to HII. I have it working well but there is no real doco on how to get this operating so thought I would share some tips:

1. There is a new HII action in provisioning now under system configuration (as well as the inf based one found under post-os config) that you must add to your template
2. As this is deploying a SW Package you must have an agent installed to the new host OS before running this new HII action

With these two steps it is working well so far.

I am not too sure what I am doing wrong but I keep getting a Bootmgr is missing after I image with imageX.

We have been using Windows Deployment server and have a bunch of wim images.  I have tried changing the system partition in the OSD job and went from 1 to 4 and I still get this message?

I am sure I am doing something wrong but what check box did I miss.

Any help would be appreciated.

Ed

  Running 9.5 SP1, after the deploy image step succeeds, the "inject script" step fails with the error "The Web service responded with an invalid call".

  What it really means is, it can't copy the XML to the target file name of C:\windows\system32\sysprep\unattend.xml . Previously post image deploy, the volumes would be mounted. In 9.5 SP1 it is not.

  Do I need to manually mount the volume, or am I missing something?

Have a customer with LDMS 9.0 and wants to multicast their image to 70 systems at once. How many systems has anyone out there imaged at once?  Just curious..

Trying to get to the bottom of an issue I am having with the deploy profile command in my osd provisioning template using 9.5. The capture profile works fine and the profile can be manually restored or used in a template as a stand alone deploy profile command, but the deploy profile fails when used within my complete template. This seems to happen only to profiles larger than 3GB. 

I have checked the ldprovisioning logs and it indicates that the ldprovision.exe: Reporting action status:  5 to Core right before the deploy profile fails.

I have checked the deploy profile handler log and it indicates:  DeployProfileHandler.exe:Executed Command. Return value is 259. 

My question is does anybody know what these error codes indicate.  I am hitting a brick wall when it comes to being able to confidently capture and restore a users profile. 

Having just installed SP1, I'm having a bit of trouble searching for .inf files when assigning drivers in the new HII Driver Management tool. I've tried putting both a UNC and HTTP path in the "Search Drivers" field, but nothing seems to populate. The "Driver Package" option works ok and lists all our packages. I've tried on both my console, and the core server's console, but cannot figure out what is (or I am doing) wrong.

Has anyone else experienced this?

Applies to LANDesk Management Suite 9 SP3 and newer

OSD.Upgrade.exe is run during the installation of a LANDesk Service Pack or any LANDesk patch that updates the WinPE image (boot.wim). It is responsible for configuring the image to function on a specific Core Server and migrating WinPE drivers from the boot.wim.bak into the new boot.wim. If OSD.Upgrade.exe fails, one or more of these steps may not be completed. This document will walk  through re-running the OSD.Upgrade.exe installation step on the core server.

Description

During the Service Pack or patch installation there may be a failure with the OSD.Upgrade.exe process. The install error may be similar to CommonCore.inf: (0xFFFFFFFF) OSD.Upgrade.exe,60000.  Review the osd.upgrade.exe log file found in C:\Program Files (x86)\LANDesk\ManagementSuite\log to get more specific information about the error. If desired the osd.upgrade.exe.log file can be renamed prior to running osd.upgrade.exe again to make curent errors easier to find.

Common Errors and Resolution

• Error Access Denied
  • Errors referring to access denied indicates that a folder path in the boot.wim is too long. Often this path will be for a driver that was injected into the WinPE image. There are two option for correcting this error. The first option is to just start with a clean boot.wim and add the necessary drivers after completing the OSD.Upgrade.exe process. In LDMS 9 Service Pack 3 the WinPE boot environment requires Windows 7 32-bit drivers. Updating those drivers is a manual process so starting with a clean boot.wim may be a good option. The second option would be to mount the backup of the boot.wim (boot.wim.bak) and rename the directories in the InstalledDrivers directory to use shorter names. After completing one of these options follow the steps outlined below to re-run OSD.Upgrade.exe.
• Error CommonCore.inf: (0xFFFFFFFF) OSD.Upgrade.exe,60000
  • This is a general error indication. Review the log for additional errors.
• Error DirectoryNotFoundException
  • Errors referring to a .0 or an mpkg package indicate that a .0 file has been extracted to a sub-folder of the ldlogon folder. DO NOT delete any .0 files from the root of ldlogon. Navigate to the directory specified in the log (i.e. C:\Program Files (x86)\LANDesk\ManagementSuite\ldlogon\mac) and delete the .0 file. To prevent additional errors when re-running OSD.Upgrade.exe delete any additional .0 files that are found in sub-folders of the ldlogon folder leaving only the .0 files in the root of ldlogon. Follow the steps below to re-run OSD.Upgrade.exe.
  • Errors referring an ALL.REG file indicate that the wim file was still mounted when osd.upgrade.exe tried to execute. This is most likely due to errors in the previous attempt at running OSD.Upgrade.exe. Review the log and correct and additional errors found before following the steps below to re-run OSD.Upgrade.exe
• Error Non-fatal error: FilterUnload failed, hr=0x801f0013
  • This is normal and does not indicate a problem. Continue reviewing the log file for additional errors.
• Error: System.ComponentModel.Win32Exception
  • You are running the process as a restricted user. Either log in as an administrative user or right click OSD.Upgrade.exe and select run as administrator.
• Error System.IO.IOException: Element not found.
  • This error indicates that there is still a wim file mounted. Review the log for additional errors prior to this error. Follow steps below to re-run the OSD.Upgrade.exe process.
• Error System.UnauthorizedAccessException
  • This error indicates either that there is still a wim file mounted, or that the bootmedia.wim.bak already exists. Bootmedia.wim.bak can be deleted as long as bootmedia.wim exists. Review the log for additional errors and then follow the step below to re-run OSD.Upgrade.exe.
• Error WAIK is not installed
  • This is normal and does not indicate a problem. Waik should have been uninstalled prior to upgrade. If Waik is installed, uninstall it. Continue reviewing the log file for additional errors.

Preparing to Re-Run OSD.Upgrade.exe

After reviewing your errors and completing the steps above perform the following steps:

1. Start an administrator command prompt (right click the command prompt and select run as administrator).
2. From the command prompt navigate to C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot.
3. Run the following command: imagex /unmount
   • The command should list all images that are currently mounted. There are instances however where a mounted image will not be listed. Check for the existence of the folder original_boot_wim and/or new_boot_wim in the C:\Users\logged in user \AppData\Local\Temp\imgtmp\ directory.
4. For each image listed and all folders found in the imgtmp directory listed in step 1, run the following command:
   • imagex /unmount "C:\mountpath". Where mountpath is the mount path listed from the imagex /unmount command or the folders specified in step 1.
   • Ensure that each unmount command completes successfully
5. In Windows Explorer open the C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot directory.
   
6. Rename the exiting boot.wim to boot.wim.bad.
7. Copy the backup boot.wim (the one from prior to upgrading) from C:\Program Files (x86)\LANDesk\ManagementSuite\backup\PatchName\ to the C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot directory.
   • If access denied errors occurred with drivers and a clean boot.wim file is desired, use the file listed in step 9 below.
8. Rename the restored boot.wim file in the vboot directory to boot.wim.bak.
9. Copy the boot.wim file from the installation package \image directory to the \vboot directory. You should now have a boot.wim and boot.wim.bak (either your backup or an additional copy from the patch) file in the vboot directory.
10. Run the OSD.Upgrade.exe from C:\Program Files (x86)\LANDesk\ManagementSuite\. This should take a few minutes to complete. If it exits quickly it is likely that there are additional errors.
11. Review the OSD.Upgrade.exe log found in C:\Program Files (x86)\LANDesk\ManagementSuite\logs to see if any additional errors were encountered. If additional errors were encountered, you must resolve each one and after resolving re-run OSD.Upgrade.exe.
12. If this still does not resolve the issue check "HKLM\SOFTWARE\Microsoft\WIMMount\Mounted Images" and remove any values in the key.

After OSD.Upgrade.exe has completed successfully you need to redeploy your PXE reps. Instructions for PXE deployment can be found at How to deploy PXE Representatives(step-by-step screenshots)

When a client machine boots into WinPE open a console to confirm the upgrade. The  version shown in the console should be 6.1.7601 or higher.

I was testing some Bare Metal templates on 4 machines.  I deleted the Bare Metal intentory entries for my 4 machines and booted one of the from the NIC and pressed F8 to see the boot options.  I left it there and re-ran my query for my 4 MAC addresses.  Sure enough, there is a LANDesk entry with the MAC as the name.  Just wanted to share because I thought it was cool and never knew it did that!

Anyone know how it does that?  Does the pxe rep send the inventory entry to the core?

There is actually more data in the WinPE mini-scan than what that entry contained.  This entry only contains:

Computer > Device ID

Computer > Display Name

Computer > ID

Computer > Inventory Server

Computer > Last Updated by Inventory Server

Computer > Record Creation Date

Computer > LANDesk Management > Proxy Host Name

Computer > LANDesk Management > Proxy ID

Computer > LANDesk Management > Proxy NIC Address

Computer > Network > NIC Address

Comptuer > Network > Pxeboot

Computer > Network > TCPIP > Address (which lists 0.0.0.0)

Hi,

This should be a faily simple one to answer... As a LANDesk Admin should i be able to schedule a Provioning Template within the console?

The Schedule button is greyed out and there is no option to schedule when I right click. I'm sure I used to be able to do this?!? I just want to do this so I can create Locked versions of my templates without actually pxe booting a machine and selecting the template that way. BTW if I do do that a scheduled task is created in my tasks and a locked template is created (as it should).

Thanks

D.

We provision several different models of computers through provisioning templates and HII.  It seems that some models are not getting the correct drivers or are not installing at all.  Example:  We are provisonign a Dell E6330 laptopn that uses a USB 3.0 bus driver. I've download the install files, extracted them and put them in the Driver Repository and updated it. 

When the template is complete and the image is installed the USB ports do not work.  I have to manually run the setup to install the files.  Is there a way to install model specific drivers in a template or force HII to find the correct files?

Thanks,

Jim

I am getting an error when my image template starts. The template is able to delete the partitions, and map the imaging drive but it fails at deploying the image. I get the error message Deploying image action failed: [80001803h] Execute return: -1

action index= 68071 type = partition

failed

Error:[80000000h]An unknown error occurred. If the probolem persists contact the landesk administrator

I am using Image X as my image type. I have moved my image to one of our preferred servers as in LDMS 9.5 it has to be stored there for credentials.  Also redeployed my pxe server after all that but I am still getting the error message above.

I have attached my xml file. Also i have attached a copy of the log file from the Provisioning folder.

Any assistance would be greatly appreciated!!!

Prior to 9.5 sp1 I was able to deploy an msi file just by putting for example  \\servername\installs$\flash\install_flash_player_11_plugin.msi in the target path and file name field and a /qn in the command line parameters.  Now after 9.5 sp1 has been applied that is no longer working.   The task just hangs forever with no errors or anything.   Is this by design?

Create Partition

To reduce the number of actions needed in a template additional options have been included with the create partition action handler. They include the ability to mount the newly created parittion, format the partition, and make the partition bootable. The ability to create GPT partitions has also been added.

Hardware Independent Imaging (HII)

HII can now be run in both the Post-OS configuration (WinPE) section of provisioning as well as the System configuration section (Client OS). During the Post-OS configuration HII will only apply driver files. Driver setup packages are ignored. During the System configuration HII will apply assigned driver setup packages. Driver INF files are ignored as they should already have been applied in the Post-Os configuration.

Patch System

The option to select the scan and repair settings that will be used has been added.

Template Options

Template options have been added to allow provisioning to run silently, control how long the client GUI is visible after completing and to retain the provisioning folder when the template has completed.

Windows Refresh

Support for Windows 8 refresh and reset have been added. Note that recovery media from your manufacturer may be required. Options for using the local WIM or specifying a WIM are available.

Reset: Deletes all personal files and settings. By default will quick delete files meaning files could be recovered using special software. Checking the option to fully clean the drive will erase data thoroughly making  recovering deleted files far less likely.

Refresh: Does not affect user data or settings.

Create and assing local WIM: Creates and image of the device in the current statue and assigns it as the local refresh/reset wim.

Assign specified image as local WIM: Assigns a new WIM as the local WIM on the device.

When we open up the Assign tool in 9.5 SP1, the device tree window is blank for all of our desktops (various HP models), except one (see attachments). All of our other systems are Windows 7 professional 64-bit. The model that shows is running Windows XP, 32-bit. A look at the inventory for a particular Windows 7 64-bit model shows an accurate hardware inventory. Any ideas? We ran into this as SP1 seems to have introduced a problem with our imaging. Imaging our machines worked fine under 9.5, but with SP1 any Windows 7 machine we image blue screen traps on boot. Booting in safe mode shows that it gets to disk.sys and the traps with BSD. We assume it is getting the wrong disk driver, but cannot force the selection due to the problem above.

Ideas?

Applies to LANDesk Managment Suite 9.5

Applies to LANDesk Managment Suite 9.5 SP1

Issue:

How do you setup provisioning to deploy a Windows 7 image with the LANDesk imaging tool (IMAGEW.EXE v2)?

What mode is required by provisioning for sysprep?

Solution:

Follow the instructions in the LD95Provisioning document attached to this article.

I've noticed that within LANDesk 9.5 SP1 (could also be within regular 9.5) that when you Apply (Save) a Provisioning Template that it takes much longer than before.

It seems like it may be doing an error check or checking status of distribution packages or actions under System configuration?

Has anyone run into this issue?  Not a huge issue, just annoying if you're constantly editing provisioning templates since it takes a lot longer to save.

Issue:

OSD script is failing with the error -1917386819 in the CJ log when running the imaging command.

Re-creating the OSD script did not resolve the issue.

Permissions are set correctly for the user specified in the OSD script.

Cause:

The image path had a space in the name.

Solution:

Removed the space in the image path then changed the OSD script to use the new path.

Applies to LANDesk Management Suite 9 SP3 and newer

Issue

When selecting a template to run on a WinPE device, or scheduling a template to a machine in WinPE, the template will not start and usually goes through the 40 retries. Looking in the LANDesk Management Console, the machine appears in the task and may show as "Failed" and/or "Off". Often this same template worked just fine in LANDesk Management Suite 9 SP2.

The Prov_Schedule.exe.log file on the Core Server often says "GetDeviceNameAndIP failed" or "Failed to preprod machine"

Cause

This issue is caused by attempting to run a Provisioning template that contains actions in the System Migration section on a machine in WinPE. Most commonly this is seen in a template that has a vBoot or Reboot action in the System Migration section to start the template. Normally this is so that machines that are still in Windows can get into WinPE.

Because the machine is in WinPE, the processes that normally start the template don't function and cause the template to fail, since the first action (Reboot) cannot be run.

Why did this work before?

Many times the exact same template worked perfectly in previous versions of LANDesk 9, and started having problems in SP3. Prior to SP3, there were significant issues on getting accurate and correct status information to the Core server in a timely manner. Many times, all of the machine in the task would have had a status of "Delayed". This status was incorrect and would often persist even after the task had started. However this particular problem allowed templates that contained System Migration actions to skip the entire section when started on a client already in WinPE. Basically another problem allowed functionality that shouldn't have existed. In SP3, the status and task information is much more correct and timely, meaning machines in WinPE can no longer take advantage of the error and skip the System Migration step.

This is the intended functionality. While many templates simply have a Reboot action to get the machine to WinPE, the System Migration section could contain other actions that could be vital. For example, it could be capturing a profile or backing up files prior to imaging the machine. Skipping those actions could be detrimental.

Solution

At present, the best solution is to remove the Reboot (or vBoot) action from the System Migration section of the provisioning template if you would like to start the template on machine in WinPE. That would apply to machines where the template is manually selected from the menu, or the template is scheduled and the machine booted to WinPE.

Another template that DOES contain the Reboot (or vBoot) action can be created and used to target clients that are still in Windows and should be rebooted to get into WinPE. The simplest way to do this is to right-click the current template and select Clone and modify it as needed. Alternatively, the WinPE template (the one without the Reboot action) could be included in another template. Then just add a Reboot action at the beginning. That way any changes to the overall process can be made in just the WinPE template and will automatically "sync" with the template containing the Reboot.

We are currently testing LANDesk 9.5 SP1 and I have noticed that for some reason there a bunch of distribution packages (some are .bat/others are .exe) that fail under provisioning under System configuration action.

Funny thing is the same packages work on LANDesk 9.5 SP1 if you run them as distribution packages and schedule them and they also still work with provisioning in LANDesk 9.0 SP3.

Has anyone else run into this?   Have tried rebuilding packages, resetting hashes, etc.  Logs dont show much useful except they failed to install.