Some of the design elements change substantially when you are moving from a entirely manual process (including uploading a .csv file) to a totally automated process like Student Provisioning Services. For example, when you are doing it manually, it is very helpful to have the students grouped by graduation year. This makes the cleanup of the graduating seniors very simple. At the end of School Year 16/17, you delete the 2017 OU and create a new OU for your incoming lowest grade level.
Would you like to automate provisioning for your district?
This method is functional but has its flaws. It doesn’t take into consideration students that have had their graduation year change sometime during their enrollment. Sorting these out can be very time-consuming. We have never seen any school districts take the time to fix this and keep it current.
This method also requires manual intervention at the end of the school year to create an OU for the incoming students. Also, if you have building level OU’s like MS or HS, you must move these graduation year OU’s to the new appropriate building.
The risk in doing it this way is that you must pay very close attention to the associations of your applications within your G-Suite Admin console and rules that you might have in place regarding sending email. If the structure changes, even if slightly, there is the risk that some other system or the curriculum will be adversely impacted.
By contrast, when there is a completely automated process in place, the structure should be completely static and let students move through the OU structure as they advance in grades. So, instead of a 2017 OU, you might have a Grade12 or just 12 OU. You can have a building level structure that is fixed, and nothing ever changes. Student Provisioning Services will automatically handle moving students wherever they need to be. They can transfer between buildings, change graduation year and their position in the directory will always automatically reflect what is currently entered in the Student Information System.
This granular structure in G-Suite gives you several advantages. You can deploy applications at whatever level is most appropriate. Your Middle School principal might purchase an app for all students in their building, so that you can deploy it at the Building OU level. It is possible that you could have a special need for all incoming Freshman, you can associate that with the Grade09 OU. You can also take advantage of rule regarding email and only allow Grade02 to email other students in the same OU. These rules change as you advance through the years. If you use Grade level OU’s, they are static, and the rules will always be age appropriate. If you use Graduation Year OU’s, you may adjust the rules and move them around as these graduation years’ advance in age.
This granular structure in G-Suite gives you several advantages. You can deploy applications at whatever level is most appropriate. Your Middle School principal might purchase an app for all students in their building, so that you can deploy it at the Building OU level. It is possible that you could have a special need for all incoming Freshman, you can associate that with the Grade09 OU. You can also take advantage of rule regarding email and only allow Grade02 to email other students in the same OU. These rules change as you advance through the years. If you use Grade level OU’s, they are static, and the rules will always be age appropriate. If you use Graduation Year OU’s, you may adjust the rules and move them around as these graduation years’ advance in age.
Now, back to your local directory. This level of granularity can be very helpful in G-Suite, but is not necessary in your local directory. Granted, it doesn’t hurt anything to make them match. It is not necessary to make them match if you are using a service like Student Provisioning Services that can take elements of your SiS and map those data value to attributes on your user objects in your local directory.
For example, we can map GradeLevel to the Office attribute, which from an LDAP perspective is the physicalDeliveryOfficeName attribute. Then, all students could be in a building OU in Active Directory, but your Google Cloud Directory Sync you can use an LDAP query like this to map users into a grade level OU:
(&(objectClass=user)(mail=*@school.org)(physicalDeliveryOfficeName=12)(userAccountControl=514))
This strategy accomplishes several things:
- The object must be a user and no other type of object.
- The user must have an email address within your domain name. This could be used to filter out generic user objects that could be mixed into this OU.
- The Office attribute must contain the grade level 12 so that only students in this grade will sync.
- The user must be enabled. This will make it so that any users that are disabled will automatically be suspended in Google, which is the proper behavior.
This is just one example of how we can get creative with leveraging attributes to customize the behavior that we to experience in our G-Suite Admin console.
For more information on how to automate your student directory and student provisioning, visit www.sps-k12.com.
