DNS Scavenging Simplified

I must admit that for years I was confused and afraid of DNS Scavenging. Horror stories of others losing lots of records and my own ignorance caused me to avoid it and disable it rather than learn how to configure it properly. After reading Microsoft's documentation and getting more confused, I stumbled across some comments someone made online that helped me begin to decrypt DNS Scavenging. Here is what I have learned over the years that I wish someone had just spelled out clearly for me long ago.

1. DNS Scavenging is almost always necessary. Unless you are managing all your DNS records manually, you really do need scavenging enabled to prevent duplicate DNS records and stale records for decommissioned servers. Without scavenging, you are much more likely to end up in a situation where two records exist for the same name, then you have a Round-Robin issue where half the time the resolution works and half the time it doesn't.

2. What the heck are the No-Refresh / Refresh intervals? In simple terms, the No-Refresh interval is the amount of time that the record is not allowed to be updated. This is to reduce DNS replication traffic. The Refresh interval is the amount of time that the record is able to be refreshed, before it is scavenged. I've seen many places where they set the No-Refresh interval to 7 days and the Refresh interval to 1 day. Unfortunately this drastically increases the likelihood of losing records.

3. Should I leave the No-Refresh / Refresh intervals at the default? Usually no. Microsoft recommends setting the No-Refresh and Refresh intervals to match the length of the DHCP lease.  This is to prevent two names pointing to the same IP address and causing reverse DNS lookup issues. What I find humorous is that the default for No-Refresh and Refresh intervals are both 7 days, but the default DHCP lease is 8 days. That means that out of the box, if you enable DNS Scavenging you are going to be likely running into issues.

4. Where do I enable DNS Scavenging? There are really two places that it needs to be enabled, and this is where I see most of the issues when scavenging isn't running at all. First, you need to pick a DNS Server in your environment to be the server that does the scavenging. There is no benefit to enabling it on multiple servers unless they host different zones. Having it enabled on multiple servers for the same zone can cause many issues when the scavenging runs at the same time. Right-click the DNS Server, then select Properties. On the Advanced tab, check the box to Enable scavenging. The Scavenging Period is how often you want the Scavenging to run. The default is 7 days, but I prefer to have it run every day.

After you enable it on a single DNS server, then you need to enable it for the entire zone. Right-click the zone, then click properties. On the General tab, click Aging. Check the box to enable scavenging and set your intervals. If your DHCP lease is 8 days, I prefer to set the No-refresh interval to 1 day and the Refresh interval to 7 days.

5. Is there anything I should do prior to enabling scavenging? YES!!!

• I recommend exporting a list of all your DNS records, in case you need to add any static entries after scavenging runs. You can do this by clicking on the DNS Zone and waiting for all the records to enumerate. Then right-click the DNS Zone and select Export List.
• Check all your servers to see the timestamps if they are not static entries. This will tell you whether updates are happening for your important records. 
• If you want to be extra careful, you can prevent a record from getting scavenged by selecting View, Advanced in the DNS Manager, then double-clicking on your DNS entry. You will now see a box that says Delete this record when it becomes stale. To prevent a record from being scavenged, simple uncheck this box. Prior to implementing DNS Scavening, I highly recommend doing this to every server, just as a safety net to make sure nothing critical is scavenged by accident.

This is not intended to be an exhaustive list of everything related to DNS Scavenging. My intent was just to demystify some of these settings for sysadmins so they can feel more comfortable enabling these features.

Exchange 2013 Authenticated Relay Possible Gotcha

This might never happen to anyone else, but just in case, I wanted to save someone lots of time troubleshooting the problem.

Background: Upgrading from Exchange 2007 to Exchange 2013, one task was to point our email relay DNS name from the Exchange 2007 environment to Exchange 2013. This handled authenticated relay as well as anonymous relay.

Problem: Once we moved the DNS name, authenticated relay from our printer/fax/scanner systems stopped functioning. We received a generic SMTP error. Unchecking authentication in the configuration and using anonymous relay worked fine when we added the IP address.

Solution: I discovered the account being used on the problem devices was a generic user account without a mailbox. The username was something like scan@domain.com, while the devices were configured for noreply@domain.com. This worked fine in our Exchange 2007 environment, but to get it to function in Exchange 2013, I had to mail enable the user account, then add the specific noreply@domain.com as a proxy address to the mailbox.

Note: It would have certainly been possible to reconfigure the devices to use a different account, or a different send from email address, or even switch them to anonymous relay.  However, in a large migration with many of these devices, it is easy to miss some. I wanted to ensure a smooth transition and address reconfiguring these devices later.

Common mistakes with Windows DHCP Configurations

Changing DNS settings to "Always dynamically update DNS records"

There is a very common misunderstanding that takes place frequently in relation to this setting. Common sense would indicate you should select this option to make sure DNS records are always updated. However, we're not supposed to use common sense here. What this setting doesn't mention, is that the default option of "Dynamically update DNS records only if requested by the DHCP clients", means that the DHCP client will update its own record automatically and only ask the DHCP server to do so if it is unable. One example of it being unable to update the record is if the record was already created and the computer account doesn't have permissions to that record. Unless you know for certain you have a case for changing this, then leave it at the default. If you are having issues with records updating, then most likely you have a DNS Scavenging issue, not a DHCP issue. If the second option to Always update is selected, then the DHCP server tells the client not to update the record, that the DHCP server will handle it. What's the problem then, Wes? Well, most people forget to configure credentials for the DHCP server, which means if you have installed DHCP onto a DC, you are in an extremely vulnerable configuration, or you are simply unable to update the DNS records. What I've seen most frequently is that DNS isn't being updated because DNS Scavenging is not enabled.  Someone then sets this to Always dynamically update, then they don't configure credentials, and the DNS records never get updated. So if you are selecting the Always dynamically update option, don't forget to enter credentials.  http://technet.microsoft.com/en-us/library/dd145315%28v=ws.10%29.aspx

