I wrote and erased the title of this post about 60 times before I settled on the above. There is so much tweaking you can do to MOSS's results, that a broad enough title didn't do enough justice to MOSS search's flexibility.

So, here is a restrictive title, but a rather cool but specific trick you can do with MOSS 2007 search.

Under shared services, go to search settings. Under there you would see "Metadata property mappings". Under there, you would see a number of "Managed Properties" already setup for you. You could add your own if you wanted to by clicking on the "New Managed Property" button above.

These Managed properties can be used in search scopes - and that is a very very powerful concept. Say for instance, if you wanted to search over all the "Word documents" on your local sharepoint sites - how would you do that?

Well, it's pretty simple.

1. As you can see, there is already a Managed Property called "FileExtension". If there wasn't - you could create your own.
2. Next, click on that Managed Property, and there is a checkbox at the bottom that says - "Allow this property to be used in scopes" <-- Check that bad boy.
3. Go back to search scopes, and create a new search scope called "Word Documents".
4. Add the following rule to "Word documents" -
   
5. Great, now run a full crawl on the "Local SharePoint Sites" content source (or whatever content source you are using).
6. Update the search scopes
7. Make this new search scope available for searching on your site.
8. And, If you just shook your head at the last 3 steps, I have covered them at numerous places on my blog.
9. Now issue a search on "Word Documents" -
10. WALLA !! You just created a search engine to search over word documents only. Now check this out - throw in an iFilter for PDF, and index a fileshare location, and whachu got? Ju got yourself a search engine for PDF files that live on \\DesignerFolks\GuysWhoWontMoveTheirShitIntoSharePoint\*.pdf. This is pretty powerful stuff IMO.

Go ahead and play with other managed properties, and new managed properties that you can slice and dice your content in searching for. For one, you can now slice and dice your data based on content types (No really you can !). Go try it out ! :-)

This gets ESPECIALLY powerful with BDC search. BDC will let you create new crawled properties, and you can then map them to managed properties, and slice and dice LOB data in any form you want - through a search engine.

Pretty powerful stuff IMO.

Posted on 5/17/2007 @ 12:08 AM in #Sharepoint

1. Go to the central administration -> Shared Services

   

2. Under the Search Menu, click on Search Settings.
3. In the Configure Search Settings page, click on Metadata Property Mappings.

   

4. In the Metadata Property Mappings page, click on New Managed Property

   

5. Enter the Property Name and add the crawled properties that you want to add by clicking on the Add mappings button.

   

   

6. Click OK. Once you have created the new custom managed property, go to the Advanced Search page.
   • Click on Site Settings and then on "Edit Page"
   • Click on Edit Menu of the Webpart and then Select "Modify Shared Web part"

In the Advanced Search Box Pane, click on the Properties Menu and then select the content in the Properties Text Box. In order that your Managed Properties appears in the Properties lists, you need to make changes in the XML file content.

The XML File in Properties has the following structure:

• Find the string:

  Collapse Copy Code

  <PropertyDef Name="ModifiedBy" DataType="text" 
              DisplayName="Last Modified By"/> 

• Add the following String below it:

  Collapse Copy Code

  <PropertyDef Name="MyProperty" DataType="text" DisplayName="MyProperty"/>

  MyProperty denotes the managed property that was created in Search Settings in the Shared Services.

• Find the ResultType node:

  Collapse Copy Code

  <ResultType DisplayName="All Results" Name="default">

• Add the following string below this:

  Collapse Copy Code

  <PropertyRef Name="MyProperty" />

• Now you can click on Apply and OK to close the pane.
• The property "MyProperty" will appear in the Property list box when All Results is selected.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

About the Author

Sabeer Mohammed

Problem
With as many Data Transformation Services (DTS) Packages that have been developed and deployed for B2B, data integration and BI needs, when it comes to upgrading from SQL Server 2000 to 2005, this portion of the upgrade will need special attention.  DTS Packages have become engrained in many applications and business processes making them business critical for not only internal applications but also mission critical for business partners.  In addition, DTS Packages are probably being used in unexpected ways than originally intended further complicating the upgrade process.  In some respects DTS Packages being called directly from web pages or being automatically triggered based on a business event follow a much different paradigm than those DTS Packages being called from a SQL Server Job as was probably how DTS Package execution was originally intended.  With the varying usage of the SQL Server 2000 DTS Packages, what is the upgrade process to SQL Server 2005 Integration Services (SSIS) Packages?

Solution
The DTS Package (SQL Server 2000) to SSIS Package (SQL Server 2005) upgrade is dependent on the Business Intelligence Development Studio which follows the Visual Studio paradigm of solutions and projects.  In the example below, we will create a single solution and project with a single SSIS Package, although numerous SSIS Packages can reside in a single solution.  Follow these steps to migrate your DTS Packages to SSIS Packages with the Migrate DTS 2000 Package Wizard:

ID
Steps
Screen Shot

1
SQL Server 2000 DTS Package - The original logic is to delete data from the destination table and then import all of the data.

2
Migrate DTS 2000 Package - Start the migration wizard by starting the Business Intelligence Development Studio, creating an Integration Services project and navigating to Project | Migrate DTS 2000 Package.

3
Choose Source Location - Specify the SQL Server 2000 server name with the DTS Package that needs to be migrated and the authentication type.

Press the 'Next >' button to continue the process.

4
Choose Destination Location - Directory on your desktop to save the SSIS Package file.

Press the 'Next >' button to continue the process.

5
List Packages - All DTS Packages on the SQL Server 2000 instance that can be upgraded.

Press the 'Next >' button to continue the process.

6
Specify a Log File - Press the 'Browse' button to specify a log file for the migration process.

Press the 'Next >' button to continue the process.

7
Complete the Wizard - Review the configurations and then press the 'Finish' button to begin the migration process.

8
Migrating the packages... - Review the status for the migration.

9
Integration Services Package - Review the objects to validate the code was successfully migrated.

For information on deploying SSIS Packages, reference - SQL Server Crosswalk - Deploying a SQL 2000 DTS vs. a SQL 2005 SSIS package.

Next Steps

• As you begin to think about upgrading to SQL Server 2005, download and execute the SQL Server 2005 Upgrade Advisor to identify all potential upgrade issues as you begin the project.  Be sure to analyze your DTS Packages, review, correct and test each of the DTS Package issues, then re-run the Upgrade Advisor to ensure a smooth upgrade to SQL Server 2005.
  • For more information about the SQL Server 2005 Upgrade Advisor check out - SQL Server 2005 Upgrade Considerations for DBAs and Developers.
• Since SQL Server 2005 has moved to the Visual Studio paradigm of Solutions and Projects, be sure to setup them up for your SSIS Packages in the Business Intelligence Management Studio (BIDS).
• As you architect and implement your Integration Services infrastructure, keep in mind that it is a separate installation in SQL Server 2005.  Depending on the number of SSIS Packages and the processing power needed, consider setting up a separate SQL Server instance for Integration Services.
• Check out these related MSSQLTips.com tips:
  • Tip Category - SQL Server Integration Services
  • Tip Category - Data Transformation Services

Written By: Edgewood Solutions Engineers

FILESTREAM是SQL Server 2008中的一个新特性，允许以独立文件的形式存放大对象数据，而不是以往一样将所有数据都保存到数据文件中。以往在对业务系统的文件进行管理时有两种方法，一种是将文件保存到服务器文件系统中，数据库中只保存了该文件的路径，在使用该文件时应用程序连接到服务器读取文件；另一种是将文件以varbinary(max)或image数据类型保存到SQL Server中。而SQL Server 2008提供了FILESTREAM，结合这两种方式的优点。

FILESTREAM使SQL Server数据库引擎和NTFS文件系统成为了一个整体。Transact-SQL语句可以插入、更新、查询、搜索和备份FILESTREAM数据。FILESTREAM使用NT系统缓存来缓存文件数据。这有助于减少FILESTREAM数据可能对数据库引擎性能产生的任何影响。由于没有使用SQL Server缓冲池，因此该内存可用于查询处理。

在SQL Server中，BLOB可以是将数据存储在表中的标准varbinary(max)数据，也可以是将数据存储在文件系统中的FILESTREAM varbinary(max)对象。数据的大小和应用情况决定您应该使用数据库存储还是文件系统存储。如果满足以下条件，则应考虑使用FILESTREAM：

• 所存储的对象平均大于1MB。
• 快速读取访问很重要。
• 您开发的是使用中间层作为应用程序逻辑的应用程序。

对于较小的对象，将varbinary(max)BLOB存储在数据库中通常会提供更为优异的流性能。

FILESTREAM存储以varbinary(max)列的形式实现，在该列中数据以BLOB的形式存储在文件系统中。BLOB的大小仅受文件系统容量大小的限制。文件大小为2GB的varbinary(max)标准限制不适用于存储在文件系统中的BLOB。

若要将指定列使用FILESTREAM存储在文件系统中，对varbinary(max)列指定FILESTREAM属性。这样数据库引擎会将该列的所有数据存储在文件系统，而不是数据库文件中。

FILESTREAM数据必须存储在FILESTREAM文件组中。FILESTREAM文件组是包含文件系统目录而非文件本身的专用文件组。这些文件系统目录称为“数据容器”。数据容器是数据库引擎存储与文件系统存储之间的接口。

使用FILESTREAM存储时，需要注意以下内容：

• 如果表包含FILESTREAM列，则每一行都必须具有唯一的行ID。
• 不能嵌套FILESTREAM数据容器。
• 使用故障转移群集时，FILESTREAM文件组必须位于共享磁盘资源上。
• FILESTREAM文件组可位于压缩卷上。

使用FILESTREAM

在开始使用FILESTREAM之前，必须在SQL Server数据库引擎实例中启用FILESTREAM。具体启用数据库实例FILESTREAM的操作如下：

（1）在SQL Server配置管理器中打开SQL Server数据库引擎的属性窗口，切换到FILESTREAM选项卡，如图所示。

（2）选中“针对Transact-SQL访问启用FILESTREAM”复选框，其他的选项是针对Windows进行读写的，可以都选中，然后单击“确定”按钮保存对FILESTREAM的设置。

（3）打开SSMS连接到数据库实例，右击数据库实例，选择“属性”选项，系统将打开SQL Server实例的属性窗口。

（4）切换的“高级”选项页，在文件流访问级别下拉列表框中选择“已启用完全访问”选项，如图所示。

（5）单击“确定”按钮，然后重启数据库实例，FILESTREAM在数据库实例中设置完成。

在启用了数据库实例的FILESTREAM后，接下来就需要设置数据库的FILESTREAM和创建具有FILESTREAM数据列的表：

