Microsoft Tech Community - Latest Blogs -

Tuning logical replication on Azure Database for PostgreSQL – Flexible Server

Sarat_Balijepalli — Mon, 10 Jun 2024 13:12:19 PDT

Native logical replication is a built-in feature which was introduced in PostgreSQL 10. It is aimed to replicate data between tables in two separate Postgres databases using a replication identity, usually a primary key. It follows a publisher and subscriber model where there can be one or more publishers or subscribers. The publisher and subscriber databases can be on the same Azure Database for Postgres - flexible server or on two different servers.

The typical use-cases for logical replication are:

Sending incremental changes in a single database or a subset of a database to subscribers as they occur.
Sending the change to subscribers could also help in event driven architectures where the subscriber can process and publish the change to, for example, message brokers like Kafka etc.
Consolidating multiple databases into one data source (for analytical purposes).
Replicating data between different major versions of PostgreSQL.
Replicating between PostgreSQL instances on different platforms (for example Linux to Windows)
Replicating data between servers hosted in different clouds or between on-prem and cloud.

A typical flow involves copying the initial data snapshot from the publisher database to subscriber database and, once the data snapshot copy is completed, any incremental changes on the publisher database are sent to the subscriber database in near real-time.

Using a use-case scenario this blog will share tuning techniques that can be used to improve the performance of the initial data snapshot copy from the publisher to the subscriber database.

The blog is further divided into the following sections:

Server parameters
Use-case scenario
Best practices

Server parameters

The parameters that are used to configure and tune logical replication are as follows:

wal_level: Sets the level of information written to the Write Ahead Log (WAL) to logical.

max_worker_processes: Sets the maximum number of background processes that the system can support. The default value is 8. You can set this value to a number which is greater than the number of subscribers and reserve some for-table data synchronization and parallel apply worker.

max_logical_replication_workers: Specifies maximum number of workers to replicate table data between publisher and subscriber. It includes leader apply workers, parallel apply workers, and table synchronization workers. The default value is 4. Logical replication workers are taken from the pool defined by max_worker_processes.

max_replication_slots: The default is 10. You can set this parameter depending on the number of publishers and subscribers. It can be influenced by the value set to parameter max_sync_workers_per_subscription.

max_sync_workers_per_subscription: Controls the amount of parallelism of the initial data copy during the subscription initialization or when new tables are added. Currently, there can be only one synchronization worker per table. The workers are dependent on max_logical_replication_workers. The default value is 2.

The recommended value is generally about 50% - 75% of the number of vCores on the subscriber server. For example, if the subscriber server is an instance of Azure Database for PostgreSQL Flexible Server running on a Memory Optimized tier, and with an SKU of 16 vCores, then the value of the parameter can be set to 8. This indicates 8 tables can be copied parallelly during initial data copy. To make this change you need to set max_replication_slots, max_worker_processes and max_logical_replication_workers parameters also. A good value for max_worker_processes could be 16 (one worker per one core of CPU), max_replication_slots could be 16 (8 for table data synchronization + additional slots for other purposes) and max_logical_replication_workers could be 12 (for table data synchronization + parallel apply worker workers for in-flight transactions).

Note we recommend 50% -75% of total vCores because, if the number of workers doing initial copy is equal to number of vCores, then you could see 100% CPU utilization on the subscriber server. 50%-75% is just a general recommendation, you can set a higher value but making it too aggressive might result in 100% CPU utilization during initial data copy process on subscriber servers.

max_wal_senders: The maximum number of simultaneously running WAL sender processes. Default is 10. It is recommended to set a value equal to or greater than the number of logical replication slots.

Use-case scenario

In the use case scenario, the publisher database has 6+ tables on Postgres version 16, and the goal is to complete the initial snapshot as fast as possible.

The publisher server is 16 vCore General Purpose Azure Database for Postgres – flexible server with 1 TB storage, and the subscriber server is also a 16 vCore General Purpose Azure Database for Postgres – flexible server with 1 TB storage.

