Prior to the release of Exchange Server 2007, Microsoft announced that the future of public folders was in question, and that SharePoint libraries would take their place. Microsoft quickly changed its stance and continues to support Exchange public folders, but there still might be a number of compelling reasons why you would want to consider storing incoming messages in SharePoint document libraries — instead of public folders.

SharePoint can enable incoming mail on lists and libraries. It also offers several out-of-the-box features like Alerts, Enterprise Search and Information Management policies, all of which provide for a richer collaborative experience.

Click here to continue reading my article in its entirety published at TechTarget’s Search Exchange.

We all know that out of the box, Microsoft decided NOT to implement item level permissions within InfoPath Forms Libraries and the same goes for Document Libraries, however if you venture into a standard SharePoint List and navigate to Settings / Advanced Settings,  you will notice that you can easily configure Item-level permissions and specify which items users can read and edit as per the below screen capture.

We all know the primary use of InfoPath right? The ability to create fancy forms that can be easily submitted and stored in a Forms Library for easy retrieval.  In our organization, there are a number of InfoPath forms that are required to be accessible by only the authors and the reviewers once a form has been submitted, so how do we go about securing these forms?  Before we delve into the solution, here is some background on permissions required for InfoPath forms.  As a minimum, users are required to have contributor rights to a form library in order for them to submit or save a form.  By having contributor rights, they inadvertently inherit read rights as well, and are provided with the opportunity to view all submitted InfoPath forms within the respective library.  Let’s take two common forms used in most organizations, the humble leave and expense forms.  These are two particular forms where you would only want the author and reviewer to have access to these forms after they have been submitted in the library.

Luckily, we can easily achieve this via SharePoint Designer Workflows and a neat little codeplex extention provided Paul Kotlyar called SPDActivities which you can download here.  This solution extends the available activities within SharePoint Designer 2007.  These are listed as follows;

• Send Email with HTTP File attachment – Allows sending emails with attachments retrieved using a web request
• Send Email with List Item attachments – Allows sending list item attachments as files attached to an email
• Start Another Workflow – Starts another workflow associated with a list item
• Grant Permission on Item – Allows granting of specified permission level on a specified item
• Delete List Item Permission Assignment – Allows deleting of specified permission level assignment for a given user
• Reset List Permissions Inheritance – removes any unique permissions assigned to an item by inheriting list permissions
• Is User a member of a SharePoint group – Checks if a given user is part of given SharePoint group
• Is Role assigned to User – Checks if a user role is already assigned on the current list item
• Lookup user info – allows to lookup properties in site’s user information list for a given login
• Copy List Item Extended Activity – Allows copying/moving list items and files cross site.
• Send Email Extended – Enhanced version of the OOTB activity. Allows you to specify the sender. Also does not break links in body.

The two that we will be utilising to ultimately provide us with the ability to set item level permissions upon submitting a form are;

• Delete List Item Permission Assignment and Grant Permission on Item.

After installing the solution on your SharePoint Farm, launch SharePoint Designer and browse to the site where the Form Library in question exists and select File / New / Workflow.

Enter a name for the Worfkflow, select your SharePoint Forms Library and select, “Automatically start this workflow when a new item is created.

Click Next.

We now need to set our Actions.  The first set of actions will be to delete any permissions that are no longer required that are being inherited, notably any viewer and contributor rights.  We do so by selecting the “Delete List Item permission Assignment” under Action.

We will click on “this item” hyperlink and select “Current Item”

We next click on “this user” hyperlink and select the SharePoint Group(s) that no longer require access to the entire library.  We repeat this process until all the unnecessary permissions are removed.

Next we select Actions and utilise the “Grant Permission on Item” activity.

We next click on “this level” hyperlink and type in one of the available permissions

Full Control
Design
Contribute
Read

In this example, I will type in Contribute, and then click on “this item” hyperlink and select “Current Item”.  Lastly, I will click on “this user” hyperlink and select,  “Workflow Lookup…” / Current Item / Created By.

This will allow the author of the form to have contributor access only to the items they create.  You can then repeat the above process to potentially add a “Reviewers” group to have the same access.

If we now navigate to the Forms Library in Question and locate an form item that has been submitted under the new workflow we will notice the correct permissions being applied.

In the below example, the Author Sarah has contribute permission, and I have two other specific groups also being assigned the necessary permissions based on the business process.

In summary, it is definitely possible to provide item level permissions to your submitted InfoPath forms without the need of code.  If you know of another method of providing the above, don’t hesitate to share your ideas via the comments below.

