Friday, June 23, 2017

When should we use "Office 365 Groups"?

There are quite a lot of posts (such as here, here, and here) trying to explain what "Office 365 Groups" is. But, after reading them, I am still confused.

"Office 365 Groups" covers many areas: Azure AD, permission management, document depository (SharePoint sites), email (Exchange Online), group chat (Microsoft Teams), Yammer, etc. But,
  • When should Group be used?
  • Should we convert existing Email Distribution List into Group automatically, during the migration to Office 365?
  • Should we allow users to create new Group when they believe it is necessary?
  • Should we use Group Site to replace normal "Team Site"?
  • Should we create a Group for a new project?
  • Can one user belong to more than one Group?
After months of investigation, finally, I got my own conclusion. However, it is so faraway from the mainstream opinion, it even shocked myself!

There is only one principle: Office 365 Group should be based on basic "Job Role".

Why? Because Group is designed to conquer the challenge of communication between a person and a team. Let me explain it through an use case here.

A user, let's say, Tom, needs help from DBA team to fix a database issue.

Obviously Tom doesn't care which member of the DBA team can help, and he just want the problem get resolved. The procedure may take months, existing DBA member may takes annual leave or even resign, new DBA may join the team at anytime. The communication between Tom and DBA team should not be affected by the those events, and it happens in many apps, such as SharePoint, Yammer, Outlook, Microsoft Teams, etc.

In other words, Tom wants to talk to DBA team, instead of any specific DBA, without the obstacles of permission management, information sharing, action history tracking.

That's why we need Group. Group should only be created for the bottom level, most basic organisation unit, just above individual user.

We should create a Group for DBA team (if there is more than one DBA in the team, and they all look after all databases), but not for IT department (because there is no such job role called "IT staff").

Now, it's easy to answer the previous questions.
  • When should it be used?
For each job role, if there are more than one person share the same responsibility, we should create a Group for them.

Normally it's just a few users, but, in some special case, for a role like "help desk", there could be more than 30 people.
  • Should we convert existing Email Distribution List into Group automatically, during the migration to Office 365?

Unless the DL is created exactly for a job role.
  • Should we allow users to create new Group when they believe it is necessary?
Users should contact Office 365 administrators to create it.
  • Should we use Group Site to replace normal "Team Site" during migration (from On-Premise to Office 365)?

Unless the existing team site is created exactly for a job role.
  • Should we create a Group for a new project?
  • Can one user belong to more than one Group?
Normally, no.
Unless he/she happens to take two roles in two teams.

I know many people have different thoughts about "Office 365 Groups". Any comments are welcome!

PS: Microsoft Teams are perfect Application for Office 365 Group. We can create a new channel for each topic/task.

Wednesday, May 31, 2017

Pause workflow instances between 8pm to 6am

Servers are busy at midnight. Data backup, data synchronization, report building ...... keep the storage system and network busy, and databases may get locked up from time to time..

That's bad to those SharePoint workflows being triggered at night. Sometimes they would simply stop working and throw out errors.

Below is how I resolve this problem in Workflow 2010 and 2013.

Tuesday, May 30, 2017

Workflow(2010) need to be triggered twice after being published or after SharePoint server (2013) is rebooted

There are more than 200 site collections in Production environment. Many of them have SharePoint Designer workflows (declarative workflows). No customized activity get involved.

Recently users reported that a few workflows could not get triggered. But this problem only happened intermittently, and only 2010 workflow have this issue..

I did some test. They were right: I have to trigger the workflow twice to make it work, if the workflow got re-published, of if the SharePoint Server 2013 is rebooted.

There was not specific error message in ULS or Windows Events log, and the problem only appears in two site collections.

That's hard for trouble shooting.

My first guess: some site collection level feature is corrupted. The feature should be related to Workflow 2010. The most famous one is "Microsoft Office Server workflows" ("OffWFCommon", c9c9515d-e4e2-4001-9050-74f980f93160).

The PowerShell script below shows that the feature is activated properly.

$site = get-spsite $url
Get-SPFeature -Site $site -Limit All |?{$_.DisplayName -match "OffWFCommon"} | select *

What the problem could be? After hours of struggling, finally I found how to fix it: disable this site collection feature, and then rebuild the workflow.

(Thanks for the "copy and paste" functionality in SharePoint Designer, to rebuild a workflow is not as hard as before.)

Once the feature is disabled, we cannot modify the workflow initialization form any more. But, in most of cases, that’s not a problem.

Why this can fix the problem? I have no idea.

Please share your insight in comments if you know the root cause.  Many thanks!

PS: In SharePoint 2010, if this feature is disabled, then workflow will not be triggered. I haven't test it in SharePoint 2016 yet.

Thursday, May 18, 2017

MIM 2016 - Trouble Shooting - All users are filtered?

After the installation and configuration of MIM 2016 following this link, I noticed that no users can be synced from AD to SharePoint User Profile store. The Synchronization Service Manager shows the screenshot below.

All users fall into "Connectors without Flow Updates", and got filtered during syncing.

