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