I came across an obscure situation earlier this year with a new SharePoint farm that I had just designed and built.  It was a fairly straight forward setup comprising of a dedicated SQL 2008 server, 2 x Web Front Ends utilising Windows NLB and 1 x Central Administration server all running Windows 2008 Enterprise R2 in a virtual environment utilising VMware ESX.

So after building the SharePoint farm, restoring the Content Databases and Shared Services Provider I thought to myself everything is actually going to plan for once, until…… I restarted one of the web front ends!

I had then noticed that the server that I had just restarted was taking an awfully long time for it login, often waiting 5-10 minutes before I would reach the logged in desktop.  First area of troubleshooting was to launch Windows Task Manager, to immediately find out that the OWSTIMER.exe process was utilizing 90-100% of the CPU without any drop.  My first instinct was to kill the process and by default, Windows will restart the process.  Whalla!! The OWSTIMER process was back to normal and the Windows Server was back to its normal responsiveness.  My immediate thoughts were, this is most likely a once off and boy was I wrong!  After restarting the server a second time later that day, I ran into the same issue.  My troubleshooting began and the first area I ventured into was Central Administration / Operations / Timer job status and Timer job definition to see if there were any jobs that were failing, however things seemed to be in order.  Next area of investigation was analysing the SharePoint Logs (fun, fun, fun)… however, everything seemed to be in order there too.  Scratching my head, I ventured into the trusty Windows Event Viewer and analysed the Application and System Logs and there it was, hidden away.  I had noticed a Date and Time change from one event to another around the time the machine was starting up. 

E.g. One event would be dated 15/03/2010 and then the next event would then be dated 16/03/2010!  This sudden change in date and time whilst the machine was starting its services was throwing the OWSTIMER into a frenzy with the culprit being VMware! 

I had just recently introduced a brand spanking new Vsphere 4 ESX host into an existing cluster which had the incorrect Date configured (in my case, it was running one day behind).  In summary, my Windows 2008 R2 SharePoint front end server was picking up the VMware ESX host time when it was starting up and then a second later would synchronise with our Domain Controller and pick up the correct time.  This sudden time shift (literally a single second) would cause the SharePoint Timer Service to have a fit and maxing out the processor.

Fair enough, I immediately amended the Date and Time on the ESX host and I was back in business. 

Please be aware that this may not be the answer to your OWSTIMER CPU issue as I have come across plenty of posts around the same problem with differing causes.

I hope this post saves you some hours, because I had spent plenty, including re-building the SharePoint farm in question.

I have just recently built a new SharePoint 2007 farm on a complete Windows 2008 R2 server platform and part of my standard build procedure is to implement a warm up routine, usually in the form of a script that is scheduled every morning to launch my SharePoint Web Applications.  Most of you will most likely know what I am referring to here, the slowness that end users experience when loading a SharePoint site for the first time in the morning!?

By default IIS will recycle its worker processes during the night, in my case IIS 7.5 tells me this happens at 1:04 AM.  You can locate this information in IIS Manager / Application Pools / Highlight your application pool in question and select Recycling under Actions / Edit Application Pool.

So what is recycling all about?  Here is a brief primer;

Recycling is all about stopping any current w3wp.exe processes that are running for a particular Web Application Pool and starting a new one.  The purpose of this maintenance routine is to clear the cache and start afresh! This routine obviously causes SharePoint to be quite slow when accessed for the first time after the recycling process.  This is because when accessing a SharePoint Site/Page for the first time, that information needs to be re-compiled and loaded into memory again.

So what can we do about this first time slowness that occurs every morning?  Wake SharePoint up!

There are an array of scripts that have been developed by 3rd party developers that can be scheduled to run straight after the recycle occurs.  These scripts are usually required to be modified for your Web applications in question.

With the introduction of IIS 7.5 and Windows 2008 R2 however, there is an actual module developed by the IIS team that will integrate directly with IIS allowing you to seamlessly enable your application pools to load your web applications after a recycle occurs.  You can download the extension here; http://www.iis.net/expand/ApplicationWarmUp At the time of this writing, the Application Warm-Up module is still in beta, but I have been using it on our production servers for over a month without any hiccups.

So let’s begin our step by step guide.  Download and launch the executable from the above site.

Click Install and then click Finish.  As you can see, the installation process is quite simple.

Launch IIS Manager and click on one of your SharePoint Sites.  In the middle pane, you will notice a new item listed under IIS titled, Application Warm-Up.

