The passcode remains after shared device is checked back in

[chengtmskcc]

On a shared device, a passcode is required upon checking out a device based on a passcode profile through the Hub app.

However, I noticed the passcode remains enabled after the device is checked back in also through the Hub app. I can confirm the same passcode profile does not apply when the device is checked in.

Any suggestion?

[GrantMcClanahan]

+1 on this one. Love to hear what others are doing in regards to this. You would think there would be a clear passcode command issued or an option for us to set.

[chengtmskcc]

I would think it should just clear itself since the same passcode profile doesn't apply upon logging out from the Hub app.

[jbarzFunk32]

Hi Thomas,
No sure if this is the case, but if you go to Groups & Settings > All Settings > Devices & Users > General > Shared Device, do you have 'Require Shared Device Passcode' and 'Enable Single App Mode' on?

I had issues with these being on in the past because I also had payload profiles determining the single app mode and pass code, so they fought against each other. I was told best practice was to use payload profiles, but not sure if that's really true or not.

[Stansfield]

The passcode profile removal would not make a passcode go away just not be required and the clear passcode on check in is android only for some reason.

[LukeDC]

It's a general rule of thumb that a policy/profile can restrict and further tighten security but should never be able to loosen it. You could apply a lighter, less restrictive policy or remove it altogether, but it would never force you to lighten or remove a passcode etc. This has always been an iOS tenet of security from my experience.

[chengtmskcc]

Thanks, all. Support confirmed this is a bug with version 19.03 and has been resolved with version 19.04. Surprisingly (or not), this bug and fix are not mentioned anywhere with both version 19.03 or 19.04.

[chengtmskcc]

Oh and we are advocating a patch to be applied to our SaaS environment as we can't just upgrade easily to fix one bug as we go through vigorous testing before any upgrade in production.

[jbarzFunk32]

Just heard some of our fleets are experiencing this too. Good to hear it's fixed with 1904, but I just updated to 1903 and wasn't planning on doing an upgrade anytime soon. Would be nice to get a patch. Let me know if you hear back about that.

[jbarzFunk32]

Looks like Patch 19.03.0.13 was made available today.

[chengtmskcc]

Jeff, is there any release note for patch 19.03.0.13? If so, does it mention about this passcode issue? I don't have access to such info as I'm now a SaaS customer. What I can tell you is that VMware installed a DLL patch in our environment and fixed it. It was installed early in the morning so can't say for sure if there was any downtime.

[LukeDC]

Tom, you can get release notes for any version (which includes release notes for each patch) here:  https://docs.vmware.com/en/VMware-Workspace-ONE-UEM/

[chengtmskcc]

Thanks, Luke. Rookie mistake there. 🙂

[LukeDC]

No worries, it's something they started to do after all these years 🙂

[chengtmskcc]

That's true!