[MUSIC PLAYING] Welcome to this great session on how to migrate On-Prem Active Directory Computer Accounts to Azure Active Directory. Today we're going to talk about the history and the challenge associated with these projects because it's got a long history back to the early NT days. We're going to talk about cloud adoption and remote working and the challenges that adds to doing these projects. We're not all in the Office anymore so these endpoints are all over the place, which makes this project even harder in how to deal with. With all the challenges that we have and opportunities, we're going to try to answer the question, is it time to make the switch?
A lot of organizations are ready, but we're going to review all the challenges to get there as well. Some orgs aren't ready or some may have to take some half steps to get there. But let's talk about the dream, the dream of migrating your computer accounts to on-prem-- from on-prem to Azure Active Directory. It's a secure world without VPNs. In our modern working environment we're not in offices anymore so users having to connect back to an on-prem virtual private network is really a pain in the neck, it's a lot of wasted hardware, and really quite a challenge.
When we talk about managing endpoints it can be a challenge because these users may not touch the VPN. So you may have long gaps before you can do actually management on those devices. We want to do a self service. We want users to be able to set up their own device, automatically connect into the cloud and get all their services and data down. So we really want to ensure that we're getting rid of all these barriers, which, unfortunately, on-prem computer accounts can add barriers and challenges here.
We talked about easy device deployment and replacement, we want to collaborate with everyone anywhere without barriers. We want centralized policy control. We mentioned if you're not connecting into the VPN, if you make a change in group policy the user has to connect in to get that change. If they never get in they're never going to get that policy change. So we want to be able to control these devices wherever the users are and we want that configuration to always be current and active.
And we need to deal with lost and stolen devices. Again, these are features that you get through Azure Active Directory and some of the features that you get in Endpoint Intune and Management. But to get to that dream we have to make a lot of changes to infrastructure and tooling. So with that, Becky is going to help us out and go over some of the definitions and the tooling that is involved when we talk about the differences and how to get from on-prem Active Directory computer accounts to Azure Active Directory joined devices.
Thanks Mike. So let's start talking about the comparisons between Active Directory and Azure Active Directory. With original Active Directory we had this environment where management and deployment is done with Group Policy and maybe even some third party tools or SCCM for being able to push out the updates and perform all of the management of your devices. We also have the standard authentication that we're all used to with NTLM and Kerberos using an LDAP type configuration. And as Mike said, a lot of this configuration with Active Directory requires that VPN connection, especially in today's world where more and more users are working remote.
And so, as he mentioned, there is that challenge. If you're trying to push out policies to manage these devices, if your users are no longer connecting into their VPN because everything else that they use is out in Exchange Online or on OneDrive, their devices might not be receiving those really important updates and policies that you want them to receive. So how do we solve this? Well, we've started moving into Azure Active Directory. With Azure Active Directory we now have a little bit more control and everything's out in the cloud.
And we're going to introduce this concept of a device identity, which I'm going to go into detail on, but there are some differences for the management and the authentication that we bring in and add when we come out to Azure Active Directory. We've got the idea of Microsoft Endpoint Manager, which has a lot of different tools for managing the devices, pushing out, deploying software, and deploying devices themselves.
And then we also introduce conditional access policies, which give you a lot more control for your user identities and those device identities that I want to go into a little bit more deeply. So in Azure AD there are two common divisor identities. You might actually be more familiar with what's called an Azure AD Registered Device, this is what your users have been using for any MDM management for their mobile devices.
If a user has a bring-your-own device, whether it's a cell phone or an iPad or any other device that they own, they can still become Azure AD registered. And this lets you perform a little bit of management, maybe push out some Intune policies to those, but they aren't truly joined to your Azure environment. So instead, there's a concept of an Azure AD joined device, this is the device identity that we'd be talking about as we start moving our real devices from that on-prem Active Directory out to Azure Active Directory. So just like being domain joined in AD, you are now going to be Azure AD joined as a device identity, but that's just for cloud only.
Most commonly, what we see today, is that you probably have some sort of hybrid environment. You have your original AD and you've deployed Azure Active Directory Connect and it is able to sync up your users, your groups, and your devices to Azure. Now, a lot of people don't realize that devices can be sensed up there as well because when they started deploying this it was mostly for exchange online, deploying those cloud mailboxes, granting them access to OneDrive, SharePoint, all of that, but you can bring your devices into scope for AADC so that those devices also show up in Azure. And those can now be managed from both places.
You can still manage them with group policy, you can push out your updates that way and control all of that. And your users can still access all of their network resources even if they have to connect to a VPN to get to those, but now, in addition, you can control their devices with those conditional access policies and be able to do some Intune management on those devices as well. So bringing in these new device identities really opens up a lot of new possibilities. Now, I mentioned Microsoft Endpoint Manager. It's not just a single tool, it has a wide variety of uses.
So the first one is Intune, again, this is what you are probably most familiar with because a lot of companies started using it for their mobile device management. In addition to being able to manage those mobile devices, you can also push out software to various devices. And as we start bringing in these Azure AD joined devices, this is how you'll be able to manage those laptops and workstations as you bring them up to your Azure environment. In addition to Intune, we have a Configuration Manager option. So for those of you who are in a hybrid AD environment, your devices are still on-prem and you haven't quite completed the move to Azure, you can start using Configuration Manager to replace some of what your group policy is taking care of today so it's there to help you out in that hybrid state.
Endpoint Manager also provides a lot of autopilot options. Autopilot is huge, it makes it so much easier to deploy new devices to your users. Instead of having to order a laptop, bring it in to your central IT, configure everything, log in as the user, and then have to ship it out to the user, you can automate all of this by having those devices just preprepared so they can be shipped directly to your end user. They start it up, they log in, and they are ready to go with their autopilot device. So many of these items are already included in your SKU if you have some of the Azure premium services.
So take a look at what you have and start using these to manage some of your devices. Now, we want to do a little deeper dive and so I'm going to hand it back to Mike to talk a little bit more about group policy and authentication.
Thanks, Becky. And those are really the two largest challenges when we look at these projects, group policy and authentication. So let's review GPOs and how we got here. And this is a common scenario in organizations that have really grown over the years and leveraged group policy for the devices.
When we first implemented our first group policy in Windows 2000 we had one policy. And then we added a department policy or a country specific policy so then we had two policies. Then we need an exception for maybe our executives or another group of users so we had another set of policies to undo the other policies. And then one weekend somebody really needed a different policy so we added another policy to undo that policy. And it just continues through this cycle, as you can see here.
And then we added server policies so these may have started as configuration policies for user workstations then we needed server policies, but then we added terminal servers in Citrix environments so then we needed more group policies to undo the server policies to make them more look like user policies. And then we're left with these layers, on layers, on layers of policy and now we're trying to figure out what to do and what needs to move over to Configuration Manager when we do the change.
And as a reminder, when we talk about layers, these are the three main settings in a group policy, not configured, which means nothing will happen, enabled, or disabled. But when we look at the layering, this example, in the screen shows-- So I have a turn on script execution GPO policy and if we had a different setting for each one of these policies it all depends on what the last policy is and what's going to get applied in the order.
So we talk about auditing our group policies and moving them to Azure Active Directory or Configuration Manager, what is the current active policy for a user? The effective policy for a user gets very, very confusing and problematic. So in this case, if we're going in order, the setting would be disabled, despite some of the others that the user may be in where it would be enabled. So what do we do? Configuration Manager is likely going to take the place of GPOs in your environment or some other third party tool.
The temptation that we run into in these projects, that Becky and I have worked on so far, is to try to copy all of our GPOs over and make it all the policies, one by one, bring them together and apply them into Configuration Manager. We're finding that is really having mixed results, particularly if you have a lot of layers and a lot of complex policies. Many firms don't have clear documentation why they put in that emergency group policy on a random weekend in 2007. They don't know why they did it, they may not even have clear documentation who the user applied to, and really putting that back together is very difficult and unnecessary because it's 13 years later, life is very different, we're in a different operating system now even. So making those decisions is really difficult.
Most firms are finding it's time to start fresh, they can move to one common policy and maybe an exception policy here and there. There's so many challenges with moving and getting these settings correct like getting an accurate move and copying them over is pretty much impossible. Some C settings are not compatible either so trying to copy them all and understand them may not have the right end result anyway. The other aspect is these settings may not be correct in your cloud-centric world. These may have been settings that you put in place when everyone was coming in on a VPN or even back when everyone was on the same network.
So it might be time to adopt a new template or new process to bring everyone to a modern standard and then move forward from there. There's some good options to help you figure this out. With the layering it can be quite difficult, but Microsoft has a great tool, the Microsoft Policy Analytics Tool, which is different than the analyzer tool, but this tool is actually in public preview and is in your tenant today. It's a really cool tool that allows you to export a group policy and import it into this tool and it will tell you about any policies that are not compatible and then it'll actually even make the configuration policy. It doesn't address the layers though and this becomes a problem.
So if you've got 20, 30, 40, 100 group policies, one by one you're bringing them in and still doing the analytics. So this is a real good slam dunk if you've got one or two policies, but if you have a lot this is really a tool in the process to help you find policies that may not be configured correctly or to help you get your master policy in and configured as a place to start. What you want to understand in your path to getting there is, if this is a very long, long road a third party solution may be helpful here because you can control these options in that third party solution.
So larger environments that have a two, three, four, year project on their hands may find that third party tool can help bridge that gap in a more effective manner and deal with some of these policy disconnects that we mentioned earlier so keep that in mind. If you're a short project it's probably best to go straight into Configuration Manager.
The other big challenge is legacy application authentication. A lot of our legacy applications are leveraging on-prem Active Directory for authentication. Many can support modern options, but there is no need to change it because it's working, it's supported, and why change it.
However, now that we're making plans to go to Azure Active Directory, we have to make remediation plans and move away from these legacy application authentication methods into a more modern method modern [? auth ?] with Azure Active Directory. There are going to be some assets simply won't support it, these are apps that maybe are really old, or legacy, or, for whatever the situation is, need to remain on-prem. Whatever your decision is, they may not support these authentication methods so it's important to make a plan for those that are left behind.
These apps are those that are relying exclusively on Kerberos and NTLM authentication that may not have another option available to you. If you find you have apps that are in this scenario you can deploy Azure Active Directory Domain Services, it's a mouthful, which is essentially turning on Domain Services in a manner where these applications can leverage that other authentication, but you need to be careful because it does take a lot of setup and know how. And you've got to be really careful about the configuration and network routing because if the application is remaining on-prem you've got to do routing and control to ensure that that's working effectively. So it's a great tool and a great option, but there are some challenges still with applying for it.
The other thing to keep in mind is the applications and settings. So applications that may have configuration settings that were being set in GPOs or custom pieces that you put into GPOs, those may not come over. That's definitely in the category of settings that may not come over to Configuration Manager. So if those are critical pieces for security or configuration you're going to have to look at other options on how to control those application settings. But you might have some applications that aren't ready, you might have some critical applications that cannot consume the new modern authentication method so you have to make a plan for them.
If it's only a few users, you may choose to leave those users behind an on-prem. That seems logical and if you move 98% of your users and leave to 2% behind that may be the right thing until you can get that last application moved up. The other aspect is you can leave those exceptions with people coming back in. That can mean they can come back in on a VPN and you can tie that VPN into Azure Active Directory or other methods for them to come back and authenticate. You can migrate the problem applications to another application, but that may take time.
So that's when we're talking about leaving users behind for a period of time, that's buying you more time to do the remediation. If you're going to have a longer term problem where there's one or two really critical applications and that's just where that's going to be and it's holding you back, you may want to put those applications into a solution like terminal server or Citrix or other virtualization platforms so that users can come back in, use that in the streaming environment to actually get to that application do their work, but then you've been able to bring their desktop experience for it into Azure Active Directory and these other tools that we're talking about today. So this is going to really depend on your situation and what you're dealing with. So I'm going to hand it back to Becky to talk about the cost impacts on how to tackle one of these projects.
All right. Thank you, Mike. So, obviously, change isn't free, Azure isn't free. So what does this mean for you? Where can you save and where can you spend a little bit extra?
So the first thing to keep in mind is Azure Premium Services, this is where you're going to get your Microsoft Endpoint Management, your Intune, to be able to help and deploy some of those policies and software updates to your devices, be able to do your autopilot. Some of these, like we said earlier, are included in your SKU but some of them might not be. And so if you do want to start migrating out to Azure make sure you take a look at what you can get from those Azure Premium Services to help you with that management, that migration, and being able to make that final move.
One thing that a lot of people forget about our servers, it's not just migrating the end user devices, that might actually be one of your easiest things to handle, but those servers, once you've attacked all of those legacy application authentications and figured out how to move forward, you can't just migrate most of your servers straight up to Azure. And so, instead, you will need to deploy some Azure VMs to be able to handle those, for the VM 2019, for instance.
So make sure that you take a look at what servers you still need, what can you consolidate. And one cool thing about servers in Azure is you don't have to actually have them on all the time. You might have some application servers that only need to run a few hours a day, maybe they only need to run during the week and they can be shut down on the weekends and so one of your cost considerations are the cost to A, have those servers and B, run those servers because those can be two different costs. So those are some of your costs of moving to Azure.
Costs for staying on-prem is those physical costs of having your own on-prem data center, having your domain controllers housed in your local branch or wherever you have them, there are hardware costs associated with those, you do have to upgrade them over time if you want them to keep running smoothly. So again, there are costs in either direction and you just have to decide what those differences are and make sure you budget for them when you start to plan this move. You can stay fully on-prem and if you do that, then you already know your cost. You've been doing it for years and so you should be able to get those numbers. If you think you can fully go cloud only then that's great, sign up for those Premium Azure Services and those VMs and turn off all of your on-prem stuff.
But like we said earlier, it's most likely that you'll probably be in a hybrid arrangement for some period of time so you might actually have to have some costs in both places for a period of time until you're able to completely make that change. But in addition to just the infrastructure and tooling, there is a cost associated with actually making the change so make sure that you train your support staff.
Most people, if they haven't had to run Azure previously and do this management, it's going to be brand new to them. So make sure to sign them up for training, make sure they know how to push out these new policies, how to manage these new cloud devices. And then also think about your end users, what's going to change for them?
Is it something that you can just send out some emails for or do you want to maybe get one of those third party training companies and create some little videos that they can record and send out to your users so they know what's coming, they know what's going to change with their log-ins? So both the support side and your end user side just make sure you train them and communicate well. In addition to that, update your documentation. You have so much documentation for your daily processes. If you want to push out a new policy, you probably have a test OU and you create a group policy, you push it just to that. When you're ready, you finally push it out to production.
Well, if you move out to Azure, you no longer have that concept of, OUs and group policies so you need to update your documentation to address how are we going to do this in the cloud to test it and then push it out to prod. There's also the cost of device deployment. If you have users who are using really old devices you may have to deploy newer ones to make sure that they are actually supported by Azure. And then there are the migration tools themselves. There are many third party migration tools out there that can help you with provisioning these user accounts, preparing your environment.
And many third party migration tools are actively working on helping ease this transition of migrating your devices from on-prem up to Azure only because we know that this is the future of devices. And lastly, for cost, there's just the cost of everyone's time and effort. It's going to take time to do the training, it's going to take time to do the move itself. And so just make sure you budget for that in your planning. This is not something that you're going to be able to handle just in a single day.
And so with that, we'd like to jump in to a few just quick top tips. First, I'm going to hand it back to Mike and he's going to tell you what his key points are for you.
Let's talk about the top tips on how to migrate on-prem Active Directory computer accounts to Azure Active Directory. And just like all projects, we want to be pragmatic. We may not be able to do everything all at once so let's dive in and see what we can do. For GPOs I really encourage you to consider starting new.
If you started putting in GPOs with server 2000, a lot has changed since then. It's probably time to bring these policies forward into Configuration Manager with new options and into a modern place and bring your organization's posture forward. Inventory software and get ready to go now. While you're starting to get everything together, understand what applications are going to need to be reconfigured and can be reconfigured. As we've said, a lot of these applications support modern authentication they just don't need to today.
So you can find a lot of applications do support modern authentication, you just need to make the switch. And you want to remediate these as quick as you possibly can, that way you can focus on actually doing user documentation, testing your policies and procedures, and getting ready for this really exciting, but big, project. The other thing to consider is you're doing an operating system upgrade, it may make sense to do this switch as part of your operating system upgrade. So for example, if you're considering moving to Windows 11 in the next few months and you're going to move everyone forward, not just make it a very long multi-year project, this might be the right time to make that switch all at once. If you're going to make it a really long project, it may make more sense to do these projects independently.
I always like this and point it out, it's important that as new hires come in you move them to the modern experience and don't keep making your problem worse. Once you have everything up and running in Azure Active Directory, ensure all your new devices are leveraging this, particularly if you're using autopilot and other features. Ensure that everyone possible is moving into that as they join the organization. It's going to be a long road. And for an organization that has a multiyear project, it might be right to bring a third party tool in to help bridge this gap, otherwise, you may find yourself administrating machines in two environments and that can be really confusing.
So some organizations find third party tools add a lot of value here. That said, if it's a relatively short period of time, maybe three months, six months, it probably makes sense to go directly into the cloud based applications and not worry about that third party tool in the middle. With that, I'm going to send it back to Becky for her top tips on how to get these projects done.
Thank you, Mike. So my top tips, I said it before, I'm going to say it again, remember your end users, think about their impacts, let them know what's coming, send them notifications, get them trained so that they are ready for this. That's always my biggest tip for any sort of migration, especially moving out to Azure. Send out those communications and then, like I said before, ensure that your support staff knows what's coming. You do not want to surprise them on this, otherwise, it can be messy.
You want this migration to be smooth. Start looking at some of the paths to get there. There are manual paths, you can start looking at some of the autopilot options that we talked about earlier, you can start taking a look at some of the bulk device deployment options that Microsoft has available for deploying these devices out into Azure AD joined and getting out of your local AD. Once you've looked at those options, start testing them. Test a little bit, refine your process, there will always be changes, test some more.
Once you feel pretty good about your tests, find a pilot group. With any migration piloting is extremely important because those are going to be your real users and they're going to let you know which applications are not working and which ones you still need to address.
Once you've finished your pilot, do those final refinements and then you can finally move forward with migrating everyone else. And like we said before, take a look at what migration tools might be out there that can help you get there because anything that you can help automate and not have to do manually, if you don't have to back up and copy files, that is fantastic. And so there are companies out there that are actively working on this because, again, this is the future is migrating your devices to Azure.
So we appreciate you taking the time and hope that you learned something here that will help you plan out your migration of moving from AD out to Azure. Coming up next is some live Q&A. We look forward to your questions.