Out of votes, but supporting. Especially the "Created By".
Yes, yes, a thousand times YES!
Flipping the switch to ON for some new feature (as was done for Video, O365 Groups, and more) is a bad enough idea, but those applications by default were made available to ALL users with no restrictions.
We'd much prefer to set our own pilot teams and have them test so we understand all aspects of the new features, can set policies on usage and naming, can set roles and permissions, can prepare our help desk, can host training, etc. prior to rollout.
I'd imagine any organization would want the same, but it's far worse when you do this to your government clients, Microsoft.
Thanks for your feedback! We’re reviewing your suggestion. Remember, the more votes a suggestion gets, the more likely it is that we’ll do it. You can see what’s happening with Office 365 on the Office 365 Roadmap.
It's got 1300+ votes. How many more before it gets added to the roadmap?
There is a weekly digest they send out
We’re planning to release a group privacy type called “secret groups” later this year. Private groups (those whose contents are only visible to members) will still remain in the directory. Secret groups are essentially private groups that aren’t visible in the directory by non-members.
I fully agree with the poster who said, "User created groups of any kind should not show in the GAL."
In addition in cluttering the GAL, we recently discovered that since there are no naming controls, users can potentially create groups (public or private) that have the same name as an official mailbox (an office, department, or employee). Then they show up in the GAL because they are not hidden...
Do you realize what a HUGE security hole it is when any internal user can create an O365 Group called "Human Resources" or make one named after [Government Agency's] director in the GAL? When other users start to pick the wrong name in the GAL and now suddenly information is being sent to the wrong recipient(s)?
Thanks for the feedback on this item. Azure Premium currently encompasses a broad array of features that span directory management for the entire organization.
We recently discovered that since there are no naming controls, users can potentially create groups (public or private) that have the same name as an official mailbox (an office, department, or employee). Then they show up in the GAL...
Do you realize what a HUGE security hole it is when any internal user can create an O365 Group called "Human Resources" or make one named after [Government Agency's] director in the GAL? When other users start to pick the wrong name in the GAL and now suddenly information is being sent to the wrong recipient(s)? We need to be able to control naming.
4,406 votesworking on it · AdminBarbara Feldon (Office 365 Customer Experience, Microsoft Office 365) responded
Great news! This capability is included in in the recently updated Office 365 Roadmap entry: “Admin App Launcher Customization Tools” which can be found in the “In Development” section.
As a corollary, allow Admins to REMOVE tiles from the App-launcher for all tenant users.
We did not have oneDrive enabled initially, as IT wanted to test it and develop policies on bit's use before rolling it out. Granting a SharePoint Online license automatically made the oneDrive tile appear. If we could have removed/concealed it until we were ready, that would probably have helped limit the number of frustrated users calling our help desk.
Out of votes, but supporting
Change the filter from "Open" to "All Requests"
If nothing else, the resolution should be in the ticket!
MS never fails to send an email** with helpful and detailed summary upon closing a case, but the resolution field never says anything more than "This request has been resolved and closed."
**That email only goes to the requestor on that ticket. If the requestor is unavailable for any reason, we have no other way to find the resolution, because it's not in the ticket.
P.S. I included the URL so others can check their own support history and see if the same applies to their tickets before deciding whether to support this idea.
It may be that this is only affecting my employer, and others at different support levels don't have this issue.
Out of votes, but supporting.
This works for me https://portal.office.com/Support/ServiceRequests.aspx?showoldtickets=true (once I change the filter from the default to "All Requests"
Out of votes, but supporting