We are excited to announce that the automated end-user feedback response feature is now GA! The user submission automatic feedback response capability in Microsoft Defender for Office 365 enables organizations to automatically respond to end user submissions of phish based on the verdict from the automated investigation. 

This feature saves SecOps time by converting the process of sending manual responses back to end users on reported messages to be automated. This layers additional value to the automated investigation and response (AIR) feature for SecOps teams and also helps encourage end users to contribute to the security posture of the organization by providing acknowledgment and feedback on those user reports of phish automatically. 

Configuration 

The ability to automatically respond to end user submissions of phish is configurable and can be turned on from the user reported settings page (Settings > Email & collaboration > User reported settings) and configured to send based on the AIR verdict. 

User submission automatic feedback response configuration found in settings > email & collaboration > user reported settings > automatically email users the results of the investigation: 

Phishing or Malware: Selecting this box indicates that the organization would like end users to receive an automatic response email on email submissions of phish when the associated user submission investigation identifies a threat of normal phish, high confidence phish or malware. 

Spam: Selecting this box indicates that the organization would like end users to receive an automatic response email on email submissions of phish when the associated user submission investigation shows the threat of spam. 

No threats found: Selecting this box indicates that the organization would like end users to receive an automatic response email on email submissions of phish when the associated user submission investigation finds no threats. 

Response Timing 

The automated end user feedback response is sent at the conclusion of the investigation when the investigation hits a final status. This means investigations in pending approval status must be approved before the response will be sent. 

Email Template 

The email that is sent to the end users utilizes the same email template as the organization’s Mark & Notify email template and allows the customization of the email body for the respective threats of Phishing, Junk and No threats found (corresponding to the Phishing or Malware, Spam, and No threats found settings above respectively). Learn more about Mark & Notify on this page: Admin review for reported messages – Office 365 | Microsoft Learn. 

User submission automatic feedback response configuration of email message using customize admin review email notification: 

Function 

Once enabled, Microsoft Defender for Office 365 will automatically respond to end user submissions based on the investigation verdict and the configured settings. For example, if an organization has enabled the user feedback response for emails with no threats found, if a user reported a message as phish it would trigger automated investigation and response (AIR) and begin an investigation on the user reported message. If that investigation concludes with no threats found and the organization had enabled the automatic feedback response for no threats found, then the end user who submitted the message would receive an email stating there were no threats found on the submitted message. The message would resemble the below, but the body of the message and footers would contain what the organization has put in for admin review for reported messages for the no threats found option. 

Sample user submission automatic feedback response for no threats found: 

If an organization has enabled the user feedback response for emails with Phishing or Malware, if a user reported a message as phish it would begin an investigation on the user reported message. If that investigation discovers high confidence phish or malware the investigation would be looking for these to be remediated either with the approval of recommend actions, shown as pending actions in the investigation, incident and action center, or remediation through other means such as explorer. Once the high confidence phish or malware threats found in the investigation have been remediated, the investigation would close as “Remediated” or “Partially Remediated” at which point the user submission feedback email would automatically be sent to the user who reported the message. If only a threat of normal phish was identified for a message, the investigation would not produce pending actions however the end user would still receive a response indicating the message was phish. The message would resemble the below, but the body of the message and footers would contain what the organization has put in for admin review for reported messages for the phishing option. 

Sample user submission automatic feedback response for high confidence phish or malware: 

Note: The response is not sent to end users until any discovered high confidence phish or malware threats are remediated, meaning responses will not be sent when the investigation is pending action. The investigation must reach “Remediated” or “Partially Remediated” status in order for the response to be triggered. 

Display 

When users receive an automatic feedback response, this will be reflected in the submission queue as “Marked as” similar to other submissions that may have manually received a response. 

User submission automatic feedback response reflected on submissions queue marked as: 

Learn More 

To learn more about the automated end user feedback response feature visit Automatic user notifications for user reported phishing results in AIR – Microsoft Defender for Office 365 | Microsoft Learn. 

To learn more about submissions and investigations in MDO please visit the following pages: 

Automated investigation and response in Microsoft Defender for Office 365 – Office 365 | Microsoft Learn 
View the results of an automated investigation in Microsoft 365 – Office 365 | Microsoft Learn 
Admin review for reported messages – Office 365 | Microsoft Learn 
How automated investigation and response works in Microsoft Defender for Office 365 – Office 365 | Microsoft Learn 

​Microsoft Tech Community – Latest Blogs –Read More 

I have been asked to create a Word template that is to be used to imprint addresses on envelopes.

I am using Power Automate to collect the data from Excel, insert the data into the Word template mail merge labels, and merge the multiple pages into a single word document.

The template fields currently look as below. 

I am trying to figure out if the Labels can be rotated in the template so that they print out as such -.