Double Click on Application Warm-Up.

Under Actions located on the far right pane, select Settings

Ensure that both options available are selected and ticked.

We also now need to add a request which is usually the main page of your SharePoint Site.  This is achieved under Actions, Select Add Request and enter the URL of your SharePoint Site.

The last area that you will need to venture into is also located under Actions / Edit User Context.  Here you will need to specify your Authentication settings, otherwise the module will not work and you will receive the below warning message in your Windows Application Even Log.

Log Name:      Application
Source:        IIS Application Warmup Module
Date:          8/03/2010 7:31:43 AM
Event ID:      1003
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      SERVERNAME

Description:
The description for Event ID 1003 from source IIS Application Warmup Module cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

/default.aspx
MACHINE/WEBROOT/APPHOST/SharePoint Central Administration v3/
Unauthorized

Here I have specified “Set Username and Type only” for the mode and “Windows” for the Type.  Lastly, specify an account that has access to load the SharePoint Web Application.

That’s all that is to it.  All you need to do now is replicate this for each SharePoint Web application on each of your SharePoint Web Front Ends.

This neat little module has a number of advantages over scheduled scripts as it seamlessly warms up your SharePoint Web applications regardless of when the Application Pool is recycled including when you re-start your servers or re-start IIS.  Please note, this little module also works with all ASP.Net applications!

Before I let you go, if you are after a neat utility for IIS7, Spencer Harbar has developed an Application Pool Recycle Utility which also incorporates a Warm Up tool  You can download it here; http://www.harbar.net/articles/apm.aspx

Resources

IIS.Net – Application Warm up http://www.iis.net/expand/ApplicationWarmUp

IIS.Net – Using the IIS Application Warm-Up Module http://learn.iis.net/page.aspx/688/using-the-iis-application-warm-up-module/

Welcome back to the second article in this series on upgrading a SharePoint 2007 content database to SharePoint 2010.  In part 1 we deep dived into the preupgrade tool that Microsoft made available with SharePoint 2007 SP2 and today we will complete our upgrade journey utilising one of the 3 upgrade models that are available to you by Microsoft.  These are listed as follows;

1. In-place upgrade
2. Database attach upgrade to a new farm
3. Hybrid approach (Read –only databases or Detach databases)

There is a wealth of information regarding these different approaches on the Microsoft TechNet site under the Upgrade and Migration Resource Center for SharePoint 2010. I will also outline other resources at the end of this article for convenience.

The upgrade model that I have chosen in this article series is the Database attach upgrade approach in which I will outline in this step by step guide.  The upgrade choice you choose is dependent on a number of factors such as how much down time can you afford and whether you are moving onto newer hardware.  All three options have their strong and weak points which is outlined in the following TechNet article; Determine Upgrade approach (SharePoint 2010)

This article is assuming that your SharePoint 2010 environment is up and running (albeit in beta form).  I have published a 3 part series in getting your SharePoint 2010 environment up and running that you can access from the following links;

1. Installing SharePoint 2010 Beta on a Windows 2008 R2 Server
2. Configuring SharePoint 2010 (Beta) Service Applications and User Profile Service Synchronization
3. Creating your first SharePoint 2010 Beta Web Application and Site Collection

When using the database attach method to upgrade your databases to SharePoint 2010, you need to be aware that none of your configuration settings in SharePoint 2007 will migrate.  You will need to ensure that you have replicated your 2007 environment in the newly created 2010 farm.  Some of the items to consider include the following;

• Outgoing email server
• Alternate Access Mappings (AAM)
• Quota templates
• Included paths
• Install any custom or 3rd party features, including web parts, solutions
• Custom site definitions
• Custom CSS

In order for you to perform a database attach upgrade into your SharePoint 2010 environment you need to ensure that you have created a new web application.  If you have not done so, you can follow my step by step guide on Creating your first SharePoint 2010 Beta Web Application and Site Collection.

Step 1 :: Restoring a copy of your SharePoint 2007 content database

Now that we have ensured that all our configuration settings are in place, and that all custom features, web parts and solutions have been re-instated, we can now proceed with our upgrade.  You will need to firstly backup and take a copy of your SharePoint 2007 content database and restore it to the newly created SharePoint 2010 farm.

I’m performing my database restore utilising SQL 2008 Management Console.  Right click on Databases and select Restore Database.

Select your source and destination as follows;

Click on Options and ensure you have selected Overwrite the existing database.

Click OK.

