/build/static/layout/Breadcrumb_cap_w.png

Blog Posts by jamie_kace

Ask a question

SDA Imaging Best Practices - SDA 6.x

THE PDF Version of this article can be found here:  SDA System Image Best Practices


Introduction

The purpose of this document is to describe best practices in the creation and deployment of Microsoft Windows System Images with the Quest KACE SDA.  This document applies to SDA deployments version 6.0 and higher.

 

Overview

When Windows images are created, one of the roadblocks we have to deal with is the move towards the UEFI architecture. This introduces a level of complexity into creating images that can function in the legacy BIOS mode as well as the new UEFI standard.   Administrators must understand partitioning and how all of the partitions relate to image capture and deployment within the KACE SDA.  With a good understanding of partitions and the architectures, we can limit the number of images that need to be created and still provide full functionality with legacy and UEFI architecture.

 

Pre-Requisites

This document makes the following assumptions:

·         Functional KACE SDA version 6.0 or higher

·         Volume license copy of Windows to use for image creation (We will focus on Windows 10 for the purposes of this document)

·         Virtual Machine available with sufficient disk space (must have over 50% free space left when image is ready to capture)

·         Machines to test image deployment

 

  NOTE : With the first release of Windows 10 Build 1809 (October 2018) and the accompanying ADK/Windows PE version, the Windows PE from this build is NOT compatible with the KACE SDA.    All of the KACE Boot Environments (KBE) should be created from the Windows 10 Build 1803 ADK.  KACE Support is aware of the issue and the PE Build from Windows 1809 will be  supported in the 6.1 release.

Creating KBEs

Creation of KACE Boot Environments (KBEs) are necessary to provide a bootable environment from which an image can be deployed.  This is done using the KACE Media Manager tool provided through the SDA interface.  Always download and install the latest version of the Media Manager before creating KBEs.  Media manager will be updated on almost every release of the KACE SDA Appliance.   The Media Manager Utility must be installed on the same computer on which the Windows ADK is installed.

When creating KBEs, the Media Manager tool will extract Windows PE from the locally installed ADK, and it will inject the drivers in the KACE SDA Drivers kbe_windows_xNN (where NN is 86 or 64).

Y8ndFt.png

KBE Drivers

Create the KBE giving it an appropriate name (like architecture, version of PE, date built, etc.).  for more advanced usage, administrators may want to add PowerShell and/or .Net packages to the KBE but for most purposes these are not needed.

AkQBrm.png

KBE Creation

Once the KBE is created, it will appear in the KACE SDA console in the Boot Environments and the Source Media areas.

 

DHCP Setup and Booting to KBEs

In order to force machines that are booted to the network to contact the KACE SDA, there are options in DHCP that must be set.   Refer to setting up these options in the KACE SDA admin guide or the following articles on the KACE Knowledge Base:

Microsoft DHCP: https://support.quest.com/kace-systems-deployment-appliance/kb/217556

Non-Microsoft DHCP:  https://support.quest.com/kace-systems-deployment-appliance/kb/112037  

Once you have setup DHCP, then you can PXE boot client machines (physical or virtual) to test the KBE loading.  If all goes correctly, you will see a boot menu with imaging options.


KfE2h0.png

KACE KBE Boot Menu

 

Now that we have a bootable KBE, the next step is to focus on building and capturing the System Image that will be used for deployment.

Image Creation

When creating your image in the SDA we suggest that we keep the image simple by using only a single partition, and then add partitions if needed during the deployment.  The first step in creating a master image will be to use the KACE SDA to deploy Windows 10 to a VM.  Using a VM we can easily take periodic snapshots that can be used to revert to previous states as we test and refine our images.

 

Scripted Installation

Using KACE Media Manager, upload the Windows media to the SDA Appliance.  Mount the Windows ISO file as a drive letter on your administrator machine and upload the media to the SDA.

 

Note that you cannot upload the ISO directly to the SDA, it MUST be mounted so Media Manger can read and upload the files within the ISO.  You can also copy the contents of the ISO file to a directory on your hard drive and point the Media Manager to the directory with the extracted files.

 

 

Ml18jY.png 

Media Manager Upload


