This article applies to LANDESK Management Suite 9.6 SP1 and later

Information

LANDESK Management Suite 9.6 SP1 includes support for OS Provisioning clients to download vBoot related files from a PXE Server.

Now the Boot.wim file that contains the Windows PE image does not have to come directly from the Core.  A peer or preferred server can now be utilized.

The boot images are over 200 megabytes so it can be important to store the boot images on the local subnet or in a more optimal location for the client than the Core may provide.

New "Attempt Peer, "Attempt Preferred Server", and "Allow Source" radio buttons have been added to the "Boot to Managed WinPE (Virtual Boot)" selection for the "Reboot/Shutdown" Provisioning Action.  Note: Downloading of the boot.wim from Preferred Server or Peer at this time only applies to Vboot (Virtual Boot).  It does not apply to PXE boot.

This eliminates the need for the clients to go back to the core to download the 200+ megabytes of support files in order to virtual boot.

In order for the vboot files to be accessible to the clients, the proper web share must be configured on the Preferred Server.

Resolution

Attached to this article is a .ZIP file Containing the following:

• Deploy PXE Rep and Configure IIS.ldms  (Package Bundle)
• ps-pxe-setup.bat

Steps to import and configure package bundle.

1. Download the attached PreferredServerWithPxeHostVboot.zip file
2. Unzip the downloaded .zip file to a desired location on the core server.
3. Open the Distribution Packages tool in the LANDESK Management Suite console.
4. Right click "My Packages" and select "Import"
5. Browse to the location where the .ZIP file was uncompressed to.
6. Double click the Deploy PXE Rep and Configure IIS.ldms file.
7. This will import a package bundle into the LANDESK Management Suite console under "My Packages"
   Click here for more information about Package Bundles.