Setup On publisher server:

Server parameters:

wal_level: Logical

max_replication_slots: 12

Execute the following statements on the publisher database:

Grant required permissions

ALTER ROLE <role name> WITH REPLICATION;

Note: Please make sure the replication user has read permissions on tables you are trying to replicate.

Create a publication

CREATE PUBLICATION publisher1 FOR TABLE member_claims, member_claims_May,member_claims_April,member_claims_March,member_claims_Feb,member_claims_January;

Setup on subscriber server:

Server parameters:

wal_level: Logical
max_logical_replication_workers: 12
max_worker_processes: 16
max_sync_workers_per_subscription: 6
Autovacuum: OFF
max_wal_size: 64 (GB)
checkpoint_timeout: 1(Hour)

Execute the following statements on the subscriber database:

Create a subscription

CREATE SUBSCRIPTION <subscription name> CONNECTION'host=xx dbname=xx user=xx password=xx' PUBLICATION <publisher name>;

Monitoring

Publisher database

Execute the following statement

SELECT application_name, wait_event_type, wait_event, query, backend_type FROM pg_stat_activity WHERE state='active';

The output should look like this where 6 tables are being copied parallelly

Subscriber database

Execute the following statement to monitor the progress of the initial data copy.
```
SELECT * FROM pg_stat_progress_copy;
```

For more details on pg_stat_progress_copy you can follow the document COPY-PROGRESS-REPORTING.

Best Practices

In general, it is recommended to have a publisher database and subscriber database on two different servers.
Follow the server parameter guidelines described above.
During the initial data copy phase, you can turn OFF autovacuum, increase max_wal_size to 64 GB if you have a storage size of 1 TB or greater than that [Generally recommended for large storage sizes] and have checkpoint_timeout parameter set to 1 Hour. [We would like the checkpoint to happen less frequently as checkpoint process consumes additional server resources for that purpose 1 hour is recommended. This is again a general recommendation value can be less than 1 hour, it depends on data volume being moved and you can also take into consideration time to recover in case there is a crash during initial data copy phase before coming up with a value]

Note: Once the initial copy is completed it is recommended to vacuum analyze the tables and then turn back autovacuum to ON. The checkpoint_timeout and max_wal_size parameters should also be changed back to previous values.

vacuumdb utility can be used to manually vacuum analyze the tables. For more information follow the document – vacuumdb.

Conclusion

Initial data copy after logical replication is set up between publisher and subscriber databases can be time consuming, particularly when the database size is large with hundreds of tables or database size is large with few large tables. With proper tuning of server parameters mentioned in the blog and having the publisher and subscriber databases on separate servers, you can help reduce the time required significantly.

If you have questions, please contact us at ASK Azure DB for PostgreSQL.

Upcoming Changes to Supported Versions of Visual Studio for Remote Debugging with Azure App Service

gauravseth — Mon, 10 Jun 2024 12:45:40 PDT

You can attach the Visual Studio debugger to any .Net process running on Azure App Service. This allows you to debug the deployed web app as though it's running locally.

For more information about how to attach Visual Studio debugger for a web app deployed to Azure App Services please refer to:

Remote Debug ASP.NET Core on Azure App Service (Windows)

Troubleshoot with Visual Studio - Azure App Service | Microsoft Learn

Over the past few years, we have received feedback from our customers regarding the opening of ports on local machines to use remote debugging with App Service. This often requires multilevel approvals and leads to configurational & operational complexity.

Based on this feedback we are announcing changes related to supportability of Visual Studio versions for remote debugging of Windows web applications deployed to App Service. These changes will remove the requirements for local ports when using remote debugging with App Service.

Versions of Visual Studio prior to Visual Studio 2022 will no longer work with the updated remote debugging feature on App Service. Visual Studio 2022 will work with the updated remote debugging feature, but customers will need to upgrade to a newer version of Visual Studio 2022 no later than January 31, 2025. The changes to remote debugging on App Service outlined in the table below will be applicable starting June 2024.

