What do Event IDs 2059 and 2153 mean in Exchange?

Event ID 2059 indicates the DAG cluster name object (CNO) lacks required permissions, while Event ID 2153 indicates database copy seeding or mounting failed due to access denied errors. Both relate to insufficient Active Directory or cluster permissions.

Why do DAG permission errors occur?

Common causes include the CNO computer account lacking permissions in AD, the Exchange Trusted Subsystem group missing from required security groups, improper OU permissions, or cluster service account issues after server rebuild or migration.

How do I fix DAG CNO permissions?

Grant the Cluster Name Object (CNO) computer account Full Control on the OU containing DAG member servers, add Exchange Trusted Subsystem to local Administrators on all members, and ensure the CNO has "Create Computer Objects" permission.

Can I fix DAG permissions without downtime?

Most permission fixes can be applied without downtime. However, if cluster quorum is affected, you may need to restart the cluster service or DAG members. Plan for potential brief database failovers during remediation.

How do I prevent DAG permission issues?

Pre-stage the CNO in Active Directory before creating the DAG, ensure proper OU permissions are set, document required permissions in runbooks, and test DAG operations after any AD or permission changes.

What do Event IDs 2059 and 2153 mean in Exchange?

Event ID 2059 indicates the DAG cluster name object (CNO) lacks required permissions, while Event ID 2153 indicates database copy seeding or mounting failed due to access denied errors. Both relate to insufficient Active Directory or cluster permissions.

Why do DAG permission errors occur?

Common causes include the CNO computer account lacking permissions in AD, the Exchange Trusted Subsystem group missing from required security groups, improper OU permissions, or cluster service account issues after server rebuild or migration.

How do I fix DAG CNO permissions?

Grant the Cluster Name Object (CNO) computer account Full Control on the OU containing DAG member servers, add Exchange Trusted Subsystem to local Administrators on all members, and ensure the CNO has "Create Computer Objects" permission.

Can I fix DAG permissions without downtime?

Most permission fixes can be applied without downtime. However, if cluster quorum is affected, you may need to restart the cluster service or DAG members. Plan for potential brief database failovers during remediation.

How do I prevent DAG permission issues?

Pre-stage the CNO in Active Directory before creating the DAG, ensure proper OU permissions are set, document required permissions in runbooks, and test DAG operations after any AD or permission changes.

Event IDs 2059/2153: DAG Permission Issues

Event IDs 2059 and 2153 indicate permission problems with your Exchange Database Availability Group (DAG), preventing proper cluster operation and database mounting. This guide shows you how to diagnose and fix DAG permission issues.

Our DAG Support Team specializes in complex cluster and permission troubleshooting.

Error Overview: DAG Permission Errors

Exchange DAGs rely on Windows Failover Clustering and Active Directory permissions. The Cluster Name Object (CNO) is a computer account in AD that represents the DAG cluster and requires specific permissions to function.

Typical Event Log Entries

# Event ID 2059
Log Name:      Application
Source:        MSExchangeRepl
Event ID:      2059
Level:         Error
Description:
The cluster network name resource failed to create its
associated computer object in domain 'domain.local'.
Error: Access is denied.

# Event ID 2153
Log Name:      Application
Source:        MSExchangeRepl
Event ID:      2153
Level:         Error
Description:
An attempt to seed database 'MailboxDB01' failed.
Error: Access is denied.
The seeding operation encountered an error and cannot continue.

Symptoms & Business Impact

What Admins See:

Event IDs 2059, 2153 in Application log
DAG creation fails with access denied
Database copy seeding fails
Database mounting fails on passive nodes
Cluster resources fail to come online

Business Impact:

Cannot create new DAG for high availability
Cannot add servers to existing DAG
Database copies cannot be seeded
Failover to passive copies may fail
No database redundancy

Quick Permission Check

# Check DAG status
Get-DatabaseAvailabilityGroup | Format-List Name, Servers, WitnessServer

# Check cluster node status
Get-ClusterNode | Format-Table Name, State

# Check for access denied in recent events
Get-EventLog -LogName Application -Source MSExchangeRepl -EntryType Error -Newest 50 | Where-Object { $_.Message -like "*access*denied*" -or $_.EventID -in @(2059,2153) }

Common Causes

1. CNO Missing Permissions (40%)

The Cluster Name Object computer account lacks permission to create computer objects in the OU or lacks Full Control on its own object.

2. OU Permissions (25%)

The Organizational Unit containing DAG members has restricted permissions preventing the CNO from managing member objects.

3. Exchange Trusted Subsystem (20%)

