Exchange 2013 Admin Center URL’s

You have just installed Exchange 2013 in your Exchange 2007 or 2010 organization. You start a browser to access the Exchange Admin Center, the Exchange GUI admin tool, point the browser to https://servername/ecp and login with an account you know have permission in Exchange but are prompted with an error message.
Reason for this is that the mailbox you try to logon to is not located on Exchange 2013. solution is to move the mailbox to Exchange 2013 mailbox server or change the URL to “https://casservername/ecp?ExchClientVer=15”. This will tell EAC to show the Exchange 15 version of EAC instead of the Exchange 14 version which should be shown because the mailbox is not located on Exchange 15 server.
With the new URL you get into EAC and can start configure your Exchange 2013 server and life is good until you realize that EAC will be reachable from Internet. It will still require authentication, but nevertheless, reachable.
Since you have TMG to publish Exchange with you figure that you can deny access to /ecp URL from Internet but this will unfortunately stop users from accessing the OWA options web.

You find out that there is a parameter “AdminEnabled” on the ECP website to disable EAC. By setting AdminEnabled to False. Sadly this option disable EAC completely and you now only have the Exchange Management Shell to use and most people want a GUI to manage Exchange.

Solution is to create a new website that is not reachable from Internet but only from Internal network. Easiest is to change the listening port on the new website.

here is what you need to do.

# port used for the EAC website
$port = 9443

# create a new folder to host the new website
mkdir C:\EAC

# create a new webiste
New-Website -Name EAC -PhysicalPath C:\EAC -Verbose -Ssl -Port $port -Id $Port –ApplicationPool MSExchangeOWAAppPool

Then you must assign a certificate to the website. This can be done on the bindings option on the newly created EAC website options.

#create FW rule to allow traffic to website
New-NetFirewallRule -Name "EAC website" -Description "Exchange Admin Center website" -DisplayName "EAC website" -Protocol TCP -Profile Any  -Action Allow -LocalPort $port 

and then create the ECP applications in the EAC website.

#hostname
$hostname = ([System.Net.Dns]::GetHostByName(($env:computerName))).hostname

#InternalUrl
$IntUrl = (Get-EcpVirtualDirectory -Server $hostname).InternalUrl.tostring()

# Get path from the original ECP website
$DirPath = (Get-EcpVirtualDirectory -Server $hostname).path

# Create new EAC web
New-EcpVirtualDirectory -WebSiteName EAC -Server $hostname -InternalUrl $IntUrl -Path $DirPath -Role ClientAccess -AppPoolId MSExchangeECPAppPool

# Finally , diable EAC on the default ECP app
Set-EcpVirtualDirectory $hostname\'ecp (default web site)' -AdminEnabled $false

New-ECPVirtualDirectory states that you must create a OWA application also, but I have not encountered any problem by not doing this. The only problem I have when doing this is that browsing in the OU structure in AD when creating new mailboxes don’t work. have tried both with the above settings and also by creating the OWA appl. as suggested but it simplyu don’t work either way.
Simply put the commands in a powershell script and run it from EMS. when done you can access EAC with the new URL “https://casname:9443/ecp”.
Tips: when later changing URL and certificate on your CAS, you should also change them in the EAC website to make everything work correctly.

This is most likely unsupported but I have it running for several months without any problem except for the browsing thing in EAC.

Irrational behavior of Exchange 2013 receive connectors

Scenario: Exchange 2013 server with both mailbox and client access role combined.
You create a receive connector and scope it down to some specific IP addresses for applications running on servers with the specified IP. You configure to allow anonymous relay on the connector.

Applications on server are happy since they can now anonymously submit and relay messages off your Exchange installation to Internet.

Suddenly after a few hours, applications cannot send and relay mail.
Luckily you have protocol logging enabled and discover that your newly created connector is not used anymore. some more troubleshooting later and you desperately restart Exchange transport service. After the restart mail flow is restored the way you want.

But again after some hours, mail flow stops. further investigation shows that exactly the same thing has happened again, another restart of Exchange transport get things going.

Solution: Restart the transport service with a few hours interval, nahh don’t think so. Exchange 2013 is brand new and should work, and before the migration you had the exact configuration with Exchange 2010 server.

Real solution: I very simple. remove the old receive connector and create a new one, but connect it against the frontend transport instead of the default Hub transport (backend).
Transport system has been running fine as it should for a couple of weeks now. I believe this is a bug in the transport service and the symptom is selecting the wrong receive connector when there is an incoming connection to Exchange.

It makes sense to connect receive connectors and possibly send connectors against frontend (CAS server) but I think it should work equally fine if you select the backend (mailbox server) especially when the backend is the default option when using Exchange Admin Center.

Exchange 2007 and 2010 anti-spam automatic installation

Some organizations use the built-in anti-spam feature in Exchange 2007 and 2010. http://technet.microsoft.com/en-us/library/aa997658(v=exchg.141).aspx.

Content Filter engine is using definitions created by Microsoft and in an ideal world they are downloaded, approved and installed with help of windows update, but for many reason this is not always possible.

I created a small vbscript that uses windows update to search for only Exchange standard antispam updates and automatically install them without doing anything with other updates.

WU_Exchange_AntiSpam.vbs script can easily be scheduled to run with task scheduler.

' search and automatically install Exchange Server standard antispam definitions
' Lasse Pettersson, http://anewmessagehasarrived.blogspot.com
'
 
Set updateSession = CreateObject("Microsoft.Update.Session")
'Updatetitle to search for
updateTitle = "Microsoft Exchange Server Standard Anti-spam Filter Updates"
 
