Wednesday, 30 September 2015

Collect exchange message tracking logs from multiple servers

It's a common scenario where an email didn't get to the recipient but there are many Exchange servers that could have been involved in the transport of the email. If you need to collect logs from all these Exchange servers then I've written a useful script.

This script will get all Exchange 2007/2010 Hub Transport and Exchange 2013 Mailbox servers in your organization and collect the logs. From there you can troubleshoot the message delivery.

$Start = "09/28/2015"
    $End = "09/29/2015"
    $HTServers = @()
    Get-ExchangeServer | ? { `
    ($_.AdminDisplayVersion.Major -eq "15" -and $_.ServerRole -match "Mailbox") -or `
    ($_.AdminDisplayVersion.Major -eq "8" -and $_.ServerRole -match "HubTransport") -or `
    ($_.AdminDisplayVersion.Major -eq "14" -and $_.ServerRole -match "HubTransport") `
    } | % {$HTServers += $_.Name}

    $emails = @()
    foreach($HTServer in $HTServers)
        {
            $emails += Get-MessageTrackingLog -Start $Start -End $End -ResultSize Unlimited -Server $HTServer
        }

The $emails array now includes message tracking logs from all Exchange servers which you can use for troubleshooting. See below:




Here we can see the issues delivering email on one of my test servers where it ran out of resources. 

Tuesday, 29 September 2015

Exchange 2013 - Install certificate (Part 1)

In this first part of a multi-part post, I'll do a run through on how to create a certificate request then import the certificate into Exchange. I'll break down the process to smaller steps and explain each step. 


Introduction

Exchange requires SSL certificates for each client access service. These include the below services:


  • Outlook Anywhere
  • Autodiscover
  • Offline Address Book
  • Exchange Web services
  • Outlook Web Access
  • Exchange Control Panel

An SSL certificate is also required for TLS which in itself is a topic for another post but I'll explain what you need on the certificate to prepare you for TLS. 


1 - Choose between self-signed vs Internal Certificate Authority vs Public Certificate Authority

Ok, so that's a long title. It's important to work out what type of certificate you require when you are configuring Exchange. This can prevent a lot of issues with Outlook prompting for credentials and sometimes being unable to connect at all. 

Self signed certificates are created by the local server and are not signed by any authority. The server is self-certifying it's identity - these certificates are therefore not trusted by clients.

Certificates issued by an internal Certificate Authority (CA) are certificates provided by a server on your network running Certificate Services. They are trusted by domain joined clients only.

Certificates issued by a public CA are trusted by all clients - domain joined and non-domain joined. 

See the below table for a comparison between the three types of certificate.


A certificate from a Public CA like Thawte, GoDaddy or Verisign is recommended although there is a cost to this. 


2 - Work out what Subject Names are required on your certificate

In our example, we have a simple setup of a single Exchange 2013 multi-role server (CAS and MBX).

  • Internal hostname: litex01.litwareinc.com
  • External hostname: mail.litwareinc.com (this is what clients will connect to for OWA and other services)

Exchange needs to use the certificate for a number of services. All of these services can be configured to use just two names on a certificate. 

The below services can use a single name of mail.litwareinc.com


  • Outlook Anywhere
  • Offline Address Book
  • Exchange Web services
  • Outlook Web Access
  • Exchange Control Panel

The last service is Autodiscover and this service needs to use a hostname of autodiscover.yourdomain.com, in our case: autodiscover.litwareinc.com. 

The two names we require on our certificate are therefore:

  • mail.litwareinc.com
  • autodiscover.litwareinc.com

You may be now asking the question "but what about the internal server name?" The answer to this is that it's not required on the certificate as we will configure the Autodiscover service not to use the internal name of the server. 

Note that if you are migrating from Exchange 2007 or 2010, you may need additional names on your certificate however this will need its own post. 

You can choose to use a Wildcard certificate if you want. These are useful as it would include all names under a particular domain, i.e. *.litwareinc.com which means you can use the same certificate for other services. It is however not as secure because it is not specifically requested. There can also be issues with some versions of Lync and older mobile devices which don't accept wildcard certificates. 

3 - Create a certificate request

This is possible using PowerShell or the Exchange Admin Center. We'll go through the steps for both approaches but you only need to choose one approach. For each approach, you need to use an administrative account that is a member of the Server Management Role Group which includes the "Exchange Server Certificates" role. 

