Tag Archives: SharePoint Development

Adding an O365 Security group to the Site Collection Administrators group

Here is the scenario… you wish provision every site collection in your SharePoint Online environment so that a key group of staff, say for example your support staff, have Site Collection Admin access.  To provide centralised control of this group you want to define it and its membership outside the boundaries of your SharePoint Online environment. In this case you have two options, a Security Group or an Office 365 Group. In the case of a Security group there is no associated email address so people can’t mail to it and it doesn’t appear in the address book. This is ideal for the type of group we are creating as communications with the support staff should be via a central help desk.

Here is where your problem arises because Microsoft publicly state that you cannot use a Security Group provide Site Collection Administrator  access. The reality is that it cane be done both manually and in code.

Manually

To add the security group as the primary SCA you will need to have O365 tenant admin permission. Go to the SharePoint Admin Center, locate the site collection in question , select the check box next to it and then click on Owners in the ribbon. In the Manage Administrators window you can add the security group just like you would any other user, both as a Primary or Secondary SCA.

If you don’t have tenant admin permission you will need to have SCA rights on the site collection in question. In this case you will be able to add the security group as a Secondary SCA by going to Site Settings and then selecting Site collection administrators under Users and Permissions. you can then add the security group as a Secondary SCA just like you would any other user .

Automated

You may have a requirement to retrospectively apply a change like this across your tenant using PowerShell or to set this up when you are provisioning the site collection as part of a provisioning app similar to the PnP provisioning samples.

The usual way to add someone as a SCA to a Site Collection using PowerShell is to use the Set-SPOUser cmdlet for example like this…

Set-SPOUser -Site $siteUrl-LoginName $userEmail -IsSiteCollectionAdmin $true 

You will notice that they way to identify the user being added as an SCA is via the -LoginName parameter which requires a valid email address in the tenant. The issue is that the  Security group doesn’t have an email address so it can’t be used it here. I’ve tried a number of approaches to including using the Object ID returned from Get-MSOLGroup cmdlet to no avail. I was able to resolve it and the simplest way to avcheive uses the claims encoded identity for the security group.

First you need to determine the claims encoded identity for the security group. One simple manual way of doing this is to go to a site and use the Check Permissions feature Under Site Permissions in Site Settings. Check the permissions for the security group in question and part of the report provides you with the claim encoded identity. It should look something like ‘c:0-.f|rolemanager|s-1-1-11-111111111-1111111111-1111111111-11111111’. In my case this manual approach is fine but it is probably possible to retrieve this using PowerShell as well.

Once you know this information you can substitute it where you would normally use the users email address in the SetSPOUser call and it will recognise the security group and set it in the Secondary Site Collection Admins group e.g.

Set-SPOUser -Site $siteUrl -LoginName "c:0-.f|rolemanager|s-1-1-11-111111111-1111111111-1111111111-11111111" -IsSiteCollectionAdmin $true

To achieve the same in code as part of a remote hosted app you will need to use CSOM. Something like the following C# ,NET code should allow you to do this. Obviously you will need to determine the claims ID for each of the security groups you want to add and will have already created you context object ctx

Dictionary<string, string> groupsForAdminAccess = new Dictionary<string, string>()
 {
    {"Global Support Staff", "c:0-.f|rolemanager|s-1-1-11-111111111-1111111111-1111111111-11111111"},
    {"Legal eDiscovery","c:0-.f|rolemanager|s-1-1-11-111111111-1111111111-1111111111-11111111"}
 }; 
 foreach (KeyValuePair<string, string> groupToAdd in groupsForAdminAccess)
 {
    User claimsGroupUser = ctx.Web.EnsureUser(groupToAdd.Value.ToString());
    claimsGroupUser.IsSiteAdmin = true;
    claimsGroupUser.Update();
    ctx.Load(claimsGroupUser);
    ctx.ExecuteQuery();
 }

			

Leave a comment

Filed under General SharePoint Development, Office 365, SharePoint, SharePoint Online

Customising Overlay Colours in SharePoint Calendars

It was recently noted by one of our technical team that when setting up Calendar overlays the list of colour​s available seemed a bit screwed up with the same colour name appearing next to different colours. This issue is a result of the colour palette used to generate the custom Look for all sites in our SharePoint environment and is actually not a currently defined by Microsoft as a bug even though it would be nice to have a bit more clarity and control of how these are determined. So the question was asked ‘can we change these colours?’

I have done some additional research and confirmed that the colours presented to the user for calendars are generated by SharePoint based on the theme selected for the web site (in our case the custom Look) and not immediately customisable for calendars out of the box. Specifically each one of the 9 colours defined comes from the definition of Accent 1-6, Hyperlink, and 2 of the text/background theme colours in the custom Look. This is why the first 6 colours map directly to a colour defined by the accent shown in the SharePoint Color Palette Tool. I think the Hyperlink text/background colours are generated based on the definitions within the custom Look.

