SharePoint vNext is
right around the corner going to be out any day now done when it’s done. That being said, I have a few wishes or SharePoint vNext from an IT Pro perspective. These are in no particular order, but here is my SharePoint vNext Wish List.
- Administrator audit log. Auditing support for actions performed by administrators, for example, changing values of objects like SPWebApplication in PowerShell. This data should be logged as plain text and/or into a separate SQL database. Reporting can be the standard Excel, with APIs for expansion.
- Full SQL retargeting support without an alias/AOAG. I should be able to use a cmdlet to update the registry references to a Configuration database. This enables mobility in scenarios where a SharePoint Administrator has not implemented an alias, by design or mistake, or in scenarios where only the Configuration/Administration database must move while leaving the remaining databases behind.
- A read-only Farm Administrator (auditor?). This enables the business, rather than IT, to review what a SharePoint Administrator has configured.
- SharePoint Management Shell access without Local Administrator access. Let me delegate tasks that do not require Local Administrator rights (e.g. provisioning a Web Application requires Local Administrator rights, just remove that functionality from the Shell just like Central Administration).
- A SharePoint cmdlet to replace stsadm -o sync. The -o sync is the last stsadm command I leverage on any regular basis as access to the API is limited so it isn’t possible to provide a (supported) PowerShell cmdlet replacement.
- Configurable SPWebApplication Max File Size. This boils down to a single property on the SPWebApplication, it’s just currently hard coded to 2GB.
- Allow ‘stretched farms’ of greater than 1ms/less than 1Gbps. Provide a range of supportability, e.g. 1 – 10ms is okay, >11ms is not. Provide per-Service Application guidance.
- Farm-wide VSS provider. Support for Hyper-V Replication/snapshot/online backup. Briefly make.a call to ‘freeze’ the state of the farm. Right now administrators have to contend with patches that may break either during deployment, or briefly there after during patch validation. Being able to apply a snapshot to a farm would allow immediate reverting… because let’s be honest, testing a patch in pre-production isn’t always the same as deployment and testing in production.
- Provide selectable components for Backup-SPFarm. Right now the story is backup the entire farm or a single object. This is rather inflexible.
- SharePoint virtual machine template support. Let me build a SharePoint VM, add it to the farm with particular services (Foundation Web, Excel Calculation Services), then flag it as a template within the farm. Integrate the removal of the server with sysprep. The sysprep process would remove the server from the farm, but store the template information within the resulting VM template. Upon deployment (with SCVMM, as an example), I could select the template and I would then immediately have a server with my pre-configured services. Alternatively, build in a ‘template’ to psconfig/Config Wizard. The template would have pre-defined Service Instances/server configuration data that would simply be a selection. On a run of psconfig/Config Wizard, I would input or select a pre-defined template and that server would be ready-to-go immediately after deployment.
- Support to trim the Audit Log in Content Databases with a scope of less than 1 day. The API is currently limited to day increments. This causes issues if enabling full auditing support on a farm with heavy traffic. The Audit Trimming command may fail with a scope even as small as a day. In addition, allow me to simply drop all data within the Audit data table. Support for also exporting the audit data via automated/timed process to an external database. Even better, support to create audit data directly in a non-Content Database. Audit data can cause significant bloat, and it is also possible to have “orphan” audit data, where the Site Collection has been deleted, but the audit data remains in the Content Database. The only solution here is to migrate all Site Collections to a new Content Database and abandon the existing database. Another alternative may be to just allow one to specify a GUID (Site GUID) to clear anything with that GUID in the audit data table.
- Support AlwaysOn Read-Intent. When performing a read-action, query the read-only copy of the data for performance improvements.
- Remove the Timer Job cache from disk. Store that data in-memory. Faster to query, less prone to host-based antivirus issues, and if the memory can be kept in-sync with other farm members, preventing the “object update conflict…” type errors (AppFabric for timer job cache? I kid…).
- Azure database (PaaS) and Azure Blob Storage support. Much of this would be dependent on latency.
- Move PowerPoint and Word Automation Services outside of SharePoint into Office Web Apps. Provide CSOM APIs for these services.
What are your wishes for the next version of on-premises SharePoint?