Linking Power BI to the Quest K1000 SMA

We use the Quest K1000 Systems Management Appliance at Dickinson to manage many tasks, including Helpdesk ticketing, deploying patches, scripting and tracking inventory. Because of how much we use the appliance in our day to day management of devices there is a lot of data available in its database. One of the great things about the KACE appliances is the ability to connect third party reporting tools directly to the MariaDB backend with a read-only reporting user. Over the past year or so I have been creating Power BI reports using that connection and this post will describe how I setup the connection and some guidance on creating your own dashboards and reports. This blog post will focus on working locally with an ODBC connection to the appliance. In future posts I will go into how you can work collaboratively using the Power BI service and give more detail on how you can use data in the KACE SMA database more effectively using relationships and custom queries.

I'm making a few assumptions here:
You are working with ORG1 (the appliance can have multiple organizations)
There isn't a firewall blocking your machine from accessing port 3306 on your appliance
You have Dell computers in your KACE inventory

First things first - Setup the appliance

In order to connect to the database you need to enable the reporting user. In the K1 admin interface browse to Settings, Security Settings. Check the box for Enable database access. Save your changes.
Note that if you have more than one organization you will need to enable to user for each one.

Next - Setup the ODBC connection

Although the KACE database is running MariaDB the MySQL connector will be close enough. You'll need to download the MySQL ODBC Connector and configure a connection to the KACE database. See the KACE administrator guide for more details.

Fire up Power BI

You will need the desktop version of Power BI from Microsoft. Download and install the client and launch it. It should open to a blank workbook. Click the Get Data button and then select Database and MySQL database. If your ODBC connection is setup correctly you should soon be seeing a list of the tables in the KACE SMA database.

Select some tables and make a report

If you aren't already familiar with the database structure then the list you are viewing will be daunting. Let's start with something rather simple that won't require a lot of database knowledge. In the list of tables select the following tables:
ORG1.DELL_ASSET
ORG1.DELL_WARRANTY
ORG1.MACHINE

Power BI will normally attempt to detect relationships between the tables for you. Click the Manage Relationships button to see how it did. Regardless of what Power BI made you will need the following, so add them if they aren't there (you may need to delete or de-activate any relationships that are already present).
ORG1 MACHINE CSP_ID_NUMBER to ORG1 DELL_ASSET SERVICE_TAG
ORG1 DELL_ASSET SERVICE_TAG to ORG1 DELL_WARRANTY SERVICE_TAG

Power BI now has a basic understanding of how rows in the MACHINE table relate to the other tables. Let's make a simple report that shows the ship date of your Dell computers.
On the right side of the window in the Fields pane there should be a list of tables, expand the ORG1 MACHINE table and check the box next to NAME. You should get a table visualization that list the computer names in your database. Next, expand the ORG1 DELL ASSET table and check the box next to SHIP_DATE and four additional columns should appear showing Year, Quarter, Month and Day.

That's pretty exciting! Of course, you might not like the format of the date because Power BI defaults to showing dates using a date hierarchy, this is useful for other kinds of visualizations, but not so much for tables. In the Visualizations pane there should be a Values section that shows NAME and SHIP_DATE. SHIP_DATE should be expanded to show the parts, click on the arrow next to SHIP_DATE and change the option from Date Hierarchy to SHIP_DATE. Your table should update to show the dates in the standard form.

The table is still showing all computers, so to make the output look nicer you can use the filters to only show items where the SHIP_DATE is not blank. This should be an option under the Advanced filtering options.

Let's make a pretty picture using this same data. In the visualizations pane click on the Pie chart visual. Drag the SHIP_DATE column from the Fields table to the Legend section. Next, drag the ID column from the MACHINE table to the Values section. BAM! Now we have a pretty pie chart showing the number of computers shipped per year. For something even cooler, click on one of the pie sections and watch the table you created earlier only show the computers shipped in that year. #MindBlown

This is but a sampling of what you can do with Power BI and your KACE SMA data. I encourage you to try making other types of visualizations using just these three table to start. As you add fields from the different tables you will eventually find that something breaks the visuals, this is normally caused by Power BI not understanding the relationship between what is already in the table and what you just added to it. In a future post I will talk about how to get around those limitations.

Automating dual boot Deployments - Part Three - KBE Automation

This is part three of my series on automating dual boot deployments with Deploystudio and the Quest K2000. In parts one and two I covered my motivation for the project and the creation of a virtual hard drive that contains the KACE Boot Environment. In part three I will be covering how to automate deploying an image from the K2000.