​I have been asked to create a Word template that is to be used to imprint addresses on envelopes.I am using Power Automate to collect the data from Excel, insert the data into the Word template mail merge labels, and merge the multiple pages into a single word document.The template fields currently look as below. I am trying to figure out if the Labels can be rotated in the template so that they print out as such -.   Read More

​

TL; DR– Deployment Stacks is a new resource type for managing a collection of Azure resources as a single unit for faster update and delete (cleanup), while also preventing unwanted changes to those resources. Now Generally Available!

The Problem: managing the lifecycle (creates, updates, deletes) of resources across multiple Azure scopes (Resource Group, Management Groups, Subscription) is both complex and time consuming. On top of that, ensuring resources have the proper guard rails in place adds more complexity to the deployment and management of those resources.

First let’s review common scenarios of where this added complexity is seen today:

Cleanup: resources with the same lifecycle are often created across multiple scopes. If you ever need to delete these resources, it requires manually navigating to each scope to clean them up (e.g. deleting test Storage accounts and VMs across numerous resource groups).
Unwanted (Accidental) changes: many developers require contributor and owner rights to certain scopes to work on their projects. Sometimes accidental changes can be done to resources (e.g. deleting resources, changing to a more premium SKU) using other clients (e.g. a user updating a “bicep-managed” or “ARM-Template” resource directly with the portal). This makes reconciling difficult when you need to redeploy that bicep file or ARM Template.

Why Deployment Stacks?

Deployment Stacks will enable users to deploy a collection of resources across scopes as a single atomic unit (Bicep or ARM Template). The deployment stack protects its managed resources against unwanted changes. 

The Solution: 1st Party resource enabling 1-to-many CRUD operations and resource change prevention. 

Cleanup: easily delete or update resources across scopes with a single update to the deployment stack resource as a 1-to-many operation. You can also delete the entire stack to clean up the entire set of managed resources in one atomic action.
Unwanted (Accidental) changes: block changes to managed resources with the deny settings capability of a deployment stack.

The Deployment Stack Resource – Key Concepts

 A deployment stack is a method of deploy an ARM Template or Bicep file which tracks the resources deployed in a “managedResources” list. Beyond the capabilities of conventional ARM Template or Bicep deployments, there are two main capabilities that deployment stacks bring to Azure:

“ActionOnUnamange”: With this setting a deployment stack resource knows what action to take when a managed resource becomes unmanaged (removed from the ARM/Bicep template). A “managedResources” can be either deleted or detached. One can trigger the “actionOnUnmanage” behavior directly on all “managedResources” by deleting the deployment stack along with the desired setting or indirectly by removing resources from the template passed into the next deployment stack update along with the desired setting. 

“DeleteResources”: this setting will delete resources that become unmanaged. Resource Groups and Management Groups will be detached.
“DeleteAll”: this setting will delete resources, resource groups, AND management groups that become unmanaged.
“DetachAll”: this setting will detach resources. In other words, the resources are removed from the deployment stack, and will continue to exist in Azure.

“DenySettingsMode”: this setting enables a denyAssignment that prevents any changes to “managedResources”, attempted from outside of the deployment stack.

“DenyDelete”: this setting will enable a denyAssignment that will block all attempted deletes to “managedResources”
“DenyWriteAndDelete”: this setting will enable a denyAssignment that will block all attempted writes and deletes to “managedResources”.
“None”: this setting disables the denyAssignment.

The Deployment Stack Resource – Create and Update

A deployment stack can be created at different scopes, such as, Resource Group, Subscription, and Management Group scope. To create a deployment stack, we need the following information:

A main template, main.bicep or azuredeploy.json, that defines the “managedResources” to be created by the deployment stack. Think of which resources that share the same lifecycle can be defined into a deployment stack (e.g. networking resources, DevTest environments, Applications). For example, here is “mainAppInfra.bicep”:
targetScope = ‘subscription’

param resourceGroupName1 string = ‘testapp-storage’
param resourceGroupName2 string = ‘testapp-network’
param resourceGroupLocation string = deployment().location

//Create Resource Groups
resource testrg1 ‘Microsoft.Resources/resourceGroups@2021-01-01’ = {
name: resourceGroupName1
location: resourceGroupLocation
}

resource testrg2 ‘Microsoft.Resources/resourceGroups@2021-01-01’ = {
name: resourceGroupName2
location: resourceGroupLocation
}

//Create Storage Accounts
module firstStorage ‘multistorage.bicep’ = if (resourceGroupName1 == ‘testapp-storage’) {
name: uniqueString(resourceGroupName1)
scope: testrg1
params: {
location: resourceGroupLocation
}
}

//Create Virtual Networks
module firstVnet ‘multinetwork.bicep’ = if (resourceGroupName2 == ‘testapp-network’) {
name: uniqueString(resourceGroupName2)
scope: testrg2
params: {
location: resourceGroupLocation
}
}​