8. Within this bundle you will find a package called Configure Preferred Server to host vboot files.
9. In addition this bundle contains the default PXE Representative Deployment package.
10. Copy the ps-pxe-setup.bat file to your regular software distribution share.
11. Modify the properties of the Configure Preferred Server to host vboot files package for your environment

          a. Modify the server name under the Package Information section to reflect the proper server name for your package share

          b. Under the Additional Files section browse to the location where you have copied the ps-pxe-setup.bat file and add it as an additional file
              (By default in the imported package this defaults to http://coreservername/ldlogon.

Scenarios for distributing package bundle or only the distribution package:

Scenario 1:

• PXE Representative is already installed on the Preferred Server

    In this instance, you can simply select the package Configure Preferred Server to host vboot files, right-click and select "Create scheduled task".

Scenario 2:

• PXE Representative is not installed on the Preferred Server and you want to configure IIS to host the vboot files

          In this instance, right-click the package bundle called "Deploy PXE Rep and Configure IIS" and select "Create Scheduled Task".

     This will first configure install the PXE Representative and then configure the Preferred Package Server to host the vboot files in a Web Application called "landesk" and a virtual directory below that called "vboot"
     This virtual directory points to the following physical path:

"%programfiles(x86)%"\landesk\pxe\system\image\boot"

Note

This solution couldn't be applied for XP clients. This is due to a difference in the BCD between XP and Vista

You can find more information in the link below:

https://support.microsoft.com/en-us/kb/919529

As XP is EOL for more than 1 year, the decision has been made to not support this OS for this feature

Introduction

LANDESK Operating System Deployment has been created in such a way to allow users to utilize any imaging tool they would like. There are a number of imaging tools available for use on the market and LANDESK users can determine which of these tools is best suited for their needs.

LANDESK Management Suite contains the LANDESK imaging tool ImageW as a starting point, or basic option for customers to use.  It is a sector based imaging tool, meaning it captures and stores the image based on the sectors on the disk, ignoring what those sectors represent, be it OS files, data, applications, etc. The image is then deployed back to machines by laying the same data back onto the hard drive, sector by sector

What is ImageX

Microsoft also has developed an imaging tool called ImageX. This tool is a file based imaging utility. This means it captures and stores the data on a file level instead of a sector level. Files captured by ImageX will have the file extension of .wim. This provides some additional functionality that is usually not afforded in a sector based deployment. For example, ImageX uses single-file instancing, meaning if a file is present in more than one location on the hard drive, it will only be captured to the image once, saving space. When deployed the file will be copied to all original locations. Microsoft uses ImageX for all OS installations starting with Windows Vista. More information about ImageX can be found here: http://technet.microsoft.com/en-us/library/cc722145%28WS.10%29.aspx

Using ImageX

Because ImageX uses an entirely different type of technology for imaging, there are a number of important differences to consider if ImageX is to be used with LANDESK Management Suite:

• ImageX images must be targeted to an existing and formatted partition.
  • With sector based imaging, the partition table is put down with the imaging process. However ImageX must be targeted to an existing partition. One particular benefit with ImageX is that it can be put onto a partition of any size regardless of the size of the partition it was captured from. With sector based imaging, the image must be deployed to a disk of equal or greater size that than what it was captured from. With ImageX, the only restriction is that the partition must be large enough to contain all of the data that is to be deployed
• Multiple images can be stored in a single file.
  • This is most evident in the Windows 7, 8, 8.1 and Server 2008 and 2012 installations. The image file (.wim) is the same for all versions of these products, and the correct version (Ultimate, Datacenter etc) is pulled from the image. This process again utilizes the single file instancing. This means that a file that is part of all 3-4 images in the .wim file is only present in the .wim file once, but deployed as needed for each distinct image.
• Images created with ImageX can be edited, added to, or modified after image capture.
  • This is a very compelling feature available from ImageX. After an image is captured to the .wim file, it can be mounted into the file system and navigated as if it were a normal folder. This allows for the extraction and addition of files to the image as needed allowing updates to be applied to the image without deploying and re-capturing the image as is required with sector based imaging.
• ImageX is a command-line only application.
  • This means there is no GUI or interface for ImageX. All commands must be run from the command-line.

It is very important that if ImageX is going to be used to capture and deploy images with LANDESK Management Suite, the ImageX documentation and information should be carefully reviewed. You can find this information on Microsoft's web site.

ImageX Technical Reference: http://technet.microsoft.com/en-us/library/cc748966%28WS.10%29.aspx

What is ImageX: http://technet.microsoft.com/en-us/library/cc722145%28WS.10%29.aspx

ImageX Command-Line Options: http://technet.microsoft.com/en-us/library/cc722145%28WS.10%29.aspx

Windows Imaging File Format (WIM): http://technet.microsoft.com/en-us/library/cc749478%28WS.10%29.aspx

ImageX and LANDESK Management Suite

Using ImageX as part of and Operating System Deployment (OSD) script is quite straight forward. From the OSD script in the Image information screen, select the image type as ImageX, and provide the path to ImageX and the image store location

LANDESK will then generate a basic imagex command line to capture or deploy the image. Please note that LANDESK creates a BASIC command line and does not add any advanced or complex ImageX functionality.

Default capture command line:

imagex.exe /compress fast /capture C:  i:\%Computer - Device Name{8}%.wim "Drive C"

• This will create an image using the Fast compression algorithm (not Maximum), captured from drive C, to the file I:\(Final 8 characters of the device name or MAC).wim and name that image file inside the .wim "Drive C"

Default deploy command line:

imagex.exe /apply i:\filename.wim 1 C:

• This will apply the image in spot/ID 1 inside filename.wim to an already partitioned and formatted C: drive

If you need to use any additional options or settings when capturing or deploying the ImageX image, you will need to add these using an "Advanced edit" of the script. For more information on using "Advanced edit" please see the following article: Advanced edit of OSD scripts

Getting ImageX

ImageX is contained in the Windows AIK.  This can be downloaded freely from Microsoft.  It is typically located in \Program Files\Windows AIK\Tools\x86 after the Windows AIK is installed.  Once the ImageX executable is obtained, it is completely portable. A copy of ImageX should be placed on a share accessible to client machines, for example \\core\ldmain\osd\imaging\

Conclusion

ImageX provides additional functionality, capacity and tools for imaging and deploying computers. It can be used for simple or complex imaging tasks. Due to the different imaging technology (file-based vs. sector-based) it should be carefully evaluated, studied and tested before applying on a large scale. LANDESK can be used to run a ImageX commands to capture and deploy images, but by default they are very basic. If any changes are needed they can be added manually and must follow the documentation provided by Microsoft. LANDESK does not provide support for the ImageX tool, but only for the process of running the ImageX command. If ImageX itself is not running as expected, please consult Microsoft for assistance.

Purpose

This article covers Frequently Asked Questions (FAQ) regarding the LDMS PXE Representative.

What specs does a PXE rep require?

The PXE rep service is very lightweight when it comes to system resources needed to run.

The machine selected to act as the PXE rep:

• Must run a Windows OS
• Be a supported agent OS for the build in use - https://community.landesk.com/support/docs/DOC-23848
• Requires wired network access to hand out DHCP packets for PXE booting

Can I have one PXE rep in use for multiple subnets?

PXE reps are designed to be used per subnet. This means that each subnet should have its own local PXE rep. This is untested and unsupported.

Can I install a PXE rep on my DHCP Server?

Because of the way PXE reps handle dhcp options related to PXE booting, the rep should not be installed on your DHCP Server. This is untested and unsupported.

This video demonstrates how to capture a profile using a provisioning template.

HII Driver Management

Hardware-Independent Imaging is a vital part of a successful imaging process. Additional features have been added to provide control and flexibility to the drivers being deployed to devices. The ability to disable drivers, assign drivers to specific hardware, and assign setup drivers has been added. It is not required to assign drivers, auto detection and assignment of drivers will still occur for devices that do not have a specifically assigned driver. The HII driver library should be rebuilt after applying Service Pack 1 to update the HII driver client database (drivers.db3).

The HII driver management has been moved from an icon on the Operating system deployment toolbar and is now a a tool in the Distribution Toolbox

Disable drivers

After building the HII library you may notice that some drivers automatically have new entries under disabled. The drivers were disabled for the generic matches included in the inf file that would have matched hardware the driver was not designed for. Reviewing these entries will show device IDs beginning with *PNP, indicating the driver could match a number of plug-and-play devices. If the driver is needed for a device in the environment, the entry can simply be removed from the disabled list.

When adding a driver to the disabled list, the driver library folder structure will be shown. Locate and select the inf file for the driver to be disabled. After selecting the driver the list of available OS and architecture will auto populate with the versions found inside the inf you selected. Set the desired OS and architecture to list the available device IDs for the selected driver. Check the disabled box for the device ID to disable and click update to disable the driver. Select any other OS and architecture combinations and disable as needed. When complete click update and close.

Assign Drivers

Assigning drivers will be matched on the make, model, OS and architecture of a device. The inventory scan now includes hardware IDs for use in HII driver management. When a driver is being assigned the hardware listing will only be shown if a devices has returned an inventory scan from an Service Pack 1 agent that matches make, model, OS and architecture.

In this example Windows 7 is selected, however on the core server there are no devices on Windows 7 for that make and model so the device tree is blank.

A device running Windows 8 for that make and model does exist, so when selected the device tree is shown.

Assign Driver .inf file

After selecting the desired option in each of the drop-downs, locate and select the device that will be assigned a driver from the device tree. The option populate by selected device ID can be used to auto fill the search box.

Searches can be made more generic by searching for just the vendor id and device id. Other Device IDs that would apply can be viewed on the device if no driver is found.

Check the appropriate driver to assign it to the selected device. Once assigned the text for the device will turn green to indicate an assigned driver. To remove the assignment, select the device and click the red x next to the assigned driver.

Assign Driver Package

Devices requiring a setup package can also be assigned. Selecting the radio button driver package and select the appropriate software distribution package for that device. In the provisioning template add an HII action in the system configuration section to install the setup packages.

Managing Assigned and Disabled Drivers

Assigned and/or disabled items are visible in the console. Those entries can be edited and removed by selecting the item and the selecting edit or remove.

Error message:

Could not map or unmap drive. Error code: 2250

Problem:

In X:\Ldprosivion or C:\Ldprovision folder, you open the file MaptoPreferredHandler.log and read the following;;

2015-09-01 23:28:46(520-1624) maptopreferredhandler.exe:******Mapping to: \\core95sp3.sebdomain.local\PRC_Landesk_Files\Images\LatestWin7\LatestWin7.TBI

2015-09-01 23:28:46(520-1624) maptopreferredhandler.exe:Drive letter = e

2015-09-01 23:28:46(520-1624) maptopreferredhandler.exe:Mode - Attempt preferred server.

2015-09-01 23:28:47(520-1624) maptopreferredhandler.exe:Could not get credentials for preferred server.

2015-09-01 23:28:47(520-1624) maptopreferredhandler.exe:End of Map Drive.  Path used: - \\core95sp3.sebdomain.local\PRC_Landesk_Files\Images\LatestWin7\LatestWin7.TBI.

2015-09-01 23:28:47(1448-1452) maptopreferredhandler.exe:******UnMapping Drive

2015-09-01 23:28:47(1448-1452) maptopreferredhandler.exe:Drive letter = e

2015-09-01 23:28:47(1448-1452) maptopreferredhandler.exe:Could not map or unmap drive. Error code: 2250

2015-09-01 23:28:47(1448-1452) maptopreferredhandler.exe:End of UnMap Drive.

Cause:

There is a big chance that there is an authentication issue when trying to map to the server "Core95sp3.sebdomain.local"..

Solution / Workaround:

To solve it, you need to be sure that the preferred server exists with the same "Server name" than the one mentioned in your UNC path; In our example; core95sp3.sebdomain.local and if that's core95sp3, it may not work. To do it, follow these steps;

1. - On the LDMS Console,go in Menu Configure > Preferred Server > A window "Preferred Server Properties" opens
2. - On the "Configuration" tab,
   1. Enter the server name core95sp3.sebdomain.local
   2. Enter the User name having some READ rights on the share drive when you stored your file
   3. Enter the password twice
   4. Press on button "Test Credentials" > A "TestCrentials" window opens
      1. Leave the box UNC checked
      2. Click OK > A "Test Credentials" window opens
         1. If that's "UNC Authentication successful", then you are ready to go
         2. If that's "UNC Authentication failed", then it could be due to some different issues;
            1. Be sure that you defined well the UserName and Password
               
            2. Be sure, that you can access to the UNC path with this credentials defined via a CMD
            3. Close all the current LDMS consoles opened and restart the Console on the Core Server to do another TestCredentials test
            4. On the Core Server, do a test net use * /d /y because the server has a remembered connection to the target device under a specific set of credentials and will not allow multiple connections to be created with different credentials
            5. Close all the Window Explorer windows and try again
               
            6. Check if there isn't any mapped drive on the computer where you are doing the TestCredential test and try to disconnect the one corresponding the server name
            7. Create a specific account to have access to this share and do the TestCredential
   5. If still not working after a test, yyou may also have an issue with the boot.wim deployed on the PXE Server, and in that case;
      1. Follow the instructions given in article https://community.landesk.com/support/docs/DOC-26968
      2. Check as well in the boot.wim (BIOS) or boot_x64.wim (UEFI) when there are mounted (As explained in the article above), if the certificate (File with an .0 extension) is existing on the folder "c:\program files (x86)\LANDesk\Shared Files\cbaroot\certs" and if that's the correct one (You can check it by comparing the name of it with the one on the Core Server in \\<CORESERVERNAME>\ldlogon shared folder. If that's not the one, copy the .0 file from the ldlogon folder and paste it in the boot.wim mounted and proceed as followed in the article mentioned above to unmount the .wim then deploy again the PXE through the script.
         

Other interesting links:

Understanding UNC Authentication (Preferred Server)

How to troubleshoot Provisioning Template Action Handlers

Applies to LANDesk Management Suite 9.0

Note: If you just want the templates, scroll to the bottom.

Purpose

This article will discuss some advanced options for deploying Windows.  With very few modifications this template should work for deploying Windows XP, or Windows 7 (x86 or x64).

This document is for use with deploying images captured using ImageW v2.  This template will not work for Ghost, ImageX or other utilities.

Difficulties with Imaging

With Windows 7 the process for preparing and deploying images has changed dramatically.  There are very distinct differences to deploying XP vs. Windows 7.  In particular XP has different boot code than Windows 7 and it uses a boot.ini file.  Windows 7 uses a BCD file.  XP generally has the boot partition and the OS partition as the same partition, where Windows 7 will usually have a 100 MB boot partition with the OS on a different partition.  In the case of Windows 7 the boot partition is optional, and may not be there.  To further complicate matters the sysprep answer file for Windows 7 is architecture dependent (32 bit Windows needs a 32 bit answer file and 64 bit Windows needs a 64 bit answer file).

Another problem is that when you are deploying a script you don't necessarily have control over how many partitions are on the device until you clean it.  This can cause drive letters to change.  For example, if you have a 1 partition device being imaged with a Windows 7 install that has 2 partitions you will see that when you go into WinPE your single partition is labeled C and your CD-ROM device is labeled D.  When you format and lay down the image you get two new partitions.  In the scenario of Windows 7 with a boot partition your boot partition would now be labeled C and your OS partition would be E (because D is already given out).  If you try to inject the Unattend.xml file to the C drive it won't work, because it is NOT the OS drive like you would expect.  If you have 2 partitions already and then image you will probably have a C drive boot partition, a D drive OS partition and an E drive CD-Rom.  Do you inject your unattend.xml into the C drive, D drive or E drive?  The answer is that it depends on the amount of partitions on the incoming drive and whether WinPE recognizes the CD-ROM drive or not.

Solutions in OSD (not Provisioning)

Our OSD tools are very simple to use.  You fill in a few boxes, select a few options and you get a customized deployment script that will work on your OS and architecture type, regardless of number of partitions.  It would seem that there must be a lot of differences between, for example, a Windows XP x86 image deployment script and a Windows 7 x64 image with boot partition deployment script.  In reality there isn't much difference at all.  The most notable difference is actually where and in what format we save the unattend.xml (or sysprep.inf) file.  All the other lines of code end up being very nearly the same if you have the same options selected.

That brings us to the question of what OSD does to make it so simple?  The answer is in two executables and a script that are run.  The first executable is FixWindows and the second is FixUnattend.  The script that is run is a DiskPart script called rmvol.txt.  Each handles one aspect of the complexity of OS Deployment when handling multiple OSes.

FixWindows will dynamically determine if the device is using Windows XP style booting (boot.ini) or Windows 7 style booting (BCD).  For Windows 7 it will also determine if there is a separate boot partition or if the boot partition and OS partition are the same.  It will then make sure the bootsector is set up correctly and that the boot file has all the appropriate information.  One additional benefit is that it will automatically remove the drive letter assignment for all hard drive partitions except the OS partition, which it will label the C drive.  This is true regardless of number of partitions that you come in with.  This utility is gold for someone who is working with a mixed OS environment, or any scenario where the number of partitions won't be 100% consistent across all hardware!

FixUnattend is a little simpler, but takes care of the 32-bit vs. 64-bit unattend.xml for Windows 7 issue (sysprep.inf for Windows XP is unaffected).  All of our unattend.xml files are created for 32-bit installs.  If you are running a 64-bit install you need to change the tags from Architecture="x86" to Architecture="amd64".  Other than that the XMLs are identical.  FixUnattend will determine the architecture of the newly imaged OS.  If the new OS is 32-bit then the unattend.xml is left alone.  If it is 64-bit then FixUnattend will convert every line that points to the 32-bit architecture to say 64-bit instead.  In this way one unattend.xml file can be used for both 32 and 64-bit images.

Rmvol.txt simply removes all the drive letter assignments at the beginning of the OS Deployment process.  This will make it so that we start off in a known state (no drive letters are assigned, we will give the first disk's first partition the letter C, next partition D, and move on from there).  This utility ensures that we don't have the CD-ROM drive taking over a drive letter that we need and that we can easily map a drive letter to an exact partition.  FixWindows.exe relies on this being run at the beginning of the script.

Difficulties in Provisioning

Provisioning, by comparison, has nothing pre-made for you.  The idea is you can do whatever you want.  There are no limits to how things are set up.  The down side is that nothing is pre-made for you, the idea is you can do whatever you want, and there are no limits to how things are set up.  By its very nature provisioning is supposed to be about you doing what you want without any guidance or suggestions.  This means that all the useful fixes and tweaks that are found in OSD are not there, because you might not want to use them.

Solution to difficulties in Provisioning

The good news is that we can use the OSD utilities within Provisioning!  We just need to explicitly state that we want to use them.  To use the attached OS Deployment template please follow the instructions listed:

  1.  Download the template and (if desired) sample unattend.xml file.

  2.  Create and assign values to the following variables (or replace the variables in the templates with their real values):

NOTE: Variables are case sensitive

a - lddomain - The domain in the environment.  This will be used along with the lduser and ldpass to map a drive to the imaging share.

b - lduser - The username that will be used with lddomain and ldpass to map a drive to the imaging share.

c - ldpass - The password that corresponds to lduser.

d - ImageShare - The unc path of the share where the image is stored.  Should be in format \\server\share.

e - Win7ProdKey - Only needed if you are using the attached unattend.xml.  This is the Windows 7 product key in the format 12345-67890-ABCDE-12345-67890.

f - owner - Only needed if you are using the attached unattend.xml.  This will fill in the Owner field on the computer properties.

g - organization - Only needed if you are using the attached unattend.xml.  This will fill in the organization field on the computer properties.

  3.  If using the attached unattend.xml import it to be used in the template.

  4.  Go to the Post OS Installation section of the template to the Inject Win 7 Unattend File action and select the file you imported in the previous action, or select the unattend.xml file you would like to use.

  5.  Schedule and run the template.

Detailed Information

The attached OSD template will run the following sequence of actions:

Run the Diskpart script rmvol.txt.  Rmvol.txt is already included in the WinPE image under X:\LDClient, so there is no need to do anything special other than an execute file command.

1. Run a Remove all partitions action.
2. Map a drive to the image utility share (where ImageW v2 is located.  This should be %coreIP%\ldmain, unless ImageW has been moved).
3. Map a drive to the image storage share (where you save your .tbi files).
4. Actually deploy the image.
5. Extend the final partition (so the OS partition utilizes all available space).
6. Download FixWindows.exe and all dependencies it requires.
7. Execute FixWindows.exe.
8. Inject the unattend.xml file (in the example it is for Windows 7).
9. Run HII.  This action is set to proceed if it fails because if you have no drivers set up for a piece of hardware this will fail.
10. Download and execute FixUnattend.exe.
11. Run Configure Target OS.

By running this sequence of actions we get the robust solutions available in standard OS Deployment while maintaining the advantages of Provisioning!  Additionally if you make the following changes this can become an OS Deployment script for XP instead of Windows 7.

1. Change the target OS for the template from Windows 7 to the desired version of Windows.
2. Remove and re-add the HII action.  This will apply the change of OS to that action.
3. Choose the appropriate sysprep answer file in the Inject Script action.

Conclusion:

With simple minor edits this template should be able to be seamlessly integrated into a larger end to end provisioning template without worrying about what OS, architecture, hardware, number of partitions, etc.

Note: The attached templates are only valid for 9.0

Hi All, i tested a workaround to deploy OEM images or images without having to use sysprep, meanwhile it could be useful in bypassing issues on ConfigureTargetOS action in provisioningMaybe it’s not really a supported procedure but it worked for me, I hope you will appreciate.

CONSIDERATIONS

Maybe it’s not more useful and a bit old-fashioned deploying non sysprepped images, but someway I found many customers with this need for a back-up, for their OEM environment to avoid some boring post OS configuration or software distribution.

My principal mean was to underline the step in which we bypass the Configure Target OS action that often caused issues and get guys crazy working on it.

CTOS is finally,once for all, perfectly, explained in doc http://community.landesk.com/support/docs/DOC-6948)

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

If the LANDESK agent is already installed on the image you have to capture, you can copy ldprovision files and then force ldprovision.exe to run at startup using Actions.ini file of CBA.

The ldprovision agent does not need to be installed because it uses the CBA services that are already active, so it’s enough copy the few files that ldprovision.exe needs in a folder to the C: drive of the computer and then run ldprovision.exe at the right time.

When the new OS boots I select few files from \\core\ldlogon\provisioning\windows and it worked.

Why you cannot schedule template as all other tasks or distribution? It will be a marvellous thing, combining software distribution with system-configuration with reboot and so on.. also for managed devices non only for OS deployment.

I attach the file with my work

Regards all

DISCLAIMER:  This process is not supported by LANDesk Support.  Use this process at your own risk.

Windows System Image Manager (SIM)

Windows System Image Manager is a tool created by Microsoft to manage and create answer files for Windows 7, 8, 8.1, Server 2008, 2012, and Server 2012 R2. The answer files can be used both for full unattended installations of Windows, and to automate the mini-setup, now known as the Out of box experience (OOBE). It automatically writes the XML from a wizard-like tool and validates the answer file against the selected installation source.

Installing System Image Manager

System Image Manager is part of the Windows Automated Installation Kit (WAIK). It can be downloaded from Microsoft. You should download and install the most recent version of WAIK as it is backwards compatible. Once installed you will find the System Image Manager under the Windows AIK program group.

Using System Image Manager

To take full advantage of SIM, make sure you have access to the install.wim file for the OS you are installing. This will allow you to validate the answer file and provide the correct options. You can create an answer file without access to the .wim file, but some functionality will be limited.

1) Click on New Answer File

2) A message will prompt you to select an image file. Select yes, then navigate to the appropriate .wim file. Once you select the .wim file, you will be prompted to create a catalog. Select Yes.

