Yep. I'm packing my bags and off to Florida for 2 weeks.
Got a friend who is getting married in DisneyWorld (make of that what you will!!) Personally I'm looking forward to the 2nd week .. relaxation in the Florida Keys (assuming I don't get a hurricane to spoil my day).
ahhh ... beaches ... swimming pools .. and drinks with little umbrellas in them :)
Thursday, 28 August 2008
Wednesday, 27 August 2008
How to handle document retention and expiry in MOSS 2007 - Disposition Workflow and Expiration Policy
This is rapidly becoming a hot topic in Records Management with SharePoint, as organisations put increasing amounts of information into their SharePoint environments serious thought needs to be put into how that information should expire and (more importantly) what happens when it expires.
SharePoint has several solutions to these issues which, if configured correctly, can help pave the way to successful document expiration management.
The Expiration Management Policy
Information Management Policies are a new framework introduced in MOSS 2007, and allow specific "policies" to be applied system wide using Content Types, or to individual document libraries and lists.
One of the most popular policies in information management is the Audit Policy (which is vastly superior to version history, as it can track who has viewed, downloaded or deleted a document, as well as who has made changes), but another equally important policy is the Expiration Policy.
The Expiration Policy effectively allows you to specify the retention period for content. This is generally calculated from the created or modified date, although you can specify any formula (i.e. calculated fields) based on any date/time column value.
When a document "expires" you can then select from a number of actions: delete the item, perform another custom action (extensible through development) or start a workflow, and it is the latter that we will focus on here.
As mentioned, you can develop additional "custom actions" for the expiry Information Policy, which you can deploy as a Feature (there is a good article here and also a forum post discussing the options for this).
The Disposition Approval Workflow
The disposition approval workflow is designed specifically for document expiry, and has been designed with a very simple user interface.
When started the workflow creates a task, which is linked to the document. The task presents the user with the options of deleting the item, or keeping it, and the ability to add some comments. Completing the task will perform the appropriate actions on the server.
This basically gives you "out of the box" capability to have items which expire and then get (optionally) deleted upon expiry.
..
Now, I put my developer hat on and delved behind the scenes.
The Disposition Approval Workflow consists of a custom Task Content Type which is used for the task, and an InfoPath form which is used for the task edit form (via Form Services).
This gives us 2 options for replacing / extending the Workflow.
1) Create our own custom content type for the tasks. This allows us to attach event handlers and perform any custom operations when the tasks are created / edited / completed.
2) Create a replacement InfoPath form and use that for the task completion, perhaps with additional options (such as "archive" ?).
...
Either way, the out of the box options are quite extensive, and the Workflow / Content Type structure gives enough extensibility to provide almost any functionality for document retention.
Friday, 22 August 2008
People search errors when My Site is running on SSL
This was a great gotcha that I picked up duing a client project handover.
They reported issues with search, and I found a load of errors in the crawl logs regarding accessing the mysite.
You will find that this issue occurs when you configure your My Sites to run under SSL (HTTPS), and the problem is that the People Search isn't really interested in the My Site content, it is actually interested in the Profile Database (which is another thing most people forget to switch on .. make sure your Profile Database has an import schedule setup!)
Basically, you need to set the Content Source URL to the following:
sps3s://<mysiteurl>/
So if your mysite is running under https://mysite.company.com/ then you need to set your Content Source URL to:
sps3s://mysite.company.com/
Personally I found this pretty confusing, so I actually split out the Profile Database content into a separate Content Source, and configured the People Scope to only retrieve items from that specific Content Source.
Happy searching!
Update
Just a quick update, because this is another "People Search" problem. Even if you don't use My Sites, you should still switch on and use the MySite web application and settings (You can stop people from creating "My Sites" by disabling Self Service Site Creation at the Web Application level).
The reason is that the My Site web application is used for People Search URLs and will automatically dsiplay information from the Profile Database (which is basically the user's "public profile") even if they don't have a My Site created!
Tuesday, 19 August 2008
How to access STSADM from any directory
This is a nice quick tip for the August holiday season.
Open up the following:
Start --> Control Panel --> System
This should open up the System Properties dialog.
Go to the Advanced Tab and click on Environment Variables.
Find the variable called "Path" and append this to the end:
;c:\program files\common files\microsoft shared\web server extensions\12\bin
That should be it.
You may need to re-open ay Command Prompt windows before you can use this.
Now you can just call "stsadm.exe" from any command prompt window!
Note - If you find type "stsadm.exe" a bit laborius, try adding another one:
Name: STSADM
Value: stsadm.exe
Hopefully you get how this would work
Monday, 23 June 2008
The Key to successful SharePoint Projects
I got 3 words for you ...
Plan
Plan
then Plan some more ...
Ok .. so this isn't specific for SharePoint, all Software development projects are reliant on planning for successful execution (how can you know if you have delivered, if you don't know exactly what you are supposed to be delivering?) but SharePoint has this point in spades.
The first reason is Scaleability. SharePoint scales extremely well (up to 40TB in Lab Conditions according to the Microsoft SharePoint Team Blog). In fact there is an excellent Whitepaper recently available on this topic: SharePoint Server 2007 Scalability and Performance whitepaper.
However ... this level of Scaleability can only come if it has been planned for. You cannot simply install SharePoint "OotB" (Out of the Box) and expect it all to work.
The main effort required in the Scaleability process is the idea of "Site Collections", each of which is reported to scale easily up to about 50GB (although the labs mentioned above had >100GB Site Collections). Either way, if you are looking at an enterprise level implementation you are probably going to run out of space at some point and that will cause problems.
So .. you need to factor in Site Collections to your infrastructure. I won't spend ages talking about them, but there is a great article by Hiran Salvi on Sites vs Site Collections that is a must read on the topic.
The other main factor is Content & Metadata Maintenance (also sometimes referred to as "Metadata Governance"). If you have been working with SharePoint for a while then you are bound to come across a client who asks the following:
"Can I add a column to all of my Document Libraries?"
Now ... if you haven't planned for Content Types then this could be a really big headache! Content Types are effectively the schemas that define all of your SharePoint storage. Each time you create a Document Library it is using the OotB "Document" Content Type. Now .. you could go and just modify the Library itself, but then you are effectively breaking your Content Type structure and that is bad mojo! (what happens when you want to modify said column after you've added it to 50 libraries?? you'll need more than one cup of coffee for that job!). The main problem is that you cannot modify the "Document" content type either! (well .. you could ... but you will probably break something doing it!). The reason is that a lot of other places in SharePoint also use that Content Type (such as "Master Page Gallery" and "Page Libraries" to name but a few!). A second major problem is that you cannot easily modify all of the Document Libraries either! (I mean .. thats what Content Types are for .. right?)
The recommended practice is to create a custom Content Type for all of the user-created Document Libraries. If the client wants to add a column .. no problem, you just add the column to the new "custom" content type, and Robert's your father's brother!
Of course .. if you didn't plan for that in the beginning ... well .. you'll be in for some pain! You either have to pay a temp to sit on your server for days on end re-allocating all of the Content Types system wide, and then you still haven't solved the problem of new lists and libraries that keep getting created! Or you have to get a developer to spend some very expensive days writing code to go around and do it all automatically!
.. either way .. best to be avoided and will be far cheaper in the long run if you plan for it!
The final point on planning (and by no means the final word on the topic, just the final point in my ramblings) is the following:
Who is going to use the system? And how will they use it?
Far too many people assume that SharePoint, being a Microsoft product .. hmph .. will just work out of the box and will solve all their problems (including World Peace). The truth is .. SharePoint is an advanced and very very complex web development platform.
Yes, it provides a whole raft of management, maintenance and administration functions and offer variability and flexibility like few other web based systems before it! But it requires time, a LOT of thought and plenty of expertise to deploy correctly.
The most important part of this is the users. What business requirement is being satisfied? What is the reason for using SharePoint (or any web based system?), what are the problems and how has this implementation been designed to solve those problems?
Last but not least .. never never never neglect the end users, especially the Content Managers. I have seen 2 things commonly happen which cause projects to fail:
1) "We'll just give them all Team Sites"...
This is a classic. You create 500 Team Sites ... one for each department / user group / business stream / office / project.
There is one major problem. they are ALL EMPTY!
99% of users will load up their nice bright shiny portal ... and look at these nice big expensive blank pages. Then log off and probably never return.
If you don't give them content and relevant design then you won't get any buy in!
2) "We'll let the Site Owners do what they want ..."
This is probably worse that point (1). At least there you can rebuild and you don't have to worry about the current system (because it's pretty much empty .. right?).
Now don't get me wrong ... this technically CAN work .. but you need Effective Training to make sure that your Site Owners understand the followig ideas:
* How to manage content
* How to create a hierarchical structure that works
* How to manage security permissions
* What is vision for the system as a whole?
* What do we want people to use the system for?
Without a unified vision for the system you end up with an implementation that is haphazardly put together, where each site has it's own layout, classifications and web parts. Trying to central manage a system like that will be a nightmare .. for both the project leaders and the systems administrators!
Well .. thats my ramblings for now, hope some of these nuggets have sunk in.
As always ... comments welcome!
- Martin Hatch
Plan
Plan
then Plan some more ...
Ok .. so this isn't specific for SharePoint, all Software development projects are reliant on planning for successful execution (how can you know if you have delivered, if you don't know exactly what you are supposed to be delivering?) but SharePoint has this point in spades.
The first reason is Scaleability. SharePoint scales extremely well (up to 40TB in Lab Conditions according to the Microsoft SharePoint Team Blog). In fact there is an excellent Whitepaper recently available on this topic: SharePoint Server 2007 Scalability and Performance whitepaper.
However ... this level of Scaleability can only come if it has been planned for. You cannot simply install SharePoint "OotB" (Out of the Box) and expect it all to work.
The main effort required in the Scaleability process is the idea of "Site Collections", each of which is reported to scale easily up to about 50GB (although the labs mentioned above had >100GB Site Collections). Either way, if you are looking at an enterprise level implementation you are probably going to run out of space at some point and that will cause problems.
So .. you need to factor in Site Collections to your infrastructure. I won't spend ages talking about them, but there is a great article by Hiran Salvi on Sites vs Site Collections that is a must read on the topic.
The other main factor is Content & Metadata Maintenance (also sometimes referred to as "Metadata Governance"). If you have been working with SharePoint for a while then you are bound to come across a client who asks the following:
"Can I add a column to all of my Document Libraries?"
Now ... if you haven't planned for Content Types then this could be a really big headache! Content Types are effectively the schemas that define all of your SharePoint storage. Each time you create a Document Library it is using the OotB "Document" Content Type. Now .. you could go and just modify the Library itself, but then you are effectively breaking your Content Type structure and that is bad mojo! (what happens when you want to modify said column after you've added it to 50 libraries?? you'll need more than one cup of coffee for that job!). The main problem is that you cannot modify the "Document" content type either! (well .. you could ... but you will probably break something doing it!). The reason is that a lot of other places in SharePoint also use that Content Type (such as "Master Page Gallery" and "Page Libraries" to name but a few!). A second major problem is that you cannot easily modify all of the Document Libraries either! (I mean .. thats what Content Types are for .. right?)
The recommended practice is to create a custom Content Type for all of the user-created Document Libraries. If the client wants to add a column .. no problem, you just add the column to the new "custom" content type, and Robert's your father's brother!
Of course .. if you didn't plan for that in the beginning ... well .. you'll be in for some pain! You either have to pay a temp to sit on your server for days on end re-allocating all of the Content Types system wide, and then you still haven't solved the problem of new lists and libraries that keep getting created! Or you have to get a developer to spend some very expensive days writing code to go around and do it all automatically!
.. either way .. best to be avoided and will be far cheaper in the long run if you plan for it!
The final point on planning (and by no means the final word on the topic, just the final point in my ramblings) is the following:
Who is going to use the system? And how will they use it?
Far too many people assume that SharePoint, being a Microsoft product .. hmph .. will just work out of the box and will solve all their problems (including World Peace). The truth is .. SharePoint is an advanced and very very complex web development platform.
Yes, it provides a whole raft of management, maintenance and administration functions and offer variability and flexibility like few other web based systems before it! But it requires time, a LOT of thought and plenty of expertise to deploy correctly.
The most important part of this is the users. What business requirement is being satisfied? What is the reason for using SharePoint (or any web based system?), what are the problems and how has this implementation been designed to solve those problems?
Last but not least .. never never never neglect the end users, especially the Content Managers. I have seen 2 things commonly happen which cause projects to fail:
1) "We'll just give them all Team Sites"...
This is a classic. You create 500 Team Sites ... one for each department / user group / business stream / office / project.
There is one major problem. they are ALL EMPTY!
99% of users will load up their nice bright shiny portal ... and look at these nice big expensive blank pages. Then log off and probably never return.
If you don't give them content and relevant design then you won't get any buy in!
2) "We'll let the Site Owners do what they want ..."
This is probably worse that point (1). At least there you can rebuild and you don't have to worry about the current system (because it's pretty much empty .. right?).
Now don't get me wrong ... this technically CAN work .. but you need Effective Training to make sure that your Site Owners understand the followig ideas:
* How to manage content
* How to create a hierarchical structure that works
* How to manage security permissions
* What is vision for the system as a whole?
* What do we want people to use the system for?
Without a unified vision for the system you end up with an implementation that is haphazardly put together, where each site has it's own layout, classifications and web parts. Trying to central manage a system like that will be a nightmare .. for both the project leaders and the systems administrators!
Well .. thats my ramblings for now, hope some of these nuggets have sunk in.
As always ... comments welcome!
- Martin Hatch
Friday, 9 May 2008
Talking about Microsoft Certified Professional Developer- Web Developer
Yay me... on Wednesday 7th May 2008 I passed the Microsoft Certified Professional Developer - Web Developer exam. Probably one of the hardest exams I've sat so far due to it being more conceptual (does this specification meet the requirements? … ) rather than technical (which class / method should you use for ..) kind of questions.
According to Microsoft I'm one of the first 5000 people worldwide to pass this one 
Hurrah ... now what's next ??
Wednesday, 16 April 2008
Displaying an Access Report in a Web Part
ok .. so who uses Microsoft Access anymore ???
You might be surprised that the Report Designer is becoming increasingly popular now that the ability to link to SharePoint data has been added in. From any SharePoint list you should be able to select "Actions" and then "Open in Access" .. which then gives you the option of taking a copy of the data, or (even better) creating a link to the data in SharePoint (allowing you to report and query the SharePoint data direct from the SharePoint database!!)
This of course opens up the possibilities of non-technical end users creating rich reports using nothing more than Microsoft Access and a couple of out of the box web parts.
I won't go into all the detail about Access Snapshots .. you can find all that (and more) here.
I must give a nod of thanks to the guys over at ProgrammingMSAccess, their samples on embedded Snapshots are the ones I am using in my web part.
So .. how can we get up and running?
First, add a Content Editor Web Part. Enter the following code into the Source of the web part (by modifying the web part, and using the built-in source editor).
<OBJECT ID="SnapshotViewer" WIDTH=800 HEIGHT=600CLASSID="CLSID:F0E42D60-368C-11D0-AD81-00A0C90DC8D9"> <PARAM NAME="_ExtentX" VALUE="16722"> <PARAM NAME="_ExtentY" VALUE="11774"> <PARAM NAME="_Version" VALUE="65536"> <PARAM NAME="SnapshotPath" VALUE="http://webserverURL/folder/snapshotfilename.snp"> <PARAM NAME="Zoom" VALUE="0"> <PARAM NAME="AllowContextMenu" VALUE="-1"> <PARAM NAME="ShowNavigationButtons" VALUE="-1"> </OBJECT>
The only part you have to change is the "VALUE" attribute for the "SnapShotPath" node (I've highlighted it for you to make it easy ;)). This needs to be a URL that points to the SnapShot file (preferably in a Document Library in your SharePoint Site - Anyone viewing this report will need Read access to it.).
That is pretty much all there is to it. Feel free to play about with the "Width" "Height" "AllowContextMenu" and "ShowNavigationButtons" ... I'm sure they are all pretty straightforward! ;)
One final note - All users who want to view the report must have Snapshot Viewer for Microsoft Access installed on their workstation (otherwise the web part will just be blank).
Example Report - Shown on a standard Web Part Page:
SQL Server Feature Comparison (2005 – 2008)
This is something we've had under our hat where I work for a while.. as you should be aware if you do a "stand-alone" install of WSS 3.0 (or MOSS 2007) then it installs "SQL Express Edition" (a.k.a. MSDE) .. but this version does have some startling limitations!
SQL 2005 Feature Comparison
|
| Express | Workgroup | Standard | Enterprise |
| Number of CPUs | 1 | 2 | 4 | No Limit |
| Max. RAM | 1 GB | 3GB | OS Limit | OS Limit |
| 64-bit support? |
|
| X | X |
| Max. Database Size | 4GB | No Limit | No Limit | No Limit |
| Clustering / Mirroring |
|
| X | X |
| Online Restore / Recovery |
|
|
| X |
| Management Studio |
| X | X | X |
| Job Scheduling (through Agent) |
| X | X | X |
| Import / Export |
| X | X | X |
| Web Services |
|
| X | X |
Much more also available at Microsoft SQL Server 2005 Features Comparison.
SQL 2008 Feature Comparison
|
| Compact | Express | Standard | Enterprise |
| Number of CPUs | 1 | 1 (per server) | 4 | No Limit |
| Max. RAM | OS Limit | 1GB | OS Limit | OS Limit |
| 64-bit support? |
|
| X | X |
| Max. Database Size | 4GB | 4GB | No Limit | No Limit |
| Clustering / Mirroring |
|
| X | X |
| Online Restore / Recovery |
|
|
| X |
| Management Studio |
| (tool) | X | X |
| Job Scheduling (through Agent) |
|
| X | X |
| Import / Export | (tool) |
| X | X |
| Web Services |
|
| X | X |
Detailed comparisons can be found between Compact and Express … and Standard and Enterprise
Thursday, 3 April 2008
Some things to note about using "Templates"
I’ve been doing some testing, mainly prompted when I was questioned about Site Templates (I originally thought that Workflows built in SharePoint Designer would not be copied over in templates) and they proved me wrong! I have done some reasonably extensive testing, and have come to the following results:
Quick Summary
- SharePoint Designer Workflows will ONLY be copied over in a SITE TEMPLATE WITH CONTENT (any other configuration fails)
- Custom Workflows (including the “out of the box” ones) will be copied over in ALL TEMPLATES.
- If you hide the “default” content type then it will re-appear after using a Template.
- Version history is not preserved when using templates with content.
List Templates include the following items:
- Custom Workflows
- Adding more Content Types
- Re-ordering the Content Types
- Changing the default Content Types
- Adding a custom Content Type
- Versioning Settings
- Content approval Settings
Site Templates include all of the above, but if you also select “Include Content” then you will also get “SharePoint Designer Workflows”!
If is important to note that if you hide one of the “out of the box” content types from your list then saving a List Template OR Site Template will not have any effect! The content type will be back and visible when your new list / site is provisioned!
I then did some more general “what if” scenarios:
| Query | Answer |
| What happens if the custom Content Type in the Site Template does not exist in the target system? | It creates a LOCAL (i.e. list level) copy of the Content Type, and links it to the parent of the original content type. This means that it works as it used to work, but the “central” copy of the content type no longer exists so maintenance has to be done manually and changes cannot be “pushed down”. |
| What happens if you delete a Custom Content type while it is in use normally? | Error – “The Content Type is in use” |
| If you save with content, does it preserve version history? | No. All items copied over will be created as version 1.0. All draft versions are removed. |
It is also important to state the Disadvantages of using Templates and that is mainly regarding Site Templates, and it is 3 main things:
- Performance. Using lots of site templates will degrade the performance of your system.
- Maintability. Maintaining the structure going forward will be difficult, as you have no “schema” to modify. All you can do is
- Limited to the User Interface. Mainly with reference to lists, changing the default fields, default content types, and modifying some of the “back end” properties is not possible through the user interface, and therefore cannot be achieved using “List Templates”.
- Automation. There is still much more flexibility in terms of automation when using “definitions”. We can tie in event handlers and automation tools to do “almost anything”.
Tuesday, 4 March 2008
Correctly disposing SPWeb objects
I guess SharePoint development is a bit like riding a wave. First off you find you do almost everything wrong ... after a while you pick up some of the "best practices" (like disposing SPWeb objects) and then you find that you are still doing things wrong. Well ... thats the learning curve I'm afraid .. and it rounds down to where your SPWeb object came from, and when you should be disposing it.
There are several different ways of retrieving an SPWeb object.
Take the following 3 examples:
1) SPContext
SPWeb web = SPContext.Current.Web
2) OpenWeb
SPSite site = new Site("http://myserver/");
SPWeb web = site.OpenWeb("");
3) Site "RootWeb"
SPSite site = new Site("http://myserver/");
SPWeb web = site.RootWeb;
All 3 of them are valid SPWeb objects, but they are also all slightly different.
Lets start off with SPContext. This is basically a context object which represents the context of the current site that you are navigating. The SPContext.Current reflects where you currently are in the SharePoint site collection (so SPContext.Current.Web will return the SPWeb object that represents the site from which your code is executing ... for example .. the site that your web part is sat in).
There are 2 major issues with using SPContext.
1) It is context sensitive. Yes .. I know thats like saying the sky is blue, but you do need to consider this if you are looking at generic code that might be accessed from multiple projects. Pulling out the "SPContext" properties is fine from a web part, but you don't want the same code executing from a Console Application or a Workflow Custom Action.
2) SPContext is in use by all manor of controls and parts on the site and the page. If you dispose of the SPContext.Current.Web object then you will find that you get a nasty error message next time you try to access that object (forcing you to refresh the page). So if you've ever seen the error message below, check your disposal!
If you write a using statement such as:
There are several different ways of retrieving an SPWeb object.
Take the following 3 examples:
1) SPContext
SPWeb web = SPContext.Current.Web
2) OpenWeb
SPSite site = new Site("http://myserver/");
SPWeb web = site.OpenWeb("");
3) Site "RootWeb"
SPSite site = new Site("http://myserver/");
SPWeb web = site.RootWeb;
All 3 of them are valid SPWeb objects, but they are also all slightly different.
Lets start off with SPContext. This is basically a context object which represents the context of the current site that you are navigating. The SPContext.Current reflects where you currently are in the SharePoint site collection (so SPContext.Current.Web will return the SPWeb object that represents the site from which your code is executing ... for example .. the site that your web part is sat in).
There are 2 major issues with using SPContext.
1) It is context sensitive. Yes .. I know thats like saying the sky is blue, but you do need to consider this if you are looking at generic code that might be accessed from multiple projects. Pulling out the "SPContext" properties is fine from a web part, but you don't want the same code executing from a Console Application or a Workflow Custom Action.
2) SPContext is in use by all manor of controls and parts on the site and the page. If you dispose of the SPContext.Current.Web object then you will find that you get a nasty error message next time you try to access that object (forcing you to refresh the page). So if you've ever seen the error message below, check your disposal!
"Trying to use an SPWeb object that has been closed or disposed and is no longer valid"
Make sure you dispose of OpenWeb("") objects!
This is very important. When you are basically just creating your own SPWeb objects you will need to make sure that you dispose of your objects correctly. The best way of doing this is encompassing your web object in a "Using" statementusing(SPSite site = new Site(http://myserver/);Do NOT Dispose SPContext.Current.Web or SPSite.RootWeb
{
using(SPWeb web = site.OpenWeb("")){// work with web object} // web object disposed} // site object disposed
If you write a using statement such as:
// This is bad! m'kay ?What you are actually doing is disposing the SPContext.Current.Web object .. not just your own "web" object. THIS IS BAD. You should actually just declare them with a single, normal line, such as:
using(SPWeb web = SPContext.Current.Web)
{
}
SPWeb web = SPContext.Current.Web;And exactly the same applies to SPSite.RootWeb properties too!
Subscribe to:
Posts (Atom)