Once the media has been uploaded, the next step is to build a Scripted Installation in the KACE SDA to deploy Windows.  Follow the Scripted installation wizard and answer the installation questions.  When you get to the image deployment detail page, create a basic installation with a single partition.  Using a single partition will allow administrators to create a system image that will function in Legacy (BIOS) mode or UEFI mode.  UEFI mode will require a second boot partition that can be added to the System image deployment. 

 

nzdANF.png

Pre-Installation Task for single partition image

 

 

You may choose to add any Mid-Level or Post-Installation tasks that you need, remembering that anything you add in the scripted installation will be part of your master image.

Next, we need to prepare the VM and deploy the image.  Create a VM that is set in Legacy (BIOS) mode with 4GB of RAM and enough disk space for the image and applications you plan to install.  Make sure you allow for some spare space on the disk so that you can add patches and applications later if needed.

 

yD54fi.png 

BIOS Mode in VMWare Workstation

 

 

Deploy the Scripted Installation to the VM and once finished you should have a single partition image on the VM.  Verify this by looking at Disk Management in the newly deployed VM.

 


Kpmlal.png

Verify Single Partition Image

 

 

Updating the Image

Now that you have a working Windows 10 installation, it is time to run updates.  Patch the system as much as possible.  Put on any applications that are needed in the base image.  There is not any “perfect” method here, every organization is different.  There are apps that you may want in the image (more complex, large installs), and apps that you might want to deploy using Post Install tasks (easy to deploy via command line, updates frequently). 

 

  Organizations may also want to consider removing bloatware that comes with Windows installations before running sysprep.  There are many tools and scripts out there to help with cleanup of a Windows image.  Quest teams have tested a script that works for most people and we have a copy here:


Quest Windows 10 Cleanup Script


This script is provided as a template and is not supported by Quest in any fashion.  Please use this script only if you are comfortable with scripting and understand that Quest will not be held liable for errors or data loss when running this script.  The script does use various methods for removing applications that are easily found on the internet.

 

Preparing the Image for Capture

Once you have finalized the image, it is advisable to take a snapshot of the image in your Virtual Hypervisor.  Shut down the machine and create the snapshot so that when it is time to update the image, you can revert to this clean state. 

 

ZAEXOE.png 

Creation of VM Snapshot (VMWare Workstation)

 

Creating Sysprep Answer File

When your snapshot has completed, boot into the VM and login to the local administrator account.

Quest provides a simple to use tool that will create and run the sysprep commands on your Windows image so that it can be captured by the SDA.  There are links to the Sysprep Creator Tool in the SDA Tools section.

 

6t2FwX.png 


KACE SDA Deployment Workbench – Sysprep Creator Wizard



Install the Sysprep Creator on the VM image and launch the application.  Select the option to create the unattend and executor file.  This option will generate two files, unattend.xml and sysprep_executor_xNN.exe (where xNN is x86 or x64 based on machine architecture). When launched, the sysprep creator wizard will allow you to configure the installation parameters for Windows.  Run through all of the tabs on the top of the screen making sure to put in admin account information and auto logon parameters which will allow image to run KACE post installation tasks during deployment.  A good value to start with for auto-login is 3.




fEm2m4.png


 

Auto Login Parameter in Sysprep Creator Wizard

 

When completed, save the files on the target machine.  As long as the two files are in the same directory, you can run the executor and it will use the unattend file created.

 

ghzLFd.png

Sysprep Creator Files

 

Launch the executor file and it will perform a pre-requisite check on the system to see if there are things that may prevent sysprep from completing successfully.  If there are any issues, allow the tool to fix the issues or you can manually fix the issues.  Once all the checks are successful, you can run sysprep and select the Sysprep Now, and use the shutdown option.

 

1sgwoy.png 

Successful Sysprep Check

 

 


qbUBlP.png

Sysprep Creator - Shutdown Option

 

When sysprep completes, the system is ready to be captured to the SDA. 



Capturing the Image

Boot the Imaging VM to the SDA and select the Capture Image option, selecting the C: drive and naming the image.  Best practice is to capture WIM images as they can be used for multicast deployment and are typically faster to deploy.

 

H935c7.png


Capturing Windows System Image from Single Partition



Setting up Image Deployment

When the image is captured the Installation Plan of the image will be blank.  In order to deploy the image we must create partitions for deployment and add naming tasks and post-installation tasks to the deployment as needed.  Because the image was created from a single partition image, we can deploy this to a Legacy system or UEFI system when using the appropriate partitioning tasks.

