When attempting to create/open a document in a SharePoint list or view a list in Datasheet view, you receive one of the messages below:

1. The list cannot be displayed in Datasheet view for one or more of 
the following reasons:
 - A datasheet component compatible with Windows SharePoint Services 
is not installed.
 - Your Web Browser does not support ActiveX controls.
 - Support for ActiveX controls is disabled.
 The list is displayed in Standard view. It cannot be displayed in 
Datasheet view for one or more of the following reasons: A datasheet 
component compatible with Microsoft SharePoint Foundation is not 
installed, your browser does not support ActiveX controls, a component is 
not properly configured for 32-bit or 64-bit support, or support for 
ActiveX controls is disabled. 2. The document could not be created. The required application 
may not be installed properly, or the template for this document library 
cannot be opened. 3. The document could not be opened for editing. A Windows SharePoint 
Services compatible application could not be found to edit the document.


There are several possible causes for any of the error message listed above.  Some possible causes are;

1) Incompatibility issues specific to the version of Microsoft Office installed on your computer,

2) The SharePoint Support component or Windows SharePoint Services Support (as appropriate to your version of MS Office) is not installed on your computer,

3) The Owssupp.dll file is not registered correctly in Microsoft Windows and/or is corrupt due to installation of Office 2003 professional, and any of Office 2007 Products

4) You are using Microsoft Office 2010 and do not have a 64-bit version of ActiveX Control installed on your computer.


It is recommended that you consult your Site Administrator before performing any of the resolution options listed below.

Repair a Corrupt Owssupp.dll: Running a Microsoft Office diagnostic tool can repair a corrupt .DLL file.  Below are the instructions to run the diagnostic tool.

1. Navigate to C:\Program Files\Microsoft Office\Office12
2. Delete the OWSSUPP.DLL file from this directory.
3. Click Start.
4. Click All Programs.
5. Click Microsoft Office.
6. Click Microsoft Office Tools.
7. Run Microsoft Office Diagnostic.

8. Repair office installation using below instructions

If Office 2003 is installed on the computer:
1. Click Start, and then click Control Panel.
2. Click Add or Remove Programs.
3. In the list of currently installed programs, click Microsoft Office 2003, and then click Change.
4. Click Add or Remove Features, and then click Next.
5. Click to select the Choose advanced customization of application check box, and then click Next.
6. In the Choose update options for applications and tools box, expand Office Tools, click the down arrow next to Windows SharePoint Services Support, and then click Run from My Computer.
7. Click Update.

Leave a comment

Posted by on July 1, 2011 in Office Integration, Sharepoint


SharePoint 2007: Word was unable to read this document. It may be corrupt


When user try to open a document from SharePoint document library, the document does not open, and they receive the following error message:
“Word was unable to read this document. It may be corrupt.
Try one or more of the following:
* Open and Repair the file.
* Open the file with the Text Recovery converter.


We have been trying to troubleshoot this above mentioned issue by applying HOTFIX from Microsoft, but no luck!

We would like to dig more information about this issue to find out a proper solution, so we gathered the information like HTTP Trace, Network Trace, ULS Log etc. We have noticed after we analyzed the ULS log, this issue appears only one web application and other web application works correctly without any issue and we could not find any entries for problematic web application.

Similarly, we could not find any useful information from Network Trace analysis however we have found out the root cause of this issue by analyzing the HTTP Trace.  HTTP Trace shows a couple of redirection(“HTTP STATUS CODE: 307”) calls when user opening a document from the SharePoint document library.

We dig into more on why it is redirecting/omitting the HTTP calls when user opening a document from document library, finally we have found out that culprit (“Proxy pac file exception”). We did not added the exception for problematic Web application url in the proxy pac file.

After we added the exception entry in the IE proxy pac file, the issue has been resolved!


Posted by on July 1, 2011 in Office Integration, Sharepoint



Cannot run Windows SharePoint Services on this page:

When uploading multiple documents to the document library from outside of corporate network, the remote users were getting “Cannot run Windows SharePoint Services on this page:”
Users have implemented SSL on ISA/Load Balancer with a common rule for both the site, where we are redirecting to external site traffic to HTTPS from HTTP. If they upload multiple document, it wont give them any problem, but if they do same thing with Remote users, it is giving them error Cannot run Windows SharePoint Services on this page.

Administrator might have configured the reverse proxy(HTTPS->HTTP vice versa) using either Load Balancer I-Rule(Redirection) or ISA server. Administrator has configured only one zone “Default” and they set the public zone in their AAM settings as follows

Internal URL Zone Public Url for Zone

https://yoursite Default https://yoursite
http://yoursite Internet http://yoursite
http://your.servers.fQDN Internet https://yoursite

