Understanding hybrid Azure AD join and co-management

[Herman Arnedo Mahr]

As we talk with our customers that are using Microsoft Endpoint Manager to deploy, manage, and secure their client devices, we often get questions regarding co-managing devices and hybrid Azure Active Directory (AD) joined devices. Many customers confuse these two topics – the first is a management option, while the second is an identity option. In this blog, I hope to clear up any confusion and give guidance and scenarios on how to use both to manage and protect your devices.

Let’s start with the basics: management

Microsoft Endpoint Manager is the combination of Configuration Manager – the on-premises management tool that you’ve been using for decades - and Microsoft Intune – the cloud-based management solution used for modern device security and management. Endpoint Manager’s goal is unifying both of your management solutions and bringing the power of the cloud to your entire endpoint estate.

To accomplish this goal, we first launched tenant attach to provide an easy and low-risk path to cloud attach your Configuration Manager infrastructure to your Intune tenant. This is an on-premises to cloud attachment like you’ve seen before when connecting your Exchange Server on-premises infrastructure to Exchange online and sync’d those mailboxes, and when you connected Active Directory to Azure Active Directory and sync’d those user accounts and other objects. Tenant attach is the same idea: attach the Configuration Manager infrastructure to Intune and sync the Windows 10 Configuration Manager managed devices to the cloud-based Intune tenant. Creating this connection brings the value of remote actions and analytics, immediately.

During or after the initial attachment, you can start moving certain workloads from Configuration Manager to Intune, either one at a time or en masse. You choose the path that’s right for you. Co-management is the act of moving workloads from Configuration Manager to Intune and telling the Windows 10 client who the management authority is for that particular workload. For example, you might move Compliance Policies and Device Configuration workloads to Intune while leaving all other workloads set to Configuration Manager. This tells the Windows 10 client to listen to Configuration Manager for app deployment and security policies, for example, while listening to Intune for compliance policies and device configuration policies.

Figure 1: Graphic representation of Microsoft Endpoint Manager, Configuration Manager, and Microsoft Intune.

As you continue to modernize, continue moving workloads to Intune until you are managing everything in the cloud, or keep all of the workloads directed to Configuration Manager and stay on the tenant attach step. Or you can even start in Intune as cloud-native. With tenant attach and co-management, you choose the path and the end state.

Let’s start with the basics: identity

Active Directory Domain Services (AD DS) has been around since 2000, with the release of Windows 2000 Server. Traditionally, we join our Windows devices to Active Directory to take advantage of Group Policies, security settings, and even to give permissions to resources that are stored in a different Active Directory environment - either in the same Active Directory forest or a different forest. Devices can be joined to only one AD DS environment.

Like we said earlier, though, it’s possible to connect the on-premises AD DS environment to Azure Active Directory (Azure AD). When this connection is made, the devices that are joined to AD DS may then be registered in Azure AD. This connection and registration is known as hybrid Azure AD joined.

Figure 2: Diagram depicting a Hybrid Azure AD joined corporate laptop.

Devices that are co-managed, or devices that are enrolled in in Intune, may be joined directly to Azure AD, or they may be hybrid Azure AD joined but they must have a cloud identity.

Our guidance

Not all devices in your organization need to be managed the same. Each device serves a different purpose, as such has different management and identity requirements. For example, new devices may not need to be joined to AD DS, and instead can be initially provisioned as Azure AD joined, being managed either by Intune natively or by co-management. Starting this device as hybrid Azure AD joined will introduce challenges later as you adopt more modern solutions, such as migrating user data, user profiles, and determining which group policies are assigned to the device. So before joining any new devices to AD DS and deciding on that hybrid approach, ask yourself, “Does this device need to be hybrid Azure AD joined? What are the benefits of joining this device to my AD DS environment?”

Hybrid Azure AD joining a device is great for uplifting your existing AD DS joined devices, but Azure AD is the Microsoft recommended path for most new or repurposed devices, especially when using modern deployment tools like Windows Autopilot.

Scenarios

Many of our customers have been using AD DS for 20 years, joining client (and server) operating systems from Windows 2000, Windows XP, Windows 7, Windows 8/8.1, Windows 10, and everything in between (I’m looking at you Windows Vista!). Because of how long AD DS has been around, you may have Group Policy Objects (GPOs) that you need to leverage, or Win32 authentication, or other scenarios that will make moving to a pure Azure AD environment challenging. Let’s look at some of these scenarios and our guidance with each one.

