Version 0.24 (still beta) is out, changes:
- now also sets the authorized senders correctly upon first seeding of the groups, won’t keep this in sync yet!
- fixed a bug in initial seeding of groups if only O365 had groups
- improved AD caching with only relevant attributes instead of *
Get it here
Azure AD, Intune and Windows 10 offer an incredibly nice light management option, where your users can use any Windows 10 Pro or higher device and simply join it to your Azure AD on their own.
Intune then allows you to enforce your security policies on those devices, and to distribute AppX and MSI packages to those devices.
Traditionally, IT used to manage devices using GPO’s or more, allowing a very high degree of granular configuration and remediation. Intune or the Enterprise Mobility Suite don’t offer good alternatives for Group Policy, and don’t allow scripts to be deployed natively, this greatly limits us.
However, the ability to deploy an MSI can be leveraged to still offer any of the granular management we used to do. I would very, very strongly advocate only using this as a last resort, don’t swim against the current, let users manage their own device and move to a services based architecture for your organisation’s IT.
Today’s case for a global NGO with a fully EMS licensed user base covers the distribution and installation of a large number of templates for Microsoft Word, including a normal.dot, macro’s and the required group policy settings to make word use these templates. Continue reading EMS case: distributing Office templates and macro’s to your users on Windows 10 mobile managed Azure AD Joined devices
My current customer had a little dabble in Office 365, they set up their Hybrid configuration and added their @xxx.onmicrosoft.com email alias to all their users and groups. This mostly happens automatically.
They then later decided to go with a new, different Office 365 tenant for production purposes, the old tenant was dismantled and the AADConnect server was deleted.
However, all AD objects still had their alias for the old Office 365 tenant, syncing that to the new tenant would be a bad idea and I cleaned that up just to be sure it wouldn’t cause trouble in the future, here’s how I did that:
This just made my day, as working with Azure AD through CSP
is was a pain in the ass. Microsoft finally enabled Azure AD management through the new Azure AD Portal!
O365GroupSync is a tool that I am building for a large global NGO, because AADConnect creates Read-Only objects in Office 365.
Read-Only objects cannot be edited in Office 365, thus users are unable to edit distribution lists in Office 365’s Outlook Web Accress (OWA) even if they are managers of said lists.
O365GroupSync was built to take over the synchronisation and initial seeding of all distribution lists, both ways, to allow users to edit distribution lists while in a hybrid Office 365 Exchange Online scenario, both on premises and in the cloud.
This beta version has been tested, but is not yet running in any production environments.
Get it here