Configure a dataset scheduled refresh – Deploy and maintain assets

Configure a dataset scheduled refresh

When you build a report, a common requirement is to keep the underlying data up to date. You can refresh a dataset manually in Power BI Desktop or the Power BI service, but this approach isn’t viable when you need to refresh data periodically. To address this issue, you can configure a scheduled refresh in the Power BI service.

You configure a scheduled refresh for each dataset individually in the dataset settings. For this, expand the Scheduled refresh section of the dataset settings and switch the Keep your data up to date toggle to On. You will then be able to configure refresh frequency and other settings, as shown in Figure 4-1.

FIGURE 4-1 Scheduled refresh settings.

You can configure the following settings for scheduled refresh:

  • Refresh frequency Specify how often the dataset will be refreshed: Daily or Weekly. If you set this option to Weekly, you can select the days of the week the refresh will run.
  • Time zone The time zone of refreshes.
  • Time You can add the time of refreshes in 30-minute intervals. The maximum number of refreshes you can set depends on whether the workspace is backed by a Premium capacity.
  • Send refresh failure notifications to This option can send an email to the dataset owner in case of a refresh failure. You can enter email addresses of other users who will receive the notifications, which can be useful when multiple people are responsible for the dataset.

After you adjust settings, select Apply. If you select Apply without setting the scheduled refresh time, your dataset will refresh at midnight.

You can see refresh history of a dataset at the top of the dataset settings by selecting Refresh history.

Sharing through an app – Deploy and maintain assets
Sharing through an app

You can also make your dataset available for others when you share an app with them. For this, you’ll need to grant the app users the Build permission by selecting the Allow all users to connect to the app’s underlying datasets using the Build permission check box, as shown in Figure 4-5.

FIGURE 4-5 App permissions.

Note Apps

We’re reviewing Power BI apps in more details in Skill 4.2: Create and manage workspaces.

Important Dataset Permissions

Removing app access for a user or a security group doesn’t automatically revoke their access to the underlying datasets. To remove the dataset access completely, you may have to do it by managing permissions of the datasets, as covered next.

Without the Build permission, users won’t be able to connect to your dataset unless they’re contributing workspace members or you give them access to the individual dataset.

Managing dataset permissions

If you want to share an individual dataset, you can do so by managing dataset permissions. To view the permissions of a dataset, select Manage permissions from the dataset menu. You’ll then see a list of users who have access to the dataset, as shown in Figure 4-6.

FIGURE 4-6 Dataset access.

If the dataset resides in a shared workspace, you’ll see the role each workspace member has. Users can have the following permissions:

  • Read The minimum level of access needed to view reports based on this dataset.
  • Reshare Allows users to reshare reports and dashboards based on this dataset.
  • Build With this permission, users can build their own reports from this dataset.

To share a dataset with a new user, follow these steps:

Select Add user.

Enter email addresses or security groups under Grant people access.

Select the permissions you want to grant. You can allow recipients to either reshare the artifact or build new content from the underlying datasets.

Select Grant access.

If you want to change the existing permissions for a user or security group, select Permission options (the ellipsis) next to a user or security group and select the desired action, such as add or remove a permission. Note that workspace roles can’t be changed here.

Note Workspace Roles

We review workspace roles in Skill 4.2: Create and manage workspaces.

Assign workspace roles – Deploy and maintain assets

Assign workspace roles

You can see the list of users who have access to a workspace by selecting Access from the workspace, where you can also add or remove users. To reflect the different needs of users, Power BI offers four workspace roles:

  • Viewers can
    • View dashboards, reports, and workbooks in the workspace.
    • Read data from dataflows in the workspace.
  • Contributors can do everything that viewers can do and
    • Add, edit, and delete content in the workspace.
    • Schedule refreshes and use the on-premises gateway within the workspace.
    • Feature dashboards and reports from the workspace.
  • Members can do everything that contributors can do and
    • Add other users as members, contributors, or viewers to the workspace.
    • Publish and update the workspace app.
    • Share and allow others to reshare items from the workspace.
    • Feature the workspace app.
  • Admins can do everything that members can do and
    • Update and delete the workspace.
    • Add and remove other users of any role from the workspace.

