How to deploy NWEA TestTaker 6.4 on Intel Macs with Casper

Hello everyone.  The title of this says it all.  If you are like me and you work in IT for a school system that uses NWEA Test Taker for their assessment testing, then you know it is one giant pain to deploy.  I am lucky that we have the Casper Suite, so I use their tool sets to accomplish this goal. Now, you could probably do something very similar to what I am doing with different tools.  So, if you would like to add to my article with different tools on how to accomplish the same thing, plase feel free to contact me and email me the specifics or write an article and I will gladly publish it. First step is to get a copy of TestTaker 6.4, which you can download from NWEA's web site.  Their tech rep will have to give you the link and log in as I don't have it handy and I am pretty sure I can't post it.  Once you obtain the DMG file containing it you will want to use Composer to take snap shots of your before and after progress.  So this article depends on using Casper to build your package for deployment. First thing I do is map the network share that holds the NTE folders for the TestTaker software.  To map a network drive you can hit  + K on the keyboard, or click on The Go menu at the top of the menu bar and then select Connect to Server... Once we know that the NTE folder is mapped, we can proceed.  We are keeping our NTE folders on some older Novell shares, and the Novell servers do run AFP.  Once you have verified that the folder is mapped you can proceed. The next step is to take a snashot with Composer so we can build our package.  Just a normal snapshot of new files will suffice for this package. Now that you have chosen to create a package for this.  So Composer will prompt you to name it, and go ahead and name it whatever it is you would like to name it. Now Composer will take the snap shot of the system.  This will record everything that is currently installed and build a receipt file.  Later on you will take a final snap shot and it will compare receipts and you will build your package off of the differences.  Wait for the progress bar to complete, it will look like this and can take several minutes. Once this completes, Composer will tell you to install and configure your software.  Make sure you leave Composer alone until you do this.  If you hit the build package now and do not add any software Composer will just build a blank package, and you will never get those 15 minutes of your life back.   So once you get this screen it is time to install your software:   Now take yor TestTaker DMG file and open it, and install it into your /Applications folder.  Install it like you would any other applicatoin by expanding the image file and then dragging it into your /Applications folder. Once you drag and drop your TestTaker app into the Applications folder.  You can then launch it for the first time.  It will ask you to point it to the NTE folder.  Since this is a Windows application running with the CrossOver APIs built into it, you will have to map it from a Windows Explorer window.  Since OS X by default mounts every volume under /Volumes, that is where you will want to look for your network share you mounted in the beginning. So, expand the root of the volume, which in Unix is simply /.  Then navigate down the folders until you see the mapped network share of where your NTE folder lives. Now that you have found your NTE folder on your mapped network drive hit the OK button and it should proceed to launch the TestTaker application.  Once it luanches you can exit out it.  The following steps is how to go into the bottle it creates and grab the full network path information and copy/paste it into the actual application itself so you can hard code the full path to the NTE folder into the Application. Now that the application has launched successfully, in the user account which you have been doing all this work in, a bottle should have been created for this application for the CrossOver API to use.  It can be found in the following path: /Users/your_user/Library/Application Support/TestTaker/Bottles/testtaker/drive_c/Program Files/TestTkr/TestTkr.ini That file will have the path of which you want to copy/paste for your NTE folder.  It gets stored as a user level preference, but if we actually hard code it into the Application it will be for all users who use the Application on this system.  I create one package for each building that uses this software, then deploy it to all computers in that building.  Since each building maps different network shares this makes it easy, and you don't have to rely on copying over user preferences to multiple accounts.  So, right click or control + click that ini file list above and open it with your favorite text editor. I am a huge fan of TextWrangler, and I recommend it to anyone who likes to code, edit, or administer OS X machines.  Open the file and near the top you will see the full path, and since Windows needs to map something to a drive letter, you will notice it is mapped to drive letter Z:  Copy that whole line and get ready to paste it into the package contents of the actual application. The line that says NTE root path is the one you want to copy.  I know it is kind of hard to read but you can see where I highlighted it above hopefully.  Now that you have copied that line, navigate to your TestTaker.app in /Applicatins and give it a right click or control + click and view the package contents. Once you have selected that it will open a finder window and you will want to navigate back to that TesTkr.ini file yet again.  Here is the ridiculously long path: /Applications/TestTaker.app/Contents/SharedSupport/testtaker/support/testtaker/drive_c/Program Files/TestTkr/TesTkr.ini So, navigate to that file and again open it up with your favorite text editor and then paste that full root NTE folder path in the same place where you go it from originally.  It should look just like the picture above that lists the NTE root folder path.  Save the file and exit.  Next you can finish up by telling Composer to take another snap shot, and this time it will take the final snap shot and build your package based on what new files have been added to the system.  If you go back to your Composer application you should still be at this window. Now you can click on the Build Package button and let it go through and build the package.  Once it goes through and completes you will get a dialog box asking if you want to copy user specific data to your package.  In this case, we really don't want to but to show you what is all created I went ahead and said copy it all over.  Here is a screen shot of everything that it built off the snapshots.   Now as you can see it picked up all my user specific preferences from the CrossOver bottles being created and the application preferences.  We don't need any of thist stuff because the first time any user launches this application those files will be created on the fly, and so will the bottles for the CrossOver API.  Since we went ahead and drilled down into TestTaker's actual package contents and hard coded the application to map a specific network drive we don't need any of these user specific files.  This will trim down the size of our package and it will also lower the margin for error.  In my experience mass copying user preferences across user accounts can cause issues.  In my initial testing of this package I had left the user preferences in, and about 50% of my packages failed to work due to corrupted user preferences.  So, I decided to take them out and let them create themselves on the first run on the fly.  That way every user who runs the application gets a fresh copy. At this point click on build as DMG.  You can build it as a PKG if you want instead, but I prefer to compress all my packages to make network transactions go smoother and take less bandwidth.  You could go either route.  If you were going to mass install over ARD Admin, then I would say make a PKG file, then you could just grab a few 100 Macs at once and use the install PKG option right from ARD Admin.  However, I deployed this as a post image package and a  Casper policy that runs at start up to install this package.   How the End User interacts with TestTaker: Now, that I have built the package and deployed it, how does my user interact with it and use it so that it works?  This was also a challenge at first since I did not want to map the NTE folder to everyone via an Open Directory policy nor did I want every client mapping that directory all the time.  So, we used another Casper application called Self Service.  Self Service is a basic web based application that connects to the JSS and allows end users to trigger policies manually.  In the JSS web end you will create a new policy and set the trigger to none, which means it will be for self service.  Then click on the self service tab and choose your icon to be displayed on your self service policy.  This is what the end user will see when they launch self service. I wrote a very simple Apple Script that maps the NTE share, and then if that share is mounted it launches the TestTaker application.  So, my self service policy actually just runs a simple Apple Script, and the application itself still lives on the client machines locally.  So, nothing actually gets installed via self service, the only thing that executes is the script.  Here is the Apple Script:       I had set up a specific user account to map the shares and put it in the script since the script will send things in clear text.  Then when the testing windows are done I just have the Novell admin disable those accounts until next testing session is up.  These accounts also only have rights to map that NTE folder.  The script mounts the share, then loops to make sure the mount exists, and if it does exist then it will launch TestTaker.  Below is what the end user would see from Self Service. As you can see once they click on the TestTaker icon they get an option on the left hand side to "install."  However, when the user clicks that it doesn't install the program, it just runs the script to mount the network share and then launch the TestTaker application.  This is the best method of deployment I could come up with, and I had a to go through some trial and error.  This seems to be the smoothest way to deploy it.  The servers that hold my NTE folders are older ones so that is why I just ended up having the Novell Admins make me up a generic account that only had rights to map the NTE folder and I use those credentials in my Apple Script to mount the share. I hope this helps all of you who are trying to deploy the TestTaker application from NWEA on your Intel Macs.  I hear a rumor that the web based version will be out in summer time of 2010, but who knows how accurate rumors can be. Thanks for reading, Tom