We all know the poor track record of SharePoint updates (security and non-security) when it comes to quality, still the updates are pushed via Windows Update causing all kinds of issues on on-premises farms.

Most common scenario is that IT doesn't really understand SharePoint, so they allow updates via WSUS (or just install them directly) to one or all servers of the farm, causing all kinds of "by-design" issues, as SharePoint Config Wizard needs to be executed to get the farm working properly again, OR the patch first needs to be installed on all SharePoint servers to make it work properly. I don't believe "train your IT" is a valid argument to this as it just keeps on occurring all the time, everywhere. It's like saying "don't crash to other vehicles" and wonder why there still are car crashes.

Another (all too common) scenario is that update itself causes issues in SharePoint, and there is total radio silence from MS side as to what happened, how to fix it, when a possible fix is done.

So, please do not push SharePoint updates (security or non-security) via Windows Update.

The current licensing model isn't friendly at all if you're thinking on making your SharePoint product available as a Cloud SaaS.

To go Cloud, this must needed change must occur so that the SharePoint (and its ecosystem required products) licensing model to fit well with SaaS business models without an obscene entry cost in licensing that crushes your initial investment as an ISV.

We have this product that we developed, and it requires SharePoint Server.

We’ve been considering for some time now the possibility of making our product also available as a SaaS.

However, as SharePoint Server is a requirement – the available licensing options pose a direct problem to this business model when you start onboarding customers.

Last year MS released the header anchor link function which enabled the possibility to link to different parts within a web page. Anchors is an extremely important and fundamental function that has been around since HTML was invented. It is a vital function for users to enhance navigation and information finding. In our case a company intranet.

Currently it's not possible to use these "header anchor" links in Sharepoint mega menu. If you try to paste an anchor link to a mega menu it cuts off the anchor part of the included link. MS 365 Tech Lead Stanley confirms this issue:

"I will like to inform you that the "anchor tag" feature is on its growth stage and we are still taking feature suggestions on making it better. It is currently supported on a "within-a-page" basis and is not yet supported on the Header section as Header URLs are allowed to either Point to a site within your SharePoint collection or an external site entirely."

I propose MS to evolve the current mega menu navigation component so that it does not cut off the anchor part in an included link.

Content types:

Enable content type-based default values in addition to site column-based and location-based default values. Allow farm administrators to specify which takes priority in cases of conflict (and make them function reagardless of if the user creates a new document from the ribbon, uploads it or drag-and-drops it into the library)

Enable all and any sharepoint columns to be displayed, and when applicable edited, from within the document (not just in the ribbon). For example give us the option to automatically propagate your new unique farm-wide document ID-based url in the actual document content. would be fantastic for users that need to print out the document to be able to have a non location-based URL.

Content Type Hub:

Allow some way of specifying if and when a site Collection should inherit Changes from the CTH rather than the only option being prior to each CT subscriber job specifying on each and every site Collection, that yes I want those changes this time also.

Instead of resulting in a synchronization-conflict or creating duplicate content types, allow renaming of conent types on subscribing sites by changing the content type name (or column names for that matter) in the CTH and resynching them.

Do not! Do not send out a new copy of every template-file that has ever been associated with a content type to each and every subscribing site on every content type subscriber timer job. In fact do not send out actual documents at all. instead reference them from a managed template library. I know it is possible in 2013 as well although less than intuitive or even documented.

Give us an option to exclude synchronising all my sites (unless we specify that we want them included).

*English follows Japanese

■Title(件名)：
SharePoint Online および OneDrive for Business を IPv6 のみで利用したい
Use only IPv6 for SharePoint Online and OneDrive for Business

■Description(内容):
IPv6 のみで SharePoint Online および OneDrive for Business を利用できるよう対応を進めてほしい。
IPv6 に対応しているとのことであれば、IPv6 のみで利用可能な形としてほしい。
他社ではそれがすでに実現しているため、そのようになることを期待する。
また、"Office 365 IPv6 テスト計画" というドキュメントに IPv6 専用クライアントについて記載があるにもかかわらず、実際対応していないのは混乱を招く元となる。

We would like progress to be made towards supporting the exclusive use of IPv6 for SharePoint Online and OneDrive for Business.
We would like to be able to exclusively use IPv6 on anything that supports IPv6.
This is already possible in other organizations, so we would expect it here too.
Also, even though there is mention made of an IPv6-only client in the document titled “Office 365 IPv6 Testing Plan”, the fact that no such thing is actually currently supported is the source of much confusion.