There are a number of solutions for implementing customisations but these are point solutions that apply to a specific calendar in a specific site and end users would need to deploy the solution themselves to customise the colours in their calendars. We could possibly look at updating our custom site provisioning app to deploy this customisation with a calendar when the site is first created.

For future reference here a few of possible point solutions (all use a similar approach)…

Leave a comment

Filed under General SharePoint Development, SharePoint, SharePoint 2010, SharePoint 2013, SharePoint Online

Problem rendering infoPath forms for External Lists

I was configuring a set of external content types and associated external lists the other day and encountered the following error message “The form cannot be rendered. This may be due to a misconfiguration of the Microsoft SharePoint Server State Service. For more information, contact your server administrator” when I create the lists to have associated InfoPath based forms (the ASPX based forms were still created).

The form cannot be rendered. This may be due to a misconfiguration of the Microsoft SharePoint Server State Service. For more information, contact your server administrator.

It turns out that because we chose to perform the configuration of services manually the config wizard wasn’t run and as a result the State Service wasn’t configured. To fix this problem we need to configure the state service either by running the config wizard through Central Admin or using the following process from within the SharePoint Powershell command window…

  1. Login to the server using the SharePoint Admin account
  2. On the Taskbar, click Start, point to Administrative Tools, and then open the Windows PowerShell Modules as administrator.
  3. In Windows PowerShell, create a service application by typing $serviceApp = New-SPStateServiceApplication -Name “State Service”
  4. Create a State Service database and associate it with a service application, by typing New-SPStateServiceDatabase -Name ”StateServiceDatabase” -ServiceApplication $serviceApp.
  5. Create a State Service Application Proxy and associate it with the service application by typing New-SPStateServiceApplicationProxy -Name ”State Service” -ServiceApplication $serviceApp -DefaultProxyGroup.

Once these instructions are run, you should have a new State Service Service Application visible under the Service Applications list. You might also need to verify that your web Applications iare associated with the new State Service Service Application before things will start working properly.

Leave a comment

Filed under Microsoft Office Sharepoint Server 2007, SharePoint 2010, Uncategorized

Installation of SP1 for SharePoint Foundation failed

I installed SP1 for SharePoint Foundation yesterday on a brand new insatllation and encountered no problems at all. Today I’ve attempted to install it on another SharePoint Foundation enviornment but this one has a handful of custom Features installed but basically no content loaded. The installation ran fine but I hit a problem when running the config wizard at step 10 (the final step). The progress dialog displayed progress until it reached around 91 percent complete i.e.

The farm is being upgraded in the timer service process. The task is 91.28% completed.

before it failed with the ambiguous error message:

An exception of type Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException was thrown.  Additional exception information: Failed to upgrade SharePoint Products.
One or more configuration settings failed.  Completed configuration settings will not be rolled back.  Resolve the problem and run this configuration wizard again. 
The following contains detailed information about the failure: <log file detail>

I examined the upgrade log file to try and determine what had caused the failure and found the following error:

SyncUpgradeTimerJob: Upgrade timer job failed. Return -1.
07/06/2011 11:25:33  12  ERR                  The exclusive inplace upgrader timer job failed.

There was nothing further to indicate in this log file what caused the problem. At this stage, as far as I can tell everything is working ok, I can still access the site collection and Central Admin running on the server. Given the problem seemed to be a failure of a timer job I reviewed the status of the Upgrade Time job and found that it has its own log file. Upon reviewing this timer job’s log file I found the cause of the failure of the Upgrade timer job:

[OWSTIMER] [SPContentDatabaseSequence] [ERROR] [7/6/2011 11:23:07 AM]: Found a missing feature Id = [e2bd7171-e179-451d-b6b1-6d15a0297e41], Name = [Custom Feature 1], Description = [This feature requires that the Custom Feature 1 feature is enabeld to ensure that all sub sites inherit the required master page.], Install Location = [My.SharePoint.Feature]
[OWSTIMER] [SPContentDatabaseSequence] [ERROR] [7/6/2011 11:23:07 AM]: The feature with Id e2bd7171-e179-451d-b6b1-6d15a0297e41 is referenced in the database [WSS_Content_DB], but is not installed on the current farm. The missing feature may cause upgrade to fail. Please install any solution which contains the feature and restart upgrade if necessary.

So it appeared that it was apparently related to a missing custom feature. After a few checks I ran the config wizard again and it completed successfully and when I checked the upgrade status in Central Admin it shows that the upgrade to SP1 has completed successfully.

3 Comments

Filed under General SharePoint Development, SharePoint 2010