The following ITNinja article describes the use of a combination task that will prepare the disk appropriately based on the architecture of the system that is receiving the image.

 

https://www.itninja.com/blog/view/bios-uefi-combined-tasks

 

We will be using two different tasks for the image deployment for partitioning.  This will allow the single image to be installed on either Legacy or UEFI architectures.  Initially we will consider the simplest configurations for each architecture.  Legacy systems will have a single partition, while UEFI systems will have three partitions used for UEFI architecture.

 

The following tasks for creating BIOS and UEFI partitions are INCLUDED in the KACE SDA version 6.1 upgrade.  You should only have to create these tasks if you are currently running a KACE SDA version 6.0.

 - While administrators can name tasks any way they need, in the examples below the tasks are named as follows:

o   The Pre-Install task -  [DISK] Create BIOS/UEFI Partitions

o   The Mid-Level task -  [DISK] Apply BIOS/UEFI Partitions

 

 


 

Pre-Installation task - [DISK] Create BIOS/UEFI Partitions

The following code should be pasted into a Pre-Installation BATCH task.

***  Copying this text from this document will remove the TAB character in line 3.  Edit this by pasting the syntax below into Notepad or other text editor and add <TAB><SPACE> after the = sign, then copy the updated text into the task.


@echo off

wpeutil UpdateBootInfo

for /f "tokens=2* delims=     " %%A in ('reg query HKLM\System\CurrentControlSet\Control /v PEFirmwareType') DO SET FIRMWARE=%%B

echo Firmware Type: %FIRMWARE%

echo Explanation of Firmware Type: (0x1 is BIOS, 0x2 is UEFI)

if %FIRMWARE%==0x1 goto BIOS

if %FIRMWARE%==0x2 goto UEFI

goto END

 

:UEFI

(

ECHO select disk 0

ECHO clean

ECHO convert gpt noerr

ECHO create partition efi size=200

ECHO assign letter=s

ECHO format quick fs=FAT32

ECHO Create partition msr size=128

ECHO create partition primary

ECHO assign letter=c

ECHO format quick fs=NTFS

ECHO exit

)>X:\Windows\System32\UEFI.txt

diskpart /s X:\Windows\System32\UEFI.txt

goto END

 

:BIOS

(

ECHO select disk 0

ECHO clean

ECHO create partition primary

ECHO select partition 1

ECHO assign letter=c

ECHO active

ECHO format quick fs=NTFS

ECHO exit

)>X:\Windows\System32\BIOS.txt

diskpart /s X:\Windows\System32\BIOS.txt

goto END


:END

 


Mid-Level task - [DISK] Apply BIOS/UEFI Partitions

The following code should be pasted into a Mid-Level BATCH task.

***  Copying this text from this document will remove the TAB character in line 3.  Edit this by pasting the syntax below into Notepad or other text editor and add <TAB><SPACE> after the = sign, then copy the updated text into the task.


@echo off

for %%I in (Z W V U S R Q P O N M L K J I H G F E D C) do (

if exist %%I:\BOOT if not exist %%I:\SOURCES\BOOT.WIM set BOOTSYS_DRIVE=%%I:

if exist %%I:\WINDOWS if not exist %%I:\SOURCES\BOOT.WIM set WINDOWS_DRIVE=%%I:

)

wpeutil UpdateBootInfo

for /f "tokens=2* delims=     " %%A in ('reg query HKLM\System\CurrentControlSet\Control /v PEFirmwareType') DO SET FIRMWARE=%%B

 

@echo on

echo Boot Drive: %BOOTSYS_DRIVE%

echo Windows Drive: %WINDOWS_DRIVE%

echo Firmware Type: %FIRMWARE% (0x1 is BIOS, 0x2 is UEFI)

echo Explanation of Firmware Type: (0x1 is BIOS, 0x2 is UEFI)

 

if %FIRMWARE%==0x1 goto BIOS

if %FIRMWARE%==0x2 goto UEFI

goto END

 

:UEFI

bcdboot %WINDOWS_DRIVE%\windows /s s: /f UEFI

bcdedit /store S:\efi\microsoft\boot\bcd /set {bootmgr} device partition=s:

bcdedit /store S:\efi\microsoft\boot\bcd /set {memdiag} device partition=s:

bcdedit /store S:\efi\microsoft\boot\bcd /set {default} device partition=%WINDOWS_DRIVE%

bcdedit /store S:\efi\microsoft\boot\bcd /set {default} osdevice partition=%WINDOWS_DRIVE%

Bcdedit /store S:\efi\microsoft\boot\bcd /set {FWbootmgr} displayorder {Bootmgr} /addfirst

bootsect /nt60 s:

goto END

 

:BIOS

if not defined BOOTSYS_DRIVE (

bcdboot %WINDOWS_DRIVE%\windows /s %WINDOWS_DRIVE%

)

goto END


:END




 

Once those tasks are saved on your SDA the deployment should be able to use these tasks for any deployment of the created image.


Example of Image Deployment using Partitioning Tasks


421ab1.png


This single installation of the System Image will apply the appropriate partitions regardless of the architecture of the system.


Variations on Partitioning

Now that we have a simple image deployment that will work on BIOS or UEFI systems, we might want to have separate partitions for things like data or profile storage.  Using these tasks above as a baseline, we can modify them to create other partitions if needed.  Edit the section as needed, creating the size of the D Partition as required.  Examples below create a 3 GB D: partition.

Example – Creating a D Partition for Legacy and UEFI systems

UEFI Section of Pre-install Script

:UEFI

(

ECHO select disk 0

ECHO clean

ECHO convert gpt noerr

ECHO create partition efi size=200

ECHO assign letter=s

ECHO format quick fs=FAT32

ECHO Create partition msr size=128

ECHO Create partition primary size=3000

ECHO assign letter=D

ECHO format quick fs=NTFS label="Data"

ECHO create partition primary

ECHO assign letter=c

ECHO format quick fs=NTFS label="Windows"

ECHO exit

)>X:\Windows\System32\UEFI.txt

diskpart /s X:\Windows\System32\UEFI.txt

goto END


BIOS Section of Pre-Install Script

:BIOS

(

ECHO select disk 0

ECHO clean

ECHO create partition primary size=3000

ECHO assign letter=D

ECHO format quick fs=NTFS label="Data"

ECHO create partition primary

ECHO assign letter=c

ECHO active

ECHO format quick fs=NTFS label="Windows"

ECHO exit

)>X:\Windows\System32\BIOS.txt

diskpart /s X:\Windows\System32\BIOS.txt

goto END




Troubleshooting Partitioning

When using physical machines, or even with virtual machines, there may be times where a DVD drive is connected, or a USB storage device (especially if you are using a USB device to boot the KACE Boot Environment).  In these cases, you have to look at the partitions and drive letters that are assigned when the boot environment loads.  You may need to alter some of the partitioning scripts to take those drives and drive letters into account.

To view a particular machine’s disk configuration, boot your device into a KBE and open a command prompt from the Recovery Menu.

t7uAOa.png 



Recovery Menu

 

XO8HFN.png

Command Prompt

 

Using DISKPART commands, we can see the disks and the drive letters being used on the system.  If you see that there are drive letters that you need to use during your image deployment (i.e. Drive D is used for a Windows Boot partition or Data storage) then we will have to reassign the drive letters before we can do an image deployment to this machine.  Below is an example of a machine with a USB storage device and DVD drive attached.

To view all of the disks in the system, using diskpart, you would type LIST DISK.  To view the drive letters, use the command LIST VOL.

jFlqi5.png

Machine with multiple drives

 

In the above configuration, notice that the C, D, and E drive letters are taken by DVD and USB drives.  If we tried to build this machine with a C partition for Windows and D partition for data storage it would fail because the drive letter is already assigned.

To accommodate this, we can alter the partitioning scripts to reassign the drive letters.  The easiest way to do this is by selecting the volume(s) that you want to use and reassigning drive letters that are not in use. 

   NOTE:  The T: and Y: drives are automatically mapped in KBE to directories in the SDA.  When you create new drive letter assignments you should avoid using T:, X: , and Y: drive letters.

To alter the above configuration, you can add the following lines to your disk part script BEFORE you do any formatting of the disk.

SELECT VOL 0

ASSIGN LETTER J

SELECT VOL 3

ASSIGN LETTER K





If you ran those commands manually in the command line of the KBE you would see the following:


W2JKSR.png

Reassigning Drive Letters with DISKPART commands


Now that the drive letters are reassigned, you could proceed with a multi partition installation and create a D drive if needed.