3) Once the catalog file is created, you will see a screen similar to the following:

This is the standard editing window for creating the answer files. The configurable sections and values are in the Components section in the lower left panel. Once a property is selected, the configurable values will appear in the right panel.

Each property can only be assigned to certain "Passes". The passes are listed in the middle pane. They are:

1. windowsPE
2. offlineServicing
3. generalize
4. specialize
5. auditSystem
6. auditUser
7. oobeSystem

These passes are run in order and each property, or action in each section is run in the order listed.

A variety of configurations are needed in order to make a fully unattended installation. More information about what is needed to fully automate the installation can be obtained from Microsoft TechNet.

Some good TechNet articles to review:

Windows System Image Manager Technical Reference

Step-by-Step: Basic Windows Deployment for IT Professionals (Windows 7)

What is Windows System Image Manager?

Windows Setup Configuration Passes

Understanding Windows Image Files and Catalog Files

Once the answer file has been completed and validated, it can be used in LANDESK by either installing the script for provisioning, or using it as a template in an OSD script.

If your company is like mine, then you might be faced with strict budgets and that may find your hardware getting replaced with the AMD chipset.  Since all our previous hardware was Intel, this was all new to me and I must say, it was a headache.

I have my Universal Image based off of Jan Buelen's whitepaper on Hardware Independent Imaging - rev 9.1found here - http://community.landesk.com/support/people/jan.buelens/blog/2009/07/10/hardware-independent-imaging--rev-91

