SharePoint

I hate PowerShell, I hate o365 (more specifically o365 Groups / Outlook Groups), and I hate SharePoint in the Office 365 Tenant. 

I know that is a strong way to start off a statement on managing o365 Groups but after banging my head against the wall for too long around o365 Groups I can’t think of a more appropriate statement regarding my feelings for Microsoft’s new product line.  So let me break down my frustration and give a few insights.

I am going to start with my hatred of SharePoint.  First off, the platform is a pig and it is a bloated pig, but I am not going to get into that right now.  With Microsoft’s new direction for SharePoint in building other products on top of it such as o365 Groups or Planner, Microsoft is stepping in the world of SharePoint and making a muck of the SharePoint environment with other products that trample over the storage and URL-space of the SharePoint tenant.  So when you create an o365 Group or a Planner plan, then you have created a SharePoint site collection in the tenant that you don’t see in the dashboard or have direct control over the quota (without PowerShell). 

Moving into my hatred of o365 Groups.  Here is a product that Microsoft is building as a collaborative communication tool (what about Yammer) and they are encouraging users to create their own groups, but they have little governance on how the groups are created (and that is just coming in now).  One exciting thing about groups is that the users can create whatever they want… and guess what, it shows up in the GAL.  A user could effectively create a group saying “Union Formation Group” and what could the company do to stop it, they could create a lot of legal problems in the company instantly and there is no way to really stop it short of turning off Groups.  Keep in mind that these Groups use quota from SharePoint too.  Here is just another though on Groups, the name.  We have AD Groups, Azure Groups, o365 Groups, just group Groups, and where will this end.  Let’s stop using generic names for products (Word?) which causes so much confusion when using the Google to try to return information (“the Google” was not a typo, it is a being now).

Lastly, I am going to complain about PowerShell or more specifically the implementation of PowerShell and the documentation for the o365 Groups.  Microsoft’s documentation is scattered and not clear on top of the fact that when you search for “Office 365 Group” or “o365 Group” you get everything from groups about o365 to permission groups in SharePoint (back to naming).  Even when you find the documentation that shows things like optional parameters for the PowerShell it is very incomplete.  For example, many of the options that are available on “Set-UnifiedGroup” (did you notice that one?  All of a sudden an o365 Group is called a “Unified Group”) are available too on “New-UnifiedGroup” even though it doesn’t show up there in the documentation.  Here is another fun one, if you want to set the quota for the file storage, it is a SharePoint PowerShell command and does not involve the “Unified Group.”  My favorite of all, I was trying to interact with the “Description” field for the o365 Group but that is the “Notes” field in PowerShell, what the hell?  Why do you even use named properties when you change the meaning of the names or the names in the UI. 

Well, there was my rant.  I doubt there will be anything helpful, but if you want the complete current list of PowerShell parameters I have it below.  Please look back in a few weeks for some examples on connecting to PowerShell through C# to create a new Unified Group or whatever the hell Microsoft changes the name to next.

• New-UnifiedGroup
  
  • [-AccessType <Public | Private>]
  • [-Alias <String>]
  • [-AutoSubscribeNewMembers <SwitchParameter>]
  • [-Confirm [<SwitchParameter>]]
  • [-Database <DatabaseIdParameter>]
  • [-DisplayName <String>]
  • [-DomainController <Fqdn>]
  • [-EmailAddresses <ProxyAddressCollection>]
  • [-ExecutingUser <RecipientIdParameter>]
  • [-ExternalDirectoryObjectId <String>]
  • [-FromSyncClient <SwitchParameter>]
  • [-Language <CultureInfo>]
  • [-ManagedBy <RecipientIdParameter[]>]
  • [-Members <RecipientIdParameter[]>]
  • [-Name <String>]
  • [-Notes <String>]
  • [-Organization <OrganizationIdParameter>]
  • [-OrganizationalUnit <OrganizationalUnitIdParameter>]
  • [-OverrideRecipientQuotas <SwitchParameter>]
  • [-PrimarySmtpAddress <SmtpAddress>]
  • [-RecipientIdType <Unknown | ExternalId | Smtp | LegacyDn>]
  • [-RequireSenderAuthenticationEnabled <$true | $false>]
  • [-SharePointResources <MultiValuedProperty>]
  • [-SuppressWarmupMessage <SwitchParameter>]
  • [-ValidationOrganization <String>]
  • [-WhatIf [<SwitchParameter>]]
  • [<CommonParameters>]

What the hell Microsoft? Why did you decide to remove the ability for a user to logon as a different user in SharePoint 2013? It was there in 2010, but this feature is not there in 2013.

