SharePoint Feature Management in PowerShell - Part 2

SharePoint Feature Management in PowerShell - Part 2

In this task, you will learn how to use the PowerShell commands to find GUID and other information about features in the SharePoint server.

In the course of many routine deployment and troubleshooting tasks, you will need to find the GUID that corresponds to a particular SharePoint feature. In previous versions of SharePoint products and technologies, this tended to be a long, complicated task. As a result, administrators would find themselves coming up with complicated strategies or resort to performing full-text searches of the Features folder on the file system. SharePoint Server 2013 provides a far more straightforward approach to this problem through Windows PowerShell.

To get a list of all the installed features in a SharePoint server farm, type the following command, and then press ENTER:

Get-SPFeature |more 

The console window provides a list of all the installed features in the server farm, together with an ID and scope for each feature.

       Note: The full returned list of –SPFeatures can be very long. Use the < |more> syntax to shorten the list until you press the SPACE button.

In addition to retrieving a list all the installed features in a server farm, you may want to retrieve a list of all the features that are activated to a particular scope.

To do this, you can add switch parameters to the Get-SPFeature cmdlet (Site, Web, WebApplication, or Farm).

Type the following command, and then press ENTER:

Get-SPFeature –Site http://intranet.contoso.com |more 

The console window shows a list of all activated features on the intranet.contoso.com site collection.

One particularly useful application of PowerShell for SharePoint Server 2013 administrators is PowerShell's built-in ability to parse SharePoint log files.

To parse a SharePoint log file, type the following command, and then press ENTER:

Get-SPLogEvent | Select –Last 10 

The console window displays the last ten messages that were written to the log files.

       Note: This command may take several seconds to complete.

The Select cmdlet can be used to limit the number of items returned from other cmdlets that return large numbers of results. As you work through the remaining exercises in this lab, you will see how to use this technique and others to create sophisticated filtering techniques to return specific information.

Create Site Settings and Properties 

In this task, you will explore how you can put these cmdlets to use in your SharePoint server farm to create sites and manage site setting properties using the Set-SPSite cmdlet.

In addition to retrieving information, the SharePoint snap-in for Windows PowerShell includes cmdlets that can set properties, create new items, and perform a wide range of other actions. Let’s start by examining the Set-SPSite cmdlet. You can use this cmdlet to configure a range of properties on a specific site collection.

Type the following command, and then press ENTER:

Set-SPSite –Identity http://intranet.contoso.com –SecondaryOwnerAlias CONTOSO\alexd 

1. To confirm that the site settings have changed, launch the SharePoint site’s Central Administration Web site. Click Start, then click SharePoint 2013 Products, and then click SharePoint 2013 Central Administration.
2. On the Central Administration home page, click the Application Management heading.
3. Under Site Collections, click Change site collection administrators.
4. On the Site Collection Administrators page, make the following changes:
5.  Change the Site Collection to intranet.contoso.com.
6. Verify that AlexD has been added as a secondary site collection administrator.

On a single, isolated SharePoint site, it may be faster to set the secondary site collection administrator through the Central Administration user interface.

However, let’s say you want to add a secondary site collection administrator to over two hundred (200) site collections. Rather than configuring hundreds of site collections individually in the Central Administration interface, you can use Set-SPSite to create a PowerShell script that loops through the site collections and change the site collection administrator on each one.

In the second part of this task, let’s take a look at to use Windows PowerShell to create new sites.

7. Switch back to the SharePoint 2013 Management Shell.
8. Type the following command, and press ENTER:

New-SPSite –Url http://intranet.contoso.com/sites/powershell –OwnerAlias 
CONTOSO\Administrator -Name "PowerShell Site" -Template STS#0 

       Note: If you do not specify a template in this step, you will be directed to a template selection page when you browse to the site. This particular cmdlet may take up to five (5) minutes to complete. To continue with this HOL and move to Exercise 2, open a new Windows PowerShell Management window.

9. When the command returns, switch to the browser window and browse to http://intranet.contoso.com/sites/powershell to verify that a new team site has been created at the URL. You may need to confirm your identity before accessing the site.

10. Optionally, you could also use the following cmdlet in Windows PowerShell sample to return a list of sites on http://intranet.contoso.com and confirm that the site has been added:

Get-SPSite http://intranet.contoso.com/sites/* 

