korry's blog

Further to my previous blog on SharePoint Disaster recovery (Cross Datacenter Failover with SQL 2005 and MOSS 2007), there is further consideration as to which version of SQL 2005 you choose for the mirroring.  SQL 2005 Standard supports Synchronous / SAFETY=FULL configuration while SQL 2005 Enterprise supports Asynchronous mirroring.  What this means is that with SQL 2005 Std the transaction does not commit on production until it commits on the secondary (mirrored data server).  If you have a slow LAN o WAN, this is less preferred UNLESS you absolutely need 100% of all data mirrored no matter what.  This is where the SAFETY=FULL comes in.  Full Safety means every transaction is guaranteed to be writing.   SQL 2005 Enterprise Asynchronous mode does not support SAFETY=FULL. 

General Guidelines to consider are: 
If you need speed at any cost, choose asynchronous.
If you need data integrity, choose synchronous.

I am currently working on a deployment that has mirroring planned across Europe to North America .  Once I have some numbers to provide to provide real world feasibility of this type of mirroring strategy, I will post them to this site.

Further to my previous blog on SharePoint Disaster recovery (Cross Datacenter Failover with SQL 2005 and MOSS 2007), there is further consideration as to which version of SQL 2005 you choose for the mirroring.  SQL 2005 Standard supports Synchronous / SAFETY=FULL configuration while SQL 2005 Enterprise supports Asynchronous mirroring.  What this means is that with SQL 2005 Std the transaction does not commit on production until it commits on the secondary (mirrored data server).  If you have a slow LAN o WAN, this is less preferred UNLESS you absolutely need 100% of all data mirrored no matter what.  This is where the SAFETY=FULL comes in.  Full Safety means every transaction is guaranteed to be writing.   SQL 2005 Enterprise Asynchronous mode does not support SAFETY=FULL. 

General Guidelines to consider are: 
If you need speed at any cost, choose asynchronous.
If you need data integrity, choose synchronous.

I am currently working on a deployment that has mirroring planned across Europe to North America .  Once I have some numbers to provide to provide real world feasibility of this type of mirroring strategy, I will post them to this site.

SharePoint 2007 is an exceptional product with features that bring collaboration and content management to a new level.  I recommend anyone looking into implementing Enterprise Portals into their corporation seriously consider the TCO and ROI; 8 times out of 10, they will likely choose SharePoint 2007.  There are however some very real short-comings that need to be dealt with either by Microsoft, the solution vendor community or in the end the poor corporations out there currently implementing MOSS.  Below is a list of capabilities MOSS needs to round out its capabilities.

Archiving (ideally low cost): 

• SharePoint does not provide any capabilities to move old data to lost cost storage such as Centera.  Alot of vendors out there like Symantec, Meridio, Zantaz have pieces of the solution but none of them have the entire Sites and Document Life Cycle Management Integrated into WSS or MOSS.  For example, when a user is notified that their site is going to be deleted it would be ideal to be able to archive the site, compress it and put it onto Centera for a time period.  Right now, it's keep or delete.  
• Archiving list items to the record repository, not just documents.  The send to function only shows up for documents
• Single Instance Records Management.  When a document is sent to the records repository, to my knowledge the copies of the document are not associated to the records repository. 

 Content Types:

• It wold be nice to be able to associate documents when uploading or importing them to a specific content type.  Most organizations will want a taxonomy to be represented in SharePoint.  Today, users can only create content types with new documents.  Migrating 5 terabytes/1 million documents from a previous collaboration system to SharePoint and not have those associated to content types is a disadvantage, maybe even a showstopper to adoption.

SharePoint Planning Templates:

• Why didn't Microsoft create InfoPath forms for the planning templates instead of word documents?   Microsoft is promoting structure data capture but not facilitating it.  A vendor should produce a pre-canned SharePoint template with all the planning templates as content types.  Then ideally add workflows such as new site creation that generates sites based on an approval system.

Wikis:

• Tags…no support for keyword tags

Web Parts:

• The are no out of the box AJAX enabled web parts to my knowledge.  See http://www.google.com/ig as an example of a well driven User Experience based portlet.  You can drag them around without clicking "edit page".  Likewise you can edit their properties on the spot.  Very desirable. 

Shared vs Personal Views:

• This is a feature I preferred in SPS 2003.  This feature allows a Site Owner to create a page and define the web parts in it – called a Shared view.  The user can "personalize" it and deviate it from the original site owners intent.  In SPS 2003 you could toggle between the personal view and the shared view.  When a user cam into the site they saw the shared view but could toggle to their personal view.  That allowed the site owner to be assured (mostly) that the user at least saw what they wanted them to.  With WSS 3/MOSS users are auto logged into their personal view completely bypassing the shared view.  Also the toggle function to switch views is gone (although you can still append ?pageview=Shared to the end of a url and see it.

This is not an exhaustive list but it represent what I have seen in implementing very large SharePoint projects and the feedback I see when demoing the product to stakeholders.

All in all, SharePoint 2007 is an excellent product, I hope these shortcomings are addressed sooner rather than later.

Let me know of other shortcomings you feel need to be addressed.

SharePoint 2007 is an exceptional product with features that bring collaboration and content management to a new level.  I recommend anyone looking into implementing Enterprise Portals into their corporation seriously consider the TCO and ROI; 8 times out of 10, they will likely choose SharePoint 2007.  There are however some very real short-comings that need to be dealt with either by Microsoft, the solution vendor community or in the end the poor corporations out there currently implementing MOSS.  Below is a list of capabilities MOSS needs to round out its capabilities.

Archiving (ideally low cost): 

• SharePoint does not provide any capabilities to move old data to lost cost storage such as Centera.  Alot of vendors out there like Symantec, Meridio, Zantaz have pieces of the solution but none of them have the entire Sites and Document Life Cycle Management Integrated into WSS or MOSS.  For example, when a user is notified that their site is going to be deleted it would be ideal to be able to archive the site, compress it and put it onto Centera for a time period.  Right now, it's keep or delete.  
• Archiving list items to the record repository, not just documents.  The send to function only shows up for documents
• Single Instance Records Management.  When a document is sent to the records repository, to my knowledge the copies of the document are not associated to the records repository. 

 Content Types:

• It wold be nice to be able to associate documents when uploading or importing them to a specific content type.  Most organizations will want a taxonomy to be represented in SharePoint.  Today, users can only create content types with new documents.  Migrating 5 terabytes/1 million documents from a previous collaboration system to SharePoint and not have those associated to content types is a disadvantage, maybe even a showstopper to adoption.

SharePoint Planning Templates:

• Why didn't Microsoft create InfoPath forms for the planning templates instead of word documents?   Microsoft is promoting structure data capture but not facilitating it.  A vendor should produce a pre-canned SharePoint template with all the planning templates as content types.  Then ideally add workflows such as new site creation that generates sites based on an approval system.

Wikis:

• Tags…no support for keyword tags

Web Parts:

• The are no out of the box AJAX enabled web parts to my knowledge.  See http://www.google.com/ig as an example of a well driven User Experience based portlet.  You can drag them around without clicking "edit page".  Likewise you can edit their properties on the spot.  Very desirable. 

Shared vs Personal Views:

• This is a feature I preferred in SPS 2003.  This feature allows a Site Owner to create a page and define the web parts in it – called a Shared view.  The user can "personalize" it and deviate it from the original site owners intent.  In SPS 2003 you could toggle between the personal view and the shared view.  When a user cam into the site they saw the shared view but could toggle to their personal view.  That allowed the site owner to be assured (mostly) that the user at least saw what they wanted them to.  With WSS 3/MOSS users are auto logged into their personal view completely bypassing the shared view.  Also the toggle function to switch views is gone (although you can still append ?pageview=Shared to the end of a url and see it.

This is not an exhaustive list but it represent what I have seen in implementing very large SharePoint projects and the feedback I see when demoing the product to stakeholders.

All in all, SharePoint 2007 is an excellent product, I hope these shortcomings are addressed sooner rather than later.

Let me know of other shortcomings you feel need to be addressed.

So there is alot of information on the internet and the recent webcasts of disaster recovery with SharePoint, however rarely do you see Distser recovery BETWEEN datacenters.  Understandably, few implementations of SharePoint for a user base less than 5000 users would require cross datacenter failover, however, consider hosted internet provider solutions, which are becoming more ubiquitous, or consider large corporations (like where I work) that have 31,000 employees and need highly available large farms.

We are planning for disaster recovery across datacenters using database mirroring using a witness server to synchronize data between the primary tier 1 data center in Canada and the UAT environment in another datacenter in the United States.  The target, redundent SQL databases in UAT are not used by the UAT instance.  In addition, there is a parralel instance of SharePoint that EXACTLY matches the production environment – NOTE that this is not used for UAT, but sits on the same hardware. 

From a Release management perspective, all changes propigated from UAT to Production, MUST be released to the Failover instance on the UAT hardware as well. 

I will write more on this, in terms of configuring the database mirroring, and release management in the coming weeks.

So there is alot of information on the internet and the recent webcasts of disaster recovery with SharePoint, however rarely do you see Distser recovery BETWEEN datacenters.  Understandably, few implementations of SharePoint for a user base less than 5000 users would require cross datacenter failover, however, consider hosted internet provider solutions, which are becoming more ubiquitous, or consider large corporations (like where I work) that have 31,000 employees and need highly available large farms.

We are planning for disaster recovery across datacenters using database mirroring using a witness server to synchronize data between the primary tier 1 data center in Canada and the UAT environment in another datacenter in the United States.  The target, redundent SQL databases in UAT are not used by the UAT instance.  In addition, there is a parralel instance of SharePoint that EXACTLY matches the production environment – NOTE that this is not used for UAT, but sits on the same hardware. 

From a Release management perspective, all changes propigated from UAT to Production, MUST be released to the Failover instance on the UAT hardware as well. 

I will write more on this, in terms of configuring the database mirroring, and release management in the coming weeks.

I recently had a client ask me why they could not save txt files that were stored in a document library back to the site.  I don't typically use txt files so I asked them to show me by creating a new txt file and uploading it to the site, then clicking on it in the document library list.  The file opened in IE (web browser) not notepad.  My reflex told me that all we had to do was add notepad.exe as an application type in the DOCICON.xml file stored in C:Program FilesCommon FilesMicrosoft Sharedweb server extensions60TEMPLATEXML.

I went back to my office, an played around with it for a while to see if I could change the entry for txt.

First I tried:

<Mapping Key="txt" Value="ictxt.gif" EditText="Notepad" OpenControl="SharePoint.OpenDocuments"/>

That didn't work

Then I tried

<Mapping Key="txt" Value="ictxt.gif" EditText="Microsoft Office Word" OpenControl="SharePoint.OpenDocuments"/>

Which creashed my IE.

Then I did some research and found out that the SharePoint.OpenDocuments command only supports openning MS documents by executing the ActiveX that is installed as part of MS Office.  There isn't much documentation on it.  Here is thread that describes the problem and challenges. 

http://www.codecomments.com/message376491.html

 Here is the MSDN article that eludes to how to solve it, however it is vague at best.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/tsptAddingDocumentTypeIcon_SV01068572.asp

So for now, unless I look into where the WordPerfect activeX is that controls this behaviour, I won't be able to do this unless I write my own activeX and have it install on client machines.

I recently had a client ask me why they could not save txt files that were stored in a document library back to the site.  I don't typically use txt files so I asked them to show me by creating a new txt file and uploading it to the site, then clicking on it in the document library list.  The file opened in IE (web browser) not notepad.  My reflex told me that all we had to do was add notepad.exe as an application type in the DOCICON.xml file stored in C:Program FilesCommon FilesMicrosoft Sharedweb server extensions60TEMPLATEXML.

I went back to my office, an played around with it for a while to see if I could change the entry for txt.

First I tried:

<Mapping Key="txt" Value="ictxt.gif" EditText="Notepad" OpenControl="SharePoint.OpenDocuments"/>

That didn't work

Then I tried

<Mapping Key="txt" Value="ictxt.gif" EditText="Microsoft Office Word" OpenControl="SharePoint.OpenDocuments"/>

Which creashed my IE.

Then I did some research and found out that the SharePoint.OpenDocuments command only supports openning MS documents by executing the ActiveX that is installed as part of MS Office.  There isn't much documentation on it.  Here is thread that describes the problem and challenges. 

http://www.codecomments.com/message376491.html

 Here is the MSDN article that eludes to how to solve it, however it is vague at best.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/tsptAddingDocumentTypeIcon_SV01068572.asp

So for now, unless I look into where the WordPerfect activeX is that controls this behaviour, I won't be able to do this unless I write my own activeX and have it install on client machines.