I post this article in response of one of my colleague's problem . Suppose that you delete by accident the dbs of the SSP (Shared Service Provider) and you have to restore it afterwards.
Back up Your SSP
Before restoring it, the first thing to know is how to backup it. :)
Back up using the user interface
1. Go to the operations page in the Central Administration, in the Backup and Restore Section, Click Perform a backup.
2. Select the SSP you want to backup. Click to Continue to Backup Options.
3. On the Backup Options page:
o Verify if your SSP is present.
o The type of backup needs to be Full.
o Select the UNC path of the backup folder.
4. Click OK.
If you go to the status page you will see the status of your backup. It refreshes every 30 seconds.
Back up using the SSP using the command line
Execute this command :
stsadm -o backup -directory SERVER\FOLDER_NAME -backupmethod full -item SSP_NAME
If you have a warning or an error you will find information in your log file spbackup.log in the folder you specified.
Back up the SSP using the SQL Server
1. Go to the SQL Server Management Studio and connect to your database server.
2. Expand Databases in the Object Explorer.
3. Right click on the SSP database, go to Tasks, then click Back Up.
4. Select the full Backup Type.
5. Select the Database option.
6. Type the name and the description of the backup.
7. Set when it will expire.
8. Specify the location to store the backup.
9. Click OK.
Restore Your SSP
Now that you know how to back up your SSP, here the way to restore it.
Restore the SSP using the user interface
1. Go to the operations page in the Central Administration, in the Backup and Restore Section, click Restore from Backup.
2. Enter the UNC path to the backup folder in the Backup File Location section.
3. Select the backup file that you want to restore, click Continue Restore Process.
4. Select the SSP you want to restore, Click Continue Restore Process.
5. On the Restore Option page :
o Verify if you select the good SSP.
o Select Same configuration in the Restore Options and accept the warning message.
o Verify the names and URLs.
6. Click OK.
Restore the SSP using the command line
1. Catch the GUID of the backup you want to restore in executing this command :
o stsadm -o backuphistory -directory UNC_PATH_TO_BACKUP_FOLDER
2. Now get the name of the SSP you want to restore using this command :
o stsadm –o restore –showtree -directory UNC_PATH_TO_BACKUP_FOLDER -backupid GUID
3. And now restore the SSP (the PATH_FROM_TREE is the full farm path as showed by the -showtree parameter) :
o stsadm -o restore -directory UNC_PATH_TO_BACKUP_FOLDER -backupid GUID -item PATH_FROM_TREE -restoremethod overwrite
4. Type y and press ENTER.
5. Type the user name and the password.
If you have a warning or an error you will find information in your log file sprestore.log in the backup shared folder.
Restore using the SQL Server
1. Stop WSS Timer service and don't restart it until you restore the database. Make sure all running procedures have completed before you continue.
2. Go to the SQL Server Management Studio and connect to your database server.
3. Expand Databases in the Object Explorer.
4. Right click on the SSP database, go to Tasks, then to Restore, click to Database.
5. Specify the destination and the source and select the backup you want to restore.
6. Click Options in the Select a page section.
7. Click OK.
8. Restart the WSS Timer service.
For more information regarding Back up and Restore I invite you to consult those articles on TechNet as I did for writing this article :
Back up SSPs (Office SharePoint Server 2007)
Restore SSPs (Office SharePoint Server 2007)
Back up databases
Restore Databases
Wednesday, December 9, 2009
Friday, November 13, 2009
change default column name 'Title ' in Item content type - Ankit
There is a file called FldEdit.aspx in layouts folder which contains a
javascript function as shown below
function doesFieldNameConflict( strName )
{
if (g_FieldName[strName.toLowerCase()] &&
strName.toLowerCase() != <
%SPHttpUtility.AddQuote(SPHttpUtility.EcmaScriptStringLiteralEncode(spField.Title),Response.Output);
%>.toLowerCase())
return true;
else
return false;
}
g_FieldName : Its an array collection of all possible fields...
Just modify the function to add your own logic and by passing the
check for existence of "Title" field as shown below
function doesFieldNameConflict( strName )
{
if( strName.toLowerCase() == "title")
return false;
if (g_FieldName[strName.toLowerCase()] &&
strName.toLowerCase() != <
%SPHttpUtility.AddQuote(SPHttpUtility.EcmaScriptStringLiteralEncode(spField.Title),Response.Output);
%>.toLowerCase())
return true;
else
return false;
}
I tried this method, and problem is resolved like this, dont forget to remove that 2 line once it get resolved.
follow this post : http://www.eggheadcafe.com/software/aspnet/29904441/change-default-column-nam.aspx
javascript function as shown below
function doesFieldNameConflict( strName )
{
if (g_FieldName[strName.toLowerCase()] &&
strName.toLowerCase() != <
%SPHttpUtility.AddQuote(SPHttpUtility.EcmaScriptStringLiteralEncode(spField.Title),Response.Output);
%>.toLowerCase())
return true;
else
return false;
}
g_FieldName : Its an array collection of all possible fields...
Just modify the function to add your own logic and by passing the
check for existence of "Title" field as shown below
function doesFieldNameConflict( strName )
{
if( strName.toLowerCase() == "title")
return false;
if (g_FieldName[strName.toLowerCase()] &&
strName.toLowerCase() != <
%SPHttpUtility.AddQuote(SPHttpUtility.EcmaScriptStringLiteralEncode(spField.Title),Response.Output);
%>.toLowerCase())
return true;
else
return false;
}
I tried this method, and problem is resolved like this, dont forget to remove that 2 line once it get resolved.
follow this post : http://www.eggheadcafe.com/software/aspnet/29904441/change-default-column-nam.aspx
Thursday, October 1, 2009
Which w3wp.exe process belongs to which App Pool in IIS6
Which w3wp.exe process belongs to which App Pool in IIS6
Along with Windows Server 2003 and Internet Information Services 6.0 came a large number of benefits. For us IIS admins, it was a great welcome set of changes. But, one apparent difficultly is matching up the w3wp.exe processes displayed in Task Manager to the Application Pools in IIS.
Review of IIS5
In IIS5.0 (Windows 2000 Server), each site that is set to Out Of Process will spin up a new instance of dllhost.exe. Windows Task Manager lists them. Now, the trick is to find out which dllhost.exe matches which site. My favorite way is to use Component Services. To do so, open Component Services from Administrative Tools, drill down to Computers -> My Computer and select COM+ Applications. Now select View from the top menu and select Status. Beside each site that currently has a dllhost.exe process spun up is the Process ID (PID). Using Task Manager, you can tell the memory and CPU.
Note: If the Process ID doesn't display for you in Task Manager, select View -> Select Columns and add it.
What about IIS6?
But, that doesn't work anymore with IIS6.0. Now each site in IIS6 is placed in an Application Pool. Each Application Pool is completely separated from other App Pools by running in its own process called w3wp.exe. This make life SO much easier. Now, the trick is to match up the process shown in Task Manager with the Application Pool set up in IIS.
If there is a different user for each application pool, Windows Task Manager is the easiest way to find out which application pool belongs to which site since Task Manager will display the user the process runs as.
But, what happens if you have multiple application pools running as the same user? For example, if you keep to the default NETWORK SERVICE user but create multiple Application Pools, you may want to know which process belongs to which App Pool. Component Services doesn't work for this anymore.
Enough already, tell me how to do it!
Have no worries, Microsoft has given us the exact tool for the situation. IISApp.vbs lists all the applications, their PID and their App Pool name.
The script is already placed in systemroot\system32 on Windows Server 2003 so simply go to your Command Prompt and type in iisapp.vbs (the .vbs is optional) and you'll have an instant list of all the App Pool information you've always wanted to know. You may need to type cscript iisapp.vbs if CScript isn't your default WSH script host.
Let's see an example of the output:
W3WP.exe PID: 1468 AppPoolId: AppPoolForSite1.com
W3WP.exe PID: 3056 AppPoolId: AppPoolForSite2.com
W3WP.exe PID: 1316 AppPoolId: AppPoolForSite3.com
Direct from the horse's mouth, Microsoft documents this:
http://www.microsoft.com/resources/documentation/WindowsServ/2003
Along with Windows Server 2003 and Internet Information Services 6.0 came a large number of benefits. For us IIS admins, it was a great welcome set of changes. But, one apparent difficultly is matching up the w3wp.exe processes displayed in Task Manager to the Application Pools in IIS.
Review of IIS5
In IIS5.0 (Windows 2000 Server), each site that is set to Out Of Process will spin up a new instance of dllhost.exe. Windows Task Manager lists them. Now, the trick is to find out which dllhost.exe matches which site. My favorite way is to use Component Services. To do so, open Component Services from Administrative Tools, drill down to Computers -> My Computer and select COM+ Applications. Now select View from the top menu and select Status. Beside each site that currently has a dllhost.exe process spun up is the Process ID (PID). Using Task Manager, you can tell the memory and CPU.
Note: If the Process ID doesn't display for you in Task Manager, select View -> Select Columns and add it.
What about IIS6?
But, that doesn't work anymore with IIS6.0. Now each site in IIS6 is placed in an Application Pool. Each Application Pool is completely separated from other App Pools by running in its own process called w3wp.exe. This make life SO much easier. Now, the trick is to match up the process shown in Task Manager with the Application Pool set up in IIS.
If there is a different user for each application pool, Windows Task Manager is the easiest way to find out which application pool belongs to which site since Task Manager will display the user the process runs as.
But, what happens if you have multiple application pools running as the same user? For example, if you keep to the default NETWORK SERVICE user but create multiple Application Pools, you may want to know which process belongs to which App Pool. Component Services doesn't work for this anymore.
Enough already, tell me how to do it!
Have no worries, Microsoft has given us the exact tool for the situation. IISApp.vbs lists all the applications, their PID and their App Pool name.
The script is already placed in systemroot\system32 on Windows Server 2003 so simply go to your Command Prompt and type in iisapp.vbs (the .vbs is optional) and you'll have an instant list of all the App Pool information you've always wanted to know. You may need to type cscript iisapp.vbs if CScript isn't your default WSH script host.
Let's see an example of the output:
W3WP.exe PID: 1468 AppPoolId: AppPoolForSite1.com
W3WP.exe PID: 3056 AppPoolId: AppPoolForSite2.com
W3WP.exe PID: 1316 AppPoolId: AppPoolForSite3.com
Direct from the horse's mouth, Microsoft documents this:
http://www.microsoft.com/resources/documentation/WindowsServ/2003
Friday, September 25, 2009
Title Column Rename Issue
This post is from PFE legend, Godwin Tenzing:
Problem
Customer created a Custom Content Type from SharePoint Site Actions user interface and renamed the default SharePoint column e.g. “Title” to “FIO” and he tried to change it back to “Title”, but he was unable to rename it back to “Title” he received an error message “The Column name that you entered is already in use or reserved”
The issue can be reproduced like this
Customer created a custom content type from the Site Settings of the portal site. When he created a custom content type customer would have chosen to inherit parent content type for e.g Document as parent content type.
Custom content type was created successfully with a default SharePoint “Title” column which was inherited from the parent content type.
Customer clicked the content type column name “Title” and renamed the default “Title” column name for e.g. “Title” to “FIO”
He realised the column name “Title” had been renamed all over the Site Collection, so he tried to rename the modified column name “FIO” back to “Title” but he received the below error message
“The Column name that you entered is already in use or reserved”
Since “Title” is a reserved word in SharePoint, customer was unable to rename the column name back to “Title”.
What customer actually wanted to do is to rename the custom content type column name, but since “Title is the inherited column and it is default SharePoint column name, renaming the column had much wider implications.
Now the entire Portal Site Collection shows the column name “Title” as FIO and it cannot be renamed to “Title” in the SharePoint front end.
Customer now wants to rename the column name back to “Title”, but this cannot be done in the user interface.
Solution
The above issue is seen as design time limitation or as a bug, this will be raised with the product group to review and to fix it, if it is confirmed as bug by the product group then a fix will be provided in the future hot fixes.
However to get the issues resolved, we have found an easy solution for the issue, please use the below code to fix the above issue, however it is recommended to test the below console application code on your Test Server before applying it on to your live portal. Also it is recommended to take a complete back up of you portal content database.
Customer will have to create a console application project, once the project is created copy the code to the new project, and then compile the project.
Note: To successfully compile the project you will have to add reference to the “Microsoft.SharePoint.dll”
Microsoft.SharePoint.dll can be found in the SharePoint Server where MOSS 2007 is installed.
Path for the Microsoft.SharePoint.dll is “C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\ISAPI”
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
namespace RenameField
{
class Program
{
static void Main(string[] args)
{
if (args.Length < 3)
{
Console.WriteLine("Usage: RenameField ");
return;
}
SPSite site = new SPSite(args[0]);
SPField f = site.RootWeb.Fields[args[1]];
f.Title = args[2];
f.Update();
}
}
}
Disclaimer
/// this source code is freeware and is provided on an "as is" basis without warranties of any kind,
/// whether expresses or implied, including without limitation warranties that the code is free of defect,
/// fit for a particular purpose or non-infringing. The entire risk as to the quality and performance of
/// the code is with the end user.
As you will not be developing this console application in a live server, you will have to create a deployment project to run this console application on the server.
The proposed solution has certain limitations on a Multilingual site, so the code has to be modified to work on a multilingual site.
-------------------------------------------------------------------------------------
Any installation of WSS 3.0 or MOSS 2007 is no complete with PowerShell. Why? Because it makes situations like this so easy.
Save the following as SharePoint.ps1:
[System.Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c");
function Get-Site($absoluteUrl) {
return new-object Microsoft.SharePoint.SPSite $absoluteUrl;
}
function Rename-Field($site, $oldTitle, $newTitle) {
$field = $site.RootWeb.Fields[$oldTitle];
$field.Title = $newTitle;
$field.Update;
}
######## End of SharePoint.ps1 ########
Now the rename function is availble on request:
1> .\SharePoint.ps1
2> $site = Get-Site http://localhost/PlaySite
3> Rename-Field $site "FIO" "Title"
When it comes to SharePoint administration, PowerShell is your new best friend - no copmiled code, no deployment issues and you can sign all scripts for use on production servers.
-------------------------------------------------------------------------------------
This will not be fixed
I raised this as a bug in the beta program and the product team said it is not a bug and is by design and will not be fixed. They suggested exactly what you have designed. They said use the object model to correct the mistake.
Lets try again
I feel it is a bug, because by design it lets you change the title name to some other name. But it doesn't let you change it back to the old name 'Title', which is weird. If this is design limitation then we need at least a warning message to warn the actions. When the customer tried to rename the title column he thought he is changing the column name for his custom content type, he didn't realise it will update the column name for the entire site collection.
I have spoken to couple of escalation engineers. They have requested me to raise it as bug, so let’s wait and see what the product group feels about it this time.
I know this bug and can rename the column to the original 'Title' with SharePoint Manager tool.
Thanks!!!!!!! Not quite the same, ... this one worked for me: ----- [System.Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"); function Get-Site($absoluteUrl) { return new-object Microsoft.SharePoint.SPSite $absoluteUrl; } function Rename-Field($site, $oldTitle, $newTitle) { $field = $site.RootWeb.Fields[$oldTitle]; $field.Title = $newTitle; $field.Update(1); } $site = Get-Site("https://myportal/"); Rename-Field $site Title1 Title; ---- after 1st run, it did not see my functions in the shell, so I added the calls to the scripts. $filed.Update(1) so as to apply the cange down the line in all ascendant field (and content) types. Title1 was my NOT-THAT-old name :-) after system rejected to rename it back to title...
Updating all lists affected by the initial Title column rename
The following code goes one step further and walks all the lists in the site collection to rename any list columns that were affected when the site column was first changed:
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
namespace FieldRename
{
class Program
{
static void Main(string[] args)
{
if (args.Length < 3)
{
Console.WriteLine("Usage: RenameField ");
Console.WriteLine("/n Run under indentity of WebApplication app pool identity");
return;
}
SPSite site = new SPSite(args[0]);
try
{
SPField f = site.RootWeb.Fields[args[1]];
f.Title = args[2];
f.Update();
Console.WriteLine("Site Column: {0} renamed {1}", args[1], args[2]);
}
catch { }
UpdateSiteLists(site, args); // update lists in targeted site collection
}
static void UpdateSiteLists(SPSite site, string[] args)
{
foreach (SPWeb w in site.AllWebs)
{
Console.WriteLine("Scanning Site{0} ( Listcount: {1})",w.Title.ToString(), w.Lists.Count);
List lists = new List();
foreach(SPList l in w.Lists)
{
try
{
SPField lf = l.Fields[args[1]]; // exception if not found
lists.Add(l); // found
}
catch { }
}
foreach (SPList l in lists)
{
Console.WriteLine(" List {0} updated", l.Title);
SPField lf = l.Fields[args[1]];
lf.Title = args[2];
lf.Update();
}
}
}
}
}
at 4/26/2009 3:16 AM
Restore original title in a multilingual scenario
Hello, Thanks for the post. You said: "The proposed solution has certain limitations on a Multilingual site, so the code has to be modified to work on a multilingual site." Well, I've got that problem. I modified the column and now, it is not translated to other languages. What could I do?
at 5/14/2009 6:49 AM
Restore original title in a multilingual scenario
Hello, Thanks for the post. You said: "The proposed solution has certain limitations on a Multilingual site, so the code has to be modified to work on a multilingual site." Well, I've got that problem. I modified the column and now, it is not translated to other languages. What could I do?
at 5/14/2009 6:55 AM
This PowerShell Script worked for me
This worked like a dream, using PowerShell on the SharePoint server front-end:
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site=[Microsoft.Sharepoint.SPSite]("http://")
$web=$site.openWeb()
$fld = $web.Fields.getFieldByInternalName("Title")
$fld.Title = "Title"
$fld.PushChangesToLists = $true
$fld.Update()
at 7/1/2009 4:19 PM
Reply: This is Fixed in WSS 3.0 SP2
http://download.microsoft.com/download/7/A/3/7A3E2E01-5454-4427-95CB-28CE84523B0A/Windows%20SharePoint%20Services%203.0%20Service%20Pack%202%20Changes.xlsx
Chris Whitehead
at 7/2/2009 7:13 AM
Do not modify SQL!!
We have had some people post comments that you can fix this by using an UPDATE SQL statement on the ContentTypes table.
We will not be posting these since whilst this may work, it is COMPLETELY UNSUPPORTED and WILL render your environment unsupported. You should never modify your SQL backend. There are many completely supported solutions posted above. Please use one of these.
If you have already modified your databases, you should restore them to the point before the modification and use a proper fix to resolve the issue.
Sorry for the stern response but it is critical that customers follow the correct guidance on this. Many thanks!
Problem
Customer created a Custom Content Type from SharePoint Site Actions user interface and renamed the default SharePoint column e.g. “Title” to “FIO” and he tried to change it back to “Title”, but he was unable to rename it back to “Title” he received an error message “The Column name that you entered is already in use or reserved”
The issue can be reproduced like this
Customer created a custom content type from the Site Settings of the portal site. When he created a custom content type customer would have chosen to inherit parent content type for e.g Document as parent content type.
Custom content type was created successfully with a default SharePoint “Title” column which was inherited from the parent content type.
Customer clicked the content type column name “Title” and renamed the default “Title” column name for e.g. “Title” to “FIO”
He realised the column name “Title” had been renamed all over the Site Collection, so he tried to rename the modified column name “FIO” back to “Title” but he received the below error message
“The Column name that you entered is already in use or reserved”
Since “Title” is a reserved word in SharePoint, customer was unable to rename the column name back to “Title”.
What customer actually wanted to do is to rename the custom content type column name, but since “Title is the inherited column and it is default SharePoint column name, renaming the column had much wider implications.
Now the entire Portal Site Collection shows the column name “Title” as FIO and it cannot be renamed to “Title” in the SharePoint front end.
Customer now wants to rename the column name back to “Title”, but this cannot be done in the user interface.
Solution
The above issue is seen as design time limitation or as a bug, this will be raised with the product group to review and to fix it, if it is confirmed as bug by the product group then a fix will be provided in the future hot fixes.
However to get the issues resolved, we have found an easy solution for the issue, please use the below code to fix the above issue, however it is recommended to test the below console application code on your Test Server before applying it on to your live portal. Also it is recommended to take a complete back up of you portal content database.
Customer will have to create a console application project, once the project is created copy the code to the new project, and then compile the project.
Note: To successfully compile the project you will have to add reference to the “Microsoft.SharePoint.dll”
Microsoft.SharePoint.dll can be found in the SharePoint Server where MOSS 2007 is installed.
Path for the Microsoft.SharePoint.dll is “C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\ISAPI”
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
namespace RenameField
{
class Program
{
static void Main(string[] args)
{
if (args.Length < 3)
{
Console.WriteLine("Usage: RenameField
return;
}
SPSite site = new SPSite(args[0]);
SPField f = site.RootWeb.Fields[args[1]];
f.Title = args[2];
f.Update();
}
}
}
Disclaimer
/// this source code is freeware and is provided on an "as is" basis without warranties of any kind,
/// whether expresses or implied, including without limitation warranties that the code is free of defect,
/// fit for a particular purpose or non-infringing. The entire risk as to the quality and performance of
/// the code is with the end user.
As you will not be developing this console application in a live server, you will have to create a deployment project to run this console application on the server.
The proposed solution has certain limitations on a Multilingual site, so the code has to be modified to work on a multilingual site.
-------------------------------------------------------------------------------------
Any installation of WSS 3.0 or MOSS 2007 is no complete with PowerShell. Why? Because it makes situations like this so easy.
Save the following as SharePoint.ps1:
[System.Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c");
function Get-Site($absoluteUrl) {
return new-object Microsoft.SharePoint.SPSite $absoluteUrl;
}
function Rename-Field($site, $oldTitle, $newTitle) {
$field = $site.RootWeb.Fields[$oldTitle];
$field.Title = $newTitle;
$field.Update;
}
######## End of SharePoint.ps1 ########
Now the rename function is availble on request:
1> .\SharePoint.ps1
2> $site = Get-Site http://localhost/PlaySite
3> Rename-Field $site "FIO" "Title"
When it comes to SharePoint administration, PowerShell is your new best friend - no copmiled code, no deployment issues and you can sign all scripts for use on production servers.
-------------------------------------------------------------------------------------
This will not be fixed
I raised this as a bug in the beta program and the product team said it is not a bug and is by design and will not be fixed. They suggested exactly what you have designed. They said use the object model to correct the mistake.
Lets try again
I feel it is a bug, because by design it lets you change the title name to some other name. But it doesn't let you change it back to the old name 'Title', which is weird. If this is design limitation then we need at least a warning message to warn the actions. When the customer tried to rename the title column he thought he is changing the column name for his custom content type, he didn't realise it will update the column name for the entire site collection.
I have spoken to couple of escalation engineers. They have requested me to raise it as bug, so let’s wait and see what the product group feels about it this time.
I know this bug and can rename the column to the original 'Title' with SharePoint Manager tool.
Thanks!!!!!!! Not quite the same, ... this one worked for me: ----- [System.Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"); function Get-Site($absoluteUrl) { return new-object Microsoft.SharePoint.SPSite $absoluteUrl; } function Rename-Field($site, $oldTitle, $newTitle) { $field = $site.RootWeb.Fields[$oldTitle]; $field.Title = $newTitle; $field.Update(1); } $site = Get-Site("https://myportal/"); Rename-Field $site Title1 Title; ---- after 1st run, it did not see my functions in the shell, so I added the calls to the scripts. $filed.Update(1) so as to apply the cange down the line in all ascendant field (and content) types. Title1 was my NOT-THAT-old name :-) after system rejected to rename it back to title...
Updating all lists affected by the initial Title column rename
The following code goes one step further and walks all the lists in the site collection to rename any list columns that were affected when the site column was first changed:
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
namespace FieldRename
{
class Program
{
static void Main(string[] args)
{
if (args.Length < 3)
{
Console.WriteLine("Usage: RenameField
Console.WriteLine("/n Run under indentity of WebApplication app pool identity");
return;
}
SPSite site = new SPSite(args[0]);
try
{
SPField f = site.RootWeb.Fields[args[1]];
f.Title = args[2];
f.Update();
Console.WriteLine("Site Column: {0} renamed {1}", args[1], args[2]);
}
catch { }
UpdateSiteLists(site, args); // update lists in targeted site collection
}
static void UpdateSiteLists(SPSite site, string[] args)
{
foreach (SPWeb w in site.AllWebs)
{
Console.WriteLine("Scanning Site{0} ( Listcount: {1})",w.Title.ToString(), w.Lists.Count);
List
foreach(SPList l in w.Lists)
{
try
{
SPField lf = l.Fields[args[1]]; // exception if not found
lists.Add(l); // found
}
catch { }
}
foreach (SPList l in lists)
{
Console.WriteLine(" List {0} updated", l.Title);
SPField lf = l.Fields[args[1]];
lf.Title = args[2];
lf.Update();
}
}
}
}
}
at 4/26/2009 3:16 AM
Restore original title in a multilingual scenario
Hello, Thanks for the post. You said: "The proposed solution has certain limitations on a Multilingual site, so the code has to be modified to work on a multilingual site." Well, I've got that problem. I modified the column and now, it is not translated to other languages. What could I do?
at 5/14/2009 6:49 AM
Restore original title in a multilingual scenario
Hello, Thanks for the post. You said: "The proposed solution has certain limitations on a Multilingual site, so the code has to be modified to work on a multilingual site." Well, I've got that problem. I modified the column and now, it is not translated to other languages. What could I do?
at 5/14/2009 6:55 AM
This PowerShell Script worked for me
This worked like a dream, using PowerShell on the SharePoint server front-end:
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site=[Microsoft.Sharepoint.SPSite]("http://
$web=$site.openWeb()
$fld = $web.Fields.getFieldByInternalName("Title")
$fld.Title = "Title"
$fld.PushChangesToLists = $true
$fld.Update()
at 7/1/2009 4:19 PM
Reply: This is Fixed in WSS 3.0 SP2
http://download.microsoft.com/download/7/A/3/7A3E2E01-5454-4427-95CB-28CE84523B0A/Windows%20SharePoint%20Services%203.0%20Service%20Pack%202%20Changes.xlsx
Chris Whitehead
at 7/2/2009 7:13 AM
Do not modify SQL!!
We have had some people post comments that you can fix this by using an UPDATE SQL statement on the ContentTypes table.
We will not be posting these since whilst this may work, it is COMPLETELY UNSUPPORTED and WILL render your environment unsupported. You should never modify your SQL backend. There are many completely supported solutions posted above. Please use one of these.
If you have already modified your databases, you should restore them to the point before the modification and use a proper fix to resolve the issue.
Sorry for the stern response but it is critical that customers follow the correct guidance on this. Many thanks!
Tuesday, September 22, 2009
SharePoint as a Web Services Platform
SharePoint as a Web Services Platform
The recent buzz around cloud computing is a new business phenomenon, but Windows SharePoint Services (WSS) 3.0 has always come out of the box with web services and protocols designed to be location-independent. The functionality offered by these web services isn’t a new idea, and SharePoint’s HTTP client/server communication functions the same way whether the client and server are located in the same room, or if the server is a virtualized guest machine in a cloud datacenter. Furthermore, Microsoft Office SharePoint Server (MOSS) 2007 adds additional web services to the base package provided by WSS 3.0 that interact with specific office applications, and SharePoint supports the addition of customized services and assemblies to its global assembly cache so that any web application can take advantage of the SharePoint environment.
In this column I discuss the components and protocols that enable SharePoint’s integration with client programs and outline some of the most-used functions that are exposed as web services by WSS 3.0 and MOSS 2007. These web services are a powerful method that SharePoint users and developers can use to extend the functionality of the collaboration environment as well as develop custom applications accessible from anywhere, but the architecture is complicated by the myriad components required to enable comprehensive client functionality. Despite the standard of a web service as an ASP.NET page (in .asmx format) that exposes methods to clients, SharePoint’s Office 2007 client integration also uses ActiveX browser controls, .aspx APIs, directly called assemblies, and legacy protocols that are more ancestors of modern web services than true web services themselves. While SharePoint’s core web service functionality is encapsulated in .asmx pages, the necessity of retaining backward compatibility with older applications—and the popularity of third party APIs—makes the SharePoint web services world an often-confusing one. If you would like to follow the explanations in this article in a test environment, see the companion material for this article at technetmagazine.com.
HTTP-based Communication with SharePoint
The model currently used by WSS 3.0 for client-server communication is based on the philosophy that not only Microsoft’s own clients but also ASP.NET web parts and third party applications will make calls on the server’s exposed web services. The underpinning technologies of this interoperability are SOAP and XML. The actual information of a web service call is encapsulated in XML, which is then placed in a SOAP wrapper and sent via HTTP to the WSS 3.0 server. For example, a Microsoft Office 2007 Application that needs to modify a SharePoint list will call the Lists (/_vti_bin/lists.asmx) web service’s methods by encapsulating the method calls in XML. What each method of each web service returns is obviously variable, and beyond the scope of this article (but see http://msdn.com/en-us/library/ms445292.aspx and http://msdn.com /en-us/library/ms542012.aspx to get started). As I discussed in previous articles, simple HTTP requests are caught by ISAPI filters on the server so that the client’s requests for virtualized URLs can be handled seamlessly. By using HTTP requests and web service method calls, remote client applications can programmatically perform the same site provisioning, architecting, and document management tasks accessible from the SharePoint browser interface.
Of course, there is more to the story than just straightforward HTTP requests to virtualized URLs and method calls to web services. Office 2007 applications make calls directly to the FrontPage server extensions (through /_vti_bin/ossvr.dll, author.dll, and admin.dll) and use the WebDAV protocol for document management. Some web parts viewable directly in the browser also call web services to generate standard HTML (such as Excel Web Access), while others run ActiveX browser controls that require client-side components installed as part of Microsoft Office 2007 (such as Access Web Datasheet). SharePoint also makes extensive use of the StsSync protocol, which is unique in that it is simply a URI read by a client handler control, which then passes the encapsulated instructions to a client application. The actual communication between the client and server is handled entirely by the standard web service protocols such as Lists.asmx. In the context of this article, I focus specifically on ASP.NET web service pages and only cover the other protocols as necessary to explain the functionality of specific Office applications. If you are interested in learning more about the full spectrum of protocols used by Microsoft Office 2007 client applications, see http://msdn.com/en-us/library/cc339482.aspx.
WSS 3.0 Web Services
Programmatic interaction with the SharePoint environment means putting HTTP requests to the web services that WSS 3.0 exposes. A full list of these services can be found at http://msdn.com/en-us/library/ms445292.aspx, but a few are commonly called by every program that interfaces with SharePoint. The Lists web service (/_vti_bin/lists.asmx, http://msdn.com/en-us/library/lists.aspx) exposes methods for creating, editing, deleting, and accessing SharePoint lists. Every client application that uses lists or document libraries (which are a type of list) uses it. Similarly, the Webs web service (/_vti_bin/lists.asmx, http://msdn.com/en-us/library/webs.aspx) exposes methods that are used to get information about a SharePoint site, such as the activated features and content types. Other services such as the Admin web service (/_vti_bin/admin.asmx, http://msdn.com/en-us/library/administration.admin.aspx), which exposes the methods to create and delete site collections in SharePoint, are used infrequently (if ever), but demonstrate the scope of the functions available to remote clients in WSS 3.0.
Microsoft Office Access 2007 extracts all of its SharePoint integration from the WSS 3.0 web services package, without any need for additional components. Access can publish database files directly to SharePoint and benefit from the environment’s document versioning and workflow systems. Access also has the ability to open a SharePoint list, update it dynamically, and use all of the Access client functions to search or edit it. From the user’s perspective, a SharePoint list opened in Access or an Access database converted into a SharePoint list and then opened in the client is no different than a locally stored database. Although SharePoint cannot enforce true referential integrity in its lists (users moving databases with referential cells to SharePoint will receive a warning message to that effect), it does allow references between lists as though they were tables. Behind the scenes, Access calls the Lists and Webs services on the server every time the user modifies a record to ensure that the SharePoint data is synchronized with what the user sees.
Access also supports browser-based access to SharePoint lists with the Access Web Datasheet control. This control is installed on the client computer with Office 2007 and renders lists in a spreadsheet-like format when the user opens the Actions menu on any list in SharePoint and clicks Edit in Datasheet. The Web Datasheet control also calls web services so that the information changes can be incrementally posted back to the server rather than requiring .aspx forms be filled out and posted, but it is not a truly interoperable client. The Access Web Datasheet control is installed as a component of Microsoft Office 2007 (by default, at C:\Program Files\Microsoft Office\Office12\stslist.dll), so thin clients without that software do not support it (and the menu option is removed in SharePoint). This contrasts with the Excel Web Access browser client, which is discussed in the next section.
WSS 3.0 also supports blogging out of the box with a blog site template and management web interface. Microsoft Office Word 2007 gives an alternative to the browser interface through the MetaWeblog API, which is called through /_vti_bin/metaweblog.aspx on the server. The API only exposes a handful of methods, but it still communicates over HTTP using XML remote procedure calls. However, the MetaWeblog API was developed by a third party (read the specification at http://www.xmlrpc.com/metaWeblogApi), so it does not conform to Microsoft standards. Word 2007 also supports the Atom Publishing Protocol and Atom Syndication format, but these protocols are not used by SharePoint.
MOSS 2007 Web Services
WSS 3.0’s standard web services offer many tools for accessing and modifying SharePoint data with powerful client applications. However, WSS 3.0 is also a platform for more specialized and powerful web services, and those added by installing Microsoft Office SharePoint Server 2007 are good examples of how web services can expand the functionality of SharePoint from being a collaboration environment to a true platform for web applications.
A simple expression of a specialized web service can be found in MOSS 2007’s Slide Library service (/_vti_bin/slidelibrary.asmx, http://msdn.com/en-us/library/bb862916.aspx), which is called by Microsoft Office PowerPoint 2007 to break up PowerPoint decks with many slides into files that contain only a single slide each, and then upload them to a SharePoint slide document library. These slides can then be re-used in future presentations from an interface within the PowerPoint client, with their content dynamically updated to reflect changes to the SharePoint version. This is accomplished by use of the Slide Library Protocol (http://msdn. com/en-us/library/cc313135.aspx) which is used only by the SlideLibrary.asmx web service. The protocol enables the PowerPoint 2007 client to query metadata such as the ID numbers of individual slides (both within the slide library and scoped to the entire SharePoint server), authoring information, and the name of the PowerPoint presentation from which the slide originated.
Other Office applications are associated with more expansive web services. Microsoft Office InfoPath 2007 has its own specialized web service (/_vti_bin/FormsServices.asmx, view the SDK documentation at http://msdn.microsoft.com/en-us/library/bb877920.aspx) which is included both in MOSS 2007 and also a separate SKU, Microsoft Office Forms Server 2007. The included functionality is the same in either case. Form templates uploaded to a SharePoint site can pull data from other web services, run declarative business logic on the server, and post data to web services from the form. For example, an InfoPath form could require that a user enter their SharePoint user name into a field, which would be posted to the /_vti_bin/usergroup.asmx web service in order to return a SOAP message containing the requested information. Form templates that are approved by a farm level administrator can also contain managed code in addition to simple web service requests. The data-gathering capabilities of Form Services are further extended by the ability to deliver forms to clients with only a web browser.
When a client makes a request for a form on the SharePoint site, Forms Services detects whether the client has InfoPath 2007 installed, and if not directs them to /_layouts/FormServer.aspx. FormServer.aspx contains the XMLFormView web part, which renders InfoPath forms so that only a web browser is needed to fill them in and post the information back to the server. If the form needs to interact with data or business logic, XMLFormView posts back the user-entered information so that the necessary calculations can be executed on the server. Regardless of whether the user fills out a form in the InfoPath 2007 client or in a web browser, Forms Services offers integrated access to all of the SharePoint web services and data available, including the calculation engine in Excel Calculation Services.
This calculation engine, exposed through the Excel Services web service (/_vti_bin/ExcelService.asmx, http://msdn.com/en-us/library/microsoft.office.excel.server.webservices.excelservice.aspx), provides the same calculation functions as the Microsoft Office Excel 2007 desktop application. But because Excel Calculation Services (ECS) is run as a shared service across the entire SharePoint server farm, it is automatically load balanced across all servers that have it enabled. Resource intensive calculation tasks and reports can be compiled in live Excel workbooks by using the processing power of a dedicated (or multiple dedicated) application servers. MOSS 2007 also includes an Excel Web Access web part, which makes these functions accessible to browser-based clients, without any need for client-side components (as is the case for Access Web Datasheet). For more information about Excel Services, including step-by-step guides, see TechNet’s white paper on the subject from March of last year (http://technet.microsoft.com/en-us/library/cc263430.aspx).
Custom Web Services
WSS 3.0 and MOSS 2007 expose a lot of functionality through their web services, but SharePoint also supports custom web services and applications that can be deployed into the global assembly cache and function the same way as native SharePoint services. A web service is registered on a server with WSS 3.0 enabled by its discovery files and asmx file, which are found in the web directory http://serverhost/_vti_bin/. On the server’s hard drive, this maps to \Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI. There is also a subfolder of this directory named \_vti_adm\. Web service files deployed to this directory will only be accessible to users and clients with farm administrator credentials. Finally, the web service must also be registered in \Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI\spdisco.aspx. For a procedural walkthrough of the deployment process and instructions on how to implement the SharePoint object model into your custom services (and creating client applications that consume those services), see http://msdn.com/en-us/library/ms464040.aspx.
Developing custom web services and client applications requires knowledge of the protocols by which clients communicate with the existing web services. The MSDN protocol reference documents (http://msdn.com/en-us/library/cc341379.aspx) contain all of the information about the protocols used in client/server communication and what components are the traffic endpoints for each protocol. You will also need a working knowledge of ASP.NET 2.0 and the existing WSS 3.0 and MOSS 2007 APIs. A custom SharePoint solution (web services being one example) consists of the .NET assemblies to power it, any resources such as images, XML schema, or new SharePoint templates needed to display the solution, the configuration information added to the server’s web.config file and elsewhere (depending on what the solution contains), and a manifest file that gives WSS instructions on how to deploy your solution. Visual Studio packages all of these components into a .wsp file for easy deployment and testing. Detailed information about the development requirements, skill sets, and deployment capabilities of SharePoint environments can be found in Patrick Tisseghem’s how-to guide, “Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0.” (http://msdn.com/en-us/library/bb530302.aspx)
In this simple example solution, I developed. To follow this example in a test environment, see the companion material at technetmagazine.com. a short couple of paragraphs about the example solution, why it’s a good example, how it works, and how to deploy it follows.
Web Services and Web Applications
As a web service platform, SharePoint is “solution ready” for custom services as well as coming out of the box with many ready-to-use services. MOSS 2007 expands this functionality to include specialized web services designed to extend the functionality of the 2007 Office suite with powerful remote computing and business logic capabilities thanks to Excel Services and Forms Services. These technologies are leveraged by companies that want to move their IT operations into a cloud computing model, but the actual functionality doesn’t change no matter where they are deployed.
The real utility of SharePoint’s model of web services and applications isn’t that they can be deployed in a cloud computing environment, but rather that they are accessible by browser-based clients as well as third party software. Custom extensions to these features can potentially give every application the SharePoint integration that makes Microsoft Office 2007’s interaction with SharePoint so seamless.
The introduction of web applications based on web part pages (such as Excel Web Access) takes this concept of interoperability one step further. Instead of deploying a client application to every work station that might conceivably need to access a workbook, even if only to look at it or run parameterized calculations, the ubiquitous web browser becomes the client application. With all of the content stored solely in the SharePoint content database and all of the calculations run on the application server, there is no longer any need to disseminate information to potentially unsecure workstation computers. Furthermore, those clients no longer need the hardware to perform resource-intensive, enterprise-level calculations. The information stays on the most secure, most powerful hardware available, while thin clients get “rich-client functionality” from their web browsers.
The recent buzz around cloud computing is a new business phenomenon, but Windows SharePoint Services (WSS) 3.0 has always come out of the box with web services and protocols designed to be location-independent. The functionality offered by these web services isn’t a new idea, and SharePoint’s HTTP client/server communication functions the same way whether the client and server are located in the same room, or if the server is a virtualized guest machine in a cloud datacenter. Furthermore, Microsoft Office SharePoint Server (MOSS) 2007 adds additional web services to the base package provided by WSS 3.0 that interact with specific office applications, and SharePoint supports the addition of customized services and assemblies to its global assembly cache so that any web application can take advantage of the SharePoint environment.
In this column I discuss the components and protocols that enable SharePoint’s integration with client programs and outline some of the most-used functions that are exposed as web services by WSS 3.0 and MOSS 2007. These web services are a powerful method that SharePoint users and developers can use to extend the functionality of the collaboration environment as well as develop custom applications accessible from anywhere, but the architecture is complicated by the myriad components required to enable comprehensive client functionality. Despite the standard of a web service as an ASP.NET page (in .asmx format) that exposes methods to clients, SharePoint’s Office 2007 client integration also uses ActiveX browser controls, .aspx APIs, directly called assemblies, and legacy protocols that are more ancestors of modern web services than true web services themselves. While SharePoint’s core web service functionality is encapsulated in .asmx pages, the necessity of retaining backward compatibility with older applications—and the popularity of third party APIs—makes the SharePoint web services world an often-confusing one. If you would like to follow the explanations in this article in a test environment, see the companion material for this article at technetmagazine.com.
HTTP-based Communication with SharePoint
The model currently used by WSS 3.0 for client-server communication is based on the philosophy that not only Microsoft’s own clients but also ASP.NET web parts and third party applications will make calls on the server’s exposed web services. The underpinning technologies of this interoperability are SOAP and XML. The actual information of a web service call is encapsulated in XML, which is then placed in a SOAP wrapper and sent via HTTP to the WSS 3.0 server. For example, a Microsoft Office 2007 Application that needs to modify a SharePoint list will call the Lists (/_vti_bin/lists.asmx) web service’s methods by encapsulating the method calls in XML. What each method of each web service returns is obviously variable, and beyond the scope of this article (but see http://msdn.com/en-us/library/ms445292.aspx and http://msdn.com /en-us/library/ms542012.aspx to get started). As I discussed in previous articles, simple HTTP requests are caught by ISAPI filters on the server so that the client’s requests for virtualized URLs can be handled seamlessly. By using HTTP requests and web service method calls, remote client applications can programmatically perform the same site provisioning, architecting, and document management tasks accessible from the SharePoint browser interface.
Of course, there is more to the story than just straightforward HTTP requests to virtualized URLs and method calls to web services. Office 2007 applications make calls directly to the FrontPage server extensions (through /_vti_bin/ossvr.dll, author.dll, and admin.dll) and use the WebDAV protocol for document management. Some web parts viewable directly in the browser also call web services to generate standard HTML (such as Excel Web Access), while others run ActiveX browser controls that require client-side components installed as part of Microsoft Office 2007 (such as Access Web Datasheet). SharePoint also makes extensive use of the StsSync protocol, which is unique in that it is simply a URI read by a client handler control, which then passes the encapsulated instructions to a client application. The actual communication between the client and server is handled entirely by the standard web service protocols such as Lists.asmx. In the context of this article, I focus specifically on ASP.NET web service pages and only cover the other protocols as necessary to explain the functionality of specific Office applications. If you are interested in learning more about the full spectrum of protocols used by Microsoft Office 2007 client applications, see http://msdn.com/en-us/library/cc339482.aspx.
WSS 3.0 Web Services
Programmatic interaction with the SharePoint environment means putting HTTP requests to the web services that WSS 3.0 exposes. A full list of these services can be found at http://msdn.com/en-us/library/ms445292.aspx, but a few are commonly called by every program that interfaces with SharePoint. The Lists web service (/_vti_bin/lists.asmx, http://msdn.com/en-us/library/lists.aspx) exposes methods for creating, editing, deleting, and accessing SharePoint lists. Every client application that uses lists or document libraries (which are a type of list) uses it. Similarly, the Webs web service (/_vti_bin/lists.asmx, http://msdn.com/en-us/library/webs.aspx) exposes methods that are used to get information about a SharePoint site, such as the activated features and content types. Other services such as the Admin web service (/_vti_bin/admin.asmx, http://msdn.com/en-us/library/administration.admin.aspx), which exposes the methods to create and delete site collections in SharePoint, are used infrequently (if ever), but demonstrate the scope of the functions available to remote clients in WSS 3.0.
Microsoft Office Access 2007 extracts all of its SharePoint integration from the WSS 3.0 web services package, without any need for additional components. Access can publish database files directly to SharePoint and benefit from the environment’s document versioning and workflow systems. Access also has the ability to open a SharePoint list, update it dynamically, and use all of the Access client functions to search or edit it. From the user’s perspective, a SharePoint list opened in Access or an Access database converted into a SharePoint list and then opened in the client is no different than a locally stored database. Although SharePoint cannot enforce true referential integrity in its lists (users moving databases with referential cells to SharePoint will receive a warning message to that effect), it does allow references between lists as though they were tables. Behind the scenes, Access calls the Lists and Webs services on the server every time the user modifies a record to ensure that the SharePoint data is synchronized with what the user sees.
Access also supports browser-based access to SharePoint lists with the Access Web Datasheet control. This control is installed on the client computer with Office 2007 and renders lists in a spreadsheet-like format when the user opens the Actions menu on any list in SharePoint and clicks Edit in Datasheet. The Web Datasheet control also calls web services so that the information changes can be incrementally posted back to the server rather than requiring .aspx forms be filled out and posted, but it is not a truly interoperable client. The Access Web Datasheet control is installed as a component of Microsoft Office 2007 (by default, at C:\Program Files\Microsoft Office\Office12\stslist.dll), so thin clients without that software do not support it (and the menu option is removed in SharePoint). This contrasts with the Excel Web Access browser client, which is discussed in the next section.
WSS 3.0 also supports blogging out of the box with a blog site template and management web interface. Microsoft Office Word 2007 gives an alternative to the browser interface through the MetaWeblog API, which is called through /_vti_bin/metaweblog.aspx on the server. The API only exposes a handful of methods, but it still communicates over HTTP using XML remote procedure calls. However, the MetaWeblog API was developed by a third party (read the specification at http://www.xmlrpc.com/metaWeblogApi), so it does not conform to Microsoft standards. Word 2007 also supports the Atom Publishing Protocol and Atom Syndication format, but these protocols are not used by SharePoint.
MOSS 2007 Web Services
WSS 3.0’s standard web services offer many tools for accessing and modifying SharePoint data with powerful client applications. However, WSS 3.0 is also a platform for more specialized and powerful web services, and those added by installing Microsoft Office SharePoint Server 2007 are good examples of how web services can expand the functionality of SharePoint from being a collaboration environment to a true platform for web applications.
A simple expression of a specialized web service can be found in MOSS 2007’s Slide Library service (/_vti_bin/slidelibrary.asmx, http://msdn.com/en-us/library/bb862916.aspx), which is called by Microsoft Office PowerPoint 2007 to break up PowerPoint decks with many slides into files that contain only a single slide each, and then upload them to a SharePoint slide document library. These slides can then be re-used in future presentations from an interface within the PowerPoint client, with their content dynamically updated to reflect changes to the SharePoint version. This is accomplished by use of the Slide Library Protocol (http://msdn. com/en-us/library/cc313135.aspx) which is used only by the SlideLibrary.asmx web service. The protocol enables the PowerPoint 2007 client to query metadata such as the ID numbers of individual slides (both within the slide library and scoped to the entire SharePoint server), authoring information, and the name of the PowerPoint presentation from which the slide originated.
Other Office applications are associated with more expansive web services. Microsoft Office InfoPath 2007 has its own specialized web service (/_vti_bin/FormsServices.asmx, view the SDK documentation at http://msdn.microsoft.com/en-us/library/bb877920.aspx) which is included both in MOSS 2007 and also a separate SKU, Microsoft Office Forms Server 2007. The included functionality is the same in either case. Form templates uploaded to a SharePoint site can pull data from other web services, run declarative business logic on the server, and post data to web services from the form. For example, an InfoPath form could require that a user enter their SharePoint user name into a field, which would be posted to the /_vti_bin/usergroup.asmx web service in order to return a SOAP message containing the requested information. Form templates that are approved by a farm level administrator can also contain managed code in addition to simple web service requests. The data-gathering capabilities of Form Services are further extended by the ability to deliver forms to clients with only a web browser.
When a client makes a request for a form on the SharePoint site, Forms Services detects whether the client has InfoPath 2007 installed, and if not directs them to /_layouts/FormServer.aspx. FormServer.aspx contains the XMLFormView web part, which renders InfoPath forms so that only a web browser is needed to fill them in and post the information back to the server. If the form needs to interact with data or business logic, XMLFormView posts back the user-entered information so that the necessary calculations can be executed on the server. Regardless of whether the user fills out a form in the InfoPath 2007 client or in a web browser, Forms Services offers integrated access to all of the SharePoint web services and data available, including the calculation engine in Excel Calculation Services.
This calculation engine, exposed through the Excel Services web service (/_vti_bin/ExcelService.asmx, http://msdn.com/en-us/library/microsoft.office.excel.server.webservices.excelservice.aspx), provides the same calculation functions as the Microsoft Office Excel 2007 desktop application. But because Excel Calculation Services (ECS) is run as a shared service across the entire SharePoint server farm, it is automatically load balanced across all servers that have it enabled. Resource intensive calculation tasks and reports can be compiled in live Excel workbooks by using the processing power of a dedicated (or multiple dedicated) application servers. MOSS 2007 also includes an Excel Web Access web part, which makes these functions accessible to browser-based clients, without any need for client-side components (as is the case for Access Web Datasheet). For more information about Excel Services, including step-by-step guides, see TechNet’s white paper on the subject from March of last year (http://technet.microsoft.com/en-us/library/cc263430.aspx).
Custom Web Services
WSS 3.0 and MOSS 2007 expose a lot of functionality through their web services, but SharePoint also supports custom web services and applications that can be deployed into the global assembly cache and function the same way as native SharePoint services. A web service is registered on a server with WSS 3.0 enabled by its discovery files and asmx file, which are found in the web directory http://serverhost/_vti_bin/. On the server’s hard drive, this maps to \Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI. There is also a subfolder of this directory named \_vti_adm\. Web service files deployed to this directory will only be accessible to users and clients with farm administrator credentials. Finally, the web service must also be registered in \Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI\spdisco.aspx. For a procedural walkthrough of the deployment process and instructions on how to implement the SharePoint object model into your custom services (and creating client applications that consume those services), see http://msdn.com/en-us/library/ms464040.aspx.
Developing custom web services and client applications requires knowledge of the protocols by which clients communicate with the existing web services. The MSDN protocol reference documents (http://msdn.com/en-us/library/cc341379.aspx) contain all of the information about the protocols used in client/server communication and what components are the traffic endpoints for each protocol. You will also need a working knowledge of ASP.NET 2.0 and the existing WSS 3.0 and MOSS 2007 APIs. A custom SharePoint solution (web services being one example) consists of the .NET assemblies to power it, any resources such as images, XML schema, or new SharePoint templates needed to display the solution, the configuration information added to the server’s web.config file and elsewhere (depending on what the solution contains), and a manifest file that gives WSS instructions on how to deploy your solution. Visual Studio packages all of these components into a .wsp file for easy deployment and testing. Detailed information about the development requirements, skill sets, and deployment capabilities of SharePoint environments can be found in Patrick Tisseghem’s how-to guide, “Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0.” (http://msdn.com/en-us/library/bb530302.aspx)
In this simple example solution, I developed
Web Services and Web Applications
As a web service platform, SharePoint is “solution ready” for custom services as well as coming out of the box with many ready-to-use services. MOSS 2007 expands this functionality to include specialized web services designed to extend the functionality of the 2007 Office suite with powerful remote computing and business logic capabilities thanks to Excel Services and Forms Services. These technologies are leveraged by companies that want to move their IT operations into a cloud computing model, but the actual functionality doesn’t change no matter where they are deployed.
The real utility of SharePoint’s model of web services and applications isn’t that they can be deployed in a cloud computing environment, but rather that they are accessible by browser-based clients as well as third party software. Custom extensions to these features can potentially give every application the SharePoint integration that makes Microsoft Office 2007’s interaction with SharePoint so seamless.
The introduction of web applications based on web part pages (such as Excel Web Access) takes this concept of interoperability one step further. Instead of deploying a client application to every work station that might conceivably need to access a workbook, even if only to look at it or run parameterized calculations, the ubiquitous web browser becomes the client application. With all of the content stored solely in the SharePoint content database and all of the calculations run on the application server, there is no longer any need to disseminate information to potentially unsecure workstation computers. Furthermore, those clients no longer need the hardware to perform resource-intensive, enterprise-level calculations. The information stays on the most secure, most powerful hardware available, while thin clients get “rich-client functionality” from their web browsers.
Tuesday, September 1, 2009
SSL Certificate Troubleshooting
After installing my SSL Certificate, some browsers report that my SSL Certificate was signed by an unknown or untrusted Certificate Authority.
For all of our clients running Microsoft Internet Information Services 6 or higher, you may find that after installing your new certificate via the supplied .p7b file, some browsers report that the SSL Certificate was signed by an unknown / untrusted Certificate Authority. This is due to a Self-Signed Certificate present in the Windows 2003/2008 Certificate Store, and should be removed.
This is due to a known issue with IIS 6/7. To correct this, the following procedure has been provided.
Open the Certificate Store for the Local Computer:
1. From the Desktop of your IIS Server, click "Start", then "Run", type 'mmc' (without the quotes), and then click "OK".
https://ssl.trustwave.com/images/support/rm_stca_fig-01.png
2. On the "File" menu, click "Add/Remove Snap-in" (See image below). A dialog box titled "Add/Remove Snap-in" will appear. Click the "Add" button. This will cause a window titled "Add Standalone Snap-in" to appear.
3. On the window titled "Add Standalone Snap-in", under "Snap-in", click "Certificates", then click the "Add" button at the bottom of the window.
4. A window titled "Certificates snap-in" will open (see image below), asking you to choose which certificates to manage. Click the radio button next to "Computer account" (the lower of the three options), and then click "Next". This will open a new window titled "Select Computer".
5. In the "Select Computer" window, click the radio button for "Local Computer" and then click "Finish". You will return to the "Add Standalone Snap-in" window.
6. Now to finish up the selections. On the "Add Standalone Snap-in" window, click the "Close" button. The "Add/Remove Snap-in" window should now have the "Certificates (Local Computer)" snap-in added to it. Click the "OK" button at the bottom of the window.
Remove the SecureTrustCA certificate:
1. In the left-hand pane, click on "Certificates (Local Computer)", then click on "Trusted Root Certification Authorities", and finally then click on "Certificates".
2. On the right-hand pane, scroll down till you see a Certificate that has been Issued To: and Issued By: "SecureTrust CA". This is the Self-Signed SSL Certificate that is susceptible to a known issue with IIS 6/7. There should be only one certificate.
3. Delete the certificate. You should receive a warning dialog box that states "This is a root certificate. Deleting this certificate will invalidate this CA. Are you certain you want to delete this certificate?".
4. Click yes.
Now restart the website via the IIS Manager.
My browser says "The security certificate was issued by a company you have not chosen to trust" or it says that it can't trust the Certificate Authority.
This error means that your browser is unable to authenticate your new Trustwave certificate. There are two main causes for this error:
The most common cause is that your intermediate certificates aren't installed or may not be installed properly. These intermediate certificates explain to the browser that the certificate can be trusted. Once they're installed properly, the error will disappear. Please return to the corresponding installation procedures for your server and complete the installation.
The other cause may be that your Trustwave SSL certificate isn't fully installed. Many servers actually create a "self-signed" or temporary certificate when you first create your CSR and private key. WHM, Plesk, and Zeus are just a few examples of servers that do this. Sometimes this certificate isn't removed when you install the Trustwave SSL certificate. Verify that your actual Trustwave certificate is installed rather than the self-signed certificate.
My browser says "The security certificate has expired or is not yet valid" or it displays some other type of error about validity and expiration dates.
This means that your certificate is either expired or not yet valid when the dates on the certificate are compared to your local computer's clock. There's two main reasons this error may appear: Your certificate may actually be expired. If you log into the Trustwave Control Center, your certificate's expiration date will appear there. If the expiration date has passed, don't worry - you can renew your certificate quite easily. You can renew it via the Trustwave Control Center, or you can call us and we can take care of it over the phone instantly.
If the expiration date hasn't passed, double check your computer's clock. The clock might be set too far into the future. Synchronize your clock with a reliable time source, close your browser, and try accessing your site securely again.
My browser says "The name on the security certificate does not match the name of the site" or it displays an error about some type of name not matching.
This error means that the web address on the certificate itself doesn't match the address in the address bar of your browser.
For example, if you install a certificate on your site for www.domain.com and you access your site as https://domain.com, your browser cannot match the names. Unfortunately, www.domain.com is not the same as domain.com. Please remember this in your check-out scripts.
This can also occur if the IP addresses on the server aren't properly configured. You could be accessing someone else's SSL certificate on your server when you attempt to access your site. Check with your web hosting provider if you think this might be the case.
My Internet Explorer says "This page contains both secure and non-secure items" and Firefox shows a padlock with a cross through it.
This error means that you have items with absolute paths to an insecure source on your secure pages. For example, if you have an image tag on a secure page that looks like this, you will receive an error:
Instead, use a relative link so that your images can be accessed insecurely or securely, depending on where the customer is on your site:
Another possible cause would be a third-party's script over an insecure source. An example of this would be:
Most often, a provider of such scripting services will also provide a secure means of accessing them. For example:
I installed my certificate on a non-Microsoft server and Firefox works fine. However, Internet Explorer either says "Page Cannot Be Displayed" or it says the certificate is signed by an authority I haven't chosen to trust.
This error normally occurs because of your server's SSL modules. Some versions of mod_ssl only support SSL connections up to 168-bits, which Internet Explorer is unable to negotiate. Firefox has the ability to accept the encryption at this level. If you are able to upgrade your SSL components, this is the best method.
Otherwise, your only option in this case is to force your server to use RC4-MD5 128-bit encryption as the highest level. To force your server to use this encryption level as its highest, add or change these configuration lines in your server's configuration file.
SSLCipherSuite !ADH:RC4+RSA:+MEDIUM:+LOW:+SSLv2:+EXP:-SHABy commenting out the SSLProtocol line, you allow the SSLCipherSuite line to specify the allowed encryption parameters. The SSLCipherSuite configuration line will allow for any encryption level up to and including RC4-MD5 128-bit encryption. Be sure to add/adjust these lines in each virtual host configuration (if you do not specify them globally). Save your configuration file and restart your server when you are finished.
For all of our clients running Microsoft Internet Information Services 6 or higher, you may find that after installing your new certificate via the supplied .p7b file, some browsers report that the SSL Certificate was signed by an unknown / untrusted Certificate Authority. This is due to a Self-Signed Certificate present in the Windows 2003/2008 Certificate Store, and should be removed.
This is due to a known issue with IIS 6/7. To correct this, the following procedure has been provided.
Open the Certificate Store for the Local Computer:
1. From the Desktop of your IIS Server, click "Start", then "Run", type 'mmc' (without the quotes), and then click "OK".
https://ssl.trustwave.com/images/support/rm_stca_fig-01.png
2. On the "File" menu, click "Add/Remove Snap-in" (See image below). A dialog box titled "Add/Remove Snap-in" will appear. Click the "Add" button. This will cause a window titled "Add Standalone Snap-in" to appear.
3. On the window titled "Add Standalone Snap-in", under "Snap-in", click "Certificates", then click the "Add" button at the bottom of the window.
4. A window titled "Certificates snap-in" will open (see image below), asking you to choose which certificates to manage. Click the radio button next to "Computer account" (the lower of the three options), and then click "Next". This will open a new window titled "Select Computer".
5. In the "Select Computer" window, click the radio button for "Local Computer" and then click "Finish". You will return to the "Add Standalone Snap-in" window.
6. Now to finish up the selections. On the "Add Standalone Snap-in" window, click the "Close" button. The "Add/Remove Snap-in" window should now have the "Certificates (Local Computer)" snap-in added to it. Click the "OK" button at the bottom of the window.
Remove the SecureTrustCA certificate:
1. In the left-hand pane, click on "Certificates (Local Computer)", then click on "Trusted Root Certification Authorities", and finally then click on "Certificates".
2. On the right-hand pane, scroll down till you see a Certificate that has been Issued To: and Issued By: "SecureTrust CA". This is the Self-Signed SSL Certificate that is susceptible to a known issue with IIS 6/7. There should be only one certificate.
3. Delete the certificate. You should receive a warning dialog box that states "This is a root certificate. Deleting this certificate will invalidate this CA. Are you certain you want to delete this certificate?".
4. Click yes.
Now restart the website via the IIS Manager.
My browser says "The security certificate was issued by a company you have not chosen to trust" or it says that it can't trust the Certificate Authority.
This error means that your browser is unable to authenticate your new Trustwave certificate. There are two main causes for this error:
The most common cause is that your intermediate certificates aren't installed or may not be installed properly. These intermediate certificates explain to the browser that the certificate can be trusted. Once they're installed properly, the error will disappear. Please return to the corresponding installation procedures for your server and complete the installation.
The other cause may be that your Trustwave SSL certificate isn't fully installed. Many servers actually create a "self-signed" or temporary certificate when you first create your CSR and private key. WHM, Plesk, and Zeus are just a few examples of servers that do this. Sometimes this certificate isn't removed when you install the Trustwave SSL certificate. Verify that your actual Trustwave certificate is installed rather than the self-signed certificate.
My browser says "The security certificate has expired or is not yet valid" or it displays some other type of error about validity and expiration dates.
This means that your certificate is either expired or not yet valid when the dates on the certificate are compared to your local computer's clock. There's two main reasons this error may appear: Your certificate may actually be expired. If you log into the Trustwave Control Center, your certificate's expiration date will appear there. If the expiration date has passed, don't worry - you can renew your certificate quite easily. You can renew it via the Trustwave Control Center, or you can call us and we can take care of it over the phone instantly.
If the expiration date hasn't passed, double check your computer's clock. The clock might be set too far into the future. Synchronize your clock with a reliable time source, close your browser, and try accessing your site securely again.
My browser says "The name on the security certificate does not match the name of the site" or it displays an error about some type of name not matching.
This error means that the web address on the certificate itself doesn't match the address in the address bar of your browser.
For example, if you install a certificate on your site for www.domain.com and you access your site as https://domain.com, your browser cannot match the names. Unfortunately, www.domain.com is not the same as domain.com. Please remember this in your check-out scripts.
This can also occur if the IP addresses on the server aren't properly configured. You could be accessing someone else's SSL certificate on your server when you attempt to access your site. Check with your web hosting provider if you think this might be the case.
My Internet Explorer says "This page contains both secure and non-secure items" and Firefox shows a padlock with a cross through it.
This error means that you have items with absolute paths to an insecure source on your secure pages. For example, if you have an image tag on a secure page that looks like this, you will receive an error:
Instead, use a relative link so that your images can be accessed insecurely or securely, depending on where the customer is on your site:
Another possible cause would be a third-party's script over an insecure source. An example of this would be:Most often, a provider of such scripting services will also provide a secure means of accessing them. For example:
I installed my certificate on a non-Microsoft server and Firefox works fine. However, Internet Explorer either says "Page Cannot Be Displayed" or it says the certificate is signed by an authority I haven't chosen to trust.
This error normally occurs because of your server's SSL modules. Some versions of mod_ssl only support SSL connections up to 168-bits, which Internet Explorer is unable to negotiate. Firefox has the ability to accept the encryption at this level. If you are able to upgrade your SSL components, this is the best method.
Otherwise, your only option in this case is to force your server to use RC4-MD5 128-bit encryption as the highest level. To force your server to use this encryption level as its highest, add or change these configuration lines in your server's configuration file.
SSLCipherSuite !ADH:RC4+RSA:+MEDIUM:+LOW:+SSLv2:+EXP:-SHABy commenting out the SSLProtocol line, you allow the SSLCipherSuite line to specify the allowed encryption parameters. The SSLCipherSuite configuration line will allow for any encryption level up to and including RC4-MD5 128-bit encryption. Be sure to add/adjust these lines in each virtual host configuration (if you do not specify them globally). Save your configuration file and restart your server when you are finished.
Wednesday, August 26, 2009
New SharePoint 2007 video
If you're new to SharePoint, or working with people who are new to SharePoint and have a hard time explaining what it is, you might find the SharePoint in Plain English video to be helpful.
This video takes a friendly approach to show how SharePoint can help you work together with others in more efficient ways. For example, SharePoint can help you plan and work on a project online instead of sending files back and forth in e-mail.
Link to the video: http://www.microsoft.com/video/en/us/details/76e8d3af-c2bd-42a6-bb12-befcbd041bf1
This video takes a friendly approach to show how SharePoint can help you work together with others in more efficient ways. For example, SharePoint can help you plan and work on a project online instead of sending files back and forth in e-mail.
Link to the video: http://www.microsoft.com/video/en/us/details/76e8d3af-c2bd-42a6-bb12-befcbd041bf1
Subscribe to:
Posts (Atom)