Autonomous Single App Mode (ASAM) and TestNAV App

promalley
New Contributor III

Is anyone using ASAM profiles and can provide any insight in to how the JSS can push them out to iPads?

69 REPLIES 69

Nick_Gooch
Contributor III

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.

stoneacheck
New Contributor III

@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?

Nick_Gooch
Contributor III

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.

stoneacheck
New Contributor III

@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.

stoneacheck
New Contributor III

Nick_Gooch
Contributor III

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.

stoneacheck
New Contributor III

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.

Nick_Gooch
Contributor III

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.

brownbe
New Contributor III

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.

cbrewer
Valued Contributor II

@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.

stoneacheck
New Contributor III

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.

cbrewer
Valued Contributor II

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

bfrench
Contributor III

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 ...

stoneacheck
New Contributor III

@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...

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.

bfrench
Contributor III

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 :(

Nick_Gooch
Contributor III

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.

stoneacheck
New Contributor III

@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

cbrewer
Valued Contributor II

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.

Nick_Gooch
Contributor III

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

cbrewer
Valued Contributor II

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

Skippiarmstrong
New Contributor

@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?

brownbe
New Contributor III

@Skippiarmstrong

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

Skippiarmstrong
New Contributor

@brownbe

Thank you.

Skippiarmstrong
New Contributor

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

brownbe
New Contributor III

@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.

promalley
New Contributor III

Thanks for everyone's feedback! Does anyone know what "bug fixes" 1.3.2 has over 1.3.1 TestNAV? Gotta love Pearson updating their app a week or so before we all need to test!

promalley
New Contributor III

Spoke with people at PARCC and they said that there is only minor changes from 1.3.1 to 1.3.2. Testing can work properly on version 1.3.1.

tmagdziasz
New Contributor III

funny I did a successful infrastructure test last week with ver 1.3.1 updated to 1.3.2 this week and tested it this morning and it does not work properly, I am now getting "Error 3044: TestNav can not lock the device. Please contact your proctor" nothing changed other than the update from Pearson

tmagdziasz
New Contributor III

Just to update you guys... I was on with Pearson support for over 2 hrs today... Turns out with Version 1.3.2 you need to have guided access enabled. The hope is they will correct this in their next release

Nick_Gooch
Contributor III

Pearson is a joke. ASAM has been the recommended way to test since last spring and it has yet to work on their end.

Litchenberg
New Contributor

Did you remember to change the app version under apps to reflect that this is 1.3.2 and not 1.3.1?

tmagdziasz
New Contributor III

yeah actually as part of troubleshooting I've recreated the entire profile

CGundersen
Contributor III

Also seeing "Error 3044: TestNav can not lock the device. Please contact your proctor" when trying to use ASAM in our PreProd testing (Casper 9.65, iOS 8.1.3, TestNav 1.3.2). In lieu of a TestNav fix (e.g. 1.3.3), it looks like a Config Profile with Single App Mode payload pushed out to groups at testing time (and then removed) might be a less than optimal workaround?

bfrench
Contributor III

I have successfully tested a few this morning. All are at 8.1.3, some had updated from 1.3.1 and a some installed 1.3.2 fresh. All starting without the error 3044. The only one where I saw the issue was one device that was not in my "test" group and therefore did not receive the profile for ASAM. Once I added it to the profile it launched the TestNav app successfully.

tmagdziasz
New Contributor III

The inconsistent results are ridiculous... What version of JSS are you running?

bfrench
Contributor III

We did upgrade to 9.6.5 last night.

tmagdziasz
New Contributor III

yeah we are on 9.6.5 as well and tested with freshly wiped iPads and still received the error 3044....

CGundersen
Contributor III

Not sure if coincidental, but I did remove the TestNav application completely (vs just updating version number) and added again to ASAM Config Profile (didn't recreate profile) and it seems to be working. We'll see if it still works in the AM ...

Nick_Gooch
Contributor III

Have any of you guys started testing yet? Are you running into any ASAM issues with the live test?