Exchange and Related Technologies
TwitterFacebookGoogle

ExchangeBytes

TwitterFacebookGoogle

Exchange 2010 Spanned Database Availability Groups and Voting Rights

Posted on by Posted in Exchange Leave a comment

 

An Exchange 2010 Database Availability Group (DAG) is a collection of up to 16 servers providing high availability access to mailbox data.  These mailbox databases can be located within the same datacenter or geographically separated to provide failover in the event of total site loss.  A database contained within a DAG can have one active copy and up to 15 passive copies for a total of 16 copies.  When running the enterprise edition of Exchange Server 2010 a single server can support up to 100 active or passive databases per server.  Using the above limits, a single DAG can support up to 1600 active and passive databases.  These limits allow Exchange 2010 to scale up to even the largest of workloads.

The foundation of a DAG is based on Microsoft Windows Clustering.  It is the Windows Clustering components that allow a DAG to maintain a shared view of the DAG and prevent any database from being mounted on more than one server simultaneously.  The concept of quorum is used to determine active and functioning servers within the DAG and is used to arbitrate for control of the cluster in the event of failure.  If a cluster can’t maintain quorum within a given DAG, the cluster service stops on each node and the Exchange Server databases dismount.  Cluster quorum is maintained differently depending on the number of serves in a DAG.  In a DAG with an odd number of servers, a system of node majority is used.  This system requires a majority of the nodes be online in order for the cluster to remain functional.  The method for determining node majority dividing the number of servers in the DAG by 2 and then rounding down and then adding one additional server.  For example, in a seven node DAG we would require 4 servers to be online to maintain quorum.  This can be expressed by 7/2 = 3.5 rounding down to 3 and then adding 1.  In an even node DAG we use what is called a file share witness server as the tiebreaker for the deciding vote.  The first server in the DAG to lock a file located on the file share witness server gets an additional vote.  For example, in a 4 node DAG 2 nodes plus the file share witness server must be online to maintain quorum.

This model works well when all servers are in constant communication with each other on a high-speed local network or when you have a primary datacenter and a passive datacenter.  However, when a DAG is spanned between geographically dispersed datacenters and both sides of the DAG are active, the network is a key component in keeping both sides of the DAG up and functioning.  In the event of network failure the side with the most votes wins and gets control of the cluster.  The side with the fewest members/votes is taken offline to protect database integrity.  This can pose a problem for some organizations that have large DAGS geographically dispersed with an uneven split of users on either side of the DAG.

 

Using the following scenario we can highlight the shortcomings of this deployment methodology.  Let say a large organization that provides data entry services requires 11 servers in a DAG to provide the appropriate number of copies between 2 different datacenters.  The first datacenter location is used for information workers and requires 7 servers to handle the number of database copies and users.  The users in this datacenter need email but it is not critical to their job function.  The 2nd datacenter is used for corporate executives and has 4 servers required to support the number of copies and users.  Email is critical to corporate executives and is highly important.  In the event of a network failure between the 2 datacenters, the corporate executives Exchange servers would be taken offline as they do not posses the majority of the votes and cannot maintain quorum.  In the above example we have a large number of users that do not require email that have access to it and a few number of users that do require email that do not.  In the past, correcting this problem required the installation of additional Exchange 2010 DAG members in the corporate datacenter to ensure that quorum was maintained in the corporate datacenter.  In our above example we would need to install a minimum of 3 more Exchange 2010 Servers and a file share witness in the corporate datacenter to maintain quorum.

 

A better Solution…..

Thankfully the folks over at Microsoft have made a change to Windows clustering that allows an administrator to control whether or not a server can vote in the quorum process.  Servers can be DAG members but don’t get a say when it comes to quorum votes.  In our above example, we can remove 4 of the servers voting rights in the first datacenter without reducing the number of Exchange servers.  This reduction of voting servers in the first datacenter allows us to keep the majority of the voting servers in the corporate datacenter.  Now, in the event of a network failure the corporate datacenter is able to maintain quorum thus keeping all of its Exchange DAG serves online and working.

The required steps to remove voting rights of a cluster server can be found at the following Microsoft knowledge base article  http://support.microsoft.com/kb/2494036

Exchange 2010: Benefits of Always Creating a CAS Array and Using Windows Enterprise

Posted on by Posted in Exchange Leave a comment

The CAS Array

One of my customers purchased a Load balancer and was in the process of adding a second Exchange server to their environment when I got a call when things were not working out as they had planned/expected.  They setup the DAG and a new Hardware load balancer and moved the database back and forth and everything seemed to be ok.  But, when they shut down the first server, all of the clients disconnected and would not connect to the database even thought it was mounted and healthy.  As soon as the first node was brought back online all the clients would reconnect.  Before I could speak, they informed me that they created a CAS array and changed the RPCClientAccessServer value on each of the databases to the newly created CAS Array and pointed the CAS array IP address to the Network Load Balancer.  At this point I had to break the bad news to them.