If we look at how the task would need to be modified in the KACE Pre-Installation script, we would have the following Pre-Installation task that could create C and D partitions on the hard drive in either BIOS or UEFI architectures.  The task would reassign the drive letters of the USB and DVD drives so they are free to be used when partitioning and formatting the hard drive in preparation for the image deployment.

Based on your configuration you may have to alter the volumes and drive letters.  The drive reassignment commands are highlighted in red in the example below.

Example – Reassigning Drive Letters and Creating a D Partition for Legacy and UEFI systems

@echo off

wpeutil UpdateBootInfo

for /f "tokens=2* delims=            " %%A in ('reg query HKLM\System\CurrentControlSet\Control /v PEFirmwareType') DO SET FIRMWARE=%%B

echo Firmware Type: %FIRMWARE%

echo Explanation of Firmware Type: (0x1 is BIOS, 0x2 is UEFI)

if %FIRMWARE%==0x1 goto BIOS

if %FIRMWARE%==0x2 goto UEFI

goto END

 

:UEFI

ECHO SELECT VOL 0

ECHO ASSIGN LETTER J

ECHO SELECT VOL 3

ECHO ASSIGN LETTER K

ECHO select disk 0

ECHO clean

ECHO convert gpt noerr

ECHO create partition efi size=200

ECHO assign letter=s

ECHO format quick fs=FAT32

ECHO Create partition msr size=128

ECHO Create partition primary size=3000

ECHO assign letter=D

ECHO format quick fs=NTFS label="Data"

ECHO create partition primary

ECHO assign letter=c

ECHO format quick fs=NTFS label="Windows"

ECHO exit

)>X:\Windows\System32\UEFI.txt

diskpart /s X:\Windows\System32\UEFI.txt

goto END

 

:BIOS

(

ECHO SELECT VOL 0

ECHO ASSIGN LETTER J

ECHO SELECT VOL 3

ECHO ASSIGN LETTER K

ECHO select disk 0

ECHO clean

ECHO create partition primary size=3000

ECHO assign letter=D

ECHO format quick fs=NTFS label="Data"

ECHO create partition primary

ECHO assign letter=c

ECHO active

ECHO format quick fs=NTFS label="Windows"

ECHO exit

)>X:\Windows\System32\BIOS.txt

diskpart /s X:\Windows\System32\BIOS.txt

goto END

 

:END



Conclusion

This guide provides the basic steps needed to create an image and deploy it successfully with the KACE SDA.  While there can be any number of partitioning combinations and drives used on Windows devices, this guide should give you a basic understanding on how you can create a single partition Windows image, and deploy it to Legacy BIOS architectures as well as UEFI architectures, while accommodating various partitioning schemes that may be needed in a production environment. 

View comments (1)

Creating Device Smart Label based on Startup Programs

Creating Smart Label based on Startup Programs

Since Startup programs are not options when creating smart labels, we will need to create smart labels a bit differently with SQL statements.  Here are the steps you should follow:


Go into the KACE console and find the program IDs that you want to label.  The easiest way to get the program IDs is to login to the KACE console with the adminui URL.  Typically you login with http://kace1000/admin (if kace1000 is your server name).  But if we use adminui, it will show us the data weu need… so login with http://kace1000/adminui


Go to Inventory à  Startup Programs and find the program you want.  In this example we are using SecurityHealth.  Note in the URL it shows us that this program ID is 54

FoiRs9.png


Create a smart label with any criteria…we will replace it with a SQL query.  Go to Label Management and then Smart Labels and create a new Device Smart Label.

5VJgJq.png 


Here we just chose agent version to use…but it really does not matter, we will edit it.  Type in a Name and hit Enter, then click save.

 

OEaOJo.png 



Next, we will edit the smart label by going into Home à Label Management à Smart Labels and click on the NAME of the label, not the pencil edit icon.  It should give you an Edit SQL button.


 VkqAF3.png


Paste the following SQL Statement into the box that opens, replacing the existing SQL query with this (change the ID in the last line to match the program that you want to label):

 