As mentioned earlier in the chapter, there’s a workspace setting that allows contributors to update apps. This setting can be useful when you want a user to be able to update an app but not add other users to the workspace.

Note that giving someone a role in a workspace does not remove the need to give them additional rights. For example, you may make a user an admin of a workspace, but unless they have a Power BI Pro license, they won’t be able to fully use the role.

Important Row-Level Security

Row-level security applies only to viewers since all other roles have full access to all datasets within a workspace.

Exam Tip

You should know which role is appropriate for a user based on the business requirements. In most cases, you should follow the principle of least privilege.

Viewing as roles in the Power BI service – Deploy and maintain assets
Viewing as roles in the Power BI service

As you saw with the View as feature in Power BI Desktop, you can test roles in the Power BI service. For this, you need to hover over a role on the Row-Level Security page and select More options (the ellipsis) > Test as role. You will then see the way a report appears to the members of the role. For example, Figure 4-4 shows what members of the Plains role would see, which you created in Chapter 2, “Model the data.” The role applies a filter on Sales Territory.

FIGURE 4-4 Testing a role in the Power BI service.

If needed, you can test a combination of roles or view as a specific user by selecting Now viewing as in the blue bar at the top and selecting the desired parameters. Once you are satisfied with how the roles work, you can select Back to Row-Level Security.

Important Row-Level Security and Workspace Roles

Row-level security does not work on users who have the Contributor, Member, or Admin role in the workspace in which the dataset resides. Those who have edit rights will always see the whole dataset regardless of the security settings, even though the Test as role feature may show a filtered dataset.

We review workspace roles in Skill 4.2: Create and manage workspaces.

Provide access to datasets

The Power BI service enables collaboration between different users. To let other users build reports based on a dataset that you published, you have to share the dataset with them. There are several ways of achieving this, as described next.

Sharing through a workspace

When publishing to the Power BI service, you can publish to your own workspace or a shared workspace. Contributing users of shared workspaces will automatically have access to the dataset you publish.

Permissions – Deploy and maintain assets
Permissions

On the Permissions screen, you can select who has access to the app. You can grant access to the entire organization or specific individuals or groups. If you only grant access to specific individual or groups, you can select Install this app automatically so that it automatically appears in the Apps section of the Power BI service for each user—otherwise, each user will have to install the app manually from the Apps section.

Note Access for Workspace Users

Users and groups with access to a workspace can access the corresponding app without you explicitly granting them access.

For users with access to the app, you can grant the following rights:

  • Allow all users to connect to the app’s underlying datasets using the Build permission Although the datasets won’t show up in the app, this setting allows you to connect to datasets from Power BI or use Analyze in Excel.
  • Allow users to make a copy of the reports in this app This setting allows users to copy reports to their personal workspaces to customize them. It is available only if the Build permission is granted.
  • Allow users to share the app and the app’s underlying datasets using the Share permission Note that connecting to the datasets requires the Build permission.

The Permissions screen is shown in Figure 4-13.

FIGURE 4-13 App permissions.

App view

Once you publish an app, the result will look like Figure 4-14.

FIGURE 4-14 App view.

Note that the interface only has the app navigation; to go back and see the standard Power BI sidebar, you can select Power BI in the upper-left corner.

Update a published app

After you publish your app, you can make changes to it if you are a contributing workspace user. For this, you need to go to the app workspace and make the changes you want; once you have made the changes, go back to the app workspace list of contents and select Update app. You can also update the Setup, Navigation, and Permissions settings that you configured when you created the app, and then select Update app > Update to propagate the app changes.

Note that on the Permissions screen, you will see the app link, as well as dashboard and report links. When you share any of those links, users will see all contents of the app, not just dashboards or reports.

Unpublish an app

If you want to unpublish an app, you can do so from the app workspace by selecting More options > Unpublish app > Unpublish. Doing so will not delete the app workspace contents; instead, the app will be removed from the list of apps of each user and become inaccessible.

Publish, import, or update assets in a workspace – Deploy and maintain assets

Publish, import, or update assets in a workspace

You can publish a report to the Power BI service from Power BI Desktop by selecting Publish on the Home ribbon. To publish a report from Power BI Desktop, you must be signed in. By default, your report will be published to your personal workspace, unless you already published to another workspace in the same session. If you are a contributor in other workspaces, you can select a workspace to publish to.

