Exchange 2013

All posts tagged Exchange 2013

 By using federated sharing it is possible to exchange free/busy informative between different Exchange organizations. This can be done by using the Microsoft Federation Gateway (MSFG) when no direct trust exists between the Active Directories. The MSFG is in this case responsible for providing a ticket which is used for authentication. By using a ticket a CAS can contact the CAS from the other organization to retrieve the free/busy information.

To use this feature several things will need to be configured:

  • trust with the Microsoft Federation Gateway
  • organizational relationship must be configured
  • autodiscover and EWS must allow WS Security authentication
  • the reverse proxy needs to allow unauthenticated traffic to the following url’s:
    • /EWS/exchange.asmx/WSSecurity
    • /autodiscover/autodiscover.svc/WSSecurity
    • /autodiscover/autodiscover.svc

Several sites contain a step-by-step plan on how to configured this. An overview of those sites can be found on the end of this article.

When you setup these things everything should work, indeed should. In most cases it will work but in some cases you will need to perform some troubleshooting. In this serie of blogs we will have a look how you can validate that it works and perform some troubleshooting in case something doesn’t work.

But how can you troubleshoot these issues? First of all it is very useful if you have a contact person who has access to the other Exchange organization. In most cases this isn’t a big issue but when using Office 365 or another form of hosting this can be very hard sometimes.

To start the troubleshooting process you mostly would like to verify your own Exchange organization first. Things that could be checked are:

  • verify if autodiscover allows WS Security for authentication
  • verify the external EWS url
  • verify if Exchange Web Services will allow WS Security for authentication

If your Exchange organization contains multiple CAS then Powershell is your friend and you can use several cmdlets to verify the steps above:

Get-AutodiscoverVirtualDirectory|select server, WSSecurityAuthentication

Get-AutodiscoverVirtualDirectory

You will get an output like above. Verify if the value of the column WSSecurityAuthentication is set to true

If WSSecurity is not true then use the following cmdlet to enable it:

Get-AutodiscoverVirtualDirectory|Set-AutodiscoverVirtualDirectory -WSSecurityAuthentication:$true

Using this cmdlet the authentication method will be configured but to offer this authentication type you will need to perform an IISReset. Additional you can verify if the svc-integrated handler is attached to the autodiscover virtual directory:

IIS

Next step is to verify the Exchange Web Services, this can be done by using the Get-WebServicesVirtualDirectory cmdlet:

Get-WebServicesVirtualDirectory|select server, ExternalUrl, WSSecurityAuthenticationcmdle

Get-WebServicesVirtualDirectory

Again the same rule apples WSSecurityAuthentication needs to be set to true. Besides this the ExternalUrl needs to contains a valid value. This url needs to accessible from the internet. If this is not the case it simply won’t work.

In case that WSSecurity is not true enabled it by using the following cmdlet:

Get-WebServicesVirtualDirectory|Set-WebServicesVirtualDirectory -WSSecurityAuthentication:$true

The same applies for EWS as it did for autodiscover perform an IISReset to activate the authentication method. Besides this verify if the ws-security handler is attached to the EWS virtual directory.

If no external url is configured you will need to configure one. Before you do this make sure the certificate contains all the correct names. If you will configure a value but it is not part of your certificate you will get errors.

To verify if the certificate contains the correct names we will use Powershell again:

Get-ExchangeCertificate|? {$_.Services -like “*IIS*”}|select Subject, CertificateDomains|FL

Verify if the CertificateDomains contain the FQDN you are planning to use for EWS, for example mail.domain.com of ews.domain.com. If this name is not on the certificate you will need to renew your certificate.

If the certificate contains the name for the external URL then you can continue configuring it:

Get-WebServicerVirtualDirectory|Set-WebServicesVirtualDirectory -Externalurl “https://ews.domain.com/EWS/exchange.asmx”

Using the cmdlet above the external URL on all Client Access Servers will be configured the same. REMARK: in some scenarios this is not what you want. Please verify if this is the case in your scenario before configuring the external url.

When this has been configured and validated it is time to verify the Federation Trust and the Organization Relationship.

