Archive for SharePoint 2007

Using IE10 With SharePoint? You Need This Patch!

If you’re running Internet Explorer 10, you may have noticed that your SharePoint environment isn’t responding in the way that you have come to expect.  It turns out, the issue isn’t with your browser!  Instead, the problem is with the server.

In short, because ASP.NET was created before Internet Explorer 10 was expected.  ASP.NET has a file that tracks browser versions in order to know how to respond when the web pages are loaded.  Unfortunately, this file (browser definition file) runs out with Internet Explorer 9.  As a result, your environment doesn’t know how to handle Internet Explorer 10 since it doesn’t recognize it as a modern browser type.

When Internet Explorer 10 hits a SharePoint environment, SharePoint treats the browser as if it is Internet Explorer 6.  This prevents many of the scripts used by SharePoint and CorasWorks from operating correctly.  This is a frustrating condition but one that can be solved.

Microsoft has issued hot fixes for the web servers.  The hot fix that needs to be installed differs depending upon the version of .NET installed on your servers:

The hot fixes perform two specific steps: they update the browser version files for Internet Explorer and Firefox (ie.browser and firefox.browser, respectively) to account for the newer browser versions.  That’s all they do!

CorasWorks is recommending the installation of this update within all of our customer’s environments.  We’re dependent upon SharePoint and it responding correctly to your browser.  As these hot fixes are so specific (updating the browser files), installing them is straightforward and worth the results.

Microsoft has identified ASP.NET to be the source of this problem:

To learn more, be sure to check out Scott Hanselman’s blog article on this issue:


jQuery UI Datepicker, SharePoint Style


Posted by Steve Evangelista, CorasWorks Professional Services Consultant

So you’ve made the decision to create a custom form, or maybe display, within SharePoint and want a nice-looking Datepicker to go with it. If you’ve done anything with jQuery you’ve likely heard of or used the jQuery UI widgets (Datepicker here) so you run over and grab a copy to use. You create your input, initialize the Datepicker widget, and boom! – you’re in business.

The only problem is your über-functional Datepicker doesn’t look much like the native SharePoint date picker your users know and (perhaps, but not likely) love. No worries though; just apply a few of the Datepicker widget’s options, add in some targeted CSS, and your Datepicker will have all the great features of the jQuery UI while integrating seamlessly into SharePoint’s design.

First, the Datepicker options you’ll want:

$(‘#YourDateInput’).datepicker({dateFormat:’yy-mm-dd’,showOn: “both”,buttonImage: “/_layouts/images/calendar.gif”,buttonImageOnly:true});
  • dateFormat – You’ll want to use this if your solution will write back the value in the Datepicker, as this is the format SharePoint will require when setting a Date value via web services, CSOM, etc.
  • showOn – This tells the Datepicker to pop the Calendar upon clicking inside the <input> (focus), clicking the icon (button) or both (both). I prefer the latter but for a true one-to-one experience like the native SharePoint date picker, you’ll want “button.”
  • buttonImage – The path to the image you want displayed as part of the Datepicker; this is the server-relative path to the same icon used by SharePoint’s native date pickers.
  • buttonImageOnly – By setting it to “true,” this ensures only the icon image is rendered, instead of it appearing inside a button element.

You’ve now got a Datepicker widget that is much closer in appearance to the native SharePoint date picker. Now let’s just apply some CSS to get the calendar icon spaced exactly right…

img.ui-datepicker-trigger {padding:0 0 5px 4px;vertical-align:middle;cursor:pointer}
  • The padding specified is 4px left and 5px from the bottom; this puts the calendar icon in the right spacing relative to the input box.
  • The vertical-align:middle, in combination with the padding, keeps the calendar in the ideal alignment.
  • The cursor:pointer ensures the user’s mouse takes on the “pointer” style when mousing over the calendar image.

Sometimes it’s the little things that make a solution feel “just right,” and having custom controls that seamlessly integrate into SharePoint’s UI are a great step in that direction.


SharePoint: Set It and Forget It, Right?

Since SharePoint v2, there has been serious uptake on implementing SharePoint within company environments. But what was once awesome is now becoming just another server of many. I put to you, this is a problem. The trend I see today is two-fold:



Let’s discuss what you are managing right now;

· Active Directory & ADFS· Firewalls

· Load Balancers

· Switches

· VPNs

· Ext. Cloud Environments

· SQL Server


· Office 365

· Exchange

· Live Meeting or Lync· SharePoint

· External Chat

· Web Sites


· Desktops

· VOIP & Cell Phones

· Anti-Virus

· Printers

· Office Networks


Did you notice SharePoint in there? In terms of importance, what is getting your time? Probably the top three are SQL/Oracle, Exchange, and Firewalls/AD. What is nice is that the latter pretty much doesn’t change except for those pesky updates you keep doing. So what happens, servers that are running SharePoint don’t get their service packs, servers aren’t cleaned, etc.  I think you get the picture.

Some contend they keep all their servers and services up to date, but we have found through our many consulting engagements that SharePoint environments are left to fend for themselves and are afterthoughts in the sea of other servers and services that are being managed.

Even more important there are special activities that relate just to SharePoint that you wouldn’t know if you haven’t read through all the Microsoft Best Practice guides, took all the tests, or read all the books.

So what do you manage in SharePoint and how often do you? Below are just SOME of the items that need to be managed:

Indexes optimized, SQL DBs optimized, Content DBs under control, Latest Software updates applied, Server Updates applied, Logs reviewed and cleaned, Review your quotas, Defrag your DB and Index, Review your backup strategies, are they still working, Web Applications optimized, architecture optimized? What does your governance process look like, your environment setup, good architecture, how’s your latency?

We see so many customers where we make simple recommendations like moving site collections to proper content databases, dedicating a server for search, setting quotas, all of which would be found if maintenance was performed on a continuous basis.

Worse yet, take the chart below, which shows us that over time, server performance goes down and latency goes up leading to a reactive approach to fixing problems.

But hey this isn’t you – couldn’t be, until that fateful day, search is running slow or you just aren’t getting the same performance from the environment you used to. People’s MySites are taking longer to come up.

But what could it be, I haven’t changed anything. That is the point!

You must manage your SharePoint environment diligently if you want to get the best performance out if it. But best performance isn’t just server side, it is client side too, how is it being used can mean the same as what is being used. But that is for a different conversation.

You took the time to get the environment up, your users trained, using it, and you built your slice of heaven, but that slice has some mold on it and needs to be cleaned.

SharePoint must be managed both inside and out. Some of you have dedicated teams to this objective and are doing a great job. You probably don’t need any help from anyone. However, we have seen these performance-related issues enough to realize that lack of SharePoint Maintenance is prevalent.

So for those of you who don’t have that dedicated team, how important do you place SharePoint in your hierarchy of management?

To be clear, on average, your SharePoint environment should be reviewed one day per week. That is four days per month of effort. Every three months, you will need an extra 3-5 days to handle service packs, hotfixes, data moves, etc… That means you should be spending a total of one week per month maintaining your SharePoint environment no matter how small it is. That’s you, right?

To really hammer home this point, are you ready for Office 15? Maintenance and Governance really matter now more than ever.  Is your investment in the right place to move forward?

So my final question: why not hire CorasWorks to help maintain your investment? You get your oil changed by a specialist, why not do the same for your SharePoint investment. It costs you more when problems come up, so intercept those problems before they really cost you and make your investment count.

Contact to learn more and we’ll be glad to review with you how we can help your investment stay solid.

Adam Macaulay


Adam Macaulay
Co-Founder & Principle Solutions Architect
tel 703 797 1881 x103
cell 240 447 9948
twitter aemacaulay

Why Some Organizations Succeed…and Others Fail…with SharePoint

Posted by Gary Voight, CorasWorks President and CEO

I was having a discussion with a CorasWorks customer last week and we evolved into the topic of what it takes to have a successful SharePoint implementation.  This client has had a great deal of success on SharePoint….measured by a rich set of applications and strong end user acceptance.  It was fascinating to hear his story.  It also got me thinking about why some organizations succeed…and fail…with SharePoint.

Before going further into this topic, let me segue a bit.  I have been in the SharePoint world for a bit over four years.  CorasWorks has been in the SharePoint world since early 2003…almost nine years. CorasWorks initially built and sold Web parts, subsequently created a builder package called the WorkPlace Suite, then re-engineered that package into a build & run-time system, and then built Project and Portfolio Management (PPM) and CorasWorks Idea & Innovation Management (Cim) applications.  Over the past two years CorasWorks has been building up a professional services team and has delivered several custom-built applications.  We are totally invested in SharePoint and committed to its success.

I decided to profile a couple of successful SharePoint implementations, and a couple of failures. My attempt was to see if there are any significant lessons.  Here is my summary:


-          Automotive Manufacturer:  This company decided to use SharePoint for a Product Lifecycle Management (PLM) application in lieu of more established products available from their ERP and CAD vendors.  PLM is the process of managing the entire lifecycle of a product from conception, through design and manufacture, to service and disposal.  PLM is truly a collaborative application, and is often employed across customer-vendor lines.  This project was run by Engineering, with some oversight from IT.  This customer saw true value in SharePoint.  Had they pursued product alternatives from their ERP or CAD vendors, they would have paid $250,000 for licenses, plus another $150,000 to $200,000 for customization and implementation services.  In addition, the implementation looked difficult due to a steep learning curve of the products, likely locked them into an implementation vendor, and carried significant on-going cost and maintenance burden for when the product vendor shipped a new release.  As SharePoint had many of the capabilities needed for a PLM, this customer determined it would be simpler to build out their PLM functionality to more precisely meet their operational requirements.  It was also much less costly.  All products and services totaled around $250,000.  The customer was able to get what it needed, secure greater end user engagement, and have something they could easily maintain and extend.

-          Green Energy Company:  This company decided to use SharePoint as a platform for 20+ applications (ie. maintenance schedules, contract archive, PO log, Help Desk), along with a Portal for user access.  There were software packages for utility firms, but none were obvious fits.  Alternatively, they could have hired custom development firms, but these seemed expensive.  They needed to build and implement a main portal, but also needed sites for each plant, the capability for process management, ability to assign and manage tasks, and aggregate data into live reports/dashboards.  SharePoint was a great starting point, but the customer also recognized both capabilities and limitations of SharePoint out-of-the-box….and budgeted what was needed to complete the system to meet their requirements.  Even more important, the customer realized that SharePoint could be intimidating to users and managers.  Therefore, the IT implementation team was fanatical about providing ease-of-use, and truly committed to business and end user support. Although they also contracted much of the build work to CorasWorks, they also knew they could provide for on-going support and additional functionality as needed.

What these successful customers had in common were:

  • They understand the potential of SharePoint, but then realized that many of the “features” were actually only capabilities that required further development or configuration.
  • They understood and accepted SharePoint’s strengths and limitations.
  • They had projects with hard and measureable return on investments (ROI’s), and that this enabled them to gain management support
  • The implementers were focused on the needs of the business functions, and dedicated to ease-of-use and support.


-          Large IT product company:  This company invested in SharePoint 5-6 years ago.  They investigated the potential of SharePoint with Microsoft, and had the full enterprise product packaged into their enterprise agreement.  The CIO announced it to the rest of the company and set up a small IT team to provide some support.  Unfortunately, there was little consideration given to governance and not enough support. Further, no one was allowed to use third party tools.  What resulted was the creation of approximately 3,500 sites that did not have consistent navigation, users who were unable to effectively use what was built, confusion over the location of documents and lack of clarity on document revisions.  Few people were happy with SharePoint.  Approximately six months ago Jive Software was installed, and gained traction with users.  When I spoke to an engineering user he said that he got more use from Jive in six months than from SharePoint in five years.  He now thinks his company is phasing out SharePoint.

-          Financial Services firm:  This firm invested in SharePoint circa 2005.  They had heard some of the horror stories around unmanaged site creation, so they decided to apply strict governance and control.  Only IT could create a site and build out solutions.   Unfortunately, users got frustrated with the IT backlog as well as what they perceived as a lack of SharePoint intuitiveness.  One user group found a way to bring in the Confluence Wiki (Atlassian) and had a positive experience.  That alternative went viral.  When the financial services vertical segment experienced serious business problems during the financial crisis, the IT department lost its funding for SharePoint. The base SharePoint was retained, but has very little use and adoption.

What these failed firms had in common were:

  • SharePoint was rolled out without the enough education or support.
  • IT funding was minimal, and generally left up to the user functions.
  • User functions didn’t understand the difference between capabilities and a finished product.
  • No one was focused on ease-of-use and end user support.
  • They did not seem to have projects that had measureable return on investment (ROI), thus, did not attain management support.

I suspect we all have our own examples of positive and negative SharePoint implementations.  However, the reasons for the successes and failures summarized above apply to any product set.  The underlying difference between success and failure is commitmentIf your organization is not committed to a product, it will almost certainly fail.

Required CorasWorks PPM (all versions) Crawl Rule Exclusions in SharePoint Search (MOSS/2010 Server/Fast Search)

The CorasWorks PPM for SharePoint Solutions are built on top of Microsoft SharePoint and take advantage of all the SharePoint benefits including: rapid deployment, customization, single platform, and high customer acceptance.  Consequently, they also inherit some of the limitations SharePoint has, including those related to data aggregation and performance.  If an application is not designed with performance in mind from its inception, these limitations can become problem areas in a SharePoint infrastructure.

One of these problem areas revolve around performance and more specifically the performance of large amounts of aggregated data on a page, which can be significantly poor if the data is coming from many sources and is being aggregated in a single view.  An example of such aggregated data is a Program Management Office site aggregating project data from many projects around the organization.

In native SharePoint some of the steps that can be taken to reduce the possibility of poor performance, include server side caching and compression; with CorasWorks Solutions there is an additional layer that can be exploited to improve performance – the application layer.  The CorasWorks PPM Solutions make use of various caching techniques that reside in SharePoint, which get loaded into the server’s memory to improve aggregated data performance.  When the pages that make use of the cache are accessed by the first user, the data being aggregated is requested from the content database, aggregated and then cached.  All subsequent users access the cached data, which removes the need for the data from being requested from the content database and aggregated every time the view is accessed.

In addition to automatically caching the data for users, data can also be cached on demand.  In SharePoint’s Search, one of the ways that content gets added to the Search index is by the Search Crawler accessing many pages at the same time, including the pages that cache the CorasWorks PPM components.  When these cache pages get accessed a cache instance gets put into memory, and if multiple cache pages get accessed at the same time then multiple cache instances will get put into memory.  If there are many PPM sites and these get crawled at the same time, then many cache instances will get put into memory, which ultimately can result in low server memory and slow performance.

In order to overcome the SharePoint Search cache issues, it is required that all CorasWorks PPM sites are excluded from being crawled via an exclusion crawl rule.  The following are the steps required to create a crawl rule in Microsoft Office SharePoint Server 2007 and SharePoint Server 2010.  Search Server should also be configured to have these exclusions; however, instructions for creating crawl rules for Search Server are beyond the scope of this document.

How to create a Crawl Rule in SharePoint Server 2010
1. Go to SharePoint Central Administration.
2. Click on the Application Management link.
3. Under Service Applications, click on the Manage service applications link.
4. Click on the Search Service Application link or the link for the appropriate service application.
5. From the Search Administration page, click on the Crawl Rules link in the Crawling section.
6. Click on the New Crawl Rule button.
7. In the Path field, enter the URL for the CorasWorks PPM site.  If working with multiple CorasWorks PPM sites, it is recommended that the site at the highest level be included with the use of a wild card character to include all PPM sub sites.  If granular control is required, then multiple URLs can be added with a semi-colon “;” separating each URL.
8. In the Crawl Configuration field, select the Exclude all items in this path radial button.  Also check the Exclude complex ULRs check box.
9. Click OK.
(See sample exclusion rule below.)
How to create a Crawl Rule in Microsoft Office SharePoint Server 2007 (MOSS)
1. Go to SharePoint Central Administration.
2. Click on the appropriate Shared Services Administration link.
3. Under Search section, click on the Search Administration link.
4. From the Search Administration page, click on the Crawl Rules link in the Crawling section.
5. Click on the New Crawl Rule button.
6. In the Path field, enter the URL for the CorasWorks PPM site.  If working with multiple CorasWorks PPM sites, it is recommended that the site at the highest level be included with the use of a wild card character to include all PPM sub sites.  If granular control is required, then multiple URLs can be added with a semi-colon “;” separating each URL.
7. In the Crawl Configuration field, select the Exclude all items in this path radial button.  Also check the Exclude complex ULRs check box.
8. Click OK.

(See sample exclusion rule below.)

A Web Part or Web Form Control on this Page cannot be displayed or imported. The type is not registered as safe.


In SharePoint 2007 and SharePoint 2010 when a CorasWorks web part is added to a page the following error can be rendered.

“A Web Part or Web Form Control on this Page cannot be displayed or imported.  The type is not registered as safe.”

In SharePoint 2007 the error may look like the following image:

In SharePoint 2010 the error may look like the following image:

In SharePoint 2007 and SharePoint 2010 in order for a web part to function properly inside a web application, a web.config entry that deems the web part as safe is required.  The web.config entry is added automatically by SharePoint when the .cab file or .wsp solution that contains the web part is installed.  A sample web.config entry can be found below:

<SafeControl Assembly=”CorasWSC.Calendar.Display.Adapter, Version=, Culture=neutral, PublicKeyToken=279250fcb9073303″ Namespace=”CorasWSC.Calendar.Display” TypeName=”*” Safe=”True” SafeAgainstScript=”False” />


In certain cases when a web part has been imported into an web application and then placed onto a page without the required web.config entry made through a normal .cab or .wsp deployment, the “A Web Part or Web Form Control on this Page cannot be displayed or imported.  The type is not registered as safe.” error will be rendered.  To resolve this issue and clear the error, the web.part that is triggering the error must be installed/deployed or reinstalled/redeployed to the web application that has the problem.  The deployment can be done using Software Manager if using the CorasWorks Suite version 9, CorasWorks Installation Manager if using versions 10 and 11 of the CorasWorks Suite, or stsadm if using native SharePoint’s installation features.

If the web part has already been installed to the web application in question and the error is being encountered, a retraction and redeployment may be required.

IMPORTANT:  This issue is not a CorasWorks specific issue, but it is rather a SharePoint security design which prevents unsafe web part code from running on a page.

Upgrading SharePoint 2007 to SharePoint 2010 – Is upgrading the CorasWorks Suite to v11 prior to upgrading to SharePoint 2010 required?

We often get asked if upgrading the CorasWorks Suite to latest version is required before upgrading SharePoint 2007 to SharePoint 2010.  The answer is in case is short and simple – YES!  If your company is currently running an earlier version of the CorasWorks Suite, v10.4 or earlier on SharePoint 2007, it is required that the CorasWorks Suite is upgraded to the latest version, v11.x, prior to upgrading to SharePoint 2010.  The failure to upgrade the CorasWorks Suite version in SharePoint 2007 will result in outdated component references in SharePoint 2010, which can prevent SharePoint pages from loading.

IMPORTANT:  If you’re running the CorasWorks Suite v9 in your SharePoint 2007 environment, please read the following document before upgrading to SharePoint 2010: CorasWorks Workplace Suite v9 on SharePoint 2010: Known Issues.

In order for CorasWorks to provide support on upgrade related issues, this requirement must be met.  If you have any questions, please e-mail CorasWorks Support.


CorasWorks Support


Show Me How: Deploying the CorasWorks Client Controls program (MSI) via Group Policy

The following are instructions for deploying the CorasWorks Client Controls program (MSI) to computers in an Active Directory domain using a Group Policy. The components included in the CorasWorks Client Controls are the required client side components for the My Workplace for Outlook web part. The My Workplace for Outlook web part is part of the CorasWorks Workplace Suite version 9.

The instructions below were written against a Windows Server 2003 Active Directory Domain.

Step 1 – Create a Distribution Point

To assign a computer program, you must create a distribution point on the publishing server:

1. Log on to the server computer as an administrator.
2. Create a shared network folder where you will put the Microsoft Windows Installer package (.msi file) that you want to distribute.
3. Set permissions on the share to allow access to the distribution package.
4. Copy the “CorasWorks Client Controls Winter 2005.msi” to the distribution point (See image below).

Step 2 – Create a Group Policy Object

To create a Group Policy object (GPO) to use to distribute the software package:

1. Start the Active Directory Users and Computers snap-in. To do this, click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
2. In the console tree, right-click your domain, and then click Properties.
3. Click the Group Policy tab, and then click New.
4. Type a name for this new policy (for example, CW Client Controls Install), and then press ENTER.
5. Click Properties, and then click the Security tab.
6. Click to clear the Apply Group Policy check box for the security groups that you want to prevent from having this policy applied.
7. Click to select the Apply Group Policy check box for the groups that you want this policy to apply to.
8. When you are finished, click OK.

Step 3 – Assign a Package

To assign a program to computers that are running Windows Server 2003, Windows 2000, Windows XP Professional, Windows Vista, and Windows 7 or to users who are logging on to one of these workstations:

1. Start the Active Directory Users and Computers snap-in. To do this, click Start, point to Administrative Tools, and then click Active Directory Users and Computers.

2. In the console tree, right-click your domain, and then click Properties.

3. Click the Group Policy tab, select the group policy object that you want, and then click Edit.

4. Under Computer Configuration, expand Software Settings.

5. Right-click Software installation, point to New, and then click Package.

6. In the Open dialog box, type the full Universal Naming Convention (UNC) path of the shared installer package that you want. For example, \\file server\share\CorasWorks Client Controls Winter 2005.msi.

Important: Do not use the Browse button to access the location. Make sure that you use the UNC path to the shared installer package.

7. Click Open.

8. Click Assigned, and then click OK. The package is listed in the right pane of the Group Policy window.

9. Close the Group Policy snap-in, click OK, and then quit the Active Directory Users and Computers snap-in.

10. When the client computer starts, the managed software package is automatically installed.

Step 4 – Adding Sites Hosting the My Workplace for Outlook Component to Internet Explorer’s Local Intranet Zone (Optional)

By default, any Internet Explorer add-ons generate a pop-up to install or accept an add-on to run on the browser. In most situations where users running the add-ons are administrators on the local machine this is not an issue. However, in highly secure environments where users don’t have administrative control of their systems, these pop-ups can pose a problem because the users do not have the privileges to either install or run an add-on. An administrator can overcome this limitation by adding the SharePoint site URLs running the My Workplace for Outlook web part to the Internet Explorer’s Local Intranet Zone via Group Policy:

1. Start the Active Directory Users and Computers snap-in. To do this, click Start, point to Administrative Tools, and then click Active Directory Users and Computers.

2. In the console tree, right-click your domain, and then click Properties.

3. Click the Group Policy tab, and then click New.

4. Select the CW Client Controls Install policy and click on the Edit button.

5. Under Computer Configuration, expand Administrative Templates.

6. Expand Windows Components.

7. Expand Internet Explorer.

8. Expand Internet Control Panel.

9. Select Security Page.

10. Double click on the Site to Zone Assignment List.

11. Select Enabled in the Site to Zone Assignment List Properties window.

12. Click on the Show button.

13. Click the Add button from the Show Contents window.

14. In the Add Item window enter the following values:

In the Enter the name of the item to be added field, enter the URLs running the My Workplace for Outlook web part.

In the Enter the value of the item to be added, enter the number 1.

15. Once all the required URLs have been added, click the OK button

16. Click the OK button.

17. Click the OK button.

18. Close the Group Policy Object Editor

19. Click the OK button.

20. When the client computer starts, the URLs added to the Local Intranet Zone via Group Policy will be added to the workstations’ browsers.

If you have any questions regarding these instructions please contact CorasWorks Support.


Show Me How: Upgrading SharePoint 2007 based CorasWorks content to SharePoint 2010

Curious to see your SharePoint 2007 based CorasWorks applications in action running on SharePoint 2010? If so, you’re not the only one. Since SharePoint 2010 was released many customers have asked for guidance with upgrading their SharePoint 2007 based CorasWorks content to SharePoint 2010. This article was written as a quick and easy guide to help the curious minds with the upgrade and was written in a manner that simplifies the process.  I would recommend using these instructions for upgrading content in development and staging environments and ideally environments that can be scrapped and rebuilt.  As best practice, I always recommend using a more methodical approach when upgrading anything on a production environment.  A good framework to use when planning for a production farm upgrade is Microsoft’s Upgrade Cycle, which incorporates a multi-phased approach (Learn, Prepare, Test, Implement, and Validate) to allow IT Professionals and Developers thoroughly understand their environments before, during, and after an upgrade.  More information regarding the SharePoint 2010 upgrade process can be found here.

This document was written in the context of CorasWorks content and therefore instructions on the installation of SharePoint 2010 will be omitted as they are considered outside the scope.  The example included in this article uses two SharePoint deployments with SQL and SharePoint on separate servers and is applicable for both SharePoint Foundation 2010 and SharePoint Server 2010.

Upgrading SharePoint Content

In both SharePoint 2007 and SharePoint 2010 all of the web application content is stored in a web application’s content database(s). As in previous versions of SharePoint, in order to upgrade the content of a web application the content database(s) had to be upgraded. However, in the previous versions the process to upgrade a content database(s) was not the most user friendly.  In fact, the process was complex, cumbersome, and not to mention lengthy if multiple databases were being upgraded (upgrade was performed serially). In SharePoint 2010 the process has been simplified tremendously and improvements were made to support simultaneous upgrades of content databases (parallel).

The upgrade approach used in this upgrade scenario is the database attach upgrade, which takes a snapshot (via backup) of a web application’s content from a SharePoint 2007 farm and is migrated into a SharePoint 2010 environment.

I. SharePoint 2007 Requirements

In order for content to be successfully upgraded from SharePoint 2007 to SharePoint 2010 the SharePoint 2007 environment hosting the content must be on must be at least on Service Pack 2 (Version  More information on upgrading to SharePoint 2010 can be found here.

Validate that SharePoint meets the version minimum requirements.

1. Navigate to the web application which will be upgraded.

2. Click on “Site Actions” and select “Site Settings”.

3. Ensure that the version of SharePoint is or higher.

II. Determine the SharePoint 2007 content database name(s) to upgrade

In order to upgrade a web application to SharePoint 2010 we first have to figure out which content database the web application is using.  In this example I will be upgrading the content database belonging to a web application with the URL of http://sharepoint.cwtest.local.

The content databases associated with a web application can be viewed within Central Administration.  All the instructions in this section are to be performed on the SharePoint 2007 environment.

1. From the server hosting Central Administration open “Central Administration”.

2. Go to the “Application Management” tab.

3. Under the SharePoint Web Application Management section click on the “Content databases” link.

4. The web application with http://sharepoint.cwtest.local has one content database with the name of SharePoint_ContentDB.

III. Backing up SharePoint 2007 content

Once the version of SharePoint has been verified and the content database name has been determined, the next step is to backup the SharePoint 2007 content database(s) from SQL Server Management Studio.

In this example the content database being backed up is the SharePoint_ContentDB database.

1. From the backend SQL server hosting the SharePoint 2007 databases open “SQL Server Management Studio”.

2. Right click on the content database and select “Back Up”.

3. Once the “Back Up Database” window pops up, ensure that the “Database” source corresponds to the appropriate database and that the “Backup type” is listed as “Full”.

4. In the “Destination” field click on the “Add” button and select the destination location of the backup file.  I selected the default location as shown below.  Click the “OK” button once the destination has been selected.

IV. Restoring SharePoint 2007 Content

1. Once the backup has successfully completed and the backup file (.BAK file extension) has been created, move the backup file to the server hosting the SQL databases for the SharePoint 2010 farm.

2. From the backend SQL server hosting the SharePoint 2010 databases open “SQL Server Management Studio”.

3. Right click on “Databases” icon and select the “Restore Database” option.

4. When the “Restore Database” window opens, select “From Device” as the source and click on the ellipses (“…”) button to navigate to the location of the backup file.

5. Once the backup file and backup set have been selected, the database name can be specified.  In this case the backup was restored with the SharePoint2010_ContentDB database name.

6. After the backup has been successfully restored the SharePoint 2010 service accounts must be granted ownership permissions to the restored database.  In this example the Server Farm Account (CORASWORKS\sharepointsvc) and Application Pool Account (CORASWORKS\sharepointapp) were granted “Owner” permissions to the SharePoint2010_ContentDB database.  To do so expand the “Security” icon, locate the appropriate service account name and double click on it.

7. From within the “Login Properties” window click on the “User Mapping” option.

8. Locate the appropriate database (SharePoint2010_ContentDB), select it and check on the “db_owner” database role membership.  Click the “OK” button once the appropriate role has been selected.  Follow this process for all the appropriate service accounts.

V. Creating SharePoint 2010 Web Application

The procedure for attaching and upgrading the SharePoint 2007 content database to the SharePoint 2010 farm is a two step process.  The first step requires a new web application in the SharePoint 2010 farm to be built using the original web application URL (http://sharepoint.cwtest.local).  The second step takes the restored SharePoint 2007 content database and attaches to the SharePoint 2010 farm, which will also upgrade the database and associate it to the newly created web application.

1. To create a web application in the SharePoint 2010 farm open Central Administration and click on the “Application Management” link.

2. Under the “Web Applications” section click on the “Manage Web Applications” link.

3. From the “WebApplicationsList.aspx” page click on the “New” link.

4. In the “Create New Web Application” window populate the required fields.  The URL used when creating the web application should the same as the original URL, which in this case is http://sharepoint.cwtest.local.

5. Ensure that the application pool service account with ownership permissions to the restored content database is used when creating the web application pool.

6. In the “Database Name” field enter a descriptive name that will help to identify and locate the database quickly.  The database created in this step is temporary and will be replaced with the restored content database from the SharePoint 2007 environment.  The name used for the temporary database in this example is  Temporary_ContentDB.

7. Once all the appropriate fields have been filled out, click on the “OK” button.

8. On the “Application Created” window click “OK”.

VI. Removing temporary content database

1. In Central Administration click on the “Application Management” link.

2. From the “Application Management” page click on the “Manage content databases” link.

3. Once on the “Manage Content Databases” page click on the temporary content database link (i.e. Temporary_ContentDB).

4. If necessary, change the web application from the “Web Application” drop down (i.e. the URL displayed should be http://sharepoint.cwtest.local).

5. From the “Manage Content Database Settings” page, check the “Remove Content Database” check box and click on the “OK” button.

6. At this point you should be back on the “Manage Content Databases” page, which will no longer have the temporary content database associated with the web application.


VII. Attaching and upgrading SharePoint 2007 content database

In order to attach and upgrade the restored SharePoint 2007 database Power Shell (i.e. SharePoint 2010 Management Shell) or command prompt can be used.  For this example I will use command prompt, but more information on how to use the management shell can be found here.

1. On the server running SharePoint 2010 Central Administration open command prompt as an administrator.

2. Change directories to the 14 hive by typing “cd C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN” from the prompt.

3. To attach and upgrade the restored SharePoint 2007 content database type “stsadm –o addcontentdb –url http://sharepoint.cwtest.local –databasename SharePoint2010_ContentDB”.  Quick tip: This upgrade approach supports simultaneous content database upgrades.

4. Once the attach process is complete (100.00% should be shown), go back to the “Manage Content Databases” page and refresh it.  At this point, the newly attached content database should be associated with the web application.

5. If the source and destination SharePoint farms are on the same domain then the users from the original configuration should work without any issues.  If the source and destination farms are on different domains, then the Site Collection Administrator for the Site Collection(s) must be assigned.  This can be done from the “Change Site Collection Administrators” page in the “Site Collection” management, under the “Application Management” section in Central Administration.

VIII. Access upgraded content

Prior to accessing the upgraded content ensure the appropriate DNS entries have been configured for the sharepoint.cwtest.local host pointing to the SharePoint 2010 farm.

1. Once DNS resolution has been verified, open a browser window and navigate to http://sharepoint.cwtest.local web application.  The web application should be accessible and since the SharePoint 2010 environment doesn’t have the CorasWorks Suite installed, the pages will display some errors.

2. At this point, install the CorasWorks Suite according to the instructions provided with the installation files or the CorasWorks Community.

3. Once all appropriate CorasWorks components have been installed, the content should display without any errors.  It is important to note that interface will continue to display the SharePoint 2007 look and feel until a “Visual Upgrade” has been applied to the site(s).

4. To perform a “Visual Upgrade” click on the “Site Actions” link and select “Visual Upgrade”.

5. From the “Title, Description, and Icon” page select the appropriate “Visual Upgrade” option and click the “OK” button.  The recommended selection is the “Preview the updated user interface” option.

6. At this point the upgraded site’s look and feel can be upgraded permanently or rolled back to the SharePoint 2007 look and feel.  This setting can be set for a site, site collection, or content for the entire web application.

7. Any customized sites can also be upgraded to the SharePoint 2010 look and feel; however, it is recommended that any mission critical applications be thoroughly tested for upgrade incompatibilities.  Once the CorasWorks content is upgraded from SharePoint 2007 to SharePoint 2010, all SharePoint 2010 functionality will be available.  However, if you need the SharePoint 2010 look and feel for your CorasWorks applications contact CorasWorks for guidance on an upgrade path.


Hopefully these instructions provide some insight to the SharePoint 2010 upgrade process (at least one of the available approaches) and answer any questions you may have.  If you need additional information regarding the SharePoint 2010 upgrade or have any general questions please contact CorasWorks Support.

Many Connection Types for the External Data Provider, there are – Blog Series Part 5

So you just finished reading all the ways the External Data Provider is THE Swiss Army knife of data integration. In closing up this Series, I’ll share some properties that can reside outside your individual connections (i.e. outside your <Data> elements) which we call the aggregate properties. A handy capability of the External Data Provider is that you can actually do mashups with it. It doesn’t provide all the feature/functions of the dedicated Mashup Adapter, but for quick & simple vertical mashups, it can often fit the need in short order.

To perform a “mashup” with the EDP, simply create a connection file that (a) has one or more connections set as the default and (b) has one or more connections with the same name. If both these conditions are met, the EDP will make all the connections listed and output their aggregate result as a vertical mashup.

In doing so, we’ve then provided some aggregate properties that you can set for the behavior/handling of the aggregate data returned. Many work just like the similarly named properties within a given connection type, they’re simply applied at the macro level. These properties are:

Property Name / Element

Property Use / Function

<AggregateOutputType> Default is “text/xml” however “text/html” & ”text/plain” are also supported.
<AggregateXSL> Actual XSL to transform the aggregate response from your Provider. However, it is recommended to use an attached stylesheet (see next property) as opposed to including your XSL in line here.
<AggregateXSLLocation> The URL to the location of an XSL stylesheet (can be .xml, .xsl or .xslt) to be applied for transforming the aggregate Provider response. This transform occurs *before* the data is rendered or passed on to another component.
<AggregateRedirectTo> The URL to redirect this connection to upon successful completion. This is the ability to take the aggregate response from your connections and instantly pass it into another to complete a process or validate a response. If you specify a parameter in the RedirectTo, you can pass the value of the initial connections using a pre-defined variable called %Data%.



<CacheOutput> A true/false value indicating whether or not the aggregate output from this connection should be cached. If set to “true”, you can use the following three properties to customize the cache label and/or duration. Absent any of the following properties, the default label will be TheConnectionName+”Output”+WebPartID with a duration of 200 mins.
<CacheLabel> A text value to specify the aggregate cache label; if not specified, the default Web Part ID will be used for this portion of the cache identifier.
<CacheAddUserID> A true/false value indicating whether or not to add the ID of the user running the aggregate connections to cache label; this is akin to a cache per user mechanism. If set to “true” the User’s ID will be added to the end of the cache label.
<CacheDuration> An integer value indicating the aggregate cache duration in minutes.

And don’t forget the check out the other posts in this Series: