Database move failed because content index in a failed state

1st restart Microsoft Exchange Search Indexer service on the node that has the active DB

2nd use Update-MailboxDatabaseCopy - catalogonly -identity dbname\servername on the node that has the passive DB

Add Permissions for Client Users to Access Public Folder Content

http://technet.microsoft.com/en-us/library/aa998834.aspx

When adding client permissions, you can either use predefined permission roles (which consist of specific access rights) or you can customize permissions by manually applying the available access rights. To specify the permissions for the client user, you can use the Add-PublicFolderClientPermission cmdlet or the AddUsersToPFRecursive.ps1 user management script.

Looking for other management tasks related to public folder permissions? Check out Managing Public Folder Permissions.

Note:
If a client user already has a specific access right to a public folder, you can't add the same access right again. Therefore, if you use the AddUsersToPFRecursive.ps1 script, and the user already has one of the access rights that you're trying to grant, a warning will appear stating that the current access rights will be removed before new access rights are granted.

Use the Shell to add public folder permissions for a client user

You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the "Public folder client permissions" entry in the Mailbox Permissions topic.

Note:
You can't use the EMC to add public folder permissions for a client user.

This example adds Publishing Editor permissions for the user Kim to access the public folder West Coast.

Add-PublicFolderClientPermission -Identity "\Marketing\West Coast" -AccessRights PublishingEditor -User Kim

For detailed syntax and parameter information, see Add-PublicFolderClientPermission.

Use the AddUsersToPFRecursive.ps1 script to add client access rights to a public folder

You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the "Public folder client permissions" entry in the Mailbox Permissions topic.

This example adds Reviewer permissions for the user David to access the top-level public folder Sales and all of the public folders under it.

AddUsersToPFRecursive.ps1 -TopPublicFolder "\Sales" -User "David" -Permission Reviewer

For more information about how to use public folder management scripts, see Scripts for Managing Public Folders in the Exchange Management Shell.

Archive in Exchange 2010

http://www.msexchange.org/player.asp?AYGsoEsC

Extensible Storage Engine (ESE) explained

Extensible Storage Engine (ESE)


The core storage technology of Microsoft Exchange Server and Active Directory is called Exchange Extensible Storage Engine (ESE), also known as JET Blue. It is an Indexed Sequential Access Method (ISAM) data storage technology whose purpose is to allow applications to store and retrieve data via indexed and sequential access. Window Mail and Desktop Search in the Windows Vista operating system also makes use of ESE to store indexes and property information respectively.


To highlight basic features of ESE –

• Microsoft JET is an advanced 32-bit multithreaded database engine that combines speed and performance with other advanced features to enhance transaction-based processing capabilities.
• A crash recovery mechanism is provided so that data consistency is maintained even in the event of a system crash.
• Transactions in ESE are highly concurrent, making ESE suitable for server applications. ESE caches data intelligently to ensure high performance access to data.
• In addition, ESE is lightweight making, optimized for fast data storage and retrieval.

Note:
The ESE Runtime (ESENT.DLL) has shipped in every Windows release since Windows 2000, with the native x64 version of the ESE runtime shipping with x64 versions of Windows XP and Windows Server 2003. The 64 bit edition support started with Exchange 2007; up to Exchange 2003, ESE runtime was shipped with only the 32 bit edition.


Exchange Information Store


The information store, which is the key component for database management in Exchange Server, is actually two separate databases. The private information store database, Priv.edb, manages data in user mailboxes. The public information store, Pub.edb, manages data in public folders.


Private store consist of .edb and .stm files. The .edb file is the main repository for the mailbox data. The .edb file is accessed by ESE directly. The fundamental construct of the .edb file is the b-tree structure. The ESE 4 KB pages are arranged into tables that form a large database file containing Exchange data.


The .stm or streaming media file is used in conjunction with the .edb file to comprise the Exchange database. Both files together make up the database, and as such, they should always be treated as a single entity.
The information store works with the Messaging Application Programming Interface (MAPI) and the database engine to ensure that all user actions are recorded on the server's hard disk.

