Today, I’ll start to tell you the story of how our company began, and continues, using Microsoft Endpoint Manager #MEM (formerly known as System Center Configuration Manager #SCCM). When our Governor’s stay-at-home order was declared more than two months ago, our company effectively shut down all buildings and sent everyone home to work remotely until further notice. Thankfully, the essential staff were already versed in VPN and knew how to gain access to company resources from home and nearly all, if not all, have Internet access at home. At least, for now, we’re not laying anyone off but I can say that, like most organizations, we weren’t fully prepared for this sudden light switch change to telework for 100% of our staff.
That said, we did alot of things right. We were already using Microsoft Endpoint Manager, MEM, and with the assistance of our dedicated support engineer, were able to stand up the built-in cloud infrastructure component of MEM (the Cloud Management Gateway, CMG) in less than a week and targeted the updated policy to inform our clients of the new cloud-enabled services. Unfortunately, many of our managed devices are in the hands of students. And those students, by the time our CMG was enabled and the policies updated, were already sent home to effectively ride out the remainder of the academic year from the (uncomfortable) comfort of their homes. The student population, unfortunately, did not have VPN account access and were unable to connect into our MEM infrastructure to receive the new policies to enable the cloud-aware services and allowing us to continue management of the devices while off-prem. This became our challenge and we haven’t yet tackled it. The good news is that those students who aren’t yet enrolled in our 1:1 program were distributed laptops by their school’s staff AFTER the CMG was established so for those 20,000+ students who received a laptop to continue their distance learning, we are able to manage those devices. That, unfortunately, doesn’t solve the problem for the some 80,000 computers that are already at home with no access to our on-prem servers to get the updated cloud-enabled policy changes. We’re still working on that.
Within a few weeks, we recognized that we faced three challenges: (1) (the biggest) how to get student devices, not currently connecting to our on-prem infrastructure, to get the updated policies enabling them to talk to the CMGs so that we can continue to manage them through these unprecedented circumstances, (2) (for those devices in the hands of students and which received the updated CMG policies) how to distribute user-targeted applications to students (because our student population, their AD accounts, were not yet sync’d to Azure AD), and (3) how to reduce the content consumed by devices connected to the Internet via company-provided MiFis (hotspots).
The solution to Challenge 2, of course, is simple, right? Just sync the student accounts to Azure AD. In organizations that take their testing and support processes very seriously, we don’t make any changes without asking a lot of questions and thinking through all the possible impacts that we might not be expecting or seeing. We try very hard never to implement policy or change configuration without a thoughtful, yes sometimes slow, process. So folks asked the question — what’s the impact to students if we sync them to Azure? Well really, it’s virtually nil. The student won’t see anything differently at all. Essentially, a user who treats his/her AD account as just a tool for logging on to the computer won’t have any idea that that account is now AzureAD enabled. There’s a “but” in the story, though. One of the other changes happening to our environment is that Microsoft is deprecating the licensing model for Office 365 that we’ve been using for several years now (called Device Based Activation, DBA). They announced late last year, they were discontinuing this licensing (which was never available to any customers other than EDU customers) effective May 31. So this meant we had to find a new way to license our devices. As an organization, we do our best never to implement solution that mean we have to treat one population “this way” while another “that way.” That sets up a bit of heartburn among our support partners in IT (operations, support, break/fix, etc.). So we were looking for a solution we could implement to all systems rather than a hybrid approach. Traditional user-based activation (the way Microsoft envisioned O365 activation from the beginning) was a problem for educational institutions like ours because of the nature of how students tend to logon to shared devices and the whole 5-device limit on activation was a show-stopper. So we agreed that we only had two options: (1) to use a new service offered to EDU customers called “device based subscription” which is a no cost add-on to our tenant licensing but which we would need to go back to our provider and request the addendum to our contract and which we were skeptical could ever be executed well or in a timely manner because nothing with this provider is ever easy, or (2) use the supported “Shared computer licensing” model whereby the user must authorize the copy of Office against Azure AD (the Office portal) but that the logon account for the user must then be sync’d to Azure AD (and our student accounts were not yet). We chose the latter and knew we needed to, very soon, sync student accounts into AzureAD. Our faculty/staff are already there by virtue of the fact that they’re provisioned Exchange accounts. But our students use Google Apps for Education (and have for some time) and were never part of that initial rollout to Exchange Online when we went from on-prem Exchange to Exchange Online with Office 365. So as I said… simple, right? Ugh. Nothing in our environment is ever simple. But this is a manageable situation. The sync of student accounts is underway (we’re sync’ing our student accounts over the weekend with Azure AD) so beginning Monday, students will not only be able to seamlessly use Office but those who have APPV or traditional “applications” targeted to them will now be able to receive those applications via our CMGs which are also DP-enabled. Yes, we’ll see a spike in downloaded content (the content you pay for over Azure) in the coming days…but at least we’ll be confident that our traditional devices are now fully able to receive all content via the cloud.
Challenge 3 above is interesting. Initially, you think… no big deal, just disable the access to the CMG’s DP capability… but then what about the patches? They don’t come from the DP, they come from Microsoft… that’s supposed to be a good thing, right? Takes up less storage, sends clients dynamically to MU to download patches… problem is they’re still “consuming content” and incurring costs for that because after all, they’re hotspots. They pay for all content they consume no matter where it’s coming from. So what we agreed to do was allow them to communicate with the CMG (for policy, status, inventory, heartbeat, etc.) but that we would disable the access to the CloudDP functionality. Additionally, for our patches, we would be monitoring their content downloads and monitor their costs/consumption that once a month when they would get policy for newly authorized patches. If that proved too expensive, we could exclude them from the patch policy deployments using an Exclude collection in MEM. The challenge is “how to we get them into a collection?” With our organization, it’s always “pick apart, or reverse engineer the existing process” to figure out how to solve the problem. Turns out there’s a process we use (through our ticketing/asset management system) to enroll the students in the MiFi program. So if we can track what devices are assigned to those students at enrollment, we can add them automatically to an AD group and then build a collection based on membership in the AD group. We would then have to detect “adds and deletes” to that group to ensure that the policies we want to enable are making it to the clients as intended. That’s the trick, isn’t it… making sure your clients get the proper policies at the proper moment in time. Welcome to our world of Desktop Management.
We’re still working on Challenge 1. We don’t know whether we’re going to be able to collect the devices assigned to the students (some 80,000 devices). And that is troubling. If anyone has ideas as to how to seamlessly (remember these are students and you can’t rely on them to do anything the right way — like sending them an email telling them how to enroll their own devices in InTune)… I’m open to suggestions. Hit me up on Twitter @DesktopMgmt.