Although the K2000 has an automated deployment mechanism in the interface their method works best for computers that are already in the database. One of the K2000 engineers also developed a separate application called "Default Deploy" that can be added to the boot environment via the KBE Manipulator. In our case we can boot to the KBE and add the Default Deploy pieces manually, this is more advantageous because the method can be repeated more easily than using the KBE Manipulator and without the need of uploading our modified KBE to the K2000 appliance.

1. Download the Default Deploy files from the link on the ITNinja site
2. Copy the Default Deploy files to a USB drive
3. Boot to the KBE on your Bootcamp machine.
   At this point you should have an Apple device setup to dual boot with Windows, that Bootcamp partition should also have a boot menu option for the Windows Pre-install environment. Booting into that environment should take you to the KACE K2000 deployment screen.
4. Click on Recovery and then Command prompt
5. Insert the USB drive
6. Change to the drive letter for your USB drive
7. Create a folder on the x: drive called applications:
   mkdir x:\applications
8. Copy the default deploy files to x:\applications
9. Edit the startnet.cmd file to add the default deploy command:
1. notepad x:\windows\system32\startnet.cmd
2. Find the section before this line:
   @echo **Performing local startup
3. Add the default deploy command before this section:
   x:\applications\default_deploy.bat /inifile:t:\default_deploy.ini
4. Save the startnet.cmd file and exit Notepad
10. Change to the T: drive
    Note: The T: drive maps to your K2000 petemp share. This is a hidden share that is used for temporary files and you can use it to store other files that you may need for deployment tasks. In this case the default_deploy.ini file will be placed there.
11. Copy the default_deploy.ini file from your USB drive to the T: drive
12. Edit the default_deploy.ini file according to the instructions to deploy your scripted install for your Bootcamp machine

At this point you can save your files and shutdown the KBE environment and upload an image of the Bootcamp environment to Deploystudio. Before uploading I do recommend removing the Windows installation files from the C: drive as there is no need for them at this point. Just be sure to leave the VHD file present. You can also use bcdedit to remove the boot option for Windows.

An advantage of using this method to automate deployment is that we can now easily customize the KBE for different scenarios. The default deploy tools can be set to use a custom ini file which enables you to have multiple default_deploy.ini files on the T: drive. This means that you will be able to create multiple images of your Bootcamp partition that when applied to the system contain different instructions for which image to apply to the computer. In a more advanced scenario you could also have the default_deploy.bat look for a file on the C: drive of the Bootcamp partition and use the Deploystudio tools to replace that file at imaging time with a default_deploy.ini that contains the instructions for the image you want to use. This would allow you to have one image uploaded to Deploystudio with the ability to set the image for the Bootcamp partition as part of your imaging workflow.

In Part four of this series I will cover how to setup the workflow for Deploystudio and the K2000.

Clearing applications from Profile Manager

For some unknown reason when editing the Dock payload in Profile Manager there are sometimes applications that won't go away, even if you delete them from the server. Thanks to this post on krypted.com I was able to figure out how to remove the offending apps from the database. Once they are created again on the server they will appear correctly when editing a Dock payload.

1. Open a Terminal session on the profile manager server.
   You can do this while connected via Screen Sharing or on your Mac by connecting via ssh
   
2. Switch to root with the following command:
   sudo –s
   
3. Open the PostgreSQL command line application with the following command:
   sudo -u _devicemgr psql -h /Library/Server/ProfileManager/Config/var/PostgreSQL devicemgr_v2m0
   
4. Show a list of applications installed on the system that are in the database with the following command:
   select id,path from system_applications;
   Note the semicolon at the end of the command line, it is needed
   
5. To show a list of specific applications, e.g. Photoshop use this command:
   select id,path from system_applications where path like '%Photoshop%';
   Make a note of the id for the application you want to remove.
   
6. To delete the offending application:
   delete from system_applications where id=123;
   Substitute the 123 for the actual id found in steps 4 or 5
   
7. Exit psql with the following command:
   \q
   
8. Exit the root shell with the following command:
   exit 

Once in the psql command line application there is a lot you can do to muck around in the database, of course. If you aren't comfortable in that kind of environment then be very careful or you would ruin your entire Profile Manager setup.

Automating dual boot Deployments - Part Two - Native Boot

Windows Native Boot is a technology introduced in Windows 7 that allows a computer to boot directly into a virtual hard drive or VHD. My work leverages this functionality to load the KACE Boot Environment (KBE) on a Bootcamp partition. This provides the ability to perform a scripted installation from the K2000 appliance on the Bootcamp partition.

Many of the steps below are taken from the following MSDN article that details the Native Boot technology.
https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufacture/desktop/boot-to-vhd--native-boot--add-a-virtual-hard-disk-to-the-boot-menu

