Blog Posts by StockTrader

Ask a question

How to install Microsoft Office 365 with Dell KACE K1000 in ten simple steps (aka Ten shades of Office 365 distribution)

In this article I explain how to create a Managed Installation to deploy in few simple steps Microsoft Office 365 with the Dell KACE K1000.
What you will need:
Let's begin then!
  1. Download the Office 2013 Deployment Tool for Click-to-Run and run it: it will ask you a directory where to place the extracted files (less than 1MB)
  2. Create an empty local directory to store the installation sources of Office 365 ( c:\TempOffice in this example )
  3. Amend the configuration.xml provided by default to point to that directory. Your configuration should look like the following one:
<Configuration>
   <Add SourcePath="c:\TempOffice" OfficeClientEdition="32" >
    <Product ID="O365ProPlusRetail">
      <Language ID="nl-nl" />
    </Product>
  </Add>
</Configuration>

 4. Now from the command line issue the command setup.exe /download configuration.xml and wait until the download is complete (~1 GB)
 5. Browse to the target directory c:\TempOffice in this example ) and move all the content in the directory where you have the setup.exe and configuration.xml files

At this point you need a batch that will kick in the installation. The batch needs t create a temporary directory, copy all the files and folders of the current directory there and launch the setup.exe this time with the /configure option.

This step is required because the SourcePath parameter is not able to handle relative paths (e.g.: ..\myfiles  OR .\) but only absolute paths (e.g.: c:\tempOffice\)

Do not worry! I wrote the script for you:

@ECHO OFF
REM Script written by Marco S. Zuppone for DELL.
REM Try it before to use in production !! 
IF NOT EXIST "C:\TempOffice" (MKDIR "C:\TempOffice") ELSE (DEL "C:\TempOffice\*.*" /F /S /Q)
XCOPY /E *.* "C:\TempOffice"
PUSHD %cd%
CD "C:\TempOffice"
setup.exe /configure configuration.xml
POPD
RMDIR /S /Q "c:\Tempoffice"

At the end your directory with all the content should look like this:


    6. Copy the folder on a test machine, open the DOS command line, change to that directory and run the batch (I called it, in my example installOffice.bat)
    Verify that the installation is correct and all is fine. Force the inventory of the test machine after the installation has been successfully performed.

    7. Select all the files in the folder (Office subfolder and all the content) and create a ZIP file of the content.

    8.Look for the Inventory of the test machine, open it and look for the Office 365 in the Installed Programs section.


    9. Click on the Office 365 record and associate to it the ZIP file that you created at the point 7

    10. Create now the Managed Installation under the Deployments menu: the only focal point here is to use Override Default and put in the Parameters field the name of the batch that will perform the installation.


Job Done. I'd suggest, as usal, to test the managed distribution against one or more test clients before to go in production.

View comments (4)

A syncretic overview on how driver management works in K2000 3.7

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 followed by another one about the 3.5 and 3.6 that you can still find here:

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

The version 3.7 introduces some news as the support for Windows 10 an some graphic changes so I created this updated article to include these changes.

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 sub-folder for every OS supported and two sub-folders for the 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?

You need to use the driver platform specific to the WAIK, AIK or ADK you used to build your KBE using the Media Manager utility

To understand exactly what kind of drivers you need to use you can refer to this table: 

If you are using

It contains 

and you need to use these drivers in the KBE folders

Notes

WAIK for Windows 7

WinPE 3.0

drivers for Windows 7

Recommended to deploy XP, Vista and Windows 7

AIK for Windows 8

WinPE 4.0

drivers for Windows 8

 

AIK for Windows 8.1

WinPE 5.0

drivers for Windows 8.1

 

ADK for Windows 10

WinPE 10

drivers for Windows 10

 

 

IMPORTANT! : Due to the fact that there are only two 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, Windows 8.1 & Windows 10 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:  https://support.software.dell.com/k2000-systems-deployment-appliance/kb/111717 and in through the Dell Software Support portal

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 Manage Drivers then press the button Recache All Drivers            

 

After recaching the drivers you need to rebuild the KBEs using the Media Manager utility: it will use the WAIK/AIK/ADK 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 that the deploy of the OS, scripted install or image, 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 models where you want to provision the OS and download the driver packages: job done!