The problems I faced was:

• No AMD Sata Driver support in WINPE
• Intel CPU driver conflict with AMD CPU

AMD SATA Driver support is fixed with Jan Buelen's latest WinPE DriverPack - found here - http://community.landesk.com/support/people/jan.buelens/blog/2009/06/18/winpe-driverpack-tool--bring-your-winpe-image-up-to-date-with-all-the-latest-drivers

The second issue I had was now that I have WinPE recongizing the hard drive.  I could lay down my universal image, inject the drivers, msd and hal. Upon it's first boot up I was presented with a BSOD. I quickly assumed that there was still mass storage drivers issues, however if you hit F8 and during boot and choose DISABLE AUTOMATIC RESTART ON SYSTEM FAILURE.  I noticed I was presented with a different error:

STOP 0×0000007E error and notSTOP 0×0000007B error

This lead me to this microsoft article: http://support.microsoft.com/kb/953356

Error message after you upgrade a computer that uses a processor other than an Intel processor to Windows XP Service Pack 2 or to Windows XP Service Pack 3: "STOP: 0x0000007E"

To sum up:

All I need to do is modify the following registry value

[HKEY_LOCAL_MACHINE\System\ControlSet001\Services\intelppm]

Set Start to 4

This disables the Intel Processor Driver from loading during boot.

