Microsoft seem to have resolved an issue with the synchronisation of users profiles between the different services within Office 365. Previously once a user had been added through the Office 365 portal, their information would not be synchronised with the other services, such as SharePoint online. This meant that should the user start a workflow, it would fail due to the user profile not being found in SharePoint online. A few weeks ago we added two new users to the Office 365 portal, and these both did not synchronise to the other services. However, as of yesterday these user profiles now appear in SharePoint online. Hopefully this issue is now all resolved.
Recently we have been researching how Windows PowerShell could help with the some of the more advanced administration tasks of SharePoint Server 2010 and Office 365. Our most recent discovery of Windows PoweShell is an online Command Builder, which enables users with limited knowledge of Windows PowerShell the ability to create commands to perform certain functions. The command builder, shown below, lets users select the product they have, either SharePoint Server 2010, SharePoint Foundation 2010 or Office 365. There is then the option to filter all the commands based on what you wish to do.
It is through exploring this command builder that we have seen the difference of what Windows PowerShell can do for SharePoint Server 2010 and Office 365. The difference in functionality is greater than what I expected. With Office 365 you appear to only get basic functionality such as ‘Get’, ‘Set’, ‘Add’, ‘Remove’ and ‘Update’ etc. In comparison SharePoint Server 2010 offers much more. As shown in the image above there are functions to revoke and grant permissions, publish and un-publish content, and also options to install and uninstall.
Here is an example of a command that was built in the command builder and sent to clipboard:
“Set-SPUser -Identity “Robert Everatt” -Group “Administrator Extraordinaire” -MobileNumber “666” -IsSiteCollectionAdmin”
So today Rob and I discovered that it is possible to work with Windows Powershell in the Office 365 environment, using the Microsoft Online Services module. We decided to follow the instructions and install the necessary components. Following some basic commands we were able to perform some basic administration on users, such as, changing display names, contact numbers and names.
However after some more research into the matter, Rob discovered that the data being changed by these commands was the data held in the main Office 365 user profiles, and not in the SharePoint user profiles. This is why we were not able to access the custom user properties that we had created to handle the extra functionality of the annual leave process. However, this should be possible when using SharePoint Server 2010 instead of SharePoint Online with Office 365.
Whilst investigating another problem we were experiencing on the SharePoint site, we stumbled upon some User Profile and Properties options. We had previous been looking at storing additional fields against a user to hold information such as leave entitlement and leave remaining. The properties of the user can be edited and custom fields can be created. The image below shows the administration centre where these additions can be made.
We were able to add the two additional fields that we require at this stage in testing and development. We were also able to read the values of the two fields and have them returned to the user in an email using a workflow. However we quickly discovered that it appears to not be possible to write data back to the fields. In this instance this would allow us to keep track of the number of days leave a user has remaining.
For the last week now, Michael and I have been struggling with a very persistent workflow issue. An approval workflow that we have created, works fine when it’s started by an administrator, however when it started by a regular user, then the approval process won’t work. The workflow is activated with the permissions’ of the user that started it, not the permissions of the approver or the author. It isn’t currently an issue for the work we’re doing, but it will need to be fixed for use in a real world environment. Googling the problem didn’t seem to help, there were too many vague “fixes”, that required complicated multiple workflows that never seemed to work. There didn’t seam to be a solution to this problem anywhere on the internet. However, I then remembered that someone gave me a large SharePoint 2010 book as a “congratulations for getting the job”, so I decided to see if I could find a solution in there. The solution showed itself almost immediately.
The answer is: High-Privilege Workflows. I found this solution to be extremely easy carry out, and it solved our workflow problems 100%. A high-privilege workflow runs with the permissions’ of the person who created the workflow. While editing the workflow, you simply click in the area just below the first step, go to the “insert” section of the ribbon bar and click “Impersonation Step”. This adds a new step into the workflow that carries out the actions within it using the permissions of the workflow author.
I find it embarrassing that the solution was so simple, however I thought I might write a post about it, incase any others users were coming across the same issues.