In this article, you learned configure your SharePoint 2013 Windows PowerShell environment. You also learned the basics of retrieving information from the server farm and some of the basic, most commonly-used Get- cmdlets. You began working with feature management cmdlets in Windows PowerShell, and you also learned how to create site settings and set the site properties using Windows Powershell.

                                                                                                               ==>> KUMAR NUGALAPU

                                                                                                                         Senior Consultant

Windows Powershell With SharePoint Server 2013 - Part I

Windows Powershell With SharePoint Server 2013 - Part I

Using Windows PowerShell to administer a SharePoint Server 2013 environment. You’ll move onto exploring how you can use PowerShell scripting to administer your SharePoint Server 2013 farm, learn how to assign and create variables, and use the SharePoint object model from Windows PowerShell, and learn Windows PowerShell scripting techniques that simplify administration tasks in SharePoint Server 2013.

After completing series of this articles, you will be better able to: Find your way around the SharePoint 2013 Management Shell and interact with SharePoint Web applications, site collections, and sites. Use Windows PowerShell scripting techniques, such as pipes, filters, wildcards, and enumerations, for SharePoint Server 2013 administration. Explain how to create and assign variables and use the SharePoint object model from Windows PowerShell.

Technologies : Windows PowerShell, SharePoint Server 2013

Scenario: This article takes you through an introduction to using the Windows PowerShell in SharePoint Server 2013 Search user experience with emphasis on exploring the cmdlet interface, new features, configuration options, and customization of SharePoint Servers.

Getting Started and Setting up your SharePoint 2013 Management Shell Environment 

Connect to the Environment

Launch the SharePoint 2013 Management Shell. Click Start, then click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell. The SharePoint 2013 Management Shell command line window will open.

At the PS > prompt, type the following command and press ENTER:

Get-Command –pssnapin "Microsoft.SharePoint.PowerShell" |more

This command displays all the available cmdlets in the Microsoft.SharePoint.PowerShell 2013 namespace. Press SPACE to page down the list. As you can see, there are hundreds of cmdlets relating to a wide range of administrative tasks.

          Note: You can also type gcm as shorthand for Get-Command.

To get help and information on a particular cmdlet, you can use the Get-Help <cmdlet-name>  command. 

Type the following command, and then press ENTER: 

get-help Get-SPSite 

The console window displays information on how to use the Get-SPSite cmdlet. 

As you might have guessed, cmdlets that include the Get prefix return information. You can use these cmdlets to write information to the console, or to provide information to other cmdlets.

You can also use the Get-Help <cmdlet-name>-detailed OR Get-Help <cmdlet-name>-full command options to retrieve more detailed technical information on a specific cmdlet.

As some of these help files can be very long, remember that you can append < | more, and then click to any command if you want to page the command output.

Type the following command, and then press ENTER:

Get-SPSite –WebApplication http://intranet.contoso.com 

This command returns all the site collections that exist in the http://intranet.contoso.com Web application.

You can use the same approach to retrieve information at each level of the SharePoint architecture. For example, you can retrieve all the Web applications in your server farm, all the site collections within a specific Web application, or all the individual sites within a site collection. We will explore this concept in the next task.

Retrieving Information from the Server Farm 

The SharePoint snap-in for Windows PowerShell includes many straightforward cmdlets that can retrieve information from your SharePoint Server farm without requiring the ability to write sophisticated scripts. In addition to being invaluable tools for day-to-day administration tasks, the cmdlets are a starting point to learn Windows PowerShell. Some of these tasks include retrieving information from various sources so you can perform daily management tasks, such as a SharePoint server farm.

In this task, you will explore cmdlets that retrieve information from a SharePoint server farm.

When you’re not sure which cmdlet you need to perform a particular task, you can use the Get-Command cmdlet to find out what is available. Let's say you want to review which cmdlets can retrieve information from SharePoint Server 2013.

Type the following command, and press ENTER:

Get-Command Get-SP* |more 

The console window displays the names of all the cmdlets that start with Get-SP. The verb Get is common to all cmdlets that return information, and the noun prefix SP is common to all SharePoint cmdlets. The asterisk ( * ) is a wildcard character that returns any of a defined subset of all possible characters.

         Note: You can use the same approach to find cmdlets relating to specific areas of functionality.                      For example, <Get-Command * Service*> will return all service-related cmdlets.

