Abhishek Bhowmick | SharePoint Blog

Who are NT AUTHORITY\Authenticated Users?

Posted in Sharepoint by Abhishek Bhowmick on May 4, 2011

The user “NT AUTHORITY\Authenticated Users” represents every Domain user account that can successfully log on to the domain . In the typical environment that would include employees, contractors, vendors with a “special account” or anyone with Windows Authenticated access to the network.

SharePoint makes it quite easy to add “NT AUTHORITY\authenticated users” to site permission:

CAUTION: You must allow this account permission to your site only when you are convinced that you are willing to reveal your site information to all who can successfully log on to the domain network because the permission you allow to this account would apply to everyone in the domain. Else, ensure if you find this account in your permission list, remove it.

This comes in very handy when you do not wish to add individual permission and you want to make your site at least visible to all or allow elevated permission as and how you plan the entitlements.

SharePoint Permissions: Hierarchy and inheritance

Posted in Sharepoint by Abhishek Bhowmick on May 4, 2011

By default, permissions on lists, libraries, folders, items, and documents are inherited from the parent site. However, you can break this inheritance for any securable object at a lower level in the hierarchy by editing the permissions on that securable object (that is, creating a unique permission assignment) . For example, you can edit the permissions for a document library, which breaks the permissions inheritance from the site.

Web sites are themselves a securable object on which permissions can be assigned. You can configure subsites to inherit permissions from a parent site or break the inheritance and create unique permissions for a particular site. Inheriting permissions is the easiest way to manage a group of Web sites. However, if a subsite inherits permissions from its parent, that set of permissions is shared.

Owners of subsites that inherit permissions from the parent site can edit the permissions of the parent. Ensure that any changes you make to the permissions on the parent site are appropriate for the parent site and all subsites that inherit those permissions.

The following figure shows a site collection hierarchy with a top-level Web site and subsites that inherit permissions from their parent site as well as a subsite with unique permissions.

In the preceding figure, subsite 1 inherits permissions from the top-level Web site.This means that changes made to SharePoint groups and permission levels on the top-level site also affect subsite 1.

Subsite 2 is also inheriting permissions from its parent (subsite 1). However, because subsite 1 is also inheriting permissions from its parent, changes made to SharePoint groups and permission levels on the top-level site affect both subsite 1 and subsite 2. This is because you cannot manage permissions on a subsite that is inheriting permissions. Instead, you either manage the permissions of the parent (which is the top-level Web site for subsite 1 and subsite 2) or you can break the inheritance and create unique permissions.

Notice that subsite 3 has unique permissions. This means that it does not inherit permissions from its parent site. Therefore, any changes made to the permission levels and SharePoint groups on subsite 3 do not affect its parent site. Because subsite 4 is inheriting permissions from subsite 3, any changes to permission levels or SharePoint groups on subsite 3 affect both sites.

Each site contains additional securable objects that have a particular position in the site hierarchy, as shown in the following figure:

Lower-level securable objects automatically inherit permissions from their parent. For example, a list or library inherits permissions from the site, and list items and documents inherit permissions from the list, library, or folder that contains them. You can break this inheritance at any point in the hierarchy and assign unique permissions. When you break the inheritance from the parent, the securable object from which you broke the inheritance receives a copy of the parent’s permissions. You can then edit those permissions to be unique — meaning that any changes you make to the permissions on that securable object do not affect the parent.

Reference: http://office.microsoft.com/en-us/windows-sharepoint-services-help/about-controlling-access-to-sites-and-site-content-HA010100144.aspx

SharePoint Versioning

Posted in Sharepoint by Abhishek Bhowmick on May 4, 2011

Versioning allows updates, restoring and tracking of the items in a list or in a library when they are changed. In order to enable versioning, one needs at least a Design permission to the specific document or list library.

Why should you enable versioning?

View a previous version – the ability to view a previous version of the item in order to refer to guidelines or to check from which version one is going to restore from. This view has nothing to do with the overwriting of the current version.

Load a previous version and store it as the current version – it is considered as easy to restore the current version with an older version. The current version which was replaced will become part of the version history so as to have the possibility to return to it. Reasons for this ability are: making mistakes on the current version or to restore an item which was deleted.

Record a version history – versioning, lets everyone know when an item was modified and by who. Version history keeps track of all the changes done in the properties and also saves the comments that users include with their version update.

