-->

Sunday, June 23, 2019

Exchange Inbox Rule To Move Email To Folder Sent To Alias

Here's a scenario I've seen quite often:

You have a Shared Mailbox called Human Resources (hr@exchangeitup.com), and you've added an alias of training@exchangeitup.com.

One of the user's with Full Access to the HR Mailbox, wants to create an inbox rule that will move messages sent to the training address to a Training folder - but this won't work.


When messages are sent to an alias, Exchange Directory Services will "translate" the alias as the primary email address; Training = Human Resources, and you can see it action by typing the address in the "To" field in Outlook and watch it change to the primary name. Therefore, inbox rules won't work for sorting/moving those emails to the alias.

In order to get around that behavior, we'll need to create a Mail Contact and a Transport Rule:

1. Remove the alias from the Shared Mailbox by running the following cmdlet in the Exchange Management Shell (EMS):

Set-Mailbox "Human Resources" -EmailAddresses @{remove="training@exchangeitup.com"}

Give it a few for Exchange/AD to update.

2. Create a Mail Contact for "Training" by running the following cmdlet:

New-MailContact -Name "Training" -ExternalEmailAddress training@exchangeitup.com -OrganizationalUnit “Contacts” 

**Note** This is re-using the secondary email address taken away from shared mailbox in step 1. Change the Name, External Email Address, OU match your environment.

3. Create a Transport Rule to redirect all messages sent to the Training Contact over to the HR Shared Mailbox:

 In the Exchange Admin Center (EAC), navigate to mail flow > rules.

Create a new Rule with the following settings:

Name: Training Forward

*Apply this rule if...
The recipient is..."Training"

*Do the following...
Redirect the message to..."Human Resources"


Or  you can use the EMS to run the cmdlet:

New-TransportRule, parameters -SentTo ("Training") -RedirectMessageTo ("Human Resources") -Name "Training Forward" -StopRuleProcessing "False" -Mode "Enforce" -Comments "" -RuleErrorAction "Ignore" -SenderAddressLocation "Header"

4. Create an inbox rule for the HR Shared Mailbox to move emails sent to the Training Contact to another folder in the Shared Mailbox:

In OWA, click your person icon in the upper-right corner, then select Open Another Mailbox.

Search for and open the Shared Mailbox (Human Resources in this example).

Then click the Settings Gear in the upper-right and go to Options > Inbox and sweep rules > create a rule using the following settings

It was sent to..."Training"
Do all of the following:
Move the message to folder..."Training Folder"


Now test it out! Send a message to training@exchangeitup.com and verify that the message was moved directly to the Training Folder.

Saturday, May 25, 2019

Exchange Forced TLS With SpamTitan

The growing trend nowadays, especially when sending messages to banks, is to use Forced TLS (also called Mandatory TLS). On top of TLS, most banks are now also requiring that the sending host use a public certificate to verify "you are who you say you are" - this is generally done with SPF records, but security requirements are getting more stringent.

If you're sending directly from Exchange and not using a spam filter (which probably isn't very common these days) you would just set up a Partner Send Connector and be done - except for assigning a cert to the connector, which is pretty tricky.
Since most organizations do use some sort of outgoing appliance (like SpamTitan), this post will walk you through setting up Forced TLS from Exchange on out through that gateway.

In my environment, we receive messages through a SpamTitan filter (which is awesome), but we send out through a Totemo encryption gateway...ever heard of it? Didn't think so. My short review on that product: It's garbage.
I was forced by company higher-ups to use it, going against my recommendations because it's not good practice to send and receive through different hosts/IPs - Totemo doesn't receive mail and it doesn't work very well...it runs on Java, which should tell you all you need to know. But it uses the "encrypt" button in Outlook to make users feel better, which adds complexity and results in help tickets...daily.
So, I decided to use the SpamTitan for outgoing TLS connections and it works perfectly!

Exchange Send Connector

We'll need to create a special Send Connector on Exchange to use the SpamTitan as a Smart Host.

**Note** Even if you're already using something like SpamTitan as your smart host on your current Send Connectors, I find it cleaner to create a dedicated connector for TLS - this way you can manage the domains requiring TLS without affecting your regular mailflow.

In the EAC (Exchange Admin Center) navigate to Mail Flow > Send Connectors. Click the "+" to create a new one:

New Send Connector
 
Give the Send Connector a name like "Google - TLS" and choose "Custom":

Custom Send Conenctor

**Note** We don't need a partner connector in this case, because mail will flow through our smart host not directly to our recipients.

Choose "Route mail through smart hosts", click the "+" and add your SpamTitan public IP address. Then click Next:

Send Connector Smart Host

There will be no authentication, so leave "None" selected and click Next:

Send Connector No Auth

In the Address space, click the "+" and enter the domains that you will sending over TLS to. If you want to include subdomains (which you always should), put an asterisk in front of the domain name. For instance to send to all of google/gmail, you'll enter *.google.com. Click Next when you've entered the domains:

Send Connector Address Space

In the Source server, click the "+" and choose your Edge Server(s) if you have them, otherwise choose your internet-facing Mailbox Server(s) and click Finish:

Send Connector Source Server

Your Send Connector is now created. Double-click it and change logging to "Verbose" and click Save. This will allow us to diagnose any issues later on by checking protocol logs, should TLS not work correctly:

Send Connector Logging

SpamTitan SSL Settings

On the SpamTitan WebUI, we need generate a CSR (Certificate Signing Request) so we can assign a public cert to send and receive with.

On your SpamTitan appliance, navigate to Settings > SSL. In the "Generate CSR" section, fill out the company info according to values below:

Common Name: The FQDN of your SpamTitan host
Organization: Your company name
OU: Optional
City/State/Country: The city, state and country your company is based in.

Then, hit "Run" under the "Generate Certificate Signing Request (CSR)" section.
 
 
SpamTitan CSR

Once the cert request is generated, copy the entire code block including "BEGIN CERTIFICATE REQUEST--- to ---END CERTIFICATE REQUEST---" and give that to whoever requests your certs from a Public CA.

When you get your cert generated and sent back to you in .pem format, import it into the SpamTitan under the "Import Certificates" section.

Under "Import Certificate from PEM" click "Choose File". Select your cert.pem file, and click "Import":

SpamTitan Cert import

You can view your imported cert under "Installed Signed Certificates" by clicking the magnifying glass icon:

SpamTitan Cert Properties

You'll then be presented with the cert details to make sure it's correct:

SpamTitan Cert

SpamTitan TLS Settings

Now that we have the cert in place and SSL enabled, we need to enable and configure TLS on the SpamTitan.

Navigate to Settings > TLS and click "Enable" for TLS. Select your new public cert, and enable logging:

SpamTitan TLS

**Note** This will also enable TLS for receiving and assign that cert for outside senders who need to verify your mail system (some banks require certs on both sending and receiving ends).

Next, navigate to System Setup > Mail Relay > Outbound.


Under "Trusted Networks" we'll add our Exchange external IP address(es). In my case it's my Edge server, but this could also be your internet-facing Mailbox Server(s):

SpamTitan Trusted Network

Under "TLS Encryption" we'll enable TLS, and in the drop-down choose "Use TLS for specified domains and Opportunistic TLS for all other connections". We do this because we don't want to force TLS on hosts that don't support it, which will drop connections:

SpamTitan TLS Encryption

Next, we'll add our recipient domains (these will match the domains we added in our Exchange Send Connector) with the following settings:

Domain: the top-level domain name
Include sub-domains: Yes
Policy: Mandatory TLS Encryption (aka Forced)
Allowed SSL/TLS Protocols: TLSv1/TLSv1.2 (these are most commonly supported)
Comment: Optional

SpamTitan TLS Domain

The domain will now be listed:

SpamTitan TLS Domain Listed
Under "Send Client Certificate" choose "enable" and verify that your public cert is selected and click "Save":

SpamTitan TLS Cert

Now, send a message to your gmail address (if you have one) or send a message to your external domain contact and verify that TLS was enforced by checking the receiving email header. You'll see the TLS version used to send the message:

TLS Verification

All done! Now you'll be sending secure messages!

Saturday, May 11, 2019

Exchange Transport Rule Block Attachments While Allowing Specific Ones

In my Exchange environment we have an invoicing mailbox that auto-forwards to an external document processing email address. This mailbox can only accept PDF or TIFF attachments, since that's what the doc processing service will accept. So, I needed a way to only allow those two attachment types, while blocking all others.

