Monday, June 26, 2017

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.

Friday, June 23, 2017

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.

Wednesday, April 19, 2017

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.



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.

Tuesday, March 07, 2017

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