Two Necessary Steps to Make Your Anti-Malware Updates Working Behind Proxy

Hi folks,

As you all well aware Microsoft replaced Forefront Protection for Exchange (FPE) on Exchange 2013 with the integrated anti-malware. On the first glance it appears as FPE integrated into Exchange. As long as its configuration is concerned anti-malware is almost like an appliance since there's not much to configure.

I found this article extremely helpful in configuring and troubleshooting proxy settings for Exchange 2013 anti-malware updates.

There are 2 areas of configuration to ensure that updates are successfully happening: file system and proxy settings.

First we will attend file system. Browse with File Explorer the folder where Exchange is installed (for example C:\Program Files\Microsoft\Exchange\V15\FIP-FS\Data\Engines\amd64\Microsoft\bin). When accessing FIP-FS directory (and some other subdirectories) File Explorer displays a dialog box that prompts you with the following: "You don’t currently have permission to access this folder. Click Continue to permanently get access to this folder". After clicking Continue you are able to browse directory contents. Check NTFS security permissions for this directory and ensure that NETWORK SERVICE has  "Full Control" permissions.

Secondly, if you are running behind proxy you will need to configure proxy settings on your Exchange server. First you need to make sure that your Exchange servers can connect to http://forefrontdl.microsoft.com/server/scanengineupdate via proxy server without authentication. After this is configured we need to configure it on the Exchange server level. Please note that anti-malware totally ignores proxy settings configured via Internet Explorer properties or unauthenticated proxy configured by using netsh command (yet the latest will still be needed to check CAS certificates URLs).

You will need to configure proxy settings for your anti-malware by executing the following commands:

Add-PsSnapin Microsoft.Forefront.Filtering.Management.Powershell

Set-ProxySettings -Enabled $true -Server 192.168.0.1 -Port 80

(of course you will need to replace the values with yours)

After this you will need to execute the following command to manually kick downloads:

cd $exscripts
.\Update-MalwareFilteringServer.ps1 -Identity SERVER1.CONTOSO.COM

Make sure that you type server FQDN rather than the hostname after the Identity parameter.

If download is successful you will get event 6033 as follows.

You can also browse to C:\Program Files\Microsoft\Exchange\V15\FIP-FS\Data\Engines\amd64\Microsoft\bin (or whatever is your Exchange installation folder) and ensure that new update files are there.

I hope you will find it helpful for your endeavors.

Enjoy.

Configuring Client Access Web Directory URL Settings on Multiple Access Servers

Hi folks,

Just wanted to share with you a quick and easy way to configure virtual directories URL settings for each of client access protocols in Exchange 2013 or 2016.

This is usually one of the first steps of configuring CAS layers on Exchange servers. And because there's a lot of typing there's always a risk to make a mistake when typing the URL of each virtual directory. To avoid an error PowerShell magic scripting comes to our help.

As the first step we need to properly configure virtual directories as described here. After this we need to check that all the URLs are configured without a mistake. If this is a true then we are ready to put together a script which can be easily applied for the rest of CAS virtual directories in your environment.

You can achieve it by creating a variable for each of the virtual directories and then use InternalUrl and ExternalUrl attribute values to configure the InternalURL and ExternalURL of the virtual directories on the remaining servers. You can this way configure from 1 to the unlimited number of the servers.


$OWA = Get-OwaVirtualDirectory -Server SERVER1
Set-OwaVirtualDirectory -Identity "SERVER2\OWA (Default Web Site)" -InternalUrl $OWA.InternalUrl -ExternalUrl $OWA.ExternalUrl


$ECP = Get-EcpVirtualDirectory -Identity "SERVER1\ECP (Default Web Site)"
Set-EcpVirtualDirectory -Identity "SERVER2\ECP (Default Web Site)" -InternalURL $EC.InternalUrl -ExternalUrl $ECP.ExternalUrl

$OAB = Get-OABVirtualDirectory -Identity "SERVER1\OAB (Default Web Site)"
Set-OABVirtualDirectory -Identity "SERVER2\OAB (Default Web Site)" -InternalUrl $OAB.InternalUrl -ExternalUrl $OAB.ExternalUrl –RequireSSL:$true

$EWS = Get-WebServicesVirtualDirectory -Identity "SERVER1\EWS (Default Web Site)"
Set-WebServicesVirtualDirectory -Identity "SERVER2\EWS (Default Web Site)" -InternalUrl $EWS.InternalUrl -ExternalUrl $EWS.ExternalUrl

$OA=Get-OutlookAnywhere -Identity "SERVER1\Rpc (Default Web Site)"

Set-OutlookAnywhere -Identity "<Server Name>\Rpc (Default Web Site)" -InternalHostname $OA.InternalHostname  -ExternalHostname $OA.ExternalHostname

I hope that it helps you as it helped me.

Enjoy.

Configuring Receive Connectors for Application Authentication

Hi folks,

