A Data Connection Library in Microsoft SharePoint Server 2010 is a library that can contain two kinds of data connections: an Office Data Connection (ODC) file or a Universal Data Connection (UDC) file. Microsoft InfoPath 2010 uses data connections that comply with the Universal Data Connection (UDC) file schema and typically have either a *.udcx or *.xml file name extension. Data sources described by these data connections are stored on the server and can be used in standard form templates and browser-enabled form templates.

How to create a SharePoint Server Data Connection Library?

1. Browse to a SharePoint Server 2010 site on which you have at least Design permissions. If you are on the root site, create a new site before you continue with the next step.

2. On the Site Actions menu, click More Options.

3. On the Create page, click Library under Filter By, and then click Data Connection Library.

4. On the right side of the Create page, type a name for the library, and then click the Create button.

5. Copy the URL of the new data connection library.

How to create a new data connection file in InfoPath?

1. Open InfoPath Designer 2010, click Blank Form, and then click Design Form.

2. On the Data tab, click Data Connections, and then click Add.

3. In the Data Connection Wizard, click Create a new connection to, click Receive data, and then click Next.

4. Click the kind of data source that you are connecting to, such as Database, Web service, or SharePoint library or list, and then click Next.

5. Complete the remaining steps in the Data Connection Wizard to configure your data connection, and then click Finish to return to the Data Connections dialog box.

6. In the Data Connections dialog box, click Convert to Connection File.

7. In the Convert Data Connection dialog box, enter the URL of the data connection library that you previously copied (delete "Forms/AllItems.aspx" and anything following it from the URL), enter a name for the data connection file at the end of the URL, and then click OK. It will take a few moments to convert and save the data connection file to the library.

8. Confirm that the data connection was converted successfully by examining the Details section of the Data Connections dialog box while the name of the converted data connection is selected.

9. Browse to the SharePoint data connection library, click the drop-down next to the name of the data connection, click Approve/Reject, click Approved, and then click OK.

Today when duplicity problem has increased a lot, authentication has become a must. Authentication is the process of determining if someone is who they claim to be. It answers the question "Who is this guy really?" Taking advantage of SharePoint Server 2010 Claims Based Authentication feature may help you curb this duplicity issue. Even if you are a SharePoint Foundation 2010 user, you can enjoy the same feature to authenticate the user identity.

In case you are looking for a place to host your Enterprise Wiki Sharepoint site, please have a look at ASPHostCentral.com. With the lowest and most affordable Sharepoint Server 2010 hosting price, you can maximize the use of this template for the benefits of your company/organizations

Most enterprise applications need some basic user security features. At a minimum, they need to authenticate their users, and many also need to authorize access to certain features so that only privileged users can get to them. Some apps must go further and audit what the user does. On Windows Azure, these features are built into the operating system and are usually quite easy to integrate into an application. By taking advantage of Windows integrated authentication, you don't have to invent your own authentication protocol or manage a user database. By using access control lists (ACLs), impersonation, and features such as groups, you can implement authorization with very little code. Indeed, this advice applies no matter which OS you are using. It's almost always a better idea to integrate closely with the security features in your OS rather than reinventing those features yourself.

In the real world, we face the following challenges:
* Privacy regulations and other pieces of legislation are impacting what kind of information we are allowed to capture and store about users, so in some cases we can't just demand that people give us all of their personal details.
* Businesses want to interoperate with other businesses, and government organizations want to provide more integrated services to citizens. However, different systems use different authentication systems and businesses want to integrate in a secure, legally compliant manner.
Consequently, claims based authentication in SharePoint Server is designed to address the two challenges mentioned above. Claims based authentication addresses privacy and other compliance concerns by requesting less specific, less personal information about people, and by trusting other parties or systems to do the "proof of identity" check. Claims based authentication addresses integration of different systems by allowing communications using open standards, and by providing a platform for developing more specialized 'identity connectors' between systems.

How to implement Claims based authentication?

The claims-based authentication is implemented in the following way:
* From a developer's point of view, the platform that Microsoft is providing is called the Windows Identity Foundation. Earlier, it was called the Geneva framework. It provides a programming library suitable for building claims-aware applications. This library is also used by SharePoint 2010
* Active Directory Federation Services implement services to create, accept, and transform tokens that contain claims.
* Cardspace provides a user interface for users to select which "identity card" they wish to use for a particular system
Claims based authentication won't address the lifecycle management of identity information.
Claims based authentication may let our system know that a user is a contractor from a partner company, but it alone won't let us specify a rule that says "all of my company's financial spreadsheets must not be seen by contractors". Not only does claims based authentication not provide this capability, but neither do the role-based access controls provided by SharePoint. In fact SharePoint's role-based access control model itself is too limited to address this. It still needs substantial improvements.
Claims based authentication feature was not available in MOSS 2007; SharePoint Server 2007 uses a native Active Directory-based authentication between machines and systems. In addition to claims based authentication, take advantage of other exclusive features in SharePoint Server 2010 and also enjoy some free SharePoint templates or web parts that come with SharePoint products.

While consulting with clients new to SharePoint and how the robust functionality can empower their organization’s collaboration efforts, we are typically asked this question:  “What’s the difference between a discussion board and a blog?”

Well, that’s a very good question to ask and sometimes a little difficult to explain.  Why?  It’s mainly due to the fact that the technical functionality between a discussion board and a blog are essentially the same.  Both provide a platform for a user or users to post a message that other users can respond to.   However, there are three core differences that separate the two within SharePoint

Organization – A discussion board’s posts are typically organized by a topic.  The blog on the other hand is organized in a chronological format, with the posts assigned to a category

List vs. Site – In SharePoint specifically; a discussion board is a preconfigured List template.  On the flip side of that coin, a blog in SharePoint is actually an entire Site template.  The blog being a site allows a great deal more functionality, while the discussion board is limited because it’s only a list


The main difference:

Purpose – the philosophical purpose of a discussion board and Blog are very different from each other

A discussion board is used to solicit feedback from others and is a great tool for generating dialogue between users in a group.   Anyone can post a message and users have a platform to respond to each other in a constraint free environment.  We typically think of a discussion board as a conversational view of an email (think ‘Reply All’ here).

A blog however is intended for a specific person or a specific group to post ideas, thoughts, and articles.  Generally the posts are considered expertise (although an occasional rant) and visitors can comment on them.  A blog’s purpose isn’t to start dialogue, but is meant to deliver a message

Here’s an example that will put it in perspective

Scenario: We want to find out what my team thinks is the best place to have lunch on Friday

Discussion Board or Blog:  Discussion Board



Scenario: We want to explain why Just Fresh is the best place for team lunches on Fridays

Discussion Board or Blog:  Blog

Conclusion

As you can see, the discussion board and blog have some major conceptual differences between them.  Although the core functionality is similar (topic, post, comments) what sets the two apart is what you want to accomplish with them.  If you want to have communication between users about a topic, utilize a discussion board.  If you have a topic that you want one user to communicate to users, utilize a blog.  In the next article we will review the blog Site template in SharePoint and how it can be used in organizations

An Enterprise Wiki is a publishing site for sharing and updating large volumes of information across an enterprise. If an organization needs a large, centralized knowledge repository that is designed to both store and share information on an enterprise-wide scale, consider using an Enterprise Wiki.

In case you are looking for a place to host your Enterprise Wiki Sharepoint site, please have a look at ASPHostCentral.com. With the lowest and most affordable Sharepoint Server 2010 hosting price, you can maximize the use of this template for the benefits of your company/organizations.

Comparison of Enterprise Wikis with Team Sites

The Team Site template provides a flexible way to create content. This template includes a cross-browser Rich Text editor and in-line auto-completion. The Team Site template enables collaboration across teams within an organization or across organizations. Team Sites address two key concerns for anyone responsible for ensuring the integrity of an organization's content

- Editorial control   Administrators of a Team Site, or anyone with Full Control permissions on a Team Site, can allow a subset of users to edit entries and allow all users to read the entries
- Version control    Users can view previous versions of an entry and see when and by whom changes were made. If the changes were incorrect or inappropriate, the entry could be rolled back to an earlier version

In SharePoint Server 2010, the Team Site template home page is a wiki page. The Enterprise Wiki template uses the publishing features of SharePoint Server 2010 to add page ratings, managed metadata, and customization capabilities. Integration with Microsoft SharePoint Designer 2010 makes it easy to modify the display of content by changing page layouts and implement consistent branding by changing master pages

Uses and benefits of Enterprise Wikis

Enterprise wikis help organizations collect, organize, and distribute information. Enterprise wikis often become repositories for an organization's unstated knowledge, which otherwise might not be stored anywhere. Enterprise wikis can encourage informal learning and sharing tips with other users, which can reduce the need for formal training or continuous IT support

Limitations of Enterprise Wikis

Because an Enterprise wiki can generate a high level of network traffic, you might find it necessary to configure a single site collection and a single, dedicated Microsoft SQL Server database. If the Microsoft SQL Server database is shared, users might experience slower performance

Enterprise Wiki pages cannot be converted or migrated to pages on a Team Site without using custom code. Because Enterprise Wikis are used with the publishing feature in SharePoint Server 2010, there are significant differences between an Enterprise Wiki site and a Team Site