Shared iPadOS TemporarySessionTimeout Experience

I have implemented some Shared iPads at my company. These are to be single-purpose devices that are shared among the staff at particular offices and are used to run a single App that is important to them.

It should be noted that the app requires some permissions before it can be used properly and so these, while not amazingly hard to agree to, are just kind of annoying for the end user to constantly be challenged with while trying to get on with their job (Camera access kind of things). The app has its own security so locking down the device and then making use of the Guest (Temporary) session meets our needs.

I also have a need to keep the devices’ iPadOS up-to-date* and this requires that they are signed off of the device to work correctly.

Counting on the end user to reliably sign out at the end of the week so the OS updates can occur over the weekend is not likely to be successful, so Apple thoughtfully provided an attribute that I could use called TemporarySessionTimeout. The only problem is… it didn’t work.

But finally, after over 5 months working with Microsoft and Apple it seems the issue is now settled.

Here are my conclusions:

  1. iPadOS 15.5 is required for the TemporarySessionTimeout attribute to work correctly.
  2. Apple assures me that any value from 1 to 129,600 seconds (36 hours) will work. I am using this as my upper limit.
  3. I have tested, multiple times now, 86,400 seconds (24 hours) and this works fine. This is the value I agreed upon with my business partner that should permit the session to persist throughout the week but then timeout on the weekend and leave enough time for iPadOS updates* to occur.
  4. The timer is reset with pretty much ANY interaction with the device. In my earlier testing I was checking at 16 hours, 20 hours, etc. with the intent of catching if the device was timing out sooner than expected. But when I did this, it would also NOT timeout after 24 hours. Only if I left it completely alone and then checked after 24 hours was the guest session signed-out. All I did was press the power button to check if the “Sign out” button was still present.

* I keep mentioning iPadOS updates like they work. They don’t. I have cases open with both Microsoft and Apple on this issue. As of iPadOS 15.5, using an Intune iOS/iPadOS Update policy does not cause the update to occur successfully, at least on my devices. There is some kind of permissions error buried in the logs and the direction I’m getting from Apple is that we will need to wait for a future release of iPadOS to see if it’s fixed. Yay team!

iOS 15 Managed Pasteboard and Intune MAM/MDM Protections

I recalled reading about the Managed Pasteboard feature in the iOS 15 release notes but the full import of it hadn’t hit me until today.

If you are using an Intune App Protection policy to “sandbox” your managed apps and you are also using Intune’s MDM, you will find that Pasting from the clipboard behaves a bit differently after upgrading your devices to iOS and iPadOS 15.

Previously, in Microsoft’s Office 365 ecosystem you used App Protection policies to specify which apps are “Managed”. You would specify what kind of actions could be done with data with respect to those apps. Only certain apps were “enlightened” or compiled with the SDK that recognized Intune’s MAM requirements so you had a very limited ecosystem of apps you could use in this fashion.

Things like saving files from a managed app to local storage, or copy-and-pasting data from inside of one of those apps to another app would be controlled this way.

In my institution, we allow people to copy-and-paste into these managed apps, but not vice-versa.

I’m not an expert on other MDM solutions having only worked with MobileIron and BlackBerry in the past, but I understand Intune’s approach is a bit different in that, for the Office 365 primary apps (Outlook, Word, OneDrive, etc.), the apps themselves are primarily responsible for enforcing the MAM requirements imposed by the Administrators.

More so, each app discriminates between Corporate data and personal data on an account-by-account basis. i.e. You can be using Outlook to access your Corporate email AND your personal Gmail account. This means you can have emails side by side in your aggregated inbox and you can copy-and-paste from the personal Gmail messages to any other app you please on your device, but try to paste from any of your Corporate emails and all you get is “Your organization’s data cannot be pasted here.” pasted in any non-managed receiving apps.

This was fine and worked well enough. We were satisfied that our data was protected.

However, it seems Apple understood the MDM piece of the equation, which would allow data from managed apps to be pasted to non-managed apps to be a gap which they rectified in iOS / iPadOS 15 with the Managed Pasteboard. The issue here is that it cannot have the nuance of Microsoft’s App Protection policy solution. Apple doesn’t know about the contents of the Managed apps, it’s unaware that some data contained in the app is personal and some is Corporate. Basically, if the MDM pushed down the app, then it’s managed and you’re not moving ANY data out of this to any but another managed app.

I’m using cut-and-paste as my typical use-case, but this will affect any data movement from managed to unmanaged apps – saving files, opening files in other apps, etc.

