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:

Successes:

-          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.

Failures:

-          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 commitment.  If your organization is not committed to a product, it will almost certainly fail.

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.

Thanks,

CorasWorks Support

IMPORTANT: In our testing the issue was caused by a bad installation of Visual Studio; however, it may also be caused by other software installations or updates. The fix described in this article is AS-IS and it is not supported by CorasWorks Corporation.

Symptoms

After installing Visual Studio, browser updates, or applications, Internet Explorer is unable to open links in new tabs or windows. When a new link is clicked where the contents are to open in a new tab or new browser window, the page launches but nothing is displayed.

The following images depict the behavior of the problem.

Cause

The issue appears to be caused by a bad installation of an application or a browser update, which causes browser DLL registrations to become corrupt or invalid.

Resolution

In order to resolve the issue, the corrupt or invalid Internet Explorer DLLs must be re-registered. To re-register the DLLs, follow the steps below. The steps MUST be performed in the order shown below or the fix will not take effect.

1. 1. Download ie8-rereg.32on64.zip and ie8-rereg.64on64 from Internet Explorer FAQ and save them to disk.
2. 2. Extract the compressed files into a single directory.
3. 3. Reboot PC.
4. 4. Open the command line as an Administrator.
5. 5. Go into folder with the following files:
   1. a. ie8-rereg.32on64.cmd
   2. b. ie8-rereg.64on64.cmd
6. 6. Run ie8-rereg.32on64.cmd within command line window. Ensure there are no errors.
7. 7. Run ie8-rereg.64on64.cmd within command line window. Ensure there are no errors.
8. 8. Reboot PC.

After implementing the fix, the behavior should be as follows:

We thank Internet Explorer FAQ for the actual fix, as this is simply an implementation of the fix documented by good folks over at Internet Explorer FAQ.

Source: Repair IE8 (IE7) and IE9, http://iefaq.info/index.php?action=artikel&cat=48&id=133&artlang=en.

Installing SharePoint 2010 updates, Service Packs or a Cumulative Updates, are made up of two separate steps: Installing the SharePoint Update bits onto the servers (e.g. officeserver2010sp1-kb2460045-x64-fullfile-en-us.exe) and running the SharePoint Products Configuration Wizard (alternatively psconfig -cmd upgrade -inplace b2b –force) to configure (i.e. upgrade) the updated SharePoint components.

In some situations, the second step of the installation may result in a “Configuration Failed” error when there are components in the content database referencing “Missing Server Side Dependencies”.  In this scenario, the configuration (step 2) of the update actually completes 100%, with errors.  See sample “Configuration Failed” error below.

Cause

SharePoint 2010 (Server/Foundation) includes a built in SharePoint Health Analyzer, which can sometimes deem native SharePoint or 3rd party components in content databases to have “Missing Server Side Dependencies”.  When the SharePoint Products Configuration Wizard (alternatively psconfig -cmd upgrade -inplace b2b –force) is run after a SharePoint update, the same Health Analyzer is used to inform administrators that there are missing features or other components in the content database(s).  These missing pieces will prevent the components from being upgraded during the update configuration.  See sample errors from the upgrade logs below.

Upgrade Log:

Upgrade Errors Log:

In some cases, when the CorasWorks Suite has been installed into a SharePoint 2010 environment and then had solutions (i.e. WSPs) removed and/or list activations were created with version 10 or earlier of the CorasWorks Suite, “Missing Server Side Dependencies” found by the Health Analyzer can cause the SharePoint Products Configuration Wizard to return a “Configuration Failed” error.

Resolution

In this scenario, since CorasWorks components should not be updated by any SharePoint update, the “Configuration Failed” error is a false positive.

Although the “Configuration Failed” error is considered a false positive, there is a way to prevent the error from being encountered during the configuration of an update.  To prevent the error, the following steps must be followed PRIOR to running the SharePoint Products Configuration Wizard (alternatively psconfig -cmd upgrade -inplace b2b –force):

Ensure the SharePoint Farm does not have any CorasWorks “Missing Server Side Dependencies”

1. Open SharePoint 2010 Central Administration.

2. Go to the Review problems and solutions page of the SharePoint Health Analyzer (http://server:port/Lists/HealthReports/AllItems.aspx).

3. Under the Configuration Category, click on the “Missing Server Side Dependencies” list item.  If the category is not listed, then the issue described in this article is not applicable to the environment.

4. Once inside the “Missing Server Side Dependencies” page, look for entries referencing the CorasWorks Suite.

5. If any are found, follow the resolutions in the articles below to remove the “Missing Server Side Dependencies” entries.

• Missing server side dependencies in SharePoint Health Analyzer (SharePoint 2010) – Part I
• Missing server side dependencies in SharePoint Health Analyzer (SharePoint 2010) – Part II

6. Once the “Missing Server Side Dependencies” entries have been removed, the SharePoint Products Configuration Wizard (alternatively psconfig -cmd upgrade -inplace b2b –force) will conplete successfully.

Important: This behavior is new with SharePoint 2010 (Foundation/Server) and it affects all solutions including native Microsoft solutions and third party solutions.  However, the Resolutions described in this article are only intended for the specific scenarios affecting the CorasWorks Suite.

Please e-mail support@corasworks.net if you have any questions or issues.

Thanks,

Rodney

Cause

When the CorasWorks Suite is installed into SharePoint, there are various solutions (WSP files) that get added to the SharePoint Solution Store and deployed to the servers in the farm.  These solutions provide a way to extend SharePoint via features, which can be activated selectively at the site collection basis.

If a feature that is part of the CorasWorks Suite (Basic or Advanced Components) has been activated in a site collection, this feature adds references to the solution that supports the feature in the content database.  If a solution required for an activated feature is removed from the environment, SharePoint will recognize that dependencies required for the feature to function as missing and will add an entry for the missing feature solution in the “Missing server side dependencies” section of the SharePoint Health Analyzer.

Resolution
In order to clear the “Missing Server Side Dependencies” errors from the SharePoint Health Analyzer, the solution(s) that is referenced in the “Missing server side dependencies” section of the SharePoint Health Analyzer must be reinstalled.  Provided below is a list of feature IDs for the CorasWorks Suite solutions.

Alternatively, the feature can also be forcefully removed from SharePoint using utilities such as the SharePoint Feature Administration and Clean Up Tool from CodePlex.  However, this is not recommended or supported by CorasWorks.

CorasWorks Feature IDs List:

Excel Format

Plain Text Format

Important: This behavior is new with SharePoint 2010 (Foundation/Server) and it affects all solutions including native Microsoft solutions and third party solutions.

Please e-mail support@corasworks.net if you have any questions or issues.

Thanks,

Rodney

In certain SharePoint 2010 (Server/Foundation) farms, the built in SharePoint Health Analyzer can log errors that indicate “Missing Server Side Dependencies” for the CorasWorks.Workplace.Actions component within a content database. Sample error message shown below.

Cause

When a CorasWorks Suite list activation is created, a corresponding event receiver is also created, so that an action can be executed when an event meets certain conditions. At time the event receiver is created, a reference to the installed CorasWorks.Workplace.Actions DLL needs to be made in order for the event receiver to function correctly.

In versions of the CorasWorks Suite prior to version 11 (i.e. v10.x), any event receivers created permanently referenced the version of the CorasWorks.Workplace.Actions DLL that was on the servers at that time (i.e. Version=10.4.0.168, etc.). When the CorasWorks Suite is upgraded to a newer version, the version of CorasWorks.Workplace.Actions DLL is also upgraded and replaced. However, the event receivers maintain references to the previous version of the DLL.

Although both SharePoint and the CorasWorks Suite function normally, the SharePoint Health Analyzer flags the outdated DLL references in the event receivers as having “Missing Server Side Dependencies”. The reason they are considered to have missing server side dependencies is because the specific version of the DLL being referenced by the event receivers are no longer on the server.

Resolution

In order to clear the “Missing Server Side Dependencies” errors from the SharePoint Health Analyzer, the references to the outdated version of the CorasWorks.Workplace.Actions DLL in the event receivers must be upgraded to the latest version. To upgrade the event receivers, the following steps must be taken.

1. Download the “CWEventReceiverUpdate.zip” file to one of the SharePoint 2010 servers on the farm.

2. Extract the “CWEventReceiverUpdate.zip” to the file system.

3. Go inside the “CWEventReceiverUpdate” folder that was created after the extraction.

4. Using administrative privileges execute the “CWEventReceiverUpdate.bat” file. If necessary, right click on the .bat file and select “Run as administrator”.

Important: The user executing the batch file must have site collection privileges to all site collections that include event receivers that need to be upgraded.

5. Review the “Update.log” file to determine if any were upgraded.

This will not be an issue with versions of the CorasWorks Suite v11 or later.

Please e-mail support@corasworks.net if you have any questions or issues.

Thanks,

Rodney

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.

Sources: http://support.microsoft.com/kb/816102, http://www.makeuseof.com/tag/configure-trusted-sites-internet-explorer-group-policy, http://support.microsoft.com/kb/182569.

The proper configuration of Alternate Access Mapping settings in SharePoint (2003/2007/2010) are extreme important because CorasWorks software (all versions and products) can be affected by these settings.  This is true for any type of SharePoint deployment, but most importantly for environments using a Reverse Proxy configuration.  While working with clients we’ve identified some settings that tend to be problematic, due to either missing or erroneous configurations.  I will cover these in the next section.

Frequently Seen Alternate Access Mapping Settings Issues

Many organizations get a jump start on SharePoint by using many of the default settings that can be selected when configuring SharePoint.  This is ideal for proof of concept (test/dev) environments because a lot of planning isn’t required to get the environment up and running.  However user friendly this may be, the configuration settings aren’t always optimal for production environments.  Unfortunately, due to the nature of SharePoint and rapid changing business needs, many proof of concept environments become production and introduce many of the issues we see often.

Issue A – Using a Server Name in the Default Zone AAM URL

One of the things that the default configuration settings include is the server name as the main SharePoint web applications URL (i.e. http://server1) and identified as “SharePoint – 80” in IIS.  This setting also associates the server named (i.e. http://server1) URL with the Default Zone in the Alternate Access Mappings.  In most cases the URL with the server name isn’t acceptable and is replaced with something that is more descriptive of the SharePoint web application (i.e. http://intranet.company.net).

An issue often seen with the aforementioned configuration is with the Default Zone’s URL is removed (i.e. http://server1) and is replaced with the more descriptive URL (i.e. http://intranet.company.net).  Although this works for most things in SharePoint, there are often some portions of the web requests that continue to reference the original URL (i.e. http://server1), which may cause issues with the CorasWorks display wizard and aggregation rollups, among other things.  When these problems are encountered, the best way to resolve them is by adding back the original URL mapping (i.e. http://server1) that was found in the Default Zone AAM configuration.  Once the original URL mapping is back in the Default Zone, a second URL can be used to in one of the other Zones (e.g. Intranet, Extranet, Internet, and Custom) with the more descriptive name (i.e. http://intranet.company.net) to make SharePoint aware of the additional identity (i.e. combination of port, IP address, host header) for the web application.

Issue B – Non-Host Header Based Default Zone AAM URL

Another issue frequently seen with AAMs settings is when hardware load balancers are used with SharePoint and are configured to distribute host header (i.e. http://intranet.company.net) based web application traffic to the cluster nodes by using the servers’ IP addresses (i.e. http://10.1.1.X) instead of the host header based URL.  In such cases the AAM settings have been updated to replace the host header based URL with the IP address based URLs.  This URL replacement in the AAM may affect any of the Public Zones available in the Alternate Access Mappings and can affect the ability of accessing the CorasWorks display wizard and also prevent aggregation rollups.

In this scenario, the best way to ensure that the Alternate Access Mappings information is used properly by SharePoint is by designating the Default Zone AAM with the host header based URL (i.e. http://intranet.company.net) and if IP addresses are required for the load balancer to distribute traffic properly, then add the servers’ IP addresses (i.e. http://10.1.1.X) in any of the available AAM Zones (i.e. Intranet, Extranet, Internet, and Custom).  This setup is not required with most hardware load balancers, but it can be used as a work around if your server farm is smaller than 4 servers.  The reason 4 servers are mentioned is because the number of available Zones besides the Default Zone, which is used by the host header based URL, are 4 (i.e. Intranet, Extranet, Internet, and Custom).  Again, this is a work around and in some extreme cases a rebuild of a web application may be required.

Issue C – Misconfigured Reverse Proxy Settings (off-box SSL termination)

It is extremely important that SharePoint is configured according to the instructions provided in the following TechNet Article in order for CorasWorks software to function properly.  This includes the creation of the web application, configuration of the alternate access mappings, and creation of the firewall publishing policies for the web application.

The following article includes Reverse Proxy Publishing Instructions for Microsoft’s Internet Security & Acceleration Server (ISA).  Contact your firewall manufacturer for specifics on how to configure a Reverse Proxy publishing rule on non-ISA based Firewalls.  Reverse Proxy Publishing Instructions http://technet.microsoft.com/en-us/library/cc261814(office.12).aspx.

IMPORTANT:  When creating a Reverse Proxy Publishing Rule in ISA Server, ensure that the same type case is used for all the representations of the URLs.  For instance, if the Alternate Access Mappings in SharePoint uses http://intranet.company.net in the URL (for any Zone), the URL most use the same case in the Public Name (i.e. https://intranet.company.net) and not https://INTRANET.company.net.  If the type case does not match in settings of both SharePoint and the ISA Firewall, then the previously mentioned CorasWorks display wizard and aggregation rollups problems may be encountered.

Examples of Issues

Display Wizard Issue

Rollups Issue

Additional Resources:

Brief Summary of the Alternate Access Mapping settings (WSSV3/MOSS)

http://blogs.technet.com/b/tothesharepoint/archive/2008/08/26/3112518.aspx

Accessing Alternate Access Mapping Settings (WSSV3/MOSS)

http://technet.microsoft.com/en-us/library/cc263208(office.12).aspx

Accessing Alternate Access Mapping Settings (SharePoint Foundation 2010/SharePoint Server 2010)

http://technet.microsoft.com/en-us/library/cc261995.aspx#section4

Reverse Proxy Publishing Procedures – Step by Step Instructions (WSSV3/MOSS)

http://technet.microsoft.com/en-us/library/cc261814(office.12).aspx

If you have any questions please contact support@corasworks.net.