Analytics Hub installer 0.6.8

Published as a pre-release first. 0.6.8 becomes Latest once a fresh install from its published exe passes. Until then, the releases/latest links, including the PowerShell command, still serve 0.6.7, and the installer doesn't offer 0.6.8 as an update. This command installs 0.6.8 either way: irm https://github.com/microsoft/AnalyticsHub-Dashboard/releases/download/installer-v0.6.8/install.ps1 | iex.

Install from PowerShell

Paste this into PowerShell. It needs no admin rights: it downloads this release's installer as a zip, checks its SHA-256 and opens the installer in your browser.

irm https://github.com/microsoft/AnalyticsHub-Dashboard/releases/download/installer-v0.6.8/install.ps1 | iex

To keep the files, download install.ps1 and AnalyticsHubInstaller.zip from this release and, where your execution policy allows scripts, run .\install.ps1 -ZipPath .\AnalyticsHubInstaller.zip. With a Node.js your IT team has approved, add -UseInstalledNode: https://github.com/microsoft/AnalyticsHub-Dashboard/blob/main/docs/INSTALL.md#it-approved-nodejs. More: https://github.com/microsoft/AnalyticsHub-Dashboard/blob/main/docs/INSTALL.md#from-powershell

Or download the exe

Download AnalyticsHubInstaller.exe and open it. Steps: https://github.com/microsoft/AnalyticsHub-Dashboard/blob/main/docs/INSTALL.md

Check the download

SHA-256: 653097081feaf30690b00531bf63e43578582e40882edf3424fa9b2b682ab9f8

In PowerShell, in the folder you downloaded it to, run:

(Get-FileHash .\AnalyticsHubInstaller.exe -Algorithm SHA256).Hash

It should match the hash above, which is also in AnalyticsHubInstaller.exe.sha256. PowerShell prints it in capitals; that doesn't matter. A match confirms the file is the one in this release, not who published it.

If your organisation blocks it

This build isn't code-signed yet, so Edge and Windows SmartScreen may warn about it. If your organisation's policy blocks it, don't work around it.
Use the PowerShell command above, another route in https://github.com/microsoft/AnalyticsHub-Dashboard/blob/main/docs/INSTALL.md, such as Azure Cloud Shell or running the installer with Node.js (https://github.com/microsoft/AnalyticsHub-Dashboard/blob/main/docs/INSTALL.md#without-the-exe), or ask your IT team.

What changed

What changed since 0.6.7: Every module now works on Azure: Agent Evaluator, the Agent 365 registry, product feedback and Workday org data install there too, and credit consumption is checked against Fabric. An Azure install can use a resource group your Azure admin creates, with least privilege, and setup sizes for tenants with more than 10,000 Copilot seats. On Azure, a long history loads and processes within the run job's memory and disk, runs after the first load no longer fail in processing, the installer doesn't start a run while another is going, a new install with public endpoints completes, uninstall works in a resource group you already had, Share adds people by email, private networking leaves private DNS zones already in the resource group alone, turning on org-scoped access and scoped delegation in Share no longer fail, and Repair keeps a shared-capacity (Pro) install's workspace where it is. Agent Evaluator reads every Copilot Studio transcript, on both paths. A user who isn't an Entra admin can now create the viewer group. Install and update check the prerequisites themselves, and the installer checks that the app can read the audit log, with a new check-audit command. The app's first pages load sooner, several of its slowest queries are faster, it fetches ahead only the next two pages, and when more than 10,000 people have Copilot activity it opens on the last 12 weeks. Changing Group by no longer crashes two Adoption pages, and the Executive summary no longer says everyone has a department. M365 Activity refreshes incrementally, refresh does less work for Consumption Central and Agent Evaluator, and users in the Microsoft 365 Copilot usage report count as licensed. On Fabric, the installer has you sign in to Viva Insights first when Cowork credits come from the Dataflow, Repair or change redeploys the app after an update, and the app shows saved task times, report packs and commercial terms again: check your terms after updating. The README sets out setup step by step, from prerequisites to after setup, and points to ValueLens and Consumption Central for a more targeted report. Azure by hand, in Azure Cloud Shell, works once 0.6.8 is Latest. The details are below, and the release candidates' are in the CHANGELOG.