Articles on the Web are spotty on how to accomplish this...most are all or nothing. MS TechNet has an article on blocking all attachments, but we need to allow the ones mentioned above to come through. In this post, I'll expand on that.

We'll be using the EAC (Exchange Admin Center) to create our Transport Rule (aka Mail Flow Rules) since it's a little bit easier to see all of our options.

In the EAC, navigate to Mail Flow > Rules.
Click the "+" and select "Create a new rule...":

EAC Create New Rule

In the rule creator, give it a name.

Under "*Apply this rule if..." select "the recipient is..." and then search for and select your recipient(s).

Click the "more options" link and then click "add condition".

Drop-down to "any attachment" then mouse over to "is greater than or equal to..."

Input "1" in the field - for 1KB.

**Note** The EAC will only accept 1KB as the lowest value, which will block all attachments in my experience. If you need to go lower, like 0KB, you'll need to use the Shell to set it later.

Under "*Do the following..." drop-down to "Reject the message with the explanation..." and enter your outgoing bounce reason. In my case I specify that only PDF and TIFF are allowed.

Under "Except if..." drop-down to "Any attachment's file extension matches..." and enter "tiff" and "pdf".

**Note** Don't enter a dot in front of the file extensions, as it will throw an error; only enter the extension name.

Set your priority and leave "enforced" selected.

Click "Save"

The results should look like so:

EAC Attachment Rule Settings

Basically, what we did is block all attachments, but since we set an exception, we allowed those two specific ones through.
This might seem counterintuitive at first, but think if you did it the other way around and had to manually block every file type...that would take forever!

**Note** In the above example I set the rule for one mailbox, but if you need to allow only these certain attachments to all mailboxes, under "Apply this rule if..." you would choose "the recipient is... located inside the organization". You can also set it to "a member of this group" if you have groups set up for different settings.

Now, test your rule by sending a blocked attachment like a JPEG, to the mailbox and then send an allowed attachment like a PDF.

The blocked attachment should generate a 5.7.1 reply like so:

Delivery has failed to these recipients or groups:

invoices@exchangeitup.com (invoices@exchangeitup.com)

This message was rejected because only PDF or TIFF attachment types are allowed.


Your message wasn't delivered because the email admin for the organization 'exchangeitup.com' created an email rule restriction. Please contact the email admin for that organization and ask them to remove or update the rule restriction.
For more information about this error, see DSN code 5.7.1 in Exchange Online - Office 365.


As you can see, the sender will get the 571 bounce, and it includes my custom outgoing message under the recipient email address: "This message was rejected because only PDF or TIFF attachment types are allowed."

Happy attachment blocking!

Saturday, May 4, 2019

Outlook Teams Add-in Overrides Skype Meeting Add-In

My company uses Teams for meetings internally, but many of our clients use SFB on-premises, so we need to be able to schedule meetings in both modalities depending on the attendees.

The problem is: once Teams is installed, the Teams Outlook add-in takes precedence over the SFB add-in - the SFB add-in actually gets disabled.

If you enable the add-in from within Outlook > Options > Add-ins > COM Add-ins, it will revert back to "unloaded" when you next log on...maybe this Microsoft's way of forcing everyone to Teams, I dunno, but they need to fix it!

Here's what I'm talking about: in Outlook, only the Teams add-in will be shown when setting a new meeting: 

Outlook Teams Only


To fix this, you need to hack the registry to force Outlook to show both Teams and SFB.

To manually set it, navigate to:

HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\UCAddin.LyncAddin.1

The LoadBehavior key will most likely be set to "0" which is Off.

LyncAddin LoadBehavior Off
 

We need to set the LoadBehavior key value to "3" which is Load At Start:

LyncAddin LoadBehavior On
 
If you don't have the key present (sometimes it won't be there), or don't want the hassle of setting it, you can grab the reg file from my Google Drive. Installing this will create the key if it's missing, or set it to "Load At Start" if it's in there already.
 
You can also use PowerShell to set the key, by running the following cmdlet in an Elevated PS session:
 
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Office\Outlook\Addins\UCAddin.LyncAddin.1" -Name loadbehavior -Value 3
 