Conflict detection Attempts set to 0
While we are on this screen, make sure you set the Conflict Detection Attempts to at least 2. Microsoft recommends setting this option to allow DHCP to send a ping to an address before handing it out. This is useful in preventing IP address conflicts when someone manually assigns an address within a DHCP range. I prefer to set it to 2 since I have seen some environments where a switch might not have an entry in the ARP table for that MAC address, and it drops the first ping, but then finds it. By setting it to 2, you can ensure that you have given your switch time to update the ARP table and aren't relying upon a single ping before handing out the address. If you're concerned about slowing down the process, I wouldn't worry about it. Having made this change in dozens of environments, I never ran into anyone that was able to notice the difference in boot times of the clients.

Not enabling scavenging in DNS
I will go into more detail in another post about DNS, but I do want to mention that scavenging should be enabled and the Refresh/No Refresh interval should equal the length of your DHCP scope. If you are scared to enable scavenging, good. You should have a healthy fear of screwing up your environment. I highly recommend exporting your list of DNS addresses prior to enabling scavenging. However, don't let the fear of issues prevent you from configuring your servers properly. DNS Scavenging can be configured to work properly. Let me repeat. DNS Scavenging can be configured to work properly!

Forgetting to remove or update legacy Authorized DHCP Servers
While it usually isn't the end of the world, it is possible to put yourself in a pickle by leaving legacy addresses in DHCP as authorized servers. Not likely, but while you are in and cleaning things up, this is a good place to look. Right click DHCP, then select Manage Authorized Servers. Make sure you only remove the old IP addresses. If you authorized a DHCP server, then replaced it later with a server with the same IP address, but a different name, you will want to make sure you unauthorize the old one with the wrong name, then authorize the new one. I've seen situations where an old authorization works because the IP address is the same, but then someone deletes that authorized server later because the name is different. Then everyone stops getting DHCP addresses until someone realizes they need to add that DHCP server back into the authorized list.

Catch-All Subnets in Active Directory Sites & Services

Background: On many occasions consulting I encountered countless organizations getting the 5807 Event ID on their Domain Controllers. This well documented and there are many blog posts discussing the need to make sure that all subnets are created in AD Sites & Services and attached to the appropriate site.

Problem: Some workstations are authenticating to Domain Controllers in the wrong site, in spite of all the wonderful information available. In fact, many companies are experiencing this and don't even realize it.  After all, the workstation will still authenticate and sometimes the issues are just slow authentication and extra WAN traffic.

Solution: In a perfect world, the AD admins would be notified of every subnet created and ensure they were created and placed in the appropriate site in AD Sites & Services. In reality, this rarely happens. As a way to ensure clients aren't authenticating to the slowest links, a Catch-All subnet can be created to force clients to a specific DC in a higher bandwidth site. Most companies will have a faster connection to their main datacenter, so creating an all-encompassing subnet and attaching it to this site will ensure clients go there if a subnet is not defined for them.

Will this force all my traffic to that one site?!?! No. The subnets start at the most restrictive and work their way to least restrictive. So if you have a subnet defined with a /24 network, all clients on that subnet will authenticate to that site and will only authenticate to your /8 Catch-All if they aren't already defined elsewhere.

Example: You have a client with an IP address of 10.0.7.7, but as the subnets and sites are created for 10.0.6.0/24 and 10.0.8.0/24, your have a client without a site and you can't control where they authenticate. If you create a subnet of 10.0.0.0/8 and attach it to your main site, then any client on a 10.x.x.x subnet that isn't defined, will authenticate to your main site. This doesn't work for everyone, but the majority of businesses I've consulted for didn't have Catch-All subnets and needed them desperately.  There is a great article on the pros and cons of Catch-All subnets, that while 5 years old, is still quite relevant today. http://technet.microsoft.com/en-us/magazine/2009.06.subnets.aspx

Note: I have decided to take some of the things that I found most commonly to be issues in my years of consulting, and create these posts to help System Admins do a little of the easy clean-up on their own. Save up that consulting budget for projects that you really need, and take care of some of this easy cleanup yourself.

OWA with multiple child domains

Background: We have a network with multiple child domains, each of which need to access OWA.

Problem: People don't want to put in Domain\Username to login. Typing is difficult and any keystrokes putting in the domain\ are calories just wasted. Our users want to just type in their username to login.  This is easily done when you have one domain, and there are many posts that already cover this. What I had a hard time finding was how to do this with multiple domains in the forest.  I noticed this was possible on our Exchange 2007 environment that was stood up well before I arrived, but I was upgrading to Exchange 2013 and couldn't figure out how to make this happen.

Solution:  I noticed when I did a get-owavirtualdirectory command on the Exchange 2007 CAS server, it returned a value for DefaultDomain as \ and LogonFormat as "Username". Since I couldn't put in this value in the Exchange 2013 EAC, I tried it through PowerShell and it worked.

Set-OwaVirtualDirectory -identity "casservername\owa (default web site)" -LogonFormat UserName -DefaultDomain "\"

Update: I also found this setting can be done in IIS, and can also be changed for ActiveSync.  To do this in IIS 7 or 8, go to the Default Web Site, then click the owa or Microsoft-Server-ActiveSync virtual directory. On the right, under IIS, double-click Authentication, then right-click Basic Authentication and choose Edit. For Default domain, input a \. Do not use quotation marks. Once you've made the change, do an IISRESET for changes to take effect.