Testing SMTP Authentication Using OpenSSL

Hi folks,

I would love to share with you with my latest experience with SMTP authentication in Exchange. SMTP authentication is a very important area in messaging as it helps to ensure that only authenticated users can send messages via your SMTP servers and that mails are secured in transfer. This is very necessary in our world full of spammers.

To perform testing you will need to use 2 tools, namely OpenSSL and Base64.exe. ToOpenSSL can be downloaded from here and Base64.exe can be downloaded from here. After both of them are downloaded you will need to extract them to the appropriate folders from where you can execute it.

OpenSSL helps you to see whether server supports AUTH protocol necessary for authentication and Base64.exe helps you to generate Base64 hashes for your usernames and passwords that you will use for authentication.

First of all we need to check if out SMTP server supports STARTTLS command it. To do it you need to execute

telnet mail.contoso.com 25

When prompt window is open type ehlo smtp.contoso.com

In response you will be presented with the list of commands ensure that the following 2 commands are listed:

250-STARTTLS
250-AUTH NTLM (or 250-AUTH PLAIN)

This indicates that your server supports TLS and SMTP authentication.

As soon as we have confirmed this we will need to emulate SMTP over TLS conversation with our SMTP server. This is where OpenSSL comes to our help. Execute the following command to connect to the server:

openssl s_client -connect mail.contoso.com:25 -starttls smtp

After connected you should receive as an output certificate that is used for TLS as well as information about certificates it has in it chain all the way up to root CA certificate. Please note common name (CN) for TLS certificate. Some application can't send SMTP messages over TLS if it is different from the hostname that is configured in their settings. The way to remediate is to use the same hostname as specified in the certificate CN. It will simply save you a lot of headache. All you need is to have an A record configured in your DNS.

To start authenticaiton type:

AUTH LOGIN

You should be presented with the 334 response followed by hash. It will be followed with the prompt

You will need to generated Base64 hash for your email address and password. The same procedure applies to both mailbox-enabled and mail-enabled users in Exchange.

This is when you will need Base64.exe utility. You will need to launch it and in the box named Text to be encoded, decoded or hashed type email address, like user1@contoso.com. Click on the Encode button (green arrow). Base64,exe will generate hash code for you in the Encoded Text box. Copy it and paste hash into the prompt and click Enter.

You will be presented with another 334 response. Follow the same steps for he password. Namely, in the box named Text to be encoded, decoded or hashed type email address, like P@$$w0rd. Click on the Encode button (green arrow). Base64,exe will generate hash code for you in the Encoded Text box. Copy it and paste hash into the prompt and click Enter. If everything is done correctly you will receive: 235 2.7.0 Authentication successful.

Now you will need to use SMTP conversation to type and send an email;

mail from:user1@contoso.com

You should reseive response: 250 2.1.0 Sender OK

rcpt to:user2@contoso.com

You should receive response: 250 2.1.5 Recipient OK

data

You should receive response: 354 Start mail input; end with <CRLF>.<CRLF>

Type your email text, something like:


subject: Test OpenSSL Mail-Enabled User

Test from mail-enabled user


.

You should receive response like:

250 2.6.0 <XXXXXXXXXXXXXXXXXXXXXXXX@server.contoso.com> [Inter
nalId=106] Queued mail for delivery

Enjoy.

Couple of Words About Microsoft Certification in the Unified Communication Area

Hi folks,

I have just recently obtained my MCSA: Office 365 certification. So I just wanted to share something I have discovered about certification programs with Microsoft.

As you all well know, in 2012 Microsoft returned from MCTS/MCITP certification back to MCSA/MCSE. In order to get your MCSE certification as in old good day you need first get MCSA and then pass 2 specialization tests and get your MCSE. It's a little bit easier than the original MCSE certification,as it doesn't require anymore to pass tons of other exams but rather focus on spealization.

Originally, when you were seeking MCSE: Messaging or MCSE: Communications certificate you had first to obtain MCSA: Windows Server 2012 certification first and then you could do 2 exams in either certification. However in 2014 Microsoft has introduced MCSA: Office 365 certification which is now alternate way to get your MCSA.

So now you are presented with 2 options to obtain your MCSE in UC are: you either obtain: MCSA: Windows Sever, which is actually a requirement for other MCSE certifications in Server and Desktop Infrastructure. Thus you are getting higher horizons open before you. And also, please note that this is an upgrade path from MCITP to MCSE. Or you can obtain MCSA: Office 365 and thus keep your mind focused in your specialization area. Either way would bring you to MCSE in Exchange and Lync.

