[UPDATE 2015-05-13]: Pearson is getting DDoS’d again.

Pearson experienced intermittent issues with PearsonAccess and TestNav beginning at 7:13 a.m. this morning. These issues continue to occur.Pearson has confirmed that a Distributed Denial-of-Service (DDoS) attack to Pearson?s firewall is causing degraded performance issues.  Pearson is actively monitoring the issue and working to resolve.

[UPDATE 2015-05-05]: Don’t use full screen with TestNav.  See below from Pearson:

…If the browser is set to Full Screen mode prior to students logging in, it will create a conflict with TestNav that may cause students to experience difficulty logging into their tests, being exited from TestNav unexpectedly or cause students to not be able to use built-in tools. This applies to all browsers on all operating systems…

[UPDATE 2015-04-23]: Pearson is back online after a DDoS, hardware failure, and firewall configuration error.  They also posted some tips and tools for resuming tests.

[UPDATE 2015-04-22]:

Minnesota Department of Education Temporarily Suspends Minnesota Comprehensive AssessmentsEducation Commissioner Brenda Cassellius announced today that the state will temporarily suspend administration of the Minnesota Comprehensive Assessments, until all technical problems with the testing system are resolved.Over the past week there have been three days during which students have experienced issues logging into the testing system. The testing window has been open since March 9 without major incident, with nearly 400,000 tests completed. As the number of students testing neared its peak today, Pearson has identified some technical problems with their system and are currently working to resolve them. These technical problems have not adversely impacted the 400,000 tests that have already been completed.“Students already give up precious instructional time for annual accountability tests,” said Cassellius. “We cannot allow these disruptions to further impact student learning.”Pearson is working on identifying the technical issues that are causing the problems. The department has informed Pearson that testing cannot resume until they assure the state that students will encounter an error-free and smooth testing experience.“We hold our students to high standards and we expect no less of Pearson. Students deserve a worry-free testing experience without interruptions,” said Cassellius.

[UPDATE 2015-04-21]: In addition to the problems we face every day on our end, Pearson is having trouble, too.

At approximately 08:55 AM Central Time on 4/21/2015, Pearson detected that the TestNav online delivery system was registering an unknown issue resulting in degraded test delivery. Primary symptoms of this condition included user difficulty in logging on, slow test item download, slow test submissions, and a warning screen to notify their teacher or test proctor.
While such conditions are frustrating, online testing may continue at this time. Iowa City Technology Operations is working diligently to correct the issues.

[Update 2015-04-15]: Java 8u45 and Flash 17.0.0.169.

[UPDATE 2015-03-16]: Java 8u40 has been updated to Java 8u40.

[UPDATE 2015-03-13]: Flash 17.0.0.134 is out.  Hooray.  X-protect hasn’t been updated yet, but I’m certain it will soon, at which point TestNav will break.

[UPDATE]: Pearson recently discovered that an active Dropbox sync process, including those that may be running in the background, will cause a 7037 error when TestNav attempts to launch.

[UPDATE]: Useful resource: TestNav Error Messages.

[UPDATE]: Download the Safari.plist, which can be used to create a Configuration Profile.  This is the .plist I use in my environment.  You may need to run this command before uploading it:

plutil -convert xml1 ~/Downloads/com.apple.Safari.plist

The .plist has the settings to

  • let the TestNav URLs to run in unsfafe mode
  • disable Autofill
  • allow pop-ups

[UPDATE]: More Flash fun.  (16.0.0.305)  And Apple just disabled the older version.

[UPDATE]: Xprotect disables all but the latest version of Flash (16.0.0.296), so if you do not have that version installed, you may end up with Message 7037: Internal Communication Error.

[UPDATE]: Representatives from Pearson, Apple, the Minnesota Department Of Education (MDE), as well as technology staff from school districts attended a meeting today to discuss the issues with TestNav, Java, and the Safari “unsafe mode.”

Here are the highlights I heard while listening via Webinar:

  • A config profile can be created to allow Java to run in unsafe mode but this does not disable the “Do you want to run this Java applet” dialog; it just eliminates the “Trust this site” sheet that Safari displays
  • System Check tool has been updated
  • TestNav documentation won’t be overhauled for spring, but it is planned
  • TestNav 8 (2015-16) is being built from the ground up and has  “mobile-first” design
  • HTML5
  • does not need Flash or Java if using the app
  • will work on Chromebooks

[UPDATE]: Calculator crashing your test?  Pearson won’t fix it, but here is their solution:

There has been an issue reported when using the calulator [sic] during testing. Sometimes the test will hang or crash if the calculator is opened and the next button is selected soon after. Pearson recommends that the calculator be closed before student’s press the next button.

[UPDATE]: Disable Java updates via script

[UPDATE]: More Flash (but there is hope)

[UPDATE]: I think the Java exceptions and Safari exceptions scripts are working again (at least in my environment).

[UPDATE]: Yet another Java update.  Also another Flash vulnerability found.

[UPDATE]: MDE reps will meet with school technology staff at TIES.

[UPDATE]: Pearson released a PDF saying they understand people are having difficulty with TestNav and are holding seminars about how to use the software.  Nothing yet on a fix.

[UPDATE]: The Java exception list script no longer seems to work on the new versions.  The System Check was 4.3.0.38 at the time of this article and now it is 4.3.0.52.  I tried modifying the script a few different ways, but to no avail.  The actual TestNav site also has an updated version.  Maybe the hack no longer works.

If possible, you should get a signed certificate and create a DeploymentRuleset.jar (well-worth the price)!

[UPDATE]: Even though Chrome became supported by Pearson, you will still have issues because Google is eliminating NPAPI plugins, but you can work around them.

[UPDATE]: Update your Flash again.

[UPDATE]: There is an article in the Pioneer Press about the hardships with Pearson’s TestNav

[UPDATE]: I wrote a post on how to set up TestNav for Windows machines

[UPDATE]: Pearson posted a technical bulletin detailing the manual steps of getting their software to run.

The Problem

Minnesota gave Pearson a $33.8 million contract for student testing, but their Website/software, TestNav, is a hardship for the technology staff getting it setup.  It uses both Java (outdated version) and Flash.  Just trying to go to the site or run the TestNav System Check, you are prompted with a bunch of annoying dialogs:

I recently had to set up over 500 computers for this test and I wasn’t about to spend my time going around to each computer, logging in, navigating to the site, clicking through all the dialog boxes, and then running the system check.  And if I just left it as-is, students would not be able to log into the test, or they might click “Never trust this site,” which would just make problems worse.  I also wanted to run the system check prior to testing to make sure the computers would work before the students arrived.  All of this was repetitive and mundane, which humans are not good at–but computers are.

The Solutions

Best Option (Buy A Signed Certificate And Create A DeploymentRuleset.jar)

This has worked very well for our district.

  1. Create a signed DeploymentRuleset.jar with all the Java exceptions for the TestNav site
  2. Create a config profile using this Safari template, which allows the site to run in unsafe mode
  3. Optionally, create a Bookmarks.plist with the TestNav sites (cannot be made into a config profile)

Free Option (Complex Shell Scripts)

I used some shell scripts sent via Apple Remote Desktop (ARD) to do the following (the first two bullets are the most important):

  • add the URLs to the Safari exception list (set to run in unsafe mode)
  • add the URLs to the Java Control Panel exception list
  • log into the GUI from the login window as the student user
  • if the Java and Safari exceptions scripts don’t work, click through the warning dialog boxes that appear saying things like: “Trust this developer,” “Run this applet,” or “Ignore this update.”

This is certainly not easy to do, but was better than spending a few days going around to each computer to do this manually.  Plus, my computer labs were already set up for GUI scripting.  There might be easier methods of doing this, but here is what I did.

Add TestNav To Java and Safari Exception Lists

This is really the crux of the issues with TestNav–getting the warning dialogs to never show up.  I strongly recommend using a signed DeploymentRuleset.jar if possible as it will save you a massive headache, but if your District won’t do that, you can try to use the scripts provided below to dismiss the dialogs.

Safari Exceptions

This script will add the URL TestNav URLs to Safari’s exception list and set them as “Run in unsafe mode.”  You may need to adjust the username or additional URLs per your environment.

I tried to just open the URLs I needed on one machine and manually added them to the list, then looked at the Safari .plist to determine what URLs should be included in the script.

Java Exceptions

This script (modified from Rich Trouton’s script) will add the TestNav URLs to the Java Control Panel exception list.  The domains in the script below are the ones we deployed in our DeploymentRuleset.jar, but there may be others you need to add.