Major and Minor versions

Major versions, usually used when a user adds a large amount of data to a file example a chapter or a section

Minor versions, which is mostly used when a user changes formats or spelling mistakes.

Minor versions are not visible to everyone unless elevated permission is allowed to users. This is because minor versions are saved as drafts. The minor versions needs to be published as Major versions so it is visible to others.

Versioning is only found in document libraries (minor and major versions) and lists (major versions only).

Versioning lifecycle in SharePoint

• Document with version 1.0 is a public version, everyone can see. Once a document is created or uploaded, it is automatically published for everyone to see.

• Document is checked out for editing, version 1.1 is created. This can only be seen by editor(s) (version 1.0 is still visible for readers).

• Document is checked in, version 1.2 (minor version).

• Document is published; version 2.0 is created – due to a major version, visible for everyone.

Versioning and Checking Out

After checking out a document or list item, a version is only created when a file is checked back in. It is very important to leave a brief comment while checking in the document or list item to track changes and timeline else versioning will not be effective.

Restoring and/or Deleting Version History

One can either restore a version to go back to a previous version or state or delete a version history if not required anymore.

Reference: http://office.microsoft.com/en-us/windows-sharepoint-services-help/introduction-to-versioning-HA010021576.aspx

Exchange Public Folder vs SharePoint

Posted in Sharepoint by Abhishek Bhowmick on May 4, 2011

Why should you migrate your Exchange Public Folders to SharePoint?

SharePoint makes it easier for people to work together. Using SharePoint, users can set up sites to share information with others, manage documents from start to finish, and publish reports to help everyone make better decisions. The capabilities of SharePoint work together to help your team quickly respond to changing business needs. Using SharePoint, your people can share ideas and expertise, create custom solutions for specific needs, and find the right business information to make better decisions. SharePoint helps you cut training and maintenance costs, save time and effort, and focus on higher business priorities.

Here are some SharePoint positives:

  • Team Workspaces – SharePoint helps teams communicate and collaborate by providing easy access to people, documents and information.

 

  • Document Management – Public Folder were not designed for document sharing and collaboration. SharePoint provides versioning and other document management features, such as check-in and check-out functionality, and automatic notifications of content changes.

 

  • Workflow Applications – SharePoint provides many application templates that provide customer scenarios for building workflow on the SharePoint platform, to address specific business processes or sets of task.

 

  • Organizational Forms – Use of Microsoft InfoPath and InfoPath Forms Services which is an enhanced and rich user experience. Users can submit the forms which can be stored in SharePoint Form libraries for future collaboration and interaction.

 

Why is SharePoint recommended over Exchange Server Public Folder?

 

  • Collaboration – Public Folders are not efficiently interactive and collaborative as SharePoint. SharePoint provides a web interface for your data to be shared across based on permission and full compatibility with your Microsoft Office. This enables you to directly interact with your files without having them downloaded locally and use the check-out and check-in feature which is quite common.

 

  • Storing large files is not an efficient use of public folders.

 

  • Search – SharePoint can crawl Exchange Server Public Folders however only the data within Public Folder messages or attachments with the supported filters can be indexed. When we refer to filters, we are referring to iFilters which are used to register file extensions so files can be recognized and indexed. While SharePoint includes filters for HTML, TIFF, text files and Microsoft file extensions. PSTs or private mailboxes cannot be crawled though. Hence, search is more efficient in SharePoint.

 

What are the limitations in SharePoint after migrating from Exchange Public Folders?

 

· Outlook is fully integrated with Exchange compared to SharePoint. Unlike SharePoint – which requires users to connect individual lists and libraries on a one-by-one basis, multiple connections to Exchange are already built in to the Outlook client. For example, there’s no need to connect to individual public folders within Exchange, since they’re all simultaneously connected through the public folder hierarchy exposed in Exchange.

 

· There are naming restrictions within SharePoint that don’t exist in Exchange. In particular, SharePoint URLs are limited to 255 characters and file names must be free of special characters. This was listed as a consideration for migrating public folders to SharePoint, but it’s also a constraint on using SharePoint more generally for other purposes.

 

· Mail-enabled SharePoint Document Library’s – While these libraries can store any document type, e-mail sent to mail-enabled document libraries usually show up in .eml format (Outlook Express format). If you try to open the .eml file from the document library, it will open using the web browser and will only contain the message body (no header or attachment). You can create your own application to convert to .msg format, or you can search on the web and find any number of .eml to .msg converter utilities.

 

