Tuesday, July 30, 2013

Exchange Cmdlet Extension Agents

Cmdlet Extension Agents are Exchange components that are invoked by cmdlets when the cmdlets run. These agents are available on any server role and, as the name suggests, they extend the capabilities of cmdlets that invoke them by assisting in processing data or performing additional actions based on the requirements of the cmdlet. They can be used to modify, replace or extend functionality of any Exchange cmdlet. For example, they can override a value provided by a user, perform actions outside of the cmdlet workflow, provide a value for a required parameter that was not provided, etc.

An example of such functionality is when creating a new mailbox. If an administrator does not specify a mailbox database when creating a new mailbox with Exchange 2007, the process fails. However, in Exchange 2010 and 2013, the New-Mailbox cmdlet invokes the Mailbox Resources Management agent whenever it is run. If a database is not specified, this agent automatically determines a suitable database on which to create the new mailbox and inserts that value into the Database parameter.

Note that cmdlet extension agents can only be invoked by Exchange 2010 and 2013 cmdlets as they are a feature introduced in Exchange 2010. Scripts cannot invoke these agents directly but if they contain Exchange 2010/2013 cmdlets, those cmdlets continue to call the cmdlet extension agents.

Unfortunately, cmdlet extension agents are not a well-known feature and, therefore, are often overlooked or ignored. A good example is the requirement that many organizations have to customize things immediately after creating a mailbox. They often develop custom scripts or even buy 3rd-party applications to achieve this, when cmdlet extension agents can very well be used to achieve most, if not all, these requirements.

In this article I use a particular cmdlet extension agent, called Scripting agent, in order to customize the mailbox provisioning process. Specifically, when a new mailbox is created, the agent will automatically configure archiving, permissions, Single Item Recovery, ActiveSync, other user attributes such as country and city, and send a welcome e-mail to the user.

To continue reading, please check the Cmdlet Extension Agents article on MSExchange.org.
 

Friday, July 26, 2013

Hyper-V Replica with Exchange Supportability

If you are considering whether to use Hyper-V Replica with Exchange, remember that Exchange has its own disaster recovery and site awareness capabilities that should be used instead.
 
Hyper-V Replica is not needed and is not supported because of problems with Exchange roles being forced back in time in the event of an unplanned failover.

DirSync Error "Microsoft.Online.PasswordSynchronization.Cryptography.dll Could Not Be Loaded"

The Directory Synchronization Tool (DirSync) is supported on Windows Server 2008 SP1 and higher. However, the Password Sync feature introduced in the latest version will not function correctly if installed on an OS older than Windows Server 2008 R2 SP1 (Windows Server 2008 R2 SP1 itself is supported).

When this is the case, you will receive the following error:
Password synchronization failed for domain: "your domain".
Details: System.IO.FileLoadException: A procedure imported by 'Microsoft.Online.PasswordSynchronization.Cryptography.dll' could not be loaded.

To resolve this issue, install the Directory Sync tool on a supported Windows Server OS.

Saturday, July 13, 2013

eDiscovery During Exchange 2010/2013 Coexistence

When transitioning from Exchange 2010 to 2013, you should be aware of the following in regarding to the eDiscovery feature during the coexistence period.
 
Administrator audit logs and metadata for eDiscovery searches (not search results) are stored in a system (arbitration) mailbox name SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9} with the display name of Microsoft Exchange.
 
For eDiscovery to work during the period while Exchange 2010 and 2013 coexist (and after the transition), you need to move this system mailbox to an Exchange 2013 server. You can do this using the EAC or through PowerShell:
Get-Mailbox -Arbitration "SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}" | New-MoveRequest -TargetDatabase “Exchange_2013_database”

When the move finishes, to check if everything went OK, run the following cmdlet and ensure the Server and Database values refer to Exchange 2013:
Get-Mailbox -Arbitration “SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}” | FL ServerName, Database

If you do not move this system mailbox to Exchange 2013, the following issues will occur when Exchange 2010 and Exchange 2013 coexist in your Exchange organization:
  • Exchange 2013 tasks are not saved to the administrator audit log. When you run the Search-AdminAuditLog cmdlet or try to export the administrator audit log in the EAC, you will receive an error that says you cannot create an administrator audit log search because this system mailbox is located on a server that is not running Exchange 2013. A Microsoft Exchange error with an Event ID of 5000 is also logged in the Windows Application log each time a command is run;
  • You cannot run eDiscovery searches using the EAC or the Shell in Exchange 2013. Mailbox searches can be created and queued, but they cannot be started. An error with an Event ID of 6 is logged in the MsExchange Management log, stating that the Start-MailboxSearch cmdlet failed. However, you can search mailboxes using the Shell and the Exchange Control Panel in Exchange 2010.

Tuesday, July 2, 2013

Exchange 2013 “Please restart the Microsoft Information Store service”

With Exchange 2013 Cumulative Update 1, administrators will notice that every time a new database is added, they are prompted to restart the Information Store service. Although this was also true in Exchange 2013 RTM, the difference was that before administrators did not receive this restart warning.
 
As we saw previously, Exchange 2013 introduced the new Managed Store, which uses a different memory management model than previous editions of Exchange. With a Store Worker Process for each active and passive database present on a server, it is now required to restart the Information Store service because the Store only determines the amount of memory that it will use to manage each database when it starts (which happens when the server starts or when the Information Store service is restarted).
 
In previous editions, Exchange typically seizes as much memory as it is available on a server and uses that memory to cache Store data. In Exchange 2013 this approach was revised and it now calculates how much memory it should use and makes it available to worker processes (obviously active databases are assigned more memory than passive databases). However, this new memory management approach depends on knowing how many worker processes are in use. When databases are added from a server, the Store does not re-calculate the amount of RAM for each worker process dynamically. This does not mean that you cannot mount the new database – it means caching will not be as efficient as it should be until the next time the Store process restarts and memory use is adjusted.

This might be seen as a big drawback of Exchange 2013, and it might even change in the future, but adding or removing databases should not happen that often, so the impact should not be that massive.