Configure course tools and resources

Pre-start student Applications

Outcome You start applications for all students in advance, so resource allocation does not slow down the start of class.

Before you start

• You are a Space Administrator of the course.

• You have distributed the application to all students.

• You expect a large number of students (above ~50) to start the application at the same time, or the application has been customised to request higher resources.

When many students start the same application simultaneously, resource allocation may take several minutes per application instead of the usual 30–60 seconds. Pre-starting applications avoids this - the applications are already running by the time students log in.

Schedule a startup

1

In the Master Instance, open the applications view.

2

Click the ... Actions menu next to the application.

3

Select Schedule for start.

4

Set the date and time by when all applications in the space should be running.

The scheduled prestarts can be viewed, edited, or deleted from under the applications list. To repeat a schedule for the next week, click Add to next week in the Actions column. The next scheduled startup is also visible from the Course checklist on the space overview.

Schedule constraints

• The schedule must be at least 30 minutes in the future, to allow time for all applications to start.

• Up to 20 scheduled prestarts can exist in a space at the same time.

• Prestart dates cannot be more than 6 months in the future.

• Prestarts cannot be set for archived courses.

Manual pre-start

If you want to start applications for all users immediately rather than scheduling, use the Start for all users option in the ... Actions menu of the applications view.

Student applications are stopped automatically after 1 hour of inactivity, so it does not make sense to pre-launch more than an hour before the planned start time. The pre-launch starts the application in the Master Instance for Space Administrators, and the respective student application in each student instance.

Optimisation for repeated prestarts

Only the first prestart starts the application for all users in the space. Subsequent prestarts check which users actually used the application around the last prestart time and start the application only for those users. This saves resources for courses with significant student dropout.