Administrator should better "External User" invitation process. Recently we had a project where the client was in the "Office 365" environment, however, we did not know that they had an "On-Prem" Exchange with a separate "Microsoft Login". So when we sent the message to their "existing" email, they kept getting errors "Access Denied". After a VERY LONG Microsoft support process, the SharePoint Team sent me to the Azure AD Team. Then the Azure AD team sent me back to the SharePoint Team. LISTEN UP MICROSOFT, your current External Permissioning process STINKS!!!!! We need to be able to set the users up in our SharePoint with the appropriate Login and Password to access the site. STOP making them go through the "Microsoft Live Login" process. IT IS TOOOOO time consuming for our Clients. They should just have to click on the link provided with their user name and password. Right now we can do it, but if the person has an existing "Microsoft" identity then they need to know to select different, logout, then Login and select an "organization" email. It would be nice to be able to load the information and have an executable (when the mail should be sent) so all the users get the message at the same time, and everything is already set. You currently process is HORRIBLE! After each of the SharePoint and Azure AD teams were done tossing me back and forth, I still ended up with a very manual process that still needs "training" guides so the users knows where to go. We need a better process for "permission granting" and reporting. I have a powershell script I can run to get the information, however it should be a standard report.

*English follows Japanese

■Title(件名)：
PowerShell で表示される Microsoft Search の ProvisioningStatus がテナントとユーザーで表示に差異がでる動作について改善を希望します
Fix differences in the display of Microsoft Search ProvisioningStatus in PowerShell between tenants and users

■Description(内容):
ライセンス、サービスの付与を PowerShell でアカウントごとに設定しているため、テナントの Microsoft Search のProvisioningStatus が Success で表示されているにも拘らず、ユーザーで ProvisioningStatus を確認すると PendingProvisioning で表示されているため、Office 365 管理センターで確認作業が必要になり手間がかかる。
また、Office 365 管理センターの確認についてはアカウントに当該ライセンスを付与する必要がありさらに作業工程が増えてしまいます。
"このアプリは組織レベルで割り当てられています。ユーザーごとに割り当てることはできません" に該当するサービスについてはテナントで確認する ProvisioningStatus をユーザーで表示されている PendingProvisioning に統一して表示することを希望します。

We use PowerShell to check license and service assignments for each account, and regardless of whether the tenant’s Microsoft Search ProvisioningStatus is shown as “Success”, checking it from the user’s side shows it as PendingProvisioning, thus requiring extra work to check it via the Office 365 Admin Center.
Also, when checking in the Office 365 Admin Center, it is necessary to assign the relevant licenses to the account, which adds even more work.
Please make the ProvisioningStatus that can be seen for the tenant and the PendingProvisioning that shows for users match up for services marked “This app is assigned at the organization level. It can't be assigned per user.”

Currently, the SharePoint Online admin center allows you to configure a "default" managed path (i.e. /teams/ or /sites/) for newly created sites.

This configuration under Admin Center > Settings > Site Creation reads as: "Create Team sites under [DROPDOWN]".

Despite the mention of Team Sites here specifically, the same default is being applied to Communication Sites as they're created outside of the admin center.

A default managed path should be allowed to be configured for both Team Sites and Communication Sites independently.

Example:
Human Resources (HR) requires both a private area to collaborate securely on employee data but also needs a space to publish out news and content for benefits, open-enrollment, policies, etc.

With separate defaults, the URLs for both their collaborative and publishing spaces can retain a consistent naming convention while easily differentiating between the two:
* HR Comm Site (1-to-many communication): https://mytenant.sharepoint.com/sites/HR
* HR Team Site (private HR collaboration): https://mytenant.sharepoint.com/teams/HR

This can be done today but requires Communication Sites to be created from the admin center which detracts from the platform's self-service capabilities.

I would love the ability to default all team sites associated with O365 groups to a /teams/ managed path while ensuring that default doesn't spill over into Communication Sites where a "teams" path would simply add confusion.

*English follows Japanese
■Title(件名)：
SharePoint Online の標準コマンドレッドの機能拡充について
Improving the standard commandlet feature for SharePoint Online

■Description(内容):
現在の SharePoint Online の標準コマンドレッドでは細かい設定が行えず、PnP などのオープン ソースを利用しなければならない。オープン ソースは自身でモジュールの更新など行わなければならなかったり、コミュニティやフォーラム以外のサポートがないため、不便である。
PowerShell を利用して業務の仕組みを組み込むことが多いが、標準コマンドででくることが少なく、オープンソースの利用だと Online の魅力がなくなってしまうため、Microsoft がサポートする標準コマンドレッドの機能拡充を要望します。
Currently the standard commandlets for SharePoint Online cannot be used to make settings in detail, so open source like PnP had to be used instead. However for open source we have to update the modules ourselves and there is no support other than the community and forums, so it is inconvenient.
PowerShell is used frequently to incorporate operation mechanisms, but not much can be done using the standard commands, if open source is used Online loses its appeal, thus we hope that the standard commandlets supported by Microsoft can be improved upon.