This can be done by starting with Test-FederationTrustCertificate which will verify if the certificate used for the trust is correct and is installed on all CAS. During the creation of the trust the self-signed certificate will normally be distributed to all CAS in your environment. But in some cases this may not happen. If this is the case the CAS will be unable to authenticate against the Federation Gateway of Microsoft which will eventually result the autodiscover process to fail.

Test-FederationTrustCertificate

Test-FederationTrustCertificate

Verify that the State column for all CAS contain the value installed.

Additionally you can run the Test-FederationTrust cmdlet to verify if the Federation Trust really works. By default this cmdlet will use the extest account:

Test-FederationTrust

If you don’t have an extest account or you would like to use another user add the UserIdentity parameter:

Test-FederationTrust -UserIdentity user@domain.com

This cmdlet will perform several tests and will output the results on the screen, verify if no errors did occur.

As final step of the process you can verify the Organization Relationship. This is only applicable if the other organization has issues when looking up the free/busy information for your mailboxes. By using an organization relationship you will give the other organization permission to retrieve free/busy information of your organization. If not all domains are listed here it can cause strange issues such as it works for domain A but not for domain B while they are located in the same Exchange environment.

To troubleshoot these kind of issues you can use two cmdlets:

  • Get-OrganizationRelationShip,  retrieves the current configuration
  • GetFederationInformation, will send an autodiscover request to the other organization to retrieve the configuration

The following parameters are important in this case:

  • DomainNames
  • TargetApplicationUri
  • TargetAutoDiscoverEpr

One remark must be made about the DomainNames parameter. In some cases this parameter doesn’t have to be the same for both cmdlets. Some organizations only want to share free/busy information with a specific domain and not all domains hosted by the other Exchange organization.

In this part of the series we did have a look which configuration items you will need to verify in your Exchange organization. Besides this we did had a look on how to fix them if they are configured incorrectly.

In the second part we will have a closer look at the reverse proxy and client part of troubleshooting.

Below are some pages which contain use full information about federated sharing:

Office 365 Community: How to configure TMG for Office 365: open
TechNet: How does Federated Calendar sharing work in Exchange 2010?: open
TechNet: Exchange 2013: Sharing: open

Using OWA and Internet Explorer 11

Now Windows 8.1 RTM is available via Technet and MSDN it is installed by several ITpro’s. And then it is just a matter of time befor someone finds  an issue. This because the code of Exchange doesnt recognize Internet Explorer 11 correctly and this will result in OWA to be displayed in light mode. As you may know OWA light doesn’t connect all the options which are available in the full blown OWA. Microsoft will probably fix this in a future update so you can use Internet Explorer 11 in full blown mode. This is confirmed by something I discovered when using Office 365. It looks like my tenant is already upgraded because Interne Explorer 11 works OK for me. The on-premise environments will need to wait till Microsoft releases an update which contains the correct code to recognize Internet Explorer 11.

20130821-172919.jpg

A few weeks ago the Exchange 2013 version of the Powershell Cookbook was published by Packt Publishing. This version also introduced a additional writer for the book: Jonas Andersson. A frequent Exchange blogger with quality articles so before I started reading I was convinced the book should be from high quality also. The second writer is the one who was also responsible for the first part Mike Pfeiffer. Those who missed the first part and are working with Exchange 2010, please read the book it contains very usefull info.

Enough about the writers and the first part . Let’s start reviewing the secondary part which is mostly decicated to Exchange 2013. The book starts from the beginning so if you are not familiar with Powershell the book will introduce how Powershell will work and you can benefit from it. And trust me I also found some nice tips for future use my scripts although I use Powershell almost every deployment.

Once the writers discus some basics which you really want to know they describe the abilities Powershell will give your per part of Exchange. For example they discuss which Powdershell cmdlets you can use for managing the Exchange Transport part. Per Exchange part a very clear description is given including some really nice examples.

As last and bonus part the writers describe how you can use EWS via Powershell which extends Powershell again. For those who are familiar with basic Powershell this is a must read chapter.

So what’s my conclusion about the book: a really nice book both for Exchange Powershell starters but also for people that are more experienced with Powershell for Exchange.

You can buy the book via the site below:

Packt Publishing

The Exchange Virtual Conference

