Over the past year, our company swam deep in the pools of MOSS 2007, fully expecting it to be a functional replacement to our aging, piecemealed, pre-.NET .ASP intranet solution.  On the plate for our alternatives were either a complete re-write in .NET, or using MOSS 2007. 

After reviewing the materials provided by the Microsoft propaganda machine and going through an evaluation period, we were excited and convinced that MOSS was going to be the way to go.  The feature set was very promising, and the community support seemed to imply that it could do almost anything we wanted, with minor customization or a bit of extensible coding.

We bit the bullet, convinced the BOD to pony up enough funds to get licenses and necessary hardware, as well as some training for our developers to start climbing the learning curve.  Two months after purchase, we’re shelving MOSS and going back to a .NET re-write.  Why?

Security

Our company might be unique in how we structure our users.  We have a dual-layer of roles, rights, and responsibilities that SharePoint cannot seem to handle with any level of success.  There is a typical hierarchy of corporate roles, departments, etc. that most companies would have, but we also have a secondary layer that throws a wrench into the gearbox – individual “projects” that could almost be considered subsidiary companies. 

Our clients are such that each “project” is its own contract, bound on paper to provide its OWN hierarchy of corporate resources, roles, etc.  In some cases these roles overlap corporate logic, in others they do not.  Employee A might have certain general abilities on the corporate level (like seeing other employee’s data), but within Project X, that same employee might not be able to see anything more than Employee B, assuming they even have an ability to access Project X to begin with.

SharePoint has its groups, and has its audiences, and has its permission levels, but after strenuous research, it seems the implementation of “our” security model within a SharePoint environment would be daunting at best, as well as a maintenance nightmare.   SharePoint groups aren’t nestable – you apparently cannot have a group within a group.  SharePoint audiences have been widely stated to not be used as a security model.

In the end we basically determined that we would need groups to cover our corporate roles, and then we would need individual groups for each “project” – and each role within that project.  Which would mean 500+ groups – either SharePoint groups or Active Directory groups – to cover all of the variances that our business logic demands.

Applying Security

Assuming that we could get the structure down, there were two ways to apply that security within SharePoint (or really any system) – at item creation, or at the time of viewing.  SharePoint seems to be amenable to both methods – but both methods also had their drawbacks in some fashion or another.  Applying permissions at time of item creation (defining which set of users or groups that had permission to see the new document, calendar entry, etc) is fine until those roles change. 

What happens when something changes that would affect those applied permissions?  Would we have to iterate through an indefinite number of lists and libraries to re-apply permissions based on those changes? 

We thought that to be the case, so view-based filtering seemed more logical, more server-friendly, and more real-time – it’s how we handle it in our current intranet. 

Would SharePoint allow us to write custom events to filter out stuff at time of presentation based upon whether the viewer was part of ProjectXRoleY group but not part of CorporateRole234 group? 

Could we stop the display of certain links or buttons (a modify button perhaps, or a delete function) based on the same dual-layer of permission possibilities?  From what we read, this was not easily possible.

Maintenance

Along with the 500+ groups comes with it maintenance of those groups.  Out of the box, there’s no way to see what groups a SharePoint user belongs to.  There are third-party solutions to this, or we could write our own, so that’s really minor.   What isn’t minor is when a new employee comes on board, they might have to be added to 50 groups to cover their roles in the company – something our current intranet handles with a couple of drop-down boxes and an array of well-worded checkboxes.  In SharePoint, they would have to be manually added to the groups.  Ouch.

Development Headaches

SharePoint, despite all of the Microsoft recommendations for having multiple “farms” for development, staging, and production – provides no easy way to synchronize data between them, especially in a team development environment.  That’s a bold statement that I expect to get a lot of flack on, but let’s step back and look at this without the rose-colored glasses.

In a standard development environment, your team of developers create, break, troubleshoot and design on a set of servers, then deploy working, tested code to a secondary environment for further testing before finally being deployed to production.

