Autonomous Single App Mode (ASAM) and TestNAV App

Under Restrictions > Applications tab you would put the bundle id of Testnav in. I have yet to have it work with Testnav in live testing, but have in practice sessions. I guess it's fixed this time but who know's.

@Nick_Gooch, are you just using the bundle ID - com.pearsoned.TestNav ?

Also do you know if the app needs to be distributed from Self-Service so it's "managed" rather than from the new managed VPP to respect the restriction?

Yes that is the bundle ID we are using per Pearson. I don't believe the app needs to be managed but the iPad's do need to be supervised.

@Nick_Gooch thanks! That's what I setup.

Are your iPads supervised OTA through DEP or through Configurator?

I'm still getting "Error 3044: TestNav can not lock the device. Please contact your proctor" - tried with managed through self-service or distributed through managed VPP, same result either way.

(This was done on the Pearson training site, using sample students/class/session).

I checked the profiles on the sample iPad I was testing with, it's being distributed properly.

Here's a screenshot of the profile - https://www.dropbox.com/s/0r09ox1ashtkqku/Screenshot%202015-02-03%2013.21.42.png?dl=0

Our iPad's are supervised OTA w/ DEP. I last tested in November and was going to start playing with it again since Pearson says it's working now. I'll let you know what I find out.

HMMMMM

Well well well.

Looks to be either a bug or an oversight on my end?

