Moving from Physical AD/Data Server to Office365
-
@scottalanmiller said in Moving from Physical AD/Data Server to Office365:
@dbeato said in Moving from Physical AD/Data Server to Office365:
@scottalanmiller But you gotta provide the option of an RMM Or agent correct? Because yes you can do scripting but you still need something to deliver it and not doing it manually. While GP can be used without AD, I would say that using GPOs manually is way more PITA than GPO on an AD. That is a discussion for another topic.
Yes, but there are a plethora of options. The question isn't "what's the right approach", the question is "do I need to do this one approach."
And at this skill, generally the best option is "do nothing". The idea that we need this kind of management at all on this scale is weird. There are cases, yes, but it is not the norm.
That's reasonable, I do agree is a case by case basis which often than not is not super needed.
-
@JaredBusch said in Moving from Physical AD/Data Server to Office365:
@Dashrender said in Moving from Physical AD/Data Server to Office365:
@scottalanmiller said in Moving from Physical AD/Data Server to Office365:
@BRRABill said in Moving from Physical AD/Data Server to Office365:
a) logging into our machines
AD is only useful if you are maintaining central creds to log into multiple machines. And at just 10 users, that's considered not to make sense, even by MS standards. So even when that functionality is needed, AD isn't considered a good option for that.
Really? then what is? manually maintaining 10 logons on each machine?
FFS.. Why the fuck would there be 10 local users on each machine?
I'll agree that in most - not just 50%, probably more than 95%, machines are frequently 1 to 1.
But I have a situation you clearly know about - it's 7 machines and 10 people over all of them. With a centralized auth setup, either, they all use one account, or I have 10 accounts on all 7 machines.
-
@PhlipElder said in Moving from Physical AD/Data Server to Office365:
Catch #1: User will not be able to remote into that PC using RDP. Third party yes, but not RDP.
Are you sure? Have you tried this?
Catch #2: The PC is tattooed to Azure AD. One cannot join a local AD anymore (IIRC).
Are you sure? I have had machines that are in AD first and then AAD joined and never had an issue. Now I've never AAD joined first, then added to AD, no clue what would happen there, though I see no reason why it wouldn't work.
As Scott mentioned - there are many options for managing machines today Salt or Intune are examples.
-
@scottalanmiller said in Moving from Physical AD/Data Server to Office365:
@Dashrender said in Moving from Physical AD/Data Server to Office365:
@scottalanmiller said in Moving from Physical AD/Data Server to Office365:
@BRRABill said in Moving from Physical AD/Data Server to Office365:
a) logging into our machines
AD is only useful if you are maintaining central creds to log into multiple machines. And at just 10 users, that's considered not to make sense, even by MS standards. So even when that functionality is needed, AD isn't considered a good option for that.
Really? then what is? manually maintaining 10 logons on each machine?
Nope, maintaining just one, like any normal person.
really - what about the bolded part - multiple people logging into multiple machines? I totally agree if it's a one person to one computer situation, but I quoted you in the multi user to single machine situation.
-
@scottalanmiller said in Moving from Physical AD/Data Server to Office365:
@dbeato said in Moving from Physical AD/Data Server to Office365:
@scottalanmiller But you gotta provide the option of an RMM Or agent correct? Because yes you can do scripting but you still need something to deliver it and not doing it manually. While GP can be used without AD, I would say that using GPOs manually is way more PITA than GPO on an AD. That is a discussion for another topic.
Yes, but there are a plethora of options. The question isn't "what's the right approach", the question is "do I need to do this one approach."
And at this skill, generally the best option is "do nothing". The idea that we need this kind of management at all on this scale is weird. There are cases, yes, but it is not the norm.
Why do you consider it weird? So you're totally on board the users having local admin rights and running as those admins while presumably not working from the office so they can dork up their machines?
We're talking about joe user here, not your company full of IT pros who can self manage their PCs.
Right now, with my users going home and working on their home computers, I'm having to solve little issues that I generally don't worry about because they dont' have a ton of crapware installed on their work computers like they do at home. Now, if it's a BYOD - that's a completely different story, and I'll agree that less administration on their device is desirable, but then you'd also likely put the onus of supporting those devices directly on the user.
-
@Dashrender said in Moving from Physical AD/Data Server to Office365:
Why do you consider it weird?
Because it doesn't generally meet a business need. Doing extra work, taking on extra risk, without a business need is downright "weird."
-
@Dashrender said in Moving from Physical AD/Data Server to Office365:
So you're totally on board the users having local admin rights and running as those admins while presumably not working from the office so they can dork up their machines?
Whoa. How the hell did you go from the topic at hand to this? What in the world does this have to do with what we were discussing? Nothing whatsoever.
This kind of nonsense is exactly what I mean when I say it's weird and people deploy AD without understanding it. That this is your idea of what "non-AD" looks like means you can't know what AD is or this could never have been mentioned. If you think you are avoiding this because of AD, that's AD used by accident.
-
@Dashrender said in Moving from Physical AD/Data Server to Office365:
We're talking about joe user here, not your company full of IT pros who can self manage their PCs.
WE are talking about this. No one knows what you are talking about.
AD has nothing to lead us here, that you are mentioning this tells us you are talking about something unrelated.
-
@Dashrender said in Moving from Physical AD/Data Server to Office365:
Right now, with my users going home and working on their home computers, I'm having to solve little issues that I generally don't worry about because they dont' have a ton of crapware installed on their work computers like they do at home. Now, if it's a BYOD - that's a completely different story, and I'll agree that less administration on their device is desirable, but then you'd also likely put the onus of supporting those devices directly on the user.
Sure, but AD has nothing to do with that. AD doesn't easily work when you send people home, so this is a perfect example of "to get what you want" you'd do best to "not do what you are doing."
-
@Dashrender said in Moving from Physical AD/Data Server to Office365:
@PhlipElder said in Moving from Physical AD/Data Server to Office365:
Catch #1: User will not be able to remote into that PC using RDP. Third party yes, but not RDP.
Are you sure? Have you tried this?
Catch #2: The PC is tattooed to Azure AD. One cannot join a local AD anymore (IIRC).
Are you sure? I have had machines that are in AD first and then AAD joined and never had an issue. Now I've never AAD joined first, then added to AD, no clue what would happen there, though I see no reason why it wouldn't work.
As Scott mentioned - there are many options for managing machines today Salt or Intune are examples.
Yeah, that he is right. If you join to AAD Join first you cannot join AD after that. So if they need both I do the hybrid join on some customers (big ones)
https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-manual
-
@dbeato said in Moving from Physical AD/Data Server to Office365:
@Dashrender said in Moving from Physical AD/Data Server to Office365:
@PhlipElder said in Moving from Physical AD/Data Server to Office365:
Catch #1: User will not be able to remote into that PC using RDP. Third party yes, but not RDP.
Are you sure? Have you tried this?
Catch #2: The PC is tattooed to Azure AD. One cannot join a local AD anymore (IIRC).
Are you sure? I have had machines that are in AD first and then AAD joined and never had an issue. Now I've never AAD joined first, then added to AD, no clue what would happen there, though I see no reason why it wouldn't work.
As Scott mentioned - there are many options for managing machines today Salt or Intune are examples.
Yeah, that he is right. If you join to AAD Join first you cannot join AD after that. So if they need both I do the hybrid join on some customers (big ones)
https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-manual
Interesting.. Thanks.
-
@Dashrender said in Moving from Physical AD/Data Server to Office365:
@JaredBusch said in Moving from Physical AD/Data Server to Office365:
@Dashrender said in Moving from Physical AD/Data Server to Office365:
@scottalanmiller said in Moving from Physical AD/Data Server to Office365:
@BRRABill said in Moving from Physical AD/Data Server to Office365:
a) logging into our machines
AD is only useful if you are maintaining central creds to log into multiple machines. And at just 10 users, that's considered not to make sense, even by MS standards. So even when that functionality is needed, AD isn't considered a good option for that.
Really? then what is? manually maintaining 10 logons on each machine?
FFS.. Why the fuck would there be 10 local users on each machine?
I'll agree that in most - not just 50%, probably more than 95%, machines are frequently 1 to 1.
But I have a situation you clearly know about - it's 7 machines and 10 people over all of them. With a centralized auth setup, either, they all use one account, or I have 10 accounts on all 7 machines.
While you may have a fringe case, that has nothing to do with the posted question at hand.
FFS don't conflate shit.
-
@scottalanmiller said in Moving from Physical AD/Data Server to Office365:
Whoa. How the hell did you go from the topic at hand to this? What in the world does this have to do with what we were discussing? Nothing whatsoever.
The correct response was FFS don't conflate shit (again)
-
@Dashrender said in Moving from Physical AD/Data Server to Office365:
@scottalanmiller said in Moving from Physical AD/Data Server to Office365:
@Dashrender said in Moving from Physical AD/Data Server to Office365:
@scottalanmiller said in Moving from Physical AD/Data Server to Office365:
@BRRABill said in Moving from Physical AD/Data Server to Office365:
a) logging into our machines
AD is only useful if you are maintaining central creds to log into multiple machines. And at just 10 users, that's considered not to make sense, even by MS standards. So even when that functionality is needed, AD isn't considered a good option for that.
Really? then what is? manually maintaining 10 logons on each machine?
Nope, maintaining just one, like any normal person.
really - what about the bolded part - multiple people logging into multiple machines? I totally agree if it's a one person to one computer situation, but I quoted you in the multi user to single machine situation.
Right, and that's how nearly all places are. Especially when you are dealing with people taking machines home. Are there exceptions? Of course. But we've already highlighted that AD is useful when you have that special case.
I literally said it was useful in that one case, and you responded as if I'd said the opposite. And we were saying that its not useful in the general case where 90%+ of companies are.
Normal companies, the vast majority, don't have any real use for people logging into lots of machines at random. It's not normal. At all. It's a valid use case, but far from normal. So for normal shops, implementing solutions based on the niche case is crazy. For those in the niche case, there are lots of ways to handle it, AD is a good one, but just one of lots of ways to tackle it.
-
Wow ... it's been a month since I asked this!
From the responses, I guess there is a third little piece of this, in RMM and also how much I want control over my user machines.
In many ways, I was almost considering them all just having fresh installs, like they went out and bought a new laptop from Best Buy, and now want to attach to Office365.
The files will be there, they can collaborate. Do I really need to provide anything else?
We are currently using an RMM solution still so I can run scripts and assist remotely if needed.
