SharePoint Online: Can't save a site as template if you have Nintex apps installed

Today I tried to save a SharePoint Online site as a template when it had the Nintex Forms and Nintex Workflow apps added. That's obviously not supported (I hope yet). In that specific case, I'll have to use on-premise infrastructure...

Automating group assignment for external users in SharePoint Online

I have this requirement as part of a site that will be built specifically for external users in SharePoint Online.

It's basically an automation need for users to be granted access to certain areas of the site by adding them to appropriate SharePoint Online groups. Users should also be automatically created by a workflow when their details are picked up from a list.

I've done an attempt to do this in SharePoint Designer, but it turns out there's no such action in there.

A couple of alternatives exist - Nintex Workflow which I have in place and Plumsail Workflow Action Pack which I don't have in place but a quick overview can be found on their website.

With Nintex, there is the handy action "Office 365 add user to group", which is usually working well. For external users, however, I found it impossible to resolve them like any Office 365 user.

I understand this might be due to the licensing part of the whole picture (external users can't be assigned a SharePoint Online license), but I am hoping that Nintex would address this issue in any of the future releases.

The only alternative I found so far is to create this user in the Office 365 tenant, assign a license to it (all automated through the workflow) and then add it to the group. Unfortunately, my requirements involve no licensing for such users, so I'll have to find another possible automation approach.

Has any of you managed to accomplish this? Would be happy to hear oppinions.

Web Part Error when trying to view the Nintex Workflow Administration reports

Today I had to do a brand new installation of Nintex Workflow 2013 over SharePoint 2013 SP1.

After following the guide from Nintex, all worked well, except viewing the Administration reports.

This page is part of the Workflow Report Center and contains 10 different reports which are quite useful and they pertain to all sites within the entire SharePoint environment.

So the issue is that whenever you go to the highlighted link in the Nintex Workflow Management section in Central Admin:

You'd end up getting this:

Solution:

1. Open IIS Manager on the SharePoint server.
2. Navigate to the SharePoint Central Administration v4 Site and go to Explore.
3. Open the Web.config file after backing it up and add the two lines below before closing the tag </SafeControls>
4. Save web.config and refresh the Administration reports page.


<SafeControl Assembly="Nintex.Workflow.ServerControls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=913f6bae0ca5ae12" Namespace="Nintex.Workflow.ServerControls" TypeName="*" Safe="True" />
<SafeControl Assembly="Nintex.Workflow.ServerControls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=913f6bae0ca5ae12" Namespace="Nintex.Workflow.ServerControls.WebParts" TypeName="*" Safe="True" />

You should be able to deep dive into the Nintex Reporting functionalities now.

Nintex Workflow calling a web service fails because of SSL Trust

We're using a Nintex Workflow for sending some email notificatoins for a SharePoint 2010 customer.
The workflow has a "Call web service" action which is calling the top level Nintex Web Service at https://rootsitecollection/_vti_bin/NintexWorkflow/Workflow.asmx. Suddenly this has stopped working. The error we see logged when checking the workflow history is that one:

The SSL certificate is valid and has not expired, however we've just recently renewed it.
It's a DigiCert SSL certificate whcih is imported properly and assigned in IIS as it should be.
Now, for some reason it seems it's not trusted by the Nintex Workflow, but what's really happening backstage is that the SharePoint farm is not trusting that one, as it only trusts its local Root certificate by default. I saw the previous Root certificate of the SSL that we've renewed  was added in the Trust manually, however the root CA has changed (the vendor has done that on purpose after one of the SSL bugs discovered recently I believe)  so I've decided to add the new Root CA to the trusted root authorities of the farm:

foreach ($cert in (Get-ChildItem cert:\LocalMachine\Root))
{
    if (!$cert.HasPrivateKey)
    {
        New-SPTrustedRootAuthority -Name $cert.Thumbprint -Certificate $cert
    }
}

That worked. If you don't want to run the whole workflow, you can just get to the action that calls the Web Service and run it (the workflow has to be in Edit mode), good practice is to export it first.

Nintex Analytics causing massive load on SQL

Nintex Analytics is a 3rd party product running on SharePoint (installed as a solution) which is used by some of our customers that are still on SharePoint 2010.I won't go into details about the product, Joel Oleson already did a great review on it a while ago. Nintex are not developing this anymore and the support will be retired on 1st July, 2015, so I've decided to share one of my very few real-world experience cases with it. Meanwhile, there is an alternative product for SharePoint 2013 - HarePoint Analytics for the people that used and loved Nintex Analytics.

The environment:

• SharePoint 2010 Standard - 1 APP, 1 WFE
• Nintex Workflow running on both servers
• Nintex Analytics running on the APP server

...All sharing the same SQL box... which was running fine for 3 years.

One wonderful day we started getting complaints from users that their Intranet is running slow, server graphs showed 100 % CPU on the SQL box since a couple of minutes. That trend has continued and the only process eating it was the one for the SQL Server itself.

I ran a report of the most CPU-expensive queries on the server and found the following:

SELECT @WebCount = COUNT_BIG(DISTINCT w.ObjectId)
 FROM dbo.DimSPObjectsSites o with (readuncommitted)
  INNER JOIN (SELECT DISTINCT ObjectId, ObjectTypeId, EventTypeId FROM dbo.FactAuditData with (readuncommitted) WHERE IntervalId >= @IntervalStart AND IntervalId < @IntervalEnd) f          
   ON  f.ObjectId = o.ObjectId
   AND f.ObjectTypeId = o.ObjectTypeId
   AND f.EventTypeId = 3
  INNER JOIN dbo.DimSPWebs w with (readuncommitted)
   ON w.ObjectId = o.SPWebId
   AND w.WebTemplate = @WebTemplate



That query is making use of the following 3 database indexes:

dbo.FactAuditData.IX_FactAuditData
dbo.DimSPObjectsSites.IX_DimSPObjectsSites
dbo.DimSPWebs.IX_DimSPWebs_WebTemplate

...which are all in the Nintex Analytics Content Databases... so I've started stopping the Nintex Analytics Services that are basically Windows services running on the SharePoint server one by one.. after stopping the Nintex Analytics Data Management Service... the CPU time dropped immediately to the recent levels we've been observing.

I've tried a few other bits and pieces like reconfiguring the reports in terms of data to retain, purging intervals and so on but every time I started the Data Management Service, in a minute the SQL Server was getting hammered (100 % CPU).

I've raised this with the Nintex Support and they've sent me the following SQL query to create a stored procedure:

CREATE PROCEDURE [dbo].[CfgIndexInformation]
AS
BEGIN
SET NOCOUNT ON
DECLARE @indexCounter int,
@maxIndexes int,
@partitioncount bigint,
@schemaname sysname,
@objectname sysname,
@indexname sysname,
@objectid int,
@indexid int,
@partitionnum bigint,
@frag float,
@partitions bigint

DECLARE @work TABLE
(
indexNumber int identity(1,1),
objectId int,
indexId int,
partitionNum bigint,
fragmentation float
)

DECLARE @tables TABLE
(
tableName sysname,
indexName sysname,
fragmentation float
)

INSERT @work (objectId, indexId, partitionNum, fragmentation)
SELECT s.object_id,
s.index_id,
s.partition_number,
s.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, 'LIMITED') s
WHERE s.avg_fragmentation_in_percent > 10.0 AND s.index_id > 0