If the workspace you are publishing to already contains a dataset with the same name, you will be asked if you want to replace it, and you’ll see how many workspace items it affects, as shown in Figure 4-15. This feature can be particularly useful when you’re updating a dataset that has other reports built from it.

FIGURE 4-15 Dataset impact.

An alternative to publishing from Power BI Desktop is to publish from the Power BI service by going to a workspace and selecting New > Upload a file. You’ll be given a choice to publish a local file, a file from OneDrive, or a file from SharePoint, as shown in Figure 4-16.

FIGURE 4-16 Creating new content from files.

Selecting Local File will prompt you to select a file from your computer to publish, whereas OneDrive and SharePoint options allow you to publish from the cloud. Publishing from OneDrive can be beneficial because you can edit a report locally in Power BI Desktop in a folder that’s synced to OneDrive, and it will be published automatically upon saving and closing the file because Power BI can sync published files from OneDrive.

Apply sensitivity labels to workspace content

Within an organization, different data may have different security levels. For example, some data must not leave a specific department, and other data may be shared publicly. To help users understand the sensitivity level of workspace content, you can apply sensitivity labels.

Note Enabling Sensitivity Labels

For users to be able to apply sensitivity labels, they must be enabled in Power BI admin portal tenant settings, typically by the central IT department in the organization. The admin portal is out of the scope of the exam. For more information, see “Enable sensitivity labels in Power BI” at https://docs.microsoft.com/en-us/power-bi/admin/service-security-enable-data-sensitivity-labels.

When information protection is enabled in your Power BI tenant, you can set a sensitivity label for a workspace item in the following way:

Go to the settings of a workspace item.

Select a sensitivity label from the dropdown list under Sensitivity label.

Optionally, check Apply this label to the dataset’s downstream content or similar.

Select Apply or Save.

After you set a sensitivity label, it will be displayed when anyone views the item, as well as in the list of workspace contents, as shown in Figure 4-17.

FIGURE 4-17 Sensitivity labels.

Note how two reports have sensitivity labels shown in the Sensitivity column. If you hover over a sensitivity label, you’ll see its description.

Configure row-level security group membership – Deploy and maintain assets

Configure row-level security group membership

Configuring row-level security (RLS) is a two-step process. In Skill 2.2: Develop a data model, we reviewed the first step—implementing RLS roles in Power BI Desktop. In this section, we review the steps needed to complete the RLS setup for a dataset; we assign and test roles in the Power BI service.

Assigning roles in the Power BI service

Once you’ve configured row-level security roles in Power BI Desktop, you need to publish your report to the Power BI service and add members to each role. To do so, go to the dataset security settings by hovering over a dataset in the list of workspace items and selecting More options > Security. If you don’t have any roles defined in the dataset, you’ll see the message in Figure 4-2.

FIGURE 4-2 The RLS has moved to Power BI Desktop message.

If you’ve created RLS roles defined in the dataset, you’ll see a page like the one shown in Figure 4-3.

FIGURE 4-3 Row-level security role membership.

On the left side of the Row-Level Security page, you can see a list of all roles in the dataset. The numbers in brackets show how many members each role has. On the right, you can view, add, and remove members for a selected role.

To add a member to a role, first select a role on the left, and then enter email addresses or security groups in the People or groups who belong to this role field. After you enter new members, select Add > Save. The changes will be applied immediately.

To remove a member from a role, select the cross next to the member and then select Save.

When you use row-level security in Power BI, you can use an email address for each user. Although this solution works, it can be hard to maintain. For example, consider that you have several datasets that use RLS based on the same rules and it’s viewed mostly by the same users. If a new user joins your company and you need to give them access to those datasets, you will have to update the row-level security settings for each dataset.

In cases like this, you can assign security groups as members of row-level security roles. When a new user joins the company, you will have to add them to the security group only once. The same principles apply to sharing content in Power BI, which we cover later in this chapter.

Need More Review? Creating Security Groups

Instructions on how to create security groups are outside the scope of this book. For more details, see “Create a group in the Microsoft 365 admin center” at https://docs.microsoft.com/en-us/microsoft-365/admin/create-groups/create-groups.

Plan a Windows 10 deployment – Deploy and upgrade operating systems