We should receive the following confirmation message once the database has been successfully restored.

Step 2 :: Verifying the Content Database

As you have already noticed from our first article, in particular with the introduction of the preupgrade check tool, Microsoft have done a great job in providing us with the necessary tools to ensure a successful upgrade.  The next tool that we will be using is the Test-SPContentDatabase Windows PowerShell cmdlet.  This cmdlet will test and verify that any custom components that are required for this content database has been installed and configured in the SharePoint 2010 environment.

Test-SPContentDatabase –Name <database name> -WebApplication <URL>

Test-SPContentDatabase –Name WSS_Content_Intranet -WebApplication http://intranet.georgekhalil.com

stsadm -o addcontentdb -url <URL> -databasename <database name>

If one is listed, you can remove the existing attached database by clicking on the actual database name and then clicking on the “Remove content database” check box.

You will receive the above warning which is safe to ignore.  In this instance we are not deleting the actual database but disassociating it from the selected Web Application.  This is the exact same behaviour that was available to us in SharePoint 2007.

We can now proceed and attach our restored SharePoint 2007 database via the following stsadm command line;

stsadm -o addcontentdb -url <URL> -databasename <database name>

In my instance, the command looked as follows;

stsadm -o addcontentdb -url http://intranet.georgekhalil.com -databasename WSS_Content_Intranet

You will eventually receive a message similar to the below advising that the upgrade was completed albeit with errors in my case.  You should review the upgrade log file which is quite extensive and lengthy, and sure enough the errors were all related to missing features etc which I was already aware of.

We can now verify that the upgrade was completed successfully by first navigating back to Central Administration / Application Management / Manage content databases, which now displays the upgraded database under my designated Web Application.

We can also view the upgrade status page which is located within Central Administration / Upgrade and Migration / Check upgrade status.  The page will list all previous upgrade attempts and summarise the number of errors and warnings that may have been encountered.  In my case, there were a number of features that were not installed in the new SharePoint 2010 farm that the current portal relies on.  All of the upgrade logs are located in the following location, providing you with finer detail on the errors and warnings encountered;

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS

By default, your site will retain it’s 2007 theme which Microsoft have done on purpose and you will need to manually change this 2010 if you wish to do so.  This is referred to as the “Visual Upgrade”, providing site administrators the ability to switch to the new look and feel at their own leisure.  This is a great move by the SharePoint product team as the new interface can be quite overwhelming to begin with.  Think about the move from Office 2003-2007 with the introduction of the new ribbon interface.   There was a week or two of frustration for most users before eventually getting the hang of it and finding the new interface to be more productive.

The below screen capture is my upgraded SharePoint 2010 portal running in “SharePoint 2007 theme mode”.

To perform the Visual upgrade, navigate to Site Actions / Visual Upgrade.

Here you are provided with 3 options in which I will select “Use the new SharePoint user interface, and don’t ask me again”.  After clicking on OK, I am now presented with the same site utilising the default SharePoint 2010 theme.

We have now successfully upgraded one of our SharePoint 2010 content databases housing our main Intranet portal, albeit with some missing web parts and features.  So what’s next on the agenda?  Upgrading My Sites of course!  This will involve attaching and upgrading your Shared Service Provider (SSP) to upgrade your user profile information followed by upgrading the My Sites content database.  This process will be left for a future post.

I hope you have found this 2 part series useful and I am interested hear how many of you have attempted a SharePoint 2010 upgrade and your experiences.

Resources from TechNet

Determine Upgrade approach (SharePoint 2010)

Microsoft SharePoint 2010 Products Upgrade Approaches – Diagrams

Upgrading to SharePoint Server 2010

Preparing to upgrade to SharePoint 2010 Products

Attach databases and upgrade to SharePoint Server 2010

_______________________________________________________________

Articles in this series

1. Upgrading your Content DB to SharePoint 2010 – Part 1, The preupgradecheck
2. Upgrading your Content DB to SharePoint 2010 – Part 2, Database Attach method

I’m sure there are a lot of SharePointers out there who are excited about the 2010 release and as I have been working my way through the installation and configuration of this updated beast, I have also been providing you with posts along the way sharing my experiences.  Today isn’t any different, and in this two part series I will be providing you with a guide to upgrading your SharePoint 2007 content databases to SharePoint 2010.  There are already some great resources out there regarding upgrade options and preparation guidance including those from Microsoft on the TechNet Site and others which I will list at the end of this article. The prime focus of part 1 of this 2 part series will be to outline the many tools that are available to you at no cost, assisting and ensuring that your SharePoint  farm and SharePoint databases are up to scratch and ready for 2010.  The series will proceed as follows;