So to get MCSA: Office 365 you will need to pass exams with code 70-346 and 70-347. If you want to obtain MCSE: Messaging, you will need afterwards to pass 70-341 and 70-342. By the way 70-342 is a very tough exam so prepare well and do a lot of TechNet or Exchange 2013 CHM file reading before you sit at this exam. And if you want to get your certification in MS Lync aka MCSE: Communications then you will need to pass 70-336 and 70-337. I can't say any word about the later because I haven't yet studies for them or sat at them.

However, it's worthy to mention that Microsoft is to issue new versions for all its server products and the OS, so who knows may we will face another certification routes change.

But anyway I hope this article is helpful for you to make your right decision.

Enjoy.

Performing Exchange 2013 Server Update to the Next Build

Hi folks,

I have recently been involved in activity of upgrading Exchange 2013 server to a later build (CU5 in my scenario).

As you're probably aware there's a new architecture in Exchange 2013 which involves only 2 roles and also MS has paid high attention to the high availability to reduce downtime for Exchange servers. The component that helps achieving this high availability by monitoring every Exchange component and making sure it's up and running. If it can't restore a component it will fail database copies to another server which has all the components healthy. More on Managed Availability can be found here.

Taking this into account there's the whole process of preparing a server for upgrade and then restoring back to its functionality. In fact this can be useful for those who are getting ready for the 70-342 certification exam to achieve their MCSE: Messaging certificate.

Before upgrading your Exchange server you need to ensure that it has no active mailbox database copy running on it and that there's no mail being routed via this server, Additionally any database copy failover to the server being upgraded should be prevented.

The following is the process for preparing a server for the upgrade:

1. We let need to drain all the transport queues on the server to avoid new messages being sent/received by it

Set-ServerComponentState SERVER1 -Component HubTransport Draining -Requester Maintenance

Redirect-Message -Server SERVER1 -Target SERVER2.contoso.com


Please note that you will need server FQDN for the Target parameter in the second command

2. Suspend node in the DAG:

Suspend-ClusterNode -Name SERVER1


3. Prevent database copies being activated on the server:

Set-MailboxServer SERVER1 -DatabaseCopyActivationDisabledAndMoveNow $true

Set-MailboxServer SERVER1 -DatabaseCopyAutoActivationPolicy Blocked

Set-ServerComponentState SERVER1 -Component ServerWideOffline -State InActive -Requester Maintenance


After this we can perform server upgrade either by running GUI or in unattended mode (my favoirite one) by executing:

setup.exe /m:Upgrade /IAcceptExchangeServerLicenseTerms

Of course, don't forget to navigate to the folder that contains the latest Exchange 2013 binaries.

After this you make yourself a cup of tea or coffee and wait for the installation to complete. When installation is over you will need to ensure that it has run successully and remove server from the maintenance mode.


To ensure that upgrade didn't mess anything up you will need to ensure that that all Exchange services are up and running by executing

Get-Service -Name *exchange* |ft -AutoSize

Make sure all the critical services are in the Started state


When all services are up and running and healthy, you are OK remove servers from the maintenance mode by restoring server's ability to send/receive email and to host active mailbox databases:

1. You activate server and its components and endpoints:

Set-ServerComponentState SERVER1 -Component ServerWideOffline -State Active -Requester Maintenance

2. You resume cluster (DAG) membership:

Resume-ClusterNode -Name SERVER1

3. You enable server to host active mailbox database copies again:

Set-MailboxServer SERVER1 -DatabaseCopyAutoActivationPolicy Unrestricted

Set-MailboxServer SERVER1 -DatabaseCopyActivationDisabledAndMoveNow $false

4 Finally you enable transport component on the server to send and receive emails:

Set-ServerComponentState E15MB1 –Component HubTransport –State Active –Requester Maintenance


After this you locate scripts folder and execute RedistributeActiveDatabases.ps1 to make sure that mailbox databases are redistributed according to their activation preference.

cd $exscripts

C:\Program Files\Microsoft\Exchange Server\V15\scripts>.\RedistributeActiveDatabases.ps1 -DagName DAG01 -BalanceDbsByActivationPreference -Confirm:$false

After servers are up and running we can do some more tests to ensure that installation and post-installation tasks have been successful:

1. Check if all services are healthy by executing Test-ServiceHealth

2. Check health of mailbox database copies located on the server Get-MailboxDatabaseCopyStatus (by default command defaults to the local server)

3. Check if replication is working by executing Test-ReplicationHealth

4. Check if nothing is left in maintenance mode by executing

Get-ServerComponentState -Identity SERVER1

Ensure that all the components have state of Active

After this you are OK to upgrade your other servers and operate the current one.

Enjoy!

Exchange 2013 UM Services Start Up Issue on Windows 2012 R2

Hi folks,