Colleague Exchange MVP and The UC Architects member Paul Cunningham launched the idea to organize an Exchange Virtual Conference in January 2013. He asked several people who are active in the Exchange community to attend this conference among them me.

The last couple of months I have been pretty busy to get my presentation ready and to record the sessions. All the presentations are prerecorded and starting from yesterday every day a presentation will be available

Besides me the following speakers attend the conference:

  • JP Bruzzese
  • Serkan Varoglu
  • Jaap Wesselius
  • Michael van Hoorenbeeck
  • Paul Cunningham

The topics discussed are both Exchange 2013 and Office 365, although most of the presentations do focus more on Exchange 2013

Below an overview of the presentations:

The sessions are available via the links above but you can also take a look yourself at the site www.exchangevirtualconference.com.

Remark: not all sessions are available, as soon as a session is available I will update the list above.

One of the most important subjects in an Exchange design is the correct sizing ofthe enviroment. Microsoft has defined several guidelines which need to be used which are described on TechNet. Since today the Server Role Requirements Calculator has been added.

Exchange 2013 Server role requirements calculator

The first thing which had changed is the name, no it is not incorrect, you can also size the CAS role with it. In Exchange 2010 the Mailbox Role calculator was available to size your Mailbox server. But the new tool can be used to size both your CAS and Mailbox servers.

One remark must be made the tool can only be used to size an Exchange 2013 environment. For Exchange 2010 you will need to continue to use the Mailbox calculator.

If you would like to use the new calculator you can download it via the link below:

download

In the first part of this blog we looked at the theory and some examples. In this blog we will continue with configuring and managin the DAG.

In this case we have an environment which consists out of two multirole Exchange 2013 servers. Because this is not an odd amount we will need to use a file share witness. Ideally this fileshare witness is placed on another Exchange server (for example your CAS) but it can also be located on an generic server.

First step is to prepare our FSW. It is important the Exchange Trusted Subsystem is a member of the local administrators group of the server. This because Exchange uses this account under the hood to perform the needed actions.

If the server doesn’t contain the File Server feature add it by using the following Powershell cmdlet:

Add-WindowsFeature FS-FileServer

Once these actions have been performed we can continue with configuring our DAG.

If you are familiar with DAG’s from Exchange 2010 pay attention to the next step. You will need to pre-stage the Cluster Name Object (CNO). Open ADUC and create a computeraccount which matches the name you want to give to the DAG, for example DAG01. After creating the object disable the account and get the properties of the object. Select the security tab and add the computeraccount of the computer which will be the first member of the DAG. Repeat this last step for the Exchange Trusted Subsystem security group.

Of course you can also script the creation of this object. Fellow The UC Architects member Michel de Rooij has created a script which can be found here.

Next step is to create the DAG, we will use the Exchange Management Shell for this:

New-DatabaseAvailabilityGroup -Name Exchange_DAG01 -WitnessServer FS01 -WitnessDirectory C:\Exchange_DAG01  -DatabaseAvailabilityGroupIpAddresses 192.168.1.90

By using the cmdlet above we will create a DAG which has the name DAG01 and assign FS01 as the witness server. On the FS01 a directory will be created called Exchange_DAG01. As last step we will assign an IP address to the DAG 192.168.1.90.

Now we have created the DAG it’s time to add the mailbox servers to it. This can be done by using the Add-DatabaseAvailabilityGroupServer cmdlet:

Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer EX01

Remark: If the Windows Failover Clustering components are missing the cmdlet will install then automatically. Keep in mind that this might require a restart of your Exchange Server. The cmdlet will in that case only install the components and will not add the server to the DAG. So if the server is rebooted run the cmdlet again to add the server to the DAG. However it may not be required to reboot the server in that case the server will be added to the DAG directly.

Add-DatabaseAvailabilityGroupServer

Once the first server is completed repeat the same step for the other server:

Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer EX02

To finish the configuration of the DAG we will need to add the additional copies of the databases. For adding a copy you will need to use the Add-MailboxDatabaseCopy cmdlet:

Add-MailboxDatabaseCopy -Identity MBDB01 -MailboxServer EX02 -ActivationPreference 2

Add-MailboxDatabaseCopy