This file deploys storage account and virtual network to different resource groups.

Choose “ActionOnUnmanage” setting of “DeleteResources”, “DeleteAll” or “DetachAll”.
Choose “DenySettingsMode” setting of “DenyDelete”, “DenyWriteAndDelete” or “None”. 
Choose the scope of the deployment stack and target scope of its deployment.

To help us start visualizing this, let’s look at what an Azure CLI command to create deployment stack at subscription scope looks like:

az stack sub create –name “DevTestEnvStack” –template-file “mainAppInfra.bicep” –location “westus2” –action-on-unmanage “deleteResources” –deny-settings-mode “denyDelete”

Here is the response from that command (some stack properties removed for simplicity of example):

{
“actionOnUnmanage”: {
“managementGroups”: “detach”,
“resourceGroups”: “detach”,
“resources”: “delete”
},
“deletedResources”: [],
“denySettings”: {
“applyToChildScopes”: false,
“excludedActions”: [],
“excludedPrincipals”: null,
“mode”: “denyDelete”
},
“deploymentId”: “/subscriptions/***/providers/Microsoft.Resources/deployments/DevTestEnvStack-24052002bd5h1”,
“detachedResources”: [],
“failedResources”: [],
“id”: “/subscriptions/***/providers/Microsoft.Resources/deploymentStacks/DevTestEnvStack”,
“location”: “westus2”,
“name”: “DevTestEnvStack”,
“provisioningState”: “succeeded”,
“resources”: [
{
“denyStatus”: “denyDelete”,
“id”: “/subscriptions/***/resourceGroups/testapp-network”,
“status”: “managed”
},
{
“denyStatus”: “denyDelete”,
“id”: “/subscriptions/***/resourceGroups/testapp-network/providers/Microsoft.Network/virtualNetworks/testnetbjildrqs4q6ve”,
“resourceGroup”: “testapp-network”,
“status”: “managed”
},
{
“denyStatus”: “denyDelete”,
“id”: “/subscriptions/***/resourceGroups/testapp-storage”,
“status”: “managed”
},
{
“denyStatus”: “denyDelete”,
“id”: “/subscriptions/***/resourceGroups/testapp-storage/providers/Microsoft.Storage/storageAccounts/teststore1ic7t5vnieyika”,
“resourceGroup”: “testapp-storage”,
“status”: “managed”
},
{
“denyStatus”: “denyDelete”,
“id”: “/subscriptions/***/resourceGroups/testapp-storage/providers/Microsoft.Storage/storageAccounts/teststore2ic7t5vnieyika”,
“resourceGroup”: “testapp-storage”,
“status”: “managed”
}
],
“type”: “Microsoft.Resources/deploymentStacks”
}

In this example, a deployment stack named “DevTestEnvStack” was created, and the resulting output of the command shows the details about the deployment stack resource and its managed resources. Note the “status” of each resource as “managed”. To refer back to those details, you can use the show command in CLI:

az sub stack show –name “DevTestEnvStack”

The result will contain all information on the specified deployment stacks object, such as, resource ID of the deployment stack, array of managed resources, deny setting configurations, and actionOnUnmanage settings. Let’s take a look at “actionOnUnmanage” in particular:

“actionOnUnmanage”: {
“managementGroups”: “detach”,
“resourceGroups”: “detach”,
“resources”: “delete”
}

Given the current configuration, if we were to remove a resource from the mainAppInfra.bicep template, that resource will be deleted by the Deployment Stack. In our example, let’s remove the virtual network resource from our template:

targetScope = ‘subscription’

param resourceGroupName1 string = ‘testapp-storage’
param resourceGroupName2 string = ‘testapp-network’
param resourceGroupLocation string = deployment().location

//Create Resource Groups
resource testrg1 ‘Microsoft.Resources/resourceGroups@2021-01-01’ = {
name: resourceGroupName1
location: resourceGroupLocation
}

resource testrg2 ‘Microsoft.Resources/resourceGroups@2021-01-01’ = {
name: resourceGroupName2
location: resourceGroupLocation
}

//Create Storage Accounts
module firstStorage ‘multistorage.bicep’ = if (resourceGroupName1 == ‘testapp-storage’) {
name: uniqueString(resourceGroupName1)
scope: testrg1
params: {
location: resourceGroupLocation
}
}

Now let’s we redeploy the deployment stack with the same command:

az stack sub create –name “DevTestEnvStack” –template-file “mainAppInfra.bicep” –location “westus2” –action-on-unmanage “deleteResources” –deny-settings-mode “denyDelete”

Here is the response from that command (some stack properties removed for simplicity of example):

