I have been asked to extract all the files from one of the SharePoint farm and put into the share drive where users can access it. I was looking around on the web and we found an article, but SQL query is incorrect in this article as Content Column is not resides in the DOCS Data-view. So, we have to create an INNER JOIN between DOCS and DOCSTREAMS to get the binary content for the files. I have attached here is the code and screenshot of it.
Hope this helps.
Microsoft has released a latest version of Diagnostics Tool for SharePoint. This tool was mentioned in all the IT professionals sessions by presenters. It is pretty interesting!!!
For more information, http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=971
[Courtesy: Microsoft Knowledge Base Article]
As mentioned in the subjected above, we have encountered the issue that existing alerts were not firing after the site migration. I digged into the Micrsoft Knowledge Base and I found out the below support article.
http://support.microsoft.com/kb/936759
There is an awesome tool for SharePoint administrator to update these existing alerts.The new stsadm -o updatealert command was released in the SharePoint Administration Toolkit. For more information and to download the toolkit, visit one of the following Microsoft Web sites, depending on the version of Windows SharePoint Services that you are running.
For more information, see the “Microsoft SharePoint Administration Toolkit” white paper. To do this, visit the following Microsoft Web site:
Enjoy!!!
When we done with the migration work from one environment to another environment, obviously stake holder would ask the SharePoint administrator to provide the URL redirection mechanism as users have been accessing the old URL from the favorites, outlook, and shortcuts.
There are multiple options for SP administrator to achieve this task like creating URLMapping element in the web.config, or writing URL Rewriting using HTTP Modules, etc. But these methods are time consuming and we can not test code as we are working on the production migration. So, the only option is to change the redirection URL at the IIS level. Below is the workable and quick solution for this task.
Just set “The exact URL entered above” and “A permanent redirection for this resource” on the IIS and enter your fully qualified host name entry as follows
The $S$Q will maintain all URLs on our other host names that enter.
This would redirect all your http://contoso.external.com/* HTTP calls to http://contoso.corp.com/*.
How simple is it right? 
SharePoint users would love to use the hard-coded URLs in the SharePoint navigation. But they dont know what would be the impact while migrating site from one place to another and also it is really hard to find and replace these URLs as it’s time consuming.
SP administrator should have to use some tool to find out these hard-coded urls and change it manually. The below SQL query would point out the hard-coded URLs in each content databases. Also, I heard some webparts are available at the CodePlex.com to find and replace these hard-coded URLs.
use [CONTENT_DATABASE_NAME]
go
select webs.title as SiteName, navnodes.url as AbsoulteUrl, webs.fullurl as location
from navnodes
join webs on navnodes.webid = webs.id
where navnodes.url like ‘%http://%’
It is a real hard to understand the issue from user who is working remotely at client location. Normally, IT support folks used to setup a webex session to see what is happening in their machine to understand the issue. But this method would not apply for a user can not accept or share their desktop due their work environment restrictions.
Only option is to share the screenshot between user computer and IT support professional. But IT support professional could not easily identify the root cause of an issue or troubleshoot the issue using screenshot of user desktop.
I had an experience with external user with same situation as mentioned above. So we decided to gather the information in regards to external user getting access denied. We analyzed the various areas as shown in below.
.jpg)
Things we gathered,
1. User account setup is okay
2. Her account works on Guest VLan on Corporate COE PC (IE7)
3. User account works on IT Support Professional home internet (IE7)
4. User account will not work on NAMSA PC (IE8)
So, it is clearly shows that IE8 is causing the issue.
We advised them to make sure their Trusted Sites zone allows ‘Automatic login with current username and password’.
Open IE, Tools -> Internet Options -> Security -> Trusted Sites.
1. Click ‘Sites’ and make sure the URL is in there.
2. Click ‘Custom Level’, scroll to the bottom and ensure ‘Automatic Logon with current user name and password’ is selected.
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. -OR- 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.
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.
(\…\test.doc)”
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 have 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!
SYMPTOMS:
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: http://portal.com/shared/xyz/allitems.aspx”
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.
CAUSE:
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://portal.com/shared/xyz/forms/upload.aspx), SHTML.dll of VTI_BIN looks for HTTP://portal.com/shared/xyz/forms/upload.aspx 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”
PROPOSED SOLUTION:
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.
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(),";",$group.name
}
}
}
}
}
}
}
}
function EnumerateSiteUsers ()
{
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$farm = [Microsoft.SharePoint.Administration.SPFarm]::Local
foreach ($spService in $farm.Services) {
if (!($spService -is [Microsoft.SharePoint.Administration.SPWebService])) {
continue;
}
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