The table below provides an overview of these changes.

Visual Studio	Version	Basic Authentication enabled for the specific App Service web app ###	Remote Debugging Supported	Applicable Timeline	Local Ports Required
2017	All	N/A	No	Starting June 2024	N/A
2019	All	N/A	No	Starting June 2024	N/A
2022	17.9 or earlier	Yes	Yes	Until January 31, 2025	Yes. On local machine
2022	17.9 or earlier	N/A	No	After January 31, 2025	N/A
2022***	17.10 or later	N/A	Yes	N/A	No local machine ports required. Remote debugging no longer uses basic authentication on App Service.

It’s important to note that the contents of this blog post are not applicable for remote debugging experience related to App Service Linux.

*** Please note that starting Jan 2025 remote debugging for Windows web applications deployed to App Service will be available only when using Visual studio 2022 version 17.10 or later. Remote debugger authentication for a web application no longer uses basic authentication on App Service.

### There are no changes to basic authentication publishing on Azure App Service. The table above refers only to basic authentication on App Service used in conjunction with the remote debugging feature. Please refer to Authentication types by deployment methods - Azure App Service | Microsoft Learn and Disable basic authentication for deployment - Azure App Service | Microsoft Learn for details.

In the coming weeks changes will also be made to the Azure portal experience matching the remote debugging support as explained above.

Microsoft Defender for Cloud Apps’ Shadow IT Discovery Capabilities Now Support MacOS

Madhurika_Ravela — Mon, 10 Jun 2024 12:31:50 PDT

The rapid growth of SaaS apps makes it challenging to gain visibility across the apps used in an organization’s environment. SaaS apps are often used without the awareness of IT departments, a phenomenon known as Shadow IT. Moreover, the swift adoption of generative AI apps introduces an additional layer of security complexity and risks. Organizations need effective app security solutions more than ever to ensure that employees only access approved and safe apps.

A key aspect of combating Shadow IT is ensuring comprehensive visibility into all the apps used in an organization’s environment, which includes the identification of all SaaS apps used by employees, regardless of the operating system. This broad scope of app discovery is essential in providing a holistic view of your SaaS landscape to help security teams discover and control Shadow IT effectively.

Gain full visibility into your SaaS apps with Microsoft Defender for Cloud Apps
Microsoft Defender for Cloud Apps offers powerful discovery capabilities to help you gain visibility into all SaaS apps, including AI apps, in your organization, assess their risk, and leverage sophisticated analytics to enhance the overall SaaS security. Previously, cloud discovery discovered SaaS apps in Windows devices through the network logs via defender for endpoint integration. To continuously improve our product experience and deliver a broader scope of app discovery, today we are thrilled to announce the public preview of our new comprehensive discovery capabilities within Microsoft Defender for Cloud Apps to help customers:

Discover Shadow IT SaaS apps on macOS devices in addition to windows
Detect and remediate risky/unusual behaviors on SaaS apps on macOS devices

This discovery capabilities on macOS work seamlessly with the native Microsoft Defender for Endpoint. This enhancement not only bolsters the discovery process but also improves the overall discovery comprehensiveness for security administrators, facilitating effective management of SaaS security risks.

For customers who do not use the native Microsoft Defender for Endpoint integration with Defender for Cloud Apps, we have ensured comprehensive discovery coverage by introducing the highly requested enhancements to our log collector. Specifically, we have added two new capabilities to the Defender for Cloud Apps log collector, enabling it to operate on popular container runtimes such as Podman and AKS. With these capabilities, customers can leverage the log collector to thoroughly discover shadow IT apps on other popular distros like RedHat and AKS.

Discovery on macOS via Microsoft Defender for Endpoint

Customers need to enable the network protection component in Defender for Endpoint in order to discover shadow IT on macOS. Here is a quick guide on how to enable network protection.

