SharePoint 2013 eDiscovery – Programmatically creating a Case, Discovery Set and Sources

I have looked around for examples on how to use the eDiscovery APIs and have found the object model information, but could not locate any source code to help guide me on what I needed to do in order to create a new case, new discovery set or a new source. Below I have provided some code I have used in a sample console app to do these activities.

First, create a new site collection using the eDiscovery Center Site Template. I assume you know how to create a site collection and select a template using central admin and/or PowerShell, so I will not get into that here in this post. If you need help creating a site collection, please refer to http://technet.microsoft.com/en-us/library/cc263094(v=office.15).aspx.

You will want to get a reference to the Microsoft.Office.Policy.dll which is located in 15\ISAPI folder. Add a Using reference for Microsoft.Office.Server.Discovery as well.

In code you will need to gain reference to the site collection which was created above. This is done as I provided below.

CreateSite

Technically you can create the site collection in code as well if you prefer, just as long as you get a reference to the site in order to create the case which is what we will do next.

In order to put something on hold in an eDiscovery Center site, you have to create a case. A case is sub-site created under the eDiscovery Center site with the eDiscovery Case site template (EDISC#1). In code this is pretty straight forward as creating any other SPWeb in code as you can see below.

CreateCaseWeb

Once you have created and/or gained reference to a case (which is an SPWeb object), you will need to create a Case object from it.

CreateCaseObject

Next is creating a Source object. A Source object is the information and data you will be putting on hold. This could be a SharePoint source location, which is considered a type of “Location” or a mailbox which is considered a type of “Mailbox”. You have to create the source from the Case object using either the CreateLocation() or CreateMailbox() methods. You can see the code below in which the Source object is created.

CreateSource

 

 

 

As you can see there are some additional properties being set as well. I will explain them here…

The Name property is just setting the name of the source as you will see it in SharePoint. The source is entered into a SharePoint list as a SharePoint list item and the name is what you will see as the source when looking at the case in the SharePoint site.

The WebId and SiteId properties are what tells the source which SharePoint location is the target. You can further refine the source using specific search query, however this code is putting an entire site on hold and I don’t have any additional search queries defined.

The FederationId is the GUID for the search result source where the content of this source is stored. If the location which is being put on hold is in another Result Source, you will have to specify that result source ID. For PowerShell code to get this Id, you can run the following to get the list of examples which will get you the Local SharePoint Results.

get-help Get-SPEnterpriseSearchResultSource -example

When you have set all the properties for the Source object, you must call Update() to save those changes.

Once you have a Source object created, you have to create a Source Group. In the browser this is referred to as a Discovery Set. The Discovery Set (or Source Group) contains the Source or Sources which are to be put on hold for that particular discovery. The following code creates the SourceGroup object and adds the Source from above to it, then starts the process to place them in a hold.

CreateSourceGroup

 

As you can see in the code the Source Group is created from the Case object and the Source created earlier is added to the Source Group. The Name property represents how you will see it displayed in the browser when looking at the site.

The Preserve property is what will set the content on hold. When setting this to true and calling the Update() method, it will start the process to gather the information provided by the sources and process them to put them on-hold. This process takes a few minutes to process depending on the number of items being placed on hold.

I hope this helps provide insight into using the eDiscovery API to create and manage cases in SharePoint programmatically.

Microsoft.Office.Server.Discovery namespace:
http://msdn.microsoft.com/en-us/library/office/microsoft.office.server.discovery(v=office.15).aspx

Posted in 1 | Tagged , | 2 Comments

SharePoint 2013 – Site Collection Upgrade with Site and Web Scoped Feature Upgrading Events

In recent weeks I have been working on explaining Feature Masking and Feature Upgrading and ran into something I would like to share.

When I was testing feature upgrading with setting a master page when a site collection is upgraded from SP2010 mode to a SP2013 site collection I was doing so based on a feature which is scoped at the web level. The one thing I noticed is that when I did the same test regarding the master page but using a site collection scoped feature it behaved differently.

What happens is that during the process of a site collection upgrade, the site collection features are upgraded, then SharePoint provisions and applies the OOTB seattle.master, then the web features are upgraded.

If your master page in SP2010 was deployed via a site collection scoped feature and you are trying to use the process to update the master page to a SharePoint 2013 version upon site collection upgrade as I explained in a previous post you will notice when the upgrade is complete you will be set back to seattle.master.

Right now the workaround is either to deactivate and reactivate the master page feature to reset your custom master page on the site or move your site collection scoped feature to a web scoped feature prior to upgrade.

Posted in 1 | Leave a comment

Automatically Update 2013 Master Page during Site Collection Upgrade using Feature Upgrading Event

Most if not all of us in SharePoint 2010 created custom master pages and designs for portals, team sites, etc. Now all that work not only has to be re-done to fit the new SharePoint 2013 look and feel and new functionality, but has to be reset once you do a site collection migration.

When you do a site collection migration from a SharePoint 2010 mode site collection to a SharePoint 2013 mode site collection in SharePoint 2013, the process will reset the master page of the site collection to the default master page. Imagine if you have 1,000’s of site collections, now you have to write scripts to update all these.. now imagine you are on a SharePoint Online Dedicated environment, where you do not have access to run scripts to update them in bulk.. It would be very difficult to do this manually.

This is where we go back to SharePoint 2010 and Microsoft introduced Feature Upgrading. Although at the time this new process was not widely adopted as people still never versioned their features no matter how many updates they applied to them… BUT this is the perfect process for handling the application of a SharePoint 2013 master page when a site collection is upgraded from SharePoint 2010 mode to SharePoint 2013 mode. This is because as part of this site collection upgrade process, it will also trigger a feature upgrade of every feature which is activated on the site or web.

Since you have to redevelop a SharePoint 2013 version of your master page and should be using feature masking to support that “Branding” feature which is activated in SharePoint 2010 to also be activated as a SharePoint 2013 feature. More information about Feature Masking can be found in my previous blog post:

https://wollerman.wordpress.com/2014/05/20/upgrading-custom-list-definitions-when-migrating-from-sharepoint-2010-to-sharepoint-2013

From this point I will assume you know how to migrate / mount a SP2010 content database (mount-spcontentdatabase 🙂 ).

The first thing is feature masking.. you have a farm solution for SharePoint 2010. In my case it is called MasterPage-SP2010.wsp. This solution has a web scope feature which deploys the master page and sets it as the current master page using the feature activation event receiver. This is nothing new, so I expect you know how to do this as well.

The second part of this is to support feature masking I created a SharePoint 2013 version of the solution called (you guessed it!) MasterPage-SP2013.wsp. In order to support feature masking I followed all the same rules defined in the previous blog post regarding the feature folder structure, feature name and feature ID needs to be the same as the feature in which I am masking from SharePoint 2010. See screen shot below (MasterPage-SP2013 on the left and MasterPage-SP2010 on the right).

FeatureUpgradingComparison-01

Now that feature masking is configured the site collection will have a feature of ID “b3add9ff-ee85-453b-80e3-2699b7da4e5d” in the “Activated” collection associated with the 14 hive (SP2010), when upgraded it will still associate with that same feature ID but now be linked to the 15 hive (SP2013). The difference is there is a different assembly which is associated with the SharePoint 2013 solution, which has additional logic to set the master page.

First in the SharePoint 2013 solution, you must include an <UpgradeActions> element. This element defines the event receiver class to run in order to execute the event of FeatureUpgrading. Within this Upgrade Actions element, you define a <VersionRange>. Since most of us never put a version on our SP2010 features, it is assumed to be a version number of 0.0.0.0. So we would need to define a version for our SharePoint 2013 feature and set the range from 0.0.0.0 to that version (in my case I set it to 1.0.0.0). You can see the example below from my test projects where I defined the upgrade actions in my feature.xml file. You will have to do this manually as this is not part of the GUI.

FeatureXML

I have included the FeatureUpgrading event code within the feature receiver file I used for activating and deactivating. In order for the upgrade event to fire, you need to specify the “<CustomUpgradeAction Name=”MasterPage2013Upgrade”>” Element in my upgrade action. Since I was just doing this one thing, I originally left this out since it is not required, however I realized my code was not being executed unless I had this defined in the XML. I also added a check in the code to make sure the upgrade action I am executing was indeed the “MasterPage2013Upgrade”, which you can see below.

FeatureUpgradingCode

The one thing which you have to watch out for when creating a module to deploy the master page to the site is where you plan on putting it in the master page gallery. For the most part up until now, we all put our custom master pages in the root of the master page gallery. Now in SharePoint 2013, you have to put it in a sub-folder. If you try to put it in the root of the master page gallery the code or the execution won’t break, however you will not see the master page in the gallery from the browser window. You can however see it if you look at the gallery through SharePoint Designer. This is not ideal as the file is not versioned or has a content type applied to it.

You will need to also add in the Type=”GhostableInLibrary” attribute as well if you want the document to show up in the library.

You can see how I defined my modules folder below…

Modules

After all this the key things to remember are to specify a CustomUpgradeAction Name and make sure you push the master page file to a sub folder of the master page gallery.

After all is said and done you should have 2 WSP’s.. One for SP2010 and one for SP2013. You must deploy these via PowerShell and when deploying these WSP’s you must remember to use the “-CompatibilityLevel” Parameter when using both Install-SPSolution and Uninstall-SPSolution.

Hope this helps.

Posted in 1 | 1 Comment

Upgrading Custom List Definitions when migrating from SharePoint 2010 to SharePoint 2013

I have run into this a couple times and have not seen much information posted regarding upgrading custom list definitions when migrating from SP2010 to SP2013, so I wanted to share my experience in a test I did.

The process I define below is using “Scenario #3 – Feature Masking” in the MSDN article I posted about earlier: http://technet.microsoft.com/en-us/library/dn673579.aspx

I had a SP2010 Farm Solution which had a site feature which “deployed” my custom list definition to my team site, which I then can create list instances from. I did this while in SP2010 as you can see here in the following screen shot.

SP2010ListDefinitions

I am not including the steps to backup/move/restore/mount databases for a migration. This is more about how a list definition is upgraded.

At this point I just deploy my SP2010 customization to my SP2013 environment to support the mounting of my content database so it doesn’t spew errors and warnings saying I am missing a solution / feature. I have my SP2010 solution deployed using the command…

Install-SPSolution -Identity splistdefinition-lib.wsp -CompatibilityLevel 14 -GACDeployment

“-CompatibilityLevel 14” is the important part of that command and details as to why is outlined in Scenario #3 in the MSDN article (see link above).

As you can see the solution has deployed the feature to the 14 hive on SP2013 and not the 15 hive because it is a SP2010 WSP Farm Solution

SP2010SolutionDeployed

This will allow me to mount my database and open the site and basically see the same thing in SP2013 as I did in the previous screen shot since the site is running in SP2010 mode.

SP2010ModeSite-NoUpgrade

To explain my point as to SP2010 custom list definitions not upgrading to the SP2013 list functionality upon upgrade of a site collection, I will upgrade my site collection prior to installing my SP2013 version of the WSP Farm Solution. Below is the screen shot of how the site has been upgraded to SP2013 and the lists still look like SP2010 lists. This is because of the “Fall back” compatibility. Since it cannot locate the feature in the 15 hive, it falls back to the 14 hive feature, giving you the same SP2010 look and feel.

SP2010ModeSite-AferUpgrade

Since SP2013 changed the look and functionality of SharePoint list and library views, the SP2010 views really stand out when they are not upgraded. In order to get these lists updated, you will have to create a SP2013 version of those list templates. The rules as to how the solutions have to be different in Solution Name and Solution ID, but the same as in Feature Names and Feature ID’s can be found in the MSDN article (see beginning of this post).

Once I have the SP2013 version of my solution, I deploy it the same as I did my SP2010 version however when I install the solution I use -CompatibilityLevel 15 (you guessed it, because this is a SP2013 solution … 🙂 ) Here is the command…

Install-SPSolution -Identity splistdefinition_13.wsp -CompatibiltiyLevel 15 -GACDeployment

After this is deployed you can see the same feature is defined in the 15 hive now. This means the site feature will find it in the 15 hive and not have to “Fall Back” to the 14 hive.

SP2013SolutionDeployed

After this is installed, going back to my SP2013 site I can see my lists now look like they belong in SP2013.

Sp2013SitewithSP2013Lists

The biggest thing is to make sure you follow the instructions outlined for feature masking in the MSDN article I posted above. You have to make sure certain things like feature name, Feature ID and Solution structure are the same between the two solutions. If they are not you will get errors when you try to deploy them side by side. If the solutions are built properly you will not have an issue deploying them as long as you use the -CompatibilityLevel parameter to define which mode the solution is targeting.

I hope this helps someone. Thanks.

 

 

Posted in 1 | Tagged | 1 Comment

SharePoint 2010 Customizations Upgrade Guidance to SharePoint 2013

I had the pleasure of getting involved in the review process for this documentation. Please check out the following MSDN article which outlines 3 scenarios to support the upgrade of full trust code (farm solutions) customizations / SharePoint solutions from SharePoint 2010 to SharePoint 2013.

http://technet.microsoft.com/en-us/library/dn673579(v=office.15).aspx

This link also leads to a discussion about using the feature upgrade framework to assist in re-application of SharePoint 2013 master pages since after a site collection upgrade the site will be transferred back to the SharePoint 2013 OOTB master page. The feature upgrade framework can be used in conjunction with feature masking (see scenario #3 in the link provided above) to trigger code to re-apply SharePoint 2013 master page assets to the site.

Posted in 1 | Leave a comment

SharePoint Hosted Apps – Deployment Options

SharePoint 2013, as we all know by now, has the ability to install and use “Apps”.  We should also know by now one of the types of apps is called a “SharePoint Hosted App”. This is pretty self explanatory as to where it will be deployed and live as the app is installed and used across the organization.

I have seen many diagrams / screenshots explaining how a SharePoint Hosted App is deployed, where it lives and how it interacts with it’s surroundings. These are great if the targeted environment will be a single web in a single site collection using a single app. What about real world environments, where there are multiple site collections, multiple webs and multiple apps being used?

I have started working on trying to explain this in diagrams to highlight where these pieces are and what the 2 options are for deploying SharePoint Hosted Apps. What? have not heard of the 2 options. Well everyone knows about the main option, where the user installs the app on their web and it runs in isolation to that web. The other is when it is deployed globally into the App Catalog site and then deployed out to the environment. The second option is not discussed much. Some talk about it in terms of “App Stapling” as you can see in Richard diZerega’s Blog Post: SharePoint 2013 App Deployment through “App Stapling” (http://blogs.msdn.com/b/richard_dizeregas_blog/archive/2013/03/04/sharepoint-2013-app-deployment-through-quot-app-stapling-quot.aspx).

I am not here to discuss the details on how to do it, you can read and learn that from Richard’s link above. What I am here to do is show a view into when an app is deployed in each manner, from a more realistic enterprise view.

#1: App is installed by users in many site collections / webs

SharePointApps-Isolated

As you can see the same app (SPApp1) is installed in many locations by many users which creates an AppWeb under the location of the host web in which it was installed. The host web can be a root web in a site collection or it could be a sub-web anywhere down the hierarchy. I have only showed a sub-web 1 level deep here, but you can imagine based on your organization structure and site collections how installing a single SharePoint Hosted App can add to your environment. Now, I am not saying this is going to disrupt your performance or overflow your capacity management governance plans (this is another discussion all together), but it is something to think about when you are an organization which has 1,00’s of apps and 1,00’s of site collections and 1,00 of webs.

#2: App installed (not uploaded) in the App Catalog Site Collection and Deployed out to site collections

SharePointApps-AppCatalog

Now you can see with this deployment, All the sites/webs refer back to the App Catalog App Web. Even though this is convenient, it may cause issues depending on the app as everyone utilizes the same app web, which is typically where your pages, content and logic is stored… meaning everyone is using and saving to the same “storage location”. Whereas in the isolated mode, everyone who has installed the app is using the pages, content and logic all to themselves “Isolated” from others who have also installed and using the app.

“App Stapling” may be a term coined by some people to replicate / replace / offer an option to old school “Feature Stapling”, I am not debating this… I simply want to show there are 2 options and what they look like across a greater sub-section of an environment. You as the developer, App Catalog Admin, SharePoint Architects (in those larger organizations) and/or end users should realize the benefits and value of having these options and utilize them accordingly depending on what the app is developed to accomplish.

More to come…

 

 

 

 

Posted in 1 | Tagged , , | Leave a comment