Exchange Autodiscover

When Microsoft released Exchange Server 2007, one of the new features it included was Autodiscover. Autodiscover allows you to automatically configure Outlook 2007 clients, but, there is a lot more behind the Autodiscover functionality. When you have issues with the Out-of-Office or Free/Busy information in Outlook 2007 in combination with Exchange Server 2007 (or Outlook 2010 and Exchange Server 2010) it is likely that it is caused by a misconfiguration in the Autodiscover configuration. To make things more complex, the SSL certificates are involved here as well.

Note:
The Autodiscover process for Exchange 2007 and Outlook 2007 is practically the same as for Exchange 2010 and Outlook 2010. In this article I will use Exchange 2010 and Outlook 2010.

Autodiscover information is stored in a so called SCP or Service Connection Point. You can view this SCP using Active Directory Sites and Services after you have enabled the “View Services Node” option.

When installing the Client Access Server (Autodiscover is part of this Server Role) the SCP is automatically created in Active Directory and configured with the default values. If you have multiple CAS Servers there will be multiple SCP’s as well.

When Outlook 2007 is installed on a domain joined workstation then the Outlook client will query Active Directory for the Autodiscover information. Active Directory will return a list of SCP’s and the Outlook client will automatically select the first SCP in this list. Using the information found in the SCP the Outlook client will contact the Client Access Server for its configuration information and the Outlook client will be configured automatically.

Non-domain clients are a bit trickier to configure since they will not query the Active Directory. Because of this non-domain clients try to retrieve information using the Autodiscover website. The FQDN that the Outlook client will use is based on the SMTP address that is used when starting the Outlook 2010 client the first time. So, when an e-mail address Bob@blogger.com is entered, the Outlook client will start trying to connect to the Client Access Server using HTTPS. There are several URL’s that Oulook will use, but the most important is https://autodiscover.Blogger.com.

Please be aware that this is the (Internet facing) Client Access Server. So besides the normal Outlook Web Access URL like https://webmail.blogger.com the same Client Access Server is also contacted using https://autodiscover.blogger.com.  This is exactly the reason a Unified Communications (UC) or SAN certificate is needed. 

Note: You can actually use a single certificate for for both OWA and Outlook Anywhere.  Please see my other blog on SSL for both OWA and Outlook Anywhere

Besides the possibility to configure Outlook 2007 and higher clients using the Autodiscover process there’s more information, in this process.

• Out-of-Office information
• Availability Services
• Offline Address Book download information
• Unified Messaging information
• Exchange 2010 personal archive (for Outlook 2010 clients only)

In Exchange Server 2010 the properties related to these settings are configured during setup of the Client Access Server when entering the “this is an external facing Client Access Server” option. When you do not select this option, or in Exchange Server 2007 you have to configure these properties manually using the Exchange Management Shell:

Set-OWAVirtualDirectory –Identity 2K10HUBCAS02\OWA (default web site) 
-ExternalURL https://webmail.blogger.com/OWA

Set-OABVirtualDirectory –Identity 2K10HUBCAS02\OAB (default web site) 
-ExternalURL https://webmail.blogger.com/OAB

Set-WebServicesVirtualDirectory –Identity 2010CASUB02\EWS (default web site) -ExternalURL https://webmail.blogger.com/ews/exchange.asmx

Set-ActiveSyncVirtualDirectory –Identity 2K10HUBCAS02\Microsoft-Server-ActiveSync (default web site) 
-ExternalURL https://webmail.blogger.com/Microsoft-Server-ActiveSync

This setting is only valid for Exchange Server 2010:

Set-ECPVirtualDirectory –Identity 2K10HUBCAS02\ECP (default web site) 
-ExternalURL https://webmail.blogger.com/ECP

The last step is to configure the external DNS for both the webmail hostname as well as the Autodiscover hostname as they need to point to the external facing Client Access Server.

When you start up Outlook 2007/2010 you can automatically configure your profile, If all goes well you should be able to set your out-of-office settings and check other mailboxes free/busy information.