Once you have the network protection enabled, to access the discovery of shadow IT SaaS apps, navigate to the Cloud discovery tab in the Microsoft Defender portal. Once there, you’ll find Defender - managed endpoints listed under the stream as shown in Figure 1. Selecting this stream presents you with a comprehensive view of discovered applications, resources, IP addresses, users, and devices information for both Windows and macOS devices within your tenant. This unified view facilitates a more complete understanding of Shadow IT across different operating systems.

Figure 1: The navigation path in the Microsoft Defender portal, under the Defender - managed endpoints stream.

Podman support for the Defender for Cloud Apps log collector

The log collector, a container image that traditionally operates on Docker runtime, now extends its support to Podman, the container runtime and orchestrator endorsed by Red Hat Enterprise Linux (RHEL) 8 and subsequent versions. This expansion ensures that the Defender for Cloud Apps log collector is compatible with Podman’s runtime, accommodating customers who use RHEL versions 8 or higher.

The Defender for Cloud Apps log collector is extremely useful for organizations not using the integration with Defender for Endpoint, or a direct integration with a built-in network device isn’t available. It helps to integrate logs from various network appliances, such as firewalls, to generate a discovery report that is pivotal for administrators to pinpoint Shadow IT apps and gather usage telemetry.

Log collector in Azure Kubernetes (AKS)

The log collector feature in AKS enhances Defender for Cloud Apps by enabling the collection of logs from network devices that lack built-in integration. This feature is particularly beneficial for customers who prioritize disaster recovery and resilience for their services hosted on AKS.

With the introduction of log collector support for AKS, Defender for Cloud Apps has expanded its capabilities to include support for Syslog-tls receiver types. Once the log collector deploys log collector on AKS, Customers can configure log sources on AKS and get insights into Shadow IT on AKS workloads.

Our latest enhancements to the shadow IT discovery capabilities in Defender for Cloud Apps empower security administrators with comprehensive app discovery across both Windows and macOS and offer better compatibility and flexibility in deployment. Furthermore, Defender for Cloud Apps is a core component of Microsoft Defender XDR, and these new advancements contribute to delivering a more streamlined and easier to deployable XDR platform that enables security teams to more efficiently protect organizations from today’s advanced cyberthreats.

Getting started

Controlling Data Egress in Azure

CraigDuBose — Mon, 10 Jun 2024 12:08:59 PDT

Summary: Regulated companies impose stringent requirements on data governance to prevent data exfiltration. As a Cloud Architect, ensuring the safe and efficient exit of data from our network to external destinations is paramount. This document aims to provide a comprehensive guide to the strategies, best practices, and tools we employ at various customers to maintain robust security measures.

What Azure services allow data egress?

Virtual Network subnets or VMs without UDR or BGP Control - traffic can leave the default outbound access IP which is not controllable or managed by the customer.
- Private VNETs will be available with secure by default enabled scheduled 2025 and will provide a means to disable this unmanaged Public egress pattern. - Azure Private Subnet
- User Defined Route (UDR) - Routes added to UDRs can inject routes to VMs and services deployed to a subnet.
  - A UDR can have a route that directs traffic directly to the internet, but this traffic would go out as mentioned above via a customer unmanaged IP address.
  - If the Subnet has a NAT Gateway associated to it and has a route targeting traffic to next hop internet, it should reach the public internet via the NAT Gateway's associated IP addresses.
  - If the Subnet has a route targeting traffic to next hop Azure Firewall or 3rd party NVA, the traffic will reach the internet via that devices route table or public IP address.