Commonly Used Get Cmdlets 

Two of the commonly used Get cmdlets are Get-SPServiceApplication Identity and Get-SPServiceApplication – Select ID, Name.

Type the following command, and then press ENTER:

Get-SPServiceApplication | Select ID, Name 

The console window displays the ID and Name properties of each service application that is running in the server farm.

Let's say a review of the event logs identifies a problem with a Service Application, and provides a GUID of: < 66c958d1-d10a-4880-bfc3-8b2646b8e4cd >. You need to find out which of the current service applications is causing the problem to be able to fix it. Use the Get-SPServiceApplication – Identity cmdlet to find it.

Type the following command, and then press ENTER:

Get-SPServiceApplication –Identity 66c958d1-d10a-4880-bfc3-8b2646b8e4cd 

The console window provides details of the service application and identifies the corresponding IIS application pool with DisplayName, TypeName, and the ID of the service application

                                                                                                              ==>> KUMAR NUGALAPU

                                                                                                                         Senior Consultant

How to Create and Use Document Sets in SharePoint (Ex: A Folder doesn't allow to trigger any workflows.)

How to Create and Use Document Sets in SharePoint (Ex: A Folder doesn't allow to trigger any workflows.)

SharePoint stores documents in document libraries. There are folders to group different types of documents into a document library. But the problem is, it just provides a logical grouping, it doesn't provide any special attributes, metadata or object model to support the complete set of documents. For example, a folder doesn't allow trigger any workflows.

Does a folder allows to trigger any workflows ?

Solution:

In SharePoint 2010, there is a new feature called document sets which allows users to group different kind of documents under a single set. It also allows the defining of metadata, attributes and workflows on a document set. In this article, we will show you how to create and use document sets inside a document library. Before creating a document set, we need to ensure whether the Document Set feature is activated or not. To do so, go to Site Settings -> Site Administration -> Site Collection Features and Activate Document Sets feature.

In the document library, we need to add the Document Set content type. To do so, go to Library -> Library Settings -> Advanced Settings.

Select Yes in "Allow management of content types?" and click OK.

Now you will be able to see the Content Types section in the Document Library settings. To add the Document Set content type, click on "Add from existing site content types".

Select Document Set and click "Add" and then "OK".

Now browse the Document Library and click on New -> New Document Set.

In our case, we are going to create the 'quarterly reports' document sets which would hold every month’s salary report.

I have also uploaded three different reports inside the document set.

Next I create a new documents set for each of the second, third and fourth quarters of 2011 inside the library.

Now we can add workflows and/or metadata that relates to each Document Set.

                                                                                                              ==>> KUMAR NUGALAPU

                                                                                                                         Senior Consultant

                                                                                                    

Setting up Drop Off Library In Microsoft Sharepoint

Setting up Drop Off Library In Microsoft Sharepoint

The Drop Off Library was introduced in SharePoint 2010 and is still available in SharePoint 2013. Its purpose is to automatically route documents from a “dumping ground” (in the form of a document library) to the appropriate location (another document library) based on content types. The Drop Off Library and the destination library do not have to be in the same site or even in the same site collection.

As an example, an organization can put a Drop Off Library on each department’s site. After employees upload their expense reports and select the expense report content type, SharePoint will then move the expense report to the appropriate document library on the accounting department’s site. The employees never have to leave their own department’s site.

Before you begin, make sure you have created the necessary content types and assigned those content types to the destination drop off libraries. If you’re going to use the same content type across multiple sites within the same site collection, set up the content type at the top level of the site collection so that you only have to create it once. Similarly, if you’re going to use the same content type across multiple site collections, set it up in your content type hub (if you have one).

To start with, you must first activate the Content Organizer site feature on all the sites where you want to have drop off libraries (the dumping ground) and destination libraries.

1.      Site Settings > Manage Site Features > Content Organizer > Activate

Next, you will set up the Content Organizer Settings on all the sites where you will have a Drop Off Library.

2. Site Settings > Content Organizer Settings

Review the default options and change any that don’t fit your requirements. For example, if you want to allow documents to move to a library in another site (or site collection), you’ll need to mark the checkbox for Allow rules to specify another site as a target location.

Depending on your about folders in SharePoint, you may want to mark the checkbox to Create subfolders after a target location has too many items.  Try not to use folders in SharePoint, but one level of folders is my acceptable limit.

In case an employee uploads the same file multiple times, by default SharePoint will apply versioning. If you’d rather have separate files (think about your storage capacity), you can mark the checkbox for Append unique characters to the end of duplicate filenames. FYI, these are random characters and cannot be customized.

To ensure that documents uploaded to a Drop Off Library are routed in a timely manner, rule managers will receive an email when submissions do not match a rule or when content has been left in the Drop Off Library. The default is three days, but you can change that number to better suite your business needs. You can also specify who the rule managers are (individuals or groups).

After the Content Organizer Settings are to your liking, you will need to set up the Content Organizer Rules.

3. Site Settings > Content Organizer Rules

4. Click + new item to create a new rule.

Hopefully, when you created your content types, you put them into a unique group so that you can filter by that group here. If you didn’t name the content types the same on this site (or site collection) as the site (or site collection) where the destination library is, you’ll need to mark the checkbox for This content type has alternate names in other sites.

By default, there is one property-based condition started for you. You can complete it if you want to use conditions, or you can delete it if you don’t.

In the Destination box, enter the URL for the destination library. Alternatively, you can click the Browse button to locate the destination library.

If the content type has not been assigned to the destination library, you will see the error message The selected library does not have this content type.
 

When all the settings are appropriately configured, click OK. You will be returned to the Content Organizer Rules screen, where you can view existing rules or create a new one.

Now you’re ready to test your Drop Off Library.

5. Navigate to the Drop Off Library. (There will be a link to it on the Quick Launch.)

6. Upload a document.

You’ll notice that the document is checked out to you. Before you check it in, you need to select a content type for the document.

7. Mark the checkbox next to the item, click the Files tab above the ribbon, and click Edit Properties.



When the Edit Properties screen opens, you’ll notice a message in a yellow bar at the top.

8. From the Content Type dropdown, select the appropriate content type.

9. Click Submit.

The message Saved to final location will appear with a link to where the document was moved.

10. Either click the link to go the location, or click OK to return to the Drop Off Library.

                                                                                                              ==>> KUMAR NUGALAPU

                                                                                                                         Senior Consultant

Best Practices for Solutions in Microsoft SharePoint

1. Every customization must be Feature based solution. 

Doesn't matter if it’s a Webpart/Event Handler/InfoPath/Content Types or file system change. You can group the features together as solutions. Solution should have event handlers for "Feature activating" and "Feature Deactivated" events wherever applicable. Place the appropriate code in respective blocks. It’s a best practice to have un-installation module in place.

2. Be Descriptive: 

Ensure that all the features has a appropriate name, description, updated version number, optionally icons.

3. Follow the Four part naming or at-least Three part naming 

In Name Spaces, Solution names, and in the Target location of the solutions. Don’t just place them inside features folder, But create a four/three part naming folder for each feature and place the supported files inside. 

 for e.g., rather "statusreport", It would be more meaningful, if it is: Company.Sales.StatusReport.WebPart, Isn't it? This will avoid conflicts and provides better manageability.

4. Follow coding standards. 

Each and every Solution must be thoroughly evaluated line-by-line and tested in DEV, TEST and then moved to PROD environments. We will do the code review before moving to DEV even. Follow the coding standards(even in variable naming! Preferably PascalCase/camelCase) 

5. Avoid de-bugging solution in PROD environment. 

You can write your code in such a way, Errors are getting logged in to the Event Log / Custom Log file. Fix them in DEV at least. So that it would be easier for de-bugging.

6. We must not deploy debug mode assemblies 

In PROD - Remove all your Break-Points, and debug codes before packing for PROD. Make sure your code and packages are compiled in release mode.

7. Avoid any manual changes. 

All changes must be automated. Even a web.config changes should be scripted. Adding Configurable Properties to a SharePoint Web Part’s Tool Pane is preferable.

8. Pay more attention to the Documentation

Pretend like you are giving instructions to the Person who doesn’t know anything about the particular solution.

we need guides which should contain

• Solution abstract, flow, name and version number.
• Activities, configurations, packages, etc. that should be installed or performed before/after the package installation.
• Deployment steps: Detailed steps to deploy or retract the package.
• Unit Test: How to validate that the package is deployed successfully.
• provide the exact steps. 

9. Never deploy SharePoint DLLs 

Along with your WSP!!! –  what’s the consequences – You will damage SharePoint. How? Your different versions DLL’s from Development box will cause In-compatible operations with PROD SharePoint environment.

10. Never Modify SharePoint’s files in File system. 

If you must modify have a backup and make the change as solution.  E.g. Changing the Core.CSS file for branding.. If you Change the file, It may be overwritten when applying service pack. Never Modify SharePoint Databases!

11. Use WSP Builder Project Template 

Use Visual Studio 2008  – No Manual DDF files generation! Use Relative Links Whenever Possible.

12.  Maintain versions 

Along with change history in solutions.  The assembly version number should be as the solution version number and should be incremented (format V#.#.#).  So that we can do upgrade solution, which is faster than going through the complete cycle, it does only upgrade existing features.

13. Use version control system

Like SVN, CVS, TFS and keep all the related artifacts there.

14. Double check your Object disposals. 

use http://code.msdn.microsoft.com/SPDisposeCheck

15. Don't hard code the parameters 

In the code, But make them configurable properties.

16. Handle the exceptions properly. 

Use Try{} Catch{} Finally{} Blocks.

17. Use SPQuery instead of SPList.items when retrieving from Large lists/libraries.

18. Last but not least: Provide excessive comments, Summary in code wherever applicable  

E.g. Use summary on functions like this:
       ///  <summary>
       ///  Function's Summary
       ///  </summary>
       ///  <param Name="param1">
       ///  Why we need param1?
       ///  </param>
       ///  <returns>
      /// What we get from the function
       ///</returns>

Event Receivers

Event handling gives developer the ability to catch certain user actions in code and react programmatically.

Ex 1: It will not allow any user to delete any item in that list and user will get

         error message.

Ex 2: where the requirements are to store a bunch of files in a document library,     

         and then sync "published" files to another document library.

Ex 3: Event receiver to prevent files other than PDF from being uploaded to a

        document library. So when user tries to upload a file other than PDF they'll

       get an Error message in the window saying "You are allowed to upload only   

       PDF files".

The event receiver is attached to all document libraries of the site where the feature is activated.If you want to attach the Event Receiver to one single list you have to code this with a custom Feature Event Receiver.

Various Events in Event Receivers in Various Levels

The feature has the ability to add custom event handlers to sites, lists, items and content types in your portal. Portal solution needs to be dynamic, expect change and work seamlessly with the other systems in your environment.

Event Types

Here is a list of events that you can hook into:

·         Microsoft.SharePoint.SPWebEventReceiver : "Site Level"

SiteDeleted	Occurs after a site collection has been deleted.
SiteDeleting	Occurs when a site collection is being deleted.
WebDeleted	Asynchronous Afterevent that occurs after an existing Web site is completely deleted.
WebDeleting	Synchronous before event that occurs before an existing Web site is completely deleted.

WebMoved	Asynchronous after event that occurs after an existing Web site has been moved.
WebMoving	Synchronous before event that occurs before an existing Web site has been renamed or moved to a different parent object.

·         Microsoft.SharePoint.SPListEventReceiver : "List Level"

FieldAdded	Occurs after a field link is added.
FieldAdding	Occurs when a field link is being added to a content type.
FieldDeleted	Occurs after a field has been removed from the list.
FieldDeleting	Occurs when a field is in the process of being removed from the list.
FieldUpdated	Occurs after a field link has been updated
FieldUpdating	Occurs when a field link is being updated

·         Microsoft.SharePoint.SPItemEventReceiver : "List Item Level"

ItemAdded	Asynchronous After event that occurs after a new item has been added to its containing object.
ItemAdding	Synchronous before event that occurs when a new item is added to its containing object.
ItemAttachmentAdded	Asynchronous after event that occurs after a user adds an attachment to an item.

ItemAttachmentAdding	Synchronous before event that occurs when a user adds an attachment to an item.
ItemAttachmentDeleted	Asynchronous after event that occurs when after a user removes an attachment from an item.
ItemAttachmentDeleting	Synchronous before event that occurs when a user removes an attachment from an item.
ItemCheckedIn	Asynchronous after event that occurs after an item is checked in.
ItemCheckedOut	Asynchronous after event that occurs after an item is checked out.
ItemCheckingIn	Synchronous before event that occurs as a file is being checked in.
ItemCheckingOut	Synchronous before event that occurs after an item is checked out.
ItemDeleted	Asynchronous after event that occurs after an existing item is completely deleted.
ItemDeleting	Synchronous before event that occurs before an existing item is completely deleted.
ItemFileConverted
ItemFileMoved	Occurs after a file is moved.
ItemFileMoving	Occurs when a file is being moved.
ItemUncheckedOut	Synchronous before event that occurs when an item is being unchecked out.
ItemUncheckingOut	Synchronous before event that occurs when an item is being unchecked out.
ItemUpdated	Asynchronous after event that occurs after an existing item is changed, for example, when the user changes data in one or more fields.
ItemUpdating	Synchronous before event that occurs when an existing item is changed, for example, when the user changes data in one or more fields.

1. Security:

The assembly you deploy to the Global Assembly Cache(GAC) is running with full trust. Watch out for the following:

·         Denial of Service attack: 

If a user uploads 10000 items to a list, what is the effect it will have to

the systems your assembly uses.

·         SQL Injection attack: 

If a user attempts to insert SQL statements into a column of a list that your 

assembly uses to update a database, what mechanisms are you using to 

make sure the input is valid.

·         Cross Site scripting attack: 

What is the effect of adding script to a column that your assembly uses to 

update another area in SharePoint?

2. Performance:

Watch out for the following:

·         Load: What burden are you placing on your web front end servers to run the assembly each time an event occurs? Use performance counters to determine this.

·         Long Running Operations: Consider creating a custom SharePoint timer job. Kick off/ Schedule the Timer Job from the event rather than running all the logic inside the event. This will allow you to use the features of SharePoint to view whether the Timer Job ran successfully.

·         Sync vs Async Events: Synchronous events have to wait until your code completes before returning the page, whereas Asynchronous events show the page immediately.

3. Error Handling:

When using synchronous events and you decide to cancel an event, let the user know why the event was cancelled. For example, update a Task List with a message why it failed.

Log your errors so that you can determine what issue is occurring when your system is in production environment.

4. Connections: 

Cater for external systems being down when you are trying to connect to them. Don’t let your code / solution go belly up because you cannot connect to a database.

5. Bulk Operations:

The MSDN documentation mentions that event handlers will not fire when bulk operation is occurring. For example, when a new list is created, the FieldAdding event will not fire. 

Limitations of Event Handler in SharePoint

Strangely there is no “SiteAdding”, “SiteAdded” event. However, if you really need this event you could create a “feature” to accomplish this. Features in SharePoint have a “FeatureActivated” event, where you could perform an action on creation of a site.

Event Receivers vs Workflows - Decide Which One to Use

As SharePoint Event Receivers & SharePoint workflows has lot of similarities, Many people stuck on deciding which one to go with: Event Receiver or Workflow?

Main Differences Between SharePoint Event Receivers and SharePoint Workflows are:

1. Event handlers Can't be manually initiated - workflows can be initiated either automatically or manually.

2. Event Handlers can be Synchronous or Asynchronous - Workflows are always async (They executes after the operation)

3. In Event Receivers we can cancel the operation (such as add/update/delete) - But in Workflows its not possible.

4. Event handlers execute from a Particular WFE, So when some thing goes wrong in that WFE, It may end-up. But Workflow Jobs are robust and  can resume even after Reboots.

5. Usually Event handlers runs for short period - Workflows can be longer even for years!

6. There is no User Interface/user Interaction in Event Receivers - Workflows can have user interactions such as getting user input in Initiation forms.

7. As the Name indicates, SharePoint Event receivers are triggered by events like New Item Adding-Added, Updating-Updated, Deleting-Deleted, etc. - But Workflows triggered only on Creation/Change/deletion.

8. Event Receivers are created using Visual studio - Workflows can be via SharePoint user interface, SharePoint Designer, Visio or Visual studio.

9. Workflows leaves "Workflow History" logs which we can refer for debugging - Event handler doesn't do such.

10. Event receivers are better for large volume - Workflows are better for small amount of data.

                                                                                                              ==>> KUMAR NUGALAPU

                                                                                                                         Senior Consultant