Scenario #1: User profile migration

Scenario

When a device is joined to Azure AD, it creates a new profile for the logged-on user, and does not reference any existing profiles. In a new device scenario, this won’t be an issue as there are no profiles yet on the endpoint. User profiles typically include the following local directories:

• Local files in the Desktop, Documents, Pictures folders
• Start menu and Taskbar customizations
• Favorites
• Browser settings
• Cached credentials
• Outlook cache and settings
• Third-party app settings

But if the devices were previously AD DS joined or joined to its own workgroup, you may need a profile migration, as seen in the table below:

Original device state	Once joined to Azure AD
New or re-imaged/repurposed device	No profile migration needed
Local workgroup	User profiles need to be migrated
AD DS joined	User profiles need to be migrated

Table 1. User profile migration needs when joining a device to Azure AD.

Guidance

Our guidance in the case where a user profile migration is needed is to:

• Manually copy/paste to migrate profiles, or use a third-party profile migration tool
• Re-map existing files and settings to the new profile
• Preserve all cache settings
• Use Enterprise State Roaming
• Force synchronization of browser data
• Moving your on-premises file shares to SharePoint Online
• Use OneDrive for Business Known Folder Move

Scenario #2: Group Policy Objects

Scenario

Though we are constantly adding configuration service providers (CSPs) settings that Windows supports into Intune and making configuration of settings easier for you, some of the GPOs that are configured on-premises may not have equivalent CSPs in Intune. These GPOs typically revolve around very specific user-based configurations, such as:

• Start menu and Taskbar customizations
• Desktop wallpaper and screensaver settings
• Some registry settings
• Other Group Policy Preferences

Guidance

• Run Group Policy Analytics to analyze these GPOs and determine your level of modern management support.
• Do a thorough assessment of supported settings in MDM – do you still need them? Are there alternative technologies with higher security? Are the registry changes covered by a KB article? Is the policy still required? Do a hard rationalization with your team!
• If you are setting Registry to configure apps, re-evaluate if the configuration is supported via ADMX (Administrative Templates).
• Migrate those GPO settings that have equivalent CSPs to an Intune policy. For devices born in the cloud, use Security baselines to configure Windows 10 devices in Intune as these have recommended MDM configurations.
• Re-evaluate the necessity of those GPO settings that do not have an equivalent CSP and report to us.

Scenario #3: Win32 apps and legacy authentication

Scenario

Some Win32 apps have a need for some legacy form of authentication. Any apps that require AD DS machine authentication will not work.

The apps that work are the apps that support NT LAN Manager (NTLM), Modern Auth, and Kerberos TGT.

Guidance

• Once you have a better idea of who is using legacy authentication in your directory and which applications depend on it, the next step is upgrading your users to use modern authentication.
• Migrate these apps to apps that support modern types of authentication.
• Re-evaluate the necessity of AD DS machine authentication.
• Get application compatibility assistance at no additional cost.

Scenario #4: Printing

Scenario

Your users are using printers that are directly connected to their devices or that have a direct path in the Printer settings. And some may be using AD Printer Discovery to find the printer closest to them. Because there are many printer-type scenarios, consider the following in the table below:

Printer scenario	Result
User has a printer directly connected	This will continue to work
User has a direct path to a printer	This will continue to work
User uses AD Printer Discovery	This will not work

Table 2. Printer scenarios when migrating a device to Azure AD.

Guidance

• Notify users of a direct printer path, when possible
• Deploy a PowerShell script from Intune to map the printers
• Best: Use Universal Print, our driverless cloud-based, print service

Conclusion

Hybrid Azure AD joining a device is a device identity scenario, which has your device joined to the on-premises AD DS domain, and registered in Azure AD. This is a good scenario when starting your identity and security migration from on-premises to the cloud.

Co-management is a device management scenario, which has your device being managed by both Configuration Manager and Microsoft Intune, with each being the management authority of specific workloads.

Consider the points in this table as our recommendations to realize the benefits of cloud management.

Identity	Management	Provisioning	Cloud modernization
AD DS only	Configuration Manager + Tenant Attach	Operating System Deployment	Low
Hybrid Azure AD joined	Tenant Attach + Co-management	Operating System Deployment	Medium
Azure AD only	Co-management Or Microsoft Intune	Windows Autopilot	High