Another Java Problem

TestNav relies on Java to work, but Oracle is always updating it.  So if they happen to release an update during a testing session, the pop-up can disrupt the test while students are taking it.

Pearson even explains this:

Upon receiving this pop-up notification, TestNav immediately closes the testing session. To resume testing, an administrator must accept the update. The test monitor must then resume the test-taker’s session in the testing administration platform before testing can resume.

but they do not offer an automated solution to disable updates.

It is issues like these that makes it difficult to believe Minnesota dished out 33.8 million for this software.  To avoid this, you can run this script (as root) to disable Java from checking for updates automatically.

How-to Automate More Of This Process

To be sure things are working, you may want to log into the System Check Website to make sure it will work for students.  If you want to check this on a lot of computers, automation is the way to go.  If you got the Java and Safari exception lists working, you have already saved yourself a ton of time.  But if you are looking to do more automation and verification, you will need a few things:

Install Utilities To Lab Computers

On the computers that will be running the test, install tccutil.py  and click , using your Desktop Management software.  We use Casper, so I just made two packages using Composer that install the utilities to /usr/sbin  and /usr/bin  Once the software is on the computer, you will be able to use them via ARD. You will need to make sure the utilities are executable by running these commands as root:

chmod 755 /usr/sbin/tccutil.py 
chmod 755 /usr/bin/click

Enable Access To Assistive Devices

This is what allows you to script the GUI login, click buttons, open windows, and perform other GUI tasks.  Without this step, you won’t be able to click the dialog buttons as easily or instruct the computers to open the URL and type in the username.  You will also not be able to send a UNIX command to log a user in from the OS X Login Window.

Snow Leopard through Mountain Lion

If you are running 10.6-10.8 you can enable this on each computer with a single command sent as root through ARD’s Send UNIX Command:

sudo touch /private/var/db/.AccessibilityAPIEnabled

Reboot to apply the change and you are ready to go.

Mavericks and Yosemite

Starting in 10.9, these settings were moved to a per-app basis, so each app that needs access, must to be added manually by dragging-and-dropping the app into the Accessibility tab under Security & Privacy settings within System Preferences.

But don’t worry, you can automate this, too, thanks to tccutil.py. Just run these commands as root from ARD once the utility is installed:

/usr/sbin/tccutil.py --insert com.apple.systemevents 
/usr/sbin/tccutil.py --insert com.apple.RemoteDesktopAgent

Alternatively, you can run these commands (as root) without installing tccutil.py, but they are a little more complex and more prone to error.

sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db "INSERT INTO access VALUES('kTCCServiceAccessibility','com.apple.systemevents',0,1,1,NULL);" 
sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db "INSERT INTO access VALUES('kTCCServiceAccessibility','com.apple.RemoteDesktopAgent',0,1,1,NULL);"

Log In As The Student User

The rest of the settings are user settings, so it will be easiest to just log in as that user on each computer, then the commands can be as from ARD as the current user.  Use the script below, sent via ARD as root, while the computers are at the loginwindow, to log in the user (adjust the username and password per your environment).

osascript -e 'tell application "System Events"
	keystroke "student"
	keystroke tab
	keystroke "student"
	keystroke return
	keystroke return
end tell'

I have found that this works best right after a reboot so that the cursor is focused on the username field.  There is also no screensaver to contend with.

Run System Check

The system check will not detect Flash (even though it is installed) until the URLs are added to the exception list and Java is working properly.

Open the System Check URL

Run this script as the current user via ARD.  It will open Safari and navigate to the System Check URL.

Click the Start Button

This is where the click  program comes in handy.  It will click at an X, Y coordinate.  This means you don’t have to go to each computer and click the start test button.  Fortunately, all of my Macs had the same screen resolution, so it was easy to set a static coordinate to click.

# Click full-screen button twice so all computers have the Safari window in the same position
osascript -e 'tell application "System Events"
set frontmost of process "Safari" to true
tell process "Safari"
click button 4 of window 1
end tell
end tell'

# Sleep for a bit seconds to make sure full screen is fully-activated
sleep 4

# Click Start button of System Check page
# Uncomment coordinates for your model listed below
# Or create your own based on the size of your screen and position of the Safari window

# iMac Intel (27-inch, Early 2013)
# iMac Intel (21.5-inch, Mid 2011)
click -x 530 -y 375

Finding the Coordinates to Click

You can use the screenshot tool to find out where to click on the screen.  Just press Command+Shift+4 and you will get a little crosshair.  Hover over the place where you want to click and take note of those coordinates.  Press Escape when done.   If you are using MouseTools, you can find the coordinates of the mouse by running this command:

MouseTools -location

which will return an X and Y coordinate.  Useful if you can not see the little crosshair that easily.

Open Sample Test Site

If the system check passed, you may want to open a sample test site to verify functionality.  Use the script below to do this.  You can use the other script to enter the test user credentials.

# Open sample test site
killall Safari > /dev/null
osascript -e 'tell application "Safari"
activate
set the URL of the front document to "http://testnav.com/mnqc"
end tell' 
# Click full-screen button so all computers have the Safari window in the same position
osascript -e 'tell application "System Events"
set frontmost of process "Safari" to true
tell process "Safari"
click button 4 of window 1
end tell
end tell'

# Sleep for a bit seconds to make sure full screen is fully-activated
sleep 3

# Enter sample credentials
# Again, adjust these coordinates per your device using Cmd+Shift+4
click -x 1200 -y 320

sleep 1

osascript -e 'tell application "System Events"
keystroke "username"
keystroke tab
keystroke "testcode"
keystroke return
end tell' 

Open the Real Test Site (And Bookmark It)

Next, you will probably want to open the real testing URL and bookmark it so students can get back to it easy without your assistance.

# Open real test site
killall Safari > /dev/null
osascript -e 'tell application "Safari"
activate
set the URL of the front document to "http://selfregister.testnav.com"
end tell' 

sleep 10

# Bookmark site
osascript -e 'tell application "System Events"
tell process "Safari"
activate
set frontmost to true
keystroke "d" using command down
delay 1.0
keystroke return
end tell
end tell'

Or you can try sending out the bookmarks via a script:

#!/bin/bash
# Set as many bookmarks in Safari as needed
# Adapted from the script by David Koff, 2012 for the J. Paul Getty Trust
# many thanks to both Chris Norris (cnorris@getty.edy) & Ryan Manly (ryan.manly@gmail.com) for their invaluable input
# https://jamfnation.jamfsoftware.com/discussion.html?id=6031

bud='/usr/libexec/Plistbuddy'
plist="/Users/student/Library/Safari/Bookmarks.plist"
urls=('https://testnav.com/mn/testnav-7.5.22.36/'
'https://proctorcaching.pearsonaccess.com/ems/systemCheck/systemCheck.jsp?acc=mn' 
'https://www.testnav.com/mn/testnav-7.5.22.36/'
'http://www.pearsonaccess.com/cs/Satellite?c=Page&childpagename=Minnesota%2FmnPALPLayout_v2&cid=1205797559436&p=1205797559436&pagename=mnPALPWrapper&itemsamplercategory=Online+Item+Samplers&start=20')

echo "Backing up ${plist}..."
cp ${plist} ${plist}.orig
#rm ${plist}

killall cfprefsd > /dev/null
for i in "${!urls[@]}"
do
	# Strip just the domain name from the url so it can be used in the case statement to create a bookmark name
	domain=$(echo ${urls[$i]} | cut -d'/' -f3)
	${bud} -c "Add :Children:1:Children:$i dict" ${plist}
	${bud} -c "Add :Children:1:Children:$i:URIDictionary dict" ${plist}
	# For each domain, add a line that creates the title you want
	# Be sure to escape whitespace in the name
	case $domain in
		testnav.com) ${bud} -c "Add :Children:1:Children:$i:URIDictionary:title string TestNav\ Test" ${plist};;
		proctorcaching.pearsonaccess.com) ${bud} -c "Add :Children:1:Children:$i:URIDictionary:title string TestNav\ Check" ${plist};;
		www.testnav.com) ${bud} -c "Add :Children:1:Children:$i:URIDictionary:title string TestNav\ Test\ 2" ${plist};;
		www.pearsonaccess.com) ${bud} -c "Add :Children:1:Children:$i:URIDictionary:title string TestNav\ Samplers" ${plist};;
		# If there is not match, the bookmark name will just be the domain name
		*) ${bud} -c "Add :Children:1:Children:$i:URIDictionary:title string $domain" ${plist};;
	esac
	# The actual URL is added here
	${bud} -c "Add :Children:1:Children:$i:URLString string ${urls[$i]}" ${plist}
	${bud} -c "Add :Children:1:Children:$i:WebBookmarkType string WebBookmarkTypeLeaf" ${plist}
done

# I find that reading the plist with defaults helps the settings apply on Mavericks and Yosemite machines
echo "Applying all settings..."
defaults read ${plist} >/dev/null
# Repair permissions when running as root
chown student ${plist}

If The Spinning Indicator Never Goes Away…

If you get the endless spinning indicator the most likely cause is that the sites are not configured in the Java exception list properly.  You may also get this error message:

7022 – “Failed to load applet. Your test administrator will need to make sure this computer is running the correct versions of necessary software and try again.”

The error or spinning dialog could also mean the site is not on the “run in unsafe” list, but you may also need to empty the Java cache (per Pearson support).  I did so with this command:

find /Users/student/Library/Application\ Support/Oracle/Java/Deployment/cache -type f | xargs rm

I’m not sure if this helps or not, but I also delete any Java-related files from the regular cache folder.

find /Users/student/Library/Caches -name *java* | xargs rm -rf

I have also started getting this error dialog after emptying the cache (even emptying it manually).

Pearson support said to add the root domain to the exception list, which is already implemented in the script provided earlier.

Disable Java Cache

You may want to just completely disable Java cache to try and avoid these problems.  I tried scripting this, but the setting seems to disappear after a reboot on my machine running Mavericks.

Chrome Settings

Chrome is supported according to Pearson, but since Chrome is disabling NPAPI plugins (Java) it’s probably not a good idea to invest your time into it.  However, here is what you can try.

Enabling Java

If you are using Chrome , you will need to deploy a .plist to allow Java to run (and allow pop-ups).  However, since Google is disabling NPAPI plugins, using Chrome may not be the best choice.  You can copy the file, or deploy it using a script (run as root) like this:


echo '<?xml version="1.0" encoding="UTF-8"?>' > /Library/Preferences/com.google.Chrome.plist 
echo '<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">' >> /Library/Preferences/com.google.Chrome.plist 
echo '<plist version="1.0">' >> /Library/Preferences/com.google.Chrome.plist 
echo '   <dict>' >> /Library/Preferences/com.google.Chrome.plist 
echo '       <key>EnabledPlugins</key>' >> /Library/Preferences/com.google.Chrome.plist 
echo '       <array>' >> /Library/Preferences/com.google.Chrome.plist   
echo '           <string>Java*</string>' >> /Library/Preferences/com.google.Chrome.plist 
echo '       </array>' >> /Library/Preferences/com.google.Chrome.plist 
echo '   </dict>' >> /Library/Preferences/com.google.Chrome.plist 
echo '</plist>' >> /Library/Preferences/com.google.Chrome.plist 
defaults write /Library/Preferences/com.google.Chrome.plist DefaultPopupsSetting -int 1

Once deployed, open Chrome and navigate to chrome://policy.  Your settings should show up here if it was successful.

Opening The URLS

There is only a slight difference in using Chrome to open a URL:

# Open system check site
killall Safari > /dev/null
osascript -e 'tell application "Google Chrome"
open location "https://proctorcaching.pearsonaccess.com/ems/systemCheck/systemCheck.jsp?acc=mn"
end tell'

ARD Workflow

Below is a screenshot of the workflow I use in ARD using saved templates.  Each one runs the scripts from above so I can quickly deploy it to the computers necessary.

Alternative Method

Jeffery Johnson came up with a similar process, but instead of scripting everything, he just packaged everything up and deployed it to the machines (download files):

  • Testing user is logged in as testing account.
  • Launch the TestNav app built by me that executes a shell script…
  • Verifies Java and Flash version and then copies and overwrite the Java and
  • Safari settings to work as needed and the launches the testing URL

His Steps

  • Login as testing user, go through the motions and verify testing is
    working
  • with correct browser and Java settings.  You can use the temp testing URL
    from Pearson.
  • I do the above so I don’t run into hiccups later on.
  • I used an app such as InstallEase or Composer to automagically capture the
    changed items needed… They can be grabbed them manually too.
  • You can get an idea what to from the scripts ToInstall.sh