In my fourth blog post about the SharePoint 2010 Ignite Training, I cover the day’s material on IT Pro Customisation and Upgrades.
These two subject areas are the bread and butter of SharePoint implementations. Ideally every customer should want to impose a bit of themselves on SharePoint, from the arrangement of sites, lists, document libraries etc to fit their business to how the layout looks and how it may reflect their own corporate branding. MOSS 2007 could be altered beyond recognition and so can SharePoint 2010, but a central aim of the product is to be able to do as much as possible without resorting to coding.
The rest of the day was devoted to upgrades – in my experience a truly greenfield site is unusual, whether this is because there is already an intranet or internet presence, or more usually because someone already understands the benefits of SharePoint and would like to capitalise on the improvements in SharePoint 2010.
IT Pro Customization (non-code)
The slightly long and unwieldy full title of “IT Pro Customizations of SharePoint (non-code customization)” was a subject area intended to show how far the product can be tailored without opening up Visual Studio 2010 and delving into the object model and .net code. My background is in development so I’m not scared of firing up Visual Studio and the extensions for WSS, but I do understand that the great potential for solving problems in code also limits the types of person in a team who can do it but also the time and risk involved in adding a development project to your overall programme.
The main tool for this job is SharePoint Designer 2010 which has grown a number of new features, as well as working better with the security model in SharePoint 2010. For one thing, the whole process of setting permissions for the main activities of SharePoint Designer are now clearer in the User Interface for the server product. And SharePoint Designer 2010 now abstracts the file system for the user so that they deal solely with objects. This is a great improvement in not only keeping the nastiness of a web file system away from the user but also focusses them on the structure imposed by SharePoint and how they should work with that instead.
SharePoint Designer 2010 comes with neater functionality to work with sites in adding lists, amending columns etc, and the often demonstrated workflow functionality has been updated too. I had also heard about the new ability to use Visio for the creation of workflows and having had a shot I can see where it fits in to the process and how easy it would be to use. There is a new “Microsoft SharePoint Workflow” template in Visio 2010 which includes the Actions and Conditions that should be familiar from workflow design for MOSS 2007. The Visio template concentrates on the steps and the flow, and then the result is exported to file and imported to SharePoint designer for it to fill in the properties and so on needed for the actions to carry through. Whether this split between the tools will work in practice will have to wait and see, but from a brief look it keeps Visio simple without bogging down the various shapes with too many properties.
Customisation Management
This subject area gave more information on the hinted at Sandbox for solutions deployed to farms. Like previous sandbox concepts in the development world this gives a special area of increased isolation that trades off less available functionality for ease of deployment. I was a little surprised to see that ado.net was one of the things excluded from the sandbox, but on reflection the removal of this and other facilities is not as bad as it may seem. Using SharePoint as an application platform should channel our development approach down a certain line – just like previous development in the office applications has done. Each of these bring ease of deployment, but this has traditionally come with a limitation on what can be done. This way of managing solutions enforces a compromise between “IT Pros” managing the SharePoint servers and “Developers” doing things that cannot be done without code. Hopefully developers will be encouraged to write solutions that will run in a sandbox, and IT Pros will support this by allowing these to be deployed in a quicker way than a full solution.
One final point to make is that the impression I get from the level of support and scalability that is given to Sandboxed Solutions indicates that this is being proposed as a controlled production environment. It is not being pitched as a development or test area but as an isolated and heavily managed way of deploying solutions. Certainly in the information presented to us there was no discussion of bedding in or promoting a solution to being a full package, solutions are expected to operate during their entire lifetime within the sandbox.
Upgrade
Again an indication of the importance of this activity is that it was given a half day’s consideration. As with any production upgrade there is a lot of planning to go through and part of this has to be testing to prove the process and to get the clearest idea of what will have to happen when the real work happens.
A big part of the IT Pro exams that I have taken in MOSS 2007 and Windows SharePoint Services (WSS) 3.0 are devoted to conducting an upgrade from SharePoint 2003 to 2007 as it is a real world situation for those bringing MOSS 2007 into an organisation. Before that, though, there are prerequisites to consider to even consider the hurdle of an installation and upgrade. This is the first stage to have a hard think. As I have mentioned before SharePoint relies on x64 throughout the platform, and at time of writing needs 8Gb of RAM and a dual core processor. Although a number of sites have made the switch to 64 bit, some have not and suitable hardware will need to be found.
I will not go through the full list of prerequisites as this will move as SharePoint 2010 gets closer to RTM, but an important point is that SQL Server (2005 or 2008) has to be on a specific Service Pack together with separate Cumulative Updates. This is very important to think about if you share your SQL Server resource across applications.
Another point for those that are familiar with the upgrade from 2003 to 2007 is that the gradual upgrade method is not offered in 2010, so further planning is important in terms of managing downtime. A point in favour of 2010 is that the UI can be upgraded separately to the data and other parts so the impact on end-users can be directly managed.
Apart from repeating advice to plan properly and test an upgrade to spot any possible issues with the process, and to obtain some timings, the overall process of upgrading doesn’t strike me as that dissimilar to migrating a 2007 farm to new hardware. That said, the one place that things need to be watched out for are the changes to config handling and the switch away from Shared Service Providers. These changes mean that the sequence of upgrade is important to make sure that downstream dependent functions like Mysites work correctly. Again I would advise keeping track of technet and MSDN on Microsoft.
Conclusion
SharePoint 2010 rearranges the picture slightly in terms of customisation, and the tools of the Web UI, SharePoint Designer and Visual Studio have been rearranged slightly in terms of the capability they offer to each of their users. There is encouraging news in the area of solution deployment and management and this has been thought about properly. In terms of upgrading to SharePoint 2010, I am encouraged that so much testing has already taken place and with appropriate planning and testing an upgrade should be predictable, if not the easiest thing to do because it is a flexible application platform we are dealing with.