Table 3. Recommended Windows client management strategy based on device Identity

As you start to move from your legacy AD DS and Configuration Manager environments, we’re here to help! Reach out to our FastTrack team and follow us on Twitter @IntuneSuppTeam! And bookmark the Microsoft Endpoint Manager community for more blogs and information on managing all of your devices, including iOS, iPad OS, macOS, Android, and Windows!

[MaxM]

Great overview article! Thank you!

Is the chart at the bottom missing a row in-between HAADJ and AAD-only? Similar to the HAADJ row, but with Autopilot provisioning?

[MaxM]

Following my previous comment: I see the table is for "Recommended" options. In that case I take back my question about HAADJ + Autopilot being missing. I understand that it's a supported/valid option, but not actually recommended.

Thanks again for the article.

[Herman Arnedo Mahr]

Hi @MaxM 

Excited to be doing this! Glad you like it!

In reference to your question, we strongly discourage any customer from building their modern provisioning plan on Hybrid Azure AD Join. At best you’re deferring a problem you’ll still have to solve and won’t necessarily get any easier with time. At worst you’ll end up investing lots of time and effort to try and solve a complex problem and gain very little benefit over the current solution you have today that work well and reliably.

• The HAADJ flow during Autopilot is one we’re seeing customers see issues and lots of unnecessary complexity.
• HAADJ is really intended to uplift a customer’s existing domain join devices.
• AAD is the Microsoft recommended path for most new or repurposed devices, especially when using modern deployment tools like Windows Autopilot 

[MaxM]

@Herman Arnedo Mahr I'm pleasantly surprised to see you/MSFT state that so decisively. Thank you.

[PMcD_]

Great article - having just enabled co-management and hybrid join, the scenarios such as GPOs and how to shift away from legacy apps is very useful.

[Vadivelu_B]

Nice overview. But HAADJ+Autopilot is recommended by MS, but it not listed here. Practically HAADJ+Autopilot having more time-consuming implementation, operational changes were there. Do you agree?

Any comments from others welcome. 

[BitwinTheSheets]

Is it possible to only to move workloads only for a subset of one's devices? For example move the windows update workload only for a number of surface devices that are HAAD joined. Then have everything else being managed the traditional way.

[Herman Arnedo Mahr]

@BitwinTheSheets Starting in version 1906, you can configure different pilot collections for each of the co-management workloads. Being able to use different pilot collections allows you to take a more granular approach when shifting workloads. 

Please check the following links and if you have any questions, don't hesitate to ask! 

• Co-management workloads - Configuration Manager | Microsoft Docs
• Enable co-management - Configuration Manager | Microsoft Docs

[jassv]

This is a great article and well explained :)

What about those scenarios that fall into the category of 'co-existence' where existing devices are managed by 3rd Party MDM providers?

[Harjit Dhaliwal]

Good article and needed. Thanks.

[Jason_Sandys]

@Vadivelu_B This statement is not correct: "But HAADJ+Autopilot is recommended by MS". We fully support doing this, but as @Herman Arnedo Mahr calls out, this path is not ideal, and our recommendation is for organizations to embrace AADJ for new devices as soon as possible. We understand that it's not an on/off proposition for most organizations which is why we will continue to support HAADJ + Autopilot, however, don't conflate support with recommendation. Our clear and stated direction is and always has been to move orgs to the cloud. This direction has been clearly reinforced over the last 18 months with dependencies to on-prem only resources (like Active Directory) becoming a major obstacle and productivity inhibitor for many organizations.

[DonalC]

Great article but I'd like to propose an additional scenario that is holding us back from embracing AADJ for new devices, Certificate Services. We use an MS Enterprise PKI built on top of our AD for all the things it's great at. If my devices aren't ADDS joined I lose a lot of the automated features that platform provides for cert management.

We're actively moving our GPOs to modern policies, we've got software deployment pivoting from ECM to Intune and have a solution for printing, but the PKI requirement has us stumped. Is there a solution we haven't thought of or perhaps are MS looking at a PKI add-on for AAD?

[Jason_Sandys]

