Exchange 2007 Install and Configuration from the command line (Part 2)

If you would like to read the other parts in this article series please go to:






In Part 1 of this series, I described the prerequisites required to install Exchange and then described the installation of Exchange and its verification. Now in Part 2, I will move on to describe some of the general configuration steps required to get the system operational.


Client Access and Hub Transport Configuration


Having completed the installation of Exchange 2007 in Part 1 the next step is to configure the server for use. All scripts are now run from the Exchange aware PowerShell version called the Exchange Management Shell or EMS.


License Key


The first step is to enter the license key details for each server. This is done using the script below which allows you to specify which Exchange server to apply the license key to by using the -Identity parameter.

#Enter the License Key
Set-ExchangeServer -Identity Exch2007 -ProductKey 12345-12345-12345-12345-12345
#Restart the Information Store Service
Restart-Service msexchangeis


Client Access and Hub Transport Server Role Preparation


Update DatabaseMaxCache setting in Transport service DB


Recently there was a recommendation made on the Exchange Team blog about changing the DatabaseMaxCache value of the Message Queue Database on Hub Transport servers. This involves editing text file C:\Program Files\Microsoft\Exchange Server\Bin\EdgeTransport.exe.config, and modifying the following line in the <appSettings> section:

<add key="DatabaseMaxCacheSize" value="134217728" />


To read:

<add key="DatabaseMaxCacheSize" value=" 536870912" />


This can be done using the script below:

(Get-Content "C:\Program Files\Microsoft\Exchange Server\Bin\EdgeTransport.exe.config") | Foreach-Object {$_ -replace "134217728", "536870912"} | Set-Content "C:\Program Files\Microsoft\Exchange Server\Bin\EdgeTransport.exe.config"
Restart-Service MSExchangeTransport


The script essentially loads the file into an array and then loops through until it finds the relevant content to replace. It then writes the changed content back to the file. No doubt there are more elegant ways to do this, but for now, this is the best I have come up with!


Global Client Access and Hub Transport Server Configuration


Routing Configuration for larger networks


As I have made clear, I am working in a one server environment however, it is worth mentioning here a crucial step for multi-site networks; routing setup. As part of the default installation a routing group connector is created between the Exchange 2003 routing group which hold the server specified during setup and the Exchange 2007 routing group. In larger organisations I would use a script as below to setup the other relevant connectors:

#Get the existing routing group connector created by setup and delete it
Get-RoutingGroupConnector | where {($_.sourceroutinggroup -eq "Exchange Routing Group (DWBGZMFD01QNBJR)") -or ($_.targetroutinggroup -eq "Exchange Routing Group (DWBGZMFD01QNBJR)")} | Remove-RoutingGroupConnector -Confirm:$false
#Create new routing group connectors
New-RoutingGroupConnector -Name "New York 2003-2007" -SourceTransportServers "” -TargetTransportServers "" -Bidirectional:$true -Cost 10
New-RoutingGroupConnector -Name "London 2003-2007" -SourceTransportServers "" -TargetTransportServers "" -Bidirectional:$true -Cost 10


The script first deletes the default connector and then replaces it with connectors named as per your naming convention which are bidirectional and have a cost of 10.


Set Message Tracking log retention amount


Back in our single server environment, there are a few global setting still to configure. First I set the maximum amount of message tracking logs to be kept to 10GB.

#Set amount of retained logs for Mailbox Servers
Get-MailboxServer | Set-MailboxServer -MessageTrackingLogMaxDirectorySize 10GB
#Set amount of retained logs for Transport Servers
Get-TransportServer | Set-TransportServer -MessageTrackingLogMaxDirectorySize 10GB


Set the maximum message size to 1GB


Next I configure the maximum message size which the Exchange organisation will accept. The script below sets the size to 50MB at the Global, Send and Receive Connector level.

#Set global message size restrictions
Set-TransportConfig -MaxSendSize 50MB -MaxReceiveSize 50MB
#Get all the receive connectors and set the maximum message size to 50MB
Get-ReceiveConnector | Set-ReceiveConnector -MaxMessageSize 50MB
#Get all the send connectors and set the maximum message size to 50MB
Get-SendConnector | Set-SendConnector -MaxMessageSize 50MB


For more information about message size restrictions see Marc’s article Exchange 2007 Message Size Limits.


Enable OOF to the Internet from both Exchange 2003 and Exchange 2007


Finally, I ensure that Exchange 2007 will allow both Outlook 2003 and Outlook 2007 clients to send Out of Office messages to the Internet using the script below:

#Get all the Remote Domain types (equal to the Internet Message formats from #Exchange 2003 and set the AllowedOOFType to ExternalLegacy which allows #both Outlook 2003 and 2007 clients to send OOF out
Get-RemoteDomain | Set-RemoteDomain -AllowedOOFType ExternalLegacy


Client Access Server Configuration


Having performed the global configuration tasks above, next I perform the steps below to set up specific settings on the Client Access server.


Generate, Install and Enable Certificate


As you will likely know, Exchange makes use of certificates to secure various means of access including Outlook Web Access. By default it uses a self signed certificate however, this almost always requires replacing with one generated either from an internal private certificate authority (CA) or from a public CA like VeriSign otherwise users end up being prompted that the certificate is not trusted. To do this I use the following commands:

#Create a request for a certificate
New-ExchangeCertificate -GenerateRequest:$True -SubjectName "c=US, o=Gaots," -DomainName,,  exch2007,, -FriendlyName ExchOWACert -PrivateKeyExportable:$True -Path C:\ExchOWACert.req


The above script generates a certificate request file which you would then be passed to either an internal CA or a 3rd party public one.


Once the CA returns the certificate the following scripts should be used to install and enable the certificate.

#Import the certificate and enable for services
Import-ExchangeCertificate -path c:\ExchOWACert.cer | Enable-ExchangeCertificate -Services "IIS,SMTP,POP,IMAP"


The above script first imports the certificate and then pipes the Thumbprint to the Enable command so that the certificate is enabled for relevant services. You should note that it may prompt you for a confirmation before enabling.


Configuring Client Access Virtual directories and Autodiscover


Having completed the installation of the certificate, the next step is to configure the virtual directories which provide access to Exchange. This is done using the script below:

# Configure Virtual Directories for the "Default Web Site"
Set-WebServicesVirtualDirectory -Identity Exch2007\"EWS (Default Web Site)" -InternalUrl -ExternalUrl
Set-OabVirtualDirectory -Identity Exch2007\"OAB (Default Web Site)" -InternalUrl -ExternalUrl -RequireSSL:$True
Set-UMVirtualDirectory -Identity Exch2007\"UnifiedMessaging (Default Web Site)" -InternalUrl -ExternalUrl
Set-OWAVirtualDirectory -Identity Exch2007\"OWA (Default Web Site)" -InternalURL -ExternalUrl -LogonFormat username -DefaultDomain
# Set URL for AutoDiscover
Set-ClientAccessServer -Identity Exch2007 -AutodiscoverServiceInternalURI -AutodiscoverSiteScope:$null
Set-AutoDiscoverVirtualDirectory -identity Exch2007\"Autodiscover (Default Web Site)" -InternalUrl -ExternalUrl
# Reset IIS


Having carried out the above steps your system is now ready to act as a Client Access server to provide access to Exchange.


For more information about understanding the wider issues surrounding certificates and Exchange see the article Securing an Exchange 2007 Client Access Server using a 3rd Party SAN Certificate.


Export the SSL Certificate to a second Client Access server


Before we move on to other areas, I thought it worth mentioning something which is only relevant if you have a pair (or more) Client Access servers which you will be using in a NLB configuration. In that case you will need the certificates on each server to match! First you must export the certificate from the first Client Access server which can be done using the script below:

#Export and copy to second server
Get-ExchangeCertificate | where {$ -eq "IMAP, POP, IIS, SMTP"} | export-exchangecertificate -path \\SecondServer\c$\OWAcas-cert.pfx -binaryencoded:$true -password:(Get-Credential).password


When you execute the command, it will prompt you to enter a password to secure the private key, and will then export the cert to the root of the C: on the second server.


On the Second Server you must then import the cert which can be done using the script below which will also prompt for the password entered above:

#Import and enable the certificate
Import-ExchangeCertificate -path c:\DCcas-cert.pfx -Password:(Get-Credential).password | Enable-ExchangeCertificate -Services "IIS,SMTP,POP,IMAP"


At this point you would configure the virtual directories as on the first server.


Outlook Anywhere


As I mentioned above we have setup the client access server, however one access method that most will be using is not yet available. That is Outlook Anywhere, formerly known as RPC over HTTP. Before enabling Outlook Anywhere, you must ensure that the RPC Proxy component is installed on the Client Access server. Also it is recommended to disable Kernel Mode Authentication when running the Client Access role on a Windows Server 2008 machine as otherwise if you use Outlook Anywhere with the NTLM authentication options users may be prompted repeatedly for login information. The script below disables Kernel Mode Authentication and then enabled Outlook Anywhere with Basic Authentication enabled and SSL Offloading disabled:

#Disable Kernel Mode Authentication for IIS7
C:\Windows\SysWOW64\inetsrv\AppCmd.exe set config /section:system.webServer/security/authentication/windowsAuthentication /useKernelMode:false
#Enable Outlook Anywhere with Basic Auth and SSL Offloading disabled
Enable-OutlookAnywhere -DefaultAuthenticationMethod:Basic -SSLOffloading:$false


Setup Relay connectors


The final configuration step I will take is to setup a client connector to allow relay from an internal application.


Although in this environment we only have a single server, if you have a farm of Hub servers which are load balanced, the relay setup should be performed on all Hub Transport servers.

#An example of a script to setup relaying for the Hub Transport servers
New-ReceiveConnector -Name “Internal SMTP Relay” -Usage Custom -Bindings, -Fqdn -RemoteIPRanges -Server Exch2007 –AuthMechanism TLS, ExternalAuthoritative –PermissionGroups ExchangeServers –MaxMessageSize 1GB


The script above allows the hub transport server to listen for relay on IP on both port 25 and port 587. Port 587 is configured in addition to port 25, as it is the default port for client to server SMTP traffic as opposed to server to server traffic which runs over port 25. The script then allows communications from only the server and sets the maximum message size to 1GB.




At this point, we have completed the basic steps needed to configure the client access server. I have tried not only to demonstrate the bare minimum, but also added configuration steps for some of the more common requirements which I have come across in the field. In the third and final part of this series, I will configure the mailbox server role and summarise some of the thought processes I use when approaching an Exchange server build.


If you would like to read the other parts in this article series please go to:




About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top