There's no need to restart the machine with either the reg change or the Shell method, the changes will automatically take effect.
 
Now, when creating a new meeting, both add-ins will be shown:
 
Outlook SFB And Teams

You can push out the reg file in a GPO if you have a lot of machines that are affected - in my case it was only a few of us.

Saturday, March 23, 2019

Office 365 Create Remote PowerShell Shortcut

In a previous post, I showed how to create a Remote PowerShell shortcut for Exchange on-premises, to save you from having to type in the remote session every time you connect.

Since I've been doing more work in O365, I decided to do the same for that; especially because Office 365 has many more connections you have to run, such as Exchange, Skype For Business/Teams, Azure AD, and Security Center.

This PS shortcut will install and import those sessions and get you signed in all in one shot.

First, set your PowerShell execution policy - I use Unrestricted but you can use RemoteSigned:

Open PowerShell as admin, and run:

Set-ExecutionPolicy Unrestricted

Next, enable PS remoting by running:

Enable-PSRemoting

Then, install the required modules:

For MSOL, run:

Install-Module MSOnline

**Note** We're using MSOL because it's more comprehensive than AzureAD

**Note** Running the above cmdlet should install the latest version straight from the PowerShell gallery. If it doesn't, browse here and grab it:

https://www.powershellgallery.com/packages/MSOnline/1.1.183.17


Next, download the Skype for Business Online Connector module from here:

https://www.microsoft.com/en-us/download/details.aspx?id=39366

**Note** As of this writing, the SFB Online Connector will manage Teams as well.

Next, copy the following block and paste it into Notepad:

$credential = Get-Credential
$exchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri
https://outlook.office365.com/powershell-liveid/ -Credential $credential -Authentication "Basic" -AllowRedirection
Import-PSSession $exchangeSession -DisableNameChecking
$SccSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri
https://ps.compliance.protection.outlook.com/powershell-liveid/ -Credential $credential -Authentication "Basic" -AllowRedirection
Import-PSSession $SccSession -Prefix cc
Connect-MsolService -Credential $credential
Import-Module SkypeOnlineConnector
$sfboSession = New-CsOnlineSession -Credential $credential
Import-PSSession $sfboSession


**Note** I left out the SharePoint Online connection, because in order to run it without errors you either need to set your local DNS to Google's, or use the web login and that's a pain - plus I don't manage SharePoint, so......

**Note** The Exchange Online and Security Center won't work if you run MFA. For that, you need to install the EXOPS modules, which can't be run in a single window.

Save it as a .ps1 with a name like O365-Remote.ps1 to somewhere like C:\Scripts

Next, create a PowerShell shortcut anywhere, like on your Desktop:

Right-click the Desktop > New > Shortcut

New Shortcut

In the location field, enter:

Powershell.exe

PowerShell Shortcut


Click Next

Give it a name like O365RemotePS and click Finish.

O365 Remote Shortcut


Right-click the new O365RemotePS shortcut, and go to Properties.

In the Target field, add the following to the end of the line:

-NoExit -File "C:\Scripts\O365-Remote.ps1"

It will look like so:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoExit -File "C:\Scripts\365-Remote.ps1"

Click OK.

Run your new shortcut as admin, and you'll get a creds prompt for your Office 365 organization.

**Note** Enter creds in the username@orgname.com format.

Once it starts the remote session, you'll be able to run your O365 cmdlets.

Remote MSOL

Remote CSUser
 
Remote Mailbox
 

Tuesday, February 19, 2019

Exchange 554 5.7.105 sender's email address is on SenderFilterConfig list

One of my users submitted a ticket that "an important client was getting blocked by our spam filter". Checking the filter, all messages from that sender were clean and not being blocked at all. After further digging i.e. the user finally gave me the NDR that the external sender was getting:

host 123.45.67.89 [123.45.67.89] said: 554 5.7.105 SenderFilterAgent; Sender denied as sender's email address is on SenderFilterConfig list

**Note** In the above bounce message, the "host IP address" refers to my Edge server.

In message tracking, it shows the same bounce message; you can view that by running the following in the EMS (Exchange Management Shell):

Get-MessageTrackingLog -Sender sender@externaldomain.com -Start "2/18/19 8AM" -End "2/18/19 5PM" | fl *RecipientStatus*