1. Upgrading your Content DB to SharePoint 2010 –The preupgradecheck
2. Upgrading your Content DB to SharePoint 2010 – Using the Database Attach method

First and foremost, Microsoft have provided us with the pre-upgrade command line stsadm parameter switch in SharePoint 2007 Service Pack 2, which has been further updated with the latest October 2009 Cumulative Update (CU),. This will be our primary analysis and reporting tool providing us with invaluable information regarding your SharePoint 2007 farm and actions that may be required to be taken prior to upgrading to SharePoint 2010, so let’s begin our journey here.

Launch a Windows command prompt on your SharePoint Server and type the following stsadm command from the following directory;

%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\bin

stsadm.exe -o preupgradecheck

STSADM -o deactivatefeature -id 758a6fdf-005a-bcaa-0ea0-1d4931979fec -url http://intranet.georgekhalil.com -force

In addition to the STSADM command line tool, there are a couple of other tools that really assisted with the process of removing rogue features where the stsadm actually failed.  The first tool which is provided by Gilham Consulting , is the WssAnalyzeFeatures tool, which will assist in listing features against their GUID similar to that of the preupgrade report.

The second tool required as part of the removal process is the WssRemoveFeatureFromSite which will remove rogue features installed in your SharePoint farm where the stsadm –o deactivate feature might fail.  Eventually you would want the output of the WssAnalyzeFeatures command to display no problems.

So after re-installing or removing any rogue features and site definitions we should be ready to proceed with our SharePoint 2010 upgrade, taking into account that there were no other problematic areas that were outlined in the preupgrade check.

There are several other tools worth mentioning that also assisted with outputting information and configuration details of my farm and assisted with the SharePoint farm cleansing process.

The SharePoint Feature Administration and Clean Up Tool which you can download from the Codeplex site,  does a great job in listing Feature Definitions across Site Collections and Sub Webs and cleanly uninstalling them.  My favourite feature in this tool is its ability to locate any faulty features and then providing you with the ability to remove them from your entire farm.

Clicking on the Find Faulty Feature in Farm should hopefully return the following “No Faulty Feature was found” message.

SharePoint Manager 2007 (note there is already a SharePoint Manager 2010 available) can also be downloaded from the CodePlex Site and is a great tool for administrators and developers in providing an understanding of any SharePoint farm topology.

My last tool of choice is from Bamboo Solutions, namely the Bamboo SharePoint Analyzer.  Similar to that of SharePoint Manager 2007, this utility also does a great job is listing everything you need to know about your SharePoint environment and your entire farm topology.  This is also available as a free download and should be installed as part of any SharePoint Farm deployment.  These tools will also greatly assist in replicating your environment for your SharePoint 2010 deployment.

Hopefully I have provided you with a comprehensive list of tools and tips to assist you in getting your Content DB’s primed for your SharePoint 2010 upgrade.  In the next part of this series I will focus on the actual upgrade itself utilising the Database attach method, so stay tuned!

References:

Upgrading to SharePoint Server 2010 – TechNet

Run the pre-upgrade checker (SharePoint Server 2010) – TechNet

5 Reasons SharePoint 2010 PreUpgradeCheck is better than Prescan – SharePoint Joel

Preparing for Upgrade to 2010 Today – Part 1 Preupgradecheck – SharePoint Joel

Planning for SharePoint 2010 – Upgrade Planning Part 4 – Using preupgradecheck – Chandima.Net

I first introduced the Data View Web Part (DVWP) in one of my articles earlier this year which you can access here and discussed a couple of scenarios in which you can utilise the DVWP.  In today’s example I will elaborate on the DVWP and provide you with a step by step scenario in how you can display a SharePoint list from one site to another site.  You can utilise the DVWP to connect to SharePoint Lists, Libraries, Database Connections etc within any site in a site collection and in today’s example I will replicate and display a SharePoint Calendar list from one Team Site to another Team Site.

The DVWP is hidden within SharePoint Designer (which is now free) so let’s launch SPD.

We need to insert a new web part zone to enable us to insert our Data view web part into our ASPX page.

Navigate to Insert / SharePoint Controls / Web Part Zone.  Now that we have our zone created, we can proceed to insert our DVWP.

Navigate to Insert / SharePoint Controls / Data View.

You will also notice that our web part zone that we have just inserted has realised that we have requested to add a DVWP and is asking for the source data.