Hi @DonalC, secure certificate deployment in a cloud-first world is a challenge particularly since this needs to account for all platforms that we currently manage (or those that we may manage in the future). Because of this, we must use a standards-based toolset to deliver the certs to the endpoints. Because of this, Intune uses a certificate connector that facilitates communication with your existing Enterprise PKI and delivers certs in one of two industry standard methods: SCEP or PKCS. You can read about the Intune Certificate Connector and these two certificate delivery options at Certificate connectors for Microsoft Intune - Azure | Microsoft Docs. If you search the web for Intune Certificate Connector you'll find lots of hits with additional official documentation as well as supplemental documentation from the community.

[DonalC]

Hi @Jason_Sandys and many thanks for taking the time to respond. We're actually running the Intune Connector and have it plugged into our MS CA using SCEP. My challenge is this is a lot of on-premise (or Azure IaaS), domain joined infrastructure that needs to be deployed and managed for a working PKI solution.

What I'd love to see is a PaaS based PKI solution built directly into MEM that could be seamlessly integrated into the device lifecycle and connected to systems for functionality such as NAC, AOVPN etc.

If we're moving to the cloud, I really want to move to the cloud, and not have to build masses of on-premise infrastructure to support that move.

[Jason_Sandys]

Thank you for the feedback. Personally, yes, I'd love to see a PaaS and Azure-based PKI as well. At this time though, we don't have this. There have been hallway-type conversations and investigations (so I'm not alone in this desire), but there are no formal plans or commitments right now. Please use the feedback capabilities within Azure and the MEM admin console to submit this to ensure it receives increased visibility.

[Joe White]

Excellent article, explained the difference between co management and Azure ad join very well

[khanax0l]

Hi Herman,

Thank you for the excellent blog, it clears alot of confusions I had as a beginner to Intune. 

I have some trouble understanding the flow and design. my company has all windows 10 devices joined to on prem AD and managed by sccm. however, there are few windows 10 mobile devices which are domain joined with ccm client installed but rarely connect to network. hence we would like to enroll these mobile devices to intune to manage updates, compliance and access company LOB applications. What is the best/ straightforward approach? 

To enroll a domain joined windows pc with sccm client is co management mandatory?

sorry for the long question, really need your help to move forward.

Thanks

AMK

[Jason_Sandys]

Hi @khanax0l. Best and straightforward is always in the eye of the beholder and depends on many details specific to your environment, users, management strategy, and usage that are not known.

Based on what you've noted though, your best first step here (IMO) is to implement a cloud management gateway (CMG) in ConfigMgr to enable you to manage these off-prem Windows systems (I suggest not calling them Windows Mobile as that means something different). This will enable you to fully utilize all of the management capabilities that you currently have with ConfigMgr for these off-prem Windows endpoints. 

You can then set about enrolling the Windows endpoints in Intune. The tricky part here for existing endpoints is that they must be hybrid Azure Active Directory joined (technically they could also be Azure AD registered but that's generally only recommended for BYOD type scenarios). To hybrid Azure Active Directory join an existing WIndows endpoint, the endpoint must have connectivity to the on-prem domain. Alternatively, you could also Azure Active Directory join the Windows endpoints, however, there is no direct, automated path to do this for existing WIndows instances meaning that you would have to reset them -- this may or may not be desirable.

Co-management enables ConfigMgr and Intune to simultaneously manage a Windows endpoint. It is not required to enroll an endpoint in Intune, but if will be using ConfigMgr to perform the Intune enrollment, then the result is a co-managed endpoint. Given that you already have ConfigMgr in place, there's no reason to recommend not using co-management.

Thus, moving forward, you have one main initial decision to make: do you want to reset the existing endpoints or not? If not, then you will have to HAADJ them which requires connectivity. If you are OK with resetting them, then you should implement Autopilot which will automatically join the endpoints to AAD and Intune enroll them and then add the ConfigMgr agent to them so that they are co-managed. Note that for new devices, you should be pursing this strategy anyway regardless of whether they are on-prem or not.

[Joe White]

Excellent article, very helpful

[v-cgiraldomo]

Good article but I am a little confused when you stated Microsoft endpoint manager is the combination of SCCM and Intune, I currently have my lab setup without any sign of SCCM and I can still use Microsoft Endpoint Manager so not sure on this point

[Jason_Sandys]

Microsoft Endpoint Manager (MEM) is an umbrella term or suite of products and services really. Intune and ConfigMgr are included in MEM as well as other services including Autopilot, Endpoint Analytics, Group Policy Analytics, and a few others. Thus, saying you "use MEM" is a bit ambiguous and could include one or all of these services, however, using "MEM" does not mean you must have all of these products and services in use or even implemented.

If you don't have ConfigMgr implemented, than some of this article is not applicable to you as co-management is about having both Intune *and* ConfigMgr implement and used to simultaneously manage your Windows endpoints. However, keep in mind that HAADJ and co-management are two different and distinct concepts as Herman calls out -- HAADJ is about device identity and co-management is about device management.

[MikkelLundKnudsen]

Great Blog - even here year(s) later!

[windex]

Does HAADJ not work with Autopilot? Your chart above indicates provisioning happens exclusively with OSD and not Autopilot. Is that accurate?

[Jason_Sandys]

Hi @windex,

What "works" is often what's different from what "works best" or what we recommend. That is the case here. Autopilot definitely works best with AADJ and it is what we strongly recommend customers adopt.

[windex]

It feels like HAADJ is a necessity for us on account of the things you listed above, a) unmigrated Group Policies, b) legacy apps that use Windows-integrated or LDAP auth, and c) other time-consuming things like 802.1x, wifi, and PKI. Does Autopilot actually 'work' with HAADJ or do we need to abandon Autopilot until we resolve a/b/c?

