What works for 100 users very often doesn’t work for 10,000, and vice versa. Few vendors worry about making software created for the enterprise meet the needs of the SMB. Those who try to fit both worlds, rarely succeed.
Specifically, let us look at Active Directory (AD) replication times. By default, AD is scheduled to do inter-site replication every 180 minutes (three hours), which makes sense if the AD is huge, and one or more of the sites is on the other end of connectivity from the past. This value can be changed from the default to occur as frequently as once every 15 minutes, representing a somewhat conservative minimum replication interval.
Nowadays, for many multi-site businesses, 15-minute replication windows are increasingly an unacceptably long choice, whereas the default 180-minute delays are totally impractical. Technology is in constant motion, and recent changes mean Microsoft has to revisit many of its choices.
One of the most crucial issues with AD replication times is that AD integrated DNS zones have to wait on the rest of the AD in order to replicate, which is a real obstacle for today’s new technologies, all designed to be highly dynamic and are totally reliant on DNS.
Another important thing: the time it takes changes made by systems administrators to implement.
 |
StarWind Cloud VTL for AWS and Veeam is built on the Virtual Tape Library, a well-proven and reliable technology allowing to accelerate backup processes. It enables Veeam users to offload their backups to AWS to enhance their IT infrastructures and meet the 3-2-1 backup rule. |
| Find out more about ➡ StarWind Cloud VTL for AWS and Veeam. |
And not administrators only, as the existence of self-service interfaces and hybrid cloud solutions means that systems administrators increasingly have no idea what is occurring on their networks.
Fortunately, there is a workaround. The way to do that is to enable Inter-site Change Notification for the relevant links. Inter-site Change Notification essentially causes Active Directory to treat replication between AD servers located across site links as though they were in the same site. When a change is made it is immediately pushed across. (In fact, it takes 3-5 seconds, which can make a difference for some applications).
The problem with that solution is that in solving some very real problems (like DNS), we create others. The prominent example is: as goes AD replication, so goes GPO dissemination. Even experienced systems administrators have been known to drop down entire networks with a bad GPO.
This issue isn’t going to go away, it’s only going to aggravate. What is needed is a fundamental change in how AD behaves.
Today, AD is (mostly) an all-or-nothing affair. When AD replicates, it all replicates. (There are some exceptions, such as lockouts.) This needs to change.
Overall, individual applications or groups of applications need to be able to set different replication times. It would also be handy to specify the order in which services replicate, if they do it together. DNS replicating ahead of GPOs, for example, would help to solve a lot of problems.
Still, it is an open question whether or not Microsoft is interested in solving the problem, as there does not seem to be a large enough customer who makes a big enough complaint about this.
This is the review of an article.
Source: theregister.co.uk
