Category Archives: Windows Share Point

Windows Share Point

Webinar on 10/19/2011 at 2pm Eastern – Using SharePoint Designer in the ‘Real World’

This is a good opportunity to get free webinar by someone like Asif Rehmani. Following is the detail of the event as received.

See more at


SharePoint Automation – Power Shell Scripts


How often I think about PowerShell Scripts while working on SharePoint 2007 and deploying solutions using Stsadm. Though, it worked well for me, but never got control as promissed by the powershell scripts.

Recently, I got chance to start working and ext exploring my experiences with PowerShell Scripts for deployment of SharePoint 2010 solution and doing a lot with Microsoft .Net object model siting outside Visual Studio and working in colorful Power Shell Snap In 🙂

Today, I’m gonna share a piece of work that we (SharePoint developers) needs to deal with almost in every SharePoint project, and that’s the deployment of SharePoint Solutions. You may find the contents of this post on google, but I tried to keep things simple and planned.

First of all, for those who are new to Power Shall, you may be wondering about the Commands that you can use with power shell. I use a better way to keep them with me, try the following command in Power Shell to dump all available SharePoint commands in a text file.

Get-Command -module Microsoft.SharePoint.PowerShell > textfilename.txt

Once You have all the commands, its easy for you to go and explore commands based on your requirements, I would say the Get-help is really helpful here 🙂

Now let’s play with Power shell and deploy our Solution files for the SharePoint Farm.

Lets take the case where we have some solution files, and we want to write a script that will Add and deploy solution files to specified Farm or Web.
To make it clean and dynamic I use a xml Configuration file for deployment.

<Solution Name=”Usman.SP.Projects.Utilities.wsp” Path=”C:\Users\afzalu\PS_Scripts\Installer\Usman.SP.Projects.Utilities.wsp” CASPolicies=”false” GACDeployment=”true”>    </Solution>
<Solution Name=”Usman.SP.Projects.Branding.wsp” Path=”C:\Users\afzalu\PS_Scripts\Installer\Usman.SP.Projects.Branding.wsp” CASPolicies=”false” GACDeployment=”true”>    </Solution>
<Solution Name=”Usman.SP.Projects.Core.wsp” Path=”C:\Users\afzalu\PS_Scripts\Installer\Usman.SP.Projects.Core.wsp” CASPolicies=”false” GACDeployment=”true”>    </Solution>
<Solution Name=”Usman.SP.Projects.Pages.wsp” Path=”C:\Users\afzalu\PS_Scripts\Installer\Usman.SP.Projects.Pages.wsp” CASPolicies=”false” GACDeployment=”true”>    </Solution>
<Solution Name=”Usman.SP.Projects.RequestHandling.wsp” Path=”C:\Users\afzalu\PS_Scripts\Installer\Usman.SP.Projects.RequestHandling.wsp” CASPolicies=”false” GACDeployment=”true”>    </Solution>
<Solution Name=”Usman.SP.Projects.WebStructure.wsp” Path=”C:\Users\afzalu\PS_Scripts\Installer\Usman.SP.Projects.WebStructure.wsp” CASPolicies=”false” GACDeployment=”true”>    </Solution>
<Solution Name=”Usman.SP.Projects.Presentation.wsp” Path=”C:\Users\afzalu\PS_Scripts\Installer\Usman.SP.Projects.Presentation.wsp” CASPolicies=”false” GACDeployment=”true”>
<Solution Name=”Usman.SP.Projects.Sites.wsp” Path=”C:\Users\afzalu\PS_Scripts\Installer\Usman.SP.Projects.Sites.wsp” CASPolicies=”false” GACDeployment=”true”>


For Now, I just take an example where I need to deploy the solution, but ofcourse with this design you can also do feature activation and other webapplication chnages (we will do that in some other post).

Now let’s see how easily we can add a Power Shell Script to add these solution to specific WebApplication or Farm