Update an existing install: run the command above, or open installer 0.6.8, and choose Update. On Azure, that redeploys with this version's images, adds the Agent Evaluator, Agent 365 and product feedback tables (migrations V008 to V010), and redeploys and reloads the ValueLens model; the jobs' next run recomputes every month once. On Fabric, it redeploys and reloads the ValueLens model, redeploys the notebooks, updates and republishes the Ask data agent, and offers to replace the pipeline and redeploy the app: let it redeploy the app. To turn on a module Azure now supports, choose Repair or change, then Data collection; Agent Evaluator's environments are under Module connections, and Workday org data is under the advanced settings: see Workday org data. Some Azure installs that ticked Credit consumption before 0.6.8 keep Copilot Studio and Cowork left out: to turn them on, choose Repair or change, then Module connections, and pick their sources. If you use Agent Evaluator, update as a System Administrator of each of its environments, then reload the history once, as below. The tag also publishes the valuelens-jobs and valuelens-web images as 0.6.8.

Azure: the installer doesn't start a run while one is going. It used to start the run job without checking, so a Repair or change during a long first load started a second run beside it, and the two shared the audit staging area and the tenant's audit queries. Now the installer checks the run job before the first load, a history reload, org-scoped access or run starts it. If a run is going, it doesn't start another: it says which run is going, and what to run once it has finished. A history reload that doesn't start isn't recorded, so the next Repair or change offers it again. As on Fabric, run then exits with an error, a run that started more than 24 hours ago doesn't count, and if the installer can't check, it starts the run as before.

Azure: private networking no longer takes over private DNS zones already in the resource group. With private networking, an install creates its privatelink.* zones in its resource group unless you choose otherwise. When an existing resource group already had a zone of the same name, the deployment updated it in place and tagged it as the install's own, so uninstalling tried to delete it, with every record in it. A second install, in a group where an earlier one had created the zones, did the same to the first install's zones. Now the preflight stops before anything is deployed when a zone the install would create is already there without its tag. It names the zones and says how to go on: choose Use existing zones in another resource group and give that resource group, after creating any of the zones that aren't there yet, or install into another resource group.

• Still goes ahead: a Repair or Update over zones the install created itself, public networking, Use existing zones, Leave DNS to Azure Policy or the network team, and privatelink.* zones the install doesn't create, such as Key Vault's.
• An install that already took over a zone isn't detected: the zone now has that install's tag, and the install record doesn't say which zones were there before it.

Azure: Share adds people by email, and shows viewers' names. In 0.6.7 and the 0.6.8 release candidates, on an Azure install with a viewer group, adding someone by email in Share failed, even for a directory admin, with "Microsoft Entra did not allow this change. Only owners of the viewer group and directory admins can change its members." Share also listed the people in the group by their object ID. The web app could change the group, but it had no permission to look people up. With the viewer group (the default), the installer now also gives it delegated Graph User.ReadBasic.All. That reads basic profiles only (name, email address and photo), not User.Read.All. Without a viewer group, nothing changes. Fabric isn't affected: there, Share opens the group in My Groups.

• Update an existing install: run the installer and choose Update, or Repair or change. It adds the permission to the web app's registration and grants it, with no other step. If you can't grant admin consent, it gives you a link to send to an admin, as for the web app's other permissions.
• When Entra refuses a lookup, Share says so. It says Microsoft Entra didn't let Analytics Hub look up people by email (or groups by name), and that Repair or change in the installer, or an Entra admin's consent, fixes it. "Only owners of the viewer group and directory admins can change its members" is now only for a change to the group that Entra refused. With org-scoped access, an admin who gives or approves a scope gets the new message too, instead of a scope left waiting for approval or the message about owners. A scope a leader gives still waits for an admin.

App: fetches ahead only the next two pages. Once the page on screen has loaded, the app used to fetch the first tab of every other page in the background, about 45 queries per open. It now fetches the first tab of the next two pages in the menu, and the two after whichever page you open next. Those background queries share the capacity with the page on screen, and on large tenants each runs longer and slows the ones in front of it. Pages further down the menu load when opened, as they did before the prefetcher. PREFETCH_AHEAD in app/src/components/prefetch-targets.ts sets the number. On Fabric and Azure.

