Category: Uncategorized

If you are currently using Basic Authentication for application access, then you are required to migrate to Certificate based authentication prior to mid February.

Microsoft is rolling out this change and it should be completed by early March. With this update, Security and Compliance PowerShell will enable configuration of certificate based authentication to allow unattended app-only access.

To migrate to certificate based authentication follow the steps below:

• Step 1: Register the application in Azure AD
• Step 2: Assign API permissions to the application
• Step 3: Generate a self-signed certificate
• Step 4: Attach the certificate to the Azure AD application
• Step 5: Assign Azure AD roles to the application

Learn more:

• Connect to Security & Compliance PowerShell
• App-only authentication for unattended scripts in the EXO V2 module

When working with Nintex workflow Item Update activity you would realize that it has different properties for document library and lists. For example if you are updating an item in document library it will allow you to update both Name and Title vs in Custom list it will only give you title.

This works perfectly fine until someone decided to use the folders in custom list and then have a business process to rename the workflow. Then Item update activity would not work in this case. Since to rename workflow you would need to set the Name property and not the title property but since it’s a custom list Workflow only property that is available to you is Title.

Workflow would run just fine and update the title but when you click on the folder it will display the folder Name and not the title.

With this business problem I have decided to use the REST API to update the folder Name. I am not going to talk too much about how to use the REST API with Nintex workflow since there is a good article on that. You can read about it at the following URL.

https://community.nintex.com/community/build-your-own/blog/2015/04/24/how-to-execute-a-rest-api-request-with-nintex-workflow

 

Only change you would need to do to change the folder Name is in the last step. In the last step you would need to change the property that you would like to update. So in our case it will become,

{

     '__metadata' : { 'type' : '{WorkflowVariable:listItemEntityType}'},

     'Title' : 'Folder Title',

     'FileLeafRef' : 'Folder Name'

}

And that is all you would need to do to rename a folder. Knew it would be simple but since I had to plug that REST API using the Nintex workflow there is some plumbing that you would need to do. 🙂

I wanted to write this blog post for a while. This one is on how to use Microsoft Flow and get SharePoint list item.

So when using Flow you have two actions for getting a SharePoint list Item.

1. SharePoint  – Get Item
2. SharePoint – Get Items

 

Picture above displays the description of each action.

Lets talk about the SharePoint – Get Item action first. As you can see that when using this action you will need to specify item ID to get the item. Now for the most part this would not work unless you have a context of the item and you are passing the ID using the context. We will talk about this in details when I cover For Each action. But for now my recommendation is do not use this action using the hard-coded ID unless you are in a situation where you have pretty static list and ID never changes.

Now the second action, SharePoint – get Items is the real deal. I mean do not judge that action by the description provided by Microsoft. That description does not justify the action. 😀

This action allows us to specify query to get the items and also allows us to specify Order By and Item count.

You need to specify ODATA filter query. You can get some general ideal about ODATA query using THIS article.

Basically you would have to specify field’s internal name and then your expression and then your value.

If you are expecting more than one item returned then you can use the Apply to Each action which I will cover in future blog post.

If you are using Microsoft Teams then you must know that  the #1 request feature on Microsoft Teams uservoice is to allow Guest Access. Microsoft Announced on September 11 that they will start rolling out Guest Access to Microsoft Teams.

This is awesome news and I am looking forward to testing the guest access with Microsoft Teams.

Now there are couple of things that we must know. Microsoft Teams have decided to only allow Azure AD accounts that are currently part of Office 365 tenant. This means if you are inviting external user as Guest to your MS Teams they must be part of any other Office 365 tenant as a regular user. Then you will be able to add them to your Team.

Now to add external users you will need to make sure that this setting is enabled at the admin level.

• Navigate to your Office 365 Admin Center
• Click Settings –> Services and add-ins –> Click Microsoft Teams
• Select Guest from the “Select the user/license type you want to configure” dropdown
• Turn ON the “Turn Microsoft Teams on or off for all users of this type” switch.

Once this is turned on you will be able to go to your MS Teams and add external users. Once the external users are added they can switch their tenants to access the Teams. Currently switching the tenant option is not supported on mobile devices and hence you must use the desktop app or browser to switch the tenant.

This is a great start by Microsoft Teams and hopefully in future we will more improvements around this area specifically allowing any external users and allow switching the Teams using mobile devices.

In this blog post I am going to talk about SharePoint Server 2013 and SQL Server Reporting Services integration. If you want to configure SSRS in SharePoint integration mode then you can refer to the article below.

https://blogs.msdn.microsoft.com/biblog/2012/12/04/installing-and-configuring-sql-reporting-services-on-sharepoint-2013/

Once you have SSRS configured in SharePoint Integration mode and you try to create a new report depending on the configuration you may receive the following error.

The permission granted to user ‘NT AUTHORITY\ANONYMOUS LOGON’ are insufficient for performing this operation.

Upon some search I found that you will receive this error if you have turned on Anonymous Access at your Web application level.

• Go to your SharePoint Central Administration
• Click Manage Web Applications under Application Management.
• Select the Web Application where you are getting the above error and click Authentication Provider.
• Select the Authentication Provider Zone(default is Default).
• Confirm that you have not checked Enable Anonymous access.

Now if you must have the Anonymous access enabled on your web application the only way you can get it working is by creating a new web application where Anonymous access is not enabled. Get your report ready on that web application and then move it to the web application where you will be using it.

Basically your report would work just fine but you will not be able to design it when you have Anonymous access enabled.

I hope this helps.