Problems adjusting the list Sharepoint​:FormField width

I’ve been doing some work on a SharePoint 2007 application and have a custom list where one column looks for data in other list. Everything works as expected but I hit a problem with the formatting of the field on the New and Edit forms for the list. On the default forms the FormField doesn’t auto expand to show the full width of the text being reference as shown below…

I’ve used SharePoint Designer to create custom forms layouts a few times before and along with some formatting requests from the customer created a couple of custom form equivalents for the list. The forms work fine and the customer is happy with the formatting except for this width issue.
 
I tried a number of things from setting properties on the control to overriding what styles I thought were being applied but I still couldn’t find a way to adjust the width of the text boxes. When I tried custom CSS I was at best only able to adjust the width of the FormField control but the text boxes don’t auto resize (as shown below) even though you can see the control is now wider. We’ve tried adjusting the DisplaySize property on the control and it makes no difference either.
 

What seems to be happening when you look at the HTML behind the page is that the Form Field control (SharePoint:FormField) is outputing the select boxes wrapped in a DIV tag that uses inline styles and not a CSS class. This makes it difficult to override the width and height settings for the select boxes.

 One suggestion was to look for the next parent that has a sensible ID (not dynamic GUID) or class applied and override the styles making sure you use the !important operator to ensure that the inline style is overridden e.g.  something like: 

td.ms-authoringcontrols table:first-child span table div.areatemplate-selection-panel select {width: auto !important} 

After some discussion on the OzMOSS mailing list Mark Burns provided the following solution based on to idea wrapping the control in a named DIV tag and then using JavaScript on the body load to parse the tags inside the DIV and modify the height and width styles. For more detail on this approach to modifying styles refer to the SharePoint Designer Team Blog entry 

Relevant code I used is shown below:

 

<script type="text/javascript">
function removeLocalStyleAttributes() {
   var coll = document.body.getElementsByTagName("div");

   for(x=0;x < coll.length; x++)
   {
      if(coll[x].className == "select-container") {
         var collDivControls = coll[x].getElementsByTagName("DIV");

         for(y=0;y < collDivControls.length; y++)
         {
            collDivControls[y].style.width = null;
            collDivControls[y].style.height = null;
         }
      }
   }
}
_spBodyOnLoadFunctionNames.push("removeLocalStyleAttributes");
</script>
-------------------------------------------------
<style>
.select-container div{
                      height:400px; }
</style>
-------------------------------------------------
<td width="400px" valign="top">
    <div class="select-container">
          <SharePoint:FormField runat="server" id="ff13{$Pos}" ControlMode="Edit" FieldName="OSCompatibility" __designer:bind="{ddwrt:DataBind('u',concat('ff13',$Pos),'Value','ValueChanged','ID',ddwrt:EscapeDelims(string(@ID)),'@OSCompatibility')}"/>
   </div>
</td>

Leave a comment

Filed under General SharePoint Development, Microsoft Office Sharepoint Server 2007

Problems Caused by IE Developer Toolbar

I’ve had a shocker of a time over the last day or so after I installed the IE Developer Toolbar on my new Windows 7 64bit laptop. I had been trying to debug some issues with a custom SharePoint list form and having used the toolbar on my old laptop to great benefit and with no problems have no hesitation installing it on my new one.

I downloaded the latest version (1.00.2189.0) and proceeded to investigate the issue with cascading styles in my page. The first problem that I started encountering was that some web sites (unrelated to the SharePoint customisation I was looking into) would simply hang. This seemed to get progressively worse to the point where I would have to restart the browser.

Next Microsoft Word 2010 started to intermittently hit problems and close down. Again this got progressively worse until everytime I tried to open a document (both .doc and .docx) Word wouldn’t even open it before  the error dialog appeared and off it went on its merry way trying to work out what went wrong, notify Microsoft and then close down.

Thinking that it could be related to the installation of the developer toolbar I reluctantly uninstalled it and restarted Windows. This seemed to fix the issues with the browser hanging but Word still wouldn’t open documents so I tried doing a Repair of the installation of Microsoft Office 2010 Professional to see if this would fix the issues with Word. After completing the repair and restarting things seemed to be ok and I was able to work on a document review for a few hours last night.

BUT, when I logged in this morning and opened up a Word document I was immediately hit with the problem again. DOH!!!

As a last resort I reverted to the restore point prior to the installation of the IE Developer Toolbar and restarted Windows. This seems to have worked and I have been able to work on various Word documents and in IE without problems since. In my books this confirms without a doubt that the installation of the IE Developer Toolbar on my system was the cause of all these problems. From now on I’ll limit its use to my development server VM’s where I haven’t encountered this problem before.

Leave a comment

Filed under General SharePoint Development, Microsoft Office Sharepoint Server 2007, SharePoint 2010