（6）对应新建的数据库，则在创建数据库时创建FILESTREAM文件组，如果是现有数据库，则使用ALTER DATABASE添加FILESTREAM的文件组，例如对TestDB1数据库添加FILESTREAM的文件组，具体SQL脚本如代码：

ALTER DATABASE [TestDB1]
ADD FILEGROUP [FileStreamGroup] CONTAINS FILESTREAM --添加FILESTREAM文件组
GO
ALTER DATABASE [TestDB1]
ADD FILE ( NAME = N'FileStream', FILENAME = N'C:\FileStream) --添加FILESTREAM文件
TO FILEGROUP [FileStreamGroup]
GO

系统将自动创建C:\FileStream文件夹并在其中写入filestream.hdr文件，该文件是 FILESTREAM容器的头文件不能删除，一定要确保在运行该语句之前C:\FileStream并不存在。

（7）创建了FILESTREAM文件组后便可创建和修改表，指定某varbinary(max)类型的列包含FILESTREAM数据。例如创建Files表，该表包含FileID和FIleContent列，具体脚本如代码：

CREATE TABLE Files
(
FileID UNIQUEIDENTIFIER ROWGUIDCOL NOT NULL UNIQUE,
ID INT UNIQUE,
FileContent VARBINARY(MAX) FILESTREAM NULL --FILESTREAM类型的二进制
)

管理与使用FILESTREAM

在创建好FILESTREAM表后即可向其中添加、修改和读取数据。SQL Server支持使用T-SQL和WIN32 API两种方式访问FILESTREAM。

对于T-SQL访问FILESTREAM数据列来说，FILESTREAM是完全透明的，也就是说，T-SQL仍然使用一般的访问varbinary(max)数据列的方式访问，并不会因为是FILESTREAM列而有所不同。

例如向Files表中插入数据、修改表数据和删除数据的SQL脚本如代码：

INSERT INTO Files --插入测试数据
VALUES (newid (),1, CAST('TestFileStream1' as varbinary(max)));
GO
UPDATE Files --更新测试数据
SET FileContent=CAST('TestFileStream2' as varbinary(max))
WHERE ID=1
GO
DELETE FROM Files --删除测试数据
WHERE ID=1

无论是插入数据还是修改数据，SQL Server都将在文件系统中创建新的文件来保存最新的修改文件内容，修改或删除数据后文件系统中的文件将保留，而不会被同时删除。

使用FILESTREAM来存储二进制大型对象（BLOB）数据时，可使用Win32 API来处理文件。为了支持在Win32应用程序中处理FILESTREAMBLOB数据。所有FILESTREAM数据容器访问都是在SQL Server事务中执行的。可在同一事务中执行T-SQL语句以保持SQL数据和FILESTREAM数据之间的一致性。

【出自博客园深蓝居，转载请注明作者出处】

When I first read about sql server 2008 filestream I don't know why (or I know ;))
but my mind started to think about WSS/MOSS 2007 so why don't try to use this new feature
for document libraries storage?

Before start, if you want to know all the detail about FILESTREAM read FILESTREAM Storage in SQL Server 2008
from MSDN site where you can find all the information you need.

OK let's start:

First of all (if you didn't enable FILESTREAM during SQL Server 2008 installation),
you have to perform these steps to enable FILESTREAM support to your SQL Server instance:

1. Open SQL Server Configuration Manager (Start-All Programs-SQL Server 2008-Configuration Tools).
2. Select SQL Services on the left, right click on SQL Server instance you are interested on and click properties
3. Select FILESTREAM tab. In this tab you have three options (I Choose all three options):
   • Enable FILESTREAM for Transact SQL Access: you can perform TSQL SELECT, INSERT UPDATE and DELETE operations
   • Enable FILESTREAM for file I/O Streaming access: you can access FILESTREAM data using WIN32 API
   • Allow remote client to have streaming access to FILESTREAM data: you can store/access data on/from a remote file share
4. Open SQL Server Management Studio and configure SQL Server to support FILESTREAM using this script:
       EXEC sp_configure filestream_access_level, 2;
       GO
       RECONFIGURE;
       GO
5. At this point open Sharepoint central administration, create a new Application with a content Database name (for exampe: WSS_Content_Filestream) and create a site collection for testing (I create a blank site).
6. Now you have to crate a FILESTRAM Filegroup for the new content database:
   • Go to management studio, right click on the new content database and select properties
   • Select Filegroups and create a new Filestream Filegrop name (for example FILESTORAGE)
7. Open SQL Server management studio and run this script:
     ALTER DATABASE WSS_Content_Filestream
     ADD FILE(
      NAME=FSGroupFile1,
      FILENAME='c:\MyDBData\FSDATA'
     )
     TO FILEGROUP FILESTORAGE;
     GO

   Note: use your WSS content database name. Replace FILENAME value with your directory name. Replace the name FILESTORAGE with your Filegroup name.
     If all runs well you can go under your directory (c:\MyDBData\FSDATA) and notice the presence of filestream.hdr file for metadata and the
     $FSLOG directory for FILESTREAM database transaction log.

8. With management studio, open your WSS_Content database, expand Tables folder and right click the dbo.AllDocStreams table and generate
   the two scripts in new query windows for drop and create table (Script Table As - Drop And Create To - New Query Windows).
   If you go to the CREATE TABLE part, you will notice that dbo.AllDocStreams table has a column called Content of type image.
   For filestream usage, you have to use the varbinary(max) data type. You have also to add a new column to the table of type
   uniqueidentifier of type rowguidcol unique, not null and with default value of NewId() (I called this column DocumentId).
   So you have to change the CREATE TABLE part for the Content column from this:

     [Content] image NULL

       To this:

     [Content] varbinary(max) FILESTREAM NULL,
     [DocumentId] UNIQUEIDENTIFIER NOT NULL ROWGUIDCOL UNIQUE DEFAULT NEWID()

          You also have to specify the FILESTREAM filegroup for that table:
          locate the ON [PRIMARY] instruction at the end of the CREATE TABLE and replace with this instruction:
          ON [PRIMARY] FILESTREAM_ON FILESTORAGE (NOTE FILESTORAGE is my FILESTREAM Filegroup name).

Et voilà, if you go to your filestream directory (c:\MyDBData\FSDATA) you will notice the presence of a new directory and a subdirectory.
One is created for the table and the other is created for the filestream column.

Now you can go yo your site collection, create a new document library, upload some documents,
go to the filestream directory on the file system and you will see your document files stored outside SQL Server!

Hope this helps
Vincenzo

You have probably seen the news announcement today where we announced the public beta for the new Microsoft Exchange Server 2010. As part of that announcement, we also talked about some of the names for the “14” wave of products including Microsoft Office 2010 and Microsoft SharePoint Server 2010. I wanted to answer some questions that I think will inevitably pop to the top of your mind:

What happened to the Office piece of the name? We love MOSS. . . .

The first thing you’ll notice is that the MOSS acronym goes away with the new name since Office is no longer in the SharePoint official name. No one should worry that SharePoint doesn’t work great with Office 2010 since we removed Office from the name, just like people didn’t worry whether SharePoint was a great portal product when we removed Portal from the 2007 name.

The primary reason why we took Office out of the name - lots of folks associate the name Office with the Office client. We wanted to take the opportunity to reestablish the Office name and brand to be synonymous with the client suite. I say “Give the people what they Want” so everyone should immediately think of Microsoft Office = Office apps.

Don’t try to acronym Microsoft SharePoint Server to MSS since MSS is already taken by Microsoft Search Server. Just remember, SharePoint is SharePoint is SharePoint.

What about Windows SharePoint Services?

When you read through the announcement, you may be wondering what happened to Windows SharePoint Services. While we didn’t announcement anything new for WSS, and I want to assure you that we’re definitely working on a new v4 version of the product. It’s too early to drill into any of the details but WSS is getting a lot of new features and will be a great release. We’ll talk more about WSS at a later date.

So, what was announced?

Here are my key takeaways from the interview with Chris Capossela:

• Exchange 2010 will lead the way for the 2010 (previously referred by its codename “14”) wave of technologies and it will be available in the second half of 2009. You can download a beta today.

• Using Office Web applications, customers will be able to create, edit and collaborate on Office documents through a browser.

• IT professionals will be able to choose to either deploy and manage on-premises or hosted as a service.

• For developers, we are working on Open APIs, deep support for industry standards and developer tool support with Visual Studio 2010.

You can read the entire interview here.

Thomas Rizzo
Sr. Director
SharePoint

Published Tuesday, April 14, 2009 4:37 PM by sptblog

Last October, we announced the upcoming release of the 2nd service pack for the 2007 Microsoft Office System and the 2007 Microsoft Office servers. Today, we’re happy to provide both a formal release date, and more details on what you should expect to see in SP2.

A fair amount has been said about SP2 already, but there is a lot more to share. We’ll cover the highlights here, but please check back on April 28th when all of our documentation will be published. It is important to remember that the information provided today is by no means a comprehensive list. We worked with the individual teams in Office to come up with a list of changes that they were most proud of and felt would be most beneficial to you, our valued customers.

In addition to the numerous product improvements introduced by SP2, you may also notice that our SP2 documentation has been overhauled.  Gone are the days of the long-winded or too sparse knowledge base articles that do little to describe what’s included in the actual service pack or that include details that may not be what you are looking for.  In their place are what we hope are more user-friendly and informative KB’s.  The technical information still exists, but it has been pulled from the main KB articles and now will live on TechNet.  And, back by popular demand, is the spreadsheet listing individual bugs that were fixed across all of our products.

The Service Pack team would like to express our sincere thanks to the many beta testers who took the time to download, install, test, and provide feedback to us. This was the largest beta we’ve done to date for an Office service pack with thousands of beta testers from over 60 countries. We know your time is extremely valuable, and we very much appreciate all you’ve done. Your efforts have helped to make this a great release!

Don’t forget to come back on April 28th. We’ll have a comprehensive list of everything we’ve released, where you can find it, and links to additional information. A brief note, some of the information posted earlier needed clarification. We have made slight modifications to the information below. 

Very sincerely,

The Office Service Pack team

We’ll start with updates that pertain to multiple products, highlight fixes to the individual desktop applications, and then discuss fixes to the server products.

Changes that impact desktop applications

• Service Pack 2 adds the ability to open, edit and save documents in version 1.1 of the OpenDocument Format for Word, Excel, and PowerPoint. These applications now let users save, open, and edit files as OpenDocument Text (*.odt), OpenDocument Spreadsheet (*.ods), and OpenDocument Presentations (*.odp).

• The 2007 Microsoft Office Service Pack 2 is the first service pack to support uninstall of client updates through the Microsoft Service Pack Uninstall Tool for the 2007 Microsoft Office Suite as well as via Windows Installer command line. The Service Pack Uninstall Tool will be available as a separate download.

• The Microsoft Save As PDF or XPS add-in has been built into Office applications in SP2. Users no longer have to download and install the add-in separately.

• When many graphic objects are present performance has been improved.

• In many scenarios, expect increased print fidelity of graphical objects.

• Improved interoperability using standard DrawingML markup to describe the visual properties of the SmartArt graphic. 

• Substantial improvements to Forms-based authentication support in Word, Excel, PowerPoint and SPD.

The 2007 Office Suite SP2 has been tested and is supported for Internet Explorer 8. Windows Vista SP2, Windows Server 2008 SP2, Windows 7 and Windows Server R2 will all be supported upon their release.

Access

• The ability to export reports to Excel has been added.

• Fixes for issues with the import data wizards, report printing and previewing, macros, Excel integration, and date filters.
  Updates to Access Developer Extensions are now included in SP2.

Excel

• The charting mechanism has improved robustness and targeted performance improvements.

• A chart object model has been added to Word and PowerPoint.

• Improved printing of graphical content, especially on PCL printers.

Groove

• Improved form tools.

• Synchronization reliability has been improved.

InfoPath

• Increased compatibility between InfoPath forms and other Microsoft products, such as Groove and Outlook.

OneNote

• SharePoint synchronization has been improved which helps reduce the load on SharePoint servers and produce fewer errors.

Outlook

• Performance in startup, shutdown, view rendering, and folder switch has been improved.
• Calendar updates, search, and RSS are more reliable.
• The object model has been improved.

PowerPoint

• Resaving of files is faster. Several printer-specific problems have been fixed.

• The Microsoft Office Excel Chart Object Model has been more fully integrated.

Project

• The scheduling engine, Active Cache, and Gantt charts all have improvements.

• There is additional reliability with earlier versions of the .mpp format.

Publisher

• Fixes have been made in the following areas: print preview, compatibility with Internet Explorer 8, e-mail on Windows Vista, and saving to the Content library. 

Visio

• Improved compatibility with other Microsoft products in several key scenarios, such as inserting Visio drawings as linked objects in PowerPoint or Word, exporting reports to Excel, and saving drawings as Web pages for browsing in Internet Explorer 8.

Word

• Fidelity of PDF and XPS output has been enhanced compared to the output created through the use of the download. 

• Better integration of the Microsoft Office Excel Chart Object Model.

Changes that impact the server products

Windows SharePoint Services 3.0 SP2 and Microsoft Office SharePoint Server SP2 include fixes and enhancements designed to improve performance, availability, and stability in your server farms. SP2 provides the groundwork for future major releases of SharePoint Products and Technologies.

• An STSADM command line that scans your server farm to establish whether it is ready for upgrade to the next version of SharePoint and provides feedback and best practice recommendations on your current environment.

• SP2 offers support for a broader range of Web browsers.

Windows Server 2008 SP2 and Windows Server 2008 R2 will be supported on their release.

Enterprise Content Management (ECM)

• The performance and stability of content deployment and variations feature has been improved.

• A new tool has been added to the STSADM command-line utility that enables a SharePoint administrator to scan sites that use the variations feature for errors.

Excel Services

• SP2 makes it easier to configure Excel Web Access Web Parts on new sites.

• Several rendering, calculation, and security issues have been resolved.

• Some display issues have been addressed.

• Improved compatibility with Mozilla Firefox browsers.

Groove Server

• Improved  synchronization reliability.

• Groove Server 2007 Manager will install and run with SQL 2008.

• Groove’s LDAP connectivity and auto-activation functionality have been improved.

• Error reporting in the Groove Relay Server has improved significantly.

• Groove Relay Server has improved robustness.

Forms Server

• Memory requirements and the page load times for large browser-rendered forms have been reduced.

• Browser rendering of various controls, such as the 'cannot be blank' asterisk and the rich text field has been improved.

Project Server

• Better memory management in the queue service.

• Performance to certain database table indexes is improved.

• Resource plans, build team, cost resources, and the server scheduling engine have improved.

Search Server

• Improvements to the reliability and stability of very large corpus crawls.

• Backup-restore has been improved.

• A new command has been introduced to the stsadm.exe tool that lets a SharePoint Administrator to tune the Query processor multiplier parameter.

• Improved accuracy in searches involving numbers.

Note: Two minor changes were made on April 22, 2009 to the original post of this blog. The changes were: Substantial improvements to Forms-based authentication was moved to the desktop section and support in Word, Excel, PowerPoint and SharePointDesigner was added to the sentence. Windows Server R2 was changed to Windows Server 2008 R2.

Published Thursday, April 16, 2009 1:50 AM by The Microsoft Office Sustained Engineering Team

Heya folks,

It's time for another Feature! Woo HOO!! This a definite must know for WSS 3.0 and MOSS 2007. Ok, so this feature will deploy a custom search box control that can be called in your own Master Page or Page Layout. Let's walk through the steps needed to create this Cool, reusable feature.
1.)Let's Create a Custom Control! Create a file named "CustomSearch.ascx", this file will be just a modified version of the current WSS 3.0/MOSS Search.
2.)Copy the following code into your "CustomSearch.ascx" control. This code only modifies the template of the "out-of-the-box" search (mainly just a little space between the search and drop-down) and still maintains all the functionality of the original.

