To discover and back up workspaces and environments in the Druva console, you must complete specific configurations in your Microsoft Azure, Power BI, and Power Platform environments. These steps enable the Druva Service Principal to access the required APIs.
Prerequisites
Use the following prerequisites to authorize the workloads you want to protect.
Power BI
Complete the following prerequisites to discover and back up Power BI workspaces.
Prerequisite step | Why this is required | Who should perform this |
Step 1: Create/update Azure Security Group with name "DRUVA-SG-DPPSPN-DR" and add the Druva Power Platform app as a member | Creates a dedicated identity container in Entra ID with a specific name so the Druva service principal has the correct security group identity. The security group must be named "DRUVA-SG-DPPSPN-DR" or reports will not be backed up. | Azure AD / Entra ID administrator with permissions to create security groups and manage enterprise applications. |
Step 2: Authorize the security group for Power BI Admin and Fabric public APIs | Grants the security group created in step 1, permission to call Fabric public APIs and read‑only admin APIs so Druva can discover and list tenant workspaces without tenant‑wide admin rights. If skipped, Druva cannot scan the tenant and discovery will not begin. | Power BI service administrator or Fabric administrator with access to the Power BI Admin portal tenant settings. |
Power Apps
Complete the following prerequisite to discover and back up Power Apps.
Prerequisite step | Why this is required | Who should perform this |
Step 1: Register an Admin Management Application for Power Apps Register the application with Microsoft Power Platform using the PowerShell script or the Power Platform APIs. | Registers Druva's management application with Microsoft Power Platform so Druva can discover Power Apps environments and back up Power Apps data. If skipped, Power Apps discovery does not start. | The registration must be performed by a Global or Power Platform Administrator, as service principals cannot self-register. |
📝Note: Power BI and Power Apps have separate prerequisites. Complete the prerequisites for each workload you want to protect.
Power BI - Step 1: Create/update Azure Security Group
Objective: Create a standard Security Group in Azure to house the Druva service principal.
Access Azure: Log in to the Azure Portal.
Create Security Group: Navigate to Entra ID > Groups > New group.
Group type: Select Security.
Group name: Enter the exact name: DRUVA-SG-DPPSPN-DR
⚠️ Important: The security group name must match exactly. If the name does not match this value, reports will not be backed up and discovery may fail.Group Description: Provide a description for this group (e.g., "Druva service principal for Power BI backup and recovery").
Add Druva Application Member:
Open the newly created group and select Members > Add members.
Search Criteria: Search for the application name Druva Powerplatform.
Action: Select the application and click Select to add it to the group.
Summary: You have created a container (Security Group) with the exact name "DRUVA-SG-DPPSPN-DR" and added the Druva service principal (Druva powerplatform app) as a member to enable identity-based permissions.
⚠️ Critical: Ensure the security group name is spelled exactly as "DRUVA-SG-DPPSPN-DR". An incorrect or misspelled security group name will prevent reports from being backed up and cause discovery failures.
Power BI -Step 2: Authorize Power BI Admin and Fabric Public APIs
Objective: Grant the Security Group created in Part 1 permission to access Power BI Admin read-only APIs.
Access Admin Settings: Log in to the Power BI Admin Portal.
Locate API Settings: Navigate to Tenant settings > Admin API settings.
Configure 'Service Principal settings':
Find the setting: Service principals can call Fabric public APIs under Developer Settings section.
Set the toggle to Enabled.
Define Access Scope:
Under Apply to, select the radio button for Specific security groups.
Search: Enter the name of the Security Group created in Step 1.
Click Apply.
Find the setting: Service principals can access read-only admin APIs under Admin API Settings section.
Set the toggle to Enabled.
Define Access Scope:
Under Apply to, select the radio button for Specific security groups.
Search: Enter the name of the Security Group created in Step 1.
Click Apply.
Summary: By enabling the Service Principal setting for a specific group, you have authorized the Druva application to call Power BI APIs without granting tenant-wide administrative rights.
📝NOTE: If the Azure environment setup is complete but discovery is not working, ensure that KMS is configured. Without KMS enabled, discovery will not initiate.
Power BI -Step 3: (Optional) Manual Workspace Access Assignment
Manually adding the Druva security group to individual workspaces is no longer required for backup operations. The security group configuration in Steps 1 and 2 provides automatic workspace access to all workspaces.
However, if you want to restrict Druva's access to specific workspaces only (for security or audit purposes), you can optionally follow these steps:
📝 Note: Due to Microsoft API limitations, backing up personal workspaces is not supported.
Open the Power BI admin portal and navigate to Workspaces.
Locate the required workspace, click the three dot menu (⋮) next to it, and select Access.
In the access panel, search for the Security Group (DRUVA-SG-DPPSPN-DR) by name and select it.
From the Permissions dropdown, choose Contributor.
Click Add to apply and save the changes.
Important: Synchronization Latency Microsoft may require up to 24 hours to synchronize permission changes across the environment.
Power Apps -Step 1: Register an Admin Management Application
Objective: Register Druva’s Admin Management Application with Microsoft Power Platform so Druva can discover environments and back up Power Apps.
📝NOTE: This step is required only for Power Apps. Power BI discovery uses Steps 1 and 2. Until this Power Apps prerequisite is complete, Microsoft Power Platform > Overview shows Discovery Not Started for Power Apps, with Waiting for prerequisite completion and a View Prerequisite button.
In the Druva console, go to Microsoft Power Platform > Overview.
In the Power Apps section, select View Prerequisite. The Power Apps Backup Prerequisite pane opens.
Under Register an Admin Management Application, click the copy icon on the wizard to copy the
register_powerplatform_management_app.ps1PowerShell script's download URL to your clipboard, then paste it into your browser's address bar and press Enter to download the script.Run the downloaded PowerShell script as an administrator. When prompted, provide:
M365 Tenant ID
Application ID (Druva Application ID)
The script registers the application with Microsoft Power Platform. You can also perform the registration using the Power Platform APIs.
📝NOTE: The registration must be performed by a Global Administrator (preferred) or Power Platform Administrator.
After the registration completes successfully, return to the Druva console and refresh the Overview page.
Result: Druva can discover the Power Platform environments in the tenant, enabling Power Apps discovery and backup.
❗IMPORTANT: A Global administrator must perform this registration. Service principals cannot register themselves as Admin Management Applications.
Verify Discovery Status
After configuration, Druva automatically scans the tenant. Check the Status Indicators:
Connected: The app is successfully authenticated.
Discovery Not Started: This status appears if the Azure prerequisites (Security Group/API settings) are not detected, or if the Power Apps Admin Management Application is not registered. You must complete the steps before discovery can proceed.
Once all prerequisites are met, discovery begins automatically. After the environment scan is complete, the system populates the list of workspaces and environments.