We have our standard restrictions payload we send down (removes game center, FaceTime, messages, etc) and then I made a second one just for TestNav. Turns out when I remove the original restrictions (I actually just excluded tester iPad I'm working on) TestNav works like a champ, so Casper's "it's fine if you make multiple profiles and the one that's most restrictive prevails" config profile logic was applied in reverse to the ASAM setting.

TL;DR if you have a pre-existing restrictions payload, add the com.pearsoned.TestNav bundle ID to the bottom of the Applications tab to get PARCC TestNav to work.

Report it to your account manager, it sounds like a bug. I just sent a profile to an iPad with nothing changed just defaults and see that it adds "Autonomous Single App Mode permissions added" under the MDM profile/restrictions on the iPad even though I never set anything there.

I will open a case as well as soon as I can test with TestNav.

We are having an issue with our testing app AirSecureTest not being secure. ASAM is set up and scoped properly. We spoke with our Apple rep and they said that if the App Store is disabled the app will not stay secure for some reason... sure enough we re-enabled the app store and it worked. Hope this info can help.

@Nick_Gooch and @stoneacheck

Did you guys actually get TestNav to work with ASAM? I'm still getting "Error 3044: You must be in Single App mode in order to take this test." I am using com.pearsoned.TestNav as the bundle ID. According to Pearson it should work: https://support.assessment.pearson.com/display/TN/Mobile+Devices

I do have ASAM working successfully with the Air Secure Test app so I know the Jamf part of it is working correctly.

Yes,

I tested with Grade 3 ELA and Grade 4 Math so far, but both worked as expected on an iPad 2 running 8.1.3. Haven't tried on lower OS or Airs yet, but hoping that works...

Like I mentioned above we noticed it only worked when utilizing a single restrictions payload.

I'm also testing with just a single restrictions payload on an iPad 2 with 8.1.3.

I have been informed that there in indeed a bug - defect D-008272. Hoping there is an update soon. Not to mention one that will incorporate the latest from apple to be able to disable autocorrect/autofill/etc...

Meanwhile still trying to determine a way to push out Java settings for unsafe mode et.al. on the OS side ...

@bfrench

Buckle up...

I setup a couple things that seem to be working:

We used create-user.pkg (https://github.com/MagerValp/CreateUserPkg) to make a policy to create PARCC user on student MacBooks - https://www.dropbox.com/s/y1et1iqz4l3s0z6/Screenshot%202015-02-09%2011.26.24.png?dl=0 we also run @rtrouton's script to disable the iCloud goofiness when creating a new account - https://derflounder.wordpress.com/2013/10/27/disabling-the-icloud-sign-in-pop-up-message-on-lion-and-later/

I then created a smart group with criteria looking for student laptops with that user - https://www.dropbox.com/s/599i7117g4eqram/Screenshot%202015-02-09%2011.14.58.png?dl=0

Then several policies trigger off that -

1.) The first replaces the dock and safari plist and safari preference folder. Doing this got trickier in Mavericks (possibly earlier, we went from 10.6 to 10.9 over the summer so I'm not sure when they goofed with writing to plists) so you gotta do the killall cfprefsd command to let the plist actually get written to. I do it before and after cause it's overkill and I didn't remember at what stage the prefs need to be killed, lol. (write up about technique here - http://manytricks.com/blog/?p=3049)

https://www.dropbox.com/s/rn5c6m05bkqgudg/Screenshot%202015-02-09%2011.18.24.png?dl=0 Those are the stages of the policy

Here's what the package looks like in Composer, built on a sample student laptop.(https://www.dropbox.com/s/bebtp0pwr591245/Screen%20Shot%202015-02-09%20at%2011.16.20%20AM.png?dl=0

I shaped the dock the way I wanted and then also visited the system check and testnav sites in safari, setting them to unsafe and always allow for those java sites.

2.) we have a secondary policy that just writes to the deployment.properties of Java (https://www.dropbox.com/s/psucb5e1tevis3w/Screen%20Shot%202015-02-09%20at%2011.16.29%20AM.png?dl=0 and specifically replaces two lines with the values for HIDE_RUN and expiration.check=FALSE (referenced on PARCC's site here - https://support.assessment.pearson.com/pages/viewpage.action?pageId=16908319 and see http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/mixed_code.html and http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/jcp/properties.html)

3.) we have http://www.lindegroup.com/autopkgr up and running (thanks to @elliotjordan's session at JNUC) and that's auto updating our java to the newest release on student MacBooks with the parcc user. This was the most complicated part to setup but it works pretty darn well so that's good. - https://www.dropbox.com/s/z7vcuaq0xfusnnj/Screenshot%202015-02-09%2011.24.48.png?dl=0
https://www.dropbox.com/s/gekmb47m2wfq2qn/Screenshot%202015-02-09%2011.25.29.png?dl=0

And that hopefully about does it. The only thing I don't know is if the Java is gonna play nice with Unsafe mode based on the domain name. Our live test is obviously at il.testnav.com and the training one I used with sample students to allow it to run was using the training domain (epat-parcc.testnav.com and parcctrng.testnav.com), so the only thing I'm unclear on is will the browser respect the main domain and go like "oh yeah, new app on same domain, we're cool here" or do I have to make a fake student for the live site too, accept that to run unsafe and then re-package everything, flush the logs and tell everyone to login/logout to trigger it? That sounds like a call to pearson, but last time I did that I spoke with someone that sounded like a very newly hired teenager who knew surprisingly little information about their own product.

I have found in testing that I had to allow il.testnav.com to run in unsafe mode specifically. You can log into the live site with the test of username and password just like in the test site to see what happens. Thanks for all of your information. We may just have a login party with our laptops to get them set up :(

Unless you move on to level 2 of Pearson support they are screen readers and nothing more. One time the rep answered the phone and mentioned a different company before realizing it was for Pearson support.

With ASAM I tried adding the bundle ID to all the other profiles as well and it looks like it works, as long as the app store is not blocked.

@bfrench

Check out Randy's post, I packaged up trusted.certs like he recommended and it seems to be working across multiple machines....

http://www.rsaeks.com/parcc/deploy-testnav-java-app-settings-to-other-os-x-clients

Even though this post got hijacked a bit I figured I'd update it with my findings. ASAM appears to be broken for just the ACT Aspire test in version 1.3.1 of TestNav. Other tests such as PARCC and Mississippi work fine with ASAM.

@cbrewer As long as the app store is not blocked, correct?

@Nick_Gooch Haven't tried it with the App Store disabled.

@stoneacheck
On 2/3/2015 you said "TL;DR if you have a pre-existing restrictions payload, add the com.pearsoned.TestNav bundle ID to the bottom of the Applications tab to get PARCC TestNav to work."

I have about 10 restrictions on my students iPads, are you saying i need to add the com.pearsoned.TestNav to every one of them?

@Skippiarmstrong

That is correct. We had a meeting with our sales rep on Wednesday and that's exactly what he said.

@brownbe

Thank you.

The ASAM does not seem to work with the App Store blocked. anyone have a workaround for this?

@Skippiarmstrong

The only workaround we've found is to clone the profile currently on the devices and make the change to enable the app store in that profile. On the day of testing we exclude the static group of devices for each class scheduled to test from the original configuration profile and then scope them to use our Testing profile. Our state DOE says they're unsure if it's a JAMF thing or an Apple thing but they are working on a solution.