www.johntimney.com

A colleague of mine with a lame excuse for not blogging ever "I dont have time to blog regularly enough, but I thought this would be an interesting topic!" asked me to post something for him.  Given its related to one of those specialised sharepoint in the field type questions I had little choice but to post it here.  All credit to Brian, I am just the lacky on this one!

My Scenario: Distributed multiple users updating a single spreadsheet.  This works fine with a file system, as we can use Excel workbook sharing

Problem: I am experiencing rare SharePoint Disgruntlement, at losing a really neat Excel collaboration feature (when working on a file system) by collaborating in MOSS.

This is the official explanation.

http://support.microsoft.com/kb/888841

Its particularly disappointing given it would be a Google-beating collaboration feature!

Solutions:

In my view the traditional SharePoint approach, would be to import your Excel data into a SharePoint list and share it that way! Its a very valid option for some scenarios, but not this one.

Its only really valid if you dont have large numbers of rows and columns, dont need any particularly sophisticated processing, graphing, or Macros otherwise you will be importing and exporting all the time to/from your list.

And no, sadly Excel services doesnt come to the rescue as this MSDN list of Unsupported features in Excel services highlights http://msdn.microsoft.com/en-us/library/ms496823.aspx

The Real Requirement:

For me, Check-in/Check-out is actually about as sophisticated as the old mainframe Printer Flag resolution, where we used a physical paper flag to control who was printing to avoid mixing up pages. Its a crude control at best. I wonder, has this become the de-facto SharePoint solution because that is how Developers work with source code control?

If we all have permissions, e.g. are Site Collection Admins, who can check-in, check-out at will, take ownership of site collections if we wish, and can switch versioning off, then why cant we make Workbook sharing work like it does on a file share? You wouldnt think it was technologically that hard, Id welcome some education on this.

So, for future generations of SharePoint Im looking for the next level of collaborative flexibility. When appropriate, update control needs to be able to be applied with cell-level locking. Each client application can have its own definition of what constitutes a control-cell (my own, probably incorrect, term).

Im not asking for this feature just in Excel, but that would be a great start. Maybe I ought to get more involved in the next Beta programme?

Brian English

Footnote: Brian English is a Technology Strategy Consultant based in the North East of England

 

This was one of those strange ones I came across recently.  Should we be using Active/Passive, or should we go for an Active Active stack when deploying MOSS to a cluster?  In reality, I should be talking about Nodes her, not active passive, but for you old timers out there I'll stick to that where its easiest.

