[johnnyuk]

I'm seeing a problem with UDS IT Policies on iOS devices that I first encountered in BES10.0 but which also happens in BES10.1.1 where if I set an the Auto-Lock timeout of 10 minutes in the policy when it applies the device does something different. It sets a 5 minute time out period for Auto-Lock and removes the entries for 10 minutes, 15 minutes and Never.

Also, in BES10.0 only, if I set a "Lock grace period" of any amount of time in the policy it doesn't change the value for the setting on the device (the Require Passcode setting in Passcode Lock). Whatever the Lock grace period was previously set to remains and the values that are available to choose from for the setting are not restricted in any way.

All other IT Policy settings apply OK on both my BES10.0 and BES10.1.1 servers (including Secure Work Space on 10.1.1) and I have no problems with Profiles not appearing or not applying on iOS devices. Everything works fine apart from the Passcode time out related IT Policies.

Anybody else have this happen them with iOS, BES10.0 and BES10.1.1?

Posted via CB10

[pkcable]

Let me see if I can get you the answer

[Sith_Apprentice]

What happens if you set these values via policy, THEN activate a device with the policy. Do the correct values apply? This is instead of changing the policy after the devices are activated. I am curious if the policy itself is not working properly for you.


Is this within the application itself (the BES10 app) or via ActiveSync? I am guessing the app, but I want to make sure.

[johnnyuk]

What happens if you set these values via policy, THEN activate a device with the policy. Do the correct values apply? This is instead of changing the policy after the devices are activated. I am curious if the policy itself is not working properly for you.

Thanks for your comment.

Setting the values in a policy and then activating a device with a user who receives that policy is what I usually do.

But the same thing happens if I activate the device with a user who just receives the Default policy, which I haven't edited, and then later apply the policy with the password rules set. It makes no difference.

Is this within the application itself (the BES10 app) or via ActiveSync? I am guessing the app, but I want to make sure.

This is when activating the device using the BES10 Client, no ActiveSync policies are on the mailbox on Exchange.

Posted via CB10

[TL Mobile]

Hi

I can confirm I have the same issue. I have the latest version of Bes 10.1.2.7 installed I have a default UDS policy set to enable auto-lock to 15 mins. I have then activated an IOS device and on the device it is set to 5mins. 10, 15mins options are removed.

johnnyuk or anyone else did you manage dot resolve this issue?

[johnnyuk]

No solution to this one so far here. Can't believe BlackBerry haven't noticed this yet!

Posted via CB10

[unsigned]

Not to dig up something from the past… but I am seeing the exact same thing on UDS 10.2

I just got off the phone after a grueling 2 hour support session, where the support tech and an 'analyst' vacillated between telling me that I had to have Secure Work space licensing because Auto lock didn't work under MDM control only, or that they were escalating me to tier 3 support.

It ended with them scheduling a tier 3 call for tomorrow morning.

Its a heck of a silly issue, all the other password controls work properly, its JUST Auto-lock and Grace Period that seem to have no effect on the iOS setting.

If its designed to only work with the Secure Work Space apps, then they really need to make that clear, as I can't find that *anywhere*

[johnnyuk]

It'll be interesting to hear what they have to say but as it still behaves this way in 10.2 I think it's safe to say that this is "by design", it just isn't a very intuitive or flexible design.

What I ended up doing, and still have to do, to set the 10 minute inactivity time out that I want is to set the Auto Lock to 5 minutes and the Lock Grace Period to 5 minutes so at least the password prompt doesn't appear for 10 minutes even if it locks after 5.

Posted via CB10 on Z30 STA100-2 /10.2.1.2141 on O2 UK - Activated on BES10.2.1

[unsigned]

I know its been a long time, but until today I didn't have news.

We recently updated to BES 10.2.2 (easy update) and I've finally retested Android 4.2.2 with client 10.3.0.150345 and iOS 7.1 with client 10.3.5.114.

The password policies do seem to work as expected now.

As per usual through this whole thing, Blackberry support was mostly non-communicative. They had scheduled a tier 3 call, but never called me. In fact I didn't hear anything until I got an email almost two weeks after starting the ticket:

"My apologies, I though I had replied to you regarding your ticket. Sorry for the delay!

I had a look into the behavior you have reported and even tested it out in my test environment. I have been able to reproduce the pretty much what you have reported.

I had a look into this and did find a previously reported case of this issue. I did see a mention of some relief being included into the 10.2 MR1 release but I am going to request confirmation of this for you.

I'll reach out as soon as I have something new to provide you Ryan."


And that is the last I heard. I never received confirmation, and have just now updated the case with the same info I've put here.

At least someone in engineering is fixing things....

[johnnyuk]

I know its been a long time, but until today I didn't have news.

We recently updated to BES 10.2.2 (easy update) and I've finally retested Android 4.2.2 with client 10.3.0.150345 and iOS 7.1 with client 10.3.5.114.

The password policies do seem to work as expected now.

I hadn't noticed any change to be honest and I've activated a few iOS devices lately, will test tomorrow to confirm.

Thanks for persevering with BlackBerry support though, you've more patience than me.

Posted via CB10 on Z30 STA100-2 /10.2.1.3175 on O2 UK - Activated on BES10.2.2