If you want to check that this is working correctly you can start Outlook and you will see the small Outlook icon in the system tray. Press the Control key together with a right mouse click, there you have two options:

• Connection Status
• Test E-mail AutoConfiguration

The connection status shows the various connections that are initiated between the Outlook client and the Exchange server. 
With the ‘Test E-mail AutoConfiguration’ there is the possibility to test the Autodiscover configuration.  Fill in your e-mail address and password, and to check the Autodiscover functionality only deselect the “Use Guessmart” and “Secure Guessmart Authentication”. When you click Test the Outlook client will check the full Autodiscover functionality and the results will be shown on the Results tab.


Another way, especially when troubleshooting your Autodiscover configuration, is the Remote Analyzer that is available on the Internet. Go on to www.testexchangeconnectivity.com. This site is developed by a few guys from the Microsoft Exchange Product Team. This site can help you troubleshoot all kinds of remote connectivity issues and gives detailed results after checking.

Exchange 2010 Database Availability Groups (DAG)

Please check out www.kaztechsolutions.co.uk for more of my technical posts, alternately please call us on 01932 268289. 

With Exchange 2010, we no longer have the concept of Local Continuous Replication (LCR), Single Copy Clusters (SCC), Cluster Continuous Replication (CCR) or Standby Continuous Replication (SCR), well this is not entirely true only LCR and SCC have been removed from the Exchange Server product. CCR and SCR have been combined and have evolved into a more unified high availability framework in which the new Database Availability Group (DAG) act as the base component. This means that no matter if you are going to deploy a local or site-level highly available or disaster recoverable solution, you use a DAG. 


So what’s interesting about a DAG then?


Limited dependency on Windows Failover Clustering - A DAG only uses a limited set of the clustering features provided by the Windows Failover Clustering component. DAG uses the cluster database, heartbeat, and file share witness functionality.


Incremental deployment - Because DAGs still use some of the WFC components such as the cluster database, heartbeat and file share witness functionality, Windows Server 2008 SP2 or R2 Enterprise edition is required in order to be able to configure Exchange 2010 Mailbox servers in a DAG. But Exchange 2010 supports an incremental deployment approach meaning that you don’t need to form a cluster prior to installing Exchange 2010. You can install the Exchange 2010 Mailbox servers, and then create a DAG and add the servers and any databases to the DAG when needed.


Co-existence with other Exchange roles - With CCR you could not install other Exchange Server roles on the mailbox servers (cluster nodes) that were protected using CCR. With DAG, a mailbox server part of a DAG can have other Exchange roles installed. This is especially beneficial for small organizations. Because now that a DAG protected Mailbox server can co-exist with other Exchange roles, it also means that you can have a fully redundant Exchange 2010 solution with only two machines dedicated as Exchange servers. Of course, you need to configure a file share witness, but this could be any in your environment.


Managed 100% via Exchange tools - With CCR in Exchange 2007, you had to configure and manage CCR clusters using a combination of Exchange and cluster management tools. With DAGs in Exchange 2010, you no longer need to use cluster management tools for either the initial configuration or management. You can manage DAGs fully using the Exchange Management tools. 


Replication at the database level - In order to support the new DAG feature, databases in Exchange 2010 has now been moved to the organizational level instead of the server level where they existed in Exchange 2007 and earlier versions. This also means Exchange 2010 does not have the concept of storage groups any longer. Now there are databases and a log stream associated with each database. One drawback of CCR was that if only one database failed on the active node, a fail-over of all active databases existing on the clustered mailbox server were moved to the passive CCR node. This meant that all users on that had a mailbox stored on the respective CMS were affected.

Support for up to 16 members in each DAG - Now that you can add up to 16 Mailbox servers to a DAG and potentially have 16 copies of each Mailbox database, Exchange 2010 had to support a larger number of mailbox databases than Exchange 2007 did. So the maximum limit has now been upped from 50 to 100 Mailbox database in the Exchange 2010 Enterprise edition. However, the Standard edition still only supports up to 5 databases per Mailbox server.

