Fix DNS_ERROR_ZONE_LOCKED (0X00002587) on Windows Server

This error is a real head-scratcher when you first see it

I know getting DNS_ERROR_ZONE_LOCKED (0X00002587) feels like the server is mocking you. You're just trying to update a record or run a zone transfer, and it slams the door. I've been there. Let's get it unlocked.

The direct fix: PowerShell

Skip the GUI for now — PowerShell is faster and more reliable for this. Open PowerShell as Administrator on your DNS server and run:

Unlock-DnsServerZone -Name "contoso.com" -Force

Replace contoso.com with your zone name. The -Force flag bypasses confirmation prompts. After running it, check the zone status with:

Get-DnsServerZone -Name "contoso.com" | Select-Object ZoneName, ZoneType, LockStatus

If LockStatus shows Unlocked, you're good. Try your original operation again. This works on Windows Server 2012 R2, 2016, 2019, and 2022. If you're on Server 2008 R2, use the older dnscmd method below.

When PowerShell won't work: dnscmd fallback

Older servers or those missing the DNS module still have dnscmd:

dnscmd /ZoneResetType contoso.com /Primary

This resets the zone type to primary, which implicitly unlocks it. Then set it back to secondary if that's what you need:

dnscmd /ZoneResetType contoso.com /Secondary 192.168.1.10

Replace the IP with your primary DNS server's address.

Why does the zone get locked in the first place?

DNS zones lock themselves during certain operations to prevent corruption. The usual suspects are:

Zone transfers — When a secondary zone is actively pulling data from a primary, it locks. This is normal, but sometimes the lock doesn't release if the transfer fails or is interrupted.
Manual locking — Someone (or a script) ran a command like dnscmd /ZoneLock. This is rare but happens when admins try to prevent changes during migrations.
WinRM or PowerShell remoting issues — If you run DNS commands remotely and the session disconnects, the lock can linger. This tripped me up the first time I automated DNS changes across a domain.
AD-integrated zones — These rarely lock, but if the Active Directory replication is stuck, the zone can appear locked. In that case, check AD sites and services first.

Less common variations of this error

The error can pop up outside the typical zone transfer scenario. Here are a few I've seen:

Locked during DHCP registration

If you're using Windows DHCP to dynamically update DNS records and the zone is locked, the DHCP server logs 0X00002587 and skips the update. This usually happens after a secondary zone transfer fails. Unlock the zone (as above) and trigger a manual transfer from the DHCP server or wait for the next automatic attempt.

Lock caused by a third-party backup tool

I once had a backup agent that used dnscmd to snapshot zone data. It locked the zone and never released it. If you use tools like Veeam or NetBackup with DNS-aware plugins, check their logs. The fix is the same — unlock via PowerShell — but you'll want to find and update the backup script to avoid it happening again.

Read-only domain controller (RODC) with DNS

RODCs don't allow DNS zone modifications. Any attempt to write to a zone on an RODC throws 0X00002587. Check if the server is an RODC by running Get-ADDomainController -Filter * | Select-Object Name, IsReadOnly. If it's read-only, run your DNS commands on a writable domain controller instead.

Prevention: Stop the lock from coming back

You can't prevent all locks — zone transfers need them — but you can minimize the frustration:

Set zone transfer timeout correctly. In the DNS console, right-click your zone, go to Properties > Zone Transfers, and set the Notify settings to push updates to secondary servers. This reduces the need for full zone transfers that lock the zone for longer.
Monitor zone lock status. Create a scheduled task that runs Get-DnsServerZone | Where-Object {$_.LockStatus -eq 'Locked'} every 15 minutes. If it finds locked zones, email you or automatically run Unlock-DnsServerZone.
Clean up old secondary zones. If you have secondary zones for domains that no longer exist, delete them. They can get stuck in a locked state when their primary server is gone.
Use Windows Server 2019 or later. Microsoft improved the lock management in newer versions. Zones are less likely to remain locked after a failed transfer. I've seen a noticeable drop in this error since upgrading our DCs to 2022.

That's it. You should be back to updating records in minutes. If the error comes back immediately after unlocking, check if a script or backup job is repeatedly locking the zone. Track it down by running Get-WinEvent -LogName 'DNS Server' and looking for Event ID 410 (Zone locked) — the source process is usually logged there.