Hello,
Previously when our snapshots were run we were able to manually enrol students into a course with no access problems. Also in manually created courses through the GUI students were also manually enrolled and unaffected.
Now it seems since we have moved to a new SMS students are appearing as 'disabled' in courses that they are manually enrolled in, and for manually created courses students are falling off.
Possibly a long shot question, but can anyone suggest or advise what might have changed to be causing these issues?
Vicky,
What data source key is the snapshot process using for the enrollments created from the SMS? Enrollments (and users, and courses) that have been manually created through the GUI have a data source key of "SYSTEM". Normally, you would set your snapshot process up so that snapshot is creating courses, users, and enrollments with its own special set of data source keys.
You should definitely NOT have the snapshot creating or managing records (users, courses, and enrollments) using a data source key of "SYSTEM". If you do, then what happens is exactly the kind of behavior you're describing--the snapshot disables records that have been manually created via the GUI, because they do not appear in the feed files that are coming from the SMS.
So, look at the data source keys that are being used by your snapshots since changing the SMS.
Mike
Hi Mike,
From what I can see we use three DSKs
2012_courses
course_id|external_course_key|course_name|start_date|end_date|template_course_key|allow_enroll|allow_enroll_existing_account|available_ind|catalog
2012_enrolements
external_person_key|external_course_key|role|available_ind
users
external_person_key|system_role|user_id|passwd|firstname|lastname|email|department|student_id|institution_role|public_ind
Though we do have a SYSTEM key with 60000+ records
The only way I have found to fix the disabled status is if I delete the user account, it is then re-created by the snapshot and then I can enrol them to courses they are not enrolled in on the SMS (but still need access to). The problem with this is that it will delete all associated data (wikis, journal, discussion posts etc)
It's not easy to tell what the DSK is for enrollments from the GUI, but when you do a search for users or courses, what DSK are you seeing listed for them in the right-hand column?
60000+ is a lot of records to have been manually created via the GUI under the "SYSTEM" DSK. If you open the "SYSTEM" DSK listing from the pull-down menu, you can see now many of those records are users, how many are enrollments, etc. Also, how many records do you have for your other DSKs ("2012_courses", "2012_enrollments", and "users")?
Do you have direct access to the Blackboard database? If so, you can fix the disabled status directly, and also confirm the DSK on enrollment records. What's more, you can change the DSK on enrollment records through the database or through the snapshot.
Hi again Mike,
Thank you for responding.
When searching a user, the DSK is specified as 'users'.
If I open system, we have the following (enabled vs disabled):
Users
For the 2012_courses we have:
2012_enrolements: (incorrect spelling but this is how it was setup)
5369
users:
I will have to see how I can access the Blackboard database, but I do not have access currently.
To be able to change the DSK would be great, though.
You can change the DSK on a record (user, course, or enrollment) by running a snapshot with under the current dsk with a feed file that has an additional New_Data_Source_Key file in it.
To trace down your problem a little more closely, you'll want to confirm (if you haven't already) whether the enrollments are getting disabled, or whether the users themselves are getting disabled. Currently, it looks like you have 14,000 enabled users in your "users" dsk, but 235,000 disabled users--that is a lot of disabled user records.
Thank you so much for your response. Nice to know you are around with your expertise :)
Vicky