A lot(!) of SharePoint functionality can be handled through the GUI, making it what some would call user-friendly.  However, there is no easy way to transport those changes from one farm to another.  Say you wanted to add a new column to a list and you do it via the GUI.  Life is good in that farm, but to get that one little change over to the next farm you… could export the entire site and then import it, crossing your fingers that it will import properly.    You could write a custom export handler that only exports that list.. and, again, hope that it will import properly.  You could simply go to the GUI of the next farm and create it as you did in development – but that negates the testing process as human error comes into play.

Or you could add the column from code, deploy that code as a feature, or, more widely recommended, package it as a solution and deploy the solution package – both of which involves tedious work with XML files and hoping that you play nice with SharePoint’s API so it will install properly.

STSADM (which is another subject altogether as to why a product in 2007 would rely so heavily on a command prompt) is extensible to allow for custom commands – and there has been some wonderful work in this regard (Greg Lapointe should be knighted), but.. it cannot be coded to work with multiple farms.  We thought this would have been our savior – write a custom event to copy, say, the above new column example from Development to Testing – but alas, this is not the case.  Greg indicated that the SPWeb and SPSite API cannot cross farm lines, thus rending STSADM incapable of performing this functionality.  Enjoy your packaging.

Going in reverse is an even bigger headache.  If your users report a fun new error with some new data they entered, reputable shops would work on a copy of the production data as part of the break/fix troubleshooting process.  However, the only way to go in reverse from production to a testing environment seems to be to make a backup of the site in question, and restore it to a dummy farm somewhere.  This process could literally take hours.  Some problems cannot wait that long, which would mean troubleshooting in production or a change in SLA – both of which are Bad Things™.

General What-Were-They-Thinkings

No referential integrity between lists?  This was a major pill for us to swallow – that SharePoint would allow for list linking via lookup columns but not reinforce any parent/child data relationships between those lists.  Delete an important list and suddenly 30 others have NULL for data.  Oops?  Yes, this can be worked-around through custom event handlers that check for references, but, really, why should we have to bear the responsibility for fixing this glaring error.

Document storage in the content database?  I know this is an issue that divides certain development communities – storing file data within a database, but I happen to be on the side that files should stay on the… file system.  Wacky idea, I know, but I don’t like thinking that someone uploading a 50 meg VISIO file, then making 3 revisions to it (because versioning IS a good thing), and having that process bloat my SQL database by 200 megabytes.  That’s 200 megabytes longer that I have to wait in a DR scenario where I have to restore this database.  Exacerbate that by our 50+ “projects” that started this mess to begin with, and our poor little SQL database is going to be gigantic.

Yes, storing them on the file system would still make recovery take just as long – at least, FULL recovery.  Users might not need some/most document libraries in order for the company to be productive.  Critical areas could be brought online first, and then the less-important document areas could be brought online AFTER the floodwaters have started to recede, rather than making everyone wait while the entire city is rebuilt before they can get any work done at all.

So to me, storing documents in the database.. bad juju.

Overall

This was not knee-jerk for us – we had a team of six full time on this issue for two solid months – attending conferences, webinars, and scouring for every nugget of wisdom we could find within the SharePoint community.  We spoke to a few MVP experts that pointed us in various directions, but with no definitive eureka-moments that provided enough “ok we can do this” without the looming overshadows of “ok how do we maintain this” or “does the company need to change its business logic to make this work?”  Regarding the latter, we feel, as does our executive level, that the company’s policies  shouldn’t have to conform to the technology – the technology should be adaptive to the policies.

There were just too many minuses for us to proceed with MOSS as a viable solution, at least in its present state.  Nothing about SP1 suggests that our issues were addressed, so we presume we are largely unique in our requirements and hopes for their product.  Perhaps the next iteration of MOSS will provide a beefier security model and some more intelligent design on the part of Microsoft, especially if they intend this to be an enterprise-level solution.

I’ve no doubt that SharePoint is successful for most companies – we are keeping it on the back burner in case any of our “projects” could benefit from using it within the scope that it is usable.  Unfortunately, overall, it’s not successful for THIS company.

For now, it’s back to C#.NET ASPX solution, a clean drawing board, and probably 6 less servers.

I welcome constructive feedback – but please keep your flames to yourself.

Johan