< %@ Control Language="C#" Inherits="Microsoft.SharePoint.WebControls.SearchArea,Microsoft.SharePoint,Version=12.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c" compilationMode="Always" % >
< %@ Register Tagprefix="wssawc" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" % >
< %@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" % >
< %@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" % >
< %@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" % >
< %@ Import Namespace="Microsoft.SharePoint" % >
< %
string strScopeWeb = null;
string strScopeList = null;
string strWebSelected = null;
SPWeb web = SPControl.GetContextWeb(Context);
string strEncodedUrl
= SPHttpUtility.EcmaScriptStringLiteralEncode(
SPHttpUtility.UrlPathEncode(web.Url + "/_layouts/searchresults.aspx", false, false)
);
strEncodedUrl = "'" + strEncodedUrl + "'";
strScopeWeb = "'" + SPHttpUtility.HtmlEncode( web.Url ) + "'";
SPList list = SPContext.Current.List;
if ( list != null &&
((list.BaseTemplate != SPListTemplateType.DocumentLibrary && list.BaseTemplate != SPListTemplateType.WebPageLibrary) ||
(SPContext.Current.ListItem == null) ||
(SPContext.Current.ListItem.ParentList == null) ||
(SPContext.Current.ListItem.ParentList != list))
)
{
strScopeList = list.ID.ToString();
}
else
{
strWebSelected = "SELECTED";
}
% >
< table border="0" cellpadding="0" cellspacing="0" class='ms-searchform' >< tr >
< td >
< input name="SearchString" type="text" value="Search..." id="idSearchString" title="Enter Search Words" class="ms-searchbox" onfocus="if (document.getElementById('sb_state').value =='0') {this.value=''; document.getElementById('sb_state').value=1;}" onblur="if (this.value =='') {this.value='Search...';document.getElementById('sb_state').value = '0'} else {document.getElementById('sb_state').value='1';}" style="width:120px" maxlength="255" ACCESSKEY="S" onKeyDown="return SearchKeyDown(event, < %=strEncodedUrl% >);" title=< %SPHttpUtility.AddQuote(SPHttpUtility.HtmlEncode(SearchTextToolTip),Response.Output);% >/ >
< input type="hidden" name="sb_state" id="sb_state" value="0" / >
< /td >
< td style="width:4px;" > < /td >
< td >
< select id='idSearchScope' name='SearchScope' class='ms-searchbox' title=< %SPHttpUtility.AddQuote(SPHttpUtility.HtmlEncode(SearchScopeToolTip),Response.Output);% > >
< option value=< %=strScopeWeb% > < %=strWebSelected% > > < SharePoint:EncodedLiteral runat="server" text="< %$Resources:wss,search_Scope_Site% >" EncodeMethod='HtmlEncode' Id='idSearchScopeSite'/ > < /OPTION >
< %
if (strScopeList != null)
{
% >
< option value=< %=strScopeList% > SELECTED > < SharePoint:EncodedLiteral runat="server" text="< %$Resources:wss,search_Scope_List% >" EncodeMethod='HtmlEncode' Id='idSearchScopeList'/ > < /OPTION >
< %
}
% >
< /select >
< /td >
< td >
< div class="ms-searchimage" >< a target='_self' href='javascript:' onClick="javascript:SubmitSearchRedirect(< %=strEncodedUrl% >);javascript:return false;" title=< %SPHttpUtility.AddQuote(SPHttpUtility.HtmlEncode(SearchImageToolTip),Response.Output);% > ID=onetIDGoSearch >< img border='0' src="/_layouts/images/gosearch.gif" alt=< %SPHttpUtility.AddQuote(SPHttpUtility.HtmlEncode(SearchImageToolTip),Response.Output);% >/ >< /a >< /div >
< /td >
< /tr >< /table >

3.)Create a feature folder named CustomSearch, this folder will host our feature.
4.)Next, let's create a "Feature.xml" file within our feature folder. This file will tell SharePoint that we have a feature we'd like it to acknowledge. Place the following code within your Feature.xml file:

< ?xml version="1.0" encoding="utf-8" ? >
< Feature Id="74CC942C-C6F9-48a7-A5CC-1856EE7BABEB"
Title="CustomSearch"
Scope="Farm"
Description="Our Custom Search"
Version="1.0.0.0"
xmlns="http://schemas.microsoft.com/sharepoint/" >
< ElementManifests >
< ElementManifest Location="CustomSearchArea.xml" / >
< /ElementManifests >
< /Feature >

You'll notice that we have all of the needed attributes for our feature.xml element (ID [guid], Title, description, etc..), this is fairly straight forward. The interesting piece of this xml file comes in the "ElementManifest" element, this element has a reference to a file not yet created called "CustomSearchArea.xml". "CustomSearchArea.xml" will contain specific meta-data for our new Custom Search control. Let's create that file.
5.)Create our "CustomSearchArea.xml" file within our feature folder and copy the following xml inside:

< ?xml version="1.0" encoding="utf-8"? >
< Elements xmlns="http://schemas.microsoft.com/sharepoint/" >
< Control
Id="CustomSearchBox"
Sequence="100"
ControlSrc="~/_controltemplates/Customsearcharea.ascx" >
< /Control >
< /Elements >