I created a .reg file with this entry (attached) and placed it in my msd folder and InjectMSD loaded the modification and now your Intel based Image will boot and go through sysprep, load drivers, ect...

I attached my exported registry modification that I use for InjectMSD.  I hope this helps.  Thank You Jan for the help and the awesome work you put out here.

One of the most common uses of Provisioning is to extend the capacities and functions of imaging or new device deployments to include the installation of the OS as well as 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 (abbreviated as CTOS). 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 action. The CTOS prepares the device to resume provisioning after the client boots into the target OS, then restarts the device, 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 device completes booting into the target OS (Windows XP, 2003, 2008, 7, 8, 8.1, 2012). 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 device. 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 device 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 7, 8, 8.1, 2008, 2012

1. All needed files are copied to C:\ldprovisioning directory on the client device.
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 occurring. 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 occurring. 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 device will stay in WinPE after the template fails so troubleshooting can be done in the exact condition the device 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?
4. Check for the ConfigTargetOSHandler.log in SystemDrive\Windows\Temp. This will normally show where the failure may have occurred if you get errors during file copy/creation.

If you deployed:

     Windows XP/2003

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

   1. 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 7, 8, 2008, 2012

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.

     Windows 8.1

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 content of the file %windir%\Windows\Setup\scripts\SetupComplete.cmd contains the following line; %systemdrive%\ldprovisioning\ldprovisioning.cmd