[Jason_Sandys]

Yes, it actually works and is fully supported. But, once again, working is not the same as being optimal or providing the best, most complete experience.

As for the unmigrated group policies, this is certainly a journey and not an overnight activity, but the sooner you get started, the sooner you'll be finished.

For legacy apps, use of integrated auth is seamlessly supported without issue or additional configuration on AADJ devices. The overwhelmingly vast majority apps fall into this category and the vast majority of orgs never have any issues with app authentication on AADJ devices.

Don't use the excuse that something is time consuming as a excuse not to do it. The world, and as a result what it takes to support businesses from an IT perspective, has drastically changed over the past five years and not changing with it because it takes time and effort is not a good reason at all. It will take you more time in the long run to try to wedge HAADJ and Autopilot into your existing solutions and process then moving to match our engineering effort and the reality of the modern world and workforce. Additionally, HAADJ will simply never meet the expectations of the modern workforce since that's not what it was ever designed for.

[Aaron Parker]

This is a fantastic article, even two years later.  I'm glad to see things like PKI pointed out in the comments, as when I've evaluated moves to embracing only AAD join, that is often one of the bigger roadblocks.  Reading the comments and helpful replies has been great, as it seems like there may be some other options in this area.  That is a subject I'd love to see it's own detailed post on quite frankly.  Something that goes into detail on deploying client certificates to support things like 802.1x with AAD joined PCs would be fantastic.  

But there is another area that I've always gotten a bit hung up on that I'm curious if you can comment on.  One of the benefits to having a device joined to a traditional AD DS domain is the ability to do secure dynamic DNS updates.  I'd imagine a number or organizations who would want to use AAD are also quite likely running a Windows Server DNS infrastructure.  What's the solution for users with an AAD joined device around DNS?  

[neurotoxic]

In an enterprise there are so many applications attached to AD DS - However enthusiastic we get, I am not clear how AADJ will replace all of them. Untill once subscribe to full Microsoft vision, I am not sure traditional organization can do away with AD completely. 

PKI being the primary and I guess that can be solved with Intune certificate connector. Voice (PBX) System with softphone which identifies based on AD identity. Video conf equipment in the office are again tied to AD. I am sure if we rip and replace and get every conceivable product directly tracking to Azure AD, may be possible. 

Most importantly support: With personal experience the folks who write such fantastic and thorough articles are not in the field. What we get in the field are Fastrack team, which are so green - it is a joke. Their entire purpose is to push bing searched links. The folks interacting with us could not properly explain what's written in this article, short of assisting with deployment. Microsoft tech support esp. with Azure AD is.. let's not even waste energy. 

So overall, though AADJ makes sense, we consider atleast 3~4 year journey before it could culminate in fully getting away from AD DS. 

[Jason_Sandys]

Hi @neurotoxic 

> In an enterprise there are so many applications attached to AD DS