NAT Gateway - NAT Gateway plays a role in allowing a subnet to reach the internet from a specific IP address or prefix. This allows data to leave and reply to requests BUT does not allow an Ingress point for data.
- A scenario here would be: I have an Azure VM that needs to reach out to our partner who whitelists IP addresses that can communicate with them. A NAT Gateway would allow that known public IP address to be provided to the partner without allowing unsecure access to your virtual machines. More information can be found here: NAT Gateway
VNET Gateway for Express Route or VPN (VNG) - Data can only leave Virtual Network Gateways if it is going through a Express Route or VPN (S2S or P2S). If traffic destined for the public internet is directed to the VNG, the traffic will drop. If you need traffic from subnets to leave a known IP address on your network, please leverage NAT Gateway. If Traffic is directed via a BGP or UDR entry to an on-prem IP address, the traffic can pass through the VNET Gateway over the secure connection to the on-prem IP address for egress.
Public IP Addresses - If an Azure VM or PaaS service has a public IP address, traffic will egress from that known published Public IP address.
- For example, if a 3rd party network solution (Cisco or Palo Alto for example) is deployed on a VM in Azure with a public IP address associated to it, traffic on the internet would show that data's source would be the public IP address assigned to the VM. Public IP Egress for VMs
- External Load Balancer (ELB) - For example, if a 3rd party network solution (Cisco or Palo Alto for example) is deployed on a VM in Azure without a public IP address associated to it, but has a Public Standard Load Balancer attached, the traffic on the internet would show that data's source would be the public IP address assigned to the ELB. Azure VM Outbound Connectivity Methods
- For PaaS Services with Public IP addresses, it can reach the internet through its public IP Address. If the PaaS Service supports VNET integration, that traffic can be redirected to the appropriate network services to control/govern that data as needed. If VNET integration is enabled and the subnet connected to the PaaS service has a NAT Gateway or a UDR directing the applicable traffic, the traffic would come from that known IP address instead. Azure VNET Integration
Public IP Prefix - Public IP Prefixes allow a group of IP addresses to be used for data egress on services such as Virtual Machines, Standard Load Balancers, Azure Firewall, and VPN Gateway. The benefit of this service is to allow you to expand past the standard network limits for a single public IP address such as SNAT (Source NAT). Azure Public IP Prefix
Azure Firewall (AzFW) - Azure Firewall is a scalable Cloud-Native Firewall. AzFW can replace or supplement 3rd party network solutions in a number of secure network designs, but focusing on egress, traffic directed to the Azure Firewall can egress to the internet via a NAT Gateway or an associated public IP address. Azure Firewall Public IP Address
Azure Firewall has a huge number of security benefits which can be found: Azure Firewall Version Comparison

Now that we discussed what can egress, how can we monitor/secure it? What does this look like in practice?

Azure Network Security Group (NSG) - As mentioned in various documents, micro segmentation is a key component of ensuring zero trust and reducing attack surfaces for network attacks. When creating NSG rules - similar to ACLs (Access Control Lists) in other network solutions, ensure only approved traffic is allowed. NSGs
- Example: If I have a web server running on a windows VM that doesn't require egress, ensure the NSG rules specify:
- Inbound:
  - Allow port 443 for https from its allowed sources at priority 100
  - RDP for management/access at priority 101
  - Implicit DENY for all inbound traffic at rule priority 4000.
  - Default rules at 65000, 65001, and 65500 should be ignored.
- Outbound:
  - Allow outbound communication to authentication servers at priority 100
  - Allow outbound communication to DNS servers at priority 101
  - Allow outbound communication to management applications at priority 101
  - Implicit DENY for all outbound traffic at rule priority 4000.
  - Default rules at 65000, 65001, and 65500 should be ignored.

