It's time for Microsoft to revisit dated defaults What works for 100 users frequently doesn't work for 10,000. The same is true in reverse, however, there are far fewer vendors worrying about tailoring software designed for the enterprise to the needs of the SMB. True mass market software needs to walk the tightrope between both worlds, and very little of it succeeds. Let's …
I used to work a lot with Novell's NDS. When AD first came out, Novell liked to brag about how poor AD replication was[1]. Novell claimed that with NDS, only the changed attribute would be propagated between servers, whereas with AD, the entire object had to be resent.
By the sounds of it, AD hasn't progressed in the years since I stopped being responsible for directories.
[1] I'm not claiming NDS was perfect, BTW!
Novell did like to talk about that, but in practice it made little difference as the Comms links had grown sufficiently that being able to replicate over a 64kbps link wasn't really a winning feature. My experience was that the Novell protocol was much more fragile and harder to fix when it did break. I am not convinced that adding more complexity to AD would improve it. Making a GUI setting for change notification would be a plus though.
Also, using slow replication as a release mechanism is horrendous and risky. Get caught at the wrong time in the cycle and you have no protection anyway. Design a staging area or group and make changes to a copy of the GPO, then re-link to release. Or similar. There's lots of options.
"What works for 100 users frequently doesn't work for 10,000"
If you implement a critical and complex system such as AD for 10,000 users without proper planning and choosing the right configuration settings for your environment you deserve what you get!
"whereas with AD, the entire object had to be resent."
Nope. Fixed in Server 2003. Active Directory replicates directory data updates at the attribute level.
"AD hasn't progressed in the years since I stopped being responsible for directories."
Implementing AD ideally requires some design and planning. Don't confuse choosing safe default values with no progress. The defaults are designed to not break limited WAN connectivity and to not overload limited bandwidth networks...
I think that the biggest difference was that the original version of AD would synch a group change by synching the entire group, whereas NDS only ever synched deltas, and did so from day one. By AD 2003 I think this was resolved and it became less chatty and less of an issue.
Though I think that AD 2000 had options to replicate directory data by SMTP didn't it?
NDS always had far better tools for directory querying and consistency checking - good old DSREPAIR.NLM would do for most things.
Anyone remember selecting "Cancel all timestamps and declare a new epoch?" - guaranteed to fix any and all NDS problems, provided you ran it from an NDS server that was healthy. Kind of like saying "You WILL replace what YOU know with what I have".
"Not being of the MS tribe AD isn't a thing I've ever had to look at so I never realised it was that bad."
Honestly? It's not. I really don't know what Trevor's getting at with this one, but I get the feeling he's releasing a bunch of pent-up rage from 10 years of having to remember to connect to a remote site's DC to reset passwords (or having to tell the Senior Vice President of C-Suite Fellatio that he has to wait upto 15 minutes to log in).
There's about a dozen ways to force immediate replication (as opposed to only going through Sites and Services, which I personally only find reason to open once a year or so) - and you could fairly easily just set up a scheduled task that does a repadmin -replicate every 30 seconds if it bothers you that much.
One of the advantages of AD is that it's simple, straightforward, reliable, and it does what it's supposed to do properly. That's why it hasn't undergone any serious revision in ten years, and why it's still basically better than most of the alternatives (opendirectory and IPA are pitiful by comparison, with less functionality, more complexity and generally worse performance). I'd say that AD (and it's integrations) is one of - if not THE - main reason that MS has been able to maintain it's stranglehold over the enterprise in spite of shitty business practices, bad design decisions, and awful product development.
The fact that the only thing Trevor has been able to find fault with it over is 'the default replication timetable is too long nowadays' should be taken as indicative of strength rather than weakness, really. It's simple enough that you can entrust access to a 17-year old helpdesk monkey without worrying about them getting confused and accidentally destroying your whole network (unlike GP, which to my mind is far, far, far, far more in need of a massive overhaul - or outright replacement).
I thought that was the issue.
If we have attribute-level replication, why doesn't AD default to pushing password changes out immediately? That is one of the things everyone wants immediately. Why not have different queues (like switch/router queues) for updates which can be on different timers?
>That's why it hasn't undergone any serious revision in ten years, and why it's still basically better than most of the alternatives ...
Maybe, or maybe everyone saw what MS did to Novell and decided that the only winning move was not to play, leading to a lack of competition and stagnation. The really messy part of network administration is the desktop/users space and if MS isn't going to let you play with those, there's not much value left to add.
>AD (and it's integrations) is one of - if not THE - main reason that MS has been able to maintain it's stranglehold over the enterprise
True, but that doesn't mean the directory is a good one. By locking third-parties out of the authentication system, MS ensured that the client-server integration was theirs alone. Given where NDS was, I suspect we would have had a better directory system now had MS integrated with, or licensed, NDS. I would rather have seen MS buy Novell than Skype.
Novell should have gone for *nix harder and focussed on using their directory to manage the deployment of services. They stayed too much in the infrastructure space and let MS take the solution space and then eat the infrastructure as well. Ah, what might have been....
"If we have attribute-level replication, why doesn't AD default to pushing password changes out immediately? That is one of the things everyone wants immediately. Why not have different queues (like switch/router queues) for updates which can be on different timers?"
Because it's considerable additional complexity with marginal benefit, mostly. Could AD be more efficient? Sure. Does it need to be? Not really. It's an extremely fundamental part of the infrastructure of 95% of the businesses on the planet. Screwing with it for the sake of minor inconveniences is basically a bad idea - much like MS's obsession with screwing with interfaces that work just fine has routinely been a disaster, only the potential bad consequences here are far, far worse. If it ain't broke...
"Maybe, or maybe everyone saw what MS did to Novell and decided that the only winning move was not to play, leading to a lack of competition and stagnation. "
Nah, that's meaningless to the Open Source crowd. MS had defeated more or less all the competition in the desktop space by the mid 90s, but that didn't stop Linux from developing past 1995. AD, much like DNS or DHCP, isn't an area where we need innovation and competition. Tech in general obsesses over 'disruption', even to the point where it looks to disrupt and innovate in places where stability is preferable. This is one of those areas, imo.
"True, but that doesn't mean the directory is a good one."
It kinda does, actually. AD is a good directory system; while we can all put on some rose-tinted glasses and fondly remember Netware, it was actually pretty limited and failed to transition into the demands of 1990s networking as networks went from tens of computers to tens of thousands. NDS couldn't scale quickly or easily, requiring hundreds of partitions with no indexing; it couldn't integrate with DNS and had no API; it's grouping was primitive and it's syncing was awful - in fact, the 'advantage' of it being able to sync individual objects wasn't an advantage at all, it was because the architecture was too primitive to synchronize in bulk so it was ALWAYS transferring objects one at a time.
Sure, we could pretend that with another 20 years of development, NDS would have become something amazing... but it's just as likely that it was a tech dead-end which simply wasn't designed with the demands of modern computing. AD was, and the fact that it's still basically unchanged isn't from lack of competition, but rather the lack of competition stems from AD being 'good enough' for all we've asked of it every since.
Twenty to forty minutes to 1st boot.
All day to change all the settings, most of which are stupid defaults for the majority and have been for 20 years.
Unless you have preconfigured images etc.
No wonder most consumers home PCs are badly set up. This is not just an AD problem, but historic to almost every configuration issue of Windows.
"Twenty to forty minutes to 1st boot."
I think you mean more like ~ 5-10 minutes (for a clean non upgrade install at least). Sounds like you haven't installed Windows for a while...
"All day to change all the settings"
Or just set them once by Group Policy or via Desired State Configuration. Can't think of a single thing I needed to change from the express defaults on a clean install of Windows 10 though...
"Unless you have preconfigured images"
No need to touch the images for that.
"No wonder most consumers home PCs are badly set up"
You can blame PC manufacturers for that...Most home users never have to install an OS from defaults...
"Can't think of a single thing I needed to change from the express defaults on a clean install of Windows 10 though..."
Generally agree with your post except this - peer to peer updating and phoning home every 20 seconds are NOT something you want on your network, unless you like the idea of 500 PCs uploading Anniversary Update continuously over your out-pipe for the next three weeks.
"peer to peer updating and phoning home every 20 seconds are NOT something you want on your network"
Peer to peer updating - don't see why you wouldn't want that on a local LAN versus downloading each update multiple times, but phoning home - probably not - hence why it doesn't in the corporate versions...
Image uploaded to fog. Sysprepped with core software. Takes 4 minutes to image to host, first boot takes up to 5 minutes depending on the drivers (we use snappydriver) then 1 min to reboot and autojoon the domain (another restart after renaming). FOG decides the OU so other software might install.
Id say from bare metal an i3 with 4g ram takes no more than 20 kins from start to ctrl.alt.del ready domain.
All thanks to gpos and a bit of planning. W7 and w10 take about the same time (we never mass rolled out 8)
I'm not even bothering to paste the links for this, but this matter is completely irrelevant.
The usage of sites has changed since Server 2012, if not even 2008 R2.
A different site is only needed, when using slow links, as in ISDN or 56k.
Since years we're using ADSL, Cable etc. with speeds of multiple mbit.
From an AD point of view that is not a "slow link", hence a separate site is not needed for that, you can use OUs for the separation.
Just add the subnets to the central site and immediate "in-site" replication will be in place.
~ 10 years ago this article might have been relevant.
"sites also determine which AD server a client should use for authentication?"
Yes, hence why sites are only really needed to differentiate very slow links, etc.
So how else does the client localise it's requests?"
It uses the fastest domain controller to reply to a ping.
Actually, you're quite wrong. "Sites" are more than just a useful means to mentally break up domain controllers. They are used by other applications that hang off AD to determine network topology for their replication, to determine how to break up the load on the AD servers (latency matters!) and more.
Also: putting everything in a single site doesn't solve the problem of needing different propagation times for different classes of object, which is ultimately what is required.
"Actually, you're quite wrong. "Sites" are more than just a useful means to mentally break up domain controllers. They are used by other applications that hang off AD to determine network topology for their replication,"
Microsoft says a site is a set of well connected (LAN speeds or greater) IP subnets. That can easily be your entire organisation these days...
"to determine how to break up the load on the AD servers (latency matters!) and more."
No, sites are not for that. Active Directory already has load balancing techniques built into it. Also Netlogon contains load balancing features that will automatically exclude logging onto to slower to respond (potentially overloaded) DCs.
"putting everything in a single site doesn't solve the problem of needing different propagation times for different classes of object, which is ultimately what is required."
That's never required in AD, and the entire design of AD is to avoid such differentiation.
Of course if you get too high a frequency of changes, the danger is that your system never converges on a stable state. AD and the directory systems that predated it depend for their scalability in part on both the relative stability of the directory tree and a correlation between subtrees and physical locality.
Increasing the frequency of replication may be a short term fix but in a truly fast-changing environment a different architectural solution may ultimately be needed.
Now I am going from memory, but I am sure since at least 2008 AD there's been an internal flag for urgent replication for certain attributes so they're pushed out immediately.
Oh and as for the crock about change your password, and wait 15 minutes...do some research.
What has happened for some time now is the password change is IMMEDIATELY sent to the PDC emulator. If a user were then to authenticate against a DC in a different site and the logon attempt fails, it's passed directly to the PDC Emulator as that will always have the latest password.
If it still fails, so be it - it's the wrong password. If it doesn't, then access is granted.
Ah I've even found an article from 2008 explaining this... https://blogs.technet.microsoft.com/kenstcyr/2008/07/05/understanding-urgent-replication/
Where did I say "change your password"? I remember discussing a password being locked out, and new device joins taking time, but not passwords.
Edit: I ctrl-fed the article, and "password" doesn't come up at all. Also, please note: "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."
That bit about lockouts was a reference to URGENT replication. Something that only applies to specific conditions, such as passwords and lockouts. Cheers.
IIRc, it was one of the other commentards that was complaining about password change replication.
I've *never* need password changes not propagate within 3-5 minutes at the absolute outset, and usually it's because the end user was hammering on the local DC after the support droid at the site on the far side of the network reset the user's password on their local DC, with the end result of the user's account still getting locked out at the PDCe at the hub site between the two.
New device joins, coming in via a MDM out in the cloud via federation or proxy or some other means? Yeah, I can see that happening. but password resets? Nope.
It gets... _interesting_ when the FSMO decides to drop off the network. (Or worse, you've done the role seizure on a copy of a DC and it accidentally gets put on the production network and the two FSMOs get into gun fights over who the man is....)
Don't ask how I know this. :)
Yeah password changes and many other things are sent immediately and do not rely on the schedule. This has been the case for quite some time, as are account disable changes and so on.
There are ways to force an immediate replication if you need it, has been as long as I can remember, and there are many other inaccuracies (as usual) with your post.
There are ways to manually trigger immediate replication, yes. So what? How is that solving the problems discussed?
I am not responsible for your ailing memory nor your inability to comprehend what you read. As usual, the so-called "inaccuracies" you detect are entirely in your personally errors regarding merging of what's read with what you think you "know".
"The marketing exec's shiny new notebook was thus not working in time for a major customer presentation and words were exchanged with IT. Loudly."
More the fault of the marketing exec than AD really - seems to be mandatory for sales . marketing folk to only try and set up things at the "last minute" & then blame someone else when things do not go smoothly & it takes more than a nanosecond to resolve the issue.
Quick tip to marketing droids - dry run well in advance of any major customer presentation should be mandatory to stop hidden gotchas, especially if using a new bit of kit
"Quick tip to marketing droids - dry run well in advance of any major customer presentation should be mandatory to stop hidden gotchas, especially if using a new bit of kit"
That'll be 5 minutes before attempting to connect to the new projector with a 9 pin to discover it only has HDMI then?
You want replication more frequently than every 15 minutes? What about laptops that are offline?Needless to say there are lots of ways of doing DNS that have nothing to do with AD replication.
The point of a Directory is that updates are infrequent so you put it in a distributed system. A user joining the company or a server being set up, etc. Within a single domain usually it's pretty instantaneous anyway.
If you really need to (hint: you don't) you can force an immediate replication with dcdiag.
Part of the problem is that of having a single monolithic system doing many different tasks... Some it does well, some it does very badly, so you end up doing all of them in one place out of convenience.
A more modular system would work better, where you choose the individual components that suit your own individual requirements
Microsoft desperately wants people off AD and onto Azure AD as their primary authentication source, but Azure AD's not quite ready for all the tasks AD does today and will be in place for quite a while. Having defaults that seem like they're from a different era does actually make sense. If you're a total newbie building out a new AD for a customer (which admittedly doesn't happen much these days, but we do it pretty frequently) you're going to want to hold down replication traffic until the admin confirms it doesn't need to be held down. Since a lot of replication traffic is RPC based and extremely chatty, it's possible to fill up a small network link if you don't set things up right.
We're used to LAN speeds on our broadband connections here in the first world, but outside the US, Europe and Southeast Asia, it's not uncommon to have leased lines at very low speeds and very high latency. Same thing with satellite links, cruise ships, etc. It's entirely possible if you have a localized environment and all your locations have Metro Ethernet links back to HQ, that you don't really care about replication intervals and clients can log on to any domain controller. But, this can be a problem in big directory environments with lots of policies, logon scripts that take forever to run, etc.
I haven't been an AD newbie for years, but I can imagine someone looking at some of the stuff from Windows 2000 era and saying "WTF?" Things like SMTP-based replication and the old super-complex multi-forest multi-domain model only make sense if you have a real need for them these days. But the funny thing is that Microsoft hasn't really rewritten the Distributed Systems Guide from the Win2K Resource Kit in its entirety, so people may be going back to that as a primary reference.
"Microsoft desperately wants people off AD and onto Azure AD as their primary authentication source"
No it doesn't. That would only work if you had EVERYTHING in the cloud. Azure AD is currently designed to compliment onsite AD, not to replace it.
Regardless of the rest of this article I call bullshit on the marketing exec example. Even the amazingly stupid executives in marketing couldn't pull that one off.
So this marketing exec purchased a brand new laptop from a vendor, opened the packaging on the laptop and less than 15 minutes later walked into a meeting with said laptop and tried to do a customer presentation with it? Riiiiight. The exec would have to get their vanity items working for it first, load it with all their music and then make sure they had their really important power points available before they walked into that meeting. Oh and have the picture of their pet / children / partner on it as well.
So how did this exec know to register their device? Clearly they were told and given instructions to do so otherwise the exec would never have been able to do it. The instruction pack didn't warn them that it would take 15-30 minutes in BOLD LETTERING ALL OVER THE PACKAGE SO AN EXEC WOULD UNDERSTAND for it to register on their network?
Sounds like the problem exists in the service delivery not MS's replication times.
So this marketing exec purchased a brand new laptop from a vendor, opened the packaging on the laptop and less than 15 minutes later walked into a meeting with said laptop and tried to do a customer presentation with it? Riiiiight.
Not an unreasonable nor unheard-of scenario by any means. I can see this clearly: the computer the exec would normally use which was carefully set up and configured by ITS has barfed up (yet, again) because of all of the things this user has done to it. The user decides the computer is a piece of crap, and since every time he or she calls ITS he or she is told that his or her preferred usage of the computer is the cause of all problems, aforementioned user, having read plenty of tech blogs and threads on the matter, decides the only solution is to obtain a replacement machine immediately. Again, ITS is obviously incompetent as it takes at least several hours for the request for a replacement machine to be handled, so a quick run off to Worst Buy is the ticket, and there will be JUST enough time to run in, be talked into the completely wrong thing by the Blue Shirt, and dash back, open it, pop in the USB stick and once again shine as PowerPoint Hero.
FTFA:
"...a marketing executive who purchased a new notebook and registered it against the company's network using the provided cloud-based mobile device management service, as she had been instructed."
Yes, there were instructions, and while you have the pithier parts of what supporting a marketing exec is like, you have conveniently ignored that said marketing execs will almost always ignore the important parts of the instructions which give the caveats as these are not "action items" but rather "informational items" which are seen as optional -- read that as, "items not to be read" no matter how bold or what color the print.
"Regardless of the rest of this article I call bullshit...The exec would have to get their vanity items working for it first, load it with all their music and then make sure they had their really important power points available before they walked into that meeting...So how did this exec know to register their device? Clearly they were told and given instructions to do so otherwise the exec would never have been able to do it..."
A) Do you know anything about Microsoft endpoint solutions? From client software to the tools built into Windows Server such as Roaming Profiles and Folder Redirection? If they had logged in, they'd have all their stuff made available with rapidity and all their customization intact. If you know what you're doing, that part works reasonably okay.
B) The "how to register" was made available through the company intranet which, if I recall, wasn't checked by the marketing exec before the device purchase. There was some kerfuffle about screeching at the local store staff to pull up the info as the marketing exec was "in a hurry", and then scrambling to follow all the steps. War stories swapped over beers revealed hilarity...
"The device was added, it began to receive emails, but her attempts to log in to the network failed."
She should have SSHed in and used PINE to access her email.
--
DHCP: Dynamic Host Configuration Protocol
DNS: Domain Name System
DNS Zone: A contiguous portion of DNS space administrated by a single manager
GPO: Group Policy Object
GUI: Graphical User IUnterface
Hybrid Cloud Solutions: A combination of in-house hardware and Cloud services, costing twice as much without any apparent advance in usability
IPv6: Internet Protocol Version 6
ISDN: Integrated Services Digital Network
Load Balancers: Allows two or more web servers to act as one, thereby speeding up client browsing.
Marketing Executive: A salesman with an office
Mcroservices: Allows remote clients to access servers through exposed native API calls, such as the Amazon API Gateway
Pine: Program for Internet News & Email
PowerShell: A Microsoft clone of BASH
Self-service Interfaces: Possibly another name for exposed native API calls
SMB: Small Medium Business
SSH: Secure Shell
@Walter, you made my day with this, thanks:
>Hybrid Cloud Solutions: A combination of in-house hardware and Cloud services, costing twice as much without any apparent advance in usability
As for Trevor ... please stop giving MS ideas how to fix things .... like a mouse in the paws of a cat, they are doomed ... what you are doing is akin to chasing the cat away and "hoping" the hurt mouse will stand a chance ... don't worry, the cat will come back as soon as you have turned your back ...
The fun thing will be to see all those MS-only shops with a massive "IT know-how" problem ...
Is that MS benefits from you continuing to use their products and therefore has an interest in fixing what is clearly broken; whereas governments can be much harder to divorce, and $om€one ¥ou failed to vote out of office bene£its from those bad la₩s.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