· Unlike Public Folders, email interactivity will not be preserved in SharePoint after migration. This means you can of course create an email enabled document library and route emails and attachments to it but cannot reply or forward from being inside SharePoint. You must have Outlook installed to open the files externally and then interact.

Differentiating Content Approval and Approval Workflow

Posted in Sharepoint by Abhishek Bhowmick on May 4, 2011

Content approval is a core SharePoint process which is used for publishing documents. This process provides the ability to limit the visibility of a document to approvers until the document is approved to be published. This will change the security of the document such that all users who have access to the list will be able OR not able to view it. Approval workflow is a workflow designed for approving documents. When the workflow is initiated, the document approval status is set to “In progress” and a task and an email is created for the specified users and groups to approve the document. Once the task is opened and completed, either “Approve” or “Reject”. The document approval status will change to “Approved” or “Rejected”. Approval workflow does not change visibility on the document.

Listing the SharePoint groups where a user account is a member of

Posted in Sharepoint by Abhishek Bhowmick on November 25, 2010

Have you ever thought of searching for a user account in an enormous list of SharePoint permission groups?  Nightmare isn’t it?

I bumped into this amazing utility which lists the SharePoint groups for a user account in a SharePoint site collection.  Thanks to the black knight!

Run it off a command line from any client computer and you do not absolutely need to be on a server.

Parameters:

ListUsersGroups <site-url> <username>
Site-url: Url of site collection including protocol (example http://localhost)
username: Full username including domain (example MOSSWORK\user)

URL: http://www.theblackknightsings.com/ListAllSharePointGroupsAUserBelongsTo.aspx

Link to the utility: http://www.theblackknightsings.com/ct.ashx?id=657139ba-bd80-42af-a4bd-107516bff6b8&url=http%3a%2f%2fwww.theblackknightsings.com%2fcontent%2fbinary%2fListUsersGroups.exe

You may download it off my blog too at https://prequest01.files.wordpress.com/2010/11/listusersgroups-exe.jpg (Right-click and save as.  Don’t forget to rename to .exe – Sorry folks, server didn’t allow the extension upload)

Using a list as a series item web part for a SharePoint meeting workspace

Posted in Sharepoint by Abhishek Bhowmick on November 10, 2010

A meeting workspace with recurring calendar dates and clicking on each date shows up the web part information pertaining to that date. So the web part in a particular date will not show the information as in another date if the source list is not manually edited like in the other from being in the date where we want to show it. The requirement here is to show all the web part information consistently across all recurring dates.

To do this, we must create the list as Series Items enabled.  We may follow steps below in order:

  1. Open your web browser and navigate to your SharePoint meeting space.
  2. Click on the Site Actions button (located near the top-right corner) and select Create from the drop-down menu.
  3. Under the Tracking header, click on Tasks.
  4. Enter your task list information and ensure that you have the checked Yes in the box marked change items into series items. This will convert the task list into a series task list that will be present during all meetings that are using this SharePoint meeting space.
  5. Click on the Create button to finish creating a series task list.

    Note: The new web part will be added to your meeting space page. To make changes to its appearances and location on the page, use the Edit function which can be accessed from the Site Actions button.

  6. This will create the list and automatically add a list view web part for the list as a series item which will show the information available in the list across on all recurring dates.

SPD Workflow won’t deliver email to document library contacts

Posted in Sharepoint by Abhishek Bhowmick on October 28, 2010

Workflow designed in SPD with a logic to send emails to email-enabled document library contacts does not get delivered but the workflow can successfully deliver email to a normal mailbox as in abhishek.bhowmick@xxx.com.


Upon investigation we learned that the email originated from SharePoint sender (SharePoint Communication – in our case) will not deliver email to SharePoint email addresses.  The emails must generate from a non-SharePoint email sender for this to work.  This is a known issue with SharePoint and is identified in the following KB article.

Please refer http://support.microsoft.com/default.aspx?scid=KB;EN-US;970818.  This functionality is unavailable in SharePoint.

Display SharePoint timings as per your local time zone

Posted in Sharepoint by Abhishek Bhowmick on October 4, 2010

Have a SharePoint site being used by people across the globe and there are issues with timings not converted to their respective time zones? Here is the answer.

These steps need to be followed in order…

 

 

Note that this is not a server level change but is a change in the user’s personal settings which would not impact all users. So every user needs to make this change at their end to display all timings automatically converted to their local time zone.

Using a Contact Selector/People Picker in an InfoPath Form

Posted in Sharepoint by Abhishek Bhowmick on September 9, 2010

Using the People Picker functionality in InfoPath 2007 that SharePoint 2007 supports natively.

Procedure:

Note that the example below assumes you are using InfoPath 2007 and that you have access to a SharePoint server.

Create a new form in design mode


Open the task pane by clicking View >> Task Pane in the toolbar.


Select Controls in the Design Tasks window


If you do not see the contact selector under Custom you will need to add the ActiveX control for the first use. Scroll to the bottom and select Add Remove Custom Controls.


Select Add or Remove Custom Controls… and the custom controls window will appear. Select Add.


Choose ActiveX Control



Do not include the cab file


Select Value in the bind to property


Select Field or Group in the Specify Data Type Options screen


Now that we have successfully added the contact selector to your available InfoPath controls let’s go ahead and add the control to our form


Now comes the most critical part but if you follow the steps perfectly, you should be result with flying colors. We are required to create a data structure with the following schema which a contact selector expects somewhat like the below to bind the control to where the data is stored. However, please keep in mind that they are all case sensitive.


Go back to the Design Tasks and select Data Source


Right click under myFields and select Add


Type in the Name as gpContactSelector and select the type as Group. Ensure that this group is NOT a repeating group. This will act as the parent group to which the Contact Selector control will bind to. Click Ok to Add.


Now right click gpContactSelector and click Add.


Type in the Name as Person and select the Type as Group. Make sure this is a Repeating type group. Click Ok to Add.


Now we will add the String type Fields attributes (DisplayName, AccountId, AccountType) under Person. Make sure you keep right clicking the Person group field and select Add for all three string type Fields else the schema would mismatch and the functionality will work.


Type in Name as DisplayName and select Type as Field (element) and Data type as Text (string). Leave the Default value as blank. Ensure this is NOT a Repeating type group and the option Cannot be blank (*) is unchecked. Click Ok to Add.


Type in Name as AccountId and select Type as Field (element) and Data type as Text (string). Leave the Default value as blank. Ensure this is NOT a Repeating type group and the option Cannot be blank (*) is unchecked. Click Ok to Add. AccountId (note the “d” is lowercase)


Type in Name as AccountType and select Type as Field (element) and Data type as Text (string). Leave the Default value as blank. Ensure this is NOT a Repeating type group and the option Cannot be blank (*) is unchecked. Click Ok to Add. AccountType (note the “T” is uppercase)


Once all the three as above are done, you data structure would look like as below


We are almost done and we will now add the Contact Selector control to the InfoPath form body thus binding it to the gpContactSelector (non-repeating type group). To do this just right click and hold on gpContactSelector group and drag it to the body of the form and release the click. It should present you with the following list of menu as below. Select Contact Selector and we are done.


Once the control is added to the form, it should look something like this.


Now for the last step, we will need to configure a secondary data source for the server context. We will first need to create an XML file called Context.xml as required by the contact selector.

Open Notepad and type in the following: <Context siteUrl=”https://sharepointserver”/&gt;. You may replace the sharepointserver with your server name or name of the web application where your SharePoint site is hosted. Note that this is case sensitive and the syntax should be absolutely identical. Save the file to your local hard drive as Context.xml (case sensitive)


Now we will need to add this file as a Data connection to receive data. To do this go back to your InfoPath form and click on Tools >> Data Connections.


Add a new data connection to receive data


Select XML document


In the XML data file details window select Resource Files and add the Context.xml document you previously created on your local drive.


Leave the name as Context


Complete the Wizard


Your form is now all set to be published. Please note you will need to publish the form template as browser enabled to your SharePoint form library and allow the option to open as web page in the form library advanced settings as below.


Common errors to be avoided at all costs:

  • Remember that the data source for Context is receive.
  • Make sure the Context.xml is well formed (the context tag must have an end tag)
  • Make sure the data source is named Context
  • Make sure you spelled all of the field names correctly
  • Make sure that the person field is repeating
  • Validate the binding of the contact selector control, it should bind to the parent of the Person group
%d bloggers like this: