Jul 28 2016 06:50 AM
Jul 28 2016 06:50 AM
Looking for some clarification on expected behaviour of the O365 Groups Naming Policy. Using details via
https://support.office.com/en-gb/article/Office-365-Groups-Admin-help-3f780e8e-61aa-4287-830d-ff6209... we have applied policy and all appears ok with new O365 Groups created with correct prefix and suffix.
However it appears that (in circumstances yet to be determined ) distribution lists and security groups sync'd via ADSync also have the policy applied.
Has anyone else seen this ?
All I can find is a lonely request asking to fix it ... https://office365.uservoice.com/forums/286611-office-365-groups/suggestions/15008712-separate-naming...
Is this a feature update that has slipped in via the June update ?
Jul 29 2016 02:26 AM
Hi Nicholas, I have tested this and I have the same issue. Thank you for notifying because this will also become a serious problem for some implementations that I am working on.
However, what seems is that it lists it with the new name but I can still see the AD Name when e.g. I want to share a site with the affected security group. In that case it shows the name without the prefix. When I search for groups using the prefixes it only shows the Office 365 groups so it appears to be a display name issue.
Jul 29 2016 07:11 AM
I think this is via design. A single group naming policy exists in the Exchange Organization configuration that is applied to both Exchange groups and Office 365 Groups. Ideally, in a hybrid environment, the same naming policy should exist in both environments to ensure consistency of group names for both on-premises and cloud users. To ensure consistency, the policy is applied to groups that belong to the on-premises environment as they are synchronized into Office 365. The reason why you have a problem is that you don't have the same naming policy defined on-premises or you have some groups that were created on-premises before a naming policy was in place. Or perhaps that you simply didn't realize that the naming policy applies to other groups than Office 365 Groups!
Jul 29 2016 07:29 AM
Jul 31 2016 09:04 PM
The fix for this issue is deploying, and based on what customers have told us, the fix works when it's avaiable in thier region. If you PM your tenant details, we can look into whether the fix has reached your tenant.
Sep 02 2016 01:03 AM
I have the same issue....
You state that a fix is deployed, how do I know if I got this and what is the fix.
Sep 27 2016 05:47 AM - edited Sep 27 2016 05:51 AM
@Eric, It was me who posted that feedback on uservoice (https://office365.uservoice.com/forums/286611-office-365-groups/suggestions/15008712-separate-naming...).
We are having a problem with naming conventions which apply to DLs coming from on-prem AD. They sometimes get applied and sometimes don't. Moreover, the policy does not get applied to the email address (understandably so, because it will then invalidate the on-prem AD without a writeback). However, for O35 groups the it does get applied to email address but is inconsistent and many times it misses doing so. (I asked that on the erstwhile community also, but the responder gor confused between O365 groups and on-prem DLs: https://answers.microsoft.com/en-us/msoffice/forum/msoffice_o365admin-mso_manage/o365-groups-naming-...)
Moreover, The DLs / Security Groups created in on-prem AD are only done by an administrator but O365 groups when created by administrators does not get the policy applied. I don't see how that could be made consistent as Tony mentioned above. For on-prem DLs, administrators can manually follow a policy while creation, but for general users creating O365 groups we need to enforce a policy via automation (so as to avoid post-facto policy violations after documents and team sites etc are provisioned and populated).
Hence we need to differentiate the policies between on-prem DLs (or mail-enabled security groups) versus O365 groups only.