When a single Exchange 2010 Server is installed the default database and any other databases created on that server will use the local CAS server name as the RPCClientAccessServer value.  This value tells Exchange what client access server to use to gain access to the database.  Once users are added to the system and outlook is configured they will continue to use this value even if you change it to a new server or a CAS Array Name.  This happens because the clients can still talk to the databases using the old value and the clients says “why update I am working”.  To fix this issue you can do one of three different things:

1.  Run a repair in the outlook profile.

2. Create a new Outlook profile.

3.  Make the old value unresolvable in DNS.

Option 1 or 2 although time consuming will probably be your best bet.  Making the old value in DNS unresolvable would probably cause a lot of issue and or break your current Exchange setup.

To avoid this scenario, always create a CAS Array as soon as you are done installing Exchange 2010, even if you are only going to have a single server in the site.  Adding a new server into the same site will not required changes to the outlook client and make your projects go smoother.  Below are a few PowerShell commands to help you determine and set the RPCClientAccessServer value

Get-MailboxDatabase |FT Name,RPCclientAccessServer

Set-MailboxDatabase –id DB1 –RPCclientAccessServer MyCasArray.company.com

 

Windows Enterprise

Like the CAS Array, a little bit of prior planning can save you a lot of work in the future.  When installing Exchange 2010 it is my recommendation to always use the Enterprise edition of the OS,  even if you are only deploying a single server in the site.  An Exchange Database Availability Group(DAG) member requires components only available in the Enterprise and Datacenter editions of the OS.  Adding or removing a servers in a DAG is relatively simple and can be done without user interruption however, once the OS and Exchange are installed you can’t change from standard to Enterprise.  Now, I have heard of people using a hack to change from standard to enterprise but, this is not supported by the Exchange product team and could cause major issues with your Exchange Server.  In summary, always using a CAS Array and installing Exchange 2010 on the Enterprise Edition of Windows Server can save lots of time and money.

Have any questions for Comments don’t hesitate to ask

 

 

Is Exchange 2000/2003 a Ticking Time Bomb?

Posted on by Posted in Exchange Leave a comment

Microsoft Exchange Server uses a transactional database architecture. This means that all database transactions are stored in Log files. Exchange versions prior to Exchange 2007 used a 5MB file with a unique naming convention. The log file name is a sequential Hexadecimal number starting with log file E0000001.log. Once the Log File is full of changes the next log file in the sequence is created E0000002.log. Exchange continues to do this until exactly 1,030,000 log files have been created (E00FFFFF.log) and then “HOUSTON WE HAVE A PROBLEM”. Now before we get to the fix, just how big of a deal is this? 1,030,000 is a lot of transaction logs files that can be generated and we should never run out right?. However, some Exchange 2000/2003 Servers have been in production for 10+ years. If we do the math on the number of maximum available logs and divide that by 3650 (10 Years) we can roughly estimate 282 log files a day or 1410 MB of email transactions per day. For smaller organizations this would seem like a significant amount of space on a daily basis considering weekends and holidays when email traffic is lessened. Unfortunately, even smaller Exchange Server shops run 24X7 365 days a years and Exchange is never down and constantly sending and receiving email.

Now, here is some detailed explanations before we all go running and screaming that the sky is falling. These log files are generated per storage group and per server. So, multiple storage groups reduce the possibility of hitting the max. Other activities such as stopping the database and deleting the checkpoint file and all transaction logs will reset the sequence back to E0000001.log. It is not recommended to perform these activities frequently as they can cause issue with backup and restore, they are sometime performed during database maintenance and or recovery.

So what do you do if you hit the max? Thankfully the folks over at Microsoft have already written an article explaining what to do. Check out this link to do some additional reading.

In summary check your log files and event viewer to figure out how much time you can run before action must be taken.

Exchange 2010 ActiveSync Device Info

Posted on by Posted in Exchange 3 Comments

Exchange Administrators always want to know who and what is connecting to their Exchange environment.  Commands like Get-ActiveSyncDevice and Get-ActiveSyncDeviceStatistics provide lots of information but leave out some of the desired details or make it hard to read.  With that being said i have done a little reworking of a script written over at Glen’s Exchange Dev Blog  to run right inside of the Exchange 2010 Management Shell.

In larger Exchange environments the get-mailbox command down in the code would need to be changed to get-mailbox -ResultSize unlimited.

If you want the output to be in a file change the last line from |FT to |Export-csv C:\Mobile.csv