This is not a technically accurate statement. The apps themselves almost always rely on the core Windows capabilities using built-in authentication libraries and functionality. The applications themselves are wholly ignorant of the exact details of how they contact the directory to request authentication or how to actually perform that auth, they simply pass the info to a built-in function and operate on the returned info. Nothing about AADJ changes this or upsets this functionality. The only difference with AADJ is that Windows needs a little bit of additional info to direct the authentication request to the on-prem domain as this is intrinsically known to an on-prem domain joined device. This little bit of additional info is provided by AAD Connect (see How SSO to on-premises resources works on Azure AD joined devices - Microsoft Entra | Microsoft Lear... for details).

If you have apps that make direct LDAP (or other direct to AD) queries, there's nothing specifically stopping them from being pointed to your on-prem AD. As eldued to above, AADJ does not in any way preclude the use of your on-prem AD or any other directory for that matter. The app simply needs to be able to be pointed to that directory. How each app handles that is an app specific implementation detail that we can't solve specifically and is something you need to engage with the app's vendor on. As noted above, Windows itself is doing this by using a hint provided to it using AAD Connect.

> So overall, though AADJ makes sense, we consider atleast 3~4 year journey before it could culminate in fully getting away from AD DS. 

You'll get no argument or pushback from us on this. We fully acknowledge that this is not an overnight excercise and that this journey may take "many" years for some customers. But every journey starts with a single step (pick your favorite cliche that says the same thing).

As for support and knowledge, note that the author of this post works directly with some of the largest and most strategic Microsoft customers on a daily basis. The team we are on is dedicated to this (we are part of the product group) so we are in general more than just passingly knowledgable. I'm sorry your experience with other resources has not been up to your expectations. I suggest providing that feedback to those teams and using other resources at your disposal including discussing this with your Microsoft account team.

Finally, don't conflate moving to AADJ with getting rid of your on-prem AD. They are not the same thing and while that is a longer term aspiration for us, that is a follow-on step to moving to AADJ and not part of moving to AADJ.

[Jason_Sandys]

Hi @Aaron Parker ,

I'm not sure if this gives the level of detail that you are looking for, but the official docs has documentation on deploying certs: Learn about the types of certificate that are supported by Microsoft Intune | Microsoft Learn. There are also a number of community guides floating around.

For secure dynamic DNS, can you discuss the bigger scenario here of why you want or need dynamic DNS in the first place particularly in a hybrid world? I'm not saying you don't necessarily, I just want to understand the bigger picture from your perspective and for the ask.

[ed1425]

Thanks for the valuable article,

We are currently using Configuration Manager and looking into using Intune co-management. But when we installed Office, users have selected the option to "allow organization to manage my device" so we accidently ended up with thousands of devices registered in Intune (those are domain joined devices currently managed by Configuration Manager). Now when we want to enable co-management, we are looking for the proper way to cleanup Intune from those accidently registered devices, so we can enable Azure AD sync to bring on-premise domain devices into Intune properly and then enable co-management. What is the proper way to do? can we just delete those devices from Intune? we can't ask thousands of users to disconnect work/school account and I couldn't find a way to do that administratively on many computers? Thanks 

[Jason_Sandys]

As long as the user that registered the device is the same as the one that logs into the device to complete the HAADJ process, the objects will automatically get cleaned up by Windows. See https://learn.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-plan#handling-d...

[ed1425]

Thank you for pointing me in the right direction, much appreciated.

[Mathg76]

This article can help you to understand to process flow :
https://campbell.scot/hybrid-azure-ad-join-intune-enrollment-prerequisites-checklist-and-process-flo...

[StefanYu]

Hybrid Azure AD still our options

[SlowCyclist80]

Hi guys, this article and the comments are great. I'm a sysadmin and have been teaching myself Intune and Autopilot. It's perfect for any new laptops we get, now that we are on 365. There's no purpose for them to join our on prem domain. I've even got apps and policies setup, it's neat to see it all flow to a laptop after signing in with my 365 creds.

Desktops are a different story. Our current setup is that access to our network has to be authenticated with our domain. My net admin mentioned Palo may have something to interact with AAD but we are looking into it. Is there a solution you know of where we can convert existing ADDS only PCs and put all new PCs on AAD and still have 802.1x security to our LAN? Also we have an on-prem print server with a ton of printers, how does this factor in?