Blog Posts tagged with K2000 Scripted Installation

Ask a question

TaskTimeout Modification Script

TaskTimeout allows you modify the timeout period of the task engine with K2000 version 3.6 and higher. The task timeout period starts immediately when a task is run.  When the timeout period is reached, the task will fail and then either display the task error screen or continue to the next task, depending on the option chosen.

The task timeout period is stored in config.xml, which gets copied to the x: drive in KBE immediately after the initial deployment begins. Config.xml gets read immediately prior to every task that is run. By default, the timeout period is set to 8 hours.

The task timeout script can be be run multiple times to change the timeout period in KBE as a pre or midlevel task or in Windows as a postinstall task.

*Note: It is recommended that you use the task timeout script as a mid-level or post install task.  This is because the "Apply Image" task also uses the task timeout period.  If you don't give the image enough time to apply, then the image deployment will fail.

Usage
=====
The /min: switch must be specified and followed by the desired number of minutes for the timeout period. The value must be between 10 minutes and 960 minutes (16 hours). An example of a proper command is:
task_timeout.exe /min:30

There are 2 executables included in the download, task_timeout.exe and task_timeout_x64.exe.

task_timeout.exe should be used for:
- Any Preinstall TaskTimeout task within a 32 bit KBE
- Any Midlevel TaskTimeout task within a 32 bit KBE
- Any Postinstall TaskTimeout task inside of Windows (regardless of x86 or x64)

task_timeout_x64.exe should be used for:
- Any Preinstall TaskTimeout task within a 64 bit KBE
- Any Midlevel TaskTimeout task within a 64 bit KBE
- Any Postinstall TaskTimeout task inside of Windows x64 only

 

Download here.
*Note: you must be a member of the K2000 ITNinja Community to download this file.


v. 1.0.0.1 [06-06-14]
-fixed issue with not reading timeout minutes correctly


v. 1.0.0.0 [02-03-14]
-initial release


Corey A. Serrins
Patrick Warme
John Cutler

 

Back to K2000 Deployment Workbench Page

Be the first to comment

SDA Advisor

SDA Advisor by: Corey A. Serrins & Patrick Warme; idea by Mike Pace.

Version 3.0 of K2 Advisor is a utility that queries the database of your SDA to gather information about your appliance in an HTML report form that can be used to assist in gathering data or troubleshooting the SDA.

Some HTML tables will not show in the report if they are not relevant, this is intended.
Active UI Alerts - only shows up if there is an alert that has not been dismissed.
Server Task Processes - only shows up if there is something in the queue, like an export, at the time the report was run.

In order to use version 3 of SDA Advisor, "Allow Offboard Database Access" must be enabled in the UI under Settings and Maintenance | Security.  After enabling, the K2000 must be rebooted.
See article http://www.kace.com/support/resources/kb/solutiondetail?sol=SOL121600 for more information.

User Quotes:

"It's so fast and comprehensive. I love that it's got a quick at-a glance data summary, and it's going to be incredibly useful to us."

email me your quote to be posted here, or leave one in the comments!

*3.0.0.0 is currently available to download, or if running an earlier version, run the application and you should be informed that an update is available.

Back to the K2000 Deployment Workbench Page.


3.0.0.0 [09/06/17]
-Rebranded for Quest | KACE
-Rebranded to SDA
-fixed a defect where pie chart was including Total Used space in chart
-fixed a defect with how Image notes were being displayed
-added created date/time for Images and SIs
-Updated KB article links to Quest Support Site

2.1.0.0 [01/26/15]
-fixed issue where the correct .ini file wasn't being used
-corrected expired license message.
-corrected null driver feed download error.
-corrected an issue with RSA sync status.
-collapsable tables added to some tables.
-added "Tasks assigned to Image and Scripted Install" reports.
-added commandline field for all tasks.
-added "Shutdown at End" column for images and scripted installs with version 3.7 and higher and have the option to "Shutdown target device after last task".
-updated built in .ini file to match newest version.

