| Everyday, I work with customers who are attempting to maintain their SharePoint environment so that the farm can handle more users, more requests or additional functionality. There are many ways to approach the prospect of maintaining SharePoint in a way that you can build the platform and handle all of your users’ requirements. Let’s start the overview reviewing the components that are apart of SharePoint. There are many components and sub-components that need to be understood before you can approach the entire package. Here are the main components: - SQL Server (Database)
- Network
- Active Directory (Authentication and Authorization)
- Managed Code (Solutions)
- Software maintenance (Patching)
- SharePoint (either Windows SharePoint Services or Microsoft SharePoint Server 2010)
With all these components, the many sub-components require attention on a continuous basis and are the building blocks that the platform maintains it’s scalability and performance. The first block is the prescribed “Software and Hardware Boundaries” prescribed by Microsoft. Following these guidelines will not only allow you to install the software, but allow you to create multiple lifecycles (development, test, QA and pre-production). Having the appropriate memory and CPU specifications or ensuring that you create the amount of web applications that is known to be supported for the product is very important. Additionally, separating the different roles (Web Front End, Search, Excel Services, etc.) based on the number of users and server load will enhance the user experience. Separating web applications or maintaining site collections with appropriate security is critical to your business’ adoption. In the next articles, we will point out specific ways that you can maintain and then increase your Farm’s health and show how these methods will proactively resolve problems and reduce support requirements. These methods will help either in keep your current SharePoint servers healthy or help prepare for future upgrades. Next: When and how should I evaluate my environment? |
| Entering Central Administration (CA) can be a daunting experience for Administrators whom are looking at the area for the first time or have a little experience, or become too comfortable and maybe overlook the issues that might impact their SharePoint server’s health. Let look at the basic process of understanding what we can do to resolve the problems when they pop-up in our environment. Here’s the screen, we all have seen it before and might know why it’s there, or might not and do not know how to fix problems. There are a couple of banners colors that will display; Red or Yellow. Red is bad, yellow might be bad and still need to be viewed (and fixed) quickly. In most cases, the red warnings are rules that impact direct health or security of for the production environment. When you seen the SP Health Analyzer banner with this type of information, click the “View these issues” link to see what’s going on. 
In this case, I have a test environment on an external drive that I allotted only 60GB (not in compliance with Microsoft’s Hardware and Software Boundaries) and now I’m being told that my drives are running out of space (see below). 
From this message, I can see the category (Availability), which servers are failing, which service told SharePoint about the issue and when it was first reported. Rules within Health Analyzer There are multiple categories of rules that you can use or disable, control the schedule or allow the process to automatically repair. It’s important to understand what they do and how they can impact the health of your SharePoint environment. Running out of space is something that SharePoint cannot fix itself, so you’ll have to develop a plan of attack to ensure these architectural items are addressed. The rules defined in SharePoint cover a broad range and in the following cases identify security and performance issues that can plague various use cases. Review them and understand what the rules are evaluating to keep your environment strong. 
Editing a Health Analyzer Rule Definition Once you receive this screen, there a couple ways to approach the way you resolve the identified issues. Let’s talk about the fields in the screens and see how we can modify the rules to our needs. Title: Text that will be shown when the rule is implemented.
Scope: This can be “All Servers” or “Any Servers”, as the rule shows, it will try all servers with a specific server or any server on the first available server.
Schedule: Choices are “Hourly”, “Daily”, “Weekly”, “Monthly” or “OnDemandOnly”.
Enabled: This rule is a “Yes” or “No” option, and is the ideal way to manage rules. I would recommend against explicitly deleting rules.
Repair Automatically: SharePoint will attempt to fix the issue automatically if this is selected. My recommendation is to deselect this to ensure you understand what is being done to fix the problem.
Version: Version number. 
In the next article, we’ll talk about creating your own rule so that you or your team will be alerted if your environment is hitting a rule that you put in place to monitor a best practice or standard you have in your farm. |
| New to SharePoint 2010 is the introduction of a Web Analytics tool that can be used to capture user visits, top pages, top number of referrers, number of search queries and number of site collections. It’s a very valuable visual representation that can be used to prove the value of SharePoint and increase it’s usability by reviewing user data and then making changes to your Farm based on that information. The service application separates web application data so that an administrator can segment the numbers to see each web application and how it is performing. Providing this overview will give you a basic understanding of what the service application is about, but it does not provide you an understanding of the moving parts that drive the processing and output of the new service. There are a couple of things to keep an eye on when you start configuring. The first is that the account you provide to the service application will become a database owner of the “Processing” role for the Reporting and Staging databases created during the implementation. Example of the “Processing” database role: 
This role exists in both the Staging and Reporting database and the user which owns the processing of analytics requires this access. I have not found any guidance that says that there can be permission levels to allow the processing happen. Decrementing the permission levels to another role has not been recommended as guidance at this time. 
Once this role has been applied, there are a variety of timer jobs what control when usage data is collected, but retrieving this data is not possible if without a user being in the “Processing” role and having dbo permission in that role. If you think you’ve configured everything correctly and still are not getting information to the Web Analytics service application, check your Processing role and see which user is in there and which role it is assigned. Configure Web Analytics service application [MSDN] |
| In Windows Server 2008, Windows Files profiles have a default “Firewall state” as “On”, which is a recommended best practice if you use the Microsoft product to manage Internet traffic. If you manage your firewall differently, then having these settings left on can cause you issues. If you are creating a demo server, then keep the firewall state to “on” for security reasons. I found this as an issue where a user could not  access a SharePoint site on the desktop, but could on the SharePoint server. Nothing could be found in the ULS, HTTPERR or IIS logs to show that the requests were not being allowed in, but when various Fiddler and NETMON traces were completed, there was strange results. In production when these settings are in place, then user requests are bounced based on the policy set for the Domain, Private and Public profile. This is a change in Windows Server 2008 and most administrators are comfortable with the fact that the service is off when they push the server to production. Checking these settings is as easy as Start > Search for “Windows Firewall with Advance Security”, right click the top node and then click “Properties” and you will get the following screen. After you change the “Firewall state”, click “OK” and the changes will take effect then. On a side note, when you work with your network or server administrators to resolve these types of issues, ask to see these defaults because shutting off the service will not necessarily resolve this issue. Usually, this type of situation that I’ve explained is usually caused by the “Loopback Adapter”, but checking your firewall (and a lot of testing in different scenarios) will save you troubleshooting time and ensure your servers are secure for accepting requests. |
| Recently, I was asked exactly how the Site Confirmation and Deletion feature works in SharePoint? Does the timer restart when a user visits the site? Does the feature look at the some field and then reset the value in a service? It was a simple question that made me think about how the process worked from an Administrator point-of-view. The simple answer is that once a user adds content to a site, a field in a content database is updated and then when a timer job is run, it will review that field and notify site owners appropriately to ensure that they are notified that their site is on “the chopping block”. Based on your configuration, it will notify you after 90 days (by default) of site collection creation or confirmed use. You can change the amount of notifications sent or you can automatically delete the site collection if use is not confirmed after 28 notices. To access this feature, go to Central Administration > Site Collections > Site Use Confirm and Deletion option. 
Some administrators or business users do not like to use this feature, but you can see that you have to make a very big effort to not confirm your site’s usage before it magically vanish. Also, this can provide a great deal of efficiency for the removal of sites that are just not used anymore. That’s the Executive Summary of how it works, let look at the details. There are three database fields that play a part in the process and they are: - “DeadWebNotifyCount”
- “CertificationDate”
- “LastContentChange”
DeadWebNotifyCount and CertificationDate are used to keep track of the date that a site owner verifies the use of the site. These fields are reset when the user verifies usage through the email sent. Do not modify the values in the SharePoint database, as this is not supported by Microsoft. The LastContentChange field keeps record of the last time a document or list item (or any content) changes on the site. This feature does not use the last time a user visited the site, only when content changes. This feature is misunderstood, but a very valuable tool to manage storage space and helps provide governance within your environment, use it or not, but keeping sites that are timely and relevant is always important and having a tool to help administrator’s is a plus. |
| If you are trying to control how certain users or groups can manipulate objects within your Web Application, creating custom permission levels are the way to do it. There a couple of different ways to accomplish this, but the most flexible is to create a custom Permission Policy and in this case, I am limiting a specific user and a security group from creating subsites. Creating subsites impacts the obvious new site creation on a collaboration site, but also can limit creating subsites under a My site, a great governance tool if you have limited space or need to apply other rules to the process. Let’s start the process. First, go to Central Administration, then Application Management > Web Applications > Manage Web Applications. Below is a list of my Web Applications that I can apply to my policy. Select “User Policy” for the appropriate Web App (I selected “SharePoint – 80”). 
Before I start, the default users and permissions are listed below, but I want to add my own permission so that I can limit the creation of sub-sites for a specific user (and security group). I select the “Permission Policy” button, then I get this screen to create my own permission policy. Click “Add Permission Policy Level” to start the process. 
The first screen I see to build my permission level asks me to create a Name and Description. The “Site Collection Administrator” and “Site Collection Auditor” provides a method to elevate permissions and let the user or group identified in this policy. As the creator of the permission level, there’s a granular control over what level of access I will let this group have in this web application. 
After I select “Grant All”, I can go back in and change individual permissions. In this case, I have denied the ability to create subsites. This is a helpful permission level if you have users that constantly delete sites. 
After I’ve finished, my permission level is available to be utilized in my web application. 
When I finish, I am going back to click “Add Users”… 
This screen will pop-up and now you can select a zone to restrict. In this case, I’m going to restrict all zones within this web application. 
Then select a user (DEMO\price) and a Security Group (DEMO\SharePoint Admins) and apply the “Deny Site Creation” permission level. Notice that I could apply the “Account operates as System” bit and that will record actions as a system account versus an individual account. 
I finish this and now I am ready to test by logging in a “DEMO\price” and then try to create a site by clicking “Site Actions”. If you notice the option is trimmed so that the user does not see the option. 
I had to test this a couple times to make sure the permission level was acting as expected, but it works as advertised and now I can apply different policies for Lists, Libraries, Site Management, Personal View or Alert actions. That’s pretty much it and I like this way to manage my policies instead of applying them across my entire web application because I can go back in and add another user or uncheck a box, or create a new permission level that only applies to another set of users. |
|
|
|
|
|
|
 |
The SharePoint Blog is a community resource which focuses on Architecture, Development, Administration and Best Practices relating to Microsoft's wildly-popular product.
The opinions and views expressed by the author are his alone and not of my employer (Microsoft Corporation). Those providing comments are theirs alone, and do not reflect – to any extent – the views of this website, or The SharePoint Blog. |
|
|
|
|
|