SDADM
My feedback
-
62 votes
-
1,074 votesSDADM
supported this idea
·
SDADM
commented
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.
-
1,928 votes
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.
SDADM
commented
It's got 1300+ votes. How many more before it gets added to the roadmap?
-
106 votesSDADM
commented
Agreed
-
56 votesSDADM
commented
Yes
-
48 votesSDADM
shared this idea
·
-
5 votesSDADM
commented
There is a weekly digest they send out
-
750 votes
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.
SDADM
commented
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)?
SDADM
supported this idea
·
-
223 votes
Thanks for the feedback on this item. Azure Premium currently encompasses a broad array of features that span directory management for the entire organization.
SDADM
commented
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.
SDADM
supported this idea
·
-
1,457 votesSDADM
commented
Agreed!
-
1 voteSDADM
shared this idea
·
-
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.
https://products.office.com/en-us/business/office-365-roadmap.
SDADM
commented
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.
-
804 votesSDADM
commented
Out of votes, but supporting
-
41 votesSDADM
commented
https://portal.office.com/Support/ServiceRequests.aspx?showoldtickets=true
Change the filter from "Open" to "All Requests" -
6 votesSDADM
supported this idea
·
-
57 votesSDADM
commented
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.
-
6 votesSDADM
commented
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.
SDADM
shared this idea
·
-
7 votesSDADM
commented
Out of votes, but supporting.
-
23 votesSDADM
commented
This works for me https://portal.office.com/Support/ServiceRequests.aspx?showoldtickets=true (once I change the filter from the default to "All Requests"
-
8 votesSDADM
commented
Out of votes, but supporting
Out of votes, but supporting. Especially the "Created By".