Using Exchange Admin Center:

1) Log into https://litex01.litwareinc.com/ecp 

Note the address bar is red - this is because the default certificate is self signed and therefore not trusted by the client I'm using.




2) Click on Servers then click on Certificates

Note that here you can see the self-signed certificates that Exchange creates when the server is installed. 




3) Select the correct server from the drop down then click Add +




4) Select "Create a request for a certificate from a certification authority" and click next



5) Enter a friendly name for the certificate then click next

This can be any name - it is not used by clients but may be visible if the user clicks on the certificate in the address bar in Internet Explorer to view more details. 

In our case, we'll set a friendly name of "Litwareinc Exchange"



6) Here you get the option to request a wildcard certificate. In our case, we don't want this so will click next. 



7) Select a server to store the certificate request on then click next



8) On this next step, the wizard asks for a domain name for each Exchange service. 

In our case, we will set everything to use mail.litwareinc.com and autodiscover to use autodiscover.litwareinc.com.



9) In the next screen, we can see a list of the unique domain names that we have entered.

We see litwareinc.com listed. We don't require this name but Exchange adds it in automatically so we'll remove it to leave just the two we require. 



10) Specify information about your company then click next

For this fictional company in my test lab, it is based in Hong Kong, China



11) Specify a location to save the certificate request then click finish



12) The certificate is now a pending request as per the screenshot below. The next step will be to request the certificate from the Public CA you choose. Each CA has different instructions on how to do this. 



13) Once your CA has issued the certificate, you should be able to download a .cer file. Click on Complete as per the screenshot above then enter the path to the .cer file you received then click ok.



14) You should now see your new certificate listed.




Using PowerShell:

1) Open up the Exchange Management Shell and run the below command:

Set-Content -Path "C:\temp\certreq.req" -Value (New-ExchangeCertificate -GenerateRequest -SubjectName "c=HK, o=Litwareinc, cn=mail.litwareinc.com" -DomainName mail.litwareinc.com,autodiscover.litwareinc.com -PrivateKeyExportable $True -FriendlyName "Litwareinc Exchange")



In the above script, we've set the certificate request file path to be c:\temp\certreq.req. Yes, that is correct - we've just done 11 pages of a Wizard in a single line of PowerShell! Now you know why I prefer to use PowerShell.

2) Confirm the contents of C:\temp\certreq.req by running the below command or using notepad to open the file

Get-Content C:\temp\certreq.req



3) Request the certificate from your CA - download the .cer file to your Exchange server. Again, see instructions from your CA.

4) Import the certificate back into Exchange. Use the below command to import your .cer file:

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\temp\litex01.litwareinc.com.cer -Encoding byte -ReadCount 0))



5) Confirm that the certificate has been installed properly by running the below command

Get-ExchangeCertificate | fl FriendlyName,Subject,NotBefore,NotAfter,Status,Services




Conclusion

In part 1, we've discussed the requirements for Exchange certificates and also demonstrated how to create a certificate request and complete it using both the Exchange Admin Center and PowerShell. In part 2, we'll configure Exchange to use the new certificate.

Monday, 28 September 2015

Exchange 2013 - A Restart from a Previous Installation is Pending

Sometimes when installing Exchange, you get an issue where it reports "A Restart from a Previous Installation is Pending". In this case, usually a restart fixes the issue but sometimes you can restart all you want and Exchange still needs a restart. This can happen with Exchange 2010 and 2013 installs.

The issue is that the Exchange install looks at certain registry keys and if it finds a value, it reports this issue. 

The most common registry key is the PendingFileRenameOperations key which can be found at the below location:


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOpearations


To resolve the issue, open up regedit, browse to the location and delete the value for the key. Double click on PendingFileRenameOperations on the right, delete the value then click ok. 





Once you've done this, you can continue the install of Exchange, however, you may find that it still fails. In this case, you should look for the next registry key which is the UpdateExeVolatile key and can be found in the path below:


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\UpdateExeVolatile


This key needs to either be set to a value of 0 or deleted. 

More information can be found here: https://technet.microsoft.com/en-us/library/cc164360%28v=exchg.80%29.aspx

Friday, 25 September 2015

Exchange 2013 install - Mailbox role install stuck at 98%, cannot start transport service

