My Role
I was the Project Sponsor for this role. I asked my IT Engineering lead to put together a plan, assemble a team, and work through the methodology to deploy our Windows machine onto Intune.
Despite being a Sponsor, I was heavily involved in user testing and learned more deeply about how to roll out and manage Intune in organizations.
Context
Our company had 3 primary computing environments for Endpoints: ChromeOS, Windows, and Mac. After the pandemic, we decided we’re going to be a fully remote company. However, our Windows environment was the only one we couldn’t deploy unless an agent physically touched the machine.
The Intune deployment was meant to give us the ability to deploy the machine without an agent ‘imaging’ the machine and gave us better device management control.
Difficult problems we encountered
Problem | Solution |
How do we get all our machines to adhere to a standard? | We had a lot of different machine types - we had to create a common standard of configuration profiles to support multiple hardware providers.
We created a custom powershell tool (courtesy of our IT Engineering team) that helped standardize the machine’s policies, enroll it into Intune, and clean out historical AV profiles in the registry. This tool saved our necks from a very painful migration process. |
How do we migrate all our machines to be managed from Intune? | There’s no way around it - this was labor intensive. We tracked down all of our current Windows machines and had to manually work with the user to enroll the machines via the powershell tool.
This was long, but it was only 5 months of consistent work. Sometimes there’s no way around it, you need to do the hard work. |
How can multi-regional Autopilot deployment be supported? | Microsoft and its vendor procedures are weird and make no sense, sometimes. One issue that we ran into is that vendors from different regions from where our tenant is based cannot enroll machines via AP.
We had to build a custom app that would enroll the machine in AP. In other scenarios, we configured our OOBE process to be dead simple and fool proof so users and enroll their own machines into Intune. |
Lessons Learned
- Don’t do slow roll migrations (e.g. enrolling only net-new hardware and keep the historical solution for older machines). Rip the bandaid off and you’ll be much happier for it. It’s more work but it meant that we could complete the migration in 5 months, and not 3 years (average EOL timeline for our machines).
- The right technical team can ease the pain of many migrations. During this project, we had some really smart folks that tried to simplify this as much as possible for our agents to have a worry-free migration.
- Recruit agents that know (and love) to think on their feet. At scale, you’ll always run into one-off issues, you need folks that are mentally agile enough to solve issues in real time.
- We pray to the documentation overlord - robust documentation from the technical team saved our butts many times and created a reference to self-resolve issues during the migration.