RecipientStatus : {[{LED=554 5.7.105 SenderFilterAgent; Sender denied as sender's email address is on SenderFilterConfig list};{MSG=};{FQDN=};{IP=10.28.68.138};{LRT=}]}

This could be one of two things:

The sender or external domain is on the SenderFilterConfig BlockedSenders/BlockedDomains on the Exchange Edge or Mailbox Server(s)

-or-

The sender/domain is listed in the User's MailboxJunkEmailConfiguration blocked senders list in Outlook.

I do run an Edge server, but I don't have entries in the Sender Filter Config (because I run a 3rd party spam filter) as seen here:

Get-SenderFilterConfig | fl *block*

BlockedSenders               : {}
BlockedDomains               : {}
BlockedDomainsAndSubdomains  : {}
BlankSenderBlockingEnabled   : False
RecipientBlockedSenderAction : Reject


Upon checking the User's Junk mail config, bingo! She had hundreds of senders in there; this particular sender being one of them.

**Note** The User also had the sender in the TrustedSendersAndDomain list, but the block list takes precedence over allowed.

To view the list, run the following in the EMS:

$formatenumerationlimit=-1

The above cmdlet will allow you view the entire list because if it's large, PowerShell will truncate it.

Then, run:

Get-MailboxJunkEmailConfiguration -Identity "user mailbox" | fl *block*

**Note** Change "user mailbox" to the user you're dealing with.

You can then right-click the Shell title bar and Edit > Find to search for the suspect sender.

Now, let's remove that sender from the blocked sender list:

Set-MailboxJunkEmailConfiguration -BlockedSendersAndDomains @{remove="sender@domain.com"}

**Note** Replace "sender@domain.com" with the actual email address of the sender.

One thing I noticed: the removal of the sender from the blocked list didn't take effect immediately. In fact it didn't do anything for the hour I waited. 
The background operation that happens is: even though the blocklist is client-specific, it pushes that setting up to the Exchange servers, and if you run an Edge, it will need to EdgeSync over.

In order for the sender to be cleared from the blocked list, I had to disable/re-enable the SenderConfig on the Edge.

To turn off the Sender Filter Config, run:

Set-SenderFilterConfig -Enabled $false

Then, run:

Set-SenderFilterConfig -Enabled $true

After that, the messages starting being delivered successfully! Now, tell your user they don't need to add every single sender in world to the blocklist, your spam filter can handle the heavy lifting ;)

Saturday, December 29, 2018

Exchange 2016 Create Remote PowerShell Shortcut


A growing trend for organizations is to lock down direct remote access to servers, requiring the need for Remote PowerShell Sessions to manage things like Exchange. The problem is, it's a nuisance to create a remote session every time you need to connect to Exchange.

To save time (and my sanity) I decided to create a shortcut that will start the remote session automatically when you run it.

Copy the following information into Notepad:

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://mail.exchangeitup.com/PowerShell/ -Authentication Kerberos -Credential $UserCredential
Import-PSSession $Session -DisableNameChecking

**Note** Change -ConnectionURI to match your Exchange namespace or a server name (if you don't publish PowerShell).

Save it as a .ps1 with a name like Exchange-RemotePS.ps1 to somewhere like C:\Scripts

Next, create a PowerShell shortcut anywhere, like on your Desktop:

Right-click the Desktop > New > Shortcut

New Shortcut
 
 
In the location field, enter:
 
Powershell.exe
 
PowerShell Shortcut
 
 
Click Next
 
Give it a name like ExchangeRemotePS and click Finish.
 
 
ExchangeRemotePS Shortcut

 
Right-click the new ExchangeRemotePS shortcut, and go to Properties.
 
In the Target field, add the following to the end of the line:
 
-NoExit -File "C:\Scripts\Exchange-RemotePS.ps1"
 
It will look like so:
 
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoExit -File "C:\Scripts\Exchange-RemotePS.ps1"
 
Shortcut Target
 
 
Click OK.
 
Run your new shortcut, and you'll get a creds prompt for your Exchange organization.
 
Once it starts the remote session, you'll be able to run your Exchange cmdlets.
 
Remote PowerShell Session
 
 
Now, you can use that new shortcut instead of tiring out your fingers before even getting into Exchange!