The Stink of School Data Sync

It seems to be the way of things that any given technology never acts on its best behavior, and often there is not enough documentation about said technology to figure out what the heck is going on. That is how I feel about Microsoft's School Data Sync for Education.

Yes, Microsoft made a nice little Mix video showing you how to setup SDS using .csv imports (the method we are using) on your tenant. (Which at the time of this writing is already outdated and still not updated since they've moved to Teams for Education from Classroom). However, they don't really show you the after effects. Theoretically I understood that Groups would be created from the Section ID fields exported from our SIS. What I didn't understand were the practical implications of that fact.

Here is an example of our Section Name fields:

(Nope, not a typo-those two names that are the same are for different grades.)

1-SKL_ Section-1

1-SKL_ Section-1

1-SKL_ Section-5

And an Example of our SIS IDs, associated to the above sections in the same order:

111111

111112

111113

And therefore our Group Names:

1-SKL_ Section-1

1-SKL_ Section-1

1-SKL_ Section-5

Group IDs:

Section_111111@tenant.org

Section_111112@tenant.org

Section_111113@tenant.org

Aliases:

Section_111111@tenant.onmicrosoft.com

Section_111112@tenant.onmicrosoft.com

Section_111113@tenantonmicrosoft.com

We have a rule setup on Groups to always include the Groups- prefix when groups are created…apparently this configuration does not apply. Why--it may be because of the integration of SDS with "Teams" which I was informed back in April would not have the functionality to be able to enforce the prefix unless we moved to Azure AD Premium…

So all of those horribly named groups got dumped into our directory. We did set the SDS profile we created to allow teachers to change the group names, but I'm sure many of them simply will not do so. We are working on doing some additional tweaking and pulling from different areas to hopefully get some better-looking group names, but the bigger point I'm making is to be cautious about how this comes out-of-the-box.

I'm sure that many school districts are in the same boat that we are--we don't have people dedicated to only managing O365. We split our time between many different technologies, and we don't have premium support contracts with Microsoft. I probably deal deeply with O365 once every 4 months if I'm lucky. During that period of time, I'm also lucky if any of my previous processes and procedures continue to work--the changes that are being implemented are often so big that either nearly everything about the process is different, or one tiny part that isn't well documented but will totally bring everything to a screeching halt if it isn't changed.

So that brings me to my next hang-up. We tried changing the files, re-uploading them with new names, then syncing them, but it didn't overwrite our previous group names. (I do believe that information was included in the documentation, but it is certainly worth re-iterating.) So what's the Occasional O365 Admin to do? Yeah-go ahead and remove those groups. But if you go in the Groups Admin interface, if you select more than one Group you get this lovely little piece of information:

No, you can't bulk-edit groups from the GUI! So This wouldn't be so bad if not for one thing-almost every interaction I've had with lower-level technical support from Microsoft (including documentation) always states that they do not support Powershell. How can they require that you use Powershell to manage certain things, yet not provide robust support for it?!? Anyway, if Microsoft can't really support Powershell, neither can I-so take this as all of the disclaimers that generally go along with this. Use the information below at your own risk, I can't be held responsible if something goes wrong with your tenant because you chose to follow the process below (like you didn't clean up the groups.csv file before uploading it in the delete process and you deleted ALL of the groups from your tenant rather than just the one you wanted to…)

I found a super-simple Blog post by Garth Jones on how to do this. Could you create a super-complex Powershell script to do the same thing? Yeah, you could-but sometimes Quick and Easy is the key. I just want something that is going to work and work well so I don't have to spend a huge chunk of time writing and testing a script to get something done. And I know there are a lot of scripters out there thinking it shouldn't take too long to write up something simple--but only using Powershell on the occasion precludes a 5 minute scripting session and lends itself more to "I just spent half a day trying to get this script to work and it still doesn't work and I'm no closer to actually accomplishing the task I set out to do." Anyway-soapboxing aside, here's the link to that walk-through:

It is very easy to follow with his documentation. However, I will post the short of it here:

Make sure you have these two things:

• Microsoft Online Services Sign-In Assistant for IT Professionals RTW

• Azure Active Directory Module for Windows PowerShell (64-bit)

Once installed, run Azure Active Directory Module for Windows Powershell--Garth didn't mention it, but I run all my Powershell instances as Administrator to prevent weird errors from cropping up.

Connect to the service using a Global Admin account for your tenant by typing in Connect-MSOLService, pressing enter, then entering your credentials.

Export all of your groups by running this command: Get-MsolGroup –All | Export-CSV c:\groups.csv

Do some cleanup of the file-remove ALL groups you DO NOT want to delete from the file. YES--be VERY CAREFUL here! Save the file.

Enter the following command to remove the groups:

Import-CSV c:\groups.csv | Remove-MsolGroup –Force

I did get some error response when I ran it (bad me-I didn't document it) but it successfully removed the groups.

Hopefully all of this info will help.