Exchange Team news

System Center Operation Manager

lundi 13 juin 2011

Gestion des boites aux lettres deconectées via PowerShell / Managing Disconnected Exchange Mailboxes with PowerShell

Source :

Gestion des boites aux lettres deconectées via PowerShell

Managing Disconnected Exchange Mailboxes with PowerShell

by Mike Pfeiffer on June 16, 2010

Source : http://www.mikepfeiffer.net/2010/06/managing-disconnected-exchange-mailboxes-with-powershell/

Having worked with Exchange 2007/2010 and PowerShell for some time now, I've developed a number of functions that I use to simplify particular "hard to type" commands. This has made for some good scripting exercises, but more importantly, it has served as a great time saver when performing certain routine tasks. In this post, I am going to share some code that I use to manage disconnected Exchange mailboxes.

Finding Disconnected Mailboxes

The first function is called Get-DisconnectedMailbox and the name is pretty much self explanitory. This function will give you a list of all disconnected mailboxes on each of your mailbox servers. Take a look at the following code:

function Get-DisconnectedMailbox {     [CmdletBinding()]     param(         [Parameter(Position=0, Mandatory=$false)]         [System.String]         $Name = '*'     )      $mailboxes = Get-MailboxServer     $mailboxes | %{         $disconn = Get-Mailboxstatistics -Server $_.name | ?{ $_.DisconnectDate -ne $null }         $disconn | ?{$_.displayname -like $Name} |             Select DisplayName,             @{n="StoreMailboxIdentity";e={$_.MailboxGuid}},             Database     } }

Note: If you've recently deleted a mailbox, but it's not showing up when running Get-DisconnectedMailbox, you may need to force Exchange to recognize this by running the Clean-MailboxDatabase cmdlet.

Running the function without specifying a user name will return all disconnected mailboxes:

To find a particular disconnected mailbox, just type the function name, followed by the users display name. For example, to determine the disconnected mailbox information for a user named Blanca Jacobs you could would run this command:

Get-DisconnectedMailbox "Blanca Jacobs"

The name parameter will accept wildcards. For example: Get-DisconnectedMailbox M* would give you all disconnected mailboxes starting with the letter "M".

Purging Disconnected Mailboxes

You purge mailboxes using the Remove-Mailbox cmdlet, specifying the StoreMailboxIdentity and Database for the disconnected mailbox in question. For a good example of this, check out Nitin Gupta's post on removing disconnected mailboxes.

In an effort to simplify the purging of disconnected mailboxes, I wrote the Remove-DisconnectedMailbox function that is designed to work with Get-DisconnectedMailbox. Here is the code:

function Remove-DisconnectedMailbox {     [CmdletBinding(SupportsShouldProcess=$true)]     param(         [Parameter(Position=0, ValueFromPipelineByPropertyName=$true, Mandatory=$true)]         [System.String]         $StoreMailboxIdentity,         [Parameter(Position=1, ValueFromPipelineByPropertyName=$true, Mandatory=$true)]         [System.String]         $Database         )      process {         Remove-Mailbox @PSBoundParameters     } }

This allows you to easily purge all disconnected mailboxes returned from Get-DisconnectedMailbox by piping the output to Remove-DisconnectedMailbox. You can also purge one disconnected mailbox at time, as shown here:

Get-DisconnectedMailbox "Bill Jones" | Remove-DisconnectedMailbox -Confirm:$false

Notice the use of -Confirm:$false in the above command. Since this is an advanced function, we can take advantage of ShouldProcess, which allows functions to use common cmdlet parameters such as -Confirm and -WhatIf.

If you look at the code closely, you'll notice that this function is essentially a specialized wrapper for the Remove-Mailbox cmdlet. I use splatting with the $PSBoundParameters variable to automatically bind all of the function parameter values to Remove-Mailbox.

Connecting Disconnected Mailboxes

Of course, you can also use the Get-DisconnectedMailbox cmdlet in conjunction with the built-in Connect-Mailbox cmdlet to reconnect a mailbox to a user account.

For example, here's how you would connect a disconnected mailbox for a user named Bradford Boyer:

Get-DisconnectedMailbox "Bradford Boyer" | %{Connect-Mailbox -Identity $_.StoreMailboxIdentity -Database 'DB1' -User 'contoso\bboyer' -Alias 'bboyer'}

As you can see in the above example, you provide the StoreMailboxIdentity, Database, User and Alias to the Connect-Mailbox cmdlet. If you'd like to do this manually, you can determine the StoreMailboxIdentity of the disconnected mailbox using the Get-MailboxStatistics cmdlet.

mercredi 8 juin 2011

Understanding Memory Configurations and Exchange Performance