I have recently had an adventure with Exchange 2013 which I want to share with you. I have installed a new Exchange 2013 server into my environment.

The bad surprise awaited me when configuring an application server to send email via Exchange server. Application was configured to issue STARTTLS command. Server was configured with the appropriate certificate (which in addition to the load balanced host name should be containing SMTP server's host name. However when attempting to send a test email i got error: 535 5.7.3 Authentication unsuccessful.

It was especially surprising, especially because I could login using clients like OWA. The answer actually was in PermissionGroups of the front-end receive connector which by default doesn't include  the "Exchange Users" group.

To make my application authenticating against Exchange servers I had to configure default front-end connector to include "Exchange users" group into permissions group. If you are running  Exchange 2010 you do it on the receive connector or you can do the same on the back end connector on the mailbox server (which is actually a default setting on Exchange 2013).

Set-ReceiveConnector "Default Frontend ServerName" -PermissionGroups ExchangeUsers,ExchangeServers,ExchangeLegacyServers

As a result i have got so desired 235 2.7.0 Authentication successful response and email was successfully submitted and sent to its recipients.

Enjoy

Reporting Exchange Attributes of the AD Object

Hi folks,

This little code will help you to report the Exchange related attributes from your AD accounts and export them into the CSV file.

So imagine a scenario where you have a bunch o test accounts which start with TST for which you need to report their recipient type information. This is where Get-AdUser cmdlet comes to help. Of course you may modify your filter according to the attribute to filter on or you can use -Filter * to output all the users. Alternatively you can filter by display name or any other attribute that fits your purpose better.

When creating report for clarity sake i used samAccountName and DisplayName to identify my mailbox-enabled users as well as msExchRecipientDisplayType  and msExchRecipientTypeDetails as I was hunting for those values. Again any Exchange or non-Exchange user attributes can be used. You can refer here as a good cheat list for the user AD attributes as a reference. And of course don't forget to import PowerShell module for AD.

Import-Module ActiveDirectory
Get-ADUser -Filter {sAMAccountName -like "TST*"} -Properties * |select samAccountName,DisplayName,msExchRecipientDisplayType,msExchRecipientTypeDetails |Export-Csv Report.csv


Enjoy!

Resolving Some of Exchange 2013 Upgrade Issues

Hi folks,

I have been lately working on the upgrade of one of my Exchange 2013 servers to CU5.

My installation attempt was interrupted with a lot of errors and warnings which were revealed during prerequisites check.

The good things is that all these warnings are quite straightforward and therefore are really addressable.

The first warning was very straight forward: send connector with the namespace * was missing e.g. your Exchange organization is not able to send email to the internet. This can be ignored (which is not fatal) and the send connector can be configured afterwards or you can run this command to have the connector created:

New-SendConnector "Internet Send Connector" -FrontendProxyEnabled:$true -AddressSpaces *

The second warning was about missing UCMA 4.0. I was surprised how Exchange 2013 was there in the first place without it. But I ended up downloading and installing it. Which again is very straight forward.

Finally there was an error related to the UM services not being able to be installed because of misconfigured PowerShell execution policy.

It can be found at this branch: Computer Policy-> User Configuration-> Administrative Templates-> Windows Components-> Windows PowerShell. The setting name is Turn On Script Execution. The default setting of the is Enabled for all scripts.

To make UM installation successful we need to enable it. Following instructions for from MS support article I have set the value for Turn On Script Execution to Not Configured.

After this I have executed setup.exe /m:Upgrade /IAcceptExchangeServerLicenseTerms and Exchange 2013 upgrade to SP1 has gone smoothly.



So the main trick here is to read warnings and use the appropriate URLs.

Enjoy.

First Glance on Exchange 2016 (Part 3). Quickly Configuring CAS Virtual Directories

Hi folks,

In this article I will share with you how I configured virtual directories in my Exchange 2016 lab. Please note that there is no dedicated CAS role in Exchange 2016 and it is running as client access services on the Mailbox server.

As you remember I'm quite a lazy guy to configure every server one-by-one either by using EAC or EMS. As the result I have put this little script together which buffers all the virtual directories (for each CAS protocol) and identically configuring internal and external URLs for each of them. This script can be used in any environment which is running Exchange 2010/2013/2016.

The code that I have executed is as follows (of course don't forget to replace URLs with the proper ones in your environment):


Get-OwaVirtualDirectory |foreach {Set-OwaVirtualDirectory -Identity $_.Identity -InternalUrl https://mail.contoso.com/owa -ExternalUrl https://mail.contoso.com/owa}

Get-EcpVirtualDirectory |foreach {Set-EcpVirtualDirectory -Identity $_.Identity -InternalUrl https://mail.contoso.com/ecp -ExternalUrl https://mail.contoso.com/ecp}

Get-oabVirtualDirectory |foreach {Set-OabVirtualDirectory -Identity $_.Identity -InternalUrl https://mail.contoso.com/OAB -ExternalUrl https://mail.contoso.com/OAB}

Get-ActiveSyncVirtualDirectory |foreach {Set-ActiveSyncVirtualDirectory -Identity $_.Identity -InternalUrl https://mail.contoso.comt/Microsoft-Server-ActiveSync -ExternalUrl https://mail.contoso.com/Microsoft-Server-ActiveSync}

Get-WebServicesVirtualDirectory |foreach {Set-WebServicesVirtualDirectory -Identity $_.Identity -InternalUrl https://mail.contoso.com/EWS/Exchange.asmx -ExternalUrl https://mail.contoso.com/EWS/Exchange.asmx}

Get-MapiVirtualDirectory |foreach {Set-MapiVirtualDirectory -InternalUrl https://mail.contoso.com/mapi -ExternalUrl https://mail.contoso.com/mapi -Identity $_.identity -IISAuthenticationMethods Negotiate}

Execution results in something like:

If you are to use this method for the scenario when adding new Exchange 2013/2016 servers into your current organization and are planning to use different namespace you may consider using variables and filters to avoid up with your production environment.

And finally it appears that MS is giving preference to MAPI/HTTP over RPC/HTTP and therefore this protocol is enabled in the brand new Exchange 2016 organization is enabled by default.

To be continued..

First Glance on Exchange 2016 (Part 2)

Hi folks,

In this article I continue story of my encounter with the Exchange 2016. After both of the servers have been installed. It is time to configure them.

Here I'm following guidelines from the TechNet. The configuration tasks can be done from both EAC or EMS. I personally preferred EMS for the majority of the tasks as it is more fun.

I have started with preparation works. I have created all the necessary DNS records. In my case I have created A record mail.contoso.com. It will be used as the hostname for client access and transport. Since it is the lab I used poor man's solution, namely DNS round-robin. Of course in the production enterprise environment it will be one single A record pointing to load balancer's VIP address.

Of course the other record I have created was MX record. I assume you all know what it is and how it is used

Additionally I have created SPF record as follows (all email sent from the servers configured as MX records are valid senders of email):
msglab16.net IN TXT “v=spf1 mx –all”

After this I have created a forward lookup DNS zone and called it labmail.com. There I also created MX and SPF record. I will use this DNS zone for my second accepted domain.

As DNS records were ready I moved to the Exchange 2016 configuration. So I have started with configuring the transport level.

First, I have created Send Connector for Internet Mail (using * as the address space and added both of transport servers as source servers).

New-SendConnector -Name "Internet Mail" -AddressSpaces * -SourceTransportServers EX2016-EX01,EX2016-EX02

Send connectors are created with the default maximum message size is 35 MB. So I have tweaked it to

Set-SendConnector "Internet Mail" -MaxMessagesize 50MB

After that I have added labmail.com as accepted domain of the Internal Relay type (this can be used for scenarios of the Office 365 or cross forest integration where part of the recipients sits in one organization and another one in the other). This is a quick command to do this:

New-AcceptedDomain -Name labmail.com -DomainName labmail.com -DomainType InternalRelay

The accepted domain msglab16.com has been created by default as Authoritative accepted domain (since this is the name of my AD forest in the lab).

When a new accepted domain has been selected I have tweaked default email address policy to make email addresses in the format firstname.secondname@labmail.com (%g.%s@labmail.com) as default email address of my recipients.

Additionally I have added another email format alias@mgslab.com to the policy.

After policy has been modified I clicked Apply to have policy applied to all the existing recipients (in my case it was only admin, so be careful in the real life scenarios with this button). Additionally in real life you may created new email address policy and change its priority as appropriate so that it is applied to your new recipients. And, at the end of the day, you can also always use EmailAddressPolicyEnabled:$false for Set-* commands for each recipient to configure them with the email addresses you desire.


After transport had been configured I started working on configuring Exchange Server certificate which will be used for client access and transport. Using EAC is a nicer tool for creating cert request and then assigning it to Exchange services but PowerShell is more fun.

New-ExchangeCertificate -GenerateRequest -SubjectName "c=US, o=MSGLAB16, cn=mail.contoso.com" -DomainName contoso.com, example.com -PrivateKeyExportable $true

After request has been created I submit it to the certification authority. Of course in production environment it should be trusted third-party CA where request should be submitted. In my case I was using my internal enterprise CA in the lab. The following screenshots are self-explanatory and therefore need no additional comments:

After certificate has been downloaded I have imported it to an Exchange server as follows:

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\certificates\ExportedCert.cer -Encoding byte -ReadCount 0))

After certificate has been imported I used its thumbnail and assigned it to IIS,SMTP,POP and IMAP services. And after this don't forget to run iisreset

Certificate for my second server I configured using EAC. I have also attached screenshots from that exercise to this article. Again they are quite self explanatory.

To be continued...