A new secondary DNS server on Windows Server 2022 stays empty until the primary agrees to send it the zone, and by default the primary says no. On our test pair the secondary zone loaded in a shutdown state, logged event 6525 every 15 seconds, and answered every query with SERVFAIL. The fix was one NS record on the primary. Within seconds of that change the secondary had pulled all 508 records, and NOTIFY carried each later change across within 0.7 s of the write, usually in 1 to 2 ms.
This guide builds that secondary DNS zone on a second Windows Server 2022 box and covers the parts that decide whether it works: zone transfer permissions, NOTIFY, Add-DnsServerSecondaryZone, forcing a transfer with Start-DnsServerZoneTransfer, and pointing clients at both servers. Every command and timing comes from two Windows Server 2022 Standard VMs (build 20348, tested October 2026). Building the primary itself is covered in our Windows Server 2022 DNS server guide, and the Windows Server 2025 DNS guide applies to the newer release.
Lab layout and the measured results
Both servers are workgroup machines on one /24, cloned from the same Windows Server 2022 Standard image with 4 GB RAM. Because neither is a domain controller, the primary zone is file-backed and the secondary copies it through standard zone transfers (AXFR and IXFR over TCP 53). Active Directory-integrated zones replicate through AD instead and do not need a secondary zone between domain controllers.
- DNS01 (10.0.1.10): primary for
corp.example.com, 507 records including 500 bulk A records added to give the transfer some weight. - DNS02 (10.0.1.11): the new secondary. It holds a read-only copy of
corp.example.comand is listed as a name server for the zone. - Linux client: an Ubuntu 26.04 host with dig, used to query both servers and to test AXFR from a host that should be refused. There is no separate Windows client: the client failover test in Step 6 ran on DNS02’s own resolver.
Every record edit happens on DNS01. DNS01 tells DNS02 about it with NOTIFY over UDP 53, and DNS02 pulls the change over TCP 53. Clients list both servers and fall back to DNS02 when DNS01 stops answering.
Each number in this table was measured on the pair above, and the steps below show how it was taken.
| Measurement | Result |
|---|---|
| Default transfer setting on a new primary zone | TransferToZoneNameServer, Notify on |
| Secondary created before it was an NS record | Refused, result 9005, event 6525 every 15 s, SERVFAIL |
| Full transfer after the NS record was added | 508 records within seconds, without a manual transfer |
| New secondary created with the NS record in place | 515 records loaded in 320 ms |
| New record visible on the secondary with NOTIFY | 1 to 2 ms after the write in 4 of 5 runs, 696 ms in the first |
| New record visible on the secondary without NOTIFY | 14.83 min, at the next SOA refresh |
| Lookup on DNS02 (resolver list DNS01, then DNS02) with the primary stopped | 1,014 ms for the first lookup, then 1.0 to 1.2 ms |
Read the two NOTIFY rows together. With NOTIFY on, a change reaches the secondary in about the time the primary takes to write it. With NOTIFY off, the secondary only notices at its next SOA check, which the default 15-minute refresh interval controls. Leave NOTIFY on unless you have a reason to throttle transfers.
What a secondary zone holds
A secondary zone is a read-only copy of a primary zone, refreshed by zone transfer. The secondary answers queries authoritatively (the aa flag is set in its replies), so clients cannot tell the two servers apart. It cannot accept changes, because every record edit happens on the primary and the secondary only pulls the result. For a wider grounding in the roles around DNS, see our list of Windows Server administration books.
Three SOA timers on the primary decide how the secondary behaves when NOTIFY is missing or the primary goes away. A new Windows Server 2022 primary zone ships with these values, read from the lab:
- Refresh 900 s (15 minutes): how often the secondary asks the primary for its SOA serial. A higher serial on the primary triggers a transfer.
- Retry 600 s (10 minutes): how long the secondary waits after a failed SOA check before it tries again.
- Expire 86,400 s (1 day): how long the secondary keeps answering without reaching the primary. After that it stops serving the zone.
The expire timer is the real limit of a secondary as a backup. It covers a primary that is down for a reboot, a patch window or a bad night, but a primary that stays dead for more than a day takes the secondary down with it. Raise the expire value on the primary if your recovery plan needs longer: in DNS Manager open the zone Properties, go to the Start of Authority (SOA) tab and change Expires after. The secondary picks up the new value with the next transfer.
Step 1: Install the DNS Server role on the secondary
The secondary needs a static IP and the DNS Server role, nothing else. Set the address before the role install, because the primary will list this IP in its NS and transfer settings. Run the install in an elevated PowerShell window on DNS02:
Install-WindowsFeature -Name DNS -IncludeManagementToolsNo reboot is needed. On DNS02 the install took 132.5 s, against 60.4 s for the same command on DNS01:
Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True No Success {DNS Server, Remote Server Administration Tools, DNS Server Tools, Role Administration Tools}The role also enables the DNS Service firewall group: DNS (UDP, Incoming), DNS (TCP, Incoming) and the RPC rules the DNS Manager console uses. Zone transfers ride on TCP 53, so nothing else has to be opened between the two servers. If a network firewall sits between them, allow TCP and UDP 53 from the secondary to the primary, and UDP 53 from the primary to the secondary for NOTIFY. Our guide to opening a port in Windows Server Firewall covers the host side if a rule is missing.
Step 2: Allow zone transfers on the primary
A file-backed primary zone created with Add-DnsServerPrimaryZone allows transfers only to servers listed in its own NS records, and it sends NOTIFY to those same servers. An Active Directory-integrated zone on a domain controller is different: zone transfers are off by default there, so you have to turn them on (the same Zone Transfers tab or -SecureSecondaries) before a non-DC secondary can copy it. Check what your primary zone is set to before you build the secondary. Run this on DNS01:
Get-DnsServerZone -Name "corp.example.com" | Format-List ZoneName,ZoneType,ZoneFile,IsDsIntegrated,SecureSecondaries,SecondaryServers,Notify,NotifyServersOur new zone came back with TransferToZoneNameServer and Notify, with both server lists empty:
ZoneName : corp.example.com
ZoneType : Primary
ZoneFile : corp.example.com.dns
IsDsIntegrated : False
SecureSecondaries : TransferToZoneNameServer
SecondaryServers :
Notify : Notify
NotifyServers :That default is reasonable, and it means the cleanest way to authorize the secondary is to make it a real name server for the zone. Add an A record for DNS02 if the zone does not have one yet, then an NS record that points at it:
Add-DnsServerResourceRecordA -ZoneName "corp.example.com" -Name "dns02" -IPv4Address 10.0.1.11
Add-DnsServerResourceRecord -ZoneName "corp.example.com" -Name "@" -NS -NameServer "dns02.corp.example.com." -PassThruList the NS records to confirm both servers are there. In our lab the secondary zone already existed at this point, which is how we caught the refusal in the troubleshooting section, and adding the NS record moved the zone serial from 505 to 506:
Get-DnsServerResourceRecord -ZoneName "corp.example.com" -RRType NSTwo NS records come back, one per server.
HostName RecordType Type Timestamp TimeToLive RecordData
-------- ---------- ---- --------- ---------- ----------
@ NS 2 0 01:00:00 dns01.corp.example.com.
@ NS 2 0 01:00:00 dns02.corp.example.com.The NS record also matters outside transfers. Resolvers that follow a delegation to corp.example.com use the NS set to pick a server, so a secondary that is missing from it never gets queried by them.
Allow an explicit list instead of the NS records
Some sites keep a secondary out of the public NS set on purpose, for example a hidden secondary used only by internal resolvers. In that case, list it by IP instead, because the NS-based default would refuse it. The primary then sends transfers and NOTIFY to that address only, whatever the NS records say:
Set-DnsServerPrimaryZone -Name "corp.example.com" -SecureSecondaries TransferToSecureServers -SecondaryServers 10.0.1.11 -Notify NotifyServers -NotifyServers 10.0.1.11The zone now reports the explicit list. A record added after this change still reached DNS02 in 652 ms, so NOTIFY works the same way in this mode:
ZoneName : corp.example.com
SecureSecondaries : TransferToSecureServers
SecondaryServers : 10.0.1.11
Notify : NotifyServers
NotifyServers : 10.0.1.11Avoid TransferAnyServer, because it hands the whole zone, every hostname and internal IP, to anyone who can reach TCP 53 on the primary. With either of the settings above, an AXFR request from our Linux client was refused, and dig printed only ; Transfer failed.. We switched back to the NS-based default for the rest of the guide with this command:
Set-DnsServerPrimaryZone -Name "corp.example.com" -SecureSecondaries TransferToZoneNameServer -Notify NotifySkip that revert if you are keeping a hidden secondary, because it moves transfers and NOTIFY back to the NS servers only.
The same three settings live in DNS Manager under Properties for the zone, on the Zone Transfers tab. That tab is where the event 6525 message on a refused secondary sends you:
- 1Zone Transfers
- 2Only to servers listed on the Name Servers tab
- 3Notify
Open DNS Manager on the primary (Server Manager, then Tools, then DNS, or run dnsmgmt.msc), expand Forward Lookup Zones, right-click the zone and choose Properties. The dashed boxes on the capture mark these controls.
- Zone Transfers: the tab that holds the transfer permission for this zone.
- Only to servers listed on the Name Servers tab: the default the cmdlet reported as
TransferToZoneNameServer. “Only to the following servers” is the explicit list. - Notify: opens the NOTIFY list, which matches
-Notifyand-NotifyServers.
Both the GUI and the cmdlet write the same zone settings, so use whichever you script with and check the result with Get-DnsServerZone.
Step 3: Create the secondary zone with Add-DnsServerSecondaryZone
On DNS02, create the secondary zone and point it at the IP of the primary. -ZoneFile names the local file the secondary writes the copy to, under C:\Windows\System32\dns, and -MasterServers takes one or more primary addresses (the Add-DnsServerSecondaryZone reference lists the rest, including -LoadExisting for reusing a zone file):
Add-DnsServerSecondaryZone -Name "corp.example.com" -ZoneFile "corp.example.com.dns" -MasterServers 10.0.1.10 -PassThruThe cmdlet returns at once with the zone type set to Secondary. The transfer itself runs in the background.
ZoneName ZoneType IsAutoCreated IsDsIntegrated IsReverseLookupZone IsSigned
-------- -------- ------------- -------------- ------------------- --------
corp.example.com Secondary False False FalseCheck the zone state on DNS02 a second later. With the NS record already in place, our secondary was serving 515 records 320 ms after the cmdlet returned:
Get-DnsServerZone -Name "corp.example.com" | Format-List ZoneName,ZoneType,IsShutdown,MasterServers,LastZoneTransferAttempt,LastZoneTransferResult,LastSuccessfulZoneTransfer,LastSuccessfulSOACheckThe fields to read are IsShutdown, which must be False, and LastZoneTransferResult, where 0 means success. Our DNS02 also showed 4294967295 in that field while a transfer was still in progress and right after a Start-DnsServerZoneTransfer that found equal serials, so read it together with IsShutdown and LastSuccessfulSOACheck:
ZoneName : corp.example.com
ZoneType : Secondary
IsShutdown : False
MasterServers : 10.0.1.10
LastZoneTransferAttempt : 10/29/2026 11:51:55 PM
LastZoneTransferResult : 0
LastSuccessfulZoneTransfer : 10/29/2026 11:51:55 PM
LastSuccessfulSOACheck : 10/29/2026 11:51:55 PMA result of 9005 with IsShutdown : True means the primary refused the transfer, which is covered in the troubleshooting section below. When we created the secondary first, DNS02 logged the refusal at 15-second intervals. After we added the NS record on DNS01, the zone loaded 508 records on its own within seconds, most likely because the serial change sent a NOTIFY to the new NS server. If your zone has not loaded within a minute of fixing the primary, run Start-DnsServerZoneTransfer -Name "corp.example.com" on DNS02 (Step 4).
DNS Manager on DNS02 shows the same thing graphically. The zone sits under Forward Lookup Zones with the full record set, and its Properties dialog reports the type as Secondary with the master server list underneath:
The Server FQDN column read “Attempting to resolve” on our workgroup lab, where no reverse lookup zone covers the address of the primary. That column is cosmetic, and transfers worked with it unresolved.
Step 4: Force a zone transfer and compare serials
You rarely need to force a transfer, because NOTIFY and the refresh timer do it for you. It is still the first thing to run after fixing a broken secondary, or when you want proof that the two servers agree. Start-DnsServerZoneTransfer on the secondary asks the primary for its SOA serial and pulls changes only if the serial on the primary is higher:
Start-DnsServerZoneTransfer -Name "corp.example.com"Nothing prints. With both serials at 513, the cmdlet only refreshed LastSuccessfulSOACheck to 11:52:10 PM and transferred nothing. To pull the whole zone again regardless of serial, add -FullTransfer. Include -Confirm:$false when you script it. In our non-interactive session the call without it returned and did not transfer anything.
Start-DnsServerZoneTransfer -Name "corp.example.com" -FullTransfer -Confirm:$falseThe DNS Server event log on DNS02 records each transfer as a pair, event 6522 when it starts and 3150 when the zone file is written:
Get-WinEvent -LogName 'DNS Server' -MaxEvents 2 | Format-List TimeCreated,Id,MessageBoth events carry the serial, here 513.
TimeCreated : 10/29/2026 11:52:28 PM
Id : 3150
Message : The DNS server wrote version 513 of zone corp.example.com to file corp.example.com.dns.
TimeCreated : 10/29/2026 11:52:28 PM
Id : 6522
Message : A more recent version, version 513 of zone corp.example.com was found at the DNS server at 10.0.1.10. Zone transfer is in progress.The quickest cross-check runs from any machine with dig, because it compares what each server actually answers. Query the SOA record on both servers:
dig @10.0.1.10 corp.example.com SOA +noall +answer
dig @10.0.1.11 corp.example.com SOA +noall +answerWe caught this pair mid-change, with NOTIFY switched off. The third field after the names is the serial, 512 on the primary and 511 on the secondary, so DNS02 was one change behind:
corp.example.com. 3600 IN SOA dns01.corp.example.com. hostmaster.corp.example.com. 512 900 600 86400 3600
corp.example.com. 3600 IN SOA dns01.corp.example.com. hostmaster.corp.example.com. 511 900 600 86400 3600Matching serials mean the secondary holds the same version as the primary, so a gap is the first number to check. A secondary that stays behind for longer than the refresh interval (900 s here) is missing NOTIFY and failing its SOA checks as well. Look at TCP 53 between the two servers first, then at the transfer permission on the primary.
Step 5: Keep NOTIFY on and measure it
NOTIFY is on by default for a new primary zone, and it is the reason a change shows up on the secondary in milliseconds instead of minutes. When a record changes, the primary sends a NOTIFY message over UDP 53 to the servers it is set to notify. The secondary answers with an SOA query and pulls the difference as an incremental transfer.
We measured it from DNS01 by adding an A record and then querying DNS02 every 100 ms until the new name resolved. Each run used a fresh name:
foreach($n in 1..5){
$name="notify-t$n"
$sw=[Diagnostics.Stopwatch]::StartNew()
Add-DnsServerResourceRecordA -ZoneName corp.example.com -Name $name -IPv4Address "10.0.3.$n"
$added=$sw.ElapsedMilliseconds
do { $r = Resolve-DnsName "$name.corp.example.com" -Server 10.0.1.11 -DnsOnly -QuickTimeout -ErrorAction SilentlyContinue; if(-not $r){Start-Sleep -Milliseconds 100} } until ($r -or $sw.ElapsedMilliseconds -gt 9000)
"run $n : record added at $added ms, answered by DNS02 at $($sw.ElapsedMilliseconds) ms, found=$([bool]$r)"
}Five runs gave these times, measured from the start of the add call to the first answer from the secondary, so each includes the time the primary took to write the record:
| Run | NOTIFY setting | Visible on DNS02, from start of add |
|---|---|---|
| 1 | Notify (default) | 1,585 ms |
| 2 | Notify (default) | 7 ms |
| 3 | Notify (default) | 6 ms |
| 4 | Notify (default) | 6 ms |
| 5 | Notify (default) | 7 ms |
| 6 | NoNotify | 14.83 min |
Runs 2 to 5 finished inside 10 ms, which is close to one round trip between two VMs on the same host. Run 1 is slower because the first Add-DnsServerResourceRecordA call in a fresh PowerShell session took 889 ms on its own, so the record was only written at that point. Run 6 is the control, from an earlier session in the same lab: we set the primary zone to NoNotify, added one record, and it did not appear on DNS02 for 40 seconds. It arrived 14.83 minutes after it was written, when DNS02 made its next scheduled SOA check. That check came 15 minutes and 26 seconds after the previous one, which matches the 900-second refresh interval.
The loop leaves five test records in a real zone, so remove them on DNS01 when you are done. Each removal bumps the serial and goes out with NOTIFY like any other change:
1..5 | ForEach-Object { Remove-DnsServerResourceRecord -ZoneName corp.example.com -RRType A -Name "notify-t$_" -Force }So without NOTIFY, the worst case for a change is the full refresh interval, and on average a change waits about half of it. Keep it on. If a secondary is behind a firewall that blocks UDP 53 from the primary, NOTIFY silently fails and you are back to that 15-minute window. That is the symptom to look for when changes arrive late but always arrive. If someone has switched a zone to NoNotify, the revert command from Step 2 sets it back to Notify, which sends to every server in the NS records. On a hidden secondary that is not in the NS set, use -Notify NotifyServers -NotifyServers with its IP instead, or it stops getting notified.
Step 6: Point clients at both DNS servers
A secondary only helps if clients know about it. On Windows, list the primary first and the secondary second on the network adapter of each client, or hand out both through DHCP option 6. The interface alias on our servers is Ethernet; check yours with Get-NetAdapter:
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 10.0.1.10,10.0.1.11
Get-DnsClientServerAddress -InterfaceAlias "Ethernet" -AddressFamily IPv4Both servers should appear in order.
InterfaceAlias InterfaceIndex AddressFamily ServerAddresses
-------------- -------------- ------------- ---------------
Ethernet 6 IPv4 {10.0.1.10, 10.0.1.11}That output comes from DNS02 itself. Our lab had no third Windows machine, so we used the DNS client on DNS02 as the test client, with its resolver list set to DNS01 first and its own address second, exactly as above. We then timed Resolve-DnsName web.corp.example.com -DnsOnly five times with the primary up and five times after Stop-Service DNS on DNS01, running Clear-DnsClientCache before every lookup and checking that the cache held no entry for the name. The script is the one we ran:
foreach($i in 1..5){
Clear-DnsClientCache
$cached=(Get-DnsClientCache -Name web.corp.example.com -ErrorAction SilentlyContinue | Measure-Object).Count
$sw=[Diagnostics.Stopwatch]::StartNew()
$r=Resolve-DnsName web.corp.example.com -DnsOnly -ErrorAction SilentlyContinue
$sw.Stop()
"run $i : cache entries before=$cached, $([math]::Round($sw.Elapsed.TotalMilliseconds,1)) ms, answer=$($r.IPAddress)"
}Every run started with zero cached entries and returned 10.0.1.20:
- Primary up: 20.5 ms for the first lookup, then 1.4 to 1.8 ms.
- Primary stopped, run 1: 1,014.3 ms. The client waited about one second for DNS01, then asked the second server on its list.
- Primary stopped, runs 2 to 5: 1.0 to 1.2 ms. Clearing the cache did not bring the delay back, so the resolver went straight to DNS02 for the following lookups.
The one-second wait matches Microsoft’s description of DNS client resolution timeouts: with no reply after 1 second, the client queries the next server. Because the second server here is the local machine, the 1 ms answers are a loopback best case. A separate client on the same subnet adds a network round trip, but the one-second penalty on the first lookup is the part that matters. Applications with a lookup timeout under one second may still log errors during that window.
To repeat the failure test on your own pair, stop the DNS Server service on DNS01 in a quiet window. Every client that lists DNS01 first pays the one-second delay while it is down, and no record can be edited until it is back:
Stop-Service DNSFrom a Linux host, dig shows the same result directly. With the service stopped on DNS01, query both servers:
dig @10.0.1.10 web.corp.example.com +time=2 +tries=1
dig @10.0.1.11 web.corp.example.com +noall +comments +answerThe primary times out, and the secondary answers with the aa (authoritative answer) flag set:
;; communications error to 10.0.1.10#53: timed out
; <<>> DiG 9.20.24-1ubuntu0.4-Ubuntu <<>> @10.0.1.10 web.corp.example.com +time=2 +tries=1
; (1 server found)
;; global options: +cmd
;; no servers could be reached
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24997
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; ANSWER SECTION:
web.corp.example.com. 3600 IN A 10.0.1.20On Linux clients, list both servers as nameserver lines, primary first, through whatever manages DNS on that host (netplan, NetworkManager or systemd-resolved). BIND speaks the same NOTIFY and AXFR/IXFR protocol, and our BIND master and slave guide for Rocky Linux builds the Linux version of this pair. Start DNS on DNS01 again once the test is done:
Start-Service DNSNo record can change while the primary is down, because the secondary refuses writes (the WIN32 9611 error below). Every edit waits for DNS01, so keep primary maintenance short and outside your change windows. The secondary keeps lookups working, not updates.
Troubleshooting zone transfer errors
Each error below was produced on the lab pair, with the exact text the server printed. The refused transfer is the one most readers hit, because the default settings cause it.
Event 6525: A zone transfer request for the secondary zone corp.example.com was refused by the master DNS server
We created the secondary on DNS02 before DNS02 was an NS record for the zone. The secondary logged this error on DNS02 at 11:34:15 PM and repeated it at 11:34:30 and 11:34:45:
TimeCreated : 10/29/2026 11:34:15 PM
Id : 6525
LevelDisplayName : Error
Message : A zone transfer request for the secondary zone corp.example.com was refused by the master DNS server at 10.0.1.10. Check the zone at the master server 10.0.1.10 to verify that zone transfer is
enabled to this server. To do so, use the DNS console, and select master server 10.0.1.10 as the applicable server, then in secondary zone corp.example.com Properties, view the settings on the
Zone Transfers tab. Based on the settings you choose, make any configuration adjustments there (or possibly in the Name Servers tab) so that a zone transfer can be made to this server.At the same time Get-DnsServerZone showed IsShutdown : True, LastZoneTransferResult : 9005 and a LastSuccessfulZoneTransfer of 1/1/1970, and every query for the zone on DNS02 failed:
Resolve-DnsName : web.corp.example.com : DNS server failure
+ CategoryInfo : ResourceUnavailable: (web.corp.example.com:String) [Resolve-DnsName], Win32Exception
+ FullyQualifiedErrorId : RCODE_SERVER_FAILURE,Microsoft.DnsClient.Commands.ResolveDnsNameThe primary logged nothing at all about the refusals, so the event log on the secondary is the only place to see them. Fix it on the primary by adding the secondary as an NS record (Step 2) or putting its IP on the explicit transfer list. Our secondary picked up the zone on its own within seconds of the NS record being added; if yours does not, force it with Start-DnsServerZoneTransfer on the secondary. Also confirm that MasterServers on the secondary holds the real IP of the primary, because the event names the address the secondary actually asked.
WIN32 9611 when adding a record on the secondary
Adding a record on DNS02 fails, because a secondary zone is read-only:
Add-DnsServerResourceRecordA : Failed to create resource record test02 in zone corp.example.com on server DNS02.
+ CategoryInfo : InvalidArgument: (test02:root/Microsoft/...ResourceRecordA) [Add-DnsServerResourceRecordA], CimException
+ FullyQualifiedErrorId : WIN32 9611,Add-DnsServerResourceRecordAMake the change on the primary instead. NOTIFY carries it to DNS02, within 0.7 s of the write on every run we measured.
WIN32 9711 when adding an A record for the DNS server itself
Our first attempt to add dns01 to the new zone on DNS01 failed with ResourceExists and WIN32 9711. The primary DNS suffix of DNS01 was corp.example.com, so the zone had already created an A record for the server itself. The error is harmless. Check the existing record with Get-DnsServerResourceRecord -ZoneName "corp.example.com" -Name "dns01" and move on.
dig AXFR prints “; Transfer failed.”
Running dig @10.0.1.10 corp.example.com AXFR from a host that is not on the transfer list returns ; Transfer failed., and our Linux client got the same answer from DNS02. That is the transfer restriction working, not a fault. A secondary zone on Windows Server 2022 does not pass the zone on to arbitrary hosts either. To prove the primary hands the zone to DNS02, read LastZoneTransferResult on DNS02 instead, as in Step 3, because that field reports the transfer the secondary actually completed.