I’m hopeful that Apple will introduce the ability to disable the Managed Pasteboard feature should we want to. I recognize that their approach is probably a bit more “standard” but I feel that usability suffers.

Android gets around this issue by having an entire area sectioned off (Work Profile) where EVERYTHING inside the work profile is work only – nothing leaves there, and everything outside is personal. The distinction is so clear that you will actually have two separate copies of any app that would be used for work purposes. So you can use Outlook for your personal Gmail account outside of the work profile completely unfettered and you use another copy of Outlook for your Corporate mail within the work profile under the limitations your company feels are appropriate to prevent the data from being exfiltrated in some undetectable fashion.

I recall that Apple seemed to be working on a similar scheme but I have not heard anything about it for a few years now.

Microsoft Intune “Defer software updates” and iOS Patch releases

Right now I’m trying to allow my fleet of devices to access iOS 15.0.2 but I do not want them to have access to iOS 15.1 yet (being released later today). Typically I like to allow a couple of weeks before upgrading devices to new minor releases to allow other folks to uncover any issues that might be introduced before my fleet tries to use them.

Intune has implemented, as part of their Device Configuration policies for iOS, the ability to take advantage of Apple iOS’ ability to defer a software update by up to 90 days.

This is potentially a great feature and has worked so far on Major and Minor releases. However, this is the first time I’ve attempted to use it to limit folks to a specific patch release (Major.Minor.Patch i.e. 15.0.2).

In my testing I find that just having the “Defer Software Updates” option set to Yes regardless of how many days delay specified causes iOS’ Software Update to completely ignore the patches.

If I watch closely, I sometimes see a ghost “iOS 15.0” zero byte offering that will disappear on a subsequent refresh. I find it appears immediately after I Check Status of my device in Intune Company portal. Then goes away after I refresh the Software Update page until the next time I refresh.

I cannot say for sure if the flaw is with Microsoft’s Intune implementation or in iOS’ Implementation, I can only say that I cannot take advantage of this feature for Patch versions while trying to safeguard the integrity of my iOS fleet.

One other thing – a defect in the Device Configuration policy. It seems if you EVER set and save the Defer Software Update setting, even if you subsequently set it to Not Configured, this will permanently enable the number of days parameter. This parameter defaults back to 30 when you set the Defer parameter to Not Configured and still be sent to the devices…

Intune – Send Custom Notifications – but not to too many people

I’ve been wrestling back and forth with Microsoft on this for the past few weeks. I’m able to use Intune’s “Send Custom Notifications” feature to send messages to a very small number of people.

But, recently, I wanted to notify just under a couple of hundred of my users that the version of iOS they are running will no longer be supported by my system. I thought this notification feature would be a neat way to reach out directly to them so they knew that I meant *them* specifically and not *them* generically as tends to happen with email communication of this sort.

So I sent my notification to a tiny number of people (me especially) to ensure that the message being sent looks good for the target folks on the mobile platform. Works fine.

Sent the identical message to a single group of 171 people (again, including me) and… nothing.
The next day I sent it again after confirming that, not only did none of my half dozen test mobile devices receive it, but NOBODY received it. And… again… nothing. This time I verified that the resulting Intune notification (bell at the top in Intune) confirmed “Success”.
Sent another notification to just myself and a coworker and…. works just fine.

Well… crap. So I sent off an email instead to the users to give them their warning and opened a ticket with Microsoft regarding this.

Basically Microsoft is telling me that I must have missed the dozen or so notifications across my devices, as did all of my users. They took pains to explain to me how end users sometimes don’t notice notifications when they come up and that must be the situation… on both days.

Long and short it turns out that there is no real auditing or logging of this feature so Microsoft cannot tell the notification disposition beyond the original “Success” which apparently only means Intune has acknowledged that I’ve submitted the request.

I wanted to put this warning out to you. Not only should you not be using this feature for time-sensitive information, but also there appears to be a threshold number of people – certainly in my case – to whom it can be sent before it will give up the ghost and just not do anything.

Be absolutely certain to include yourself and some sympathetic coworkers on ANY Intune Custom notification that you send out if you want to have any assurance that it actually made it to your audience.

In my opinion Microsoft needs to update this feature so it:

  1. Logs all sent messages,
  2. Provides a disposition for the message as to whether or not a device has acknowledged receiving it.

I don’t imagine there is a lot more I could ask for. The end user is welcome to ignore the message after delivery. At that point my goal has been achieved.

I would be interested to know if there are any other folks who have run up against this issue.