I have recently had to deal with the problem of Unified Messaging (aka UM) components not being able to start on a Exchange 2013 multi-role box. I will not dwell explaining what the UM in Exchange 2013 is because it can be found here.

I'd rather share with you what were the symptoms and what was the magic bullet in my case.

First of all both Microsoft Exchange Unified Messaging and Microsoft Exchange Unified Messaging Call router services would fail to start. I had both of these services on my server because it was a multi-role box. Manual attempt to start them would fail with the error 1067: The process terminated unexpectedly.

When checking Event Viewer I have discovered there are errors with ID 4999 and 1038 found in the Application log and 7031 (for each of the service in the System log.

When searching for solution in Google and Bing I was pointed to different articles and forum discussions. Each person posting his/her post was missing this or that component which would prevent successful start of the UM services. In some cases people were missing the right certificate, while in others some files were corrupted, even UMWorkerProcess.exe. Recommendations were different, including re-installing Exchange binaries on the server. Each story would end up either with success or failure.

Checking my server and found out that UCMA 4.0 was missing. Actually, UCMA 4.0 is one of the  Exchange 2013 prerequisites which should be installed on a Windows server before the installation of Exchange binaries.

Finding this out made my solution quite successfuly. I have downloaded UCMA 4.0 installation file from here and installed it on my server. Installation is straightforward. All you need is to press Next button couple times and wait till UCMA is installed on the server.

After this I have restarted my server (after all it's running Windows OS) and the services have been restored to functionality. Server Manager dashboard became shiny and both UM and UM Call Router services successfully started and all the dodgy events have stopped being logged to event logs.

Enjoy

Reviving EMS in Exchange 2013

Hi folks,

Just wanted to share with you about the latest adventure that I had with Exchange 2013.

We have recently launched Exchange 2013 lab to play with the new features and also prepare for the future Exchange update. We installed Exchange on the Windows 2012 R2.  However, after installing servers we were greeted by the bad surprise. When we launched Exchange Management Shell (aka EMS) we have received the error like this:

As I have started my investigation the first thing that took my attention that one of the important registry keys is missing, namely HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine.

I have started googling and there were all different kind of advises given. One of them was like this one where it was advised to export the same key from Windows 2008 R2 and import it to Windows 2012 R2 box. This wouldn't work. Fortunately it was lab and there was no negative impact.

Further investigation lead me to this article. The solution it was proposing to install PowerShell 2.0 Engine windows feature which has made the magic. You can use Server Manager or Install-WindowsFeature cmdlet to install it.

After installation I restarted the server and it made the magic and EMS functionality has been restored. Optionally you can run iisreset command (however make sure that you run is as admin) to achieve the same without restarting.Missing registry keys have been restored and PowerShell has started without any problems.

This is the universal solution for all the servers which is working.

However there were couple other problems on the other servers. In one case EMS wouldn't start because of the problems with remote PowerShell. It couldn't connect to remote PowerShell with the error 403.

Further investigations pointed me that 2 websites hosted by IIS on this box are configured with wrong ports. We have installed our Exchange 2013 boxes as multi-role servers. It means that Exchange creates 2 websites in IIS: Default Web Site for CAS role and Exchange Back End for mailbox role. Exchange clients are connected to CAS on port 443 and then are redirected to port 444 on the Mailbox server where all the client protocol data processing is happening. In case of PowerShell ports 80 and 81 are used respectively. More information about how IIS is configured for Exchange 2013 you can read in this Microsoft article about Exchange 2013 Web sites and virtual directories.

In my case I ran Get-WebSite cmdlet and discovered that Exchange Back End website is listening on port 80 and Default Web Site is listening on port 81.

On the properly configured box it should be configured other way around, as on the picture below. I have configured Default Web Site to listen on port 80 and Exchange Back End to listen on port 81.

After restarting the server I could successfully run EMS, it proved to be successful and I managed to connect to PowerShell and do normal admin works,

Finally on the other server EMS couldn't connect to the local server because World Wide Web Publishing Service and Windows Process Activation Service were not running. Attempts to start them wouldn't succeed. In the System Events log i would get errors 7001, 7023, 5005 and 5036.

Both of the services wouldn't start due invalid data. Investigation pointed me to this article and this advice. When I have accessed C:\Windows\System32\inetsrv\config I have discovered that the applicationHost.config file was empty that therefore consuming only 0 KB on the disk. I have renamed the file (optionally you can delete it). After this I went to the C:\inetpub\history folder which contains backups for the config and XML files that were recently changed. I have found the latest version of the file and copied it back to C:\Windows\System32\inetsrv\config . It made the magic and as a result after server restart World Wide Web Publishing Service and Windows Process Activation Service started successfully.

Executing EMS succeeded as the result.

I hope this helps you to spend less time on this issue comparing to the time I did.

Enjoy.

Extract Average Mailbox Size for Exchange 2013 Capacity Planning

Hi folks!

Currently I'm working on the planning of the capacity for new Exchange 2013 solution, namely upgrade from Exchange 2010. To plan server and storage capacity I'm using Exchange engineer's little helper, namely Exchange 2013 Role Requirement calculator. Recently Microsoft has published version 6.6 of it for Exchange 2013 which can be found and downloaded from here.

One of the new inputs that has been introduced Initial Mailbox Size (MB). It helps you to predict how soon will you reach the mailbox maximum size that you define in the Mailbox Size Limit (MB) input.

If you are building a brand new Exchange solution you will need to place value of 0 there. This will give you the following storage usage model by mailboxes for each mailbox tier which can be located on the Mailbox Space Modeling page of the calculator. In my case I set maximum size of the mailbox to be 25 GB (25600 MB) for each profile and the whole mailbox space would be filled within 60 months or 5 years.

However things change when you are upgrading the current Exchange 2007/2010 environment, as I do. In this case you will need to populate Initial Mailbox Size (MB) with the value of the average mailbox size in your current DAG to get more accurate prediction on when mailboxes that will be migrated to Exchange 2013 will reach their maximum size.

To achieve this I used yet one more Exchange engineers later helper, namely PowerShell. Of course your scenario can be different for mine. But let's imagine the scenario when you have DAG named DAG01 and DBs within this DAG are named DAG01-DB01, DAG01-DB02 and so on. Having such a contiguous naming convention will allow you to easily retrieve mailboxes from you databases that are part of your DAG.

So in my case I first create the variable which contains all mailboxes which reside in the mailbox databases within DAG. With naming convention like mine you can easily filter databases by using part of this name which common among all the databases:

 $MBXS = Get-Mailbox -ResultSize Unlimited |where-object {$_.Database -like "*DAG01*"}

To ensure that the variable has been properly populated you may output it to the screen or CSV file using Export-Csv cmdlet.

After this we need to execute Get-MailboxStatistics cmdlet against the mailboxes populated in the variable. The attribute that is interesting to us is TotalItemSize which gives us info about the size of the mailbox. We convert this value to the numeric value and the count the average value for all mailboxes by using Measure-Object cmdlet with -Average parameter. So the code for this looks something like:

$MBXS| Get-MailboxStatistics | %{$_.TotalItemSize.Value.ToMB()} | Measure-Object -Average

This should output the average number on the screen which you can then use in your role calculator.

This works fine when command is executed in the Exchange Management Shell locally on Exchange server. However, there may be a problem when this command executed from the local workstation that is talking to Exchange server via remote PowerShell. Instead of $_.TotalItemSize.Value.ToMB() you will be getting blank values. MS has advised the following workaround in their Technet Blog article. You will have to replace TotalItemSize.Value.ToMB() with @{name="TotalItemSize (MB)"; expression={[math]::Round(($_.TotalItemSize.ToString().Split("(")[1].Split(" ")[0].Replace(",","")/1MB),2)}} 

As a result it retrieves information to the screen like below

However it won't be able to retrieve average because the numeric value is actually string against which average can't be calculated. I would get screen as below:

To overcome this I extracted output into Excel spreadsheet as below:

 $MBXS| Get-MailboxStatistics | select DisplayName,@{name="TotalItemSize (MB)"; expression={[math]::Round(($_.TotalItemSize.ToString().Split("(")[1].Split(" ")[0].Replace(",","")/1MB),2)}} |Export-Csv DAG01-SizeReport.csv

And finally in Excel all you need is to calculate average mailbox size using good old AVERAGE function which gives us a value that we can use in the calculator for the Initial Mailbox Size (MB)

As a result we are getting more accurate prediction on how soon maximum mailbox size will be reached when we migrate from the existing Exchange solution to Exchange 2013.

I hope this will help you as it did help me.

Enjoy

Quick Bulk Mailbox-Enabling

Hi folks,

This is just a quick post for those of you who provision bulks of mailboxes on the regular basis. This scenario assumes that user accouts have already been created in the AD.

All you need to is to have TXT or CSV file with the UserId header. Underneath it you can publish one of these values to identify user accounts which can be wither of the below:

• GUID
• Distinguished name (DN)
• Display name
• Domain\Account
• User principal name (UPN)

As soon as the input file is ready you can import it into the pipe and enable mailboxes for each user ID in the file. And it's only one string as follows:


Import-Csv D:\Scripts\Users.txt| foreach {Enable-Mailbox -Identity $_.UserId}

Very helpful for lazy guys like me.

Enjoy.