This is the only "quasi" tricky part in this walkthrough. As we've seen with our previous Feature, the "Elements" element contains the actual definition for the item we're provisioning or creating. The "Control" element contains the definition of our new Custom Control. This element has ID, Sequence, and ControlSrc attributes which directly reference the control we're creating. In our control we define an ID of "CustomSearchBox", a custom sequence of "100", and in our ControlSrc we directly reference the "CustomSearchArea.ascx" file (In our case this file will live in the "ControlTemplates" folder of our 12 hive). These attributes gives SharePoint all the info it needs to declare a new Custom control.
6.)Now, let's test our feature (I'll do a Solution Pack for my next post, but for now we'll have to do the work around). Copy your the "CustomSearch" folder into the 12/Templates/Features folder. Now copy the "CustomSearch.ascx" file into the 12/Templates/ControlTemplates. Once everything is copied run the following commands:
stsadm -o installfeature -name CustomSearch -force
There you have it! If you open Central Administration => Application Management => Farm Features, you'll notice that our new custom search control is there waiting to be activated!
Well another bit of code well done. I know this was a whirl wind so if you have any questions just drop me a comment.
~:)

Posted by Eric Stallworth at 9:56 PM

After receiving a couple of emails about displaying multiple columns within the CQWP, I decided to post about it as a step by step. So here goes. To begin with I have created the following structure:

• PORTAL

  • DEMO SITE 1

    • SUB SITE 1
    • SUBSITE 2

What I am hoping to achieve is consolidate the entire contacts, into a single list that appears at the root demo site. I have created the following sites as shown below and their respective lists.

Each of the above lists has a few contacts added for demo purposes.

Firstly we need to edit the page that we want to display the contacts list on. For this demonstration I have created a custom web part page. Simply press the "Site Actions" menu and select the "Edit Page" option.

Now press the "Add Web Part" button.

You will then need to select the "Content Query Web Part" and add this to the page.

By default when the CQWP renders it will show generally news items and pages. Click the arrow to modify the web part.

You now need to set the query properties of the CQWP to point to the contact content type. This is done by setting the properties as below:

Upon applying these settings, the CQWP should render as below:

Now we have it connected to the correct lists we now need to modify the web part itself to connect to all the fields that we want to show and then make a custom style for displaying these in a different way. So to begin lets press the arrow for modifying the web part and select export:

When prompted save it to your desktop.

You now need to open this file in an editor such as Visual Studio, SharePoint Designer or like me just good old notepad!! Within the document you are looking for the "CommonViewFields" property.

In order to add the correct fields you firstly need to know what the internal names are of the fields. Press the "Settings" then select "List Settings" on the list you wish to know the fields from.

When accesssin the page you will see a list of all the fields that are part of this list or associated content types.

However this does not give us the actual internal names of these fields. To do this we will need to look at the site columns that exist within the content type itself. Press the "Site Actions" menu and the "Settings", then press to go to the root of the site and select the "Site Content Types".

From the list that appears select the "List Content Types" and then press the "Contact" link.

The fields names should then be listed as below:

When you hover your mouse over the field you can look at the status bar of the browser and see the actual internal field name as shown below, or you can click into the field and access it's name from the URL that appears in the browser.

Now we know how to find the exact internal names we need to modify the CQWP lines to look as below:

<property name="CommonViewFields" type="string">

FullName,Text;Company,Text;JobTitle,Text;Email,Text;WorkPhone,Text;CellPhone,Text;City,Text;

</property>

In case you are not sure of the syntax: Fieldname,Type

Save this file now. This then needs to be imported to the page and replace the one we added earlier. To do this edit the page and then press to add a web part as before. Simply close the current web part:

Now press the following link on the web part window:

And select the import option that appears on header bar of the task pane that appears.

Browse to the web part we modifed earlier and import to the page. It should then show as below, notice it looks exactly like the other one did (for now).

However even though it renders the same way it is loading all the other fields in the background but not displaying them. To make them display we need to make some changes to the "ItemStyle.xsl" file. This can be done by selecting the "Manage Content and Structure" link from the "Site Actions" menu.

You will then need to select the "Open in New Window" from the menu that appears on the "Style Library" folder.

Once this is open press on the folder below:

At this point take a backup of the "ItemStyle.xsl" file and then edit the existing one in an XML Editor.

I have opened mine in Notepad. Now the structure of the "ItemStyle.xsl" is basically made up of a XSL Templates that will render the content in different layouts. The layout I am after is simple. I want to show a certain amount of fields and have hyperlinks for viewing all the details, email and links to call their numbers using skype. Firstly make a copy of one of the styles that exist and then rename the top line as below:

<xsl:template name="ContactsList" match="Row[@Style='ContactsList']" mode="itemstyle">

The next set of code is not changed from any of the original styles:

<xsl:variable name="SafeLinkUrl">

<xsl:call-template name="OuterTemplate.GetSafeLink">

<xsl:with-param name="UrlColumnName" select="'LinkUrl'"/>

</xsl:call-template>

</xsl:variable>

<xsl:variable name="DisplayTitle">

<xsl:call-template name="OuterTemplate.GetTitle">

<xsl:with-param name="Title" select="@FullName"/>

<xsl:with-param name="UrlColumnName" select="'LinkUrl'"/>

</xsl:call-template>

</xsl:variable>

<xsl:variable name="LinkTarget">

<xsl:if test="@OpenInNewWindow = 'True'" >_blank</xsl:if>

</xsl:variable>

Now we get into creating our own custom layout.

<xsl:call-template name="OuterTemplate.CallPresenceStatusIconTemplate"/>

<table>

<tr>

<td style="width:100px" class="item link-item"><a href="{$SafeLinkUrl}" target="{$LinkTarget}" title="{@LinkToolTip}">

<xsl:value-of select="$DisplayTitle"/>

</a>

</td>

<td style="width:160px" class="item link-item"><xsl:call-template name="OuterTemplate.CallPresenceStatusIconTemplate"/><a href="#"><xsl:value-of select="@Company" /></a></td>

<td style="width:200px" class="item link-item"><a href="#"><xsl:value-of select="@JobTitle" /></a></td>

<td style="width:300px" class="item link-item"><a href="mailto://{@Email}"><xsl:value-of select="@Email" /></a></td>

<td style="width:150px" class="item link-item"><a href="callto://{@WorkPhone}"><xsl:value-of select="@WorkPhone" /></a></td>

</tr>

</table>

</xsl:template>

Once you have finished modifying the "ItemStyle.xsl" you will need to save it and then check it back in. You will now need to modify the web part again and select the new style from the presentation list of styles as shown below:

The CQWP should then render as below:

As you can see utilising content types and the CQWP will allow you to display content in different styles and layouts from accross your site.

Wednesday, 25 Jul 2007 06:17 by Ishai Sagi

Download Sample Custom Policy File

Have you ever written a web part or a web service? If yes then you must have dealt with a security problem. Writing a web part or web service may not be a big issue but deploying them is certainly a headache. You start getting permission errors as soon as you deploy your code on the server. I recently wrote an article demonstrating the web service creation process and I promised in that article that I would write about Code Access Security (CAS) in another article. There are three ways to assign execution permissions to your code:

1. Increase the trust level for the entire virtual server
2. Create a custom policy file for your assemblies
3. Install your assemblies in the GAC

In the article, we installed our assembly in the GAC but the safest method is to create a custom policy file for the assembly. Following article on MSDN contains complete details on code access security:

Microsoft Windows SharePoint Services and Code Access Security

Written in July 2003, this is one of the most comprehensive articles written on "SharePoint and Code Access Security".

For security reasons, the assembly must be installed in the bin directory of the application instead of GAC but installing it in the bin directory requires you to assign execution permissions to the assembly. One way is to increase the trust level of the entire virtual server. This is easy to implement but this option is least secure as it affects all assemblies used by that virtual server. Second way is to create a custom policy file and this is the recommended approach. This option is most secure but difficult to implement. In this article, we will create a custom policy file for an assembly (web service assembly) written for MOSS 2007.

Creating a Custom Policy File

1. Go to the following location on the server:

LocalDrive:\Program Files\Common Files\Microsoft Shared\web server extensions\12\CONFIG

2. Make a copy of wss_minimaltrust.config and rename it wss_customtrust.config.

3. Open wss_customtrust.config file using any text editor.

4. Under the <SecurityClasses> element, add a reference to the SharePointPermissions class as follows:

<SecurityClass Name="SharePointPermission" Description="Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c." />

5. Search for the <PermissionSet> tag where the name attribute equals ASP.NET. If you couldn't find that <PermissionSet> tag, locate the one that has SPRestricted in the name attribute.

6. Copy the entire tag and all of its children, and paste a copy of it immediately below the one you copied.

7. Change the name of the PermissionSet element from ASP.NET (or SPRestricted) to CustomTrust.

Before:

<PermissionSet
class="NamedPermissionSet"
version="1"
Name="SPRestricted">

After:

<PermissionSet
class="NamedPermissionSet"
version="1"
Name="CustomTrust">

8. Add the following <IPermission> node to the <PermissionSet> element where the name attribute equals CustomTrust:

<IPermission class="SharePointPermission"
version="1"
ObjectModel="True" />

Therefore, the resulting customized <PermissionSet> will look as follows:

<PermissionSet
class="NamedPermissionSet"
version="1"
Name="CustomTrust">

<IPermission
class="AspNetHostingPermission"
version="1" Level="Minimal"
/>

<IPermission
class="SecurityPermission"
version="1" Flags="Execution"
/>

<IPermission class="WebPartPermission"
version="1"
Connections="True"
/>

<IPermission class="SharePointPermission"
version="1"
ObjectModel="True" />
</PermissionSet>

9. Once you define the customized element, you must create a code group to specify when the CLR should apply the permission set. (For details, see the original Microsoft article). Locate <CodeGroup> tag where the class attribute equals FirstMatchCodeGroup and copy following CodeGroup immediately below it:

<CodeGroup class="UnionCodeGroup"
version="1"
PermissionSetName="CustomTrust">
<IMembershipCondition class="UrlMembershipCondition"
version="1"
Url="$AppDirUrl$/bin/*" />
</CodeGroup>

The membership condition for this new code group is based on URL membership and the URL points to the bin directory. The permissions will be applied to all the assemblies in the bin directory of the current application. You can also use strong name membership but then the permissions will  be applied only to one assembly. For example, if I have written a web service and I wanted to assign permissions to my assembly only, I would use strong name membership. Copy following code immediately below the <CodeGroup> tag where the class attribute equals FirstMatchCodeGroup, if you want to use strong name membership:

<CodeGroup class="UnionCodeGroup"
version="1"
PermissionSetName="CustomTrust">
<IMembershipCondition class="StrongNameMembershipCondition"
version="1"
PublicKeyBlob="0x0024000004800000940000000602000000
2400005253413100040000010001004"
Name="UploadService" />
</CodeGroup>

Replace PublicKeyBlob value with your own value and change the name of the assembly in the Name attribute. Name attribute contains the name of the assembly. To retrieve the public key blob for an assembly, use the secutil.exe tool. Please note that publickeyblob is different from publickeytoken. Secutil.exe is located in the following folder:

LocalDrive:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin

To retrieve the public key blob for your assembly, either copy the secutil.exe tool to the folder that contains your assembly else provide exact path to the assembly in the command, and run the tool as follows:

secutil.exe -hex -s UploadService.dll > blob.txt

UploadService.dll is the name of the assembly. This command will create a text file named blob.txt. Open blob.txt and copy the public key and paste it in the publickeyblob attribute.

10. Save and close the file. The policy file is ready to use.

11. Open the web.config file for the virtual server where you have deployed your component and add the following <trustlevel> tag to the SecurityPolicy element:

<trustLevel name="WSS_Custom" policyFile="LocalDrive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\config\wss_customtrust.config" />

Virtual Directories for web applications are located in the following folder:

LocalDrive:\Inetpub\wwwroot\wss\VirtualDirectories

Suppose I want to deploy my web service in the web application configured at port 17316. The URL of that application would be http://localhost:17316 and its virtual directory will be:

LocalDrive:\Inetpub\wwwroot\wss\VirtualDirectories\17315

Create a bin folder in this path and copy your assembly to the bin folder. The web.config for this virtual server will be located in the following folder:

LocalDrive:\Inetpub\wwwroot\wss\VirtualDirectories\17315

In the web.config file,  change the <trust> tag so that it refers to the newly defined trust level.

<trust level="WSS_Custom" originUrl="" />

12. Save and close the web.config file.

13. Restart IIS to apply the custom policy to the specified virtual server.

Download Sample Custom Policy File

Previous Entry / Next Entry

comes from:http://it.toolbox.com/blogs/sharepoint-blog/moss-2007-and-code-access-security-14357

Sunday, 6 April 2008

So my tool, the SharePoint Content Deployment Wizard has been available for some time now and I've been monitoring the feedback and issues people have raised closely. The current version is labelled 'beta 2' but I'm happy with the stability of the current codebase, so will probably re-label it as 'release 1.0' soon (following some feedback on the psychological aspect of the beta label :-)).

Only a small number of people have raised issues, and any problems have almost exclusively been related to the underlying Microsoft code used by the tool rather than the Wizard itself. I should probably be happy about this, but in reality if some people get errors from the tool it doesn't really matter why it happens. The good news is that it seems Microsoft are finally getting some issues with the Content Deployment API sorted at their end. This is a key point in my list of guidance I'd give to anybody running into any errors from the Wizard. Note that the first two apply to use of standard Content Deployment using Central Admin also:

Tip 1 - Service Pack 1 and hotfixes matter

Service Pack 1 fixed many issues with Content Deployment. Unfortunately it also broke some things which had previously been fixed with pre-SP1 hotfixes. It took me a while to realize this, but it's definitely the case. Probably the most common issue in this area is the 'Violation of Primary Key' error. There are reports of being able to work around this by modifying versioning settings on certain libraries, but MS have now released a hotfix very recently which seems to solve the problem for good on SP1 environments. At the moment this is by special request only - the KB to ask for is KB950279. This forum thread discusses this, and it worked for us. Interestingly I spoke to Tyler Butler (Program Manager for Content Deployment) at SPC2008, and he indicated Content Deployment in SharePoint is likely to get "significantly more stable in the next 30-60 days". I'm guessing this hotfix is what he was referring to, or at least part of it.

Tip 2 - always start from a blank site template an empty site created from STSADM -o createsite on the destination

The official guidance currently states that Content Deployment requires that the target site has been created from the 'blank' site template - this is detailed in KB article 923592. However, a better way detailed by Stefan in the comments below is to create an empty site using the STSADM -o createsite command. This is not the same as a site created from the blank template, and is the safest way to create sites which will use Content Deployment or the Wizard. What this means is that even if you're creating a site based on say, the publishing site template in development, any other environments which you wish to deploy content to should be created in this way. Notably, for publishing sites the publishing Feature should also not be enabled for the first deployment - this will be taken care of for you when the first deployment happens. You'll receive the same 'object already exists' error otherwise.

Tip 3 - pay attention to the 'retain object IDs' option

Generally the right option here is to select that you do want to retain the object IDs, and this should be done from the very first deployment - the only exception is when moving webs/lists to a different part of the site structure (reparenting). However, it's important to note that mixing use of Content Deployment or the Wizard with STSADM export/import is likely to cause problems as noted by Stefan in his recommended 'Content Deployment and Migration API - avoiding common problems' post.

A more comprehensive write-up of options available with the Wizard is available at 'Using the SharePoint Content Deployment Wizard'. Also note that's not it as far as the tool goes - in addition to extra functionality such as item-level reparenting and incremental deployment, I hope to refactor the code so that the Wizard would be scriptable from the command-line.

And special thanks go to my colleague Nigel Price for working through the hotfix situation, much appreciated :-)

Posted by Chris O'Brien at 21:04

Recently I’ve had the pleasure to use the content deployment feature of MOSS between some of our SharePoint environments.

It was not a smooth ride and I believe that I have now met every single obstacle and bug in that feature. This posting is the result of several months’ worth of frustration.

We got three environments Dev, Test and Prod and we want to use content deployment to move content from the production servers to the development and test servers, simply to ensure current test data.

As a side node, you might want to read the Microsoft brief “Team-based Development in Microsoft Office SharePoint Server 2007” for another good reason to make content deployment one of your skills.

Well, without beating around the bush anymore the following are the steps needed to do a content deployment (with some minor obvious exceptions) in order of appearance.

Setup path

Content deployment requires you to first setup a path and then one or more jobs for that path. Simply put the path is the server to server connection configuration, the job is a specification of what to do and when.

I try to use security best practices so all my both service users are just standard domain users, any special rights they might need are assigned by MOSS during the configuration wizard. In the same vein my farm administrator accounts are standard domain users that are assigned extra permissions only through SharePoint.

The first problem with creating a path is an access denied problem during the path setup page (/_admin/DeploymentPath.aspx), when you select the source web application and site collection. For the destination site collection you are required to provide an explicit user with sufficient rights.

Figure 1: The “Access denied” message

It seems that your logged in user needs to be able to read the IIS metabase when you select a web application. There are many ways to grant access, I choose to add my farm administrator to the IIS_WPG local security group on the server. In my opinion the SharePoint team forgot to impersonate the call to read the IIS metadata. Will hopefully be fixed in some future service pack.

The second problem (on the very same page) occurs if you connect to another farm using SSL (which you should!) – You get the exception “Requested registry access not allowed” when you submit the page.

After some tracing I’ve learned that the problem is that the server tries to store the SSL key for your destination server in the registry hive for the system user, which is the correct one, but apparently the SharePoint configuration wizard tightened the security on the keys in question.

To get around this: Grant your user (farm admin) membership to the local WSS_RESTRICTED_WPG security group and grant that group “full control” to HKEY_USERS\.DEFAULT\Software\Microsoft\SystemCertificates. You could also opt for granting your user direct access to the key.

To sum it up:

1. Your logged in user should be a farm administrator
2. Should be a member of either the local IIS_WPG or WSS_WPG groups
3. Grant access to HKEY_USERS\.DEFAULT\Software\Microsoft\SystemCertificates
   1. Add user to WSS_RESTRICTED_WPG group
   2. Grant that group “full control” access to the key

That’s it! You should now be able to setup a path.

Setup Job

Next setup the job to your liking, choose whatever options you desire.

Run the job. If it succeeds then stop reading now and save a few minutes of your time. No? Carry on then…

Hotfix deployment

At this point I got the following exception:

User cannot be found. at Microsoft.SharePoint.SPUserCollection.GetByID(Int32 id) at Microsoft.SharePoint.SPWeb.get_Author() at Microsoft.SharePoint.Deployment.WebSerializer.GetDataFromObjectModel(Object obj, SerializationInfo info, StreamingContext context) at Microsoft.SharePoint.Deployment.DeploymentSerializationSurrogate.GetObjectData(Object obj, SerializationInfo info, StreamingContext context) at Microsoft.SharePoint.Deployment.XmlFormatter.SerializeObject(Object obj, ISerializationSurrogate surrogate, String elementName, Boolean bNeedEnvelope) at Microsoft.SharePoint.Deployment.XmlFormatter.Serialize(Stream serializationStream, Object topLevelObject) at Microsoft.SharePoint.Deployment.ObjectSerializer.Serialize(DeploymentObject deployObject, Stream serializationStream) at Microsoft.SharePoint.Deployment.SPExport.SerializeObjects() at Microsoft.SharePoint.Deployment.SPExport.Run()

Looking like this:

Figure 2: Deployment error - no creator/owner of site

The exception occurs fairly quickly during the preparation phase. It obviously indicates that a creator of a (sub) site it not to be found in the SharePoint user database.

In my case it happened because the farm was originally deployed using a site collection backup/restore from another AD domain, the creators of various sites would then be users in the original SharePoint farm which would be unknown in the new (which is now my source). I suppose you might see this error if you deleted some users as well.

There is nothing you can do about this error; Microsoft however, has a hotfix for this (which also solves a few other bugs). Hotfix number is 313183 and the knowledge base article you are trying to address is kb936867. At the moment of writing this is private hotfix that can only be obtained by contacting MS support. Sucks but there is a way at least.

The hotfix solves a total of 11 bugs including one more in relation to Content Deployment entitled “Violation of PRIMARY KEY” – it seems I avoided one snag after all.

Feature problems

Next error in line occurred right after the last during the export phase. I received the very informative exception:

Failed to compare two elements in the array.
at System.Collections.Generic.ArraySortHelper`1.QuickSort[TValue](T[] keys, TValue[] values, Int32 left, Int32 right, IComparer`1 comparer)
at System.Collections.Generic.ArraySortHelper`1.QuickSort[TValue](T[] keys, TValue[] values, Int32 left, Int32 right, IComparer`1 comparer)
at System.Collections.Generic.ArraySortHelper`1.QuickSort[TValue](T[] keys, TValue[] values, Int32 left, Int32 right, IComparer`1 comparer)
at System.Collections.Generic.ArraySortHelper`1.Sort[TValue](T[] keys, TValue[] values, Int32 index, Int32 length, IComparer`1 comparer)
at System.Collections.Generic.ArraySortHelper`1.Sort(T[] items, Int32 index, Int32 length, IComparer`1 comparer)
at System.Array.Sort[T](T[] array, Int32 index, Int32 length, IComparer`1 comparer)
at System.Collections.Generic.List`1.Sort(Int32 index, Int32 count, IComparer`1 comparer)
at System.Collections.Generic.List`1.Sort(IComparer`1 comparer)
at Microsoft.SharePoint.Deployment.WebSerializer.GetDataFromObjectModel(Object obj, SerializationInfo info, StreamingContext context)
at Microsoft.SharePoint.Deployment.DeploymentSerializationSurrogate.GetObjectData(Object obj, SerializationInfo info, StreamingContext context)
at Microsoft.SharePoint.Deployment.XmlFormatter.SerializeObject(Object obj, ISerializationSurrogate surrogate, String elementName, Boolean bNeedEnvelope)
at Microsoft.SharePoint.Deployment.XmlFormatter.Serialize(Stream serializationStream, Object topLevelObject)
at Microsoft.SharePoint.Deployment.ObjectSerializer.Serialize(DeploymentObject deployObject, Stream serializationStream)
at Microsoft.SharePoint.Deployment.SPExport.SerializeObjects()
at Microsoft.SharePoint.Deployment.SPExport.Run()
*** Inner exception:
Object reference not set to an instance of an object.
at Microsoft.SharePoint.SPFeature.EnsureProperties()
at Microsoft.SharePoint.SPFeature.get_TimeActivated()
at Microsoft.SharePoint.Deployment.WebSerializer.ExportFeatureComparer.System.Collections.Generic.IComparer .Compare(ExportObject exportObject1, ExportObject exportObject2)
at System.Collections.Generic.ArraySortHelper`1.QuickSort[TValue](T[] keys, TValue[] values, Int32 left, Int32 right, IComparer`1 comparer)

Going to the source server I tried to pinpoint the error by running “stsadm –o export …” on the base site collection url (same error) and then the first level of sub sites (all exported fine).

That command is exactly the same as a content deployment just without the transfer and import part on the destination end (you are responsible for transfer and then use the import command).

The exception basically means that some of the features activated at the site collection level no longer exist on disk. Their feature definition files have probably been deleted. This can easily occur if you delete some features from your solution packs without deactivating/reactivating all features on deployment (and who cares to do that?).

If you know exactly what features are the problem (might be more than you know) I suppose you might be able to reinstall, deactivate and then uninstall to fix the problem. You might also be able to create dummy features with the correct ids and then try to install, deactivate and uninstall.

I did neither; code had to be written

What you need to do is:

1. Go recursively through your web application / site collection / root web / web
2. Each of these “parent” objects have a Feature collection
3. Each of these features in the feature collection should be examined
   1. If there is no feature.Definition (== null) then this is one of the faulty features.Simple remove it by executing parent.Features.Remove( id, true ). The force parameter is needed since the feature is not properly installed anymore, so you just remove it without any knowledge of deactivation event handlers etc.

I wrote an aspx page for this that is installed as a feature in the Central Administration site:

Figure 3: My page to list and possibly remove features from web app / site / web

Pretty cool

In due time, I will clean up the code and publish another article about this administration feature along with a few others that I’ve developed and since found indispensable.

Server Name Problem

Finally the export phase can be completed. Next problem is the transfer phase, which simply moves the exported files from the server assigned the task of performing the content deployment job to the destination server. In the path specification the location of the Central Administration site on the destination server is specified along with the destination web application and site collection.

The source server tries to export the file directly to the destination server handling content deployment jobs, which might or might not be the same server that’s running the Central Administration site. It does so by resolving the FQDN (Fully Qualified Domain Name) of the server, which might very likely be a problem to you.

If you deploy content between servers in separate network segments this won’t work out of the box, e.g. the source server can probably not find your destination server by the name “my_dest_server.my_domain”, which is only known within the immediate local AD domain of that server.

There’s no reason to think too deeply about these names – just try to do a content deployment and if it fails during the transport phase it’ll report “The remote upload Web request failed” along with the name it’s trying to resolve. A similar event log entry is also created:

Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Timer
Event ID: 6398
Date: 6/12/2007
Time: 9:48:07 PM
User: N/A
Computer:
Description:
The Execute method of job definition Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJobDefinition (ID 2f94ff2b-2aa1-498b-96ba-649c2e75ada7) threw an exception. More information is included below.

The remote name could not be resolved: ‘servername.dev.local’

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

The fix is simple:

1. Open your host file, usually located at c:\windows\system32\drivers\etc\hosts
2. Add a new line (don’t delete existing lines): “qqq.xxx.yyy.zzz servername.dev.local“. Be sure to use the correct ip address and name for your destination server. Remember that it should be an ip address that works from the source server (in some cases internal other external ip). You can probably get away with specifying the same ip address you used for the Central Administration site in that path definition – if you used a dns name then just ping the dns and grab the ip address.
3. Save the file
4. Retry your content deployment. No need to restart any services the fix is immediate.

Feature problems – part II

We’re now in the import phase and almost through. During the import SharePoint will check whether all the activated features at the source site collection (and sub sites) are also available at the destination site collection.

If not you’ll get an informative error, similar to: “Content deployment job ‘Remote import job for job with sourceID = 71bb6ada-762c-4e78-8bc3-2a105bbe5988′ failed.The exception thrown was ‘Microsoft.SharePoint.SPException’ : ‘Could not find Feature xxxxxx.’

The solution is obvious – install the same solutions/features at the destination web application as on the source.

Specified Name is already in use

If you get an error similar to “Content deployment job ‘Remote import job for job with sourceID = 71bb6ada-762c-4e78-8bc3-2a105bbe5988′ failed.The exception thrown was ‘Microsoft.SharePoint.SPException’ : ‘The specified name is already in use. A list, survey, discussion board, or document library cannot have the same name as another list, survey, discussion board, or document library in this Web site. Use your browser’s Back button, and type a new name.’“

You forgot to read the manual (ok, blogs) that specifies that the destination site collection should be a brand new blank site collection – in my case I tried to export to a newly created publishing site collection.

The Small Print

Finally your content deployment ought to be complete

If your site looks a bit strange it’s probably because the master page settings wasn’t copied, so you’ll have to assign the correct master page through the site settings. Might also be the case for the welcome page, though I haven’t confirmed it.

During the export every file of your site will be copied to the deployment package so if any files have gone missing you’ll get appropriate warnings during the export, but it’ll still complete.

This is actually a great way to detect if any aspx files have been deleted by accident, e.g. an AllItems.aspx page for a custom list might have gone missing if somebody changed the list definition (probably deployed within a feature).

Phew! At least it works for me now…

(Updated) Other bugs

This is a small list of other bugs I’ve heard/read about

1. (Thanks Harry!) The Cab-files are not always deleted and remain in the folder C:\WINDOWS\Temp\ContentDeployment. Regardless of the content deployment setting of the number of jobs to keep, they will not be deleted. Roll your own workaround and delete the files. You could schedule a job to delete everything older than 1 day (as I’m sure your job can complete in less time than that)

And of course: Move the directory location to a non-system drive

2. (Thanks Harry!) Specific sites within the site collection: I select only the language-variations but not the root. After Test Job or Run Now the root has been always added to the Scope (Fix 937208 apparently solves the problem)

3. Some characters are mangled after deployment, specifically “nbsp;” in html fields (probably a lot of others too). Update: This has been fixed with hotfix 938536 (private hotfix for now - sorry)

4. Missing disk space on destination server will be reported (on the source server) as
Failed to read package file. at Microsoft.SharePoint.Deployment.ImportDataFileManager.Uncompress(SPRequest request) at Microsoft.SharePoint.Deployment.SPImport.Run() *** Inner exception: Failure writing to target file at Microsoft.SharePoint.Library.SPRequest.ExtractFilesFromCabinet(String bstrTempDirectory, String bstrCabFileLocation) at Microsoft.SharePoint.Deployment.ImportDataFileManager.<>c__DisplayClass2.<Uncompress>b__0() at Microsoft.SharePoint.SPSecurity.CodeToRunElevatedWrapper(Object state) at Microsoft.SharePoint.SPSecurity.<>c__DisplayClass4.<RunWithElevatedPrivileges>b__2() at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode) at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param) at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode) at Microsoft.SharePoint.Deployment.ImportDataFileManager.Uncompress(SPRequest request)

5. If you choose to copy “all” security information between servers not in the same domain you might get the following error (copying role definitions only works fine)
A duplicate name “62c4fcbb-7ff7-4cc3-842e-17476b2e6219″ was found. at Microsoft.SharePoint.SPFieldCollection.AddFieldAsXmlInternal(String schemaXml, Boolean addToDefaultView, SPAddFieldOptions op) at Microsoft.SharePoint.Deployment.ListSerializer.CreateOrUpdateField(SPList list, String fieldName, XmlNode fieldNode) at Microsoft.SharePoint.Deployment.ListSerializer.UpdateListFields(SPList list, Dictionary`2 listMetaData) at Microsoft.SharePoint.Deployment.ListSerializer.SetObjectData(Object obj, SerializationInfo info, StreamingContext context, ISurrogateSelector selector) at Microsoft.SharePoint.Deployment.XmlFormatter.ParseObject(Type objectType, Boolean isChildObject) at Microsoft.SharePoint.Deployment.XmlFormatter.DeserializeObject(Type objectType, Boolean isChildObject, DeploymentObject envelope) at Microsoft.SharePoint.Deployment.XmlFormatter.Deserialize(Stream serializationStream) at Microsoft.SharePoint.Deployment.ObjectSerializer.Deserialize(Stream serializationStream) at Microsoft.SharePoint.Deployment.ImportObjectManager.ProcessObject(XmlReader xmlReader) at Microsoft.SharePoint.Deployment.SPImport.DeserializeObjects() at Microsoft.SharePoint.Deployment.SPImport.Run()

On hotfixes: Please note that hotfixes are cumulative and later numbers super seeds earlier ones - so the game is to get the highest number of all

(Updated) Conclusion (sort of)

Some of you have asked (in the comments) whether or not it all worked in the end. It actually did work! All of the above steps where enough to solve our immediate problems with the content deployment between our three environments.

Great! So do we use it? No.

We really really wanted to use this feature and all looked so well after our the latest hotfix deployment that we planned to use it for the existing publishing site as well as for a some additional upcoming site collections we’re developing.

One particular annoying feature (sorry for the pun) is breaking the content deployment which I have yet to find a solution for. The new sites are based on custom site definitions and a number of features that creates custom content types and site columns from a number of xml files. Some of these site columns are lookup columns that which cannot be created with xml files the same way as every other site column, because they need to refer to an existing list by list id (in the xml file) but the list will be assigned a dynamic id by the system when it’s created (by another feature that the site columns is dependent on).

To get around that problem a feature activation handled is executed that creates the lookup site columns using custom code that find the dynamic list id from the name. That code is roughly based on code found on codeplex (here). Some minor differences: I fixed some bugs with internal/display name mixup, reactivation problems and a missing “webid” (had to be dynamic as well) in the constructed field. The missing “webid” did cause content deployment to fail immediatly. For some reason I have yet to track down it now fails if the content type using one of the lookup site columns is in use, i.e. a list item of that type exists anywhere in the site collection. For lookup site columns created through the web interface there are no problems. Bummer.

The choice we’re facing (barring that I manage to solve the problem before long) is

1. Either: We can define the content type through xml files

2. Or: we can use content deployment and create content types manually through the web interface - they will be copied as part of the content deployment)

We chose the first option as content deployment at the current level of maturity seems too unstable. Furthermore we also decided to use only one strategy and therefore not use the content deployment for the first site collection that this article originally targetted (one where all content types where created through the web interface).  

How do we do it now? We use “stsadm -o backup/restore” to deploy new versions of the site. It’s essentially a database backup with all the benefits and drawbacks of such. It’s very stable. Specifically history of all items are maintained, you get a messed up user database where you’ll (eventually) find users from all environments, you need to explicitly set new ownership (to a valid user that can be found in the relevant environments AD), you get the luxury of copied security permissions sets and groups (which I might still build a tool to import/export).

comes from:http://soerennielsen.wordpress.com/2007/06/19/the-long-path-to-content-deployment/

Following the recent questions from my last post I thought it would be useful to highlight what functions are available when creating a column in a list/library within MOSS 2007. This can be useful when creating a:

• Calculated column based on other columns within a list/library. For example, to calculate the number of days difference between a list item being Created and Modified.
• View of a list/library that shows items that meet a certain criteria. For example, a View showing the tasks assigned to me.

Although the [Today] and [Me] functions are well know, other functions are not.

List of functions available

All of the functions available are listed below. I have only tested a sample of these in a MOSS 2007 list, but in theory most/all should work!

To get a more detailed list of the functions available:

1. Open a MOSS 2007 site.
2. Create a list.
3. On the Actions menu, select Edit in Datasheet.

   4.  At the bottom of the list, click the Help hyperlink. This will open a chm file.

    5. In the chm file, expand the Function Reference tree

The chm file may also be found at C:\Program Files\Microsoft Office\Office12\1033\STSLIST.CHM.

Example use of a function

Requirement = calculate the number of days difference between two date columns.

1. Make two date columns, one called Date1 and the other called Date2.

2. Make a third column (e.g. DateCalc) to calculate the difference and ensure the column type is set to Calculated.

3. In the Formula box type =DATEDIF(Date1,Date2,"D")

4. In the The data that is returned from this formula is section, click the Number radio button.

Result within a MOSS 2007 List:

Enjoy!

Posted: Friday, March 28, 2008 5:30 PM by James Kemp

How do you add a new Site Column to a Content Type using the MOSS object model? 

Here is the sample code

SPWeb web = new SPSite("http://localhost:4040").OpenWeb();

SPContentType myCT = web.ContentTypes["myNewContentType"];

   myCT.FieldLinks.Add(new SPFieldLink(web.Fields["abc"]));

   myCT.Update();

Note :

The following MSDN article speaks about “Updating Child Content types”.

http://msdn2.microsoft.com/en-us/library/ms442695.aspx

The example given in the article uses the SPFieldCollection object (SPContentType.Fields) to add columns to the content type. But when we use the sample given in the article we end up with the error message “SPException: This functionality is unavailable for field collections not associated with a list.”. I found that the columns are not added into content type and that are referenced in content type from the following article.

http://msdn2.microsoft.com/en-us/library/aa543526.aspx

Also the above article “How to: Reference a Column in a Content Type” says,

The Fields property returns an SPFieldCollection object. Each SPField in this collection represents a "merged view" of the base column definition and any overwritten properties specified in the column reference in the content type. Because of this, you cannot add columns directly to this collection. Attempting to do so results in an error.

Keep Coding...

Published Monday, January 08, 2007 2:08 PM by Karthikeyan

Two of the great new things about MOSS2007 are Content Types and the extensibility of the Search function. Put the two together and very quickly you’ll come up with the scenario where you’ve created a nice comprehensive set of metadata which you’ve now applied to all the sites and libraries in your site collection, and now you want search on those metadata items.

The Advanced Search web part (typically surfaced through the Search Centre) looks like it’s going to do the job for you, with a drop down box which lets you restrict your search based on properties, but out-of-the-box it quickly becomes apparent that only a subset of the standard properties are there, not your own site columns. The ones you get as standard are:

Author

Description

Name

Size (MB)

URL

Created Date

Last Modified Date

Created By

Last Modified By

There are a couple of additional steps which you have to carry out to make your own appear there, most of which have been documented in various places but I couldn’t find a complete end-to-end walk through for the process, so this is it.

Firstly, I’ve assumed that you’ve already set up the site columns, assembled them as content types, and made those content types available within the document libraries of your sites. In my case, I have a set of them which form the core metadata schema for my customer – a mixture of default and bespoke ones.

Contributor (multiline) default

Date Created (date/time) default

Disposal Action (choice) bespoke

Disposal Date (date/time) bespoke

Disposal Review (date/time) bespoke

Document Type (choice) bespoke

Relation (multiline) default

Title (single line) default

Topic (choice) bespoke

Created By (person/group) default

Modified By (person/group) default

Checked Out To (person/group) default

The problem comes about because within Sharepoint 2007 there are two types of properties – crawled and managed. Crawled properties are automatically extracted from crawled content, but users can however only perform queries over managed properties. Thankfully Sharepoint lets us map one or more crawled properties onto a managed property and then, after the next crawl, those properties become available.

That description – one or more – is quite important as it permits an element of ‘fuzzy searching’ whereby the metadata category which the user wants to search on may be implemented in a number of different ways across different content types. This lets us hide that from the user.

The place to start is Central Admin – Shared Services Administration – Metadata Poperty Mappings. This is where you can check whether the properties you want are already being managed, or whether you will need to add them. For my list above, the “Created By”, “Created Date” [aka “created”], “Title” [aka “DisplayTitle] and “Modified By” properties are present but the “Contributor”, “Disposal Action”, “Disposal Date”, “Disposal Review”, “Document Type”, “Relation”, Topic and “Checked Out To” ones will need to be added. NB It may also be necessary to check the existing ones and add any additional new crawled properties to the list.

Adding them is really only a case of clicking the “new managed property” button, giving the property name (no embedded spaces allowed), a description, a type (text, integer, date, etc) and then deciding which crawled property (or properties) to map to.

In my case I’m mapping as follows

Managed Property

Type

Crawled Properties

CreatedBy

Text

Creator

Created

Date/Time

Office:12

Basic:15

DisplayTitle

Text

Basic:displaytitle

ModifiedBy

Text

ows_ModifiedBy

ows_Modified_0x0020_By

Contributor

Text

_Contributor

DisposalAction

Text

Disposal Action

ows_Disposal_x0020_Action

DisposalDate

Date/Time

ows_Disposal_x0020_Date

DisposalReview

Date/Time

Disposal Review

DocumentType

Text

Document Type

ows_Document_x0020_Type

Relation

Text

_Relation

Topic

Text

ows_Topic

Topic

CheckedOutTo

Text

ows_CheckoutUser

At this point it would be nice if they all just magically appeared in the advanced search dropdown list, but unfortunatley there’s one more step involving evil editing of config files.

Go into your Advanced Search page and select Site Actions – Edit Page. For the Advanced Search Box webpart chose Edit- Modify Shared Webpart. In the “Properties” section there is a ‘properties’ dialogue box which, if you click into it, will give you the […] ‘builder’ link allowing you to edit the XML string.

This string has four sections, two of which concern us. Between <LangDefs> and </LangDefs> it lists all the languages which can be used and between <Languages> and </Languages> it causes those languages to be displayed in the web part.

We’re interested in the bottom two sections however. Somewhere between <PropertyDefs> and </PropertyDefs> we need to insert all of the Managed Properties we added above, following the format of the entries already there. So, for example, for our “DisplayTitle” property, we add the line

<PropertyDef Name=”DisplayTitle” DataType=”text” DisplayName=”Title”/>

Finally, in the section between <ResultTypes> and </ResultTypes> we need to show which result types we want our results to show up in. So assuming we want our new results to show up everywhere, we find the subsection between <ResultType DisplayName=”All Results” Name=”default”> and </ResultType> and add in the line

<PropertyRef Name=”DisplayTitle” />

Exit the “modify web part” process and publish the page if necessary.

comes from:http://www.sharepointblogs.com/andymay/archive/2006/11/09/moss-2007-advanced-search-on-your-own-metadata.aspx

by Oscar 1/29/2008 4:22:00 PM

As you may or may not know, there are thousands of ways to accomplish development and customization tasks in MOSS 2007 and WSS 3.0.
At one point or another, as a MOSS Consultant, you will be faced with the task of creating custom application pages.  If you have an extensive web application development experience (much like I do), you will first think of using your web application techniques when faced with this task.  However, there are better and faster ways of accomplishing customization tasks around SharePoint. 
Today I will walk you through one of those scenarios where it would make sense to completely use your typical web application skills and techniques, then show you how to do it the MOSS way!

Scenario

You are creating a custom Site Provisioning Tool for MOSS 2007, and want to allow users to enter specific information so that the new site is created.  Once the site is created, you want to add an entry in a SharePoint List to track all the sites that have been created, and maybe if you are motivated create some custom views on the List to view by Region :) 

Solution

For example, I created some fields on my page that map to the fields on a SharePoint List to track newly created project sites on a List called Projects
This is what the page looks like when browsing to it.

FIGURE 1 - Shows the custom site provisioning application page with all the form field controls rendered

The table below shows you the actual field type used for each field on the form.
SharePoint List Fields

Field Label
Field Type

Project Title
Text Field

IT Owner
Person or Group

IT Group
Choice Menu

Region
Choice Menu

The table below shows you what out of the box SharePoint Form Controls you will use

Field Types and corresponding Field Controls used on ASPX page

Field Type
Control Used

Project Title - Title
FormField

IT Owner
PeoplePicker

IT Group
FormField

Region
FormField

So here is the interesting part on this blog entry!
TIP: Throughout the various Application Pages on MOSS, there are samples of how the FormField is used.  Look around, you will be amazed what you can learn just by firing up VS 2005 and viewing the code for these pages! 
Rendering the Region Field (Choice)
Our task here is to render the Region Field which is a Choice Menu on the SharePoint List. 
The Most Obvious Way of Populating the Choice Field
Now, typically, to render the drop down menu and populate it, you would probably do the following:

a) Drag a DropDownList Control on to the page
b) Wire an event handler on the page load event, and then query the SharePoint List using CAML
c) Iterate through the results and populate the DropDownList