By default, the Data Source Library will display SharePoint lists from the current site. In our example we are required to connect to a list (a calendar list in our case) from another team site.

Under the Data Source Library we will click on “Connect to another library” The below screen capture is displayed.

Click Add

You will be prompted to specify a display name and location for the collection properties.

Click OK and then OK again.

You will then notice that the team site that we have just added will also be displayed under the data source library with its SharePoint lists and libraries.

In today’s example we are connecting to and replicating a SharePoint calendar List from the “Assurance Services Team Site” to be displayed on the current site.

I will expand SharePoint Lists and click on the relevant SharePoint List that I will be adding which will display a context menu in which I will click on Show Data. These instructions are also displayed in the web part zone that we have added earlier

The data source details (fields) will also be displayed.

Highlight the fields/columns that you would like to include in the DVWP.

We will now click on “Insert Selected Fields as.. “ and in this example I will click on “multiple item view”

The information will then be inserted into the DVWP as follows;

We can now be a fit fancy and customise the formatting of some of the fields that are being displayed. The first area of customisation is changing the date format so I will click on the End Time field until the arrow appears.

I will now click on DateTime formatting options and select my desired Date Format and deselect Show Time.

Click OK

You will now notice that the information in the DVWP will now be displayed accordingly;

You will also notice in this example that the “Description” field has come in with html code as opposed to rich text. In this instance I will click on the arrow beside the description column

You will notice that the Data Field “Description” is being formatted as Text.

I will click on the Format as: drop down and select Rich Text.

The Div tags have now disappeared and the description field is formatted correctly.

I will now make some further customisations, but this time to the entire list such as sorting and grouping etc. You do so by highlighting the entire DVWP and clicking on the arrow beside the web part located on the top right corner.

The “Common Data view Tasks” appear in which you have free reign to make further customisations to formatting, filtering, sorting and grouping, conditional formatting etc.

After making your customisation we are pretty much done and below is my end result.  The first screen capture is the original SharePoint Calendar list “Important Dates to Remember” located in one site and the other is the Data View Web Part that we have just created located in another site.

SharePoint Calendar List – Important Dates to Remember

Data View Web Part – Important Dates to Remember

Don’t forget to subscribe to future articles via your RSS reader and follow me on twitter @georgekhalil.

This question pops up every now and then and that is, how do I create a “quote of the day” web part to place on the front page of my SharePoint Intranet Portal.  Quite easily is my response and in today’s post I will demonstrate how you can utilise the Content Editor Web Part (CEWP) to easily achieve this.  As way of background, the CEWP is an out of the box SharePoint web part allowing you to add formatted text, tables, hyperlinks and images to a Web Part page.  In addition to the above, the CEWP also allows you to add HTML content which we will utilise in the below example to create our quote of the day web part.   The end product will look similar to the below screen capture;

You can add the CEWP to any Web Part zone but in most instances your “quote of the day” web part will reside on the portal’s front page visible to all users.

I will begin my navigating to Site Actions / Edit Page and click on Add a Web Part on the desired zone on your web part page.

The Add Web Parts dialog window will then open and I will scroll down and select the “Content Editor Web Part” located under the Miscellaneous section.

Click Add.  The Content Editor Web Part will now appear in the web part zone as per the below screen capture.

We will now click on “open the tool pane” which will open the modify web part window.

I am utilising a 3rd party service from “Brainy Quote” which will provide us with a direct feed into their quotes which will update automatically on a daily basis.  Copy the below code into the Content Editor Web Part “Source Editor” as per the below screen capture.  More information and advanced instructions on customising the text can be found here.

<script type="text/javascript" sc="http://www.brainyquote.com/link/quotebr.js"></script>

After adding the code, click OK.  I will now proceed and make some cosmetic changes to the Content Editor Web Part, such as changing the Title and Chrome Type as per the below screen capture.  Note that I have specifically specified a Chrome Type of None as the Title is already included as part of the javascript provided by brainy quote.

After making the changes, I will click Apply and OK.  The Quote of the day by default will look like the below;

However, because we are utilising the Content Editor Web Part, we can spruce it up a little by adding an image beside our text using code similar to the below.  In the below example I am inserting an image called quote.png which I have sourced from the world wide web.

<P><IMG style="BORDER-BOTTOM: 0px solid; BORDER-LEFT: 0px solid; BORDER-TOP: 0px solid; BORDER-RIGHT: 0px solid" border=0 align=left src="/PublishingImages/quote.png"></P><SCRIPT type=text/javascript src="http://www.brainyquote.com/link/quotebr.js"></SCRIPT>

