Mobile Device Management

two black smartphones

Small business deployments are still too cumbersome

Today is going to be a busy day. We’ve got a small party to attend to host, so I’ve got to do a bunch of household cleanup, roast a pork shoulder, bake a cake, and then host seven or ten children plus parents in the backyard. If that wasn’t enough, I’m behind on both my WordPress project and the Substack post for Monday, which is about bitcoin.

Work picked up a bit last week. I’m helping roll out Git best practices for a software development firm, which is the kind of challenge I’m looking for, and dealing with a failed mobile device management solution (MDM) that I rolled out several years ago and which has been summarily ignored since then. It’s not what I’d rather be doing.

Microsoft’s MDM, Intune, has evolved over the past few years, and like most Microsoft services, has gone through several iterations and is a maze of admin dashboards, documentation, and licensing products. It still seems vastly superior to the product that we’ve been using from IBM, called MaaS360. Still, figuring out the requirements for a small business client is a huge pain. We’ve been dealing mainly with Apple devices, which means managing all the end user accounts. Getting the devices enrolled requires managing a signed certificate from Apple (another account), and then deploying the device requires not only a configuration profile on the device, but additional apps on the device for it to work.

For our initial deployment MaaS360, requirements were pretty simple, the customer mainly wanted to lock down the browser on the phones for content filtering. It was an arduous process, even for a first-time deployment. Setting up the device profiles and testing took me several hours, then another associate of mine had to go through each device, setting up iTunes profiles for each user and downloading our management application. Then, after we deployed it, we discovered that GPS tracking wasn’t working. Permission needed to be granted individually on each device.

This initial deployment went unattended for almost two years. We got a request to pilot a new service app on one of the phones, and when I went back to check the tenant, all but two of the phones hadn’t checked in to the portal in over six months, more than half in over a year.

By some stroke of luck one of the two belonged to the individual who was selected to pilot the new service app, so I was able to proceed with the planning for that. I spent the rest of the morning trying to acquaint myself with Microsoft’s MDM offerings. Since most of our clients are on O365, it makes sense to take advantage of whatever is available through the platform. I was able to get a device policy setup under our partner account, but wasn’t able to get my personal iPhone to report into the console, even after several attempts connecting it to my O365 Exchange account.

Then, several hours later, after getting a Teams notification, I was prompted to install the device management profile, as well as two other apps, one for a “company portal”, and the Microsoft Authenticator app. Then, I was prompted for a managed Apple ID, and that’s where I stopped for the day.

I decided that if I was going to be forced to redeploy management to a dozen or so client devices, that I had best start communicating with the client, so I spoke to them. There had been numerous personnel changes in the past few months, and a lot of other processes were being re-evaluated, which meant that it was a good time to put some processes in place. First off, a freeze on any device purchases or equipment transfers without keeping me in the loop. (Outsource IT is usually an afterthought when it comes to hiring and firing.) Second, we were going to audit all existing devices, and make sure that we have a record of which devices we think we have, and who they belong to. That would give us some time to evaluate whether we can move management over to O365, or redeploy with the current solution.

I pulled some spreadsheets down from the management portal and dumped them into the client’s SharePoint site, then scheduled a Tuesday meeting with the pilot user for the new app.

Next week, I’ll have to do some investigation into Apple Business Manager, to see if it allows us to manage user IDs as well as the devices. We can barely depend on this firm’s employees to manage the one AD accounts, let alone another set of Apple IDs. It’s management hell. I’ll also have to draft some written policies for device and user onboarding and so forth. Eventually, I’d like to enroll the client firm in the carrier’s device provisioning program, to get them enrolled with minimal supervision. That will likely be a slog for this small firm.

On the brighter side of things, this may force me to develop some concrete MDM deployment best practices that will make me a superstar. I’m not aware of any Powershell tools that can be used to automate any of this process. Even turning on MDM within O365 requires clicking a box in the admin portal, and the Apple Certificate provisioning requires setting up accounts and downloading a file from one portal into another. Drafting an SOP for the entire process start to finish would be valuable.

That will have to wait till next week, because today, I have a party and very special birthday girl to attend to.

Exchange Online Bulk Add SMTP Addresses

We are a Microsoft partner and have been standing up a lot of clients on Office 365, the management of which requires a lot of PowerShell use to administer properly. My last boss told me that Microsoft’s move away from the GUI toward PS scripting is what is going to ‘separate the men from the boys’, and I’ve taken this to heart, trying to script out everything as much as possible. Server 2012 has really made improvements over 2008 as far as this goes, and Exchange Online and Office 365 (AKA Microsoft Online Services) are strongly there as well. Sure, there are web interfaces for them, but Microsoft seems to have a habit of changing the navigation and language every few weeks and the GUI has been inconsistent between the business and enterprise plans as well, so the Powershell commands seem be the way to go.

For this most recent job, we had a client who wanted to change domain names, so we stood up the new domain on O365 and configured client workstations for the new accounts. Once that was done we verified the old domain with Microsoft in anticipation of routing the old domain to the new mailboxes. Rather than manually add each additional SMTP address for each user account, I used the following script. Make sure you connect to Exchange Online using remote PowerShell first.


$users = get-user * #Filter your OU appropriately, this was a blanket change for a flat hierarchy.
foreach ($user in $users)
{
$mailbox = get-mailbox $user.identity
$newmailbox = $user.id + "@yourNewDomain.com"
set-mailbox -identity $user.identity -EmailAddresses @{Add=$newmailbox}
}

You can then verify that the changes went correctly with the following:

foreach ($user in $users) {
$mailbox = get-mailbox $user.identity
$mailbox.emailaddresses
write-host  $addresses
}