Skill 1.1: Plan a Windows 10 deployment

Windows 10 offers organizations new and exciting methods for deploying the operating system to users. However, traditional on-premises image creation-based deployment methods continue to be supported and are widely used. You can expect that the adoption of the new dynamic deployment methods will gain traction in the modern workplace and will be featured in the MD-101 exam. You must understand when these methods should be implemented over more traditional methods.

This skill covers how to:

Assess infrastructure readiness

Embarking on any new project should be carefully planned so that the delivery can be given every chance of success. This is especially applicable when deploying Windows 10 within an enterprise environment.

There are several tools and services available to help you evaluate, learn, and implement Windows 10. By following best practices and avoiding making deployment mistakes, you can ensure that your users are productive and that the project is delivered on schedule.

Windows 10 is released using a continuous delivery model known as Windows as a Service, with a new version of Windows 10 available every six months. Therefore, the skills you learn in deploying Windows 10 to your users will be reused again, and often.

It is recommended that you choose a group of users and deploy Windows 10 into focused pilot projects. This enables you to test each version of Windows 10 within your organization before rolling out the operating system to larger cohorts of users.

Plan pilot deployments

Each organization is different, and therefore, you must determine which deployment method (or methods) you will use. For example, you may choose to deploy new devices to your remote salesforce using Windows Autopilot and perform an in-place upgrade of your head office computers using the in-place upgrade method, perhaps.

To make effective decisions relating to the deployment method, you should perform testing in a non-production environment, and if you are successful, you should proceed to roll out Windows 10 to a small group of users.

By breaking down your Windows 10 deployment project into multiple stages, you can identify any possible issues and determine solutions where available. This will involve documenting and obtaining feedback from stakeholders at each stage. The first stage of deploying the operating system will be with a pilot deployment.

As part of the pilot, it’s important to determine the following:

  • Production hardware, including PCs, laptops, and tablets, meets the minimum hardware requirements for Windows 10.
  • Peripherals, such as printers, scanners, projectors, and other devices, are compatible with Windows 10.
  • All required device drivers are available.
  • All apps required following the deployment will work on Windows 10.
  • Any existing third-party disk encryption will work with Windows 10 (alternatively replaced with BitLocker Drive Encryption).
  • Your IT support staff has the necessary skills to support Windows 10.

The pilot is essential because it can be useful to ensure compatibility with existing hardware, apps, and infrastructure, and it provides you with an insight to the gains and potential pitfalls that you are likely to encounter during the later stages of the roll-out program. By reviewing and implementing feedback gained during the pilot phase, you can seek to minimize the future impact of any problems encountered.

If you find that your existing IT support staff doesn’t have the necessary skills to support Windows 10, you may use the pilot deployment phase to identify any training needs; doing so gives you time to implement the recommendations before a larger roll-out. You should also consider your non-technical users, who may require information relating to the new operating system so that their day-to-day productivity is not affected by the adoption of the new operating system.

You can also use the pilot to help to determine user readiness for Windows 10 and to identify any training needs—for both users and IT support staff.

Identify hardware requirements for Windows 10 – Deploy and upgrade operating systems
Identify hardware requirements for Windows 10

As part of your planning considerations, you should review the system requirements for installing Windows 10. Windows 10 can run adequately on hardware of a similar specification that supports Windows 8.1. Consequently, most of the computers in use within organizations today are Windows 10–capable. However, to get the best from Windows 10, you might consider installing the operating system on the computers and devices that exceed the minimum specifications described in Table 1-1. A good working specification is an Intel i5 processor or equivalent, 8 GB of memory, and an SSD of sufficient capacity for your users’ needs.

TABLE 1-1 Minimum hardware requirements for Windows 10

ComponentRequirement
ProcessorA 1 GHz or faster processor or System on a Chip (SoC).
Memory1 GB RAM on 32-bit versions and 2 GB for 64-bit versions.
Hard disk space16 GB for 32-bit versions and 32 GB for 64-bit versions.
Graphics cardDirectX 9 or later with a Windows Display Driver Model (WDDM) 1.0 driver.
Display resolution800×600 pixels.
Internet connectionInternet connectivity is required to perform updates and to take advantage of some features.

Note Evaluate Windows 10 Enterprise