NSGs have default rules that allow certain traffic BEFORE the implicit deny. If you are advertising addresses through a Virtual Network Gateway from a Site-to-Site VPN or BGP configuration, the on-prem communication may be allowed as part of the 'VNET communication' default rule since it is a private address that announced to your Virtual Networks.
Flow Logs:
- Only Option Until April 2024 - NSG Flow Logs - NSG Flow logs can help monitor what traffic is being allowed to reach the various sources including the public internet. This information can be sent to a SIEM solutions for central review of all traffic from Azure.
- VNET Flow logs was released April 2024, can simplify the capturing of flow logs and be deployed per VNET instead of per subnet. - VNET Flow Logs
Azure UDR - User Defined Routes can control what routes are published to subnets in Azure and can control if routes from on-prem are published to Azure. Routes such as Communication to IP addresses, IP ranges, or Azure Services can be manipulated to direct traffic. For example, if an environment is using an Azure Firewall for Azure Native traffic, but all other traffic firewall should be going to a particular 3rd party solution to leave the environment:
- Subnets will have a UDR that directs the applicable Service Tag will say next hop = Azure Firewall.
Azure Service Tags - A Service Tag is a Microsoft Managed logical grouping of public IP addresses in the Azure Backbone to provide access to services with or without region association. Examples can be found: Service Tags
Azure Policy
- NSGs should be associated with all subnets
- Flow Logs should be deployed to capture all data on networks in Azure.
  - Per Subnets - Flow logs should be configured for every network security group
  - Per Virtual Networks - Audit flow logs configuration for every virtual network

What can govern your Azure Data Egress requests?

Azure Firewall
- Deploy Route Table to control traffic. Azure Firewall UDR Support
- Network Rules on Azure Firewall to control traffic
3rd party NVAs (Palo, Cisco, Juniper, etc)
- Deploy Route Table to control traffic. Azure Firewall UDR Support
- Network Rules on NVAs to control traffic
Azure NSGs
- Deployed per subnet as mentioned above.

In conclusion, the secure management of egress traffic is a critical component of our overall security posture. By adhering to the guidelines and principles outlined in this document, we fortify our defenses against potential threats and ensure the integrity of our data as it traverses beyond the confines of our internal network. Thank you for your commitment to upholding these standards and contributing to our collective security efforts.

What's new in Viva Insights

zachminers — Mon, 10 Jun 2024 11:11:28 PDT

Updates to Copilot Dashboard

Configurable minimum aggregation threshold

The Copilot Dashboard allows users to filter analysis to a desired group, while hiding results if the selected group does not meet a minimum group size for user privacy. To enable customers with more control in specifying the desired privacy threshold, Viva Insights admins can now configure the minimum group size. The default minimum group size is set at 10 and can be lowered to a minimum of 5.

Copilot assisted hours breakdown by app and activity

Copilot assisted hours enables users to estimate the amount of time employees were assisted using Copilot. Users can now select How do we estimate this? to see a breakdown of the Copilot actions that contributed to the hours assisted, and can use the insights to better understand how the total hours assisted is calculated.

Date ranges

Specific date ranges that represent the time period of analysis have been added to the Copilot dashboard.

Microsoft 365 Copilot metrics now available in the metric library in Advanced insights

We’ve added the Microsoft 365 Copilot metrics to the metric library in Advanced insights. As a result, we’re removing the checkbox in the person query that lets analysts add the metrics to their person query. Analysts can now find these metrics in the metric library and in the “add metrics” step in a person query under the “Microsoft 365 Copilot” section.

Meeting cost and quality in the Viva Insights Teams app

With this set of new features, employees can improve meeting time for their colleagues or themselves, and managers and leaders can understand the business case for balancing meeting cost and quality within their organizations.

Each user can choose whether to view meeting cost as hours or currency, and they can edit those settings in the Viva Insights app. Admins can also adjust this setting for others.

Meeting cost and quality report

Eligible managers in Viva Insights will see a report about how much time their team spends in meetings and what share of it goes to high-cost large or long recurring meetings. Reviewing just one or two high-cost meetings can help many others get back their time.

“Like” button

Managers can show other people in their organization if they like the idea of reviewing meetings to balance meeting cost with meeting quality by selecting the Like button. When they do, they’ll be added to the list of people who have liked the scenario, and other Viva Insights users in the company may see their name or picture on related content. If the manager changes their mind, they can select the Like button again.

Meeting review card