# add SharePoint Powershell snapin
add-PSSnapin Microsoft.Sharepoint.powershell
write-host “———————————————————-” -foregroundcolor Green
write-host “Deploying Soultions” -foregroundcolor Green


# Getting web.Config File

$configFile = $args[0];

if ([string]::IsNullOrEmpty($configFile)) { return }

[xml]$solutionsConfig = Get-Content $configFile

if ($solutionsConfig -eq $null) { return }

$solutionsConfig.DLW.Solutions.Solution | ForEach-Object{
[string]$path = $_.Path
[bool]$gac = [bool]::Parse($_.GACDeployment)
[bool]$cas = [bool]::Parse($_.CASPolicies)
$webApps = $_.WebApplications.WebApplication

#Add the solution

$spAdminServiceName = “SPAdminV4”
[string]$name = Split-Path -Path $path -Leaf
$solution = Get-SPSolution $name -ErrorAction SilentlyContinue
Write-Host “Adding solution $name…”
$solution = Add-SPSolution $path

#Deploy the solution

if (!$solution.ContainsWebApplicationResource) {
Write-Host “Deploying solution $name to the Farm…”
$solution | Install-SPSolution -GACDeployment:$gac -CASPolicies:$cas -Confirm:$false
else {
if ($webApps -eq $null -or $webApps.Length -eq 0) {
Write-Warning “The solution $name contains web application resources but no web applications were specified to deploy to.”
$webApps | ForEach-Object {
Write-Host “Deploying solution $name to $_…”
$solution | Install-SPSolution -GACDeployment:$gac -CASPolicies:$cas -WebApplication $_ -Confirm:$false
# Restarting the Service
Stop-Service -Name $spAdminServiceName
Start-SPAdminJob -Verbose
Start-Service -Name $spAdminServiceName

#Block until we’re sure the solution is deployed.

do { Start-Sleep 2 } while (!((Get-SPSolution $name).Deployed))
} #End of $solutionsConfig.Solutions.Solution | ForEach-Object
write-host “Solutions Deployed Successfully” -foregroundcolor Green

write-host “———————————————————–” -foregroundcolor Green

Sorry for Formating, but it takes too much time so I prefer sharing things rather than spending lots of time on formating.
Once you run the above code you will see a very informative Power Shell Window, that will show you all the deployment setps in a friendly way so your deployement team can really enjoy the deployment.
You can use the below code to uninstall and delete the solution files using the same XML file

# add SharePoint Powershell snapin

add-PSSnapin Microsoft.Sharepoint.powershell

write-host “———————————————————-” -foregroundcolor Green

write-host “Deleting Soultions” -foregroundcolor Green


# Getting web.Config File

$configFile = $args[0];

if ([string]::IsNullOrEmpty($configFile)) { return }

[xml]$solutionsConfig = Get-Content $configFile

if ($solutionsConfig -eq $null) { return }

$solutionsConfig.DLW.Solutions.Solution | ForEach-Object{

[string]$name = $_.Name

$spAdminServiceName = “SPAdminV4”

$solution = Get-SPSolution $name

# Un-Install Solutions


if (!$solution.ContainsWebApplicationResource) {

Write-Host “Un-Installing solution $name from the Farm…”

$solution | UnInstall-SPSolution -Confirm:$false



Write-Host “Un-Installing solution $name …”

$solution | UnInstall-SPSolution -AllWebApplications:$true -Confirm:$false


Stop-Service -Name $spAdminServiceName

Start-SPAdminJob -Verbose

Start-Service -Name $spAdminServiceName

#Block until we’re sure the solution is deployed.

do { Start-Sleep 2 } while (((Get-SPSolution $name).Deployed))


} #End of $solutionsConfig.Solutions.Solution | ForEach-Object

# Remove Solutions

$solutionsConfig.DLW.Solutions.Solution | ForEach-Object{


[string]$name = $_.Name

Write-Host “Getting uninstall solution $name…” -foregroundcolor YELLOW

$unInstallSolution = Get-SPSolution $name

$unInstallSolution | Remove-SPSolution -Confirm:$false

Write-Host “Solutoin $name… Removed” -foregroundcolor YELLOW




write-host “Solutions Deleted Successfully” -foregroundcolor Green

write-host “———————————————————–” -foregroundcolor Green

Authentication and Autherization in SharePoint 2007/2010: A Food for thought

Authentication and Authorization in Share Point

Authentication is process of challenging and approving user’s Identity, while Authorization comes after the authentication, where user based permissions, rights, and privileges are taken into account. Microsoft SharePoint Services 3.0, MOSS, and SharePoint Foundation supports security for user access at the Web site, list, library folder, and item levels2. This security is managed based on role based mechanisms where each user is able to perform specific operation and all levels based on his/her role, and this is achieved through Authorization process once the user is successfully authenticated by the underlying authentication mechanism.

Available Options

In SharePoint Services 3.0, MOSS and SharePoint Foundation, the Authentication is achieved mainly through following methods

1. Windows based Authentication, Including Active Directory Authentication (both Kerberos and NTLM protocols), anonymous and basic authentication. Authentication is done by underlying IIS.

2. Form based Authentication, which is implemented by the ASP.NET authentication provider model. SharePoint provides an LDAP membership provider which can talk to Active Directory, Active Directory Application mode (ADAM), Active Directory Lightweight Directory services (AD LDS). Forms-based authentication can also use the SQL Server provider included with ASP.NET. Forms authentication allows ASP.NET to perform the authentication for SharePoint Foundation, but In SharePoint Foundation, ASP.NET forms are supported only under claims authentication. A forms provider must be registered within a Web application that is configured for claims.

3. Claim based Authentication (SharePoint Foundation 2010), this new way of authentication facilitates by authenticating across widows based users, and non-windows based users, stronger real-time authentication, and delegating user identity between multiple applications. 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.

Above are the brief descriptions of available options for Authentication in SharePoint, to keep things simple and traceable I am omitting details because there could be a detailed discussion on each mentioned options.

How Windows Authentication works in SharePoint?

Now, let’s have a look how generally Authentication works in SharePoint.
1.  A client anonymously generates a request using his/her browser that initiates a connection to a SharePoint front-end server, which is handled by IIS with .NET through an HTTP GET request.
2.  If the zone is configured for anonymous access (such as for Internet scenarios), IIS continues to
process the request. Otherwise, IIS returns error 401.2 and requests authentication from the
client browser.
3.  The client browser receives the request and, depending on the zone and associated options,
authenticates the client. A common method is by prompting for a username/password, and
then passing an auth token back to SharePoint via IIS.
4.  IIS is waiting for a response in the HTTP conversation and accepts the auth token, and then
either authorizes or denies access. At this point, IIS passes the request to SharePoint through
5. If the requested page has a Web Part that needs to access the back-end SQL databases,
SharePoint authenticates with the SQL Server and accesses the databases. The nature of the SQL authentication varies with the configuration options. For example, you can configure SQL Server authentication or Integrated Windows authentication using NTLM or Kerberos.

NTLM mode of Authentication

More specifically if NTLM mode of Authentication is configured then Step 3 and 4 would be as follows
3.1 IIS rejects the anonymous request with a 401.2 error and sends back a request to authenticate with NTLM.
3.2 The client browser receives the request, creates the Authentication token that includes domain and computer name, and then sends the authentication token to IIS.
3.3 IIS accepts the details and sends an NTLM challenge to the client.
3.4 The client responds with the response to the challenge (auth token again), encrypted with the
password of the user.
4.1 At this point, IIS needs to talk to the domain controller. It sends the client’s user name,
challenge, and challenge response.
4.2 The domain controller retrieves the password hash for the user and compares t to the challenge
response, which was encrypted using the user’s credentials. If there’s a match, the domain controller returns a successful authentication to IIS, and IIS can talk to the client browser.

Kerberos mode of Authentication

In case, where Kerberos mode (Kerberos uses a ticket system that authenticates once and then authorizes through delegation) of authentication is configured then Step 3 and 4 would be as follows

3.1 The client contacts the KDC (Key distribution center) on the domain controller and requests a ticket for the SPN (service principal name) based on what the browser client sent as the hostname.
3.2 If the KDC locates a matching SPN, it encrypts the ticket and returns it.
3.3 The browser client creates the authenticator and sends it with the service ticket to the IIS
server, which in turn decrypts the ticket, determines identity, and checks the permissions
(access control list) on the requested resource to see if access is permitted.
4 If access is permitted, IIS, through the Web Application service, contacts the SQL Server and the
service requests a ticket for the SQL Server from the KDC.

Generally, Windows based Authentication mode is selected whenever your application is running on windows, where Active directory is already configured, this is the easiest way of authenticating in SharePoint.

Anonymous Access

Anonymous Access is a way of providing unregistered users to interact with SharePoint sites. For internal deployments and Intranet sites Anonymous Access is always discouraged. The possible scenario in which anonymous authentication should be considered is on public-facing websites – so that people can browse sites without having to create accounts. Anonymous access does not provide item-level control, prevents document authoring, and does not provide access to remote interfaces.

Form Based Authentication in SharePoint

The Forms-based authentication option is generally selected when an environment does not use Active Directory, or needs to support external access. Form based Authentication basically builds on top of ASP.Net 2.0 Membership concepts, where there is Member Ship Provider which defines interfaces for identifying and authenticating individual users, and a Role Manager, which defines interfaces for grouping individual users into logical groups or roles4.
The authentication is authorization is done by redirecting to custom pages developed in using login controls and/or custom controls and after getting user credentials a user identity object is created which is used to authenticate users based on their roles against custom data base (SQL) or Active directory users.

General Practices

For internal sites, one should disable anonymous authentication as it may prevent compliance with business’s accountability requirements and business policies. Windows authentication with the Kerberos protocol is most proffered where this is possible, as it offers better integration and ease of use.

Microsoft development kit for SharePoint

Is this Information helpful ? Please leave a Comment.

Understanding the differences between SharePoint Portal Server and the Windows SharePoint Services

This is not a fresh post, I found goggling on this topic, just throwing here to give proper and more easy searched tags. You will find the original link below.

Lately, Microsoft has been placing a much heavier emphasis on its SharePoint line of products. SharePoint will eventually take over the public folder functionality currently found in Exchange Server and Microsoft is also pushing to make SharePoint the file server technology of choice. Unfortunately, many of the people that I have talked to say that they find SharePoint to be confusing. What makes SharePoint even more confusing though is that it comes in two different flavors; the Windows SharePoint Services and SharePoint Portal Server. In this article, I will discuss the differences and the similarities of these two products.

If you are shopping for SharePoint products, the first difference that you are likely to notice between the two versions of SharePoint is the cost. SharePoint Portal Server tends to be a bit pricey. The retail price of SharePoint Portal Server with five client access licenses is $5,619. This price is the tip of the iceberg though. You must also figure in the cost of a Windows Server 2003 license, the Windows Server client access licenses, and the cost of the hardware that SharePoint will run on. SharePoint Portal Server also requires SQL Server. The software comes with MSDE (Microsoft Database Engine), which is a watered down version of SQL Server, but most organizations will have to use a full blown SQL Server deployment.

Furthermore, if you need additional SharePoint client access licenses, those licenses cost $71 per device or user. Since SharePoint is a Web based technology, it is conceivable that some organizations may make a SharePoint site available to external users or non employees over the Internet. In order to do so, you must purchase an external connector license. An external connector license sells for $30,000 per server.

As you can see, SharePoint Portal Server can be very pricey to deploy. In contrast though, the Windows SharePoint Services are free! Actually, they aren’t completely free. You still need a Windows Server 2003 license and the Windows Server client access licenses. Even so, Microsoft offers the Windows SharePoint Services as a downloadable feature pack for Windows Server 2003.

To put it into prospective, both SharePoint products require you to buy a Windows Server 2003 license and the necessary Windows Server client access licenses. After doing so though, you could deploy the Windows SharePoint Services at no additional cost, whereas deploying SharePoint Portal Server will cost you thousands of additional dollars in software licenses.
Windows SharePoint Services

Since the Windows SharePoint Services are so much less expensive than SharePoint Portal Server, I will talk about it first. As I mentioned earlier, the Windows SharePoint Services are downloadable as a free feature pack for Windows Server 2003. You can download the Windows SharePoint Services at Microsoft’s Web site.

The Windows SharePoint Services are primarily focused around workgroup level collaboration. The idea is that the Windows SharePoint Services can be easily deployed in a matter of minutes. Once the Windows SharePoint Services are up and running, it is simple to set up a workspace for a small group of users, with minimal effort. This allows a group of users to share a small collection of documents among themselves.

Even though small seems to be the operative word here, don’t be fooled. The Windows SharePoint Services can be scaled to support thousands of users and multiple terabytes of data. In fact, SharePoint Portal Server (an enterprise class product) is built on top of the Windows SharePoint Services.

The truth is that even though the Windows SharePoint Services are free, the Windows SharePoint Services are no slouch by any stretch of the imagination. While it’s true that SharePoint Portal Server offers features and capabilities that the Windows SharePoint Services don’t offer, the Windows SharePoint Services is a very powerful application.

When you install the Windows SharePoint Services, there is next to no configuration that has to be done. I have to admit that when I installed the Windows SharePoint Services on my test server, I didn’t take notes regarding the installation process, but I honestly can’t remember having to do anything other than accepting an end user license agreement. Once the installation was complete, Windows opened Internet Explorer and displayed the Windows SharePoint Services Web site, shown in Figure A.

This is what the Windows SharePoint Services Web Site looks like.

As I mentioned earlier, SharePoint Portal Server costs thousands of dollars while the Windows SharePoint Services are free. In order to understand what you are really getting for your money if you decide to invest in SharePoint Portal Server, you need to have a good idea of what you can and can’t do with the Windows SharePoint Services. Unfortunately, there is no way that I can talk about all of the Windows SharePoint Service features in a single article, but I will give you a brief tour so that you can see how SharePoint Portal Server differs.

If you look at Figure A, you will see that the Home page contains a list of announcements, events, and links. Each of these sections is made up of a separate Web part. A Web part is nothing more than a block of HTML or ASP code. In a SharePoint environment, multiple Web parts can be joined together to create a Web page like the one that you see in Figure A. In fact, you will notice in Figure A that there is a Modify Shared Page link directly above the Windows SharePoint Services logo. You can use this link to add additional Web Parts, remove unwanted Web Parts, or to rearrange the position of the Web parts on the screen.

What this means is that the SharePoint Web site is completely customizable. The reason why this is important is because the default Web site is usually only used in the smallest organizations. As you will recall, earlier, I mentioned that the Windows SharePoint Services were designed to allow small groups of users to share small groups of documents.

If a user were to click the Create link, they would be able to create a dedicated Web site for the group or the project that they are working with. The fact that SharePoint sites are nothing more than a collection of pre-defined Web parts means that when users create dedicated Web sites, they can custom tailor the new site to fit their specific needs. Furthermore, they can accomplish this without having to do any coding.

That being the case, you might be wondering what users can use these Web sites for. Well, if you go back to Figure A, you can get a bit of a preview. If you look in the menu bar on the left portion of the screen, you will see links for shared documents, contacts, tasks, discussions, and surveys. There is actually a lot more that users can do with the Windows SharePoint Services, but I don’t really have the space to talk about everything, so let’s pretend that these were the only options available.

To see how these particular Web parts are useful, imagine that you are working as a part of a team that’s assigned to develop a new product for your company. In such a case, you could start out by creating a contacts list containing contact information for everyone on the team. You could then go on to add contact information for parts suppliers and other non-employees that you might interact with as a part of the project.

You could then use the task list to assign tasks related to the project to various members of the team. The Discussion area is basically a message board that can be used to discuss specific issues related to the project. You could use the Pictures library to store blueprints or design ideas, while the document library can be used to store text documents.

The document library is one of the key pieces of SharePoint and is worth discussing for a moment. The idea behind the document library is that users can check documents in and out of the library. Essentially, what this means is that a user can check out a document, make changes, and check the document back in. This prevents users from making simultaneous, possibly contradictory changes to a document, but it does something else too. The document library allows you to retain multiple versions of documents. This way you can see who has made changes to a document and when. If necessary, you can even revert to a previous version of the document.

Another thing that the document library does is that it allows users to be alerted to changes. Users can be alerted immediately if a new document is added to the library or if an existing document is modified. If users don’t want to be bothered by constant change notifications, they can receive a daily or a weekly change summary message.

In case you are wondering, the Windows SharePoint Services does have built in user management. You can easily specify which users are allowed to create Web sites. When a user does create a site, they can decide who can access the site, and what level of access various users should receive to the document library and to other areas of the site.
SharePoint Portal Server

It’s impossible for me to talk about all of the capabilities of the Windows SharePoint Services because the application is so intricate. Hopefully by now though, you have a pretty good idea of what the Windows SharePoint Services are and what they are used for. Now, I want to move on and talk about SharePoint Portal Server. As I mentioned earlier, SharePoint Portal Server was built on top of the Windows SharePoint Services. This means that anything that the Windows SharePoint Services can do, SharePoint Portal Server can also do.

The main difference between the two applications is their focus and intended usage. As I have said numerous times in this article, the Windows SharePoint Service’s primary focus is to create workspaces that small groups of users can use to collaborate on projects by sharing a small collection of documents and other data. Certainly, SharePoint Portal Server can be used for this as well, but why spend thousands to do something that you can do for free with the Windows SharePoint Services?

The main purpose for SharePoint Portal Server is to act as an enterprise level portal. One of the areas where this is the most obvious is in SharePoint Portal Server’s ability to manage documents. SharePoint Portal Server’s document library is very similar to the one found in the Windows SharePoint Services. The main difference is that SharePoint Portal Server is designed to index huge numbers of documents that exist across multiple locations.

For example, you could start out by indexing all of the documents that exist on your company’s file servers. You don’t have to stop there though. You could also index the public folders on your Exchange Servers. If there are Web sites that your company frequently references, you could even index pages on those sites. It doesn’t even matter if the Web page is in secured by SSL. SharePoint can use the HTTPS protocol to index secure Web content.

The point is that large companies typically have huge amounts of information on file, and that information often exists in many different formats (Microsoft Office documents, PDF files, public folders, HTML, text files, etc.). What SharePoint Portal Server does is to make it possible for users to use a single search engine to search for information regardless of where the information is located and what format the information is in.

SharePoint Portal Server also differs from the Windows SharePoint Services in its ability to search document indexes. SharePoint Portal Server offers some very rich search capabilities. For example, users can search for specific key words and tell the search engine that they only want to search for items that have been added since their last search. The results of the search can then be arranged by document author, site, date, and category. SharePoint Portal Server also offers hierarchical search scopes that allow users to perform searches from within specific topics, categories, or content sources.
Similar names, but different

As you can see, there are many similarities between the Windows SharePoint Services and SharePoint Portal Server. Where the two products really differ is in that SharePoint Portal Server allows you to index the contents of huge numbers of documents, in a variety of formats, both inside and outside of your company. SharePoint Portal Server also offers advanced query tools that make it easier to locate specific content within a vast store of indexed content.

Original Link:Understanding the differences between SharePoint Portal Server and the Windows SharePoint Services