If the target machine is not a Dell machine or you need to add additional drivers for your Dell machine that are not included in the driver pack, you will need to add them under the drivers_postinstall share 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! it 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.7 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.

Be the first to comment

How to extract information from the Chrome preferences file and collect them with a K1000 Custom Inventory Rule

If you already had a look inside the Chrome folders on your Windows machine for sure you noticed that Chrome saves the preferences in a file under 

 %USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default .

The file that contains the preferences is called Preferences and it is in JSON format.

The best approach to extract the information that we need from that file and collect them with a Custom Inventory Rule is 

  1. run a script that looks for the Preferences file for all the users of the device
  2. interpreters the Preferences file that is in the JSON format and dumps the information in a unique text file
  3. collect the file content with a Custom Inventory Rule

To interpreter the file we can use the PowerShell cmdlet ConvertFrom-Json that was introduced in PowerShell 3.0.

The following example extracts the default page(s) from the Preferences file found in all the users profiles and dumps the result in the file C:\Chromato.txt

 <# 
 .SYNOPSIS
This script extracts the default page from the Chrome preferences file for all the user of the computer.
 .DESCRIPTION
 This script extracts the default page from the Chrome preferences for all the user of the device using the 
 ConvertFrom-Json cmdlet introduced in PowerShell 3.0
 AUTHOR:      Marco S. Zuppone for DELL KACE
 .NOTES       
  You will need PowerShell 3.0 or better
 WARNING: This script is given AS IS. Use it at your own risk! Revise it carefully before to use it.
#>
Remove-Item c:\Chromato.txt
Get-ChildItem c:\users| 
where {$_.PsIsContainer} |
foreach {
$PrefFileName = $_.FullName+'\AppData\Local\Google\Chrome\User Data\Default\Preferences'
try {
$ch = ConvertFrom-Json -InputObject (Get-Content $PrefFileName -raw)
echo "-----------------" | Out-File -filepath c:\Chromato.txt -Append
Out-File -filepath c:\Chromato.txt -Append -InputObject ("User: "+$_.FullName)
Out-File -filepath c:\Chromato.txt -Append -InputObject $ch.session.startup_urls
echo "-----------------" | Out-File -filepath c:\Chromato.txt -Append
    }
    catch {"File not there or not parsable at "+$PrefFileName}
}  

You can easily modify the script above to exact the information that you want from the file: the object $ch contains all of them.

The custom inventory rule is the following:

ShellCommandTextReturn(cmd /c type c:\Chromato.txt)

You can execute periodically the PowerShell script on the devices from you want to obtain the Chrome settings information.

Remember to invoke it using PowerShell.exe -ExecutionPolicy Unrestricted  or otherwise to sign the script with a trusted certificate.

If you want to know more about how to sign a PowerShell script you can have a look to this article http://www.msz.it/how-to-sign-a-powershell-script/

Be the first to comment

How to use the K1000 6.4 Inventory API (WSAPI) with PowerShell

One KACE K1000 major version after, my old article about How to use the K1000 Inventory API (WSAPI)  needed a revamp.

First of all: what is the Inventory API and what can you do with it?
  • The Inventory API is a web service of the KACE K1000 appliance that allows you to programatically send a XML file that represents a device inventory.
Using the API you can write a program that sends a series of XML files, each one representing a machine inventory, to the K1000.
The XML file format is explained in the K1000 online help: look for Valid XML schema for Windows 
For Linux and Apple devices there is a different schema that's available in the online help as well.

There are situations where you cannot install an agent and you cannot use the agentless inventory functionality but you still like to add these devices to the K1000 inventory and you need some degree of automatism: in this case the WSAPI is what you are looking for.

The inventory API endpoint is this one: http://k1000-hostname/service/wsapi.php