SELECT MACHINE.NAME AS SYSTEM_NAME,SYSTEM_DESCRIPTION, MACHINE.IP, MACHINE.MAC, MACHINE.ID  FROM (ORG1.MACHINE_STARTUPPROGRAM_JT MACHINE_STARTUPPROGRAM_JT

      INNER JOIN ORG1.STARTUPPROGRAM STARTUPPROGRAM

         ON (MACHINE_STARTUPPROGRAM_JT.STARTUPPROGRAM_ID = STARTUPPROGRAM.ID))

     INNER JOIN ORG1.MACHINE MACHINE

        ON (MACHINE.ID = MACHINE_STARTUPPROGRAM_JT.MACHINE_ID)

WHERE (STARTUPPROGRAM.ID = 54)

 

5.    Save the label, then force your machines to check in.  Verify that they have picked up the new label based on the startup program. 

6.    Once your machines have picked up the label, you can then use this label to assign scripts, run patches, reports, etc.

View comments (2)

Validating Unattend.xml files with System Image Manager

Introduction

In this document we will explore how to utilize the KACE Sysprep Creator Utility and validate the unattend.XML file with Windows System Image Manager.  The KACE Sysprep Creator Utility can be downloaded from here: 

KACE Sysprep Creator – ITNinja.com

 

After completing this document, you should be able to create and validate the unattend.xml file generated by the KACE Sysprep Creator tool.

KACE Sysprep Creator

The KACE Sysprep Creator tool allows administrators to create unattend.xml files that are used when running the Microsoft System Preparation Tool (sysprep).

Creating Unattend.xml files with Sysprep Creator

Select the OS and Architecture for the unattend file.  The Executor option will create an additional file which will perform sysprep pre-requisite checks and run sysprep if all the checks pass.  Either option will generate an unattend.xml file which will provide the installation options for the image deployment.


                                                                                        


 

Continue through all 8 steps of the sysprep creator, answering all necessary parameters. Steps 5,6, and 7 are omitted from this document as they are rarely used settings.

 






Click Create when finished entering all settings.  Save the unattend file (and executor if selected) to your hard drive.

Note that in the unattend.xml file you will see that the local account passwords are in clear text.



*   NOTE: Domain join passwords are ALWAYS in clear text and CANNOT be encrypted. Microsoft advises that accounts for join domain should have ONLY the permission to add machines to the domain and have access to no other resources.

 

Using System Image Manager to Validate the XML

When installing the Windows AIK (Win 7) or the Windows ADK (Windows 8/8.1/10) one of the options is to install the Windows Deployment tools which includes System Image Manager.  This tool is typically how an administrator would create the unattend.xml files if they did not have the KACE Sysprep Creator wizard. 


31khRf.png


Using System Image Manager

 

Once you have created the unattend.xml file, the next step is to validate it against the Windows Installation media.  The best way to do this is to copy the Windows installation media to a directory on your hard drive.  Once you have copied it over, the next step is to add the media to the Windows image section.  Right click on Select Windows image catalog file and select Windows image. 


 aW34xV.png


Browse to the INSTALL.WIM file in the Windows media under the \\<Windows DVD>\Sources directory…


 yJJplG.png


Say yes and let it create a catalog file if asked.  This will only happen the first time you open the image.  It will create a catalog file in the directory where the install.wim file is located.

JRDFTH.png

 

Next, open the answer file and associate the unattend.xml file with the image.

iSN7BR.png


Select Yes to associate the XML file with the image.

FkT7A8.png 

 

Once the answer file is associated with the file, the Messages pane in the bottom of the screen will show validation errors.  Double click on each message to review and change the setting.

Z44MDB.png  


        

Note:

In some cases (as in Network Location in the example), the setting cannot be changed.  In this case you can manually edit the XML file and remove the line(s) related to that setting.

myJPlm.png








 

 

 


 

Finalizing the Unattend.xml file

While in System Image Manager, you can add other features and settings as needed.  For more advanced users there are many settings that can be added to the unattend.xml file.  KACE Sysprep creator only generates the basic requirements to successfully sysprep a system.  Once all of the issues have been resolved, and new features/settings have been added, go to the File menu, select Save Answer file:

 

LWCgHN.png

 

An added benefit of using Windows System Image manager to validate the unattend.xml file, is that the password stored in the XML file for local administrator account will be encrypted when the new answer file is saved. Remember: passwords for the join domain function will NOT be encrypted.        

                                                                                


Using the new XML file