The Rapid Method of populating the Choice Field

a) got to your page code and type code so that you can add a FormField Controls as such

FIGURE 2 - Shows you how you can add an out of the box FormField, set its properties so it gets wired to the appropriate column on the SharePoint List

NOTE: The FieldName should be the same as the one specified on the List
b) Wire the FormFields's OnInit event handler - this is where we are going to tell the FormField what List we are inserting data into.
c) Write code to get a handle on the List - I used a page global variable and set its value  on OnPreInit event
d) On the FormField's OnInit handler, specify the ListName property
And that's it!  Now if you browse to the aspx application page, you should see the DropDownList populated!
Rendering the IT Owner Field (PeoplePicker)

Have you ever wanted to use that nice User Picker Control that you see on various WSS/MOSS pages?  You can!
I dropped the People Picker onto my ASPX custom application page like so:

FIGURE 3 - How to specify a PeopleEditor Control in a declarative manner

To obtain the values the user has selected, you need to do something similar to my code-behid page below.  Here I am capturing the value (using PickerEntity Class), and inserting a new list item on my SharePoint List.

FIGURE 4 - Shows you how to obtain or capture the values entered in the PeopleEditor Control.

TIP: One more thing I would like to point out in the code on Figure 4.  I am also inserting a value in a Hyperlink or Picture Field Type.  You will notice that after putting the url value, i have an additional piece of information, that is the link label! in this case, 'Go To Site'.  This is how it looks on the SharePoint List