To fix that is easy: add a join rule for "user"("Data Source Object Type").

I am quite surprised that this is not added to the Step By Step Installation User Guide.

MIM 2016 - ADMA - AD Replication error 8453: "Replication access was denied"

I am pretty sure that the ADMA service account "_SPSyncUp" have been granted "Replicating Directory Changes" permission of the AD, because it had been used by SharePoint built-in "User Profile Sync Service" for years.

But, the AD Replication error 8453 still appeared.

The error log in Windows Event Viewer doesn't help much. Below is the error message:

The management agent "ADMA" failed on run profile "FullImport" because of connectivity issues.

The management agent "ADMA" failed on run profile "FullImport" because a partition specified in the configuration could not be located.

The DCDIAG Replication test (DCDIAG /TEST:NCSecDesc) reports that everything is OK.

So, what is wrong?

It turns out that MIM 2016 asks for more access rights than SharePoint built-in "User Profile Sync Service". As the screenshot below shows, we have to grant "Replicating Directory Changes" permission of the AD configuration partition to ADMA service account.

That can be done through "adsiedit.msc".

Monday, May 1, 2017

Simple Email Reminder through SharePoint Workflow 2013

For SharePoint reminder, my first thoughts is "scheduled PowerShell script". Three years ago, I posted how to do that. But that needs SharePoint administrator to get involved.

Can business users do it by themselves? Yes, they can, but the workflow is a bit complicated.

Thanks for the "Loop" functionality from SharePoint Workflow 2013, we get much simpler solution.

But it's not as simple as it should be, due to lack of "DateTime" relevant functions.

Anyway, only one workflow and one list is needed.

1. Workflow.

2. Three variables are needed in the workflow. ("create" is automatically created by Designer)

3. Three calculated fields "CurrentDay, CurrentHour, CurrentMinute" are created here.

But normally we only need one of them.

To send out email every hour, we need field “CurrentMinute”; (this is the one being used in the example above, pause for one minute each time)

To send out email every day, we need field “CurrentHour”; (pause for one hour each time)

To send out email every month, we need field “CurrentDay”. (pause for one day each time)

When the value of field “Title” is set to “exit”, the workflow will exit.

Every time when an email is sent out, a new item is created in the same list.

[update, 2017-06-06]

The other way is to do it through OverDue Task. Two emails will be sent out, and can only be sent to the same SharePoint user group (or same user).

But normally that's fine.

Since it's much easier to configure, I believe it's a better solution.

Thursday, April 13, 2017

Claims Authentication error: Trusted provider is missing. Provider: '00000003-0000-0ff1-ce00-000000000000'

Some end users reported missing emails from workflows, but they could not reproduce the problem, and me either. So I put it on hold.

A few weeks later, the same issue happened again.

The error messages in ULS are:

04/11/2017 10:14:30.55 w3wp.exe (0x2A3C) 0x6E48 SharePoint Foundation Claims Authentication amcbl Medium Trusted provider is missing. Provider: '00000003-0000-0ff1-ce00-000000000000' 97c8e69d-f945-3099-c843-9153fa257c74

04/11/2017 10:14:30.60 w3wp.exe (0x2A3C) 0x6E48 InfoPath Forms Services Runtime m0ib Medium Not persisting state for request due to previous errors. Form Template: urn:schemas-microsoft-com:office:infopath:workflowInitAssoc:-AutoGen-2017-04-07T00:12:12:113Z 97c8e69d-f945-3099-c843-9153fa257c74

After some investigation, I finally found how to reproduce the error.

Every time when SharePoint server is rebooted (for windows OS patching or something else), or after re-publishing the workflow, the workflow instances would not be triggered. Users have to trigger it again (manually or through a item level event) to make it work.

It only happened on 2010 version workflows.

That's interesting.

I replicated the site collection to DEV environment, and then tried it there. Same.

I created a new site collection in DEV, and built a new workflow there. The workflow worked well.

I compared all settings at different level (site collection, site, list, workflow, etc.), and could not find the problem.

SharePoint 2013 CU201703 is installed, but that doesn't help.

In the end, as the error mentioned that it's throw out by "InfoPath Forms Services", I decided to switch the workflow URL from

{Site URL}/_layouts/IniWrkflIP.aspx?List={List ID}&ID={Item ID}&TemplateID={Template ID}


{Site URL}/Workflows/{Workflow Name}/{Workflow Initiation Form Page}?List={List ID}&ID={Item ID}

The first one, by default, is used by SharePoint Standard and Enterprise edition; the latter is used by SharePoint Foundation server. Of course InfoPath form provides much more functionalities to the workflow initiation form. But in my case, we don't customise any workflow form.

The change can be done by the PowerShell script below:

Get-SPSite $SiteUrl | %{ Get-SPFeature -Site $_ |?{$_.DisplayName -eq "OffWFCommon"} | Disable-SPFeature -URL $SiteUrl}

Then, we have to rebuilt the workflow. (Thanks God, we can copy & paste workflow activities in SharePoint Designer now)

That's it.

If any one knows the root cause of this problem, could you please share it here?