I’ve recently been reviewing our SharePoint Governance Plan and thought one good way to identify whether we have covered everything was to do a brain dump in the form of a mind map.
It’s really important for your company to have a governance plan to ensure that your SharePoint implementation doesn’t grow arms and legs. The plan should basically be a set of guidelines/rules and processes for effectively managing your SharePoint environment. There’s no single right answer to a governance plan. You can’t just download a document from the web and say “here’s our governance plan”. Every company’s plan will be different. The following mind map is my brain splurge of some of the things you should consider when implementing your SharePoint Governance Plan (and it was all done on the iPod Touch using an application called iBlueSky).
You can download it in full size here and in PDF format here
Tweet This Post
I’ve finally migrated to my new blog and it happened with no downtime (I won’t start talking about SharePoint upgrades and maintenance windows!). All links and feed subscriptions should be maintained. The blog is now also optimised for the iPhone and iPod Touch but you can switch to the normal view if you like.
Hopefully, I’ll follow up with a meaty post soon to celebrate the re-launch!. SharePoint Governance maybe…
Tweet This Post
After three blog posts I’ve realised that I don’t like Blogger. It’s too restrictive and most of the templates stand out like a sore thumb. I’ve had a bit of a play with Wordpress and it knocks Blogger for six (or out of the park for friends over the pond). The dashboard is much nicer with more options and the plugins seem far better. I probably should have done this evaluation before product selection (sound familiar?). Practise what you preach!
As a result, I’ve decided to move to a hosted Wordpress blog. Hopefully, this will be a fairly smooth transition. The hundreds (!) of subscribers to my feed should be unaffected since Feedburner will handle this when I switch. Fingers crossed….
Tweet This Post
So, you want to install the Enterprise version of SharePoint so that you have the ability to turn on Enterprise features for sites whose users have purchased Enterprise CALs but only purchase Standard CALs for the everyone else (hence saving money). This is easy to manage, right? WRONG!
It would seem logical for there to be an “Enterprise Users” group and for SharePoint to authorise the use of Enterprise Features only to members of that group. Unfortunately, the product doesn’t offer that facility. Basically, SharePoint trusts that you have the processes in place to manage a mixed mode farm – it’s down to administrators to ensure that users only access features they are licensed for. This is extremely difficult especially considering that site owners have the ability to activate Enterprise Features on their sites.
So what are the alternatives? There are two simple ones:-
- Purchase the Enterprise CAL for all users
- Implement separate Enterprise and Standard farms
But that’s throwing away money!
There are some options and things to consider if you really need to run Enterprise and Standard sites on the same farm although you probably need to weigh up whether it’s worth the effort.
- Restrict access to Enterprise enabled sites by creating Enterprise sites and Standard sites in different web applications and using the “Deny All” web application policy permission. You can set up a “Standard Users” AD group and add that group to the Enterprise Features web application policy with the deny all permission. You can then add all Standard CAL users to that group and remove anybody who has purchased the Enterprise CAL thus only allowing Enterprise users access to the Enterprise web app.
- This doesn’t solve the fact that site owners of sites under the Standard Features web application can enable Enterprise Features. Therefore, you really need to write some custom code to report on sites which have Enterprise Features enabled and take steps to ensure they get deactivated.
- Enterprise Features need to be deactivated at 3 levels – Web Application, Site Collection and Site. Deactivating “Office SharePoint Server Enterprise Web application features” doesn’t deactivate all Enterprise Features at Site Collection and Site level. Similarly, deactivating “Office SharePoint Server Enterprise Site Collection features” doesn’t deactivate all Enterprise Features at Site level. In other words, you need to deactivate Enterprise features at all levels.
I’m looking into other options to manage this but would welcome any comments or suggestions from anyone out there who has experienced this scenario. I’ll probably post again on the subject after further investigation.
Tweet This Post
I’m sure there have been lots of posts about applying updates, hotfixes and service packs to your MOSS 2007 farm but I thought it was worth sharing my thoughts since I’ve recently been updating our patching process following a config DB corruption during the SP1 upgrade. The cause is unknown but was most likely due to the complexity and lack of best practise recommendations at the time. There’s a great podcast where J D Wade talks about this at http://www.mossgonewild.com/ (episode 4). There were a couple of tasks that I’ve added to my documentation after listening to that show. Here are the steps I believe you should follow…
- There will be an outage since it’s important that no content updates are made during the upgrade. Communicate this and agree outage with stakeholders. There are options to provide a read only farm but that’s not covered here. Also, it is possible to reduce the outage by using additional farms to upgrade the content databases in parallel (again, not covered here).
- Download the relevant hotfixes or upgrades – see Deploy software updates for Office SharePoint Server 2007.
- Test the process below in a pre-production environment.
- Make sure you have your farm configuration documented in case you wipe out the config database during the upgrade. I’m talking from experience here – during the SP1 upgrade our config DB became corrupt and, to cut a long story short, we ended up in a DR scenario (albeit on a pilot system). We had to recreate the farm, apply all of the config and reconnect the content databases to the new farm. Although we had a backup of the configuration DB, it is not supported to restore it to an environment where updates have been applied (i.e. SP1 in our case). See Restore a farm using SQL Server tools and Restore a farm after a configuration database problem.
- Ensure you have adequate disk space for the update logs which can grow quite large.
- Rename update log so that a new log is created specific to this upgrade.
- Run a backup of the farm so that you have the ability to restore data if anything goes wrong. The reason for this is because it’s not possible to uninstall SharePoint updates since database changes can’t be backed out. If possible, validate that the backup has been successful.
- Backup any out-of-the-box files that have been customised. Whilst it’s not supported it’s sometimes necessary to do this. Click here for more information.
- Run the orphan repair tool since the upgrade can fail if it finds orphans. See KB923904.
- Defragment the SQL databases since this can speed up the upgrade. See KB943345.
- Check that there aren’t any timer jobs running.
- Disable AV software so that it doesn’t prevent the upgrade.
- We’re now actually into the upgrade steps! Outage starts here.
- Take the servers out of the load balancer and/or stop the WWW service on the web servers.
- Detach the content databases from the web applications (stsadm.exe -o deletecontentdb). It’s best to build a batch file to do this, particularly if you have a large number of databases. You can use stsadm –o enumcontentdbs to get the details of the databases to build the batch file. This step is not vital but potentially improves the upgrade time when you attach the databases as opposed to upgrading them via psconfig.
- Run the install executable on the first server in the farm. This should be run as the the farm account. WSS upgrades should be run before the MOSS upgrades. Don’t run psconfig until all of the servers in the farm have had the binary installs (to ensure that all server versions are in sync). Once this is done you can continue to run psconfig one server at a time (this should be quick if you’ve detached the content DBs in the previous step). You can keep an eye on the update log to ensure there are no errors and check the build version after each install (check Microsoft.sharepoint.portal.dll).
- Attach the content databases (stsadm.exe -o addcontentdb). This needs to be done one database at a time. The databases will be upgraded automatically when they are re-attached.
- Now you’re ready to bring the farm back into service so add the servers back to the load balancer and/or start the WWW service and enable the AV software.
- A full crawl may need to run, especially if you detached the content databases.
- Finally, you’ll need to run a full backup since the all previous backups will be at the earlier version.
Just for reference the equivalent process in Domino is as follows:-
- Take the servers out of the load balancer
- Run the install
- Bring the servers back into the load balancer
- Walk away!
Hope that’s useful
Tweet This Post
Hi. Thanks for visiting. My name is Paul Bednall. Hope you like the name of my blog – it took me ages to think up Bedblog! More information about me to follow but here’s a brief intro…
I’m 34 years old and married with 2 kids. I work for a UK company as a Senior Infrastructure Developer and Team Leader. I started my career as an application developer and moved into infrastructure development after 3 years of coding. I am a Lotus Domino expert (and fan) but was converted to the world of Sharepoint a couple of years ago. It’s very interesting to have a view of both products (maybe one for a later post). I lead a team of infrastructure developers delivering Sharepoint projects but also provide technical support, consultancy and strategy for all things Sharepoint.
I’m hoping to use this blog to post some information and tips based on real world experience of the beast that is Sharepoint. Watch this space…
Tweet This Post