Understanding Memory Configurations and Exchange Performance
Source : http://technet.microsoft.com/en-us/library/dd346700.aspx

Memory configurations for Exchange 2010 servers based on installed server roles

Exchange 2010 server role Minimum supported Recommended maximum

Edge Transport

4 GB

1 GB per core (4 GB minimum)

Hub Transport

4 GB

1 GB per core (4 GB minimum)

Client Access

4 GB

2 GB per core (8 GB minimum)

Unified Messaging

4 GB

2 GB per core (4 GB minimum)

Mailbox

4 GB

4 GB plus 3-30 MB additional memory per mailbox:

The total required memory is based on the user profile and database cache size. For more information about how to determine the total required memory, see Understanding the Mailbox Database Cache.

Client Access/Hub Transport combined role (Client Access and Hub Transport server roles running on the same physical server)

4 GB

2 GB per core (8 GB minimum)

Multiple roles (combinations of Hub Transport, Client Access, and Mailbox server roles)

8 GB

4 GB plus 3-30 MB additional memory per mailbox:

The total required memory is based on the user profile and database cache size. For more information about how to determine the total required memory, see Understanding the Mailbox Database Cache.

The Edge Transport and Hub Transport server roles don't require substantial quantities of memory to perform well in optimal conditions. Generally, 1 GB of RAM per processor core (4 GB minimum total) is sufficient to handle all but the most demanding loads. Most deployments will be optimally configured with the recommended memory configuration of 1 GB per processor core (4 GB minimum total).

In general, memory utilization on Client Access servers has a linear relationship with the number of client connections and the transaction rate. Based on the current recommendations of 2 GB per core processor and memory configurations, a Client Access server will be balanced in terms of memory and processor utilization, and it will become processor-bound at approximately the same time it becomes memory- bound.

These recommendations are based on the Exchange 2010 feature, RPC Client Access. This feature requires a larger memory and processor configuration to manage the increased loads placed on the Client Access server role.


Exchange Server 2010 Design and Architecture at Microsoft

Exchange Server 2010 Design and Architecture at Microsoft : http://technet.microsoft.com/en-us/library/ff829232.aspx

Les mauvaises conceptions de la Haute Disponibilité sur Exchange 2010/Exchange 2010 High Availability Misconceptions Addressed

Source : http://blogs.technet.com/b/exchange/archive/2011/05/31/exchange-2010-high-availability-misconceptions-addressed.aspx

The recommended maximum number of processor cores we state that you should have for a Client Access or Hub Transport server. It’s 12. Memory guidance for Client Access servers is 2 GB per core and for Hub Transport it is 1 GB per core. Thus, if you have a 12-core Client Access server, you’d install 24 GB of memory, and if you had a 12-core Hub Transport server, you would install 12 GB of memory.

Exchange 2010 High Availability and Site Resilience Terminology

But first let’s start with some terminology to make sure everyone understands the components, settings and concepts I’ll be discussing.

TermDescriptionHow Configured
Activation The process of making a passive database copy into an active database copy. Move-ActiveMailboxDatabase cmdlet
Activation Suspended or Blocked The process of suspending or blocking a single database or an entire server from automatic activation. Suspend-MailboxDatabaseCopy or Set-MailboxServer cmdlets

Active Manager

