Exchange Management Shell

All posts tagged Exchange Management Shell

In the previous blog we had a look how we could install a multi-role Exchange 2013 server via the command prompt. In this blog we will have a look at how to configure this Exchange 2013 environment.

We will start with configuring the accepted domains, the domains for which Exchange will accept e-mail. By default the Active Directory domain is added. If you have corp.local as Active Directory domain this will be added as authoritative accepted domain to Exchange:

Authoritative means that Exchange is the only mail server which is responsible for this domain. When a message is sent to a non-existing user Exchange will reply with an error message immediately.

Because in most cases the Active Directory domain is not the same as the mail domain we will first need to add it. This can be done by using the New-AcceptedDomain cmdlet, for example:

New-AcceptedDomain -DomainName -DomainType authoritative -Name

The parameter DomainName specifies the domain, DomainType will tell Exchange to configure it as an authoritative domain and with the last parameter name we specify the name of the domain this makes it easier to identity it in the GUI and Shell.

Next step is to add the domain to the default e-mail address policy or even create a new e-mail address policy. By default Exchange 2013 contains one e-mail address policy, the default address policy, which will be applied to all users to which no other e-mail address policy applies. This policy contains only the Active Directory domain. There are two options:

  • Add the new domain to the default address policy
  • Create a new e-mail address policy for the new domain

In this example we will use the 2nd option. Because this will ensure that only an e-mail address is added containing the mail domain and not one with the Active Directory as domain part.

To create a new e-mail address policy we will use the New-EmailAddressPolicy cmdlet:

New-EmailAddressPolicy -Name “” -IncludedRecipients MailboxUsers -ConditionalCompany “Johan Veldhuis” -EnabledEmailAddressTemplates “”

In this example we will create an e-mail address policy with the name This policy will be applied to all Mailbox users so not to contacts or mail-enabled users. We will add a filter using the ConditionalCompany. As last parameter we will specify the format of the e-mail address. In this case A complete overview of variables which can be used can be found here.

Now we have added the accepted domain and e-mail address policy it’s time to configure the internal and external URL’s.  In this example we will use the following URL’s:

  • for Outlook Web App and the Exchange Control Panel
  • for EWS, the Offline Address Book and ActiveSync

We don’t configure Outlook Anywhere we will discuss this in a future blog.

To configure the URL’s we will use several cmdlets:


Set-OwaVirtualDirectory -identity “EXCHANGE\owa (Default Web Site)” -InternalUrl -ExternalUrl


When running the cmdlet above you will receive a warning that you also must change the url of the ECP virtual directory.


Set-EcpVirtualDirectory -identity “EXCHANGE\ecp (Default Web Site)” -InternalUrl  -ExternalUrl


Set-WebServicesVirtualDirectory -identity “EXCHANGE\EWS (Default Web Site)” -InternalUrl -ExternalUrl


Set-OabVirtualDirectory -identity “EXCHANGE\OAB (Default Web Site)” -InternalUrl  -ExternalUrl


Set-ActiveSyncVirtualDirectory -identity “EXCHANGE\Microsoft-Server-ActiveSync (Default Web

Site)” -Internalurl  -Externalurl

As last step we will need to reconfigure the autodiscover URL. For those of you who are familiar with Exchange 2007 and higher this will be no surprise. For those who don’t Exchange will offer autodiscover functionality for auto configure Outlook/Entourage clients. By default a service connection point (SCP) is created. This SCP has the value in the following format http://serverfqdn/autodiscover/autodiscover.xml. Because this will create a single point of failure in a HA environment this has to be reconfigured. Although in our scenario we don’t have a HA environment yet we will reconfigure the autodiscover URL using the Set-ClientAccessServer cmdlet:

Set-ClientAccessServer –AutodiscoverInternalUri

Now all URL’s have been configured correctly it’s time to request a new certificate. This because Exchange 2013 has a self-signed certificate by default.

First we generate the CSR:

$newcert = New-ExchangeCertificate -GenerateRequest -SubjectName