The documentation explains us that we can basically perform three operations with it:

  1. Ask for a session key (a challenge key): this is fundamental and we will need it for all our subsequent requests.
  2. Ask the K1000 to generate for us a KUID: this is very useful if we do not have a way to generate a KUID for an agentless machine.
    A KUID is at the end a GUID and we can even obtain it with this simple PowerShell line:
     $guid = ([guid]::NewGuid()).Guid.toupper() 
    but if we want the K1000 can do the job for us.
  3. Submit a XML file that contains the inventory information.
    The documentation is generous about this point: in the K1000 help file is explained in detail the format of this file.
    If you want to obtain a more generous blueprint of it you can even use this command line from the Kace agent directory:
     KInventory -machine -out .\myNiceFile.xml

In the documentation there is even a nice Perl script but due to the fact I'm allergic to it (I hate the needs of external libraries) I thought to write an example in PowerShell for the benefit of all the Microsoft lovers.

Some notes about it:

  • This script is given AS IS. Please revise it CAREFULLY before to execute it.
  • You're welcome to improve it and send me comments to this post.
  • To run an unsigned PowerShell script you need to ''relax'' your Execution Policy or sign it. There is a nice article about how to sign a PowerShell script here: How to sign a PowerShell script

And now the script!

You will need to pass to it three parameters: the file to send (better if included in " " ), the K1000 host name or IP and the API password.
Invoking it without parameters (or incomplete parameters) will prompt a couple of usage line. 
I tried to comment the script but if something is not clear please do not hesitate to contact me.

Sometimes ITNinja may break the correct formatting of a script. 

In this case you can download it from: https://dl.dropboxusercontent.com/u/93688199/TestWSAPIv4.ps1


 <# 
 .SYNOPSYS
This script demostrates how to use the K1000 INVENTORY API (WSAPI)
 .DESCRIPTION
 TITLE:       TestWSAPIv4.ps1
 VERSION:   4.0
 AUTHOR:      By Marco S. Zuppone for DELL KACE
 This script demonstrates how to use the K1000 INVENTORY API (WSAPI)
 .NOTES       
  You will need PowerShell 2.0 or better
 WARNING: This script is given AS IS. Use it at your own risk! Revise it carefully before to use it.
 .EXAMPLE
 TestWSAPI.ps1 [file-to-send.xml] [K1000 Hostname] [API Password]
