Registered: 1451623596 Posts: 184
Reply with quote
OK, this may be a dumb question. I'm working with a non-technical boss and a guy who is a Linux nerd. So we use AD in the office area on all the computers, which everyone is fine with.
But on our manufacturing floor, there is a mixture of AD, Workgroup, and standalone computers. Changes on the computers are rarely done. And they want to standardize the computers to make it easier to support. So either all AD or all Workgroup non-AD computers. So I got the question, "what are the benefits of using AD on the manufacturing floor, since software is rarely pushed to the computers and we rarely have AD authentication issues, we don't use Group Policy on manufacturing computers, we use remote desktop tools that work whether the computer is AD or in a workgroup, etc., etc.," So what is an easy way to explain it to them, the benefits on using AD to manage computers as opposed to having all Workgroup computers and being able to support the computers?
New Friend (or an Old Friend who Built a New Account)
Registered: 1501005838 Posts: 46
Reply with quote
The befit for AD on the floor, although you rarely have authentication issues when you do, it would be nice to have AD to fix.
? just a thought
Registered: 1451586584 Posts: 264
Reply with quote
Since I have been working with Microsoft Business applications for a long time, I have to say that without AD we have really a tradition of very week ways of identifying objects and authenticating access to them in an application.
Kerberos in AD along with DNS allows for objects to be identified and secured. Service Principle name errors were common when there were problems with AD. TCP Sockets were used for connections to SQL Databases. The application servers in turn authenticated to the GUIDs in the tables that Identified the records , users and subsequent objects in the business applications. If you have every worked with business apps or research apps that used simple methods of restoring and retrieving data , you quickly see how crucial AD is. In addition it's been extended in AZURE. For the non tech folks, a similar system is used to connect phones all over the world. The System is what Novel 4.0 started using before AD was deployed by Microsoft. So to me, a system like this is crucial. Even now we can monitor devices for maintenance via this method. OK, Nice to comment on this. Thanks Dennis. Long time no see. Miss all you Minasi group guys. __________________ Curt Spanburgh
Registered: 1451592353 Posts: 418
Reply with quote
late to the party, but felt compelled to chime in so there :-) I've been building ADs since before there was AD, at least, officially. AD is what I still earn my bread with, although not in the same manner as 20 years ago. That said, for me, AD is a default in a Windows shop... except where it isn't. There is a huge difference between designing an infrastructure from scratch (where you can take AD into consideration right from the start) and introducing AD into an existing landscape, especially Group Policies. There is also a huge difference between an office building full of knowledge workers (doing pretty much the same things using pretty much the same set of tools) and a machine floor where almost every computer's configuration is unique, both in respect to the software installed and the persons (admins) to whom the management of that machine is delegated. More often than not, 3rd parties (= equipment vendors) will be allowed unmonitored external access to a certain machine, usually combined with local admin rights. Taking both of those differences into account, here's what I will usually advise to do in this situation: You need SOME tools in place to deploy, manage and monitor those suckers. Whether it's AD, Ansible, InTune, Jenkings or something else for management, depends on what skills you've got at your disposal and what your org is prepared to invest in licenses. Standardization (to whatever standard) is best done when you redeploy or deploy a major update. In those situations, a longer than usual downtime is going to be tolerated so you will get the opportunity to iron out the kinks. Common authentication authority can be a curse as well as a blessing. Think about the vendor having unrestricted unmonitored access to some piece of equipment. Do you *have* to make it easier for these guys to compromise the entire infrastructure. To paraphrase, with the opportunity to unify there usually comes the need to segregate. This consumes time and resources, too. If it's going to be AD, it's all right, but do make sure it's a separate forest form where your Accounting, HR, R&D and other valuable assets live. All in all, for a *diverse* equipment floor, I would go with platform agnostic automation like Ansible and keep the machines separate from each others, authentication-wise. On a *homogenous* machine floor, AD certainly has a great appeal and will probably help streamline things. Make sense? __________________ Evgenij Smirnov My personal blog (German): http://www.it-pro-berlin.de/ My stuff on PSGallery: https://www.powershellgallery.com/profiles/it-pro-berlin.de/