Microsoft's recommendation is to right-click on Internet Explorer and then select run-as and then enter your username and password. This is not a good option for most users and in our environment it is not practical. So to get this functionality back, we will create a SharePoint feature that is deployed at the farm level. There are some sites out there that detail this but there is one problem with all of them, they do not redirect the user back to the same site where they did the logout / login function. I have included the specific code to solve the problem but I am not including the details on how to create the feature. Once the feature is created add an empty element to the project and paste in the code below. The LogoffAndLogin() javascript function will get the current subsite and pass it in as a parameter to then allow the logoff webservice to redirect the user back to the original page after login.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <CustomAction
    Id="LoginScript"
    ScriptBlock="function LogoffAndLogin(){ if (typeof SP != 'undefined') { 	var siteCollUrl = '';SP.SOD.executeFunc('SP.js', 'SP.ClientContext', function(){var clientContext = new SP.ClientContext.get_current();var site = clientContext.get_site();clientContext.load(site);clientContext.executeQueryAsync(Function.createDelegate(this, function(){siteCollUrl = site.get_url();var fullURL = siteCollUrl + '/_layouts/closeConnection.aspx?loginasanotheruser=true&amp;amp;Source=' + siteCollUrl; window.location = fullURL;}))})} else { alert('An error occurred during the logoff process, please try again.');}};"
    Location="ScriptLink">
  </CustomAction>
  <CustomAction
    Id="LogInAsUser"
    GroupId="PersonalActions"
    Location="Microsoft.SharePoint.StandardMenu"
    Sequence="998"
    Title="Sign in as a Different User"
    Description="Sign Out and Login as a Different User">
    <UrlAction Url="javascript:LogoffAndLogin();"/>
  </CustomAction>
</Elements>

I have the code all in one line and I realize that it might be a bit difficult to follow. I have included the code broken out as multiple lines to help you follow what is going on.

LogoffAndLogin(){ 
	if (typeof SP != 'undefined') { 	
		var siteCollUrl = '';
		SP.SOD.executeFunc('SP.js', 'SP.ClientContext', function(){
			var clientContext = new SP.ClientContext.get_current();
			var site = clientContext.get_site();
			clientContext.load(site);
			clientContext.executeQueryAsync(Function.createDelegate(this, function(){
				siteCollUrl = site.get_url();
				var fullURL = siteCollUrl + '/_layouts/closeConnection.aspx?loginasanotheruser=true&Source=' + siteCollUrl;
				window.location = fullURL;
			}))
		})
	} 
	else { 
		alert('An error occurred during the logoff process, please try again.');
	}
};

This has worked well in our environment. This is a stupid problem that MS created, but this solution should work well to solve it. Good luck !!

Okay, so it has been a bit since I have posted anything, mainly due to that I have not anything notable to post.  This is not due to me not doing anything notable but that the things that I have done that were notable were proprietary and I did not feel comfortable disclosing in a public forum. 

So the problem that I was given was that when people landed on the root site within the root site collection of our managed path / application the user hit a page that was essentially blank.  From there they did not know where they should go and did not really know what they would be able to access.  So here comes a webpart that can help solve the problem.  What the goal of this webpart was is to create a security trimmed list of sites the user would have access at the root level.  I am not going to go through each and every step for creating a webpart but I will give some high level info since these are steps that I struggled with when creating the webpart.