The end result will look as follows;

As you can see, we have easily utilised the Content Editor Web Part to insert html code which pulls information from a 3rd party quoting service in a matter of minutes.  I have been using brainy quote on our SharePoint Intranet Portal for over 12 months without any hiccups and the quotes which are updated daily are enjoyed by all.

If you have come across other methods or services for creating your Quote of the Day web part please let me know using the comments below.

Welcome back to the final post in this 2 part series, Integrating Exchange 2007 MRM with SharePoint Document Libraries.  Today’s post will wrap things up by going through the process of mail enabling an existing SharePoint document library and creating a new managed content setting in Exchange 2007 providing us with the ability to journal a copy of all messages moved into our “Project XYZ” managed folder located in Outlook, into our Shared collaborative Document Library under our Project Team Site.

Recall from part 1, that the objective of integrating Exchange MRM with SharePoint is to provide us with the ability to store and centralise all emails pertaining to a specific project from multiple users into a single SharePoint document library, that can be easily accessed by the Project Team.  If you missed the initial setup of Exchange MRM, you can access part 1 of this series here.

We finished off our last post by having our Project XYZ Managed Folder automatically pre-created for our specified Exchange users as per the below screen shot.

This has provided all users from the Project XYZ Team site the capability of moving all email records in relation to Project XYZ into this so called “dumping ground”.  At the moment, it’s fairly static and the information “dumped” into this folder isn’t going anywhere any time soon.  But this will now change by creating a new “Managed Content Settings” policy in Exchange 2007.  But just before we go ahead, we need to ensure we have our SharePoint Document Library ready to receive incoming emails.

To mail enable a SharePoint Document Library, navigate to the Project XYZ Document Library in question and click Settings / Document Library Settings / and click on Incoming e-mail settings under Communications.

We will then fill out the details as per the below screen shot.

This will go ahead and create the corresponding Contact address in Exchange 2007.  Please note this article is assuming that your SharePoint farm has been correctly setup to receive Incoming mail.  Click on the following TechNet article for further instructions on how this can be achieved; http://technet.microsoft.com/en-us/library/cc262947.aspx

We can now proceed with the creation of the Exchange Managed Content Setting for our Managed Folder.

To so, navigate to Mailbox / Managed Custom Folders / click on the newly created custom folder, in our case Project XYZ and then click on New Managed Content Settings.

The below wizard is invoked and we will specify the following details as per the below screen shot.

Your goal here should be defined to meet the business requirements and in this example we will want to keep items that are moved into the Project XYZ managed folder for 30 days. After the 30 day period ,the items are permanently deleted to empty the user’s Project XYZ custom folder.

Do not fear however!!  In the next screen we will specify our Journaling options providing us with the capability to auto forward a copy to our SharePoint Email Enabled Document Library that we had created earlier. One of the advantages of using Managed Content Settings and Journaling with SharePoint enabled Libraries, is that you can specify the format of the email message and hence I have selected Outlook Message Format to ensure greatest compatibility.

Click New to Finish.

You will now notice that our Managed Content Settings has been applied against our Managed Custom Folder as per the below screen shot.

That’s it!  Based on your Managed Folder Assistant Schedule that we configured in part 1, all email records that are moved into the Project XYZ Managed Folder in Outlook will be copied to the Project XYZ Document Library as well.  In order to expedite the process and to ensure that it is all working, you can run the following Exchange Management Shell command;

Start-ManagedFolderAssistant

Once the Managed Folder Assistant has been initiated, it should only be a matter of a couple of minutes until you see your SharePoint Document Library populated as follows.

The Folder Assistant is intelligent enough to only copy the emails that are stored under the Managed Folder in Outlook once, avoiding any duplication.  It there are emails with the exact same subject line, SharePoint is also intelligent enough to follow our settings that we configured earlier for our email enabled SharePoint Library. In my setup we set it to not overwrite and hence will append the subject with a unique number as per the below screen shot.

In summary, Exchange 2007 MRM and SharePoint Document Libraries has enabled us to control the lifespan of items that are moved into our Project XYZ Managed Folder that we have created in Exchange and the capability to journal a copy of all records that are moved into this folder to our SharePoint document library for collaborative and archival reasons.

Hope you enjoyed this two part series and am sure you will find use with integrating these two technologies together to meet your business requirements.