Copy the unattend.xml file to the appropriate location on the system that will be running sysprep.  If using just the unattend,xml file and not the KACE Sysprep Executor, copy the unattend.xml file to C:\Windows\System32\sysprep and run sysprep according to Microsoft guidelines.

If using the Sysprep Executor file to run sysprep on the target system, then simply copy the executor file and the new unattend.xml file to the desktop of the system and let the executor run sysprep.  It will delete the files so there is no residual files left in the image.

View comments (1)

Using External WIM Files in the K2000

Summary: 

There may be times, especially in new instllations, when you would like to use your existing WIM files from the K2000.  Here we will discuss how to utilize the K2000 to deploy existing WIM files without uploading the images through K2000 Deployment Menu. You can utilize the K2000 to store the images or you can use existing server storage to access WIM files.

Authors Note:   There are some similar articles from @SMal.tmcc that also go over this function:

K2000 version 3.4:   http://www.itninja.com/blog/view/wim-storage-freeing-up-space-on-your-k2000-if-you-are-using-wim-s

K2000 version 3.5:   http://www.itninja.com/blog/view/do-you-want-to-store-your-wim-s-externally-with-k2000-v3-5-like-we-did-with-3-4

K2000 version 3.6:   http://www.itninja.com/blog/view/wim-storage-freeing-up-space-on-your-k2000-if-you-are-using-wims-k2000-version-3-6

K2000 version 3.7:   http://www.itninja.com/blog/view/wim-storage-k2000-version-3-7-freeing-up-space-on-your-k2000-if-you-are-using-wims-and-speed-up-deployment-using-network-windows-shares

Other articles:

http://www.itninja.com/blog/view/capturing-wim-s-to-locations-other-than-the-kbox-externally-capturing

http://www.itninja.com/blog/view/capturing-windows-10-wim-s-to-locations-other-than-the-kbox-externally-capturing-using-dism

=================

In order to do this, you must have imported tasks from the K2000 Streaming WIM Toolkit from here:

K2000 Streaming WIM Toolkit


KACE Streaming WIM Toolkit

 

The KACE Streaming WIM Toolkit provides components that allow WIM files to be streamed to the endpoints instead of copying and extracting from the local drive.  This can be useful for environments where disk space is low.  Typical WIM deployments require that the WIM file be copied to the local drive first, then the WIM file is extracted to the partition locally.  To do this however, the endpoint will require over 50% free space available.  Systems with small disk drives and large images will need to utilize this method.  The streaming toolkit will bypass that requirement and extract the WIM file directly to the system.  This can make deployments a bit faster, but the downside is that the streaming WIM deployments cannot utilize multicast.


Using the Streaming Image Templates

While the KACE Streaming WIM Toolkit (KSWIM for short) has a few uses and in this case we are going to use the system image deployment template.  With a standard WIM deployment, the image is injected during the “Deploy System Image” component of the installation plan.  When streaming a WIM you need to use the streaming template that “fakes out” the system into thinking it is applying an image.  The image will actually get unpacked and installed to the hard drive as a post-installation task (mid level – K2000 Boot environment).  Using this method we will alter the post installation task we use to deploy a WIM from a location other than the default image location on the KACE appliance. 

Note:

In order to stream a WIM from another source, the KBE must have access to the WIM file.  This can be done with a simple drive mapping if you have the WIM on an external server.  Alternatively you can place a WIM file in the PETEMP directory on the KACE server if needed.

 


Importing Tasks into K2000

Download the KSWIM from ITNinja here:

http://www.itninja.com/blog/view/kace-streaming-wim-toolkit-kswim

Follow the included instructions to import the tasks into your K2000.  Once imported you will notice templates for streaming images in your post-installation tasks section of the K2000 library.

In this paper we will focus on a simple single partition image but the tasks and image deployments can be easily modified to accommodate multiple partition images.


Understanding the KSWIM tasks

 

Once you have imported the tasks into your K2000, go into the System Images and edit the single partition template and DUPLICATE the task at the bottom of the screen.  DO NOT edit the template so you can use it later if needed.


5keGKK.png

 

 

Once duplicated, setup the new System Image make sure it has the correct partitioning tasks.  We will add the image deployment in a task later on.  If using the driver feed, ensure that this option is checked as it is off by default.  Remove the existing “Apply WIM Stream C Partition” task from the mid-level tasks.

 

CjJbO2.png

 

Locations of WIM files