The "Exchange Trusted Subsystem" group is not a member of the local Administrators group on DAG member servers.

4. Cluster Service Account (10%)

The cluster service is running under an account that lacks required permissions, or the CNO was deleted/recreated.

5. AD Replication Delay (5%)

Recent permission changes haven't replicated to all domain controllers that DAG members are using.

Quick Diagnosis

Step 1: Check CNO in Active Directory

# Find the CNO computer account
$dagName = "DAG01"
$cno = Get-ADComputer -Identity $dagName -Properties *
$cno | Select-Object Name, DistinguishedName, Enabled

# Check CNO permissions
$acl = Get-Acl "AD:\$($cno.DistinguishedName)"
$acl.Access | Where-Object { $_.IdentityReference -like "*$dagName*" -or $_.IdentityReference -like "*Exchange*" } | Format-List

# Check if CNO is enabled
if (-not $cno.Enabled) {
    Write-Host "WARNING: CNO is disabled!" -ForegroundColor Red
}

Step 2: Check OU Permissions

# Get the OU containing the CNO
$ouPath = ($cno.DistinguishedName -split ',', 2)[1]
Write-Host "CNO is in OU: $ouPath"

# Check OU permissions for Create Computer Objects
$ouAcl = Get-Acl "AD:\$ouPath"
$ouAcl.Access | Where-Object { $_.ActiveDirectoryRights -like "*CreateChild*" } | Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType

Step 3: Check Exchange Trusted Subsystem

# On each DAG member, check local Administrators group
$dagMembers = (Get-DatabaseAvailabilityGroup -Identity "DAG01").Servers
foreach ($server in $dagMembers) {
    Write-Host "Checking $server..."
    Invoke-Command -ComputerName $server -ScriptBlock {
        $admins = Get-LocalGroupMember -Group "Administrators"
        $ets = $admins | Where-Object { $_.Name -like "*Exchange Trusted Subsystem*" }
        if ($ets) {
            Write-Host "  Exchange Trusted Subsystem: Present" -ForegroundColor Green
        } else {
            Write-Host "  Exchange Trusted Subsystem: MISSING" -ForegroundColor Red
        }
    }
}

Quick Fix

Add Exchange Trusted Subsystem to Local Admins

# Run on each DAG member server
$domain = $env:USERDOMAIN
Add-LocalGroupMember -Group "Administrators" -Member "$domain\Exchange Trusted Subsystem" -ErrorAction SilentlyContinue

# Verify
Get-LocalGroupMember -Group "Administrators" | Where-Object { $_.Name -like "*Exchange*" }

# Restart cluster service to pick up new permissions
Restart-Service ClusSvc -Force

Detailed Solutions

Solution 1: Fix CNO Permissions

Grant CNO Required Permissions

# Enable the CNO if disabled
$dagName = "DAG01"
$cno = Get-ADComputer -Identity $dagName
if (-not $cno.Enabled) {
    Enable-ADAccount -Identity $dagName
    Write-Host "CNO enabled"
}

# Grant CNO Full Control on itself
$cnoPath = "AD:\$($cno.DistinguishedName)"
$acl = Get-Acl $cnoPath
$identity = New-Object System.Security.Principal.NTAccount($env:USERDOMAIN, $dagName + "$")
$rights = [System.DirectoryServices.ActiveDirectoryRights]::GenericAll
$type = [System.Security.AccessControl.AccessControlType]::Allow
$inheritance = [System.DirectoryServices.ActiveDirectorySecurityInheritance]::None
$ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($identity, $rights, $type, $inheritance)
$acl.AddAccessRule($ace)
Set-Acl $cnoPath $acl

Write-Host "CNO Full Control granted"

Solution 2: Fix OU Permissions

Grant CNO Create Computer Objects Permission

# Get the OU path
$dagName = "DAG01"
$cno = Get-ADComputer -Identity $dagName
$ouPath = "AD:\" + ($cno.DistinguishedName -split ',', 2)[1]

# Get current ACL
$acl = Get-Acl $ouPath