After the copy is added you will need to restart the Microsoft Exchange Information Store service on the target server. This has to do with the “Managed Store” as introduced in Exchange 2013. Collegue Exchange MVP Tony Redmond published a nice blog. So if you want to know the indept details I recommend to visit this page.

This will add a copy of the database called MBDB01 to mailboxserver EX02 and will set the activation preference to 2.

Repeat the step for the database hosted by EX02:

Add-MailboxDatabaseCopy -Identity MBDB02 -MailboxServer EX01 -ActivationPreference 2

Once the cmdlets have been ran you can use the Get-MailboxDatabaseCopyStatus cmdlet to verify the status of the databases and its copies:

Get-MailboxDatabaseCopyStatus

In the example above the first copy is mounted and the content index state is healthy. However for the second copy of the database the content index is FailedAndSuspended. In case of a *over this results in users who will start to have issues when searching their mailbox.

To fix this issue we need to run the Update-MailboxDatabaseCopy cmdlet like this:

Update-MailboxDatabaseCopy -Identity MBDB01\EX02 –CatalogOnly

After the confirmation the catalog will be updated on the second copy:

Add-MailboxDatabaseCopy

Let’s look at another issue:

Get-MailboxDatabaseCopyStatus

In this case the second copy failed completely so we do have to update both the database and the catalog:

Update-MailboxDatabaseCopy -Identity MBDB02\EX01

Update-MailboxDatabaseCopy

After confirming the reseed is performed and both the database and catalog should be healthy again.

If we want to perform maintenance on the DAG members we will need to put the member in maintenance mode. This can be done by using the StartDagServerMaintenance script which can be found in the default script directory of Exchange.

StartDagServerMaintenance

By adding the Server parameter we can specify a server which we would like to put in maintenance. Once this is done it will check if the PAM role and which databases are currently activated on the server and will try to move them to another DAG member.

Once we have performed some maintenance on EX02 we will need to take it back in production. This can be done by using the StopDagServerMaintenance script:

.\StopDagServerMaitenance.ps 1 –Server EX02

Once this script has been executed verify if the databases are healthy using the Get-MailboxDatabaseCopyStatus cmdlet. The script will not re-balance the databases so we will need to do this manually. To move the active database we need to run the Move-ActiveDatabase cmdlet:

Move-ActiveMailboxDatabase MBDB02 –ActivateOnServer EX02

Move-ActiveMailboxDatabase

After confirming the activation on the other server the database will be moved to EX02.

Here ends the second part of the Exchange Alphabet about Database Availability Groups. In this part we had a look how to create a DAG and perform several operations

Exchange 2013: e-Discovery tasks stay queued

During some testing in a lab environment which contained Exchange 2010 SP3 and Exchange 2013 I found a strange issue. The e-discovery tasks all got stuck in the queue.

Let’s start with some background information. Since Exchange 2010 SP3 and Exchange 2013 CU1 it’s possible to install an Exchange 2013 server in an Exchange 2010 environment. This will give you the ability to migrate from Exchange 2010 to Exchange 2013. Before doing this it is recommended to perform some testing in a test environment.

The e-discovery functionality can be used to search for messages with for example specific keywords in specific or all mailboxes in an Exchange environment. Back to the issue.

After testing the same functionality on the Exchange 2010 SP3 server I found out that it worked correctly on that side. After some research the solution was pretty easy. As you might know Exchange contains a few special mailboxes. These mailboxes can’t be seen in the GUI and can only be found using the Get-Mailbox cmdlet and using the -arbitration option.

get-mailbox -arbitration

When you have implemented Exchange 2013 in your current Exchange 2010 environment it is important to move the mailbox SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9} to a database hosted on an Exchange 2013 mailbox server.

The mailbox can be moved by using the New-Moverequest cmdlet:

New-MoveRequest SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}  -TargetDatabase dbname

Once the move request has migtrated the mailbox it might be necessary to restart the search. When looking at the status of the e-discovery now you will see that it proceeds and finally gets the status completed:

get-mailboxsearch

In the Technet documentation you will find a small description about this functionality. Using the e-discovery functionality in a coexistence scenario it is important to know that the mailbox search created on the Exchange 2013 environment can only be used to search Exchange 2013 mailboxes. If you would like to search the Exchange 2010 mailboxes you will need to perform a seperate e-discovery.

