Behind the scenes: access and region control in Windows Update for Business reports

[Aaron_Oneal]

Interested in using Windows Update for Business reports for richer access and region control? As we've announced on the Windows IT Pro Blog today, you now have more power and flexibility to route data and to control access to your data with Windows Update for Business reports, as well as to host it in an expanded set of regions. While you can find out how in the blog article linked below, let's get behind the scenes of the new capability:

• The architecture
• Pricing structure
• A few current limitations
• Additional information

The architecture

When you run the Ansible solution to control access and region, your automated script deploys the following resources to your tenant. This solution automatically creates the following resources.

• Azure resources:
• Azure Function triggered on an interval to perform periodic data export
• Log Analytics resources:
• Log Analytics workspace for each scope
• Azure Monitor resources:
• Data collection endpoint for ingesting data
• Data collection rule for each scoped workspace to direct data routing

You can easily manage these resources through the Azure Portal. The diagram below shows the key workflows, resources, and interactions for the Contoso/Fabrikam deployment example. If you're an Azure administrator, you may find it helpful for understanding the created resources and how data is routed throughout the solution.

The diagram of architecture of Windows Update for Business reports shows how it connects Azure resources with Log Analytics resources and Azure Monitor resources to user roles and workflows

Pricing structure

Since you'll be routing data for Azure AD device groups to different Log Analytics workspaces, let's see if anything changes in your billing based on your existing infrastructure.

Data is stored in Log Analytics workspaces with the same schema as your already existing Windows Update for Business reports workspace, and so billing remains the same—which is to say there is no data charge at the default 30-day retention period. See Log Analytics pricing tiers for more information.

The Azure Function that copies data to scoped workspaces will incur standard Azure Function compute and consumption costs, and this is dependent upon the scale of your scopes and devices. You can use the calculator to estimate costs after running a test with your lab configuration to determine how many scopes and devices are processed over what time frame.

A few limitations of the Ansible solution for access control

Since this is a preview of the Ansible solutions, you might encounter a few limitations with access control capabilities:

• All scoped workspaces in the tenant are shown in the drop-down menu. We'll be filtering that list to just those each user has access to in a future update.
• Aggregated delivery optimization status is not computed. Aggregated status is tenant-wide in the primary workspace. Therefore, scoped workspaces would need to compute the aggregate for their device set separately. The Azure Function doesn't yet perform that process.
• No support for nested Azure AD groups. Only direct group members are considered at present. Nested support could be added by modifying the Azure Function.
• The solution assumes a single subscription and target resource group. This may or may not be relevant for your tenant. Tenants that need greater control can extend the solution by modifying the Ansible project.

Additional information

Not sure how easy it is for you to implement our new access control solution? You won't need anything other than your familiar Azure Portal and general understanding of resource management and Azure security fundamentals.

Just follow these 7 easy steps to route the tenant's primary workspace into separate secured workspaces for each access control scope:

1. Define scopes.
2. Create Azure Active Directory groups.
3. Group resources and restrict tag access.
4. Download the Ansible solution.
5. Configure your deployment.
6. Deploy the Ansible solution to Azure.
7. Use the Ansible solution.

Find precise guidance and answers to your questions in Windows Update for Business reports: access and region control.

Get in on the conversation

This space is excellent for discussion with your peers and with our team members, so feel free to leave a comment below! If you have any feedback or questions regarding the Ansible solution on GitHub, please feel free to open project issues for support or reach out through our other Windows Update for Business reports support options.

[#2]

The GitHub page says that whatever account will run the Ansible playbook should be Subscription owner to be able to create all the resources. However, the target_resource_group parameter in the localhost file seems to indicate that we can have everything go in the same resource group.

To me it seems possible to have the account have just the Contributor role for that resource group in order to run the playbook successfully, since everything created by the playbook would go into that group. I assume the Subscription Owner role would definitely be needed if the playbook was also creating a new resource group instead of using an existing one.

Am I missing something? Is subscription owner a hard requirement besides for the reason I mentioned?

Thank you.

@Aaron_Oneal 

[#3]

For anyone who is curious, I tried to do this with a service principal that only has Owner rights to the resource group. This fails, because the playbook tries to register a storage provider, which requires permissions to the subscription.

Specifically, 'Microsoft.Storage/register/action' permission to the subscription is what is required.

[#4]

Resource group contributor will generally suffice if you have already created one in the subscription. But as noted, you will also need to have pre-created and registered the storage provider due to the required subscription permission.