FIGURE 5 - Shows how the link label looks based on the code used on Figure 4 to programmatically populate the Hyperlink or Picture Field Type.

I hope this information is useful to you at some point!
Enjoy,
Oscar

It seems that links in Sharepoint 2007 lists still open in the same window. There is no build in option to change this as far as I know, so what I did was create a new field type.

I've based this on an article from Patrick Tisseghem that can be found here.

I could not get the sample to work. In the end I found that I had an inherits statement in the control's ascx that did not need to be in there.  

The steps to create the custom field are:

1. Create a class for the value of the field
2. Create a class custom field itself
3. Create a class for the control that is used for rendering (it uses a control template for the actual rendering)
4. Create an ascx file containing the rendering template
5. Create a field type definition file
6. Deploy, register as safe control and recycle the app pool

Here is the code:

1. LinkFieldValues.cs

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
namespace MyCompany.MOSS.Web.Link
{
public class LinkFieldValue: SPFieldMultiColumnValue
{
private const int numberOfFields = 3;
public LinkFieldValue()
: base(numberOfFields)
{ }
public LinkFieldValue(string value)
: base(value)
{ }
public string Hyperlink
{
get { return this[0]; }
set { this[0] = value; }
}
public string Description
{
get { return this[1]; }
set { this[1] = value; }
}
public string Target
{
get { return this[2]; }
set { this[2] = value; }
}
}
}

2. LinkField.cs

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;
namespace MyCompany.MOSS.Web.Link
{
class LinkField: SPFieldMultiColumn
{
public LinkField(SPFieldCollection fields, string fieldName):base(fields, fieldName)
{
}
public LinkField(SPFieldCollection fields, string typeName, string displayName)
: base(fields, typeName, displayName)
{
}
public override Microsoft.SharePoint.WebControls.BaseFieldControl FieldRenderingControl
{
get
{
BaseFieldControl fldControl = new LinkFieldControl();
fldControl.FieldName = InternalName;
return fldControl;
}
}
public override object GetFieldValue(string value)
{
if (string.IsNullOrEmpty(value))
{
return null;
}
return new LinkFieldValue(value);
}
}
}

3. LinkFieldControl.cs

using System;
using System.Collections.Generic;
using System.Text;
using System.Web.UI.WebControls;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;
namespace MyCompany.MOSS.Web.Link
{
class LinkFieldControl : BaseFieldControl
{
protected TextBox hyperlinkTextBox;
protected TextBox descriptionTextBox;
protected DropDownList targetDropDownList;
protected override string DefaultTemplateName
{
get { return "LinkFieldRendering"; }
}
public override object Value
{
get
{
EnsureChildControls();
LinkFieldValue fieldValue = new LinkFieldValue();
fieldValue.Description = descriptionTextBox.Text.Trim();
fieldValue.Hyperlink = hyperlinkTextBox.Text.Trim();
fieldValue.Target = targetDropDownList.Text.Trim();
return fieldValue;
}
set
{
EnsureChildControls();
LinkFieldValue fieldValue = (LinkFieldValue)value;
descriptionTextBox.Text = fieldValue.Description;
hyperlinkTextBox.Text = fieldValue.Hyperlink;
targetDropDownList.SelectedValue = fieldValue.Target;
}
}
public override void Focus()
{
EnsureChildControls();
hyperlinkTextBox.Focus();
}
protected override void CreateChildControls()
{
if (Field == null)
return;
base.CreateChildControls();
if (ControlMode == SPControlMode.Display)
return;
hyperlinkTextBox = (TextBox)TemplateContainer.FindControl("hyperlinkTextBox");
if (hyperlinkTextBox == null)
throw new ArgumentException("Corrupted LinkFieldRendering template - missing hyperlinkTextBox.");
hyperlinkTextBox.TabIndex = TabIndex;
hyperlinkTextBox.CssClass = CssClass;
hyperlinkTextBox.ToolTip = Field.Title + " Link";
descriptionTextBox = (TextBox)TemplateContainer.FindControl("descriptionTextBox");
if (descriptionTextBox == null)
throw new ArgumentException("Corrupted LinkFieldRendering template - missing descriptionTextBox.");
descriptionTextBox.TabIndex = TabIndex;
descriptionTextBox.CssClass = CssClass;
descriptionTextBox.ToolTip = Field.Title + " description";
targetDropDownList = (DropDownList)TemplateContainer.FindControl("targetDropDownList");
if (targetDropDownList == null)
throw new ArgumentException("Corrupted LinkFieldRendering template - missing targetDropDownList.");
targetDropDownList.TabIndex = TabIndex;
targetDropDownList.CssClass = CssClass;
targetDropDownList.ToolTip = Field.Title + " target";
if (ControlMode == SPControlMode.New)
{
hyperlinkTextBox.Text = Field.GetCustomProperty("DefaultHyperlink").ToString();
descriptionTextBox.Text = Field.GetCustomProperty("DefaultDescription").ToString();
targetDropDownList.SelectedValue = Field.GetCustomProperty("DefaultTarget").ToString();
}
}
}
}

4. LinkControl.ascx

<%@Control Language="C#" Debug="true" Inherits="MyCompany.MOSS.Web.Link.LinkFieldControl"%>
<%@Assembly Name="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@Register TagPrefix="SharePoint" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" namespace="Microsoft.SharePoint.WebControls"%>
<SharePoint:RenderingTemplate ID="LinkFieldRendering" runat="server">
<Template>
<asp:TextBox runat="server" id="hyperlinkTextBox" MaxLength="400" Size="40"/>
<asp:TextBox runat="server" id="descriptionTextBox" MaxLength="100" Size="40"/>
<asp:DropDownList runat="server" id="targetDropDownList">
<asp:ListItem Value="_Blank" Text="Nieuw Venster"/>
<asp:ListItem Value="_Self" Text="Dit Venster"/>
</asp:DropDownList>
</Template>
</SharePoint:RenderingTemplate>

5. fldtypes_LinkControl.xml

<?xml version="1.0" encoding="utf-8"?>
<FieldTypes>
<FieldType>
<Field Name="TypeName">MyLink</Field>
<Field Name="ParentType">MultiColumn</Field>
<Field Name="TypeDisplayName">My Link</Field>
<Field Name="TypeShortDescription">My Link (Link, Description, Target)</Field>
<Field Name="UserCreatable">TRUE</Field>
<Field Name="ShowOnListAuthoringPages">TRUE</Field>
<Field Name="ShowOnDocumentLibraryAuthoringPages">TRUE</Field>
<Field Name="ShowOnSurveyAuthoringPages">TRUE</Field>
<Field Name="ShowOnColumnTemplateAuthoringPages">TRUE</Field>
<Field Name="FieldTypeClass">MyCompany.MOSS.Web.Link.LinkField,MyCompany.MOSS.Web.Link, Version=1.0.0.0, Culture=neutral,PublicKeyToken=null</Field>
<PropertySchema>
<Fields>
<Field Name="DefaultHyperlink" DisplayName="Default Link:" MaxLength="400" DisplaySize="40" Type="Text">
<Default>http://www.nu.nl</Default>
</Field>
<Field Name="DefaultDescription" DisplayName="Default Description:" MaxLength="100" DisplaySize="40" Type="Text">
<Default>Nieuws</Default>
</Field>
<Field Name="DefaultTarget" DisplayName="Default Target:" MaxLength="20" DisplaySize="20" Type="Text">
<Default>Nieuw Venster</Default>
</Field>
</Fields>
</PropertySchema>
<RenderPattern Name="DisplayPattern">
<Switch>
</Expr>
<Case Value="">
</Case>
<Default>
<HTML><![CDATA[<A HREF="]]></HTML>
<Column SubColumnNumber="0" HTMLEncode="TRUE"/>
<HTML><![CDATA[" target="]]></HTML>
<Column SubColumnNumber="2" HTMLEncode="TRUE"/>
<HTML><![CDATA[">]]></HTML>
<Column SubColumnNumber="1" HTMLEncode="TRUE"/>
<HTML><![CDATA[</a>]]></HTML>
</Default>
</Switch>
</RenderPattern>
</FieldType>
</FieldTypes>

6. Deploy

• Place the dll in the GAC
• Copy the xml file to c:\program files\common files\microsoft shared\web server extensions\12\template\xml
• copy the ascx file to c:\program files\common files\microsoft shared\web server extensions\12\template\controltemplates
• Add this line to the safecontrols section in the web.config file:

<SafeControl Assembly="MyCompany.MOSS.Web.Link, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" Namespace="MyCompany.MOSS.Web.Link" TypeName="*" Safe="True" />

• iisreset

comes from:http://bloggingabout.net/blogs/edwin/archive/2007/03/02/let-sharepoint-link-open-in-a-new-window.aspx