Sometimes all of these will be correct and ready to go, but the device 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 device to resume provisioning after the whole mini-setup process is complete.

Windows 7, 8, 2008, 2012

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, the RunSynchronousCommand action is added calling ldprovisioning.cmd from C:\ldprovisioning\. The section of the unattend will look roughly 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>

Windows 8.1

As mentioned in Add a Custom Script to Windows Setup a command line is injected within the SetupComplete.cmd (%systemdrive%\ldprovisioning\ldprovisioning.cmd) which will then be run after the reboot following the mini-setup phase. Hence, the system will follow the provisioning process when rebooting.

In Windows

Once the device completes the mini-setup section, it will boot into the final OS. As the device 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 device completes 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 capital 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.

───────────────────────────────────────

See also CTOS action fails after reboot.

The following flowchart illustrates the process flow for the PXE process used with LANDESK to PXE boot machines.

(Click image for expanded view or download the attached image file)

Issue

LANDesk Antivirus or Policy Invoker Service is not installing with the agent during the sysprep process on OS deployment

Cause

The network drive to the LDLogon folder is being deleted before the Agent installation completes.

Resolution

Windows XP, Windows 2003, Windows 2003 R2:

1. Do an Advanced Edit on the deployment script (right click and select "Advanced Edit")  (two files will open, one .ini and one .inf)
2. In the .inf file, REM (;) out or delete the Command3 line. (Command3="net use \\coreservername\ldmain\ldlogon /d /y")
3. Save the file
4. Run OS deploy on new machine.