The process of creating the VHD containing the KBE requires that we first use the Bootcamp Assistant to create a Bootcamp partition and install Windows. This will help ensure that the partition is formatted correctly for the Apple hardware. 

After the Windows installation is complete we can create the VHD and apply our boot environment. In order to do this you will need the boot.wim file for that environment. To get a copy of this file for the Quest K2000:

1. Login to the K2000 web interface
2. Navigate to Deployments, Boot Environments
3. Select the appropriate boot environment
   Note: I have found that a standard Windows 10 boot environment will boot to Apple hardware with the necessary drivers for deployment. If that is not the case in your environment you will have to build a custom KBE.
4. On the boot environment detail page click the link to download a bootable ISO for this boot environment.
5. Open the downloaded ISO file.
6. Browse to the Sources folder in the ISO.
7. Copy the boot.wim file to your computer.

Now that you have the boot.wim file we can create the VHD and apply the WIM image to it.

Creating the virtual hard drive

1. Open a command prompt as administrator
2. Run diskpart and execute the following commands
1. create vdisk file=c:\vhdboot.vhd maximum=5000 type=fixed
   Note: I create the file at the root of the system drive to avoid and path issues. We also don't need a very large disk image and 5GB is still more than we need.
2. attach vdisk
3. create partition primary
4. format quick label=vhd
5. assign letter=v
6. exit

There should now be a V: drive on your computer that maps to the virtual hard drive. 

Applying the WIM

The next step is to apply the WIM to that drive. While still in the administrative command prompt run this command:

dism /apply-image /imagefile:c:\boot.wim /index:1 /applydir:v:\

This command assumes that you placed the boot.wim file at the root of the C: drive. 

Booting to the Virtual Drive

Now that the image has been applied to the VHD we can add it to the boot menu and boot to the OS on the drive. While still in the administrative command prompt:

1. v:
2. cd \windows\system32
3. bcdboot v:\windows

There should now be an entry in the boot configuration database that points to the V: drive. To verify this you can run bcdedit to list the boot options. When the computer is restarted you should see an options for Windows Pre-installation environment. Booting to that option should load the KACE Boot Environment.

In my next post I will describe how to manipulate the KBE to automatically deploy a desired scripted install.

Automating Dual Boot Deployments - Part 1 - Introduction

I have been putting a lot of effort into the automation of dual boot deployments on Apple hardware and I am ready to start publishing that work. This first post in the series will cover my motivation for this work and future posts will include the details on my approach and methodology.

Trend 1 - Higher Demand
Dickinson College has seen a growth in the demand for dual boot Apple devices in recent years. I personally support three dual boot labs and many classrooms which total to almost 100 devices that need to be configured and re-imaged on an annual basis.

Trend 2 - Imaging Problems
With newer versions of macOS and Windows the benefits of creating "golden master" images are quickly fading and moving towards scripted installations/thin imaging is becoming a more preferred method of deployment. The tools used to create those images are also becoming more difficult to work with. In particular, changes in the macOS architecture have made creating images of Bootcamp partitions more difficult, if not impossible in some scenarios. The differences in hardware also make moving an image from one platform to another very difficult, also. For instance, creating an image on a Dell and applying it to an Apple device is fraught with peril.

Trend 3 - Thin Imaging/Scripted Installation
We have already made the transition to thin imaging on our Apple hardware for macOS and scripted installations for configuring Windows on our Dell systems. There was not a method for replicating this technique for Windows on Apple hardware in a dual boot scenario.

Motivator 1 - Desire for consistency
This divergence of configuration management resulted in a lack of consistency across devices. For example, imagine two classrooms with instructor computers. Classroom A has an iMac that is configured with macOS and Windows. Classroom B has a Dell with just Windows. If a professor teaches in classroom A using Windows she should expect the same experience in classroom B. Having the ability to create the same configuration on both platforms is highly desirable.

Motivator 2 - Making the most of current resources
With the move to thin imaging and scripted installations the desktop support team has put a large amount of time into packaging applications for deployment. This work could not be leveraged effectively when configuring Windows on dual boot systems.

Motivator 3 - Laziness
Let's be honest, I don't want to spend time configuring computers by hand, especially at a large scale. I have found that it is worth putting the time into developing a system that will save countless hours of clicking and typing.

Combining these trends and motivators led me to the work that I will be detailing in the next several posts. The broad strokes of my technique leverage Windows Native Boot to a virtual hard drive that contains the imaging environment for our Quest K2000 appliance. An image containing this virtual hard drive is placed onto the Bootcamp partition of a dual boot Apple device and when booted a scripted installation is performed. The end result is a Deploystudio workflow that completely automates the configuration of a dual boot system for both platforms that is consistent with other deployments across campus.