1. So first off, when you are creating this webpart select the "Visual Web Part option" in the project type.
2. You MUST select DEPLOY AS FARM SOLUTION.  The sandboxed solution will not have access to the necessary objects needed for this webpart.  Specifically getting all site collections in a web application (managed path).
3. To start we will create two classes.  SiteLookup and SPSiteInfo. 
   
   

   SiteLookup

   using Microsoft.SharePoint;
   using System;
   using System.Collections.Generic;
   using System.Linq;
   using System.Text;
   using System.Threading.Tasks;
    
   namespace SPSiteListing.ListSPSites
   {
       class SiteLookup
       {
           private Boolean _EnableTrimming;
           private SPContext _Context;
           private string _CurrentUserName;
           public SiteLookup(SPContext context, Boolean enablePermissionTrimming)
           {
               _EnableTrimming = enablePermissionTrimming;
               _Context = context;
               _CurrentUserName = context.Web.CurrentUser.LoginName;
           }
           public List<SPSiteInfo> GetSites()
           {
               if (IsRootInApplication())
               {
                   var list = new List<SPSiteInfo>();
                   list.AddRange(GetSitesUnderCurrentWeb());
                   list.AddRange(GetSitesUnderManagedPath());
                   return list;
               }
               else
                   return GetSitesUnderCurrentWeb();
           }
           public  Boolean IsRootInApplication()
           {
               if (_Context.Site.RootWeb.Url != _Context.Site.Url)
                   return false;
               if (_Context.Site.WebApplication.Sites[0].Url != _Context.Site.Url)
                   return false;
               return true;
           }
           public List<SPSiteInfo> GetSitesUnderManagedPath()
           {
               var sites = new List<SPSiteInfo>();
               var applicationSites = _Context.Site.WebApplication.Sites;
               foreach (SPSite item in applicationSites)
               {
                   //you must set disable catching access exceptions to prevent sharepoint from catching it
                   item.CatchAccessDeniedException = false;
                   try
                   {
                       if (item.RootWeb.DoesUserHavePermissions(_CurrentUserName, SPBasePermissions.Open) || !_EnableTrimming)
                           sites.Add(new SPSiteInfo(item));
                   }
                   catch (UnauthorizedAccessException)
                   {
                       //The user does not have access to check their access.  So an exception will be thrown.
                       //This will not cause a problem to not do anything with it, since we are security trimming
                       //we do not want this one listed anyway.
                   }
               }
               return sites;
           }
           public List<SPSiteInfo> GetSitesUnderCurrentWeb()
           {
               var sites = new List<SPSiteInfo>();
               if (_EnableTrimming)
               {
                   foreach (SPWeb item in _Context.Web.GetSubwebsForCurrentUser())
                   {
                       sites.Add(new SPSiteInfo(item));
                   }
               }
               else
               {
                   foreach (SPWeb item in _Context.Site.AllWebs)
                   {
                       sites.Add(new SPSiteInfo(item));
                   }
               }
               return sites;
           }
       }
   }

   SPSiteInfo

   using Microsoft.SharePoint;
   using System;
   using System.Collections.Generic;
   using System.Linq;
   using System.Text;
   using System.Threading.Tasks;
    
   namespace SPSiteListing.ListSPSites
   {
       class SPSiteInfo
       {
           public string SiteName { get; private set; }
           public string SiteUrl { get; private set; }
           public string HTMLLink 
           { 
               get 
               { 
                   return String.Format(@"<a href=""{0}"">{1}</a>",
                       SiteUrl,
                       String.IsNullOrEmpty(SiteName) ? SiteUrl : SiteName); 
               } 
           }
           public SPSiteInfo(SPSite site)
           {
               try
               {
                   SiteName = site.RootWeb.Title;
               }
               catch (UnauthorizedAccessException)
               {
                   //since the user does not have access to get the title, we can do something
                   //here if we want with demonstrating that. but it isn't necessary
               }
               SiteUrl = site.Url;
           }
           public SPSiteInfo(SPWeb site)
           {
               SiteName = site.Name;
               SiteUrl = site.Url;
           }
       }
   }

4. So now that we have the classes written to get the data, we need a something to display the data in the webpart. To do that we will use the ascx file created already (just adding a ul with an id and a runat) and add some code in the page_load method.

   ASCX file

   <ul id="siteList" runat="server">
    
   </ul>

   ASCX code behind

   protected void Page_Load(object sender, EventArgs e)
           {
               SiteLookup query = new SiteLookup(SPContext.Current, true);
               foreach (var item in query.GetSites())
               {
                   var li = new HtmlGenericControl("li");
                   li.InnerHtml = item.HTMLLink;
                   siteList.Controls.Add(li);
               }
           }

So that is basically it. There are some details that are not covered in this post, but this should get you past the things that I struggled with when I created my webpart.

SharePoint is a powerful platform, but is SharePoint really anything without custom coding and is an out of the box solution worth the trouble?  The short answer is if you want a web based file share out of the box is fine…but if you need anything else, then plan on coding and jumping through a few hoops.

So what do you get out of the box?

• File sharing

• Basic (very basic) versioning control

• Change the background and the color

So when does coding being?  It begins when you want to change the “SharePoint” word or logo at the top left of the screen.  When it comes to SharePoint the thought of it as a CMS needs to go away and it needs to be thought of as a platform for development. 

SharePoint demonstrates its extensibility and need for custom development when it comes to utilizing functionality that is promised in the out of the box functionality but is not delivered.  One area that this is very apparent is with version control and retention policies.  Version control works well out of the box but it does not do anything with retention policies meaning that if you need to maintain the current version’s retention policy independent from the historical version’s retention policy custom code will be needed.

To accomplish this functionality there are five requirements.

1. A document library to hold the current documents.

2. A content type that can be used for the record with applicable metadata.

3. A record center with a record library to capture the versions.

4. The record center must be setup as a Send To location for the SharePoint farm.

5. Some code with an event receiver to capture the versions.

Using this methodology when a user begins the process to update a document the current version is immediately sent to the event receiver and based on the logic within there is a determination whether or not to archive.  The document is then sent to Send To location (the record center) which will handle the routing to the correct record library.  The record library can have whatever retention policies required by the documents applied.

Functionally there is only a few lines of code that are required for this to function:

 public override void ItemUpdating(SPItemEventProperties properties)
{
    SPFile file = properties.ListItem.File;
    string strOut = "";
    OfficialFileResult retVal = file.SendToOfficialFile(out strOut);
    string value = retVal.ToString();
}

However there is a bit more code that is required to make this a fully functioning option.  Click Here to see the full code (not including the installer for the feature).