New-SecOpsOverrideRule
This cmdlet is available only in Security & Compliance PowerShell. For more information, see Security & Compliance PowerShell.
Use the New-SecOpsOverrideRule cmdlet to create SecOps mailbox override rules to bypass Exchange Online Protection filtering. For more information, see Configure the delivery of third-party phishing simulations to users and unfiltered messages to SecOps mailboxes.
For information about the parameter sets in the Syntax section below, see Exchange cmdlet syntax.
Syntax
New-SecOpsOverrideRule
[-Name] <String>
-Policy <PolicyIdParameter>
[-Comment <String>]
[-Confirm]
[-SentTo <MultiValuedProperty>]
[-WhatIf]
[<CommonParameters>]
Description
You need to be assigned permissions in the Security & Compliance before you can use this cmdlet. For more information, see Permissions in the Security & Compliance.
Examples
Example 1
New-SecOpsOverrideRule -Name SecOpsOverrideRule -Policy SecOpsOverridePolicy
This example creates the SecOps mailbox override rule with the specified settings.
Parameters
-Comment
The Comment parameter specifies an optional comment. If you specify a value that contains spaces, enclose the value in quotation marks ("), for example: "This is an admin note".
Type: | String |
Position: | Named |
Default value: | None |
Required: | False |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Applies to: | Security & Compliance |
-Confirm
The Confirm switch specifies whether to show or hide the confirmation prompt. How this switch affects the cmdlet depends on if the cmdlet requires confirmation before proceeding.
- Destructive cmdlets (for example, Remove-* cmdlets) have a built-in pause that forces you to acknowledge the command before proceeding. For these cmdlets, you can skip the confirmation prompt by using this exact syntax:
-Confirm:$false
. - Most other cmdlets (for example, New-* and Set-* cmdlets) don't have a built-in pause. For these cmdlets, specifying the Confirm switch without a value introduces a pause that forces you acknowledge the command before proceeding.
Type: | SwitchParameter |
Aliases: | cf |
Position: | Named |
Default value: | None |
Required: | False |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Applies to: | Security & Compliance |
-Name
The Name parameter specifies the name for the policy. Regardless of the value you specify, the name will be SecOpsOverrideRule<GUID> where <GUID> is a unique GUID value (for example, 6fed4b63-3563-495d-a481-b24a311f8329).
Type: | String |
Position: | 0 |
Default value: | None |
Required: | True |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Applies to: | Security & Compliance |
-Policy
The Policy parameter specifies the phishing simulation override policy that's associated with the rule. You can use any value that uniquely identifies the policy. For example:
- Name
- Id
- Distinguished name (DN)
- GUID
Type: | PolicyIdParameter |
Position: | Named |
Default value: | None |
Required: | True |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Applies to: | Security & Compliance |
-SentTo
This parameter is reserved for internal Microsoft use.
Type: | MultiValuedProperty |
Position: | Named |
Default value: | None |
Required: | False |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Applies to: | Security & Compliance |
-WhatIf
The WhatIf switch doesn't work in Security & Compliance PowerShell.
Type: | SwitchParameter |
Aliases: | wi |
Position: | Named |
Default value: | None |
Required: | False |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Applies to: | Security & Compliance |
Feedback
Submit and view feedback for