SET @maxIndexes = @@ROWCOUNT
SET @indexCounter = 1

WHILE @indexCounter <= @maxIndexes
BEGIN

SELECT @objectid = objectId, 
@indexid = indexId, 
@partitionnum = partitionNum, 
@frag = fragmentation
FROM @work
WHERE indexNumber = @indexCounter

SELECT @objectname = o.name, 
@schemaname = s.name
FROM sys.objects o
INNER JOIN sys.schemas s 
ON s.schema_id = o.schema_id
WHERE o.object_id = @objectid

SELECT @indexname = name 
FROM sys.indexes
WHERE object_id = @objectid 
AND index_id = @indexid

SELECT @partitioncount = count (*) 
FROM sys.partitions
WHERE object_id = @objectid 
AND index_id = @indexid

INSERT @tables
SELECT @schemaname + '.' + @objectname, @indexname, @frag

SET @indexCounter = @indexCounter + 1
END

SELECT * FROM @tables ORDER BY fragmentation DESC, tableName, indexName

END

Then I ran the newly created stored procedure (exec CfgIndexInformation) to get information on the Indexes fragmentation. The indexes used by the most expensive query I found earlier were gragmented at 95%, 91% and 66% respectively. I stopped and disabled all the Nintex Analytics services and ran exec dbo.CfgIndexRefresh against all the Nintex Analytics content databases as per the support team advice.

That has decreased the fragmentation a lot and we've managed to run the Nintex Analytics fine after that. The long-term solution is to schedule the index refresh on a monthly basis to avoid reoccurences of that.

Bamboo World Clock & Weather Web Part stopped working today

We are using a 3rd party webpart for displaying weather and clocks for a few customers on SharePoint 2010. The webpart is also available for 2007 and 2013. This has unexpectedly stoped working today (2nd time in the last 2 months). Usually it works quite alright and for a free solution, there's no better alternative. More info in the Bamboo website.

The webpart looks like that when working (just a basic example, there's lots of configuration you could do on the looks of it, what is displayed, sizing and formatting):

Today, I've proactively noticed that the webpart looks like this as I was doing other work for one of the clients that have this in place:

Some quick analysis shows the feed that it used just doesn't exist anymore. It was located here. Now all it says is:

This XML file does not appear to have any style information associated with it. The document tree is shown below.

<weatherdata xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<weather errormessage="Access denied: Please contact weather@microsoft.com if you need access to this API."/>

</weatherdata>

The previous time we've had issues with that webpart, we've just upgraded it as per their recommendations (that includes redeploying the solution and readding the webpart to all pages where you've used it before) and it started working again. I guess a change in the MSN Weather API.
Today, that's not an option as we're running the latest version.

The good news is the webpart has an out of the box option to get the feed from Yahoo instead.
So I've tried that and it worked like a charm. Hopefully that will last longer than the MSN one :)