“c=NL,o=Johan Veldhuis,” -DomainName “”,””  -PrivateKeyExportable $true

In the example above we will store the request in a variable called $newcert. Because we want to have the option to install this certificate on another server we also specify that we want to be able to export the certificate including the private key.

Once we stored the request in a variable we will store the content to a text file:

newcert | out-file c:\install\csr.txt

Now we have the file we can request the certificate. As soon as we have received the certificate from the CA we can install it on the Exchange 2013 server:

Import-ExchangeCertificate –FileData ([byte []]$(Get-Content –Path “c:\install\certificaat.cer” –Encoding Byte –ReadCount 0))

As final step we will need to assign the certificate to the Exchange services:

Get-ExchangeCertificate –ThumbPrint thumbprint| Enable-ExchangeCertificate –Services POP,IMAP,IIS,SMTP

In this example you will need to replace thumbprint by the thumbprint of the certificate we have installed. You can find the value of the thumbprint by running the following cmdlet:

Get-ExchangeCertificate|select Subject,Thumbprint

The certificate will be assigned to POP3, IMAP, all web services and SMTP.

When you assign the certificate to the services you will receive a warning that the current certificate is being replaced. Accept this warning so the certificate will be assigned correctly to the services.

Before we can create users we only need to perform one step, configure the send connector:

New-SendConnector -Internet -Name To_Internet -AddressSpaces *

Using the cmdlet adobe we will create a send connector which has as name To_Internet. All messages to other mail domains will be send via this connector.

Here ends the blog about how to configure Exchange via the Exchange Management Shell. In the next blog we will have a look at how to create the mailbox types and provide extra functionalities to users such as UM.

Both the Exchange Management Console (EMC) and Exchange Management Shell (EMS) are making a connection to Powershell using a remote session. During the session a connection will me made to the virtual directory Powershell which can be found in the IIS Management Console. This virtual directory can only be accessed by using port 80 by default.

To authenticate users Kerberos is used. During the Exchange setup a seperate dll has been installed.

In case of a remove and re-install of Exchange on another volume this may lead to problems. Of course this is a scenarion which you won’t see a lot.

After Exchange is completely re-installed on the new location you won’t be able to start the EMC anymore. In the event log you will see a lot of errors just like the one above.

Because IIS is used some configuration settings are stored in. These files can be found on the following location c:\windows\system32\inetsrv\config\ for example the applicationhost.config.

In the section globalmodules several modules such as the authentication methods, redirection and the other modules are listed here. This is done by refering to the dll which is required.

Because the kerbauth.dll is a native module this dll is also listed and the location specified is the Exchange installation directory. In some cases this rule is not deleted or updated and keeps pointing to the old location. The result: the DLL can’t be found.

The problem can be solved very easily by correcting the path and ensure that it points to the correct location. This can be done by using the variable ExchangeInstallPath (Exchange 2007 only).

For more troubleshooting tips you can visit the page below. Here you will find several issues and the solution for these issues.

Technet: Powershell Virtual Directory issue causes problems with EMS open

It has been a while ago that I published a tutorial. Today it’s time for a new one, this time about dynamic distribution groups, a new feature from Exchange 2007. In this tutorial I will explain how you can create a dynamic distribution group via the Exchange Management Console and Exchange Management Shell. Besides this I will describe somethings that you should keep in mind while creating them.


In Exchange 2003 you could use the Cleanup database to check the mailboxdatabase for mailboxes who were not assigned to users anymore. In Exchange 2007 you can do this via the Exchange Management Shell. The command that you need to use for this is clean-mailboxdatabase. This command will scan the Active Directory for mailboxes who are not assigned to users anymore but are not marked as this in the AD. When the status is not correct it will update the status directly.

Clean-MailboxDatabase Mailbox_db

The command above will scan de mailboxdatabase Mailbox_db, the only required parameter is the databasename. There are 2 other parameters who could be usefull:

  • Confirm, this parameter will ask the user for confirmation before really executing the command.
  • DomainController, with this parameter you can specify the domaincontroller which will be used as the source for the Active Directory database.