By far, one of the biggest and most talked about trends over the past few years has been the shift to cloud computing and the proliferation of SaaS across almost all vertical industries. Although, there is still much debate centering around security and how to best manage these new systems, it is apparent that most organizations are still eagerly moving forward to the cloud.
Some of the biggest shifts and perhaps least surprising, have been the move to hosted email and storage solutions from Google Apps and Microsoft Live@edu and Outlook Live, especially in the education and government sectors. The cost benefits here seem to be the driving factor in these markets and with good reason. However, this makes it much more imperative that these organizations employ measures to better manage user identity and data security to prevent unnecessary risks and a loss of functionality to their users. It makes sense then that these clients either leverage their existing provisioning solutions or employ a new process as part of their implementation.
A good number of these organizations have approached Tools4Ever in order to incorporate their Live@edu connector as part of the rollout of this hosted solution. A major component of these implementations is the use of Live@EDU Dynamic Distribution Groups (“DDGs”) which can be very powerful because they allow you to have large mailing lists without the need to maintain individual memberships.
As consultant Ivan Jouikov noted though, traditionally, if you wanted to maintain large mailing lists per-school, you would simply set up a group like BlackHawk@mydistrict.com, and then add all the students’ emails into that group. You would also have to maintain that membership list, as students change the schools or graduate.
DDGs use filters to determine their members, rather than maintaining an actual membership list. When an email is sent to a DDG, it finds its members by running a search like “all users whose Live@EDU Department is set to BlackHawk”. This lets you maintain many various DDGs, without having to manage their membership lists.
However, what if the student changes their school? Unless their Live@EDU Department is set to the new school, they will keep receiving mail from the old DDG, but not the new one. This means that to truly leverage the power of DDGs, you need to constantly keep the “Department” attribute updated for all of the student accounts. These and other changes do occur, and this can create an overhead nightmare keeping updates in check and data consistent.
That’s where UMRA comes in and something the solution has been doing for some time now - provisioning accounts and their attributes. In case of schools, we would constantly provision students’ Live@EDU Departments (from SIS data) to fully leverage DDGs.
This way you can have mailing lists like:
- Per-school
- Per-grade
- Per-class
- Per-any-SIS-attribute
- Per-School & Per-Grade
- Any combination of the above
- …all with memberships maintained automatically
Take it one step further –with UMRA we can provision the DDGs themselves! This means we can set up something like class-driven DDGs that get created and deleted automatically, as classes are created and removed in the SIS.
DDGs are a “hidden” feature of Live@EDU – they don’t appear on the administrator GUI (though they will show up in GAL (global address book), if that’s what we want).
A process as simple as this can really help you make the most of your Live@edu solution and greatly simplify the management of users and groups in this system. I will be posting much more information regarding to Live@edu and Google Apps, so please follow this blog for future information.
Wednesday, March 16, 2011 at 6:32PM 