Blog Posts tagged with K2000 3.6

Ask a question

K2000 3.6 Task Engine .cmd Bug

After upgrading to 3.6 for the K2000 we started having issues with the Task Engine and post install tasks that use a .cmd file. There's a KB article on how to modify post install tasks to work with the new Task Engine, but this didn't seem to be the issue we were having. I opened a case with support and they determined that there is a bug with that Task Engine and .cmd files. I also noticed this issue occurring with one BAT script post install task as well (a .bat file generated by the K2000, not a file I uploaded). Support's work around was to either add "CMD /C" or the path of the task (Y:\applications\[task id]\) before the call to the .cmd file (add contents\ if the file is in a zip). Since we have a few tasks across two different K2000s that weren't working, I came up with a VBScript that modifies Tasks.xml to workaround the bug. It's run as our first mid-level (post install task in the PE) task:

Set objXMLDoc = CreateObject("Msxml2.DOMDocument") 

objXMLDoc.async = False 
strTasksFile = "X:\KACE\engine\Tasks.xml" If Not objXMLDoc.load(strTasksFile) <> 0 Then
WScript.Echo "There was an error loading Tasks.xml"
WScript.Quit
End If Set objXMLRoot = objXMLDoc.DocumentElement
For Each Task In objXMLRoot.SelectNodes("//Task")
Set CommandLine = Task.SelectSingleNode("./CommandLine")
If Right(CommandLine.Text, 3) = "cmd" Or Right(CommandLine.Text, 3) = "bat" Then
Set FileType = Task.SelectSingleNode("./FileType")
FileType.Text = "Batch"
End If
Next objXMLDoc.save(strTasksFile)

This script works by loading the Task Engine's Tasks.xml file and looping through to find any task that calls a .cmd or .bat file. If found it sets the FileType node to Batch (from Exe) as this seems to be what causes an error.

I just thought I'd share this on the chance it's useful.

View comments (1)

K2 Advisor

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

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

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 2 of K2000 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!

*2.1.0.0 is currently available to download.  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.


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)

Run batch files or apps after Kace K2000 3.6 is done with it's post imaging tasks

As some have discovered with the advancement of the imaging engine for K2000 version 3.6 some extra reboots occur that interfere with certain post install tasks failing due to the reboot. 

Sysprep image changes

I had the imaged box login as a local user in my sysprep answer file and then join the domain and install software during the post phase and last turn on the computer use policy. 

For version 3.6 I had to add an extra local login prior to the post tasks running for that reboot.

3.5 answer file auto logon part was:

<AutoLogon>
                <Password>
                    <Value>XXXXXXXXXXXXXXXXXXXXXXXX==</Value>
                    <PlainText>false</PlainText>
                </Password>
                <Enabled>true</Enabled>
                <LogonCount>1</LogonCount>
                <Username>installer</Username>
            </AutoLogon>

With 3.5 the box would finish it's wim cast and set the mbr and go on to it's post tasks.  With the introduction of 3.6 the box rebooted between the mid and post tasks using up my 1 autologin.

3.6 answer file auto logon part is:

<AutoLogon>
                <Password>
                    <Value>XXXXXXXXXXXXXXXXXXXXXXXX==</Value>
                    <PlainText>false</PlainText>
                </Password>
                <Enabled>true</Enabled>
                <LogonCount>2</LogonCount>
                <Username>installer</Username>
            </AutoLogon>

That was the only change I had to make to my answer file.  This way it reboots goes on to the posts task as the local user, joins the domain and sets the autologon to a domain user during the post tasks prior to the post task reboot.

My post script tasks ran without any changes, but I need the box to autologin as the domain user a couple of times to install deepfreeze prior to installing the policy screen that halts the autologin process waiting for you to say ok to the policy.  I also read about other ITNinja's who have also complained that the post reboot interfering with installs running. You can use this to run an install/msi after kace is all done with the posts tasks or use this to runkbot and force a checkin after a couple of reboots. 

my batch file is in the image:

(policy.bat)

reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v legalnoticecaption /d "TMCC Academic Use Statement" /f

reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v legalnoticetext /d "TMCC Computer Use Policy - TMCC General Access Computer Labs are educational computer facilities open to all students, faculty and staff at TMCC. If not enrolled or employed at TMCC, then access is not allowed. Identification may be requested.  Lab Assistants may monitor computer use. Students needing a computer to do their homework will have preference over students that are game playing or participating in Internet chat. Students who are on the chat lines or playing games are welcome, but will be advised to come back when the labs are not busy.  Viewing or printing pornographic material that can be viewed by others is not allowed in any of the Labs or Kiosks. Cell-phone use in the labs is prohibited.  Emergency calls can be received, but the user must step outside of the Lab to continue the conversation.  Absolutely no food or beverages are allowed in the labs!  Maintain a friendly and quiet lab for other students to do their work.  Maintain a quiet work area: Loud boisterous behaviour is not acceptable; the Lab is not a place to socialize, as it's distracting to others. Children are not to be left unattended in the labs. Head count and surveys: In order to effectively use technology resources, head counts or surveys will be taken by the lab monitor. Please provide them with your cooperation. Closing time: The labs must close promptly at the scheduled time. Your cooperation in abiding with the closing time would be greatly appreciated. ACTIVITIES IN VIOLATION OF TMCC'S COMPUTER USE POLICY - Unauthorized use of a computer account. Using the campus network to gain unauthorized access to any computer systems. Connecting unauthorized equipment to the campus network. Using electronic mail to harass or threaten others. This includes, but is not limited to, sending repeated, unwanted Email to another user. Transmitting or reproducing materials that are slanderous or defamatory in nature or that otherwise violate existing laws, NSHE, or College regulations. Displaying obscene, lewd, or sexually harassing images or text in a public computer, facility, or location that can be in view of others. Initiating or propagating electronic chain letters inappropriate mass mailing. This includes, but is not limited to, multiple mailings to the TMCC Campus, newsgroups, mailing lists, or individuals forging the identity of a user or machine in an electronic communication. Attempting to monitor or tamper with another user's electronic communications, or reading, copying, changing, or deleting another user's files or software without the explicit agreement of the owner. Unauthorized attempts to circumvent data protection schemes or uncover security loopholes. This includes creating and/or running programs that are designed to identify security loopholes and/or decrypt intentionally secure data. Knowingly or carelessly performing an act that will interfere with the normal operation of computers, terminals, peripherals, or networks. This includes tampering with or removing computer hardware or software. Knowingly or carelessly running or installing on any computer system or network, or giving to another user a program intended to damage or to place excessive load on a computer system or network. This includes, but is not limited to, programs known as computer viruses, Trojan horses, and worms. Deliberately wasting/overloading computing resources, such as printing excessive copies of a document. Violating terms of applicable software licensing agreements or copyright laws. Violating the TMCC Copyright Infringement policy, copyright laws and their fair use provisions through inappropriate reproduction or dissemination of copyrighted text, images, etc. Using college resources for commercial activity such as creating products or services for sale." /f

So to make it delay 2 reboots I add this line to the end of my last post task.

reg.exe add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce /v setrunonce2 /d "reg.exe add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce /v setrunonce1 /d \"reg.exe add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce /v policyon /d c:\windows\w2d\policy.bat\""

 

 

 

View comments (1)
Showing 1 - 5 of 8 results

Top Contributors

Talk About Adobe