An internal Exchange component which runs inside the Microsoft Exchange Replication service that is responsible for failure monitoring and corrective action within a DAG. N/A
Alternate Witness Directory An optional property of a DAG that specifies the name of the directory that is shared on the Alternate Witness Server for quorum purposes. Set-DatabaseAvailabilityGroup cmdlet or Exchange Management Console (EMC)
Alternate Witness Server An optional property of a DAG that specifies the witness server that will be used by DAG after you have performed a datacenter switchover. Set-DatabaseAvailabilityGroup cmdlet or EMC
Attempt Copy Last Logs (ACLL) A process performed during Best Copy Selection in which the system attempts to copy from the original active database copy any log files missing by the passive copy selected for activation. N/A
AutoDatabaseMountDial Property setting of a Mailbox server that determines whether a passive database copy will automatically mount as the new active copy, based on the number of log files missing by the copy being mounted. Set-MailboxServer cmdlet
Best Copy Selection (BCS) A process performed by Active Manager to determine the best passive mailbox database copy to activate either in response to a failure affecting the active mailbox database copy, or as a result of an administrator performing a targetless switchover. N/A
Continuous Replication Block Mode A form of continuous replication that replicates blocks of ESE transaction data between the ESE log buffers on the active mailbox database copy to replication log buffers on one or more passive mailbox databases copies. N/A – not configurable
The system automatically switches between file mode and block mode based on the passive copy’s ability to keep up with continuous replication.
Continuous Replication File Mode A form of continuous replication that replicates closed transaction log files from the active mailbox database copy to one or more passive mailbox database copies. N/A – not configurable
Datacenter In Exchange, typically this refers to an Active Directory site; however, it can also refer to a physical site. In the context of this blog post, datacenter equals Active Directory site. N/A
Datacenter Activation Coordination (DAC) Mode A property of the DAG setting that, when enabled, forces starting DAG members to acquire permission in order to mount databases. Set-DatabaseAvailabilityGroup cmdlet
Datacenter Activation Coordination Protocol (DACP) A bit in memory (0 or 1) that is used by DAG members in DAC mode. A value of 0 indicates the DAG member cannot mount databases; a value of 1 indicates the DAG member can mount active databases that it currently hosts. N/A – Automatically used when the DAG is configured for DAC mode.
Datacenter Switchover The manual process performed to activate the Exchange components of a standby datacenter and restore Exchange service and data after failure of a primary datacenter. Process documented in Datacenter Switchovers.
Failover The automatic process performed by the system in response to a failure affecting one or more active mailbox database copies. N/A – Happens automatically by the system; although you can activation-block or suspend individual mailbox database copies or an entire DAG member.
File Share Witness A cluster-managed resource that is created and use when the cluster uses the node and file share majority quorum model. N/A – Automatically created and destroyed by Exchange, as needed, based on the number of DAG members.
Incremental Resync A built-in process that corrects certain forms of divergence that occur between mailbox database copies in a DAG (typically between a new active copy and the previous active copy). N/A – Happens automatically by the system
Lossy Failover A database failover condition in which the passive copy being activated is mounted with one or more log files missing. Partially controlled via AutoDatabaseMountDial
Primary Active Manager (PAM) An Active Manager role held by a single DAG member at any given time that is responsible for responding to failures an initiating corrective action in the form of a database or server failover. N/A – The PAM role is automatically held by the DAG member that owns the cluster’s core resource group.
Quorum Has a dual meaning:
  • Refers to the consensus model used by members of a cluster to ensure consistency within the cluster. Exchange uses two of the four cluster quorum models:
    • Node Majority (for DAGs with an odd number of members)
    • Node and File Share Majority (for DAGs with even number of members)
  • Refers to the data (e.g., “quorum data”) shared by the cluster members that is used to maintain quorum
N/A – Automatically configured by Exchange, as needed, based on the number of DAG members.
RPCClientAccessServer A property of a Mailbox database that specifies the Client Access server or Client Access server array through which MAPI/RPC clients (Outlook 2003, Outlook 2007, Outlook 2010) access their mailboxes on that database. Set-MailboxDatabase cmdlet
Site Active Directory Site, which is defined as one or more fast, reliable and well-connected (< 10 ms latency) subnets. N/A – Configured outside of Exchange by using Active Directory Sites and Services
Split Brain A condition in which multiple cluster members believe they are authoritative for one or more common resources. N/A
Standby Active Manager (SAM) An Active Manager role held by all DAG members that do not hold the PAM role that is responsible for monitoring for local failures and responding to queries from CAS and Hub as to the location of the user’s mailbox database. N/A – The SAM role is automatically held by the DAG members that do not own the cluster’s core resource group.
StartedMailboxServers A list of DAG members that are currently operational and functional. Automatically added to list during normal operations
Manually added to list as part of re-activation of primary datacenter using Start-DatabaseAvailabilityGroup cmdlet
StoppedMailboxServers A list of DAG members that have been marked as non-operational or non-functional. Automatically added to list during normal operations
Manually added to list as part of activation of second datacenter using Stop-DatabaseAvailabilityGroup cmdlet
Switchover In the context of a single database, it is the manual process used to move the active mailbox database copy to another server. In the context of an entire server, it is the manual process used to move all active mailbox database copies from one server to one or more other servers. Move-ActiveMailboxDatabase cmdlet
Targetless Switchover A switchover process in which the administrator does not specify which passive mailbox database copy should become active, but instead allows Active Manager’s BCS process to choose the best copy to activate. Move-ActiveMailboxDatabase cmdlet (specifically without using the TargetServer parameter)
Transport Dumpster A feature of the Hub Transport role that retains copies of messages sent to users on replicated mailbox databases in a DAG so that messages can be recovered by the system in the event of a lossy failover of the user’s database. Set-TransportConfig cmdlet or EMC
Witness Directory A required property of every DAG that specifies the name of the directory that is shared on the Witness Server for quorum purposes. Set-DatabaseAvailabilityGroup cmdlet or EMC
Witness Server A required property of every DAG that specifies the server external to the DAG that should be used as a participant in quorum for the DAG’s underlying cluster when the DAG contains even number of members. Set-DatabaseAvailabilityGroup cmdlet or EMC