/build/static/layout/Breadcrumb_cap_w.png

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.


Comments

This post is locked

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