# Create the access rule for Create Computer Objects
$identity = New-Object System.Security.Principal.NTAccount($env:USERDOMAIN, $dagName + "-split ',', 2)[1]

# Get current ACL
$acl = Get-Acl $ouPath

# Create the access rule for Create Computer Objects
$identity = New-Object System.Security.Principal.NTAccount($env:USERDOMAIN, $dagName + "$")

# Computer object GUID
$computerGuid = [GUID]"$computerGuid = [GUID]"bf967a86-0de6-11d0-a285-00aa003049e2"

# Create Child permission
$rights = [System.DirectoryServices.ActiveDirectoryRights]::CreateChild
$type = [System.Security.AccessControl.AccessControlType]::Allow
$inheritance = [System.DirectoryServices.ActiveDirectorySecurityInheritance]::All

$ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($identity, $rights, $type, $computerGuid, $inheritance)
$acl.AddAccessRule($ace)
Set-Acl $ouPath $acl

Write-Host "$rights = [System.DirectoryServices.ActiveDirectoryRights]::CreateChild
$type = [System.Security.AccessControl.AccessControlType]::Allow
$inheritance = [System.DirectoryServices.ActiveDirectorySecurityInheritance]::All

$ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($identity, $rights, $type, $computerGuid, $inheritance)
$acl.AddAccessRule($ace)
Set-Acl $ouPath $acl

Write-Host "CNO granted Create Computer Objects on OU"

Solution 3: Pre-stage CNO for New DAG

Pre-stage CNO Before DAG Creation

# Create CNO computer account before creating DAG
$dagName = "DAG01"
$ouPath = "OU=Exchange Servers,DC=domain,DC=local"

# Create disabled computer account
New-ADComputer -Name $dagName -Path $ouPath -Enabled $false -Description "Exchange DAG Cluster Name Object"

# Set permissions on the CNO
$cno = Get-ADComputer -Identity $dagName
$cnoPath = "AD:\$($cno.DistinguishedName)"
$acl = Get-Acl $cnoPath

# Grant Exchange Trusted Subsystem Full Control
$ets = New-Object System.Security.Principal.NTAccount($env:USERDOMAIN, "Exchange Trusted Subsystem")
$rights = [System.DirectoryServices.ActiveDirectoryRights]::GenericAll
$type = [System.Security.AccessControl.AccessControlType]::Allow
$ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($ets, $rights, $type)
$acl.AddAccessRule($ace)
Set-Acl $cnoPath $acl

Write-Host "CNO pre-staged. Now create DAG with: New-DatabaseAvailabilityGroup -Name $dagName"New-DatabaseAvailabilityGroup -Name $dagName"

Solution 4: Recreate Failed CNO

Recreate Corrupted CNO

# If CNO is corrupted, remove and recreate
# WARNING: This will briefly impact DAG operations

$dagName = "DAG01"

# First, document current DAG configuration
$dag = Get-DatabaseAvailabilityGroup -Identity $dagName
$dag | Export-Clixml "C:\Temp\DAG_Backup.xml"

# Stop cluster service on all members
$dag.Servers | ForEach-Object {
    Invoke-Command -ComputerName $_ -ScriptBlock { Stop-Service ClusSvc -Force }
}

# Delete the CNO from AD
Remove-ADComputer -Identity $dagName -Confirm:$false

# Pre-stage new CNO with correct permissions (see Solution 3)3)

# Start cluster service
$dag.Servers | ForEach-Object {
    Invoke-Command -ComputerName $_ -ScriptBlock { Start-Service ClusSvc }
}

# Verify DAG is operational
Get-DatabaseAvailabilityGroup -Identity $dagName -Status | Format-List

Verify the Fix

Verify DAG Permissions

# Check CNO status
$dagName = "DAG01"
$cno = Get-ADComputer -Identity $dagName -Properties Enabled
Write-Host "CNO Enabled: $($cno.Enabled)"

# Check DAG operational status
Get-DatabaseAvailabilityGroup -Identity $dagName -Status | Format-List Name, Servers, OperationalServers, PrimaryActiveManager

# Check cluster health
Get-ClusterNode | Format-Table Name, State

# Verify database copies are healthy
Get-MailboxDatabaseCopyStatus * | Format-Table Name, Status, CopyQueueLength -AutoSize

# Test seeding a database copy (non-destructive test)
# Test-ReplicationHealth | Format-Table Server, Check, Result-Table Server, Check, Result

Prevention Tips

Best Practices

Pre-stage CNO before creating new DAGs
Document required permissions in runbooks
Use dedicated OU for Exchange servers with proper permissions
Add Exchange Trusted Subsystem to local Admins during server build
Test DAG operations after any AD permission changes
Monitor Event IDs 2059 and 2153 proactively

When to Escalate

Contact DAG specialists if:

Permission fixes don't resolve the issue
Cluster is in a failed state
CNO recreation is required in production
Complex AD delegation model is in place
Cross-site DAG with different AD sites

Need Expert Help?

Our DAG Support Team provides comprehensive cluster permission troubleshooting and DAG configuration assistance.