Howdy,
Microsoft has released an important update to resolve some issues experienced when using the Hybrid Configuration Wizard to create a new or manage an existing hybrid deployment with Microsoft Exchange Server 2013.
In order to know more about this including a FAQ section please follow the below link:
http://blogs.technet.com/b/exchange/archive/2014/07/30/important-update-available-for-exchange-server-2013-hybrid-deployments.aspx
Keep Safe!!!
Howdy Protectors,
It seems Microsoft has released another couple of updates for our beloved product:
2966012 - Update Rollup 7 for System Center 2012 Data Protection Manager SP1
http://support.microsoft.com/kb/2966012
2966014 - Update Rollup 3 for System Center 2012 R2 Data Protection Manager
http://support.microsoft.com/kb/2966014
The Microsoft Exchange Team just published an amazing document on Office 365 and SPAM. Apparently these will be a series, so we have a lot to look forward on this.
Here is the first one…
http://blogs.technet.com/b/exchange/archive/2014/07/25/spam-email-and-office-365-environment-overview.aspx
Howdy
Did you like MEC 2014?
http://channel9.msdn.com/events/mec/2014
Guess what, we've announced the 2015 dates!
The news on this one is that it converges a series of events into one. If you've attended Microsoft Exchange Conference (MEC), SharePoint Conference, Lync Conference or Project Conference, this event is for you! Head over to Office Blogs for more.
For those of you with DPM 2012 who have attempted to restore the DPMDB, the restore operation may fails with the following error message:
Error ID: 470DPM database is not present in the instance of SQL Server. Check that the DPM database is present in the given instance of SQL Server.Detailed Error: Invalid object name 'dpmdb.dbo.sysfiles'.
In order to fix this please check:
KB2968666 - "Error ID: 470" when you run the dpmsync -restoredb command in Data Protection Manager 2012 http://support.microsoft.com/kb/2968666
You may say, here it comes another agent deployment troubleshooting idea, and you’d be absolutely right! In this case is specifically developed for the error 319:
Install protection agent on name.domain.com failed:Error 319: The agent operation failed because of a communication error with the DPM Agent Coordinator service on name.domain.com.Error details: The RPC server is unavailable (0x800706BA)Recommended action: 1) Verify that name.domain.com is remotely accessible from the DPM server.2) If a firewall is enabled on name.domain.com, make sure that it is not blocking requests from the DPM server. Refer to the DPM Deployment Guide for more information on configuring the firewall for DPM.
Additionally, the DPM-Alerts event log displays the following event:
Log Name: DPM AlertsSource: DPM-EMDate: <date>Event ID: 370Task Category: NoneLevel: WarningKeywords: ClassicUser: N/AComputer: name.domain.com Description:Agent operation failed. (ID: 370)The agent operation failed because of a communication error with the DPM Agent Coordinator service on name.domain.com. (ID: 319)
KB2981833 - System Center 2012 Data Protection Manager agent installation fails with error 319 (http://support.microsoft.com/kb/2981833)
Howdy Protectors
We have great news… Finally we can AGAIN protect our Windows Server 2003 boxes even using DPM 2012 R2…
In order to do that we will need to:
Thanks a million for your time reading my blog…
Hello there,
Recently I had been helping a customer in a migration from Exchange Server 2010 to Exchange Server 2013. All went pretty normal, actually some of the steps were easier than I thought they would be, but there was a tiny little (and very annoying) surprise – the DAG creation kept failing…
Basically I just assumed that all would be good and would be pretty much next, next, finish… And that I’d not need to do nothing manually.
CNO Pre Staging is something that I assumed that would not need to do, however that was the only way to make it work…
Basically I run New-DatabaseAvailabilityGroup and all went well… After that was the time to do start adding members, and when doing it was getting the bellow failure:
A server-side database availability group administrative operation failed. Error The operation failed. CreateCluster errors may result from incorrectly configured static addresses. Error: An error occurred while attempting a cluster operation. Error: Cluster API ‘”CreateCluster() failed with 0×5. Error: Access is denied”‘ failed.. [Server: MBX1.fabrikam.int]
Only way to fix it was either:
After that all was good…
Bottom line here is, and after some good email threads with some colleagues, the CNO for a DAG should always be pre staged regardless of Exchange version, Windows version, or AD version. It greatly reduces the failures due to access denied for the many other reasons that can cause access denied.
After running into this, I’ll pre stage regardless of version used from now on, save a lot of headache.
Thanks a million,
This update rollup was re-released on May 20, 2014 to resolve a "DPMAMService" crash that occurred if the original update (KB 2958100) was applied.
If you already installed Update Rollup 2 (UR2) on your Windows Server 2003 servers, you do not have to reinstall the UR2 agent that is required for Windows Server 2003 communication for this re-release. Additional updates after this re-release will install and work as expected.
KB2963543 - Description of Update Rollup 2 for System Center 2012 R2 Data Protection Manager
For the GUI lovers we have something really cool here…
Migrate DPM Disk / Data Source (GUI)
Below are some screenshots of how it works:
I have SQL auto protect and co-location enabled, so I have a single replica and RP volume on Disk 1.
Now I want to migrate that setup to be across Disk 2 and Disk 3 so I launch the MigrateDPMData.ps1. Here you enter C to migrate an entire disk or O to migrate a data source. I entered O for one data source.
And you get a separate popup screen listing the protection groups. I only have one to select from.
Once selected – it will list all the data sources in that PG to choose from.
Since my DBs are all co-located, migrating one DB will automatically migrate all – that is the way MigrateDataSourceDataFromDPM.ps1 works under the covers.
The next screen allows me to select one or more disks to migrate to. Here I selected Disk 2 and Disk 3 by holding down the Ctrl key while selecting.
Below shows the migration was successful and the two new volumes were created on the specified disk, one for the replica on Disk 2 and one for the recovery point on Disk 3.
Note the post-recovery jobs running that copy the replica data from the original replica to the new replica.
Pretty Awesome!!
Big Thanks to Michael Jacquet for sharing the screenshots…
One of the first actions most Exchange Administrators generally take when troubleshooting suspected problems with Exchange Content Indexing will be to rebuild the impacted Mailbox Database's content index files (either manually or by using the ResetSearchIndex.PS1 script found in the \Exchange Server\Scripts directory). Many Exchange administrators choose to proactively rebuild search indexes at various points during the calendar year or as various milestones within a project are met (say in a migration project; as a single example).
Eric Norberg wrote an awesome set of posts regarding this subject which show us much more in detail what to do in each situation… Below we can find them:
We hope you find this post series useful, and better yet, have learned something new along the way!
There are brilliant news for RCA users, owner team has made an awesome effort in listening to customers feedback and change quite a few issues or let’s just say a bit more annoying than what it should be operations!
Check it out below…
For more info check Release Notes!!!
There may be scenarios where we would want to have some data sources’ data from DPM storage pool to some specific custom volumes. This post is here to show the main steps:
Run the dpm2010-ldmstat.ps1 script to see which data sources have the most extents. This only runs on DPM 2010:
==============================
LDM&ShrinkStats
Total extents : 20
Total data sources : 15
Total volumes : 18
Data source extent list...
DatasourceName ProtectionGroupName NumberOfExtents PhysicalReplicaId DatasourceId
-------------- ------------------- --------------- ----------------- ------------
System Protection BMR 3 f6769aa3-3991-45d0-9bea-ab94d4995160 4ea2ceee-2443-427d-8513-3746c59dd49b
System Protection SQL PROTECTION on DC1 3 4460be42-337d-4f5e-bddb-4f97c8a787e8 a6159995-754d-4835-8fe3-9b4c46abbae4
N1-MB2 E-14 DAG 2 5328326e-e7af-4414-beee-5d2b476acf9a 17e9e992-5892-4ad3-9bc6-70663ff404d5
DisconnectedClient Client Protection 2 a36df5b6-084a-4fbd-ab25-6349dec93248 b62b6dbc-580e-42bd-80a8-1b2ed191df6e
N2-DB2 E-14 DAG 2 e1ea38f8-9b2e-400e-a450-77e03ad36e19 889596a2-1d24-4b50-9ce5-5e557841698d
Mailbox Database N2-MB1 E-14 DAG 2 9d956aeb-8d0e-4561-91cc-8993d1c452cf 337331fc-1087-4bf5-a508-28a08f374bfd
MJLC-DC\MSDPMV3TAP\model SQL PROTECTION on DC1 2 00e38e25-01c8-44d3-8005-aca453f1f2dd 6bb4ab04-7288-48cc-8216-01201e32ad2b
MJLC-WSS-V14\SHAREPOINT\SharePoint_AdminContent_234f95fc-3230-4ddb-85d1-230b25e4dfce 2 35b03787-9e1b-4b43-a0cf-bcac33c3fdc5 a0cf0d91-efcc-4eae-866a-20b2f3f7e1b1
Mailbox Database N1-MB1 E-14 DAG 2 a6794c2b-2953-41b0-bd3d-d327989caa9d 5175b4f1-f85b-49b1-b843-823de8228619
Replica colocation counts...
PhysicalReplicaId Count
----------------- -----
4460be42-337d-4f5e-bddb-4f97c8a787e8 1
5328326e-e7af-4414-beee-5d2b476acf9a 1
a36df5b6-084a-4fbd-ab25-6349dec93248 2
e1ea38f8-9b2e-400e-a450-77e03ad36e19 1
9d956aeb-8d0e-4561-91cc-8993d1c452cf 1
f6769aa3-3991-45d0-9bea-ab94d4995160 1
00e38e25-01c8-44d3-8005-aca453f1f2dd 6
35b03787-9e1b-4b43-a0cf-bcac33c3fdc5 5
a6794c2b-2953-41b0-bd3d-d327989caa9d 1
LDM alerts list...
None found!
Done!
Get the list of protection groups and data sources:
PS C:\Program Files\Microsoft DPM\DPM\bin> $pg = get-protectiongroup mjlc-dpm01
PS C:\Program Files\Microsoft DPM\DPM\bin> $pg
Name Protection method
---- -----------------
BMR Short-term using disk
Sharepoint 2010 Short-term using disk
SQL PROTECTION on DC1 Short-term using disk
Client Protection Short-term using disk
E-14 DAG Short-term using disk
PS C:\Program Files\Microsoft DPM\DPM\bin> $ds = get-datasource -protectiongroup $pg[2]
PS C:\Program Files\Microsoft DPM\DPM\bin> $ds
Computer Name Type
-------- ---- ----
MJLC-DC MJLC-DC\MSDPMV3TAP\model SQL Server 2008 database
MJLC-DC MJLC-DC\MSDPMV3TAP\ReportServer$MSDPMV3TAP SQL Server 2008 database
MJLC-DC MJLC-DC\MSDPMV3TAP\master SQL Server 2008 database
MJLC-DC MJLC-DC\MSDPMV3TAP\DPMOfflineUIViewerDB SQL Server 2008 database
MJLC-DC MJLC-DC\MSDPMV3TAP\msdb SQL Server 2008 database
MJLC-DC Computer\System Protection System Protection
MJLC-DC MJLC-DC\MSDPMV3TAP\ReportServer$MSDPMV3TAPTempDB SQL Server 2008 database
Get the list of custom volumes we can migrate to and label the volumes accordingly:
The migratedatasourcedatafromdpm.ps1 expects the replica volume to be the first array member, and the recovery point volume to be the second.
PS C:\Program Files\Microsoft DPM\DPM\bin> Get-DPMVolume mjlc-dpm01
VolumeLabel VolumeSize DiskName
----------- ---------- --------
replica-1 15728640000
diffarea-1 47185920000
PS C:\Program Files\Microsoft DPM\DPM\bin> $dpmvol = Get-DPMVolume mjlc-dpm01
PS C:\Program Files\Microsoft DPM\DPM\bin> $array = @($dpmvol[0],$dpmvol[1])
PS C:\Program Files\Microsoft DPM\DPM\bin> $array
Now run the migratedatasourcedatafromdpm.ps1 and provide source and destination using the following syntax:
PS C:\Program Files\Microsoft DPM\DPM\bin> migratedatasourcedatafromdpm -dpmservername mjlc-dpm01 -source $ds[5] -destination $array = @($dpmvol[0],$dpmvol[1]) FormatVolumes 1-true/0-false : 0
Have Fun!!
I think everyone understands that it’s not possible to select a specified disk from the DPM storage pool as a target disk for a specific protection group, however we can always move data between disks as far as the same DPM server has access to both disks.
Lets suppose we have ten protection groups and ten disks, and we moved data of a particular protection group (let’s say that data was written in disk one and disk two) to a particular disk (let’s say disk three).
Does that mean that DPM will never ever use disk one and disk two for this particular protection group and will always use disk three or can it use disk three along with any other disks, except for disk one or disk two?
To try to contextualize this a bit better, let’s imagine that we’ve attached a new disk to the storage pool of DPM and we want the data of a particular protection group to end up there.
Maybe an odd request however some customer ask for it…
The trick here will be to use custom volumes instead of the DPM storage pool. So basically after we add the new disk we can just create a custom volume on it – we just need to make sure we convert it to dynamic before anything else just in case we need to stretch it or shrink it…
DPM cannot allocate space on any disks not in the DPM storage pool, so using custom volume on disks outside the storage pool will ensure that the disk is only used for the data sources you configured (or migrated) to use that disk.
After this we need to migrate the data sources to this recently created custom volume. Just a quick note which may be handy – we will need two custom volumes per data source, one for replica and the other for recovery point.
If you check this other post you can see an example of migrating a data source from DPM storage pool to custom volumes…
http://blogs.technet.com/b/sjimmie/archive/2012/05/07/data-source-migration-to-custom-volumes.aspx
Have Fun!!!
There is a quite awesome tool which will make Exchange administrators’ life so much easier when the need to play with Role Base Access Control comes… As everyone knows that’s an amazing feature on the Exchange Server however sometimes may get complex as it can go madly granular…
RBAC Manager puts all efforts to simplify the RBAC administration. Basically it provides the missing GUI to edit RBAC settings on Exchange 2010 systems including adding/removing cmdlets, cmdlet properties, assignments etc. RBAC tool is written in C# and using Powershell behind the scenes and you need to have Exchange 2010 Management Tools installed prior to running RBAC GUI…
http://rbac.codeplex.com/
Have Fun!
This post is supposed to be the first of a series of four and they all have a common goal which is to try to demystify the concept of Tape Library Sharing. I have to thanks to Michael Jacquet, who has been my main source either in forums, blogs, trainings, or when I am simply stuck! BIG THANKS MICHAEL…
So before go any further in terms of Tape Library Sharing… Let me share with you a picture, which following what Confucius said, worth more than one thousand words…
Tape library is typically a collection of tape drives that automatically mount and dismount tape media. Basically in order to achieve the referred concept we need that the tape is in a Storage Area Network (SAN) environment. We need as well at least two DPM servers: the library server that is a computer on which DPM 2010 is installed, the library sharing command has been run and the medium changer is enabled; the library client that is a computer on which DPM 2010 is installed, the library sharing command has been run and the medium changer is disabled. We can have more than one library client sharing the same tape library.
That been explained let’s now remember the pre-requisites for Tape Library Sharing:
Requisites remembered and we are ready to set it up then:
After you have configured library sharing, you can use the shared tape library as if it were attached to each DPM server.
I hope this stuff help you all and soon will publish the second one of this series… Bear with me…
Microsoft Information Technology (Microsoft IT) maintains a complex Microsoft® Exchange Server environment that consists of several geographic locations and multiple Active Directory® forests. There are 16 data centers, four of which host Exchange servers, to support more than 515 office locations in 102 countries with more than 180,000 users. These users include managers, employees, contractors, business partners, and vendors. Microsoft IT transitioned this environment to Exchange Server 2010 in less than seven months by taking advantage of its growing automation infrastructure and the enhanced deployment features available in Microsoft Exchange Server 2010, in combination with proven planning, design, and deployment methodologies.
Before an Exchange Server release can ship, it has to be thoroughly tested in the production environment. The deployment of Exchange Server into the corporate environment is quicker with each release. For Exchange Server 2010, production testing began in February 2009, one year before Exchange 2010 was available. The entire company migrated to a release candidate (RC)—several months before release to manufacturing (RTM) occurred in September 2009. Microsoft IT accomplished this despite the challenge of testing the Windows® 7 operating system and Microsoft Office 2010 at the same time.
At Microsoft, Microsoft IT and the Exchange Server product group work together closely. Microsoft IT must sign off on a release before the product group can ship it to customers. This relationship is critical to identifying show-stopping factors during the release process.
This technical white paper discusses the Exchange Server 2010 architecture, design, and technologies that Microsoft IT chose for the corporate environment. This paper also discusses the strategies, procedures, successes, and practical experiences that Microsoft IT gained during the planning and design phase. Common planning and design tasks for many Exchange Server deployment projects include server design, high-availability implementation, and capacity planning. In addition to these tasks, transitioning a complex messaging environment to run on Exchange Server 2010 entails specific planning considerations regarding directory integration, routing topology, Internet connectivity, client access technologies, and unified messaging (UM).
The most important benefits that Microsoft IT achieved with the production rollout of Exchange Server 2010 included:
A reduction in input/output per second (IOPS) of 70 percent since Microsoft Exchange Server 2007. The database optimizations of Exchange 2010 provide better performance and reduced storage costs. This results in a savings of more than 50 percent in the total cost of ownership (TCO) of storage.
An increased Mailbox size of 5 GB for all mailboxes in the organization.
Increased mailbox migration velocity over Exchange Server 2007, which enabled Microsoft IT to migrate the entire company much more quickly.
Elimination of backups, which saves millions of dollars per year.
This paper contains information for business and technical decision makers who are planning to deploy Exchange Server 2010. This paper assumes that the audience is already familiar with the concepts of the Windows Server® 2008 operating system, Active Directory Domain Services (AD DS), and previous versions of Exchange Server. A high-level understanding of the new features and technologies included in Exchange Server 2010 is also helpful. Detailed product information is available in the Exchange Server 2010 Technical Library at http://technet.microsoft.com/en-us/library/bb124558.aspx.
For security reasons, the sample names of forests, domains, internal resources, organizations, and internally developed security file names used in this paper do not represent real resource names used within Microsoft and are for illustration purposes only.
In order to obtain the full technical white paper visit http://technet.microsoft.com/en-us/library/ff829232.aspx.
I am pleased to announce that starting today you can download the BETA version of the Exchange UM 2010 troubleshooting tool from Microsoft Download Center. The Exchange Unified Messaging team needs your feedback! Download the tool, use it and let us know your thoughts!
The UM troubleshooting tool is a diagnostic cmdlet which helps Exchange UM administrators to identify misconfigurations in telephony equipment and Exchange 2010 SP1 Unified Messaging settings. It emulates calls and runs a series of diagnostic tests, stating the reason and possible solutions for issues that have been detected. This is the tool you should use whenever someone in your organization complains: “My voice mail is not working!”.
You can download the Exchange 2010 Unified Messaging Troubleshooting (BETA) tool from Microsoft Download Center at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=10d2e48f-0846-40b6-b08f-d282309811a2.
We are preparing a set of articles about the tool in TechNet which will be released soon. A separate email will be sent once the articles are published.
You can invoke the PowerShell Get-Help for the cmdlet to find detailed information about each parameter and usage examples (e.g. Get-Help Test-ExchangeUMCallFlow –detailed).
You can install the tool on a local Unified Messaging server or on any 64 bit computer running:
Prior to installing the Exchange 2010 Unified Messaging Troubleshooting (BETA) tool, the following components must be installed on a 64 bit version of Windows 7, Windows Vista, or the 64 bit edition of Windows Server 2008:
DPM 2010 provides node based protection so the state of the database on the node - whether it is an Active copy or a Passive copy of the Exchange 2010 DB does not matter. The state of the database may switch back and forth from Active to Passive, but DPM will continue to protect the DB as long as the Exchange server is up and running.
As for how many copies to protect - it is recommended that you protect at least two copies of the DB, especially if your Exchange server implementation is based on JBODs/SATA drives. In this situation, it is possible that the database will switch states due to the higher probability of disk failures with SATA drives. So if you only protect one copy, you will not have protection when the protected copy goes offline. You will have to manually add protection for another copy after the failure. This has a further disadvantage that you will incur the heavy cost of Initial Replication where you will be backing up the entire database which could be time consuming and will expose you to the risk of not having a consistent backup in this interim.
If you choose to protect at least two databases, you will not incur the cost of Initial Replication every time a disk goes offline. It can also be shown that the storage consumed on the Recovery Point volume when protecting two databases is less than twice the amount of the space consumed when protecting only one server. In fact, if you expect to switch the databases from Active to Passive frequently, the space consumed by Recovery Points decreases.
If you are using RAID higher end disks then protecting only one copy of the DB with DPM may suffice. By the way, in either case, we recommend that you use RAID 5 disks.
Log file truncation - when you setup protection, in the Protection Group wizard, you are required to configure a database to either be a "Full Backup" or a "Copy Backup". With DPM 2010 you need to configure at least one Full Backup. The Full Backup will backup the databases and the log files and then truncate the log files. If you are protecting more than one copy of the Exchange database, then you should configure one Exchange database for Full Backup and the rest of the copies for "Copy Backup". Copy backup will not truncate the log files.
The next challenge we faced was getting DPM to backup using the assigned (using Add-BackupNetworkAddress) backup network. The post at http://technet.microsoft.com/en-us/library/ff399746.aspx seems to indicate that the NICS for the backup network should register their IPs in DNS.
Some customers complain that if they add the primary IP address of the DPM server to another “Add-BackupNetworkAddress” statement (-SequenceNumber2) the backup works but it goes over the primary address. Alternatively this would be a workaround but with the respective risks… Hosts file is the name…
I tested several other approaches first though. On my network the backup network NICs do not register themselves in DNS. In fact, they do not even talk to the domain controllers where DNS is located. As memory serves this is what I found:
To use hosts files, put an entry in each client's hosts file with the name of the DPM server and the backup network address of the DPM server. In the DPM server's hosts file put an entry for each client list the client host name and the backup address for that client. Do not create entries for the normal, non-backup network addresses. At that point ping by name in both directions should resolve to and use the backup network. If not, you might have other name resolution methods in place. Check out http://support.microsoft.com/kb/142309 (old, but as far as I am aware the resolution order has not changed) or do a search for "host name resolution". I have no LMHOSTS entries, no WINS, etc. so all I needed to do was put the above entries in the hosts file and it worked. I did not run the PowerShell cmdlet to inform DPM of a dedicated backup network. As far as DPM was concerned, all communication was over that network. I verified during backups that the traffic did stay on the backup network.
Would like to thanks Anne Soilleux, one of our brilliant Escalation Engineers, who actually grab me in the office making me DPM questions and coz of that I end up researching, blogging and posting! Cheers Anne!!!
In most environments that plan to implement Exchange 2010, there will probably be an older (legacy) version of Exchange Server running. This document provides information on how Exchange 2003, Exchange 2007, and Exchange 2010 will work together in regards to OWA. If implemented correctly this will provide a single namespace for user access to the Outlook Web App (OWA), regardless of where their mailbox is located.
Because the variations are numerous in customer environments, the steps in this bulletin may not work for every implementation. The steps are tailored for several typical environments and actual steps for configuring this solution may vary.
Some general planning guidelines for coexistence are as follows:
This scenario is a typical scenario for most of our small to mid-sized customers. Typically, they will have one Active Directory site and the addition of Exchange 2010 into their environment will not change that. If the steps below are followed, users can continue to use their existing URL for OWA. They can also expect to have single sign-on for their OWA users, even if they are on Legacy versions of Exchange.
This is a very clean experience for the users and should help make the migration painless as a user’s learning curve will not be required.
The following list contains the basic instructions for the setup of the single sign-on and a brief explanation of what will happen when a user accesses OWA:
In most cases in a 2 internet facing site Environment the users in the internet facing sites would type the name that correlates to the site they are located in but for this example we will assume they did not.
This scenario is typically found in a medium- to large-size company that has multiple Active Directory sites that are not well connected. In this case, you would not want the traffic from a CAS server to return mailbox data from a server in an Active Directory site where the connection is not optimized. In this case if a user goes to a site where the mailbox is not located and authenticates, the Exchange Server 2010 CAS server would provide a page informing the user to click on a link to take them to the CAS server for the site where the mailbox is located. When the link is clicked, the user will be prompted for authentication again, this time from their local (to the Mailbox server) CAS server. This will not be a single sign-on scenario unless the user accesses the proper link for the site where there mailbox is located.
An explanation of what the user will see follows the instructions to configure the solution:
This scenario could apply in a medium- to large-size company that has multiple Active Directory sites that are well connected. This provides a single namespace for the users to connect to for OWA access and minimizes user confusion.
In this case if a user goes to the published OWA URL and authenticates, the Exchange 2010 CAS server silently proxies to the Client Access Server that is local to their Mailbox server. The user would not be prompted again or redirected to another site for action.
This will generate more network traffic, as the rendered mailbox data will be passed to and from the CAS server in the site where the mailbox is located back to the External facing CAS server. The configuration steps and the user experience explanation follow:
The scenario below is for a company that does not have Exchange Server 2007 installed and is migrating or coexisting with Exchange Server 2010 and Exchange Server 2003, only.
The Exchange2003URL value can be found in Active Directory in the following location using ADSIEdit.MSC:
This will allow the Exchange 2010 server to know where to direct the Legacy users so that they can access OWA using the 2010 CAS servers URL. This parameter was added as there is no longer a /exchange virtual directory in Exchange Server 2010, as there was in Exchange Server 2007. It is important to understand that Exchange Server 2010 cannot proxy to Exchange Server 2003 Mailbox role servers. Exchange Server 2010 must redirect this traffic.
In this situation you would use the new Exchange2003URL parameter that is configurable via the Exchange Management Shell with the set-OWAVirtualDirectory commandlet explained below:
Thanks to Timothy Heeney, Chris Lineback and Sam Kamau putting together all of this awesome piece of information which will help so many customers in migration processes.
One corrupted mailbox can have the potential to disrupt service by taking down the entire information store, thereby affecting all users on that server. Mailbox quarantine has been introduced in Exchange Server 2010 to help prevent this situation.
Mailbox quarantine is a feature in the Exchange Server 2010 information store. Based on values in the registry, the store detects a mailbox or mailboxes that have the potential to or have caused the store to crash and quarantines them for specific period. The mailboxes that have the potential to crash the store are called Poisoned mailboxes.
Quarantining of mailboxes can occur in two situations:
The store will tag a mailbox that has the potential to crash the store. The tag includes the number of times that mailbox has caused the store to crash and a time stamp. If the store is crashed by a mailbox, a registry key is created. The path to the registry key is:
HKLM\SYSTEM\CCS\Services\MSexchangeIS\Servername\Private-dbguid\Quarantined Mailboxes\ {Mailbox GUID}
It will have the following two values:
The key is not created until the store has been crashed at least one time by a mailbox.
Each time a database is mounted, the store checks the registry to see if any mailboxes hosted on this particular database is tagged. If the registry indicates that a mailbox has caused the store to crash the mailbox will be quarantined.
By default, if a mailbox has been identified as a threat 3 times in 2 hours then that mailbox will be quarantined for 6 hours.
These default settings can be modified by creating the following key:
HKLM\SYSTEM\CCS\Services\MSexchangeIS\ParameterSystem\Servername\Private-dbguid\Quarantined Mailboxes
Using the following values:
These two values do not exist by default. They should be created only if there is a need to change the default behaviour.
A background process in the store runs every 2 hours (this default can’t be changed) to check the registry values for each mounted database. The store checks the CrashCount and LastCrashTime values and performs any of the following four actions:
When a client attempts to access a mailbox the following occurs:
1. The store will return an error code ecMailboxQuarantined and based on this, XSO throws the transient exception MapiExceptionMailboxQuarantined to signal transport and other XSO clients
2. Every 5 minutes transport tries to deliver message sent to a quarantined mailbox
3. Outlook clients see the following pop up when they try to access a quarantined mailbox
4. OWA displays the following pop up error message when trying to access a quarantined mailbox
Only clients such as MFCMAPI that can pass Open-As-Admin flag can access a mailbox while it is in quarantined state. Even Exchange processes such as content indexing and mailbox assistants cannot access the mailbox.
For example, a move mailbox request will fail with the following pop up error:
It is possible to reset a quarantined mailbox by deleting the quarantine registry key for that mailbox located at:
HKLM\SYSTEM\CCS\Services\MSexchangeIS\Servername\Private-dbguid\Quarantined Mailboxes\ {Mailbox guid}.
The database then has to be dismounted and remounted or the IS service restarted for the reset to take effect immediately. Unless the underlying issue is not resolved, the mailbox could crash the store and become quarantined again.
The following event will be logged when a mailbox is automatically quarantined:
Log Name: Application
Source: MSExchangeIS
Event ID: 10018
Task Category: General
Level: Error
Description: The mailbox for user /o=AMERICAS/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=test1 has been quarantined. Access to this mailbox will be restricted to administrative logons for the next 6 hours.
The following event will be logged when a mailbox is automatically removed from the quarantine:
Event ID: 10019
Description: The quarantine of the mailbox for user /o=AMERICAS/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=test1 has expired. Access to the mailbox has been restored.
We can also use the Get- MailboxStatistics cmdlet to see if a mailbox has been quarantined.
Get-MailboxStatistics –identity test1 | FL Isquarantined
Isquarantined : True
The store also provides the performance monitor counter: MSExchangeIS Mailbox\Quarantined Mailbox Count. This counter shows the number of quarantined mailboxes on a specific server.
Finally we can used EXTRA to trace data. Select Function from Trace Types and use the tag tagQuarantineMailbox under component Store.
Thanks to Hamza Hassen and Jonathan Runyon for putting all this information together which will help so many of us certainly…
A database availability group (DAG) is a set of up to 16 Exchange Server 2010 Mailbox servers that provide automatic database-level recovery from a database, server, or network failure. DAGs use continuous replication and a subset of Microsoft Windows failover clustering technologies to provide continuous mailbox availability. Mailbox servers in a DAG monitor each other for failures. When a Mailbox server is added to a DAG, it works with the other servers in the DAG to provide automatic, database-level recovery from database failures.
When we create a DAG, it will initially be empty, and a directory object is created in Active Directory Domain Services (AD DS) that represents the DAG. The directory object is used to store relevant information about the DAG, such as server membership information. When an administrator adds the first server to a DAG, a failover cluster is automatically created for the DAG. In addition, the infrastructure that monitors the servers for network or server failures is initiated. 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.
Exchange Server 2010 uses the same continuous replication technology found in Exchange Server 2007. However, Exchange Server 2010 combines on-site data replication (CCR) and off-site data replication (SCR) into a single Structure known as a DAG. Once servers have been added to a DAG, administrators can add replicated database copies (up to 16 in total), and Exchange Server 2010 switches between these copies automatically, as needed, to maintain availability.
This new high availability architecture also provides simplified recovery from a variety of failures (disk-level, server-level, and datacenter-level), and it can be deployed on a variety of storage types.
Exchange Server 2007 introduced a built-in data replication technology called continuous replication. Continuous replication, which was available in three forms: LCR, CCR, and SCR, significantly reduced the cost of deploying a highly available Exchange infrastructure, and provided a much improved deployment and management experience over previous versions of Exchange. Even with these cost savings and improvements, however, running a highly available Exchange Server 2007 infrastructure still required a great deal of time and expertise because the integration between Exchange and Windows failover clustering was not seamless. In addition, customers wanted an easier way to replicate their e-mail data to a remote location, in order protect their Exchange environment against site-level disasters.
Unlike Exchange Server 2007, where clustered mailbox servers required dedicated hardware, Mailbox servers in a DAG can host other Exchange roles (Client Access, Hub Transport, Unified Messaging ), providing full redundancy of Exchange services and data with just two servers.
The underlying continuous replication technology previously found in CCR and SCR remains in Exchange Server 2010 and it has been further developed to support new high availability features such as database copies, database mobility, and database availability groups. Some of these new architectural changes are briefly described below:
Several concepts used in Exchange Server 2007 continuous replication also remain in Exchange Server 2010 .These include the concepts of failover management, divergence, the use of the auto database mount dial, and the use of replication and client access networks.
Exchange Server 2010 includes a new Active Manager component that provides functionality that replaces the resource model and failover management features provided by integration with the Cluster service in older versions of Exchange. Exchange no longer uses the cluster resource model for high availability. All Exchange cluster resources provided by exres.dll no longer exist, including the construct known as a clustered mailbox server. A failover cluster is used by Exchange, but there are no cluster groups for Exchange, and there are no storage resources in the cluster. Thus, if you examine the cluster using cluster management tools, you will see only the core cluster resources (Internet Protocol address and network name, and if needed, file share witness resource). Cluster nodes and networks will also exist, but those are managed by Exchange and not cluster or cluster tools.
Active Manager runs on all Mailbox servers that are members of a DAG. There are two Active Manager Roles: primary active manager (PAM) and standby active manager (SAM). PAM is the Active Manager in a DAG that decides which copies will be active and passive. PAM is responsible for getting topology change notifications and reacting to server failures. The DAG member that holds the PAM role is always the member that currently owns the cluster quorum resource (default cluster group). If the server that owns the cluster quorum resource fails, the PAM role automatically moves to a surviving server that takes ownership of the cluster quorum resource. In addition, if you need to take the server that hosts the cluster quorum resource offline for maintenance or an upgrade, you must first move the PAM to another server in the DAG. The PAM controls all movement of the active designations between a database’s copies (only one copy can be active at any given time, and that copy may be mounted or dismounted). The PAM also performs the functions of the SAM role on the local system (detecting local database and local information store failures).
The SAM provides information on which server hosts the active copy of a mailbox database to other components of Exchange (e.g. remote procedure call RPC, Client Access service or Hub Transport). The SAM detects failures of local databases and the local information store. It reacts to failures by asking the PAM to initiate a failover (if the database is replicated). A SAM does not determine the target of failover, nor does it update a database’s location state in the PAM. It will access the active database copy location state to answer queries for the active copy of the database that it receives.
Active Manager (AM) manages the live relationship between mailbox databases and the Mailbox servers that have replicated copies of the databases.
The AM has the following functionality:
Mount and dismount databases, Provide database availability information, Provide interface for administrative tasks, Monitor for failure and Maintain database and server state information.
At any given point of time, AM assumes one of the following roles.
The PAM role holder is responsible for making all decisions that affect database availability in a DAG. Only one AM can operate as the PAM role holder at a time. All other servers in the DAG operate as SAM role holders until conditions change.
A DAG can be created using the New Database Availability Group wizard in the Exchange Management Console, or by running the New-DatabaseAvailabilityGroup cmdlet in the Exchange Management Shell.
When you create a DAG, an empty object representing the DAG with the name you specified and an object class of msExchMDBAvailabilityGroup is created in AD DS.
After a DAG has been created, you can add server to or remove servers from the DAG by using the Manage Database Availability Group wizard in the Exchange Management Console, or by using the Add-DatabaseAvailabilityGroupServer or the Remove-DatabaseAvailabilityGroupServer cmdlets in the Exchange Management Shell.
If the Mailbox server being added to a DAG is running Microsoft Windows Server 2008 and does not have the failover clustering component installed, then you must run the Add-DatabaseAvailabilityGroupServer cmdlet or use the Manage Database Availability Group wizard locally on the server being added. This is because the failover clustering component is installed on the Mailbox server when it is added to a DAG, and there is no way to install failover clustering remotely.
When the first Mailbox server is added to a DAG, the following occurs:
DAGs use a subset of failover cluster technologies, namely, the cluster heartbeat, cluster networks, and the cluster database (for storing data that changes or can change quickly, such as database state changes from active to passive or vice versa, or from mounted to dismounted and vice versa).
When creating a DAG, you will need to specify a name for the DAG no longer than 15 characters that is unique within the AD DS forest. In addition, you will also need to provide a file share witness and witness directory for use by the DAG. You do not need to create the directory ahead of time. Exchange will automatically create and secure the directory for you on the file share witness you specify. The directory should not be used for any purpose other than for the DAG witness.
The requirements for the file share witness are as follows:
We recommend that you use a Hub Transport server in the AD DS site containing the DAG. This allows the file share witness and directory to remain under the control of an Exchange administrator.
When a DAG is formed, the failover cluster that is created will initially use the Node Majority quorum mode. When the second Mailbox server is added to the DAG, the cluster quorum is automatically changes to the Node and File Share Majority quorum model. When this change occurs, the DAG will begin using the specified Universal Naming Convention (UNC) path and directory for the cluster quorum. If the witness directory does not exist, Exchange will automatically create it, and provision it with full control permissions for local administrators and the CNO computer account for the DAG.
When a server is added to a DAG, it works with the other servers in the DAG to provide automatic, database-level recovery from database, server, or network failures. When a server is removed from a DAG, it is no longer automatically protected from failures.
Before performing either procedure below, you must first verify that:
To perform this procedure, you must be assigned, either directly or using a universal security group, to the Organization Management Role Group.
1. In the console tree, expand Organization Configuration.
2. Select Mailbox, and then select the Database Availability Group tab.
3. Right-click the DAG you want to manage and then select Manage Database Availability Group Membership.
4. On the Manage Database Availability Group Membership page, you can either:
Click Add to add the local server to the DAG, select the local server, and then click OK.
Select a server from the list of members, and click the red X to remove the local server from the DAG.
5. Click Manage to perform the configured management action (adding or removing a server) on the DAG.
6. On the Completion page, the Summary states whether the operation was successful. The summary also displays the Exchange Management Shell command that was used to perform this procedure.
7. Click Finish
In this example, a Mailbox server named CONSEAMB2 is added to a DAG named CONDAG1. The DatabaseAvailablityGroupIpAddresses parameter is not used when the DAG already has been assigned IP addresses, or when you want the DAG to use DHCP to obtain an IP address.
Add-DatabaseAvailabilityGroupServer -Identity CONDAG1 -MailboxServer CONSEAMB2
In this example, a Mailbox server named CONSEAMB2 is added to a DAG named CONDAG1. CONDAG1is configured with an IP address of 10.0.0.20.
Add-DatabaseAvailabilityGroupServer -Identity CONDAG1 -MailboxServer CONSEAMB2 -DatabaseAvailablityGroupIpAddresses 10.0.0.20
In this example, a Mailbox server named CONSEAMB2 is removed from a DAG named CONDAG1. Before running this command, you must ensure that no replicated databases exist on the Mailbox server.
Remove-DatabaseAvailabilityGroupServer -Identity CONDAG1 -MailboxServer CONSEAMB2
You can use the Exchange Management Console or the Exchange Management Shell to configure the properties of a DAG, including the file share witness and directory used by the DAG.
Configurable properties include:
The Exchange Management Shell enables you to configure DAG properties that are not available in the Exchange Management Console, such as encryption and compression settings, network discovery, the Transmission Control Protocol (TCP) port used for replication, alternate file share witness settings, and datacenter activation mode.
Exchange 2010 uses only two of the four quorum models available in Windows 2008 Failover Clustering:
Using these two models, the DAG cluster provides automatic monitoring and failover only when there is a majority of votes, that is, more than half of the voters are functioning.
The quorum model used by Exchange depends on the number of mailbox servers in the DAG and is automatically updated as servers are added or removed from the DAG. When the first mailbox server is joined to the DAG cluster, the Node Majority quorum model is used. When a second server is added, the quorum model is changed to Node and File Share Majority. If a third server is added, the quorum model is changed back to Node Majority. This process continues as servers are added or removed from the DAG cluster so that the following rules emerge:
Notice that each model results in an odd number of voters. This ensures that in all cases that the cluster is able to maintain functionality as long as a majority of voters are functioning. In the case where there is an even number of servers in the DAG, if it were not for the vote of the file share witness, a failure of half of the DAG members would result in a failure of the cluster.
DAG networks support the use of encryption by leveraging the encryption capabilities of the Windows Server operating system. DAG networks use Kerberos authentication between Exchange servers. Microsoft Kerberos SSP’s Encrypt Message/Decrypt Message APIs handle encryption of DAG network traffic. Microsoft Kerberos security support provider (SSP) supports multiple encryption algorithms. The Kerberos authentication handshake picks the strongest encryption protocol supported in the list: typically Advanced Encryption Standard (AES) 256-bit, potentially with a Secure Hash Algorithm (SHA) Hash Message Authentication Code (HMAC) to maintain integrity of the data.
Encryption Settings for DAG Network Communications
Setting
Description
Disabled
network encryption is not used
Enabled
network encryption is used on all DAG networks for replication and seeding
InterSubnetOnly
network encryption is used on DAG networks on the same subnet
SeedOnly
network encryption is used on all DAG networks for seeding only
You can configure DAG network encryption by using the Set-DatabaseAvailabilityGroup cmdlet in the Exchange Management Shell. The possible encryption settings for DAG network communications are detailed in the following table.
DAG networks also support built-in compression. When compression is enabled, DAG network communication uses XPRESS, which is Microsoft’s implementation of the LZ77 algorithm.
You can configure DAG network compression by using the Set-DatabaseAvailabilityGroup cmdlet in the Exchange Management Shell. The possible compression settings for DAG network communications are detailed in the following table.
Compression Settings for DAG Network Communications
network compression is not used
network compression is used on all DAG networks for replication and seeding
network compression is used on DAG networks on the same subnet
network compression is used on all DAG networks for seeding only
The Exchange Management Shell enables you to configure DAG encryption and compression settings that are not available in the Exchange Management Console.
Microsoft Exchange Server 2010 high availability introduces a new Extensible Storage Engine mechanism known as page patching. When database corruption is caused by minor disk faults, Exchange Server 2010 page patching automatically repairs the corrupted database, using one of the database copies configured for high availability.
Exchange Server 2007 incremental reseed provided the ability to correct divergences in the transaction log stream between a source and target storage group, but did not provide a means to correct divergences in the passive copy of a database after divergent logs had been replayed. This functionality forced the need for a complete reseed of the database copy.
Exchange Server 2010 incremental reseed automatically corrects divergences in database copies using a new Extensible Storage Engine (ESE) mechanism known as Page Patching.
You can create multiple networks in a DAG, and dedicate them to client access or for replication purposes.
You can use the Exchange Management Console or the Exchange Management Shell to configure the properties of a DAG, including the file share witness share and directory used by the DAG, network encryption and compression settings, and the TCP port on each DAG network that is used for replication.
The Exchange Management Shell enables you to configure DAG properties that are not available in the Exchange Management Console, such as network discovery, the TCP port used for replication, alternate file share witness settings, and datacenter activation mode.
This section provides instructions for creating a DAG network using two different methods; using the Exchange Management Console and the Exchange Management Shell.
3. Right-click the DAG for which you want to create the new network, and then select New Database Availability Group Network.
4. On the New Database Availability Group Network page, provide configuration information for the new DAG network:
5. Click New to create the DAG network. On the Completion page, the Summary states whether the operation was successful. The summary also displays the Exchange Management Shell command that was used to perform this procedure.
6. Click Finish to exit the wizard.
In the following example, a network named DAGNetwork01 is being created with a subnet of 10.0.0.0 and a bitmask of 8 in a DAG named CONDAG1. Replication is enabled for the network, and an optional description of the network is also being added.
New-DatabaseAvailabilityGroupNetwork -DatabaseAvailabilityGroup CONDAG1 -Name DAGNetwork01 -Subnets 10.0.0.0/8 -ReplicationEnabled:$True
Each DAG network has several properties that you can configure, including the name of the DAG network, a description field for the DAG network, a list of subnets that are used by the DAG network, and whether or not the DAG network is enabled for replication.
This section provides instructions for configuring DAG network properties using two different methods: by using the Exchange Management Console, and by using the Exchange Management Shell.
1. In the console tree, navigate to Organization Configuration -> Mailbox.
2. In the result pane, on the Database Availability Group tab, select the DAG you want.
3. In the work pane, on the Networks tab, right-click the DAG network you want, and then click Properties.
4. Use the General tab to configure DAG network properties as follows:
5. Click OK
In this example, a DAG network in a DAG named CONDAG1 is being renamed from its default network of DAGNetwork01 to a new name of RepNet.
Set-DatabaseAvailabilityGroupNetwork -Name RepNet -Identity CONDAG1\DAGNetwork01
In this example, a subnet of 10.0.0.0 and subnet mask of 255.0.0.0 is being added to a DAG network named RepNet in a DAG named CONDAG1.
Set-DatabaseAvailabilityGroupNetwork -Subnets 10.0.0.0/8 -Identity CONDAG1\RepNet
The following new CmdLets are available for use in configuring DAG networks:
Set-DatabaseAvailabilityGroupNetwork
Use the Set-DatabaseAvailabilityGroupNetwork cmdlet to configure a network for a DAG. You can configure a variety of network properties, such as:
Get-DatabaseAvailabilityGroupNetwork
Use the Get-DatabaseAvailabilityGroupNetwork cmdlet to display configuration and state information for a DAG network. State information is returned for subnets and for network interfaces
New-DatabaseAvailabilityGroupNetwork
Use the New-DatabaseAvailabilityGroupNetwork cmdlet to manually create a network for a DAG. After you create DAG networks, you can use them for log shipping and seeding for mailbox databases hosted on servers in the DAG, or use them for client access to mailbox databases in the DAG.
Remove-DatabaseAvailabilityGroupNetwork
Use the Remove-DatabaseAvailabilityGroupNetwork cmdlet to remove a network from a DAG.
I’d like to express a HUGE thanks to Niyaz Mohamed for compiling content and providing screenshots, which hopefully will help loads of people on DAGs.
It was recently published an amazing article about DPM licensing… So many customers come to me asking me all of these questions regarding licensing, and because on my role we don’t deal with that we always end up kind of passing the question to other people in Microsoft…
With this article from the so well known Jason Buffington my life and others is easier now on these tricky subjects…
A small summary is here, however if you want to know the full story please visit Jason’s Article:
If you already have ECAL, then you already have the Client licenses for DPM 2010 and can begin protecting your Windows client machines (and probably not have to renew whatever third-party backup software is currently backing up your workstations).
If you already have the System Center SMSE or SMSD suites, then you can protect your Windows application, file and virtualization servers because you already own Enterprise licenses for DPM. See money saving note above.
And if you are a midsized organization that has been excitedly looking forward to SC Essentials 2010, then you will soon be able to purchase the SC Essentials Plus suites for both your clients and your servers.
I hope this was helpful…
Another great achievement on the Exchange Universe… Exchange Server 2007 Service Pack 3!!!!
I am very pleased to let you all know that Exchange Server 2007 SP3 is available for download. As we highlighted in Updates to the Exchange Supportability Matrix this past November, this third service pack for Exchange 2007 enables Exchange 2007 to be installed on the Windows Server 2008 R2 version of the operating system. We heard you loud and clear that this is enormously important to our Exchange 2007 customers, so we worked quickly to deliver SP3 in order to meet this requirement.
Download Exchange 2007 SP3 here…
Keep the feedback coming and for those of you evaluating all the good stuff packed into Exchange Server 2010, don't miss the beta of Exchange Server 2010 SP1. You can read about SP1 here…
Kevin Allison General Manager - Exchange Customer Experience
In conversation with a good friend, David Rankin, also known as The Highlander, and because I was in the middle of a Data Protection Manager 2007 Health Check and needed to check builds, versions, patches applied etc. he kindly help providing me his wonderful list which I am publishing here now! It is not rocket science but the fact that its all in one place makes the difference!
Build Number
Release Date
KB Article
RTM
2.0.5820.0
01/11/2007
N/A
Rollup Mar’08
2.0.8037.0
24/03/2008
950082
Rollup Apr’08
2.0.8102.0
24/04/2008
951557
Feature Pack
2.0.8107.0
18/07/2008
949779
Rollup Jul'08
2.0.8111.0
07/10/2008
954641
SP1
2.0.8793.0
19/12/2008
959605
SP1 Hot-Fix
2.0.8811.0
16/01/2009
961502
Rollup Feb'09
2.0.8824.0
16/02/2009
963102
Rollup Apr'09
2.0.8836.0
14/04/2009
968579
Rollup Jun'09
2.0.8844.0
30/06/2009
970867
Rollup Aug'09
2.0.8851.0
28/08/2009
970868
Rollup Oct'09
2.0.8861.0
23/10/2009
976542
Rollup Mar’10
2.0.8864.0
29/03/2010
979970
If any other patches appear meanwhile I’ll try to keep it up to date, in order every single one of you desperate protectors in a crusade to find the builds have a nice place to go… and reliable!!!
Thanks David!!