Guess what, there is no easy answer to this one!  There's a surprise - go ask a SAN engineer what they think and they'll likely say Active Active, gives you a scale out option!  However, digging deeper into this you ask a MOSS architect (which I did - a few very credible MVP's in this field in fact) and the answer is "why would you want to do that then?", usually accompanied by "thats not really a good idea! - or don't you have much budget spare!"

I have recently chosen an Active/Passive SQL Cluster as the configuration of choice for some rather large farms, mainly because I've seen an awful lot of MOSS deployments done succesfully to this and you typically stick with what you know works well, primarily because I have yet to see CPU throughput on the cluster merit a different choice.  But what about Active/Active. I now know of one large consulting company using a four Active/Active node to SAN for their own internal system, and MSFT allegedly have an A/A/A/P/P design for an internal instance, that must have took some planning, but two other very large consultancies (with large or massive farms) I know of have chosen Active/Passive and very common among small businesses is just virtualised large capacity Active alone. 

Most architects I've spoken to appear to be defaulting to Active/Passive and I have not seen a single best practice paper or book that states either choice is the better choice, or MOSS works better this way or that.  I do have some unresolved concerns for Active/Active however around MOSS in particular and the fact that Exchange historically was not recommended for deployment to Active Active sticks in my throat still!  Certainly with Exchange 2003 performance, availability, and scalability reasons, Active/Passive cluster configurations were a better option than Active/Active configurations and Active/Active is dropped for 2007. Ok, thats a different product set, I'll give you that one!  However, HP guidance on MOSS best practice doesn't appear to mention Active/Active anywhere.

http://h71019.www7.hp.com/ERC/downloads/4AA2-1456ENW.pdf

EMC virtual architecture testing was also carried out using Active/Passive, although the farm itself was spread across a Active/Active/Active virtual cluster in one test instance.

http://www.emc.com/collateral/hardware/technical-documentation/h4456-emc-vrtl-arch-ms-sharepoint-srvr-2007-ref-arch.pdf

This is not to say that either of these companies (both very credible in this space) would not choose to architect Active/Active in, its certainly do-able.  As a side note, most of the storage vendors are doing geo-replicated database solutions that ae worth looking at.

Scale out should be a convincing argument and it should be a significant a factor in your choice, but what if your Active\Passive cluster is appropriately scaled to start with and you do not expect performance issues?  Scale out then has no intrinsic value except perhaps to offer additional redundancy.  Is the default choice then to stick with Active/Passive because you can switch in the future to Active/Active should you need to grow differently. Of course there is a cost to this switch, so the lesson is to make sure your calculations on RPS (Request Per Second) can be met by Active/Passive, or indeed by Active/Active.  A big question is around planning, simply put the more nodes you add, the more complications you have in planning your DB placement, planning recovery and testing node failure.  Its probably going to cost you more to put it in.

Also, what if your virtualising - once you start virtualising SQL clusters backed off to SAN, the active nodes then just become devices in memory anyway, so is using lower spec Active/Active devices and having a lot of them better than having a high spec Active/Passive option in memory? Again, this is a relatively subjective argument as moving images from failed hardware to an alternative stable device is not really rocket science and planning Active/Passive is easier than Active\Active.

For example: You have decide that your clever enoiugh to split out your sharepoint databases into various instances of the cluster, and you have two active nodes, each one an instance on a single SQL server.  You were clever enough to rack both instances into the same rack and not put one in London and the other in Cape Town, and they are both on the same VLAN, not bridged across busy network segements. 

Node instance 1 points to database file 1 on the SAN (Drive J) - and you have your configuration database here, and your SSP databases. Node instance 2 points to database file 2 on the SAN (Drive K) - and you have your site collection databases here.  Along came your boss and said you had to make it redundent, and add in passive failure.

Failing either or both active Nodes to Node instance 3 means Node 3 will access both file 1 and 2 (Drive J and K), means you will now need to run 2 passive SQL instances on node 3, 1 for node 1 and 1 for node 2.  Where you thought you had a good DB split, you don't have the rackspace for instance 3, so it goes on another rack to consider and any latency between those two racks in addition to latency between the inital two Active nodes of any inter database communication in MOSS, never mind SQL compound your planning.  So, you now have to also work out how to run 2 instances of SQL server on that passive node and make sure that the server itself can cope with the load of both Active devices failing at the same time.  To complicate matters, you now need to add in a new drive letter, because you have secure data that will reside in a secure site collection in MOSS and you need a new SSP which needs to load balance between Application Servers residing on, so you have to add a new active node which is racked on a different LAN segment.  If only you'd stuck with a simple Active/Passive configuration.  Of course thats not esseentially all correct and the scenario is totally fabricated, you could equally make a shambles of planning your MOSS DB's with any configuration of SQL if you don't give it some up front thought.

So, I'm not going to be able to state with certainty that Active/Passive is a better choice over Active/Active, but its the one I always tend to use as default for most implementations should I get the performance expectations from it on both the active and passive node instances, whihc should never be on the same piece of kit, even virtually.  The only concern with Active/Active designs appears to be that they sacrifice performance to save money and when improperly designed, they may reduce availability due to complication. A poorly designed Active/Active SQL cluster in an MOSS farm under failure could see all the instances ending up on the same node, so any single node has to be scaled to cope with substantial traffice as it is.   The added complication of which active node you place which MOSS databases, how your VLANs and firewalling might affect this and how these nodes access the Content DB, or how you gauge performance on cross site content lookups when you have more than one active node and databases split across them, or what the impact on the Index servers may be doesn't appear well documented.  Seems there will be a lot of additional testing cost, and planning cost to choosing Active/Active and getting it working.

As to systems, well WIndows Enterprise Edition supports any number of nodes and is the only OS that supports clustering.  That is true for WIndows 2000, 2003, and 2008. SQL Standard Edition 2005 and 2008 will install on two-node clusters only. SQL Enterprise Edition 2005 and 2008 will install on pretty much any number of nodes.  Microsoft apparently stopped testing around 16 nodes for SQL 2005. If you are building a new cluster you should be going with the Windows 2008 Operating System and looking at SQL 2008.

It may be a while until I see myself passing the performance limits of a Active/Passive clusters to merit going for Active\Active as my default choice in the farms I'm planning.  The lesson here is get a good storage or SAN engineer to assist with palnning, one that has expereicne of MOSS DB configurations.  Hens Teeth spring to mind!

 

MOSS audit logs if enabled and left to go wild can grow very fast indeed.  Every 150,000,000 entries will consume about 40gig of database space.  So about 300 bytes per audit record give or take a few bytes.

if you enable item level auditing then this will grown at a rather rapid rate and few architects actually consider this additional space requirement when they plan their corpus storage.  

http://msdn.microsoft.com/en-us/library/bb397403.aspx

Working this out is based on the number of transaction per day that will be audited, so you need to know which sites will have auditing enabled.  

In a site trying to achieve compliance, or prove an audit trail as legally admissable the audit storage requirements can be taking up space that the MOSS admin has not factored in, and can't find.  If you have vanishing space - look here first!

The lesson here is don't enable auditing without thinking carefully about the impact of it from a performance perspective (item level auditing is a performance killer) and from an audit management perspective.  Fortunately, Microsoft recently released the
the infrastructure update for MOSS which contaisn the new Trimauditlog Stsadm command.  It basically allows you to manage the audit table and remove old entries (hooray!) without hacking the DB audit table which is of course unsupported.

http://technet.microsoft.com/en-us/library/cc706879.aspx

One tip worth remembering.  if you are clearing out the dbo.AuditData table you might want to back it up.  This is explianed in the Item Level auditing paper

By default SharePoint 2007 has Diagnostic logging turned in Central Administration logging and reporting, and typically stores 48 hours worth of log data. The default setting can be as much of a killer as the Audit logs to the unwary.

As well as Audit Logs, Diagnostic Logging can also consume a considerable amount of disk space in the “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS” folder.

On a heavy site, each log file can be about 150-200 meg. With new log files being created every 30 minutes this can quickly eat up 15 to 20Gb of space over a 2 day period. So be careful that your root partitions on your WFE servers are large enough to cater for poor diagnostics logging planning.

One of the good things about MOSS is that it can roll content up to higher tiers using content rollup, search and RSS webparts.  Combined with MOSS publishing templates you can create a very intuitive intranet or website.

The first few levels of a good intranet (and in fact most good websites) are usually given over as a "communications" layer where almost everyone in the organisation has read access.   It's ideal for the MOSS publishing templates as information is typically read only, easily structured and not subject to huge upheavals and constant change.   Surfacing niche information from different team sites usually works well for a broad consumer audience and allows the projects to concentrate on project related information and COMMS to fish for quality content.

Content rollup is a strategy!  The right strategy with an understanding of rollup approaches allows you to package your intranet and allow it to grow from the inside – without many of the usual issues connected to information being hard to find for end users, and poor or cumbersome navigation making structure changes very difficult.  Your intranet therefore becomes quite a tight entity where it counts, at the consumer face.

Content rollup in a nutshell means that as internal projects start to come on board and take advantage of the collaborative features they need to operate their project, whoever is responsible for managing the public face of the site can easily access and expose relevant information using content rollup through rollup, search and RSS webparts.  Of course this does assume they have the correct read security model in place for content they wish to expose.  So, team sites also need some form of structure thinking applied to them to make sure this is achievable, as do references to external sites and how that information might be surfaced on your own site using RSS perhaps, or custom search results.

A rich choice of pre-defined templates from FAQs and press releases to documents makes deployment easy at the public face, whilst helping to preserve flexibility and design freedom for more advanced users.  Rolled up content rollup can be scheduled with start and expiry dates with optional email alerts to notify on expiry. You can allow any type of files you deem are appropriate, but its normally a good idea to restrict the use of video to designate areas –  as video can show a speaker's personality it can be used to strengthen the corporate culture through messages from the CEO and other executives, or expose technical expertise though mysite blogs containing video.  Again, easily surfaced on the intranet home page, but located elsewhere in the site structure.    Of course video has a huge impact on bandwidth so has to be carefully planned in. The worst intranets are those bloated so much they underperform, or are so hard to navigate you can’t find anything.
So think carefully about how your Public area can surface information and links into you publishing site with a rollup strategy and you’ll have a very fluid intranet or internet service with little actual work.

Pointers:

This is an excellent article on how to do cross site collection rollup of content using a Search webpart.
http://www.devcow.com/blogs/jdattis/archive/2007/04/17/SharePoint-2007-How-to-Rollup-Content-from-multiple-Site-Collections.aspx

A great article on dynamically filtering the Content Query Webpart results
http://www.andrewconnell.com/blog/archive/2008/02/18/Subclassing-the-Content-Query-Web-Part-Adding-Dynamic-Filtering.aspx

How to rollup content from more than one content type
http://www.sharepointblogs.com/mykiep/archive/2007/06/30/overriding-the-content-query-web-part.aspx

Using a Dataview and Sharepoint Designer to enhance rollup
http://blogs.msdn.com/sharepointdesigner/archive/2007/04/24/spdatasource-and-rollups-with-the-data-view.aspx

A deep dive into the Content Query webpart
http://sharepointkb.wordpress.com/2008/07/25/sharepoint-content-query-webpart-customizable-powerful-and-invaluable-to-anyone-who-uses-sharepoint/

A multiple RSS feed consolidation webpart
http://codeplex.com/FeedReader

A good write up on MOSS RSS Webpart
http://www.datasprings.com/Resources/ArticlesInformation/SharePointMOSS2007RSSFeeds/tabid/831/Default.aspx

Someone asked me the question "how secure is sharepoint?"

I actually think thats very hard to answer within the context of which the question is being asked.

“how secure is sharepoint?”  We'll - how secure is any online system?

Kerberos, AD, Federated AD (policy based), SSL encryption, Forms Authentication, Token based security, is all supported.  Permissions enforce security to the granular level and strengthen it based on zones of access (ie different access for internet audience than intranet audience).

Its worth looking at Joel Olesons blog entry on this which covers a lot of the enhancements in security for MOSS 2007

http://blogs.msdn.com/joelo/archive/2007/04/06/security-improvements-in-sharepoint-server-2007.aspx

Most public instance of MOSS use ISA Server and https encryption with forms authentication.  So it’s really as secure (probably more so) as using an online banking system in terms of data transmission and storage.  You only have proxied access to the internal system over HTTPS from an internet access point, you are never really on the servers even – which makes hacking it very difficult.  When you add forefront into the mix its hardened even further.

From an architectural view, this kind of security approach means it can be security hardened to the nth degree as a product.  Architecture of the underlying application for hardened security is quite an art form and you can go overboard easily.

For reading:  I would start here with the roadmap and downloadable book on the requirements for hardening a  MOSS instance.

http://technet.microsoft.com/en-us/library/cc263518(TechNet.10).aspx

Most people tend to run Central Admin on a single server, as its usually a bit of a pain to run it load balanced.  Now that is not normally an issue - that is of course until you lose the server its running on.

Try as hard as you might, you wont be able to just enable it on another server as the farm thinks its already provisioned.  That means you will have to reprovision it on a different server, get Central Admin up and running on an alternative box and then take the old Central Admin application out of the farm.

There is a tool to help you with this and its good old psconfig.exe.

The trick in enabling a replacement Central Admin server is to ensure you provision with a new port, because if you don't the timer job that activates the newly provisoned server will not run, and the old Central Admin allocation will remain active leaving you with two innaccesible Central Admin applications.

So, on the new server as a precaution run:

psconfig.exe -cmd adminvs -unprovision

and then run it again to provision a new Central Admin service, ensuring you specify the replacement port number.

psconfig.exe -cmd adminvs -provision -port 8080 -windowsauthprovider onlyusentlm

You should now be able to access Central Admin on the new port, allowing you to go into Operations and delete the application for the old service.  When you get the old server re-instated make sure the old application isn't still lurking. 

Replication is rarely the solution to poor wan links in MOSS - and MOSS deployment support over WAN is not good.  Bear in mind that as soon as you replicate content DB's or sites and have them attached to another site collection in a remote farm you have a possible synchronisation issue unless your audience is read only.

A decision to replicate has to be based on planning with a consideration for WAN link data consumption when adding a MOSS farm.  What's the impact - you need to know the volume a link has to carry before you deploy a farm, as that should form part of your planning exercise to see if new working practice when using MOSS will swamp your network, and it will if you do not plan it up front.  Simple rules like how many read and write operations per day of a typical document size are going to travese our network should be at the front of your mind.  Can the doc converter service help me, can I use publishing to offset traffic - what can be anonymous to offset load etc etc.

Also, if you do chose to replicate - how much data needs to go from one site to another or vice versa and before you decide that have you looked at the options like ISA server caching requests etc. and of course the possibility of harnessing WSS instances at remote sites for collaborative working and consolidating search or shared services centrally.

One other thing to consider is to have two farms in this type of low bandwidth scenario and use content publishing to replicate fixed data (like rarely changing HR policy) between sites, but there are many factors to consider (cost and techncial complexity of course can make this prohibitive).  If this isn't an option and you must replicate then take a look at DocAve from Avepoint as it can do two way replication with synching.
http://www.avepoint.com/products/sharepoint-administration/sharepoint-replication

I've not tested it (yet) but I hear its a fine fish in a river full of slippery eels!

As usual Joel Olsen has a word to say with respect to replication, more for redundancy than in a low bandwidth sceneario, but also as usual the words do carry a lot of value.

Read more here:

http://blogs.msdn.com/joelo/archive/2007/04/02/replication-and-high-availability.aspx

and here:

http://blogs.msdn.com/joelo/archive/2008/01/17/global-sharepoint-deployment-partner-solutions.aspx

I've been asked this question a few times, and I can honestly say I don't have a defacto answer for it.  Can MOSS really do Fileplans?  Myself and a good friend Brian English (who know more than me about information flow in MOSS) had a chat about this.

MOSS doesn’t provide great tools for defining a Fileplan and then enforcing it from that. However many organisations, inc Government, document their File plan in MS Excel or even Word so this isn’t necessarily a huge shortcoming. If the implementation and Design of the FilePlan is in the same tool and that tool doesn’t separate the two activities you run the risk of quality audit non-compliance. If one tool does everything, how do you know that it is doing what it is meant to do, and not what someone has mistakenly set it up to do. This is a common check for ISO9001 Quality Auditors in all sorts of areas which can result in the Fileplan design therefore having to be documented off-the system that enforces it anyway.

So, File-plans are normally defined outside of MOSS, depending on how you want to organise your information storage and the policies around it.  This is then mapped into MOSS using a combination of document workspaces, libraries, lists, image libraries etc. either at a root site level (department) or at a team site level (team) or an individual level (mysite – typically no policy other than manual process enforcement). 

This would include definition of Metadata which could be applied to each document and list item and views hrough which to improve exploitation.

You would build site templates to represent how the taxonomy of these storage areas (for want of a better description) would sit, and the structure for new sites based on the breakdown of the fileplan and new sites would be created to represent this taxonomy and the fileplan breakdown as it was expected to be applied. These can be reused to provide a consistent site structure, they may include standard data, e.g. document templates or links to help or template references (other sites) that you want to deliver to each site. You need to be careful which approach is used as embedding data in site templates can cause problems over time if the data changes significantly and there are a lot of sites that then need updating.

All areas of information storage in MOSS can be team centric (but they don’t have to be) as they can be divisional centric – but those team centric views on information can have policies applied to feed the records centre from anywhere to ensure the fileplan requirement is met.  So the structure of any “drop zone” in the records centre so to speak can have information policies applied that ensure the requirements of the fileplan are met. Ie. If it’s this type of document (email) move to folder X in the record centre and retain for two years then delete. The concept of content types supports the fileplan definition stage, so fileplan elements should be mapped into content types and the content types mapped to MOSS Information Management policy whihc can for all sense and purpose drive your fileplan enforcement.

There is a specific site called the document centre which is designed to offer a more robust document centric view on an organisation than a document library in a team site, where a less formal more hierarchical top level file structure can be created that represents how a logical view of the information might be managed – but it’s a bit of a forced taxonomy.  This though can be applied at any level, as can a folder hierarchy that represents taxonomy based on lists and libraries.  So it all depends on “what” you trying to do with your fileplan and whether it can be done in MOSS.

There are no fileplan modelling tools in MOSS.  You are expected to do this outside of MOSS and enforce the policy of fileplan object types based on specific content types.   MOSS also has no support in its record centre for hierarchical fileplans - you need third party tools like Wisdom, which is MOREQ2 compliant and conforms to the UK National Archive standards.

At this stage, I would probably start repeating an excellent article writtien by MVP  Zlatan Dzinic which goes into more details than I intend to do, and so I'm going to divert you over to that.

http://dotnet.org.za/zlatan/archive/2007/09.aspx

Hopefully I've wet your appetite and Zlatan can serve you the main course!