One of the common challenges I encounter when working with SPFx components is that the app doesn’t work with IE11 as expected even though it works fine with other browsers. This has delayed many of my projects and puts a lot of risk on production releases. Hence in this blog, I will try to call out some of the challenges that we might run into when deploying complex SPFx components in IE11 and other older browsers, and some workarounds/rectifications for the same.… [Keep reading] “Dev Tips : Planning IE11 compatibility with SPFx components and PnPJS library”
Sometimes I get requirements when projects require a full width layout pages in Team Sites or would like to create a page which is System maintained, so users cannot edit those pages. In this blog, we will look at some of these options and how easy it is to set them up using PnP PowerShell
Over the last year, we have seen many great advancements with SharePoint communications sites that have bought it more closer of being an ideal Intranet. In this blog series, I will be discussing about some of my experiences for the last years in implementing Modern Intranet and best practices for the same.
During Ignite 2018, Microsoft showcased some great updates that are going to change how we implement SharePoint Intranets. It will scale Modern Communication sites to new heights to become the Next-gen Intranet.
Since Ignite 2018, there have been many steady releases and some great updates on SharePoint Modern communication sites. Following this blog, I am planning to start with a detailed blog series about how to build cool Modern Intranets in SharePoint #makespintranetcoolagain.
Custom reporting for Office 365 Audit logs is possible using data fetched from the Security and Compliance center. In the previous blogs here, we have seen how to use PowerShell and Office 365 Management API to fetch the data. In this blog, we will look at planning, prerequisites and rationale to help decide between the approaches.
For creating custom reports on Office 365 content, the best approach is to fetch the Audit data from Office 365 Management Audit log, store it in a custom database and then create reports through it. In an earlier blog here, we looked at steps to retrieve Office 365 Audit log data using PowerShell. In this blog, we look at a similar process to gather audit data by using Office 365 Management API in Azure Functions.… [Keep reading] “Retrieve Office 365 audit logs using Office Management API and Azure Functions”
Azure AD apps provide a faster and secure way to connect to the Office 365 tenancy and carry out automation tasks. There are many advantages of using Azure AD apps and could be used to authenticate for various Microsoft services such as Graph, Office 365 Management Api, SharePoint etc.
In a recent project, we had a requirement to prevent specific selective content from shared externally while still allowing the flexibility of external sharing for all users. We were able to make it possible through Security and Compliance Center. There are few ways to achieve this, Auto-classify (see below conclusion section for more info), Selective apply via Labels and both.
Note: Till recently (Dec 2018), there was a bug in Office 365 which was preventing this DLP policy with Labels to work. This is fixed in the latest release so available for use.
In this blog, we will look at the process where business users can decide the content to be shared externally or not. This is a nifty feature, because there are cases when the content could be classified as secured even when they don’t have any sensitive info such as contracts (without business info) or invoices (with only business name). Also, there are cases when content could be public even when the document has sensitive info because the company has decided to make it public. So, at the end it is up to the discretion of the owner to decide the content’s privacy and hence this feature a great value in these scenarios.
Note: If you would like to auto classify the content using Sensitive info types, please refer to the great article here. This process leverages the machine learning capabilities of Office 365 engine to identify secure content and automatically apply the security policy on it.
The first step is to create a Retention label (somehow this doesn’t work with Security labels, so must create retention label). After creating a label, publish the label to the selected locations, for our use case we will post it to SharePoint Sites only. While the label is published, we could go ahead and create a DLP policy to prevent sharing with external users (I was not able to make it work while set to Test with notification so put it to on state to test also). After this, when you apply the label to a document, after some time (takes about 1-2 min to affect), then the content is not able to be shared with external users. Lets’ look at each of the above steps in detail below.
First step is to create a retention label in Security and Compliance center. To my astonishment, the selective process doesn’t work with Security Labels but Retention Labels, so will create Retention Labels. If it is optional to apply a retention period to the content, then the retention period can be left, so not required for this exercise.
Secondly, we will publish the label to SharePoint Sites, for our requirement. I haven’t tried the process with other sources such as Outlook and One Drive but should work the same when applied. Note: It takes about a day for the retention labels to publish to SharePoint sites, so please wait for that to become available. We can move to the next configuration step right away but will have to wait for the label to be published to stop sharing.
Next, we could create a DLP policy for the content to be applied. For creating a DLP policy we need to follow the below configuration steps. Once created, we might have to turn it on in order to test it.
First step of the policy creation would be select Custom Policy for DLP policy creation and give it a name.
Then, we would select the sources to be included for this policy. In our case, it is only SharePoint.
After the above, we will set rule settings for the DLP policy where we will select the label to which the policy to apply, then select the policy tips, block sharing rules and override rules as shown in the below screenshots. We could also set the admins (provided) to get notified when such as content is shared externally.
Next, we could allow the users to override the policy if needed. For this blog and our requirement, we had decided to not allow it to happen.
After this is setup, we could turn on the DLP policy so that it could start applying the rules. There doesn’t seem to be any wait time for applying the policy later but give it some time if you don’t see it happening right away.
Now the policy is enabled and if the label are published, the user can then apply the label on a content as shown in below screenshot. Note: In some cases, it takes about 2-3 min for the policy to be effective on the content after applying the label so give it some time.
After the label is effective after 2-3 min wait, if the same content is shared with an external user, we get the following error.
If there is a complex web part to be implemented (for eg. with over 5000 lines of code), then the important question to ask is how to distribute the implementation logic, so it could be better maintained. From a technical architecture point of view, better readability and efficiency, the react components provide a suitable solution for it.