Microsoft SharePoint Content Database Policies in DocAve Governance Automation Service Pack 5

As we have seen from previous posts in this series, many enhancements in DocAve Governance Automation Service Pack (SP) 5 are visible to and especially useful for SharePoint end users. Today, in the final post of the series, we will focus on a new feature that end users will never see, but SharePoint administrators will find quite valuable: Content Database Policies. The Problem: Managing SharePoint Content Databases Using Native Tools Every new site collection created in SharePoint stores user and system content (documents, pages, icons etc.) within a Microsoft SQL Server database. This database is referred to as the content database. Every SharePoint web application has one or more content database defined in the web application settings. If only one content database is registered, then all site collections created in the web application will go into that same content database. If more than one database is defined in the web app, SharePoint will automatically place the newly created site collection in a content database – a decision based primarily on which of the registered content databases has the biggest difference between the number of site collections currently in the database, versus the configured maximum number of site collections allowed in the database. Unfortunately, this native process of locating site collections into databases has two big problems for many organizations. First, it lacks the ability to define a maximum size that a given content database can grow. Large content databases can present organizations with many potential problems – they take longer to back up and restore, they take longer to update during a SharePoint version upgrade, and, by putting many site collections into a single database, lack of access to the database (caused by maintenance or failure) means that large scopes of users are unable to access their site collections. Smaller content databases are often preferred because they solve the problems above – yet, natively, SharePoint only looks at the number of site collections when making a decision about where to place the next site collection, not the size of the databases. The second potential issue with SharePoint’s native content database management capabilities is lack of flexibility – either you tell SharePoint which content database to use when you create the site collection or you let SharePoint put the site collection where it wants. There is no capacity to ensure that sites of a particular type will always exist in a particular database (this has benefits if you want to define your backup Service Level Agreements by site type or if you want to make sure that all of a department’s sites are migrated to a new SharePoint version at once) unless you choose to do so for every individual site collection created. As is often the case, the lack of tooling in SharePoint to allow administrators to address these concerns means that policies around maximum database size and site collection placement require inefficient, manual efforts to enforce. Administrators have to be deliberate when creating new site collections and also need to closely monitor the size of ever-growing databases to ensure compliance with their defined policies. The Solution: Governance Automation Content Database Policies In Governance Automation SP 5, we are introducing the Content Database Policy as a way to automate the placement and maximum size of your SharePoint content databases. Content database policies will not only ensure that size and placement requirements are met, but they also allow for the automatic creation of new content databases as needed to ensure the databases stay in compliance with your sizing requirements as new site collections are created. [caption id="attachment_3573" align="alignnone" width="629"] Content Database Policy settings in DocAve Governance Automation.[/caption] These new policies are fairly easy to understand, yet extraordinarily powerful. A Content Database policy has a few simple elements:

• Do you want to set a maximum size for the content database?
• Do you want to set a maximum density (e.g. number of site collections) for the database?
• How do you want to name the content databases that are created as a result of this policy? (This allows you to easily identify groups of databases that belong together for backup and upgrade purposes.)

The ability to set a maximum content database size is a powerful capability that assesses content databases not based on their current size, but rather on potential size. Here is an example: Let’s say my policy is that no content database should be larger than 200GB. I already have 10 site collections in the database that total 150 gigabytes (GB) and now I need to create another. If I looked just at the actual size of the database, I would probably decide that my new site collection (which will have a 50 GB quota) could be placed within this database and not risk violating my stated database sizing policy. But in reality, those 10 existing site collections (which may each have a 50 GB quota of their own) will likely continue to grow and, before you know it, I could be well beyond my 200 GB policy limit for the database. From this point, I would have no choice but to start moving site collections to new content databases to bring the database back into compliance with my policy. Moving the site collections will require extra time and either some PowerShell knowledge or a tool like DocAve Administrator. By basing the placement of a site collection into a database on the potential size of the site collections (that is, looking not at the current size of the existing site collections, but rather on the maximum quota size of the existing and new site collections), we ensure that the content database will never grow beyond the stated maximum because we have planned for the long term. This means less moving of site collections to new content databases and less monitoring of content database sizes as site collections grow because Governance Automation is managing the whole process. When new content databases are required because a site collection is being created that would exceed the stated policy thresholds, Governance Automation simply creates the new database and names it appropriately during the automated execution process. Governance Automation even automates the process for when a site collection quota increase is requested and approved. If the quota increase causes the potential size of a content database to increase beyond the threshold stated in the policy, Governance Automation will automatically create a task for the Content Database Policy contact advising them to move the site collection using DocAve Administrator, and will also automatically create a new database for the site collection to be moved. But what if an organization has different sizing policies for different types of site collections? Or what if the organization wants to have different “groupings” of content databases for different business units? The way we built the Content Database Policy into Governance Automation SP5 allows an organization to create as many content database policies as they require. That means each can have different thresholds, administrative contacts, and naming schemes. The decision about which Content Database Policy will be invoked during a new site collection request in Governance Automation is based on the Site Collection Policy that is applied to the service that the user has requested. So an administrator can advertise or guide users to the “create site collection service” that has an appropriately mapped Content Database Policy. [caption id="attachment_3574" align="alignnone" width="668"] Mapping a Content Database Policy to a Site Collection Policy in DocAve Governance Automation.[/caption] Governance Automation’s purpose is to automate the enforcement of defined governance policies, reducing the risk of human error and maximizing administrative efficiency. As you can see, this concept is embodied by the new Content Database Policies in Governance Automation SP 5. We have taken a stated risk – content databases that are too big – and created a fully automated and managed process for ensuring that the policies formulated to mitigate that risk can be efficiently and proactively enforced. I hope you have enjoyed this blog series on some of the most exciting new features of Governance Automation SP5. There are many more new features and enhancements in this release, so I encourage you to check out the release notes and user guide to learn more. Additionally, please be sure to visit our Governance Automation product page for more information as well as a 30 day free trial of the product.