This is an issue I've seen before when installing Exchange in a child domain. The problem was that the mailbox role fails the install at 98% as it cannot start the transport service. 

If you try to start this service, it starts then stops and you see the below error in the event log:


The worker process crashes continuously on startup: c:\Program Files\Microsoft\Exchange Server\V15\Bin\edgetransport.exe. The service will be stopped.





To resolve this problem, you'll need to go back and ensure that you have run the AD preparation tasks correctly using accounts with the right permissions and that each command was run on computers in the correct site and domain. These are tasks are listed below:

1) Prepare Schema
2) Prepare Active Directory
3) Prepare Active Directory Domains

See my recent post on how to do this here.

Thursday, 24 September 2015

Exchange 2013 Install - An error occurred with error code '3221684226' and message 'The system cannot find the file specified.'

During the Organization Preparation stage of an Exchange 2013 install or uninstall, you may get the below error message:

An error occurred with error code '3221684226' and message 'The system cannot find the file specified.'



This error message is not very descriptive but the issue is that the AD tools are not installed on the Exchange server. 

To install these, run the below command in an elevated PowerShell window:

Install-WindowsFeature RSAT-ADDS


Once done, you can re-run your install or uninstall operation.



Wednesday, 23 September 2015

Install Exchange 2013 CU10 in a child domain - Part 2

In part 1 of this two part article, we looked at how to prepare the AD forest and domains for Exchange 2013. In this part, I'll demonstrate how to install Exchange in our selected child domain.

Introduction

We've already gone through the AD preparation tasks in part 1. These are:

1) Prepare Schema
2) Prepare Active Directory
3) Prepare Active Directory Domains

AD is now ready for the first install of Exchange. If you remember back to the last part, our forest has a root domain of contoso.com and two child domains: uk.contoso.com and us.contoso.com. We'll be installing Exchange in uk.contoso.com

Preparation

Before we go ahead and install Exchange, we need to go through a few tasks.

1) Sizing. 

To ensure that we size up Exchange correctly, we should analyse our current infrastructure and use the Exchange sizing guidance to work out how much RAM/CPU each Exchange server requires. If you're virtualizing your Exchange servers, you can always add RAM, vCPU and disks to your VMs after you first install them.

2) System Requirements. 

Check that the system you are going to be installing on meets the System Requirements.

3) Release Notes. 

Often this is missed out but is usually quite useful. Always ensure that you read the Release Notes as there is useful information which can prevent problems down the line. 

4) Windows Updates

Ensure that the server you will be installing Exchange on has the latest Windows Updates.

5) Join to domain

Join the server to the domain in which you will be installing Exchange.

6) Add storage

Add additional disks for storage as required. In our case, we will add a single disk to be used for the mailbox database and log files for simplicity. This is the E drive in our case.

Installation

Once you've gone through the preparation steps above, it's now time to install Exchange. 

The recommendation from Microsoft is to install multi-role servers, i.e. servers that run both the CAS and MBX roles. If you do have a requirement to install separate roles, for example the requirement to use NLB then install the mailbox role first.

1) Assign correct permissions

For the first Exchange server in the organization, the user that performing the install must be a member of the Enterprise Admins group, assuming that the Schema has already been prepared as per part 1. If you haven't already prepared the Schema then you also need to be a member of the Schema Admins group. 

If you're not installing the first Exchange server in the organization then you don't need to be an Enterprise Admin or Schema Admin but you do need to be a member of Organization Management role group.

In our case, we've added the the Domain Admin account of the uk.contoso.com domain, to the Enterprise Admins group. This account is UK\Administrator in our case.

We'll then go on to install the pre-requisites for Exchange in step 2. 

2) Install .Net 4.5.2 from here. Accept the license terms and click install:





3) If you are not using Server 2012 R2 then you also need to install the Windows Management Framework 4.0. In our case we are using Server 2012 R2 so this is not required.

4) Install the Unified Messaging Communications Managed API 4.0 Runtime.







5) Install the required Windows features

Use the below command to install the required Windows features. This command needs to be run on a single line and run from a PowerShell window with elevated privileges. 

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation,RSAT-ADDS





The AD tools are included in the above command - this prevents issues with AD operations and the EXSetup program.

6) Download Exchange 2013 CU10 from here or the latest Exchange CU. The Cumulative Update includes the entire Exchange package. There is no need to install Exchange then install the CU. 