You can access a 90-day evaluation of Windows 10 Enterprise through the Microsoft Evaluation Center. The evaluation is available in the latest released version, in 64-bit and 32-bit versions, and in multiple languages. The Evaluation Center and Windows 10 Enterprise can be downloaded from https://www.microsoft.com/evalcenter/evaluate-windows-10-enterprise.

Determine hardware compatibility for Windows 10

After you’ve verified that any new or existing computers on which you intend to install Windows 10 meet the minimum hardware requirements, you must verify that the operating system also supports any existing hardware devices and peripherals.

If you are purchasing new computers preinstalled with Windows 10, take no further action. But if you’re using existing computers, or you want to attach existing hardware peripherals to your new computers, you must verify compatibility of these older computers and peripherals.

If you have only one or two computers and a few peripheral devices to check, the easiest—and probably quickest—solution is to visit the hardware vendor’s website and check for compatibility of these devices and peripherals. You can then download any required drivers for the version of Windows 10 (32-bit or 64-bit) that you may need to install.

Provisioning packagesProvisioning packages – Deploy and upgrade operating systemsProvisioning packages

Provisioning packages are created using the Windows Configuration Designer, which is included in the Windows Assessment and Deployment Kit (Windows ADK). You can also download the standalone Windows Configuration Designer app from the Microsoft Store.

Note Download Windows ADK

You can download the Windows ADK from the Microsoft website at https://docs.microsoft.com/windows-hardware/get-started/adk-install. Ensure that you download the version of the Windows ADK that matches the version of Windows 10 that you intend to deploy.

Provisioning packages use very small configuration files. These are used to modify existing Windows 10 installations and configure their runtime settings.

A provisioning package can perform a variety of functions, such as:

  • Configure the computer name and user accounts.
  • Add the computer to a domain.
  • Upgrade the Windows 10 version, such as Windows 10 Home to Windows 10 Enterprise.
  • Configure the Windows user interface.
  • Add additional files or install apps.
  • Remove installed software.
  • Configure network connectivity settings.
  • Install certificates.
  • Implement security settings.
  • Reset Windows 10.
  • Run PowerShell scripts.

To create a provisioning package, you should complete the installation process of Windows Configuration Designer using either the Windows ADK or the Microsoft Store. Once you have done so, you are ready to create and deploy your provisioning packages. Start by opening Windows Configuration Designer. On the Start page displayed in Figure 1-1, select the option that best describes the type of provisioning that you want to do. If you’re unsure, choose the Advanced Provisioning tile.

Figure 1-1 Creating a new provisioning package

Use the following procedure to create your provisioning package to deploy a universal line of business (LOB) app:

  1. Select the Advanced provisioning tile.
  2. In the New project wizard, on the Enter project details page, enter the name and a meaningful description for your provisioning package. For example, enter Deploy LOB App1 and then select Next.
  3. On the Choose which settings to view and configure page, select All Windows desktop editions and select Next.
  4. On the Import a provisioning package (optional) page, select Finish. (You can use this option to import settings from a previously configured package that mostly, but not entirely, meets your needs.)
  5. On the Available customizations page, in View, select All settings, and then expand Runtime settings, as displayed in Figure 1-2.
  6. On the Available customizations page, in the navigation pane, expand UniversalAppInstall and then select DeviceContextApp.
  7. In the details pane, in the PackageFamilyName text box, enter a name for this collection of apps. For example, enter LOB App1.
  8. Select the PackageFamilyName: LOB App1 node.
  9. In the ApplicationFile text box, select Browse, navigate to the .appx file that represents your app, and select it, as displayed in Figure 1-2.
  10. In the File menu, select Save and note the location of the saved provisioning package file.

Figure 1-2 Available customizations for your provisioning package

You have created a customization for your app, and you are now ready to deploy this customization by applying the provisioning package.

Note Deploy Powershell Scripts from Provisioning Packages

If you want to use PowerShell scripts with provisioning packages, you need to select All Windows Desktop Editions on the Choose Which Settings To View And Configure page within Advanced Provisioning. You can then add command-line files in the Runtime Settings\ProvisioningCommands\DeviceContext area of the available customizations. To view detailed information about using scripts in provisioning packages, visit this Microsoft website at https://docs.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-script-to-install-app.