$HWVersions = @{
"Apple-iPad" = "iPad";
"Apple-iPad1C1" = "iPad";
"Apple-iPad2C1" = "iPad 2";
"Apple-iPad2C2" = "iPad 2";
"Apple-iPad2C3" = "iPad 2";
"Apple-iPhone" = "iPhone";
"Apple-iPhone1C2" = "iPhone 3G";
"Apple-iPhone2C1" = "iPhone 3GS";
"Apple-iPhone3C1" = "iPhone 4";
"Apple-iPhone3C3" = "iPhone 4";
"Apple-iPhone4C1" = "iPhone 4S";
"Apple-iPod" = "iPod Touch";
"Apple-iPod2C1" = "iPod Touch 2";
"Apple-iPod3C1" = "iPod Touch 3";
"Apple-iPod4C1" = "iPod Touch 4";
}

$IOSVersions = @{
"508.11" = "2.2.1";
"701.341" = "3.0";
"701.400" = "3.0.1";
"702.367" = "3.2";
"702.405" = "3.2.1";
"702.500" = "3.2.2";
"703.144" = "3.1";
"704.11" = "3.1.2";
"705.18" = "3.1.3";
"801.293" = "4.0";
"801.306" = "4.0.1";
"801.400" = "4.0.2";
"802.117" = "4.1";
"802.118" = "4.1";
"803.148" = "4.2.1";
"803.14800001" = "4.2.1";
"805.128" = "4.2.5";
"805.200" = "4.2.6";
"805.303" = "4.2.7";
"805.401" = "4.2.8";
"805.501" = "4.2.9";
"805.600" = "4.2.10";
"806.190" = "4.3";
"806.191" = "4.3";
"807.4" = "4.3.1";
"808.7" = "4.3.2";
"808.8" = "4.3.2";
"810.2" = "4.3.3";
"810.3" = "4.3.3";
"811.2" = "4.3.4";
"812.1" = "4.3.5";
"901.334" = "5.0";
"901.405" = "5.0.1"
"902.179" = "5.1"
}

$Resultset = foreach($mbx in get-mailbox -ResultSize unlimited) {Get-ActiveSyncDeviceStatistics -Mailbox:$mbx.Identity |Select-Object @{name="Username";expression={$mbx.name}},DeviceType,@{name="Device";expression={$_.DeviceUserAgent.ToString().Split("/")[0]}},@{name="OSVersion";expression={$_.DeviceUserAgent.ToString().Split("/")[1]}},LastSuccessSync}
$Output= @()
ForEach ($Line in $Resultset) {
$Object = "" | Select-Object Username,DeviceType,Device,Version,LastSuccessSync
$Object.UserName= $line.Username
$Object.DeviceType =$Line.DeviceType
$Object.Device = $HWVersions.Get_Item($line.Device)
$Object.Version = $IOSVersions.Get_Item($line.OSVersion)
$Object.LastSuccessSync = $line.LastSuccessSync
$Output += $Object
}
$output |FT

 

Exchange 2003/2007/2010 ActiveSync Proxy and Redirection

Posted on by Posted in Exchange 6 Comments

When performing a mail migration from Exchange2003/2007 to Exchange 2010 a little understanding of how proxy and redirection work can smooth your migration woes. A quick definition of proxy and redirection can help eliminate confusion between the two. A redirection happens when a device is configured to communicate with Exchange at specific URL and the initial server sends the device a redirection to a different URL that is closer or better suited to handle the device.  The device then updates it configuration to talk to the new location.   A proxy happens when a device is configured to a specific URL and the responding server gets the required data from mailbox server on behalf of the device regardless of version and or location. To help further explain the situation the following graphics can be used to as an example of a proxy and a redirect.

 

Figure 1.  Redirection

 

Figure 2.  Proxy

 

One could look at the above graphics and could make the determination to always proxy due to the  belief that it is faster and would appear to be simpler.  However, redirection is a very effective way of moving devices to servers more suited to handle the request.  For Example, if a user from the UK has a device configured to communicate with a server in the USA, it is along away across the pond for a proxy request from server to server.  In this particular scenario a redirection would be better suited to allow the device to talk to a server in the UK that is closer in proximity.

Proxy and Redirection determination is handled by the existence of the external URL on the 2007/2010 Client Access Server.  If all Internet facing servers have their External URLs configured then those servers will always redirect devices to the Client Access Server closest to the mailbox.  If only 1 site is Internet facing, that one site will Proxy connections to all other exchange Servers in the environment.

When performing a migration from 2003 to 2010 it is always best practice to point the external address at a 2010 Client Access Server.  Since Exchange 2003 has no concept of sites and Internet connected sites, 2010 will always proxy to 2003.  The last trick to the configuration is to ensure that devices configured to point to an Exchange 2010 server and have mailboxes on Exchange 2003, need to have integrated authentication enabled on the Exchange 2003 ActiveSync Virtual Directory.  Unfortunately, when you enable integrated authentication on 2003 it goes behind you and resets the configuration back to basic every so many minutes.  The Fix for this issue can be located here at the following MS support article.

if you have any questions please feel free to leave a comment :)