WScript.Echo vbCRLF & "Searching for: " & updateTitle & "..."
Set updateSearcher = updateSession.CreateupdateSearcher()
 
'Search for all software updates, already installed and not installed
Set searchResult = updateSearcher.Search("Type='Software'")
Set updateToInstall = CreateObject("Microsoft.Update.UpdateColl")
updateIsApplicable = False
 
'Cycle through search results to look for the update title
For i = 0 To searchResult.Updates.Count-1
    Set update = searchResult.Updates.Item(i)
    If Left(UCase(update.Title),Len(updateTitle)) = UCase(updateTitle) Then
        'Update in list of applicable updates 
        'Determine If it Is already installed Or Not
        If update.IsInstalled = False Then
            WScript.Echo vbCrlf & "Result: Update applicable, not installed."
            updateIsApplicable = True
            updateToInstall.Add(update)
        Else 
            'Update Is installed so notify user And quit:
            WScript.Echo vbCrlf & "Result: Update applicable, already installed."
            updateIsApplicable = True
            WScript.Quit
        End If
    End If 
Next
 
If updateIsApplicable = False Then
    WScript.Echo "Result: Update is not applicable to this machine."
    WScript.Quit
End If
 
'Download update
Set downloader = updateSession.CreateUpdateDownloader() 
downloader.Updates = updateToInstall
WScript.Echo vbCrlf & "Downloading..."
Set downloadResult = downloader.Download()
WScript.Echo "Download Result: " & downloadResult.ResultCode
        
'Install Update
Set installer = updateSession.CreateUpdateInstaller()
WScript.Echo vbCrlf & "Installing..."
installer.Updates = updateToInstall
Set installationResult = installer.Install()
        
'Output the result of the installation
WScript.Echo "Installation Result: " & installationResult.ResultCode
WScript.Echo "Reboot Required: " & installationResult.RebootRequired

If you run this script manually, use the cscript engine because some text is written and looks better if you don’t use the wscript engine.

Exchange 2010 Service Pack 3 is out

Exchange 2010 SP3 is finally out and people have been waiting for it to be able to upgrade to Exchange 2013, but hurry slowly, Microsoft at the same time announce that to get coexistence with Exchange 2010, you not only need Exchange 2010 SP3 but also Exchange 2013 CU1 

As usual you need to update Active Directory schema before applying SP3. See the Exchange 2010 SP3 release notes.
If the Exchange 2013 CU1 will need to extend the schema once more, only time can tell.

Some useful links.
Exchange 2010 SP3 download
What’s new
Exchange 2010 SP3 UM language pack

The same time Exchange 2010 SP2 Update Rollup 6 and also Exchange 2007 SP3 Update Rollup 10

Hopefully we don’t need to see a version 2 of these patches or any new bugs introduced like we sort of have been used to the last year, sigh.

Exchange 2013 Anti-Malware Protection

Since there will be no Forefront protection for Exchange Server 2013 to handle spam and other bad things coming in with mail from Internet, Exchange admins must use something else to block those bad things, but what to use?

For those organizations that use Exchange Edge and Forefront protection for Exchange on it can continue to use that together with Exchange server 2013.
There is no Exchange 2013 Edge server yet, but hopefully it will be in the future.

Another option that many organizations already use is to leverage something outside of Exchange for hygiene. This software is deployed on regular servers or as an appliance and some is used as a service on Internet, and most of the time these solutions costs money.

Microsoft did not leave organizations completely out in the dark by removing forefront for Exchange. They moved some if it’s functionality into Exchange.
First we have to regular transport anti-spam agents that have its legacy from Exchange 2003 and IMF (Intelligent Message Filter). They of course have evolved and some organizations use them today with their Exchange 2007 and Exchange 2010.
Installation is done with help of a powershell script “install-AntispamAgents.ps1” located in the scripts subfolder in the Exchange installation. Difference with Exchange 2013 compared to earlier versions is that in Exchange 2013 there is no GUI to configure those agents and you must leverage powershell.
Those agents are as stated anti-spam agents, http://technet.microsoft.com/en-us/library/jj218660.aspx . They have been around for years and are configured in the same way as before so one thing you definitely should do is to use safelist aggregation, http://anewmessagehasarrived.blogspot.se/2008/04/outlook-safelist-aggregation.html but configuration of the anti-spam agents is a story for it self.

Secondly the malware filtering piece of Forefront for Exchange moved into Exchange itself, http://technet.microsoft.com/en-us/library/jj150547.aspx. If you have an Exchange 2010 with forefront for Exchange installed and an Exchange 2013 you will see the same folder structure “C:\Program Files (x86)\Microsoft Forefront Protection for Exchange Server” and “C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS”
This is something that you have to enable and configure after installation of Exchange and are all done with powershell commands.
To enable the malware agent who is disabled by default, use the powershell script “Enable-AntimalwareScanning.ps1”. This script will not only enable the malware agent but also configure regular updates, restart the transport service etc. to get everything running. Default automatic update check for definitions will every 60 minutes. You can verify when and what version of the engine and definitions is in use with “Get-EngineUpdateInformation” or if you want to manually check for updates, use the powershell script “Update-MalwareFilteringServer.ps1” that basically is a wrapper around the “Start-EngineUpdate” powershell command.

When this is done, you should have a look at the default malware policy and possibly alter the configuration, http://technet.microsoft.com/en-us/library/jj150576.aspx.
Think about the available options for a while before changing them, especially where to send notifications and to whom otherwise you can create a mail storm of notifications.

If the built-in anti-spam agents and malware protection is good enough for your organization is something you have to decide. There is little information about how the malware piece is performing in real life since very few organizations don’t yet run Exchange 2013