This post is the third of a series explaining how to audit your SharePoint farm.
- SharePoint health check (1): Auditing the SharePoint farm
- SharePoint health check (2): Extracting Customizations
- SharePoint health check (3): Auditing Customizations (this post)
Analyzing the Customizations
In the previous post we retrieved all code customizations with the help of a little PowerShell script. In order to analyze them,
- Go to your machine where SPCAF is installed (SPCAF does not require SharePoint or Visual Studio when analyzing in the client application).
- Start the SPCAF client application
- Navigate to the network share where you stored the extracted files
- Drop one, several or all of the customizations from your farm into the center of your application
Tip: Analyzing all customizations at once will most likely overwhelm you with the sheer amount of findings, so better only combine the ones that seem to belong together (eg. similar naming, similar source location) as they might have dependencies to each other. Analyze the all others separately.
- Click the advanced settings in the client and adjust which rules should be applied, e.g. by selecting an existing or your custom pre-configured analysis settings created with the settings editor.You can also select the different report type that should be created including HTML, DOCX, PDF, XML, CSV or DGML (for dependencies)
- Start the analysis and let SPCAF gather the information. This may take a while depending number, size and complexity of the solutions you are analysing.
- When the analysis is completed you will be presented an overview dashboard allowing you to navigate into the different results or download the generated report documents.
Reviewing the Results
SPCAF will highlight if and where there are problems and give guidance how they can be resolved.
Its reporting can be broken down into the five areas:
The code quality analysis validates the code against over 600 rules that vary by severity, the most serious being Critical Errors and Errors. This includes quality rules in categories like Correctness, Security, Best Practice, Localization, Memory Disposal, Performance, Deployment, Syntax, App Store Compatibility and many more.
Note: As it is common with SharePoint there is seldom only one truth. The validity of a many reported violations depend very much on your target environment, the allowed customizations, your internal coding policies and preferences.
The code metrics can be used to evaluate the complexity, maintainability and migratability of the solution packages and apps. It won’t give a list of easy to follow errors, but it gives a good summary of the structure of the solution helping you for example to calculate migration efforts.
The inventory provides a summary of the contents of the solution. By this you can create a standardized documentation which can be used as reference e.g. when resolving issues found in the ULS logs of the farm, or getting an overview in order to plan a migration to a new SharePoint version or the cloud.
The code migration assessment is a combination of the four analysis view described above, focussing entirely on giving you guidance how to migrate a full trust code solution to the SharePoint app model. It highlights potential road blocks which prevent a 1:1 migration and describes alternative ways to implement a similar functionality.
Seeing is believing so check out one of the sample reports:
Looking towards a future in the Cloud
Although there is no quick fix to a healthy stable SharePoint farm, using tools like SPCAF and SPDocKit can help start the process. As Microsoft moves ever more to the Cloud, and the new SharePoint ‘App model’ for custom code, understanding how current solutions are structured will become more and more important. We designed SPCAF to help people on this journey, and would love to hear your experiences in the comments below.