Feedback by UserVoice

Murray Webber

My feedback

  1. 944 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    32 comments  ·  Office 365 Admin  ·  Flag idea as inappropriate…  ·  Admin →
  2. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Office 365 Admin  ·  Flag idea as inappropriate…  ·  Admin →
    Murray Webber shared this idea  · 
  3. 133 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  Office 365 Admin  ·  Flag idea as inappropriate…  ·  Admin →
    Murray Webber supported this idea  · 
    An error occurred while saving the comment
    Murray Webber commented  · 

    This needs way more support than it has currently.

    We also have a parent domain configured as federated, and it was configured first when we deployed, and via PowerShell to boot. Unfortunately, we are not only prevented from adding non-federated subdomains now, but also can't manage domains via the O365 Admin portal and need to use PowerShell instead. Both of these are a pretty terrible situation for us to be in. As Microsoft tried to explain to me, the current backend "container system" used by Office 365 doesn't permit subdomains to exist in a separate container, should the parent be configured as a federated domain. As such, unless the subdomain was added as a "Managed" domain first, all subdomains will have a "RootDomain" flag set; and that locks the subdomain to the federated parent only. Apparently, the only solution - and it isn't a real solution - is to remove all the domains and add them back, starting with the managed subdomains. Yikes.

    We were hoping to create subdomains that we could use for all of our cloud-only accounts we have (and were planning on using). We were hoping to create a community subdomain for parent accounts, and a alumni subdomain, and more... but this limitation has prevented all these scenarios, because we can't create subdomains. This really needs to be fixed.

  4. 116 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  Office 365 Admin » SharePoint Admin  ·  Flag idea as inappropriate…  ·  Admin →
    Murray Webber supported this idea  · 
  5. 877 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    67 comments  ·  Microsoft 365 Groups  ·  Flag idea as inappropriate…  ·  Admin →

    Following up on the previous update, if a workload (such as Planner) is enabled for Outlook by default, we don’t plan on hiding those groups from the GAL. The only other scenario currently under consideration where we would hide groups by default is “Secret Groups”. “Secret Groups” would be hidden from everywhere unless you are a member. “Secret groups” is on the Microsoft 365 Groups backlog, but there is no delivery date available at this time.

    An error occurred while saving the comment
    Murray Webber commented  · 

    The lack of progress on this, and/or option for default HiddenFromAddressListsEnabled option, has resulted in our School SERIOUSLY considering the disabling of Office 365 Groups for our users. In fact, I've recently been made of aware of several nearby schools, and the administrators for a very large group of schools, that have already chosen to disable Group creation. Come on Microsoft. You're losing momentum, and people are disabling your functionality, because things like this aren't in place; and once people make a decision to disable, it's going to be super-hard to convince them to re-enable it down the track. This is bad.

    Murray Webber supported this idea  · 
  6. 378 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    30 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    Murray Webber supported this idea  · 
  7. 267 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    14 comments  ·  General » Users, Photos, Contacts  ·  Flag idea as inappropriate…  ·  Admin →
    Murray Webber supported this idea  · 
  8. 3,297 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    115 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    Murray Webber supported this idea  · 
  9. 282 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    9 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    Murray Webber supported this idea  · 
  10. 243 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    53 comments  ·  Office 365 Business Center  ·  Flag idea as inappropriate…  ·  Admin →
    Murray Webber supported this idea  · 
  11. 1,510 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    56 comments  ·  Microsoft 365 Groups  ·  Flag idea as inappropriate…  ·  Admin →
    Murray Webber supported this idea  · 
  12. 1,319 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    45 comments  ·  Office 365 Admin » SharePoint Admin  ·  Flag idea as inappropriate…  ·  Admin →
    Murray Webber supported this idea  · 
  13. 69 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    7 comments  ·  Office 365 Admin  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Murray Webber commented  · 

    Currently, we see the following:

    a) A new user is created on-premises and synchronised to Office 365. At that time, they have no location or licenses applied. These users cannot use the services they need until an admin is notified or finds out.

    b) As admins, need to check the "Unlicensed Users" filter, or run a PowerShell query to find unlicensed users, and then need to assign a license to them. There are no notifications. There is no automation, beyond scheduled PowerShell scripots we make ourselves.

    c) When assigning licenses via PowerShell, the default is to always assign whole licenses, and then remove components later; which is complex, ever-changing, and somewhat backwards right now. Unlike the web Admin, you also can't replace all licenses with a selection, you need to remove individual licenses and add replacement ones; and if you get the order incorrect, or something goes wrong, you risk data loss.

    d) Making matters worse, thanks to education users being able to obtain their own ProPlus license without admin approval - that happened... thanks Microsoft - users now have inconsistent licensing, with some products enabled across multiple licenses, with various components of licenses assigned from each. It's a mess. PowerShell licensing scripts error out when multiple component licenses exist, or when licenses exist or don't exist, so unless you write a lot of administration scripts and perform a lot of checks, you'll fail to replace licenses. It's easier, at that stage, to load up the web UI.

    e) But the admin Web UI is also broken. You can only edit licenses for one hundred (100) users at a time. You can't perform actions against more and have them split into group of 100, it just doesn't let you continue. You also can't create "pages" of users, to make selecting 100 at a time easier, because the page loads as an endless single list of users as you scroll down. This also rules out using the "select all" box, and requires you to perform manual clicking on users. It's horrible, and the page sometimes fails to load users as well, which further frustrates the admin.

    So, for us, when our executive/board declared that Yammer is to be turned off for students (for now), that meant removing a component from nearly two thousand (2000) accounts, by hand, in groups of one hundred (100). And it couldn't be automated due to the licensing issues discussed above, and the fact that PowerShell doesn't offer the same "replace all licenses with the selected" functionality that the web UI provides. And because the Admin page was broken when we did it, we had to manually select users one screen at a time (which meant twenty students at a time). Do you have any idea how long that took!? This is something that can be easily achieved by using groups/collections, and licensing templates. For example, we'd like to:

    - Create a query-based collection for students, using something similar to the "Filters" in the "Users" area, to include all users from our student domain. Any new students that are created and synchronised to Office 365 will obviously be a member of this collection.

    - We then create a license template for that collection, and apply it.

    - Regardless of the number of users, we simply click "Apply" and wait. Even if the back end of Office 365 can only handle 100 user operations at any one time - as is the limit when using the Admin page - it should queue up the actions in groups of 100 automatically. The user should not need to manage this. If this is a "safety feature", then display the appropriate "Are you sure" prompt, with appropriate information about the action, and let us continue if it what we desire.

    - After a couple of minutes, the licenses are applied, and we're all happy. There is no longer a need for scheduled PowerShell scripts or visits to the Office 365 Admin page. Users are automatically licensed as required.

    - Using this concept, if we want to allow Yammer for a sub-set of students, we'd build a new student collection (possibly using the above collection as a "Limiting Collection"), and further limited via synchronised Active Directory attributes and/or direct membership. We'd then simply add the Yammer license to this group, and have this enable the new license component for all the members.

    I don't understand why Office 365 doesn't support groups/collections. Using Configuration Manager, on-premises SharePoint, etc., everything is scoped and limited to collections of users (audience), based on groups. Why is Microsoft's cloud solution all about assigning individual UPN access to things? This just makes management harder than it needs to be. Even permissions in SharePoint Online are based on individual UPNs instead of groups. Why? Okay, I've finished my rant.

  14. 34 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Office 365 Admin  ·  Flag idea as inappropriate…  ·  Admin →
    Murray Webber supported this idea  · 
  15. 22 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Office 365 Admin  ·  Flag idea as inappropriate…  ·  Admin →
    Murray Webber supported this idea  · 
  16. 278 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    14 comments  ·  Office 365 Admin  ·  Flag idea as inappropriate…  ·  Admin →
    Murray Webber supported this idea  · 

Feedback and Knowledge Base