Auditing SharePoint is one of the indispensable processes before deploying a new solution on the existing farm since SharePoint is going to be more critical to the corporate business. There are many reasons why auditing before SharePoint deployment is really important:
- Identifying things are properly configured in SharePoint farm
- Identifying the impaction of hardware and software on SharePoint performance
- Measuring security in several different aspects
- Infrastructure involved to operate SharePoint
- Customization maintenance
The wheel describes 5 parts you need to look at when conducting a SharePoint audit.
This includes network topology, logical and physical architecture, and server farm details of the SharePoint farm you want to do an audit in. With network topology, hardware and network devices including firewall, router, switch or so on need to be documented. You don’t have to necessarily perform an assessment on network device, but the least is to list down which network devices involved to be functioning for SharePoint.
With more specific to SharePoint farm, drawing a whole SharePoint farm is ideal. See the following sample:
We will then documents physical servers or virtual machines involved in each farm. Each needs to have the following data:
- Server Name
- Operating System
- Memory of RAM
- System Disk
- Data Disk
- Virtualized (Yes/No)
That’s all about physical topology. Now we need to document logical topology for current SharePoint farm. The following scopes you should look at:
- Service (with server services are running relatively)
- Service application (with application pool account and service application database relatively)
- Web Application (Zone, Port, Host Header, Public URL)
- Site Collection (Web Application, URL, Template, Content Database)
- Content Database (Specific name, Description, Backup/Recovery Option)
See the following sample for Service Application scope.
Security is a very huge topic and it can’t be done over a night. However, when it comes to SharePoint audit, security needs to be taken into account. You don’t have to be a professional security auditor or someone who is familiar with penetration testing.
What need to be documented basically from the security perspective are as follows:
- User Account
- Operating system with security patches/hotfix (use Microsoft Baseline Security Analyzer)
- Security hardware (mapping to infrastructure network devices)
- Custom security policy
When having an overall of security template your client has made, you can ask them accurately what you need for your development.
Farm configuration includes important information for your SharePoint deployment. See the following sample:
SharePoint has many out-of-the-box (OOTB) features that empower end-user to build business solutions without having to write code. This statement is correct. However, in many cases, custom solutions are deployed to fit specific needs. That said, every of them need to be documented with the following data:
- Solution scope: farm, web application, site collection, sandboxed
- Interaction: solution may interact with external file server, or ASP.NET-based application.
- Assemblies: solution ID, assembly location, deployment target
- Features: feature ID, scope, purpose…etc.
- Deployment guidance: via PowerShell/STSADM, Central Administration
These above often get documented in SharePoint Custom Solution Documentation. If not, you would have to ask internal development team or use 3rd party tool to capture information. I strongly recommend SPCAF (SharePoint Code Analysis Framework) tool (http://www.spcaf.com/features/)
There are several common types performance testing: performance test, load test, stress test, and capacity test. Each of them has different benefits and challenges. I strongly suggest following Performance Testing Guidance from Microsoft patterns & practices written by Microsoft (http://msdn.microsoft.com/en-us/library/bb924375.aspx)
Taking a look at the following helpful tool:
- Microsoft Visual Round Trip Analyzer
- Visual Studio Test
- Dashboard Designer
- Forefront Identity Manager (used to see the duration of profile synchronization)
Report & Recommendation
There are lots of things in SharePoint you would have to count in or may be asked by the client. The reality is that you don’t really have enough time to cover all. So before conducting SharePoint audit, you need to identify and ask the client what need to be audited. For example, if you are to configure high availability solution, look at infrastructure scope first.
In terms of report, it should at least includes the following:
- Priority (Critical, High, Medium, Low)
- Recommendation (optional)