2.0.2.1 [07/30/14]
-added version of K2 Advisor into the report
-evaluate drivers_postinstall is selected by default

2.0.2.0 [07/26/14]
-added ability to make app portable, if ini file is in same directory
-added ability to expand portable ini file for other scripting ninja scripts
-redesigned GUI to allow more options and added a menu bar
-moved 'Quit' under File | Exit
-added hotkey (alt-shift-d) to enable debugging, saving a .log file to the same location as the report
-report can now be saved to a specific directory on the main gui or file File | Save to...
-moved settings from a file to the registry for all scripts to read, if not portable
-moved check for updates app into the application itself, every launch checks for updates.
-changed terminology from 'backed up' to 'exported'
-a task is listed in the report if the title has the word 'reboot' in it, the wording was updated to include the possibility of it being a false positive.
-added 'Evaluate drivers_postinstall' checkbox to map this share and list the models under each manufacturer.
thanks to the post by dugullet on itninja the next 2 features were included (http://www.itninja.com/blog/view/k2000-3-6-sql-for-failed-deployments)
-added failed image deployments in last 30 days
-added failed scripted installs in last 30 days

2.0.1.11 [06/19/14]
-fixed issue with image and SI information links
-more accurate information of the data gathering dialog

2.0.1.9 [06/18/14]
-added version number to first GUI screen
-added rename/join tasks from 3.5 and earlier to Task Suggestion
-fixed issue where no warning was given if free disk usage was in MB
-fixed an issue where a deleted user account was showing
-fixed language in the export table to be easier to read
-removed task suggestion about using cscript and msiexec if commandline contained schtasks
-fixed cosmetic issue with driver feed download error 400
-fixed sizing on some tables so they are easier to read

2.0.1.1 [06/06/14]
-fixed issue with PO Task Converter and Driver Feed Workaround

2.0.1.0 [06/05/14]
-updated some language in Task Suggestions
-added PO Task Converter and Driver Feed Workaround as tasks that need to be deleted.
-search for reboot in task names and suggest removing and using "reboot required" instead.
-added Export table to show number of items needing to be backed up or not having current version backed up.

2.0.0.1 [05/28/14]
-fixed cosmetic issue with RSAs updating boot actions in active server queue processes
-fixed issues with RSA Linked Appliances not being reported correctly
-fixed issues with RSAs reporting nothing was selected to sync
-fixed cosmetic issue with driverfeed download error due to not being able to resolve host 'servicecdn.kace.com'
-fixed 'Check for Updates' app location

2.0.0.0 [05/27/14]
-complete rewrite of the script using mysql queries to get more information than just tasks.

1.0.0.0 [02/24/14]
-initial release
-maps k2 drive and reads .xml files for common 3.6 PO errors.
-HTML report of errors found and links directly to those tasks

 

 

Back to K2000 Deployment Workbench Page

Be the first to comment

A syncretic overview on how driver management works in K2000 3.4

After learning the most of how K1000 works I started to dig in the K2000. 
It is a really nice and powerful product, very flexible and expandable but one thing over the other was surrounded by mystery (at least that was my feeling): the driver management!

I started to read articles here and there, asking to friends and colleagues, watching various videos and I found out that there are many ‘’doctrines’’ and pieces of information spread all over the places that you need to know to unveil how the driver management mechanism is working.

I thought to write a “syncretic” document that explains what I understood about the driver management in the K2000 3.4.

I do not have the presumption to have discovered something revolutionary or have written a complete and ‘’dogmatic’’ document so please comment it if you have something to add or if I wrote something not exact.

The K2000 exposes 3 shares:

  • drivers
  • drivers_postinstall
  • restore

What are these folders for?

Let start with the DRIVERS folder

Under this folder there is a folder for every OS supported and two folders for KBE, one for the KBE 32 bit and another for the KBE 64 bit.

What drivers you need to have under the KBE folders?

In these folders you need to put the drivers for storage and network: so the bare minimum drivers needed for the KBE to be able to access the disks of the device where it is booting from and the network to talk back to the K2000.

Do not add to these folders drivers for video, sound or strange devices not really needed: remember that KBE exists only in the memory and it will be totally gone after the reboot.

How to add drivers under the KBE folders

Excluding the feed folder that is automatically created and managed from the Driver Feed functionality you need to create a new folder, the name does not matter but I’d suggest you to name it using the brand of the machine the driver belongs to.

Under that folder I suggest you to create a subfolder with the name of the driver and put the driver files there.

NOTE: if the driver is included in a single EXE or MSI you need to extract the files and put them under the folder: we cannot install EXEs or MSI as driver in this phase.

Which driver’s platform I need to add for KBE?

KBE 32 is a special version of Windows 7 32 bit and KBE 64 bit is a special version of Windows 7 64 bit, so you need to download drivers for Windows 7 32 or 64 bit to be added to the KBE folders.

After adding the drivers under the KBE folders we need to recache the drivers (in the web interface click on Library -> Drivers and choose the action recache drivers)                        

After recaching the drivers you need to rebuild the KBEs using the Media Manager utility that will rebuild the KBEs using the WAIK (you will need it installed on the machine where the Media Manager is running to rebuild KBEs) and adding the drivers in it.

NOTE: when you use Media Manager do not name the KBE as a name of a KBE that already exists: the Media Manager is not able to overwrite an existing KBE but it will tell you this, kindly, at the end of the KBE rebuild process.

How and which kind of drivers you need to add under the OS folders

Under the OS folders you need to add, as in the KBE folders, the bare minimum drivers that the scripted installation of Windows needs to run effectively, so again: network and storage drivers.

After adding the drivers under the OS folders (you can organize them as for the KBE folders) you need to recache the drivers.

If you added drivers only to the OS folders but not to the KBE folders you do not need to rebuild the KBEs with the Media Manager.

The drivers_postinstall folder

Under this folder  we need to add all the drivers that our machine will need after the scripted install is finished (so for its ‘’normal life’’) : storage, network, audio, video etc etc…

If your machine is a Dell machine the Driver Feed functionality does most of the job for you: under Library -> Driver Feed you can search for the device you need to image the OS to and download the driver packages: job done!

If your machine is not a Dell machine or you need to add additional driver you will need to add them under this directory but how??

The folder names and structure is not so context free as in the DRIVERS folder

The folder structure under the DRIVERS_POSTINSTALL is  the following:

<Manufacturer name>\<OS Name>\<Model name>

It seems complex but is not: we have a script that will help you to determine the name of the Manufacturer and the name of the model.

Simply execute on the system this VBscript program:

 \\<your_k2000_box>\drivers_postinstall\feed_tools\Get_Manufacturer_Model_OS.vbs

This script will show you the exact manufacturer and model name of the device

 

So in this case where do you need to put the drivers?

\\<your k2000 box>\drivers_postinstall\dell\ windows_7_x64\E6420\

Under this folder I suggest to create a folder for each driver and put under that folder all the files needed. Once again: if the driver is shipped as a monolithic ZIP, EXE or MSI you need to extract the files and put there under the folder.

If you want to install an “applicative driver” (and EXE or MSI that install drivers) you can do this as a post installation task or through the K1000 once the system will have a K1000 agent with a software distribution job.

If you added drivers only to this folder without touching the DRIVERS folder you do not need to rechache the drivers.

It is fundamental that under the drivers_postinstall you name correctly the folders.

Imaging vs. Scripted Install

If you only use scripted install and you have followed the entire article so far you are done! No other steps, other than test your solution, are needed. Big success!

But if you use imaging you need to use the famous Driver Feed Workaround.

If you do not have it in your Postinstallation actions you need to read this article where there are links to download the utility:

http://www.itninja.com/blog/view/driverfeed-workaround-for-k2000-v3-4

In a nutshell after downloading the Driver Feed Workaround and unzipping it you will find some files:

You will need: driver_feed_tasks.zip and install_driver.exe.

You need to create two Postinstallation tasks. With the driver_feed_tasks.zip you need to create a task like this:

 

With the install_drivers.exe you need to create a Postinstallation task like this one:

 

 

Once you have defined these two tasks you will need to use both of them if your image OS is Windows XP.

You will need to use only the mid-level task (Driver Feed Workaround that runs under the K2000 boot environment) for all the operative systems but the “Install Driver Feed” (executed in Windows that calls install_driver.exe) only for Windows XP systems.

Instead of using the driver_feed_tasks.zip file to create the mid postinstallation task you can directly use this script: \\<your_k2000>\peinst\hta\copy_drivers.vbs

The advantage to use this script is that this script is more updated than the driver_feed_tasks.zip that you find on the web.

 

Where to use these tasks that now I created.

The two task you created are needed only when you deploy and image and not for scripted installations.

To deploy a Windows XP image you use them in this way:

 

For Windows Vista and Windows 7 you will not need the “Install Driver Feed” job.

 

The RESTORE folder

This folder is not used for the drivers mechanism but it is used to import and export packages.

So if you export a software distribution job from the K1000 you will need to copy it there to import it in the K2000

CREDITS

Thanks to all my colleagues that helped me to understand better this technology.

Be the first to comment

A syncretic overview on how driver management works in K2000 3.5 & 3.6

After joining the Dell KACE Training team I started to learn the  K1000 and after that I started to dig in the K2000 secrets. 
It is a really nice and powerful product, very flexible and expandable but one thing over the others was surrounded by mystery (at least that was my feeling of novice user): the driver management!

I started to read articles here and there, asking to friends and colleagues, watching various videos and I found out that there are many ‘’doctrines’’ and pieces of information spread all over the places that you need to know to unveil how the driver management mechanism was really working.

After studying all the available material I wrote my first “syncretic” article about the K2000 3.4 version that you can still find here:

http://www.itninja.com/blog/view/a-syncretic-overview-on-how-driver-management-works-in-k2000-3-4

The introduction of K2000 3.5 introduced some nice changes simplifying a lot the driver management and avoiding the need to create and use the famous "Driver Feed Workaround" so I thought to write a new and updated “syncretic” article for the 3.5 & 3.6 users.

I do not have the presumption to have discovered something revolutionary or have written a complete and ‘’dogmatic’’ document so please comment it if you have something to add or if I wrote something not exact.

The K2000 exposes 3 shares:

  • drivers
  • drivers_postinstall
  • restore

What are these folders for?

Let start with the DRIVERS folder

Under this folder there is a folder for every OS supported and two folders for KBE, one for the KBE 32 bit and another for the KBE 64 bit.

What drivers you need to have under the KBE folders?

In these folders you need to put the drivers for storage and network: so the bare minimum drivers needed for the KBE to be able to access the disks of the device where it is booting from and the network to talk back to the K2000.

Do not add to these folders drivers for video, sound or strange devices not really needed: remember that KBE exists only in the memory and it will be totally gone after the reboot.

How to add drivers under the KBE folders

Excluding the feed folder that is automatically created and managed from the Driver Feed functionality you need to create a new folder, the name does not matter but I’d suggest you to name it using the brand of the machine the driver belongs to.

Under that folder I suggest you to create a subfolder with the name of the driver and put the driver files there.

NOTE: if the driver is included in a single EXE or MSI you need to extract the files and put them under the folder: we cannot install EXEs or MSI as driver in this phase.

Which driver’s platform I need to add for KBE?

KBE 32 is a special version of Windows 7 32 bit and KBE 64 bit is a special version of Windows 7 64 bit, so you need to download drivers for Windows 7 32 or 64 bit to be added to the KBE folders.

If you are you using the AIK for Windows 8 (WinPE 4.0) to build your KBE you will need to use the drivers for Windows 8 32 or 64 bit and you used AIK for Windows 8.1 (WinPE 5 .0) you will need to use the drivers for Windows 8.1 32 or 64 bit. The following table clarifies the drivers you will need: 

If you are using It contains   and you need to use these drivers in the KBE folders
WAIK for Windows 7 WinPE 3.0 use drivers for Windows 7
AIK for Windows 8 WinPE 4.0 use drivers for Windows 8
AIK for Windows 8.1 WinPE 5.0 use drivers for Windows 8.1

IMPORTANT Due to the fact that there are only 2 folders for KBE drivers, one for the 32bit and the other for the 64bit version, and not a couple of folder for every type of WinPE/WAIK, remember that only one type of drivers at time can be in that folder.

Do not mix Windows 7, Windows 8 and Windows 8.1 drivers in these folders.

If you previously built a WinPE 3.0 based KBE and now you want to build a WinPE 4.0 based KBE you need to delete all the drivers from the two KBE folders and put under them the drivers for Windows 8.

For Dell hardware we made available the Dell KBE Drivers packs. You can find them here:  http://www.kace.com/support/resources/kb/solutiondetail?sol=SOL111717 

After adding the drivers under the KBE folders we need to recache the drivers (in the web interface click on Library -> Drivers and choose the action Recache drivers).            

After recaching the drivers you need to rebuild the KBEs using the Media Manager utility: it will use the WAIK installed on the machine to rebuild the KBE and will inject automatically in it the drivers you added in the KBEs folder that are under the DRIVERS share.

NOTE: when you use Media Manager do not name the KBE as a name of a KBE that already exists: the Media Manager is not able to overwrite an existing KBE.

How and which kind of drivers you need to add under the OS folders

Under the OS folders you need to add, as in the KBE folders, the bare minimum drivers that the scripted installation of Windows needs to run effectively, so again: network and storage drivers only.

After adding the drivers under the OS folders (you can organize them as for the KBE folders) you need to recache the drivers.

If you added drivers only to the OS folders but not to the KBE folders you do not need to rebuild the KBEs with the Media Manager.

The drivers_postinstall folder

Under this folder you need to add all the drivers that the machine will need after the scripted install is finished (so for its ‘’normal life’’) : storage, network, audio, video etc etc…

If your machine is a Dell machine the Driver Feed functionality does most of the job for you: under Library -> Driver Feed you can search for the device you need to image the OS to and download the driver packages: job done!

If your machine is not a Dell machine or you need to add additional drivers you will need to add them under this directory but how??

The folder names and structure is not so context free as for the DRIVERS folder

The folder structure under the DRIVERS_POSTINSTALL is the following:

<Manufacturer name>\<OS Name>\<Model name>

It seems complex but is not: we have a script that will help you to determine the name of the manufacturer and the name of the model: they are taken from the BIOS.

Simply execute on the machine this VBscript program:

 \\<your_k2000_box>\drivers_postinstall\feed_tools\driver_feed_discovery_tool.vbs

This script will show you the exact manufacturer and model name of that device.

After you press the OK button you may see some other message box and sometimes a script error: no panic! is all ok..simply ignore them.

So in this case where do you need to put the drivers?

\\<your k2000 box>\drivers_postinstall\dell\ windows_7_x64\E6420\

Under this folder I suggest to create a folder for each driver and put under that folder all the files needed. Once again: if the driver is shipped as a monolithic ZIP, EXE or MSI you will need to extract the files and put there under the folder.

If you want to install an “applicative driver” (and EXE or MSI that install drivers) you can do this as a post installation task or through the K1000 once the system will have a K1000 agent with a software distribution job.

If you added drivers only to this folder without touching the DRIVERS folder you do not need to recache the drivers.

It is fundamental that under the drivers_postinstall you name correctly the folders.

Imaging vs. Scripted Install

If you only use scripted install and you have followed the entire article so far you are done! No other steps, other than test your solution, are needed. Big success!

If you are deploying an image with K2000 3.5 or 3.6 there are only two things to remember to be able for the driver management mechanism to work:

  1. The image you captured need to be a "sysprepped" image. (prepared and closed with SYSPREP before to capture it)
  2. You need to remember to flag the checkbox "Use driver feed"

The RESTORE folder

This folder is not used for the drivers mechanism but it is used to import and export packages.

So if you export a software distribution job from the K1000 you will need to copy it there to import it in the K2000

CREDITS

Thanks to all my colleagues that helped me to understand better this technology.

View comments (5)

Get/Set ComputerName

Get/Set ComputerName
by Corey A. Serrins, Kent Feid and Patrick Warme

These tasks will work with both sysprepped images and scripted installs of XP/Vista/7/8
Major features include:
-using the K1 database
-using the K2 database
-using variable replacement
-using a data file
-dialog prompting
-and more...

There are 2 scripts included with this download, getcomputername and setcomputername, each has a 32 and 64 bit versions.

For complete instructions and commandline switches, please read the included README.txt file

Get/Set ComputerName Download

Back to K2000 Deployment Workbench

Version History
=======================================================

v. 1.5.5.2 09/01/15
-fixed an issue where [ ] ; characters weren't being stripped from the final computer name
-added Win10 to variable replacement

v. 1.5.5.1 05/01/15
-fixed issue where USB image deployments without network connection were failing

v. 1.5.0.1 02/26/15
-resolved an issue where the name in the unattend was not getting updated.

v. 1.5.0.0 10/08/14
-added /log to generate a log file for both get and set scripts.
-added variable replacement functionality to setcomputername
-added data file naming functionality to setcomputername
-added ability to use K1 database
-added ability to use K2 database

v. 1.3.0.0 08/16/13
-added /look: switch to getcomputername and setcomputername. If using this switch, it must be used in both applications.
-added /notrandom and /timeout: switch to setcomputername in case the name read was '*' (random) and that is undesired

v. 1.2.2.1 10/02/12
-modified an error to be more clear that the name file wasn't found or error with it.

v. 1.2.2.0 08/03/12
-added 15 character limit to the dialog box so user can't enter more than that.
-changed the default write drive letter to x:

v. 1.2.1.0 08/01/12
-added /drive to both get & set

v. 1.1.2.2 05/20/12
-changed dialog box so that timer was set, takes whatever name is is in box at that time.

v. 1.1.2.1 05/04/12
-fixed /timeout issue in getcomputername where it wasn't working at all.
-fixed issue where when timeout happened, computername was blank in getcomputername.

v. 1.1.2.0
-added in /debug

v. 1.1.1.2 03/06/12
-made maximum length of computer name 15 characters in get/set scripts, no exceptions.

v. 1.1.1.1 12/22/11
-removed guictrlread from nodialog, not sure why it was there, as we aren't reading gui
-was just looking for /dialog, changed it to read first 7 characters to match command line, like other options
-fixed bug where /dialog would not work unless the computer name was ""

v. 1.1.1 11/21/11
    for SI, there is no name, so by default it will be "*" which will assign a random name

v. .65  03/09/11
switch was added to getcomputername.exe to allow for a timeout period on the dialog box to ask for a computer name.
Synatax for /timeout switch is /timeout:30 to timeout after 30 seconds. At this point, the unattend file would be left alone, assuming that the computername is set to "*" computer would end up with a random name.
/timeout at this time is meant to work with /dialog, if /timeout is used without /dialog, nothing will happen and there will be no affect on the outcome, but there will be no timeout.
v. .602/28/11
switch was added to getcomputername.exe to allow for naming the computer from commandline with /name:"name". This is more for one-offs.
switch was added to getcomputername.exe to allow the user to have a pop-up window to enter the computername. This is convenient for machines that come out of the box from the manufacturer, without any previous naming scheme for an organization.
v. .502/23/11
all known issues were resolved
all situations were tested with imaging and scripted install on Windows XP/Windows 7 and both architectures.
View comments (30)
Showing 1 - 5 of 11 results

Top Contributors

Talk About Patch Management