7) Once downloaded, double click to extract Exchange. 


Select a location to extract the files to. In this demo, we're extracting to C:\temp\Exchange2013-x64-cu10.






8) Run Setup

We'll be installing Exchange from the command line. Open up a elevated command prompt and change directory to where you extracted the files as per step 7.

We're going to install both the mailbox and client access roles together. We're also specifying our Exchange Organization name, Contoso. By default, Exchange will install a mailbox database with the mailbox role and this is installed in the installation path for Exchange but in our case, we'll specify the mailbox database name, edb file path and log file path. In summary:

Roles to install: Mailbox and Client Access
Organization Name: Contoso
Mailbox database name: UKMDB01
Database file path: "E:\Program Files\Microsoft\Exchange Server\V15\Mailbox\UKMDB01\UKMDB01.edb"
Log folder path: "E:\Program Files\Microsoft\Exchange Server\V15\Mailbox\UKMDB01"

To install with the above configuration, run the below command on a single line:

setup.exe /Mode:Install /Roles:mb,ca /IAcceptExchangeServerLicenseTerms  /OrganizationName:Contoso /MdbName:UKMDB01 /DbFilePath:"E:\Program Files\Microsoft\Exchange Server\V15\Mailbox\UKMDB01\UKMDB01.edb" /LogFolderPath:"E:\Program Files\Microsoft\Exchange Server\V15\Mailbox\UKMDB01"




The /MdbName, /DbFilePath and /LogFolderPath settings are optional and you can omit these if you prefer. Exchange will create a default mailbox database in the Exchange installation path which is on the system drive by default.

9) Confirm the installation was successful

To do this, run the command below. This will list all the Exchange servers, their roles and version. Check that your new Exchange server is listed with all the required roles.

Get-ExchangeServer | ft -AutoSize





Also, review the setup log for any issues. This log file is C:\ExchangeSetupLogs\ExchangeSetup.log. 


Conclusion

In part 1, we went through the steps required to prepare the Active Directory forest and domains for an Exchange 2013 install. In this second part, we've gone through the steps required to install the first Exchange 2013 server in a forest and this was installed in a child domain. 

In upcoming posts, I'll walk through how configure Exchange - including autodiscover and mail routing configuration etc.

Tuesday, 22 September 2015

Install Exchange 2013 CU10 in a child domain - Part 1

In this post, I'll demonstrate how to install the first Exchange 2013 server on Server 2012 R2 in a child domain. This will be the first Exchange server in the forest.

Introduction

First, we'll look at the AD logical structure which is already in place. We start off with the AD forest contoso.com. The root domain is contoso.com and two child domains are uk.contoso.com and us.contoso.com. Below is a screenshot of the AD Domains and Trusts snap in.



We're using Server 2012 R2 on all domain controllers. The forest functional level and all domain functional levels are Server 2012 R2. To install Exchange 2013, you need at least a forest functional level of Server 2003 and a Schema master running Server 2003 SP2.

The list of domain controllers is below:



The physical topology is as below:



We will be installing a multi-role Exchange 2013 CU10 server in the uk.contoso.com domain.

Preparation of Active Directory - Overview

Exchange stores all configuration in AD and the AD schema needs to be extended to support these new features and objects. Once done, AD needs to be prepared for Exchange and then the required domains need preparation. The steps are below:

1) Prepare Schema
2) Prepare Active Directory
3) Prepare Active Directory Domains

We'll take each one in turn and go through the required steps.

Prepare Schema

The first step in installing Exchange is to prepare Active Directory which means we will be extending the AD schema to support new features. More information about the schema changes can be found here. Make sure you take a backup of your domain controllers before making these changes to AD.

To prepare the schema, select a computer that is in the same AD site and domain as the Schema master. If you are unsure which domain controller is the schema master, use the command: 

netdom query fsmo




Here we can see that contdc01.contoso.com is the Schema master so we'll select this server to be the machine we use to extend the AD schema and prepare AD. 

Below are the steps required to install the pre-requisites on the machine that will be used to prepare AD then to prepare AD.

1)  Install .Net 4.5.2 from here. Accept the license terms and click install:








Restart the computer when prompted.

2) If you are not using Server 2012 R2 then you also need to install the Windows Management Framework 4.0. In our case we are using Server 2012 R2 so this is not required.

