The StartDagMaintenance.ps1 script pauses servers cluster node and blocks chosen servers and databases from being mounted. Here is what it does in the below example, for en environment that has 3 or more Servers with 3 or more database copies per database:

Here is the logic used by the script (big thanks to Allan Wang – US PFE for putting the below together !):

• SERVER_1 (who is already in maintenance) was chosen because

• 1/ the activation preference is set to “1”,

AND

• 2/ it has the following conditions: “Status=Healthy, ContentIndexing=Healthy, CopyQueueLength=0, ReplayQueueLength=0”

VERBOSE: [01:45:10.133 UTC] Move-DagMasterCopy: Entering: `$db=DB10, `$srcServer=SERVER_2, `$preferredTarget=

VERBOSE: [01:45:10.180 UTC] Test-DagTargetCopy: Testing move criteria for DB10\SERVER_1, with `$Lossless=True and

`$CICheck=False ...

VERBOSE: [01:45:10.196 UTC] Test-DagTargetCopy: Name='RED02\RED-MLT-1', Status='Healthy', CIStatus='Healthy',

CopyQueueLength=0, ReplayQueueLength=0

VERBOSE: [01:45:10.196 UTC] Test-DagTargetCopy: Leaving (returning 'True')

The suggestion made to administrators is to suspend the database after the server is put into maintenance so that the logic would most likely skip it (Overall status will change to “Suspended” then the script won’t try to mount databases on it)

*********** Below example put together by Bernard Chouinard, Canadian independant Consultant *********

• Start the Dag maintenance on the first server with the dag maintenance script (StartDagMaintenance.ps1 –ServerName <First_Server_Name>)

• Then suspend databases on this same first server with the below script:

#Get database on the first server

$dbases = Get-MailboxDatabaseCopyStatus -Server servername

#Suspend the database copy, this is so when the second server is put into maintenance mode it does not select the first server to move databases to

$dbases | %{if ((Get-MailboxDatabase $($_.DatabaseName)).ReplicationType -eq 'Remote'){Suspend-MailboxDatabaseCopy $($_.Name) -SuspendComment 'Serverbeing patched and rebooted' -Confirm:$false}}

• Start the Dag maintenance on the second server with the dag maintenance script (StartDagMaintenance.ps1 –ServerName <SECOND_Server_Name>) – NOTE: databases will be on a third server, but the script won’t try to mount databases on the FIRST server as it’s suspended now.

• Then resume (“un-suspend”) databases on the first server – NOTE: they will continue to replicate, but still be blocked from activation as we ran StartDagMaintenance.ps1 earlier…

#Resume the database copy on the first server

$dbases | %{if ((Get-MailboxDatabase $($_.DatabaseName)).ReplicationType -eq 'Remote'){Resume-MailboxDatabaseCopy $($_.Name) -Confirm:$false}}

****************** Example end – Thank you very much Bernard ! *****************

Or, if you are a scripting warrior, you can add an “IF” statement to test the DatabaseCopyAutoActivationPolicy  parameter and/or the database status (as the StartDagMaintenance.ps1 script also set individual databases as suspended for activation only).

Sam.

Users on Exchange 2010 who try to update or create a Distribution List may get the following error message:

"Changes to the public group membership cannot be saved. You do not have sufficient permission to perform this operation on this object.”

Usually, it’s because they don’t have the permissions (reminder: RBAC only for Exchange 2010 users) to create or modify security groups).

To assign these permissions to a security group in which you add users (recommended) or to a single user:

1 – First create a security group

2 – All the DL owners should be member of this group ( This way you do not have to assign permissions to individual users, it will be easier to manage permissions Only for the required users, )

3 – Assign permissions to security group (recommended)

• New-managementroleassignment –role “Security group creation and membership” –securitygroup “DL Owners”

or to assign the roles directly to user

• New-managementroleassignment –role “Security group creation and membership” –User “username”

5 – Add all the users who needs to manage DL’s to the security group

6 – Wait for AD Replication

7 – now users will be able to manage Mail enabled Security DL using outlook

8 – Any helpdesk users can use Exchange management shell and manage DL membership

9 - logout and login to their outlooks and try to change the Security group membership

NOTE : If you configured Outlook 2010 or earlier to directly use a GC (using the “ClosestGC” or the “DS Server” registry key) as per http://support.microsoft.com/kb/319206 , users won’t be able to manage DL memberships or creation as this will bypass RBAC check and use AD permissions instead – it’s not recommended you give users direct AD permissions – Also remember that the registry keys described in the above article (KB 319206) works, but is NOT SUPPORTED when mailboxes are in Exchange 2010/2013 (one example why is the bypass of RBAC permissions for AD related operations like DL management). So please only use these for troubleshooting purposes.

Sam.