The meeting review card is available for both managers and non-managers. The card has two faces: Meetings you organized, and Meetings you’re attending. The meetings I’ve organized side presents opportunities to improve meeting time for your colleagues, and the meetings I’m attending side presents opportunities to improve meeting time for myself. Users can see meeting insights, edit the meeting or their RSVP, or simply mark the meeting as “reviewed” to manage the list.

Meeting compose nudge

The meeting compose nudge encourages users to pay attention to the duration, frequency, and invitee list for high-cost meetings. When a user creates a new meeting in Outlook, it can trigger the infobar message to let the user know when the meeting cost (duration x frequency x invitees) is getting high.

The user can expand the message to open the Viva Insights add-in, which offers actionable suggestions. Accepting suggestions to reduce frequency or shorten duration will immediately update the invitation with a new, less costly configuration.

Viva Feature Access Management

If for any reason meeting cost features aren’t a good fit for some Viva Insights users, admins are able to toggle these features for groups or individuals using Viva Feature Access Management.

Data egress with Microsoft Graph Data Connect

We’re excited to announce the public preview release of Viva Insights data egress with partition support via Microsoft Graph Data Connect (MGDC). Customers can now export Viva Insights data (e.g., computed metrics, imported attributes) from any partition, using flexible queries that also support our PBI templates, into Azure storage. This feature enables customers to build custom analytical solutions by exporting and integrating Viva Insights data with external data or applications. They can integrate insights into business applications like CRM or perform more comprehensive analyses for purposes like workspace planning.

The MGDC export solution is scalable and secure, with the following benefits:

It allows for seamless data access at scale with integrations to the Azure toolchain to enable an accelerated path to insights.
It empowers administrators to review and explicitly consent to the types and amounts of data that applications may consume.
It alleviates concerns and allows organizations to establish detailed data governance policies about how sensitive data is handled, keeping customer data within a single, trusted service boundary.

Learn more about data egress via MGDC.

View Power BI templates in the advanced insights web app

We’re proud to announce the release of a new way to view Power BI templates in the advanced insights web app, leveraging Power BI embedded. With this new option, analysts no longer have to set up Power BI templates in Power BI Desktop, and can instead view them directly in the web app.

After successfully running a Power BI template query, analysts will find a new option to View it in the Query results page, along with the current Data export options, like download .csv.

Upon selecting View, a fully interactive Power BI template is opened. Analysts can navigate across the different pages in the report using the navigation menu and use all the features already available in our Power BI templates, like selecting the employee attributes to view and filter the report by web app.

Users with the Insights Analyst role can view Power BI templates in the advanced insights web app.

New out-of-the-box leader reports

New leader deep-dive reports in Viva Insights focus on customers, business operations, and agility. You can find these reports under Team insights in the Viva Insights app in Teams and on the web.

With these reports, leaders can view a variety of metrics and suggested actions focused on specific business outcomes. Leaders can further drill down into the insights with custom filters such as time periods and breakdowns by group.

The new reports include:

External focus

This report helps leaders understand how employees are managing external relationships, and how different parts of the company may have been impacted by business shifts.

This report can help leaders improve their strategies for communicating and collaborating with external groups. And for groups with increased external engagement, these insights can help leaders ensure these engagements don’t come at the expense of increased after-hours work.

New hire onboarding and integration

The New hire onboarding and integration report helps leaders understand the onboarding experience of new hires as well as the transition for employees who've started out in a new role within the company. The report also identifies opportunities to improve the onboarding and professional development experience.

Because research shows it takes new employees 12 months on average to reach their full performance potential, this report focuses on the entire 12-month period a new hire is learning, connecting, and developing in their new role.

This report can help leaders answer the following questions:

How are new hires developing their network, and how fast are they integrating into the organization’s network?
Are new hires getting the 1:1 coaching and support from their managers that they need?
Is the organization sufficiently encouraging new hires and employees to set aside time for learning and training?

Learn more about the new reports.