Downloads

BI Pixie Instrumentation is now called BI Pixie Desktop. The file is still named bi-pixie.exe. Version 3.1.2 and earlier end a run with the log line “BI Pixie Instrumentation is completed”. Later versions end it with “BI Pixie Desktop has finished”. The default commit message is still “BI Pixie instrumentation”.

A setting the tool needs at the end of a run is checked before any report changes. The first time the tool runs, it creates bi_pixie_config.json with placeholder values. Version 3.1.1 added Pixies to the reports with those placeholders still in place, then stopped with a Python error at the last step, which sends the list of reports to BI Pixie. This version checks the project name, the subscription email and the flow URL before it changes any report. When one of them is empty or still a placeholder, the tool names the setting, says that no report was changed, and stops with exit code 8.

bi-pixie.exe --help shows help. Earlier versions took --help as the name of a folder to work in and stopped with a Python error. This version prints how to run the tool, where it reads its settings and where it writes its log files, and then stops without changing anything. -h and /? do the same.

The tool has the BI Pixie lantern icon. File Explorer and the taskbar showed an older BI Pixie icon for bi-pixie.exe. This version shows the BI Pixie lantern.

Exit code 8 is new. A script that runs the tool and checks its exit code can read 8 as a setting in bi_pixie_config.json that is not filled in. The tool's log names the setting.

Update BI Pixie Desktop before running it on a report that BI Pixie cloud or the Fabric workload already updated. BI Pixie cloud and the Fabric workload add Pixies to phone layouts. A version of BI Pixie Desktop earlier than 3.1.0 cannot remove those Pixies, so it stops with an error on such a report.

A phone layout created or changed after Pixies were added is tracked only after BI Pixie Desktop runs on the report again. Until then, that page is not tracked on phones. Running BI Pixie Desktop on the report again adds Pixies to the new or changed phone layout.

A new report or an empty report folder is no longer reported as a failure. Version 3.1.0 logged "Failed to process Report" with a Python error on the first run for a new report, and on a report folder that came back empty from Fabric. The report was skipped in both cases and nothing was lost, but the log said the tool had failed. This version writes the intended sentence instead: that the report's configuration files were created, or that the folder was empty and the report was skipped.

The company root certificate is trusted for every connection the tool makes. Version 3.0.0 added company_ca_certificate_path for networks that inspect encrypted traffic, but only the license check and the inventory used it. On such a network the license check passed and the tool then stopped at its first call to Power BI with a certificate error. This version also trusts the named certificate for its Power BI and Git connections. Certificates are still checked in full, and an empty setting keeps the system's certificates only, as before.

Usage on phones is tracked on pages that have a phone layout. When a report author gives a page a phone layout in Power BI, the Power BI mobile app shows that page on a phone with only the visuals the author placed on the phone layout. The tool now adds each Pixie to the phone layout of every page that has one, so a person reading that page on a phone is tracked. Pages without a phone layout are left as earlier versions wrote them, and the report author's own phone layout files are not changed. A phone layout created or changed after Pixies were added is tracked once the tool runs on the report again. Update BI Pixie Desktop before running it on a report that BI Pixie cloud or the Fabric workload already updated: a version earlier than 3.1.0 cannot remove the Pixies they add to phone layouts, so it stops with an error on such a report.

BI Pixie Desktop can use the tracking setup of your BI Pixie account. An organization that adds Pixies to some reports from the BI Pixie portal or the Fabric workload, and to others with BI Pixie Desktop, can now give every report the same tracking setup. Set the new tracking_setup setting in bi_pixie_config.json to account. The tool then uses, for each workspace folder, the tracking setup your account saved for that workspace in BI Pixie, or your account's default setup when it saved none. That includes the values an administrator locked and the per-report settings the account saved. When an administrator changes the setup in BI Pixie, the next run of the tool uses the change.

The setup arrives inside the signed license answer. The tool checks the signature before it changes any report, so the setup cannot be altered on its way to the computer. When BI Pixie does not send the setup, for example because the key in license_key is a self-hosted license rather than an account license, the tool stops before it changes any report and says so.

The first lines of every run say which tracking setup the run used. A run with account says it uses the tracking setup of your BI Pixie account, and a run with local says it uses the tracking setup in bi_pixie_config.json.

tracking_setup is local unless you change it. A run with local uses bi_pixie_config.json and bi_pixie_config_details.json exactly as version 3.0.0 does, so an existing release pipeline writes the same Pixies as before. With account, the license key, the tracking endpoint address, Git, Fabric sync, the company certificate and the log folder still come from bi_pixie_config.json. A self-hosted license has no account, so it keeps local.

The license check moved to the BI Pixie service, and the person running the tool signs in. Before this version, the tool checked the license by sending the license key to an address written into the program. In this version, the tool asks the BI Pixie service as the person who is running it, using the sign-in that person already has from the Azure CLI. Nothing secret ships in the program any more. A person who is not signed in is told to run az login with their work account and run the tool again.

BI Pixie signs every license answer, and the tool checks the signature before it changes any report. The tool stops without changing any report when an answer was altered on its way to the computer, when an answer recorded during an earlier run is sent again, or when the list of reports BI Pixie received differs from the list the tool sent. Organizations that inspect encrypted network traffic may need their network team to let the BI Pixie service through unchanged.

A license answers only for the organization it was issued to. A key used by someone signed in to another organization, or by someone a license limited to named people does not name, is answered as if no license had that key. The answer never confirms that a key belongs to somebody else.

A license from a BI Pixie Cloud or Fabric workload account can now be used in BI Pixie Desktop, when that license sends usage events to the organization's own tracking endpoint. The account license's key goes in license_key in bi_pixie_config.json, where the self-hosted key went before. BI Pixie counts the reports the tool adds Pixies to together with the reports the account already tracks, and counts each report once. An account administrator may use any license of the account. A member may use only the license the account assigned to them.

Organizations whose network inspects encrypted traffic can name their company root certificate. The new company_ca_certificate_path setting in bi_pixie_config.json takes the path of that certificate (a PEM file). The tool no longer retries a failed secure connection with weaker security.

A run in which a report could not be updated now ends with an error. Earlier versions logged the error for that report and then closed the run by saying the Pixies were ready, with exit code 0. This version closes the run by naming every report it could not update, and exits with code 7, so a person or a release pipeline sees that the run failed. The other reports in the run are still updated, saved and posted to the inventory as before.

A report that could not be updated is no longer committed, pushed or synced. When Git is on, earlier versions committed every changed file at the end of the run. That included a report that had failed partway through, which could be left with its old Pixies removed and no new ones in place, and the run pushed it to the Git repository and synced it to the workspace. This version puts the folder of each report that failed back as the last commit has it, names that report in the log, and commits, pushes and syncs only the reports it updated. A report that an earlier version already pushed this way is not repaired by this version.

What did not change

• What a Pixie writes into a report, and where its usage events go.
• How the tool reads report definitions, reports its results and posts the inventory.
• Every other setting in bi_pixie_config.json. The subscription_email setting is still required. When it is empty, the tool stops before it posts the inventory of the reports it changed. The license check no longer uses this setting to identify the person, because BI Pixie reads who is running the tool from their sign-in.

Before running version 3.0.0 or later

• Install the Azure CLI if it is missing, and run az login with a work account in the organization the license was issued to.
• Ask DataChant for a new license key if your organization has not received one since the license service moved. Keys from the earlier service are not carried over.

Earlier versions

Earlier versions of the tool check the license through a service BI Pixie is retiring. Once it is retired, those versions can no longer check a license, so every computer and release pipeline that runs the tool needs version 3.1.2.