3) If you don't already have the AD tools installed on the computer, you also need to install them. Do this by running the command in an elevated PowerShell window: 

Install-WindowsFeature RSAT-ADDS






4) Ensure that the account you are logged in as on the machine you'll use to prepare AD is a member of the Schema Admins and Enterprise Admins groups in AD. Note that if you are logged in and you add yourself to the required groups, you'll need to log off and on again. Also, beware that AD replication may take time if you've modified your group membership on a domain controller in a different site. The command below which will show you which groups you are currently a member of:

whoami /groups


5) Download Exchange 2013 CU10 from here. The Cumulative Update includes the entire Exchange package. There is no need to install Exchange then install the CU. 



6) Once downloaded, double click to extract Exchange. 


Select a location to extract the files to. In this demo, we're extracting to C:\temp\Exchange2013-x64-cu10.





7) Extend Active Directory schema by running the below command from the directory where you extracted the files to. in our case this is C:\temp\Exchange2013-x64-cu10

Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms



Check that all steps have completed as above before moving on to preparing AD. Also, give AD time to replicate the schema changes throughout the forest. The time this takes will depend on your replication topology, site topology and the size of your forest. 

8) To confirm that the Schema has been updated on all domain controllers, run the below script by modifying the list of domain controllers then pasting into your PowerShell window:


$DomainControllers = "contusdc01.us.contoso.com","contukdc01.uk.contoso.com","contdc01.contoso.com","contdc02.contoso.com"



$DomainControllers | % {

Write-Host $_ -ForegroundColor Green
Write-Host "Range Upper:" 


$query = "LDAP://" + $_ + "/cn=ms-Exch-Schema-Version-Pt,cn=schema,cn=configuration,dc=contoso,dc=com"

([ADSI]$query).RangeUpper

}


This will output the rangeUpper value of the ms-Exch-Schema-Version-Pt container in the Schema naming context which Exchange has created. For CU10, this should be 15312.

Below we can see that all domain controllers have the correct value for rangeUpper which means that the schema has been replicated:



Prepare Active Directory

The next step involves preparing AD. You need to be a member of the Enterprise Admins group for this step.

Select a computer which is in the same domain and site as the schema master and which can connect to all the domains in the forest on port 389. In our case, we'll continue using contdc01. 

1) Select a name for the Exchange organization. This name is not seen by end users but ensure that you meet the below requirements:


  • You can use any uppercase or lowercase letters from A to Z.
  • You can use numbers 0 to 9.
  • The name can contain spaces as long as they're not at the beginning or end of the name.
  • You can use a hyphen or dash in the name.
  • The name can be up to 64 characters but can't be blank.
  • The name can't be changed after it's set.
We'll use the organization name Contoso.

2) Run the below command to prepare AD. This command is to be run on a single line. Ensure that you replace Contoso with your organization name.



Setup.exe /PrepareAD /OrganizationName:"Contoso" /IAcceptExchangeServerLicenseTerms




Ensure that you allow time for AD to replicate these changes. You should see a new Organizational Unit in AD in the root domain:



Prepare Active Directory Domains

Now that we have extended the schema and prepared the forest, we need to prepare each domain that will have mail enabled users or Exchange installed. Again, you need to be a member of the Enterprise Administrators group for this task but you also need to be a member of the Domain Admins group in the domain you are preparing.

The account you will be using for this step needs to be a member of the below groups:

1) Enterprise Admins
2) Domain Admins in the domain you will be preparing
3) Organization Management

This will cover you for all required permissions should the domain have been created before or after PrepareAD was run. 

Here we have the option of preparing all domains in the forest or only domains that we specify. 

To prepare all domains, run the below command (note the /PrepareAllDomains switch):

Setup.exe /PrepareAllDomains /IAcceptExchangeServerLicenseTerms

In our case, we only want to prepare the uk.contoso.com domain so we need to run the below command. Ensure that you replace uk.contoso.com with your domain name.

Setup.exe /PrepareDomain:uk.contoso.com /IAcceptExchangeServerLicenseTerms



Your AD preparation is now complete.

Conclusion

We've now configured AD for Exchange. The schema has been extended to support the Exchange configuration and new objects and the required domains have been prepared for an Exchange installation. 

In part 2, I'll demonstrate how to install Exchange in the child domain.