For more information about the e-discovery functionality you can have a look at the site below:

Technet: In-Place eDiscovery

Redmond: where’s my Exchange Admin Center

 

Since CU1 is available it is possible to implement Exchange 2013 in an environment which contains Exchange 2010 SP3. This will create the option to migrate your resources to Exchange 2013. As you may now the Exchange Management Console (EMC) is replaced by the  Exchange Admin Center (EAC) a web based admin tool.

The EAC is accessible via the url https://fqdn/ecp for those who are familiar with Exchange 2010 will see this is the same url as for the  Exchange 2010 Control Panel. When Exchange 2013 is implemented you would like to check somethings and maybe configure several things via the EAC.

To do this go to https://fqdn/ecp and you will see the following screen:

Exchange 2013: EAC login

Provide the username and password and login:

Exchange 2010: ECP

But what you will see is the Exchange Control Panel. But how can you get to the Exchange Admin Center?
To do this you will need to add an additional parameter to the url https://fqdn/ecp?ExchClientVer=15. The loginpage will be displayed again but after you have provided the login details you will see the EAC:

Exchange 2013 EAC

A simple solution but which can take pretty long before you have found this specific thing.

In an earlier blog we had a brief look at the Database availability Group (DAG) of Exchange 2013. In this blog we will have a closer look how it works and how you can create it.

The DAG functionality was introduced in Exchange 2010 to replace all the other cluster methods Exchange 2007 contained. Using a DAG it is possible to create multiple copies of a database within the DAG. This is limited to 16 copies per database which I personally have never seen during implementations.

Database Copies can have several statuses which are displayed in the table below:

Status Description
Active The database is active on the specific server and handles requests
Mounted (passive) The database is in sync and waits till it needs to come in action
Failed The database copy is in failed state and might require a full reseed
Suspended The database copy has been suspended and new logs will not be replayed

When looking under the hood of the DAG you will discover that is uses windows clustering. These components are automatically installed when adding a server to a DAG. One import remark that must be made is that this requires an enterprise edition when deployed on Windows 2008 R2.  For Windows 2012 is doesn’t matter anymore because the failover feature is available in both standard and datacenter. Although it uses the failover feature of the OS it is not recommend to make changes via the failover cluster manager.

Within the DAG one server has the primary active manager (PAM). This server will make the decisions which copies are active and passive. When an issue occurs with the active copy the PAM is responsible for getting the topology change notifications and reacting to the failure. The server which hosts the PAM is always the owner of the cluster quorum group. If the server hosting the PAM will fail it will automatically failover to one of the DAG members who has survived.

Besides the PAM role there is an additional role called the standalone active manager (SAM). This role is active on all servers within the DAG but on the server which contains the PAM role the PAM will perform the actions of the SAM. The SAM role is responsible for detecting local database and local Information Store failures and acting on actions initiated by the PAM.

As you may have noticed we talked about the quorum. This is pretty important to understand. If you are familiar with clustering this must sound familiar to you. Because the DAG is a kind of clustering it also uses quorum to prevent issues like split-brain. In a DAG there are two options for this. Either implement an odd amount of DAG members, for example 3. Or decide to implement a Failover Witness Share. In this last case a shared folder is created on another server which is not a part of the DAG. For example if you have two DAG members we will need to add the failover witness share to get quorum.

To calculate how many at least need to be online to we can use the following formula (n / 2) + 1 where n is the number of DAG nodes within the DAG. For example we have 3 DAG members which makes (3/2) +1=2.5. Since halves do not count we need to round this down to 2. This means that at least 2 members will need to be online to leave the DAG running.  Members can be either the mailbox servers or a mix of one mailbox server and the server containing the FSW. Another example, let’s say we have 6 DAG members which makes (6/2)+1=4 which is equal. In this case at least 4 members of the DAG will need to be online.

We already talked about the multiple copies of a database but how does this work? Well each copy of a database has an activation preference. The initial database gets an activation preference of 1. All additional copies will get a unique ID assigned. For example the second copy gets 2 as activation preference etc. This preference is used as one of the parameters when the PAM needs to select a copy which needs to be activated if a failover is initiated.