Current Month Slicer

I have been working a lot in Microsoft Power BI recently and came across an interesting problem. The filters and slicers available don't offer a good way to set dynamic values. This makes it difficult to create a dashboard that shows data from the current month without manually updating the report every month with the current dates. While trying to find a way around this I found an interesting work around here: https://community.powerbi.com/t5/Desktop/Setting-the-Default-Value-of-a-Slicer/td-p/16442.

The author of the solution, greggyb, created a list of dates and through various columns designated if those dates were in the current month. Unfortunately, his solution used a set of static dates, which I found less than ideal. I have developed a different solution that generates the list of dates going back one year from the current date. Here is the code that will generate the required table.

let Source = List.Dates( DateTime.Date(Date.AddYears(DateTime.LocalNow(), -1)) ,365 ,#duration(1,0,0,0) ), #"Converted to Table" = Table.FromList(Source, Splitter.SplitByNothing(), null, null, ExtraValues.Error), #"Renamed Columns" = Table.RenameColumns(#"Converted to Table",{{"Column1", "Date"}}), #"Changed Type" = Table.TransformColumnTypes(#"Renamed Columns",{{"Date", type date}}), Year = Table.AddColumn(#"Changed Type", "Year", each Date.Year( [Date] )), MonthNumber = Table.AddColumn(Year, "MonthNumber", each Date.Month( [Date] )), MonthIndex = Table.AddColumn(MonthNumber, "MonthIndex", each let FirstYear = List.Min( MonthNumber[Year] ) ,Mult = [Year] - FirstYear ,Index = 12 * Mult + [MonthNumber] in Index), Month = Table.AddColumn(MonthIndex, "Month", each Date.ToText( [Date], "yyyy MMM" )), MonthName = Table.AddColumn(Month, "MonthName", each Date.ToText( [Date], "MMMM" )), CurrentMonth = Table.AddColumn(MonthName, "CurrentMonth", each Date.IsInCurrentMonth( [Date] )), MonthSlicer = Table.AddColumn(CurrentMonth, "MonthSlicer", each if [CurrentMonth] then "Current Month" else [Month]), #"Changed Type1" = Table.TransformColumnTypes(MonthSlicer,{{"Year", Int64.Type}, {"MonthNumber", Int64.Type}, {"MonthIndex", Int64.Type}, {"Month", type text}, {"CurrentMonth", type logical}, {"MonthName", type text}, {"MonthSlicer", type text}}) in #"Changed Type1"

Use this code to create a table. You must also create a relationship between the Date column on this table and the column containing the date in the table that you want to filter. Then create a slicer using the Months column.

Note that the table will be generated whenever the data source is updated, so this solution works best with a data source that is updated on a regular basis.

Power BI Pro vs Free

I have been working with Power BI recently and wanted to share a big lesson learned regarding the Pro license vs the Free license. Our Office365 license grants everyone access to the free license and for most users that will be sufficient. However, if you need the ability to link Power BI directly to a database you may need a Pro license.

Microsoft provides connectors to several types of databases and depending on your specific needs there are several options available for connectivity. In all of these scenarios I'm assuming that you have a database that you want to prepare reports and dashboards.

• Scenario 1 - Your reports and dashboards do not need to be updated on a regular basis.
  In this case you do not need a Pro license. You can setup Power BI desktop on your computer with the appropriate connector and publish your reports and dashboards to the Power BI service.
• Scenario 2 - Your reports and dashboards need to be updated on a regular basis, but not dynamically.
  As an example, you want to have your reports updated on a monthly basis and it isn't a problem for you to login to the Power BI application or service to update the data. 
  This does not require a Pro license, either. There are two options in this scenario, you can launch the Power BI desktop application, update the data, and then publish the updated reports. You can also use the Data Gateway software to update the data via the Power BI service.[1] 
• Scenario 3 - Your reports rely on dynamic data and should be updated automatically on a schedule.
  This is when we get into needing a Pro license. In conjunction with the Data Gateway software you can create a schedule to update your datasource. Unfortunately, anyone that you want to view reports that are based on a dataset like this will also need Pro licenses. That means that if you have a team that needs access to the dashboard and reports, every team member will need a Pro license.
  I hope these examples help clarify whether or not you need to purchase Pro licenses for Power BI. With our education discount they are not terribly expensive but it is a cost that will need to be considered if they may be required for your project.
  1. I'll write more about the Data Gateway in another post