I think it’s safe to say we’ve learned a bit over the past year about how we in the IT world were or were not prepared to deal with a remote workforce. And yeah, sure: it’s been talked about to death that working from home presents a “unique set of challenges,” from scalability of VPN to ensuring users remain present and productive, but one area I don’t think gets a lot of attention is our actual capability to deploy systems to remote users.
On the VPN topic, specifically, I mused openly about it last March, but the response I got was generally lack of concern. “Nah, we have a VPN: it’ll be ok” was what I heard frequently. But…was it? Did that VPN solution scale to the entire workforce? Did you have enough licenses, and did your ingress speeds enable users to work with on-premises infrastructure satisfactorily? Did password resets consume your help desk, or Group Policy deployment fail entirely? What about software distribution?
The point is VPN was suddenly asked to go from occasional-use to a life-support system, and the functionality was never designed for that.
Our regular readers know that Synergy Technical was “born in the cloud.” We have never had an on-premises infrastructure and have thus never needed to extend one to support these remote connectivity scenarios. We had the benefit of having already solved these software and configuration challenges by default, with Office 365 and Microsoft Intune.
With our workloads are in the cloud, all anybody really needs to be productive is a web browser. Edge and Chrome readily fit the bill, but while Edge comes with devices, Chrome does not. We can’t allow users to be local admins and let them install any ol’ web browser they want, but fortunately Intune allows us to set some guard rails.
With Intune, we can publish apps to be assigned or available to users or devices, and even force removal of apps we don’t want on our users’ devices. We can, for instance, make Chrome available to all of our users through the Company Portal app. If they want Chrome, they don’t need to call the help desk: they can self-service the request. The same can be true for just about any other application (.exe, .msi, Microsoft Store, web links, you name it), and we can sort and categorize them as we decide within the Company Portal app.
We can also control the behavior of the Windows environment with Configuration Profiles in much the same way we’ve done in the past with Group Policy objects, only without any of the limitations that come with “startup” policies requiring pre-authentication line-of-sight to a domain controller. Should our users try to change their configurations, we can support those configurations with compliance policies that assess conditions of the devices, while also checking against risk data from EDR solutions, to determine if users should be allowed to continue gaining access to our systems and data.
We can further control the Windows Update and Feature Update cycles for the environment, control Bitlocker and Windows Defender, and even define Windows Information Protection policies to ensure data doesn’t get copied between apps.
So yeah: apps & configuration? We have that pretty well dialed.
But then there’s the challenge of personnel changes. Your first thought may have gone to getting the user’s machine back, but if we’re talking new hires, they may not have a machine to reclaim. What then?
In the early days of the pandemic, we saw organizations rolling back security postures and allowing users to just bring whatever device they had, unmanaged, to the company data. That…is not the way we want to do things. It certainly isn’t in keeping with the Zero Trust philosophy.
But we have a couple of options, and each offers its own unique set of capabilities for remote work.
The first is Autopilot, which takes all the cool stuff we’re already doing in Intune and allows us to target controls at new physical devices. Consider…
A new user starts with Company A pre-pandemic. That user comes to the office on Day 1 and finds a shiny new laptop. They log in and everything “just works”. But to make that happen, IT first might have used that new user’s account to log on to the device at a wired network shop, pre-loaded all the apps AS the user, then delivered the device.
Now we’re in the pandemic, and it’s time to hire another new user. That process is followed again, only this time the company has to have the new device shipped to the office, the admin has to come in to image the device, then ships the device out to the new user, with packaged instructions on how to get connected to the VPN for the first time and a help desk contact to walk them through the process.
The company has paid for shipping twice, had to bring people into the office, introduced finger-touches to the new user’s equipment, and significantly delayed (often by many days) the time to productivity. One company I talked to last year put the cost of simply deploying—not purchasing—a new device at over $1000 in time and shipping losses. If you’re buying $1000 machines, that means it’s potentially costing $2000 to get machines in front of users.
With Autopilot, the device manufacturer pre-loads a digital code for each new device to your company’s Microsoft Store for Business. That code is baked into the device and cannot be changed. So the first person who ever gets the machine out of the box is the end user, and when they start it for the first time, that code is read by the Microsoft Store for Business before the system even presents a logon prompt. And if that code matches one that belongs to your company, they can ONLY use your company’s credentials to log in to the computer. The user then is constrained to an OOBE (out of box experience) environment that informs them of the process of deploying apps and configuration changes before delivering them to a fully-functional Company A environment.
No secondary shipping, no admin logon, no time lost. It’s not often you can save $1000 per deployment. And all that work we did before to deploy the apps and the configuration for Synergy’s internal use? That all gets re-used: no extra build-out necessary! So we’re not even adding work, except for the initial enrollment into Autopilot. And since we’re already licensed for Intune, there wasn’t even any additional cost.
So that’s option 1, and the only question it really leaves is the one we ignored off the bat: how do we get it back? Well that’s your call, but we can also wipe and reset Autopilot devices, so maybe the laptop becomes a parting gift? IDK.
But what about the other way? This one, Windows Virtual Desktop, also uses our Intune configuration, but assumes that maybe we don’t want to give the user a physical device (or maybe we do—we can stack solutions if we want).
WVD allows us to leverage Azure VM’s running Windows 10 to provide virtual desktop environments to users. Perfect for contractors and folks who already have computers. Again we lose nothing for all the work we did configuring and deploying our apps, except now we can scale our deployment for seasonal workers, resize the hosts for performance issues (heck of a lot better than shipping RAM to end users), and just take the VM away when users depart.
What’s nice about both options is that they scale. They scale with our app deployments, our configuration profiles, our compliance controls, and our business growth. Neither relies on on-prem infrastructure or VPN to succeed, and both will serve just as well when users are back in the office…if they ever come back.
What’s also really amazing about both is that they both happen to exist right when we need them. What an amazing time to be in this industry!
Comments