Switch/Fail-overs much quicker than in the past - Because of the improvement made with Exchange 2010 DAG, we will now experience much quicker switches and fail-overs (*-overs) between mailbox database copies. They will typically occur in under 30 seconds, compared to several minutes with CCR in Exchange 2007. In addition, because Outlook MAPI clients now connect to the RPC Client Access service on the Client Access Servers, end users will rarely notice a *-over occurred. You can read more about the RPC Client Access service in a previous articles series of mine here.

Go backup-less with +3 DB copies - When having 3 or more copies of a mailbox database, it is programmed to backup-less. This means that you basically enable circular logging on all mailbox databases protected by DAG, and no longer perform backups as we know them. This thinking of course requires enterprise organizations to change their mindset in regards to how they think mailbox databases should be protected.

Support for DAG members in separate AD sites - Unlike CCR cluster nodes, you can have DAG member servers located in different Active Directory sites. This should be a welcome addition to those of you who do not have the option of using the same AD site across physical locations (datacenters). It should be noted though, that you cannot place Mailbox servers protected by the same DAG in different domains within your Active Directory forest.

Log shipping via TCP - In Exchange 2007, the Microsoft Exchange Replication Service copied log files to the passive database copy (LCR), passive cluster node (CCR) or SCR target over Server Message Block (SMB), which meant you needed to open port 445 in any firewall between the CCR cluster nodes (typically when deploying multisite CCR clusters) and/or SCR source and targets. Those of you who work for or with a large enterprise organization know that convincing network administrators to open port 445/TCP between two datacenters is far from a trivial exercise. With Exchange 2010 DAG, the asynchronous replication technology no longer relies on SMB. Exchange 2010 uses TCP/IP for log file copying and seeding and, even better, it provides the option of specifying which port you want to use for log file replication. By default, DAG uses port 64327, but you can specify another port if required.

Log file compression - with Exchange 2010 DAGs you can enable compression for seeding and replication over one or more networks in a DAG. This is a property of the DAG itself, not a DAG network. The default setting is InterSubnetOnly and has the same settings available as those of the network encryption property.

Log file encryption - Exchange 2010 DAG supports the use of encryption whereas log files in Exchange 2007 are copied over an unencrypted channel (unless IPsec has been configured). More specifically, DAG leverages the encryption capabilities of Windows Server 2008—that is, DAG uses Kerberos authentication between each Mailbox server member of the respective DAG. Network encryption is a property of the DAG itself, not the DAG network. Settings for a DAG's network encryption property are: Disabled (network encryption not in use), Enabled (network encryption enabled for seeding and replication on all networks existing in a DAG), InterSubnetOnly (the default setting meaning network encryption in use on DAG networks on the same subnet), and SeedOnly (network encryption in use for seeding on all networks in a DAG).

Up to 14 day lagged copies - With Standby Continuous Replication which were included in Exchange 2007 SP1, the concept of lagged database copies were introduced. With this feature we could delay the time for when log files that were copied to the SCR target should be replayed into the databases on the SCR target. We also had the option of specifying a so called truncation lag time, which was an option which allowed us to delay the time for when log files that had been copied to the SCR target and replayed into the cop of the database should be truncated. With both options we could specify a lag time of up to 7 days. With Exchange 2010 DAG, we can now specify a truncation lag time of up to 14 days, which is extra interesting when you choose to go backup-less.

Seeding from a DB copy - Unlike CCR in Exchange 2007, we can now perform a seed by specifying a database copy as the source database. This means that a new seed or a re-seed of an existing mailbox database no longer has any impact on the active database copy.

Improved Transport Dumpster - The transport dumpster we know from Exchange 2007 has also been improved, so that messages are re-delivered even when a lossy database failover occurs between databases copies stored in different Active Directory sites. In addition to this, when all messages have been replicated to all database copies, they will be deleted from the transport dumpster.

I thought i'd better make it aware that you cannot use DAG on a PF database.  Public folder databases must be protected using traditional public folder replication mechanisms. The positive thing about this is that we no longer are limited to only one public folder store in the Exchange organization, if it is stored on a DAG member server.

Source: MSExchange.org