Installer: audit-ingestion checks, and the Viva Insights sign-in first.

• The installer checks the app can read the audit log. After admin consent, it gets the app's own token and checks it's for this tenant and has AuditLogsQuery.Read.All. Straight after consent, a problem is only noted, as Entra can take a few minutes to apply a new app, secret or consent (an app it can't find yet is tried again too). Once the pipeline is deployed it checks again, and then says why the audit load would find nothing (consent missing, the secret not working, or an app registration from another tenant) and who fixes it. On Azure, it checks the jobs' managed identity has the role.
• New check-audit command (Check audit ingestion in the browser), and --check-audit for install and update on Fabric. As well as the token check, it runs a small audit search and warns, rather than passing quietly, when it finds no Copilot interactions, or no records at all (audit logging probably off in Purview).
• A Prerequisites row for audit ingestion. It shows whether the app has the role, or whether you can grant it, and the last check's result.
• Clearer 0-record data checks. When the audit load finds nothing, the data check lists the likely causes in order, narrowed by the last audit check. It also says how to reload the days already read as empty once the cause is fixed: on Fabric, rename Files/_audit_staging/_manifest.json in the Lakehouse and run run --backfill-days <n>.
• A brought app registration must be in this tenant. The installer stops, and says who can fix it, when it finds only another tenant's app, or an app with no service principal that you can't create.
• Sign in to Viva Insights first. With Cowork credits from the Dataflow, the installer creates AnalyticsHub_Cowork_Credits early, asks you to sign it in, and checks the connections are saved before it deploys the notebooks and pipeline and runs the first load. No more coming back to the installer after configuring the connection in Fabric. You can still skip it and finish later.
• Install and update check the prerequisites themselves. You no longer have to run prereqs first. Before anything is created, install lists only the prerequisites that are missing for what you chose; update does the same before it changes anything. The checks run in parallel, each with a 15-second limit, and one that takes longer shows as "couldn't check" and never stops you. Only a true blocker stops an install: with --yes, no way to register the app (you can't, and there's no app registration or admin pack to use instead). Update only warns. prereqs still gives the full list.

Changed:

• Licensed users: the Copilot usage report counts too. The licensed-users ingest, in Fabric and on Azure, now also reads the Microsoft 365 Copilot usage report, which lists every Copilot-enabled user. A user in that report is flagged as licensed even when their assigned product name doesn't match the Copilot patterns, for example a renamed or bundled SKU. It uses the Reports.Read.All permission the ingest already has, so there's nothing new to grant. If the report returns 400, 403 or 404, the run falls back to assigned products and says so in the log. Other errors stop the run and keep the previous snapshot. The log shows how many users each source found, and warns if no names match between the two reports (concealed names).
• Installer: M365 Activity now refreshes incrementally (12 months kept, the last 35 days reloaded), instead of reloading the whole table on every refresh. The first refresh after an install or Repair or change still loads it all once.
• Consumption Central refresh does less work for large user counts, with the same results. The Studio and GitHub usage intensity groups find each percentile cut once instead of ranking every user against every other user, and Weeks Ago no longer looks up the latest week separately for every row. The Cowork usage cohorts are now worked out in the CoworkBilling query, which sorts the credits once and compares each user with five cut values, instead of ranking every user for every user. Weeks Active and Weeks Over Limit are unchanged. The overall saving still needs timing on a large copy.
• The Microsoft 365 activity and Agent Evaluator notebooks now compact the tables they wrote (OPTIMIZE ... VORDER) once at the end of each run, so the daily and incremental writes no longer pile up small files that slow down refresh. A failed compaction is reported and the load still succeeds. Set RUN_OPTIMIZE = False to turn it off.
• The Agent Evaluator report no longer loads eight columns that nothing in it reads: error messages, the 500-character transcript preview, the first and last bot messages, and the variable copies other than the user's UPN. Refresh reads less data and the model is smaller.
• The app opens on the last 12 weeks for a large organization. When more than 10,000 people have Copilot activity, the date filter starts at Last 12 weeks, the 84 days to the last day with activity, rather than all dates. With 20,000 people, a three-month window made the Adoption summary about 30% quicker and the org-to-person drill about 15% quicker; bigger tenants gain more. Each query works out the tenant's size and the dates itself, so the first page doesn't wait for anything extra. The filter bar shows the dates and says it's the default for large organizations, and Show all dates widens it in one click. Clear filters is now Reset filters, and goes back to this default. Smaller tenants still start on All dates. Consumption Central and the Agent Evaluator keep every date until you choose a range.

Fixed:

• Azure uninstall from a resource group you already had. It asked Azure to delete each resource the install had tagged with API version 2021-04-01, which most of them don't support. So it stopped part-way, with NoRegisteredProviderFound, and left the rest of those resources and the Analytics Hub and SQL reader app registrations behind. Now it uses a version each resource's provider offers, deletes each resource before what it depends on, and waits for Azure to finish each one. If one can't be deleted, it carries on, still deletes the app registrations, then lists what's left and exits with an error: run Uninstall again to finish. Uninstall from a resource group the installer created still deletes the whole group. 0.6.7 has this problem too.
• Azure: a first install with public endpoints no longer stops at Power BI model with DM_GWPipeline_Gateway_DataSourceAccessError. Public endpoints are the default unless a policy keeps Azure SQL private. Power BI tests the SQL reader's sign-in when it takes the models' credentials, but the reader's database user is made by the database migration, which ran later. Now a new Power BI credentials step sets them after Database migration. Private networking is unchanged. To finish an install that stopped there, run setup again. Every earlier installer with the Azure path (0.5.0 to 0.6.7) has this problem.
• Agent Evaluator reads every Copilot Studio transcript. The installer gave the transcript reader, the jobs' managed identity on Azure or the app on Fabric, only the Bot Transcript Viewer role, which reads only the transcripts the reader owns or that are shared with it. In a test environment, Copilot Studio's own service user owned them, so on Azure the first load read none, and its status said empty. Fabric gave its app the same role. Now, in each environment you pick, the installer also creates a role for the install, Analytics Hub transcript reader followed by the first 8 characters of the install's ID, with one privilege: ConversationTranscript read at Organization depth. It reads the role back to check that, gives it to the reader beside Bot Transcript Viewer, and asks Dataverse whether the reader can read a transcript. Unticking the environment or Agent Evaluator, or uninstalling, takes the role away and deletes it. The installer never changes or deletes a role it didn't create. It adds transcript read to its role only while no user or team other than the reader has the role. On Azure, Dataverse's first delete of an application user the installer created only soft-deletes it: the user stays, deactivated with no role, and ticking the environment again found it disabled. Now the installer reads the user back and deletes it again, and says it removed the user only once it's gone. Otherwise it warns, and prints how a System Administrator deletes it for good. Creating the role needs a System Administrator of the environment, as adding the reader does; otherwise the installer prints the admin center steps. To fix an existing install, run Update or Repair or change as a System Administrator of each environment, then reload the history once, for example with run --backfill-days 30. Later runs read only the last 14 days of transcripts, and a reload reads up to 180 days, so it picks up the older ones the environment still keeps.
• Azure: runs after the first load no longer fail at process. Each run of the run job starts in a new container, with none of the earlier runs' files on its disk. process downloaded only its inputs, then read the months that earlier runs had curated from that disk. So every run after the first load, other than a full rebuild, failed there with No files found that match the pattern and a path ending in month-….parquet. Those runs didn't publish or refresh, so the dashboard stopped updating, and status showed them as Failed. Azure installs on 0.6.6 and 0.6.7 have this problem; Fabric doesn't. Now process downloads the month files it reads, each once a run. A full rebuild reads none of them, so it downloads none. The failed runs still collected their data, and the next run after you update processes it. If you set VALUELENS_PROCESS_FULL_REBUILD=true on the run job to get by, updating removes it, since Update redeploys the run job's settings. Runs then go back to recomputing only recent and changed months.
• Fabric: Repair or change redeploys the app after an update. It pushed the new version's semantic model, notebooks and pipeline, but its question about the app, "Deploy it again?", defaulted to no unless the app's pages, currency or who can view it had changed. So with the defaults, the app stayed at the earlier version, on the new model. Installers up to 0.6.7 have this problem, on Fabric only; on Azure, both Update and Repair or change redeploy the web app. Now the install record keeps the installer version that deployed the app. When another version deployed it, or the record has none, as with every install from 0.6.7 and earlier, the question says the app needs redeploying to update it to this version, and defaults to yes. Answer no, and the next Repair or change asks again. Update already defaulted to redeploying the app.
• App: changing Group by no longer crashes Adoption's Trend heatmap and Activation pages. With either page showing data, picking another attribute under Group by, such as Office location, or going back to Organization, replaced the whole app with "Something went wrong" and Column "Chat + Agent Org DataOrganization" was not found. Try Again recovered, but opened the Executive summary grouped by Organization, so the filters were lost. The app in 0.6.7 and 0.6.6 has this problem too. While the answer for the new attribute loaded, these pages read the previous answer by the new attribute's column names, so they couldn't find the column they rank by. Now each answer is read by the column names of the query that asked for it: the previous answer stays on screen, with its own labels, until the new one comes, as it does when a filter changes. And a chart that can't find the column it ranks by shows its rows unranked, rather than stop the app.
• A user who isn't an Entra admin can create the viewer group. Setup, access and turning on org-scoped access stopped with Graph's 400 "Request contains a property with duplicate values" when they kept A new group. Entra makes a user who isn't an admin an owner of a security group they create, so Graph refused the request, which named them as owner too. Now, when Graph refuses it for that reason, the installer sends it again without naming them, and Entra makes them owner. An admin's group is created as before, naming them as owner. If Graph refuses the group for another reason, the installer now warns that there's no viewer group yet, and says to run access and choose A group I already have, instead of stopping with the error. And the plan before Go ahead? says you own the viewer group only when the installer creates it. 0.6.7 has this problem too; its release notes list it as a Known issue.
• Azure: turning on org-scoped access no longer fails with 403 AuthorizationPermissionMismatch. The installer read the scope list from the install's storage account before it gave you Storage Blob Data Contributor there. So unless you already had that role, turning org-scoped access on, opening access once it was on, and applying it during setup could fail with that 403. In testing, it turned on only once a test user was given the role by hand. 0.6.7 has this problem too, and its release notes list it as a Known issue. Now, on Azure, the installer gives you the role before it first reads or writes the scope list, then retries for a few minutes while a new role takes effect. It asks every time, even if the install gave the role to someone before, so a second admin gets it too; if you have it already, that counts as given. If you can't assign roles on the storage account but someone gave you the role, it now goes ahead; before, it could stop and say you needed the role. Without the role, it says to ask an Owner or User Access Administrator for it (Azure portal > the storage account > Access control (IAM)), wait about 5 minutes and try again, instead of showing the 403. Private networking and Fabric are unchanged.
• Azure: Repair keeps a shared-capacity (Pro) install's workspace where it is. A Repair with --yes, or one that took every default, moved it onto your first active capacity. Installers up to 0.6.7 have this problem, and 0.6.7's release notes list it as a known issue. The install record didn't keep the choice None (shared capacity, Pro) at Capacity for the Power BI workspace, so Repair suggested the first active capacity instead. Now the record keeps None, and Repair suggests where the workspace is: the capacity you chose, if it's active; otherwise the active capacity the workspace is on, or None if it's on shared capacity; failing that, None if that was the choice. Earlier installers didn't keep None, so a record with a workspace and no capacity is taken to have chosen it. If the capacity you chose is paused, Repair still suggests the first active capacity, as before. A new install still suggests the first active capacity, and private networking still needs a capacity. Choosing None doesn't move a workspace off a capacity: if a Repair moved yours, set it back to Pro in the workspace's settings in Power BI, then run Repair without --yes and choose None. Fabric isn't affected.
• Azure: scoped delegation in the Share panel no longer fails with 503. With org-scoped access on, the panel couldn't show, give, take back or approve scopes: each request failed at once with "Couldn't reach the Analytics Hub database. Try again in a minute.", even with the database online, and the web app logged SQL connection failed with "must be an instance of the token credential class". The SQL driver copies its settings into plain objects, which dropped the managed identity's getToken, so it refused the identity before connecting. Now the web app hands the driver a credential with its own getToken, which survives the copy. The fault has been in the web app since 0.6.0, but the Share panel offers scoped delegation on Azure only since 0.6.8-rc.2, so released versions, 0.6.7 included, couldn't reach it from the app.

Docs:

• Agent Evaluator: pick environments that save transcripts. Copilot Studio doesn't save conversation transcripts in developer or Dataverse for Teams environments, so Agent Evaluator finds none there. The installer's Agent Evaluator section, Prerequisites and Troubleshooting now say so.

Known issue: on Azure, the schedule can still start a run while another is going, for example when a long first load reaches the scheduled time. If it does, stop the newer run, then reload the history once the other has finished, as Troubleshooting shows. A fuller fix is planned.

Known issue: on Azure, Uninstall deletes the install's managed identity but leaves the roles it was given outside the resource group, such as Reader on the management group and Cost Management Reader on subscriptions. In the Azure portal, they then show as Identity not found. To remove them, see Remove the roles the installer gave, which lists them all. 0.6.7 has this too.

Known issue: on Azure, if you ran the installer again after the first install, Uninstall deletes the install's resources one by one and leaves the resource group. Delete the group in the Azure portal afterwards.

Known issue: the installer doesn't give Agent Evaluator's transcript reader role on the run that creates it, in a new install or an update. While it sets up the new Analytics Hub transcript reader role, Dataverse puts four SharePoint privileges back on it, so the installer warns that the role "should hold only ConversationTranscript read at Organization depth". Until the role is given, Agent Evaluator reads only the transcripts shared with the reader, as in 0.6.7. Run the installer again and choose Repair or change, keeping your answers: the second run takes those privileges off, gives the role, and checks that the reader can read a transcript. Then reload the history once, for example with run --backfill-days 30. A fix is planned.

Known issue: on Azure, Dataverse doesn't let the installer delete Agent Evaluator's application user for good, because the user owns its own user settings record. Uninstall, or unticking an environment, leaves it deactivated with no role, so it can't sign in or read transcripts. The installer says so, but the steps it prints name a filter that the Power Platform admin center's Users page no longer has. The user is listed as Inactive under the environment's Settings > Users + permissions > Application users; deleting it there hasn't been tested. Until it's gone, ticking that environment again finds the user disabled, skips the environment's transcripts, and says to enable it, which a soft-deleted user can't be.

Known issue: on Azure with private networking, Uninstall can fail to delete the resource group, and the installer says it's Succeeded. Power BI can keep the gateway's subnet for up to 72 hours after the gateway has gone. Only the virtual network and network security group are left, and they cost nothing. Run Uninstall again later. See Troubleshooting.

Known issue: on Azure with private networking, the installer can't give the jobs read on the SharePoint drop folder's site, even for a Global administrator. The jobs can't read the files there until a SharePoint or Global administrator makes that grant by hand, as described in Troubleshooting > Known issues > Azure.

Known issue: on Azure, in a browser, the app can show Something went wrong with timed_out a day after you signed in. Clear the site's data for the app's address (or use an InPrivate window) and sign in again. That workaround hasn't been tested yet.

Known issue: on Azure, the browser setup doesn't offer Public endpoints when an Azure Policy keeps Azure SQL's public access off, even in a resource group that's exempt from it. To use Public endpoints there, set up from a terminal: run AnalyticsHubInstaller.exe install --target azure, answer yes to Change the advanced settings?, choose the exempt resource group, and under Networking choose Public endpoints. Setup warns that the policy keeps public access off and that the deployment would fail; with the exemption, it doesn't. A fix is planned.

Known issue: on Fabric, the tenant credits export (tenant by day) from the Power Platform admin center loads with blank dates when its Usage Date has seconds and AM/PM (for example 5/3/2026 12:00:00 AM), so Credit consumption shows no tenant rows, and the load still reports success. The agent and user exports aren't affected, and neither are credits loaded by the Analytics Hub - Copilot Studio credits flow. Until it's fixed, use the flow, or, before you drop the file in or upload it with the installer, re-save its Usage Date in the form 5/3/2026 0:00 (month/day/year, 24-hour time). Re-saving it as yyyy-MM-dd doesn't help: that loads blank too. If a file has already loaded with blank dates, remove it from the landing folder and delete those rows before you load the corrected file. See Troubleshooting.