Next we need to either map a network drive as a post-install (Mid-Level) task if you are storing WIM files external to the K2000.  Create a post install BAT script task that looks like this (modify with your server IP and share, username and password:

AiLeGL.png


This should be the first mid-level task run in your system image sequence if you are going to use an external source for the WIM file.  Copy your WIM file(s) to this share on your server.

Alternatively, we can store WIMs on the K2000 in the PETEMP directory.  Open \\<yourK2>\PETEMP and create an Images directory.  Copy your WIM file(s) into this directory as shown here:

rBTSU3.png


Inserting into an Image Deployment

Once we have the WIM file(s) stored on our external source (or PETEMP folder), we need to make a task to apply the WIM file to the hard drive.  Create a mid-level BAT script task again and use the following command:

Dism /apply-image /imagefile:T:\Images\Win10x64.wim /index:1 /ApplyDir:C:\

In this example we are calling the Win10x64.wim file which is stored in the Images directory on PETEMP.  PETEMP is always mounted as the T: drive in KBE environments.

 

If you are using an external source, then specify the drive you mapped in the mapping task you created.  Using the previous example drive mapping, it might look like this:

Dism /apply-image /imagefile:W:\Win10x64.wim /index:1 /ApplyDir:C:\

 

Note:

If you are using multiple WIM files, specify all commands in the batch file using a single command per each WIM file you need to install.

 

Dism /apply-image /imagefile:T:\Images\Win10x64-CDrive.wim /index:1 /ApplyDir:C:\

 

Dism /apply-image /imagefile:T:\Images\Win10x64-DDrive.wim /index:1 /ApplyDir:D:\

 

 

Modifying the KSWIM template

Once you have the Post Install tasks created, we need to insert them back into our System Image deployment.  A complete install might look like this:

 R3LjJO.png


Running the Deployment

Running the deployment is now like any other image deployment.  You can schedule the image to be deployed or run the deployment from the KBE deployment menu.

ld4Bv3.png

 

Note:

Since the WIM deployment is not a traditional WIM file deployment, the main downside to this method is that the deployment cannot take advantage of multicast deployments.


Conclusion

This document has outlined how to utilize WIM files that you may already be using in conjunction with the K2000 deployment appliance without having to deploy the WIM and then recapture the image in the K2000 appliance.


This document can also be accessed in PDF form here:

Using External WIM files with K2000

Be the first to comment

Smart Label based on OS Installation Date

There may be times when you need to group devices by installation date.   A practical example might be that you want to deploy an image to a system that has not be re imaged in 2 years.  Another reason to use this might be if you are deploying images and you want to run an aggressive patch schedule on newly imaged systems.  Since we cannot rely solely on K1000 agent creation date as this would apply to new agent installs and not only new machines, we need to separate the machines that were just re imaged from those that received the agent recently.

The problem lies in the smart label drop downs.  Not every inventory field is shown when building a smart label and the inventory item OS Install Date is one of those items.  In order to build a smart label for this we can use a simple SQL query pasted in over a new smart label.

First, build a new smart label from devices.  It does not matter what you use since we will wipe out the query.  Go to Label Management --> Smart Labels and click on the name of the smart label that was created.

JG5TGv.png

Click on Edit SQL and paste in the following SQL statement:

SELECT MACHINE.NAME AS SYSTEM_NAME, OS_INSTALLED_DATE as TOPIC_ID FROM MACHINE  WHERE (((TIMESTAMP(MACHINE.OS_INSTALLED_DATE) <= NOW() AND TIMESTAMP(MACHINE.OS_INSTALLED_DATE) > DATE_SUB(NOW(),INTERVAL 48 HOUR))))

Save the label.  This will automatically label devices that were imaged within the last 48 hours.

Now we can use that label in a patch schedule that aggressively patches machines in that label while keeping older machines out of that patch schedule.

We can alter the time query a bit to find whatever devices we need.  For example devices that were imaged over 2 years ago would use this query:

SELECT MACHINE.NAME AS SYSTEM_NAME, OS_INSTALLED_DATE as TOPIC_ID FROM MACHINE  WHERE ((TIMESTAMP(MACHINE.OS_INSTALLED_DATE) < DATE_SUB(NOW(),INTERVAL 2 YEAR)))

Happy labeling!
View comments (4)
Showing 1 - 5 of 16 results

Top Contributors

Talk About License Management