DNS Scavenging is a great answer to a problem that has been nagging everyone since RFC 2136 came out way back in 1997. Despite many clever methods of ensuring that clients and DHCP servers that perform dynamic updates clean up after themselves sometimes DNS can get messy. Remember that old test server that you built two years ago that caught fire before it could be used? Probably not. DNS still remembers it though. There are two big issues with DNS scavenging that seem to come up a lot:
“I’m hitting this ‘scavenge now’ button like a snare drum and nothing is happening. Why?”
or
“I woke up this morning, my DNS zones are nearly empty and Active Directory is sitting in a corner rocking back and forth crying. What happened?”
This post should help us figure out when the first issue will happen and completely avoid the second. We’ll go through how scavenging is setup then I’ll give you my best practices.
Scavenging setup
Scavenging will help you clean up old unused records in DNS. Since “clean up” really means “delete stuff” a good understanding of what you are doing and a healthy respect for “delete stuff” will keep you out of the hot grease. Because deletion is involved there are quite a few safety valves built into scavenging that take a long time to pop. When enabling scavenging patience is required. It will work just fine, but not today!
Note: For purposes of this discussion we are going to concentrate on the most common Windows DNS scenario: Windows Server 2003 DNS servers hosting AD integrated zones.
Scavenging is set in three places on a Windows Server:
- On the individual resource record to be scavenged.
- On a zone to be scavenged.
- At one or more servers performing scavenging.
It must be set in all three places or nothing happens.
Scavenging settings on a Resource Record
To see the scavenging setting on a record hit View | Advanced in the DNS MMC then bring up properties on a record.
Scavenging gets set on a resource record in one of three ways. The first is by someone coming in here, checking the “Delete this record when it becomes stale” checkbox and hitting apply. When you hit apply the time of day will be rounded down to the nearest hour and applied as the timestamp on the record. Static records have a timestamp of 0 indicating do not scavenge.
The second is when a record gets created by a client machine registering using dynamic DNS. Windows clients will attempt to dynamically update DNS every 24 hours. All DDNS records get set to scavenge. When a record is first created by a client that has no existing record it is considered an “Update” and the timestamp is set. If the client has an existing host record and changes the IP of the host record this is also considered an “Update” and the timestamp is set. If the client has an existing host record with the same IP address then this is considered a “Refresh” and the timestamp may or may not get changed depending on zone settings. More on this later.
The third way to set scavenging on records is by using DNScmd.exe with the /ageallrecords switch. Let’s pause here for a few moments to consider a few important words: All, Records, Delete, Stuff. If you actually run this command against a zone it will truly set scavenging and a timestamp on all records in the zone including static records that you never want to be scavenged. Because of the time it takes scavenging to do it’s thing people find this command and get tempted to give it a try. Do not. It will delete stuff. Have patience instead.
Once a timestamp is set on a record it will replicate around to all servers that host the zone. There is one caveat to this. If scavenging is not enabled on the zone that hosts the record then it will never scavenge so the timestamp is essentially irrelevant. The timestamp may get updated on the server where the client dynamically registers but it will not replicate around to the other servers in the zone.
Scavenging Settings at the Zone
Before a server will even look at a record to see if it will be scavenged the zone must have scavenging enabled. To access the scavenging settings for a zone right click the zone, select properties then on the general tab hit the “Aging” button. This screen is universal for the zone. If you view it on any DNS server where this zone is replicated it will be the same.
When you first set scavenging on a zone the timestamp seen at the bottom (reload zone if you don’t see it) will be set to the current time of day rounded down to the nearest hour plus the Refresh interval. This also gets reset any time the zone is loaded or any time dynamic updates get enabled on the zone.
The “zone can be scavenged after” timestamp is the first of your safety valves. It gives clients time to get their record timestamp updated before the big axe swings. Since new record timestamps are not replicated while zone scavenging is disabled this also gives replication time to get things in order.
Refresh and No-Refresh intervals
The next safety valves are the Refresh and No-refresh intervals. Both of these must elapse before a record can be deleted.
The No-refresh interval is a period of time during which a resource record cannot be refreshed. Recall from earlier that a refresh is a dynamic update where we are not changing the host/IP of a resource record, just touching the timestamp. If a client changes the IP of a host record this is considered an “update” and is exempt from the No-refresh interval. The purpose of a No-refresh interval is simply to reduce replication traffic. A change to a record means a change that must be replicated.
After the (Record Timestamp) + (No-refresh interval) elapses we enter the Refresh interval. The refresh interval is the time when refreshes to the timestamp are allowed. This is the time when good things must happen. The client is allowed to come in and update it’s timestamp. This timestamp will be replicated around and the No-refresh interval begins again. If for some reason the client fails to update it’s record during the refresh interval it becomes eligible to be scavenged. Will it disappear immediately? Probably not but it is certainly possible.
Note: When setting Refresh and No-Refresh intervals be sure to allow enough time for clients to get several registration attempts during a Refresh interval. Failure to do so could allow a record to become eligible for scavenging simply from a failed refresh attempt.
One last thing before we leave the zone setting behind. If you right click on your server you will see the option to “Set Aging/Scavenging for All Zones…”. Selecting this will take you to a screen similar to the one above. What does this do? This sets the default settings that will be used if a new zone is created by this server. Unless you check the subsequent box “Apply these settings to the existing Active Directory-integrated zones” it will not touch existing zones.
Scavenging settings on the Server
So you now have a resource resource record set to scavenge and a zone set to scavenge. All that is left is for somebody to come along, check all the timestamps and delete some stuff. This is done by any server that hosts the AD integrated zone.
Setting scavenging on the server is done by right clicking the server in the MMC, selecting properties, going to the advanced tab and checking the “Enable automatic scavenging of stale records” checkbox.
The Scavenging Period is how often this particular server will attempt to scavenge. When a server scavenges it will log a DNS event 2501 to indicate how many records were scavenged. An event 2502 will be logged if no records were scavenged. Only one server is required to scavenge since the zone data is replicated to all servers hosting the zone.
Tip: You can tell exactly when a server will attempt to scavenge by taking the timestamp on the most recent 2501/2502 event and adding the Scavenging period to it.
Although you can set every server hosting the zone to scavenge I recommend just having one. The logic for this is simple: If the one server fails to scavenge the world won’t end. You’ll have one place to look for the culprit and one set of logs to check. If on the other hand you have many servers set to scavenge you have many logs to check if scavenging fails. Worse yet, if things start disappearing unexpectedly you don’t want to go hopping from server to server looking for 2501 events.
To facilitate strict control over which server is scavenging for a zone you can use DNSCmd.exe to specify exactly which servers may scavenge. For example the following command will make it so that only 192.168.1.1 and 192.168.1.2 DNS servers are allowed to scavenge on the contoso.com zone:
DNSCmd . /ZoneResetScavengeServers contoso.com 192.168.1.1 192.168.1.2
With the server now scavenging, zones enabled for scavenging, and resources records set what actually happens when the server does it’s thing?
The scavenging process and final safety valves
When the last 2501/2052 event + the server scavenging period comes around the server is going to make a scavenging attempt. You can also manually initiate an attempt by right clicking the server and selecting “Scavenge Stale Resource Records”. Note that manually making an attempt in no way bypasses the safety valves. These are the final safety valves before we “delete stuff”:
- Is scavenging enabled on the zone? Pretty self explanatory.
- Is dynamic update enabled on the zone? If it’s not there is a good chance timestamps will be old enough that mass deletions can occur.
- Is the scavenging server listed as one of the “Scavenge Servers” for the zone?
- Are we past the “zone can be scavenged after” timestamp on the zone? This gives the clients and AD replication to get things squared away before we start.
- Has it been longer than a refresh interval since this zone was last replicated in Active Directory? If scavenging gets enabled on a server that has replication issues this will prevent it from tombstoning a bunch of records that may be perfectly fine on other servers.
If all of the above checks are good then the zone is ready to be scavenged. At this point the scavenging server checks the timestamp on each individual resource record. If the current date/time is greater than the timestamp + No-refresh + Refresh then the record is deleted.
My best practices
Here is how I set scavenging up on a preexisting zone. This procedure is designed for maximum safety. Using default settings this process can take as long as 4-5 weeks (2 weeks Sanity phase, 2-3 weeks for Enable phase)
Setup phase
- Turn off scavenging on all servers. To confirm scavenging won’t inadvertently run use the DNSCmd /ZoneResetScavengeServers to confine scavenging to a single server then ensure this server has scavenging disabled.
- Turn on scavenging on the zones you wish to scavenge. Set the refresh and No-refresh intervals as desired. If you want things to scavenge more aggressively I would recommend lowering the No-refresh interval at the cost of some replication traffic. Leave the refresh at the default.
- Add today’s date plus the Refresh and No-Refresh intervals. Come back in a few weeks when this time has elapsed. Seriously you can’t rush this.
Sanity check phase
Sift through your DNS records looking for any records older than the Refresh + No-Refresh interval. If you see any then something has gone wrong with the dynamic registration process and it must be corrected before proceeding. A thorough check at this point is the most important step in setup
Things to check if you find old records:
- Does an IPConfig /registerdns work?
- Who is the owner of the record (see security tab in the record properties)?
- Was the record statically created by an admin then later enabled for scavenging? If so you may need to delete the record to clear ownership and run an IPConfig /registerdns to get it updated.
- Is the server replicating OK with AD?
Do not proceed unless you can explain any outdated records. In the next phase they will be deleted.
Enable phase
The final step is to actually enable scavenging. Enable scavenging on the single server you used the /ZoneResetScavengServers command on.
Once enabled create a new test record and enable it for scavenging. Then map out the point in time when this record will disappear. Here is how:
- Start with the timestamp on the record
- Add the refresh interval
- Add the no refresh interval
- The result will be your “eligible to scavenge” time. The record will not disappear at this time though. It’s just eligible.
- Check your DNS event logs for 2501 and 2502 events to find what hour the DNS server is doing a scavenging run.
- Take your “eligible to scavenge” time, find the most recent 2501/2502 event and add the server’s Scavenging Period (from server properties | advanced tab) to it. This is the point in time when the test record you just created will disappear.
Lets look at an example with the following assumptions:
- Zone is set to a 3 day Refresh and a 3 day No-Refresh interval
- Server Scavenging period is set to 3 days
- Last DNS Event id 2501 or 2502 occurred at 6am on 1/1/2008
- We have a record with a timestamp of 1/1/2008 at 12:00 noon
Given these assumptions you can rub your temples for a bit and predict that the record will be deleted at approximately 6am on 1/10/2008.
Once scavenging is enabled you can check back periodically to look for the 2501 and 2502 events to see how things are going. You can also come back at the predicted date and time and see if your test record disappeared.
That’s it!
Hi
Great article – but in my DNS i have records from servers with static IP adresses that dosn’t have a current timestamp. If i manually run ipconfig /registerdns the timestamp is updated correctly. It seems the timestamp is from when the machine first had a static IP adress. Why isn’t the timestamp updated on serveres with static IP’s and how can I avoid these records from being scavenged (without manually clearing the "Scavenge this record" check box)??
Question regarding Sanity Check (the most important step):
We have a lot of DCs which are DNS servers, and the Time Stamp data for records is not the same on all servers, since this information is not replicated before enabling Aging and Scavenging.
How can we make sure that no important Host record will be deleted, when we have inconsistent time stamps among different DNS servers?
Ed,
Here is the script for exporting Time Stamp information from your DNS server:
On Error Resume Next
Const SERVER_NAME = "<DNSServer>"
Const DOMAIN_NAME = "<DomainNameToQuery>"
Const WBEM_RETURN_IMMEDIATELY = &h10
Const WBEM_FORWARD_ONLY = &h20
Set objWMIService = GetObject("winmgmts:\" & SERVER_NAME & "rootMicrosoftDNS")
Set colItems = objWMIService.ExecQuery("SELECT * FROM MicrosoftDNS_AType", "WQL", _
WBEM_RETURN_IMMEDIATELY + WBEM_FORWARD_ONLY)
For Each objItem In colItems
If InStr(1, objItem.DomainName, DOMAIN_NAME, VbTextCompare) > 0 Then
WScript.Echo "DnsServerName: " & objItem.DnsServerName
WScript.Echo "DomainName: " & objItem.DomainName
WScript.Echo "Name: " & objItem.OwnerName
WScript.Echo "IPAddress: " & objItem.IPAddress
If objItem.TimeStamp > 0 Then
WScript.Echo "Timestamp: " & DateAdd("h", objItem.TimeStamp, "1/1/1601 00:00:00 AM")
Else
WScript.Echo "Timestamp: Not Set"
End If
WScript.Echo
End If
Next
I have run into this issue several times: My customer has a fairly large network, with several subnets.
Great info
The section “Scavenging settings on the Server” mentions in the last paragraph the command “DNSCmd /ZoneResetScavengeServers”. The following point should be added for clarification:
When the DNS server on which scavenging is enabled is not listed in the allowed scavenging servers for a zone, scavenging will not take place. To see which servers are currently allowed to scavenge, run the command “DNSCmd /ZoneInfo ”. If there is a section “Scavenge Servers” at the bottom of the output, then those DNS servers whose IP addresses are listed are the only ones that can perform scavenging on the specified zone. If there is no “Scavenge Servers” section present, then any DNS server otherwise permitted can perform scavenging on the zone. The command “DNSCmd /ZoneResetScavengeServers ” with no server IP addresses listed will remove the “Scavenge Servers” section so that any DNS server can perform scavenging. The command “DNSCmd /ZoneResetScavengeServers ” will restrict scavenging ability to the DNS servers whose IP addresses are listed, and will replace any previously configured Scavenge Server IP address list, if any. Specifying a list of Scavenge Servers for a zone adds a stricter level of control over scavenging, but creates a potential troubleshooting issue if the scavenging server is changed and the Scavenge Servers IP address list is not updated. Removing the Scavenge Servers list relaxes control and eliminates this potential troubleshooting issue.
Laurence, I completely agree. It doesn't make sense. In an org of about 2000 devices, I'm meant to clean out a DNS zone containing about 8500 entries without using scavenging because we've apparently had trouble with it deleting current devices. I'm hoping it'll be easier to fix/correctly configure scavenging than to go through 8500 DNS entries by hand!
So the Setup Phase involves turning off scavenging on all servers. Then configuring it in the zones. If you haven't actually enabled scavenging at the server level yet and it was never on to begin with, why wouldn't there be older dates still? Nothing is cleaning them up yet as scavenging needs to be set at all three of record, zone, and server for any clean up to happen.
I am missing something in the chain of thought here.
Scavenging is one of the most complicated aspects of MS DNS. It isn’t simple to predict what will happen or when it will happen. Personally, I think it should be enabled by default and set fairly aggressively but I’m jaded from my personal experience. GREAT info in the blog; VERY helpful! Keep up the posting – this stuff is sooo helpful to the troops in the field.
Thanks very much for a well written explanation of the failsafes and timeframes involved in enabling scavenging.
during the sanity phase you advised to look at records older than refresh and no refresh interval, before checking Do I have to run scavenging manually from the GUI with the option "Scavenge stale resource record" ?
Thanks indeed for the docs it is very helpfull
Simon,
When doing the sanity check you (the admin) are really in read-only mode. You are just looking through your records. If you’ve done the previous steps then records should be getting updated regularly via DDNS. This point is your last chance to catch anything that’s not working before scavenging truly begins.
It’s a tedious but important step. If you are managing large DNS zones then you could automate it to some degree by using DNScmd to export the zone then scrub it via script, Excel, or something similar.
Manually scavenging is often of little use. If scavenging is properly setup then it will work without intervention. If it is not properly setup then both automatic and manual attempts will fail. aka… "I’m hitting this ‘scavenge now’ button like a snare drum and nothing is happening. Why?"
Hilde,
I agree. The best way to do scavenging is to flip it on when the zone is first created and is still empty. Any RRs that appear in the zone from DDNS are obviously working ok. Any RRs that you create manually will have the scavenge checkbox cleared by default. Either way you are safe.
I’m not sure I would want the default settings to be more aggressive though. The 7 and 7 day intervals seem rather arbitrary at first but when you look at the default DHCP lease time of 8 days it makes more sense. DHCP attempts a renew at half the lease interval right? So 4 days + 2 days + 1 day = 3 attempts within a single 7 day interval.
Thanks for the feedback everyone!
-Josh
I added a Host (A) record for my UNIX client (sunws1) and an Alias (CNAME) record (activedsvr) for the DC as the (Kerberos) KDC that my UNIX machine will authenticate to. After a week or so, I noticed I couldn’t authenticate from the UNIX client to my DC, and all my DNS records I had added were gone – scavenged I believe. I only have one DC, and I’m not replicating to any other DC. It’s a closed test network. I turned off scavenging, but why would I ever want my aliases and host records to disappear? Or is this only an issue when a system has only one (1) DC (and not replicating anywhere)?
Brian,
Scavenging is a solution for some problems that creep up when using dynamic DNS. When clients update their own records there are situations where incorrect or outdated records can be left behind. For example, mobile clients roaming between two DHCP servers can cause fits with the PTR records that some unix apps use for "client verification".
Scavenging will never delete a static record and you would never want it to.
If you created a static record and found it disappeared then either the scavenge checkbox got checked or a client came along and made an update to this record and in doing so flipped it from static to dynamic. Setting DNS to only accept secure dynamic updates will prevent this as the DDNS client will have no permissions to the record (barring use of the DNSupdateProxy group).
In the case of a Domain Controller (Microsoft KDC) it will continuously update it’s records so even with scavenging they will not disappear. If for some reason the DC goes offline for an extended period then scavenging will take out the record just as you would want it to. It will reappear if the server ever comes up again.
-Josh
Thanks for this usefull reply. I’ve got a question about record ownership in DNS. When I try to see whom is the owner of a dynamic record, the owner tab always display "SYSTEM" on the "current owner of this item:" field. Is that correct ?
Thank you, great article! Only one correction. We had a problem with the "Setup Phase". You wrote
1. … DNSCmd /ZoneResetScavengeServers can be used …
2. Turn on scavenging on the zones …
But the command in (1.) does not work before scavenging in turned on at the zone level.
Otherwise:
Error, failed reset of scavenge servers on zone rsint.net. Status = 9611
Command failed: DNS_ERROR_INVALID_ZONE_TYPE 9611
We opened a call at microsoft and they told us we have to enable scavenging on the zone first. Not logical but that’s it!
Hermann
Very good explanation, especially compared to other articles including Microsoft Technet. Thank you.
Does anyone know of a CD/DVD step-by-step video instruction on DNS? I am a visual person and feel more comfortable.
Should I set all of the DNS records (servers, etc.) to no refresh, i.e., no to delete this record when it becomes stale?
I, personally, would perfer just a little more info out of the 2501 events. Aside from doing an export of the zones before and after, I have no way of telling what got axed. Are there any methods to getting some kind of report as to what zones got scavenged?
Very well written and informative. Thanks.
Another tidbit; If you want to test by manualy starting the Scavenge process, you can "Scavenge Stale Resource Records" from the Action menu. The system will only allow you to do this once very 30 minutes.
Super important before enabling DNS Scavenging is to verify that the DHCP Client Service for DCs and all important member servers is up and runnning!
If not A and PTR records will not be refreshed (Note: this DNS registration function has been moved to the DNS Client in Windows 2008), you’ll have all SRV records for DCs thanks to the Netlogon Service but without the A records they will end up being useless…
This is another known reason for "I woke up this morning, and my Active Directory (and/or critical servers) was sitting in a corner rocking back and forth crying. What happened?"
Either I didn’t see it, or it isn’t in the write up. IIRC the scavenging server resets its timer for the scavenging event on reboot or restart of DNS service. Which would meen the 2501/2502 may not be a valid gauge of the next scavenging event. Is that true?
In manual and auto scavenging we will not be knowing what are the records get deleted.
How to check what are all the records will get scavenged before starting manual scavenging of stale records. Any command or Script?
We enabled scavenging last Thursday and it is scheduled to scavenge for its first time after 7 days. In the meantime we found that our printers had A-Host records that had their box checked for scavenge stale. Since we use DHCP mac-reservations for these printers they have not been updating the DNS record, thus are stale. We have since unchecked that box on all printers, however I am not sure whether or not the list of scavenged items was already marked last Thursday when we enabled scavenging, or if it waits until this Thursday and rechecks all records prior to its sweep action. Does anyone know? Thx
Josh, So the scavening service will not check the "delete when stale" check box. So if you have manaually unchecked static records they are safe from scavenging.
You can run DNSCMD /zoneExport zonename
This sends a text folder to system32/dns folder and all records that are marked for deletion (aging) have the word Age in the text output. You should then be able to parse through the data realatively easily to find the static records.
To answer my own question above I setup a lab with a 2 day setting on the savenging server and ran a scheduled task to restart DNS once a day.
Scavening ceased to occur.
So as far as I can tell a restart of DNS (reboots count) resets the counter for scavenging.
I am about to enable scavenging on a large domain at zone level following the advice in this article. In preparation, I need to disable scavenging at DC level using the dnscmd /zoneresetscavengeservers command to prevent the risk of some DC already being configured to scavenge.
As previously commented, this can only be done if the zone is enabled for scavenging.
How do I get past this hurdle? If I enable scavenging in the zone now, there will be a risk of records being scavenged before their current timestamps are replicated.
The only option I can see is to manually go through all DCs and until scavenging.
Any ideas?
As noted above, does a static DSN record get scavenged if it is set to be delete for becoming stale? If so how can we make static DNS entries never get touched?
Hi
Great article.. But in my DNS i can see the serveres with static IP adresses haven’t got a recent time stamp. If I manually run ipconfig /registerdns on one of these serveres the timestamp is updated. How can I make sure that my records for serveres with static IP adresses wont get scavenged??? And why is the timestamp not updating – seems to have the date when the static IP adress was configured???
I believe static records do not get a timestamp and the "Delete this record when it becomes stale" box checked
There is a way to export the DNS zone to see the timestamp and flags for each record. I can’t remember where but should be easy to find by a search
PEP,
Where are you seeing this timestamp? The DNS record isn’t timestamped unless you have "Delete this record when it becomes stale" box checked.
TO export you can right click on the zone and click on export. This will create a .csv file or .txt to c:windowssystem32dnsbackup.
Is there coresponding dnscmd option (or other tool) available to do Uncheck "Delete this record when it becomes stale" for my serveal hundreds servers (that were checked by defaul when the records were created)?
I have a question:
What is the best configuration for a environment with many VPN connected clients?
My problem are double dns entries.
I am very interessted at the following values(days or hours??):
non-refresh:
refresh:
Scavenging:
DHCP lease:
Hi guys,
What’s the process for checking the age of DNS records? I’ve exported the DNS data to a text file but it states "[AGE:3579465]" on all records, what does this mean and how do interpret this numbers?
Also I can’t find a way of distinguishing between dynamic and static DNS entries, how can I confirm a static entry?
Thanks in advance.
The AGE is calculated by adding the age number (which is number of hours) to the date 1/1/1601..
So in C# you can calculate it like this..
DateTime rootTime = new DateTime(1601, 1, 1);
DateTime expires = rootTime.AddHours(age);
Hi Everyone,
This is a great blog post and explains a lot of things, but I have a problem I am not able to resolve.
It is said that in "Sanity Check" phase, most important step is to check for old Time Stamps for records. I found a script and exported Time Stamp information from one of the DCs, only to find out that if I export from another DC, Time Stamp data is different.
As it happens, Time Stamp info is not replicated between DCs if the zone is not set to be Aging.
How can I check my records if I have a lot of DCs (DNS servers) in different locations/AD sites, and DDNS process works on all of these servers?
How can I be sure what will be deleted, and which server should I choose to perform scavenging?
Thank you.
Milan,
I have the same question, I see inconsistent record time stamps across my DNS servers. Even after forcing replication across the Active Directory Integrated Zone.
If anybody has info on why, or how to fix, would appreciate it.
Would sure be nice to know WHICH records were removed and WHY in the default logging. Presumably we can get this info with debug logging, but who runs debug logging on their DNS servers 24/7?
Twice now I’ve had ACTIVE systems purged from DNS by scavenging. Yes, upon reboot the system will re-register its record, but the business process that access these systems via DNS 24/7 FAIL until the record is manually recreated or the system is rebooted. FLAWED DESIGN!!
Hi,
really its a great article about DNS scavenging.
I need help.
We are trying to understand why our AD is growing compare to last year.
When we ran ADRAP tool it shows the DNS nodes (30010)
Tombstoned DNS nodes (200001) toal (230011)
this might be because of low scavening / aging value set
what will be best scavenging time set to have other than default settings
Server properties is set to Default 7 days
no-refresh interval set to 2 days
refresh set to 2 days
DHCP lease is 8 hrs.
can anyone please suggest me what will be the best settings for our environment (as DHCP lease is 8 hrs keeping in mind)
Thanks in advance
Great article.
I’d recommend that you export DNS records to Excel and examine their timestamps during the sanity check phase. There are excellent instructions on how to do this here:
http://blogs.technet.com/networking/archive/2008/05/21/export-dns-records-to-excel-to-read-time-stamps-and-static-records.aspx
This will allow you to determine exactly which records will be deleted by the scavenging process.
so the big question here is how can you log the records that were scavenaged? I get a 2501 stating x records or nodes scavenged, is there a way to log all the records that were removed?
Hello,
The article was very informative. I’m lucky I found a link to it. I have a question about the relationship between the lease time in DHCP and the scavenge period-no refresh interval-refresh interval. If I need to set my DHCP lease to one day what must I set my scavenging parameters at?
Has anyone experienced issues with Linux servers falling out of DNS? Using product called Likewise Domain join to place Linux server in AD domain. After period of time, server A records falling out of DNS forward lookup zones, but not all only some?
Great article! Any reason why this would delete some of my server A record? I set it up, and for some reason some of them got deleted. In ALL cases, the servers have static IP's with dynamic DNS registration. Thanks.
I have clients with DHCP reservations; leases expire in 30 days and scavenging is enabled for 7 days. So the clients try and renew every 15 days (1/2 of 30) but theyre scavenged every 7 so host records are disappearing. is it just a matter of extending the refresh, no refresh, and scavenging period to longer than 15 days?
does anyone know of some animated tutorial on how dns scavenging works? Thanks.
Helpful write-up, but this is still a PITA multiple server editions later. Job security, I guess….
Pingback from DNS issues. HELP!
One of my duties as a Microsoft Premier Field Engineer (PFE) is to make sure the products a customer
This is a collection of the top Microsoft Support solutions to the most common issues experienced using
These are the top Microsoft Support solutions to the most common issues experienced using Microsoft Windows
We’ve gathered together the top Microsoft Support solutions for the most common issues experienced
S'applique à Windows 2008 R2 Server, Windows 2012 Server, Windows 2012 R2 Server hébergeant une ou
These are the top Microsoft Support solutions for the most common issues experienced when using Windows
As a Microsoft Premier Field Engineer I frequently get asked for more information on Active Directory topics. Most of the time I end up passing along one or more of the links in today’s post. This list will be extremely valuable for anyone who wants
Top Microsoft Support solutions for the most common issues experienced when you use Windows Server 2008
Top Microsoft Support solutions for the most common issues experienced when you use Windows Server 2008
Top Microsoft Support solutions for the most common issues experienced when you use Windows Server 2008
Los equipos con Windows permiten actualizar dinámicamente su registro A en el servidor DNS local al que
Dougga here – PFE (or “poofy” as one of my customers likes to call us). The DNS scavenging topic never
Well done Josh!
Top Microsoft Support solutions for the most common issues experienced when you use Windows Server 2008
Hi, we have four (4) dns servers in one AD domain and one zone. Clients get ip addresses from dhcp server. Different client's RR are in different dns server, and we also static RRs. timestamp values refresh in dns servers. When I open the dns management
console in different dns servers, I saw same host, same ip but different timestamp ? What should we to do host's timestamp values can be replicate between different dns servers ?
A host of reference material for AD and Group Policy