Here is the Microsoft Exchange Server 2010 Cost Savings calculator designed explicitly for customers to know how much they can save if upgrading to Exchange Server 2010. Simply use your mouse to enter the required values and get the cost of upgrading to Exchange Server 2010.
Friday, 20 March 2015
Jetstress in Exchange Server 2010
As
we know, with Exchange Server 2010 disk input/output requirements has
been significantly dropped, but still the disk subsystem is very
critical for any organization.
Jetstress
verifies the performance and stability of a disk subsystem by
simulating Exchange disk input/output (I/O) load before you actually
deploy Exchange Server 2010 for production use. It simulates the
Exchange database and log files produced by a specific number of users.
It is always recommended to use System Monitor and Event viewer in conjunction with Jetstress reports to validate the expected and actual load.Jetstress testing should always be performed before you install
Exchange server in your organization. There are lots of well-known
risks associated with installing Jetstress on system having Exchange
installed.
Load Generator in Exchange Server 2010
As the name implies, it generates the load against a test Exchange server deployment
to evaluate how Exchange server performs in a given environment or
load. Also, we can analyze the impact of any change in Exchange
configuration on its behavior and performance. LoadGen can be used to
simulate Microsoft Outlook, POP3, IMAP, SMTP, Activesync and OWA connectivity.
One
important you should remember that LoadGen should always be run on test
environments, but not in production. LoadGen reports then can be used
to verify the Exchange deployment plan and validating Exchange Server settings and configurations.
Microsoft Outlook Configuration Analyzer Tool
OCAT provides a detailed report of your current Outlook profile; detects and highlights any known problem. It also provides the link to Microsoft Knowledge Base (KB) article for finding fix to that problem. This tool looks like Microsoft Exchange Best Practices Analyzer (ExBPA). OCAT supports MS Outlook 2007 and Outlook 2010 (32/64 bit). This tool is best suited for Help Desk to identify possible issues in Outlook proactively.
Visit this link to download Microsoft Outlook Configuration Analyzer Tool.
Database Availability Group In Exchange Server 2010
One
of the nice feature which I like most in Exchange Server 2010 is the
new Database Availability Group (DAG) high availability and site
resilience feature which has replaced LCR/SCR/CCR.
Cluster is no longer required before installing
the MBX server role in DAG. Cluster heartbeat and quorum are configured
by-default to the DAG when adding first Mailbox Server and hence more
or less visible to the administrator.
A
DAG is a group of 16 Mailbox servers that can each maintain up to 100
databases (up to 1600 databases in a DAG) and each database can have 16
copies of a Mailbox database with DAG using continuous replication. In
addition, we can also have other Exchange 2010 servers such as Hub
Transport and CAS which can be the member of a DAG. DAG members can be
on different subnets or on different Active Directory sites.
As
we know, Exchange Server 2007 introduced a number of new options for
availability, which includes Cluster Continuous Replication (CCR),
Single Copy Cluster (SCC), Standby Continuous Replication (SCR) and
Local Continuous Replication (LCR). You can read more about them from
this link.
How the DAG differs from Exchange Server 2007 SP1 availability options, let’s see:-
1. With
CCR, we can have only two highly available copies of the database
within the cluster, but DAG there can be up to 16 copies of each
database.
2. SCR required manual administrative intervention for activation, whereas DAG provides automatic database failover.
Therefore
we can conclude that Exchange Server 2010 provides database-level
failover within the DAG which means failure of single database no longer
affects all mailbox databases on a server. Also, DAG handles both
in-site and inter-site replication for implementing site failover.
A
DAG is initially empty, and a directory object is automatically created
in Active Directory that represents the DAG. This object is used to
store related information about the DAG, such as server membership. A
failover cluster is automatically created when an administrator adds the
first server to a DAG. The failover cluster heartbeat mechanism and
cluster database are then used to track and manage information about the
DAG that can change quickly, such as database mount status, replication
status, and last mounted location.
- No more Exchange Virtual Server/Cluster Mailbox Server
- Database is no longer associated to a Server but is an Org Level resource
- There is no longer a requirement to choose Cluster or Non Cluster at installation, an Exchange 2010 server can move in and out of a DAG as needed
- The limitation of only hosting the mailbox role on a clustered Exchange server
- Storage Groups have been removed from Exchange
Continuous
replication creates a passive database copy on another mailbox server
in the DAG and uses asynchronous log shipping to maintain the copies.
Unlike in Exchange Server 2007 which uses SMB (file share) protocol for
transactional log shipping, Exchange Server 2010 uses TCP sockets
default port 64327 for replication. Current used port can be checked by
running the Get-DatabaseAvailabilityGroup -Status | Format-List command.
Block
mode which was introduced in the Exchange Server 2010 SP1- which
reduces the exposure of data loss during failover by replicating all
logs to the passive database copies in parallel to writing them locally.
In other words, it reduces the possibility of any data loss during a
failover and the time it takes to perform a switchover.
Message Retention and Backup Strategy In Exchange Server 2010
Most of the customers have change their message retention and backup strategy. They have reduced the deleted items retention windows, yet they maintain long backup retention time periods which very from weeks to months and to years.
Let's
take an example where a customer that currently maintains backups for
90 days and retains deleted items for 5 days. Customer is taking backup
restores on a weekly basis to recover deleted items for end users. If
the customer moved to Exchange 2010 they could move that process into Exchange by simply increasing their mailboxes capacity for dumpster:
- Users send/receive 200 messages per work day and have an average message size of 60KB
- Single Item Recovery is enabled and the deleted retention window is configured to be 90 days
- 10% of items are edited
- Mailbox capacity calculations
- 5 work days * 200 emails = 1000 emails / week
- For Purges:
- 1000 emails / week * 13 weeks = 13000 emails / retention period
- 1300 emails * 50KB ? 636MB
- For Versions:
- 1000 emails / week * 13 weeks = 13000 emails / retention period
- 13000 emails * .1 = 1300 emails
- 1300 emails * 50KB ? 65MB
- Total Space Required per mailbox: 700MB
By increasing each mailbox's capacity by a minimum of 700MB, backups are no longer needed for single item recovery. Single item recovery can be maintained and performed within Exchange.
Shadow Redundancy in Exchange Server 2010
Exchange Server 2010 has introduced a new feature, Shadow Redundancy,
which provides redundancy for the entire message while it is in
transit. This feature delay the message deletion from the message queue
(mail.queue) on Hub Transport or Edge Transport
Server until Exchange server has verified that message has completed
all the hops and only then message will be deleted. Message will be
resubmitted if any of the count fails.
Let us try to understand how Shadow Redundancy actually works:-
1. Mike wants to send a message to John.
2. Mike messages is first delivered to its hub transport server, Server-A.
3. Server-A sends that message to the next hub transport server, which is Server-B and retains a shadow copy of that message.
4. Server-B sends that message to the next hub transport server, which is Server-C and queue a discard status for the Server-A.
5. Server-A queries the Server-B for discard status and upon receiving the discard notification from Server-B, it can remove the shadow copy of the message from its database.
Subscribe to:
Posts (Atom)