Scenario: You need a distribution group to send a ‘specific’ reply message back to the sender, every time a sender sends to it. An Out-of-Office message will not do because it will only send a reply one time.
Note: Distribution Groups do not have this functionality, however there is a work around with using a shared mailbox.
Solution:
1. Create a Shared Mailbox that will host sending the reply messages. We will call it: ReplyMessage@steveman.com
2. Log into an Outlook client as the shared mailbox and create the following inbox rule:
“Apply this rule after the message arrives
have server reply using “blah blah blah“
3. Even though this is a Inbox Rule, set your Distribution Group so it allows sending Out-of-Office (OOF) messages which is turned off by default. This is required for return messages:
Set-DistributionGroup DL01@steveman.com -SendOofMessageToOriginatorEnabled:$true
4. Create a Transport Rule OR add that shared mailbox to your distribution list. I chose the Transport Rule because it is cleaner to the end users — they wont start asking questions about this new account. We are using the AnyOfToCCHeader to trigger the rule if it the Distribution list is sent to.
New-TransportRule -name “BCC_Reply” -AnyOfToCCHeader DL01@steveman.com -blindcopyto ReplyMessage@steveman.com
Tag: Powershell
Error: The request was aborted: Could not create SSL/TLS secure channel
Scenario: You are trying to access or download from a URL within PowerShell and you receive this error message:
The request was aborted: Could not create SSL/TLS secure Channel
Solution: Use TLS1.2 in your PowerShell to initiate the download.
#verifies that TLS1.2 is available within your PowerShell
[Enum]::GetNames([Net.SecurityProtocolType]) -contains 'Tls12'
#If True, Checks to see if TLS1.2 is in use with PS
[System.Net.ServicePointManager]::SecurityProtocol.HasFlag([Net.SecurityProtocolType]::Tls12)
#If False Run the following to enable the use of TLS1.2
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
#Check again for True
[System.Net.ServicePointManager]::SecurityProtocol.HasFlag([Net.SecurityProtocolType]::Tls12)
#Then attempt to initate the install
iex (New-Object Net.WebClient).DownloadString("https://gist.github.com/darkoperator/6152630/raw/c67de4f7cd780ba367cccbc2593f38d18ce6df89/instposhsshdev")Error: Remove-ADUser : The directory service can perform the requested operation only on a leaf object.
Scenario: When cleaning up Active Directory accounts, you receive the following error:
Remove-ADUser : The directory service can perform the requested operation only on a leaf object.
Solution: Our issue is caused by mobile devices being attached within these user accounts. Instead for using the Remove-ADUser commandlet, use the Remove-ADObject with a -recursive commandlet to get ad objects, such as mobile devices, that are attached.
Remove-ADObject “CN=buhbye,OU=Disabled,DC=domain,DC=com” -confirm:$false -recursive
New-ApplicationAccessPolicy
Scenario: A registered App within Azure was created that has various ‘Application’ Exchange Permissions granted to it. You want to apply a scope to that registered app so the app only has permissions to specific mailbox, and not every mailbox by default
Scriptlet: Use the New-ApplicationAccessPolicy to Restrict Access
New-ApplicationAccessPolicy -AccessRight RestrictAccess -AppId “<client app id>” -PolicyScopeGroupId grp-app_Mbx_access -Description “Restrict this app to members of security group grp-app_MBX_access.”
SMTP Error: ‘550 5.7.54 SMTP; Unable to relay recipient in non-accepted domain’ ·
Scenario: After standing up a new Exchange On-Premises Server, users are receiving the bounce back message with wording similar to the following:
For Email Admins: The message couldn’t be sent because it’s an attempt to relay a message to a recipient in a non-accepted domain (open relay) which isn’t allowed.
-or-
‘550 5.7.54 SMTP; Unable to relay recipient in non-accepted domain’
Solution: Make sure the Default Frontend Receive Connector is set to accept AnonymousUsers when connecting AND the ADPermission for AnonymousLogon is applied to the Receive Connector on the new server:
Set-ReceiveConnector “ExSrv1\Default Frontend ExSrv1” -PermissionGroups AnonymousUsers
Get-ReceiveConnector “ExSrv1\Default Frontend ExSrv1” | Add-ADPermission -User ‘NT Authority\Anonymous Logon’ -ExtendedRights MS-Exch-SMTP-Accept-Any-Recipient
Ex-Shell 