Some examples

OK enough theory let’s have a look at some examples. The easiest example is a DAG within a datacenter which contains 3 multirole Exchange 2013 servers. Each server contains a copy of each database. The preferences of the databases have been configured in a way that during normal operation each server will only host one active copy:

DAG_3_Members_One_AD_Site

Let’s assume one of the nodes has an issue and would need to be taken down for maintenance. No problem just put the node in maintenance and the PAM will ensure the database will be moved to another server.

After the maintenance has been performed on the server just stop the maintenance. The other servers will see that the node is back and will ensure the copies hosted on the server will be brought up-to-date. A manual action however is needed to move the database originally active on this server.

In the next example we will have our DAG members spread across two different datacenters. Each datacenter is defined as an AD site. We are still having 3 multirole servers in our Exchange 2013 environment. The only difference with the first example is that two of them are located in the primary datacenter and the third one in the secondary datacenter. The second data center is used for disaster recovery purposes:

DAG_3_Members_Multi_AD_sites

Let’s assume the WAN link goes down in this scenario. Think of the formula what do you think will happen? Right the users can access their mailbox. Let’s use the formula (3/2)+1 = 2.5 which can be rounded down to 2. Which means at least two mailbox servers of a combination of one FSW and one mailbox server should be online. But if the complete primary data center burns down we will need to follow the procedure as described next.

A DAG can be either created within one AD Site or across two AD sites. In this last case it is pretty important in which site you locate the file share witness (FSW). In most cases this will be the site which you want to survive which might be primary site. In this case if the WAN link between the two sites goes down the site containing the quorum will survive. To bring the DR site online again we will need to introduce an alternate FSW and then bring the DAG online again.

Here ends the first part of the blog about database availability groups. In this article we looked at the theory behind the DAG and looked at some example configurations. In part two we will start building a DAG.

Exchange 2013 CU1 has been release and now?

Last week Exchange 20130 CU1 was released by Microsoft. It was a little bit later then originally planned but cudo’s for Microsoft to announce it publicly that the first CU for Exchange would arrive later then expected.

CU1 contains several fixes and enhancements. If you would like to know more about those have a look at the following blogs::

Exchange 2010 RTM CU1 released

High Availability Changes in Exchange Server 2013 Cumulative Update 1

Now CU1 is available it’s supported to migrate from Exchange 2010 SP3 to Exchange 2013. The organizations who are still running Exchange 2007 will need to run at least Rollup 10 for SP3.

But now Microsoft has “finished” his job it’s time for the other vendors in the Exchange eco-systeem to come with support. Because this is sometimes forgotten I decided to do some research. The results are that some vendors are already supporting Exchange 2013 while others are in the middle of a beta or even have planned a beta a few months from now.

I split the software up in three categories:

  • antivirus
  • backup
  • overige utilities

In the tables below an overview per category:

antivirus:

vendorproductnamestatus
ESETMail security 4.5supported
GFIMailEssentialssupported
McAfeeSecurity for Microsoft Exchange 8supported
SophosPuremessage expected July/August 2013
Trend MicroScanmail for Exchangecurrently in beta

backup/recovery:

vendorproductnamestatus
AcronisBackup & Recovery 11.5 for MS Exchange Serversupported
CommVaultSimpanaunknown
EMCNetworkerexpected Q1 2013 but some sources reported Q3/Q4
IBMTSMexpected Q2/Q3 2013
MicrosoftSystem Center 2012 - Data Protection Managersupported
SymantecBackup Execexpected Q1 2013
QuestRecovery Manager 5.0supported
VeeamExplorer v 7currently in beta

utilities:

vendorproductnamestatus
BinaryTreeCMT for Coexistencesupported
E2E Completesupported
BlackBerryEnterprise Server 5.0.4supported
ExclaimerMail Disclaimers 1.0.60227.0supported
Priasoft Migration Suite for Exchange 6.5supported
Stellar Phoenix EDB to PST converterlater this year
SymantecEnterprise Vault 10.0.3supported
QuestGroupwise Migrator 4.2supported
Notes Migrator 4.6.1supported

As you could see not all vendors are ready for Exchange 2013. So verify every software which you are using against Exchange if the vendor does support it.