{
“actionOnUnmanage”: {
“managementGroups”: “detach”,
“resourceGroups”: “detach”,
“resources”: “delete”
},
“deletedResources”: [
{
“id”: “/subscriptions/***/resourceGroups/testapp-network/providers/Microsoft.Network/virtualNetworks/testnet1bjildrqs4q6ve”,
“resourceGroup”: “testapp-network”
},
{
“id”: “/subscriptions/***/resourceGroups/testapp-network/providers/Microsoft.Network/virtualNetworks/testnet2bjildrqs4q6ve”,
“resourceGroup”: “testapp-network”
}
],
“denySettings”: {
“applyToChildScopes”: false,
“excludedActions”: [],
“excludedPrincipals”: null,
“mode”: “denyDelete”
},
“deploymentId”: “/subscriptions/***/providers/Microsoft.Resources/deployments/DevTestEnvStack-24052317bd010”,
“deploymentScope”: null,
“description”: null,
“detachedResources”: [],
“failedResources”: [],
“id”: “/subscriptions/***/providers/Microsoft.Resources/deploymentStacks/DevTestEnvStack”,
“location”: “westus2”,
“name”: “DevTestEnvStack”,
“provisioningState”: “succeeded”,
“resources”: [
{
“denyStatus”: “denyDelete”,
“id”: “/subscriptions/***/resourceGroups/testapp-network”,
“status”: “managed”
},
{
“denyStatus”: “denyDelete”,
“id”: “/subscriptions/***/resourceGroups/testapp-storage”,
“status”: “managed”
},
{
“denyStatus”: “denyDelete”,
“id”: “/subscriptions/***/resourceGroups/testapp-storage/providers/Microsoft.Storage/storageAccounts/teststore1ic7t5vnieyika”,
“resourceGroup”: “testapp-storage”,
“status”: “managed”
},
{
“denyStatus”: “denyDelete”,
“id”: “/subscriptions/***/resourceGroups/testapp-storage/providers/Microsoft.Storage/storageAccounts/teststore2ic7t5vnieyika”,
“resourceGroup”: “testapp-storage”,
“status”: “managed”
}
],
“type”: “Microsoft.Resources/deploymentStacks”
}

Note that the virtual network resource is no longer “managed” and can now be seen in the “deletedResources” array property of the deployment stack response. This shows how deployment stacks can be used to easily delete resources by removing them from the template with the appropriate “–actionOnUnmanage” behavior defined.

You can also view the Deployment Stack and its contents in portal by navigating to the specified scope (Subscription for this example) > settings > deployment stacks. 

Select the deployment stack “DevTestEnvStack” to view:

Beyond deciding on the behavior for “actionOnUnmanage” it is also important to define what deny settings mode should the deployment stack use. This enables guard-rails to help protect your “managedResources” against unwanted changes. In our initial example, we specified DenyDelete for our deny settings mode. Behind the scenes, our deployment stack resource created a deny assignment for each of its managedResources. This means that other users (not our deployment stack) can make updates/writes to the provisions test storage accounts, but can’t delete them, even if they have owner access to that resource and scope.

In some cases, you might need some flexibility or stop gap measure for the deny settings mode. For example, you may want to exclude a particular admin user from the deny assignment, such that they can go and delete the resource manually (outside of the context of a deployment stack), or maybe you want to exclude specific actions for all users (e.g. Still allow all users to perform Writes and Deletes to storage accounts and virtual network resource types). This can be done with the following exclusion parameters for deny settings:

“DenySettingsExcludedPrincipals”: this setting will exclude the list of AAD Principal IDs from the denyAssignment.
“DenySettingsExcludedActions”: this setting will exclude the list of RBAC Actions from the denyAssignment.

In our example, if we were to decide to exclude a specific user ID and also exclude the ability to delete storage accounts from the deployment stack’s deny settings, the command will now look like this:

az stack sub create –name “DevTestEnvStack” –location “westus2” –template-file “mainAppInfra.bicep” –actionOnUnmanage “DeleteAll” –deny-settings-mode “DenyDelete” –deny-settings-excluded-principals “12304812408-2148124081” –deny-settings-excluded-actions “Microsoft.Storage/storageAccounts/delete”

These exclusion flags give you the flexibility to enable access to “managedResources” for specific users or specific actions, while keeping all other “managedResources” secured with deny settings. For more information on deployment stacks, please visit our docs and our GitHub.  

Deployment Stacks Docs Reference:

Quickstart: Create and deploy a deployment stack with Bicep (Preview) – Azure Resource Manager | Microsoft Learn
How-To: Create & deploy deployment stacks in Bicep – Azure Resource Manager | Microsoft Learn
Tutorial: Use deployment stack with Bicep – Azure Resource Manager | Microsoft Learn
GitHub: Azure/deployment-stacks: Contains preview Deployment Stacks CLI scripts and releases (github.com)
CLI Reference
PowerShell Reference

​Microsoft Tech Community – Latest Blogs –Read More