There are two technologies in my IT Pro life that I am very passionate about, SharePoint and Exchange, so why not incorporate both passions in a single blog post. In this two part series I will be discussing how we can manage email records from our Exchange mailboxes and archive them in SharePoint Document Libraries for compliance or collaboration reasons.  Exchange 2007 introduced a great new feature set in the name of “Messaging Records Management” or commonly referred to as MRM.  Managed Default Folders is a key component of MRM which will assist us in achieving our archiving strategy.  Exchange 2007’s MRM functionality provides organisations with the ability to set email-retention policies, the ability to manage content residing in mailboxes and to establish an archiving strategy to SharePoint Document Libraries.

This is a great feature when you want to combine email records from various users working on a particular project and have them reside under the Team SharePoint Site Document Library. In this 2 part post I will provide step by step instructions on how this can be achieved with today’s post focusing on Exchange and the creation of our managed “project” folder .

So let’s begin by firing up the Exchange Management Console and navigating to Organization Configuration / Mailbox and then click on the Managed Default Folders Tab. You will notice the system default folders listed as per the below screen shot.

In our case we will create a new Managed Custom Folder for a specific project that we will later integrate with a specific document library located under our project team site.

In order to create our Managed Custom Folder, navigate to Actions and select New Managed Custom Folder..to invoke the wizard.

Enter the Name, Display Name and Description similar to the below screen shot.

Please take note of the Exchange Enterprise CAL requirement.

After filling the details click New. Your managed folder has now been created and listed under the Managed Custom Folders Tab per the below screenshot.

If you are an Exchange Management Shell person and would like to create a managed custom folder that way, all you need to do is simply type in the below command.

New-ManagedFolder -Name Project XYZ -FolderName “Project XYZ”

Now that our Managed Custom Folder has been created, we need to create a Managed Folder Mailbox policy.   Also located under Actions, Select New Managed Folder Mailbox Policy …

Creating a managed folder mailbox policy setting is great when grouping together a set of managed folders that you can then assign to a user mailbox in the one step.

Type in your managed folder mailbox policy name and then select Add to select the Managed Custom folder that we had just created earlier.

Your newly created policy will now be listed under the Managed Folder Mailbox Policies Tab as per the below screen shot.

We now have the capability to assign this policy to our users. So let’s now do so by navigating to Recipient Configuration / Mailbox. Right click on your user and select Properties / Mailbox Settings.

Select Messaging Records Management and then click on properties. From here, click on browse and select the Policy that we have just created.

When applying the settings you will receive a warning regarding compatibility with different Outlook versions, but we can ignore this warning as we are all running Outlook 2007/10 right?

Now that we have created our custom managed folder and policy we need to ensure that our Managed Folder Assistant Schedule has been setup. To so, navigate to Server Configuration / Mailbox and right click on the top pane on your server name and select properties. Then click on the Messaging Records Management tab.

By default it will be set to “Never Run”. We will click on Customize and set a schedule for it to run during non business office hours.

Now rather than waiting for the next scheduled time we can force the process via the Exchange Management Shell by running the following command.

Start-ManagedFolderAssistant

The below entry should appear in your Windows Application Event Log when the Managed Folder Assistant routine is run.

Event Type: Information

Event Source: MSExchange Assistants

Event Category: Assistants

Event ID: 9022

Date: 16/07/2009

Time: 11:01:18 AM

User: N/A

Computer: EXCHANGESERVER

Description:

Service MSExchangeMailboxAssistants. Managed Folder Mailbox Assistant for database Users Mailbox Database/Users Mailbox Database (ed6raqeq29db3-7301-4443-8917-a3b6e7857dd1) has finished an on-demand request. 1002 out of 1002 mailboxes were successfully processed. 0 mailboxes were skipped due to errors.

I can now open up Outlook for the user we applied the policy to and see that the Project XYZ managed folder has been created and listed under Managed Folders.  Remember, this is the folder that our user can now drag emails into for compliance or archive reasons.

Now that we have successfully created and deployed our Managed Folder Project XYZ we will continue our journey in Part 2 where we will mail enable a SharePoint Document Library providing it with an SMTP address and creating a Managed Content Setting that will be applied to our manage custom folder “Project XYZ”.  This will enable us to control the lifespan of items that are moved into our Project  XYZ Managed Folder that we have created and to also enable journaling on that folder to forward a copy to an alternative address, in our case the SharePoint Document Library SMTP address for archive.

If you would like to notified of future articles via email click here or subscribe via RSS.