#>
function Get-MD5String([string]$s

#This function calculates the MD5 of a string and returns the hexacecimal representation of it in lowercase.
    $result2 = ""
    $algo = [System.Security.Cryptography.HashAlgorithm]::Create("MD5")
    $hashByteArray2=$algo.ComputeHash($([Char[]]$s))
    foreach ($byte in $hashByteArray2
{ $result2 += “{0:x2}” -f $byte }
    $result2
}
if ($args.Length -lt 3)
{
Write-Host "USAGE: TestWSAPI.ps1 [file-to-send.xml] [K1000 Hostname] [API Password]" -ForegroundColor Green
Write-Host "Example: .\TestWSAPI.ps1 ""d:\myfile.xml"" k1000.mycompany.org myPassword"-ForegroundColor Green
Break
}
else 
{
if (-not (Test-Path $args[0] -PathType Leaf)) 
{
Write-Host "the file "$args[0]" does not exist or is not accessible"
Break 
}
}
New-Variable -Name password -Value $args[2] -Option ReadOnly #This is the API password you specified in the Security Settings
New-Variable -Name K1000Url -Value ("http://"+$args[1]) -Option ReadOnly #This is the K1000 url.
<#First request
In this first request we ask to the K1000 to provide us a session key.
We will need to save the cookies that the K1000 will send us back to re-use them in the subsequent requests.
#>
$uploadstring=$K1000Url+"/service/wsapi.php?keyreq=true"
$req = [System.Net.WebRequest]::Create($uploadstring);
$myCookiesContainer=New-Object System.Net.CookieContainer #We need to grab the cookies from the first request to mantain the session.
$req.Method ="GET";
$req.ContentType = "text/xml";
$req.useragent="User-Agent: Mozilla/4.0 (compatible; MSIE 7.0;)" #Let try to resemble a real browser
$req.CookieContainer=$myCookiesContainer #We need to grab the cookies from the first request to maintain the session.
$stOut = new-object System.IO.StreamWriter($req);
$resp = $req.GetResponse();
$reader = new-object System.IO.StreamReader($resp.GetResponseStream());
$session_string=$reader.ReadToEnd();
Write-Host "Session string returned from K1000: " $session_string
$passwordMD5=Get-MD5String($password.ToString())
$tokenMD5=Get-MD5String($session_string+"|"+$passwordMD5) #I calculate the reply token as specified in the K1000 help file.
Write-Host "Token to be used to reply to the K1000: " $tokenMD5
<#Second request
Now we ask the K1000 to generate for us a KUID.
This can be used to upload the inventory of a new agentless machine.
In this example we will not use it but if this request will be succesfull it means that our password is good and we calculated the reply in a good way.
So it is a good test to see if we are doing the right request.
#>
$downloadString=$K1000Url+"/service//wsapi.php?req=newuuid&key="+$tokenMD5
$req = [System.Net.WebRequest]::Create($downloadString);
$req.CookieContainer=$myCookiesContainer #We send back the cookies obtained in the first session
$req.Method ="GET";
$req.ContentType = "text/xml";
$req.useragent="User-Agent: Mozilla/4.0 (compatible; MSIE 7.0;)"
$resp = $req.GetResponse();
$reader = new-object System.IO.StreamReader($resp.GetResponseStream());
$theNewKUID=$reader.ReadToEnd();
Write-Host "The new KUID generated by K1000 using WSAPI call is " $theNewKUID;
<#Third request
Now the tricky part :-) !!!
We send to the K1000 an XML file with the format described in the documentation.
To ease the test I'm using the file I found in the documentation of the K1000
You need to specify the KUID it it's not specified in the XML file.
If you specify here a KUID and there is a different one in the file the one in the file wins.
#>
$sendFileUri=$K1000Url+'/service/wsapi.php?req=loadxml&key='+$tokenMD5+'&KUID='+$theNewKUID+'&version=6.0'
$req = [System.Net.WebRequest]::Create($sendFileUri);
$req.Method ="POST";
$req.ContentType = "text/xml";
$req.useragent="User-Agent: Mozilla/4.0 (compatible; MSIE 7.0;)"
$req.CookieContainer=$myCookiesContainer #We send back the cookies obtained in the first session
$req.ProtocolVersion="1.0"
$uploadFilePath=((split-path $args[0] -Resolve) + "\" +(split-path $args[0] -Leaf))
$FileContens = [System.IO.File]::ReadAllBytes($uploadFilePath) #I need a byte array. Potentially is the same as Get-Content $uploadFilePath -Raw -Encoding Byte
$stOut = new-object System.IO.StreamWriter($req.GetRequestStream())
$stOut.Write($FileContens,0,$FileContens.Length)
$stOut.Flush()
$stOut.Close()
$resp = $req.GetResponse();
$reader = new-object System.IO.StreamReader($resp.GetResponseStream());
Write-Host "Optional reply of the K1000: "$reader.ReadToEnd();
Write-Host "Status code and Status description of the HTTP reply from the K1000:" $resp.StatusCode " " $resp.StatusDescription
$resp.close()
$resp.Dispose()
# a bit of cleanup is a very good idea if you want to use the PowerShell debugger in the ISE
Remove-Variable K1000Url -Force 
Remove-Variable password -Force  


Be the first to comment

How to monitor DELL KACE K1000 and K2000 disk space using SNMP, asset subtypes & agentless inventory

Two years ago I wrote the article How to monitor the hard disk space on K1000 & K2000 . At that time the Agentless Inventory and Asset Subtypes features were not there yet so it was necessary to use some 3rd party software to query the SNMP of the appliances and get the hrStorage values.
In this new video I want to show you how to take advantage of the new features introduced with the K1000 version 6.4 that eliminate completely the need to use external tools.

The basic idea I will show you in the video is the following:
  1. Create an asset subtype for the Device asset type with some additional fields representing the disk space used by the appliance volumes.
  2. Create a SNMP Inventory Configuration specific for the K1000.
  3. Enable SNMP in the appliance settings.
  4. Add the appliance as an Agentless device.
  5. Apply to it the SNMP Configuration and the Asset Subtype create in the previous steps.
In the video I go through the procedure to monitor the K1000 but with some small adjustment you can create a specific Asset Subtype and SNMP Configuration for the K2000 as well.



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

Top Contributors

Talk About ITNinja