As shown in exception above, URL is starts with HTTP for HTTPS users(Remote users). So it is clearly indicates that ISA/BIG-IP(Load Balanacer) redirecting external site traffic from HTTPs to HTTP vice versa. When remote user tries to upload multiple document using upload.aspx(HTTPS://, SHTML.dll of VTI_BIN looks for HTTP:// and it could not find out the HTTP connection, so it throws “Failed Connection Attempt” at load balancer/ISA server side and displayed the error message as “Cannot run Windows SharePoint Services on this page”

In order to resolve this issue, administrator should correct their AAM mapping as follows

Internal URL Zone Public Url for Zone
https://yoursite Default https://yoursite
http://yoursite Internet https://yoursite
http://your.servers.fQDN Internet https://yoursite

Hope this helps.

Leave a comment

Posted by on February 11, 2011 in Sharepoint


Using PowerShell list SharePoint site users, roles, groups on all sites

I have been asked to generate the list of users with their roles and groups belongs to for all sites presented in the web application. I found some blog talking about same requirements. But it is not fully satisfied my requirements. So I have taken his logic and created the PowerShell script to list the users, their roles and groups belong for the sites presented in the web application

Here is the below code which will iterate all sites and enumerate the users with their roles and groups belongs to.

[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”) > $null
function EnumerateUserRolesPermissions ([string]$webURL){
$site = new-object Microsoft.SharePoint.SPSite($webURL)
$web = $site.OpenWeb()
$webUsers = $web.Users
$groups = $web.sitegroups
foreach($webUser in $webUsers){
$Permissions = $web.Permissions
foreach($group in $groups)
foreach($Permission in $Permissions){
if($webUser.ID -eq $Permission.Member.ID){
foreach ($role in $webUser.Roles){
if ($role.Type -ne [Microsoft.SharePoint.SPRoleType]::None)
write-host $webURL,“;“,$webUser.LoginName,“;“,$webUser.Name,“;",$role.Type.ToString(),";",$webUser.groups
if($group.ID -eq $Permission.Member.ID){
foreach ($role in $group.Roles){
if ($role.Type -ne [Microsoft.SharePoint.SPRoleType]::None
foreach($user in $group.users){
write-host $webURL,“;“,$user.LoginName,“;“,$user.Name,“;",$role.Type.ToString(),";",$
function EnumerateSiteUsers ()
$farm = [Microsoft.SharePoint.Administration.SPFarm]::Local
foreach ($spService in $farm.Services) {
if (!($spService -is [Microsoft.SharePoint.Administration.SPWebService])) {
foreach ($webApp in $spService.WebApplications) {
if ($webApp -is [Microsoft.SharePoint.Administration.SPAdministrationWebApplication]) { continue }
$webAppUrl = $webApp.GetResponseUri('Default').AbsoluteUri
foreach ($site in $webApp.Sites) {
foreach ($web in $site.AllWebs) {
EnumerateUserRolesPermissions $web.url

Hope this helps


Posted by on February 3, 2011 in PowerShell, Sharepoint


Tags: ,

Diagnose Performance Issues in Web Pages especially SharePoint

We have came across lot of queries about SharePoint or Web Pages performance issues in our day-to-day professional life.  I was thinking to develop a tool to draw the map of behind the web request which has HTTP route map with multiple components like Load Balancer, Front-End Server(especially which server and it is configurations)  to Database Server. This route map should clearly mention where exactly HTTP request hanging and why it is hanging etc.

I was going through on MSDN and found out that a tool called “Visual Round Trip Analyzer”  – Web page performance visualizer and analyzer. Pretty decent tool to visualize your web page performance and it helps to find out the root cause of the issue.

Here you can check it out in detail.

The Visual Round Trip Analyzer tool helps web developers and testers visualize the download of their page, identify best practices and changes that improve web performance. The network Round-Trip between the client and server(s) is the single biggest impact to web page performance – much greater than server response time. VRTA examines the communications protocol, identifying the causes of excessive round-trips, and recommending solutions. Performance engineers, testers, developers, operations personnel should use VRTA to conduct their web performance analysis.

Leave a comment

Posted by on October 26, 2010 in Uncategorized



SharePoint 2010 Development Environment Options

Jay Horan has posted his experience on SharePoint 2010 Development Environment Option and would be helpful in Planning & Preparation for SharePoint 2010.

Leave a comment

Posted by on April 19, 2010 in Uncategorized



Kerberos Requirements for Internet facing MOSS 2007 environment

Most of you guys have implemented the Internet facing MOSS 2007 environment with two different domains(i.e, one is least trusted Extranet domain and another one is intranet domain).  So the TRUST level between Extranet and Intranet Domain is “External One Way” trust as shown in following figure. This could be designed to implement a Secure MOSS 2007 to avoid any hacker calls from extranet.

But in-terms of authentication, this would work pretty well for NTLM authentication, but, will not work for Kerberos authentication. In order to implement a Kerberos Authentication with this environment/farm, there is a Forest Two-Way trust required to exchange the delegation between two different domain(i.e., Extranet and Intranet Domains).

We had similar situation as described above, the above farm/architecture works pretty good for NTLM but when we are planning to switch back “Kerberos”, it got failed as “The request failed with HTTP status 401: Unauthorized”. We investigated the network traces using NETMON, we saw LOT of HTTP, KERB, NTLM/NLMP/SPNEG Authorization calls, then we forced to use KERBEROS authentication using cscript adsutil.vbs set w3svc/1/root/NTAuthenticationProviders “Negotiate” – Still no luck!

Finally found that HTTP response from SQL back-end server to WFEs are empty SOAP messages. After that we temporarily removed the two WFEs and modified the DNS entry pointing to central administration server. It means that we are removing the Extranet Domain from Farm. This time we are able to see the SOAP response coming from SQL-Server to Central Administration MOSS Server. We checked with Microsoft Supporting Team, they were not giving the solid answers that “Forest Two-Way Trust” is MANDATORY between Extranet and Intranet Domains. They said may or may not be required a Two-way trust between two domains for SharePoint Implementation.

When we digging into MSDN article about this issue and we found the following article, – It states as follows:

•    If the customer has more than one domain, verify that the SharePoint and Reporting Services service accounts and the user accounts accessing SharePoint are in domains that have a two-way trust between them. If there is only a one-way trust, there will be problems authenticating users and resources from both domains.

So it is clearly said that, we need to have a “Forest Two-way trust” between Extranet Domain and Intranet Domain in order to work with Kerberos in MOSS 2007 environment. Please be keep this in your mind when you are designing the internet faced MOSS 2007 with Kerberos Implementation

Hope this helps!

Leave a comment

Posted by on March 22, 2010 in Uncategorized