Windows 7, 8, 8.1, 2008, 2012:

1. The file that needs to be edited is a XML file, So execution may vary depending on how you computer is configured to handle viewing XML files. The instructions are written as if you need to manually find the file and open it with notepad.
2. Browse to <coreserver>\LDmain\Landesk\files
3. Locate the .XML file with the name of your OSD deployment script.
4. Open the .XML with notepad.
5. Locate the and change the following as shown.

<SynchronousCommand>  <CommandLine>net use \\core90v2\ldlogon /d /y</CommandLine>  <Description />  <Order>6</Order>  </SynchronousCommand>
- <SynchronousCommand>  <CommandLine>cmd /q /c del /q c:\ldiscan.cfg</CommandLine>  <Description />  <Order>76</Order>  </SynchronousCommand>

Note: If you do a regular edit on the script and save the script, it will overwrite the .ini and .inf file and put the command3 line back in.  So if you have to modify the script, make sure that you do the advance edit on the script when you finish and remove the command3 line again.

When double-clicking an OSD script, the default action is a standard edit using the OSD script interface. However, there is also an Advanced edit feature available by right-clicking on the script and selecting "Advanced edit"

Why use Advanced edit

When LANDESK creates OSD scripts, they are created with the most common and basic options for each imaging tool. Additionally, the process to prepare the computer is very generic. This is so that the basic scripts can work in the majority of cases and cover the most general and common imaging tasks. However, sometimes additional functionality is needed or a more complex series of actions is desired during the OSD task. In this case Advanced edit allows you to modify the OSD script manually to add any needed functionality or changes.

Using Advanced edit

OSD scripts are written using the LANDESK custom scripting language/tool. Information about using custom scripts can be found here: The specified item was not found.. When Advanced edit is selected, the associated scripts will open in the default text editor. In the case of a capture script a single .ini file will open. In the case of a deploy script, an ini and an inf will open. The ini is the OSD script and contains the commands that will be run on the targeted machine. The inf is the sysprep file that will be deployed. Once any changes to these files is saved the script has been modified and the changes will be reflected in the next execution of the script.

Important Note

If the script is opened in the regular edit OSD script interface and saved, any custom changes will be overwritten in the script with the default values and configuration!

If you would like to prevent changes from being made via the OSD script interface, thus protecting any changes made via Advanced edit, right-click the OSD script and select Disable edit. This will disable the standard edit and require all modifications to be made manually via Advanced edit. This cannot be undone, and edits can still be made manually. If you need to disallow any edits, set the ini file (found in \\core\ldmain\scripts) to read-only.

Issue

The following error occurs when attempting PXE boot:

PXE-E74 bad or missing PXE menu and or prompt information

This issue can be caused by a variety of different problems.   The following describes these different scenarios, causes and resolutions.

For more information on PXE boot errors please see:

PXE Boot errors and descriptions.

For more information on troubleshooting PXE boot please see:

Troubleshooting PXE boot (OSD)

Issue

When machines are attempting to PXE boot they are failing with one of the following errors:

BOOT SERVER IP: x.x.x.x MFTP...PXE-T00 Undefined error code

PXE-T01 Undefined error code

PXE-E36: Error received from TFTP server

PXE-M0F: Exiting (NIC Manufacturer) PXE ROM

Cause

PXE Representative is failing to give a valid multicast address for Startrom.0 file.

This is being caused by the PXE Representative attempting to redirect the Client machine to a PXE rep in another subnet for file download.

Resolution

Currently there are 3 solutions:

1. Remove all PXE Representatives except the one you are attempting to use.
2. Install a PXE representative on the same subnet as the computer being PXE booted.
3. 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 is in the script or template.

Instructions for how to manually disable Multicast

This will need to be performed on all PXE Representatives:

1. On the 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

Further information on PXE boot errors:

PXE Boot errors and descriptions.

How to troubleshoot PXE boot:

Troubleshooting PXE boot (OSD)

Issue

When running a provisioning template, the template fails on the Deploy Image action.

This occurs in Windows PE when running imagew.exe.

The error is "68". The full error is "-2147477501".

Error as seen in Windows PE:

The ldprovision.log file on the client (X:\ldprovision\ldprovision.log in WinPE) will show this error:

2008-02-15 21:32:19(692-696) ldProvision:Launching action handler http://DeployImageHandler.exe with parameters

2008-02-15 21:32:26(1500-1988) DeployImageHandler.exe:execute failed with 68

The following error is seen in the Provisioning History in the LDMS console when viewing the history for the device:

Cause

The disk driver has not been fully loaded and/or the hard drive is still locked when the imaging command is run.

Resolution

• Add a Wait action before the Deploy Image action.
• Start with 30 seconds.
• If that is not enough to fix the problem, gradually increase the wait time until the issue is resolved.

Issue

Imaging a device with a LANDESK Management Agent installed can cause the devices that receive the image to overwrite each other in the database.

Cause

LANDESK inventory looks at a Unique ID/Device ID when inserting the scan. This ID is created when the agent installed on the device.

Resolution

It is strongly recommended that the LANDESK agent not be included in an image.  The recommended way to install the LANDESK Agent with imaging is to use LANDesk Provisioning and include a Configure Agent action in your provisioning template.  Besides causing duplicate devices, the LANDESK agent is often updated and adding it to the image will quickly cause your image to be outdated. 

If the agent must be included in an image or Non-Persistent VDI image, the unique identifiers must be deleted out of the registry prior to the capture of the image.  Before creating an image of the machine do the following:

LANDesk Mangement Suite 9.0 and later

1. Install the LANDESK agent, then STOP all LANDESK related services
2. Delete the following Registry Keys for 32bit clients:

           HKLM\SOFTWARE\Intel\LANDesk\Common Api\UniqueID
          HKLM\SOFTWARE\LANDesk\Common Api\UniqueID

          HKLM\SOFTWARE\LANDesk\Inventory\LogonHistory\Logons
          HKLM\SOFTWARE\LANDesk\ManagementSuite\WinClient\SoftwareMonitoring\MonitorLog contents

          Delete the following Registry Keys for 64 bit clients:

          HKLM\SOFTWARE\Wow6432Node\Intel\LANDesk\Common Api\UniqueID

          HKLM\SOFTWARE\Wow6432Node\LANDesk\Common Api\UniqueID

          HKLM\SOFTWARE\Wow6432Node\LANDesk\Inventory\LogonHistory\Logons

          HKLM\SOFTWARE\Wow6432Node\LANDesk\ManagementSuite\WinClient\SoftwareMonitoring\MonitorLog contents

     3. On Windows XP delete C:\Documents and Settings\All Users\Application Data\LANDESK (delete the entire directory and subdirectories)

     4. On Windows 7, 8, and 8.1 delete C:\ProgramData\LANDesk (delete the entire directory and subdirectories)

     5. From the command line (as administrator) in the \LDCLIENT directory run the following

"clientdbutil.exe /create"

     6. Verify that a new database, (LDClientDB.db3) was created in the same path as you deleted above

In addition it is a good practice to ensure that the image does not contain any DRIVERS.DB3 file.

See Community discussion for additional tips and information:

http://community.landesk.com/support/message/61210

Issue

The following error shows up when PXE booting:

PXE-E52: ProxyDHCP offers were received. No DHCP offers were received.

• PXE Boot Fails

Cause

This occurs when the PXE client receives a response from a PXE proxy but cannot contact the DHCP server.

A DHCP server is necessary for network booting to work correctly.

Understanding the PXE boot process

Resolution

Resolve the problem with the DHCP server.

Common issues and things to check

• Is the IP Address scope full?
• Are any addresses available for the PXE client?
• Is network latency causing the client to time out before contacting the DHCP server?
  (Check ping between between client subnet and DHCP)
• Is the DHCP server down or is the DHCP Service stopped?
• Are BootP packets being blocked between the PXE client and the DHCP server?

More information on PXE boot errors:

PXE Boot errors and descriptions.

How to troubleshoot PXE boot:

Troubleshooting PXE boot (OSD)

Issue

When attempting to PXE boot, the following error appears:

• PXE Boot fails.
• No F8 option is recieved by clients.
• Unable to PXE Boot machines.
• Unable to network boot machines.

Cause

• No PXE representatives are deployed.
• Deployed PXE Representative is turned off.
• PXE representative is not in the 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.
• Another service on the server is using port 67

Resolution

• Update BIOS on device
• Ensure that a PXE representative 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® PXE Service" and "LANDESK® 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.
• Run the "netstat -abn" command to find the service which is using port 67 and disable/reconfigure this service.

Note: The PXE Representative may need to be rebooted if the services are running, the firewall is off, but it still does not respond.

More information on PXE boot errors:

PXE Boot errors and descriptions.

How to troubleshoot PXE boot:

Troubleshooting PXE boot (OSD)